如何使用Istio进行多集群部署管理及单控制平面VPN连接拓扑

本篇文章为大家展示了如何使用Istio进行多集群部署管理及单控制平面VPN连接拓扑，内容简明扼要并且容易理解，绝对能使你眼前一亮，通过这篇文章的详细介绍希望你能有所收获。服务网格作为一个改善服务到服务通信的专用基础设施层，是云原生范畴中最热门的话题。随着容器愈加流行，服务拓扑也频繁变动，这就需要更好的网络性能。服务网格能够通过服务发现、路由、负载均衡、心跳检测和支持可观测性，帮助我们管理网络流量。服务网格试图为无规则的复杂的容器问题提供规范化的解决方案。服务网格也可以用于混沌工程 —— “一门在分布式系统上进行实验的学科，目的是构建能够应对极端条件的可靠系统”。服务网格能够将延迟和错误注入到环境中，而不需要在每个主机上安装一个守护进程。容器是云原生应用的基石，通过应用容器化，使得应用开发部署更加敏捷、迁移更加灵活，并且这些实现都是基于标准化的。而容器编排则是更近一步，能够更加有效地编排资源、更加高效地调度利用这些资源。而到了云原生时代，在Kubernetes基础架构之上，结合Istio服务网格，提供了多云、混合云的支持能力，针对微服务提供了有效的治理能力，并以Kubernetes和Istio为基础，提供了针对特定应用负载的不同支持，例如针对Kubeflow服务的流量治理、为Knative提供负载的路由管理能力等。尽管Service Mesh在云原生系统方面的应用已经有了快速的增长，但仍然存在巨大的提升空间。无服务器（Serverless）计算正好需要Service Mesh的命名和链接模型，这让Service Mesh在云原生生态系统中的角色得到了彰显。服务识别和访问策略在云原生环境中仍显初级，而Service Mesh毫无疑问将成为这方面不可或缺的基础。就像TCP/IP一样，Service Mesh将在底层基础设施这条道路上更进一步。混合云可以采用多种形式。通常，混合云指的是跨公有云和私有（内部部署）云运行，而多云意味着跨多个公有云平台运行。采用混合云或多云架构可以为你的组织带来诸多好处。例如，使用多个云提供商可以帮助你避免供应商锁定，能够让你为实现目标选择最佳的云服务。使用云和本地环境，你可以同时享受云的优势（灵活性、可扩展性、成本降低）和本地的好处（安全性、低延迟、硬件复用）。如果你是首次迁移到云端，采用混合云步骤可以让你按照自己的节奏，以最适合你业务的方式进行。根据我们在公有云上的实践经验及从客户那里得到的信息，我们认为采用混合服务网络是简化云和本地环境中应用程序管理、安全性和可靠性的关键，无论你的应用程序是在容器中运行，或是在虚拟机中运行。Istio的一个关键特性是它为你的工作负载（例如pod、job、基于VM的应用程序）提供服务抽象。当你转向混合拓扑时，这种服务抽象变得更加重要，因为现在你不只需要关注一个环境，而是需要关注若干个环境。当你在一个Kubernetes集群上使用Istio时，可以获得包括可见性、细粒度流量策略、统一遥测和安全性在内的微服务的所有管理优势。但是当你在多个环境中使用Istio时，实际上是为应用程序提供了一个新的超级能力。因为Istio不仅仅是Kubernetes的服务抽象，也是一种在整个环境中标准化网络的方法。它是一种集中API管理并将JWT验证与代码分离的方法。它是跨云提供商的安全、零信任网络的快速通道。那么所有这些魔法是如何发生的呢？混合Istio是指一组Istio Sidecar代理，每一个Envoy代理位于所有服务的旁边，而这些服务可能运行在不同环境中的每一个虚拟机、每一个容器中，而且这些Sidecar代理之前互相知道如何跨边界交互。这些Envoy Sidecar代理可能由一个中央Istio控制平面管理，或由每个环境中运行的多个控制平面管理。服务网格本质上是将一组单独的微服务组合成单个可控的复合应用程序，Istio作为一种服务网格，也是旨在单一管理域下监视和管理协作微服务网络。对于特定大小的应用程序，所有微服务是可以在单个编排平台如一个Kubernetes集群上运行的。然而，由于规模不断增大或者冗余等原因，大多数应用程序最终将需要分发一些服务在其他地方运行。社区越来越关注在多个集群上运行工作负载，以实现更好的扩展，故障可以更好地隔离，从而提升应用程序的敏捷性。Istio v1.0开始支持一些多集群功能，并在之后的版本中添加了新功能。Istio服务网格支持许多可能的拓扑结构，用于在单个集群之外分发应用程序的服务，有两种常见的模式或用例：单网格和网格联合。顾名思义，单个网格将多个集群组合成一个单元，由一个Istio控制平面管理；它可以实现为一个物理控制平面，也可以实现为一组控制平面，同时所有控制平面都能通过复制配置保持同步。而网格联合则会将多个集群分离作为单独的管理域，有选择地完成集群之间的连接，仅将服务的子集暴露给其他集群；自然它的实现会包含多个控制平面。具体来说，这些不同的拓扑结构包括以下几个方面：网格中的服务可以使用服务条目（Service Entry）来访问独立的外部服务或访问由另一个松散耦合的服务网格公开的服务，通常称为网格联邦（Mesh Federation）。这种拓扑适合于互相独立并且网络隔离、只能通过公网交互的多集群的场景；支持在虚拟机或物理裸机上运行的服务进行服务网格扩展，通常称为网格联合（Mesh Expansion）。在前面章节中，我们已经讲述了这种Kubernetes集群与虚拟机、物理裸机之间混合部署的场景；把来自多个集群的服务组合到单个服务网格中，通常称为多集群网格（Multicluster Mesh）。根据网络拓扑结构的不同，多集群网格通常分为单控制平面VPN连接、单控制平面网关连接以及多控制平面拓扑。作为基准，在Istio的1.1版本之前，Istio 1.0多集群仅支持使用单网格设计。它允许多个集群连接到网格中，但所有集群都在一个共享网络上。也就是说，所有集群中所有pod和服务的IP地址都是可直接路由的，不会发生冲突，同时保证在一个集群中分配的IP地址不会在另一个集群中同时重用。在这种拓扑配置下，在其中一个集群上运行单个Istio控制平面。该控制平面的Pilot管理本地和远程集群上的服务，并为所有集群配置Envoy代理。这种方法在所有参与集群都具有VPN连接的环境中效果最佳，因此可以使用相同的IP地址从其他任何地方访问网格中的每个pod。在此配置中，Istio控制平面部署在其中一个集群上，而所有其他集群运行更简单的远程Istio配置，该配置将它们连接到单个Istio控制平面，该平面将所有Envoy管理为单个网格。各个集群上的IP地址不允许重叠，并且远程集群上的服务的DNS解析不是自动的。用户需要在每个参与集群上复制服务，这样每个集群中的Kubernetes集群服务和应用程序都能够将其内部Kubernetes网络暴露给其他集群。一旦一个或多个远程Kubernetes集群连接到Istio控制平面，Envoy就可以与单个控制平面通信并形成跨多个集群的网状网络。事实上，我们已经了解到网格、集群和网络之间的存在各种约束，例如，在某些环境中，网络和集群直接相关。Istio单网格设计下的单控制平面VPN连接拓扑需要满足以下几个条件：运行Kubernetes 1.9或更高版本的两个或更多集群；能够在其中一个集群上部署Istio控制平面；RFC1918网络、VPN或满足以下要求的更高级网络技术：单个集群pod CIDR范围和服务CIDR范围在多集群环境中必须是唯一的，并且应当不重叠；每个集群中的所有pod CIDR必须可以相互路由；所有Kubernetes控制平面API服务器必须可以相互路由。此外，为了跨集群支持DNS名称解析，必须确保在所有需要跨集群服务调用的集群中定义对应的命名空间、服务和服务账户；例如，集群cluster1中命名空间ns1的服务service1需要调用集群cluster2中命名空间ns2的服务service2，那么在集群 cluster1 中为了支持服务名的DNS解析，需要在集群 cluster1 中创建一个命名空间ns2以及该命名空间下的服务service2。以下示例中的两个Kubernetes集群的网络假定已经满足上述要求，每个集群中的pod都能够互相路由，也就是说网络可通并且端口是可访问的（如果采用的是类似于阿里云的公有云服务，请确保这些端口在安全组规则下是可以访问的；否则服务间的调用会受到影响）。两个Kubernetes集群的pod CIDR范围和服务 CIDR 范围定义如下表所示： （CIDR范围定义） （Istio中单控制平面VPN连接拓扑的多集群支持的调用关系）从图中可以看到整个多集群拓扑中只会在一个Kubernetes集群上安装Istio控制平面。这个安装Istio控制平面的集群通常被称为本地集群，所有其它集群称为远程集群。这些远程集群只需要安装Istio的Citadel和Sidecar Injector准入控制器，具有较小的Istio占用空间，Citadel用于这些远程集群的安全管理，Sidecar Injector准入控制器用于控制平面中的自动注入和数据平面中工作负载的Sidecar代理功能。在这个架构中，Pilot可以访问所有集群中的所有Kubernetes API服务器，因此它具有全局网络访问视图。Citadel和Sidecar Injector准入控制器则只会在集群本地范围内运行。每个集群都有唯一的pod和服务CIDR，除此之外，集群之间还有一个共享的扁平网络，以保证能直接路由到任何工作负载，包括到Istio的控制平面。例如，远程集群上的Envoy代理需要从Pilot获得配置，检查并报告给Mixer等。如果在多个集群中启用跨集群的双向TLS通信，就需要按照如下方式在各个集群中进行部署配置。首先，从共享的根CA为每个集群的Citadel生成中间CA证书，共享的根CA启用跨不同集群的双向TLS通信。为了便于说明，我们将samples/certs目录下Istio安装中提供的示例根CA证书用于两个集群。在实际部署中，你可能会为每个集群使用不同的CA证书，所有CA证书都由公共根CA签名。在每个Kubernetes集群中（包括示例中的集群cluster1与cluster2）创建密钥。使用以下的命令为生成的CA证书创建Kubernetes密钥：当然，如果你的环境只是开发测试或者不需要启用双向TLS通信，上述步骤完全可以跳过。在所谓的本地集群上安装一个Istio控制平面的过程，与在单集群上安装Istio并没有开发云主机域名太多差别，需要注意的一点是如何配置Envoy代理用于管理直接访问某个IP范围内的外部服务的参数。如果是使用Helm安装Istio，那么在Helm中有一个名为global.proxy.includeIPRanges的变量，确保该变量为“*”或者包括本地集群、所有远程集群的pod CIDR范围和服务CIDR。可以通过查看命名空间istio-system下的配置项istio-sidecar-injector 中的 traffic.sidecar.istio.io/includeOutboundIPRanges来确认global.proxy.includeIPRanges参数设置，如下所示：在部署Istio控制平面组件的集群cluster1中，按照以下步骤执行。如果启用了双向TLS通信，则需要如下配置参数：如果不需要启用双向TLS通信，配置参数则需要做出如下修改：修改Istio服务istio-pilot、istio-telemetry、istio-policy及zipkin的类型为内网负载均衡，将这些服务以内网方式暴露给远程集群使用。不同的云厂商实现机制不尽相同，但大都是通过修改annotation的方式实现。针对阿里云容器服务来说，设置为内网负载均衡的方式非常简单，只需要添加如下annotation到服务的YAML定义中即可： service.beta.kubernetes.io/alicloud-loadbalancer-address-type: intranet。此外，需要按照图中的端口定义为每一个服务进行设置。 （服务设置）istio-pilot服务端口如表1所示。 （表1　istio-pilot服务端口说明）istio-telemetry服务端口如表2所示 （表2　istio-telemetry服务端口说明）istio-policy服务端口如表3所示。 （表3　istio-policy服务端口说明）zipkin服务端口如表4所示。 （表4　zipkin服务端口说明）在本地集群中安装完控制平面之后，必须将istio-remote组件部署到每个远程Kubernetes集群。等待Istio控制平面完成初始化，然后再执行本节中的步骤。你必须在Istio控制平面集群上运行这些操作以捕获Istio控制平面服务端点，例如上述提到的Istio服务istio-pilot、istio-telemetry、istio-policy以及zipkin。在远程集群cluster2中部署Istio-remote组件，按照以下步骤执行：1.在本地集群上使用以下命令设置环境变量：2.如果在多个集群中启用跨集群的双向TLS通信，就需要在集群中进行部署配置。当然，如果你的环境只是开发测试或者不需要启用双向TLS通信的话，该步骤完全可以跳过。在远程Kubernetes集群cluster2上运行以下命令，在集群中为生成的CA证书创建Kubernetes密钥：3.在远程Kubernetes集群cluster2上，通过执行以下命令，使用Helm创建Istio remote部署YAML文件。如果启用了双向TLS通信，则需要如下配置参数：然后将Istio remote组件部署到cluster2，如下所示：如果不需要启用双向TLS通信，配置参数则需要做出如下修改：然后将Istio remote组件部署到cluster2，如下所示：确保上述步骤在Kubernetes集群中执行成功。4.创建集群cluster2的Kubeconfig。安装Istio-remote Helm chart后，在远程集群中创建了一个叫istio-multi的Kubernetes服务帐号，该服务帐号用于最小化RBAC访问请求，对应的集群角色定义如下：下面的过程通过使用先前所述的istio-multi服务帐号凭证生成一个远程集群的kubeconfig配置文件。通过以下命令，在集群cluster2上创建服务帐号istio-multi的Kubeconfig，并保存为文件n2-k8s-config：5.将集群cluster2加入Istio Pilot所在集群中。在集群dusterl执行以下命令，将上述生成的集群cluster2的kubeconfig添加到集群cluster1的secret中。执行这些命令后，集群cluster1中的Istio Pilot将开始监听集群cluster2的服务和实例，就像监听集群cluster1中的服务与实例一样：为了演示跨集群访问，在第一个Kubernetes集群cluster1中部署sleep应用服务和版本v1的helloworld服务，在第二个集群cluster2中部署版本v2的helloworld服务，然后验证sleep应用是否可以调用本地或者远程集群的helloworld服务。1.部署sleep和版本v1的helloworld服务到第一个集群cluster1中，执行如下命令：2.部署版本v2的helloworld服务到第二个集群cluster2中，执行如下命令：3.验证在集群cluster1中的sleep服务是否可以正常调用本地或者远程集群的helloworld服务，在集群cluster1下执行如下命令：如果设置正确，则在返回的调用结果中可以看到两个版本的helloworld服务，同时可以通过查看sleep容器组中的istio-proxy容器日志来验证访问的端点IP地址，返回结果如下所示：4.验证Istio路由规则是否生效。创建针对上述两个版本的helloworld服务的路由规则，以便验证Istio配置是否可以正常工作。创建Istio虚拟服务VirtualService，执行如下命令：接着，创建Istio目标规则DestinationRule：如果启用了双向TLS通信，则需要如下配置参数：如果不需要启用双向TLS通信，配置参数则需要做出修改，在YAML定义中添加trafficPolicy.tls.mode:ISTIO_MUTUAL，定义如下所示：通过执行命令kubectl apply创建启用双向TLS的Istio目标规则，如下所示：多次调用helloworld服务，只会返回版本v2的响应结果，如下所示：上述内容就是如何使用Istio进行多集群部署管理及单控制平面VPN连接拓扑，你们学到知识或技能了吗？如果还想学到更多技能或者丰富自己的知识储备，欢迎关注开发云行业资讯频道。

相关推荐: ProxmoxVE 之 从debian拷贝数据到移动硬盘（USB口）

上面左边是我的个人微信，如需进一步沟通，请加微信。 右边是我的开发云主机域名公众号“Openstack私有云”，如有兴趣，请关注。记录一下直接从pve物理机中（debian9）通过usb口直接拷贝数据到移动硬盘中。移动硬盘是使用NTFS文件格式，刚开始直接挂载…