Что такое Kubernetes probes?

Эти проверки выполняются в течение жизненного цикла PODа и описываются для каждого контейнера в PODе. Существует три типа проверок.

Startup probe запускается сразу после запуска PODа и используется для приложений с длительной процедурой инициализации. Другие проверки не запускаются, пока эта не завершится.

Readiness probe проверяет готовность PODа обрабатывать трафик (POD не добавляется в маршрутизацию трафика в сервисе, пока эта проверка не будет пройдена).

Liveness probe проверяет, работает ли приложение (в случае неудачной проверки процесс в контейнере PODа перезапускается). Readiness и Liveness — независимые и запускаются после прохождения Startup probe.

Существуют exec-, http-, tcp- и grpc-проверки. Проверки выполняются сервисом kubelet на узле, на котором запущен целевой POD.

Для чего при старте PODа создаётся контейнер с процессом pause?

Для PODа необходимо создать как минимум два контейнера. Один из них используется с pause для обеспечения общей сети (для этого создается network namespace в linux), что позволяет размещать все контейнеры PODа на одной ноде.

Что такое POD?

Группа контейнеров, соединенных общей сетью (общий localhost, общий внешний IP), может быть необходима для запуска взаимозависимых сервисов, которые используют общие файловые ресурсы или взаимодействуют друг с другом по сети (например, nginx + php-fpm).

Каким образом мы можем запустить в Kubernetes приложение (варианты: рабочую нагрузку, workload)?

Запускать PODы поодиночке можно, но обычно для этого используются более функциональные сущности в Kubernetes, такие как:

— Deployment, который используется для развертывания необходимого количества PODов на основе общего шаблона.
— StatefulSet, похожий на Deployment, но оптимизированный для работы с stateful-приложениями.
— DaemonSet, позволяющий развернуть один экземпляр приложения на каждом доступном узле и обычно используется для обслуживания узлов.
— Job, для запуска конечного процесса в контейнере и ожидания его успешного завершения с заданием политик запуска, таких как длительность и количество рестартов в случае сбоя.
— CronJob, аналогичный Job, но с возможностью запуска по расписанию и ведением логов успешных запусков.

ReplicationController считается устаревшим и практически не используется, на его место пришел Deployment.

Каким образом мы можем предоставить приложение, которое работает в нашем кластере, k8s нашим пользователям?

Если наше приложение работает через HTTP, мы можем использовать ingress-контроллер, который является реверс-прокси, интегрированным с Kubernetes API. Этот контроллер позволяет на основе custom resources маршрутизировать трафик по HTTP.

— Для ряда задач мы можем использовать Kubernetes service. Мы можем использовать тип externalIp, чтобы опубликовать порт сервиса на определенных IP-адресах наших нод. Тип nodePort позволяет опубликовать порт сервиса на всех нодах на произвольных портах в определенном диапазоне. Также есть опция trafficPriority: local, которая позволяет предпочитать PODы приложения, находящегося на локальной ноде при маршрутизации трафика.

— Для работы в облаке мы можем использовать тип loadBalancer. Это создает сервис, аналогичный nodePort, но с добавлением load balancer, который маршрутизирует трафик на ноды кластера через порты, выбранные для nodePort.

— Мы также можем использовать kubectl proxy для проброса порта сервиса локально на нашу машину, что может быть полезно для разработки.

— Используя nodeNetwork: true (нужно проверить, когда будет доступ в интернет), мы можем разрешить приложению, работающему в контейнере, использовать сеть ноды и занимать сетевые порты непосредственно на интерфейсах ноды.

Каким образом организована сеть в k8s?

В Kubernetes существуют три типа сетей:

1. Сеть узлов (node network) — это сеть, в которую объединены узлы кластера. В зависимости от используемого CNI-плагина, узлы могут работать либо в одной подсети, либо в нескольких.

2. Сеть POD-ов (pod network) — это сеть, в которой получают IP-адреса запускаемые POD-ы.

3. Сеть сервисов (service network) — это сеть, в которой получают адреса сервисы Kubernetes. Сети POD-ов и сервисов организуются с помощью CNI-плагинов.

Что такое CNI-плагин и для чего он нужен?

Аббревиатура CNI расшифровывается как Container Network Interface. Это представляет собой уровень абстракции над реализацией сети, позволяя работать с верхнеуровневыми абстракциями, такими как IP-адрес PODа и Endpoint. CNI-плагин отвечает за то, как это будет реализовано на физическом уровне. Существует множество CNI-плагинов (например, Flannel, Calico, Cilium), которые предлагают различный функционал и сетевую производительность. Они могут быть простыми, использующими L3-маршрутизацию, iptables и IPVS, а также достаточно сложными, обеспечивающими шифрование внутреннего трафика, поддержку VLAN, маршрутизацию на основе IBGP, поддержку EGRESS и другие функции.

Что такое CRI?

CRI означает интерфейс выполнения контейнера. Это спецификация, описывающая определенный уровень абстракции, позволяющая унифицированно использовать различные версии программного обеспечения для работы с контейнерами, такими как Containerd или CRI-O.

Как мы можем ограничить трафик в Kubernetes?

Для управления трафиком от приложений применяется объект networkpolicy. С его помощью можно контролировать как входящий, так и исходящий трафик на уровне неймспейса и компонентов, определенных в нем. Реализация поддержки данного объекта должна быть выполнена на уровне CNI-плагина.

Что такое service mesh и для чего он нужен?

Service mesh - это шаблон, который обеспечивает более гибкое управление трафиком в Kubernetes. Service mesh включает в себя control plane, который собирает информацию о кластере Kubernetes, запущенных в нем приложениях, а также дополнительных объектах (custom resources), которые могут быть описаны для настройки, и sidecar-контейнеры, которые обычно инжектируются в PODы автоматически с помощью mutation webhook. Sidecar-контейнеры являются прокси-серверами, перехватывающими входящий и исходящий трафик приложений в контейнерах и управляющими ими в соответствии с конфигурацией, полученной из control plane.

Что такое алерт в Prometheus?

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

Что такое ARP? Как это работает?

ARP означает протокол разрешения адресов (Address Resolution Protocol). Когда вы пытаетесь проверить IP-адрес в локальной сети, скажем, 192.168.1.1, ваша система должна преобразовать IP-адрес 192.168.1.1 в MAC-адрес. Это предполагает использование ARP для разрешения адреса, отсюда и его название. Системы хранят справочную таблицу ARP, в которой хранится информация о том, какие IP-адреса с какими MAC-адресами связаны. При попытке отправить пакет на IP-адрес система сначала сверится с этой таблицей, чтобы узнать, знает ли она уже MAC-адрес. Если значение кэшировано, ARP не используется.

Что такое service account?

Это уникальные элементы в API Kubernetes, которые называются учетными записями служб (ServiceAccounts) и связаны с определенным пространством имен и набором учетных данных, хранящихся в объектах Secrets в кластере. Эти пользователи (ServiceAccounts) предназначены главным образом для управления правами доступа к API Kubernetes для процессов, работающих в кластере Kubernetes.

🐳✈️ Docker ушёл из РФ! Инструкция по восстановлению доступа к Docker Hub для пользователей из России

Docker заблокировал доступ к своему главному репозиторию Docker Hub для пользователей из России. Однако есть способы обойти это ограничение и продолжить работу. В этом посте мы расскажем, как настроить альтернативные репозитории и зеркала.

Читать статью

Что такое bearer token?

Bearer token, также известный как токен учетной записи службы, представляет собой JWT-токен, который генерируется автоматически при создании новой учетной записи службы. Он содержит информацию о конкретной учетной записи службы и подписывается корневым сертификатом кластера. Этот токен сохраняется в объекте типа secret, который затем монтируется в POD по стандартному пути и периодически обновляется. При использовании данного токена процесс, запущенный в контейнере, получает доступ к API Kubernetes и может выполнять только разрешенные действия.

🔥 Кто такой DevOps-инженер?

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

В этом ролике кратко рассказывается про задачи DevOps и про необходимые навыки. Также самое интересное — зарплаты DevOps-инженера.

Смотреть видео

В чем разница между deployment и statefulset?

В наименованиях PODов есть различия: в deployment в качестве суффикса используется случайный хеш, а в statefulset — порядковый номер. Каждый POD в statefulset имеет особое доменное имя, по которому к нему можно обратиться (это особенно полезно, например, для mongodb, где клиент должен знать имена всех узлов кластера).

При работе с дисками (volume) statefulset использует алгоритм работы at most once, который ожидает завершения работы предыдущего POD с таким же именем, чтобы занять его привязанный диск, в то время как PODы deployment'а могут занять первый доступный диск.

В стратегиях перезапуска PODов при обновлении также имеются различия.

В чем отличие меток (labels) от аннотаций (annotations)?

Метки используются для создания механизмов поиска и группировки объектов, в то время как аннотации используются для добавления метаинформации к объекту. Например, с помощью аннотаций можно запретить service mesh внедрять sidecar-контейнеры в определенные поды.

Что такое role/clusterRole?

Роли определяют права с помощью наборов правил, которые включают:

— Группы API, описанные в официальной документации по apiGroups и выводимые командой kubectl api-resources;
— Ресурсы (например, pod, namespace, deployment и другие);
— Глаголы (например, set, update и другие);
— Имена ресурсов (resourceNames), которые используются в случае необходимости предоставления доступа к определенному ресурсу, а не ко всем ресурсам данного типа.

Каким образом мы можем разделять права в k8s?

Для управления правами в Kubernetes используется механизм RBAC (Role Based Access Control). В этой системе выделяются три группы объектов: пользователь (user) или учетная запись сервиса (service account), которая определяет субъект доступа; роль (role) или кластерная роль (clusterRole), определяющая разрешения; и привязка роли (roleBinding) или кластерной роли (clusterRoleBinding) к конкретному субъекту.