Любопытное поведение с TLS RabbitMQ в Kubernetes и externalIP - PullRequest
0 голосов
/ 29 января 2020

Я развернул RabbitMQ (с рулевой диаграммы https://github.com/helm/charts/tree/master/stable/rabbitmq) в кластере Kubernetes, в пространстве имен с именем rabbitmq. Я добавил 3 IP-адреса (IP-адреса моих узлов Kubernetes) в качестве внешних IP-адресов в сервисе rabbitmq. Вот служба rabbitmq:

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: rabbitmq
    app.kubernetes.io/name: rabbitmq
    helm.sh/chart: rabbitmq-6.15.0
  name: rabbitmq
  namespace: rabbitmq
spec:
  externalIPs:
  - x.x.x.x1
  - x.x.x.x2
  - x.x.x.x3
  ports:
  - name: epmd
    port: 4369
    protocol: TCP
    targetPort: epmd
  - name: amqp
    port: 5672
    protocol: TCP
    targetPort: amqp
  - name: amqp-ssl
    port: 5671
    protocol: TCP
    targetPort: amqp-ssl
  - name: dist
    port: 25672
    protocol: TCP
    targetPort: dist
  - name: stats
    port: 15672
    protocol: TCP
    targetPort: stats
  - name: metrics
    port: 9419
    protocol: TCP
    targetPort: metrics
  selector:
    app.kubernetes.io/component: rabbitmq
    app.kubernetes.io/name: rabbitmq
    helm.sh/chart: rabbitmq-6.15.0
  type: ClusterIP

У меня есть внешний балансировщик нагрузки, который нацелен на эти 3 IP-адреса. У меня есть запись DNS "rabbitmq.mycompagny.com", которая предназначена для моего балансировщика нагрузки. Я всегда использую этот механизм для нацеливания на все мои входы без каких-либо проблем.

Наконец, у меня есть тестовый модуль в пространстве имен test, с установленными amqp-tools. В этом тестовом модуле см. Некоторые команды и результаты:

amqp-get --url=amqps://user:password@rabbitmq.rabbitmq.svc.cluster.local:5671 --cacert=/opt/bitnami/rabbitmq/certs/ca_certificate.pem --key=/opt/bitnami/rabbitmq/certs/server_key.pem --cert=/opt/bitnami/rabbitmq/certs/server_certificate.pem --queue=test --ssl
# opening socket to rabbitmq.rabbitmq.svc.cluster.local:5671

# => KO

# logs from rabbitmq :
#2020-01-29 07:34:25.308 [debug] <0.3077.0> accepting AMQP connection <0.3077.0> (10.244.96.29:42620 -> 10.244.32.52:5671)
#2020-01-29 07:34:25.308 [debug] <0.3077.0> closing AMQP connection <0.3077.0> (10.244.96.29:42620 -> 10.244.32.52:5671):
#connection_closed_with_no_data_received

amqp-get --url=amqps://user:password@rabbitmq.mycompagny.com:5671 --cacert=/opt/bitnami/rabbitmq/certs/ca_certificate.pem --key=/opt/bitnami/rabbitmq/certs/server_key.pem --cert=/opt/bitnami/rabbitmq/certs/server_certificate.pem --queue=test --ssl

# => OK

# logs from rabbitmq :
#2020-01-29 07:37:47.430 [info] <0.23936.4> accepting AMQP connection <0.23936.4> (10.244.32.0:55694 -> 10.244.32.28:5671)
#2020-01-29 07:37:47.472 [debug] <0.23936.4> User 'user' authenticated successfully by backend rabbit_auth_backend_internal
#2020-01-29 07:37:47.486 [info] <0.23936.4> closing AMQP connection <0.23936.4> (10.244.32.0:55694 -> 10.244.32.28:5671, vhost: '/', user: 'user')

amqp-get --url=amqp://user:password@rabbitmq.rabbitmq.svc.cluster.local:5672 --queue=test

# => OK

amqp-get --url=amqp://user:password@rabbitmq.mycompagny.com:5672 --queue=test
#opening socket to rabbitmq.mycompagny.fr:5672

# => OK

Разница между этими командами заключается в целевом DNS. С TLS, когда я использую внешний DNS, это нормально, но это не так с внутренним DNS. Вы можете объяснить, почему?

Я дважды проверил сертификат, который является подписанным сертификатом с подстановочными знаками (проверьте с помощью openssl s_server / s_client).

Мне нужно использовать внешние IP-адреса, ориентированные на внешний балансировщик нагрузки, чтобы access rabbitmq, поскольку входы Kubernetes поддерживают только протокол HTTP / HTTPS, а протокол rabbitmq - AMQP / AMPQS.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...