Книга «Kubernetes: Лучшие практики»

Привет, Хаброжители! Положитесь на опыт профессионалов, успешно применяющих и развивающих проект Kubernetes. Инженеры Microsoft предлагают лучшие приёмы оркестрации контейнеров. Их практики сложились в процессе разработки распределённых систем, на ответственных и нагруженных проектах. Вам останется лишь слегка адаптировать код. Книга идеально подойдет тем, кто уже знаком с Kubernetes, но ещё не умеет использовать его максимально эффективно. Вы узнаете всё, что необходимо для создания классного Kubernetes-приложения, в том числе: — Подготовка окружения и разработка приложений в Kubernetes. — Паттерны мониторинга и защиты ваших систем, управления обновлениями. — Сетевые политики Kubernetes и роли сервисных сетей в экосистеме. — Использование Kubernetes в задачах машинного обучения.

Сервисы в Kubernetes

Благодаря базовым правилам организации сети в Kubernetes и сетевым дополнениям, реализующим эти правила, развертываемые pod могут взаимодействовать только внутри одного кластера. Некоторые дополнения CNI назначают pod IP-адреса в одном адресном пространстве с узлами, поэтому теоретически, зная данный IP, вы можете подключиться к pod напрямую из-за пределов Kubernetes. Но это не самый эффективный способ доступа к сервисам, поскольку pod в Kubernetes по своей природе непостоянны. Представьте, что у вас есть функция или система, которой нужно обратиться к API, доступному в pod. Какое-то время схема может работать нормально, однако рано или поздно возникнет добровольное или принудительное прерывание, в результате которого данный pod исчезнет. Kubernetes, вероятно, создаст ему замену с новыми именем и IP-адресом, поэтому очевидно, что для его поиска нужен некий механизм. Здесь вам пригодится API для работы с сервисами.

Данный API позволяет назначать конечным точкам сервиса постоянные IP-адрес и порт в пределах кластера и автоматически привязывать их к подходящим pod. Этот магический процесс основан на упомянутых выше механизмах iptables и IPVS, работающих на уровне узлов Linux; он привязывает IP-адрес и порт сервиса к реальным IP-адресам конечной точки или pod. Контроллер, который отвечает за это, называется kube-proxy; он выполняется на каждом узле кластера, управляя правилами iptables.

При определении объекта Service необходимо указать тип сервиса. От этого зависит, где будет доступна конечная точка: только внутри кластера или за его пределами. Существует четыре основных типа сервисов, которые мы кратко обсудим в следующих подразделах.

Тип сервисов ClusterIP

Если не указать в спецификации сервиса его тип, то по умолчанию будет использоваться ClusterIP. Сервисам данного типа назначаются IP-адреса из выделенного диапазона CIDR. Эти адреса действительны на протяжении всего жизненного цикла сервисов и привязываются к IP-адресам и портам клиентских pod с помощью поля selector. Но, как вы увидите сами, в некоторых случаях селектор использовать нельзя. В спецификации сервиса также указывается его доменное имя. На этом основан механизм обнаружения внутри кластера, позволяющий рабочим заданиям с легкостью обращаться к другим сервисам в том же кластере, используя DNS-запросы. Например, если у вас есть спецификация сервиса, представленная ниже, и вам нужно сделать HTTP-вызов к этому сервису из другого pod внутри того же кластера, то вы можете использовать адрес web1-svc (при условии, что клиент и сервис находятся в одном пространстве имен):

apiVersion: v1
kind: Service
metadata:
 name: web1-svc
spec:
 selector:
 app: web1
ports:
- port: 80
 targetPort: 8081

Если вам нужен доступ к сервисам в других пространствах имен, то вы можете использовать доменные имена вида <имя_сервиса>.<название_пространства_имен>.svc.cluster.local.

При отсутствии в определении сервиса селектора для него можно определить API с конечными точками. В результате сервис будет доступен по заданным IP-адресу и порту, и для этого не требуется атрибут selector, который автоматически обновляет конечные точки из pod, соответствующих селектору. Это может пригодиться в ряде ситуаций, если у вас есть база данных, предназначенная для тестирования, но находящаяся за пределами кластера, и вы хотите, чтобы ваш сервис использовал вместо нее другую БД, развернутую в Kubernetes. Такие сервисы иногда называют неуправляемыми (headless), поскольку они, в отличие от обычных, не управляются контроллером kube-proxy, но позволяют работать с конечными точками напрямую, как показано на рис. 9.4


Тип сервисов NodePort

Сервисы типа NodePort привязывают свои IP-адреса и порты к портам высшего уровня на каждом узле кластера. Порты высшего уровня находятся в диапазоне от 30 000 до 32 767 и могут быть либо динамически назначены, либо явно заданы в спецификации сервиса. Они обычно используются в кластерах с локальным размещением или в самописных решениях, которые не поддерживают конфигурацию с автоматической балансировкой нагрузки. Для прямого доступа к сервису из-за пределов кластера используйте адрес вида <IP_узла>:<порт_узла>, как показано на рис. 9.5



Тип сервисов ExternalName

Сервисы типа ExternalName редко применяются на практике, но могут пригодиться для привязки постоянных внутренних доменных имен кластера к сервисам с внешними доменными именами. Типичный пример — внешняя база данных облачного провайдера с уникальным доменным именем, таким как mymongodb.documents.azure.com.

Строго говоря, это можно легко прописать в спецификации pod, используя переменную Environment (см. главу 6). Но лучше задействовать более общее внутреннее имя, такое как prod-mongodb. что позволит изменить базу данных, на которую оно ссылается, простым редактированием спецификации сервиса. В случае изменения переменной Environment вам пришлось бы перезапускать pod.

kind: Service
apiVersion: v1
metadata:
 name: prod-mongodb
 namespace: prod
spec:
 type: ExternalName
 externalName: mymongodb.documents.azure.com

Тип сервисов LoadBalancer

LoadBalancer — специальный тип сервисов, позволяющих автоматизировать взаимодействие с облачными провайдерами и другими программируемыми сервисами облачной инфраструктуры. С их помощью можно развернуть механизм балансировки нагрузки, предоставляемый облаком, в котором размещен кластер Kubernetes. Это означает, что в большинстве случаев сервис LoadBalancer будет работать примерно так же, как публично доступный балансировщик нагрузки от AWS, Azure, GCE, OpenStack и т.д. Однако каждый облачный провайдер предоставляет собственные аннотации для поддержки дополнительных возможностей, таких как сугубо внутреннее распределение нагрузки, установка параметров конфигурации для AWS ELB и т.д. В спецификации сервиса можно вдобавок указать IP-адрес балансировщика и допустимые диапазоны. Пример этого показан в следующем листинге и на рис. 9.6.

kind: Service
apiVersion: v1
metadata:
 name: web-svc
spec:
 type: LoadBalancer
 selector:
 app: web
 ports:
 - protocol: TCP
 port: 80
 targetPort: 8081
 loadBalancerIP: 13.12.21.31
 loadBalancerSourceRanges:
 - "142.43.0.0/16"

Объекты и контроллеры Ingress

Формально спецификация Ingress не считается типом сервиса, но это важный механизм для направления трафика к рабочим заданиям в Kubernetes. API сервисов поддерживает базовое распределение нагрузки на транспортном и сетевом уровнях (Layer 3/4). Но в реальности многие сервисы, которые развертываются в Kubernetes и не хранят свое состояние, нуждаются в управлении трафиком на более высоком, прикладном уровне — в частности, на уровне протокола HTTP.

API Ingress, по сути, представляет собой HTTP-маршрутизатор, позволяющий направлять запросы к отдельным клиентским сервисам с помощью правил на основе доменных имен и путей. Представьте, что сайт с доменным именем www.evillgenius.com имеет два пути, /registration и /labaccess, обслуживающиеся двумя разными сервисами, развернутыми в Kubernetes, reg-svc и labaccess-svc. Вы можете определить правило доступа, согласно которому запросы к www.evillgenius/registration будут передаваться сервису reg-svc и соответствующим pod; точно так же подходящие конечные точки сервиса labaccess-svc могут получать запросы, направленные к www.evillgenius.com/labaccess. API Ingress также поддерживает маршрутизацию на уровне узлов, позволяя указывать разные серверы в одном и том же правиле доступа. Кроме того, вы можете создать объект Secret с информацией о сертификатах для работы с TLS на порте 443. На случай, если путь не указан, обычно предусматривают обработчик по умолчанию, который возвращает нечто более полезное, чем стандартная страница с ошибкой 404.

Деталями конфигурации конкретных TLS-путей и обработчика по умолчанию занимается так называемый контроллер Ingress. Этот контроллер отделен от API Ingress и позволяет системным администраторам развертывать разные реализации, такие как NGINX, Traefik, HAProxy и т.д. В отличие от других контроллеров Kubernetes, он не является частью системы; это сторонний механизм, который работает с динамической конфигурацией через API Ingress. Самая распространенная реализация контроллера Ingress, NGINX, частично поддерживается проектом Kubernetes, но имеет множество аналогов, как открытых, так и коммерческих:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: labs-ingress
 annotations:
  nginx.ingress.kubernetes.io/rewrite-target: /
spec:
 tls:
 - hosts:
  - www.evillgenius.com
  secretName: secret-tls
rules:
- host: www.evillgenius.com
 http:
 paths:
 - path: /registration
 backend:
  serviceName: reg-svc
  servicePort: 8088
 - path: /labaccess
 backend:
  serviceName: labaccess-svc
  servicePort: 8089

Рекомендации по использованию сервисов и контроллеров Ingress

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

• Ограничьте количество сервисов, к которым нужно обращаться из-за пределов кластера. В идеале большинство сервисов должны иметь тип ClusterIP, а доступными снаружи должны быть только сервисы, действительно нуждающиеся в этом.
• Если сервисы, которые должны быть доступны снаружи, работают преимущественно по HTTP/HTTPS, то лучше всего использовать API и контроллер Ingress в сочетании с прокси-сервером для поддержки TLS. Некоторые типы контроллеров Ingress имеют встроенную поддержку ограничения частоты запросов, переопределения заголовков, аутентификации OAuth, наблюдаемости и прочих возможностей, которые можно не реализовывать в самих приложениях.
• Выберите контроллер Ingress с поддержкой возможностей, необходимых для безопасного управления трафиком ваших рабочих заданий. Выберите какую-то одну реализацию и используйте ее во всех своих промышленных средах, поскольку разные контроллеры предоставляют специфические аннотации, которые затрудняют перемещение кода между кластерами Kubernetes.
• Исследуйте возможности контроллера Ingress, который предоставляет ваш облачный провайдер, и попробуйте вынести инфраструктуру, необходимую для управления трафиком, за пределы кластера. Но убедитесь, что по-прежнему можете управлять этой инфраструктурой с помощью конфигурационных файлов Kubernetes.
• Если ваши API в основном доступны снаружи, то обратите внимание на специализированные контроллеры Ingress, такие как Kong и Ambassador. Они поддерживают тонкую настройку рабочих заданий, основанных на API. NGINX; Traefik и другие решения тоже позволяют конфигурировать API, но являются не столь гибкими по сравнению со специализированными прокси-серверами.
• При развертывании контроллеров Ingress в Kubernetes в виде рабочих заданий на основе pod убедитесь, что они высокодоступны, и агрегируйте показатели их производительности. В целях обеспечения их адекватного масштабирования используйте метрики, но в то же время не забудьте предусмотреть резервные ресурсы, чтобы не терять соединения с клиентами при изменении масштаба.

Об авторах

Брендан Бернс — известный инженер Microsoft Azure и соучредитель открытого проекта Kubernetes. Занимается созданием облачных приложений уже больше десяти лет.

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

Дейв Штребель работает архитектором глобальных облачных систем в Microsoft Azure и занимается открытыми облачными технологиями и Kubernetes. Он принимает активное участие в открытом проекте Kubernetes, помогая с релизами новых версий и возглавляя группу SIG-Azure.

Лахлан Эвенсон — руководитель команды контейнерных вычислений в Microsoft Azure. Его практические уроки и выступления на конференциях помогли огромному количеству людей перейти на Kubernetes.

Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 25% по купону — Kubernetes

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.