CKA on Deep Blue

CKA Learning path 22

Sun, 03 Oct 2021 23:05:47 +0800

Certified Kubernetes Administrator (CKA) Practice Exam: Part 1

Introduction

This lab provides practice scenarios to help prepare you for the Certified Kubernetes Administrator (CKA) exam. You will be presented with tasks to complete as well as server(s) and/or an existing Kubernetes cluster to complete them in. You will need to use your knowledge of Kubernetes to successfully complete the provided tasks, much like you would on the real CKA exam. Good luck!

Solution

ssh cloud_user@

Count the Number of Nodes That Are Ready to Run Normal Workloads

Switch to the appropriate context with kubectl:
```
kubectl config use-context acgk8s
```
Count the number of nodes ready to run a normal workload:
```
kubectl get nodes
```
Check that the worker nodes can run normal workloads:
```
kubectl describe node  acgk8s-worker1
```
Scroll to the top of the output and check the list of taints. You should see none.
Repeat the steps above for acgk8s-worker2. You should see no taints on that node either.
Save this number to the file /k8s/0001/count.txt:
```
echo 2 > /k8s/0001/count.txt
```

Retrieve Error Messages from a Container Log

Obtain error messages from a container’s log:
```
kubectl logs -n backend data-handler -c proc
```

Return only the error messages:

kubectl logs -n backend data-handler -c proc | grep ERROR

Save this output to the file /k8s/0002/errors.txt:

kubectl logs -n backend data-handler -c proc | grep ERROR > /k8s/0002/errors.txt

Find the Pod That Is Utilizing the Most CPU within a Namespace

Locate which Pod in the web namespace with the label app=auth is using the most CPU (In some cases, other pods may show as consuming more cpu):
```
kubectl top pod -n web --sort-by cpu --selector app=auth
```
Save the name of this Pod to /k8s/0003/cpu-pod.txt:
```
echo auth-web > /k8s/0003/cpu-pod.txt
```

Certified Kubernetes Administrator (CKA) Practice Exam: Part 2

Introduction

Solution

ssh cloud_user@

Edit the `web-frontend` Deployment to Expose the HTTP Port

Switch to the appropriate context with kubectl:
```
kubectl config use-context acgk8s
```
Edit the web-frontend deployment in the web namespace:
```
kubectl edit deployment -n web web-frontend
```

Change the Pod template to expose port 80 on our NGINX containers:

spec:
  containers:
  - image: nginx:1.14.2
    ports:
    - containerPort: 80

Press Esc and enter :wq to save and exit.

Create a Service to Expose the `web-frontend` Deployment’s Pods Externally

Open a web-frontend service file:
```
vi web-frontend-svc.yml
```

Define the service in the YAML document:

apiVersion: v1
kind: Service
metadata:
  name: web-frontend-svc
  namespace: web
spec:
  type: NodePort
  selector:
    app: web-frontend
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
    nodePort: 30080

Press Esc and enter :wq to save and exit.
Create the service:
```
kubectl create -f web-frontend-svc.yml
```

Scale Up the Web Frontend Deployment

Scale up the deployment:

kubectl scale deployment web-frontend -n web --replicas=5

Create an Ingress That Maps to the New Service

Create a web-frontend-ingress file:
```
vi web-frontend-ingress.yml
```

Define an Ingress in the YAML document:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-frontend-ingress
  namespace: web
spec:
  rules:
  - http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: web-frontend-svc
            port:
              number: 80

Press Esc and enter :wq to save and exit.

Create the Ingress:

kubectl create -f web-frontend-ingress.yml

Certified Kubernetes Administrator (CKA) - Practice Exam Part 3

Introduction

Solution

ssh cloud_user@

Create a Service Account

Switch to the appropriate context with kubectl:
```
kubectl config use-context acgk8s
```
Create a service account:
```
kubectl create sa webautomation -n web
```

Create a ClusterRole That Provides Read Access to Pods

Create a pod-reader.yml file:
```
vi pod-reader.yml
```

Define the ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Press Esc and enter:wq to save and exit.
Creat the ClusterRole:
```
kubectl create -f pod-reader.yml
```

Bind the ClusterRole to the Service Account to Only Read Pods in the `web` Namespace

Create the rb-pod-reader.yml file:
```
vi rb-pod-reader.yml
```

Define the RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: rb-pod-reader
  namespace: web
subjects:
- kind: ServiceAccount
  name: webautomation
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Press Esc and enter:wq to save and exit.
Create the RoleBinding:
```
kubectl create -f rb-pod-reader.yml
```

Verify the RoleBinding works:

kubectl get pods -n web --as=system:serviceaccount:web:webautomation

Certified Kubernetes Administrator (CKA) - Practice Exam Part 4

Introduction

Solution

ssh cloud_user@

Back Up the etcd Data

From the terminal, log in to the etcd server:
```
ssh etcd1
```

Back up the etcd data:

ETCDCTL_API=3 etcdctl snapshot save /home/cloud_user/etcd_backup.db \
--endpoints=https://etcd1:2379 \
--cacert=/home/cloud_user/etcd-certs/etcd-ca.pem \
--cert=/home/cloud_user/etcd-certs/etcd-server.crt \
--key=/home/cloud_user/etcd-certs/etcd-server.key

Restore the etcd Data from the Backup

Stop etcd:
```
sudo systemctl stop etcd
```
Delete the existing etcd data:
```
sudo rm -rf /var/lib/etcd
```

Restore etcd data from a backup:

sudo ETCDCTL_API=3 etcdctl snapshot restore /home/cloud_user/etcd_backup.db \
--initial-cluster etcd-restore=https://etcd1:2380 \
--initial-advertise-peer-urls https://etcd1:2380 \
--name etcd-restore \
--data-dir /var/lib/etcd

Set database ownership:
```
sudo chown -R etcd:etcd /var/lib/etcd
```
Start etcd:
```
sudo systemctl start etcd
```

Verify the system is working:

ETCDCTL_API=3 etcdctl get cluster.name \
--endpoints=https://etcd1:2379 \
--cacert=/home/cloud_user/etcd-certs/etcd-ca.pem \
--cert=/home/cloud_user/etcd-certs/etcd-server.crt \
--key=/home/cloud_user/etcd-certs/etcd-server.key

CKA Practice Exam - Part 5

Introduction

Solution

ssh cloud_user@

Upgrade All Kubernetes Components on the Control Plane Node

Switch to the appropriate context with kubectl:
```
kubectl config use-context acgk8s
```

Upgrade kubeadm:

sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubeadm=1.21.1-00

Drain the control plane node:

kubectl drain acgk8s-control --ignore-daemonsets

Check whether the components are upgradeable to v1.21.1:
```
sudo kubeadm upgrade plan v1.21.1
```
Apply the upgrade:
```
sudo kubeadm upgrade apply v1.21.1
```

Upgrade kubelet and kubectl:

sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubelet=1.21.1-00 kubectl=1.21.1-00

Reload:
```
sudo systemctl daemon-reload
```
Restart kubelet:
```
sudo systemctl restart kubelet
```
Uncordon the control plane node:
```
kubectl uncordon acgk8s-control
```

Upgrade All Kubernetes Components on the Worker Node

Drain the worker1 node:

kubectl drain acgk8s-worker1 --ignore-daemonsets --force

SSH into the node:
```
ssh acgk8s-worker1
```

Install a new version of kubeadm:

sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubeadm=1.21.1-00

Upgrade the node:
```
sudo kubeadm upgrade node
```

Upgrade kubelet and kubectl:

sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubelet=1.21.1-00 kubectl=1.21.1-00

Reload:
```
sudo systemctl daemon-reload
```
Restart kubelet:
```
sudo systemctl restart kubelet
```
Type exit to exit the node.
Uncordon the node:
```
kubectl uncordon acgk8s-worker1
```
Repeat the process above for acgk8s-worker2 to upgrade the other worker node.

Certified Kubernetes Administrator (CKA): Practice Exam: Part 6

Introduction

This lab provides practice scenarios to help prepare you for the Certified Kubernetes Administrator (CKA) Exam. You will be presented with tasks to complete, as well as server(s) and/or an existing Kubernetes cluster to complete them in. You will need to use your knowledge of Kubernetes to successfully complete the provided tasks, much like you would on the real CKA exam. Good luck!

Solution

ssh cloud_user@

Drain the `Worker1` Node

Switch to the acgk8s
```
kubectl config use-context acgk8s
```
Attempt to drain the

worker1

kubectl drain acgk8s-worker1


3. Does the node drain successfully?

4. Override the errors and drain the node:

kubectl drain acgk8s-worker1 –delete-local-data –ignore-daemonsets –force


5. Check the status of the exam objectives:

./verify.sh


### Create a Pod That Will Only Be Scheduled on Nodes with a Specific Label

1. Add the

disk=fast


label to the

worker2


node:

kubectl label nodes acgk8s-worker2 disk=fast


2. Create a YAML file named

fast-nginx.yml

vim fast-nginx.yml


3. In the file, paste the following:

apiVersion: v1 kind: Pod metadata: name: fast-nginx namespace: dev spec: nodeSelector: disk: fast containers: - name: nginx image: nginx


4. Save the file:

ESC :wq


5. Create the

fast-nginx


pod:

kubectl create -f fast-nginx.yml


6. Check the status of the pod:

kubectl get pod fast-nginx -n dev -o wide


7. Check the status of the exam objectives:

./verify.sh


# Certified Kubernetes Administrator (CKA): Practice Exam: Part 7

## Introduction

This lab provides practice scenarios to help prepare you for the Certified Kubernetes Administrator (CKA) Exam. You will be presented with tasks to complete, as well as server(s) and/or an existing Kubernetes cluster to complete them in. You will need to use your knowledge of Kubernetes to successfully complete the provided tasks, much like you would on the real CKA exam. Good luck!

## Solution

Log in to the server using the credentials provided:

ssh cloud_user@


> **Note:** *When copying and pasting code into Vim from the lab guide, first enter `:set paste` (and then `i` to enter insert mode) to avoid adding unnecessary spaces and hashes. To save and quit the file, press **Escape** followed by `:wq`. To exit the file* without *saving, press **Escape** followed by `:q!`.*

### Create a PersistentVolume

1. Switch to the

acgk8s


context:

kubectl config use-context acgk8s


2. Create a YAML file named

localdisk.yml

vim localdisk.yml


3. In the file, paste the following:

apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: localdisk provisioner: kubernetes.io/no-provisioner allowVolumeExpansion: true


4. Save the file:

ESC :wq


5. Create a storage class using the YAML file:

kubectl create -f localdisk.yml


6. Create a YAML file named

host-storage-pv.yml

vim host-storage-pv.yml


7. In the file, paste the following:

apiVersion: v1 kind: PersistentVolume metadata: name: host-storage-pv spec: storageClassName: localdisk persistentVolumeReclaimPolicy: Recycle capacity: storage: 1Gi accessModes: - ReadWriteOnce hostPath: path: /etc/data


8. Save the file:

ESC :wq


9. Create the PersistentVolume:

kubectl create -f host-storage-pv.yml


10. Check the status of the volume:

 ```
 kubectl get pv host-storage-pv
 ```

11. Check the status of the exam objectives:

 ```
 ./verify.sh
 ```

### Create a Pod That Uses the PersistentVolume for Storage

1. Create a YAML file named

host-storage-pvc.yml

vim host-storage-pvc.yml


2. In the file, paste the following:

apiVersion: v1 kind: PersistentVolumeClaim metadata: name: host-storage-pvc namespace: auth spec: storageClassName: localdisk accessModes: - ReadWriteOnce resources: requests: storage: 100Mi


3. Save the file:

ESC :wq


4. Create the PersistentVolumeClaim:

kubectl create -f host-storage-pvc.yml


5. Check the status of the PersistentVolumeClaim:

kubectl get pv


6. Verify that the claim is bound to the volume:

kubectl get pvc -n auth


7. Create a YAML file named

pv-pod.yml

vim pv-pod.yml


8. In the file, paste the following:

apiVersion: v1 kind: Pod metadata: name: pv-pod namespace: auth spec: containers: - name: busybox image: busybox command: [‘sh’, ‘-c’, ‘while true; do echo success > /output/output.log; sleep 5; done’] volumeMounts: - name: pv-storage mountPath: /output volumes: - name: pv-storage persistentVolumeClaim: claimName: host-storage-pvc


9. Save the file:

ESC :wq


10. Create the pod:

 ```
 kubectl create -f pv-pod.yml
 ```

11. Check the status of the exam objectives:

 ```
 ./verify.sh
 ```

### Expand the PersistentVolumeClaim

1. Edit

host-storage-pvc

kubectl edit pvc host-storage-pvc -n auth


2. Under `spec`, change the `storage` value to **200Mi**.

3. Save the file:

ESC :wq


4. Check the status of the exam objectives:

./verify.sh


# Certified Kubernetes Administrator (CKA): Practice Exam: Part 8

## Introduction

This lab provides practice scenarios to help prepare you for the Certified Kubernetes Administrator (CKA) Exam. You will be presented with tasks to complete, as well as server(s) and/or an existing Kubernetes cluster to complete them in. You will need to use your knowledge of Kubernetes to successfully complete the provided tasks, much like you would on the real CKA exam. Good luck!

## Solution

Log in to the server using the credentials provided:

ssh cloud_user@


### Create a Networkpolicy That Denies All Access to the Maintenance Pod

1. Switch to the

acgk8s


context:

kubectl config use-context acgk8s


2. Check the

foo


namespace:

kubectl get pods -n foo


3. Check the

maintenance


pod's labels:

kubectl describe pod maintenance -n foo


4. Create a new YAML file named

np-maintenance.yml

vim np-maintenance.yml


5. In the file, paste the following:

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: np-maintenance namespace: foo spec: podSelector: matchLabels: app: maintenance policyTypes: - Ingress - Egress


6. Save the file:

ESC :wq


7. Create the

NetworkPolicy

kubectl create -f np-maintenance.yml


8. Check the status of the exam objectives:

./verify.sh


### Create a Networkpolicy That Allows All Pods in the `users-backend` Namespace to Communicate with Each Other Only on a Specific Port

1. Label the

users-backend


namespace:

kubectl label namespace users-backend app=users-backend


2. Create a YAML file named

np-users-backend-80.yml

vim np-users-backend-80.yml


3. In the file, paste the following:

apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: np-users-backend-80 namespace: users-backend spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: app: users-backend ports: - protocol: TCP port: 80


4. Save the file:

ESC :wq


5. Create the NetworkPolicy:

kubectl create -f np-users-backend-80.yml


6. Check the status of the exam objectives:

./verify.sh


# Certified Kubernetes Administrator (CKA): Practice Exam: Part 7

## Introduction

This lab provides practice scenarios to help prepare you for the Certified Kubernetes Administrator (CKA) Exam. You will be presented with tasks to complete, as well as server(s) and/or an existing Kubernetes cluster to complete them in. You will need to use your knowledge of Kubernetes, to successfully complete the provided tasks, much like you would on the real CKA exam. Good luck!

## Solution

Log in to the server using the credentials provided:

ssh cloud_user@


### Create a Multi-Container Pod

1. Switch to the

acgk8s


context:

kubectl config use-context acgk8s


2. Create a YAML file named

multi.yml

apiVersion: v1 kind: Pod metadata: name: multi namespace: baz spec: containers: - name: nginx image: nginx - name: redis image: redis


3. Save the file:

ESC :wq


4. Create the multi-container pod:

kubectl create -f multi.yml


5. Check the status of the pod:

kubectl get pods -n baz


6. Check the status of the exam objectives:

./verify.sh


### Create a Pod Which Uses a Sidecar to Expose the Main Container's Log File to Stdout

1. Create a YAML file named logging-sidecar.yml:

vim logging-sidecar.yml


2. In the file, paste the following:

apiVersion: v1 kind: Pod metadata: name: logging-sidecar namespace: baz spec: containers: - name: busybox1 image: busybox command: [‘sh’, ‘-c’, ‘while true; do echo Logging data > /output/output.log; sleep 5; done’] volumeMounts: - name: sharedvol mountPath: /output - name: sidecar image: busybox command: [‘sh’, ‘-c’, ’tail -f /input/output.log’] volumeMounts: - name: sharedvol mountPath: /input volumes: - name: sharedvol emptyDir: {}


3. Save the file:

ESC :wq


4. Create the

logging-sidecar


pod:

kubectl create -f logging-sidecar.yml


5. Check the status of the pod:

kubectl get pods -n baz


6. Check the

logging-sidecar


logs:

kubectl logs logging-sidecar -n baz -c sidecar


7. Check the status of the exam objectives:

./verify.sh


# Certified Kubernetes Administrator (CKA): Practice Exam: Part 10

## Introduction

This lab provides practice scenarios to help prepare you for the Certified Kubernetes Administrator (CKA) Exam. You will be presented with tasks to complete, as well as server(s) and/or an existing Kubernetes cluster to complete them in. You will need to use your knowledge of Kubernetes, to successfully complete the provided tasks, much like you would on the real CKA exam. Good luck!

## Solution

Log in to the server using the credentials provided:

ssh cloud_user@


### Determine What Is Wrong with the Broken Node

1. Switch to the

acgk8s


context:

kubectl config use-context acgk8s


2. Check the current status of the nodes:

kubectl get nodes


3. Identify the broken node and save the name to a file named

broken-node.txt

echo acgk8s-worker2 > /k8s/0004/broken-node.txt


4. Attempt to determine the cause of the issue:

kubectl describe node acgk8s-worker2


### Fix the Problem

1. Access the node using

ssh acgk8s-worker2


2. Check the

kubelet


log:

sudo journalctl -u kubelet


3. Check the last entry in the log.

4. Check the

kubelet


status:

sudo systemctl status kubelet


5. Enable

kubelet

sudo systemctl enable kubelet


6. Start

kubelet

sudo systemctl start kubelet


7. Verify that

kubelet


started successfully:

sudo systemctl status kubelet


8. Return to the control plane node:

exit


9. Check the status of the nodes:

kubectl get nodes


10. Check the status of the exam objectives:

 ```
 ./verify.sh
 ```

CKA Learning path 21

Sun, 03 Oct 2021 17:39:47 +0800

Troubleshooting a Broken Kubernetes Cluster

Introduction

Every Kubernetes administrator will likely need to deal with a broken cluster at some point, whether a single node or the entire cluster is down. In this lab, you will be able to practice your troubleshooting skills. You will be presented with a broken Kubernetes cluster and asked to use your investigative skills to identify the problem and fix it.

Solution

ssh cloud_user@

Determine What is Wrong with the Cluster

Find out which node is having a problem by using kubectl get nodes. Identify if a node is in the NotReady state.
Get more information on the node by using kubectl describe node .
Look for the Conditions section of the Node Information and find out what is affecting the node’s status, causing it to fail.
Log in to the worker 2 node server using the credentials provided:
```
ssh cloud_user@
```
Look at the kubelet logs of the worker 2 node by using sudo journalctl -u kubelet.
Go to the end of the log by pressing Shift + G and see the error messages stating that kubelet has stopped.
Look at the status of the kubelet status by using sudo systemctl status kubelet, and note whether the kubelet service is running or not.

Fix the Problem

In order to fix the problem, we need to not only start the server but also enable kubelet to ensure that it continues to work if the server restarts in the future. Use clear to clear the service status, and then start and enable kubelet by using sudo systemctl enable kubelet, followed by sudo systemctl start kubelet.
Check if kubelet is active by using sudo systemctl status kubelet, and note if the service is listed as active (running).
Return to the control plane node.
Check if all nodes are now in a Ready status by using kubectl get nodes. You may have to wait and try the command a few times before all nodes appear as Ready.

Troubleshooting a Broken Kubernetes Application

Introduction

Kubernetes administrators need to be able to fix issues with applications running in a cluster. This lab will allow you to test your skills when it comes to fixing broken Kubernetes applications. You will be presented with a cluster running a broken application and asked to identify and correct the problem.

Solution

Identify What is Wrong with the Application

Examine the web-consumer deployment, which resides in the web namespace, and its Pods by using kubectl get deployment -n web web-consumer.
Get more information by using kubectl describe deployment -n web web-consumer, including container specifications and labels that the Pods are using.
Look more closely at the Pods by using kubectl get pods -n web to see if both Pods are up and running.
Get more information about the Pods by using kubectl describe pod -n web , and evaluate any warning messages that may come up.
Look at the logs associated with the container busybox by using kubectl logs -n web -c busybox.
Determine what may be going wrong by reading the output from the container logs.
Take a closer look at the pod itself by using kubectl get pod -n web -o yaml to get the data in the yaml format.
Determine which command is causing the errors (in this case, the while true; do curl auth-db; sleep 5; done command).

Fix the Problem

Take a closer look at the service by using kubectl get svc -n web auth-db.
Locate where the service is by using kubectl get namespaces and finding the one other non-default namespace called data.
Check kubectl get svc -n data and find the auth-db service in this namespace, rather than the web namespace.
Start resolving the issue by using kubectl edit deployment -n web web-consumer.
In the spec section, scroll down to find the pod template and locate the while true; do curl auth-db; sleep 5; done command.
Change the command to while true; do curl auth-db.data.svc.cluster.local; sleep 5; done to give the fully qualified domain name of that service. This will allow the web-consumer deployment’s Pods to communicate with the service successfully.
Save the file and exit by pressing the ESC key and using :wq.
Check kubectl get pods -n web to ensure that the old pods have terminated and the new pods are running successfully.
Check the log of one of the new pods by using kubectl logs -n web -c busybox. This time the pod should be able to communicate successfully with the service.

CKA Learning path 20

Sun, 03 Oct 2021 16:56:47 +0800

Using PersistentVolumes in Kubernetes

Introduction

PersistentVolumes provide a way to treat storage as a dynamic resource in Kubernetes. This lab will allow you to demonstrate your knowledge of PersistentVolumes. You will mount some persistent storage to a container using a PersistentVolume and a PersistentVolumeClaim.

Solution

ssh cloud_user@

Create a PersistentVolume That Allows Claim Expansion

Create a custom Storage Class by using ```vi localdisk.yml`.

Define the Storage Class by using:

apiVersion: storage.k8s.io/v1 
kind: StorageClass 
metadata: 
  name: localdisk 
provisioner: kubernetes.io/no-provisioner
allowVolumeExpansion: true

Save and exit the file by hitting the ESC key and using :wq.
Finish creating the Storage Class by using kubectl create -f localdisk.yml.
Create the PersistentVolume by using vi host-pv.yml.

Define the PersistentVolume with a size of 1Gi by using:

kind: PersistentVolume 
apiVersion: v1 
metadata: 
   name: host-pv 
spec: 
   storageClassName: localdisk
   persistentVolumeReclaimPolicy: Recycle 
   capacity: 
      storage: 1Gi 
   accessModes: 
      - ReadWriteOnce 
   hostPath: 
      path: /var/output

Save and exit the file by hitting the ESC key and using :wq.
Finish creating the PersistentVolume by using kubectl create -f host-pv.yml.
Check the status of the PersistenVolume by using kubectl get pv.

Create a PersistentVolumeClaim

Start creating a PersistentVolumeClaim for the PersistentVolume to bind to by using vi host-pvc.yml.

Define the PersistentVolumeClaim with a size of 100Mi by using:

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
   name: host-pvc 
spec: 
   storageClassName: localdisk 
   accessModes: 
      - ReadWriteOnce 
   resources: 
      requests: 
         storage: 100Mi

Save and exit the file by hitting the ESC key and using :wq.
Finish creating the PersistentVolumeClaim by using kubectl create -f host-pvc.yml.
Check the status of the PersistentVolume and PersistentVolumeClaim to verify that they have been bound:
```
kubectl get pv
kubectl get pvc
```

Create a Pod That Uses a PersistentVolume for Storage

Create a Pod that uses the PersistentVolumeClaim by using vi pv-pod.yml.

Define the Pod by using:

apiVersion: v1 
kind: Pod 
metadata: 
   name: pv-pod 
spec: 
   containers: 
      - name: busybox 
        image: busybox 
        command: ['sh', '-c', 'while true; do echo Success! > /output/success.txt; sleep 5; done']

Mount the PersistentVolume to the /output location by adding the following, which should be level with the containers spec in terms of indentation:
```
volumes: 
 - name: pv-storage 
   persistentVolumeClaim: 
      claimName: host-pvc
```
In the containers spec, below the command, set the list of volume mounts by using:
```
volumeMounts: 
- name: pv-storage 
  mountPath: /output 
```
Save and exit the file by hitting the ESC key and using :wq.
Finish creating the Pod by using kubectl create -f pv-pod.yml.
Check that the Pod is up and running by using kubectl get pods.
If you wish, you can log in to the worker node and verify the output data by using cat /var/output/success.txt.

CKA Learning path 19

Sun, 03 Oct 2021 16:51:47 +0800

Managing Container Storage with Kubernetes Volumes

Introduction

Kubernetes volumes offer a simple way to mount external storage to containers. This lab will test your knowledge of volumes as you provide storage to some containers according to a provided specification. This will allow you to practice what you know about using Kubernetes volumes.

Solution

ssh cloud_user@

Create a Pod That Outputs Data to the Host Using a Volume

Create a Pod that will interact with the host file system by using vi maintenance-pod.yml.

Enter in the first part of the basic YAML for a simple busybox Pod that outputs some data every 5 seconds to the host’s disk:

apiVersion: v1
kind: Pod
metadata:
    name: maintenance-pod
spec:
    containers:
    - name: busybox
      image: busybox
      command: ['sh', '-c', 'while true; do echo Success! >> /output/output.txt; sleep 5; done']

Under the basic YAML, begin creating volumes, which should be level with the containers spec:
```
volumes:
- name: output-vol
  hostPath:
      path: /var/data
```
In the containers spec of the basic YAML, add a line for volume mounts:
```
volumeMounts:
- name: output-vol
  mountPath: /output
```
Save the file and exit by pressing the ESC key and using :wq.
Finish creating the Pod by using kubectl create -f maintenance-pod.yml.
Make sure the Pod is up and running by using kubectl get pods and check that maintenance-pod is running, so it should be outputting data to the host system.
Log into the worker node server using the credentials provided:
```
ssh cloud_user@
```
Look at the output by using cat /var/data/output.txt to see whether the Pod setup was successful.

Create a Multi-Container Pod That Shares Data Between Containers Using a Volume

Return to the control plane server.
Create another YAML file for a shared-data multi-container Pod by using vi shared-data-pod.yml.

Start with the basic Pod definition and add multiple containers, where the first container will write the output.txt file and the second container will read the output.txt file:

apiVersion: v1
kind: Pod
metadata:
    name: shared-data-pod
spec:
    containers:
    - name: busybox1
      image: busybox
      command: ['sh', '-c', 'while true; do echo Success! >> /output/output.txt; sleep 5; done']
    - name: busybox2
      image: busybox
      command: ['sh', '-c', 'while true; do cat /input/output.txt; sleep 5; done']

Set up the volumes, again at the same level as containers with an emptyDir volume that only exists to share data between two containers in a simple way:
```
volumes:
- name: shared-vol
  emptyDir: {}
```
Mount that volume between the two containers by adding the following lines under command for the busybox1 container:
```
volumeMounts:
- name: shared-vol
  mountPath: /output
```
For the busybox2 container, add the following lines to mount the same volume under command to complete creating the shared file:
```
volumeMounts:
- name: shared-vol
  mountPath: /input
```
Save the file and exit by pressing the ESC key and using :wq.
Finish creating the multi-container Pod using kubectl create -f shared-data-pod.yml.
Make sure the Pod is up and running by using kubectl get pods and check if both containers are running and ready.
To make sure the Pod is working, check the logs for shared-data-pod.yml and specify the second container that is reading the data and printing it to the console, using kubectl logs shared-data-pod -c busybox2.
If you see the series of “Success!” messages, you have successfully created both containers, one of which is using a host path volume to write some data to the host disk and the other of which is using an emptyDir volume to share a volume between two containers in the same Pod.

CKA Learning path 18

Wed, 29 Sep 2021 22:37:47 +0800

Using Kubernetes Ingress

Introduction

Kubernetes Ingress allows you to customize how external entities can interact with your Kubernetes applications via the network. This lab will allow you to exercise your knowledge of Kubernetes Ingress. You will use Ingress to open access from an existing service to an external server.

Solution

ssh cloud_user@

Create a Service to Expose the web-auth Deployment

Check out the deployment:
```
kubectl get deployment web-auth -o yaml
```
Note the web-auth label on our Pods. We’ll use this label to select these Pods using our Service.
Create a web-auth-svc.yml file:
```
vi web-auth-svc.yml
```

Paste the following YAML definitions:

Note: To paste YAML directly into the Vi/Vim editor, first enter the command :set paste.

apiVersion: v1
kind: Service
metadata:
  name: web-auth-svc
spec:
  type: ClusterIP
  selector:
    app: web-auth
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 80

Press Esc and enter :wq to save and exit.
Create the Service:
```
kubectl create -f web-auth-svc.yml
```

Create an Ingress That Maps to the New Service

Create a web-auth-ingress.yml file:
```
vi web-auth-ingress.yml
```

Add the following YAML definitions:

Note: To paste YAML directly into the Vi/Vim editor, first enter the command :set paste.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-auth-ingress
spec:
  rules:
  - http:
      paths:
      - path: /auth
        pathType: Prefix
        backend:
          service:
            name: web-auth-svc
            port:
              number: 80

Press Esc and enter :wq to save and exit.
Create the Ingress:
```
kubectl create -f web-auth-ingress.yml
```
Check the status of the Ingress:
```
kubectl describe ingress web-auth-ingress
```
Note the service endpoints in the Backends section of the output. You have successfully created an Ingress that maps to the backend Service.

CKA Learning path 17

Wed, 29 Sep 2021 21:33:47 +0800

Using Kubernetes Services with DNS

Introduction

Kubernetes Services can be located with the Kubernetes DNS just like Pods can. In this lab, you will work with the Kubernetes DNS to discover Services from within a Pod. This will test your knowledge of how to interact with Services using DNS.

Solution

ssh cloud_user@

Perform an Nslookup for a Service in the Same Namespace

Start using the busybox Pod in the web namespace to perform an nslookup on the web-frontend Service by entering:
```
kubectl exec -n web busybox -- nslookup web-frontend
```

Redirect the output to save the results in a text file by using:

kubectl exec -n web busybox -- nslookup web-frontend >> ~/dns_same_namespace_results.txt

Look up the same Service using the fully qualified domain name by entering:

kubectl exec -n web busybox -- nslookup web-frontend.web.svc.cluster.local

Redirect the output to save the results of the second nslookup in a text file by using:

kubectl exec -n web busybox -- nslookup web-frontend.web.svc.cluster.local >> ~/dns_same_namespace_results.txt

Check that everything looks okay in the text file by using:
```
cat ~/dns_same_namespace_results.txt
```
Use clear to clear the text file output.

Perform an Nslookup For a Service in a Different Namespace

Use the busybox Pod in the web namespace to perform an nslookup on the user-db Service in the data namespace, while only utilizing the short Service name, by entering:
```
kubectl exec -n web busybox -- nslookup user-db
```
This first request is supposed to result in an error message, so don’t be alarmed if you see that we can’t resolve user-db.

Save the results of this nslookup in a text file by using:

kubectl exec -n web busybox -- nslookup user-db >> ~/dns_different_namespace_results.txt

Perform the same lookup using the fully qualified domain name by entering:
```
kubectl exec -n web busybox -- nslookup user-db.data.svc.cluster.local
```

Save the results in a text file by using:

kubectl exec -n web busybox -- nslookup user-db.data.svc.cluster.local >> ~/dns_different_namespace_results.txt

Check the output in the text file by using:

cat ~/dns_different_namespace_results.txt

CKA Learning path 16

Wed, 29 Sep 2021 21:03:47 +0800

Exposing Kubernetes Pods Using Services

Introduction

Kubernetes Services are a great way to combine Kubernetes networking with the dynamic and often automated nature of Kubernetes applications. In this lab, you will use Services to expose existing Kubernetes Pods. This will allow you to practice your skills with Kubernetes Services.

Solution

ssh cloud_user@

Expose the Pods from the User-db Deployment as an Internal Service

Examine the properties of the user-db deployment by using kubectl get deployment user-db -o yaml.
In the deployment properties, find the spec and look for the Pod template, paying particular attention to the labels, especially the label app: user-db.
Take note of which port(s) are exposed.
Start creating a Service that will expose its Pods to other components within the cluster by using vi user-db-svc.yml.

Define the Service by using:

apiVersion: v1 
kind: Service 
metadata: 
  name: user-db-svc 
spec: 
  type: ClusterIP 
  selector: 
    app: user-db 
  ports: 
  - protocol: TCP 
    port: 80 
    targetPort: 80

Save and exit the file by hitting the ESC key and using :wq.
Finish creating the Service by using kubectl create -f user-db-svc.yml.
Test the Service to make sure it works by using kubectl exec busybox -- curl user-db-svc. It may not work right away, so you may need to wait a few minutes and try again, but you should be able to see the Nginx welcome page.

Expose the Pods from the Web-frontend Deployment as an External Service

Now, examine the properties of the frontend deployment by using kubectl get deployment web-frontend -o yaml.
Check the labels applied to the Pod template. You should see the label app=web-frontend.
Take note of which port(s) are exposed.
Start creating a Service that will expose its Pods on port 30080 of each cluster node by using vi web-frontend-svc.yml.

Define the Service by using:

apiVersion: v1 
kind: Service 
metadata: 
  name: web-frontend-svc 
spec: 
  type: NodePort 
  selector: 
    app: web-frontend 
  ports: 
  - protocol: TCP 
    port: 80 
    targetPort: 80 
    nodePort: 30080

1. Save and exit the file by hitting the ESC key and using :wq.
Finish creating the Service by using kubectl create -f web-frontend-svc.yml.
Test the Service from outside the cluster (such as in a browser) by navigating to http://:30080.

CKA Learning path 15

Wed, 29 Sep 2021 16:02:47 +0800

Exploring Kubernetes Networking

Introduction

Kubernetes networking is a deep and varied subject. In this lab, you will test your knowledge of Kubernetes networking by implementing a networking solution. You will also verify two pods can communicate with one another via your virtual container network.

Solution

ssh cloud_user@

Fix the Issue Causing Pods Not to Start Up

List the pods to check their status:
```
kubectl get pods
```
Check the node status:
```
kubectl get nodes
```
It looks like the nodes are NotReady.
Describe a node to see if you can get more info:
```
kubectl describe node k8s-worker1
```
It looks like kube-proxy, a component that handles networking-related tasks, is stuck starting up.
Check the status of the networking plugin pods:
```
kubectl get pods -n kube-system
```
The networking pods seem to be missing. Most likely, a networking plugin was never installed.

Install the Calico networking plugin:

kubectl apply -f https://docs.projectcalico.org/v3.14/manifests/calico.yaml

Check the status of the Nodes and Pods again:
```
kubectl get nodes
```
They should both be Ready after about a minute.
```
kubectl get pods
```

Verify You Can Communicate between Pods Using the Cluster Network

Verify the two pods can communicate over the network:
```
kubectl get pods -o wide
```
Run curl on the IP address of the cyberdyne-frontend Pod (which will be listed in the output from the previous command):
```
kubectl exec testclient -- curl 
```
The result should be HTML of an Nginx page, meaning the Pods are able to communicate.

CKA Learning path 14

Wed, 29 Sep 2021 15:32:47 +0800

Managing Kubernetes Applications with Deployments

Introduction

Deployments offer a wide range of features for automating application management. In this lab, you will put your knowledge of deployments to the test. You will use an existing deployment to scale an application, as well as perform a rolling update.

Solution

ssh cloud_user@

Update the App to a New Version of the Code

Edit the beebox-web deployment:
```
kubectl edit deployment beebox-web
```

Locate the Pod’s container specification, and change the 1.0.1 image version tag to 1.0.2:

...

spec:
  containers:
  - image: acgorg/beebox-web:1.0.2
    imagePullPolicy: IfNotPresent
    name: web-server

...

Save and exit the file by pressing Escape followed by :wq.
Check the status of your deployment to watch the rolling update occur:
```
kubectl rollout status deployment.v1.apps/beebox-web
```

Scale the App to a Larger Number of Replicas

Scale the deployment to 5 replicas:

kubectl scale deployment.v1.apps/beebox-web --replicas=5

View the deployment to watch it scale up:
```
kubectl get deployment beebox-web
```
View the Pods:
```
kubectl get pods
```

CKA Learning path 13

Tue, 28 Sep 2021 23:05:47 +0800

Using Static Pods in Kubernetes

Introduction

Static pods are a great way to run a pod on a single node without the involvement of the Kubernetes control plane. In this lab, you will have a chance to exercise your knowledge of static pods by creating them in an existing cluster.

Create a Manifest for a Static Pod

Create a static pod manifest file:

[cloud_user@k8s-worker1]$ sudo vi /etc/kubernetes/manifests/beebox-diagnostic.yml

Add the following into the file:

apiVersion: v1
kind: Pod
metadata:
  name: beebox-diagnostic
spec:
  containers:
  - name: beebox-diagnostic
    image: acgorg/beebox-diagnostic:1
    ports:
    - containerPort: 80

Save and exit the file by pressing Escape followed by :wq.

Start Up the Static Pod

Restart kubelet to start the static pod:

[cloud_user@k8s-worker1]$ sudo systemctl restart kubelet

In a new terminal session, log in to the Control Plane Node server:
```
ssh cloud_user@
```

Check the status of your static Pod:

[cloud_user@k8s-control]]$ kubectl get pods

Attempt to delete the static Pod using the k8s API:

[cloud_user@k8s-control]]$ kubectl delete pod beebox-diagnostic-k8s-worker1

Check the status of the Pod:
```
[cloud_user@k8s-control]]$ kubectl get pods
```
We’ll see the Pod was immediately re-created, since it is only a mirror Pod created by the worker kubelet to represent the static Pod.

CKA Learning path 12

Tue, 28 Sep 2021 22:45:47 +0800

Using DaemonSets in Kubernetes

Introduction

DaemonSets are a great way to ensure a pod replica runs dynamically on each node. They even automatically handle the creation and removal of such pods when nodes join or leave the cluster. In this lab, you will have the opportunity to practice your skills with DaemonSets by using them to run pods on all nodes in an existing cluster.

Solution

ssh cloud_user@

Create a DaemonSet Specification YAML File

Create a DaemonSet descriptor:
```
vi daemonset.yml
```

Add the following to the file:

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: beebox-cleanup
spec:
  selector:
    matchLabels:
      app: beebox-cleanup
  template:
    metadata:
      labels:
        app: beebox-cleanup
    spec:
      containers:
      - name: busybox
        image: busybox:1.27
        command: ['sh', '-c', 'while true; do rm -rf /beebox-temp/*; sleep 60; done']
        volumeMounts:
        - name: beebox-tmp
          mountPath: /beebox-temp
      volumes:
      - name: beebox-tmp
        hostPath:
          path: /etc/beebox/tmp

Save and exit the file by pressing Escape followed by :wq.

Create the DaemonSet in the Cluster

Create the DaemonSet in the cluster:
```
kubectl apply -f daemonset.yml
```
Get a list of pods, and verify a DaemonSet pod is running on each worker node:
```
kubectl get pods -o wide
```

CKA Learning path 11

Tue, 28 Sep 2021 22:27:47 +0800

Assigning a Kubernetes Pod to a Specific Node

Introduction

Kubernetes scheduling usually doesn’t need much help in order to determine which node to run a pod on. However, you may occasionally wish to have a little more control. In this lab, you will be able to practice the process of ensuring a pod runs on a specific node.

Solution

ssh cloud_user@

Configure the `auth-gateway` Pod to Only Run on `k8s-worker2`

Attach a label to k8s-worker2.

kubectl label nodes k8s-worker2 external-auth-services=true

Open auth-gateway.yml:
```
vi auth-gateway.yml
```

Add a nodeSelector to the auth-gateway pod descriptor:

...

spec:
  nodeSelector:
    external-auth-services: "true"

  ...

Save and exit the file by pressing Escape followed by :wq.

Delete and re-create the pod:

kubectl delete pod auth-gateway -n beebox-auth

kubectl create -f auth-gateway.yml

Verify the pod is scheduled on the k8s-worker2 node:

kubectl get pod auth-gateway -n beebox-auth -o wide

Configure the `auth-data` Deployment’s Replica Pods to Only Run on `k8s-worker2`

Open auth-data.yml:
```
vi auth-data.yml
```

Add a nodeSelector to the pod template in the deployment spec (it will be the second spec in the file):

...

spec:

  ...

  template:

    ...

    spec:
      nodeSelector:
        external-auth-services: "true"

      ...

Save and exit the file by pressing Escape followed by :wq.
Update the deployment:
```
kubectl apply -f auth-data.yml
```
Verify the deployment’s replicas are all running on k8s-worker2:
```
kubectl get pods -n beebox-auth -o wide
```

CKA Learning path 10

Tue, 28 Sep 2021 21:09:47 +0800

Using Init Containers in Kubernetes

Introduction

Init containers are a great way to customize container startup. This lab will allow you to test your knowledge of init containers by using them to solve problems in an existing Kubernetes cluster.

Solution

ssh cloud_user@

Create a Sample Pod That Uses an Init Container to Delay Startup

Open the pod descriptor file:
```
vi pod.yml
```

Add an init container (at the same level as containers in the file) to delay startup until the shipping-svc service is available:

spec:
  ...
  initContainers:
  - name: shipping-svc-check
    image: busybox:1.27
    command: ['sh', '-c', 'until nslookup shipping-svc; do echo waiting for shipping-svc; sleep 2; done']

Save and exit the file by pressing Escape followed by :wq.
Create the pod:
```
kubectl create -f pod.yml
```
Check the status of the pod:
```
kubectl get pods
```
It should remain in the Init status.

Test Your Setup by Creating the Service and Verifying the Pod Starts Up

Create the service from the shipping-svc.yml file:
```
kubectl create -f shipping-svc.yml
```
Check the status of your pod again:
```
kubectl get pods
```
It should enter the Running status after about a minute.

CKA Learning path 9

Tue, 28 Sep 2021 17:21:47 +0800

Building Self-Healing Containers in Kubernetes

Introduction

Kubernetes offers several features that can be used together to create self-healing applications in a variety of scenarios. In this lab, you will be able to practice your skills at using features such as probes and restart policies to create a container application that is automatically healed when it stops working.

Solution

ssh cloud_user@

Set a Restart Policy to Restart the Container When It Is Down

Find the pod that needs to be modified:
```
kubectl get pods -o wide
```
Take note of the beebox-shipping-data pod’s IP address.
Use the busybox pod to make a request to the pod to see if it is working:
```
kubectl exec busybox -- curl :8080
```
We will likely get an error message.

Get the pod’s YAML descriptor:

  kubectl get pod beebox-shipping-data -o yaml > beebox-shipping-data.yml

Open the file:
```
vi beebox-shipping-data.yml
```

Set the restartPolicy to Always:

spec:
  ...
  restartPolicy: Always
  ...

Create a Liveness Probe to Detect When the Application Has Crashed

Add a liveness probe:

spec:
  containers:
  - ...
    name: shipping-data
    livenessProbe:
      httpGet:
        path: /
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5
    ...

Save and exit the file by pressing Escape followed by :wq.

Delete the pod:

kubectl delete pod beebox-shipping-data

Re-create the pod to apply the changes:

kubectl apply -f beebox-shipping-data.yml

Check the pod status
```
kubectl get pods -o wide
```
If you wait a minute or so and check again, you should see the pod is being restarted whenever the application crashes.
Check the http response from the pod again (it will have a new IP address since we re-created it):
```
kubectl exec busybox -- curl :8080
```
If you wish, you can explore and see what happens as the application crashes and the pod is restarted automatically.

CKA Learning path 8

Mon, 13 Sep 2021 22:42:47 +0800

Passing Configuration Data to a Kubernetes Container

Introduction

Kubernetes has multiple options for storing and managing configuration data. This lab will focus on the process of passing that configuration data to your containers in order to configure applications. You will have the opportunity to work with application configuration in Kubernetes hands-on by passing some existing configuration data stored in Secrets and ConfigMaps to a container.

Solution

ssh cloud_user@

Generate an `htpasswd` File and Store It as a Secret

Generate an htpasswd file:
```
htpasswd -c .htpasswd user
```
Create a password you can easily remember (we’ll need it again later).
View the file’s contents:
```
cat .htpasswd
```

Create a Secret containing the htpasswd data:

kubectl create secret generic nginx-htpasswd --from-file .htpasswd

Delete the .htpasswd file:
```
rm .htpasswd
```

Create the Nginx Pod

Create pod.yml:
```
vi pod.yml
```
Set vi to ‘paste’ mode by hitting :, and then typing set paste (ENTER). Then switch back to INSERT mode by hitting i.

Enter the following to create the pod and mount the Nginx config and htpasswd Secret data:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.19.1
    ports:
    - containerPort: 80
    volumeMounts:
    - name: config-volume
      mountPath: /etc/nginx
    - name: htpasswd-volume
      mountPath: /etc/nginx/conf
  volumes:
  - name: config-volume
    configMap:
      name: nginx-config
  - name: htpasswd-volume
    secret:
      secretName: nginx-htpasswd

Save and exit the file by pressing Escape followed by :wq.
View the existing ConfigMap:
```
kubectl get cm
```
Get more info about nginx-config:
```
kubectl describe cm nginx-config
```
Create the pod:
```
kubectl apply -f pod.yml
```
Check the status of your pod and get its IP address:
```
kubectl get pods -o wide
```
Its IP address will be listed once it has a Running status. We’ll use this in the final two commands.
Within the existing busybox pod, without using credentials, verify everything is working:
```
kubectl exec busybox -- curl 
```
We’ll see HTML for the 401 Authorization Required page — but this is a good thing, as it means our setup is working as expected.
Run the same command again using credentials (including the password you created at the beginning of the lab) to verify everything is working:
```
kubectl exec busybox -- curl -u user: 
```
This time, we’ll see the Welcome to nginx! page HTML.

CKA Learning path 7

Mon, 13 Sep 2021 21:54:47 +0800

Discovering Pod Resource Usage with Kubernetes Metrics

Introduction

Kubernetes metrics allow you to gain insight into a wide variety of data about your Kubernetes applications. You can use these metrics to gain insight into how your compute resources are being used. In this lab, you will have the opportunity to hone your skills by investigating existing pods running in a Kubernetes cluster to determine which ones are using the most CPU.

Solution

ssh cloud_user@

Install Kubernetes Metrics Server

Install Kubernetes Metrics Server:

kubectl apply -f https://raw.githubusercontent.com/linuxacademy/content-cka-resources/master/metrics-server-components.yaml

Verify Metrics Server is responsive:
```
kubectl get --raw /apis/metrics.k8s.io/
```
It may take a few minutes for Metrics Server to become responsive to requests.

Locate the CPU-Using Pod and Write Its Name to a File

In the beebox-mobile namespace, determine which pod with the label app=auth is using the most CPU:
```
kubectl top pod -n beebox-mobile --sort-by cpu --selector app=auth
```
If you get an error message saying metrics are not available, wait a few minutes and then run the command again.

Write the name of the pod to a file:

echo auth-proc > /home/cloud_user/cpu-pod-name.txt

CKA Learning path 6

Mon, 30 Aug 2021 12:34:47 +0800

Controlling Access in Kubernetes with RBAC

Introduction

Role-based access control is an important component when it comes to managing a Kubernetes cluster securely. The more users and automated processes there are that need to interface with the Kubernetes API, the more important controlling access becomes. In this lab, you will have the opportunity to practice your skills with the Kubernetes RBAC system by implementing your own RBAC permissions to appropriately limit user access.

Solution

Log in to the lab server using the credentials provided:
```
ssh cloud_user@
```
Note: When copying and pasting code into Vim from the lab guide, first enter :set paste (and then i to enter insert mode) to avoid adding unnecessary spaces and hashes.

Create a Role for the `dev` User

Test access by attempting to list pods as the dev user:
```
kubectl get pods -n beebox-mobile --kubeconfig dev-k8s-config
```
We’ll get an error message.
Create a role spec file:
```
vi pod-reader-role.yml
```

Add the following to the file:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: beebox-mobile
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "watch", "list"]

Save and exit the file by pressing Escape followed by :wq.
Create the role:
```
kubectl apply -f pod-reader-role.yml
```

Bind the Role to the `dev` User and Verify Your Setup Works

Create the RoleBinding spec file:
```
vi pod-reader-rolebinding.yml
```

Add the following to the file:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader
  namespace: beebox-mobile
subjects:
- kind: User
  name: dev
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Save and exit the file by pressing Escape followed by :wq.

Create the RoleBinding:

kubectl apply -f pod-reader-rolebinding.yml

Test access again to verify you can successfully list pods:
```
kubectl get pods -n beebox-mobile --kubeconfig dev-k8s-config
```
This time, we should see a list of pods (there’s just one).
Verify the dev user can read pod logs:
```
kubectl logs beebox-auth -n beebox-mobile --kubeconfig dev-k8s-config
```
We’ll get an Auth processing... message.
Verify the dev user cannot make changes by attempting to delete a pod:
```
kubectl delete pod beebox-auth -n beebox-mobile --kubeconfig dev-k8s-config
```
We’ll get an error, which is what we want.

CKA Learning path 5

Sat, 28 Aug 2021 21:42:47 +0800

Backing up and Restoring Kubernetes Data in etcd

Introduction

Backups are an important part of any resilient system. Kubernetes is no exception. In this lab, you will have the opportunity to practice your skills by backing up and restoring a Kubernetes cluster state stored in etcd. This will help you get comfortable with the steps involved in backing up Kubernetes data.

Solution

ssh cloud_user@

Back Up the etcd Data

Look up the value for the key cluster.name in the etcd cluster:

ETCDCTL_API=3 etcdctl get cluster.name \
  --endpoints=https://10.0.1.101:2379 \
  --cacert=/home/cloud_user/etcd-certs/etcd-ca.pem \
  --cert=/home/cloud_user/etcd-certs/etcd-server.crt \
  --key=/home/cloud_user/etcd-certs/etcd-server.key

The returned value should be beebox.

Back up etcd using etcdctl and the provided etcd certificates:

ETCDCTL_API=3 etcdctl snapshot save /home/cloud_user/etcd_backup.db \
  --endpoints=https://10.0.1.101:2379 \
  --cacert=/home/cloud_user/etcd-certs/etcd-ca.pem \
  --cert=/home/cloud_user/etcd-certs/etcd-server.crt \
  --key=/home/cloud_user/etcd-certs/etcd-server.key

Reset etcd by removing all existing etcd data:

sudo systemctl stop etcd

sudo rm -rf /var/lib/etcd

Restore the etcd Data from the Backup

Restore the etcd data from the backup (this command spins up a temporary etcd cluster, saving the data from the backup file to a new data directory in the same location where the previous data directory was):

sudo ETCDCTL_API=3 etcdctl snapshot restore /home/cloud_user/etcd_backup.db \
  --initial-cluster etcd-restore=https://10.0.1.101:2380 \
  --initial-advertise-peer-urls https://10.0.1.101:2380 \
  --name etcd-restore \
  --data-dir /var/lib/etcd

Set ownership on the new data directory:
```
sudo chown -R etcd:etcd /var/lib/etcd
```
Start etcd:
```
sudo systemctl start etcd
```

Verify the restored data is present by looking up the value for the key cluster.name again:

ETCDCTL_API=3 etcdctl get cluster.name \
  --endpoints=https://10.0.1.101:2379 \
  --cacert=/home/cloud_user/etcd-certs/etcd-ca.pem \
  --cert=/home/cloud_user/etcd-certs/etcd-server.crt \
  --key=/home/cloud_user/etcd-certs/etcd-server.key

The returned value should be beebox.

CKA Learning path 4

Thu, 05 Aug 2021 09:05:47 +0800

Performing a Kubernetes Upgrade with kubeadm

Introduction

When you are managing Kubernetes in the real world, it is essential that you are able to keep your cluster up to date. This lab will allow you to practice the process of upgrading a Kubernetes cluster to a newer Kubernetes version using kubeadm. This will ensure you are comfortable with the upgrade process and ready to manage real-world Kubernetes clusters.

Solution

ssh cloud_user@

Note: We’ll be switching between nodes throughout the lab, so be sure to check the Bash prompt for which node to run the commands on.

Upgrade the Control Plane

Upgrade kubeadm:

[cloud_user@k8s-control]$ sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubeadm=1.21.1-00

Make sure it upgraded correctly:

[cloud_user@k8s-control]$ kubeadm version

Drain the control plane node:

[cloud_user@k8s-control]$ kubectl drain k8s-control --ignore-daemonsets

Plan the upgrade:

[cloud_user@k8s-control]$ sudo kubeadm upgrade plan v1.21.1

Upgrade the control plane components:

[cloud_user@k8s-control]$ sudo kubeadm upgrade apply v1.21.1

Upgrade kubelet and kubectl on the control plane node:

[cloud_user@k8s-control]$ sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubelet=1.21.1-00 kubectl=1.21.1-00

Restart kubelet:

[cloud_user@k8s-control]$ sudo systemctl daemon-reload

[cloud_user@k8s-control]$ sudo systemctl restart kubelet

Uncordon the control plane node:

[cloud_user@k8s-control]$ kubectl uncordon k8s-control

Verify the control plane is working:
```
[cloud_user@k8s-control]$ kubectl get nodes
```
If it shows a NotReady status, run the command again after a minute or so. It should become Ready.

Upgrade the Worker Nodes

Note: In a real-world scenario, you should not perform upgrades on all worker nodes at the same time. Make sure enough nodes are available at any given time to provide uninterrupted service.

Worker Node 1

Run the following on the control plane node to drain worker node 1:
```
[cloud_user@k8s-control]$ kubectl drain k8s-worker1 --ignore-daemonsets --force
```
You may get an error message that certain pods couldn’t be deleted, which is fine.
In a new terminal window, log in to worker node 1:
```
ssh cloud_user@
```

Upgrade kubeadm on worker node 1:

[cloud_user@k8s-worker1]$ sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubeadm=1.21.1-00

[cloud_user@k8s-worker1]$ kubeadm version

Back on worker node 1, upgrade the kubelet configuration on the worker node:
```
[cloud_user@k8s-worker1]$ sudo kubeadm upgrade node
```

Upgrade kubelet and kubectl on worker node 1:

[cloud_user@k8s-worker1]$ sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubelet=1.21.1-00 kubectl=1.21.1-00

Restart kubelet:

[cloud_user@k8s-worker1]$ sudo systemctl daemon-reload

[cloud_user@k8s-worker1]$ sudo systemctl restart kubelet

From the control plane node, uncordon worker node 1:

[cloud_user@k8s-control]$ kubectl uncordon k8s-worker1

Worker Node 2

From the control plane node, drain worker node 2:

[cloud_user@k8s-control]$ kubectl drain k8s-worker2 --ignore-daemonsets --force

In a new terminal window, log in to worker node 2:
```
ssh cloud_user@
```

Upgrade kubeadm:

[cloud_user@k8s-worker2]$ sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubeadm=1.21.1-00

[cloud_user@k8s-worker2]$ kubeadm version

Back on worker node 2, perform the upgrade:

[cloud_user@k8s-worker2]$ sudo kubeadm upgrade node

[cloud_user@k8s-worker2]$ sudo apt-get update && \
sudo apt-get install -y --allow-change-held-packages kubelet=1.21.1-00 kubectl=1.21.1-00

[cloud_user@k8s-worker2]$ sudo systemctl daemon-reload

[cloud_user@k8s-worker2]$ sudo systemctl restart kubelet

From the control plane node, uncordon worker node 2:

[cloud_user@k8s-control]$ kubectl uncordon k8s-worker2

Still in the control plane node, verify the cluster is upgraded and working:
```
[cloud_user@k8s-control]$ kubectl get nodes
```
If they show a NotReady status, run the command again after a minute or so. They should become Ready.

CKA Learning path 3

Wed, 04 Aug 2021 21:47:47 +0800

Building a Kubernetes 1.21 Cluster with Kubeadm

Introduction

This lab will allow you to practice the process of building a new Kubernetes cluster. You will be given a set of Linux servers, and you will have the opportunity to turn these servers into a functioning Kubernetes cluster. This will help you build the skills necessary to create your own Kubernetes clusters in the real world.

Solution

ssh cloud_user@

Install Packages

Log into the Control Plane Node (Note: The following steps must be performed on all three nodes.).
Create configuration file for containerd:
```
cat <
```



Load modules:
sudo modprobe overlay
sudo modprobe br_netfilter


Set system configurations for Kubernetes networking:
cat <


Apply new settings:
sudo sysctl --system


Install containerd:
sudo apt-get update && sudo apt-get install -y containerd


Create default configuration file for containerd:
sudo mkdir -p /etc/containerd


Generate default containerd configuration and save to the newly created default file:
sudo containerd config default | sudo tee /etc/containerd/config.toml


Restart containerd to ensure new configuration file usage:
sudo systemctl restart containerd


Verify that containerd is running.
sudo systemctl status containerd


Disable swap:
sudo swapoff -a


Disable swap on startup in:
/etc/fstab
sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab


Install dependency packages:
sudo apt-get update && sudo apt-get install -y apt-transport-https curl


Download and add GPG key:
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -


Add Kubernetes to repository list:
cat <


Update package listings:
sudo apt-get update


Install Kubernetes packages (Note: If you get a dpkg lock message, just wait a minute or two before trying the command again):
sudo apt-get install -y kubelet=1.21.0-00 kubeadm=1.21.0-00 kubectl=1.21.0-00


Turn off automatic updates:
sudo apt-mark hold kubelet kubeadm kubectl


Log into both Worker Nodes to perform previous steps.


Initialize the Cluster


Initialize the Kubernetes cluster on the control plane node using kubeadm
(Note: This is only performed on the Control Plane Node):
sudo kubeadm init --pod-network-cidr 192.168.0.0/16 --kubernetes-version 1.21.0


Set kubectl access:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config


Test access to cluster:
kubectl get nodes


Install the Calico Network Add-On


On the Control Plane Node, install Calico Networking:
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml


Check status of the control plane node:
kubectl get nodes


Join the Worker Nodes to the Cluster


In the Control Plane Node, create the token and copy the kubeadm join command
(NOTE:The join command can also be found in the output from kubeadm init command):
kubeadm token create --print-join-command


In both Worker Nodes, paste the kubeadm join command to join the cluster. Use sudo to run it as root:
sudo kubeadm join ...


In the Control Plane Node, view cluster status (Note: You may have to wait a few moments to allow all nodes to become ready):
kubectl get nodes



CKA Learning path 2
Sun, 11 Apr 2021 16:22:41 +0800
1. Control Plane
The control plane is a collection of multiple components responsible for managing the cluster itself globally. Essentially, the control plane controls the cluster.
Individual control plane components can run on any machine in the cluster, but usually are run on dedicated controller machines.



1 - K8S Component tools
Sun, 11 Apr 2021 12:15:41 +0800
Component tools
1. Etcd
A distributed, reliable key-value store for the most critical data of a distributed system
etcd
default port: 2379
./etcdctl set key1 value1
./etcdctl get key1
Every information you see when you run the kubectl get command is from the Etcd Server.
To list all keys stored by Kubernetes, run the command like this. Run inside the etcd-master POD.
kubectl exec etcd-master -n kube-system etcdctl get / --prefix -keys-only
2. kube-apiserver
Kube-apiserver is the primary management component in kubernetes. When you run a kubectl command, the kubectl utility is in fact reaching to the kube-apiserver. The kube-apiserver first authenticates the request and validates it. It then retrieves the data from the etcd cluster and reponds back with the requested information.
POST request is available as well.
curl -X POST /api/v1/namespaces/default/pods ...[other]
enable verbose for your command
kubectl get pods -A -v 8
I0209 16:48:43.713733   29886 loader.go:374] Config loaded from file:  /Users/~/.kube/config
I0209 16:48:43.714375   29886 loader.go:374] Config loaded from file:  /Users/~/.kubeconfig_pro
I0209 16:48:43.724834   29886 round_trippers.go:463] GET https://127.0.0.1:6443/api/v1/pods?limit=500
I0209 16:48:43.724856   29886 round_trippers.go:469] Request Headers:
I0209 16:48:43.724870   29886 round_trippers.go:473]     Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json
I0209 16:48:43.724879   29886 round_trippers.go:473]     User-Agent: kubectl/v1.25.0 (darwin/amd64) kubernetes/a866cbe
I0209 16:48:43.744984   29886 round_trippers.go:574] Response Status: 200 OK in 20 milliseconds
kube-apiserver
kube-apiserver is the only component that interacts directly with the etcd datastrore.
3. kube-controller-manager
kube-controller-manager manages various controllers in kubernetes. A controller is like an office or department within the master ship that have their own set of responsibilities.
These offices are:
	No 1. Continuously on the lookout for the status of the ships
	No 2. Take necessary actions to remediate the situation
kube-controller-manager
Node Monitor Period = 5s
Node Monitor Grace Period = 40s
POD Eviction Timeout = 5m
4. kube-scheduler
kube-scheduler is responsible for scheduling pods on nodes. It is only reponsible for deciding which pod goes on which node. It doesn’t actually place the pod on the nodes.
kube-scheduler
The scheduler decides which nodes the pods are placed on depending on certain criteria. You may have pods with different resource requirements. You can have nodes in the cluster dedicated to certain applications.
1. Filter Nodes
2. Rank Nodes - calculates the amount of resources that would be free on the nodes after placing the pod on them

5. kubelet
The kubelet is like the captain on the ship. They lead all activities on a ship. They’re the ones responsible for doing all the paperwork necessary to become part of the cluster. They’re the sole point of contact from the master ship. They load or unload containers on the ship as instructed by the scheduler on the master. The kubelet in the kubernetes worker node, registers the node with the kubernetes cluster. When it receives instructions to load a container or a pod on the node, it requests the container runtime engine, which maybe Docker, to pull the required image and run an instance. The kubelet then continues to monitor the state of the pod and the containers in it and reports to the kube-apiserver on a timely basis.
kubelet
6. kube-proxy
kube-proxy is a process that runs on each node in the kubernetes cluster. Its job is to look for new services and every time a new service is created it creates the appropriate rules on each node to forward traffic to those services to the backend pods. One way it does this is using IPTABLES rules.

CKA on Deep Blue

CKA Learning path 22

Certified Kubernetes Administrator (CKA) Practice Exam: Part 1

Introduction

Solution

Count the Number of Nodes That Are Ready to Run Normal Workloads

Retrieve Error Messages from a Container Log

Find the Pod That Is Utilizing the Most CPU within a Namespace

Certified Kubernetes Administrator (CKA) Practice Exam: Part 2

Introduction

Solution

Edit the web-frontend Deployment to Expose the HTTP Port

Create a Service to Expose the web-frontend Deployment’s Pods Externally

Scale Up the Web Frontend Deployment

Create an Ingress That Maps to the New Service

Certified Kubernetes Administrator (CKA) - Practice Exam Part 3

Introduction

Solution

Create a Service Account

Create a ClusterRole That Provides Read Access to Pods

Bind the ClusterRole to the Service Account to Only Read Pods in the web Namespace

Certified Kubernetes Administrator (CKA) - Practice Exam Part 4

Introduction

Solution

Back Up the etcd Data

Restore the etcd Data from the Backup

CKA Practice Exam - Part 5

Introduction

Solution

Upgrade All Kubernetes Components on the Control Plane Node

Upgrade All Kubernetes Components on the Worker Node

Certified Kubernetes Administrator (CKA): Practice Exam: Part 6

Introduction

Solution

Drain the Worker1 Node

CKA Learning path 21

Troubleshooting a Broken Kubernetes Cluster

Introduction

Solution

Determine What is Wrong with the Cluster

Fix the Problem

Troubleshooting a Broken Kubernetes Application

Introduction

Solution

Identify What is Wrong with the Application

Fix the Problem

CKA Learning path 20

Using PersistentVolumes in Kubernetes

Introduction

Solution

Create a PersistentVolume That Allows Claim Expansion

Create a PersistentVolumeClaim

Create a Pod That Uses a PersistentVolume for Storage

CKA Learning path 19

Managing Container Storage with Kubernetes Volumes

Introduction

Solution

Create a Pod That Outputs Data to the Host Using a Volume

Create a Multi-Container Pod That Shares Data Between Containers Using a Volume

CKA Learning path 18

Using Kubernetes Ingress

Introduction

Solution

Create a Service to Expose the web-auth Deployment

Create an Ingress That Maps to the New Service

CKA Learning path 17

Using Kubernetes Services with DNS

Introduction

Solution

Perform an Nslookup for a Service in the Same Namespace

Perform an Nslookup For a Service in a Different Namespace

CKA Learning path 16

Exposing Kubernetes Pods Using Services

Introduction

Solution

Expose the Pods from the User-db Deployment as an Internal Service

Expose the Pods from the Web-frontend Deployment as an External Service

CKA Learning path 15

Exploring Kubernetes Networking

Introduction

Edit the `web-frontend` Deployment to Expose the HTTP Port

Create a Service to Expose the `web-frontend` Deployment’s Pods Externally

Bind the ClusterRole to the Service Account to Only Read Pods in the `web` Namespace

Drain the `Worker1` Node

Configure the `auth-gateway` Pod to Only Run on `k8s-worker2`

Configure the `auth-data` Deployment’s Replica Pods to Only Run on `k8s-worker2`

Generate an `htpasswd` File and Store It as a Secret

Create a Role for the `dev` User

Bind the Role to the `dev` User and Verify Your Setup Works