Узнайте о службе в Kubernetes, указании модулей, использовании служб для внешних рабочих нагрузок, федерации кластеров, kubectl и многом другом.
На этой странице вы найдете все, что вам нужно знать о службах в Kubernetes:
Contents
Что такое сервис в Kubernetes?
Для Kubernetes служба — это абстракция, представляющая собой набор логических модулей, в которых выполняется приложение или компонент, а также внедряющая политику доступа к этим модулям. Фактические модули эфемерны, Kubernetes гарантирует доступность указанных модулей и реплик, но не работоспособность каждого отдельного модуля. Это означает, что другие модули, которым необходимо взаимодействовать с этим приложением или компонентом, не могут полагаться на базовые IP-адреса отдельного модуля.
Службе также выделяется виртуальный IP-адрес (называемый в Kubernetes clusterIP), и она существует до тех пор, пока не будет явно уничтожена. Запросы к службе перенаправляются в соответствующие модули, поэтому служба служит стабильной конечной точкой, используемой для обмена данными между компонентами или приложениями. Для нативных приложений Kubernetes запросы также можно делать через API в apiserver Kubernetes, который автоматически предоставляет и поддерживает фактические конечные точки модулей в любой момент.
Дополнительные сведения см. в Документация по Kubernetes: Службы ›
Сравнение типов сервисов: ClusterIP, NodePort, LoadBalancer, Ingress
NodePorts, LoadBalancers и Ingress — это разные способы доставки внешнего трафика в кластер Kubernetes. Ниже мы объясним различия между этими типами услуг.
IP кластера
Служба ClusterIP — это тип службы по умолчанию в Kubernetes. Он создает службу внутри кластера Kubernetes, к которой могут обращаться другие приложения в кластере, не разрешая внешний доступ.
ClusterIP предоставляет следующее:
spec.clusterIp:spec.ports[*].portNodePort
Служба NodePort открывает определенный порт на всех узлах в кластере, и любой трафик, отправляемый на этот порт, перенаправляется в службу. Доступ к службе невозможен с IP-адреса кластера.
NodePort предоставляет следующее:
<NodeIP>:spec.ports[*].nodePort
spec.clusterIp:spec.ports[*].portLoadBalancer
LoadBalancer — это стандартный способ предоставления службы Kubernetes извне, чтобы к ней можно было получить доступ через Интернет. Если вы используете Google Kubernetes Engine (GKE), это создает балансировщик сетевой нагрузки с одним IP-адресом, к которому могут получить доступ внешние пользователи, а затем они перенаправляются на соответствующий узел в вашем кластере Kubernetes. Доступ к LoadBalancer можно получить так же, как к ClusterIP или NodePort.
LoadBalancer предоставляет следующее:
spec.loadBalancerIp:spec.ports[*].port
<NodeIP>:spec.ports[*].nodePort
spec.clusterIp:spec.ports[*].portВход
Ingress на самом деле не является типом службы. Он находится перед несколькими службами и выполняет интеллектуальную маршрутизацию между ними, обеспечивая доступ к вашему кластеру. Существует несколько типов контроллеров входящего трафика с различными возможностями маршрутизации. В GKE контроллер входящего трафика создает балансировщик нагрузки HTTP, который может направлять трафик к службам в кластере Kubernetes на основе пути или поддомена.
Указание модулей в службе
Службу в Kubernetes можно создать с помощью запроса API, передав определение службы, например:
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376В этом примере новая служба названа my-service и будет нацелена на TCP-порт 9376 на любом модуле с меткой метаданных "app=MyApp" . Kubernetes постоянно оценивает селектор меток службы, чтобы в любой момент определить, какие модули включены в службу. Это означает, что новый сервис может включать в себя существующие модули, которые уже соответствуют селектору меток.
Чтобы облегчить изменение портов в модулях/приложениях, Kubernetes поддерживает строки для targetPorts, поэтому каждый модуль в службе может предоставлять другой порт, если существует сопоставление с портом с общим именем. Это позволяет, например, изменить номер порта, который модули предоставляют в следующей версии вашего серверного программного обеспечения, не нарушая работу клиентов.
Дополнительные сведения см. в Документация по Kubernetes: Определение службы ›
Использование служб для внешних рабочих нагрузок
Служба также может применяться к внешней рабочей нагрузке, позволяя использовать ту же абстракцию, например, для подключения к серверной части или базе данных, работающей вне Kubernetes. Затем поды могут подключаться к этой службе, не зная о конкретных конечных точках для рабочих нагрузок за пределами Kubernetes.
Для этого сервис должен быть определен, как в предыдущем разделе, но без селектора меток. После создания службы необходимо указать конечные точки для внешней рабочей нагрузки. Например:
kind: Endpoints
apiVersion: v1
metadata:
name: my-service
subsets:
- addresses:
- ip: 62.82.24.195
ports:
- port: 9376Весь входящий трафик my-service будет направляться прямо в конечную точку 62.82.24.195:9376.
Дополнительные сведения см. в Документация по Kubernetes: Службы без селекторов ›
Типы услуг
Самый простой тип службы по умолчанию — ClusterIP . Он предоставляет кластеру Kubernetes внутренний адрес ClusterIP службы. Другие типы допускают различные политики доступа к службе и включают в себя:
NodePort— предоставляет сервис на указанном номере порта на всех узлах в кластере Kubernetes. Это означает, что входящий запрос к IP-адресу узла на указанном порту будет перенаправлен на ClusterIP службы.LoadBalancer— служба предоставляется так же, как в NodePort, но создает балансировщик нагрузки в облаке, где работает Kubernetes (если поддерживается облачным провайдером), который получает внешние запросы к службе. Затем он распределяет их между узлами кластера с помощью NodePort. Чтобы указать этот тип, добавьте эту строку в спецификацию:
type: LoadBalancerExternalName – возвращает псевдоним внешнему компоненту, находящемуся за пределами кластера Kubernetes. Входящий запрос службы направляется DNS-сервером Kubernetes на указанный внешний домен. Например, чтобы перенаправить трафик, отправленный на my-service, на my.database.example.com :
kind: Service
apiVersion: v1
metadata:
name: my-service
namespace: default
spec:
type: ExternalName
externalName: my.database.example.comДополнительные сведения см. в документации Kubernetes: Службы публикации — типы служб ›
Обнаружение службы
Обнаружение службы в Kubernetes может быть достигнуто через DNS кластера (рекомендуется) или с помощью переменных среды на узлах.
DNS-сервер отслеживает API Kubernetes на наличие новых сервисов и создает набор DNS-записей для каждого из них. Затем поды могут получать доступ к службам через стандартное разрешение имен DNS. Если в кластере используются пространства имен, то внешние модули должны квалифицировать пространство имен службы, например, путем вызова my-service.my-namespace вместо простого вызова my-service .
Переменные среды менее надежны, поскольку модуль может не получить доступ к службе, созданной после модуля. Kubernetes экспортирует набор переменных среды для каждой службы, которая в данный момент активна в кластере Kubernetes во время создания модуля. Эти переменные экспортируются на узел, где создается модуль, поэтому они становятся видимыми для модуля. Например, эти переменные (и другие) будут экспортированы для каждой из активных служб payments и orders:
PAYMENTS_SERVICE_HOST=10.0.0.11
PAYMENTS_SERVICE_PORT=6379
ORDERS_SERVICE_HOST=10.0.171.239
ORDERS_SERVICE_PORT=6379Но если orders служба еще не существовала во время создания пода, она orders не была бы видна поду через переменные среды.
Дополнительные сведения см. в Документация по Kubernetes: Discovering services ›
Мультикластерные службы с федерацией кластеров
Kubernetes Cluster Federation позволяет (федеративной) службе работать одновременно в нескольких кластерах Kubernetes. Кластеры могут быть распределены между различными облачными провайдерами, зонами доступности и даже частными облаками, если конечная точка API кластера и учетные данные зарегистрированы на сервере API федерации.
Новую федеративную службу можно создать, вызвав API федерации так же, как kube-apiserver для конкретного кластера вызывается для (не федеративной) службы (как описано в этой статье до сих пор). Федерация означает, что сервис будет сегментирован во всех кластерах Kubernetes, входящих в федерацию.
Модуль может получить доступ к федеративной службе аналогично обычной службе, добавив имя федерации. Например my-service.my-namespace.my-federation , DNS-сервер Kubernetes автоматически разрешает вызовы в ближайший (географически) кластер, где работает служба (в обычных обстоятельствах это будет сегмент службы в том же кластере, где находится модуль).
Состояние службы в каждом кластере автоматически отслеживается, и набор записей DNS поддерживается в актуальном состоянии. Такие записи устанавливаются иерархически. Например, запрос, отправленный в запись верхнего уровня:
my-service.mynamespace.my-federation.svc.example.com
может быть перенаправлен на любую (работоспособную) конечную точку службы в любом из федеративных кластеров (в любой зоне, регионе или поставщике). Однако запрос, отправленный в
my-service.my-namespace.my-federation.svc.europe-west1-d.example.com
будет перенаправлен на конечную точку в кластере внутри зоны доступности europe-west1-d.
Если в этой зоне не работает работоспособный сегмент службы, запрос будет переадресован в кластер в другой зоне доступности в регионе europe-west1. -уровень:
my-service.mynamespace.my-federation.svc.example.com
и, возможно, будет обрабатываться сегментом службы в другом регионе или даже у другого облачного провайдера.
Федерация обеспечивает высокую доступность сервисов, отказоустойчивость зоны доступности и встроенное обнаружение сервисов в нескольких зонах, регионах, поставщиках и локальных кластерах.
Дополнительные сведения см. в Документация по Kubernetes: Обнаружение межкластерных служб с использованием служб Federated Services ›
Общие операции с kubectl
Командная строка kubectl упрощает выполнение некоторых распространенных операций с сервисами Kubernetes:
- Создать службу . Можно указать, что все развернутые модули в данном развертывании являются частью новой службы. Например, эта команда создаст службу
my-nginx, нацеленную на TCP-порт 80 в любом модуле сrun: my-nginxметкой метаданных:
$ kubectl expose deployment/my-nginx- Описать службу — это полезно, чтобы убедиться, что служба была создана, как ожидалось, или узнать ее ClusterIP или конечные точки модулей, которые в настоящее время являются частью службы. Для описания услуги
my-nginx:
$ kubectl describe svc my-nginx- Список всех служб — чтобы просмотреть полный список служб, работающих в кластере, запустите
kubectl get services - Проверьте, запущена ли служба DNS Kubernetes : служба DNS должна быть запущена, чтобы обнаружение службы с помощью разрешения имен работало. Чтобы проверить, работает ли он в кластере, выполните:
$ kubectl get services kube-dns --namespace=kube-system- Удалить сервис —
kubectl deleteэто команда для удаления ресурсов Kubernetes. Например, чтобы удалитьmy-nginxзапуск службы:
$ kubectl delete svc my-nginxДля дальнейшего чтения см. документацию Kubernetes: kubectl ›
Резюме
Службы — это абстракция, которая позволяет изменять базовые модули (некоторые из них удаляются, некоторые создаются) без необходимости клиентам службы отслеживать, какие модули доступны в любой момент. Это делается с помощью кластерного IP-адреса службы. Чтобы предоставить службу внешнему миру, она должна быть определена как тип NodePort или LoadBalancer . Также можно перенаправлять запросы на обслуживание на внешний ресурс с помощью ExternalName типа службы. Это обеспечивает поддержку сценариев взаимодействия и миграции. Федеративная служба — это, по сути, обычная служба, реплицируемая в нескольких кластерах Kubernetes, которые могут находиться в разных зонах доступности, у облачных провайдеров или даже локально, поддерживая высокую доступность и отказоустойчивость зоны доступности.
