Mock Exam 2 Step by Step Solutions

​

Question 1 – Creating a Default Local StorageClass

1. SSH into your control plane:
   ssh cluster1-controlplane
   Welcome to Ubuntu 22.04.5 LTS (GNU/Linux 5.15.0-1078-gcp x86_64)
    * Documentation: https://help.ubuntu.com/
    * Management: https://landscape.canonical.com
    * Support: https://ubuntu.com/pro
   
   This system has been minimized by removing packages and content that are not required on a system that users do not log into.
   To restore this content, you can run the 'unminimize' command.
   
2. Referencing the documentation, copy the example configuration and update it as follows:
   • Change the name to local-sc.
   • Update the annotation storageclass.kubernetes.io/is-default-class to "true".
   • Set the provisioner to kubernetes.io/no-provisioner.
   • Remove any unnecessary fields (such as reclaimPolicy and mountOptions) not specified.
   • Retain only allowVolumeExpansion and volumeBindingMode: WaitForFirstConsumer.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/no-provisioner
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

kubectl apply -f question1.yaml

storageclass.storage.k8s.io/local-sc created

​

Question 2 – Deployment with App and Sidecar Containers for Logging

• app-container: Uses the busybox image to continuously append log entries to /var/log/app/app.log.
• log-agent: Also based on busybox, this container tails the same log file.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: logging-deployment
  namespace: logging-ns
spec:
  replicas: 1
  selector:
    matchLabels:
      app: logger
  template:
    metadata:
      labels:
        app: logger
    spec:
      volumes:
        - name: log-volume
          emptyDir: {}
      containers:
      - name: app-container
        image: busybox
        command:
          - sh
          - -c
          - "while true; do echo 'Log entry' >> /var/log/app/app.log; sleep 5; done"
        volumeMounts:
          - name: log-volume
            mountPath: /var/log/app
      - name: log-agent
        image: busybox
        command:
          - tail
          - -f
          - /var/log/app/app.log

kubectl apply -f question2.yaml

kubectl get pod -n logging-ns
kubectl logs <pod-name> -c log-agent -n logging-ns

​

Question 3 – Creating an Ingress Resource to Route Traffic

• Hostname: kodekloud-ingress.app
• Path: / (with PathType: Prefix)
• Forward traffic to webapp-svc on port 80

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: webapp-ingress
  namespace: ingress-ns
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: kodekloud-ingress.app
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: webapp-svc
            port:
              number: 80

kubectl apply -f question3.yaml

curl -s http://kodekloud-ingress.app/

​

Question 4 – Updating an Nginx Deployment with Rolling Updates

1. Generate an initial deployment YAML using a dry run:
   kubectl create deployment nginx-deploy --image=nginx:1.16 --dry-run=client -o yaml > question4.yaml
   
   The generated YAML will be similar to:
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deploy
     labels:
       app: nginx-deploy
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: nginx-deploy
     template:
       metadata:
         labels:
           app: nginx-deploy
       spec:
         containers:
         - name: nginx
           image: nginx:1.16
           resources: {}
   
2. Apply the deployment:
   kubectl apply -f question4.yaml
   
3. Update the image to version 1.17 using a rolling update:
   kubectl set image deployment/nginx-deploy nginx=nginx:1.17
   
4. Verify the rollout history:
   kubectl rollout history deployment nginx-deploy
   kubectl rollout history deployment nginx-deploy --revision=2
   

​

Question 5 – Creating a User via CSR and Configuring RBAC

​

Part A: Create a CertificateSigningRequest (CSR) for User “john”

1. The private key is located at /root/cka/john.key and the CSR file at /root/cka/john.csr. Base64 encode the CSR file content for use in your CSR object.
2. The CSR object should use the signer kubernetes.io/kube-apiserver-client and specify these usages: digital signature, key encipherment, and client auth.

apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
  name: john-developer
spec:
  signerName: kubernetes.io/kube-apiserver-client
  request: <BASE64_ENCODED_CONTENT_OF_/root/cka/john.csr>
  usages:
    - digital signature
    - key encipherment
    - client auth

cat /root/cka/john.csr | base64 | tr -d '\n'

kubectl apply -f question5.yaml

kubectl certificate approve john-developer

​

Part B: Grant RBAC Permissions with Role and RoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: development
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["create", "list", "get", "update", "delete"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: john-developer-role-binding
  namespace: development
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f question5-rbac.yaml

kubectl auth can-i create pods --as=john -n development

​

Question 6 – Creating an Nginx Pod with an Internal Service and DNS Testing

1. Create the Nginx pod:
   kubectl run nginx-resolver --image=nginx
   
2. Expose the pod internally:
   kubectl expose pod nginx-resolver --name=nginx-resolver-service --port=80 --target-port=80 --type=ClusterIP
   
3. Verify the service endpoints:
   kubectl get svc nginx-resolver-service
   kubectl get pod -o wide
   
4. Run a temporary BusyBox pod to perform an nslookup:
   kubectl run test-nslookup --image=busybox:1.28 --rm -it --restart=Never -- nslookup nginx-resolver-service
   

​

Question 7 – Creating a Static Pod

1. Generate a pod YAML definition via dry run:
   kubectl run nginx-critical --image=nginx --restart=Always --dry-run=client -o yaml > static.yaml
   
2. SSH into Node One:
   ssh cluster1-node01
   
3. Place the YAML file into /etc/kubernetes/manifests/static.yaml with contents similar to:
   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx-critical
     labels:
       run: nginx-critical
   spec:
     containers:
     - name: nginx-critical
       image: nginx
     dnsPolicy: ClusterFirst
     restartPolicy: Always
   

kubectl get pod -o wide

​

Question 8 – Creating a Horizontal Pod Autoscaler (HPA)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-hpa
  namespace: backend
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend-deployment
  minReplicas: 3
  maxReplicas: 15
  metrics:
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 65

kubectl apply -f webapp-hpa.yaml

kubectl describe hpa -n backend

​

Question 9 – Troubleshooting a Non-Responsive API Server

1. Run a command such as:
   kubectl get nodes
   
   which may yield:
   The connection to the server cluster2-controlplane:6443 was refused - did you specify the right host or port?
   
2. Use crictl pods to check the running containers and notice that the API server container is missing.
3. Verify the kubelet status:
   sudo systemctl status kubelet
   
   If it is inactive, start and enable the kubelet:
   sudo systemctl start kubelet
   sudo systemctl enable kubelet
   

kubectl get nodes

​

Question 10 – Modifying the Web Gateway for HTTPS

1. Verify that the secret exists:
   kubectl get secret -n cka5673
   
2. Retrieve the current gateway configuration:
   kubectl get gateway -n cka5673 -o yaml > question10.yaml
   
3. Edit the YAML file to update the listener section. Change to the following:
   listeners:
   - name: https
     port: 443
     protocol: HTTPS
     hostname: kodekloud.com
     tls:
       certificateRefs:
       - name: kodekloud-tls
   
4. Apply the updated configuration:
   kubectl apply -f question10.yaml
   

​

Question 11 – Uninstalling a Vulnerable Helm Release

1. List all Helm releases across namespaces:
   helm list -A
   
2. Search for the vulnerable image in each release’s manifests:
   helm get manifest <release-name> -n <namespace> | grep -i kodekloud/webapp-color:v1
   
3. Once identified (for example, if the release is named atlanta-page-apd in the atlanta-page-04 namespace), uninstall it:
   helm uninstall atlanta-page-apd -n atlanta-page-04
   

​

Question 12 – Applying a Network Policy

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: net-policy-3
  namespace: backend
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
  ports:
  - protocol: TCP
    port: 80

kubectl apply -f net-pol-3.yaml

​

Question 13 – Troubleshooting a Failed Deployment Due to Resource Quota

1. Describe the deployment to see error events:
   kubectl describe deployment backend-api
   
   Also check the ReplicaSets for error events indicating that pod creation is forbidden by resource quotas.
2. Describe the resource quota:
   kubectl describe resourcequota cpu-mem-quota
   
   An example output might be:
   Name:            cpu-mem-quota
   Namespace:       default
   Resource         Used     Hard
   ------------------------------
   requests.cpu     200m     300m
   requests.memory  256Mi    300Mi
   
   If the new pod’s request (e.g., 128Mi) exceeds the quota, adjustments are needed.
3. Update the deployment’s resource requests to ensure the total for three replicas remains within the limits. For instance, reduce the memory request from 128Mi to 100Mi:
   resources:
     requests:
       cpu: 100m
       memory: 100Mi
     limits:
       cpu: 150m
       memory: 150Mi
   
4. Update the deployment using editing or applying a modified YAML, and if necessary, delete the problematic ReplicaSet to trigger a new rollout:
   kubectl edit deployment backend-api
   kubectl delete rs <offending-replicaset>
   

​

Question 14 – Deploying Calico CNI with a Custom CIDR

1. Download the custom-resources file:
   curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.29.2/manifests/custom-resources.yaml
   
2. Edit the downloaded YAML file. Locate the Calico IP pool definition and update the cidr value as shown below:
   apiVersion: operator.tigera.io/v1
   kind: Installation
   metadata:
     name: default
   spec:
     calicoNetwork:
       ipPools:
       - name: default-ip4-ipool
         blockSize: 26
         cidr: 172.17.0.0/16
         encapsulation: VXLANCrossSubnet
         natOutgoing: Enabled
         nodeSelector: all
   
3. Apply the modified configuration:
   kubectl apply -f custom-resources.yaml
   
4. To verify that Calico is operating correctly and pod-to-pod communication works, deploy a test pod (such as an Nginx pod) and use a BusyBox or net-tools container for connectivity tests:
   kubectl run web-app --image=nginx
   kubectl run test --rm -it --image=jrcs/net-tools --restart=Never -- sh -c "curl -s <web-app-pod-IP>"