kubectl rollout restart deployment prometheus -n openshift -monitoring Explanation: Setting up alerts ensures proactive monitoring. Prometheus rules allow administrators to customize alerts for specific metrics. Inspect all events in the cluster and filter for warnings related to pods. Provide commands to gather and analyze the data. ee the Solution below. Solution: 1. List all events in the cluster: kubectl get events --all-namespaces 2. Filter for pod -related warnings: kubectl get events --all-namespaces | grep Pod Explanation: Cluster events provide a timeline of activities. Filtering warnings helps identify potential issues requiring attention. View logs from all containers in a multi -container pod. Provide the command and describe how to analyze the logs for issues. ee the Solution below. Solution: 1. Retrieve logs for each container: kubectl logs <pod -name> -c <container -name> Explanation: In multi -container pods, analyzing individual container logs ensures no component issues are missed, enabling targeted troubleshooting.
Deploy an application that uses a Secret to store database credentials. Create the Secret and demonstrate how to inject it into the application. ee the Solution below. Solution: 1. Create a Secret: kubectl create secret generic db -secret --from-literal=username=admin --from-literal=password=secret 2. Reference the Secret in the Deployment YAML: env: - name: DB_USER valueFrom: secretKeyRef: name: db-secret key: username - name: DB_PASS valueFrom: secretKeyRef: name: db-secret key: password Explanation: Secrets securely store sensitive data like credentials. Referencing them in Deployments ensures that applications receive the data without exposing it in configurations. Manually schedule a pod on a specific node in the cluster by using a nodeSelector. Create a pod definition YAML and demonstrate how to verify that the pod is running on the desired node. ee the Solution below. Solution: 1. Create a pod YAML file node -selector -pod.yaml: apiVersion: v1 kind: Pod metadata: name: nginx -pod
spec: containers: - name: nginx image: nginx:latest nodeSelector: kubernetes.io/hostname: <node -name> 2. Apply the pod YAML: kubectl apply -f node -selector -pod.yaml 3. Verify the pod’s node placement: kubectl get pods -o wide Explanation: Using nodeSelector ensures that specific workloads run on designated nodes, enabling targeted resource allocation and optimized cluster performance. Perform a rolling update of an application to upgrade the nginx image from 1.19 to 1.21. Ensure zero downtime during the update and verify that all replicas are running the new version. ee the Solution below. Solution: 1. Update the Deployment: kubectl set image deployment/nginx -deployment nginx=nginx:1.21 2. Monitor the rollout status: kubectl rollout status deployment/nginx -deployment 3. Verify the updated pods: kubectl get pods -o wide kubectl describe pods | grep "nginx:1.21" Explanation: Rolling updates replace pods incrementally, ensuring that applications remain available during the update process. Monitoring confirms the successful rollout.
Use a Horizontal Pod Autoscaler (HPA) to scale the nginx Deployment based on CPU utilization. Create an HPA YAML definition, apply it, and simulate a CPU load to verify the scaling behavior. ee the Solution below. Solution: 1. Create an HPA YAML file hpa.yaml: apiVersion: autoscaling/v2beta2 kind: HorizontalPodAutoscaler metadata: name: nginx -hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx -deployment minReplicas: 2 maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50 2. Apply the HPA: kubectl apply -f hpa.yaml 3. Simulate CPU load on pods and monitor scaling: kubectl run stress --image=alpine -- sh -c "apk add stress && stress --cpu 1" kubectl get hpa Explanation: HPA dynamically adjusts the number of pods to match workload demands, ensuring efficient resource usage while maintaining application performance. Back up etcd data from the OpenShift cluster control plane and explain how to restore it in case of a
failure. ee the Solution below. Solution: 1. Backup etcd data: ETCDCTL_API=3 etcdctl --endpoints=<etcd -endpoint> \ --cacert=/path/to/ca.crt \ --cert=/path/to/etcd -client.crt \ --key=/path/to/etcd -client.key snapshot save /backup/etcd -backup.db 2. Verify the backup: ETCDCTL_API=3 etcdctl snapshot status /backup/etcd -backup.db 3. Restore etcd data: ETCDCTL_API=3 etcdctl snapshot restore /backup/etcd -backup.db \ --data-dir=/path/to/new -data-dir Explanation: Backing up etcd ensures that critical cluster state information can be recovered during disasters. Restoring from snapshots minimizes downtime and restores cluster integrity. Troubleshoot a persistent volume claim (PVC) stuck in Pending state. Identify and resolve common issues such as storage class misconfiguration or unavailable PVs. ee the Solution below. Solution: 1. Check the PVC details: kubectl describe pvc <pvc -name> 2. Verify PV availability and matching storage class: kubectl get pv 3. Fix the storage class or provision a new PV if needed: storageClassName: <correct -storage -class>
kubectl get pods 4. Test the application by exposing the Deployment: kubectl expose deployment nginx -deployment --type=NodePort --port=80 kubectl get svc 5. Use the NodePort and cluster IP to confirm that the application is serving requests. Explanation: Deployments provide a scalable and declarative way to manage applications. YAML manifests ensure the configuration is consistent, while NodePort services expose the application for testing. Verifying replicas ensures that the application is running as expected and resilient. Your team requires an application to load specific configuration data dynamically during runtime. Create a ConfigMap to hold key -value pairs for application settings, and update an existing Deployment to use this ConfigMap. Provide a complete YAML definition for both the ConfigMap and the updated Deployment, and demonstrate how to validate that the configuration is applied correctly. ee the Solution below. Solution: 1. Create a ConfigMap YAML file named app-config.yaml: apiVersion: v1 kind: ConfigMap metadata: name: app-config data: APP_ENV: production APP_DEBUG: "false" 2. Apply the ConfigMap using: kubectl apply -f app -config.yaml 3. Update the Deployment YAML to reference the ConfigMap: apiVersion: apps/v1 kind: Deployment metadata: name: app-deployment spec: replicas: 1
