Kubernetes服务网格
kubernetes服务网格
是一种架构，为了解决服务和服务之间的通信。
服务网格接口（打算理解）
SMI
用于定义服务网格标准化接口的规范，旨在提供一个通用的接口，让不同的服务网格实现可以互操作。SMI的主要目的是简化服务网格的使用和集成，使用户可以使用统一的API管理不同的服务网格实现，如Istio、Linkerd、Consul Connect等。
CRD
是Kubernetes中的一种机制，用于扩展Kubernetes API，使用户可以定义自己的资源类型。通过CRD，用户可以创建自定义资源（CR），这些资源可以与Kubernetes内置资源（如Pod、Service）一样进行管理和操作。
数据平面代理
负责处理和管理服务间流量的代理组件。
核心职责:
流量转发：代理组件负责接收、转发和负载均衡服务之间的流量。这包括 HTTP、gRPC、TCP 等多种协议。
服务发现：代理可以自动发现 Kubernetes 中的服务，根据服务的配置进行相应的流量路由。
流量管理：包括流量控制、重试策略、断路器、故障注入等功能，以保证服务间通信的可靠性和稳定性。
安全：提供 mTLS（双向 TLS）加密来确保服务间通信的安全性，支持认证和授权策略。
监控和可观测性：代理会收集并上报各种流量指标和日志，帮助管理员监控和诊断服务间的通信问题。
数据平面架构
代理附件
一般部署在工作负载的pod上，后续会拦截进出服务的所有通信，但是在一些升级上，代理附件不能保证在不重建Pod的条件下进行升级
代理节点
由代理节点来处理运行服务的所有流量。但是会存在很大的网络瓶颈。
Envoy
一个高性能的开源边缘和服务代理，主要用于微服务架构中的通信管理
场景
API网关：
Envoy可以作为API网关，处理外部请求并将其路由到内部服务，同时提供认证、限流、缓存等功能。
边车代理：
- 是一种设计模式，在这种模式下，一个代理程序（如Envoy）被部署在每个服务实例的旁边，这样每个服务实例都有一个独立的代理来处理进出流量。
- 在服务网格架构中，Envoy通常以边车代理的形式部署在每个服务实例旁，拦截和处理所有入站和出站流量。
- 边车注入是将边车代理自动注入到服务实例的Pod中，以便在微服务架构中实现服务网格功能的过程。分为手动与自动，自动注入似乎能够用istio来进行自动注入。
- Sidecar 模式：Envoy 通常以 sidecar 容器的形式部署在每个微服务 Pod 内，与应用容器共享网络命名空间。所有进出微服务的流量都会通过 Envoy 代理。
中介层代理：
Envoy可以部署在不同的服务层之间，作为中介层代理，处理跨服务的流量和策略管理。
模块化架构
Listener：
作用：Listener是Envoy用于监听网络端口的组件，负责接受客户端的连接请求。每个Listener都绑定到一个特定的IP地址和端口，并根据配置将流量传递给相应的处理模块。
配置：Listener的配置包括监听的地址和端口、使用的协议（如HTTP、TCP）、以及关联的过滤器链。
Filter：
作用：Filter是Envoy用于处理请求和响应的中间处理模块。Filter可以用于修改请求、添加日志、执行身份验证、路由选择等。Envoy的Filter分为多种类型，包括网络过滤器、HTTP过滤器和TCP过滤器。
类型：
网络过滤器：处理TCP连接层面的流量，如TLS终止、连接限速等。
HTTP过滤器：处理HTTP请求和响应，如修改头部信息、执行认证和授权、负载均衡等。
TCP过滤器：处理TCP层流量，如TCP代理、流量镜像等。
Cluster：
作用：Cluster是Envoy用于表示一组上游服务实例的组件。Cluster负责服务发现、负载均衡、健康检查等。每个Cluster包含多个主机（即上游服务实例），并定义了如何将流量分配到这些主机上。
配置：Cluster的配置包括服务发现类型（静态、DNS、EDS等）、负载均衡策略（如轮询、随机、加权轮询等）、健康检查配置等。
Route：
作用：Route组件定义了Envoy如何将请求路由到不同的Cluster。Route规则基于请求的属性（如路径、头部信息、方法等）来决定具体的路由目标。
配置：Route的配置包括匹配规则、路由目标Cluster、重试策略、超时设置等。
Admin：
作用：Admin组件提供了管理和监控Envoy的接口。通过Admin接口，用户可以查看Envoy的运行状态、统计信息、配置详情，并进行管理操作。
配置：Admin接口通常通过HTTP API暴露，可以在Envoy配置中指定Admin的监听地址和端口。
配置管理
配置管理
Envoy的配置管理可以通过静态文件配置，也可以通过动态配置API（xDS）实现。xDS（Envoy Dynamic Configuration API）包括以下几个部分：
ADS（Aggregated Discovery Service）：聚合配置服务，统一管理其他xDS服务。
CDS（Cluster Discovery Service）：动态管理Cluster的配置。
EDS（Endpoint Discovery Service）：动态管理Cluster中上游服务实例的配置。
LDS（Listener Discovery Service）：动态管理Listener的配置。
RDS（Route Discovery Service）：动态管理路由配置。
SDS（Secret Discovery Service）：动态管理密钥和证书。
控制平面
负责管理和协调数据平面代理
配置管理：提供统一的配置接口，管理服务网格中所有代理的配置，包括路由规则、负载均衡策略、故障恢复策略等。
服务发现：集成服务发现机制，实时感知集群中服务的变化，并通知数据平面代理更新其配置。
安全管理：实现服务间的认证和授权，管理 TLS 证书的分发和轮换，确保服务间通信的安全性。
流量管理：提供流量路由、灰度发布、A/B 测试等高级流量控制功能，帮助开发和运维人员灵活管理服务间的流量。
可观测性：收集和聚合数据平面代理的监控指标、日志和分布式追踪数据，提供全局的可观测性视图，帮助排查和诊断问题。
istio
istiod为基于envoy的服务网络提供控制平面，他包括三个核心组件，Galley，Pilot，Citidel
Pilot：一个Envoy的配置服务器，实现 xDS API，并将配置流向与应用程序一起运行的Envoy代理。
Citadel：负责网格内的证书管理，建立服务器身份和相互TLS。
Galley：与外部系统互动，Kubernetes等。
webhook
用于在 Kubernetes 集群中实现动态配置和策略控制的关键组件。 Istio 中的主要用途包括服务网格控制、资源变更管理和策略执行等。
- 自动注入 Sidecar 容器:Istio 使用一个变异（Mutating）Webhook 自动将 Envoy 代理（Sidecar）注入到新创建的 Kubernetes Pod 中。这个过程确保每个服务都能被 Istio 管理和监控。当你为集群启用了自动注入，Webhook 会拦截 Pod 创建请求，在 Pod 完成调度之前往其定义中添加 Envoy 容器以及必要的配置信息。
- 配置验证（Validating Webhook）:验证（Validating）Webhook 用于在新的 Istio 配置资源（如 VirtualService、DestinationRule 等）创建或更新时执行验证过程，确保这些配置符合要求，避免因错误配置导致服务故障。这个 Webhook 会在配置提交到 etcd 之前进行执行，起到一个“守门人”的作用，阻止不符合标准的配置生效。
- 动态配置和策略控制:Webhook 还可以用于执行动态配置和策略决策。例如，通过 Webhook，可以向运行时注入配置参数或更新策略以应对瞬时需求或安全要求。
通过iptable达到工作负载通过Envoy发送流量。
Istio的iptables规则是通过init-containner来进行安装，拦截pod网络流量路由到Envoy。
initContainers: |
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)
.jpg)