Блог

Я создал службу, и каждая служба создает новый балансировщик нагрузки, я не хочу создавать новый балансировщик нагрузки для каждой службы. Для этого я нашел решение ingress controller, но этого не происходит.

Я попытаюсь описать нужные вам объекты просто словами.

Вам не нужно создавать балансировщик нагрузки для каждой службы. Когда вы используете входной контроллер (например, nginx), сам входной контроллер будет балансировщиком нагрузки типа. Все ваши другие сервисы должны быть чем-то вроде типа ClusterIP.

После этого вы можете решить, как связать ваши службы ClusterIP с балансировщиком нагрузки Nginx: создайте вход для каждой службы или один вход, который предоставляет доступ к каждой службе на основе некоторого правила (например, пути, как @harsh-manvar показывает в сообщении выше).

Когда вы говорите «этого не происходит», было бы хорошо, если бы вы могли предоставить подробную информацию о вашей настройке.

Для того чтобы входной контроллер Nginx работал, он должен быть определен либо как тип службы NodePort, либо как LoadBalancer. В примерах, приведенных в документации nginx, используется LoadBalancer. Однако LoadBalancer работает только тогда, когда ваш кластер поддерживает этот объект (это означает запуск в большинстве облачных провайдеров, таких как AWS / GCP / Azure / DigitalOcean или более новых версиях minikube). С другой стороны, NodePort предоставит входной контроллер на узле Kubernetes, где он запускается (при использовании minikube это обычно означает своего рода виртуальную машину, которую затем необходимо перенаправить на порт, чтобы она была доступна).

Чтобы использовать ingress в локальной среде, вы можете заглянуть в minikube. Все, что вам нужно, это запустить minikube addons enable ingress , и он развернет для вас контроллер nginx. После этого все, что вам нужно сделать, это определить вход, и в зависимости от ваших настроек вам может потребоваться использовать kubectl port-forward для переадресации порта 80 на модуле контроллера nginx на локальный порт на вашем компьютере.

Существуют разные типы сервисов: ClusterIP, NodePort, LoadBalancer и ExternalName. Вы можете указать это в spec.type. На самом деле по умолчанию, если не указано, используется не LoadBalancer, а ClusterIP, поэтому в вашем случае просто оставьте type: LoadBalancer определение и используйте ваше ServiceName в качестве серверной части вашего входного ресурса. Пример:

 spec:
  rules:
  - host: your.fully.qualified.host.name
    http:
      paths:
      - backend:
          serviceName: your-internal-service-name
          servicePort: 80
        path: /
  

Имейте в виду, что для некоторых облачных провайдеров также существует возможность использовать внутренний балансировщик нагрузки без общедоступного IP. Это делается путем добавления аннотации к конфигурации сервиса. Для Azure AKS это выглядит так:

 metadata:
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
  

Для GKE от Google аннотация cloud.google.com/load-balancer-type: "Internal"

  apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: ingress
      annotations:
        kubernetes.io/ingress.class: "nginx"
        certmanager.k8s.io/cluster-issuer: wordpress-prod
        nginx.ingress.kubernetes.io/rewrite-target: /
    spec:
      tls:
      - hosts:
        - test.test.com
        secretName: prod
      rules:
      - host: test.test.com
        http:
          paths:
          - path: /service-1
            backend:
              serviceName: service-1
              servicePort: 80
          - path: /service-2
            backend:
              serviceName: service-2
              servicePort: 5000
  

Разделяя здесь документацию для ingress, предназначенную для нескольких сервисов, вы можете перенаправить на мультисервисный.

Используя это, вы можете получить доступ к таким сервисам, как

https://test.test.com/service-1

https://test.test.com/service-2

Следуя документации, вы должны сделать следующее. Дополнительная информация:kubernetes.github.com

 apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /$2
  name: rewrite
  namespace: default
spec:
  rules:
  - host: rewrite.bar.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /something(/|$)(.*)
  

Например, приведенное выше определение входа приведет к следующим перезаписям:

 rewrite.bar.com/something rewrites to rewrite.bar.com/
rewrite.bar.com/something/ rewrites to rewrite.bar.com/
rewrite.bar.com/something/new rewrites to rewrite.bar.com/new