Kubernetes

Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications. —kubernetes.io

Architecture

Masters

Also know as control plane.

A Kubernetes master is a collection of system services that make up the control plane of the cluster. The simplest setups run all the master services on a single host. However, this is only suitable for labs and test environments. For production environments, multi-master high availability (HA) is a must have.

  • Sweet spot is between 3 or 5 masters, increasing this further would make reaching consensus impossible.
  • Don't run user applications on masters. This allows masters to concentrate only on managing the cluster.

Components

kube-apiserver
  • Front-end to the control plane, even the other components of the master node have to pass through the API server.
  • Exposes a REST API that consumes JSON and YAML.
etcd
  • The cluster's store.
  • Persists the cluster state and configuration.
  • Based on etcd.
controller-manager
  • Behaves like a controller of controllers:
    • Node controler.
    • Deployment controller.
    • Endpoint/EndpointSlicer controller.
  • Implements watch loops in the subcontrolers, to check if their observed state is matching the desired state.
scheduler
  • Default scheduler for kubernetes, watches the kuber-apiserver for new work tasks.
  • Assigns work to cluster nodes:
    • Affinity/Anti-Affinity.
    • Constraints.
    • Traits.
    • Resources.

Nodes

Components

kubelet
  • Main kubernetes agent, it runs in every node in the cluster
  • Registers node with cluster
  • Watches the API Server for work tasks and reports back to masters
  • Executes pods
Container Runtime
  • Performs container-related tasks, like:
    • Pulling images
    • Start/Stop containers
  • Can be one of the following pluggable Container Runtime Interface (CRI):
    • Docker
    • containerd
    • CRI-O
    • Kata
kube-proxy
  • Networking component, ensures every pod gets it's own unique IP
  • Basic loag-balacing

Packaging Apps for Kubernetes

For an application to run on a Kubernetes cluster it needs to tick a few boxes. These include:

  1. Packaged as a container
  2. Wrapped in a Pod
  3. Deployed via a declarative manifest file

Pods

At the highest-level, a Pod is a ring-fenced environment to run containers. The Pod itself doesn’t actually run anything, it’s just a sandbox for hosting containers. Keeping it high level, you ring-fence an area of the host OS, build a network stack, create a bunch of kernel namespaces, and run one or more containers in it. That’s a Pod.

  • Kubernetes atomic unit of deployment
  • A wrapper around containers, that add the following properties which a cluster's life easier:
    • Annotations
    • Labels
    • Policies
    • Resources
    • Co-scheduling
    • …
  • Each pod has it's own IP

Deployment

  • A deployment is a higher-level Kubernetes object that wraps around a particular Pod and adds features such as scaling, zero-downtime updates, and versioned rollbacks.
ReplicaSet

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pod, by implementing the following:

  • Self-healing mechanisms
  • Ensure the requested number of pods is running at any given time
  • Provide fault-tolerance
  • Can be used to scale Pods
YAML Structure
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deploy
  labels:
    app: web
spec:
  selector:
    matchLabels:
      app: web
  replicas: 5
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 1
  template:
    metadata:
      labels:
        app: web
    spec: 
      terminationGracePeriodSeconds: 1
      containers:
      - name: <container-name>
        image: <registry-image>
        imagePullPolicy: Always
        ports:
        - containerPort: 8080

Service

  • An abstract way to expose an application running on a set of Pods as a network service
  • Implements a front-end that consists of:
    • A stable DNS name
    • Permanent IP address and port, not connected to the pod lifecycle
  • The backend layer has the following tasks:
    • Load-balancing across different pods
    • Only sends traffic to a healthy pod
  • Can do session affinity
  • Can send traffic to endpoits outside the cluster
  • Can do TCP and UDP
  • Handles both external access (via the internet) or internally through the cluster

Services use labels and a label selector to know which set of Pods to load-balance traffic to. The Service has a label selector that is a list of all the labels a Pod must possess in order for it to receive traffic from the Service.

Types
  • Loadbalancer: External access via cloud load-balancer
  • NotePort: External access via nodes
apiVersion: v1
kind: Service
metadata:
  name: example-nodeport
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 8080
    nodePort: 31111
    protocol: TCP
  selector:
    app: web
  • ClusterIP (default): Internal cluster connectivity
  • ExternalName
  apiVersion: v1
  kind: Service
  metadata:
    name: example-en
  spec:
    type: ExternalName
    externalName: <service-name>.<namespace>.svc.cluster.local

Pods

YAML structure
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  labels:
    app: web
spec:
  containers:
    - name: web-ctr
      image: <image-from-registry>
      ports:
        - containerPort: 8080

References:

Backlinks: