Поздравляю, вы установили Куберентис (Kubernetes)! Но есть нюанс

Поздравляю, вы успешно (или не очень) развернули свой первый кластер k8s с помощью kubeadm! В связи с этим ловите мем, вы его заслужили:

Но давайте перейдем к сути... А что дальше делать-то? Большинство побежит читать доку побегут сразу на гитхаб искать любое приложение которое можно запустить в их кластере Kubernetes (Далее k8s), но они столкнутся с рядом «нюансов». И вот как раз про эти нюансы мы сегодня и поговорим.

В этой статье я, как DevOps-инженер компании СТАРКОВ Групп, расскажу о трёх ключевых "подводных камнях", с которыми сталкивается каждый, кто начинает работать с кубиком:

1. Настройка сетевого взаимодействия (CNI)
2. Организация хранилища (StorageClass, PV, PVC)
3. Настройка входящего трафика (Ingress/Ingress Controller)
    

Нюанс номер 1. Сеть, плагины, CNI

В k8s за сеть отвечает Container Network Interface (далее CNI). Что-же такое CNI? Если коротко – это фреймворк для динамической настройки всех сетевых ресурсов в k8s. CNI может применяться как для оверлейных сетей (сети, в которых трафик инкапсулируется посредством виртуального интерфейса), так и для андерлейных (сети, работающие сугубо на физическом уровне). Но давайте душнить не будем, а перейдем к конкретике. После «ванильной» раскатки вы обязательно должны установить один из CNI-плагинов чтобы ваши pod-ы смогли общаться между собой. Вот они все, слева направо: Calico, Cilium, Flannel, Kube-route.

1. Calico

GitHub: https://github.com/projectcalico/calico
Docs: https://docs.tigera.io (Придется использовать ВПН)
Плюсы:

• поддержка Network Policies (NP);

• очень большое комьюнити: Calico используется большими компаниями, а как следствие очень быстро развивается, и активно поддерживается;

• поддержка большого количества плюх: интеграция с istio, глубокая интеграция с большинством облачных систем, при отсутствии BGP – есть fallback через IP-in-IP или VXLAN и еще очень много всего;

• высокая производительность (при использовании BGP);

• рекомендуется для продуктивных сред.

Минусы:

• требует понимания: что такое BGP, как используется, общие азы маршрутизации;

• в больших кластерах может быть сложно писать, а также поддерживать большое количество NP.

2. Cilium

GitHub: https://github.com/cilium/cilium
Docs: https://docs.cilium.io/en/stable/index.html
Плюсы:

• самая высокая производительность среди всех CNI;

• хорошо себя проявляет в больших инсталляциях, которые порождают большое количество правил iptables;

• рекомендуется к применению в хайлоад продуктивных системах;

• нативная интеграция с eBPF – функционалом ядра Linux, который позволяет создавать и встраивать на уровне ядра (т.е запускаться в kernel space, а не в user space как обычные приложения) программы, которые могут мониторить и контролировать различные события в системе;

• Cloud-native;

• может полностью заменить дефолтный kube-proxy, что в больших кластерах просто обязательно для снижения накладных сетевых ресурсов.

Минусы:

• требует очень глубокого понимания eBPF(!), а как следствие:

  • знание основ языка C, всю базу про syscall, чтобы уметь создавать свои костыли для BPF и вообще понимать, как это все работает;

  • знание языка GOlang, так как все либы написаны нём.

Но опять же, все вышеперечисленное необходимо, если вы хотите раскрыть весь "потанцевал" данного CNI.

• не подходит для легаси кластеров, так как требует минимально ядро linux 4.9.

3. Flannel

GitHub: https://github.com/flannel-io/flannel
Docs: https://github.com/flannel-io/flannel/tree/master/Documentation 
Плюсы:

• самый легкий способ запустить сеть в кластере: одна команда, и все начинает работать.

Минусы:

• нет поддержки NP;

• совершенно не подходит для продакшена, максимум для препрода;

• overlay сети (яркий пример – udp) могут выдавать оверхед в ~10-20%.

4. Kube-router

GitHub: https://github.com/cloudnativelabs/kube-router
Docs: https://kube-router.io/docs/user-guide
Плюсы:

• подходит, если требуется легковесный CNI без лишних зависимостей;
• есть интеграция с BGP, но можно завести и без BGP;
• поддерживает NP;
• подходит для больших продакшенов, которым не нужно eBPF;
• заменяет kube-proxy.

Минусы:

• требует понимания: что такое BGP, как используется, и общие азы маршрутизации. К слову, это все еще на голову легче, чем eBPF;
• не имеет широкой поддержки облачных провайдеров, так как рассчитан больше для on-premise;
• в огромных кластерах могут возникать коллизии в результате проблем с синхронизацией состояния и, как следствие, снижение производительности BGP.

Вы, скорее всего, спросите: а что выбрать? А вот ответ на ваш вопрос:

• для препрода, изучения или просто всяких шалостей – Flannel;
• если важна общая поддержка продукта, а также эффективность как в on-premise, так и в облаке – Calico;
• если вы работаете с высокими нагрузками, и/или вам важна cloud-native архитектура – Cilium;
• если у вас on-premise, и облако вам никогда не пригодится – kube-router.

Нюанс номер 2. Storage Class, магия PV и зачем нужен PVC

На данном этапе у вас в кластере есть только CNI плагин для работы сети, но его одного не достаточно, чтобы сразу запускать приложухи/вводить кластер в продакшен и так далее – нам же наши данные где-то надо хранить! В k8s за хранение данных отвечают 3 сущности: Storage Class, PV и PVC. Но так как вы только-только развернули свой первый кластер, вам это ни о чем не говорит. Давайте подробнее разберем каждую сущность.

Storage Class (Далее SC) – это абстракция, которая определяет класс хранилища, и указывает, как создавать PV.

PV (Persistent Volume) – это объект k8s, который предоставляет кусок хранилища который УЖЕ существует в кластере или создается динамически (автоматическое выделение PV мы разберем ниже).

PVC (Persistent Volume Claim) – если по-простому, это запрос на использование хранилища, то есть абстракция, которая как бы говорит: "Мне нужно X Гб хранилища с режимом Y и классом Z".

Казалось бы, ну и в чем тут нюанс? А нюанс в том, что при ванильной раскатке у вас не будет SC из коробки, его придется создать, как и CNI. А чтобы создать SC, нам нужен соответствующий провайдер. Давайте же выберем его! Вот список проверенных провайдеров, каждый со своими плюсами и минусами:

1. kubernetes.io/no-provisioner

GitHub: -
Docs: -
Плюсы:

• работает безотказно, как палка;
• подходит для изучения работы SC в k8s.

Минусы:

• по функционалу – палка;
• требует ручного создания PV.

2. Local Path Provisioner

GitHub: https://github.com/rancher/local-path-provisioner (содержит примеры использования)
Docs: -
Плюсы:

• простота установки и использования;
• поддерживает динамическое создание PV через StorageClass;
• идеален для тестирования и обучения;
• не требует внешних зависимостей.
• в крайне редких случаях может использоваться в продуктивных системах, особенно если в k8s крутятся реляционные БД.

Минусы:

• нет отказоустойчивости;
• требуется ручное управление дисками;
• не поддерживает snapshot'ы или расширение томов;
• при удалении PVC данные теряются.

3. Rook/CEPH

GitHub: https://github.com/rook/rook
Docs: https://rook.io/docs/rook/latest-release/Getting-Started/intro/
Плюсы:

• распределённое и отказоустойчивое хранение;
• поддерживает динамическое создание PV через StorageClass;
• поддержка block, file и object storage;
• снапшоты, Volume Expansion, Cloning и вообще все по красоте.

Минусы:

А также:

• сложная настройка и диагностика;
• требует минимум 3 узла;
• высокий оверхед на обслуживание и поддержку;
• требует хороших знаний самого CEPH (неожиданно, правда?).

4. Longhorn

GitHub: 
Docs: https://longhorn.io/docs
Плюсы: https://github.com/longhorn/longhorn

• простота установки и управления;
• поддерживает динамическое создание PV через StorageClass;
• поддержка снапшотов, резервного копирования, volume expansion;
• хорошая документация и активное комьюнити.
• удобный веб интерфейс, но он особо не нужны.

Минусы:

• меньше функционала, чем у Rook/Ceph;
• ограниченная поддержка file/object storage (но все же есть).

Также существуют сугубо облачные провайдеры, но их описывать большого смысла нет. Там все +/- одинаковое.

А где что использовать-то?

• если вы только изучаете, как все работает в k8s – kubernetes.io/no-provisioner.
• для dev/test окружения – Local Path.
• Если вам нужен отказоустойчивый storage on-premise:
  • для огромного количества данных и важностью каждого байта – Rook/Ceph.
  • для продакшена средней руки – Longhorn.

На данный момент мы уже и сеть подняли, и хранилище организовали. Когда там уже можно будет деплоить приложухи? Ответ: скоро, осталось только обратный прокси как-то засунуть в этот кластер – и все, можно будет работать.

Нюанс номер 3. I – значит Ingress (или Ingress Controller?)

Для начала разберемся, что такое ingress и что такое Ingress Controller. Ingress – это декларативный ресурс (YAML-файл по сути), который описывает, как маршрутизировать запросы. А Ingress Controller – это работающий процесс (под/набор подов), который обрабатывает эти правила. Если очень просто: Ingress это файлик с описанием что и куда отправлять, а Ingress Controller выполняет то, что описано в Ingress.

Рассмотрим существующие контроллеры, чтобы выбрать тот, что подходит именно нам.

1. NGINX Ingress Controller

GitHub: https://github.com/kubernetes/ingress-nginx
Docs: https://docs.nginx.com/nginx-ingress-controller/
Плюсы:

• хорошая документация;
• поддержка TLS, rewrite правил, rate limiting;
• активное комьюнити;
• гибкая настройка через аннотации.

Минусы:

• ограниченная поддержка продвинутых функций (например, L7-политик)
• поначалу сложно привыкнуть к специфике работы с ним.

2. Traefik

GitHub: https://github.com/traefik/traefik
Docs: https://doc.traefik.io/traefik/
Плюсы:

• простота настройки;
• встроенный Dashboard;
• поддержка Let’s Encrypt "из коробки";
• продвинутые функции: Canary, Circuit Breaker, Rate Limiting.

Минусы:

• меньше примеров в интернете;
• нужно уверенно понимание CRD.

3. Istio Gateway

GitHub: https://github.com/istio/istio/tree/master/manifests/charts/gateway
Docs: https://istio.io/latest/docs/reference/config/networking/gateway/
Istio Gateway является частью сервис-меша Istio, которая может использоваться как Ingress-прокси на основе Envoy Proxy.

Плюсы:

• глубокая интеграция с сервис-мешем (Istio);
• продвинутые функции: Canary, L7-политики, мониторинг;
• поддержка mTLS, tracing, metrics.

Минусы:

• сложность внедрения;
• высокие требования к ресурсам;
• крайне избыточен, если нужны только простые маршруты.

4. HAProxy Ingress

GitHub: https://github.com/haproxytech/kubernetes-ingress
Docs: https://www.haproxy.com/documentation/kubernetes-ingress/
Плюсы:

• высокая производительность.
• поддержка TCP/UDP-маршрутизации.

Минусы:

• меньше документации;
• менее активное сообщество, по сравнению с NGINX и Traefik.

Итоги

Подведем краткий итог:

• если вам необходим относительно простой и надежный контроллер – NGINX Ingress Controller;
• если у вас уже есть сервис-меш, или даже сам istio – Istio Gateway;
• нужна сверхвысокая производительность – Haproxy Ingress;
• необходим быстрый старт с кучей функций – Traefik.

И вот теперь, дорогие мои читатели, если вы не просто прочитали статью, а еще и выбрали из нее то, что вам подходит, и сами развернули это, то – ваш кластер готов к деплою приложений, поздравляю!