Kubernetes Architecture – Master, apiserver {}, Nodes, Pods, Services, Deployments – the basics

A Kubernetes architecture comprises masterand worker nodes.

Master (a.k.a control plane)

  • keep free of user workloads
  • apiserver {} – front-end to the control plane and should be the only component we should speak to (i.e. we send the Manifest files to this)
  • Cluster Store – persistent storage (i.e. the memory) – currently uses etcd (an OpenSource Key-Value store) as the source of truth for the cluster. Only stateful part.
  • kube-controller-manager – Controller of controllers – node, endpoints, namespace controllers – watch for changes and help maintain desired state
  • kube-scheduler – watches apiserver for new pods and assigns work to nodes

Multi-master soon.

apiserver {}

  • Aka master cos we only speak to it rather than the other components
  • port 443
  • kubectl sends commands in JSON to it
  • It then talks to the other components and commands get sent out to nodes

Node (a.k.a “Minions”)

Kubernetes Workers

  • Kubelet
    • main Kubernetes agent on the node
    • registers node with cluster
    • watches apiserver
    • instantiates pods
    • reports back to master
    • exposes endpoint on :10255 (lets you inspect your node – e.g. /spec, /healthz, /pods)
  • Container Engine
    • Container management
      • pulling images
      • starting / stopping containers
    • Pluggable
      • usually Docker
      • can be rkt
  • kube-proxy
    • Kubernetes networking
      • Pod IP addresses
        • All containers in a pod share a single IP
      • Load balances across all pods in a service

Desired State and the Declarative Model

  • declare to apiserver{} using Manifest file (which describes desired state)

Pods

  • Containers always run inside of pods
  • Pods can have multiple containers
  • All containers in the pod share pod environment – e.g. volumes, IP address, IPC namespace – e.g. web server (main) and log scraper (sidecar)
  • Scaling – unit of scaling is a Pod. i.e. you don’t add containers to a Pod, you add Pods (each with a container)
  • Pods are Atomic – Pod is never declared up and available until it’s completely up
  • Deployed via Manifest file or Replication Controller (superceded a bit now by Deployments)

Services

Every new pod gets a new IP => IP churn

Service object (declared using a Manifest) – sits between backend and frontend and load balances using IP and DNS.

Pod belongs to a Service via a Label.

Label ties Pod to Service.

Deployments

  • Self documenting
  • Versioned
  • Spec-once deploy-many
  • Simple rolling updates and rollbacks
  • REST objects
  • Deployed via YAML or JSON manifests
  • Deployed via the apiserver
  • Add features to Replication Controllers (Replica Sets – next generation Replication Controllers – i.e. RC v2)

Multiple concurrent versions:

  • Blue-green deployments
  • Canary releases
  • Simple versioned rollbacks

 

Leave a Reply

Your email address will not be published. Required fields are marked *