istio实验1-请求路由

1、bookinfo应用架构

2、路由到版本v1

• 在之前的实验中，访问productpage会看到V1、V2、V3这三个版本。这个实验会将请求全部路由到V1版本的微服务

部署virtualService

kubectl apply -f /root/istio-1.24.3/samples/bookinfo/networking/virtual-service-all-v1.yaml

virtual-service-all-v1.yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: productpage
spec:
  hosts:
  - productpage
  http:
  - route:
    - destination:
        host: productpage
        subset: v1
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v1
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: details
spec:
  hosts:
  - details
  http:
  - route:
    - destination:
        host: details
        subset: v1
---

部署destinationRule

kubectl apply -f /root/istio-1.24.3/samples/bookinfo/networking/destination-rule-all-v1.yaml

destination-rule-all-v1.yaml

apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: productpage
spec:
  host: productpage
  subsets:
  - name: v1
    labels:
      version: v1
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
---
apiVersion: networking.istio.io/v1
kind: DestinationRule
metadata:
  name: details
spec:
  host: details
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
---

查看路由情况

• 在k8s集群其中一个节点执行，模拟用户访问

while true; do curl -s http://192.168.40.11:8088/productpage > /dev/null; sleep 0.2; done

• 在kiali中查看

3、基于用户身份的路由

部署virtualservice

• 注意：
  • 一个 Service 通常只对应 一个 VirtualService
  • 不能创建两个同名 VS
  • 也不应该创建两个指向同一个 host 的 VS（容易冲突）
• 只需要修改名为reviews的VS即可，其他VS保留。DR也保留

kubectl apply -f /root/istio-1.24.3/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml

virtual-service-reviews-test-v2.yaml

apiVersion: networking.istio.io/v1
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: v1

查看路由情况

5、混沌工程（Chaos Engineering）

传统测试方式

• 开发 → 测试 namespace → 故障注入 → 验证超时链 → 修复 → 上线 → 结束

云环境下成熟公司的测试方式

• 阶段1，测试 namespace 故障注入；（测试环境验证功能）
• 阶段2，灰度环境；（预发布环境验证压力）
• 阶段3，生产1% 流量注入；（生产小流量验证韧性）
• 阶段4，扩大到 5%；（持续周期性故障演练）

能生产测试的原因

• 生产测试是“可控影响”。因为它不是全量注入，随机大面积宕机。而是1% 流量，指定 Header，指定用户，指定时间窗口，有监控和回滚预案

混沌测试在现实中的平衡方式

• 先在灰度环境验证，再在生产只对内部用户注入
• 或只在凌晨低峰期做
• 或只在一个 AZ 做

混沌工程的意义

• 主动、可控地在系统中制造故障，验证系统在真实生产环境下的韧性

混沌工程的目标

• 系统是否有合理的超时？
• 重试是否会放大流量？
• 是否存在级联失败？
• 是否有快速回滚能力？

如果：
ratings 延迟 9 秒
productpage 允许 6 秒
你是：
A. 改 productpage 代码
B. 改 Istio timeout
C. 改 reviews timeout
D. 改架构设计
你会选哪个？为什么？

我问你一个更深入的问题
如果：
你在生产 1% 流量上注入 7 秒延迟
结果 productpage 开始 CPU 飙升
你觉得原因可能是什么？
A. 重试放大流量
B. 线程池阻塞
C. 连接耗尽
D. 全部都有可能

kubectl get virtualservices -o yaml

Istio 的路由匹配逻辑

如果 VirtualService 里：
没写gateways，只对mesh内部流量生效
写了gateways: [mesh]，只对mesh内部生效
写了具体gateway名称，只对外部流量生效
两个都写，内外都生效

Gateway的ADDRESS是bookinfo-gateway-istio.default.svc.cluster.local。说明它是ClusterIP 类型，只能在集群内部访问

而且service中没有istio-ingressgateway，没有NodePort或LoadBalancer，没有 8088 端口。所以访问http://192.168.40.11:8088/productpage不会经过 Istio Gateway

在新版 Istio 里，Gateway API 会：自动创建一个 Deployment + Service。默认是 ClusterIP。不会自动暴露为 NodePort。

Istio路由体系

• 在Istio中有两套路由体系：
  • 传统 Istio API（Gateway + VirtualService）
  • Kubernetes Gateway API（Gateway + HTTPRoute）
• 路由体系只是指定了流量的路由规则，执行路由的方式是数据平面决定的，Sidecar模式下是由每个Pod的Envoy执行路由，Ambient模式是由Waypoint（Envoy）或 ztunnel执行。Ambient 默认只有 L4（ztunnel）如果你只用 mTLS，不用 L7，那么不需要任何路由API。如果你要 L7 路由（灰度、header 匹配）就必须创建 Waypoint，Waypoint 是 Envoy。此时可以用 VirtualService也可以用 HTTPRoute，但执行者是Waypoint Envoy

传统 Istio API

• istio自己设计的API，功能完整，可以实现流量的细粒度控制，生产最常见

组件

• Gateway（networking.istio.io）
• VirtualService
• DestinationRule
• istio-ingressgateway（独立 Service）

流量结构

浏览器
   ↓
NodePort / LoadBalancer
   ↓
istio-ingressgateway (Envoy)
   ↓
VirtualService 路由规则
   ↓
destnationrule
   ↓
Service
   ↓
Pod

Gateway API

• 这是 Kubernetes 官方主推标准。Istio 只是其中一个实现者

组件

• Gateway（gateway.networking.k8s.io）
• HTTPRoute
• GatewayClass

流量结构

浏览器
   ↓
Gateway Service
   ↓
HTTPRoute
   ↓
Service
   ↓
Pod

命令 istioctl analyze

模拟访问
apt install apache2-utils -y

修改了 /root/istio-1.24.3/samples/bookinfo/networking/virtual-service-all-v1.yaml
svc/bookinfo-gateway-istio由ClusterIP改为NodePort