Я использую NSX / NCP Ingress в выделенном кластере VMWare PKS. Я пытаюсь противостоять входу в Elasticsearch, а серверная служба использует HTTPS. Кажется, я не могу найти способ, чтобы NSX Ingress разговаривал с серверной службой HTTPS.
Балансировщик нагрузки завершит TLS и отправит HTTP-запросы на внутренний сервер по умолчанию, если есть TLS Ingress (в кластере для варианта использования Kubernetes / PKS или в том же пространстве имен для варианта использования Project Pacific) с хостом, который соответствует хост в запросе.
Задний план:
kuberneties.io/ingress.class: nsx
)ingress.kubernetes.io/secure-backends: 'true'
аннотация.nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
аннотация, и это работает. Однако эти входящие контроллеры получают случайно назначенный IP-адрес (который может измениться) и никаких записей DNS.ncp/ssl-mode: reencrypt
аннотации и получите только ошибку 502. Был бы готов вернуться к этому.Что я ищу:
ncp/ssl-mode: reencrypt
вариант работает для этого сценария. Я не хочу устанавливать входящий трафик по умолчанию (в правиле нет хоста)eventsink-opendistro-es-client-service
порт 9200 HTTPS в качестве службы HTTP для контроллера входящего трафика NSX. Я подумал о создании отдельного модуля nginx, который подключается к сервису на бэкэнде и представляет его как HTTP во фронтенде, который затем может задействовать контроллер входящего трафика.Я также не хочу перестраивать образ Elasticsearch на пользовательский, не использующий https, но если есть метод диаграммы управления, позволяющий сделать открытый порт 9200 только HTTP, я могу это сделать.
Наконец, вот мое определение входящего трафика в его нынешнем виде:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: eventsink-opendistro-es-client
annotations:
kubernetes.io/ingress.class: nsx
ingress.kubernetes.io/secure-backends: 'true'
# ncp/ssl-mode: reencrypt
namespace: default
spec:
rules:
- host: elasticsearch.clustername.pks.example.net
http:
paths:
- backend:
serviceName: eventsink-opendistro-es-client-service
servicePort: 9200
tls:
- hosts:
- elasticsearch.clustername.pks.example.net
secretName: clustername.pks.example.net-ssl
Обходной путь, который я в конечном итоге использовал, заключался в создании службы обратного прокси, чтобы предоставлять 9200 HTTPS как HTTP для входящего контроллера.
---
apiVersion: v1
kind: ConfigMap
metadata:
name: eventsink-reverseproxy-conf
data:
default.conf: |
server {
listen 80;
server_name _;
location / {
proxy_pass https://eventsink-opendistro-es-client-service:9200;
}
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: eventsink-reverseproxy
labels:
app: eventsink-reverseproxy
spec:
replicas: 3
selector:
matchLabels:
app: eventsink-reverseproxy
template:
metadata:
labels:
app: eventsink-reverseproxy
spec:
containers:
- name: nginx
image: nginx:1.19.0
ports:
- name: http
containerPort: 80
volumeMounts:
- name: nginxconfd
mountPath: /etc/nginx/conf.d
volumes:
- name: nginxconfd
configMap:
name: eventsink-reverseproxy-conf
---
apiVersion: v1
kind: Service
metadata:
name: eventsink-reverseproxy-svc
spec:
selector:
app: eventsink-reverseproxy
ports:
- name: http
protocol: TCP
port: 80
targetPort: 80