Kubernetes базовые концепции: от API Server до Pod

⚙️ Теория

🧠 Идея Kubernetes

Kubernetes это система оркестрации, где пользователь описывает желаемое состояние (desired state), а контроллеры постоянно приводят кластер к этому состоянию (reconciliation).

Ключевой принцип:

вы описываете что должно быть,
система решает как этого достичь и поддерживать.

🏗️ Control Plane компоненты

Базовые компоненты control plane:

kube-apiserver: центральная точка API;
etcd: хранилище состояния кластера;
kube-scheduler: выбирает node для Pod;
kube-controller-manager: запускает контроллеры (Deployment, Node, Job и др.);
cloud-controller-manager (в cloud-сценариях).

Эти компоненты формируют управляющую логику кластера.

🧱 Worker Node компоненты

На worker-node обычно работают:

kubelet: агент узла, синхронизирует PodSpec с runtime;
container runtime (containerd/CRI-O и др.);
kube-proxy (или eBPF-эквиваленты в некоторых CNI-стэках).

Именно здесь запускаются Pod'ы и обслуживается service-трафик.

📦 Объекты и декларативная модель

Чаще всего в базовом потоке:

Pod это минимальная единица запуска;
Deployment управляет ReplicaSet и rollout;
Service дает стабильную сеть/доступ к Pod;
ConfigMap/Secret хранят конфиг и чувствительные данные;
Namespace изолирует логические домены.

Все это отправляется в API в формате YAML/JSON.

♻️ Reconcile loop в одном абзаце

Контроллер сравнивает:

текущее состояние (что реально работает),
желаемое состояние (что описано в API),

и выполняет действия, пока разница не исчезнет.
Это делает систему самовосстанавливаемой в рамках описанной модели.

❓ Что нужно уметь объяснить

Почему "kubectl apply" это не просто запуск контейнера?

Потому что apply меняет desired state в API, а дальше контроллеры и scheduler обеспечивают фактическое состояние.

Где источник большинства проблем у новичков?

попытка "чинить вручную" Pod вместо изменения контролируемого объекта (Deployment/StatefulSet);
слабое понимание границы между Pod, Service и Ingress;
игнорирование событий (kubectl describe) и состояния rollout.

Почему Kubernetes требует дисциплины описаний?

Без корректных ресурсов, probes, policy и версионного контроля декларативная модель теряет предсказуемость.

🧪 Практика

1. Посмотреть компоненты кластера

kubectl cluster-info
kubectl get --raw='/readyz?verbose'
kubectl get nodes -o wide
kubectl get pods -A

2. Простейший Deployment + Service

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-app
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
        - name: app
          image: nginx:stable
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app
spec:
  selector:
    app: demo-app
  ports:
    - port: 80
      targetPort: 80

3. Диагностика reconcile и rollout

kubectl apply -f demo.yaml
kubectl rollout status deployment/demo-app
kubectl describe deployment demo-app
kubectl get events --sort-by=.lastTimestamp

4. Базовые правила эксплуатации

каждое изменение через Git + review;
обязательные requests/limits и probes;
namespace и RBAC по окружениям;
запрет "ручных" drift-изменений в production.

🧾 Вывод

Kubernetes хорошо работает, когда команда думает в терминах desired state и контроллеров, а не ручных действий над Pod.
База зрелости:

понимание control plane/worker ролей,
аккуратная декларативная модель,
наблюдаемость rollout и событий кластера.