Сообщения

Сообщения за август, 2019

Хуки жизненного цикла контейнера (Container Lifecycle Hooks) в Kubernetes

Изображение
В этом посте описано, как управляемые kubelet контейнеры могут использовать инфраструктуру хуков жизненного цикла контейнера для исполнения кода, запускаемого событиями в течение их жизненного цикла управления. Аналогично многим языковым средам программирования (таким как Angular), которые имеют хуки жизненного цикла компонентов, Kubernetes предоставляет контейнерам хуки жизненного цикла . Хуки позволяют контейнерам узнавать о событиях в их жизненном цикле управления и запускать код, реализованный в обработчике, когда выполняется соответствующий хук жизненного цикла. Контейнеры открыты для двух хуков: PostStart Этот хук выполняется сразу после создания контейнера. Тем не менее, нет никакой гарантии, что хук выполнится перед ENTRYPOINT контейнера. Параметры не передаются обработчику. PreStop Этот хук вызывается непосредственно перед тем, как контейнер завершается из-за запроса API или события управления, такого как сбой проверки жизнеспособности, вытеснение, конфликт ресурсов и др...

Переменные среды контейнера в Kubernetes

Изображение
В этом посте описаны ресурсы, доступные для контейнеров в среде контейнеров (Container environment). Контейнерная среда Контейнерная среда Kubernetes предоставляет контейнерам несколько важных ресурсов: Файловая система, представляющая собой комбинацию образа и одного или нескольких томов. Информация о самом контейнере. Информация о других объектах в кластере. Контейнерная информация Имя хоста контейнера - это имя модуля (pod), в котором работает контейнер. Он доступен через команду hostname или вызов функции gethostname в libc. Имя Pod и пространство имен доступны как переменные среды через нисходящий API (Downward API). Пользовательские переменные среды из определения Pod также доступны для контейнера, как и любые переменные среды, указанные статически в образе Docker. Информация о кластере Список всех служб, которые работали при создании контейнера, доступен этому контейнеру в качестве переменных среды. Эти переменные среды соответствуют синтаксису ссылок Docker. Для с...

Контейнеры в Kubernetes: образы, использование частных реестров (Private Registry)

Изображение
Частные реестры могут требовать ключи для чтения образов с них. Учетные данные могут быть предоставлены несколькими способами: Использование Google Container Registry Один на каждый кластер автоматически настраивается в Google Compute Engine или Google Kubernetes Engine все модули (pods) могут читать частный реестр проекта Использование Amazon Elastic Container Registry (ECR) использовать роли и политики IAM для контроля доступа к репозиториям ECR автоматически обновляет учетные данные ECR Использование Oracle Cloud Infrastructure Registry (OCIR) использовать роли и политики IAM для контроля доступа к репозиториям OCIR Использование реестра Azure Container (ACR) Использование реестра IBM Cloud Container Настройка узлов для аутентификации в частном реестре все модули (pods) могут читать любые настроенные частные реестры требует настройки узла администратором кластера Предварительно загруженные образы все модули могут использовать любые образы, кэшированные на уз...

Контейнеры в Kubernetes: образы (images)

Изображение
Обычно вы создаете свой Docker образ и помещаете его в реестр, прежде чем обращаться к нему в модуле (pod) Kubernetes. Свойство image контейнера поддерживает тот же синтаксис, что и команда docker , включая частные реестры и теги. Обновление образов Политика извлечения по умолчанию - IfNotPresent, которая заставляет Kubelet пропускать вытягивание образа, если он уже существует. Если вы хотите всегда принудительно загружать образ, вы можете выполнить одно из следующих действий: установите для imagePullPolicy контейнера значение Always. опустите imagePullPolicy и используйте :latest в качестве тега для используемого образа. опустите imagePullPolicy и используйте конкретный тег для используемого образа. включите контроллер доступа AlwaysPullImages. Обратите внимание, что согласно Best Practices конфигурации рекомендуется избегать использования тега :latest. Создание мультиархитектурных образов с помощью манифестов Docker CLI поддерживает команду docker manifest с такими подк...

Архитектура Kubernetes: Мастер-Узел (Master-Node) взаимодействия

Изображение
В этом посте будут описаны пути связи между мастером (на самом деле, apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настроить свою установку для усиления конфигурации сети, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера). Кластер к Мастеру Все коммуникационные пути от кластера до мастер устройства заканчиваются на apiserver (ни один из других мастер компонентов не предназначен для предоставления удаленных служб). В типичном развертывании apiserver настроен на прослушивание удаленных подключений через безопасный HTTPS порт (443) с включенной одной или несколькими формами проверки подлинности клиента. Должна быть включена одна или несколько форм авторизации, особенно если разрешены анонимные запросы или токены учетной записи службы. Узлы должны быть снабжены общедоступным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver вместе с действительными учет...

Архитектура Kubernetes: управление узлами

Изображение
В отличие от модулей (pods) и служб (services), узел по сути не создается Kubernetes: он создается извне облачными провайдерами, такими как Google Compute Engine, или существует в вашем пуле физических или виртуальных машин. Поэтому, когда Kubernetes создает узел, он создает объект, который представляет узел. После создания Kubernetes проверяет, является ли узел действительным или нет. Например, если вы попытаетесь создать узел из следующего содержимого: { "kind": "Node", "apiVersion": "v1", "metadata": { "name": "10.240.79.157", "labels": { "name": "my-first-k8s-node" } } } Kubernetes создает объект узла внутри себя (представление) и проверяет узел путем проверки работоспособности на основе поля metadata.name. Если узел действителен - то есть, если все необходимые службы (services) запущены - он может запускать модуль (pod). В противном случае он игнорир...

Архитектура Kubernetes: узлы (Nodes)

Изображение
Узел - это рабочая машина в Kubernetes, ранее известная как minion . Узел может быть виртуальной машиной или физической машиной, в зависимости от кластера. Каждый узел содержит службы, необходимые для запуска модулей (pods), и управляется мастер компонентами (master components). Службы (services) на узле включают среду выполнения контейнера (container runtime), kubelet и kube-proxy. Статус узла Статус (состояние) узла содержит следующую информацию: Addresses (Адреса) Conditions (Условия) Capacity и Allocatable (Емкость и Распределение) Info (Информация) Статус узла и другие подробности об узле могут быть отображены с помощью следующей команды: kubectl describe node <имя-узла> Каждый раздел подробно описан ниже. Addresses (Адреса) Использование этих полей варьируется в зависимости от вашего облачного провайдера или конфигурации физического сервера. HostName: имя хоста, сообщаемое ядром узла. Может быть переопределено с помощью параметра kubelet --hostname-over...

Рекомендуемые метки в Kubernetes

Изображение
Вы можете визуализировать объекты Kubernetes и управлять ими с помощью большего количества инструментов, чем kubectl и панель инструментов. Общий набор меток позволяет инструментам работать интероперабельно, описывая объекты в общем виде, понятном для всех инструментов. В дополнение к поддержке инструментов, рекомендуемые метки описывают приложения таким образом, чтобы их можно было запрашивать. Метаданные организованы вокруг концепции приложения. Kubernetes не является платформой как сервисом (PaaS) и не имеет или не применяет формальное понятие приложения. Вместо этого приложения являются неформальными и описываются метаданными. Определение того, что содержит приложение, является свободным. Примечание . Это рекомендуемые метки. Они облегчают управление приложениями, но не требуются для каких-либо основных инструментов. Общие метки и аннотации имеют общий префикс: app.kubernetes.io. Метки без префикса являются частными для пользователей. Общий префикс гарантирует, что общие метки...

Селекторы полей (Field Selectors) в Kubernetes

Изображение
Селекторы полей позволяют выбирать ресурсы Kubernetes на основе значения одного или нескольких полей ресурсов. Вот несколько примеров запросов селектора полей: metadata.name=my-service metadata.namespace!=default status.phase=Pending Эта команда kubectl выбирает все Pod, для которых значение поля status.phase равно Running: kubectl get pods --field-selector status.phase=Running Примечание : Селекторы полей по сути являются фильтрами ресурсов. По умолчанию селекторы/фильтры не применяются, что означает, что выбраны все ресурсы указанного типа. Это делает следующие запросы kubectl эквивалентными: kubectl get pods kubectl get pods --field-selector "" Поддерживаемые поля Поддерживаемые селекторы полей зависят от типа ресурса Kubernetes. Все типы ресурсов поддерживают поля metadata.name и metadata.namespace. Использование неподдерживаемых селекторов полей приводит к ошибке. Например: kubectl get ingress --field-selector foo.bar=baz Error from serv...

Аннотации в Kubernetes

Изображение
Вы можете использовать аннотации Kubernetes для прикрепления произвольных неидентифицирующих метаданных к объектам. Клиенты, такие как инструменты и библиотеки, могут извлечь эти метаданные. Прикрепление метаданных к объектам Вы можете использовать метки (labels) или аннотации для прикрепления метаданных к объектам Kubernetes. Метки можно использовать для выбора объектов и для поиска коллекций объектов, которые удовлетворяют определенным условиям. Аннотации, напротив, не используются для идентификации и выбора объектов. Метаданные в аннотации могут быть маленькими или большими, структурированными или неструктурированными и могут включать символы, не разрешенные метками. Аннотации, как и метки, являются картами ключ/значение: "metadata": { "annotations": { "key1" : "value1", "key2" : "value2" } } Вот несколько примеров информации, которая может быть записана в аннотациях: Поля, управляемые декларативным...

Селекторы меток (label selectors) в Kubernetes

Изображение
В отличие от имен и UID, метки не обеспечивают уникальности. В целом, мы ожидаем, что многие объекты будут иметь одинаковые метки. С помощью селектора меток клиент/пользователь может идентифицировать набор объектов. Селектор меток является основным примитивом группировки в Kubernetes. В настоящее время API поддерживает два типа селекторов: на основе равенства и на основе набора. Селектор метки может быть сделан из нескольких требований, разделенных запятыми. В случае нескольких требований все должны быть выполнены, поэтому разделитель запятых действует как логический оператор AND (&&). Семантика пустых или неуказанных селекторов зависит от контекста, и типы API, которые используют селекторы, должны документировать их действительность (валидность) и значение. Примечание . Для некоторых типов API, таких как ReplicaSets, селекторы меток двух экземпляров не должны перекрываться в пространстве имен, иначе контроллер будет рассматривать это как конфликтующие инструкции и не може...

Метки (labels) в Kubernetes

Изображение
Метки - это пары ключ/значение (key/value), которые прикрепляются к объектам, таким как модули (pods). Метки предназначены для указания идентифицирующих атрибутов объектов, которые являются значимыми и релевантными для пользователей, но не подразумевают семантику основной системы. Метки могут использоваться для организации и выбора подмножеств объектов. Метки могут быть прикреплены к объектам во время создания и впоследствии добавлены и изменены в любое время. Каждый объект может иметь набор меток ключ/значение. Каждый ключ должен быть уникальным для данного объекта. "metadata": { "labels": { "key1" : "value1", "key2" : "value2" } } Метки позволяют выполнять эффективные запросы и наблюдения, и идеально подходят для использования в пользовательском интерфейсе и CLI. Неидентифицирующая информация должна быть записана с использованием аннотаций. Мотивация Метки позволяют пользователям отображать свои организ...

Пространства имен (namespaces) в Kubernetes

Изображение
Kubernetes поддерживает несколько виртуальных кластеров, поддерживаемых одним физическим кластером. Эти виртуальные кластеры называются пространствами имен . Когда использовать несколько пространств имен Пространства имен предназначены для использования в средах с множеством пользователей, распределенных по нескольким командам или проектам. Для кластеров с несколькими десятками пользователей вам вообще не нужно создавать или думать о пространствах имен. Начните использовать пространства имен, когда вам понадобятся функции, которые они предоставляют. Пространства имен обеспечивают область для имен. Имена ресурсов должны быть уникальными в пространстве имен, но не во всех пространствах имен. Пространства имен не могут быть вложены друг в друга, и каждый ресурс Kubernetes может находиться только в одном пространстве имен. Пространства имен - это способ разделения ресурсов кластера между несколькими пользователями (через квоту ресурсов). В будущих версиях Kubernetes объекты в одном и ...

Имена объектов в Kubernetes

Изображение
Все объекты в API REST Kubernetes однозначно идентифицируются по Имени (Name) и UID . Для неуникальных предоставленных пользователем атрибутов Kubernetes предоставляет метки (labels) и аннотации (annotations) . Имена Имя (name) - это предоставленная клиентом строка, которая ссылается на объект в URL-адресе ресурса, например /api/v1/pods/some-name. Только один объект данного вида может иметь данное имя за раз. Однако, если вы удалите объект, вы можете создать новый объект с тем же именем. По соглашению имена ресурсов Kubernetes должны иметь максимальную длину 253 символа и состоять из буквенно-цифровых символов в нижнем регистре, - (дефиса), и . (точки), но некоторые ресурсы имеют более конкретные ограничения. Например, вот файл конфигурации с именем Pod'а как nginx-demo и именем контейнера как nginx: apiVersion: v1 kind: Pod metadata: name: nginx-demo spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 UID UID - это строка...

Управление Kubernetes объектами

Изображение
Инструмент командной строки kubectl поддерживает несколько различных способов создания и управления объектами Kubernetes. В этом посте представлен обзор различных подходов. Методы управления Предупреждение : объект Kubernetes должен управляться с использованием только одного метода. Смешивание методов для одного и того же объекта приводит к неопределенному поведению. 1 Техника управления: Императивные команды Работает c живыми объектами Рекомендуемая среда: Разрабатываемые проекты Кривая обучения: наименьшая 2 Техника управления: Конфигурация императивного объекта Работает c отдельными файлами Рекомендуемая среда: Производственные проекты Кривая обучения: умеренная 3 Техника управления: Конфигурация декларативного объекта Работает c каталогами файлов Рекомендуемая среда: Производственные проекты Кривая обучения: наивысшая Императивные команды При использовании императивных команд пользователь работает непосредственно с живыми объектами в кластере. Пользователь...