Solution: 1. Create a ResourceQuota YAML file resource -quota.yaml: apiVersion: v1 kind: ResourceQuota metadata: name: namespace -quota namespace: resource -restricted spec: hard: pods: "10" requests.cpu: "2" requests.memory: 2Gi limits.cpu: "4" limits.memory: 4Gi 2. Apply the ResourceQuota: kubectl apply -f resource -quota.yaml 3. Test the quota enforcement: kubectl create deployment test-deployment --image=nginx kubectl get resourcequota -n resource -restricted Explanation: ResourceQuotas enforce limits on resource consumption, ensuring fair resource allocation and preventing single workloads from exhausting cluster resources. Troubleshoot an issue where pods are not starting due to missing NodePorts in a Service configuration. Fix the Service and validate pod communication. ee the Solution below. Solution: 1. Inspect the Service configuration: kubectl describe svc <service -name> 2. Update the Service YAML to include NodePorts: spec: type: NodePort
ports: - protocol: TCP port: 80 targetPort: 80 nodePort: 30080 3. Apply the updated Service: kubectl apply -f service.yaml 4. Test pod communication via NodePort: curl <Node -IP>:30080 Explanation: NodePorts expose applications externally for testing or debugging, ensuring proper communication between pods and clients. Use OpenShift CLI to monitor cluster health and identify nodes under pressure. Provide steps to analyze and resolve any resource contention issues. ee the Solution below. Solution: 1. Check node resource usage: kubectl top nodes 2. Inspect workloads on a specific node: kubectl get pods --all-namespaces -o wide | grep <node -name> 3. Identify and scale resource -intensive deployments: kubectl scale deployment <deployment -name> --replicas=1 Explanation: Monitoring node health helps detect and resolve resource bottlenecks, ensuring cluster stability and optimal performance.
Configure OpenShift to send alerts for failed Jobs using Prometheus AlertManager. Include steps to define alert rules and test the alert mechanism. ee the Solution below. Solution: 1. Edit Prometheus configuration: kubectl edit cm prometheus -config -n openshift -monitoring Add an alert rule: groups: - name: job.rules rules: - alert: JobFailed expr: kube_job_status_failed > 0 for: 2m labels: severity: warning annotations: summary: "Job failure detected" description: "Job {{ $labels.job }} has failed {{ $value }} times." 2. Restart Prometheus: kubectl rollout restart deployment prometheus -n openshift -monitoring 3. Simulate a failed Job to test alerts. Explanation: Prometheus AlertManager integrates with OpenShift to provide real-time notifications for critical events like Job failures, ensuring quick remediation. Configure OpenShift to restrict ingress traffic to a specific namespace using Network Policies. Include steps to create a policy that allows traffic only from a specific pod in another namespace. ee the Solution below. Solution: 1. Create a NetworkPolicy YAML file network -policy.yaml: apiVersion: networking.k8s.io/v1 kind: NetworkPolicy
metadata: name: restrict -ingress namespace: restricted -namespace spec: podSelector: {} ingress: - from: - namespaceSelector: matchLabels: name: allowed -namespace podSelector: matchLabels: app: allowed -pod 2. Label the namespaces and pods: kubectl label namespace allowed -namespace name=allowed -namespace kubectl label pod allowed -pod app=allowed -pod -n allowed -namespace 3. Apply the NetworkPolicy: kubectl apply -f network -policy.yaml 4. Test the policy by attempting connections from disallowed and allowed pods. Explanation: NetworkPolicies enable administrators to enforce strict ingress and egress rules, securing namespace communications and ensuring compliance with organizational policies. Perform a cluster -wide search for all pods using images older than a specific version and update them. Provide commands to identify and upgrade the images. ee the Solution below. Solution: 1. Search for pods with old images: kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[].image | contains(":v1.0")) | {namespace: .metadata.namespace, pod: .metadata.name, image: .spec.containers[].image}' 2. Update the image in the Deployment: kubectl set image deployment/<deployment -name> <container -name>=<new -image> -n <namespace>
3. Verify the update: kubectl rollout status deployment/<deployment -name> Explanation: Keeping container images updated ensures security and performance. Searching for outdated images helps identify workloads that require updates. Troubleshoot and resolve an issue where a pod is in Pending state due to insufficient CPU or memory resources. Include steps to identify and reallocate resources. ee the Solution below. Solution: 1. Check the pod description for resource issues: kubectl describe pod <pod -name> 2. Review node resource usage: kubectl top nodes 3. Adjust the pod’s resource requests and limits in the Deployment: resources: requests: cpu: "200m" memory: "256Mi" limits: cpu: "500m" memory: "512Mi" 4. Apply the updated Deployment: kubectl apply -f deployment.yaml Explanation: Pods in Pending state often indicate resource constraints. Adjusting resource requests ensures proper scheduling while maintaining cluster balance. Configure an OpenShift Service to route traffic to multiple backends based on the request path. Include steps to create the Service and validate traffic routing. ee the Solution below. Solution: 1. Define a Service with multiple backends: apiVersion: v1 kind: Service metadata: name: multi -backend -service spec: selector: app: backend ports: - protocol: TCP port: 80 targetPort: 8080 2. Create an Ingress resource to handle path-based routing: apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: path-routing spec: rules: - http: paths: - path: /app1 pathType: Prefix backend: service: name: app1 -service port: number: 80 - path: /app2 pathType: Prefix backend: service: name: app2 -service port: number: 80 3. Test routing by accessing paths /app1 and /app2. Explanation:
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
