Service
There multiple challenges with pods. Suppose we have two pods with one front-end and one back-end. Now we have couple of questions –
- How does the front-end app expose to the outside world?
- How the front-end app talks to the back-end app?
- When a pod dies a new pod gets created and get assigned with a new IP Address. How to resolve Pod IP changes, when pod die?
So, the services are the way of grouping of pods in a cluster. We can have as many as services in cluster. There are mainly three type of services in k8s –
- ClusterIP – It actually deals with the pod IP change problem. It’s a static IP address that can be attached with each pod. So even the pod dies the service stays in place and don’t change. Exposes the Service on an internal IP in the cluster. Here the service only reachable within the cluster.
- NodePort – Makes a Service accessible from outside the cluster.
- Load Balancer – Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service.
# Get the running services
$ kubectl get services
# Expose service to outside of the world
$ kubectl expose deployment/kubernetes-bootcamp --type="NodePort" --port 8080
# Delete a specific service
$ kubectl delete service -l app=kubernetes-bootcamp
Scalability
When we want to scale our app then we create multiple replica of the pods on the nodes and to balance the request on each pods we use load balancer service.
Rolling Update
K8s allows us to do rolling updates and let’s see how it does –
- First it creates the new pod with updated config.
- Then it replaces the new pods with old ones one by one and change the pod IP addresses.
It allows app to update in zero down time.
# Update image of the application
$ kubectl set image
# Get Rollout update status
$ kubectl rollout status <service_name>
# Get the service info
$ kubectl describe <service_name>
# Roll Back to the deployment to your last working version
$ kubectl rollout undo <deployment_name>