Laboratorul 2 - Kubernetes

În Laboratorul 1 am construit și am rulat aplicația Ticketing API în containere. În acest laborator mutăm aceeași aplicație într-un cluster Kubernetes și urmărim modul în care Kubernetes menține automat starea declarată.

Vom lucra cu repository-ul Cloud-Computing-UPB/lab2, care conține aplicația și toate manifestele folosite în exerciții.

Obiective

La finalul laboratorului veți putea:

• să creați un cluster Kubernetes local cu kind
• să identificați rolul obiectelor Pod, ReplicaSet, Deployment, Service și ConfigMap
• să aplicați configurații declarative cu kubectl apply
• să expuneți Ticketing API printr-un Service
• să observați reconcilierea, self-healing-ul și scalarea
• să realizați un rolling update și un rollback
• să diagnosticați o imagine inexistentă și un selector configurat greșit.

În acest laborator aplicația folosește stocarea în memorie. PostgreSQL, volumele și persistența vor fi introduse în Laboratorul 3.

📄️ Pregătirea mediului

Pentru acest laborator sunt necesare următoarele instrumente:

📄️ Arhitectura și reconcilierea

Kubernetes este un orchestrator de containere. Utilizatorul declară starea dorită, iar controllerele Kubernetes compară permanent această stare cu starea observată și încearcă să elimine diferențele.

📄️ Crearea clusterului kind

kind rulează nodurile Kubernetes sub forma unor containere Docker. Pentru laborator folosim un control plane și două noduri worker.

📄️ Obiectele folosite în laborator

În Kubernetes, o aplicație este descrisă prin mai multe obiecte care au responsabilități diferite.

📄️ Primul Pod

Înainte de a folosi un Deployment, vom porni un singur Pod pentru a observa limitele gestionării directe.

📄️ Manifestele declarative

Resursele Kubernetes pot fi create prin comenzi imperative sau prin manifestele YAML declarative. Pentru configurații reproductibile folosim manifestele din repository.

📄️ Configurarea aplicației

Configurația unei aplicații nu ar trebui inclusă direct în imaginea containerului. Kubernetes oferă două obiecte principale:

📄️ Deployment-ul Ticketing API

Deployment-ul descrie starea dorită a aplicației: imaginea, numărul de replici, configurația, probele și strategia de actualizare.

📄️ Service și accesul la aplicație

Pod-urile sunt efemere, iar adresele lor IP se pot schimba. Un Service oferă un endpoint stabil și direcționează traficul către Pod-urile care îi corespund.

📄️ Labels și selectors

Un label este o pereche cheie–valoare atașată unui obiect Kubernetes. Selectors folosesc aceste labels pentru a identifica un set de obiecte.

📄️ Reconciliere, self-healing și scalare

ReplicaSet-ul creat de Deployment menține numărul declarat de Pod-uri. Nu îl vom modifica direct, ci vom modifica Deployment-ul.

📄️ Rolling update

Un Deployment poate actualiza gradual template-ul Pod-urilor. Fișierul k8s/scenarios/deployment-v2.yaml schimbă:

📄️ Erori, rollback și curățare

În ultima parte a laboratorului introducem două erori controlate și folosim informațiile oferite de Kubernetes pentru a le diagnostica.