- Annotations provide a place to store additional metadata for kubernetes objects with sole purpose of assisting tools and libraries
metadata: annotatations: qt.com/icon-url: "https://qt.com/icon.png"
- Lets assume we have create a replica set of k8s with two pods
- Each pod will have labels and will have unique ip address
- How can these pods be accessed by other pods in cluster and externally
- Using Pod Ip is not sensible even with in the cluster as Pods can be added or removed either dynamically or manually
- Kubernetes has service discovery and it supports DNS and load balancing
- Service Object:
- K8s service discovery starts with Service Object
- Because the cluster ip (ip address given to service ) is virtual and it is appropriate to give it a DNS address
- Service can be accessed also by a DNS name and k8s provides a DNS service exposed to pods running in cluster
- The DNS for service will be
- For the service shown in image the DNS name would be
- Lets create a nginx service with cluster ip Refer Here
--- apiVersion: v1 kind: Service metadata: name: nginx-svc spec: selector: app: nginx ports: - protocol: TCP targetPort: 80 port: 80
Create replicaset and service
Service Types: Refer Here
Refer Here for the changes done to add node port
We will look into load balancers in AKS and EKS
Scaling Replica Sets
- Imperatively scale
kubectl scale replicaset <rs-name> --replicas=<desired count>
- Declaratively scale: Change the yaml field replicase in replicaset manifest and apply
- Autoscaling a Replicaset: k8s can handle scaling automatically based on CPU and memory consumptions using Horizontal Pod AutoScaling (HPA)
- Now lets try to autoscale rs using cpu
kubectl autoscale rs nginx-rs --min=3 --max=6 --cpu-percent=80
- Manifest to HPA also can be written Refer Here
- We can run our application in pods with autoscaling configured and expose our application to the outside world using service
- However they do little to help you manage the daily or weekly releases of your applications
- The Deployment object exists to manage the release of new versions.
- Deployments enable you to easily move from one version of your application/code to the next. This is referred as rollout process.
- In some case the new rollout might lead to errors/application issues and we would like to go back to previous versions. K8s deployment covers this scenario as well as the deployments in k8s support roll-backs (undo rollouts)
- Lets create a Deployment for an application Refer Here
- The deployment manifest is changed to new version Refer Here
- Now lets apply the deployment with –record flag
kubectl apply -f my-deploy.yaml --record="version 2"
- Now lets assume we need to rollback to revision 1
kubectl rollout undo deployment myapp-deploy --to-revision=1
- It simply updates the ReplicaSet it manages to use the new image and terminates all the Pods associated with deployment.
- The RS noticies it no longer has any replicas and recreate all Pods with new changes
- This is simple and fast but has one major drawback i.e. this strategy will have some downtime
- This recommeded strategy
- This deployment has maxSurge and maxUnavailable fields
- maxSurge is the maximum number of new Pods to be created above the desired number of pods and can be expressed in numbers or percentage
- maxUnavailable: he maximum number of pods that can be unavailable during the update.
- Refer Here for the documentation
Refer Here to view the deployment manifest with strategy