Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

Example Analysis of using Istio for Multi-Cluster deployment Management and single Control plane Gateway connection Topology

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Servers >

Share

Shulou(Shulou.com)05/31 Report--

This article is about the use of Istio for multi-cluster deployment management and single control plane Gateway connection topology example analysis, the editor thinks it is very practical, so share it with you to learn, I hope you can get something after reading this article, not to say much, follow the editor to have a look.

In a single control plane topology, multiple Kubernetes clusters share a single Istio control plane running on one of the clusters. The Pilot of the control plane manages services on local and remote clusters and configures Envoy Sidecar agents for all clusters.

Cluster-aware service routing

Cluster-aware service routing capability is introduced in Istio 1.1.Under a single control plane topology configuration, Istio's Split-horizon EDS (split Endpoint Discovery Service) function allows service requests to be routed to other clusters through its ingress gateway. Based on the location of the request source, Istio can route requests to different endpoints.

In this configuration, requests from Sidecar in a cluster to services in the same cluster are still forwarded to the local service IP. If the target workload is running in another cluster, use the gateway IP of the remote cluster to connect to the service.

(cluster-aware service routing)

As shown in the figure, the main cluster cluster1 runs a full set of Istio control plane components, while the cluster cluster2 runs only Istio Citadel, Sidecar Injector, and Ingress gateways. No VPN connection is required, and direct network access is not required between workloads in different clusters.

An intermediate CA certificate is generated from the shared root CA for the Citadel of each cluster, and the shared root CA enables two-way TLS communication across different clusters. For illustration purposes, we use the sample root CA certificate provided in the Istio installation under the samples/certs directory for both clusters. In a real deployment, you might use a different CA certificate for each cluster, and all CA certificates are signed by the common root CA.

In each Kubernetes cluster, including the clusters cluster1 and cluster2 in the example, use the following command to create an Kubernetes key for the generated CA certificate:

Kubectlcreate namespace istio-systemkubectlcreate secret generic cacerts-n istio-system\-- from-file=samples/certs/ca-cert.pem\-- from-file=samples/certs/ca-key.pem\-- from-file=samples/certs/root-cert.pem\-- from-file=samples/certs/cert-chain.pemIstio control plane component

In the cluster cluster1 where the full set of Istio control plane components are deployed, follow these steps:

1. Install the CRD for Istio and wait a few seconds to submit them to the Kubernetes API server, as follows:

Fori in install/kubernetes/helm/istio-init/files/crd*yaml; do kubectl apply-f $idone

two。 Then start deploying the Istio control plane in the cluster cluster1.

If helm dependencies are missing or not up to date, you can update them through helm dep update. It is important to note that because istio-cni is not used, you can temporarily remove it from the dependency requirements.yaml and perform the update operation. The specific commands are as follows:

Helmtemplate-- name=istio-- namespace=istio-system\-- setglobal.mtls.enabled=true\-- setsecurity.selfSigned=false\-- setglobal.controlPlaneSecurityEnabled=true\-- setglobal.meshExpansion.enabled=true\-- setglobal.meshNetworks.network2.endpoints [0] .fromRegistry = n2-k8s-config\-- setglobal.meshNetworks.network2.gateways [0] .address = 0.0.0.0\-- setglobal.meshNetworks.network2.gateways [0] .port = 15443\ install/kubernetes/helm/istio >. / istio-auth.yaml

Notice that the gateway address is set to 0.0.0.0. This is a temporary placeholder value that will be updated to the public IP value of its gateway after the cluster cluster2 deployment.

Deploy Istio to cluster1 as follows:

Kubectlapply-f. / istio-auth.yaml

Ensure that the above steps are performed successfully in the Kubernetes cluster.

3. Create a gateway to access remote services, as follows:

Kubectlcreate-f-

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Servers

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report