Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Лучшие практики Kubernetes. Корректное отключение Terminate
Лучшие практики Kubernetes. Маппинг внешних сервисов
Все знают, насколько хорошо поддерживать ваши приложения в актуальном состоянии. Kubernetes и Docker могут сделать процесс обновления намного проще, так что вы сможете создать новый контейнер с обновленными зависимостями и легко его развернуть. Кроме обновления зависимости приложений, Kubernetes постоянно выполняет обновление функций и политик безопасности.
Таким образом, базовые узлы и инфраструктура Kubernetes должны находится в актуальном состоянии. В этой серии мы узнаем, как Google Kubernetes Engine может без проблем обновить кластер Kubernetes.
Итак, при обновлении кластера необходимо обновить мастера и узлы, причем мастера должны быть обновлены в первую очередь. Рассмотрим, как обновить оба элемента с помощью Google Kubernetes Engine. Эта система автоматически обновляет мастера по мере выпуска точечных релизов. Однако, как правило, он не станет обновляться до новой версии, например, 1.7-1.8, автоматически. Когда вы будете готовы перейти на новую версию, то можете просто нажать ссылку Upgrade available в консоли GKE, после чего на экране появится диалоговое окно. В нем имеется предупреждение, что изменение мастер-версии может занять несколько минут, в течение которых вы не сможете редактировать этот кластер, при этом во время обновления мастера ваши развертывания и сервисы будут продолжать нормальную работу. Однако вся инфраструктура, нуждающаяся в API Kubernetes, работать не будет.
Это означает, что QPTL и все приложения, использующие API Kubernetes для получения информации о кластере, отключатся, и вы не сможете внести в кластер никаких изменений.
Давайте посмотрим, как можно решить эту проблему, обновив мастер с нулевым временем простоя.
В то время как стандартный зональный кластер GKE поддерживает только одного мастера, вы можете создавать региональные кластеры, которые обеспечивают многозонные мастера высокой доступности. Поэтому при создании своего кластера обязательно выбирайте региональный вариант.
Ваши узлы и мастера будут автоматически создаваться в трех зонах, причем мастера будут иметь IP-адреса с балансировкой нагрузки. Это обеспечит бесперебойную работу API Kubernetes во время обновления.
При обновлении узлов существует несколько различных стратегий, которыми можно воспользоваться. Хочу заострить ваше внимание на двух вещах – плавающих обновлениях rolling updates и миграции с использованием пулов узлов.
Самый простой способ обновить узлы Kubernetes – это использовать rolling update, механизм обновления по умолчанию, который GKE использует для обновления ваших узлов. Он работает следующим образом.
Узлы старой версии один за другим выводятся из эксплуатации так, что в них перестают работать все модули. Затем эти узлы удаляются, а вместо них друг за другом появляются новые узлы обновленной версии Kubernetes. После того, как заработает один узел, другой переходит к процессу обновления, и так продолжается, пока все узлы не будут обновлены. Вы можете позволить GKE управлять этим процессом вместо вас, включив автоматическое обновление узлов в пуле узлов, выбрав параметр Enabled.
Если вы этого не сделаете, панель мониторинга GKE предупредит вас о том, когда будет доступно новое обновление. В этом случае, чтобы выполнить обновление, требуется кликнуть ссылку Automatic node updates и следовать инструкциям.
При этом очень важно убедиться, что ваши поды управляются с помощью набора реплик replica set, набора с сохранением данных stateful set или чего-то подобного. Тогда автономные поды не будут реструктурированы.
Хотя обновление rolling updates довольно просто выполняется с помощью GKE, у него все же имеется несколько недостатков. Один из них заключается в том, что при обновлении емкость вашего кластера уменьшается на один узел. Этот недостаток легко устраняется путем масштабирования пула узлов добавлением дополнительной емкости с последующим ее уменьшением по окончании обновления.
Кроме того, полностью автоматизированный характер rolling updates облегчает обновление, однако оставляет вам меньше возможностей контролировать этот процесс. Если что-то пойдет не так и вам придется откатиться на старую версию, потребуется время, чтобы остановить rolling updates и отменить уже внесенные изменения. Давайте посмотрим, как можно использовать пулы из нескольких узлов для обновления вашего кластера.
Итак, вместо обновления активного пула узлов при помощи rolling updates, вы создаете совершенно новый пул узлов, дожидаетесь запуска всех узлов, а затем переносите рабочие нагрузки по одному узлу за раз. Поскольку вы сами выполняете эти команды, то получаете больше контроля над процессом миграции, при этом GKE продолжает управлять вашими узлами.
Предположим, что кластер Kubernetes состоит из 3 виртуальных машин. Вы можете просмотреть узлы с помощью команды get nodes.
Чтобы создать новый пул узлов с именем pool-two, нужно использовать соответствующую команду, настроив ее точно таким же образом, как и команду для старого пула.
При желании вы также можете использовать графический интерфейс GUI для создания нового пула узлов. Для получения дополнительной информации по этому вопросу используйте ссылку Node pool creation, расположенную под этим видео.
Если вы снова проверите количество нодов, то обнаружите три новых узла с именем пула pool-two, однако поды все равно будут находиться на старых узлах.
Давайте переместим их в новый пул узлов, перенося по одному узлу за раз в режиме rolling. Для этого используем команду cordon для каждого старого узла, чтобы оградить их и предотвратить в них образование новых подов.
Как только все старые узлы будут ограждены, создание подов будет планироваться только в новых узлах. Это означает, что вы можете начать удалять поды из старых узлов, и Kubernetes будет автоматически планировать их создание в новых узлах. Затем вам понадобиться «осушить» каждый узел, что приведет к удалению всех подов в узле.
После того, как вы проделаете это для одного узла, убедитесь, что новые поды готовы и уже работают, а потом переходите к следующему узлу. Если во время переноса у вас возникли какие-либо проблемы, выполните uncordon для старого пула, а затем выполните cordon и drain для нового пула. При этом поды будут автоматически перенесены обратно в старый пул. Как только все поды будут благополучно перенесены, можно удалить старый пул. Для этого замените пул по умолчанию на пул, который вы хотите удалить.
Google Kubernetes Engine позволяет вам поддерживать свой кластер Kubernetes в актуальном рабочем состоянии с помощью всего лишь нескольких щелчков мыши. Я настоятельно рекомендую использовать региональные кластеры GKE для мастеров высокой доступности и автоматическое обновления узлов, чтобы обеспечить корректное и беспроблемное обновление.
Если вам нужен дополнительный контроль процесса обновления узла, его можно обеспечить с помощью пулов, не отказываясь от преимуществ платформы управления, которую предоставляет GKE.
Если вы не используете GKE, то для обновления узлов вашего кластера применяйте метод плавающего обновления rolling updates или пул узлов node pools. Но помните, что в этом случае вам нужно вручную добавить новые узлы к кластеру и собственноручно выполнить критические обновления, что может быть не совсем просто.
Продолжение будет совсем скоро…
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Лучшие практики Kubernetes. Корректное отключение Terminate
Лучшие практики Kubernetes. Маппинг внешних сервисов
Все знают, насколько хорошо поддерживать ваши приложения в актуальном состоянии. Kubernetes и Docker могут сделать процесс обновления намного проще, так что вы сможете создать новый контейнер с обновленными зависимостями и легко его развернуть. Кроме обновления зависимости приложений, Kubernetes постоянно выполняет обновление функций и политик безопасности.
Таким образом, базовые узлы и инфраструктура Kubernetes должны находится в актуальном состоянии. В этой серии мы узнаем, как Google Kubernetes Engine может без проблем обновить кластер Kubernetes.
Итак, при обновлении кластера необходимо обновить мастера и узлы, причем мастера должны быть обновлены в первую очередь. Рассмотрим, как обновить оба элемента с помощью Google Kubernetes Engine. Эта система автоматически обновляет мастера по мере выпуска точечных релизов. Однако, как правило, он не станет обновляться до новой версии, например, 1.7-1.8, автоматически. Когда вы будете готовы перейти на новую версию, то можете просто нажать ссылку Upgrade available в консоли GKE, после чего на экране появится диалоговое окно. В нем имеется предупреждение, что изменение мастер-версии может занять несколько минут, в течение которых вы не сможете редактировать этот кластер, при этом во время обновления мастера ваши развертывания и сервисы будут продолжать нормальную работу. Однако вся инфраструктура, нуждающаяся в API Kubernetes, работать не будет.
Это означает, что QPTL и все приложения, использующие API Kubernetes для получения информации о кластере, отключатся, и вы не сможете внести в кластер никаких изменений.
Давайте посмотрим, как можно решить эту проблему, обновив мастер с нулевым временем простоя.
В то время как стандартный зональный кластер GKE поддерживает только одного мастера, вы можете создавать региональные кластеры, которые обеспечивают многозонные мастера высокой доступности. Поэтому при создании своего кластера обязательно выбирайте региональный вариант.
Ваши узлы и мастера будут автоматически создаваться в трех зонах, причем мастера будут иметь IP-адреса с балансировкой нагрузки. Это обеспечит бесперебойную работу API Kubernetes во время обновления.
При обновлении узлов существует несколько различных стратегий, которыми можно воспользоваться. Хочу заострить ваше внимание на двух вещах – плавающих обновлениях rolling updates и миграции с использованием пулов узлов.
Самый простой способ обновить узлы Kubernetes – это использовать rolling update, механизм обновления по умолчанию, который GKE использует для обновления ваших узлов. Он работает следующим образом.
Узлы старой версии один за другим выводятся из эксплуатации так, что в них перестают работать все модули. Затем эти узлы удаляются, а вместо них друг за другом появляются новые узлы обновленной версии Kubernetes. После того, как заработает один узел, другой переходит к процессу обновления, и так продолжается, пока все узлы не будут обновлены. Вы можете позволить GKE управлять этим процессом вместо вас, включив автоматическое обновление узлов в пуле узлов, выбрав параметр Enabled.
Если вы этого не сделаете, панель мониторинга GKE предупредит вас о том, когда будет доступно новое обновление. В этом случае, чтобы выполнить обновление, требуется кликнуть ссылку Automatic node updates и следовать инструкциям.
При этом очень важно убедиться, что ваши поды управляются с помощью набора реплик replica set, набора с сохранением данных stateful set или чего-то подобного. Тогда автономные поды не будут реструктурированы.
Хотя обновление rolling updates довольно просто выполняется с помощью GKE, у него все же имеется несколько недостатков. Один из них заключается в том, что при обновлении емкость вашего кластера уменьшается на один узел. Этот недостаток легко устраняется путем масштабирования пула узлов добавлением дополнительной емкости с последующим ее уменьшением по окончании обновления.
Кроме того, полностью автоматизированный характер rolling updates облегчает обновление, однако оставляет вам меньше возможностей контролировать этот процесс. Если что-то пойдет не так и вам придется откатиться на старую версию, потребуется время, чтобы остановить rolling updates и отменить уже внесенные изменения. Давайте посмотрим, как можно использовать пулы из нескольких узлов для обновления вашего кластера.
Итак, вместо обновления активного пула узлов при помощи rolling updates, вы создаете совершенно новый пул узлов, дожидаетесь запуска всех узлов, а затем переносите рабочие нагрузки по одному узлу за раз. Поскольку вы сами выполняете эти команды, то получаете больше контроля над процессом миграции, при этом GKE продолжает управлять вашими узлами.
Предположим, что кластер Kubernetes состоит из 3 виртуальных машин. Вы можете просмотреть узлы с помощью команды get nodes.
Чтобы создать новый пул узлов с именем pool-two, нужно использовать соответствующую команду, настроив ее точно таким же образом, как и команду для старого пула.
При желании вы также можете использовать графический интерфейс GUI для создания нового пула узлов. Для получения дополнительной информации по этому вопросу используйте ссылку Node pool creation, расположенную под этим видео.
Если вы снова проверите количество нодов, то обнаружите три новых узла с именем пула pool-two, однако поды все равно будут находиться на старых узлах.
Давайте переместим их в новый пул узлов, перенося по одному узлу за раз в режиме rolling. Для этого используем команду cordon для каждого старого узла, чтобы оградить их и предотвратить в них образование новых подов.
Как только все старые узлы будут ограждены, создание подов будет планироваться только в новых узлах. Это означает, что вы можете начать удалять поды из старых узлов, и Kubernetes будет автоматически планировать их создание в новых узлах. Затем вам понадобиться «осушить» каждый узел, что приведет к удалению всех подов в узле.
После того, как вы проделаете это для одного узла, убедитесь, что новые поды готовы и уже работают, а потом переходите к следующему узлу. Если во время переноса у вас возникли какие-либо проблемы, выполните uncordon для старого пула, а затем выполните cordon и drain для нового пула. При этом поды будут автоматически перенесены обратно в старый пул. Как только все поды будут благополучно перенесены, можно удалить старый пул. Для этого замените пул по умолчанию на пул, который вы хотите удалить.
Google Kubernetes Engine позволяет вам поддерживать свой кластер Kubernetes в актуальном рабочем состоянии с помощью всего лишь нескольких щелчков мыши. Я настоятельно рекомендую использовать региональные кластеры GKE для мастеров высокой доступности и автоматическое обновления узлов, чтобы обеспечить корректное и беспроблемное обновление.
Если вам нужен дополнительный контроль процесса обновления узла, его можно обеспечить с помощью пулов, не отказываясь от преимуществ платформы управления, которую предоставляет GKE.
Если вы не используете GKE, то для обновления узлов вашего кластера применяйте метод плавающего обновления rolling updates или пул узлов node pools. Но помните, что в этом случае вам нужно вручную добавить новые узлы к кластеру и собственноручно выполнить критические обновления, что может быть не совсем просто.
Продолжение будет совсем скоро…
Немного рекламы :)
Спасибо, что остаётесь с нами. Вам нравятся наши статьи? Хотите видеть больше интересных материалов? Поддержите нас, оформив заказ или порекомендовав знакомым, облачные VPS для разработчиков от $4.99, уникальный аналог entry-level серверов, который был придуман нами для Вас: Вся правда о VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps от $19 или как правильно делить сервер? (доступны варианты с RAID1 и RAID10, до 24 ядер и до 40GB DDR4).
Dell R730xd в 2 раза дешевле в дата-центре Equinix Tier IV в Амстердаме? Только у нас 2 х Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ТВ от $199 в Нидерландах! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — от $99! Читайте о том Как построить инфраструктуру корп. класса c применением серверов Dell R730xd Е5-2650 v4 стоимостью 9000 евро за копейки?
