Kubernetes API, kubectl і життєвий цикл об’єктів

Після модуля ви зможете читати Kubernetes API як контракт, обирати підтримувану версію ресурсу, розрізняти spec і status, безпечно застосовувати маніфести та діагностувати невдалий rollout за станом об’єктів.

• Discovery замість вгадування apiVersion
• структуроване читання об’єктів
• server-side validation до зміни кластера
• Server-Side Apply і володіння полями

kubectl, контролери, scheduler, kubelet та оператори працюють з API Server. Тип ресурсу задають API group, version і kind; екземпляр додатково визначають namespace та name.

spec описує бажаний стан, status публікують контролери. metadata.generation змінюється разом зі spec, а status.observedGeneration показує вже оброблену контролером ревізію.

kubectl api-resources
kubectl api-versions
kubectl explain deployment.spec.strategy
kubectl get --raw /api
kubectl get --raw /apis

Не вгадуйте apiVersion з пам’яті: Discovery API показує ресурси конкретного кластера. Перед upgrade перевіряйте deprecation guide та видалені API цільової версії.

• core-група записується як v1
• alpha API може зникнути без періоду сумісності
• beta API має обмежені гарантії
• GA API надає найсуворіші гарантії сумісності

metadata ідентифікує об’єкт, spec задає намір, status відображає результат. Selector пов’язує Deployment з Pods, після створення є незмінним і має збігатися з template labels.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: lab-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.28-alpine
          ports:
            - name: http
              containerPort: 80

Server-Side Apply записує managedFields і виявляє конфлікти власників. field-manager має стабільно ідентифікувати автоматизацію. У production маніфест зберігається в Git; kubectl edit та несистемний patch створюють drift.

kubectl apply --server-side --field-manager=course-lab -f deployment.yaml
kubectl get deploy web -n lab-api -o json | jq '.metadata.managedFields[] | {manager,operation}'
kubectl diff -f deployment.yaml

• Перед зміною перевіряйте context і namespace
• Спочатку використовуйте kubectl diff та --dry-run=server
• Для скриптів обирайте JSON, jsonpath або Go template
• get показує об’єкт, describe додає Events, logs читає контейнер
• Не застосовуйте --force-conflicts, доки не встановили власника поля

Визначте групи й версії ресурсів свого кластера. Потім збережіть маніфест як deployment.yaml і дослідіть схему полів через kubectl explain.

kubectl api-resources
kubectl api-versions
kubectl explain deployment.spec.strategy
kubectl get --raw /api
kubectl get --raw /apis

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: lab-api
spec:
  replicas: 2
  selector:
    matchLabels:
      app.kubernetes.io/name: web
  template:
    metadata:
      labels:
        app.kubernetes.io/name: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.28-alpine
          ports:
            - name: http
              containerPort: 80

Створіть namespace, застосуйте Deployment через Server-Side Apply, дочекайтеся rollout і збільшіть desired replicas до трьох.

kubectl create namespace lab-api
kubectl apply --server-side --field-manager=course-lab -f deployment.yaml
kubectl rollout status deployment/web -n lab-api --timeout=120s
kubectl scale deployment/web -n lab-api --replicas=3
kubectl get pods -n lab-api -w

kubectl get deploy,pods -n lab-api -o wide
kubectl get deploy web -n lab-api -o yaml
kubectl describe deploy web -n lab-api
kubectl events -n lab-api --for deployment/web

Критерій: Available=True, observedGeneration дорівнює generation, доступні три Pod, а managedFields містить manager course-lab.

Установіть неіснуючий image tag. Timeout rollout очікуваний: спочатку зберіть evidence, потім виконайте rollback та очищення.

kubectl set image deployment/web nginx=nginx:does-not-exist -n lab-api
kubectl rollout status deployment/web -n lab-api --timeout=30s
kubectl get pods -n lab-api
kubectl events -n lab-api --types=Warning
kubectl rollout undo deployment/web -n lab-api
kubectl rollout status deployment/web -n lab-api --timeout=120s
kubectl delete namespace lab-api

Порядок: перевірити context і namespace → generation → Conditions Deployment → стани Pod → Warning Events → мінімальна оборотна зміна.

• Чим ресурс відрізняється від об’єкта?
• Чому status не можна зберігати як бажаний стан у Git?
• Що показує observedGeneration?
• Навіщо потрібен server-side dry-run?
• Як managedFields допомагає під час конфлікту?

Модуль засвоєно, якщо ви знаходите ресурс через Discovery, пояснюєте GVK та identity об’єкта, перевіряєте зміну до apply і доводите причину невдалого rollout даними API.