Învață Kubernetes: comenzi kubectl și obiecte explicate cu exemple

# Arhitectura Kubernetes este strict decuplată în două mari subsisteme:

# ═══════════════════════════════════════════════════════════════════════════════
# 1. CONTROL PLANE (Creierul și Centrul Decizional al Clusterului):
# ═══════════════════════════════════════════════════════════════════════════════
# - kube-apiserver:
#   * Singura componentă care expune API-ul REST securizat (HTTPS) pe portul 6443.
#   * Toate celelalte componente (inclusiv kubectl și nodurile) comunică EXCLUSIV cu API Server.
#   * Responsabil de autentificare (mTLS/OIDC), autorizare (RBAC) și validare de scheme.
# - etcd:
#   * Baza de date distribuită de tip cheie-valoare de înaltă consistență (algoritm Raft).
#   * Păstrează întregul „adevăr” despre starea clusterului. Doar API Server are acces direct la etcd!
# - kube-scheduler:
#   * Monitorizează Pod-urile nou create care nu au încă un nod asignat.
#   * Filtrează și punctează nodurile disponibile pe baza resurselor libere (CPU/RAM),
#     afinităților, taints/tolerations și constrângerilor de topologie.
# - kube-controller-manager:
#   * Un binar compus din zeci de bucle de control (Node Controller, Deployment Controller,
#     EndpointSlice Controller, ServiceAccount Controller).
# - cloud-controller-manager:
#   * Integrează clusterul cu API-ul providerului cloud (AWS, GCP, Hetzner) pentru a comanda
#     Load Balancere externe și volume persistente de rețea.

# ═══════════════════════════════════════════════════════════════════════════════
# 2. WORKER NODES (Mașinile de Execuție unde Rulează Aplicațiile):
# ═══════════════════════════════════════════════════════════════════════════════
# - kubelet:
#   * Agentul primar ce rulează pe fiecare nod. Citește specificația PodSpecs de la API Server
#     și instruiește Container Runtime-ul să descarce imaginile și să pornească procesele.
#   * Monitorizează sănătatea containerelor și raportează starea înapoi la Control Plane.
# - kube-proxy:
#   * Gestionează rutarea rețelei virtuale pe fiecare nod (folosind iptables sau IPVS).
#   * Asigură că traficul trimis către un Service ClusterIP este distribuit corect către Pod-uri.
# - Container Runtime (CRI):
#   * Motorul OCI de nivel jos (standardul actual fiind containerd sau CRI-O).

spec:
  containers:
    - name: api-service
      image: my-company/api:v2.0
      ports:
        - containerPort: 8080
      
      # 1. STARTUP PROBE (Pentru aplicații lente la inițializare):
      # Blochează celelalte sonde până când aplicația pornește complet (evită repornirea prematură):
      startupProbe:
        httpGet:
          path: /healthz
          port: 8080
        failureThreshold: 30
        periodSeconds: 10 # Oferă până la 300 de secunde pentru încărcarea datelor la pornire

      # 2. LIVENESS PROBE (Detectează blocajele de execuție / Deadlocks):
      # Dacă această sondă eșuează, kubelet OMOARĂ containerul și îl repornește automat:
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 15
        failureThreshold: 3

      # 3. READINESS PROBE (Controlează rutarea traficului utilizatorilor):
      # Dacă această sondă eșuează, Pod-ul este scos INSTANT din Endpoint-urile Serviciului
      # (nu mai primește trafic de la clienți până când nu redevine sănătos!):
      readinessProbe:
        httpGet:
          path: /ready
          port: 8080
        periodSeconds: 5
        failureThreshold: 2