This lab provides practice scenarios to help prepare you for the Certified Kubernetes Application Developer (CKAD) 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 CKAD exam. Good luck!
Successfully complete this lab by achieving the following learning objectives:
- Create a ConfigMap to Store an `haproxy` Config File
Create a ConfigMap called
defaultNamespace to store the
haproxyconfiguration for an
In the ConfigMap, store the following config file in a key called
frontend ambassador bind *:7171 default_backend api_svc backend api_svc server svc api-svc:8181
- Update a Service to Serve on a New Port.
defaultNamespace, there is a Service called
api-svc. This Service serves an API that is accessed by the
Change the Service’s exposed port to
8181. This will temporarily break the
clientPod’s communication with the Service since the client Pod is still using the old port.
- Re-configure a Pod to use an haproxy ambassador container.
defaultNamespace, there is a Pod called
client. This Pod should be unable to reach the
api-svcService since the Service’s port was changed. Fix this issue by adding an ambassador container to the
clientPod that uses haproxy to forward traffic to the Service’s new port.
You can find manifest file for this Pod at
/home/cloud_user/client.yml. Note that you may need to delete and re-create the Pod in order to make certain changes.
First, modify the command of the client Pod’s
maincontainer so that it reaches out to
api-svc. Do not change the port number that is used within this command.
Add an haproxy ambassador container to the
clientPod using the
haproxy:2.4image. Mount the
haproxy-configConfigMap to the ambassador container at
/usr/local/etc/haproxy/. This will cause the ConfigMap’s haproxy configuration data to configure haproxy in the ambassador container.
Once this is done, the client Pod’s
maincontainer should be able to contact the
api-svcsuccessfully again. You can check the container’s logs with
kubectl logs client -c main.