CKA Exam Notes Series Part 1: Pods

I recently took the Certified Kubernetes Administrator exam. To successfully pass this advanced, hands on, CLI-based exam you will need to spend a considerable amount of time studying, labbing, and working with Kubernetes constructs in order to successfully demonstrate your skills and achieve a passing score.

In the next few posts I will share the notes I created during my studies.

The Lifecycle of a Pod

Method 1: Create a Pod Using the kubectl run Command

kubectl run nginx-pod --image=nginx

Method 2: Generate YAML from an Existing Pod

1. Export the YAML for the Created Pod:

kubectl get pod nginx-pod -o yaml > nginx-pod.yaml

2. Update the Pod Name in the YAML File:

apiVersion: v1

kind: Pod

metadata:

  name: nginx-new

spec:

  containers:

    - name: nginx

      image: nginx

3. Create the New Pod Using the Modified YAML:

kubectl apply -f nginx-pod.yaml

YAML Concepts:

YAML heavily relies on indentation to define hierarchical structures. Misaligned indents lead to parsing errors, so consistency is crucial.

Key-Value Pairs: Data in YAML is structured as key-value pairs, where each key is a property of the Kubernetes resource.

Example : —

apiVersion: v1  # Kubernetes API version

kind: Pod       # Type of Kubernetes resource

metadata:

  name: my-pod  # Name of the Pod

Lists: Lists are represented with a dash (-) and are typically used for collections, like a list of containers in a Pod.

Example: —

containers:

  - name: nginx-container

    image: nginx

  - name: busybox-container

    image: busybox

Comments: Comments in YAML are denoted by #, helping to clarify configurations.

Example : —

# Define a Pod in Kubernetes

apiVersion: v1       # API version for Kubernetes resources

kind: Pod            # Specifies that this is a Pod

metadata:

  name: my-pod       # The name of the Pod

Static Pods, Manual Scheduling, Labels, and Selectors

Static pods are pods created and managed by kubelet daemon on a specific node without the API server observing them. If the static pod crashes, kubelet restarts it.

The control plane is not involved in the lifecycle of a static pod. Kubelet also tries to create a mirror pod on the kubernetes api server for each static pod so that the static pods are visible.

i.e. when you do kubectl get pod for example, the mirror object of the static pod is also listed.

You rarely have to deal with static pods. Static pods are usually used by software bootstrapping Kubernetes itself.

The kubeadm uses static pods to bring up Kubernetes control plane components like API-server, and controller-manager as static pods.

kubelet can watch a directory on the host file system (configured using --pod-manifest-path the argument to kubelet) (or) sync pod manifests from a web URL periodically (configured using --manifest-urlargument to kubelet).

When kubeadm is bringing up Kubernetes control plane, it generates pod manifests for API-server, and controller-manager in a directory that kubelet is monitoring. Then kubelet brings up these control plane components as static pods.

Kubernetes scheduling is simply the process of assigning pods to the matched nodes in a cluster. A scheduler watches for newly created pods and finds the best node for their assignment.

Manual scheduling means running a pod on a particular node by manually mentioning the nodeName field in the pod YAML configuration file.

Here are some common reasons you may want to schedule pods manually:

1. You want pods with high resource requirements to run on larger nodes.

2. You want to spread pods across nodes for high availability.

3. You want pods to run on nodes with special hardware like GPUs.

4. You want a pod locality with services already running on a node.

   
   

Methods Used for Kubernetes Pod Scheduling

1. Node Selector

2. Node Affinity/Anti-Affinity

3. Taints and Tolerations

4. Taints/Tolerations and Node Affinity

NodeSelector is the simplest recommendation for scheduling a pod on a specific node.

Node Selector is a field of PodSpec. It specifies a map of key-value pairs. For the pod to be eligible to run on that specific node, the node should have each of the indicated key-value pair labels as used for the pod.

Node Affinity/Anti-Affinity is a method to fix rules on which nodes are selected by the scheduler. This feature is a generalization of the node selector.

The rules are defined using the familiar concepts of custom labels on nodes and selectors laid out in pods, and they are often either required (or) preferred, depending on how strictly you want the scheduler to enforce them.

Taints are applied to nodes in a Kubernetes cluster to repel pods from being scheduled on those nodes, except for pods that explicitly tolerate the taint. Taints are typically used to mark nodes with specific attributes (or) limitations, such as reserving certain nodes for particular workloads (or) preventing pods from being placed on nodes with specific hardware characteristics.

Tolerations are applied to pods and indicate that the pod can be scheduled on nodes with specific taints. A pod with toleration will only be scheduled on nodes that have a matching taint.

By setting tolerations, you can make sure that certain pods are placed on nodes with specific attributes or restrictions, even if those nodes are tainted.

Node affinity allows pods to specify rules about which nodes they can run on, based on node labels.

There are two types of node affinity:

1. Required

2. Preferred.

   
   

Required node affinity, pods can only be placed on nodes matching certain rules.

Preferred node affinity, scheduling tries to match the rules but is not obligated.

Selectors are more efficient since they are pre-computed expressions. They are evaluated on the target node where a pod is scheduled. It can be evaluated on any node in the cluster.

Labels have to be dynamically updated each time the label value changes. They are evaluated on the kube controller which means that all pods are evaluated against the label even if they don’t have that label. It can only be evaluated against pods on the same node as the kube controller.

Schedule a pod manually - No Scheduler

apiVersion: v1

kind: Pod

metadata:

    name: nginx-manual

spec:

    containers:

        - name: nginx

          image: nginx:latest

    nodeName: cka-cluster-worker2

Schedule a pod using Node Selector

Example 1:

apiVersion: v1

kind: Pod

metadata:

  name: nginx-kusc00101

  namespace: engineering

  labels:

    env: test

spec:

  containers:

  - name: nginx

    image: nginx

  imagePullPolicy: IfNotPresent

  nodeSelector:

    disk: ssd

Example 2:

apiVersion: v1

kind: Pod

metadata:

  labels:

    run: pod1

  name: pod1

spec:

  containers:

  - image: httpd:2.4.41-alpine

    name: pod1-container # change

  dnsPolicy: ClusterFirst

  restartPolicy: Always

  tolerations: # add

  - effect: NoSchedule # add

    key: node-role.kubernetes.io/control-plane # add

  nodeSelector: # add

    node-role.kubernetes.io/control-plane: "" # add