Да, это не совсем корректный перевод. В оригинале это звучит вот так:
For each deployment that Kubernetes manages, it schedules sets of containers (known as pods) onto machines to be run (known as nodes).
Или «внутри машин для запуска (так называемые «узлы»)»
1) Service существует, но это примитивный tcp-балансировщик, а это значит, что, если один из pod возвращает ошибку, он просто транслирует её пользователю, а nginx может спросить у следующего. Это тонкий момент работы с абстракцией svc.
2) Ssl-offloader похож на Ingress, и это факт, но Ingress существует чуть более полугода, а проект несколько старше. Плюс сейчас prod переезжает на GCP и там мы решаем этот вопрос родными средствами платформы.
3) Удаление namespace сделано при принятии PR из фича-ветки в мастера.
4) Рассылка — хорошая идея, попробую реализовать.
Общение происходит через внутреннюю сетку, api-шлюз нужен для гибкой маршрутизации. Например, при внедрении нового сервиса, на который нужно перевести часть запросов со старых.
Да, это возможно, но я, пока, не исследовал как себя поведут pod при попытке запуститься на уже занятом порту.
К тому же, проблему связи с пользователем, в данном решении, решает всё-же Cloudflare, а не Kubernetes.
Парадигма контейнеров предусматривает хранение только статичной информации.
Динамика, пользовательский данные и логи хранить внутри контейнеров вообще не стоит, разве что, при условии монтирования в контейнер внешнего хранилища, например по iscsi.
В статье выше, в разделе «заметки на полях» есть замечательная фраза «Using the kube-proxy obscures the source-IP of a packet accessing a Service» А для меня важно, чтобы приложение знало этот самый source-IP.
К сожалению, исключительно вручную, Kubernetes это система управления контейнерами и работает она только с ними.
В последних релизах добавили возможность отдавать через kube-proxy статику, но, как я понял, её нужно раскладывать по серверам так же — вручную.
Кстати про ipsec.
Flannel входящая в состав Kubernetes создаёт единое адресное пространство для всех контейнеров в пределах кластера, что позволяет свободно разносить ноды кластера по разным ЦОДам.
Как только они добавят механизм резервирования в систему управления можно будет проводить «учения» на целом ЦОДе.
Но и сейчас, потеря мастер-ноды не нарушает работу сервиса.
Да, подобные playbook довольно легко написать для любой системы управления серверами, благо, даже запуск «вручную» у Kubernetes довольно прост. Соответственно и playbook написать не сложно, необходимо описать запуск нескольких исполняемых файлов с определёнными параметрами.
Другой вопрос, что эти параметры стоит изучить и написать свой рецепт, а не брать готовый, можно напороться на неприятные последствия.
У меня есть небольшой опыт использования CoreOS совместно с Docker. Выбор пал на эту ОС как на активно развивающуюся, настраиваемую конфигом и имеющую возможность кластеризоваться «by design».
К сожалению опыт прошёл в формате «продакшн тест» и, пока что, далее не продвинулся.
Я рассматривал Docker Swarm когда выбирал систему управления контейнерами. Выбор между Kubernetes и Docker Swarm сводится к необходимому функционалу. Это связано с тем, что изначальные задачи у них различаются.
Docker Swarm — способ использовать несколько машин как единую виртуальную среду для запуска контейнеров.
Kubernetes же позволяет не только запустить несколько машин, но и занимается балансировкой нагрузки, контролем запущенности и обновлением контейнеров (есть функция rolling-update позволяющая без простоя обновить pod'ы внутри RC).
Морочиться стоит в случае если:
Есть необходимость регулярного безпростойного деплоя
Необходимо обеспечить высокую отказоустойчивость
Необходимо обеспечить горизонтальную масштабируемость и балансировку не прибегая к «зоопарку» ПО
Вы не боитесь использовать в продакшне ПО находящееся в стадии альфа стадии разработки
Возможно я ошибаюсь на счёт Swarm, буду благодарен за дополнительную информацию по опыту работы с ним.
For each deployment that Kubernetes manages, it schedules sets of containers (known as pods) onto machines to be run (known as nodes).
Или «внутри машин для запуска (так называемые «узлы»)»
2) Ssl-offloader похож на Ingress, и это факт, но Ingress существует чуть более полугода, а проект несколько старше. Плюс сейчас prod переезжает на GCP и там мы решаем этот вопрос родными средствами платформы.
3) Удаление namespace сделано при принятии PR из фича-ветки в мастера.
4) Рассылка — хорошая идея, попробую реализовать.
К тому же, проблему связи с пользователем, в данном решении, решает всё-же Cloudflare, а не Kubernetes.
Динамика, пользовательский данные и логи хранить внутри контейнеров вообще не стоит, разве что, при условии монтирования в контейнер внешнего хранилища, например по iscsi.
В последних релизах добавили возможность отдавать через kube-proxy статику, но, как я понял, её нужно раскладывать по серверам так же — вручную.
Как-то так.
Почему именно такой выбор — напишу в статье.
Flannel входящая в состав Kubernetes создаёт единое адресное пространство для всех контейнеров в пределах кластера, что позволяет свободно разносить ноды кластера по разным ЦОДам.
Как только они добавят механизм резервирования в систему управления можно будет проводить «учения» на целом ЦОДе.
Но и сейчас, потеря мастер-ноды не нарушает работу сервиса.
А бага интересна, читал про неё, но лично не сталкивался. Надеюсь, что её всё-же устранят.
Другой вопрос, что эти параметры стоит изучить и написать свой рецепт, а не брать готовый, можно напороться на неприятные последствия.
К сожалению опыт прошёл в формате «продакшн тест» и, пока что, далее не продвинулся.
Docker Swarm — способ использовать несколько машин как единую виртуальную среду для запуска контейнеров.
Kubernetes же позволяет не только запустить несколько машин, но и занимается балансировкой нагрузки, контролем запущенности и обновлением контейнеров (есть функция rolling-update позволяющая без простоя обновить pod'ы внутри RC).
Морочиться стоит в случае если:
Возможно я ошибаюсь на счёт Swarm, буду благодарен за дополнительную информацию по опыту работы с ним.