I'm in the middle of creating an K8s app that doesn't expose any HTTP endpoints, is just a background app that pulls messages from a message bus and takes some action based on the incoming message. No other apps will interact directly with this background app, only thru posting messages into the message bus.
Scaling is a requirement and most likely will always need to run more than one replica. What is the recommended Service type in Kubernetes to handle this type of workload ?
No service required... just create a Deployment, which will result in a ReplicaSet, which will keep n replicas of your app running.
Related
I have a containerized legacy application using VNC as an XServer.
I'd like to run this application in a Kubernetes cluster, and start an application instance on-demand, when a new user logs in the system.
I'd like to
scale the number of PODs on-demand and not automatically with the replicas property
provide unique host/port to the clients to connect to their own VNC server?
How can I achieve this in K8S?
Your question is a bit contradictory, since on-demand scaling is a variant of automatic scaling.
Given your constraints you could create a custom application in which users request their connection data. Upon request your application talks to the kubernetes api and scales up the number of instances.
You would use a headless service to get the list of endpoints and associate a specific endpoint to a user. Your application would reserve a specific port for that user. You then have to create a new nodeport or loadbalancer service to expose this port of your application that forwards to the chosen instance.
After all this sounds like a lot of effort, perhaps your concept is not a good match for kubernetes.
I have 2 Deployment - A(1 replica) and B(4 replica)
I have scheduled job in the POD A and on successful completion it hits endpoint present in one of the Pods from Deployment B through the service for Deployment B.
Is there a way I can hit all the endpoints of 4 PODS from Deployment B on successful completion of job?
Ideally one of the pod is notified!! But is this possible as I don't want to use pub-sub for this.
Is there a way I can hit all the endpoints of 4 PODS from Deployment B on successful completion of job?
But is this possible as I don't want to use pub-sub for this.
As you say, a pub-sub solution is best for this problem. But you don't want to use it.
Use stable network identity for Service B
To solve this without pub-sub, you need a stable network-identity for the pods in Deployment B. To get this, you need to change to a StatefulSet for your service B.
StatefulSets are valuable for applications that require one or more of the following.
Stable, unique network identifiers.
When B is deployed with a StatefulSet, your job or other applications can reach your pods of B, with a stable network identity that is the same for every version of service B that you deploy. Remember that you also need to deploy a Headless Service for your pods.
Scatter pattern: You can have an application aware (e.g. aware of number of pods of Service B) proxy, possibly as a sidecar. Your job sends the request to this proxy. The proxy then sends a request to all your replicas. As described in Designing Distributed Systems: Patterns and Paradigms
Pub-Sub or Request-Reply
If using pub-sub, the job only publish an event. Each pod in B is responsible to subscribe.
In a request-reply solution, the job or a proxy is responsible for watching what pods exists (unless it is a fixed number of pods) in service B, in addition it need to send request to all, if requests fails to any pod (it will happen on deployments sometime) it is responsibly to retry the request to those pods.
So, yes, it is a much more complicated problem in a request-reply way.
Kubernetes service is an abstraction to provide service discovery and load balancing. So if you are using service your request will be sent to one of the backend pods.
To achieve what you want I suggest you create 4 different services each having only one backend pod or use a message queue such as rabbitmq between service A and service B.
You can use headless service. That way Kubernetes won't allocate separate IP address and instead will setup DNS record with IP addresses of all the pods. Then in your application just resolve the record and send notification to all endpoints. But really, this is ideal use case for pub-sub or service discovery system. DNS is too unreliable for this.
PUB-SUB is the best option here. I have similar use case and I am using pub-sub , which is in production for last 6 months.
I have a use case in which front-end application in sending a file to back-end service for processing. And at a time only one request can be processed by backend service pod. And if multiple request came service should autoscale and send that request to new Pod.
So I am finding a way in which I can spawn a new POD against each request and after completion of processing by backend service pod it will return the result to front-end service and destroy itself.
So that each pod only process a single request at a time.
I explore the HPA autoscaling but did not find any suitable way.
Open to use any custom metric server for that, even can use Jobs if they are able to fulfill the above scenario.
So if someone have knowledge or tackle the same use case then help me so that I can also try that solution.
Thanks in advance.
There's not really anything built-in for this that I can think of. You could create a service account for your app that has permissions to create pods, and then build the spawning behavior into your app code directly. If you can get metrics about which pods are available, you could use HPA with Prometheus to ensure there is always at least one unoccupied backend, but that depends on what kind of metrics your stuff exposes.
As already said, there is no built in way for doing this , you need to find custom way to achive this.
One solution can be use of service account and http request to api server to create back end pod as soon as your service is received by front end pod, check status of back end pod and once it is up, forward request to back end.
Second way i can think of using some temp storage ( db or hostpath volume ) and write cronejob in your master to poll that storage and depending on status spawn pod having job container.
We have an application that's receiving calls from other services that use Eureka to discover the different IP addresses of the different application instances/replicas.
When deploying a new version of this app, our deployment system (kubernetes in our case) sends a SIGTERM to one of the instances of the application to shut it down.
But the Eureka client in the services sending requests to the application, keeps a local cache of Eureka's information. Meaning that these applications won't realize that the instance of the app has been shutt down, and they will continue to send requests to an instance that is no longer working.
Is there a way to make a Spring Cloud application to wait for some seconds before shutting down to make sure that all clients have the updated Eureka information (where this app won't be listed anymore)?
If you're using Kubernetes then you could map a Service to each of the apps/services that register with eureka and tell the apps to register using the service name instead of an IP. Then you can manage the blue/green deploy with Kubernetes (provided you've got probes set up). Eureka will then just know about the Service names and whether something is registered for them and Kubernetes will be managing availability during the upgrade. It's a bit of a hybrid model.
If you are removing an app or changing the name rather than upgrading then I think you'll need to set a lease time for the eureka registration data. Eureka never unregisters a service
I have an app with 3 nodes running with a service, which uses zookeeper to elect a leader. And I want the requests to the service to be redirected to a certain pod, depending if it's leader or not. I have a http method in my app that returns if it's leader or not (if this helps in any way).
I'm not aware of a k8s feature for doing this.
What I would do:
write a little application which looks for the endpoints of the existing service, searches the current leader, and creates/updates a 2nd service without selector (https://kubernetes.io/docs/concepts/services-networking/service/#services-without-selectors) with an endpoint pointing to the leader. Then you can use that new service for your dashboard.
To do that, use a StatefulSet, for example, following the example here.