История изменений

Сразу предупреждаю - у меня опыт работы с кубернетисом на уровне «развернул 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.

Сразу предупреждаю - у меня опыт работы с кубернетисом на уровне «развернул 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.

Сразу предупреждаю - у меня опыт работы с кубернетисом на уровне «развернул 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.

Сразу предупреждаю - у меня опыт работы с кубернетисом на уровне «развернул 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-а с его умолчальной изоляцией сетей друг от друга для меня было откровением что тут подход - всё разрешено по умолчанию.

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

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

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

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

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

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

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

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

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

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

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

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