Sari la conținutul principal

Resurse și security context

Requests și limits​

Scheduler-ul și runtime-ul au nevoie de informații despre resursele fiecărui container. Deployment-ul API declară:

resources:
  requests:
    cpu: 25m
    memory: 32Mi
  limits:
    cpu: 200m
    memory: 128Mi
  • requests reprezintă resursele folosite de scheduler pentru plasarea Pod-ului
  • limits stabilesc limitele maxime impuse containerului
  • 25m reprezintă 25 millicores, adică 0,025 dintr-un CPU logic.

PostgreSQL are valori separate, deoarece profilul său de consum este diferit.

Inspectați configurația efectivă:

kubectl describe pod -n cc-lab3 -l app=ticketing-api
kubectl describe pod postgres-0 -n cc-lab3

Security context pentru API​

Imaginea API este distroless și rulează cu UID/GID numeric 65532:

USER 65532:65532

Manifestul confirmă explicit aceleași valori:

securityContext:
  runAsNonRoot: true
  runAsUser: 65532
  runAsGroup: 65532
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop:
      - ALL

Aceste setări:

  • împiedică rularea API-ului ca root
  • elimină posibilitatea de privilege escalation
  • fac sistemul de fișiere al imaginii read-only
  • elimină capabilitățile Linux care nu sunt necesare aplicației.

La nivel de Pod folosim și profilul seccomp implicit al runtime-ului:

securityContext:
  seccompProfile:
    type: RuntimeDefault

De ce PostgreSQL nu are exact același context​

Containerul PostgreSQL trebuie să inițializeze și să scrie în directorul de date. Aplicarea mecanică a readOnlyRootFilesystem sau a unui UID nepotrivit poate împiedica inițializarea imaginii oficiale.

În laborator păstrăm pentru PostgreSQL un context compatibil cu imaginea și aplicăm restricțiile mai agresive serviciului pe care îl controlăm direct. Politicile de securitate trebuie testate pentru fiecare imagine, nu doar copiate între componente.

Diagnosticarea unei erori de configurare

Dacă un Pod rămâne în CreateContainerConfigError, consultați evenimentele:

kubectl describe pod <nume-pod> -n cc-lab3
kubectl get events -n cc-lab3 --sort-by=.metadata.creationTimestamp