Kubernetes Cheat Sheet

Kubernetes Cheat Sheet#

Key Concepts#

  • Pod = Container + Layer to abstract the underlying container technology. Each pod has its own ip address

  • Service provides a static IP address to a pod and acts as load balancer for replicated pods

  • All pod have a service. Lifetime of pod and service is not related

  • Ingress is an “external service” which routes requests to services

  • ConfigMap stores external configuration of the application, e.g. DB_URL

  • Secret like ConfigMap, base64 encoded

  • Volume attaches a physical storage to a pod

  • Deployment contains a blueprint (template section) for a pod. You can specify the number of replicas of a pod.

  • Deployment Spec → Replicaset → Pod Spec

  • StatefulSet is the deployment equivalent for stateful applications (e.g., databases). It ensures that database reads and writes are synchronized to avoid data inconsistencies

  • Worker node consists of 3 processes

    • Container runtime

    • Kubelet handles the pods

    • Kube Proxy forwards the processes

  • Control Plane node consists of 4 processes

    • ApiServer is a cluster gateway and a gatekeeper to the cluster

    • Scheduler determines where to place the pods (Scheduler -> asks Kubelet to schedule)

    • Controller Manager detects state changes like pod crashes

    • Etcd is a key value store. It is the cluster brain, provides information for the scheduler about the availability of resources

kubectl#

kubectl create deployment nginx-depl --image=nginx
kubectl edit deployment >deployment<
kubectl logs >pod<
kubectl exec -it >pod< — /bin/bash
kubectl apply/delete -f >file<
kubectl get pod -o wide
kubectl create namespace my-namespace

Deployment#

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb-deployment
  labels:
    app: mongodb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      containers:
        - name: mongodb
          image: mongo
          ports:
            - containerPort: 27017
          env:
            - name: MONGO_INITDB_ROOT_USERNAME
              valueFrom:
                secretKeyRef:
                  name: mongodb-secret
                  key: mongo-root-username
            - name: MONGO_INITDB_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mongodb-secret
                  key: mongo-root-password
--- # separates yaml files
apiVersion: v1
kind: Service
metadata:
  name: mongodb-service
spec:
  selector:
    app: mongodb
  ports:
    - protocol: TCP
      port: 27017       # exposed service port for all pods
      targetPort: 27017 # matches containerPort
---
apiVersion: v1
kind: Secret
metadata:
    name: mongodb-secret
type: Opaque
data:
    mongo-root-username: dXNlcm5hbWU= # echo -n 'username' | base64
    mongo-root-password: cGFzc3dvcmQ= # echo -n 'password' | base64

Each config has three parts:

  1. Metadata

  2. Specification

  3. An automatically generated status that compares the desired and actual state (self-healing feature provided by etcd)

The service’s selector (app: nginx) and the deployment’s label (app: nginx) define which pods are registered to the service.

Ingress & External Services#

  • The service’s targetPort must match the pod’s containerPort.

  • A LoadBalancer is an external service that opens up nodePort.

  • A LoadBalancer is only used without Ingress, as Ingress has rules to map an external URL to an internal service.

  • An Ingress Controller must be installed in the cluster separately.

  • This requires a proxy server with a public IP address to redirect requests to the Ingress Controller.

  • For minikube:

minikube addons enable ingress
minikube service mongo-express-service

Namespaces#

  • Namespaces are virtual clusters within a cluster.

  • Standard Namespaces:

    • kube-system: processes kubectl commands

    • kube-public: contains public information, kubectl cluster-info

    • kube-node-lease: tracks node heartbeats

    • default

Grouping#

  • Logical grouping: Database Namespace, Monitoring Namespace, Nginx Ingress

  • Staging and Development Grouping

  • Blue/Green Deployment, if they use the same resources:

    • Production Blue (active)

    • Production Green (standby)

  • One Namespace per team

Limitations#

  • ConfigMaps and Secrets cannot be shared between namespaces.

  • Volumes and nodes cannot be namespaced.

  • kubens/kubectx allows selecting the default namespace in the shell.

Helm Chart#

  • Package Manager for Kubernetes

  • ArtifactHub: Can bundle a complete tech stack

  • values.yaml contains configuration values

  • chart.yaml contains metadata

  • charts/ folder contains chart dependencies

  • templates/ contains the actual charts

Storage#

Requirements#

  1. Storage should not depend on the pod lifecycle.

  2. Storage must be accessible from all nodes.

  3. Storage must persist even if the cluster crashes.

Persistent Volumes#

  • Persistent Volumes (PV) are a cluster resource similar to memory; they must exist before pods are created.

  • Local storage violates requirements 2 and 3. For database persistence, it is best to use remote storage.

  • Applications do not directly use PVs but must claim them using Persistent Volume Claims (PVCs).

  • PVs are not namespaced.

  • PVCs are namespaced.

  • Storage Classes create persistent volumes in the background using a provisioner.

  • Storage Classes are referenced by PVCs.

StatefulSet#

  • Replicas maintain a unique identity for each pod.

    • Pods are named (StatefulSetName)-(ordinal), with the master being 0.

    • Pods have fixed DNS names.

  • Pods are created from the same specification but are not interchangeable.

  • Only the master pod is allowed to write to the database; other pods can only read.

  • Pods need to synchronize data continuously.

  • Due to the unique identity, remote storage should be used.