Comments 11
А к какому подходу склоняется Флант?
Добрый день.
На самом деле мы практикуем любые схемы в зависимости от финаносв и специфики клиентов.
Однако более удобен для нас вариант с большим количеством меньших кластеров. Для нас управление большим количеством кластеров не является проблемой, так как у нас есть свой инструмент, который позволяет автоматически устанавливать, настраивать и обновлять все компоненты кластера с помощью конфигов, версий и CustomResource. При этом сохраняет единообразие всего ПО в кластере, будь то кластер в AWS, Azure, OpenStack или bare metal.
Совсем скоро мы планируем выпустить данный инструмент в Open Source.
На самом деле мы практикуем любые схемы в зависимости от финаносв и специфики клиентов.
Однако более удобен для нас вариант с большим количеством меньших кластеров. Для нас управление большим количеством кластеров не является проблемой, так как у нас есть свой инструмент, который позволяет автоматически устанавливать, настраивать и обновлять все компоненты кластера с помощью конфигов, версий и CustomResource. При этом сохраняет единообразие всего ПО в кластере, будь то кластер в AWS, Azure, OpenStack или bare metal.
Совсем скоро мы планируем выпустить данный инструмент в Open Source.
Не увеличивает ли ваш инструмент «радиус взрыва»?
Если придерживаться правила что все развертывания идут через CI/CD, то можно минимизировать этим риски до незначительных.
Если имеется ввиду, что допущенная ошибка в инструменте может привести к проблемам во всех кластерах, то мы минимизируем риски с помощью простых вещей:
— Покрываем все, что возможно тестами
— Ручное тестирование
— У нас есть 5 каналов обновлений, между которыми разделены все кластера: alpha, beta, early-access, stable, rock-solid и мы поэтапно выкатываем на каждый канал обновлений, на каждом из каналов изменения «отстаиваются» определенное время.
— Покрываем все, что возможно тестами
— Ручное тестирование
— У нас есть 5 каналов обновлений, между которыми разделены все кластера: alpha, beta, early-access, stable, rock-solid и мы поэтапно выкатываем на каждый канал обновлений, на каждом из каналов изменения «отстаиваются» определенное время.
кластер с 10-ю узлами и 100 pod'ами больше кластера с 1-м узлом и 10-ю pod'ами
O'Reilly?
Оригинал поста писался, видимо, британцами?
Дальше не читал.
По теме: держим по одному AWS EKS кластеру на dev/stage/prod окружения, приложения живут на отдельных WorkerNode группах.
Стоит отметить, что есть много способов, как измерять размер кластера, например: сумарное количество ядер/памяти в кластере, количество нод, количество сервисов (сколько разных процессов запущено), количество подов (сколько всего процессов запущено, включая реплики), по этому вполне уместно уточнить, что именно означает фраза «большой кластер» в данной статье. Это как в научной работе — в начале задаються дефиниции для используемых понятий
Используем схему с одним кластером на каждое окружение. Это удобно на наших скейлах.
Менеджатся они копсом и все конфигурации на кластерах совпадают (вплоть до задеплоеных хельм чартов). Сетевая изоляция достигается впервую очередь за счет того, что они находятся в разных VPC. За счет такой схемы, обновления продакшн кластера происходят без единого разрыва. Сначала деплоим sandbox кластер, вручную обновляем его, ловим все потенциальные ошибки, после этого стейдж (как правило) обновляется как по маслу, равно как и продакшн.
Что касается минусов такого подхода.
У нас не сотни приложений в кластере, поэтому грамотное использование скейлинга нод, подов, affinity/antiaffinity правил, taints/tolerations, limits/requests и instance groups, практически закрывает этот минус. Возможно на больших скейлах все немного сложнее, не могу сказать.
Похоже с таким кейсом мы не сталкивались.
Менеджатся они копсом и все конфигурации на кластерах совпадают (вплоть до задеплоеных хельм чартов). Сетевая изоляция достигается впервую очередь за счет того, что они находятся в разных VPC. За счет такой схемы, обновления продакшн кластера происходят без единого разрыва. Сначала деплоим sandbox кластер, вручную обновляем его, ловим все потенциальные ошибки, после этого стейдж (как правило) обновляется как по маслу, равно как и продакшн.
Что касается минусов такого подхода.
Отсутствие изоляции между приложениями
У нас не сотни приложений в кластере, поэтому грамотное использование скейлинга нод, подов, affinity/antiaffinity правил, taints/tolerations, limits/requests и instance groups, практически закрывает этот минус. Возможно на больших скейлах все немного сложнее, не могу сказать.
Невозможность локализовать зависимости приложений
Похоже с таким кейсом мы не сталкивались.
Недавний вебинар по этой теме от партнеров CNCF (SUSE): «One large cluster or lots of small ones? Pros, cons and when to apply each approach».
Sign up to leave a comment.
Проектирование Kubernetes-кластеров: сколько их должно быть?