Istio服务网格技术解析与实践（初级篇）

Istio服务网格技术解析与实践（初级篇）目录\h初级篇\h第1章服务网格与Istio\h1.1微服务架构的发展与挑战\h1.2使用应用程序库解决这些挑战\h1.3什么是服务网格\h1.4为什么服务网格是必要的\h1.5Istio服务网格\h1.6本章总结\h第2章快速上手Istio\h2.1在MiniKube上搭建Istio环境\h2.2在DockerDesktop上搭建Istio环境\h2.3使用公有云Istio服务\h2.4在Istio中部署第一个应用程序\h2.5本章总结\h第3章Istio架构剖析\h3.1Istio的整体架构\h3.2剖析Istio控制平面\h3.3剖析Istio数据平面\h3.4剖析Sidecar自动注入\h3.5本章总结初级篇第1章服务网格与Istio第2章快速上手Istio第3章Istio架构剖析第1章服务网格与Istio本章讨论从单体应用程序向分布式的微服务架构进行转型过程中带来的挑战，引出解决这些问题的一个方法，即ServiceMesh服务网格技术。然后阐述了Istio作为服务网格技术的代表作，如何提供一个完整的解决方案来解决这些问题。1.1微服务架构的发展与挑战很长一段时间以来，传统的软件应用程序一般都是作为单个项目开发的，一个项目通常具有单个代码库和单个部署的二进制文件，这种情况适用于小型软件应用程序开发。然而不断扩展的功能要求以及对互联网规模使用模式的需求不可避免地导致了这些代码库日益庞大、复杂甚至不灵活。由于大部分的代码是紧密耦合的，因此这些单一应用程序变得越来越难以维护和操作，即使某一功能的细微变化也可能导致意想不到的整体应用的变化。尤其是在当下缩短软件发布周期的竞争浪潮中，现代应用程序需要进行快速的更新迭代、日常维护、功能升级，以及适应新的安全要求，这些需求都会因为架构设计而导致开发和架构团队手忙脚乱。根据微服务大师MartinFowler的定义，微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制并且相互沟通（通常是基于HTTP的RestfulAPI）。每个服务都围绕着具体的业务进行构建，并且能够被独立地部署到预发布环境或者生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。由此可见，微服务是一种小型、可独立部署的且可独立扩展的软件服务，目的是将特定语义功能封装在更大的应用程序中。现代应用程序可以完全由微服务组成，或者利用微服务作为单一应用程序进化的辅助支持。技术创新者已经将微服务架构作为解决单一应用架构的各种问题的优雅解决方案。通过将应用程序分解为轻量级且解耦的服务，每个服务都满足特定的业务需求，开发团队可以更频繁地部署应用，更有效地扩展应用，并避免软件单一架构带来的其他问题。尽管许多企业仍然处于迁移到微服务架构的开始阶段，当前微服务的使用增长非常显著。根据《GlobalMicroservicesTrends》的调查报告，企业开发团队不希望微服务的势头放缓，几乎所有人（98%）都希望微服务成为默认架构，大多数人（86%）希望在未来五年内实现微服务架构，如图1-1所示。图1-1几乎所有人都希望微服务成为默认架构软件是当今很多公司的生命线，随着我们向更加数字化的世界迈进，最终用户在与这些公司互动时会期望得到更好的便利性、更优的服务质量，而软件将为用户提供这些体验。与此同时，客户的需求是动态变化且不容易预测的，因此，我们的公司和软件系统需要具备这些相同的特性以满足客户需求。对于一些初创公司而言，构建敏捷且能够响应不可预测性的软件系统将是生存的关键因素之一。而对于其他公司来说，无法使用软件使自己具备差异化竞争力则意味着业务增长可能会放缓、衰退甚至可能导致最终折戟。最近软件架构的趋势主要围绕如何扩展团队和技术来实现这种敏捷性。云改变了我们消费基础设施的方式，并改变了我们构建应用程序的条件。微服务、DevOps和云服务等技术能带来开发的灵活性，然而在任何新方法或技术转变带来巨大收益的同时，新的挑战也随之而来并不可避免。当我们探索如何更快地利用云平台和容器等新技术时，会发现过去的一些问题被扩大化了，一些问题变得更难，甚至有些问题似乎无法解决。随着我们开始构建更大更分散的系统，网络必须成为应用程序中的核心设计因素。应用程序本身是否应该实现弹性问题，如重试、超时以及熔断？是否应该让每个应用程序自己实现这些关键功能，还是独立出来作为统一功能提供给每个程序？此外，度量和日志是我们必须收集并用于理解系统的重要手段。随着系统变得更加复杂并部署在弹性的云基础架构上，我们应如何对系统进行检测和监控，从而能够在运行时或者实时地对系统进行理解分析？同样，是否需要提供一个基本的遥测数据收集器可以使系统运维人员在应用程序之外完成收集分析？开发人员作为大型IT系统中的关键资源，其核心价值是编写出更有差异化的软件来提供更好的业务价值。而这些弹性问题、度量指标收集问题并非特定于应用程序逻辑本身，我们想要的是一种以语言和框架无关的方式实现这些功能，并将它们作为应用程序的基础架构服务，可以不用考虑任何特殊应用程序下使用它们。任何开发人员都可以基于这个架构来构建出以云原生应用架构为基础的任何应用程序，而不必担心由于网络而可能引入的令人棘手的应用弹性、度量指标问题。“服务网格”是一个相对较新的术语，用于描述分布式应用程序的网络基础架构，通过它使得应用程序更加安全、更加有弹性，并且可观测性以及灵活可控。服务网格描述了一种由控制平面和数据平面组成的体系架构，其中，数据平面使用应用程序级的代理来管理网络流量，而控制平面用于管理代理。这种架构允许我们在应用程序之外构建这些重要功能，几乎不需要应用程序的干预或太多修改。Istio是服务网格的开源实现，也是目前社区中最为流行的服务网格实现，是基于Kubernetes平台的应用服务网格最佳搭档。Istio允许我们构建可靠安全的云原生系统，并解决一些难以解决的问题，如安全性、策略管理和可观测性，只需极少的（甚至在某些情况下几乎完全不需要）应用程序代码更改。Istio的数据平面由基于Envoy代理的服务代理组成，控制平面实现了API来管理和配置这些Envoy代理。服务代理与应用程序一起用于控制服务网络行为。Istio适用于微服务或SOA风格的体系架构，但不仅限于新的应用程序。现实情况下，大多数组织在现有应用程序和平台上投入了大量资金。他们很可能围绕现有的应用程序构建服务架构，这就是Istio真正闪耀光芒的地方。使用Istio，我们可以解决这些应用程序网络问题，而无需强制更改现有系统。由于服务代理服务于应用程序之外，因此任何架构的任何应用程序都是服务网格中受欢迎的一等公民。本书将介绍Istio，并展示所有这些特性是如何由可能变为现实的，并教你如何使用Istio构建更具弹性的应用程序，你可以在云环境中监视和操作这些应用程序。在此过程中，我们将探索Istio的设计原则，解释为什么它与过去解决这些问题的方式不同。当然，我们不希望开始使用新技术只是因为它是新的时髦技术而已，我们需要花点时间了解为什么要使用Istio，它到底解决了什么问题，要避免哪些问题，以及为什么这项技术会为业务带来价值。如果不充分了解这项技术，我们极有可能会得不到预期的效果。1.2使用应用程序库解决这些挑战第一批了解如何在云环境中运行其应用程序和服务的组织是大型互联网公司，其中许多都是我们今天所熟悉的云基础架构的先驱。这些公司投入了大量的时间和资源来构建库和框架，以便为基于某种语言框架的应用程序提供帮助，解决在云原生架构中运行服务的挑战。幸运的是这些早期的微服务实践者已经慷慨地分享了他们在微服务方面的实践，并贡献了源代码到社区中，例如阿里巴巴开源的微服务框架Dubbo、Netflix向开源社区开放的微服务库、SpringCloud微服务开发体系等。具体来说，在实际项目开发过程中，对于Java程序员，如果采用了Netflix或者SpringCloud等微服务框架，那么势必会使用其程序库处理了云原生的一些问题，包括：·Hystrix——熔断·Ribbon——客户端负载均衡·Eureka——服务注册和发现·Zuul——动态代理由于这些库是针对Java运行时的，因此只能用于Java项目。要使用它们，必须创建一个应用程序依赖项，将它们加入类路径，然后在应用程序代码中使用这些依赖库。通常来说，在Java应用程序构建中如果使用到NetflixOSS程序库（譬如在应用系统中依赖Hystrix），就需要在依赖配置中添加如下信息：<dependency>

<groupId>flix.hystrix</groupId>

<artifactId>hystrix-core</artifactId>

<version>x.y.z</version>

</dependency>

具体来说，要使用Hystrix，就需要使用基本的Hystrix类包装命令HystrixCommand，例如：publicclassCommandHelloWorldextendsHystrixCommand<String>{

privatefinalStringname;

publicCommandHelloWorld(Stringname){

super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));

=name;

}

@Override

protectedStringrun(){

//arealexamplewoulddoworklikeanetworkcallhere

return"Hello"+name+"!";

}

}

可能读者会疑惑为什么在服务网格的书籍中，会讲述类似于NetflixOSS的开源微服务框架。其实，两者所解决的问题是类似的，即微服务架构中分布式特点带来的复杂性问题；然而，两者解决相同问题的方式手段不尽相同，在后续章节中我们希望能通过对Istio网格的讲解，让读者理解它们之间的差异。1.2.1特定应用程序库的缺点当我们将应用程序弹性能力的实现分散到应用程序本身时，显然减轻了对大规模服务架构的担忧，但同时也引入了一些新的挑战。譬如，如果我们希望在架构中引入新服务，它将受限于其他人和其他团队的实施决策。假设在架构中要使用NetflixOSSHystrix，则必须使用Java或某些基于JVM的技术。通常，熔断和负载均衡是一致的，因此需要使用这两个弹性库。若要使用Netflix功能区进行负载均衡，可能还需要使用Eureka的服务注册库。当引入新语言或框架来实现服务时还会引发另一个潜在问题。譬如，你可能会发现NodeJS更适合实现面向用户的API，但已有架构的其余部分都是基于Java语言并利用了NetflixOSS库。你可以选择一组不同的库来实现弹性模式，对于希望引入的每种语言，需要搜索、认证和引入新的开发堆栈。这些库中的每一个库都将具有不同的实现，在某些情况下，你可能无法为每个框架语言组合找到类似的替代方案，最终得到结果的是总体使用效果不一致性。如图1-2所示，这些代码库中包括了服务发现、熔断、限流等功能，版本不同往往会带来冲突问题，而且版本一旦变更，整个应用也要随之全部变更，即使你的应用逻辑并没有任何变化。复杂系统中的微服务实现往往会使用不同的编程语言、不同的框架，这些实现方案往往存在差异大、缺少共性的问题。图1-2特定应用程序库的缺点1.2.2将这些问题推向基础设施这些基本的应用程序网络问题并非特定于某个应用程序、语言或框架。例如，重试、超时、客户端负载均衡，或者熔断等，这些问题与应用程序功能本身相互独立。作为整个服务的一部分，它们是关键问题，但是为使用的每种语言或者框架投入大量时间和资源，以便在特定于语言或框架中实现类似的功能，这不应该是最佳的解决方法。我们真正想要的是以一种技术无关的方式来解决这些问题，并减轻特定于应用程序本身来实现。Linux容器简化了应用程序的打包部署，容器是云原生应用的基石，通过应用容器化，不仅使得开发部署更加敏捷、迁移更加灵活，并且可将这些实现标准化。而容器编排则是更近一步，负责解决如何高效地编排和利用好这些资源。Kubernetes编排容器服务已经成为一种事实标准；同时微服务与容器在轻量、快速部署、运维等特征方面已实现了匹配，微服务运行在容器中也正成为一种标准实践。不论使用什么具体的语言与编程框架，针对应用程序的构造、部署、服务暴露、服务关联/反关联、健康检查以及扩展等，通过使用Kubernetes即可将其提升到新的水平。实际上，Kubernetes也有一个简单的负载均衡和服务发现机制。在Kubernetes中，我们可以使用单个虚拟IP与后端pod进行通信。Kubernetes将以轮询或随机方式自动将流量发送到pod。Kubernetes根据其健康状态以及它们是否与标签和选择器匹配来进行处理。然后，服务可以使用DNS进行服务发现和负载均衡，而不管其实现如何，也就是说无需特殊的语言特定库或注册客户端。在这种技术架构下，Kubernetes将简单的网络问题从应用程序转移到基础架构中。Kubernetes是一个出色的容器部署和管理平台，它为创建通用的分布式系统管理并将其公开为基础架构服务树立了榜样。但是，Kubernetes是一个容器部署平台，它不会演变或应用网络的其他诸多方面，它旨在通过API以非常自然的方式进行扩展，并期望将任何更高阶的应用程序服务构建为插件。而类似于Istio的这些服务网格技术在微服务治理上很好地补齐了Kubernetes的功能，同时又与Kubernetes有着完美的集成，不同于现有的微服务架构，如SpringCloud、Dubbo、NetflixOSS等。将这些问题转移到基础架构中的另外一种方法是使用代理。代理是一个中间基础架构组件，可以处理连接并将它们重定向到适当的后端。我们可以使用代理来处理网络流量，强制执行安全策略以及对后端服务器进行负载均衡等工作。例如，HAProxy是一种简单但功能强大的反向代理，用于在多个后端服务器之间分配连接；mod_proxy是ApacheHTTP服务器的一个模块，它也可以充当反向代理。在我们的企业IT系统中，通常所有传出的互联网流量都通过转发代理进行路由，这些代理监视流量并阻止某些类型的活动。当然，我们需要一个七层代理。这个服务代理将需要理解应用程序架构，能够支持诸如重试、超时、熔断、客户端负载均衡、服务发现、安全性和指标收集等功能，并且不局限于任何特定的语言或框架依赖。1.3什么是服务网格Gartner2018关于服务网格技术趋势分析报告，展示了一系列的服务网格技术，如图1-3所示。划分服务网格技术的依据是基于应用服务代码是否必须对其服务网格感知及其是否锁定，或锁定的程度。基于编程框架的网格技术可以帮助开发人员构建一个架构体系良好的服务，但这会导致应用代码与框架和运行时环境的紧密耦合。而基于Sidecar代理的服务网格技术不会为开发人员设置这些障碍，并且使得管理和维护更加轻松，能够提供更灵活的方法来配置运行时策略。图1-3Gartner2018关于服务网格技术趋势的分析在微服务环境中，可将单一应用程序分解为独立的多个组件，并作为分布式服务进行部署，这些服务通常是无状态的、短暂的、动态可扩展的，运行在容器编排系统（如Kubernetes）中。服务网格一般由控制平面和数据平面组成。具体来说，控制平面是一组在一个专用的命名空间中运行的服务。这些服务完成一些控制管理的功能，包括聚合遥测数据、提供面向用户的API、向数据平面代理提供控制数据等。而数据平面则是由一系列运行在每个服务实例旁边的透明代理构成。这些代理自动处理进出服务的所有流量，因为它们是透明的，所以这些代理充当了一个进程外网络堆栈，向控制平面发送遥测数据并从控制平面接收控制信号。服务实例可以根据需要进行启动、停止、销毁、重建或替换。因此，这些服务需要一个通信中间件来支持服务的动态发现和自我修复连接能力，从而使得这些服务之间能够以安全、动态和可靠的方式相互通信，这就是服务网格所支持的功能，如图1-4所示。服务网格是一个专用的基础设施层，使服务到服务之间的通信更加安全、快速、可靠。如果你正在构建云原生应用程序，则需要服务网格。在过去的一年中，服务网格已成为云原生程序的关键组件，它通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，服务网格通常实现为轻量级网络代理的组合，这些代理与应用程序代码一起部署，而不需要知道应用程序是什么。服务网格作为单独层的概念与云原生应用程序的兴起有关。在云原生模型中，单个应用程序可能包含数百个服务，每个服务可能有数千个实例，并且每个实例可能处于不断变化的状态。这也是为什么像Kubernetes这样的协调器日益流行和必要的原因所在。这些服务之间的通信不仅变得越来越复杂，而且也是运行时环境中最为常见的一部分，因此管理这些服务之间的通信对于确保端到端的性能和可靠性至关重要。图1-4服务网格支持的功能服务网格是一种网络模型，位于TCP/IP之上的抽象层。它假定底层的三四层网络存在并且能够从一点到另一点传送字节。它还假设该网络与环境的其他方面一样不可靠，因此服务网络也必须能够处理网络故障。在某些方面，服务网格类似于TCP/IP。正如TCP协议栈抽象了在网络端点之间可靠地传递字节的机制一样，服务网格抽象了在服务之间可靠地传递请求的机制。与TCP一样，服务网格不关心实际有效负载或其编码方式，只负责完成从服务A发送到服务B，并且在处理任何故障的同时实现这一目标。但是，与TCP不同的是，服务网格不仅仅具备“使其工作”的能力，还提供了一个统一的应用程序控制点，用于将可见性和控制引入应用程序运行时。服务网格的明确目标是将服务通信从不可见的基础设施领域移出，并转变为生态系统的一部分，可以对其进行监控、管理和控制。在云原生应用程序中，保证请求具备完整的可靠性并非易事。服务网络通过各种强大的技术来管理这种复杂性，支持熔断、延迟感知的负载均衡、最终一致性的服务发现、重试与超时等机制来尽可能保证可靠性。这些功能必须全部协同工作，并且与其运行的复杂环境之间的相互作用也非常重要。例如，当通过一个服务网格向服务发出请求时，其交互过程可以大致简化为如下步骤（如图1-5所示）：1）服务网格组件通过应用动态路由规则来确定请求者想要的服务。请求应该路由到生产还是预发布的服务？是路由到本地数据中心还是云中的服务？是需要灰度到正在测试的服务的最新版本，还是仍然路由到在生产中经过验证的旧版本？所有这些路由规则都是动态可配置的，并且可以全局应用，也可以应用于任意流量片段。2）找到正确的目的地后，服务网格组件从相关的服务发现端点检索相应的实例池，可能有多个实例。如果这些信息与服务网格组件在实践中观察到的信息不同，那么它会决定要信任哪些信息来源。3）服务网格组件根据各种因素选择最有可能返回快速响应的实例，包括观察到的最近请求的延迟数据。4）服务网格组件尝试将请求发送到选择的实例，记录响应结果的延迟和响应类型。5）如果实例已经由于各种原因宕机，或者请求根本没有响应，或者由于其他任何原因而无法处理请求，服务网格组件则会根据需要在另一个实例上重试该请求，前提是它知道请求是幂等的。6）如果实例始终返回错误，则服务网格组件会将其从负载均衡池中逐出，以便稍后定期重试。这种情况在互联网分布式应用中非常常见，公共网络中的实例非常有可能由于某些原因导致瞬间故障。7）如果请求的超时点已过，服务网格组件则会主动使请求失败，而不是通过进一步重试来添加负载，以防雪崩发生。这一点对于互联网分布式应用至关重要，否则一个小故障极有可能会引起雪崩式灾难。8）与此同时，服务网格组件以度量指标和分布式跟踪的形式捕获上述行为的各个方面，并将这些数据发送到集中式的度量系统或者链路跟踪系统。图1-5服务网格中的服务代理、注册库值得注意的是，这些功能都是在为分布式应用提供逐点弹性和应用程序范围的弹性能力。大规模分布式系统（无论如何构建）都有一个明确的特征：任何小型本地化故障都有可能升级为系统范围的灾难性故障。服务网格必须设计成在基础系统接近其极限时通过减少负载和快速失败来防止这些故障升级。1.4为什么服务网格是必要的服务网格本身并不是一个新功能，而更像是功能所在位置的转变。Web应用程序始终必须管理服务通信的复杂性。在过去的十五年中，服务网格模型的起源可以追溯到这些应用程序的演变过程。在本世纪初，中型Web应用程序的典型架构常见的是三层应用程序架构，分为应用程序逻辑层、Web服务逻辑层和存储逻辑层，都是单独的层。层之间的通信虽然复杂，但范围有限。这个时候的应用架构并没有网格，但是在每个层的代码处理逻辑之间存在通信逻辑。当网络发展到非常高规模时，这种架构方法开始变得捉襟见肘。特别是一些大型互联网公司，都面临着巨大的流量需求，实现了有效的云原生方法的前身：应用层被分成许多服务，也就是现在通常所知的“微服务”，层之间形成拓扑的通信方式。在这些系统中，通常采用“胖客户端”库的形式，也就是前面讲述过的类似于Netflix的OSS库，Hystrix的熔断能力就是很好的例证。这些代码库虽然与特定的环境相关，并且需要使用特定的语言和框架，但它们是用于管理服务之间通信的形式与能力，在当时的情况下是不错的选择，而且也在众多公司里被使用。进入云原生时代之后，云原生模型有两个重要因素：容器（例如Docker）提供资源隔离和依赖管理，编排层（例如Kubernetes）将底层硬件抽象为同质的资源池。尽管这些代码库组件在一定程度上允许应用程序具备一定的负载扩展能力，并处理云环境中始终存在的部分故障，但是，随着数百个服务或数千个实例的增加，以及存在不时重新调度实例的业务流程层，单个请求通过服务拓扑所遵循的路径可能非常复杂。同时随着容器技术的普及，且容器使每个服务都易于用另一种语言编写运行，程序库式方法在此时此刻就变得捉襟见肘了。这种复杂性和关键性的诉求，使得应用越来越需要一个服务间通信的专用层，该专用层与应用程序代码分离并且能够捕获底层环境的高度动态弹性能力。该层就是我们需要的服务网格。服务代理可以帮助我们在云环境服务架构中添加重要功能。每个应用程序都可以拥有自己的要求或配置，以了解代理在给定其工作负载目标时的行为方式。随着应用程序和服务越来越多，配置和管理大量代理可能非常困难。此外，在每个应用程序实例中使用这些代理可以为构建丰富的高级功能提供机会，否则我们将不得不在应用程序本身执行这些功能。服务代理形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。数据平面负责建立、保护和控制通过网格的流量。负责数据平面如何执行的管理组件称为控制平面。控制平面是网格的大脑，并为网格使用人员提供公开API，以便操纵网络行为。1.5Istio服务网格Istio是一个用于连接/管理以及安全化微服务的开放平台，提供了一种简单的方式用于创建微服务网格，并提供负载均衡、服务间认证以及监控等能力，关键的一点是并不需要修改太多服务就可以实现上述功能。Istio本身是一个开源项目，它提供了一致的方式用于连接、加固、管理和监控微服务，最初是由Google、IBM和Lyft创建的服务网络的开源实现。Istio可以帮助你以透明的方式为服务架构添加弹性和可观察性能力。使用Istio，应用程序不必知道它们是服务网格的一部分。每当应用程序与外界交互时，Istio将代表应用程序处理网络流量。这意味着如果你正在做微服务，Istio可以带来很多好处。Istio主要提供以下功能：·流量管理，控制服务之间调用的流量和API调用，使得调用更可靠，并使网络在恶劣情况下更加健壮。·可观测性，获取服务之间的依赖，以及服务调用的流量走向，从而提供快速识别问题的能力。·策略执行，控制服务的访问策略，不需要改动服务本身。·服务身份和安全，为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。Istio第一个生产可用版本1.0于2018年7月31日正式发布，并于2019年3月发布版本1.1。之后，社区按照快速迭代的方式，在三个月内接连发布了10个小版本。截至本书完稿之际，社区已经发布了1.4版本。Istio的数据平面默认使用Envoy代理，开箱即用，可帮助你配置应用程序以在其旁边部署服务代理的实例。Istio的控制平面由一些组件组成，这些组件为最终用户和运维人员提供运维API、代理的配置API、安全设置、策略声明以及其他更多功能。我们将在本书的后续部分介绍这些控制平面组件。Istio最初是为在Kubernetes上运行而构建的，但却是从部署平台中立的角度实现代码的。这意味着你可以在Kubernetes、OpenShift、Mesos和CloudFoundry等部署平台上利用基于Istio的服务网格，甚至可以在虚拟机、物理裸机上部署Istio环境。在后面的章节中，我们将展示Istio对于包括私有数据中心在内的云组合的混合部署来说有多强大。在本书中，我们将优先考虑在Kubernetes上进行部署，在后面更高级的章节中会引入虚拟机等环节。Istio在希腊语中的意思是“启航”，而Kubernetes在希腊语中可以翻译为“舵手”或“驾驶员”。所以从一开始Istio就期望与Kubernetes很好地配合，高效地运行分布式微服务架构，并提供安全、连接和监控微服务的统一方法。通过每个应用程序实例旁边的服务代理，应用程序不再需要具有特定于语言的弹性库来实现熔断、超时、重试、服务发现、负载均衡等功能。此外，服务代理还处理度量标准收集、分布式跟踪和日志收集等。由于服务网格中的流量流经Istio服务代理，因此Istio在每个应用程序中都有控制点来影响和指导其网络行为。这允许服务运维人员可以控制路由流量，并通过金丝雀部署、暗启动（DarkLaunch）、分级滚动和A/B测试来实现细粒度部署。我们将在后面的章节中探讨这些功能。1.5.1核心功能Istio在服务网络中统一提供了许多关键功能，主要包括流量管理、安全、可观测性、平台支持、集成和定制五个部分。1.流量管理通过简单的规则配置和流量路由，Istio可以控制服务之间的流量和API调用。Istio简化了熔断器、超时和重试等服务级别属性的配置，并且可以轻松设置A/B测试、金丝雀部署和基于百分比的流量分割的分阶段部署等重要任务。Istio有开箱即用的故障恢复功能，你可以在问题出现之前先发现问题，通过优化使服务之间的调用更加可靠。2.安全Istio具备强大的安全功能，使开发人员可以专注于应用程序级别的安全性。Istio提供底层安全通信信道，并大规模管理服务通信的认证、授权和加密。使用Istio，服务通信在默认情况下是安全的，允许跨多种协议和运行时一致地实施策略，而关键的是所有这些都很少或根本不需要应用程序更改。虽然Istio与平台无关，但将其与Kubernetes网络策略一起使用时，其优势更大，包括在网络和应用层保护pod-to-pod或服务到服务通信的能力。后续章节中会讲述如何在Kubernetes中结合网络策略与Istio来共同保护服务。3.可观测性Istio具备强大的追踪、监控和日志记录能力，可让你深入了解服务网格部署。通过Istio的监控功能，可以真正了解服务性能如何影响上游和下游的功能，而其自定义的仪表板可以提供对所有服务性能的可视性，并让你了解该性能如何影响其他进程。Istio的Mixer组件负责策略控制和遥测收集，提供后端抽象和中介，将Istio的其余部分与各个后端基础设施的实现细节隔离开来，并为运维人员提供对网格和后端基础设施之间所有交互的细粒度控制。所有这些功能可以让你更有效地设置、监控和实施服务上的服务等级目标SLO。当然，最重要的是可以快速有效地检测和修复问题。4.平台支持Istio是独立于平台的，目标是可以在各种环境中运行，包括跨云、内部部署、Kubernetes、Mesos等。你可以在Kubernetes上部署Istio或在具有Consul的Nomad上部署。Istio目前支持：·在Kubernetes上部署的服务。·使用Consul注册的服务。·在各个虚拟机上运行的服务。5.集成和定制可以扩展和自定义Istio的策略实施组件，以与现有的ACL、日志记录、监控、配额、审计等解决方案集成。此外，从版本1.0开始，Istio支持基于MCP（MeshConfigurationProtocol，网格配置协议）进行配置分发。通过使用MCP，可以很容易地集成外部系统，例如可以自己实现MCP服务器，然后将其集成到Istio中。MCP服务器可以提供以下两个主要功能：·连接并监控外部服务注册系统，以获取最新的服务信息（例如Eureka、ZooKeeper等系统）。·将外部服务信息转换为IstioServiceEntry并通过MCP资源发布。1.5.2为什么要使用Istio在从单体应用程序向分布式微服务架构的转型过程中，开发人员和运维人员面临诸多挑战，使用Istio可以解决这些问题。随着规模和复杂性的增长，服务网格越来越难以理解和管理，各种需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及更加复杂的运维，例如A/B测试、金丝雀发布、限流、访问控制和端到端认证等。Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。Istio提供一种简单的方式来为已部署的服务建立网络，该网络具有负载均衡、服务间认证、监控等功能，只需要对服务的代码进行一点改动或不需要做任何改动。想要让服务支持Istio，只需要在你的环境中部署一个特殊的Sidecar代理，使用Istio控制平面来配置和管理代理，拦截微服务之间的所有网络通信。此外，面向服务的架构（SOA）的企业服务总线（ESB）与服务网格有一些相似之处，在SOA体系架构中ESB对于应用程序服务来说是透明的，这意味着应用程序对它无感知。服务网格可以得到类似的行为，服务网格应该对应用程序透明，就像ESB那样，简化服务间的调用。当然，ESB还包括交互协议的中转、消息转换，或者基于内容的路由之类的事情，而服务网格不负责ESB所做的所有功能。服务网格确实通过重试、超时、熔断提供服务请求的弹性能力，同时也提供服务发现和负载均衡等服务。复杂的业务转换、业务流程编排、业务流程异常，以及服务编排能力等并不属于服务网格的解决范畴。相对于ESB的集中式系统，服务网格中的数据平面高度分布，其代理与应用程序并存，这消除了ESB架构中经常出现的单点故障瓶颈问题。当然，也需要清楚服务网格没有解决哪些问题，像Istio这样的服务网格技术通常都提供了强大的基础架构功能，可以触及分布式架构的许多领域，但肯定不能解决你可能遇到的每个问题。理想的云架构能从实现的每个层中分离出不同的关注点。在基础架构的低层，更加关注基础设施，如何提供自动化部署的基础架构能力。这有助于将代码部署到各种平台上，无论是容器、Kubernetes，还是虚拟机等。Istio不会限定你应该使用哪种自动化部署工具。在更高的业务应用级别，应用程序业务逻辑是企业保持核心竞争力的差异化资产。这些代码资产涉及了包括业务功能单一以及需要调用的服务，以何种顺序执行，如何执行这些服务的交互，如何将它们聚合在一起，以及在发生故障时要执行的操作等。Istio不实现或替换任何业务逻辑，它本身不执行服务编排，也不会提供业务负载的内容转换或者增强，不会针对负载进行拆分或者聚合。这些功能最好留给应用程序中的库和框架来实现。图1-6是关于云原生应用程序中的关注点分离，其中Istio对应用程序层起支持作用并位于较低级别的部署层之上。Istio扮演着部署平台和应用程序代码之间的连接角色。它的作用是促进从应用程序中取出复杂的网络逻辑，可以基于作为请求的一部分的外部元数据（例如HTTP标头等）来执行基于内容的路由。也可以根据服务和请求的元数据匹配进行细粒度的流量控制和路由。还可以保护传输和卸载安全令牌验证，或者可以实施服务运维人员定义的配额和使用策略等。图1-6云原生应用中的关注点分离了解Istio的能力，与其他系统的相似之处以及它在架构中的位置，可帮助我们像我们过去可能遇到的有前途的技术那样犯同样的错误至关重要。1.5.3成熟度和支持级别Istio社区针对每个组件功能的相对成熟度和支持级别，提出了不同的功能阶段定义，分别用Alpha、Beta和Stable来描述各自的状态，如表1-1所示。表1-1Istio社区针对每个组件功能的相对成熟度和支持级别表1-2是我们摘录的Istio1.4版本现有功能中已经达到Beta及Stable功能阶段的列表。此信息将在每次发布后更新，可参照官方网站获取更新状态。表1-2Istio1.4版本中已经达到Beta及Stable功能阶段的列表当然，Istio仍然有一些功能还处于Alpha状态，如IstioCNI插件，它能够代替istio-init容器完成同样的网络功能，而且无需Istio用户额外申请KubernetesRBAC授权；以及在Envoy中使用自定义过滤器的能力等等。相信在后续不断完善中，这些功能将逐渐变得越来越稳定且生产可用。1.6本章总结Istio作为当前业界服务网格领域中最流行的实现，其功能允许你在混合环境中简化云原生服务架构应用的运行和操作。Istio使开发者专注于使用自己喜欢的编程语言构建服务功能，这有效地提升了开发者的生产力，同时开发者免于将解决分布式系统问题的代码糅合到业务代码中。Istio是一个完全开放的开发项目，拥有一个充满活力、开放和多元化的社区，它的目标是赋能开发者和运维人员，使他们在所有环境中都能敏捷地发布和维护微服务，拥有底层网络的完全的可见性，且获得一致的控制和安全能力。在本书的后续部分，我们将展示如何利用Istio的功能在云原生世界中运行微服务。第2章快速上手Istio本章介绍如何从头开始快速搭建Istio环境，用于个人开发测试，还介绍基于公有云Kubernetes（K8S）服务如何搭建用于企业级应用开发及生产运行的Istio环境，以及包括公有云提供商提供的Istio服务环境，并带领读者部署第一个Istio应用程序。读者可以在搭建好的Istio环境中部署一个应用程序来体验Istio的功能。2.1在MiniKube上搭建Istio环境为了方便大家开发和体验Kubernetes，社区提供了可以在本地部署的Minikube。由于网络访问原因，很多朋友无法使用Minikube进行实验。为此我们提供了一个修改版的Minikube，可以从阿里云的镜像地址来获取所需的Docker镜像和配置。Minikube在不同操作系统上支持不同的驱动：·macOS：xhyvedriver、VirtualBox或VMwareFusion。·Linux：VirtualBox或KVM。·Windows：VirtualBox或Hyper-V；注意，在Windows环境下，如果开启了Hyper-V，则不支持VirtualBox方式。2.1.1安装启动Minikube我们提供了一个国内可访问的Minikube修改版的文件，可以直接下载使用。MacOSX用户可通过以下命令安装Minikube：curl-Lominikube

/minikube/releases/v0.30.0/minikube-darwin-amd64&&chmod+xminikube&&sudomvminikube/usr/local/bin/

Linux用户可通过以下命令安装Minikube：curl-Lominikube/minikube/releases/v0.30.0/minikube-linux-amd64&&chmod+xminikube&&sudomvminikube/usr/local/bin/

Windows用户可通过以下方式下载安装Minikube：\h/minikube/releases/v0.30.0/minikube-windows-amd64.exe?spm=a2c4e.11153940.blogcont221687.28.7dd54cecA8DSic&file=minikube-windows-amd64.exe，并重命名为minikube.exe。Minikube默认使用VirtualBox驱动来创建Kubernetes本地环境，可以通过以下命令启动：minikubestart--registry-mirror=

默认会启动最新版本的Kubernetes，也可以指定不同的Kubernetes版本，如下所示：#安装Kubernetesv1.12.1

minikubestart--registry-mirror=--kubernetes-versionv1.12.1

#安装Kubernetesv1.11.3

minikubestart--registry-mirror=--kubernetes-versionv1.11.3

在执行上述命令过程中会下载MinikubeISO文件，如果由于网络原因无法下载，可以先通过其他方式获取该ISO文件，然后在启动命令中加上参数--iso-url并执行ISO文件，例如：minikubestart--registry-mirror=--kubernetes-versionv1.12.1--iso-url=file://tmp/minikube-v0.30.0.iso

以Kubernetesv1.12.1为例，在Mac机器上进行安装部署，应该有如下类似的执行结果：minikubestart--registry-mirror=--kubernetes-versionv1.12.1

StartinglocalKubernetesv1.12.1cluster...

StartingVM...

DownloadingMinikubeISO

170.78MB/170.78MB[============================================]100.00%0s

GettingVMIPaddress...

Movingfilesintocluster...

Settingupcerts...

Connectingtocluster...

Settingupkubeconfig...

Startingclustercomponents...

Kubectlisnowconfiguredtousethecluster.

Loadingcachedimagesfromconfigfile.

接着运行如下命令，可以查看安装后的Kubernetes控制台：minikubedashboard

2.1.2安装部署Helm使用Helm安装和配置是将Istio安装到你的开发环境，这是推荐安装方式，因为它为Istio控制平面和数据平面Sidecar提供了丰富的配置。因此首先在Kubernetes中安装Helm。可以根据Helm的官方文档安装：\h/helm/helm/blob/master/docs/install.md，具体来说，方法如下。在MacOS上安装：#UsehomebrewonMac

brewinstallkubernetes-helm

#InstallTillerintoyourKubernetescluster

helminit--upgrade-i/google_containers/tiller:

v2.12.2--skip-refresh

#updatechartsrepo(Optional)

helmrepoupdate

在Windows上安装：#UseChocolateyonWindows

#注：安装的时候需要保证网络能够访问googleapis这个域名

chocoinstallkubernetes-helm

#InstallTillerintoyourKubernetescluster

helminit--upgrade-i/google_containers/tiller:

v2.12.2--skip-refresh

#updatechartsrepo(Optional)

helmrepoupdate

2.1.3安装部署Istio接着，按照如下步骤安装部署Istio。1）进入到Istiorelease下载页面\h/istio/istio/releases，下载对应目标操作系统的安装文件。在macOS或者Linux系统中，还可以运行下面的命令，进行下载和自动解压缩：curl-Lhttps://git.io/getLatestIstio|sh-

2）进入Istio包目录。例如，假设这个安装包是istio-1.4.0，进入该目录即执行cdistio-1.4.0。安装目录中包含以下内容：·install/目录中包含了Kubernetes安装所需的.yaml文件。·samples/目录保存示例应用。·bin/目录保存istioctl客户端文件，istioctl的功能是手工进行EnvoySidecar的注入等其他操作。·istio.VERSION为配置文件。然后，把istioctl客户端加入PATH环境变量。3）通过Helm命令，安装istio-initHelmChart以创建所有Istio所需的自定义资源CRD：helminstallinstall/kubernetes/helm/istio-init--nameistio-init--namespaceistio-system

4）使用以下命令验证是否已将所有IstioCRD提交到Kubernetesapi-server：kubectlgetcrds|grep'istio.io\|certmanager.k8s.io'|wc-l

5）通过Helm命令，安装istioHelmChart以创建Istio组件：helminstallinstall/kubernetes/helm/istio--nameistio--namespaceistio-system

执行上述命令之后，等待几分钟，待所有Istio相关的容器启动正常之后，查看Kubernetes控制台，得到如图2-1所示的画面。图2-1安装后的Istio资源如果在启动过程中，由于内存限制不能正常启动istio-pilot，可以修改istio-pilot部署YAML定义中的内存大小，默认为2Gi；此外还可以修改istio-pilot的容器组水平伸缩器，将最大副本数从5减小到1，如图2-2所示。图2-2IstioPilot容器组如果需要调整Minikube虚拟机的内存大小，可以通过config命令进行配置，如下所示：minikubeconfigsetmemory8192

Thesechangeswilltakeeffectuponaminikubedeleteandthenaminikubestart

如提示所言，需要删掉已有的Minikube，重新启动一个才会生效。其实也可以通过直接修改虚拟机内存和CPU的方式进行调整，即执行minikubestop命令，等待虚拟机停止之后，通过VirtualBox界面调整内存和CPU，然后重新启动Minikube使这些配置生效，如下所示：minikubestart

StartinglocalKubernetesv1.10.0cluster...

StartingVM...

GettingVMIPaddress...

Kubernetesversiondowngradeisnotsupported.Usingversion:v1.12.1

Movingfilesintocluster...

Settingupcerts...

Connectingtocluster...

Settingupkubeconfig...

Startingclustercomponents...

Kubectlisnowconfiguredtousethecluster.

Loadingcachedimagesfromconfigfile.

kubectllabelnamespacedefaultistio-injection=enabled

kubectlapply-fsamples/bookinfo/platform/kube/bookinfo.yaml

kubectlapply-fsamples/bookinfo/networking/bookinfo-gateway.yaml

要获取Minikube的ip地址，执行如下命令：exportINGRESS_HOST=$(minikubeip)

以下命令将服务istio-ingressgateway的类型修改为NodePort，并获取对应的端口：exportINGRESS_PORT=$(kubectl-nistio-systemgetserviceistio-ingressgateway-ojsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

通过执行如下命名部署应用示例Bookinfo：kubectllabelnamespacedefaultistio-injection=enabled

kubectlapply-fsamples/bookinfo/platform/kube/bookinfo.yaml

kubectlapply-fsamples/bookinfo/networking/bookinfo-gateway.yaml

确认相应的Pod启动成功之后，然后在浏览器中输入\hhttp://${INGRESS_HOST}:${INGRESS_PORT}/productpage，可以确认Bookinfo应用的运行情况，如图2-3所示。图2-3Bookinfo应用示例如果刷新几次应用的页面，productpage页面中会随机展示reviews服务的不同版本的效果（用红色、黑色的星形，或者没有显示）。reviews服务出现这种情况是因为我们还没有使用Istio来控制版本的路由。在后续章节中可以学习到如何使用Istio的路由能力。2.2在DockerDesktop上搭建Istio环境Docker社区版（CE）是开发人员和小型团队试用Docker和容器应用的理想之选，适用于许多主流的基础设施平台，如桌面、云和开源操作系统。DockerCE提供了简单快速的安装程序，安装后即可立即着手应用开发。因为DockerCE根据基础设施进行了集成和优化，所以在使用Docker时能够像使用本机应用一样具有流畅的使用体验。有了Docker社区版，你可以构建自己的第一个容器，并与团队伙伴共享，还能自动设置好开发流程。2.2.1安装配置DockerDesktopforKubernetes如果需要一个DockerforMac或者DockerforWindows的安装包，可以到官方网站\h/community-edition中去下载最新版本。由于Kubernetes大量的容器镜像在gcr.io，无法在国内保证稳定的访问，我们提供了一些工具脚本，帮助开发者从阿里云镜像服务所需镜像。通过如下命令，可以下载这些镜像的脚本文件：gitclone/AliyunContainerService/k8s-for-docker-desktop

cdk8s-for-docker-desktop

1.在DockerforMac中开启Kubernetes如果是在Mac上运行DockerDesktop，首先为Dockerdaemon配置DockerHub的中国官方镜像加速：\h，如图2-4所示。根据实际机器资源情况为Kubernetes配置CPU和内存资源，建议分配4GB或更多内存，如图2-5所示。图2-4Dockerdaemon配置图2-5开启Kubernetes预先从阿里云Docker镜像服务下载Kubernetes所需要的镜像，可以通过修改perties文件加载自己需要的镜像，如下所示：./load_images.sh

开启Kubernetes，并等待Kubernetes开始运行，如图2-6所示。图2-6开启Kubernetes2.在DockerforWindows中开启Kubernetes如果是在Windows上运行DockerDesktop，首先为Dockerdaemon配置DockerHub的中国官方镜像加速：\h，如图2-7所示。图2-7Dockerdaemon配置根据实际机器资源情况为Kubernetes配置CPU和内存资源，建议分配4GB或更多内存，如图2-8所示。图2-8开启Kumbernetes预先从阿里云Docker镜像服务下载Kubernetes所需要的镜像，可以通过修改perties文件加载自己需要的镜像，如下所示：·执行如下Bashshell命令：./load_images.sh

·执行如下PowerShell命令：.\load_images.ps1

提示如果因为安全策略无法执行PowerShell脚本，请在“以管理员身份运行”的PowerShell中执行Set-ExecutionPolicyRemoteSigned命令。与在Mac上运行DockerDesktop一样，开启Kubernetes，并等待Kubernetes开始运行。2.2.2切换Kubernetes切换Kubernetes运行上下文至docker-for-desktop如下所示：kubectlconfiguse-contextdocker-for-desktop

可以通过如下命令确认Kubernetes集群是否正常运行：或者查看Kubernetes集群的节点信息，以了解它的状态，如下所示：接下来，我们要想启动Kubernetes仪表板，还得在集群中部署kubernetes-dashboard.yaml，如下所示：kubectlcreate-f/kubernetes/dashboard/v1.10.1/

src/deploy/recommended/kubernetes-dashboard.yaml

部署成功后，启动Proxy，通过如下命令开启APIServer访问代理：kubectlproxy

通过如下URL访问Kubernetes仪表板，如图2-9所示：http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

图2-9访问Kubernetes仪表板你可以选择已配置用来访问集群的kubeconfig文件，也可以指定使用保密字典来保存持有者令牌，用来在仪表板登录的每个服务帐号都会有保密字典。可以通过以下方式获取令牌：·对于Mac环境：kubectl-nkube-systemdescribesecretdefault|awk'$1=="token:"{print$2}'

TOKEN=$(kubectl-nkube-systemdescribesecretdefault|awk'$1=="token:"{print

$2}')

echo"${TOKEN}"

·对于Windows环境：TOKEN=((kubectl-nkube-systemdescribesecretdefault|Select-String"token:")

-split"+")[1]

echo"${TOKEN}"

登录之后即可以看到安装好的Kubernetes，如图2-10所示。2.2.3安装部署Helm使用Helm安装和配置是将Istio安装到生产环境的推荐安装方式，因为Helm为Istio控制平面和数据平面Sidecar提供了丰富的配置。首先要在Kubernetes中安装Helm。可以根据Helm的官方文档安装，地址为\h/helm/helm/blob/master/docs/install.md，安装好的Kubernetes如图2-10所示。图2-10查看安装好的Kubernetes·在MacOS上安装：#UsehomebrewonMac

brewinstallkubernetes-helm

#InstallTillerintoyourKubernetescluster

helminit--upgrade-i

/google_containers/tiller:v2.12.2--skip-refresh

#updatechartsrepo(Optional)

helmrepoupdate

·在Windows上安装：#UseChocolateyonWindows

#注：安装的时候需要保证网络能够访问googleapis这个域名

chocoinstallkubernetes-helm

#InstallTillerintoyourKubernetescluster

helminit--upgrade-i

/google_containers/tiller:v2.12.2--skip-refresh

#updatechartsrepo(Optional)

helmrepoupdate

2.2.4安装部署Istio接着，按照以下步骤安装部署Istio。1）进入Istiorelease下载页面。从\h/istio/istio/releases下载对应目标操作系统的安装文件。在macOS或者Linux系统中，还可以运行下面的命令，进行下载和自动解压缩：curl-Lhttps://git.io/getLatestIstio|sh-

2）进入Istio包目录。例如，假设这个安装包是istio-1.4.0，进入该目录，即执行cdistio-1.4.0。安装目录中包含：·install/目录中包含Kubernetes安装所需的.yaml文件。·samples/目录中包含示例应用。·bin/目录中保存istioctl客户端文件，istioctl的功能是手工进行EnvoySidecar的注入等其他操作。·istio.VERSION配置文件。然后，把istioctl客户端加入PATH环境变量。3）通过Helm命令，安装istio-initHelmChart以创建所有Istio所需的自定义资源CRD，如下所示：helminstallinstall/kubernetes/helm/istio-init--nameistio-init--namespaceistio-system

4）使用以下命令验证是否已将所有IstioCRD提交到Kubernetesapi-server：kubectlgetcrds|grep'istio.io\|certmanager.k8s.io'|wc-l

5）通过Helm命令，安装istioHelmChart以创建Istio组件，如下所示：helminstallinstall/kubernetes/helm/istio--nameistio--namespaceistio-system

6）如果要卸载Istio，可以按照如下方式进行：helmdelete--purgeistio

helmdelete--purgeistio-init

按照设计原则，Istio期望安装文件CRD中包含的Istio的自定义资源能够提交到Kubernetes环境中。CRD包含运维者设置的一些运行时配置。因此，我们认为应该交与运维者来明确是否、什么时候删除运行时的配置数据更为合适，而不是随意删除它。需要注意一点的是，删除CRD会永久删除你对Istio所做的任何配置更改。在istio-initHelmChart包含的目录istio-init/files中，定义了Istio所需的所有自定义资源CRD。获取此HelmChart后，只需通过kubectl删除这些CRD即可，如下所示：kubectldelete-finstall/kubernetes/helm/istio-init/files

2.3使用公有云Istio服务除了可以在MiniKube和DockerDesktop上安装部署Istio之外，当前较大的公有云服务商都已经不同程度地支持Istio服务，例如阿里云容器服务Kubernetes1.10.4及之后版本均支持部署Istio，如果是1.10.4之前的版本，请先升级到1.10.4或之后版本。下面以阿里云容器服务Kubernetes为例，了解一下当前的公有云Istio服务。1）前提条件。·已经成功创建一个Kubernetes集群，创建Kubernetes集群参见：\h/document_detail/86488.html。·以主账号登录，或赋予子账号足够的权限，如自定义角色中的cluster-admin，可参考子账号Kubernetes应用权限配置指导：\h/document_detail/87656.html?spm=a2c4g.11186623.2.11.b6ba21d6Zq1sSY#concept-qlf-lv4-f2b。2）操作步骤。登录容器服务管理控制台，单击左侧导航栏中的集群，进入集群列表页面。选择所需的集群并单击操作列“更多>部署Istio”，如图2-11所示。图2-11登录容器服务管理控制台3）根据表2-1中的信息，部署Istio，如图2-12所示。表2-1部署Istio的信息图2-12部署Istio表2-2为各项配置说明，配置页面如图2-13所示。表2-2配置说明如下图所示：图2-13Istio参数配置4）单击部署Istio，启动部署。在部署页面下方，可实时查看部署进展及状态，如图2-14所示。图2-14查看部署进展5）可通过以下方法查看部署是否成功：在部署Istio页面下方，部署Istio变为已部署，如图2-15所示。图2-15查看部署是否成功或者，单击左侧导航栏“应用>容器组”，进入容器组页面。选择部署Istio的集群及命名空间，可查看到已经部署Istio的相关容器组，如图2-16所示。图2-16已经部署的Istio相关容器组2.4在Istio中部署第一个应用程序在开始之前，确认上述Kubernetes集群中的Istio安装部署完毕，并正常启动。接下来我们在Istio环境中正式部署第一个应用程序。该示例应用是一个面向用户的投票应用程序，提供了两个投票选项：对于Istio和其他的服务网格你更喜欢哪个？此外，还有一个用于保存各个选项的投票数的存储组件，以及一个用于提供各个选项的投票详细信息的分析组件。首先将部署投票应用程序的1.0版本及分析组件的1.0版本。此分析组件将对投票数进行简单计数。投票应用和分析组件与由Redis支持的存储组件1.0版本进行交互。然后，将分析组件升级到提供计数和当前总数及百分比的2.0版本。一部分用户将通过灰度发布测试应用的2.0版本。确信该2.0版本按预期方式作用于该部分用户后，向所有用户推出2.0版本。1.部署应用程序1.0版本首先将应用程序部署到安装了Istio的Kubernetes集群中，可以是上述章节中介绍的Minikube、DockerDesktopforKubernetes，也可以是公有云上的Kubernetes集群等。图2-17说明了本部分结束时运行的内容：所有组件的1.0版本及由IstioIngress网关维护的入站请求。该示例应用所需的项目可在GitHub存储库中获取，具体地址为\h/osswangxining/istio-book。下载这些项目或克隆该存储库，并转到下载/克隆的存储库中的以下文件夹中，从此文件夹中运行所有后续步骤，如下所示：cd/intelligent-routing-with-istio

首先，在Kubernetes集群中为投票应用示例创建命名空间，并命名为“voting”，如下所示：kubectlcreatenamespacevoting

为此命名空间添加一个标签istio-injection=enabled，这个标签会指示Istio自动将Istio代理作为Sidecar注入到此命名空间中的所有pod中，如下所示kubectllabelnamespacevotingistio-injection=enabled

图2-17部署应用程序1.0的组件现在，我们将创建投票应用的组件，在上一个步骤所创建的voting命名空间中创建这些组件，执行如下命令：kubectlapply-fkubernetes/step-1-create-voting-app.yaml--namespacevoting

下面的示例输出说明已成功创建资源：deployment.apps/voting-storage-1-0created

service/voting-storagecreated

deployment.apps/voting-analytics-1-0created

service/voting-analyticscreated

deployment.apps/voting-app-1-0created

service/voting-appcreated

使用kubectlgetpods命令查看示例应用已创建的pod是否启动正常，如下所示：kubectlgetpods-nvoting

NAMEREADYSTATUSRESTARTSAGE

voting-analytics-1-0-645cfc8475-qb5l72/2Running03m

voting-app-1-0-57f867bbd5-dt9z42/2Running03m

voting-storage-1-0-f775b5df7-vjzh42/2Running03m

上面的示例输出显示了有三个pod实例，分别为一个投票应用pod实例、一个投票分析pod实例和一个投票存储pod实例。每个pod有两个容器，一个容器是组件，另一个是Istio代理。使用kubectldescribepod查看pod的相关信息。将pod名称替换为前面输出的集群内的某个pod的名称，如下所示：kubectldescribepod--namespacevotingvoting-app-1-0-

为了能在外部访问示例应用，需要创建Istio网关和虚拟服务。网关是位于服务网格边缘的组件，用于接收入站或出站HTTP和TCP流量。虚拟服务将定义一组适用于一个或多个目标服务的路由规则。这些Istio资源将来自默认IstioIngress网关的流量路由到应用程序。使用如下命令部署网关和虚拟服务yaml：kubectlapply-fistio/step-1-create-voting-app-gateway.yaml--namespacevoting

以Minikube或者公有云支持负载均衡器的Kubernetes为例，使用下面的命令获取Istio入口网关的端口：使用http时的端口：e