Как взаимодействуют компоненты Kubernetes?

В Kubernetes все компоненты взаимодействуют через API-сервер (kube-apiserver), который выступает центральной точкой управления и единственным интерфейсом для изменения состояния кластера.

Архитектура взаимодействия:

graph TD
    A[Users/kubectl] -->|REST API| B[kube-apiserver]
    B -->|Read/Write| C[(etcd)]
    D[kube-controller-manager] -->|Watch| B
    E[kube-scheduler] -->|Watch| B
    F[kubelet] -->|Report Status| B
    F -->|Watch| B
    G[kube-proxy] -->|Watch| B
    B -->|Admission Controllers| H[Webhooks]

Детали взаимодействия:

1. Control Plane компоненты:

   • kube-controller-manager постоянно опрашивает API-сервер через watch-соединения, сравнивая текущее состояние с желаемым (declarative state)
   • kube-scheduler получает информацию о незапланированных Pod'ах и доступных Node'ах, затем назначает Pod'ы на Node'ы
   • cloud-controller-manager (в облачных средах) взаимодействует с облачным провайдером для управления LoadBalancers, Volumes и другими ресурсами

2. Worker Node компоненты:

   • kubelet на каждой ноде:

     # Пример взаимодействия: kubelet получает Pod spec
     kubectl describe pod my-pod | grep -A5 "Node:"

     • Регулярно отправляет heartbeat и статус Pod'ов на API-сервер
     • Получает манифесты Pod'ов и запускает контейнеры через Container Runtime Interface (CRI)
     • Выполняет liveness/readiness probes

   • kube-proxy поддерживает сетевые правила (iptables/IPVS) на основе Service и Endpoint объектов из API-сервера

3. Пример создания Pod'а:

   # 1. Пользователь отправляет запрос
   kubectl apply -f pod.yaml
   
   # 2. API-сервер валидирует, аутентифицирует и авторизует запрос
   # 3. Запись сохраняется в etcd
   # 4. Scheduler замечает новый Pod в Pending состоянии
   # 5. Scheduler выбирает Node и обновляет Pod spec в API-сервере
   # 6. Kubelet на назначенной Node замечает новый Pod
   # 7. Kubelet запускает контейнер через CRI
   # 8. Kubelet обновляет статус Pod'а в API-сервере

4. Сетевые взаимодействия:

   • Все компоненты Control Plane общаются с API-сервером через HTTPS (порт 6443)
   • kubelet на нодах использует порт 10250 для API
   • etcd кластер общается между собой на порту 2379/2380

5. Мониторинг взаимодействий:

   # Проверка healthz эндпоинтов
   kubectl get --raw='/readyz?verbose'
   
   # Аудит API-запросов
   kubectl get --raw='/apis/auditregistration.k8s.io/v1alpha1'
   
   # Метрики API-сервера
   curl -k https://<api-server>:6443/metrics

Best practices в production:

• Использование --enable-admission-plugins для безопасности
• Настройка ResourceQuotas и LimitRanges через Admission Controllers
• Регулярный мониторинг etcd latency и API-сервер latency
• Использование Network Policies для изоляции трафика между компонентами