Kubernetes блог

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