DevOps Classroom Series -12/Sept/2021

Annotations

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

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

Deployment

• 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

• 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