Misc

Config File

MEMORY Limits

If the actual MEMORY usage of the container at run time exceeds the limit... The CONTAINER will be killed Pod will remain, the container will therefore attempt th restart.

CPU Limits

If the actual CPU usage of the container at run time exceeds the limit… The CPU will be "clamped” While the container will continue to run.

---
apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"  # 1G  = 1000M, 1Gi = 1024M
        cpu: "500m"      # 500/1000 of a core (50%) or just "0.5"
  - name: log-aggregator
    image: images.my-company.example/log-aggregator:v6
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Commands to check metrics
Note: Enabling the Metrics Server

$ k top pod
NAME   CPU(cores)   MEMORY(bytes)   
po     0m           17Mi            

$ k top node
NAME       CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
minikube   239m         3%     991Mi           6%

HPA Horizontal Pod Autoscaling

• This is done using Metrics Server

Readiness and Liveness Probes in Kubernetes

Readiness Probe

yamlCopy code
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  containers:
  - name: myapp-container
    image: myapp-image
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 10
      periodSeconds: 5

Liveness Probe

yamlCopy code
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp-image
        ports:
        - containerPort: 8080
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 10

Quality of Service (QoS) for Pods in Kubernetes

QoS class of Guaranteed

1. Every Container in the Pod must have a memory limit and a memory request.

2. For every Container in the Pod, the memory limit must equal the memory request.

3. Every Container in the Pod must have a CPU limit and a CPU request.

4. For every Container in the Pod, the CPU limit must equal the CPU request.

QoS class of Burstable

1. The Pod does not meet the criteria for QoS class Guaranteed.

2. At least one Container in the Pod has a memory or CPU request or limit.

QoS class of BestEffort

StateFulSets

Treating your Pods as "Pets" Sometimes you need a set of pods with known, predictable names ...and you wants clients to be able to call them, by their name.

StateFulSets is just SatateFulName

1. In a StatefulSet, the pods will have a predictable name: 0, 1, 2.

2. The pods will always start up in sequence.

3. Clients can address them by name.

Example:

Jobs and CronJobs

• Run to Completion — It runs the Job in parallel by creating one or more pods for the successful completion

apiVersion: batch/v1
kind: Job
metadata:
  name: test-job
spec:
  template:
    spec: # Pod
      containers:
      - name: long-job
        image: python:rc-slim
        command: ["python"]
        args: ["-c", "import time; print('starting'); time.sleep(30); print('done')"]
      restartPolicy: Never
  backoffLimit: 2  #Retry limit

• Schedulers (CronJob) — It’s like scheduling tasks in crontab in Linux.

Cron Tab Syntax

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of the week (0 - 7) (Sunday = 0 or 7)
│ │ │ │ │ ┌───────────── command to be executed
│ │ │ │ │ │
│ │ │ │ │ │
* * * * * command

Here are some common examples:

- `* * * * *`: Runs the command every minute.
- `0 * * * *`: Runs the command at the start of every hour.
- `0 0 * * *`: Runs the command once a day at midnight.
- `0 0 * * 1`: Runs the command once a week on Monday at midnight.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: cron-job
spec: # CronJob
  schedule: "* * * * *"
  jobTemplate:
    spec: # JOB
      template:
        spec: # Pod
          containers:
          - name: long-job
            image: python:rc-slim
            command: ["python"]
            args: ["-c", "import time; print('starting'); time.sleep(30); print('done')"]
          restartPolicy: Never
      backoffLimit: 2

DaemonSet

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: webapp
spec:
  selector:
    matchLabels:
      app: webapp
  # replicas: 1
  template: # template for the pods
    metadata:
      labels:
        app: webapp
    spec:
      containers:
      - name: webapp
        image: richardchesterwood/k8s-fleetman-webapp-angular:release2
        env:
        - name: SPRING_PROFILES_ACTIVE
          value: production-microservice

Kubernetes Documentation

Key Concepts:

1. Containerization:
• Kubernetes is built around the concept of containers, which are lightweight, portable, and consistent environments for running applications and their dependencies.

2. Nodes:
• A Kubernetes cluster consists of nodes. Nodes can be physical or virtual machines and are divided into two types: master nodes and worker nodes.

3. Master Node (Control Plane):
• The master node is responsible for managing the overall state of the cluster.
• Components on the master node include the API server, etcd, controller manager, and scheduler.

4. Worker Node:
• Worker nodes, or minions, host the containers that run the actual applications.
• Each worker node has the Kubelet, Kube Proxy, and a container runtime (e.g., Docker) installed.

5. Pod:
• The smallest deployable unit in Kubernetes.
• A pod represents a single instance of a running process in a cluster and encapsulates one or more containers.

• KubeCTL autocomplete: Configure autocompletion to kubectl with zsh (github.com)