What you build

Your Assignment 7 project, changed in four ways:

The two environments, their host names, the pipeline's five jobs and the Assignment 5 API stay as they are in Assignment 7.

The chart and the releases

The chart contains everything of an environment: the Deployment, its Service, the Ingress, the ConfigMap, the database's StatefulSet and Service, and for staging the HPA and the PDB.

The configuration

Your service gets one new endpoint:

GET /info        →  200   {"environment": "<value>"}

The JSON may hold more fields.

Scaling and disruptions, in staging

Dev has neither: the same chart with another values file leaves them out.

Under load the HPA must act: while 20 requests at a time arrive at staging's host for 90 s, the HPA raises the Deployment above 2 replicas. Your CPU request and your target decide whether it does.

The end state, checked

• the Assignment 5 API answers at both host names, and GET /info answers dev and staging
• the Deployments, Services, Ingresses, ConfigMaps and StatefulSets of both environments carry Helm's label and release annotations; dev and staging are two releases
• each Deployment reads its ConfigMap
• staging has an HPA with a current utilisation, and a PDB that allows one disruption; dev has neither
• during the load the HPA's wanted replicas rise above 2
• the commits that run in dev and staging have green pipelines, as in Assignment 7
• the repository holds the chart and no credential

The validator

https://iti8801.digivader.com/lab8-validator/: your student code and your GitLab project.

On the walkthrough's service, 20 requests at a time were 80 to 130 requests per second, and the HPA wanted 4 replicas within 30 s. The validator sends the load once per check, runs one check per namespace at a time, and creates and changes nothing in your namespace or your project.

The quota

The HPA can raise staging to 5 service pods. Everything in the namespace still shares one quota:

A pod the quota refuses is not created: the HPA shows 5 replicas and kubectl get pods shows fewer. kubectl describe quota shows the sums.

Your Assignment 6 objects may be deleted once your Assignment 6 check is PASSED; they hold 1500m of CPU limits with the sizes of practice 6.

What to submit, and when

• The validator's code of a check that is PASSED. Paste it into Moodle.
• Deadline: Sunday next week, 23:59, as for every assignment.
• A check is stored with its result: what you change in the project or the namespace afterwards does not change it.

Step 0 · Helm

$ helm version --short
v4.3.0+gbec5b06

Helm reads the same kubeconfig as kubectl: with KUBECONFIG set as in practice 6, helm list answers with the releases of your namespace, at first none.

The pipeline's image alpine/k8s:1.36.5 contains Helm 4.3. Helm 3, the previous version and the one most tutorials still show, works with the same chart; it calls --rollback-on-failure --atomic, and that is the only difference you will meet.

Step 1 · the endpoint

Add GET /info to your service: it answers with the value of an environment variable.

@app.get("/info")
def info():
    return {"environment": os.environ.get("ENVIRONMENT", "")}

Add a line for it to tests/smoke.sh, commit, push. The pipeline builds, tests, scans and deploys to dev as before.

The variable is not set anywhere yet: /info answers with an empty value. The next steps set it through the chart.

Step 2 · the chart's frame

chart/
├── Chart.yaml
├── values.yaml
└── templates/
values-dev.yaml
values-staging.yaml

# chart/Chart.yaml
apiVersion: v2
name: <a name for your application>
description: <one line>
version: 0.1.0

# chart/values.yaml
image:
  repository: <your image repository>
  tag: ""
host: ""
replicas: 1
config:
  ENVIRONMENT: ""
autoscaling:
  enabled: false
  minReplicas: 2
  maxReplicas: 5
  cpuUtilization: 60

The names of the values are yours to choose; the templates of the next steps use these.

Step 3 · the templates

Move your manifests from k8s/ into chart/templates/, one file per object or group, and replace the placeholders:

spec:
  {{- if not .Values.autoscaling.enabled }}
  replicas: {{ .Values.replicas }}
  {{- end }}

The release will be named dev or staging, so api-{{ .Release.Name }} gives the names the objects already have, and secretKeyRef: {name: db-{{ .Release.Name }}, key: password} finds the Secrets you made for Assignment 7.

The database's volume claim is named after the StatefulSet. With the same StatefulSet name as before, the new StatefulSet finds the old claim and its data.

Step 4 · the ConfigMap

chart/templates/configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: api-{{ .Release.Name }}
data:
  {{- range $key, $value := .Values.config }}
  {{ $key }}: {{ $value | quote }}
  {{- end }}

In the Deployment template, the container reads every key as an environment variable, and the pod template carries the ConfigMap's checksum:

  template:
    metadata:
      labels:
        app: api-{{ .Release.Name }}
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/configmap.yaml") . | sha256sum }}
    spec:
      containers:
      - name: service
        envFrom:
        - configMapRef:
            name: api-{{ .Release.Name }}

The annotation changes when a value changes, so the Deployment replaces its pods and the new ones read the new value.

Step 5 · the HPA and the PDB

chart/templates/hpa.yaml, both objects under one condition:

{{- if .Values.autoscaling.enabled }}
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-{{ .Release.Name }}
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-{{ .Release.Name }}
  minReplicas: {{ .Values.autoscaling.minReplicas }}
  maxReplicas: {{ .Values.autoscaling.maxReplicas }}
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: {{ .Values.autoscaling.cpuUtilization }}
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-{{ .Release.Name }}
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: api-{{ .Release.Name }}
{{- end }}

Step 6 · the values files, and a look at the result

# values-dev.yaml
host: <code>-dev.k8s.digivader.com
config:
  ENVIRONMENT: dev

# values-staging.yaml
host: <code>-staging.k8s.digivader.com
config:
  ENVIRONMENT: staging
autoscaling:
  enabled: true

$ helm lint chart -f values-dev.yaml --set image.tag=0fa0b979
==> Linting chart
[INFO] Chart.yaml: icon is recommended

1 chart(s) linted, 0 chart(s) failed
$ helm template dev chart -f values-dev.yaml --set image.tag=0fa0b979 | less
$ helm template staging chart -f values-staging.yaml --set image.tag=0fa0b979 | grep '^kind:'

Read the rendered manifests of both: dev has a replicas: line and no HPA; staging has the HPA and the PDB and no replicas: line. helm template contacts no cluster.

Step 7 · dev becomes a release

Helm does not take over objects that kubectl apply created:

$ helm upgrade --install dev chart -f values-dev.yaml --set image.tag=0fa0b979
Error: unable to continue with install: Service "db-dev" in namespace "000007test" exists and cannot be imported
  into the current release: invalid ownership metadata; label validation error: missing key
  "app.kubernetes.io/managed-by": must be set to "Helm"; …

The error names the first object it meets. Every object of dev that kubectl made has to go, the ConfigMap too if you made one by hand. Not the volume claim, not the Secret: the data is in the claim, and the new StatefulSet, same name, picks it up again.

$ kubectl delete deployment,service,ingress api-dev
$ kubectl delete statefulset,service db-dev
$ kubectl delete configmap api-dev
$ kubectl get pvc data-db-dev-0
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-db-dev-0   Bound    pvc-2ba786ef-88a7-4310-8c7e-8915fcb390cf   1Gi        RWO            local-path     35m

Install, with the tag of an image that exists in your registry:

$ helm upgrade --install dev chart -f values-dev.yaml --set image.tag=0fa0b979 --wait --timeout 2m
Release "dev" does not exist. Installing it now.
NAME: dev
STATUS: deployed
REVISION: 1
$ helm list
NAME   NAMESPACE    REVISION   UPDATED               STATUS     CHART
dev    000007test   1          2026-10-05 23:02:26   deployed   boardgames-0.1.0
$ curl -s http://000007test-dev.k8s.digivader.com/health
{"status":"ok"}

Step 8 · the pipeline deploys with Helm

.deploy:
  stage: deploy
  image: alpine/k8s:1.36.5
  script:
    - helm upgrade --install $ENV chart -f values-$ENV.yaml --set image.tag=$CI_COMMIT_SHORT_SHA --wait --timeout 2m

deploy-dev:
  extends: .deploy
  variables: { ENV: dev }
  environment: { name: dev, url: "http://<code>-dev.k8s.digivader.com" }
  rules:
    - if: $CI_COMMIT_BRANCH == "main"

deploy-staging likewise, with ENV: staging and its rule. Delete the directory k8s/, commit the chart, the values files and the changed .gitlab-ci.yml, push.

$ helm upgrade --install $ENV chart -f values-$ENV.yaml --set image.tag=$CI_COMMIT_SHORT_SHA --wait --timeout 2m
Release "dev" has been upgraded. Happy Helming!
STATUS: deployed
REVISION: 2
Job succeeded

$ curl -s http://000007test-dev.k8s.digivader.com/info
{"environment":"dev"}

Step 9 · staging becomes a release

Delete staging's objects that kubectl made, as in Step 7, with -staging in the names, and the HPA and the PDB if you applied them by hand. Then tag the commit whose pipeline on main is green:

$ kubectl delete deployment,service,ingress api-staging
$ kubectl delete statefulset,service db-staging
$ kubectl delete configmap,hpa,pdb api-staging
$ git tag v2.0
$ git push origin v2.0

After the tag pipeline:

$ helm list
NAME      NAMESPACE    REVISION   UPDATED                   STATUS     CHART
dev       000007test   2          2026-10-05 20:04:20 UTC   deployed   boardgames-0.1.0
staging   000007test   1          2026-10-05 20:05:39 UTC   deployed   boardgames-0.1.0
$ curl -s http://000007test-staging.k8s.digivader.com/info
{"environment":"staging"}
$ kubectl get hpa,pdb
NAME                                              REFERENCE                TARGETS        MINPODS   MAXPODS   REPLICAS   AGE
horizontalpodautoscaler.autoscaling/api-staging   Deployment/api-staging   cpu: 20%/60%   2         5         2          32m

NAME                                     MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
poddisruptionbudget.policy/api-staging   1               N/A               1                     32m

TARGETS shows <unknown> for the first minute. Staging does not answer between the deletion and the end of the tag pipeline.

Step 10 · see it scale

A pod in your namespace that requests staging's Service in four endless loops:

$ kubectl run load --image=busybox:1.37 --restart=Never -- sh -c \
   'for i in 1 2 3 4; do (while true; do wget -q -O /dev/null http://api-staging/api/<resource>; done) & done; wait'
pod/load created
$ kubectl get hpa api-staging          # repeated every 15 s
NAME          REFERENCE                TARGETS         MINPODS   MAXPODS   REPLICAS   AGE
api-staging   Deployment/api-staging   cpu: 22%/60%    2         5         2          70s
api-staging   Deployment/api-staging   cpu: 680%/60%   2         5         2          85s
api-staging   Deployment/api-staging   cpu: 884%/60%   2         5         4          100s
api-staging   Deployment/api-staging   cpu: 778%/60%   2         5         5          116s
$ kubectl top pods -l app=api-staging
$ kubectl delete pod load --now

busybox is a 5 MB image with a shell and wget; --restart=Never makes a plain pod that is not started again when its command ends. kubectl get hpa api-staging --watch prints a line at every change of the object, until Ctrl-C. The first reaction comes 45 to 60 s after the load began. After the load pod is deleted the HPA waits 5 minutes before it removes pods.

Step 11 · the validator

• https://iti8801.digivader.com/lab8-validator/: your student code and your project.
• Six boxes. The Scaling box sends load to staging for up to 90 s and watches the HPA; start a check when staging is at 2 replicas and no load pod runs: 5 minutes after your own load, or after a check. A check takes about two minutes.
• Paste the code of the PASSED check into Moodle.

$ helm list
$ helm history staging
$ kubectl get all,configmap,hpa,pdb -l app.kubernetes.io/managed-by=Helm

show the two releases, the revisions of one, and every object Helm manages.

When something does not work

What stays where