Часть 1. Модель Kubernetes и базовые сетевые задачи

Если вы — сетевой инженер, ваш мир построен на четких и понятных правилах. У вас есть OSPF для динамической маршрутизации, BGP для обмена маршрутами между автономными системами, зоны VRF для изоляции трафика, VLAN-ы для сегментации и списки ACL для ограничения доступа. Каждый порт на коммутаторе имеет свой VLAN, каждый маршрутизатор знает свою таблицу маршрутизации, и всё это работает предсказуемо.

А потом в вашу жизнь врывается Kubernetes (K8s).

Внезапно вместо физических серверов с постоянными IP-адресами у вас появляются контейнеры, которые живут минуты или секунды. Вместо статических маршрутов — динамически создаваемые сети. Вместо конфигурации в CLI роутере — YAML-файлы. Звучит пугающе? Давайте разберёмся. Под капотом Kubernetes использует всё те же сетевые примитивы, которые вы уже знаете: мосты, маршруты, iptables, VXLAN, BGP. Просто они оркестрируются автоматически.

Базовые понятия: Pod, Node, Cluster

Pod — минимальная единица развёртывания в Kubernetes. Думайте о нём как о виртуальном сервере с одним (или несколькими) контейнерами внутри. У каждого Pod свой уникальный IP-адрес. 

Node — физическая или виртуальная машина, на которой работают Pod-ы. Для сетевого инженера Node — это ваш сервер (физический или виртуальный). ToR-коммутатор — это уже часть физической сети, к которой Node подключен. В контексте кластера Node — это устройство, на котором работают Pod'ы.

Cluster — совокупность всех Node-ов под управлением Kubernetes. Это ваш ЦОД целиком.

Плоская L3-модель: один IP на каждый Pod

Вот ключевое правило, которое отличает сеть Kubernetes от классической виртуализации:

Каждый Pod получает уникальный IP-адрес, и все Pod-ы в кластере могут общаться друг с другом напрямую — без NAT.

Это фундаментальное требование Kubernetes. Никаких port-mapping-ов, никакого двойного NAT. Если Pod A имеет IP 10.244.1.15, а Pod B — 10.244.2.30, то A может отправить пакет напрямую на 10.244.2.30, и B увидит в заголовке source IP 10.244.1.15.

Представьте, что весь ваш ЦОД — это одна огромная плоская L3-сеть. Каждый сервер видит каждый другой сервер без NAT-шлюзов. Это как если бы вы построили сеть, где все VLAN-ы маршрутизируются через единый VRF без каких-либо ограничений.

На практике кластер использует общий CIDR-блок (например, 10.244.0.0/16), который разбивается на подсети для каждого Node. Каждый Node получает свой PodCIDR — обычно /24 (256 адресов), что даёт до 254 Pod-ов на ноду. Node с IP 192.168.1.10 может обслуживать Pod-ы в диапазоне 10.244.1.0/24, а Node 192.168.1.11 - в 10.244.2.0/24.

Четыре сетевые задачи, которые решает Kubernetes

Kubernetes должен обеспечить четыре типа сетевого взаимодействия:

Задача 1. Контейнер — Контейнер (внутри Pod)

Допустим, нам нужно, чтобы несколько контейнеров внутри одного Pod общались между собой.

В этом случае все контейнеры в Pod разделяют один сетевой namespace. Они видят одни и те же сетевые интерфейсы, один IP-адрес и один localhost. Это как несколько процессов на одном сервере, общающихся через 127.0.0.1. Никакой сети - все локально.

Задача 2. Pod - Pod

Или например, Pod на Node A должен достучаться до Pod на Node B. Pod-ы создаются и уничтожаются динамически, их IP-адреса непредсказуемы.

Тогда CNI-плагин (Container Network Interface) обеспечивает связность между всеми Pod-ами в кластере. Это может быть overlay-сеть (VXLAN), BGP-маршрутизация или eBPF.

Для понимания: CNI — это ваш протокол маршрутизации (OSPF/BGP), который автоматически распространяет маршруты до подсетей Pod-ов по всему кластеру. Только вместо ручной настройки router ospf 1 на каждом устройстве - все происходит автоматически при добавлении нового Node.

Задача 3. Pod - Service

Pod-ы эфемерны: они появляются и исчезают, меняя IP-адреса. Как другим Pod-ам найти нужный сервис?

Kubernetes Service создаёт стабильный виртуальный IP-адрес (ClusterIP), который балансирует трафик между Pod-ами, реализующими этот сервис.

Получается, ClusterIP — это ваш HSRP/VRRP VIP или Load Balancer. Это стабильная точка входа для группы серверов, которые могут меняться.

Задача 4. Внешний мир — Service

Бывает, что пользователи из интернета должны попасть на сервис внутри кластера.

Решение есть и тут. NodePort, LoadBalancer или Ingress — механизмы публикации внутренних сервисов наружу.

Это как настройка DNAT на пограничном файрволе для публикации внутренних серверов в интернет. Или ваш F5/Citrix ADC, принимающий трафик снаружи и распределяющий его по backend-серверам.

Часть 2. CNI: Container Network Interface

Что такое CNI

CNI — это спецификация, а не конкретный продукт. Это стандартный интерфейс, описывающий, как сетевой плагин должен настраивать сеть для контейнера. 

Когда kubelet (агент Kubernetes на каждом Node) запускает новый Pod, он вызывает CNI-плагин через простой JSON-вызов: «Создай сетевой интерфейс для этого контейнера и подключи его к сети». Плагин делает всю работу:

1. Создаёт veth-пару (виртуальный кабель — один конец в Pod, другой на хосте).

2. Подключает хостовый конец к bridge или напрямую к маршрутизируемому интерфейсу.

3. Назначает IP-адрес через IPAM (IP Address Management) из PodCIDR этого Node.

4. Прописывает маршруты, чтобы трафик мог ходить между Node-ами

Аналогия для каждого компонента:

• veth-пара — патч-корд между сервером и коммутатором. Один конец — в сервере (Pod), другой — в порту коммутатора (хост).

• bridge — виртуальный L2-коммутатор внутри Node. Все Pod-ы на одном Node подключены к этому коммутатору.

• IPAM — ваш DHCP-сервер или IPAM-система. Только здесь адреса раздаются из PodCIDR автоматически.

• PodCIDR — подсеть, выделенная данному Node. Если Node получил 10.244.3.0/24, все Pod-ы на нём будут из этого диапазона.

Три подхода к CNI

1. Overlay-сети (VXLAN / IP-in-IP)

Примеры: Flannel, Calico (overlay mode), Weave.

Pod-ы на разных Node-ах общаются через туннели. Пакет от Pod 10.244.1.15 на Node A к Pod 10.244.2.30 на Node B инкапсулируется в VXLAN-заголовок (или IP-in-IP) и отправляется между Node-ами по обычной сети.

Плюсы:

• Работает поверх любой L3-сети между Node-ами — не нужно менять конфигурацию физических коммутаторов

• Простота развертывания — «поставил и забыл»

Минусы:

• Overhead в заголовках: VXLAN добавляет 50 байт к каждому пакету. Если MTU вашей физической сети — 1500, эффективный MTU для Pod-ов - 1450. Это может ломать приложения, чувствительные к MTU (привет, Path MTU Discovery)

• Дополнительная нагрузка на CPU для инкапсуляции/декапсуляции

• Сложнее отлаживать — tcpdump на физическом интерфейсе покажет вам VXLAN-пакеты, а не реальный трафик

Overlay — это как GRE или VXLAN-туннели между вашими ЦОД-ами. Быстро настраивается, но добавляет complexity и overhead.

2. Routing-подход (BGP)

Примеры: Calico (BGP mode), kube-router.

Вместо туннелей — обычная L3-маршрутизация. Calico в режиме BGP запускает BIRD (BGP-демон) на каждом Node и анонсирует PodCIDR этого Node как BGP-маршрут. Node-ы обмениваются маршрутами друг с другом (full mesh iBGP) или через Route Reflector.

Самое интересное для сетевого инженера: Calico может пириться по BGP с вашими физическими ToR-коммутаторами. Это значит, что ваша физическая сеть знает, на какой Node отправлять пакет для конкретного PodCIDR. Никаких туннелей, никакого overhead-а, чистый L3-роутинг.

Плюсы:

• Нативная производительность — нет overhead-а инкапсуляции

• MTU не меняется

• Полная видимость трафика — tcpdump показывает реальные пакеты

• Интеграция с существующей сетевой инфраструктурой через BGP

Минусы:

• Требует L3-связности между Node-ами (или BGP-пиринга с коммутаторами)

• Сложнее в настройке — нужно координировать ASN, BGP-политики, Route Reflector-ы

Это буквально ваш BGP. Каждый Node - это маршрутизатор, анонсирующий свои подсети. Если вы работали с BGP в ЦОД (а тем более с EVPN/VXLAN fabric), то все знакомо.

3. eBPF-подход

Примеры: Cilium.

eBPF (extended Berkeley Packet Filter) — технология, позволяющая выполнять программы прямо в ядре Linux без модулей ядра. Cilium использует eBPF для маршрутизации пакетов, заменяя традиционные iptables, bridge и даже kube-proxy.

В 2024–2025 годах Cilium стал CNI по умолчанию в Google Kubernetes Engine (GKE) и Azure Kubernetes Service (AKS). Это не случайно — eBPF обеспечивает значительно лучшую производительность при масштабировании.

Плюсы:

• Максимальная производительность — обработка пакетов на уровне ядра без прохождения через сетевой стек

• Заменяет iptables (kube-proxy не нужен) — нет деградации при тысячах сервисов

• Встроенная поддержка L7-политик, observability, шифрования (WireGuard)

Минусы:

• Требует ядро Linux 5.10+ (для полной функциональности - 5.15+)

• Новая парадигма — iptables -L больше не покажет правила, нужно изучать cilium monitor, hubble

eBPF — это как программируемый ASIC в вашем коммутаторе. Вместо фиксированного пайплайна обработки пакетов — гибкая программа, выполняемая на скорости порта прямо в ядре.

Часть 3. Services и kube-proxy

Почему ClusterIP «не пингуется»

Одна из самых частых проблем, с которой сталкиваются сетевые инженеры в Kubernetes: вы создали Service типа ClusterIP, получили адрес 10.96.0.100, попробовали ping 10.96.0.100 и тишина.

Это нормально. ClusterIP — виртуальный адрес, который не существует ни на одном интерфейсе. Он живёт только в правилах iptables (или IPVS, или eBPF) на каждом Node. Когда Pod отправляет пакет на 10.96.0.100:80, iptables перехватывает его в цепочке PREROUTING и делает DNAT — подменяет destination IP на реальный IP одного из Pod-ов за этим Service. ICMP-пакеты (ping) просто не обрабатываются этими правилами.

Это как Policy-Based Routing (PBR) на вашем маршрутизаторе. Вы настроили route-map, который перенаправляет трафик на порт 80 к определённому next-hop. Но если вы пингуете адрес, указанный в правиле, то ничего не произойдет, потому что PBR работает только для трафика, соответствующего условиям.

Режимы kube-proxy

kube-proxy — это компонент, который программирует правила балансировки трафика на каждом Node. 

Он работает в одном из трёх режимов:

1. iptables (по умолчанию): Для каждого Service kube-proxy создаёт набор правил iptables с вероятностным распределением. Если за Service стоят 3 Pod-а, создаются правила с probability 0.33, 0.50, 1.00 — простая статистическая балансировка.

Проблема при масштабе: Каждый Service — десятки правил iptables. При 5 000 сервисов — это сотни тысяч правил. Обновление таблицы iptables — O(n), и каждое изменение блокирует всю таблицу. Latency растет.

2. IPVS: Linux IPVS (IP Virtual Server) — полноценный L4-балансировщик в ядре. Использует хеш-таблицы вместо линейных цепочек, поддерживает алгоритмы балансировки: round-robin, least connections, source hash и другие.

Производительность: O(1) lookup вместо O(n). При тысячах сервисов — радикальная разница.

Аналогия: Переход с iptables на IPVS — как замена ACL на роутере на аппаратный TCAM в коммутаторе. Те же правила, но выполняются на скорости порта.

3. eBPF (без kube-proxy): Cilium может полностью заменить kube-proxy, обрабатывая Service-трафик через eBPF-программы. Никаких iptables, никакого IPVS. Пакет обрабатывается еще до входа в сетевой стек Linux.

В Kubernetes 1.29–1.32 (2024–2025) все больше кластеров переходят на этот режим, особенно в production-окружениях с высокой нагрузкой.

Endpoints и EndpointSlice

Как kube-proxy узнает, на какие Pod-ы балансировать? Через ресурсы Endpoints (устаревший) и EndpointSlice (актуальный). Когда Pod с нужным label запускается или останавливается, Kubernetes автоматически обновляет EndpointSlice — список IP:port пар для каждого Service.

EndpointSlice — это как таблица ARP или MAC-таблица на вашем коммутаторе. Только вместо «MAC → порт» здесь «Service → список Pod IP:port». И она обновляется автоматически при каждом изменении.

Часть 4. L7-маршрутизация и Ingress

Ingress: ваш L7-прокси внутри кластера

Все, о чём мы говорили до сих пор, — это L3/L4: IP-адреса, порты, балансировка TCP-соединений. Но современные приложения — это HTTP-микросервисы. Вам нужна маршрутизация по URL, Host-заголовкам, TLS-терминация.

Ingress — это ресурс Kubernetes, описывающий правила L7-маршрутизации:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: api.example.com
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: api-v1
            port:
              number: 80
      - path: /v2
        pathType: Prefix
        backend:
          service:
            name: api-v2
            port:
              number: 80
  tls:
  - hosts:
    - api.example.com
    secretName: api-tls-cert

Но сам ресурс Ingress — это только декларация (желаемое состояние). Чтобы она заработала, нужен Ingress Controller — реальный L7-прокси, который читает эти правила и настраивает себя. Популярные реализации: Nginx Ingress Controller, Traefik, HAProxy, Envoy (Contour).

Аналогия: Ingress Resource — это как конфигурация виртуального сервера на F5 BIG-IP или правило на Citrix ADC. Ingress Controller — сам F5, железка (или Pod), которая обрабатывает трафик. Вы описываете, что хотите (host-based routing, TLS offload), а контроллер реализует.

Gateway API: новый стандарт

В 2023–2024 годах Kubernetes-сообщество осознало, что Ingress-ресурс слишком ограничен. Нет стандартного способа описать TCP/UDP-маршрутизацию, traffic splitting, header-based routing. Каждый Ingress Controller добавлял это через нестандартные аннотации.

Gateway API — эволюция Ingress, ставшая GA (General Availability) в Kubernetes 1.29. Он вводит явное разделение ответственности:

• GatewayClass — тип инфраструктуры (аналог «модели коммутатора»)

• Gateway — точка входа трафика (аналог физического интерфейса с IP и портом)

• HTTPRoute / TCPRoute / GRPCRoute — правила маршрутизации (аналог route-map или PBR)

Для сетевого инженера Gateway API — гораздо более логичная модель. Она разделяет инфраструктуру (Gateway) и политику маршрутизации (Route), как вы привыкли разделять physical interface configuration и routing policy.

Часть 5. Service Mesh

Что добавляет Service Mesh

Если CNI обеспечивает L3/L4-связность, а Ingress — входящую L7-маршрутизацию, то Service Mesh — это L7-управление трафиком между сервисами внутри кластера:

• mTLS (mutual TLS) — автоматическое шифрование всего трафика между Pod-ами с взаимной аутентификацией сертификатов. Каждый Pod получает свой сертификат из встроенного CA.

• L7 Load Balancing — балансировка не по TCP-соединениям, а по HTTP-запросам. Retry, timeout, circuit breaker на уровне каждого запроса.

• Observability — метрики (latency, error rate, throughput) для каждого запроса между каждой парой сервисов. Без изменения кода приложения.

• Traffic Management — canary deployments (10% трафика на новую версию), A/B-тестирование, fault injection.

Sidecar vs eBPF

Sidecar-модель (Istio, Linkerd): рядом с каждым Pod-ом (в его сетевом namespace) запускается прокси (обычно Envoy). Весь трафик Pod-а перехватывается через iptables и проходит через этот прокси.

Плюсы: полный контроль L7, богатая функциональность

Минусы: дополнительное потребление CPU/RAM на каждый Pod, дополнительная latency (~1–3 мс на hop)

eBPF-модель (Cilium Service Mesh): вместо sidecar-прокси обработка выполняется eBPF-программами в ядре; нет дополнительных контейнеров, минимальная latency.

• Плюсы: меньше ресурсов, ниже latency

• Минусы: менее зрелая L7-функциональность (но быстро развивается)

Когда нужен Service Mesh

Service Mesh — это не обязательный компонент. Не ставьте его «на всякий случай». Он добавляет значительную сложность.

Ставьте, когда:

• Регуляторные требования к шифрованию всего internal-трафика (mTLS)

• Нужен детальный мониторинг между сервисами без изменения кода

• Сложная маршрутизация трафика (canary, A/B, fault injection)

Не ставьте, когда:

• У вас 10 сервисов и простая архитектура

• Можно решить задачу на уровне CNI или Ingress

• Команда не готова к дополнительной сложности

Аналогия: Service Mesh — это как развертывание IPS/IDS на каждом сегменте сети. Да, это дает полную видимость и контроль. Но это стоит ресурсов, и если у вас небольшая сеть — overhead не оправдан.

Часть 6. NetworkPolicy и сегментация

По умолчанию — все открыто

В Kubernetes по умолчанию любой Pod может общаться с любым другим Pod в кластере. Нет никаких ACL, никакой сегментации. Это как сеть, где все порты коммутатора в одном VLAN, а файрвол отключен.

Для production-среды это неприемлемо. И решение есть — NetworkPolicy.

NetworkPolicy: декларативные ACL

NetworkPolicy — это ресурс Kubernetes, описывающий правила фильтрации трафика:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Этот манифест запрещает весь входящий и исходящий трафик для всех Pod-ов в namespace production. Теперь нужно явно разрешить нужные потоки:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Аналогия: NetworkPolicy — это ваши ACL, только декларативные. Вместо access-list 101 permit tcp 10.1.0.0 0.0.255.255 host 10.2.0.50 eq 8080 вы описываете то же самое в YAML. И, как в классической сети, best practice — это прописать что именно разрешено и запретить все остальное.

Ограничения

NetworkPolicy работает только на L3/L4 — IP-адреса, порты, протоколы. Вы не можете фильтровать по HTTP-заголовкам, URL-путям или gRPC-методам.

Для L7-фильтрации нужны:

• Cilium NetworkPolicy (CiliumNetworkPolicy) — расширенные L7-правила через eBPF

• Service Mesh — Istio AuthorizationPolicy и аналоги

NetworkPolicy — это только спецификация. Ее обеспечивает ваш CNI-плагин. Если ваш CNI не поддерживает NetworkPolicy (базовый Flannel, например), правила будут созданы, но не применены. Calico, Cilium, Weave — поддерживают.

В каждом namespace создавайте default-deny политику первым делом. Потом добавляйте explicit allow по мере необходимости. Точно так же, как вы настраиваете файрвол: deny any any в конце, конкретные permit - в начале.

Часть 7. Диагностика: как отлаживать сеть в Kubernetes

Всегда тестируйте изнутри Pod-а. NetworkPolicy, DNS-резолвинг, Service IP — всё это работает в контексте Pod-а, а не Node-а. Если вы сидите на Node и пытаетесь curl ClusterIP, вы тестируете не то, что видит ваше приложение.

# Запустите отладочный Pod с полным набором инструментов
kubectl run debug --rm -it --image=nicolaka/netshoot -- bash

# Или выполните команду внутри существующего Pod
kubectl exec -it my-pod -- sh

Внутри Pod вам доступны привычные инструменты:

# DNS-резолвинг (критически важно - 90% проблем начинаются с DNS)
nslookup my-service.my-namespace.svc.cluster.local

# Проверка связности
ping 10.244.2.30
curl http://my-service:8080/health

# TCP-проверка порта
nc -zv my-service 8080

# Маршруты внутри Pod
ip route show

# Полный дамп трафика (если есть tcpdump в образе)
tcpdump -i eth0 -nn port 8080

Типичные проблемы и их сетевое объяснение

Pod не может достучаться до другого Pod:

• Проверьте CNI: работает ли сетевой плагин? 

kubectl get pods -n kube-system | grep -E 'calico|cilium|flannel'

• Проверьте NetworkPolicy: есть ли default-deny, блокирующий трафик? 

kubectl get networkpolicy -A

• Проверьте маршруты на Node: есть ли маршрут до PodCIDR целевого Node? 

ip route | grep 10.244

Проверьте MTU: если используется VXLAN overlay, убедитесь, что MTU внутри Pod-а = MTU физической сети минус 50 байт

ClusterIP недоступен извне кластера:

Это ожидаемое поведение. ClusterIP - внутренний адрес, существующий только в iptables на Node-ах кластера. Для внешнего доступа используйте:

• NodePort — открывает порт (30000–32767) на каждом Node

• LoadBalancer — создаёт внешний балансировщик (в облаке)

• Ingress — L7-маршрутизация через единую точку входа

DNS не резолвится:

Kubernetes использует CoreDNS для внутреннего DNS. Каждый Pod по умолчанию настроен на nameserver <ClusterIP kube-dns> (обычно 10.96.0.10).

# Проверьте, работает ли CoreDNS
kubectl get pods -n kube-system -l k8s-app=kube-dns
kubectl logs -n kube-system -l k8s-app=kube-dns

# Проверьте, резолвится ли Service
kubectl exec debug -- nslookup kubernetes.default

Частые причины: CoreDNS Pod-ы в CrashLoopBackOff, NetworkPolicy блокирует DNS (порт 53/UDP к kube-dns), некорректная конфигурация dnsPolicy в Pod-е.

Периодические тайм-ауты при большой нагрузке:

Скорее всего, исчерпание conntrack-таблицы. Linux отслеживает каждое соединение в таблице conntrack. По умолчанию лимит — 131 072 записей. В нагруженном кластере с тысячами Pod-ов и Service-ов этого может не хватать.

# Проверьте текущее состояние на Node
cat /proc/sys/net/netfilter/nf_conntrack_count   # текущее количество
cat /proc/sys/net/netfilter/nf_conntrack_max     # лимит

# Если count ≈ max - увеличивайте
sysctl -w net.netfilter.nf_conntrack_max=524288

Аналогия: Это как исчерпание session table на вашем файрволе. Те же симптомы — случайные drop-ы, тайм-ауты, и то же решение — увеличить таблицу или оптимизировать количество соединений.

Заключение

Kubernetes не заменяет сетевую инженерию — он строит на ее фундаменте. Под капотом всех этих абстракций — Pod, Service, Ingress, NetworkPolicy — лежат те же технологии, с которыми вы работаете каждый день:

Главное преимущество сетевого инженера в мире Kubernetes: вы уже понимаете механику, которая стоит за абстракциями. Когда разработчик видит «ClusterIP не работает» — он в тупике. Вы знаете, что это DNAT в iptables, и начинаете проверять цепочки. Когда Pod-ы не общаются между Node-ами — вы проверяете маршруты, MTU и инкапсуляцию. 

Что действительно меняется — это подход к управлению. Вместо ручной конфигурации через CLI (interface GigabitEthernet0/1, ip address ..., router bgp 65000) — декларативные YAML-манифесты, хранящиеся в Git. Вместо единичных изменений — автоматическое приведение к желаемому состоянию (reconciliation loop). Это не хуже и не лучше — это другая парадигма: Infrastructure as Code вместо Infrastructure as CLI.

Kubernetes — это не магия. Это сетевые технологии, которые вы знаете, обернутые в автоматизацию. И если вы потратите время на понимание этого слоя автоматизации — вы станете незаменимым специалистом, который понимает и сеть, и платформу.

В этой статье мы сознательно заглянули под капот Kubernetes, чтобы вы видели: за абстракциями Pod'ов и Service'ов стоят знакомые вам механизмы — BGP, VXLAN, iptables. Именно это понимание позволяет проектировать отказоустойчивые и производительные решения. Но в реальной практике инженеру важно не только знать теорию, но и эффективно расходовать ресурсы — как вычислительные, так и временные. Иногда разумнее делегировать управление мастер-узлами и базовой сетевой связности провайдеру, сохранив за собой полный контроль над сетевыми политиками и архитектурой взаимодействия сервисов. Например, Kubernetes as a Service от Cloud4Y предоставляет чистый K8s с поддержкой популярных CNI-плагинов, оставляя вам ровно ту степень свободы, которая нужна для тонкой настройки сети под задачи проекта. Вы по-прежнему управляете NetworkPolicy, Ingress-контроллерами и маршрутизацией, но избавляете себя от необходимости мониторить etcd или обновлять компоненты Kubernetes в 3 часа ночи.