labels: app: my -app version: canary spec: containers: - name: app-container image: my -app:v2 3. Configure traffic split using a Service: apiVersion: v1 kind: Service metadata: name: app-service spec: selector: app: my-app ports: - protocol: TCP port: 80 sessionAffinity: None 4. Monitor canary performance: kubectl logs <canary -pod-name> Explanation: Canary deployments reduce risks by testing updates on a small subset of traffic, allowing issues to be identified before a full rollout. Implement a ClusterRole to allow developers to create and delete pods in a specific namespace. Bind this role to a group named dev -group. ee the Solution below. Solution: 1. Create a ClusterRole YAML file clusterrole.yaml: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: pod-manager rules: - apiGroups: [""]
resources: ["pods"] verbs: ["create", "delete"] 2. Bind the ClusterRole to the dev -group: apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: pod-manager -binding subjects: - kind: Group name: dev-group apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: pod-manager apiGroup: rbac.authorization.k8s.io 3. Apply both files: kubectl apply -f clusterrole.yaml kubectl apply -f clusterrolebinding.yaml Explanation: ClusterRoles and bindings provide scalable permissions management, ensuring developers have access to required resources without over -permissioning. Diagnose and fix an issue where a Deployment fails due to exceeding the configured ResourceQuota. ee the Solution below. Solution: 1. Check the ResourceQuota usage: kubectl get resourcequota -n <namespace> 2. Review the Deployment resource requests: kubectl describe deployment <deployment -name> 3. Adjust Deployment resource requests to fit within the quota: resources: requests:
cpu: "100m" memory: "128Mi" 4. Reapply the Deployment: kubectl apply -f deployment.yaml Explanation: ResourceQuotas ensure fair resource distribution. Adjusting Deployment configurations avoids conflicts and ensures compliance. Use OpenShift metrics to analyze and optimize application performance under load. Include steps to simulate load and monitor metrics through Prometheus. ee the Solution below. Solution: 1. Simulate load on the application: kubectl run load-generator --image=busybox -- /bin/sh -c "while true; do wget -q -O- http://<service -IP>; done" 2. Access Prometheus: kubectl port -forward -n openshift -monitoring svc/prometheus 9090 3. Query application metrics (e.g., CPU usage): container_cpu_usage_seconds_total{namespace="<namespace>", pod="<pod -name>"} Explanation: Prometheus metrics provide insights into application performance under load, helping administrators identify and resolve bottlenecks. Use OpenShift to configure an external load balancer to expose a service to the internet. Provide steps to create a LoadBalancer service and validate its accessibility. ee the Solution below. Solution:
1. Create a LoadBalancer service YAML file: apiVersion: v1 kind: Service metadata: name: external -lb-service spec: type: LoadBalancer selector: app: my-app ports: - protocol: TCP port: 80 targetPort: 8080 2. Apply the YAML: kubectl apply -f external -lb-service.yaml 3. Retrieve the external IP of the LoadBalancer: kubectl get svc external -lb-service 4. Validate accessibility using the external IP: curl http://<external -IP> Explanation: LoadBalancer services allow OpenShift to integrate with external cloud or on-premises load balancers, enabling public exposure of services. Simulate and fix a crash -loop issue in a pod caused by incorrect environment variables. Provide steps to identify the issue and apply a fix. ee the Solution below. Solution: 1. Check pod logs for errors: kubectl logs <pod -name> 2. Inspect the pod configuration: kubectl describe pod <pod -name>
3. Fix the Deployment by updating environment variables: env: - name: APP_ENV value: "production" 4. Apply the updated Deployment: kubectl apply -f deployment.yaml 5. Verify the pod status: kubectl get pods Explanation: Crash -loop issues often stem from configuration errors. Diagnosing logs and fixing environment variables ensures pod recovery. Create a multi -container pod that includes a primary application and a sidecar container for logging. Demonstrate how to configure and validate the logging setup. ee the Solution below. Solution: 1. Create a multi -container pod YAML file: apiVersion: v1 kind: Pod metadata: name: app-with-logger spec: containers: - name: app-container image: nginx - name: logging -sidecar image: fluentd args: [" -c", "/fluentd/etc/fluent.conf"] 2. Apply the pod configuration: kubectl apply -f pod.yaml 3. Validate logs generated by the sidecar:
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
