kube-proxy
Тема дорожной карты · Kubernetes
kube-proxy — сетевой прокси, работающий как DaemonSet на каждом узле кластера Kubernetes и отвечающий за реализацию абстракции Service путём программирования сетевой подсистемы ядра для маршрутизации трафика от ClusterIP и NodePort сервисов к правильным конечным точкам Pod'ов. В режиме iptables по умолчанию kube-proxy отслеживает изменения в API-сервере Kubernetes для ресурсов Service и Endpoints (или EndpointSlice) и транслирует их в правила DNAT iptables, балансирующие соединения между IP-адресами здоровых Pod'ов. Режим ipvs обеспечивает лучшую производительность в крупных масштабах (тысячи Service) за счёт использования модуля ядра Linux IP Virtual Server с алгоритмами балансировки нагрузки на основе хэш-таблиц — round-robin, наименьшее число соединений или хэш по источнику — настраиваемых через флаг --proxy-mode=ipvs. При eBPF-сети Cilium kube-proxy можно полностью заменить (--disable-kube-proxy), поскольку Cilium обрабатывает балансировку нагрузки Service напрямую в ядре, устраняя слой iptables и снижая сетевые задержки в K8s-средах с высокой пропускной способностью.
Как это работает
kube-proxy структурирован вокруг control plane и node plane Kubernetes. В control plane: API-сервер, etcd (хранилище состояния кластера), scheduler и controller-manager. В node plane: kubelet (агент, исполняющий pods), kube-proxy (сетевой слой) и container runtime. Решения по kube-proxy идут от API-сервера через контроллеры и применяются на нодах.
Когда применять
Понимание kube-proxy важно когда (а) вы отлаживаете проблемы кластера и нужно знать, какой компонент виноват, (б) sизируете кластер и решаете control-plane vs worker ресурсы, (в) проектируете HA-топологию (multi-master, etcd quorum), (г) выбираете между managed K8s (EKS/GKE/AKS) и self-managed. Без этого фундамента ошибки kubectl становятся гаданием.
Типичные ошибки
Архитектурные ловушки с kube-proxy: single-master control plane в production (один etcd-отказ = outage кластера), under-sizing control plane для размера кластера (1000+ pods требуют больше CPU API-сервера, чем дефолты), допущение что режимы kube-proxy (iptables vs IPVS) не важны — они важны на масштабе. Относитесь к control plane как к critical infrastructure со своим мониторингом и DR.