15 Prompts for Kubernetes: Master Manifests, Helm, and Deployments

Generate a Kubernetes Pod manifest for a single container running nginx:1.25-alpine. Include resource limits (CPU: 200m, memory: 256Mi) and a liveness probe that checks HTTP GET on port 80 with path /healthz. Use YAML format.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.25-alpine
    ports:
    - containerPort: 80
    resources:
      limits:
        cpu: "200m"
        memory: "256Mi"
      requests:
        cpu: "100m"
        memory: "128Mi"
    livenessProbe:
      httpGet:
        path: /healthz
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 10

Create a Kubernetes Service manifest of type ClusterIP that exposes port 80 and targets port 8080 on pods with label app: myapp. Include a selector, and name the service myapp-service.

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

Write a Kubernetes Ingress manifest for a domain api.example.com that routes all traffic to a service named api-service on port 80. Use the nginx ingress controller annotation. Assume TLS is not required yet.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api-ingress
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

Generate a ConfigMap manifest that imports the contents of a local file app.properties. The ConfigMap name should be app-config. Then show a Pod that mounts this ConfigMap as a volume at /etc/config.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.properties: |
    database.url=jdbc:postgresql://localhost:5432/mydb
    log.level=INFO
---
apiVersion: v1
kind: Pod
metadata:
  name: config-pod
spec:
  containers:
  - name: app
    image: myapp:1.0
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config

Write a PersistentVolumeClaim manifest that requests 5Gi of storage with ReadWriteOnce access mode. Storage class should be standard. Then attach it to a Pod running MySQL.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard
---
apiVersion: v1
kind: Pod
metadata:
  name: mysql
spec:
  containers:
  - name: mysql
    image: mysql:8.0
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: secret
    volumeMounts:
    - name: mysql-storage
      mountPath: /var/lib/mysql
  volumes:
  - name: mysql-storage
    persistentVolumeClaim:
      claimName: mysql-pvc

Create a Deployment manifest for a Node.js application with 3 replicas. Use image node:18-slim, expose container port 3000, and add a readiness probe that checks HTTP GET on /ready. Include rolling update strategy with maxSurge=1 and maxUnavailable=0.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: node-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  selector:
    matchLabels:
      app: node-app
  template:
    metadata:
      labels:
        app: node-app
    spec:
      containers:
      - name: node
        image: node:18-slim
        ports:
        - containerPort: 3000
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 10
          periodSeconds: 5

Write a HorizontalPodAutoscaler manifest that scales the deployment 'frontend' between 2 and 10 replicas when CPU utilization exceeds 70%. Use the autoscaling/v2 API version.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: frontend-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: frontend
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Generate a NetworkPolicy that allows only ingress traffic from Pods with label role: monitoring to the Pods with label app: database on port 5432. Deny all other ingress.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-network-policy
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: monitoring
    ports:
    - protocol: TCP
      port: 5432

Create a Pod with an init container that runs a busybox command to create a file /data/initialized and then the main container runs nginx. Use an emptyDir volume shared between both containers.

apiVersion: v1
kind: Pod
metadata:
  name: init-pod
spec:
  volumes:
  - name: data
    emptyDir: {}
  initContainers:
  - name: init-setup
    image: busybox
    command:
    - sh
    - -c
    - "echo initialized > /data/initialized"
    volumeMounts:
    - name: data
      mountPath: /data
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - name: data
      mountPath: /usr/share/nginx/html

Write a step-by-step debugging checklist for a Pod stuck in CrashLoopBackOff. Include commands to check logs, describe the Pod, and inspect events. Then provide a sample kubectl command to view the last 50 log lines with timestamps.

1. Check Pod status: kubectl get pods
2. Describe Pod for events: kubectl describe pod <pod-name>
3. View logs: kubectl logs <pod-name> --tail=50 --timestamps
4. If init containers exist: kubectl logs <pod-name> -c <init-container>
5. Check previous instance logs: kubectl logs <pod-name> --previous
6. Verify resource limits: kubectl describe pod <pod-name> | grep -A5 Limits

Sample command:
kubectl logs my-app-7d4f8b9c6-abcde --tail=50 --timestamps

Generate a Helm chart structure for a Python Flask application. Include a values.yaml with default replica count, image, service port, and ingress host. Provide the templates/deployment.yaml and templates/service.yaml. Use Helm 3 format.

# Chart.yaml
apiVersion: v2
name: flask-app
version: 0.1.0
---
# values.yaml
replicaCount: 2
image:
  repository: myregistry/flask-app
  tag: latest
service:
  type: ClusterIP
  port: 5000
ingress:
  enabled: true
  host: flask.example.com
---
# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "flask-app.fullname" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "flask-app.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "flask-app.name" . }}
    spec:
      containers:
      - name: flask
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        ports:
        - containerPort: {{ .Values.service.port }}
---
# templates/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: {{ include "flask-app.fullname" . }}
spec:
  type: {{ .Values.service.type }}
  ports:
  - port: {{ .Values.service.port }}
    targetPort: {{ .Values.service.port }}
  selector:
    app: {{ include "flask-app.name" . }}

Create a VirtualService and DestinationRule for Istio to route 10% of traffic to version v2 of a service named 'checkout'. The rest goes to v1. Use the host checkout.default.svc.cluster.local.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: checkout-destination
spec:
  host: checkout.default.svc.cluster.local
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: checkout-vs
spec:
  hosts:
  - checkout.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: checkout.default.svc.cluster.local
        subset: v1
      weight: 90
    - destination:
        host: checkout.default.svc.cluster.local
        subset: v2
      weight: 10

Generate a PrometheusRule manifest that triggers an alert when any Pod in the 'production' namespace has CPU usage above 90% for 5 minutes. Include a summary and description annotation.

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: k8s-cpu-alerts
  namespace: production
spec:
  groups:
  - name: cpu.rules
    rules:
    - alert: HighCPUUsage
      expr: sum(rate(container_cpu_usage_seconds_total{namespace="production"}[5m])) by (pod) / sum(kube_pod_container_resource_limits_cpu_cores{namespace="production"}) by (pod) > 0.9
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "Pod {{ $labels.pod }} has high CPU usage"
        description: "CPU usage for pod {{ $labels.pod }} is above 90% for 5 minutes."

Create a ClusterIssuer for Let's Encrypt staging environment using HTTP01 challenge, and then a Certificate resource for domain secure.example.com that references this issuer. Include the necessary Ingress annotation.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
spec:
  acme:
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    email: admin@example.com
    privateKeySecretRef:
      name: letsencrypt-staging-key
    solvers:
    - http01:
        ingress:
          class: nginx
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: secure-tls
  namespace: default
spec:
  secretName: secure-tls-secret
  issuerRef:
    name: letsencrypt-staging
    kind: ClusterIssuer
  dnsNames:
  - secure.example.com
---
# Ingress annotation to use the certificate
# cert-manager.io/cluster-issuer: letsencrypt-staging

Create a Kyverno policy that denies Pods if they don't have resource limits set for CPU and memory. Apply it to all namespaces except 'kube-system'. Use validate action.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-limits
    match:
      any:
      - resources:
          kinds:
          - Pod
    exclude:
      resources:
        namespaces:
        - kube-system
    validate:
      message: "Pods must have resource limits for CPU and memory."
      pattern:
        spec:
          containers:
          - resources:
              limits:
                cpu: "?*"
                memory: "?*"

Design a Helm-driven deployment pipeline that uses a single chart but separate values files for each environment (values-dev.yaml, values-staging.yaml, values-prod.yaml). Provide a Makefile target that runs helm upgrade with the correct values file based on an environment variable. Include a values-prod.yaml snippet with replicaCount: 5 and resource limits.

# Makefile
ENV ?= dev

install:
    helm upgrade --install my-app ./my-chart \
      --values ./my-chart/values-$(ENV).yaml \
      --namespace $(ENV) --create-namespace
---
# values-prod.yaml
replicaCount: 5
image:
  tag: prod-1.0.0
resources:
  limits:
    cpu: "1"
    memory: "1Gi"
ingress:
  enabled: true
  host: app.example.com

Write a sequence of Helm commands to rollback a release named 'frontend' to revision 3, verify the rollback, and then clean up old revisions. Include commands to list revisions and check release status.

# List all revisions
helm history frontend

# Rollback to revision 3
helm rollback frontend 3

# Verify the rollback
helm status frontend

# Clean up old revisions (keep last 3)
helm history frontend --max 10
helm delete frontend --revision 1
helm delete frontend --revision 2

Create an Argo CD Application manifest that syncs a Helm chart from a Git repo (https://github.com/myorg/charts.git) in the 'charts/my-app' directory. Use auto-sync with pruning enabled. Set targetRevision to main and namespace to production.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/myorg/charts.git
    targetRevision: main
    path: charts/my-app
    helm:
      valueFiles:
      - values-prod.yaml
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true