General info

• standardisation of deployment of applications
• deploy declarativly
• processes run on same hardware/os but on isolated processes
• os for the cluster or your deployment platform
• container is a single isolated process running on OS
  • how?
    • linux namespaces
    • linux control groups

kubernetes does:

• leader election
• service discovery
• horizontal scaling
• load balancing
• self-healing

architecture

• master node(s)
  • host Kubernetes control plane
  • controls and manages kube system
• worker node(s)
  • runs the actual application

    
  graph LR

  client -- pushes manifest to --> conp
  api -. talks to .-> kubelet

  subgraph conp[master / control plane]

      api[API service]
      etcd[ETCD]
      scheduler
      cont[controller manager
 --> creates the objects]

      api --> etcd
      scheduler --> api
      cont --> api

  end
  subgraph worker[worker nodes]
      kubelet
      kubep[kube-proxy]
      contr[container-runtime]
  end

    
  graph LR
  api[API server]
  scheduler
  contrm[controller manager]
  etcd

  subgraph apigraph
      api --- apid[communicates with you and other control planes]
  end

  subgraph schedulergraph
      scheduler --- schedulerd[schedules your app]
  end

  subgraph controllergraph
      contrm --- contrmd[perform cluster-level functions /n e.g. keeping track of worker nodes]
  end

  subgraph etcdgraph
      etcd --- etcdd[data store - stores cluster config]
  end

  apigraph ~~~ schedulergraph ~~~ controllergraph ~~~ etcdgraph

• docker (RKT) container runtime
  • which runs your containers
• kubelet
  • talks to API server and manages container on its node
• kubernetes service proxy (kube-proxy)
  • load balancing. Does network-config

    
  graph LR

  info{push info}
  api[api server]
  controller
  scheduler
  kubelet
  contr[container runtime]
  kubep[kube proxy]

  info --> apigraph
  apigraph --> controllergraph
  controllergraph --> schedulergraph
  schedulergraph --> kubeletgraph
  kubeletgraph -- instructs --> contrgraph
  contrgraph ~~~ kubep

  subgraph master[master node]
      subgraph apigraph[ ]
          api --- apid[writes to etcd]
      end

      subgraph controllergraph[ ]
          controller --- controllerd[creates the object]
      end

      subgraph schedulergraph[ ]
          scheduler --- schedulerd[schedules work on the worker nodes]
      end
  end

  subgraph worker[worker node]
      subgraph kubeletgraph[ ]
          kubelet
      end

      subgraph contrgraph[ ]
          contr --- contrd[pulls required container]
      end
      subgraph kubepgraph[ ]
          kubep --- kubepd[readies load balancer]
      end
  end

pods

• group of one or more tightly related containers, that will always run together.
  • on same worker node, same linux namespace
  • is a seperate logical machine
    • own IP, hostname, processes

    
  graph LR
  subgraph wn1[worker node 1]
      subgraph pod1[pod 1 . IP A]
          ca[container A]
      end
      subgraph pod2[pod 2 . IP B]
          cb[container B]
          cd[container D]
      end
      subgraph pod3[pod 3 . IP C]
          cc[container C]
      end
  end

scheduling

• assigning a pod to a node

service object

A method for exposing a network application that is running as one or more Pods in your cluster.

source: https://kubernetes.io/docs/concepts/services-networking/service/

serivce object - types

• clusterIp
  • default service object
  • only accessible from inside the cluster
• load balancer
  • will create external load balancer
  • not supported out-of-the-box! You cluster needs to support this

    
  graph LR

  deployment[deployment - 
 manages replicas] --> pa[Pod A]
  deployment --> pb[Pod B]
  deployment --> pc[Pod C]

  pa[pods - 
 number of instances of your application runs in] --> service
  pb --> service
  pc --> service

  service[service - 
exposes your application] --> ce[common entry]

event objects

    
  graph TB

  con[controller] -- manages --> obj[object]
  con -- creates --> eo[event objects]

  eo -.-> con
  eo -.-> obj
  

pods

• containers share the same interfaces and portspace
• 2 containers can’t bind to the same port
• containers can communicate via loopback device

= seperate computer

• should not use mutiple containers in the same pod, unless you have a good reason, e.g.:
  • communication happens between OS busses (not enabled by default)
  • it’s a sidecart container
  • reverse proxy for HTTPS or a log agent

pods - phases

pods - conditions

• Pod scheduled - pod has node
• initialized - all init containers are completed
• containers ready - containers are ready
• ready - ready for service

pods - container status

pods - container status - Restart policy

per restart takes longer because kube has exponential backoff.

• always
• onFailure
• never

all objects

manifests

kube manifests consists of following:

• type metadata: info about type of object
• object metadata: basic info, name, …
• spec: desired state of object
• status: current actual state. Will only be visible when getting the manifest via the API.

apiVersion: v1
kind: Pod
metadata:
    name: nginx
    spec:
    containers:
        - name: nginx
        image: nginx:latest

troubleshooting connectivity issues

k get pods <id> -owide (to get IP address)
minikube ssh (one off pod with curl command)
k port-forward <id> <port:port> (has a lot of layers between you and the pod)

init containers

• don’t run in parallel
  • run sequentially and previous needs to succeed before next can be started
  • should be idempotent