Kubernetes(Istio)Mongodb企业集群:HostUnreachable:对等重置连接 [英] Kubernetes(Istio) Mongodb enterprise cluster: HostUnreachable: Connection reset by peer
问题描述
我的k8集群中正在运行Istio1.6.在集群中，我还部署了分片的mongodb集群禁用istio-injection注入.
I have Istio1.6 running in my k8 cluster. In the cluster I have also deployed sharded mongodb cluster with istio-injection disabled.
我的应用程序启用了istio-injection 的命名空间有所不同.如果我尝试连接到Mongo，则从Pod中获得此由于对等错误而导致的连接重置:
And I have a different namespace for my app with istio-injection enabled. And from the pod if I try to connect to the mongo I get this connection reset by peer error:
root@mongo:/# mongo "mongodb://mongo-sharded-cluster-mongos-0.mongo-service.mongodb.svc.cluster.local:27017,mongo-sharded-cluster-mongos-1.mongo-service.mongodb.svc.cluster.local:27017/?ssl=false"
MongoDB shell version v4.2.8
connecting to: mongodb://mongo-sharded-cluster-mongos-0.mongo-service.mongodb.svc.cluster.local:27017,mongo-sharded-cluster-mongos-1.mongo-service.mongodb.svc.cluster.local:27017/?compressors=disabled&gssapiServiceName=mongodb&ssl=false
2020-06-18T19:59:14.342+0000 I NETWORK [js] DBClientConnection failed to receive message from mongo-sharded-cluster-mongos-0.mongo-service.mongodb.svc.cluster.local:27017 - HostUnreachable: Connection reset by peer
2020-06-18T19:59:14.358+0000 I NETWORK [js] DBClientConnection failed to receive message from mongo-sharded-cluster-mongos-1.mongo-service.mongodb.svc.cluster.local:27017 - HostUnreachable: Connection reset by peer
2020-06-18T19:59:14.358+0000 E QUERY [js] Error: network error while attempting to run command 'isMaster' on host 'mongo-sharded-cluster-mongos-1.mongo-service.mongodb.svc.cluster.local:27017' :
connect@src/mongo/shell/mongo.js:341:17
@(connect):2:6
2020-06-18T19:59:14.362+0000 F - [main] exception: connect failed
2020-06-18T19:59:14.362+0000 E - [main] exiting with code 1
但是，如果我禁用对应用程序(pod)的istio-injection ，那么我可以按预期成功连接并使用mongo.
But if I disable the istio-injection to my app(pod) then I can successfully connect and use mongo as expected.
是否可以解决此问题，我想将istio-proxy注入我的app/pod并使用mongodb吗?
推荐答案
使用istio注入数据库很复杂.
Injecting Databases with istio is complicated.
我将从检查您的mtl开始，如果它是STRICT，我将其更改为宽松并检查它是否有效.很好地描述了此处.
I would start with checking your mtls, if it´s STRICT, I would change it to permissive and check if it works. It´s well described here.
您看到的请求仍然成功，除了从没有代理的客户端sleep.legacy到通过代理httpbin.foo或httpbin.bar发送到服务器的请求.这是可以预料的，因为现在严格要求相互TLS ，但是没有附带工具的工作负载无法遵守.
You see requests still succeed, except for those from the client that doesn’t have proxy, sleep.legacy, to the server with a proxy, httpbin.foo or httpbin.bar. This is expected because mutual TLS is now strictly required, but the workload without sidecar cannot comply.
是否可以解决此问题，我想将istio-proxy注入我的app/pod并使用mongodb吗?
Is there a work around for this, I would like to have istio-proxy injected to my app/pod and use mongodb?
如果更改mtls不起作用，则在istio中，您可以不注入而设置数据库，然后使用ServiceEntry对象将其添加到istio注册表中，以便能够与其他istio服务进行通信.
If changing mtls won´t work, then in istio You can set up database without injecting and then add it to istio registry using ServiceEntry object so it would be able to communicate with the rest of istio services.
要将mongodb数据库添加到istio，可以使用 ServiceEntry .
To add your mongodb database to istio you can use ServiceEntry.
ServiceEntry允许在Istio的内部服务注册表中添加其他条目，以便网格中自动发现的服务可以访问/路由到这些手动指定的服务.服务条目描述了服务的属性(DNS名称，VIP，端口，协议，端点).这些服务可能在网状网络外部(例如，Web API)或不在网状网络服务注册表中的网状内部内部服务(例如，一组与Kubernetes中的服务进行对话的VM).另外，还可以通过使用工作负载选择器字段动态选择服务条目的端点.这些端点可以是使用WorkloadEntry对象或Kubernetes容器声明的VM工作负载.在单一服务下同时选择Pod和VM的能力允许将服务从VM迁移到Kubernetes，而无需更改与服务相关联的现有DNS名称.
ServiceEntry enables adding additional entries into Istio’s internal service registry, so that auto-discovered services in the mesh can access/route to these manually specified services. A service entry describes the properties of a service (DNS name, VIPs, ports, protocols, endpoints). These services could be external to the mesh (e.g., web APIs) or mesh-internal services that are not part of the platform’s service registry (e.g., a set of VMs talking to services in Kubernetes). In addition, the endpoints of a service entry can also be dynamically selected by using the workloadSelector field. These endpoints can be VM workloads declared using the WorkloadEntry object or Kubernetes pods. The ability to select both pods and VMs under a single service allows for migration of services from VMs to Kubernetes without having to change the existing DNS names associated with the services.
ServiceEntry示例
Example of ServiceEntry
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: external-svc-mongocluster
spec:
hosts:
- mymongodb.somedomain # not used
addresses:
- 192.192.192.192/24 # VIPs
ports:
- number: 27018
name: mongodb
protocol: MONGO
location: MESH_INTERNAL
resolution: STATIC
endpoints:
- address: 2.2.2.2
- address: 3.3.3.3
如果启用了mtls，则还需要DestinationRule，它将定义如何与外部服务进行通信.
If You have mtls enabled You will also need DestinationRule that will define how to communicate with the external service.
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: mtls-mongocluster
spec:
host: mymongodb.somedomain
trafficPolicy:
tls:
mode: MUTUAL
clientCertificate: /etc/certs/myclientcert.pem
privateKey: /etc/certs/client_private_key.pem
caCertificates: /etc/certs/rootcacerts.pem
另外请参阅本文档
Additionally take a look at this documentation
- https://istiobyexample.dev/databases/
- https://istio.io/latest/blog/2018/egress-mongo/
这篇关于Kubernetes(Istio)Mongodb企业集群:HostUnreachable:对等重置连接的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
