Вопросы по кубернетесу

1. Тут на вкус и цвет.
2. Да, обновляется быстро, слишком старый не бери, раньше придётся обновлять минорную версию.
3. Всё так. NFS, Ceph, etc. Если ты упомянул OpenStack, то там должны быть свои провайдеры для хранения данных.
4. Сложнее менеджить.
5. Про калико ничего не скажу.
6. В один скинуть норм, но я бы production вынес в отдельный кластер всё таки. Ну и namespace ограничивают только логически ресурсы. Из коробки любой под может обратиться к любому поду из другого namespace. Нужно настраивать Network Policy для ограничения хождения траффика.

1. Лучше брать ту, что лучше знаешь, последней версии. Наверняка потом она ещё чёрт знает сколько не будет обновляться, потому что некогда и лень.
2. Бери самую последнюю, что есть у провайдера. Алсо, managed хорошо конечно, можно и поддержку подолбить, если что пойдёт не так, но если есть ресурсы на самостоятельную поддержку, лучше конечно самому поднимать.
3. В openstack в комплекте к куберу своё всё идёт. Cinder называется, block storage. Можно и внешнее что-то использовать, я думаю, а надо ли?
4. Сильно от базы зависит и архитектуры приложения. Лично я бы предпочёл виртуалки под базу, а проксю держать в кубере.
5. Тут от задачи зависит, у этих штук совершенно разный подход. Проблем с чем?
6. Лучше не пускать разрабов вообще в прод кластер. Пусть либо minikube ставят, либо отдельный поднимать. По моему опыту многие разрабы даже не оч в докер умеют, про кубер вообще молчу.

Сразу предупреждаю - у меня опыт работы с кубернетисом на уровне «развернул k3s на трех виртуалках в HA-режиме на потыкать»

3. Хранилище. ... Не очень понятно, есть ли тут какой-то «стандарт-де факто».

А его нет. Для bare metal инсталляций можешь попробовать longhorn - ставится нативно, использует место на самих нодах(по умолчанию кладет тома в /var/lib/longhorn). Уровень реплики настроишь по желанию, по дефолту там ЕМНИП 3(если нод в кластере достаточно).

А так в общем-то - либо NFS(и кластерная ФС под ним для отказоустойчивости, ага), либо кластерные ФС типа ceph. Rook(то есть считай тот же ceph) как раз можно развернуть поверх кубернетиса, но я так не делал.

СУБД. Для сервисов нужен постгрес. Планирую его тоже запускать на отдельном сервере, т.к. много слышал, что в кубернетесе СУБД запускать неправильно. Правда не понял, почему. В перспективе сделать репликацию для устойчивости

Кубер вообще на мой дилетантский взгляд плохо заточен под non-persistent контейнеры - слишком много телодвижений с ними приходится делать. Зато stateless на нём шикарный получается, если конфиги/секреты в etcd упихать.

Сеть. Как я понял, два основных варианта это Flannel и Calico. С Flannel у меня всё заработало сразу, с Calico возникли проблемы (dashboard не открывается). ... Нормально ли будет остановиться на Flannel? Не приведёт ли к проблемам в будущем?

Либо в установленном мною k3s идет какой-то другой flannel, либо у тебя старая версия. Потому что в новой версии flannel сетевые политики(то есть файрвол) вполне себе работают - я проверял. Собственно после docker-а с его умолчальной изоляцией сетей друг от друга для меня было откровением что тут подход - всё разрешено по умолчанию.

Ну и помни о том, что во flannel ты ограничен ~250 контейнерами на одну ноду. В Calico, как я понял, таких жестких ограничений нет из-за другой схемы раздачи IP-адресов.

6. Всё в одном кластере. ... В основном волнует то, чтобы сервисы из других пространств имён не влияли на production. Я так понимаю, в кубере для этого есть все инструменты по ограничению ресурсов.

Почитай про подходы к развертыванию. Если кратко, то в идеале staging от production надо отделять, потому что даже настроенные квоты не гарантируют тебе того, что глючащий staging не повалит тебе соседние контейнеры. Ибо у контейнеров априори слабее изоляция, в отличии от полноценных VM.

Если по железу можешь позволить себе несколько кластеров, то для облегчения управления всем этим хозяйством можно заюзать Rancher или KubeSphere.

Кстати, нагло ворвусь в тред со своим вопросом(надеюсь ТС меня не проклянет):

Что есть по балансировщикам нагрузки, которые нативно интегрируются в кубер, и которые сохраняют исходный IP-адрес клиента(сервисы TCP и UDP, не чистый HTTP) и при этом раскидывают нагрузку по всем нодам?

MetalLB в режиме BGP? Traefik? Что-то еще, о чём я не знаю? Может какой-нибудь HAProxy хитро настраивается(я его подобным образом настраивал, но в режиме standalone, без Kubernetes)?

Коротко: Ос любая, версия куба чем новее, тем лучше (1.24), с хранилкой все плохо, но можно какой-нибудь S3 прикрутить сбоку, типа MinIO, СУБД упирается по производительности в IOPS, а тут (см. предыдущий пункт), везде использую Calico без проблем. И да, неймспейсы разграничивают только логически, никак иначе, ну или раскуривай rbac, чтобы нельзя было с конерктным сервисаккаунтом из одного неймспейса в другой ходить.

Кстати, посмотри в сторону kubespray.

можно какой-нибудь S3 прикрутить сбоку, типа MinIO

Для Persistent Volumes? Пишут что тормозить будет даже по сравнению с Ceph/NFS. Врут?

Тормозить будет все равно. В нормальном варианте это должен быть какой-нибудь storage по fc. Просто S3 сейчас де-факто стандарт для хранилки, и если что, потом будет проще уехать в облако.

Наверное речь про то, чтобы переписать приложения, используя S3 вместо доступа к ФС. Ну и БД. Я считаю это правильным вариантом, но не для тех случаев, когда надо пользоваться уже написанными кем-то приложениями, которые переписывать никто не будет.

Ну почему сразу «переписать приложение»? Просто использовать как бэкенд для создания pv/pvc, с соответствующим sc. Но для начала, конечно, неплохо бы хотя бы для себя сформулировать, зачем тебе стейтфул непременно нужен в кубе.

Ну мне надо как минимум потому, что гитлаб там хранит данные репозитория.

Вообще говоря, я не про то, зачем в кластере нужен персистенс, а про то, какие плюсы и минусы от установки туда того же гитлаба, например? Как по мне нормально, например, в кластере раннеры запускать, но с самим гитлабом преимущества подобного способа установки мне неочевидны. Просто точку отказа с инстанса гитлаба ты переносишь на NFS и сеть (в самом простом случае, когда персистенс на нфс). Либо нивелируешь преимущества, используя localpath и node affinity. С другой стороны, можно попробовать родную опестековскую хранилку, и тогда уже плюсов будет больше.

зачем в кластере нужен персистенс

Этот вопрос очень сложно воспринимать тем, кто пришел в мир кубера из мира виртуальных машин, где большая часть нагрузки как раз таки требует сохранения состояния :-)

Понятно, что даже тот же чистый Docker приучает что «данные - отдельно, код - отдельно». Это хорошо, это здорово. Но вот когда ты начинаешь масштабировать это(потому что привязываться к одной ноде - не круто), то у тебя в общем-то вариант либо Docker Swarm и трахайся со стораджем как хочешь(потому что готовых живых решений под него в общем-то уже и нет, только монтировать ручками с самой ноды и следить самому чтоб не крякнуло, а дальше - local provider), либо кубер.

Я сам в общем-то в кубер вкатываться не горел желанием(но только потому что Swarm в общем-то по большой части не требовал ничего нового учить, в отличие от кубера где сам подход ко ВСЕМУ несколько другой), но суровая реальность эээ... сурова :-)

Отвечу сам себе исходя из результатов «поигрался ещё немного».

1. ОС - Debian 11 Cloud Image. Ubuntu 20 тоже нормально, но там много лишнего мусора. Ubuntu 22 - там какой-то непонятный ворнинг cgroups blkio blabla, в целом работало, но я с этим ворнингом не разобрался и решил, что оно мне не надо.

2. Версия - предпоследняя (1.23.9). У некоторых компонентов (например калико) в документации не утверждается совместимость с 1.24. Хотя у меня оно работало, но поскольку я люблю старьё, то решил не торопиться. Честно говоря до сих пор не понимаю, в чём разница между этими версиями, отличия там в каких-то эзотерических нюансах.

3. Хранилище - тут два варианта. Я пользую CSI Cinder. Оно у моего провайдера само заказывает диск и подключает в нужную машину. У провайдера есть SAN (примерно 12k iops) и ceph (ещё меньше). Не фонтан, но жить можно. Такой диск переключается между машинами, то бишь если базу убил на одном сервере и кубер её перекинул на другой, то диск перелетит туда автоматом и всё будет хорошо. Есть local volume. Это когда ноды крутятся на компьютерах, к которым SSD подключен локально. Там iops запредельный, но понятно, что само никуда не перелетит, нужно всегда думать про кластерное ПО, всякие репликации и тд.

4. СУБД - в кубере крутится вообще без проблем. Самый простой вариант это тупо поднять контейнер с обычным докер-образом и подключить к нему cinder pvc, без всяких репликаций. Работает отлично. А вообще есть такая штука - называется postgres operator, там одним движением настраивается кластер postgres-серверов, который сам работает, сам реплицируется и тд, ещё и в S3 сам бэкапится. Шикарная штука, я руками такое не умею настраивать, например. Я CloudNativePG использую.

5. Для сети три варианта. Flannel это тупо сеть и всё. Calico даёт сеть плюс политики безопасности, типа фаервола. У меня не работало, т.к. там по дефолту инкапсуляция не включена, включается легко, просто про это надо знать (VXLAN). Третий вариант это Cilium. Это самая крутая и передовая технология. Там вообще всё есть, что только можно придумать. В целом надо его ставить, гугл себе его ставит, значит оно достаточно стабильно.

6. Всё в одном кластере это нормально. Неймспейсы всё разграничивают, можно и права раздать как надо, можно и лимиты на ресурсы раздать как надо, можно и приоритеты подам раздать и тд. Ну если богатые, то делайте два кластера, но и в одном нормально. Но - да, конечно надо с умом подходить, прописывать все лимиты где надо и тд.