Helm pentru aplicații multi-pod

În această secțiune, vom folosi Helm pentru a orchestra o aplicație simplă compusă din două componente:

• un backend scris în Python (Flask), care servește un mesaj JSON
• un frontend bazat pe Nginx, care afișează acel mesaj într-o pagină HTML statică.

Vom folosi un singur chart Helm care definește ambele componente și le conectează între ele printr-un Service intern.

Crearea unui chart nou

Începem prin crearea unui nou chart:

$ helm create webapp
Creating webapp

Ștergem fișierele implicite din templates/ (deployment/service unice) și vom crea două fișiere noi: frontend.yaml și backend.yaml.

Definirea backend-ului

Creăm fișierul templates/backend.yaml cu următorul conținut:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-backend
spec:
  replicas: {{ .Values.backend.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}-backend
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-backend
    spec:
      containers:
      - name: backend
        image: {{ .Values.backend.image }}
        ports:
        - containerPort: 5000
---
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-backend
spec:
  selector:
    app: {{ .Release.Name }}-backend
  ports:
  - port: 5000
    targetPort: 5000

Definirea frontend-ului

Creăm fișierul templates/frontend.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-frontend
spec:
  replicas: {{ .Values.frontend.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Release.Name }}-frontend
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}-frontend
    spec:
      containers:
      - name: frontend
        image: {{ .Values.frontend.image }}
        ports:
        - containerPort: 80
        env:
        - name: BACKEND_URL
          value: "http://{{ .Release.Name }}-backend:5000"
---
apiVersion: v1
kind: Service
metadata:
  name: {{ .Release.Name }}-frontend
spec:
  selector:
    app: {{ .Release.Name }}-frontend
  ports:
  - port: 80
    targetPort: 80

Setarea valorilor configurabile

În values.yaml, ștergem tot conținutul pre-populat și adăugăm două secțiuni separate:

backend:
  image: "ghcr.io/benc-uk/python-demoapp:latest"
  replicaCount: 1

frontend:
  image: "nginx:1.25"
  replicaCount: 1

Backend-ul este o imagine publică care rulează un mic API Python ce răspunde cu „Hello from Python backend!”. Frontend-ul este un container Nginx gol, pe care îl putem ulterior personaliza (de exemplu, cu un config map pentru HTML static).

Pentru simplitate, vom verifica doar că podurile se lansează și că frontend-ul poate ajunge la backend prin DNS-ul intern Kubernetes.

Instalarea aplicației

$ helm install webdemo ./webapp
NAME: webdemo
LAST DEPLOYED: Sat Nov  1 11:54:49 2025
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

$ kubectl get pods -l app=webdemo-backend
NAME                               READY   STATUS    RESTARTS   AGE
webdemo-backend-6b98dc7d85-gzxw7   1/1     Running   0          47s

$ kubectl get pods -l app=webdemo-frontend
NAME                                READY   STATUS    RESTARTS   AGE
webdemo-frontend-6d8998b646-ksmqz   1/1     Running   0          2m

$ kubectl get svc | grep webdemo
webdemo-backend           ClusterIP      10.96.144.100   <none>        5000/TCP                     2m4s
webdemo-frontend          ClusterIP      10.96.191.231   <none>        80/TCP                       2m4s

Ar trebui să existe două Deployment-uri și două Service-uri (frontend și backend).

Pentru a testa comunicația între ele, executăm în interiorul unui pod frontend un curl către backend:

$ kubectl exec -it deploy/webdemo-frontend -- curl -I -s http://webdemo-backend:5000
HTTP/1.1 200 OK
Server: gunicorn
Date: Sat, 01 Nov 2025 11:57:00 GMT
Connection: close
Content-Type: text/html; charset=utf-8
Content-Length: 3467

Dacă primim mesajul de mai sus, DNS-ul intern funcționează și aplicația este interconectată corect prin Helm.

Vizualizarea șabloanelor generate

Pentru a vedea ce YAML-uri generează chart-ul nostru, putem folosi comanda helm template:

$ helm template webdemo ./webapp | less

Aceasta afișează manifestele Kubernetes completate (combinate cu valorile actuale). Este o metodă foarte bună de debugging și pentru a înțelege exact ce va aplica Helm.

Inspectarea manifestelor instalate

Putem verifica manifestele efectiv aplicate în cluster cu:

$ helm get manifest webdemo

Această comandă este utilă pentru a confirma că șabloanele au fost procesate corect și pentru a vedea configurația curentă fără a accesa direct kubectl.

Actualizare și rollback

Să modificăm numărului de replici ale frontend-ului la 2:

$ helm upgrade webdemo ./webapp --set frontend.replicaCount=2
Release "webdemo" has been upgraded. Happy Helming!
NAME: webdemo
LAST DEPLOYED: Sat Nov  1 11:58:43 2025
NAMESPACE: default
STATUS: deployed
REVISION: 2
TEST SUITE: None

Verificăm:

$ kubectl get pods -l app=webdemo-frontend
NAME                                READY   STATUS    RESTARTS   AGE
webdemo-frontend-6d8998b646-cv68b   1/1     Running   0          31s
webdemo-frontend-6d8998b646-ksmqz   1/1     Running   0          4m26s

Apar acum două poduri frontend. Dacă dorim să revenim la versiunea anterioară, folosim rollback:

$ helm rollback webdemo 1
Rollback was a success! Happy Helming!

Astfel, am văzut în această secțiune um un chart Helm poate gestiona mai multe componente (multi-pod / microservicii) într-o aplicație coerentă, păstrând logica de configurare și versiuni într-un singur loc.

Conceptul se extinde ușor la aplicații mai complexe, precum un stack web + DB sau servicii dependente (Redis, API gateway, etc.).