Istio与Kubernetes叠加后的快感从何而来？

Posted 2021-04-13 博文视点Broadview

本文选自《云原生服务网格Istio》一书，带你从原理、实践、架构与源码多角度全解Istio，直击Istio的每一个细节。

---

Istio，Kubernetes的好帮手

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

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

目前，最完美的答案就是在Kubernetes上叠加Istio这个好帮手。

在Kubernetes上叠加Istio

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的粒度就更细了，和服务实例的联系也更紧密了，可以做更多更细粒度的服务治理通过拦截Pod的Inbound流量和Outbound流量，并在Sidecar上解析各种应用层协议，Istio可以提供真正的应用层治理、监控和安全等能力。

更细粒度的Proxy提供更多更细粒度的能力

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

 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里已经有的，绝不再自己搞一套，避免了数据不一致和用户使用体验的问题。

Istio与Kubernetes架构的关系

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

下表为Istio+Kubernetes的方案与将SDK开发的微服务部署在Kubernetes上的方案的比较。

微服务、容器、Kubernetes、Istio

一图看懂四者关系。

Istio、微服务、容器与Kubernetes的关系  

Kubernetes在容器编排领域已经成为无可争辩的事实标准；微服务化的服务与容器在轻量、敏捷、快速部署运维等特征上匹配，这类服务在容器中的运行也正日益流行；随着Istio的成熟和服务网格技术的流行，使用Istio进行服务治理的实践也越来越多，正成为服务治理的趋势；而Istio与Kubernetes的天然融合且基于Kubernetes构建，也补齐了Kubernetes的治理能力，提供了端到端的服务运行治理治理平台。这都使得Istio、微服务、容器及Kubernetes形成一个完美的闭环。

---

 本文选自《云原生服务网格Istio：原理、实践、架构与源码解析》一书。

（预售中，点击图片了解本书详情）

本书篇章组织概述

---

原理篇：介绍Istio概念、核心功能、原理和使用方式，为后续的实践提供理论基础。其中，第1～2章分别介绍Istio的背景知识、基本工作机制、主要组件及概念模型等；第2～7章分别介绍Istio的五大块功能集，即非侵入的流量治理、可扩展的策略和遥测、可插拔的服务安全、透明的Sidecar机制及多集群服务治理。

实践篇：通过实际操作介绍如何通过一个典型应用进行Istio实践。其中，第8章讲解环境准备，完成Kubernetes与Istio平台的基础设施准备工作；第9～13章分别介绍如何实际操作一个天气预报应用在Istio平台上实现流量监控、灰度发布、流量治理、服务安全、多集群管理等功能。

架构篇：从架构角度剖析Istio多个主要组件的设计原理、关键内部流程及数据结构等内容，为高级用户提供架构与设计层面的参考。其中，第14～19章分别介绍了Pilot、Mixer、Citadel、Envoy、Pilot-agent与Galley等6个Istio核心组件。

源码篇：本篇包括第20～24章，分别介绍Istio整体的代码组织情况，以及Pilot、Mixer、Citadel、Envoy与Galley的代码结构与关键代码片段。

 

博文视点

您阅读的专业智库

了解更多本书详情请点击阅读原文

长按二维码轻松关注

点击阅读原文，了解本书详情！