MOCK 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: 3 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.


🔶 Question 2: Memory-Based Autoscaling

You have a Deployment memory-consumer running in apps namespace.


Task:


Create an HPA that:


Scales based on Memory usage


Uses autoscaling/v2


Min: 2, Max: 8


Target Memory usage: 500Mi average per pod


File: hpa-memory.yaml


🧠 Hint: Use resource metric type with memory selector. This only works if metrics-server supports memory usage (sometimes mocked in exam).


🔶 Question 3: Stabilization Window for Both Scale-Up and Scale-Down

Deployment load-burst-app is deployed in dev namespace.


Task:


Create an HPA that:


Targets CPU usage at 60%


Min: 3, Max: 12


Scale-Up window: 45 seconds


Scale-Down window: 120 seconds


📁 File: hpa-burst.yaml


🧠 This prevents flapping (rapid up/down) during CPU spikes or drops.


🔶 Question 4: Limit Scaling Rate – Pods per Minute

You have a deployment named rate-app in default namespace.


Task:


Configure an HPA with:


CPU target: 55%


Min: 2, Max: 6


Set max scale-up to 2 pods per minute


Set max scale-down to 1 pod per minute


📁 Save as hpa-rate.yaml


🧠 Use behavior.scaleUp.policies and behavior.scaleDown.policies for rate control.


🔶 Question 5: Multiple Metrics (CPU + Custom)

Deployment multi-metric-app is running in default.


Task:


Create an HPA that:


Scales on:


CPU usage: 65%


A custom metric named http_requests_per_second from Pods API group


Min: 1, Max: 5


📁 Save as: hpa-multi.yaml


🧠 Bonus: Use metrics.k8s.io and external.metrics.k8s.io API groups.


Let me know which one you want to implement first, and I’ll give full YAML + Hinglish walkthrough.









You said:

i want t deployment file and full solution for all 5 mock questions with step and all info



ChatGPT said:

Updated saved memory

Great! Let's tackle all 5 HPA mock questions one by one. I’ll provide for each:


Deployment YAML (customized for that scenario)


HPA YAML with all annotations and advanced properties


kubectl commands


Hinglish explanation for clarity


Verification step with expected command output or behavior


✅ Question 1: Scale-Up Cooldown – api-backend

🔧 Step 1: Create Deployment (deploy-backend.yaml)


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"

🚀 Step 2: Create HPA with Scale-Up Cooldown (hpa-backend.yaml)

yaml

Copy

Edit

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:

bash

Copy

Edit

kubectl apply -f deploy-backend.yaml

kubectl apply -f hpa-backend.yaml

kubectl get hpa api-backend-hpa -w

✅ Question 2: Memory-Based Autoscaling – memory-consumer

🔧 Deployment (deploy-memory.yaml)

yaml

Copy

Edit

apiVersion: apps/v1

kind: Deployment

metadata:

  name: memory-consumer

  namespace: apps

spec:

  replicas: 2

  selector:

    matchLabels:

      app: memory-consumer

  template:

    metadata:

      labels:

        app: memory-consumer

    spec:

      containers:

      - name: memory-pod

        image: polinux/stress

        args: ["--vm", "1", "--vm-bytes", "200M", "--vm-hang", "1"]

        resources:

          requests:

            memory: "256Mi"

          limits:

            memory: "512Mi"

🚀 HPA (hpa-memory.yaml)

yaml

Copy

Edit

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: memory-consumer-hpa

  namespace: apps

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: memory-consumer

  minReplicas: 2

  maxReplicas: 8

  metrics:

  - type: Resource

    resource:

      name: memory

      target:

        type: AverageValue

        averageValue: 500Mi

📜 Commands:


bash

Copy

Edit

kubectl create ns apps

kubectl apply -f deploy-memory.yaml

kubectl apply -f hpa-memory.yaml

kubectl get hpa -n apps

✅ Question 3: Stabilization Window Both Sides – load-burst-app

🔧 Deployment (deploy-burst.yaml)

yaml

Copy

Edit

apiVersion: apps/v1

kind: Deployment

metadata:

  name: load-burst-app

  namespace: dev

spec:

  replicas: 3

  selector:

    matchLabels:

      app: bursty

  template:

    metadata:

      labels:

        app: bursty

    spec:

      containers:

      - name: stress-ng

        image: progrium/stress

        args: ["--cpu", "2"]

        resources:

          requests:

            cpu: "200m"

          limits:

            cpu: "300m"

🚀 HPA (hpa-burst.yaml)

yaml

Copy

Edit

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: load-burst-app-hpa

  namespace: dev

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: load-burst-app

  minReplicas: 3

  maxReplicas: 12

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

        averageUtilization: 60

  behavior:

    scaleUp:

      stabilizationWindowSeconds: 45

    scaleDown:

      stabilizationWindowSeconds: 120

📜 Commands:


bash

Copy

Edit

kubectl create ns dev

kubectl apply -f deploy-burst.yaml

kubectl apply -f hpa-burst.yaml

kubectl get hpa -n dev -w

✅ Question 4: Rate-Limited Scaling – rate-app

🔧 Deployment (deploy-rate.yaml)

yaml

Copy

Edit

apiVersion: apps/v1

kind: Deployment

metadata:

  name: rate-app

spec:

  replicas: 2

  selector:

    matchLabels:

      app: rate-app

  template:

    metadata:

      labels:

        app: rate-app

    spec:

      containers:

      - name: cpu-burner

        image: vish/stress

        args: ["--cpu", "2"]

        resources:

          requests:

            cpu: "100m"

          limits:

            cpu: "500m"

🚀 HPA (hpa-rate.yaml)

yaml

Copy

Edit

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: rate-app-hpa

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: rate-app

  minReplicas: 2

  maxReplicas: 6

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

        averageUtilization: 55

  behavior:

    scaleUp:

      policies:

      - type: Pods

        value: 2

        periodSeconds: 60

    scaleDown:

      policies:

      - type: Pods

        value: 1

        periodSeconds: 60

📜 Commands:


bash

Copy

Edit

kubectl apply -f deploy-rate.yaml

kubectl apply -f hpa-rate.yaml

kubectl get hpa rate-app-hpa

✅ Question 5: Multiple Metrics – multi-metric-app

🔧 Deployment (deploy-multi.yaml)

yaml

Copy

Edit

apiVersion: apps/v1

kind: Deployment

metadata:

  name: multi-metric-app

spec:

  replicas: 1

  selector:

    matchLabels:

      app: multi-app

  template:

    metadata:

      labels:

        app: multi-app

    spec:

      containers:

      - name: nginx

        image: nginx

        ports:

        - containerPort: 80

        resources:

          requests:

            cpu: "100m"

            memory: "128Mi"

🚀 HPA (hpa-multi.yaml)

yaml

Copy

Edit

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: multi-metric-hpa

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: multi-metric-app

  minReplicas: 1

  maxReplicas: 5

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

        averageUtilization: 65

  - type: Pods

    pods:

      metric:

        name: http_requests_per_second

      target:

        type: AverageValue

        averageValue: "10"

📜 Commands:


bash

Copy

Edit

kubectl apply -f deploy-multi.yaml

kubectl apply -f hpa-multi.yaml

kubectl describe hpa multi-metric-hpa


Comments

Post a Comment

Popular posts from this blog

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:   ...
Read more

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