Skip to content

Latest commit

 

History

History
47 lines (26 loc) · 3.88 KB

kubernetes.md

File metadata and controls

47 lines (26 loc) · 3.88 KB

Заметки по использованию kubernetes

Продакшн Кочерги использует kubernetes.

Возможно, внедрение k8s было ошибкой/преждевременным решением. Изначально я (Слава) искал возможность для организации zero-downtime deployments, и не хотел связываться с docker swarm как отмирающей технологией. А после первых экспериментов было уже сложно остановиться.

В этом документе собраны некоторые менее очевидные (для меня на текущем этапе) заметки, которые хочется зафиксировать.

k3s vs k8s

k3s проще в установке, поэтому пока что мы используем его.

Когда я начинал настраивать кластер, то ещё мало что понимал в k8s, поэтому взял k3s как минимальное и поэтому очевидно хорошее (до первых проблем) решение.

Проблем с k3s, в общем-то, нет, всё работает и всё настраиваемо.

Тем не менее:

  • когда-нибудь захочется переехать на полноценный k8s (поставленный через kubeadm или что-то ещё)
  • переезд вряд ли будет тривиальным, потому что надо будет придумать, как аккуратно перетащить данные из k3s sqlite-базы в etcd (или налить всё заново)
  • возможно, всё же стоило взять kubeadm, но время на эксперименты с kubernetes'ом пока что превысило все разумные сроки
  • при установке через kubeadm пришлось бы следить за обновлением сертификатов

Сеть

Private network

TODO. Пока что ноды общаются с мастером напрямую. Но живут в одном ДЦ, поэтому это не должно быть важно.

CNI

Из коробки k3s использует flannel, поэтому пока что мы используем его.

У flannel'а есть один недостаток: он не умеет в network policies, поэтому в текущий кластер будет менее комфортно пускать других разработчиков и запускать другие сервисы (типа lesswrong.ru).

Когда-нибудь надо будет посмотреть ближе на calico. К сожалению, после запуска продакшн-кластера сменить CNI будет уже сложнее. Ну что ж.

CSI (storage)

Используем hcloud-csi. В целом всё работает достаточно стабильно.

Из проблем: при потере PVC (почему-то, например, при удалении helm chart'а) не совсем очевидно, как подключить PV обратно к деплойменту.

То есть это точно возможно (и я пробовал это воспроизвести), но это достаточно нетривиально, незадокументированно и требует переписывания chart'ов вручную.

OOM / kswapd0

kswapd0 может убить хост. Заметки по этой проблеме тут: https://gitlab.com/kocherga/core/issues/157