Когда сервис падает, важно за минуту понять: под не поднялся, сеть не пробросилась или правила mesh не доехали. Разложу K8s и Istio как два слоя - один про запуск, второй про общение.

Control plane - решает, но не делает kube-apiserver - единственная входная дверь. Всё идёт через него. etcd - единственный источник правды. Лежит etcd - кластер уже не «жив», даже если ноды крутятся. kube-scheduler - смотрит на ресурсы, taints и affinity, решает, на какую ноду посадить под. kube-controller-manager - цикл «хочу так / вижу так / делаю шаг». Тянет Deployment к нужному числу реплик. Control plane ничего не исполняет - только фиксирует желаемое состояние в etcd. Исполняют ноды.

Ноды - реально запускают kubelet - агент на ноде. Получает PodSpec и говорит рантайму «запускай». container runtime (containerd, CRI-O) - запускает контейнеры. kube-proxy - превращает Service в правила iptables/IPVS, чтобы трафик дошёл до пода. Цепочка: создал Deployment - apiserver записал в etcd - scheduler выбрал ноду - kubelet поднял под - controller-manager сверил реплики.

Объекты на каждый день Pod - минимальная единица запуска. Deployment / StatefulSet / DaemonSet - держат нужное число подов и размещают их. Service - стабильный адрес поверх меняющихся подов. Ingress - вход снаружи. ConfigMap / Secret - конфиг и секреты отдельно от образа. Поды эфемерны. Стабильность им дают абстракции сверху и labels/селекторы как клей.

Istio - слой общения K8s из коробки не умеет mTLS, умный роутинг, ретраи, канареечные релизы и метрики по вызовам. Это закрывает service mesh. istiod - control plane mesh. Следит за K8s API и раздаёт конфиг прокси по xDS. Envoy в sidecar - data plane. Прокси рядом с подом: через него идёт весь трафик. В ambient-режиме вместо sidecar - ztunnel (L4) и waypoint (L7). CRD: VirtualService, DestinationRule, Gateway, PeerAuthentication, AuthorizationPolicy.

Как Istio встраивается в K8s Работает webhook для внедрения sidecar - компонент, который «докручивает» под перед запуском. В namespace ставится метка istio-injection=enabled. Webhook перехватывает создание пода и добавляет sidecar с Envoy. istiod читает объекты K8s и CRD, превращая их в правила для прокси по xDS. Итог: mTLS без правок кода, канареечные релизы (90% на v1, 10% на v2 через VirtualService), ретраи и таймауты на уровне mesh, метрики и трейсы по каждому вызову.

Что такое xDS xDS - семейство API, через которое istiod динамически раздаёт конфиг Envoy. Правила обновляются на лету при изменении сервисов и политик. LDS - какие listeners поднять: порты и протоколы. CDS - список upstream-кластеров, куда слать запросы, плюс балансировка и таймауты. RDS - правила маршрутизации: «путь /api/v2 и canary=true - в кластер v2». Это канарейки и A/B. EDS - живые эндпоинты (IP и порты готовых подов), связан с K8s Endpoints. SDS - сертификаты и ключи для mTLS. На практике: применил VirtualService - istiod собрал RDS/CDS - разослал по xDS всем Envoy - прокси обновились без рестарта. Не переключается трафик - смотри xDS-статусы и EDS.

Как искать проблему Под живой? (kubelet, runtime, лимиты) Service резолвится? (kube-proxy, CoreDNS, Endpoints) Sidecar поднялся? (istiod, webhook, квоты) Правила доехали? (xDS-статусы, istioctl proxy-config) Приложение отвечает? (readiness/liveness, лимиты) Так отсекаешь лишнее и не трогаешь то, что работает.