kubectl get pods -l app=demo,environment=production
Учебник Kubernetes The Hard Way (github.com/kelseyhightower/kubernetes-the-hard-way) от Келси Хайтауэр
контейнеры работают непосредственно на реальном ЦПУ и без дополнительных расходов на виртуализацию — точно так же, как обычные исполняемые файлы.
Не могу понять, почему людей пугают новые идеи. Лично меня пугают старые.
Джон Кейдж
Мы рекомендуем kops или Kubespray, в зависимости от ваших потребностей.
Если вам приходится самостоятельно размещать собственный кластер, можно использовать kops: это проверенный и широко применяемый инструмент, позволяющий создавать и администрировать кластеры промышленного уровня на AWS и Google Cloud.
• Является ли управляющий уровень высокодоступным? То есть должен ли ваш кластер продолжать работу, если его ведущий узел выйдет из строя или перестанет отвечать? Сможете ли вы при этом развертывать или обновлять приложения? Останутся ли ваши запущенные задания отказоустойчивыми без управляющего уровня (см. подраздел «Высокая доступность» на с. 67)?
• Является ли высокодоступным ваш пул рабочих узлов? То есть не прекратят ли выполнение ваши рабочие задания в случае, если из-за перебоев в работе выйдет из строя несколько рабочих узлов или даже целая зона доступности облака? Сможет ли ваш кластер автоматически выделить новые узлы, чтобы восстановить свою работоспособность, или же это потребует ручного вмешательства?
• Настроен ли ваш кластер безопасным образом? Используют ли его внутренние компоненты шифрование TLS и доверенные сертификаты для общения между собой? Назначены ли пользователям и приложениям минимальные права и полномочия для работы в кластере? Установлены ли для контейнера безопасные параметры по умолчанию? Имеют ли узлы излишний доступ к компонентам управляющего уровня? Установлены ли надлежащие контроль и аутентификация для доступа к внутренней базе данных etcd?
• Все ли сервисы в вашем кластере защищены? Если они доступны из Интернета, предусмотрены ли для них надлежащие аутентификация и авторизация? Является ли доступ к API кластера строго ограниченным?
• Соответствует ли ваш кластер установленным требованиям? Отвечает ли он стандартам для кластеров Kubernetes, определенным организацией Cloud Native Computing Foundation (см. раздел «Проверка на соответствие» на с. 146)?
• Полностью ли поведение узлов вашего кластера определяется конфигурацией, или, может быть, они настраиваются с помощью скриптов командной оболочки и затем живут своей жизнью? Операционная система и ядро на каждом узле требуют обновления, применения патчей безопасности и т.д.
• Проводится ли правильное резервное копирование данных вашего кластера, включая любое постоянное хранилище? Каков ваш процесс восстановления? Как часто вы тестируете восстановление?
• Как вы обслуживаете рабочий кластер после его настройки? Как выделяете новые узлы? Как выкатываются обновления Kubernetes и изменения конфигурации для имеющихся узлов? Как происходит масштабирование в ответ на нагрузку? Как вы следите за соблюдением политик?
Недоумение — начало познания.
Халиль Джебран
этом вам могут помочь инструменты для автоматического тестирования устойчивости, такие как Chaos Monkey от Netflix.
сконфигурировать кластер правильным образом, прочитав несколько книг или статей, и затем оставить его как есть. Вам придется регулярно проверять конфигурацию — например, убрав ведущий узел и убедившись, что все по-прежнему работает.
