Following is a list of questions that you can time it yourself for practicing the implementation on your local clusters. It will help you speed up your kubectl skills to create the k8s resources that will be handy during the examination.
- Create a new pod with the NGINX image.
- Create a new pod with the name 'redis' and with the image 'redis:1.99'.
- Identify the problem with the pod.
- Rectify the problem with the pod and wait until the pod is ready and healthy.
- Create a new replicaset rs-1 using image nginx with labels tier:frontend and selectors as tier:frontend. Create 3 replicas for the same.
- Scale the replica set above to 5 replicas.
- Update the image of the above replicaset to use nginx:alpine image.
- Scale down the replica set to 2 replicas.
- Create a new deployment deploy-1 using image busybox with 3 replicas and command "sleep 3600".
- Update the image of the above deployment with image ubuntu.
- Create a namespace 'finance'.
- Create a pod redis01 using image redis in 'finance' namespace.
- Deploy a redis02 pod using the redis:alpine image with the labels set to tier=db.
- Create a service redis-service to expose the redis02 application within the cluster on port 6379.
- Create a new pod called custom-nginx using the nginx image and expose it on container port 8080.
- Create a pod called httpd using the image httpd:alpine in the default namespace. Next, create a service of type ClusterIP by the same name (httpd). The target port for the service should be 80.
- Create a pod with the ubuntu image to run a container to sleep for 5000 seconds.
- Create a new ConfigMap for the 'webapp-color' POD. Set key-value pairs as COLOR=blue.
- Create a deployment nginx01 using nginx image, which has environment variable CREATED_BY with value
octocat
. - Verify the environment variable in the containers of the above deployment.
- Create a new config map db-config with key-value pairs as: a] db-host = "localhost.example.com" b] db-port = 3306 c] db-name = "kubernetes-objects"
- Mount the config map db-config in the deployment ubuntu01 with image ubuntu which has 2 replicas.
- Create a deployment named multi-con-01, which has two containers, one container uses nginx image and has port 80 exposed. Mount the config map in (21) as environment variables. Create the second container in the same deployment with image ubuntu, keep the container alive using the command
sleep 5000
and mount the config map in (21) with different keys where the new keys are mapped as db-host --> DB_URL, db-port --> DB_PORT, db-name --> DB_NAME. - Create an opaque secret named db-creds with following details: db_user=root,db_password=pass404,db_role=admin.
- Mount the secret db-creds in the deployment multi-con-01 [created in (23)] as environment variables in the ubuntu container with the same keys as mentioned in the secret.
- Create a pod ubuntu02 with image ubuntu and run the command
sleep 3400
as user 1001. - Create a pod ubuntu03 with image ubuntu and add capabilities for SYS_TIME to each container. Run the command `date -s '01JAN 2020 10:00:00' to verify if it is successful.
- Taint one of the worker nodes in your cluster with the following property,
mode=maintainance:NoSchedule
. Create a pod nginx02 with image nginx:alpine and ensure the pod runs on the tainted node as above. Hint: You might want to use tolerations and nodeselectors both in case you have multiple worker nodes.. - Create a pod box0 with image busybox and command "sleep 30; touch /tmp/debug; sleep 30; rm /tmp/debug". The pod should not be ready until the file /tmp/debug is available in the pod. If the file doesn't exist, the pod must restart.
- Create a pod nginx03 with image nginx, make sure the server is up and running every 10 seconds. The nginx server ideally takes 30 seconds to warm up so ensure that there are no false negatives when reporting the health of the pod. Note: Nginx runs on port 80..
- This is a multistage problem: a] Create a deployment deploy01 with image nginx with port 80 exposed. b] Update the deployment with image nginx:dev and make sure you record the execution of this action. c] If the deployment in step b is unsuccessful, rollback the deployment to the previous state by setting any fields explicitly. d] If the nginx deployment is in a healthy state, scale the deployment to run 3 replicas, also record this execution for audit-keeping.
- Create a job that will roll a dice using image kodekloud/throw-dice. The image generates a random number between 1 and 6 and exits. It is a success only if it is a 6 else it is a failure. Check how many times it takes the job to trigger to get a successful outcome.
- Create a job with the above image to generate 8 successful outcomes. Also, ensure that the job will attempt no more than 15 attempts and see if the job is successful. You can add an element of 3 parallel executions if required.
- Create a scheduled job such that it runs every minute. Use the image kodekloud/throw-dice to check the outcome.
- Create a Persistent Volume
deploy-history
which makes the storage available on each worker nodes at /tmp/deployment. Make sure it has the default provisioner of your cluster assigned. Label the Persistent Volume withaudit: true
,tier: middleware
. The persistent volume must have a capacity of 2 GB. - Create a Persistent Volume
persistent-data
which uses a storage class namepersistent
and is of type hostPath which stores the data on /tmp/persistent on worker nodes. The persistent volume must have a capacity of 2 GB. - Create a Persistent Volume
my-personal-data
which uses a storage class namepersistent
and is of type hostPath which stores the data on /tmp/pii on worker nodes. The persistent volume must have a capacity of 2 GB. Since this will store personal data, make sure you can identify the persistent volume using the label "security: high", "type: pii", "audit: true". - Create a Persistent Volume Claim to bind to persistent volume which uses storage class
persistent
and needs 2 GB capacity. - Create a Persistent Volume Claim to bind to a PV which ensures that the personal and private data is secure. Ensure that this PVC will bind to a PV of type
pii
. - Create a PVC such that it will bind to a PV that is qualified for middleware applications.
- Create a deployment deploy02 with image busybox, mount one of the PVC from above such that it will store logs in the
/tmp/deployment
directory. The containers of the deployment must: a] Create a file in /tmp/deployment with the same name as the pod name with .txt extension. b] Run the commandi=0; while true; do; echo "$i $(date)" >> /tmp/deployment/<podname>.txt && sleep 60 ; done
to the log file. Hint: You can use init-containers, environment variables to achieve this. c] Ensure there are 5 replicas of the deployment. d] Ensure you can see the log files created and populated with data in /tmp/deployment directory on the scheduled worker nodes. - Create two deployments i.e. nginx04 and redis04 using images nginx and redis respectively with 3 replicas. Your goal is to ensure that: a] each worker node must not have 2 or more nginx04 pods. b] each worker node that has a nginx04 pod must have a redis04 pod scheduled on the same node. Hint: Use pod affinity and anti-affinity to ensure the above scneario.
- Create 3 pods nginx05, redis05, and httpd05 with images nginx, redis, and httpd respectively. Attach a sidecar debug container of image busybox to each of them. The security team has enforced the application team to limit the communication between unnecessary pods. Ensure that only the following communication is allowed between pods: a] Allow: nginx05 and redis05, nginx05 and httpd05. b] Deny: httpd05 and redis05, redis05 and rest of the world. nginx05 and the rest of the world. Identify a possible information flow in this system. Write the information flow in the format End-User::Pod1::Pod2::Pod3.
- Create an application stack from this source link. Apply a network policy from this source link. Identify whether the network policy applied is correct or not. If not, update the desired network policy. If any network policy was updated, write the updated policy in /opt/44_netpol.yaml.
- A developer started a pod calculus with image busybox which performs the calculation "i=0; while true; do a=$(( i*i+i )); echo
$a; i=$ (( i+1 )); done". But later realized that this is not a reliable way to start a calculation-intensive pod. The developer decided to use a replicaset instead. But with the current pod running it would ruin all the calculations done so far. Can you the developer to ensure that a replicaset can be created and the existing pod can become a part of this replicaset without any downtime. Store the manifest file of the replica set in /opt/45_rs.yaml and at the beginning add a comment describing in one line what strategy was implemented to achieve this.