Obiectul Pod în Kubernetes: sintaxă, opțiuni și exemple

Ce face `Obiectul Pod`

În Kubernetes nu rulezi containere direct, ci Pod-uri. Un Pod este un „înveliș” în jurul unuia sau mai multor containere strâns legate între ele: toate containerele din același Pod împart aceeași adresă IP și aceleași porturi (comunică între ele pe localhost) și pot monta aceleași volume de stocare.

În 95% din cazuri un Pod conține un singur container ( cel al aplicației). Când are mai multe, cele suplimentare sunt fie initContainers (rulează secvențial înainte de pornirea aplicației, de exemplu pentru a aștepta baza de date sau a aplica migrații), fie containere sidecar (agent de loguri, proxy Envoy, exporter de metrici).

În producție nu creezi Pod-uri izolate („goale”): dacă nodul pe care stă un Pod izolat cade, Pod-ul nu este recreat pe alt nod. În schimb, creezi un Deployment, un StatefulSet sau un Job, care gestionează Pod-urile pentru tine. Totuși, șablonul spec din exemplu se regăsește identic în interiorul fiecărui Deployment (spec.template.spec), iar cu kubectl run poți porni rapid un Pod de test.

Opțiuni și argumente

Opțiune / Parametru	Descriere
`spec.containers[]`	Lista containerelor principale: `name`, `image`, `command`, `args`, `ports`, `env`, `resources`.
`spec.initContainers[]`	Containere care rulează până la finalizare (cod `0`) înainte ca vreun container principal să pornească.
`resources.requests / limits`	`requests`: cât CPU/memorie îi garantează schedulerul pe nod; `limits`: pragul maxim (la depășirea memoriei containerul primește `OOMKilled`).
`readinessProbe / livenessProbe / startupProbe`	Verificări HTTP, TCP sau exec: `readiness` decide când Pod-ul primește trafic din Service, `liveness` îl repornește dacă s-a blocat.
`spec.restartPolicy`	`Always` (implicit), `OnFailure` sau `Never` (folosite la Job-uri și pod-uri de test).
`kubectl run NUME --image=IMG`	Creează rapid un Pod din linia de comandă; cu `--rm -it --restart=Never` îl șterge automat când ieși din shell.

Exemple

Exemplul 1: Manifest YAML complet al unui Pod cu resurse și probe de sănătate

Se aplică cu kubectl apply -f pod.yaml. Aceeași structură spec se folosește și în spec.template.spec la un Deployment.

apiVersion: v1
kind: Pod
metadata:
  name: api-demo
  namespace: shop
  labels:
    app: api
spec:
  containers:
    - name: api
      image: ghcr.io/exemplu/api:1.4.2
      ports:
        - name: http
          containerPort: 8080
      env:
        - name: PORT
          value: "8080"
      resources:
        requests:
          cpu: 100m
          memory: 128Mi
        limits:
          cpu: 500m
          memory: 256Mi
      readinessProbe:
        httpGet:
          path: /healthz
          port: http
        initialDelaySeconds: 3
        periodSeconds: 5
      livenessProbe:
        httpGet:
          path: /livez
          port: http
        initialDelaySeconds: 10
        periodSeconds: 10

Ieșire în terminal

pod/api-demo created

Exemplul 2: Pornirea unui Pod temporar de test care se șterge singur la ieșire

Ideal pentru a testa DNS-ul intern sau un endpoint HTTP din interiorul clusterului.

kubectl run test-curl --rm -it --restart=Never --image=curlimages/curl:8.10.1 -- curl -sI http://api.shop.svc.cluster.local/healthz