1.5 Istio与Kubernetes

Kubernetes是一款用于管理容器化工作负载和服务的可移植、可扩展的开源平台，拥有庞大、快速发展的生态系统，它面向基础设施，将计算、网络、存储等资源进行紧密整合，为容器提供最佳运行环境，并面向应用提供封装好的、易用的工作负载与服务编排接口，以及运维所需的资源规格、弹性、运行参数、调度等配置管理接口，是新一代的云原生基础设施平台。

从平台架构而言，Kubernetes的设计围绕平台化理念，强调插件化设计与易扩展性，这是它与其他同类系统的最大区别之一，保障了对各种不同客户应用场景的普遍适应性。另外，Kubernetes与其他容器编排系统的显著区别是Kubernetes并不把无状态化、微服务化等条件作为在其上可运行的工作负载的约束。

如今，容器技术已经进入产业落地期，而Kubernetes作为容器平台的标准已经得到了广泛应用。Kubernetes从2014年6月由Google宣布开源，到2015年7月发布1.0这个正式版本并进入CNCF基金会，再到2018年3月从CNCF基金会正式毕业，迅速成为容器编排领域的标准，是开源历史上发展最快的项目之一，如图1-12所示。

1.5.1 Istio，Kubernetes的好帮手

从场景来看，Kubernetes已经提供了非常强大的应用负载的部署、升级、扩容等运行管理能力。Kubernetes 中的 Service 机制也已经可以做服务注册、服务发现和负载均衡，支持通过服务名访问到服务实例。

从微服务的工具集观点来看，Kubernetes本身是支持微服务的架构，在Pod中部署微服务很合适，也已经解决了微服务的互访互通问题，但对服务间访问的管理如服务的熔断、限流、动态路由、调用链追踪等都不在Kubernetes的能力范围内。那么，如何提供一套从底层的负载部署运行到上层的服务访问治理端到端的解决方案？目前，最完美的答案就是在Kubernetes上叠加Istio这个好帮手，如图1-13所示。

Kubernetes的Service基于每个节点的Kube-proxy从Kube-apiserver上获取Service和Endpoint 的信息，并将对 Service 的请求经过负载均衡转发到对应的 Endpoint 上。但Kubernetes只提供了4层负载均衡能力，无法基于应用层的信息进行负载均衡，更不会提供应用层的流量管理，在服务运行管理上也只提供了基本的探针机制，并不提供服务访问指标和调用链追踪这种应用的服务运行诊断能力。

Istio复用了Kubernetes Service的定义，在实现上进行了更细粒度的控制。Istio的服务发现就是从 Kube-apiserver中获取 Service和 Endpoint，然后将其转换成 Istio服务模型的 Service 和 ServiceInstance，但是其数据面组件不再是 Kube-proxy，而是在每个 Pod 里部署的 Sidecar，也可以将其看作每个服务实例的 Proxy。这样，Proxy 的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理，如图 1-14 所示。通过拦截Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种应用层协议，Istio可以提供真正的应用层治理、监控和安全等能力。

总之，Istio和Kubernetes从设计理念、使用体验、系统架构甚至代码风格等小细节来看，关系都非常紧密，甚至有人认为 Istio 就是 Kubernetes团队开发的 Kubernetes可插拔的增强特性。

1.5.2 Kubernetes，Istio的好基座

Istio最大化地利用了Kubernetes这个基础设施，与之叠加在一起形成了一个更强大的用于进行服务运行和治理的基础设施，并提供了更透明的用户体验。

1.数据面

数据面Sidecar运行在Kubernetes的Pod里，作为一个Proxy和业务容器部署在一起。在服务网格的定义中要求应用程序在运行的时候感知不到Sidecar的存在。而基于Kubernetes的一个 Pod 多个容器的优秀设计使得部署运维对用户透明，用户甚至感知不到部署 Sidecar的过程。用户还是用原有的方式创建负载，通过 Istio 的自动注入服务，可以自动给指定的负载注入Proxy。如果在另一种环境下部署和使用Proxy，则不会有这样的便利。

2.统一服务发现

Istio的服务发现机制非常完美地基于Kubernetes的域名访问机制构建而成，省去了再搭一个类似 Eureka 的注册中心的麻烦，更避免了在 Kubernetes 上运行时服务发现数据不一致的问题。

尽管 Istio 强调自己的可扩展性的重要性在于适配各种不同的平台，也可以对接其他服务发现机制，但在实际场景下，通过深入分析 Istio 几个版本的代码和设计，便可以发现其重要的能力都是基于Kubernetes进行构建的。

3.基于Kubernetes CRD描述规则

Istio的所有路由规则和控制策略都是通过 Kubernetes CRD实现的，因此各种规则策略对应的数据也被存储在 Kube-apiserver 中，不需要另外一个单独的 APIServer 和后端的配置管理。所以，可以说Istio的APIServer就是Kubernetes的APIServer，数据也自然地被存在了对应Kubernetes的etcd中。

Istio非常巧妙地应用了Kubernetes这个好基座，基于Kubernetes的已有能力来构建自身功能。Kubernetes里已经有的，绝不再自己搞一套，避免了数据不一致和用户使用体验的问题。

如图1-15所示为Istio和Kubernetes架构的关系，可以看出，Istio不仅数据面Envoy跑在Kubernetes的Pod里，其控制面也运行在Kubernetes集群中，其控制面组件本身存在的形式也是Kubernetes Deployment和Service，基于Kubernetes扩展和构建。

如表1-2所示为Istio+Kubernetes的方案与将SDK开发的微服务部署在Kubernetes上的方案的比较。