DevOps Classroom Series -12/Sept/2021


  • Annotations provide a place to store additional metadata for kubernetes objects with sole purpose of assisting tools and libraries
  annotatations: ""

Service Discovery

  • 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 Preview
  • 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 Preview
    • 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 <service-name>.<namespace>.<svc>.<cluster.local>
    • For the service shown in image the DNS name would be ngix-svc.default.svc.cluster.local
  • Lets create a nginx service with cluster ip Refer Here
apiVersion: v1
kind: Service
  name: nginx-svc
    app: nginx
    - protocol: TCP
      targetPort: 80
      port: 80
  • Create replicaset and service Preview

  • 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



  • 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 Preview Preview Preview
  • 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


  • Deployment Strategies

    • Recreate:
      • 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
    • RollingUpdate:
      • 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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

About learningthoughtsadmin