Kubernetes блог

StatefulSet - это объект workload API, используемый для управления приложениями с отслеживанием состояния. Управляет развертыванием и масштабированием набора Pod'ов, а также предоставляет гарантии относительно порядка и уникальности этих Pod'ов. Подобно Deployment, StatefulSet управляет Pod'ами, основанными на идентичной спецификации контейнера. В отличие от Deployment, StatefulSet поддерживает липкую (sticky) идентификацию для каждого из своих Pod'ов. Эти Pod'ы созданы из одной и той же спецификации, но не являются взаимозаменяемыми: у каждого есть постоянный идентификатор, который он поддерживает при любом перепланировании. StatefulSet работает по тому же шаблону, что и любой другой контроллер. Вы определяете желаемое состояние в объекте StatefulSet, а контроллер StatefulSet делает все необходимые обновления, чтобы получить его из текущего состояния. Использование StatefulSet StatefulSet полезны для приложений, которым требуется одно или несколько из следующ...

Как и во всех других конфигах Kubernetes, для Deployment требуются поля apiVersion , kind и metadata . Deployment также нужен раздел .spec . Шаблон Pod .spec.template и .spec.selector являются единственными обязательными полями .spec. .spec.template является шаблоном Pod. Он имеет ту же схему, что и Pod, за исключением того, что он вложенный и не имеет apiVersion или kind. В дополнение к обязательным полям для Pod, шаблон Pod в Deployment должен указывать соответствующие метки и соответствующую политику перезапуска. Для меток, убедитесь, что они не перекрываются с другими контроллерами. Разрешается только .spec.template.spec.restartPolicy, равная Always, которая по умолчанию используется, если не указана. Реплики .spec.replicas - это необязательное поле, которое указывает количество желаемых Pod'ов. По умолчанию 1. Селектор .spec.selector - это обязательное поле, в котором указывается селектор меток для Pod'ов, предназначенных для этого Deployment. .spec.selector ...

Deployment входит в различные состояния (status) в течение своего жизненного цикла. Он может прогрессировать (progressing) при развертывании нового ReplicaSet, может быть завершен (complete) или может потерпеть неудачу при прогрессировании (fail to progress) . Прогрессирующий Deployment Kubernetes помечает Deployment как прогрессирующий (progressing) , когда выполняется одна из следующих задач: Deployment создает новый ReplicaSet. Deployment расширяет свой новейший ReplicaSet. Deployment сокращает свои старые ReplicaSet. Новые Pod'ы становятся готовыми или доступными (готовыми как минимум за MinReadySeconds). Вы можете следить за ходом Deployment, используя kubectl rollout status . Завершенный Deployment Kubernetes отмечает Deployment как завершенный (complete), если он имеет следующие характеристики: Все реплики, связанные с Deployment, были обновлены до последней указанной вами версии, что означает, что все запрошенные вами обновления были выполнены. Доступны все...

Вы можете приостановить Deployment , прежде чем запускать одно или несколько обновлений, а затем возобновить его . Это позволяет применять несколько исправлений между приостановкой и возобновлением, не вызывая ненужных развертываний . Например, с только что созданным Deployment (из предыдущего поста ): получите детали Deployment: kubectl get deploy Вывод: NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx 3 3 3 3 1m Получить статус развертывания: kubectl get rs Вывод: NAME DESIRED CURRENT READY AGE nginx-2142116321 3 3 3 1m Сделайте приостановление , выполнив следующую команду: kubectl rollout pause deployment.v1.apps/nginx-deployment Вывод: deployment.apps/nginx-deployment paused Затем обновите образ Deployment: kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 Вывод: deployment.apps/nginx-deployment image...

Вы можете масштабировать Deployment с помощью следующей команды: kubectl scale deployment.v1.apps/nginx-deployment --replicas=10 Вывод: deployment.apps/nginx-deployment scaled Предполагая, что в вашем кластере включено горизонтальное автоматическое масштабирование Pod'ов, вы можете настроить автоматическое масштабирование для вашего Deployment и выбрать минимальное и максимальное количество Pod'ов, которые вы хотите запустить, исходя из загрузки ЦП существующих Pod'ов. kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80 Вывод: deployment.apps/nginx-deployment scaled Пропорциональное масштабирование Deployments RollingUpdate поддерживают запуск нескольких версий приложения одновременно. Когда вы или автоматическое масштабирование масштабируете Deployment RollingUpdate, находящееся в середине развертывания (либо в процессе, либо в режиме паузы), контроллер Deployment балансирует дополнительные реплики в сущес...

Иногда вам может потребоваться откатить (rollback) Deployment ; например, когда Deployment работает нестабильно, например, происходят циклы сбоев. По умолчанию вся история развертывания (rollout) Deployment хранится в системе, так что вы можете откатиться в любое время (вы можете изменить это, изменив предел истории изменений). Примечание . Ревизия Deployment создается при запуске развертывания Deployment. Это означает, что новая ревизия создается только тогда, когда шаблон Pod для Deployment (.spec.template) изменяется, например, если вы обновляете метки или образы контейнера шаблона. Другие обновления, такие как масштабирование Deployment, не создают ревизию Deployment, так что вы можете упростить одновременное ручное или автоматическое масштабирование. Это означает, что при возврате к более ранней ревизии выполняется откат только части шаблона Pod для Deployment. Предположим, что вы сделали опечатку при обновлении Deployment, поставив имя образа как nginx:1.91 вместо nginx:1.9.1: ...

Следуйте приведенным ниже инструкциям, чтобы обновить свой Deployment: 1. Обновим Pod'ы nginx (созданные в предыдущем посте ), чтобы использовать образ nginx:1.9.1 вместо образа nginx:1.7.9. kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.9.1 Вывод: deployment.apps/nginx-deployment image updated Кроме того, вы можете отредактировать Deployment и изменить .spec.template.spec.containers[0].image с nginx:1.7.9 на nginx:1.9.1: kubectl edit deployment.v1.apps/nginx-deployment Вывод: deployment.apps/nginx-deployment edited Чтобы увидеть статус развертывания, запустите: kubectl rollout status deployment.v1.apps/nginx-deployment Вывод: Waiting for rollout to finish: 2 out of 3 new replicas have been updated... или deployment.apps/nginx-deployment successfully rolled out Получить более подробную информацию о вашем обновленном Deployment: После успешного развертывания вы можете пр...

Контроллер Deployment предоставляет декларативные обновления для Pod и ReplicaSets. Вы описываете желаемое состояние в Deployment, и контроллер Deployment изменяет фактическое состояние на желаемое состояние с контролируемой скоростью. Вы можете определить Deployments для создания новых ReplicaSets или для удаления существующих Deployments и принять все их ресурсы с новыми Deployments. Сценарии использования Deployment Ниже приведены типичные сценарии использования для Deployment: Создайте Deployment для развертывания ReplicaSet. ReplicaSet создает Pod'ы в фоновом режиме. Проверьте состояние развертывания, чтобы увидеть, насколько оно проходит успешно или нет. Объявите новое состояние Pod'ов, обновив PodTemplateSpec для Deployment. Создается новый ReplicaSet, и Deployment управляет перемещением Pod'ов из старого ReplicaSet в новый с контролируемой скоростью. Каждый новый ReplicaSet обновляет версию Deployment. Откат к более ранней версии Deployment, если текущее сос...

ReplicationController гарантирует, что указанное количество реплик Pod'ов выполняется в любой момент времени. Другими словами, ReplicationController обеспечивает постоянную доступность Pod'а или однородного набора Pod'ов. Сразу стоит отметить, что на данный момент рекомендуемым способом настройки репликации является использование контроллера Deployment, который в свою очередь настраивает ReplicaSet контроллер. Как работает ReplicationController Если Pod'ов слишком много, ReplicationController завершает работу дополнительных Pod'ов. Если их слишком мало, ReplicationController запускает больше Pod'ов. В отличие от созданных вручную Pod'ов, Pod'ы, поддерживаемые ReplicationController, автоматически заменяются в случае сбоя (fail), удаления (deleted) или заверешения (terminated). Например, ваши Pod'ы воссоздаются на узле после прерывистого обслуживания, такого как обновление ядра. По этой причине вам следует использовать ReplicationController, даже ес...

Цель контроллера ReplicaSet - поддерживать стабильный набор реплик (экземпляров) Pod'ов, работающих в любой момент времени. Как таковой, он часто используется, чтобы гарантировать наличие определенного количества идентичных Pod'ов. Как работает ReplicaSet ReplicaSet задается полями , включая селектор (selector) , который указывает, как идентифицировать Pod'ы, которые он может приобрести, количество реплик (replicas) , указывающих, сколько Pod'ов он должен поддерживать, и шаблон (template) Pod'ов , указывающий данные новых Pod'ов, которые он должен создать для соответствия критерию количества реплик. Затем ReplicaSet выполняет свое предназначение, создавая и удаляя Pod'ы по мере необходимости для достижения желаемого числа. Когда ReplicaSet нуждается в создании новых Pod'ов, он использует свой шаблон Pod'ов для их создания. Ссылка, которую ReplicaSet имеет на свои Pod'ы, осуществляется через поле metadata.ownerReferences Pod'ов, которое у...