Kubernetes (CKA / CKAD) cheat sheet

Here is my personal cheat sheet about Kubernetes for the CKA and CKAD certification
Saturday, October 7, 2023

I could pass the CKA first time with these notes 😊

Note 1:

  • “If you see ”🟢”, it signifies advice relevant to the Certified Kubernetes Administrator (CKA) exam.”
  • “If you see ”🟠”, it indicates a topic not covered in the CKA exam, but you can quickly glance at it for additional information.”

Note 2:

  • 🟢 When preparing for the CKA exam, it’s advisable to utilize the alias k="kubectl" command. This alias not only shortens your commands but is also conveniently preconfigured for you during the exam. So, make sure to take advantage of it! 😊
  • I’ll be incorporating this alias throughout this cheatsheet for your reference.

Note 3:

  • 🟢 During the Certified Kubernetes Administrator (CKA) exam, personal notes are not permitted; however, you do have access to the official documentation at https://k8s.io. Consequently, in this cheat sheet, I will provide numerous references from the documentation.

K8S Architecture

  • Manager
    • API Server: This component is responsible for managing and controlling the entire cluster. It serves as the entry point for administrators, users, and external components to interact with Kubernetes.
    • Scheduler: The Scheduler is responsible for efficiently distributing containers across worker nodes within the cluster. It calculates where each pod should run based on resource requirements and constraints.
    • Controller Manager: The Controller Manager monitors the state of nodes, pods, and other resources in the cluster. It ensures that the desired state is maintained and takes corrective actions if necessary.
    • ETCD: ETCD is a key/value database that serves as the brain of the cluster. It stores all configuration data, ensuring consistency and high availability for the entire Kubernetes system.
  • Worker
    • Container runtime (like containerd or Docker): These software components are responsible for running containers on worker nodes. They manage the execution and lifecycle of containers.
    • Kubelet: The Kubelet is the Kubernetes agent running on each worker node. It ensures that containers are running as expected by interacting with the container runtime. Kubelet also communicates with the Kubernetes control plane to receive pod specifications and ensure their correct execution.
    • KubeProxy: KubeProxy operates on each worker node and plays a crucial role in forwarding network traffic to the appropriate pods based on their IP addresses and port numbers. It enables essential functionalities such as load balancing, service discovery, and network routing within the Kubernetes cluster.

Kubernetes Concepts

  1. Node: A server in the Kubernetes cluster, which can be a physical machine or a virtual instance.

  2. Deployment: Used to manage the deployment of applications. For example, you can create a deployment like this: kubectl create deploy nginx-deploy --image=nginx. Deployments are handy for rolling updates and ensuring that the desired number of replicas are running.

  3. ReplicaSet: A controller used to maintain a specified number of replicas of pods running in the cluster. It ensures the desired pod count is maintained even in the case of failures.

  4. Pod: The smallest and simplest unit in Kubernetes, representing one or more containers. You can create a pod like this: kubectl run [name] --image=nginx. Pods are the lowest level of abstraction in Kubernetes.

  5. Service: A Kubernetes abstraction that provides a stable network identity and connectivity to one or more pods. Services come in different types:

    • NodePort: Exposes the service on a static port on each node, making it accessible externally. It’s useful for scenarios where you need to access services from outside the cluster.

      • port: The service port that external clients use.
      • targetPort: The port on which the container inside the pod is listening.
      • nodePort: A port on the node that acts as a bridge to the service.
    • ClusterIP: Exposes the service with an internal cluster IP, typically used for inter-service communication within the cluster.

      • port: The service port for communication within the cluster.
    • Ingress: Manages external access to services within the cluster, often used for routing traffic based on domain names. It serves as a powerful way to expose services to external users and is particularly useful for HTTP and HTTPS routing.

  6. Secret: A Kubernetes resource for storing sensitive information such as API keys, passwords, and tokens. Secrets are encoded and can be used by pods securely.

  7. ConfigMap: A Kubernetes resource for storing configuration data separately from application code. ConfigMaps allow you to decouple configuration settings from your application code, making it easier to manage and update configuration across different environments.

File structure

  1. Headers and Metadata: This section includes the following key information:
    • API Version
    • Kind
    • Name
    • Namespace Location
    • Labels
  2. Spec: The content of this section varies depending on the “Kind” of resource. Refer to the relevant Kubernetes documentation for details on the specific resource you are working with.
  3. Status: This section is automatically generated by Kubernetes and is used to calculate the difference between the previous and current states of the resource.

This is a small example:

pod-example.yaml
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: my_super_nginx_pod
name: my_super_nginx_pod
spec:
containers:
- image: nginx
name: my_super_nginx_pod
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}

Basic kubectl commands

Terminal window
# Demo with "deploy / deployment" object
k create deploy nginx-depl --image=nginx --replicas=3
k create deploy nginx-depl --image=nginx --replicas=3 --dry-run=client -o yaml > depl.yaml
# 🟢 "--dry-run=client -o yaml" is very useful for CKA to avoid searching in the documentation how to create object
k get deploy nginx-depl
k edit deploy nginx-depl
k describe deploy nginx-depl
k delete deploy nginx-deploy
k run super-nginx --image=nginx
k exec -ti super-nginx -- bash
k get all
k get api-resources -o name
k get events
# Count stuff:
k get role --no-headers | wc -l
# Manipulate containers
docker ps
#
crictl ps
crictl rm
crictl inspect <container_id> | grep runtime
k apply -f <file>.yaml
k apply -f <file>.yaml --force --grace-period=0 # 🟢 Useful for CKA to avoid to wait some seconds
kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' # Complex queries
k get pod -o wide # (get IP address of Pod)
k get pod -n kube-system
k get pod -A # (= all namespaces)
k get pod --watch
k get pod --sort-by="..."
k get pod --show-labels
k top node
k top pod
k top pod --containers=true
#
k scale deployment nginx --replicas=3
# or
k edit deployment nginx # 🟢 I prefer using this method for the CKA. Type "/replica" in VIM, and press "CTRL+A" or "CTRL+X"
k explain replicaset
k describe
k create deploy --help
#
k config view
k config use-context
k config current-context

You can see the exhaustive cheatsheet on the documentation : https://kubernetes.io/docs/reference/kubectl/cheatsheet/

🟢 Note : most of the objects have a shortcut:

Terminal window
k get services
k get svc

These two commands are the same.


Now, let’s see all the useful documentation references for the CKA exam:

Scheduling

Logs & Monitoring

  • Logs & Monitoring
    • Metric server ; Prometheus ; Elastic stack
    • k top node
    • k top pod
    • k logs -f <pod_name> <container_name>

Application Lifecycle Management

command:
- sh
- -c
- "wget ..."

Cluster Maintenance

Here is an example for CKA :

Terminal window
# 1) Upgrade controlplane
kubectl drain controlplane --ignore-daemonsets
apt update
apt-get install kubeadm=1.27.0-00
kubeadm upgrade plan v1.27.0
kubeadm upgrade apply v1.27.0
apt-get install kubelet=1.27.0-00
systemctl daemon-reload
systemctl restart kubelet
kubectl uncordon controlplane
# 2) Remove the taint of the controlplane
kubectl describe node controlplane | grep -i taint
kubectl taint node controlplane node-role.kubernetes.io/control-plane:NoSchedule-
kubectl describe node controlplane | grep -i taint
#3) Upgrade Node
ssh node
kubectl drain node01 --ignore-daemonsets
apt update
apt-get install kubeadm=1.27.0-00
kubeadm upgrade node
apt-get install kubelet=1.27.0-00
systemctl daemon-reload
systemctl restart kubelet
exit
kubectl uncordon node01
kubectl get pods -o wide | grep super_pod # (make sure this is scheduled on a node)

Security

Storage

Networking

./netscript.sh

Terminal window
# Create veth pair
ip link add ...
# Attach veth pair
ip link set ...
ip link set ...
# Assign IP Address
ip -n <namespace> addr add ...
ip -n <namespace> route add ...

Loading graph...

IP Table would be (Network - Gateway) :

  • 10.224.1.0/24 - 192.168.1.11
  • 10.224.2.0/24 - 192.168.1.12
  • 10.224.3.0/24 - 192.168.1.13

Kubelet :

  • --cni-config-dir=/etc/cni/net.d
  • --cni-bin-dir=/etc/cni/bin => ./net-script.sh add <container> <namespace>

In ./net-script.sh, we should add switch case:

Terminal window
ADD)
...
DEL)
ip link del ...
  • That’s why we have to use a CNI plugin

    • Example installation :
      • kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml
      • It will deploy an agent WeaveWorks on each node with a DaemonSet
    • CIDR = Range of IP address
      • /etc/kubernetes/manifests/api-server.yaml -> // Search for range (controlplane)
  • Service networking

    • ClusterIP = IP accessible only INSIDE the cluster
    • NodePort = IP accessible INSIDE and OUTSIDE

🟢 Please use k expose pod|deploy <pod|deploymentName> --name=<serviceName> --type=<serviceType>. AVOID to use k create svc [...].

Manage cluster

  • Choosing the infrastructure

    • OpenShift
    • Cloud Foundry Container Runtime
    • VMware Cloud PKS
    • Vagrant
  • High Availability

    • Multiple masters (active / stand by)
    • ETCD
      • Stacked Topology or External Topology
      • RAFT Algorithm
        • Always use a ODD number of manager server !
        • Majority = Quorum = (n/2)+1
          • Manager=1 - so Majority=1 - so Fault Tolerance=0
          • Manager=2 - so Majority=2 - so Fault Tolerance=0
          • Manager=3 - so Majority=2 - so Fault Tolerance=1
          • Manager=4 - so Majority=3 - so Fault Tolerance=1
          • Manager=5 - so Majority=3 - so Fault Tolerance=2
          • Manager=6 - so Majority=4 - so Fault Tolerance=2
          • Manager=7 - so Majority=4 - so Fault Tolerance=3
        • Fault Tolerance add 1 every odd number of managers
  • Troubleshooting

    • Check about K8S components: k get pod -n kube-system
      • k describe pod <podName>
      • k logs <podName>
    • Check about Nodes: k get nodes
      • ssh <failed_node>
      • systemctl status kubelet
      • systemctl start kubelet
      • systemctl status kubelet
      • journalctl -u kubelet -f
      • whereis kubelet
      • ls /var/lib/kubelet
      • ls /etc/systemd/system/
      • k get events
      • tail -1000 /var/log/messages
      • journalctl -xe
    • Check about services, if everything is well configured, if labels match…

If replicas=3 doesn’t work, then the failure must be on Scheduler or Controller manager


Even this cheat sheet is very personnal, I hope it proves valuable in helping 😊

🍀🍀🤞🏻🤞🏻 Hard work and Good luck ! 🤞🏻🤞🏻🍀🍀


Recommended articles