#istio #mesh
# Traffic Management
^ebc917
- https://istio.io/latest/docs/concepts/traffic-management/
- traffic routing rules：轻松控制服务间 traffic 和 API calls 的流向。
- 简化了 service-level 的属性配置，如
- 熔断
- 超时
- 重试
可以轻松设置重要任务如 A/B 测试、canary rollouts；
也提供了可靠性功能，对抗服务和网络故障。
- Istio 的流量管理模型依赖 Envoy proxies。Envoy 跟服务一起部署，服务发送和接收的流量都经过 Envoy 代理，不需要改动服务就可以控制流量。
- 
## Introducing Istio traffic management
- 为了引导流量，Istio 需要知道你所有的 endpoints，以及它们属于哪些 services。因此 Istio 需要链接到一个 **service discovery system** 作为 service registry。
- 例如如果在 k8s 中安装 istio，它会自动检测集群中的 services 和 endpoints.
- 使用 service registry，Envoy 可以将流量引导到相关的 services.
- Istio 基本的 service discovery 和 负载均衡 可以构建一个 service mesh，但它的功能不仅仅如此，可以有更多细粒度的控制。
- A/B 测试，为某个服务子集定制 LB
- 可以通过 Istio 的 traffic management API 添加自己的流量配置。API 使用 k8s **CRDs** 来定义，通过 YAML 文件配置。
- 跟流量管理相关的 resources：
- Virtual services
- Destination rules
- Gateways
- Service entries
- Sidercars
## Virtual services
- virtual services 和 destination rules 是 Istio 流量路由功能的关键模块。
- 一个 virtual service 可以让你配置请求如何路由到服务，每个 virtual service 包含了一组 **routing rules**, 依次估值，请求匹配到规则后转发到相应的目的地。
### Why use
- 基于 virtual service，你可以使用 routing rules 告诉 Envoy 如何将 virtual service 的流量发送到合适的目的地。路由目的可以是相同服务的不同版本 或者 不同的服务。
- 典型案例：将不同版本的服务定义为一个 subset， 将 20% 的流量转发到新版本。
- virtual service 可以做到：
- 通过一个 virtual service 处理多个应用服务。一个 virtual service 映射为多个真正的服务，将一个 monolithic application ==分解==为多个微服务。
- 例如将`monolith.com`的某些 URI 路由到微服务 A，依次类推。
- 跟 gateways 一起配置流量规则，控制出入流量（ingress and egress traffic）。
### Example
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
end-user:
exact: jason
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v3
```
- **hosts**：用户发送请求时的地址，可以是 IP 地址、DNS name、k8s service short name 等。
- **http**：http section 包含了 routing rules，描述了匹配条件和动作，适用于 HTTP/1.1，HTTP2 和 gRPC。（TCP 和 TLS 使用 tcp 和 tls slections）。
- **destination** 必须是**真实**的目的，存在于 Istio 的 service registry，否则 Envoy 无法转发。
- 第二条 route 规则没有 match 条件，表示默认目的地。
## Destination rules
- virtual services 负责管理如何路由流量到一个给定的目的地。
- destination rules 配置针对该目的地的流量发生了什么。
- 特别地，可以destination rules 来定义 service subsets，比如按版本划分。
- destination rules 也可以允许你定义 Envoy 的流量策略，当转发到整个 destination service 或者 subset 时。这些策略包含负载均衡模型、TLS 安全模式、熔断设置等。
### Example
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: my-destination-rule
spec:
host: my-svc
trafficPolicy:
loadBalancer:
simple: RANDOM
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
- name: v3
labels:
version: v3
```
- 定义了不同服务子集 v1，v2, v3 的策略。基于 k8s labels 来划分子集。
## Gateways
- 可以使用 gateway 来管理到 mesh 的 inbound 和 outbound 流量，运行你指定进入和离开 mesh 的流量。
- gateway 配置只适用于运行在 mesh edge 的 Envoy proxies，而非 sidercar proxies。
- Istio 的 gateway resources 只允许配置 L4-6 的负载均衡属性（例如端口暴露、TLS设置等），然后给 gateway 绑定一个常规的 virtual service.
- gateway 主要用于管理入流量，但也可以配置 **egress** gateways。例如你可以配置一个专门的节点用于出流量，可以管理哪些服务允许访问外部网络。
## Service entries
- 可以使用 service entry 来向 Istio 内部管理的 service registry 添加一个 entry。添加后，Envoy proxy 就可以像这个 service 发送流量，就像你自己 mesh 中的 service 一样。
- 配置 service entries 允许你管理 mesh 之外的流量，包含以下任务：
- 重定向和转发到外部目的地（external destinations) 的流量
- 为外部目的地定义重试、超时和错误注入策略
- Run a mesh service in a Virtual Machine (VM) by [adding VMs to your mesh](https://istio.io/latest/docs/examples/virtual-machines/).
> [!NOTE]
> 默认 Istio 对于未注册的外部 service 流量，Envoy 会 passthrough
- 定义外部资源：
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
name: svc-entry
spec:
hosts:
- ext-svc.example.com
ports:
- number: 443
name: https
protocol: HTTPS
location: MESH_EXTERNAL
resolution: DNS
```
- 使用 hosts 字段指定 external resource.
- 为外部资源配置超时
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: ext-res-dr
spec:
host: ext-svc.example.com
trafficPolicy:
connectionPool:
tcp:
connectTimeout: 1s
```
## Sidecars
- 默认情况下，Istio 配置 Envoy 接受它关联 workload 的所有端口上的流量，转发流量时可以 reach 到 mesh 中的每一个 workload。
- 使用 sidecar 配置可以做到：
- 细粒度控制 Envoy proxy 可以接受的端口和协议。
- 限制 Envoy proxy 可以 reach 到的 services.
- 限制 sidecar reachability 的好处：避免因为内存使用过高而影响 mesh 性能。
- 可以配置 sidecar 只应用于特定 namespace 的所有 workloads 或者某些 workloads（使用 `worloadSelector`)。
```yaml
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: bookinfo
spec:
egress:
- hosts:
- "./*"
- "istio-system/*"
```
- 配置 `bookinfo` namespace 下的所有 services 只能 reach 相同 namespace 的 services 以及 Istio control plane.
## Network resilience and testing
- Istio 提供了可选的容错和错误注入特性，可以在运行时动态配置。
- **Timeouts**：配置 Envoy 等待的超时（Istio 默认禁用）。可以通过 virtual services 动态为每个 service 进行配置。
- **Retries**：为请求配置重试策略（次数、每次间隔等）。通过 virtual services 配置。
- **Circuit breakers**: 应用于真实的 mesh 目的地，需要使用 destination rules 配置。达到配置后（并发连接数、失败请求数），停止向其发送新请求。
- **Fault injection**：在应用层注入（而非在网络层）。通过 virtual services 配置。两种类型错误：
- Delays：延迟请求
- Aborts：返回 HTTP error codes 或者 TCP 连接错误。
- 虽然 Istio 的故障恢复特性可以提升 mesh 中服务的可达性和可用性。但**仍然**需要应用层处理故障或错误，并采取适当的回退操作。
- 例如，当负载均衡池中的所有实例都失败时，Envoy 返回 HTTP 503 状态码。应用程序必须实现任何所需的回退逻辑来处理 HTTP 503 错误代码。
## 总结
> [!Summary] Virtual Service
> - 称为 virtual 是因为它不是真实的 service ，比如一个 virtual service 可以分解映射多个真实 service。
> - 它可以实现到 services 的路由功能，例如实现 AB测试。
> [!Summary] Destination rules
> - 为路由的目的地（services) 划分不同的子集、配置不同的策略（负载均衡等）。
> [!Summary] Service entries
> - 为外部资源（mesh 之外的流量）赋能，例如为它们配置超时、重试等。
> [!Summary] Sidercars
> - 限制 sidecar 到 services 的可达性。
--------------
# Security
- https://istio.io/latest/docs/concepts/security/
- 微服务特有的安全需求：
- 为了对抗中间人攻击，需要**流量加密**
- 为了提供灵活的服务访问控制，需要**双向 TLS** 和 细粒度的**访问策略**
- 为了确定谁在什么时候做了什么事情，需要**审计工具**。
- Istio Security为解决这些问题提供了全面的安全解决方案。
- 
--------
# Observabilty
- https://istio.io/latest/docs/concepts/observability/
- Istio 为网格内的所有 service 通信生成了详细的 telemetry，提供了服务行为的可观测性。
- 三类 telemetry：
- **Metrics**：Istio 根据监控的四个“黄金信号”（延迟、流量、错误和饱和度）生成一组服务指标。也为 mesh control plane 提供了详细的 metrics.
- **Distributed Traces**：为每个服务生成 distributed trace spans，展示了 mesh 中的 call flows 和 服务依赖。
- **Access Logs**：为每次请求生成访问记录，包括源和目的地元数据。
-------
# Extensibility
- https://istio.io/latest/docs/concepts/wasm/
- WebAssembly 是一个用于扩展 Istio proxy(Envoy) 的沙盒技术。Proxy-Wasm sandbox API取代了 Mixer 作为 Istio 中的主要扩展机制。
- WebAssembly sandbox 的目标：
- **Efficiency**：扩展带来的延迟、CPU 和 内存开销要低
- **Function**：An extension can enforce policy, collect telemetry, and perform payload mutations.
- **Isolation**：一个插件的程序错误和 crash 不会影响其他插件。
- **Configuration**：使用跟其他 Istio API 一致的 API 来动态配置插件。
- **Operator**：An extension can be canaried and deployed as log-only, fail-open or fail-close.
- **Extension developer**：插件可以使用多种编程语言。
## High-level architecture
- Istio 扩展（Proxy-Wasm plugins）有几个组件：
- **Filter Service Provider Interface（SPI）**：用于构建 filters 插件
- **Sandbox**：内嵌在 Envoy 中的 V8 Wasm Runtime
- **Host APIs**：处理 headers、trailers 和 metadata
- **Call out APIs**：用于 gRPC 和 HTTP calls
- **Stats 和 Logging APIs**：用于 metrics 和 monitoring
- 
## Example
- C++ Proxy-Wasm filter 插件示例：[Example](https://github.com/istio-ecosystem/wasm-extensions/tree/master/example)
- [Guide](https://github.com/istio-ecosystem/wasm-extensions/blob/master/doc/write-a-wasm-extension-with-cpp.md)
## Ecosystem
- [Istio Ecosystem Wasm Extensions](https://github.com/istio-ecosystem/wasm-extensions)
- [Proxy-Wasm ABI specification](https://github.com/proxy-wasm/spec)
- [Proxy-Wasm C++ SDK](https://github.com/proxy-wasm/proxy-wasm-cpp-sdk)
- [Proxy-Wasm Rust SDK](https://github.com/proxy-wasm/proxy-wasm-rust-sdk)
- [Proxy-Wasm AssemblyScript SDK](https://github.com/solo-io/proxy-runtime)
- [WebAssembly Hub](https://docs.solo.io/web-assembly-hub/latest/tutorial_code/)
- [WebAssembly Extensions For Network Proxies (video)](https://www.youtube.com/watch?v=OIUPf8m7CGA)