《Kubernetes网络权威指南(基础、原理与实践)(1).docx》由会员分享,可在线阅读,更多相关《Kubernetes网络权威指南(基础、原理与实践)(1).docx(5页珍藏版)》请在第一文库网上搜索。
1、生成CN1插件的配置,并将其插到CN1配置插件链的末尾,其中CNI的配置文件路径是KUbe1et启动参数-cniconfdr所指定的目录,默认是/etc/cni/net.d;watch-cni-conf-dir目录下的CN1配置,用来检测是否有配置更新并在内存中重载:watch存储istio-cni-node自身的配置ConfigM叩对象,检测到有修改就重新执行CN1配置生并与下发流程。6.5除了微服务,Istio还能做更多在前面的章节中,我们探讨了微服务新的设计模式:SideCar模式及IStio创新的架构在微服务中扮演的重要角色。在笔者看来,Istio的能量绝不仅仅体现在微服务领域。它将在
2、现代网络基础设施的路由和安全领域扮演非常重要的角色,其至极有可能颠覆现有的网络基础设施,成为未来混合云的基石。Istio在混合云中的应用为什么需要混合云这种形态的“云”?混合云有多种组成形式,形式一是公有云和私有云的融合,形式二是多种公有云的互补。先来看公有云和私有云融合这种形式的混合云。笔者曾供职于国内线公有云团队,虽然笔者相信最终所有的私有云都会被公有云收编,但我们必须意识到用户在公有云的数据隐私保护等方面仍有所保留,些经济效益好的企业(例如金融等),在现阶段更喜欢自建专有云平台。而混合云可以认为是对当前这种公有云和私有云共存现状的妥协,做到公有云和私有云的优势互补。例如,用户可以同时享受
3、云的优势(灵活性、可扩展性、成本降低)和本地的好处(安全性、低延迟、硬件复用)。如果用户是首次把业务迁移到云端,采用混合云步骤可以按照用户自己的节奏,以最适合业务的方式进行。此外,私有云的一些业务在峰值时可以弹性扩容到公有云上。而采用多共有云的混合云意味着应用可以跨多个公共云平台运行。使用多个云提供商可以帮助用户避免厂商锁定,并为实现用户目标选择最佳的云服务。笔者的经验是,无论应用程序是运行在容器中,还是在虚拟机中,采用混合服务网格可以简化混合云应用程序管理,网络流量治理,并且实现安全性和可靠性。卜面我们将讨论如何使用IStiO来支持混合服务网格。1多集群IStiO之一个控制平面使用IStiO
4、管理多个KUben1eteS集群(代表多个云)的一种方法是先部署一个KUberneteS集群,然后配置该集群连接到远程的Istio控制平面(同样运行在KUbemeteS中)。需要注意的是,这两个集群中的KubernetesPod蛊要相互通信。这种多集群的架构常用的场景有: 用户逐步将在测试集群中验证过的新功能过渡到生产集群: 准备处理故障转移的备用集群; 跨地域或可用区的冗余集群。图6-7演示的是跨越两个不同的可用区(例如US-Centra1和us-east,但底层网络仍然可达)部署多集群Isti。我们先在个KUbemeteS集群上安装IStiO控制平面,在另一个KUberneteS集群上安装
5、IStio的远程组件(包括SideCar代理注入器)。在这两个集群中,我们可以跨KUbemeteS集群部署应用程序。图67多集群IScio之个控制平面这种单控制平面的部署无须改变任何有关微服务之间相互通信的信息。例如,只要两个集群底层网络打通,前端仍然可以使用本地KUbemeteSDNS域名(CartSerVice:Port)访问CartSerVice。这是最基本的多集群ISti。示例,下面进步演示稍微复杂点的部署方式。2多集群IStiO之两个控制平面假设在本地和云中或跨云平台运行应用程序,为了使Istio跨越这些不同的环境,两个集群内的Pod必须能够跨越网络边界。图6-8演示了使用两个ISt
6、io控制平面,每个集群各个,形成个双头逻辑服务网格。两个集群间的流量交互是通过IStio的IngreSSGateway,而不是使用SideCar代理直接相互通信。IStiO1ngreSSGateWay也是个EnVoy代理,但它专门用于进出集群Istio网格的流量。在两个控制平面拓扑中,IStio安装辅助DNS服务器(COreDNS),该服务器解析本地集群的外部服务的域名。对于那些外部服务,流量在IstioIngreSS网关之间透传,然后转移到相关服务。为使跨两个集群运行的微服务能够互相通信,我们还通过IStiOSerViCeEntry完成此操作。IstioSerViCeEntry用于手动添加不
7、在当前服务网格内的服务,例如,我们将集群2的前端服务条目通过IStiOSerViCeEntry添加到集群1中,这样来集群1就知道集群2中运行的服务。与第个演示不同,这种双控制平面的IStiO设置不需要集群之间的扁平网络,只需要把IStio网关暴露在Intemet上即可。这意味着两个集群之间的Pod允许有重叠的网断,而且每个集群内的服务可以在各自的网络环境中安全运行。3.将虚拟机纳入IStio鉴于很多遗留系统仍运行在虚拟机中,因此我们得想办法使用ISUo把虚拟机和容器起管理,让虚拟机应用也能享受IStio服务网格带来的福利。图69演示了GKE(GoOg1e的容器服务)上运行ISti。时集成Goo
8、g1eGCE(GOOgIe的虚拟机服务)的实例。我们像以前一样部署相同的应用程序。但这一次,一个服务(PrOdUCtCataIOg)被部署在KUbCn1CteS集群之外的外部虚拟机上运行。该GCE虚拟机运行组最小的IStiO组件集,以便能够与中心的IStiO控制平面通信。然后,我们将IStioSerViCeEr1try对象部署到GKE集群上,该集群在逻辑上将外部ProdUCt-CataIOgSerViCe添加到IStiO网格中。通过这种IStiO配置模型,运行在虚拟机中的ProdUCtCata1ogSerViCe逻辑像是运行在KUbemeteS集群内部一样。用户可以为PrOdUCtCataIogSerViCe添加IStio策略和规则,也可以为虚拟机的所有入站流量信用双向T1S等IStiO服务治理的功能。需要注意的是,虽然图6-9使用GCE进行演示,但用户可以在物理机上或使用本地虚拟机运行相同的示例。通过这种方式,用户可以将IStio的现代云原生原则带到在任何地方运行的虚拟机或物理机中。