Kubernetes

:ID: dd924a84-7d6f-41ec-98c2-aa16582c0d89

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

Architecture

Masters

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.

kube-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.

kube-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:

Packaged as a container
Wrapped in a Pod
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