Kubernetes блог

Cron Job создает Job'ы по расписанию. Один объект CronJob похож на одну строку файла crontab (таблицы cron). Он запускает работу периодически по заданному расписанию, написанному в формате Cron. Примечание. Все расписание CronJob: время основано на часовом поясе мастера, в котором запущено задание. Ограничения Cron Job Cron Job создает объект Job примерно один раз за время выполнения своего расписания. "Примерно", потому что есть определенные обстоятельства, когда могут быть созданы два Job, или Job не может быть создан. Поэтому Job'ы должны быть идемпотентными. Если для startDeadlineSeconds задано большое значение или не задано значение (по умолчанию), а для параметра concurrencyPolicy задано значение Allow, Job'ы всегда будут запускаться хотя бы один раз. Для каждого CronJob Контроллер CronJob проверяет, сколько расписаний он пропустил за время с его последнего запланированного времени до настоящего времени. Если пропущено более 100 расписаний, Job не зап...

Написание спецификации Job Как и во всех других конфигурациях Kubernetes, для работы требуются поля apiVersion, kind и metadata. Job также нуждается в разделе .spec. Pod шаблон .spec.template является единственным обязательным полем .spec. .spec.template является шаблоном pod. У него точно такая же схема, что и у pod, за исключением того, что он вложенный и не имеет apiVersion или kind. В дополнение к полям, обязательным для Pod, в шаблоне Pod в Job должны быть указаны соответствующие метки и соответствующая политика перезапуска. Разрешается только RestartPolicy, равное Never или OnFailure. Pod селектор Поле .spec.selector является необязательным. Почти во всех случаях вы не должны указывать это. Параллельные Job Существует три основных типа заданий, подходящих для выполнения Job: Непараллельные Job Обычно запускается только один Pod, если он не вышел из строя. Job завершается, как только его Pod успешно завершается. Параллельные Job с фиксированным количеством зав...

Job создает один или несколько Pod'ов и обеспечивает успешное завершение указанного количества из них. По мере успешного завершения Pod'ов, Job отслеживает успешные завершения. Когда определенное количество успешных завершений достигнуто, задача (т. е. Job) завершена. Удаление Job очистит созданные им Pod'ы. Простой случай - создать один объект Job, чтобы надежно запустить один Pod до его завершения. Объект Job запустит новый Pod, если первый Pod выйдет из строя или будет удален (например, из-за аппаратного сбоя узла или перезагрузки узла). Вы также можете использовать Job для параллельного запуска нескольких Pod'ов. Запуск примера Job Вот пример конфигурации Job. Он вычисляет значение пи до 2000 знаков и распечатывает его. Это займет около 10 секунд, чтобы завершить. apiVersion: batch/v1 kind: Job metadata: name: pi spec: template: spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi"...

Роль сборщика мусора в Kubernetes заключается в удалении определенных объектов, которые когда-то имели владельца, но у которых больше нет владельца. Владельцы и зависимые объекты Некоторые объекты Kubernetes являются владельцами других объектов. Например, ReplicaSet является владельцем набора Pod'ов. Собственные объекты называются зависимыми от объекта-владельца. Каждый зависимый объект имеет поле metadata.ownerReferences, которое указывает на владельца объекта. Иногда Kubernetes устанавливает значение ownerReference автоматически. Например, когда вы создаете ReplicaSet, Kubernetes автоматически устанавливает поле ownerReference каждого Pod в ReplicaSet. В версии 1.8 Kubernetes автоматически устанавливает значение ownerReference для объектов, созданных или принятых ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job и CronJob. Вы также можете указать отношения между владельцами и зависимыми, вручную установив поле ownerReference. Вот файл конфигурации д...

DaemonSet гарантирует, что все (или некоторые) узлы запускают копию Pod. Когда узлы добавляются в кластер, к ним добавляются Pod'ы. Когда узлы удаляются из кластера, эти Pod'ы удаляются. Удаление DaemonSet приведет к очистке созданных им Pod'ов. Некоторые типичные применения DaemonSet : запуск демона кластерного хранилища, такого как glusterd, ceph, на каждом узле. запуск демона сбора журналов на каждом узле, таком как fluentd или logstash. запуск демона мониторинга узла на каждом узле, таком как экспортер узлов Prometheus, агент Sysdig, collectd, Dynatrace OneAgent, агент AppDynamics, агент Datadog, агент New Relic, агент Ganglia gmond или агент Instana. В простом случае один DaemonSet, охватывающий все узлы, будет использоваться для каждого типа демона. Более сложная установка может использовать несколько DaemonSets для одного типа демона, но с разными флагами и/или разными запросами памяти и процессора для разных типов оборудования. Написание спецификации Daemon...

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: ...