У нас есть приложение с зависимостью от RabbitMQ, которое развертывается внутри кластера kubernetes в качестве стандартного развертывания с учетом состояния / стиля обслуживания (с использованием helm stable / rabbitmq-ha).Затем в отдельном пространстве имен приложение развертывается в макете развертывания / обслуживания аналогичного стиля, но с включенным istio (включая добавление коляски).
Как только мы включим внедрение боковой тележки istio, развертывание больше не сможет подключаться кслужба kubernetes.
Я пытался вставить istio ServiceEntry с полным доменным именем каждого модуля RabbitMQ, но, похоже, это не имело значения.
---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: rabbitmq
spec:
hosts:
- "rabbitmq-rabbitmq-ha-0.rabbitmq-rabbitmq-ha-discovery.rabbitmq.svc.cluster.local"
- "rabbitmq-rabbitmq-ha-1.rabbitmq-rabbitmq-ha-discovery.rabbitmq.svc.cluster.local"
- "rabbitmq-rabbitmq-ha-2.rabbitmq-rabbitmq-ha-discovery.rabbitmq.svc.cluster.local"
ports:
- number: 4369
name: epmd
protocol: TCP
- number: 5672
name: amqp
protocol: TCP
- number: 15672
name: http
protocol: HTTP
- number: 25672
name: inter-node
protocol: TCP
...
Я вижу трафикдобирается до модуля RabbitMQ, но с включенным Istio выдает следующую ошибку:
2019-06-19 09:40:39.538 [info] <0.32110.48> accepting AMQP connection <0.32110.48> (10.233.122.234:47530 -> 10.233.122.85:5672)
2019-06-19 09:40:39.538 [error] <0.32110.48> closing AMQP connection <0.32110.48> (10.233.122.234:47530 -> 10.233.122.85:5672):
{bad_header,<<22,3,1,0,222,1,0,0>>}
Единственная мысль, которая у меня сейчас есть, заключается в том, что RabbitMQ разрешает DNS Kubernetes в каждый конкретный модуль с помощью плагина(rabbitmq_peer_discovery_k8s), это может мешать?
Просто чтобы прояснить, я не заинтересован в том, чтобы Istio mTLS между приложением и RabbitMQ просто имел полностью функциональную базовую связь.
Мыиспользуя:
- Kubernetes 1.3.0
- Istio 1.1.9
- RabbitMQ 3.7.12