у нас есть кластер Kubernetes в AWS (EKS). В нашей настройке нам нужно иметь два контроллера ingress-nginx, чтобы мы могли применять различные политики безопасности. Для этого я использую
kubernetes.io / ingress.class и -ingress-class
В соответствии с рекомендациями здесь , я создал одинстандартный входной контроллер со значением по умолчанию 'required.yaml' из репозитория ingress-nginx.
Для создания второго входного контроллера я настроил входное развертывание из 'обязательного'.Ямл немного. Я в основном добавил тег:
'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: ...
Я вижу, что они оба содержат один и тот же АДРЕС,адрес первого Ingress Controller:
$ 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-внутренние "" внутри 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 для определения нового контроллера. Есть шанс, что я перебираю мелкие детали.