Skip to main content

Instalarea unui chart Helm

Având chart-ul pregătit, următorul pas este instalarea lui pe clusterul Kubernetes. Comanda generală pentru a instala un chart este helm install <nume_release> <cale_chart> [opțiuni]. Putem alege un nume pentru release-ul nostru sau lăsa Helm să genereze unul aleator (prin --generate-name); de obicei este preferabil să specificăm un nume ușor de recunoscut. Vom instala chart-ul mychart pe clusterul Kind sub un release numit example-release`**:

$ helm install example-release ./mychart
NAME: example-release
LAST DEPLOYED: Sat Nov  1 11:40:49 2025
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app.kubernetes.io/name=mychart,app.kubernetes.io/instance=example-release" -o jsonpath="{.items[0].metadata.name}")
  export CONTAINER_PORT=$(kubectl get pod --namespace default $POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl --namespace default port-forward $POD_NAME 8080:$CONTAINER_PORT

Să analizăm pe rând rezultatul comenzii:

  • Helm ne confirmă că a creat un release nou numit example-release în namespace-ul Kubernetes default. Statusul este deployed (chart-ul a fost aplicat cu succes) și avem REVISION: 1 (fiind prima instalare).
  • Secțiunea NOTES este preluată din fișierul templates/NOTES.txt al chart-ului și conține instrucțiuni utile. În cazul nostru, notițele sugerează modul de a accesa aplicația Nginx instalată, prin obținerea numelui pod-ului și portului, apoi executând un port-forward de la localul nostru către acel pod (vom reveni imediat la acest pas).

După instalare, Helm a generat și trimis către Kubernetes toate obiectele definite de șabloanele chart-ului, folosind valorile implicite. Putem verifica direct în cluster resursele create. De exemplu, listăm toate pod-urile, deployment-urile și serviciile din namespace-ul default:

$ kubectl get deployment,pods,svc
NAME                                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/example-release-mychart   1/1     1            1           29s

NAME                                           READY   STATUS    RESTARTS   AGE
pod/example-release-mychart-6f57d7b79c-bgzk7   1/1     Running   0          29s

NAME                              TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
service/example-release-mychart   ClusterIP   10.96.69.93   <none>        80/TCP    29s
service/kubernetes                ClusterIP   10.96.0.1     <none>        443/TCP   4m57s

Observăm că Helm a creat un Deployment numit example-release-mychart (numele combină numele release-ului cu numele chart-ului, asigurând unicitate), un Pod care aparține deployment-ului (numele pod-ului începe cu example-release-mychart urmat de un sufix generat) și un Service numit example-release-mychart de tip ClusterIP pe portul 80. Pod-ul are starea Running, ceea ce indică lansarea cu succes a containerului Nginx în clusterul Kind.

Sfat

În general, dacă helm install eșuează, puteți inspecta cauza erorii citind mesajele de eroare afișate. Erori comune pot fi: clusterul Kubernetes nu este accesibil (de exemplu Docker nu rulează sau contextul kubectl nu e setat corect), sau deja există un release cu același nume (Helm nu permite două release-uri cu același nume în același namespace). Dacă întâmpinați eroarea "cannot re-use a name that is still in use", probabil ați folosit deja numele respectiv, așa că alegeți alt nume pentru release sau dezinstalați release-ul existent.

După instalare, aplicația Nginx rulează în clusterul Kubernetes, însă, fiind un service de tip ClusterIP, acesta este accesibil doar din interiorul clusterului (nu are o adresă externă implicită). În mediul local Kind, neavând un load balancer sau un ingress controller configurat, cea mai simplă metodă de a accesa aplicația web din exterior (de pe mașina noastră) este să folosim port forwarding.

Instrucțiunile din secțiunea NOTES ne arată exact pașii: putem prelua numele pod-ului și apoi rula kubectl port-forward către acel pod pe portul 80. Pentru simplitate, putem face port-forward direct către serviciu (Kubernetes va redirecționa traficul către pod-uri). Vom expune portul 80 al serviciului Nginx pe un port local 8080. Deschideți un nou terminal (sau rulați comanda în background) și executați:

$ kubectl port-forward svc/example-release-mychart 8080:80
Forwarding from 127.0.0.1:8080 -> 80
Forwarding from [::1]:8080 -> 80

Comanda de mai sus redirecționează traficul de la http://127.0.0.1:8080 pe mașina proprie către portul 80 al serviciului example-release-mychart din cluster (care, la rândul lui, trimite către pod-ul Nginx). Practic, atâta timp cât kubectl port-forward rulează, putem accesa în browser sau cu curl adresa http://localhost:8080 și vom ajunge la serverul Nginx din cluster.

Să verificăm, folosind curl, că primim răspuns de la serverul Nginx din cluster:

$ curl -I http://127.0.0.1:8080
HTTP/1.1 200 OK
Server: nginx/1.16.0
Date: Sat, 01 Nov 2025 09:44:38 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Tue, 23 Apr 2019 10:18:21 GMT
Connection: keep-alive
ETag: "5cbee66d-264"
Accept-Ranges: bytes

Am folosit opțiunea -I (head) pentru a vedea doar anteturile răspunsului. Observăm codul 200 OK și serverul nginx/1.16.0, ceea ce confirmă că solicitarea noastră a ajuns la instanța Nginx din cluster. Dacă deschidem într-un browser adresa http://localhost:8080, vom vedea pagina implicită "Welcome to nginx!" servită de container.

Notă

Fără a realiza un port-forward (sau alt mecanism de expunere), conexiunile către aplicație din afara clusterului nu vor funcționa. De exemplu, dacă am fi încercat anterior curl http://localhost:80 (fără să facem port-forward), am fi primit o eroare de conexiune refuzată. Acest lucru se întâmplă deoarece, în Kind, serviciile de tip ClusterIP nu sunt accesibile direct din exterior, iar serviciile de tip LoadBalancer nu sunt disponibile (nu există un cloud provider care să aloce automat un IP extern). În medii locale de testare, kubectl port-forward este adesea soluția cea mai la îndemână pentru a accesa serviciile din cluster. O alternativă este schimbarea tipului serviciului la NodePort, însă, în contextul Kind, chiar și NodePort necesită cunoașterea adresei containerului nod sau configurarea unui mapping de port Docker. Astfel, port-forward rămâne metoda cea mai simplă.

După ce am confirmat funcționarea aplicației implicite, putem opri comanda de port-forward (cu Ctrl+C în terminalul respectiv).