Организация доступа к приложению в Kubernetes

Способы доступа к сервисам внутри кластера есть в официальной документации.

С помощью Linx Cloud можно обеспечить доступ к сервисам любым из этих способов:

NodePort

Открывается порт на worker-узле.

• С помощью Load Balancer платформа может сама создать балансировщики в отказоустойчивой конфигурации active-standby, в таком случае трафик прозрачно переключается на запасной балансировщик, если происходит отказ основного балансировщика. Для организации такой конфигурации используются два экземляра HAProxy с настроенным протоколом VRRP между ними.
• Чтобы подключить балансировщик к кластеру Kubernetes, нужно создать манифест с типом «сервис» и типом сервиса «Load Balancer». После деплоя созданного манифеста по умолчанию происходит обращение к OpenStack API Linx Cloud и создание балансировщика.
  Примечание

  Автоматически при создании балансировщика нагрузки ему назначается публичный IP-адрес, если в этом не нужно, то надо в манифест добавить аннотацию service.beta.kubernetes.io/openstack-internal-load-balancer: "true". Так будет создан внутренний балансировщик, к которому можно будет обращаться только из виртуальных сетей, которые доступны только вам через Linx Cloud.

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

Пример манифеста для внутреннего балансировщика нагрузки:

1apiVersion: v1
2kind: Service
3metadata:
4  name: nginx
5  labels:
6    k8s-app: nginx-backend
7  annotations:
8    service.beta.kubernetes.io/openstack-internal-load-balancer: "true"
9spec:
10  type: LoadBalancer
11  externalTrafficPolicy: Cluster
12  selector:
13    k8-app: nginx-backend
14  ports:
15    - port: 80
16      name: http
17      targetPort: http
18    - port: 443
19      name: https
20      targetPort: https

Ingress

Ingress-контроллер интегрируется с балансировщиком OpenStack в Linx Cloud. Бывает неудобно создавать баланcировщик для каждого сервисп, это может привести к трудностям в управлении балансировщиками на большом масштабе.

Но вместо нескольких балансировщиков на каждый сервис можно использовать развернутый Ingress Controller, настроенный на работу с отказоустойчивым балансировщиком и балансировку по DNS-именам. В таком случае создаются несколько ресурсов Ingress, использующих этот Ingress Controller: по одному ресурсу на каждый сервис, к которому надо предоставить доступ.

Более полную информацию о работе с Ingress читайте в здесь.