Поды, развертывания и наборы реплик: объяснение ресурсов Kubernetes

Kubernetes не известен своей доступностью. Чтобы освоить Kubernetes, вам нужно понять, как его абстракции сочетаются друг с другом. Kubernetes поставляется с десятками типов ресурсов, которые вы можете использовать в своих приложениях. Рассмотрим роли наиболее часто используемых ресурсов.

стручки

Если есть один термин Kubernetes, который нужно выучить, это «Pod». Поды — это основная вычислительная единица, используемая Kubernetes. На них размещаются ваши работающие контейнеры. По этой причине pod часто сравнивают с экземпляром контейнера Docker.

Это сходство не является точным, поскольку в одном модуле Kubernetes может работать несколько контейнеров. Поды лучше рассматривать как «группу» контейнеров с общим контекстом выполнения. Окружение Pod изолировано; отдельные контейнерные среды внутри дополнительно изолированы.

Контейнеры в модуле всегда планируются на один и тот же узел Kubernetes. Они будут работать на одной физической машине и могут совместно использовать ресурсы хранения и сети.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image:latest

Приведенный выше манифест вручную создаст один под. Под будет запускать контейнер, используя образ my-image:latest.

Обычно вы не управляете подами напрямую в Kubernetes. Поды создаются в результате добавления других ресурсов, таких как развертывание (см. ниже). Вы должны относиться к своим модулям как к эфемерным единицам. Kubernetes контролирует Pod и может перенести его на другой узел, если ресурсы кластера станут ограниченными.

Наборы реплик

Наборы реплик (обычно записываются как ReplicaSets без пробела) — это еще один уровень абстракции поверх модулей. Наборы реплик гарантируют, что в любой момент времени будет запущено определенное количество идентичных подов.

При использовании ReplicaSets вы можете установить минимальное количество модулей Pod для своего приложения. Вы указываете количество подов, которые должны запускаться одновременно. Затем Kubernetes планирует достаточное количество модулей, чтобы обеспечить минимальную доступность, которую вы определяете. Помните, что каждый модуль может состоять из нескольких запущенных контейнеров, в зависимости от того, как настроено ваше приложение.

Когда под создается набором реплик, Kubernetes обновляет поле metadata.ownerReferences пода, чтобы включить идентификатор набора реплик. Затем ReplicaSet может установить контролируемые им поды, чтобы узнать, достигнута ли минимальная цель доступности.

Наборы реплик имеют поле replicas, которое определяет количество запускаемых подов. Измените это значение и примените обновленный манифест ReplicaSet к своему кластеру, чтобы Kubernetes перепланировал ваши поды в соответствии с новым количеством реплик.

Эта деталь подчеркивает важный момент, касающийся наборов реплик: Kubernetes только гарантирует, что количество запущенных подов будет в конечном счете соответствовать количеству реплик, которое вы указали. Если вы измените количество реплик, будет период времени, когда будет запущено больше или меньше модулей, чем указано в манифесте. ReplicaSet будет создавать или удалять поды до тех пор, пока нужное количество не будет работать.

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
  labels:
    my-label: my-value
spec:
  replicas: 3
  selector:
    matchLabels:
      my-label: my-value
  template:
    metadata:
      labels:
        my-label: my-value
    spec:
      containers:
        - name: app-container
          image: my-image:latest

Приведенный выше манифест будет запускать три реплики образа контейнера my-image:latest с использованием ReplicaSet. Вы можете изменить количество реплик, обновив значение в манифесте и повторно применив его (kubectl apply -f my-manifest.yml).

Развертывания

Хотя наборы реплик упрощают работу с модулями, они также редко используются напрямую. Развертывания — это абстракция поверх наборов реплик. Обычно развертывание создается при добавлении новой рабочей нагрузки в кластер.

Ресурсы развертывания позволяют выполнять декларативные обновления модулей Pod и наборов реплик. Они позволяют выполнять скользящие обновления ReplicaSets, при этом Pod переназначаются без простоя службы. Поды и наборы реплик заменяются по отдельности, что позволяет на короткое время сосуществовать старым и новым версиям.

Потребность в развертываниях возникла из-за исторического подхода Kubernetes к репликам. Наборы реплик произошли от контроллеров репликации. Контроллеры репликации предлагают функциональные возможности, аналогичные ReplicaSets, но со встроенной поддержкой масштабирования.

Однако контроллеры репликации не предлагали декларативное масштабирование. Вам пришлось вручную использовать kubectl roll-update, чтобы масштабировать реплики без простоев. Это противоречило декларативному подходу на основе манифеста других ресурсов Kubernetes.

По сравнению с наборами реплик основным преимуществом развертываний является их поддержка последовательных обновлений. Изменение количества реплик в наборе реплик не гарантирует, что какое-либо количество модулей останется в любом заданном состоянии во время развертывания. С развертыванием вы можете быть уверены, что ваше приложение продолжит обработку трафика, даже если развертывание еще не завершено.

Сегодня Kubernetes рекомендует использовать развертывания для представления ваших рабочих нагрузок. Ваши развертывания будут запускаться и масштабироваться ReplicaSet автоматически; ReplicaSets, в свою очередь, будет управлять вашими модулями. Вы можете выполнить последовательное обновление развертывания, обновив поле replicas в его манифесте. Затем Kubernetes гарантирует, что ваше приложение останется доступным на протяжении всего изменения, позволяя новым и старым подам временно сосуществовать.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    my-label: my-value
spec:
  replicas: 3
  selector:
    matchLabels:
      my-label: my-value
  template:
    metadata:
      labels:
        my-label: my-value
    spec:
      containers:
        - name: app-container
          image: my-image:latest

Приведенный выше манифест создаст развертывание, состоящее из трех реплик, каждая из которых запускает образ контейнера my-image:latest. Изменение значения replicas приведет к последовательному обновлению базовых наборов реплик и модулей.

Другие виды ресурсов

Три типа ресурсов, которые мы рассмотрели, являются наиболее распространенными объектами, с которыми вы столкнетесь при работе с Kubernetes. Они используются для настройки рабочих нагрузок вашего приложения и управления вашими контейнерами.

Вам нужно будет использовать другие типы ресурсов, поскольку вы больше работаете с Kubernetes. ConfigMaps и Secrets позволяют вводить конфигурацию в ваши поды, предоставляя им доступ к внешним значениям. Тома и постоянные тома предоставляют подам общую доступную для записи файловую систему, которую можно использовать для хранения данных вместо эфемерного хранилища по умолчанию, которое теряется при выходе из пода.

Дополнительный набор ресурсов помогает управлять сетевыми параметрами вашей рабочей нагрузки. Службы позволяют отображать набор модулей как единую сетевую службу с одним IP-адресом. Ingress позволяет вам предоставлять услуги извне. Они направляют трафик в ваш кластер к службе назначения на основе таких атрибутов, как имя хоста, порт и URL-адрес.

Наконец, есть мета-ресурсы, описывающие ваш кластер. Пространства имен используются для изоляции отдельных рабочих нагрузок, предотвращая конфликты имен. Обычно вам следует создавать новое пространство имен для каждой из ваших независимых рабочих нагрузок. Узлы — это своего рода ресурс, представляющий физические машины, на которых работают ваши поды. На каждом узле обычно размещается несколько модулей. Kubernetes решает, как планировать рабочие нагрузки на основе доступности каждого узла и ограничений, которые вы применяете.

Вы можете просмотреть полный список ресурсов для своего кластера, запустив kubectl api-resources. В дополнение к встроенным ресурсам рабочие нагрузки могут добавлять свои собственные определения пользовательских ресурсов (CRD), которые позволяют создавать новые типы объектов. Kubernetes автоматически предоставляет конечные точки API для пользовательских определений ресурсов.

Заключение

Изучение Kubernetes означает знакомство с новыми абстракциями и терминологией. Несмотря на то, что это обеспечивает широкую поверхность API, каждый объект Kubernetes имеет относительно узкую цель.

Вы часто сможете придерживаться высокоуровневых абстракций, таких как развертывания. Вам не нужно микроуправлять основными типами ресурсов, такими как поды, если только у вас нет сложных требований, которые нельзя решить с помощью одних только развертываний и наборов реплик.