简体   繁体   English

k8s集群中的通信

[英]Communication in k8s cluster

I have a k8s cluster of 2 hazelcast instances and one client application. 我有一个由2个hazelcast实例和一个客户端应用程序组成的k8s集群。 Target is to have many clients and at least 2 hazelcast members. 目标是拥有许多客户和至少2个淡褐色成员。 I've set up a LoadBalancer type service in k8s to expose hazelcast instances 我在k8s中设置了一个LoadBalancer类型的服务来公开hazelcast实例

apiVersion: v1
kind: Service
metadata:
  name: hazelcast-service
  labels:
    app: hazelcast-service
spec:
  type: LoadBalancer
  ports:
  - port: 10236
    targetPort: 5701
  selector:
    app: hazelcast 

And when it comes for client to start with given config: 当客户端以给定的配置开始时:

clientConfig.getNetworkConfig().addAddress("127.0.0.1:10236");

in recognizes a hazelcast members: 认识到一个黑客成员:

May 08, 2018 11:25:21 AM com.hazelcast.core.LifecycleService
INFO: hz.client_0 [dev] [3.9.3] HazelcastClient 3.9.3 (20180216 - 539b124) is STARTING
May 08, 2018 11:25:22 AM com.hazelcast.core.LifecycleService
INFO: hz.client_0 [dev] [3.9.3] HazelcastClient 3.9.3 (20180216 - 539b124) is STARTED
May 08, 2018 11:25:22 AM com.hazelcast.client.connection.ClientConnectionManager
INFO: hz.client_0 [dev] [3.9.3] Trying to connect to [127.0.0.1]:10236 as owner member
May 08, 2018 11:25:22 AM com.hazelcast.client.connection.ClientConnectionManager
INFO: hz.client_0 [dev] [3.9.3] Authenticated with server [10.1.0.151]:5701, server version:3.10 Local address: /127.0.0.1:60102
May 08, 2018 11:25:22 AM com.hazelcast.client.spi.impl.ClientMembershipListener
INFO: hz.client_0 [dev] [3.9.3]

Members [2] {
    Member [10.1.0.148]:5701 - b0e4a52f-0170-47f2-8ff3-74d9b67f45f5
    Member [10.1.0.151]:5701 - 1355caa4-5c2b-4366-bd5b-b504f4f0ae4f
}

May 08, 2018 11:25:22 AM com.hazelcast.client.connection.ClientConnectionManager
INFO: hz.client_0 [dev] [3.9.3] Setting ClientConnection{alive=true, connectionId=1, channel=NioChannel{/127.0.0.1:60102->/127.0.0.1:10236}, remoteEndpoint=[10.1.0.151]:5701, lastReadTime=2018-05-08 11:25:22.420, lastWriteTime=2018-05-08 11:25:22.418, closedTime=never, lastHeartbeatRequested=never, lastHeartbeatReceived=never, connected server version=3.10} as owner with principal ClientPrincipal{uuid='28696aaf-e678-47ee-8c7d-a79ba7a0079a', ownerUuid='1355caa4-5c2b-4366-bd5b-b504f4f0ae4f'}
May 08, 2018 11:25:22 AM com.hazelcast.core.LifecycleService
INFO: hz.client_0 [dev] [3.9.3] HazelcastClient 3.9.3 (20180216 - 539b124) is CLIENT_CONNECTED
May 08, 2018 11:25:22 AM com.hazelcast.internal.diagnostics.Diagnostics
INFO: hz.client_0 [dev] [3.9.3] Diagnostics disabled. To enable add -Dhazelcast.diagnostics.enabled=true to the JVM arguments.

and when it tries to connect to second instance (10.1.0.151) it also seems to be fine: 当它试图连接到第二个实例(10.1.0.151)时,它似乎也很好:

May 08, 2018 11:25:29 AM com.hazelcast.core.LifecycleService
INFO: hz.client_1 [dev] [3.9.3] HazelcastClient 3.9.3 (20180216 - 539b124) is STARTING
May 08, 2018 11:25:29 AM com.hazelcast.core.LifecycleService
INFO: hz.client_1 [dev] [3.9.3] HazelcastClient 3.9.3 (20180216 - 539b124) is STARTED
May 08, 2018 11:25:29 AM com.hazelcast.client.connection.ClientConnectionManager
INFO: hz.client_1 [dev] [3.9.3] Trying to connect to [127.0.0.1]:10236 as owner member
May 08, 2018 11:25:29 AM com.hazelcast.client.connection.ClientConnectionManager
INFO: hz.client_1 [dev] [3.9.3] Authenticated with server [10.1.0.148]:5701, server version:3.10 Local address: /127.0.0.1:60113
May 08, 2018 11:25:29 AM com.hazelcast.client.spi.impl.ClientMembershipListener
INFO: hz.client_1 [dev] [3.9.3]

Members [2] {
    Member [10.1.0.148]:5701 - b0e4a52f-0170-47f2-8ff3-74d9b67f45f5
    Member [10.1.0.151]:5701 - 1355caa4-5c2b-4366-bd5b-b504f4f0ae4f
}

May 08, 2018 11:25:29 AM com.hazelcast.client.connection.ClientConnectionManager
INFO: hz.client_1 [dev] [3.9.3] Setting ClientConnection{alive=true, connectionId=1, channel=NioChannel{/127.0.0.1:60113->/127.0.0.1:10236}, remoteEndpoint=[10.1.0.148]:5701, lastReadTime=2018-05-08 11:25:29.455, lastWriteTime=2018-05-08 11:25:29.453, closedTime=never, lastHeartbeatRequested=never, lastHeartbeatReceived=never, connected server version=3.10} as owner with principal ClientPrincipal{uuid='a04aa2ca-626d-4d1a-a366-38c0dbc4781f', ownerUuid='b0e4a52f-0170-47f2-8ff3-74d9b67f45f5'}
May 08, 2018 11:25:29 AM com.hazelcast.core.LifecycleService
INFO: hz.client_1 [dev] [3.9.3] HazelcastClient 3.9.3 (20180216 - 539b124) is CLIENT_CONNECTED
May 08, 2018 11:25:29 AM com.hazelcast.internal.diagnostics.Diagnostics
INFO: hz.client_1 [dev] [3.9.3] Diagnostics disabled. To enable add -Dhazelcast.diagnostics.enabled=true to the JVM arguments.

but immediately after above message I got another one (seems to be connection problem regarding first member that my client connected to): 但是在上面的消息之后我又得到了另一个(似乎是关于我的客户连接的第一个成员的连接问题):

Constructor threw exception; nested exception is com.hazelcast.core.OperationTimeoutException: ClientInvocation{clientMessage = ClientMessage{length=72, correlationId=272, operation=Client.createProxy, messageType=5, partitionId=-1, isComplete=true, isRetryable=false, isEvent=false, writeOffset=0}, objectName = hz:impl:mapService, target = address [10.1.0.151]:5701, sendConnection = null} timed out because exception occurred after client invocation timeout 120000 ms. Current time: 2018-05-08 11:27:29.913. Start time: 2018-05-08 11:25:29.458. Total elapsed time: 120455 ms.

Sometimes it cannot even connect to the first member as I got OperationTimeoutException after client says that it connected to 10.1.0.151 member. 有时它甚至无法连接到第一个成员,因为我在客户端说它连接到10.1.0.151成员后得到了OperationTimeoutException。 Funny thing is that sometimes it works all fine:( And when I only have one replica of hazelcast pods it works predictable & fine. Thus, I believe this is because of LoadBalancer service which distributes requests equally among target pods and that there is something wrong with this set-up. 有趣的是,有时候它可以正常工作:(当我只有一个淡褐色吊舱的复制品时,它可以预测和精细。因此,我相信这是因为LoadBalancer服务在目标pod之间平均分配请求并且有错误有这个设置。

I suppose that client should be able to connect to any node it wants as any node can store requested item in its map but I don't know how to set up such a configuration in k8s. 我想客户端应该能够连接到它想要的任何节点,因为任何节点都可以在其映射中存储所请求的项目,但我不知道如何在k8s中设置这样的配置。

Question is: how should I configure services in k8s so that client apps can talk to all members? 问题是:如何在k8s中配置服务,以便客户端应用程序可以与所有成员交谈? Or this is not the case and it should work in a different way? 或者情况并非如此,它应该以不同的方式工作?

Am I missing something? 我错过了什么吗?

Thus, I believe this is because of LoadBalancer service which distributes requests equally among target pods and that there is something wrong with this set-up. 因此,我认为这是因为LoadBalancer服务在目标pod之间平均分配请求,并且此设置存在问题。

Yes, it is true. 是的,它是真实的。

how should I configure services in k8s so that client apps can talk to all members? 我应该如何在k8s中配置服务,以便客户端应用程序可以与所有成员交谈?

Service can only balance requests between available pods. 服务只能在可用容器之间平衡请求。

Or this is not the case and it should work in a different way? 或者情况并非如此,它应该以不同的方式工作?

Yes, that is a good idea. 是的,这是个好主意。 The simplest way is to create one service per hazelcast replica. 最简单的方法是为每个hazelcast副本创建一个服务。 And that is practically the only way to do that. 这实际上是唯一的方法。

If your hazelcast client is inside the kubernetes cluster, you dont really need LoadBalancer type. 如果您的hazelcast客户端位于kubernetes集群中,那么您实际上并不需要LoadBalancer类型。 A simple service ClusterIP or headless would suffice. 一个简单的服务ClusterIP或无头就足够了。 Hazelcast supports kubernetes discovery mode. Hazelcast支持kubernetes发现模式。 I suggest try using ClusterIP or none. 我建议尝试使用ClusterIP或无。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM