CKA 2025 MOCK Q-05 HPA

5 Mock Questions on Horizontal Pod Autoscaler (HPA)

🔶 Question 1: Scale Based on Custom CPU Target and Scale-Up Cooldown

You have a Deployment named api-backend in the default namespace.

Task:

  • Create an HPA targeting 70% CPU usage
  • Min: 1, Max: 10 replicas
  • Set scale-up cooldown (delay before scaling up again) to 30 seconds
  • File name: hpa-backend.yaml

Bonus: Set the HPA to avoid scaling up rapidly even if CPU spikes.

 

cat <<EOF | kubectl apply -f -

apiVersion: apps/v1

kind: Deployment

metadata:

  name: api-backend

  namespace: default

spec:

  replicas: 2

  selector:

    matchLabels:

      app: api-backend

  template:

    metadata:

      labels:

        app: api-backend

    spec:

      containers:

      - name: backend

        image: nginx

        ports:

        - containerPort: 80

        resources:

          requests:

            cpu: "100m"

          limits:

            cpu: "200m"

EOF

 

Solution: Create HPA with Scale-Up Cooldown (hpa-backend.yaml)

 

vi hpa-backend.yaml

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: api-backend-hpa

  namespace: default

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: api-backend

  minReplicas: 1

  maxReplicas: 10

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

        averageUtilization: 70

  behavior:

    scaleUp:

      stabilizationWindowSeconds: 30   # Don't scale up again until 30 sec cool down

📜 Commands:

 

kubectl apply -f deploy-backend.yaml

kubectl apply -f hpa-backend.yaml

kubectl get hpa api-backend-hpa -w


Comments

Post a Comment

Popular posts from this blog

CKA-2025 MOCK Q-06 PRIORITY

 Generate a PriorityClass named urgent-priority for urgent workloads,  setting the value to 10 less than the highest current user-defined priority class value.  Patch the Deployment mysql-writer in the database namespace to use the urgent-priority class and verify a successful rollout.   Note – Pods from other Deployments in the database namespace should be evicted if resources Cruch kubectl create namespace database # redis-cache Deployment cat <<EOF | kubectl apply -f - apiVersion: apps/v1 kind: Deployment metadata:   name: redis-cache   namespace: database spec:   replicas: 2   selector:     matchLabels:       app: redis-cache   template:     metadata:       labels:         app: redis-cache     spec:       containers:       - name: redis         image: redis:7         resources: ...
Read more

Cert-manager - Custom Resource Definitions

 Cert-manager is a Kubernetes add-on used to manage and automate the issuance, renewal, and management of TLS/SSL certificates inside a Kubernetes cluster. It helps in securing applications and services by integrating with external and internal certificate authorities (CAs) like Let’s Encrypt, HashiCorp Vault, or even self-signed issuers. Here’s how it works: CRDs (Custom Resource Definitions) : cert-manager introduces new Kubernetes resource types like Issuer , ClusterIssuer , and Certificate . These CRDs are used to define how and from where the certificates will be issued. Issuer and ClusterIssuer : Issuer is a namespaced resource that defines a certificate authority configuration usable within a single namespace. ClusterIssuer is similar but works cluster-wide and can issue certificates across all namespaces. Certificate Resource : You define a Certificate resource specifying the domain, secret name (where the certificate will be stored), and which Issuer ...
Read more