Контроллеры в Kubernetes: Deployment, написание спецификации

Как и во всех других конфигах 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 должен соответствовать .spec.template.metadata.labels, иначе он будет отклонен API.

В версии API apps/v1 .spec.selector и .metadata.labels не устанавливаются по умолчанию в .spec.template.metadata.labels, если они не установлены. Поэтому они должны быть установлены явно. Также обратите внимание, что .spec.selector является неизменным после создания Deployment в apps/v1.

Deployment может прервать Pod'ы, чьи метки соответствуют селектору, если их шаблон отличается от .spec.template или если общее количество таких Pod'ов превышает .spec.replicas. Он создает новые Pod'ы с .spec.template, если количество Pod'ов меньше желаемого.

Примечание. Не следует создавать другие Pod'ы, метки которых соответствуют этому селектору, либо напрямую, либо путем создания другого Deployment, либо путем создания другого контроллера, такого как ReplicaSet или ReplicationController. Если вы это сделаете, то первый Deployment решит, что он создал эти другие Pod'ы. Kubernetes не останавливает вас от этого.

Если у вас есть несколько контроллеров, которые имеют перекрывающиеся селекторы, контроллеры будут бороться друг с другом и не будут вести себя правильно.

Стратегия

.spec.strategy определяет стратегию, используемую для замены старых Pod'ов новыми. .spec.strategy.type может быть “Recreate” или “RollingUpdate”. “RollingUpdate” является значением по умолчанию.

Воссоздать Deployment

Все существующие Pod'ы уничтожаются до создания новых, когда .spec.strategy.type==Recreate.

Развертывание обновлений Deployment

Deployment обновляет Pod'ы по мере обновления, когда .spec.strategy.type==RollingUpdate. Вы можете указать maxUnavailable и maxSurge для управления процессом непрерывного обновления.

Максимально допустимая недоступность

.spec.strategy.rollingUpdate.maxUnavailable - это необязательное поле, в котором указывается максимальное количество Pod'ов, которые могут быть недоступны в процессе обновления. Значение может быть абсолютным числом (например, 5) или процентом желаемых Pod'ов (например, 10%). Абсолютное число рассчитывается из процента округлением к меньшему. Значение не может быть 0, если .spec.strategy.rollingUpdate.maxSurge равно 0. Значение по умолчанию - 25%.

Например, если для этого значения установлено значение 30%, старый ReplicaSet может быть уменьшен до 70% требуемых Pod'ов сразу после запуска развертывания обновления. После того, как новые Pod'ы будут готовы, старый ReplicaSet можно еще больше уменьшить, а затем увеличить новый ReplicaSet, гарантируя, что общее количество Pod'ов, доступных в течение всего времени обновления, составляет не менее 70% от требуемых Pod'ов.

Максимальное превышение

.spec.strategy.rollingUpdate.maxSurge - это необязательное поле, в котором указывается максимальное количество Pod'ов, которое можно создать свыше требуемого количества Pod'ов. Значение может быть абсолютным числом (например, 5) или процентом желаемых Pod'ов (например, 10%). Значение не может быть 0, если MaxUnavailable равно 0. Абсолютное число вычисляется из процента путем округления в большую сторону. Значение по умолчанию составляет 25%.

Например, если для этого значения установлено значение 30%, новый ReplicaSet можно сразу же увеличить при запуске непрерывного обновления (rolling update), чтобы общее количество старых и новых Pod'ов не превышало 130% от требуемых Pod'ов. После того, как старые Pod'ы были завершены, новый ReplicaSet можно еще больше увеличить, гарантируя, что общее количество Pod'ов, запущенных в любое время во время обновления, составляет не более 130% от требуемых Pod'ов.

Срок выполнения в секундах

.spec.progressDeadlineSeconds - это необязательное поле, в котором указывается количество секунд, в течение которых вы хотите подождать, пока Deployment будет выполнен, прежде чем система сообщит, что Deployment не удалось завершить. Появилось как условие с Type=Progressing, Status=False и Reason=ProgressDeadlineExceeded в статусе ресурса. Контроллер Deployment будет повторять попытку развертывания. В будущем, как только будет реализован автоматический откат, контроллер Deployment откатит развертывание, как только оно выполнит такое условие.

Если указано, это поле должно быть больше, чем .spec.minReadySeconds.

Минимальный срок готовности в секундах

.spec.minReadySeconds - это необязательное поле, в котором указывается минимальное количество секунд, в течение которых вновь созданный Pod должен быть готов без сбоя любого из его контейнеров, чтобы его можно было считать доступным. По умолчанию это 0 (Pod будет считаться доступным, как только он будет готов).

Откат к

Поле .spec.rollbackTo устарело в версиях API extensions/v1beta1 и apps/v1beta1 и больше не поддерживается в версиях API, запускающих apps/v1beta2. Вместо этого следует использовать kubectl rollout undo.

Предел истории изменений

История изменений Deployment хранится в наборах ReplicaSet, которыми он управляет.

.spec.revisionHistoryLimit - это необязательное поле, в котором указывается количество старых ReplicaSets, которые необходимо сохранить, чтобы разрешить откат. Эти старые ReplicaSets используют ресурсы в etcd и заполняют выходные данные kubectl get rs. Конфигурация каждой версии Deployment хранится в ее ReplicaSets; следовательно, после удаления старого ReplicaSet вы теряете возможность отката к этой версии Deployment. По умолчанию будут сохранены 10 старых ReplicaSets, однако их идеальное значение зависит от частоты и стабильности новых Deployment.

Более конкретно, установка этого поля в ноль означает, что все старые ReplicaSets с 0 репликами будут очищены. В этом случае новый релиз Deployment не может быть отменен, так как его история изменений очищена.

Приостановлен

.spec.paused - необязательное логическое поле для приостановки и возобновления Deployment. Единственное различие между приостановленным Deployment и тем, который не приостановлен, состоит в том, что любые изменения в PodTemplateSpec приостановленного Deployment не будут вызывать новые развертывания, пока оно приостановлено. Deployment не приостанавливается по умолчанию при его создании.

Альтернатива Deployment

kubectl rolling update

kubectl rolling update обновляет Pod'ы и ReplicationControllers аналогичным образом. Но Deployment рекомендуются, поскольку они декларативны, на стороне сервера и имеют дополнительные функции, такие как откат к любой предыдущей ревизии, даже после того, как обновление будет выполнено.

Поиск по этому блогу

Kubernetes блог