Ресурс Ingress получает адрес от неправильного контроллера Ingress при использовании нескольких контроллеров Ingress-nginx

у нас есть кластер Kubernetes в AWS (EKS). В нашей настройке нам нужно иметь два контроллера ingress-nginx, чтобы мы могли применять разные политики безопасности. Для этого я использую

kubernetes.io/ingress.class и -ingress-class

Как было рекомендовано здесь, я создал один стандартный контроллер Ingress с обязательным 'по умолчанию. yaml ' из репозитория ingress-nginx.

Для создания второго контроллера входящего трафика я немного настроил развертывание входящего трафика из «обязательного.yaml». Я в основном добавил тег:

'env: internal'

к определению развертывания.

Соответственно, я также создал другую службу, указав тег env: internal, чтобы связать эту новую службу с моим новым контроллером входящего трафика. Пожалуйста, взгляните на мое определение yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-ingress-controller-internal
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    env: internal
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
      env: internal
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
        env: internal
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      # wait up to five minutes for the drain of connections
      terminationGracePeriodSeconds: 300
      serviceAccountName: nginx-ingress-serviceaccount
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: nginx-ingress-controller-internal
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.26.1
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
            - --ingress-class=nginx-internal
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          lifecycle:
            preStop:
              exec:
                command:
                  - /wait-shutdown

---

kind: Service
apiVersion: v1
metadata:
  name: ingress-nginx-internal
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    env: internal
spec:
  externalTrafficPolicy: Local
  type: LoadBalancer
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    env: internal
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https

После применения этого определения мой Ingress Controller создается вместе с новой службой LoadBalancer:

$ kubectl get deployments -n ingress-nginx
NAME                                READY   UP-TO-DATE   AVAILABLE   AGE
nginx-ingress-controller            1/1     1            1           10d
nginx-ingress-controller-internal   1/1     1            1           95m

$ kubectl get service -n ingress-nginx
NAME                     TYPE           CLUSTER-IP       EXTERNAL-IP                                          PORT(S)                      AGE
ingress-nginx            LoadBalancer   172.20.6.67      xxxx.elb.amazonaws.com   80:30857/TCP,443:31863/TCP   10d
ingress-nginx-internal   LoadBalancer   172.20.115.244   yyyyy.elb.amazonaws.com   80:30036/TCP,443:30495/TCP   97m

Пока все хорошо, все работает нормально.

Однако, когда я создаю два ресурса входа, каждый из этих ресурсов привязан к разным контроллерам входа (обратите внимание на 'kubernetes.io/ingress.class:'):

Внешний входящий ресурс:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: accounting-ingress
  annotations:  
    kubernetes.io/ingress.class: nginx
 spec: ...

Внутренний входящий ресурс:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: internal-ingress
  annotations:  
    kubernetes.io/ingress.class: nginx-internal    
spec: ...

Я вижу, что они оба содержат один и тот же АДРЕС, адрес первого контроллера входящего трафика:

$ kg ingress
NAME                 HOSTS                  ADDRESS                                                                   PORTS     AGE
external-ingress   bbb.aaaa.com           xxxx.elb.amazonaws.com   80, 443   10d
internal-ingress   ccc.aaaa.com           xxxx.elb.amazonaws.com   80        88m

Я ожидал, что вход, связанный с 'ingress-class = nginx-internal', будет содержать этот адрес: 'yyyyy.elb.amazonaws.com'. Хотя вроде все работает нормально, но меня это раздражает, у меня такое впечатление, что что-то не так.

С чего начать устранение неполадок, чтобы понять, что происходит за кулисами?

#### --- ОБНОВЛЕНИЕ --- ####

Помимо того, что описано выше, я добавил строку '"ingress-controller-leader-nginx-internal" в manadatory.yaml, как показано ниже. Я сделал это, основываясь на одном комментарии, который я нашел в файле required.yaml:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
      - "ingress-controller-leader-nginx-internal"

К сожалению, в документации nginx упоминаются только «kubernetes.io/ingress.class и -ingress-class» для определения нового контроллера. Есть шанс, что я ввязываюсь в незначительные детали.


person vinicius.olifer    schedule 21.10.2019    source источник
comment
Какая конфигурационная карта для другого nginx-ingress?   -  person night-gold    schedule 21.10.2019
comment
Это хороший вопрос. Я бы сказал, что они используют тот же самый, потому что я в основном изменил только развертывание и обслуживание для второго контроллера. Но я добавил одну строчку в обязательный.yaml. Я обновлю свой вопрос этим. Эта строка была добавлена ​​в раздел Роль ›Правила› apiGroups ›ResourceNames. Теперь он содержит две строки: - "ingress-controller-leader-nginx" - "ingress-controller-leader-nginx-internal" Не уверен, смог ли я, добавив ingress-controller-leader-nginx-internal, определить другую configMap или нет. Некоторые концепции мне все еще не так понятны.   -  person vinicius.olifer    schedule 21.10.2019


Ответы (1)


Попробуйте изменить эту строку:

- --configmap=$(POD_NAMESPACE)/nginx-configuration

В вашем коде это должно быть примерно так:

- --configmap=$(POD_NAMESPACE)/internal-nginx-configuration

Таким образом, у вас будет разная конфигурация для каждого nginx-контроллера, в противном случае у вас будет такая же конфигурация, может показаться, что она работает, но у вас будут некоторые ошибки при обновлении ... (Уже было ....)

person night-gold    schedule 21.10.2019
comment
Я вижу, что в файле required.yaml уже есть configMap под названием nginx-configuration. Прежде чем указывать эту «внутреннюю-nginx-конфигурацию», как вы предложили, следует ли мне заранее создать дополнительную configMap с этим именем? - person vinicius.olifer; 21.10.2019
comment
Нет. Он генерируется контейнером. Если вы измените конфигурацию, он должен выполнить обновление. - person night-gold; 21.10.2019
comment
Я думаю, что мне действительно нужно создать эту дополнительную конфигурационную карту, потому что, не создавая ее, я вижу следующую ошибку в журналах модулей контроллера: store.go: 635] Неожиданная ошибка чтения конфигурации configmap: configmaps internal-nginx-configuration не найден . Я что-нибудь упускаю :)? - person vinicius.olifer; 21.10.2019
comment
Хааа да, извините, вы должны переименовать конфигурационную карту, которая должна быть пустой в yaml ... - person night-gold; 21.10.2019
comment
Привет, я сделал это, но он все еще выбирает тот же адрес, что и первый контроллер. Я вижу это в журналах: updating Ingress inno-testing2/internal-ingress status from [] to [{ xxxxx.elb.amazonaws.com}] Я думаю о создании совершенно нового обязательного.yaml, дублируя таким образом все ресурсы, чтобы убедиться, что нет общих ресурсов. Вы думаете, что это перебор? Может, продолжить копать только по configMap? - person vinicius.olifer; 22.10.2019
comment
У вас не должно быть общих ресурсов в вашей конфигурации между двумя контроллерами nginx :) - person night-gold; 22.10.2019
comment
Я создал отдельные ресурсы для моего внутреннего входа, больше не используя никаких общих ресурсов. С самого начала я пытался создать только новое развертывание и новую службу, которые не работали. Я приму ваш вопрос, потому что вы открыли мне глаза на отсутствие совместного использования ресурсов между контроллерами. Спасибо, ночь-золото. - person vinicius.olifer; 25.10.2019