Linux Foundation CKA 問題集

質問 1：
You have a deployment named 'web-app' with three replicas, exposing the application using a 'LoadBalancer' service. The application uses an internal database service named 'db-service' that is running as a 'ClusterlP' service. You need to configure the 'web-app' deployment to only allow traffic from the service' to its internal port (e.g., 5432).
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Create a NetworkPolicy:
- Create a NetworkPolicy resource that allows traffic from the 'db-service' to the 'web-app' Deployment.

2. Apply the NetworkPolicy: - Apply the YAML file using 'kubectl apply -f networkpolicy.yaml'. 3. Verify the NetworkPolicy: - Check the status of the NetworkPolicy using 'kubectl get networkpolicies allow-db-to-web-app -n . 4. Test: - Ensure that the 'db-service' can communicate with the 'web-app' deployment on port 5432. - Attempt to connect to port 5432 on 'web-app' pods from outside the cluster or from other services/pods within the cluster that are not the 'db-service'. You should not be able to connect. Note: Replace with the actual namespace where your deployments and services are located.

質問 2：
You have a Kubernetes cluster running several applications. You want to implement a network policy that allows traffic only between pods within the same deployment and denies all other traffic. How can you achieve this using NetworkPolicies?
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Create a NetworkPolicy:
- Create a NetworkPolicy in the namespace where the deployments are located.
- Code:

2. Apply the NetworkPolicy: - Apply the NetworkPolicy using 'kubectl apply -f networkpolicy.yaml'

質問 3：
You have a Deployment named 'frontend-deployment' with 5 replicas of a frontend container. You need to implement a rolling update strategy that allows for a maximum of 2 pods to be unavailable at any given time. You also want to ensure that the update process is completed within a specified timeout of 8 minutes. If the update fails to complete within the timeout, the deployment should revert to the previous version. Additionally, you want to configure a 'post-start' hook for the frontend container that executes a health check script to verify the application's readiness before it starts accepting traffic.
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Update the Deployment YAML:
- Update the 'replicas' to 5.
- Define 'maxUnavailable: 2' and 'maxSurge: 0' in the 'strategy.rollingUpdate' section to control the rolling update process.
- Configure a 'strategy.type' to 'RollingUpdate' to trigger a rolling update when the deployment is updated.
- Set Always' to ensure that the new image is pulled even if
it exists in the pod's local cache.
- Add a 'spec.progressDeadlineSeconds: 480' to set a timeout of 8 minutes for the update process.
- Add a 'spec.template.spec.containers[0].lifecycle.postStart' hook to define a script that executes a health check script before the container starts accepting traffic.

2. Create the Deployment: - Apply the updated YAML file using 'kubectl apply -f frontend-deployment.yaml' 3. Verify the Deployment: - Check the status of the deployment using 'kubectl get deployments frontend-deployment' to confirm the rollout and updated replica count. 4. Trigger the Automatic Update: - Push a new image to the 'my.org/frontend:latest' Docker Hub repository. 5. Monitor the Deployment: - Use 'kubectl get pods -l app=frontend' to monitor the pod updates during the rolling update process. 6. Observe Rollback if Timeout Exceeds: - If the update process takes longer than 8 minutes to complete, the deployment will be rolled back to the previous version. This can be observed using 'kubectl describe deployment frontend-deployment' and checking the 'updatedReplicas' and 'availableReplicas' fields.,

質問 4：
You need to deploy a microservice application that uses a custom DNS service for internal communication between microservices. This DNS service is not a standard Kubernetes DNS service. How would you configure Kubernetes to use your custom DNS service for the internal communication of your application?
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Create a ConfigMap for DNS Configuration:
- Create a ConfigMap to store the DNS configuration details for your custom DNS service.
- Example:

- Replace '10.0.0.1 ,10.0.0.2 with the IP addresses of your custom DNS servers and 'my-app.svc.cluster.local' with the search domain for your application. 2. Create a DaemonSet for DNS Configuration: - Create a DaemonSet that will inject the custom DNS configuration into all pods in your cluster. - Example:

- This DaemonSet will use a 'busybox' container to write the DNS configuration from the 'custom-dns-config' ConfigMap to the '/etc/resolv.conf file in every pod. 3. Deploy your Application: - Deploy your microservice application with the appropriate labels to ensure that the DaemonSet injects the custom DNS configuration into your application's pods. 4. Verify DNS Resolution: - Verify that your application's pods can resolve internal DNS names using your custom DNS service. - Example: - You can use the 'nslookup command within a pod to test DNS resolution. 5. Configure Security: - Implement appropriate security measures to protect your custom DNS service and prevent unauthorized access to your application's internal services. - Example: - Consider using a firewall to restrict access to the custom DNS servers. - Configure access control lists to limit access to the DNS service.

質問 5：
You have a Deployment that runs a containerized application. The application requires access to a specific service running in a different namespace. You need to define a NetworkPolicy to allow traffic from the application's Pods to the service in the other namespace only on port 8080.
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Network Policy Definition:

2. Explanation: - 'apiVersion: networking.k8s.io/v1 Specifies the API version for NetworkPolicy resources. - 'kind: NetworkPolicy': Specifies that this is a NetworkPolicy resource. - 'metadata.name: allow-service-access': Sets the name of the NetworkPolicy. - 'metadata.namespace: Specifies the namespace where the NetworkPolicy is applied. Replace with the actual namespace where your deployment is running. - 'spec.podSelector.matchLabels: app: application': This selector targets Pods labeled with 'app: application', ensuring the NetworkPolicy applies to the application Pods. - 'spec.egress.to.namespaceSelector.matchLabels: service-namespace: This allows outgoing traffic only to the namespace labeled with 'service-namespace: Replace with the actual namespace of the service. - 'spec.egress.ports.port: 8080': This allows communication only on port 8080. - 'spec.egress.ports.protocol: TCP': Specifies the protocol (TCP) for the allowed port. 3. How it works: - This NetworkPolicy allows outgoing traffic from the application Pods only to the specified service in the different namespace and only on port 8080. It effectively restricts communication from the application Pods to only the intended target service. 4. Implementation: - Apply the YAML using 'kubectl apply -f allow-service-access.yaml' 5. Verification: After applying the NetworkPolicy, test the connectivity from the application Pods to the service in the other namespace on port 8080. You should observe that the NetworkPolicy successfully enforces the restrictions, allowing access only to the specified port and service.]

質問 6：
have a Kubernetes cluster with limited resources. You have two Deployments: 'app-a' and 'app-b'. Both Deployments require the same resource limits (CPU and memory) but have different resource requests. 'app-a' requests 500m CPU and 512Mi memory, while 'app-b' requests 1000m CPU and IGi memory. When you create a new Pod for 'app-a', it gets scheduled successfully, but when you try to create a new Pod for 'app-b' , it fails to schedule. Explain why the Pod for 'app-b' fails to schedule, and suggest a solution to resolve the issue.
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Understanding the issue: The Pod for 'app-b' fails to schedule because it requests more resources (1000m CPU and IGi memory) than are currently available in the cluster. The scheduler prioritizes Pods that can fit within the available resources, and since 'app-b' exceeds the available resources, it cannot be scheduled.
2. Solution: You can solve this issue by either:
a) Increase Cluster Resources: The most straightforward solution is to increase the resources available in your Kubernetes cluster. This could involve adding more nodes with more CPU and memory or upgrading existing nodes with more powerful hardware.
b) Adjust Resource Requests for 'app-b': If increasing cluster resources is not an option, you can try to adjust the resource requests for 'app-b' to match the available resources. You could reduce the CPU request from 1000m to 500m and the memory request from IGi to 512Mi. This would allow 'app-b' to fit within the available resources and be scheduled. However, reducing resource requests could potentially impact the performance of app-b', so it's important to monitor its performance after the adjustment.
3. Implementation (Example Code):
- Option a (Increase Cluster Resources):
- This involves managing your Kubernetes infrastructure.
- Depending on your Kubernetes setup, you may need to use commands like 'kubectl scale' or 'kubectl apply -f deployment.yamr to manage the deployment of your application.
- For detailed instructions on how to manage your cluster, consult your cluster provider's documentation or the Kubernetes documentation.
- Option b (Adjust Resource Requests):

4. Verification: After implementing either option, you can verify the scheduling by creating a new Pod for 'app- b'. If the Pod is scheduled successfully, the solution has been implemented successfully.

質問 7：
You have a Kubernetes cluster where different teams manage applications in different namespaces. You want to enable a team to manage their resources in a specific namespace while preventing them from accessing resources in other namespaces.
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1 . Create a ServiceAccount for the team:

2. Create a ClusterRole for the team:

3. Create a ClusterRoleBinding that binds the ClusterRole to the ServiceAccount and restricts access to a specific namespace:

4. Replace 'team-sa', 'team-namespace', and 'team-clusterrole' with the actual names. 5. Test the configuration by creating a deployment as the ServiceAccount in the assigned namespace and verifying that you can't access resources in other namespaces.

質問 8：
You have a Deployment named 'web-app-deployment' that uses a service named 'web-app- service' to expose the web application on port 80. You want to update the Deployment to use a new image named 'web-app:v2.0' and update the service to expose a new port, 8080. How would you perform this update using Kubernetes commands?
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Update the Deployment:
- Update the Deployment YAML to use the new image 'web-app:v2.0'.
- Use 'kubectl apply -f web-app-deployment.yaml' to apply the updated Deployment.
- Example YAML:

2. Update the Service: - Update the Service YAML to expose the new port 8080. - Use 'kubectl apply -f web-app-service.yaml' to apply the updated Service. - Example YAML:

3. Verify the Update: - Use 'kubectl get deployments web-app-deployment' to verify that the Deployment has updated to use the new image. - Use 'kubectl get services web-app-service' to verify that the Service has updated to expose the new port. - You can then access the web application using the new port through your Kubernetes cluster's IP address or through a NodePort if that's your service type. - If you're using Ingress, you'll need to update your Ingress resource as well to match the new port. ,

質問 9：
You are running a Kubernetes cluster with a NodePort service exposing a web application on port 80. You want to access the web application from a client machine outside the cluster. However, the client machine is behind a NAT gateway and you cannot directly configure firewall rules on the gateway. How can you configure the Kubernetes cluster to allow the client machine to access the web application?
正解：
See the solution below with Step by Step Explanation.
Explanation:
Solution (Step by Step) :
1. Create a NodePort Service:
- Create a NodePort service that exposes port 80 of the web application on a specific NodePort (for example,
30080).
- Code:

2. Configure NAT Gateway: - Configure the NAT gateway to forward traffic from the client machine's IP address and port to the Kubernetes cluster's IP address and the NodePort. - Note: This configuration will depend on the specific NAT gateway and its configuration options. 3. Access the Application: - On the client machine, access the web application by using the Kubernetes cluster's IP address and the NodePort. - Example: 'http://:30080'