Pull to refresh

Comments 16

По моему мнению, лучше развернуть Kubernetes поверх AWS, и избежать многих минусов, перечисленных в статье. Миграция между облачными(и self-hosted) решениями будет намного проще, в добавок k8s очень активно развивается.
Kubernetes тоже не лишён минусов, fault tolerant master так и не запилили, например.
Master HA можно запилить самому, есть руководство, но скоро видимо запилят это в новый kubeadm

Можно ссылку на руководство? Вы уверены что речь идёт о мастере, который задеплоен на несколько датацентров (aka availability zone) и он остаётся доступен при падении 1 из них? Вроде бы этим занимается подпроект Ubernetes.

http://kubernetes.io/docs/admin/high-availability/

Оно несколько топорное, но надеюсь что это все будет автоматизировано в будущем

Это руководство для мастера, который устойчив к падению нод в датацентре, но не всего датацентра. Да и вообще не ясно как это сделать поверх etcd. Ведь если у меня 2 датацентра, а для консенсуса RAFT требует 2/3, 3/5, и т.д., то как тут сделать fault tolerant etcd. Об этом же написано в issue https://github.com/kubernetes/kubernetes/issues/21124


В общем не путайте людей, в kubernetes все еще этого нет.

А я и ни слова не говорил про отказустойчивость между датацентрами.
FYI Если у вас 2 датацентра, то нет возможности решить split-brain problem.
А зачем нужен этот зоопарк, когда GC уже имеет k8s в своем составе (что более чем логично) и практически готов к использованию сразу же? Кроме того k8s при желании можно развернуть где угодно, о чем верно написано.
не можем запускать больше 1 сервиса на 1 инстансе из-за конфликта портов

Есть же Application Balancer
Интеграция с CloudWatch и AutoScalingGroup, которая позволяет регулировать количество EC2 инстансов в ECS кластере в зависимости от количества запущенных контейнеров.

Можно об этом поподробнее?

Потому я и написал:


Примечание: я не смотрел на новый AWS ALB, возможно там все по-другому.
Когда мы начинали использовать ECS (конец 2015 года)...

Про CloudWatch дал ссылку на тутлориал в статье.

UFO just landed and posted this here
«таким образом наиболее близкий аналог это Google Compute Engine (aka kubernetes-as-a-service)»: Google Compute Engine — это аналог EC2, Google Container Engine — это Kubernetes as a service.

Поправил, спасибо.

А теперь того, чего нам не хватает и почему для следующего проекта я буду использовать Kubernetes.

Именно так! Тоже с две недели поткали ЕЦС и лично я пришел вашему выводу!
Sign up to leave a comment.

Articles