Sesiunea 1
Deploy AKS în Azure Portal
De la 0 la hero — ghid complet AKS Standard
Ghid complet, de la 0 la hero — actualizat pe baza documentației Microsoft Learn disponibile până în martie 2026. Acest webinar îți explică nu doar ce să apeși, ci și de ce alegi fiecare opțiune.
Agenda
Parcurgem împreună toate etapele esențiale
De ce AKS?
Comparație cu alte servicii Azure și cazuri de utilizare reale.
Arhitectura laboratorului
Resource Group, VNet, subnet și planul IP recomandat.
Creare cluster pas cu pas
Toate filele din Azure Portal explicate: Basics, Node pools, Networking, Integrations, Monitoring, Advanced.
Autoscaling, Monitoring, Backup
Mecanismele de scalare, observabilitate și protecție a datelor.
AKS Standard vs. Automatic
Când alegi fiecare variantă și exerciții recomandate.
Capitol 1
De ce AKS și nu alt serviciu?
Gândește-te la opțiunile de hosting ca la patru moduri de a călători. Fiecare are locul lui — cheia este să alegi corect în funcție de nevoile aplicației tale.
Mașini Virtuale
Tu administrezi aproape tot: OS, patching, runtime, orchestrare. Bun pentru control total, dar cere multă muncă manuală.
Azure App Service
Excelent pentru aplicații web clasice. Platforma ascunde serverele, dar flexibilitatea pentru containere complexe este mai mică.
Azure Container Apps
Foarte bun pentru microservicii și API-uri containerizate fără să administrezi Kubernetes. Ideal când vrei simplitate și scale rapid.
Azure Kubernetes Service
Alegi AKS când ai nevoie de orchestrare Kubernetes completă, mai multe servicii, politici, rețea avansată, observabilitate și control enterprise.
Când alegi AKS — și când NU
Alege AKS când...
Ai mai multe microservicii, API-uri, workers sau joburi batch care trebuie coordonate. Ai nevoie de Kubernetes real, politici enterprise, control fin pe networking, identity, scaling și observabilitate. Ai echipe DevOps/Platform Engineering care pot valorifica flexibilitatea.
NU alege AKS când...
Pentru o aplicație web simplă — App Service este mai simplu. Pentru containere stateless cu administrare minimă — Azure Container Apps. Dacă echipa nu are maturitate operațională pe Kubernetes, AKS poate aduce complexitate inutilă.
De ce AKS Standard în acest curs? Microsoft oferă și AKS Automatic, dar pentru un curs zero-to-hero vrem să înțelegem mecanica din spate: rețea, node pools, autoscaling, monitoring și opțiuni de securitate.
Ghid rapid: ce serviciu pentru ce scenariu
| Scenariu | Serviciu recomandat | De ce |
|---|---|---|
| Website sau API simplu | Azure App Service | Mai puține decizii operaționale și administrare minimă. |
| Microservicii simple, event-driven, fără Kubernetes | Azure Container Apps | Scale ușor și ascunde o bună parte din complexitatea infrastructurii. |
| Aplicație legacy cu acces complet la OS | Virtual Machines | Control total asupra sistemului și middleware-ului. |
| Platformă modernă multi-serviciu, cu nevoi enterprise | AKS | Orchestrare Kubernetes completă și control avansat. |
Capitol 2
Arhitectura pe care o vom construi
Model recomandat pentru un laborator educațional și bun punct de plecare pentru producție.
Resource Group
rg-aks-lab-weu-01 — Un Resource Group dedicat păstrează toate resursele împreună și permite ștergerea ușoară a laboratorului.
VNet + Subnet
vnet-aks-lab-weu-01 (10.20.0.0/16) cu subnet dedicat nodurilor AKS snet-aks-nodes (10.20.0.0/23).
Cluster AKS
Control plane administrat de Azure + System node pool (kube-system) + User node pool (App pods, API pods, Jobs).
Observabilitate
Integrare cu Azure Monitor: Container Insights, Managed Prometheus, Grafana și loguri control plane.
Backup
Opțiune de backup prin Azure Backup și Backup Vault pentru resurse cluster și volume persistente.
Ingress / Load Balancer
Standard Load Balancer pentru expunerea serviciilor și endpointurilor aplicațiilor.
Ce trebuie să ai înainte să începi
Abonament Azure activ
Permisiuni suficiente pentru a crea Resource Groups, rețele, AKS și resurse de monitorizare.
Regiune aleasă
Pentru exemple vom folosi West Europe, dar poți adapta la orice regiune disponibilă.
Convenție de naming
Exemplu: rg-aks-lab-weu-01, vnet-aks-lab-weu-01, aks-lab-weu-01.
Claritate asupra scopului
Laborator educațional, nu cluster de producție critică.
Acces la terminal
Azure Cloud Shell sau terminal local cu az CLI și kubectl, pentru verificările post-deploy.
Documentația Microsoft precizează că ghidul rapid din portal este pentru evaluare și că pentru producție trebuie raportat la arhitectura de referință AKS. În acest material facem un pas mai departe și explicăm nu doar ce să apeși, ci și de ce alegem fiecare opțiune.
Capitol 3
Planificarea rețelei: de ce contează înainte de AKS
Una dintre cele mai frecvente greșeli în AKS apare înainte de a crea clusterul: planificarea slabă a rețelei. AKS are nevoie de un plan IP suficient pentru noduri, poduri, servicii și operațiuni de upgrade.
VNet 10.20.0.0/16
Un /16 este generos și prietenos pentru cursuri și medii de test. Spațiu să experimentezi și să adaugi ulterior subnets pentru ingress, private endpoints, jumpbox sau alte laboratoare.
Subnet noduri 10.20.0.0/23
Un /23 oferă echilibru bun între simplitate și spațiu de manevră: suficient pentru laborator, upgrade surge, node pools suplimentare. Mai sănătos decât un /27 sau /28 care produce rapid blocaje.
Service CIDR 10.30.0.0/16
Trebuie să nu se suprapună cu VNet sau alte rețele conectate. DNS service IP: 10.30.0.10 — o adresă din Service CIDR pentru kube-dns / CoreDNS.
Pod CIDR Overlay 192.168.0.0/16
Cu Azure CNI Overlay, doar nodurile iau IP-uri din subnet, iar podurile folosesc acest CIDR overlay separat. Fiecare nod primește un /24 din spațiul overlay.
Formula de sizing și alegerea networking mode
Subnetul trebuie să fie suficient de mare pentru noduri, poduri și resursele Kubernetes, iar în calcul trebuie să intre și noduri suplimentare pentru upgrade. Formula orientativă: (noduri + max surge) + ((noduri + max surge) × max pods/nod).
Chiar dacă recomandăm Azure CNI Overlay, această formulă te învață un principiu important: în Kubernetes nu planifici doar pentru ziua 1, ci și pentru scaling și upgrade.
De ce recomandăm Azure CNI Overlay
| Opțiune | Ce înseamnă | Când are sens |
|---|---|---|
| Azure CNI Overlay | Nodurile iau IP-uri din subnet; podurile dintr-un CIDR overlay separat. | Alegerea recomandată pentru curs și multe deploymenturi moderne. |
| Azure CNI Node Subnet | Atât nodurile, cât și designul rețelei sunt mai strâns legate de VNet. | Când ai cerințe specifice de adresare și integrare directă în rețeaua Azure. |
| Kubenet / modele mai vechi | Mai puțin recomandate pentru design nou în 2026. | Doar în contexte moștenite sau foarte specifice. |
Lab — Pasul 1
Creează Resource Group-ul
Navighează în portal
Intră în portal.azure.com și caută Resource groups.
Selectează Create
Apasă butonul Create pentru a începe configurarea.
Completează detaliile
Alege Subscription-ul corect. La Resource group name folosește: rg-aks-lab-weu-01.
Alege regiunea
La Region alege aceeași regiune în care vei crea clusterul, de exemplu West Europe.
Finalizează
Apasă Review + create, apoi Create.
Un Resource Group dedicat îți oferă: ordine (toate resursele într-un singur loc), cost tracking simplu, și ștergere ușoară — la finalul cursului ștergi tot și nu rămân resurse orfane.
Lab — Pasul 2
Creează VNet-ul și subnetul
Navighează la Virtual networks
În portal caută Virtual networks și selectează Create.
Configurează de bază
Subscription: același abonament ca pentru Resource Group. Resource group: rg-aks-lab-weu-01. Name: vnet-aks-lab-weu-01. Region: aceeași regiune ca AKS.
Setează spațiul de adrese
IPv4 address space: 10.20.0.0/16.
Adaugă subnetul
Adaugă un subnet nou: snet-aks-nodes cu prefix 10.20.0.0/23.
Finalizează
Apasă Review + create și apoi Create.
Nu complica laboratorul cu multe subnets din prima. Un subnet bine ales pentru noduri este suficient pentru început. Subnets suplimentare se adaugă când introduci cerințe noi: private endpoints, firewall, ingress dedicat sau integrare hibridă.
Lab — Pasul 3
Creează clusterul AKS
Înainte să creezi clusterul, este important să înțelegi ce te așteaptă în fiecare filă din Azure Portal. Ordinea exactă poate varia ușor în funcție de preview-uri active, dar logica rămâne aceeași.
Harta portalului: fluxul de creare AKS
Basics
Subscription, RG, nume, regiune, versiune K8s, identitate, pricing tier.
Node pools
Pool sistem, mărime VM, autoscaler, min/max, max pods, OS SKU.
Networking
VNet, subnet, Azure CNI Overlay, Service CIDR, DNS IP, access model.
Integrations
Container registry, policy, secrets, alte integrări după nevoie.
Monitoring
Container Insights, Prometheus, Grafana, loguri control plane.
Advanced
Upgrade channel, maintenance, RBAC, private/public access după scenariu.
Review + create
Validare, cost estimat, creare și verificări post-deploy.
Fila Basics — Setări și Identitate
| Setare | Recomandare curs | De ce |
|---|---|---|
| Subscription | Abonamentul de laborator | Separă costurile și permisiunile. |
| Resource group | rg-aks-lab-weu-01 | Păstrezi toate resursele împreună. |
| Cluster preset | Dev/Test | Cost mai mic și complexitate redusă pentru învățare. |
| Kubernetes cluster name | aks-lab-weu-01 | Naming clar și ușor de urmărit. |
| Region | West Europe | Apropiere și consistență cu celelalte resurse. |
| AKS pricing tier | Free (laborator) / Standard (producție) | În laborator reduci costul. În producție alegi Standard. |
| Availability zones | None în laborator | Simplifici lecția. În producție ai discuție separată. |
| Kubernetes version | O versiune suportată, nedefazată | Nu alege o versiune prea veche doar pentru "stabilitate" aparentă. |
Identitate: Preferă Managed Identity (reduce secretele față de service principals) și Azure RBAC pentru Kubernetes (simplifică guvernarea). Nu complica cu acces privat la API server, decât dacă obiectivul lecției este networking avansat.
Fila Node Pools — Configurare
| Setare | Recomandare | De ce |
|---|---|---|
| System node pool | Lasă pool-ul de sistem activ | Clusterul are nevoie de el pentru componentele de bază. |
| User node pool | Adaugă unul separat | Înveți separarea corectă între platformă și aplicație. |
| VM size | D2s_v5 sau echivalent mic, modern | 2 vCPU și memorie decentă pentru teste. |
| OS SKU | Ubuntu Linux sau Azure Linux 3 | Linux este alegerea naturală pentru majoritatea workload-urilor. |
| Node count | 2 noduri (laborator serios) | 2 noduri oferă reziliență minimă și comportament realist. |
| Mode | System pentru principal, User pentru aplicații | Separare operațională sănătoasă. |
| Azure Spot | Nu pentru prima lecție | Util pentru optimizare cost, dar complică prin posibile evacuări. |
Autoscaling pe node pools: Enable autoscaler = On, Min nodes: 2, Max nodes: 5. De ce nu 1-1? Nu înveți nimic despre elasticitate. De ce nu 1-50? Laboratorul trebuie controlat și predictibil.
Fila Networking — Configurare rețea
| Setare | Recomandare | De ce |
|---|---|---|
| Network model | Azure CNI Overlay | Mai simplu pentru planificare IP și foarte potrivit pentru învățare. |
| Virtual network | vnet-aks-lab-weu-01 | Folosim VNet-ul creat intenționat înainte. |
| Subnet | snet-aks-nodes | Separăm clar clusterul de alte resurse. |
| Pod CIDR | 192.168.0.0/16 | Spațiu suficient pentru overlay și ușor de reținut. |
| Service CIDR | 10.30.0.0/16 | Trebuie să nu se suprapună cu VNet sau alte rețele. |
| DNS service IP | 10.30.0.10 | O adresă din Service CIDR pentru kube-dns / CoreDNS. |
| Load balancer | Standard | Alegerea sănătoasă pentru majoritatea scenariilor. |
Greșeală clasică: Service CIDR nu trebuie să se suprapună nici cu subnetul nodurilor, nici cu alte rețele conectate. Verifică de două ori înainte de a apăsa Create!
Integrations, Monitoring și Advanced
Fila Integrations
Fii selectiv. Container Registry: util pentru imagini private. Azure Policy: introduce după ce studentul înțelege bazele. Secret management: explică principiul, apoi implementează Key Vault CSI într-o lecție separată.
Fila Advanced / Security
Auto-upgrade channel: discuție despre patching. Maintenance windows: control când se fac operațiuni automate. Private cluster: important pentru securitate avansată, dar nu obligatoriu în primul laborator.
Fila Monitoring
Container Insights: ✅ On. Managed Prometheus: ✅ On. Azure Managed Grafana: ✅ Recomandat. Control plane logs: ✅ On. Log Analytics Workspace: ✅ Dedicat laboratorului.
Review + Create: lista de verificare finală
Verifică toate filele
Parcurge fiecare filă și confirmă că setările sunt corecte.
Aceeași regiune
Confirmă că regiunea este aceeași pentru RG, VNet și AKS.
Service CIDR fără overlap
Confirmă că Service CIDR nu se suprapune cu VNet sau alte rețele.
Autoscaler sensibil
Confirmă că autoscalerul are min și max sensibile (ex: min 2, max 5).
Rulează validarea
Apasă Validate și rezolvă orice erori înainte de a continua.
Apasă Create
Crearea clusterului poate dura câteva minute. Verifică Overview, Node pools, Networking și Monitoring.
Verificări obligatorii după deploy
Nu închide lecția imediat după "deployment succeeded". Un cluster sănătos trebuie verificat operațional.
Verificări în Azure Portal
AKS → Overview: stare Running. Node pools: pool-urile Ready. Networking: VNet, subnet și CIDR-urile corecte. Monitoring: integrarea pornită corect.
Verificări cu kubectl
az aks get-credentials --resource-group rg-aks-lab-weu-01 --name aks-lab-weu-01 → kubectl get nodes (noduri Ready) → kubectl get pods -A (poduri sistem).
Capitol 4
Autoscaling în AKS: toate mecanismele
Autoscaling în AKS nu înseamnă un singur mecanism, ci mai multe mecanisme care operează la niveluri diferite. Cheia este să înțelegi întrebarea la care răspunde fiecare opțiune.
| Mecanism | La ce răspunde | Unde îl folosești |
|---|---|---|
| Cluster Autoscaler | Avem suficiente noduri? | La nivel de node pool. |
| Horizontal Pod Autoscaler (HPA) | Avem suficiente replici de poduri? | La nivel de Deployment/ReplicaSet. |
| Vertical Pod Autoscaler (VPA) | Fiecare pod are request/limit potrivit? | La nivel de resurse CPU/memory per workload. |
| KEDA | Trebuie să scalăm după evenimente? | Queue-uri, mesaje, workload-uri event-driven. |
| Node Auto-Provisioning (NAP) | Ce tip de noduri ar trebui create automat? | Scenarii moderne, cu Karpenter și optimizare dinamică. |
Mecanismele în detaliu
Cluster Autoscaler
Primul mecanism activat. Urmărește podurile care nu pot fi programate și decide dacă trebuie adăugate noduri. Poate reduce nodurile neutilizate. Se configurează per node pool cu min/max.
Horizontal Pod Autoscaler (HPA)
Răspunde la câte replici de aplicație ai, nu câte noduri. Dacă CPU, memorie sau alte metrice cresc, HPA mărește podurile. Lucrează excelent cu Cluster Autoscaler.
Vertical Pod Autoscaler (VPA)
Ajustează request/limit de CPU și memorie pe baza utilizării istorice. Util când echipa nu a dimensionat bine workload-urile.
KEDA
Autoscaling event-driven. Ca un ospătar care nu se uită doar câți clienți sunt la masă, ci câți oameni stau la coadă la intrare. Extraordinar pentru queue-uri și topicuri.
Capitol 5
Monitoring în AKS: straturile de observabilitate
O companie matură nu consideră clusterul "gata" doar pentru că rulează. Un cluster bun este un cluster observabil. În AKS, observabilitatea vine din mai multe surse.
Platform Metrics
Metricile de bază ale resursei Azure. Se colectează automat. Excelente pentru alerte rapide și o primă vedere asupra sănătății.
Container Insights
Ce se întâmplă în cluster: noduri, poduri, containere, evenimente. Studentul vede imediat legătura dintre obiectele Kubernetes și resursele care consumă CPU/memorie.
Managed Prometheus
Experiență administrată pentru metrici Prometheus. În lumea Kubernetes, Prometheus este limbajul nativ al metricilor.
Azure Managed Grafana
Partea vizuală care ajută să înțelegi rapid starea clusterului. Foarte utilă pentru dashboard-uri și demo-uri.
Control Plane Logs
Când apar probleme reale, logurile control plane fac diferența dintre presupuneri și diagnostic serios. Recomandate în orice mediu.
Capitol 6
Backup în AKS: protecția datelor fără mituri
Backup-ul în AKS trebuie explicat fără mituri. Kubernetes nu înseamnă doar YAML; în multe aplicații ai și volume persistente care trebuie protejate. Azure Backup pentru AKS folosește o extensie în cluster și lucrează cu un Backup Vault.
Tier-uri de backup
| Tier | Ce înseamnă | Când îl alegi |
|---|---|---|
| Operational Tier | Snapshot-uri operaționale pentru recovery rapid. | Backup operațional pe termen scurt. |
| Vault Tier | Stocare pe termen lung în Backup Vault. | Retenție mai lungă și reziliență mai puternică pentru Azure Disk. |
Pentru Azure Files, retenția este limitată și Vault Tier nu este suportat la fel ca pentru Azure Disk.
Pași în portal
Creează un Backup Vault
Configurează redundanța și, dacă ai nevoie, Cross Region Restore.
Creează o Backup Policy
Pentru Kubernetes Services, cu politicile de retenție dorite.
Instalează Backup Extension
Intră în AKS → Settings → Backup. Indică storage account și blob container.
Configurează și validează
Selectează vault-ul, policy-ul, resursele de protejat, snapshot resource group și validează rolurile.
Capitol 7
AKS Standard versus AKS Automatic
AKS Automatic automatizează și mai mult setările și operațiunile clusterului. Merită menționat în 2026 deoarece face parte clar din peisajul actual AKS.
AKS Standard
Mai mult control explicit. Excelent pentru înțelegerea mecanicii interne. Node management prin node pools definite de tine. Predai primul într-un curs zero-to-hero. Ideal pentru studenți care vor profunzime.
AKS Automatic
Mai multă automatizare și guardrails implicite. Mai puțin pentru mecanica internă, mai mult pentru experiență accelerată. Node management mai automatizat, inclusiv cu Node Autoprovisioning. Ideal pentru echipe care vor producție rapidă cu overhead minim.
Configurația recomandată de curs, pe scurt
| Componentă | Valoare recomandată |
|---|---|
| Resource Group | rg-aks-lab-weu-01 |
| VNet | 10.20.0.0/16 |
| Subnet noduri | 10.20.0.0/23 |
| AKS mode | AKS Standard |
| Network mode | Azure CNI Overlay |
| Pod CIDR | 192.168.0.0/16 |
| Service CIDR | 10.30.0.0/16 |
| DNS service IP | 10.30.0.10 |
| System node pool | 2 x D2s_v5 sau echivalent mic și modern |
| Autoscaler | On, min 2, max 5 |
| Monitoring | Container Insights + Managed Prometheus + control plane logs |
| Grafana | Opțional, dar recomandat pentru demo |
| Backup | Explicat complet; activat după nevoie și buget |
Greșeli frecvente pe care merită să le eviți
Subnet prea mic
Pare suficient în ziua 1, dar explodează la primul upgrade sau scale-out. Alege /23 sau mai mare, nu /27 sau /28.
CIDR-uri care se suprapun
Service CIDR, Pod CIDR și VNet trebuie să fie complet separate. O suprapunere produce erori greu de diagnosticat.
Prea multe opțiuni activate fără înțelegere
Activarea tuturor integrărilor fără să înțelegi ce fac și ce cost au duce la facturi surpriză și configurații fragile.
Fără separare system / user workloads
Lipsa separării dintre system și user node pools creează instabilitate și face troubleshooting-ul mult mai dificil.
Fără monitorizare
Un cluster fără observabilitate este un cluster pe care nu îl poți opera serios.
Confuzia între scaling de noduri și poduri
Cluster Autoscaler ≠ HPA. Înțelege întrebarea la care răspunde fiecare mecanism înainte de a-l activa.
Exerciții recomandate pentru studenți
Practică este esențială. Aceste exerciții consolidează conceptele din webinar.
kubectl de bază
Conectează-te cu kubectl și listează nodurile și podurile de sistem. Verifică starea fiecărei componente.
Primul deployment
Adaugă un deployment simplu cu 2 replici și observă-l în Container Insights. Urmărește metricile în timp real.
HPA + Cluster Autoscaler
Creează un HPA și observă relația dintre HPA și cluster autoscaler. Generează load și urmărește comportamentul.
Al doilea user node pool
Adaugă un al doilea user node pool și mută workload-ul prin nodeSelector sau taints/tolerations.
Cost-conscious design
Simulează un design orientat pe cost și explică de ce Spot nu a fost activat în lecția de bază.
Schema IP
Desenează schema IP a clusterului și explică de ce Service CIDR nu trebuie să se suprapună cu VNet.
Concluzie: de la zero la hero
AKS merită ales atunci când compania are nevoie de orchestrare Kubernetes reală, control operațional și flexibilitate enterprise. Pentru un student, cheia nu este doar să știe să apese Create, ci să înțeleagă de ce a ales acel subnet, acel network mode, acel autoscaler și acel model de monitoring.
Dacă elevul înțelege aceste decizii, atunci a trecut cu adevărat de la zero la hero.
Arhitectură solidă
Resource Group dedicat, VNet /16, subnet /23, Azure CNI Overlay — fundamente clare pentru orice scenariu.
Configurare înțeleasă
Fiecare setare din portal are o justificare. Nu apeși butoane — iei decizii arhitecturale.
Cluster observabil
Container Insights, Managed Prometheus, Grafana și control plane logs — vizibilitate completă.
Pregătit pentru producție
Principiile din acest laborator sunt direct aplicabile în medii enterprise reale.
Surse Microsoft Learn
Acest material a fost actualizat pe baza documentației Microsoft Learn disponibile până în martie 2026.