k8s 和 service mesh

微服务和云原生可能用到的相关组件。

一、什么是 Kubernetes（k8s）

1、Kubernetes 作为一种容器编排调度工具，解决了分布式应用程序的部署和调度问题

2、Kubernetes 本质上是通过声明式配置来实现应用生命周期管理

3、Kubernetes 通过 Service 对象将一个服务的多个实例组合在了一起，统一对外服务

4、作为微服务的可交付成果，容器解决了环境一致性问题，并在限制应用程序资源方面提供了更多的粒度。它们被广泛用作微服务的载体

5、为了应对服务流量高峰和平谷时，服务能够弹性扩容，计算机资源最合理化而生。

6、Kubernetes 不能很好得处理流量方面的需求：

        ①、服务具有多个版本，需要迭代和上线，在新版发布的时候需要切分流量

        ②、如何监控应用程序的指标，了解每个请求的耗时和状态

        ③、如何保障服务的安全性，确保服务是可用的

        ④、Kubernetes 在每个 node 中安装了 kube-proxy 组件来转发流量，但是kube-proxy 组件只能实现最基本的服务发现和转发能力，无法实现这些细粒度的流量需求

总结：Kubernetes 负责粗粒度的，目标是服务（一个服务可以有多个实例，每个实例有N多流量）

k8s 中的服务模型：

从上图我们可以看出：

        ①、同一服务的不同实例可能被调度到不同的节点

        ②、Kubernetes 通过 Service 对象组合多个服务实例，统一外部服务

        ③、Kubernetes 在每个节点都安装了一个 kube-proxy 组件来转发流量，具有简单的负载均衡能力

        ④、来自 Kubernetes 集群外部的流量可以通过 Ingress 进入集群（Kubernetes 还有其他几种暴露服务的方式；例如 NodePort、LoadBalancer 等）

        它对服务实例控制的很好，但是并没有完全解决如何保证应用的健壮性和冗余，如何实现更细粒度的流量划分（不是基于服务的实例数）的问题，如何保证服务的安全性，或者如何管理多个集群等

Istio 应运而生 

二、什么是 service mesh，什么是 Istio

        Istio 是目前最流行的  service mesh 的一种实现（可以理解为：service mesh 是一种架构风格，Istio 是一种架构模式），Istio 才是具体的产物。

        Istio 带有丰富的功能集。它提供了一些功能，例如使用 TLS 加密的服务到服务通信、身份验证和授权、自动负载平衡、细粒度路由规则、重试、故障转移和故障注入——以及具有指标、日志和跟踪入口和出口流量的可观察性功能。它的控制平面istiod提供服务发现、配置和证书管理。Istio 利用Envoy作为其代理 Sidecar，而 istiod 负责将高级规则转换为特定于 Envoy 的配置

Istio 服务模型如下：

从图上可以看出：

        ①、Istiod 充当控制平面，将配置分发到所有 Sidecar 代理和网关

        ②、Istio 支持从应用层到集群中其他支持网格的服务的智能应用感知负载平衡，并绕过基本的 kube-proxy 负载平衡

        ③、应用程序管理员可以通过声明性 API 来操纵 Istio 网格中的流量行为，就像他们在 Kubernetes 中管理工作负载一样。它可以在几秒钟内生效，他们可以做到这一点而无需重新部署

         ④、Ingress 被 Gateway 资源取代，这是一种特殊的代理，也是重用的 Sidecar 代理

         ⑤、可以在虚拟机中安装 sidecar 代理，以将虚拟机带入 Istio 网格

Istio 使流量管理对应用程序透明，将此功能移出应用程序并作为云原生基础设施进入平台层（将流控和应用层解耦），Istio 通过增强云原生应用程序的流量管理、可观察性和安全性来补充 Kubernetes的不足。

        总结：

        1、Service Mesh 是 TCP/IP 的云原生等价物，可解决应用程序网络通信、安全性和可见性问题

        2、Istio 是目前最流行的服务网格实现，它依赖于 Kubernetes，但也可扩展到虚拟机负载

        3、Istio 的核心由控制平面和数据平面组成，Envoy 作为默认的数据平面代理

        4、Istio 充当云原生基础设施的网络层，对应用程序是透明的

Istio 相关官网文档：Istio / The Istio service mesh

        凡事都有两面性，Istio也存在反对的声音：

        1、复杂性：服务网格将新组件添加到您的整体解决方案架构中。无论您选择哪种服务网格产品，您都必须始终管理一组额外的服务（控制平面服务）并配置每个 Sidecar 代理。
        2、资源消耗：sidecar 代理使用内存和 CPU 等资源，并且该使用量将随着应用程序使用的服务数量而扩展。
        3、成本：除产品价格外，控制平面和边车所需的额外计算资源将具有财务成分。
        4、额外的网络跃点：虽然 sidecar 代理提供了很多功能，但当服务与另一个服务通信时，它们会为服务添加一个额外的网络跃点。
        5、调试：调试分布式系统可能很复杂，通过网格添加额外的服务会使过程更加复杂。

        service mesh 通常实现为与应用程序代码一起部署的一组可扩展的网络代理（有时称为sidecar的模式）。这些代理处理微服务之间的通信，并充当可以引入服务网格功能的点；是一种通过在平台层而不是应用程序层插入这些特性来向应用程序添加可观察性、安全性和可靠性特性的工具的

        提供了关键的可观察性、可靠性和安全特性，并具有一个很大的优势：应用程序不需要实现这些特性，甚至不需要知道 service mesh 就在那里！
        这对平台团队来说非常有用，因为它使他们的职责与他们的所有权保持一致。它对开发人员来说也很棒，因为它可以消除与业务逻辑无关的功能。
        service mesh 将这种显式处理 服务到服务通信 的想法与两个额外的云原生组件相结合。首先是容器，它提供资源隔离和依赖管理，并允许服务网格逻辑作为代理实现，而不是作为应用程序的一部分。其次，容器编排器（例如Kubernetes），它提供了部署数千个代理的方法，而无需大量的运营成本，够将这些平台级功能与应用程序本身完全解耦。

        k8s 做不了的事情，service mesh 来做，Istio 通过透明代理（sidecar)刚好能够将流量管理从K8S中解耦（Envoy 是 Istio Service Mesh 中默认的 Sidecar），完美结合，天造地设的一对儿

总结：service mesh 负责细粒度，目标是请求流量

三、两者有什么区别

1、Kubernetes 本质上是关于通过声明式配置来管理应用程序生命周期，而 service mesh 本质上是关于提供应用程序间流量、安全管理和可观察性。

2、负责的粒度不一样，k8s 负责粗粒度的服务级别的，service mesh 负责服务内部的细粒度的流量级别的，k8s 主外，service mesh 主内。

此处应该有张手画图的

四、番外篇

1、如果你已经使用 Kubernetes 搭建了一个稳定的应用平台，那么如何为服务之间的调用设置负载均衡和流量控制呢？这就是 service mesh 出现的地放。k8s 负责服务的控制，service mesh 负责服务内部流量的控制，k8s 主外，service mesh 主内，两者相互结合，使服务体系更加完美得向外提供服务。