1. K8s vs Istio

1.1 k8s简介

2014 年，Google 开源了 Kubernetes，随后几年得到迅猛发展，在 2017 年奠定了容器编排调度标准的地位。
Kubernetes 作为一种容器编排调度工具，解决了分布式应用程序的部署和调度问题。
Kubernetes 本质上是通过声明式配置来实现应用生命周期管理
Kubernetes 通过 Service 对象将一个服务的多个实例组合在了一起，统一对外服务。

1.2 k8s无法很好解决Service Mesh的流量需求

服务具有多个版本，需要迭代和上线，在新版发布的时候需要切分流量，实现金丝雀发布；
同时我们应该假定服务是不可靠的，可能因为各种原因导致请求失败，需要面向失败来编程；
如何监控应用程序的指标，了解每个请求的耗时和状态？
如何保障服务的安全性？
Kubernetes 在每个 node 中安装了 kube-proxy 组件来转发流量，该组件与 Kubernetes API Server 进行通信，获取集群中的服务信息，然后设置 iptables 规则，将服务请求直接发送到对应的 Endpoint。
但是kube-proxy 组件只能实现最基本的服务发现和转发能力，无法实现这些细粒度的流量需求。

1.3 Istio通过透明代理（sidecar)将流量管理从K8S中解耦

Istio 的发起者们就想到了在每个 pod 中注入一个代理，将代理的配置通过一个控制平面集中分发，然后将从 pod 中应用容器发起的每个请求都劫持到 sidecar 代理中，然后转发，这样不就可以完美的解决以上问题了吗？
Kubernetes 优秀的架构和可扩展性，可以完美的解决大量 sidecar 的注入和管理问题，在 Kubernetes 的 Pod 中，在原有的应用容器旁边运行一个 Sidecar 容器，可以理解为两个容器共享存储、网络等资源。
Istio 不再使用 kube-proxy 组件做流量转发，而是依托在每个 pod 中注入的 sidecar proxy，所有的 proxy 组成了 Istio 的数据平面。从而将流量管理与 Kubernetes 解耦。
在 Istio 之前，人们可以使用 SpringCloud、Netflix OSS 等，通过在应用程序中集成 SDK，编程的方式来管理应用程序中的流量。但是这通常会有编程语言限制，而且在 SDK 升级的时候，需要修改代码并重新上线应用，会增大人力负担。Istio 使得流量管理变得对应用程序透明，使这部分功能从应用程序中转移到了平台层，成为了云原生基础设施。

2. Istio vs Envoy

Envoy 是专为大型现代 SOA（面向服务架构）架构设计的 L7 代理和通信总线。该项目源于以下理念：网络对应用程序来说应该是透明的。当网络和应用程序出现问题时，应该很容易确定问题的根源。

2.1 envoy的设计目标

为了做到这一点，Envoy 提供了以下高级功能:

进程外架构：Envoy 是一个独立进程，设计为伴随每个应用程序服务运行。从而Envoy可以透明地在整个基础架构上快速部署和升级。
L3/L4 filter 架构：Envoy 的核心是一个 L3/L4 网络代理。可插入 filter 链机制允许开发人员编写 filter 来执行不同的 TCP 代理任务并将其插入到主体服务中。现在已有很多用来支持各种任务的 filter，如原始 TCP 代理、HTTP 代理、TLS 客户端证书认证等。
HTTP L7 filter 架构： HTTP 是现代应用程序体系结构的关键组件，Envoy 支持额外的 HTTP L7 filter 层。可以将 HTTP filter 插入执行不同任务的 HTTP 连接管理子系统，例如缓存，速率限制，路由/转发，嗅探 Amazon 的 DynamoDB 等等。
顶级 HTTP/2 支持：当以 HTTP 模式运行时，Envoy 同时支持 HTTP/1.1 和 HTTP/2。Envoy 可以作为 HTTP/1.1 和 HTTP/2 之间的双向透明代理。这意味着它可以桥接 HTTP/1.1 和 HTTP/2 客户端以及目标服务器的任意组合。
HTTP L7 路由：当以 HTTP 模式运行时，Envoy 支持一种路由子系统，能够根据路径、权限、内容类型、运行时及参数值等对请求进行路由和重定向。这项功能在将 Envoy 用作前端/边缘代理时非常有用，同时，在构建服务网格时也会使用此功能。
gRPC支持：gRPC 是一个来自 Google 的 RPC 框架，它使用 HTTP/2 作为底层多路复用传输协议。Envoy 支持被 gRPC 请求和响应的作为路由和负载均衡底层的所有 HTTP/2 功能。这两个系统是非常互补的。
MongoDB L7 支持：MongoDB 是一种用于现代 Web 应用程序的流行数据库。Envoy 支持对 MongoDB 连接进行 L7 嗅探、统计和日志记录。
DynamoDB L7 支持：DynamoDB 是亚马逊的托管键/值 NOSQL 数据存储。Envoy 支持对 DynamoDB 连接进行 L7 嗅探和统计。
服务发现和动态配置/健康检查/高级负载均衡/最佳的可观察性等等…

2.2 Istio使用Envoy作为默认sidecar

Envoy 是 Istio Service Mesh 中默认的 Sidecar，Istio 在 Enovy 的基础上按照 Envoy 的 xDS 协议扩展了其控制平面。
那么Istio 是如何将 Envoy 作为 Sidecar 的方式注入到应用程序 Pod 中，及 Sidecar 是如何做劫持流量的？
在 Sidecar 部署方式中，你会为每个应用的容器部署一个伴生容器。Sidecar 接管进出应用容器的所有流量。在 Kubernetes 的 Pod 中，在原有的应用容器旁边运行一个 Sidecar 容器，可以理解为两个容器共享存储、网络等资源。

istio-proxy作为 Sidecar 的方式和应用运行在同一个 Pod 中，拦截所有进出应用容器的流量。

该容器存在的意义就是让 Envoy 代理可以拦截所有的进出 Pod 的流量，即将入站流量重定向到 Sidecar，再拦截应用容器的出站流量经过 Sidecar 处理后再出站。

Init 容器启动时命令行参数中指定了 REDIRECT 模式，因此只创建了 NAT 表规则，接下来我们查看下 NAT 表中创建的规则。

# 查看 NAT 表中规则配置的详细信息
$ iptables -t nat -L -v
# PREROUTING 链：用于目标地址转换（DNAT），将所有入站 TCP 流量跳转到 ISTIO_INBOUND 链上
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)pkts bytes target     prot opt in     out     source               destination2   120 ISTIO_INBOUND  tcp  --  any    any     anywhere             anywhere# INPUT 链：处理输入数据包，非 TCP 流量将继续 OUTPUT 链
Chain INPUT (policy ACCEPT 2 packets, 120 bytes)pkts bytes target     prot opt in     out     source               destination# OUTPUT 链：将所有出站数据包跳转到 ISTIO_OUTPUT 链上
Chain OUTPUT (policy ACCEPT 41146 packets, 3845K bytes)pkts bytes target     prot opt in     out     source               destination93  5580 ISTIO_OUTPUT  tcp  --  any    any     anywhere             anywhere# POSTROUTING 链：所有数据包流出网卡时都要先进入POSTROUTING 链，内核根据数据包目的地判断是否需要转发出去，我们看到此处未做任何处理
Chain POSTROUTING (policy ACCEPT 41199 packets, 3848K bytes)pkts bytes target     prot opt in     out     source               destination# ISTIO_INBOUND 链：将所有目的地为 9080 端口的入站流量重定向到 ISTIO_IN_REDIRECT 链上
Chain ISTIO_INBOUND (1 references)pkts bytes target     prot opt in     out     source               destination2   120 ISTIO_IN_REDIRECT  tcp  --  any    any     anywhere             anywhere             tcp dpt:9080# ISTIO_IN_REDIRECT 链：将所有的入站流量跳转到本地的 15001 端口，至此成功的拦截了流量到 Envoy
Chain ISTIO_IN_REDIRECT (1 references)pkts bytes target     prot opt in     out     source               destination2   120 REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 15001# ISTIO_OUTPUT 链：选择需要重定向到 Envoy（即本地） 的出站流量，所有非 localhost 的流量全部转发到 ISTIO_REDIRECT。为了避免流量在该 Pod 中无限循环，所有到 istio-proxy 用户空间的流量都返回到它的调用点中的下一条规则，本例中即 OUTPUT 链，因为跳出 ISTIO_OUTPUT 规则之后就进入下一条链 POSTROUTING。如果目的地非 localhost 就跳转到 ISTIO_REDIRECT；如果流量是来自 istio-proxy 用户空间的，那么就跳出该链，返回它的调用链继续执行下一条规则（OUPT 的下一条规则，无需对流量进行处理）；所有的非 istio-proxy 用户空间的目的地是 localhost 的流量就跳转到 ISTIO_REDIRECT
Chain ISTIO_OUTPUT (1 references)pkts bytes target     prot opt in     out     source               destination0     0 ISTIO_REDIRECT  all  --  any    lo      anywhere            !localhost40  2400 RETURN     all  --  any    any     anywhere             anywhere             owner UID match istio-proxy0     0 RETURN     all  --  any    any     anywhere             anywhere             owner GID match istio-proxy  0     0 RETURN     all  --  any    any     anywhere             localhost53  3180 ISTIO_REDIRECT  all  --  any    any     anywhere             anywhere# ISTIO_REDIRECT 链：将所有流量重定向到 Envoy（即本地） 的 15001 端口
Chain ISTIO_REDIRECT (2 references)pkts bytes target     prot opt in     out     source               destination53  3180 REDIRECT   tcp  --  any    any     anywhere             anywhere             redir ports 15001

ISTIO_OUTPUT 链规则匹配的详细过程如下：

如果目的地非 localhost 就跳转到 ISTIO_REDIRECT 链
所有来自 istio-proxy 用户空间的非 localhost 流量跳转到它的调用点 OUTPUT 继续执行 OUTPUT 链的下一条规则，因为 OUTPUT 链中没有下一条规则了，所以会继续执行 POSTROUTING 链然后跳出 iptables，直接访问目的地
如果流量不是来自 istio-proxy 用户空间，又是对 localhost 的访问，那么就跳出 iptables，直接访问目的地
其它所有情况都跳转到 ISTIO_REDIRECT 链

参考

理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持
为什么在使用了 Kubernetes 后你可能还需要 Istio？
xds协议
Learn Kubernetes using Interactive Browser-Based Scenarios
Get Started with Istio and Kubernetes
Getting Started with Envoy
MOSN with Istio
Envoy 的架构与基本术语
Envoy 架构与配置结构

云原生和ServiceMesh主要组件--理解K8s/Istio/Envoy相关推荐

【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（上）
目录一.k8s 安全管理:认证.授权.准入控制概述 1.1 认证认证基本介绍授权基本介绍准入控制基本介绍为什么需要准入控制器呢? k8s 客户端访问 apiserver 的几种认证方式 ku ...
【云原生之kubernetes实战】在k8s环境下部署Snipe-IT固定资产管理平台
[云原生之kubernetes实战]在k8s环境下部署Snipe-IT固定资产管理平台一.Snipe-IT介绍二.检查本地k8s环境 1.检查工作节点状态 2.检查系统pod状态 3.检查kube ...
【云原生之kubernetes实战】在k8s环境下部署OneNav个人书签工具
[云原生之kubernetes实战]在k8s环境下部署OneNav个人书签工具一.OneNav介绍 1.OneNav简介 2.OneNav特点二.检查本地k8s环境 1.检查工作节点状态 2.检查 ...
【云原生之kubernetes实战】在k8s环境下部署Homepage个人导航页
[云原生之kubernetes实战]在k8s环境下部署Homepage个人导航页一.Homepage简介二.检查本地k8s环境 1.检查工作节点状态 2.检查系统pod状态三.安装docker- ...
【云原生 | Kubernetes 实战】18、K8s 安全实战篇之 RBAC 认证授权（下）
目录一.常见角色(role)授权的案例 1.1 允许读取核心 API 组的 Pod 资源 1.2 允许读写 apps API 组中的 deployment 资源 1.3 允许读取 Pod 以及读写 ...
【云原生之kubernetes实战】在k8s集群下部署Weave Scope监控平台
[云原生之kubernetes实战]在k8s集群下部署Weave Scope监控平台一.Weave Scope介绍 1.Weave Scope简介 2.Weave Scope的特点 3.Weave ...
灵活、高效的云原生集群管理经验：用 K8s 管理 K8s
作者 | 淮右.临石 **导读:**单 K8s 集群为用户提供了 Namespace 级别的隔离能力,理论上支持不超过 5K Node.15W Pod.多 K8s 集群则解决了单集群的资源隔离.故障隔 ...
云原生是趋势吗？学习 K8s 和 Docker 的意义在哪里？
作者 | 幻灰龙出品 | CSDN(ID:CSDNnews) 注: 云原生入门技能树本文是在知乎上对同名问题做的回答. 直接答案: 是! 细细说下为什么. 从前,写代码只要在单机上写即可,但是编程 ...
云原生之史上最全K8S环境搭建(强烈建议收藏）
目录首先安装K8S的基础要安装Docker环境编辑 Docker安装 1.移除以前docker相关包 2.配置yum源 3.安装docker 4.启动 5.配置加速环境配置和Kubernete ...

云原生和ServiceMesh主要组件--理解K8s/Istio/Envoy