DevOps Classroom Series – 05/Jul/2020

Controllers contd

  • ReplicaSet:
    • Is also used to create number of pods across k8s cluster, but it is managed by other controller (generally in major use cases) Deployments
  • Deployment:
    • Deployment is a controller used in k8s to deploy new versions of your applications. If managed correctly it would help in zero down time deployments
  • Jobs and CronJobs: These are controllers with Podspec having containers which will call the job script/command. The controllers wait for the containers to be terminated and job status is reported back. Cron Job can automatically call the containers on scheduled times
  • DaemonSet: DaemonSet runs a Pod as mentioned in spec on every node in k8s cluster

K8s Cluster Networking

  • Any K8s Networking has to address the following 4 networking problems
    1. Highly-Coupled container-to-container communications: This is solved by pods (bcoz pods get ip address) and two contianers in the pod can communicate with each other on localhost
    2. Pod to Pod Communications
    3. Pod to Service Communications
    4. External to Service Communications

Kubernetes Network model

  • Every pod gets its own IP address
  • K8s imposes following requirements to any networking implementation
    • pods on a node can communicate with all pods on the nodes without NAT
    • Agents on node (kubelet etc) can communicate with all pods on that node
  • K8s networking model is based CNI (Container Networking Interface)
  • Some of the implemenations of k8s CNI
    • AWS VPC CNI
    • Azure CNI
    • Cilium
    • Flannel
    • Google Compute Engine
    • Kube-router
    • OpenVSwitch
    • OVN (Open Virtual Networking)
    • Weavenet

Service

  • Service is an abstract way in k8s to expose application running on a set of Pods as a network service
  • Now lets assume we have created replication controller with 2 replicas to run our application server Preview
  • Pods in k8s are mortal i.e they are born and they might die. Since pods is mortal, we use controllers.
  • These controllers when the pod dies they create new pods which means new pod ip address
  • Now lets assume we have webserver pods which needs to communicate with appserver Preview
  • Which pods ipaddress should be used in webserver?
  • Giving any pods ip adress can lead to disaster, so we need one ipadress/dns name which will forward the traffic to suitable pod and this ipadress is fixed
    Preview
  • This is where k8s service comes to the rescue.
  • How will k8s service know which pods to forward the traffic?
  • K8s allows Labels to be created on the pods and service will forward the traffic to the pods where labels are matching Preview
  • Overview of demo application with service and controllers Preview

Sample with Services and rc

  • Create a file called as nginx-rc.yaml with the following
---
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx-rc
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: mynginx
          image: nginx:1.14
  • Now apply kubectl commands Preview
  • How to publish service. To do this we have field called as Type with following possibilities
    • ClusterIp: Default value. Exposes the service on cluster-internal ip address
    • NodePort: Exposes the Service on each nodes static port. A clusterIP Service, to which NodePort Service routes is automatically created. You can access the application on any node on the nodeport
    • LoadBalancer: Exposes the service externallys using a cloud providers loadbalancer
    • ExternalName: Maps the service to the conents of the external name by returning a CNAME record
  • Lets create service with type NodePort
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    app: nginx
  type: NodePort
  ports:
    - port: 80
      targetPort: 80
      nodePort: 32000 
  
  • Now execute the following commands Preview Preview Preview

Service Discovery

  • How will k8s services will be discovered for pods.
  • K8s provides 2 primary modes for finding Services
    1. environmental varaibles
    2. DNS
  • For experimentation lets create a alpine POD
---
---
apiVersion: v1
kind: Pod
metadata:
  name: jenkins-pod
spec:
  containers:
    - name: jenkins
      image: jenkins
  • execute
kubectl apply -f jenkins-pod.yaml
kubectl exec -it jenkins-pod -- /bin/bash
set

Preview

  • When a new service is created k8s add the following environmental variables in all the contaiers (inside pods)
{svc-name}_SERVICE_HOST
{svc-name}_SERVICE_PORT
  • DNS:
    • when a service is created, names are resolved by directly using service names. If you use namespace in k8s then use <svc-name>.<namespace>
    • curl <svcname> in jenkins pod about nginx service Preview

Next Steps

  1. How to manage storage (persistent)
  2. Namespaces, annotations
  3. Controllers => Deployment
  4. Azure Kubernetes Services
  5. Elastic Kubernetes Services
  6. Helm
  7. Open shift
  8. How to hook k8s to external monitroing systems

Leave a Reply

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

About learningthoughtsadmin