Kubernetes 1.11: IPVS-режим kube-proxy и CoreDNS - что изменилось на практике

Kubernetes 1.11 вышел в конце июня. По меркам минорных релизов - достаточно тихий: никаких громких архитектурных сдвигов, зато два изменения, которые напрямую касаются сетки и DNS в нагруженных кластерах. Мы обновили тестовый кластер на managed-инфраструктуре и провели неделю с этим.

IPVS вместо iptables: почему это вообще важно

kube-proxy в режиме iptables работает так: для каждого Service создаётся набор правил, по которым ядро маршрутизирует пакеты к бэкендам. Когда в кластере сотни сервисов и тысячи эндпоинтов - таблица разрастается, и каждый пакет проходит через линейный обход правил. При добавлении или удалении эндпоинта kube-proxy перезаписывает всю таблицу целиком.

IPVS-режим kube-proxy (IP Virtual Server) - это подсистема ядра Linux, которую разрабатывали именно для балансировки нагрузки. Она хранит правила в хэш-таблице, а не в линейном списке. Обновление одного эндпоинта - это операция над одной записью, а не переписывание всей таблицы. Из коробки доступны несколько алгоритмов балансировки: round-robin, least connections, source hashing и другие, тогда как iptables-режим умеет только статистический random.

В 1.11 IPVS-режим перешёл из beta в stable. До этого мы его не трогали - beta в kube-proxy в продакшне это отдельный вид риска.

Как переключали и что увидели

Переключение несложное - достаточно поменять параметр mode в конфигурации kube-proxy на ipvs и убедиться, что в ядре загружены модули ip_vs, ip_vs_rr, ip_vs_wrr, ip_vs_sh. На Ubuntu 16.04 они уже есть, на некоторых минимальных образах надо доставлять ipvsadm.

После перезапуска kube-proxy на всех нодах - все существующие сервисы подхватились без каких-либо изменений со стороны приложений. Это важно: с точки зрения подов ничего не изменилось, ClusterIP те же, порты те же.

Что поменялось на нагруженных сервисах - latency. У нас есть несколько внутренних сервисов, через которые идёт высокочастотный трафик: агрегаторы метрик, шины событий, кэши. На них latency на p99 просела заметно - не в разы, но ощутимо и стабильно. На p50 разница скромнее, зато пропали хвосты, которые периодически вылезали при массовом обновлении эндпоинтов.

Отдельно понравилось что ipvsadm -Ln даёт прозрачную картину: видно какие эндпоинты за каждым виртуальным сервисом, сколько соединений на каждом, статистику. С iptables для этого нужно было разгребать iptables-save и считать правила вручную.

CoreDNS: замена kube-dns без шума

Второе изменение - CoreDNS стал DNS-провайдером по умолчанию при установке через kubeadm. kube-dns при этом никуда не делся, он опциональный, но новые кластеры разворачиваются с CoreDNS.

У нас kube-dns всегда был источником мелкого раздражения. Он состоит из трёх контейнеров в одном поде: dnsmasq как кэш, kubedns как резолвер для cluster.local, sidecar как экспортёр метрик. Конфигурация расползлась по нескольким ConfigMap и аргументам контейнера. Масштабирование было отдельным упражнением.

CoreDNS - один бинарь, один контейнер, конфигурация через Corefile. Плагинная архитектура: каждый плагин отвечает за свой кусок обработки запроса. Метрики Prometheus из коробки, без дополнительного сайдкара.

Мы мигрировали тестовый кластер с kube-dns на CoreDNS - ни одного инцидента. DNS-resolution для cluster.local работает идентично, внешние запросы форвардятся на upstream без изменений. Единственное что потребовало внимания - проверить что кастомные DNS-настройки из старого ConfigMap kube-dns перенесены в Corefile правильно.

Скорость резолвинга субъективно не изменилась - kube-dns тоже не был проблемой в этом плане. Главный выигрыш - управляемость и наблюдаемость.

Что требует внимания при обновлении

Пара вещей, на которые стоит обратить внимание перед апгрейдом до 1.11:

• IPVS и NetworkPolicy. Если используете NetworkPolicy с Calico или Cilium, проверьте совместимость с IPVS-режимом. Не все версии сетевых плагинов одинаково хорошо с ним дружат - смотрите release notes своего CNI.
• Переход с iptables на IPVS без рестарта подов. Он работает, но при этом старые conntrack-записи для существующих соединений iptables не сбрасываются автоматически. Долгоживущие TCP-соединения продолжат работать через старые правила пока не переустановятся.
• kube-dns vs CoreDNS при in-place upgrade. kubeadm при обновлении существующего кластера с 1.10 на 1.11 не меняет DNS-провайдер автоматически - оставляет что было. Переход на CoreDNS нужно делать явно.

Итог

Обновление до 1.11 в тестовом кластере прошло штатно. IPVS-режим в stable - это повод переключиться, если в кластере есть высоконагруженные сервисы или крупная сервисная сетка: выигрыш по latency реальный, даже если не драматический. CoreDNS в дефолте - разумный шаг, нам он нравится больше чем трёхголовый kube-dns.

На продакшн-кластеры пока не катили - смотрим ещё неделю на тестовом, потом будем думать про план миграции.