如何使用Istio 1.6管理多集群中的微服务? (2)

由于我们需要为不同得活动连接两个集群,因此获取上下文并将其存储在环境变量中会很有意义。有了这些,我们只要在kubectl命令中加入上下文,就可以在我们选择得集群中运行kubectl命令。

获取上下文:

$ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE cluster-1 cluster-1 cluster-1 * cluster-2 cluster-2 cluster-2

设置环境变量以使用上下文:

$ export CTX_CLUSTER1=$(kubectl config view -o jsonpath='{.contexts[0].name}') $ export CTX_CLUSTER2=$(kubectl config view -o jsonpath='{.contexts[1].name}') $ echo CTX_CLUSTER1 = ${CTX_CLUSTER1}, CTX_CLUSTER2 = ${CTX_CLUSTER2} CTX_CLUSTER1 = cluster-1, CTX_CLUSTER2 = cluster-2 部署示例微服务

我们先在集群1的foo命名空间上部署sleep微服务。

$ kubectl create --context=$CTX_CLUSTER1 namespace foo namespace/foo created $ kubectl label --context=$CTX_CLUSTER1 namespace foo istio-injection=enabled namespace/foo labeled $ kubectl apply --context=$CTX_CLUSTER1 -n foo -f samples/sleep/sleep.yaml serviceaccount/sleep created service/sleep created deployment.apps/sleep created $ export SLEEP_POD=$(kubectl get --context=$CTX_CLUSTER1 -n foo pod -l app=sleep -o jsonpath={.items..metadata.name})

现在我们在集群2的bar命名空间上部署httpbin微服务:

$ kubectl create --context=$CTX_CLUSTER2 namespace bar namespace/bar created $ kubectl label --context=$CTX_CLUSTER2 namespace bar istio-injection=enabled namespace/bar labeled $ kubectl apply --context=$CTX_CLUSTER2 -n bar -f samples/httpbin/httpbin.yaml serviceaccount/httpbin created service/httpbin created deployment.apps/httpbin created 创建服务条目

现在我们需要在Istio CoreDNS上创建一个服务条目以便于我们可以从集群1中发现集群2上的服务。由于所有的通信都会通过Ingress 网关,导出集群2 Ingress网关地址。

export CLUSTER2_GW_ADDR=$(kubectl get --context=$CTX_CLUSTER2 svc --selector=app=istio-ingressgateway \ -n istio-system -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}')

为了让集群1上的服务能够发现集群2上的httpbin,我们需要在集群1上为httpbin.bar.global创建一个ServiceEntry。这样可以保证集群1上的Istio Core DNS在集群1上的服务到达httpbin.bar.global这个端点时,可以到达集群2的Ingress网关。下面的yaml:

在hosts部分定义服务域名

位置是mesh_INTERNAL,因为我们需要把其他服务当作同一个服务网格的一部分

将服务暴露在8000端口上

我们需要给该服务提供一个独特的IP地址。该IP地址不需要可路由,并且你可以使用240.0.0.0/16范围内的任意地址

我们在端点地址部分上定义集群2 ingress网关地址,以便于请求可以路由给它。端口15443是Ingress网关的SNI识别的Envoy代理端口,用于在目标群集服务的Pod之间路由流量。

应用yaml文件:

$ kubectl apply --context=$CTX_CLUSTER1 -n foo -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: ServiceEntry metadata: name: httpbin-bar spec: hosts: - httpbin.bar.global location: MESH_INTERNAL ports: - name: http1 number: 8000 protocol: http resolution: DNS addresses: - 240.0.0.2 endpoints: - address: ${CLUSTER2_GW_ADDR} ports: http1: 15443 # Do not change this port value EOF serviceentry.networking.istio.io/httpbin-bar created 测试服务

现在让我们从sleep微服务中产生一些流量,看看它是否能到达集群2上运行的httpbin微服务。

$ kubectl exec --context=$CTX_CLUSTER1 $SLEEP_POD -n foo -c sleep -- curl -I httpbin.bar.global:8000/headers % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0HTTP/1.1 200 OK 0 519 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0 server: envoy date: Sat, 16 May 2020 23:03:22 GMT content-type: application/json content-length: 519 access-control-allow-origin: * access-control-allow-credentials: true x-envoy-upstream-service-time: 37

我们得到一个成功的响应!恭喜你,我们已经成功地使用Istio在多个Kubernetes集群之间配置了服务发现。

结 论

感谢你的阅读,希望你能喜欢这篇文章。

这是一个在多个集群上运行的高可用Istio服务网格配置的演示。你也可以有一个共享的控制平面配置,但这并不推荐用于生产——如果你因为中断而失去一个集群,你也会失去对正在运行的集群的控制。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/wsxxpy.html