K8s 运维系列 | 第 20 天：服务网格——Istio 入门与流量管理

引言

随着微服务架构在生产环境的深入落地，服务之间的调用关系变得日益复杂。当我们把一个个单体应用拆分成几十上百个微服务之后，服务间的通信、流量控制、安全认证、可观测性等一系列问题接踵而至。传统的做法是在每个服务的业务代码里嵌入 SDK（如 Spring Cloud、Dubbo），但这种方式强绑定了语言与框架，跨团队、跨语言的治理成本极高。服务网格（Service Mesh）正是为解决这一困境而生的基础设施层方案，而 Istio 则是当下最主流、社区最活跃的服务网格实现之一。本篇作为 K8s 运维系列的第 20 天，将带你从零认识 Istio 的核心架构，并完成流量管理方向的实战演练。

核心概念

什么是服务网格

服务网格是一个专门负责服务间通信的基础设施层，它把原本散落在业务代码里的流量治理能力（重试、超时、熔断、限流、路由、鉴权、加密、观测）下沉到一个独立的进程中，让业务开发专注于业务本身。服务网格通常由「数据平面（Data Plane）」和「控制平面（Control Plane）」两部分组成。

数据平面与控制平面

数据平面：由一组与业务容器并行部署的轻量级网络代理组成，Istio 默认使用 Envoy。每个 Pod 内都会注入一个 Sidecar（边车）容器，所有进出该服务的流量都被 Envoy 接管。
控制平面：负责配置下发与策略管理，Istio 的控制平面组件（Istiod）将路由规则、安全策略、服务发现信息翻译成 Envoy 的配置并下发。

为什么需要 Sidecar

Sidecar 模式是服务网格的核心思想。业务容器完全无感知地被注入一个 Envoy 代理容器，两者共享网络命名空间。这样 Envoy 就能透明地拦截、转发、监控业务流量，而业务代码不需要做任何改动。

实战步骤

1. 下载并安装 Istio

我们以 istioctl 方式安装，这是官方推荐且最直观的方式。先下载与 K8s 集群版本兼容的 Istio 发行包：

# 下载 Istio（示例为 1.20 版本）
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.4 sh -
cd istio-1.20.4

# 将 istioctl 加入 PATH
export PATH=$PWD/bin:$PATH

# 预检环境是否符合安装要求
istioctl x precheck

2. 安装 Istio 到集群

使用默认 profile 安装，它会在 istio-system 命名空间部署 Istiod 与 ingress/egress 网关：

# 安装默认 profile（包含控制平面与入口/出口网关）
istioctl install --set profile=default -y

# 查看安装结果
kubectl get pods -n istio-system

3. 开启命名空间自动注入 Sidecar

给目标命名空间打上注入标签，之后该命名空间内新建的 Pod 都会自动注入 Envoy Sidecar：

# 给 default 命名空间开启自动注入
kubectl label namespace default istio-injection=enabled

# 验证命名空间标签
kubectl get namespace -L istio-injection

4. 部署示例应用 Bookinfo

Bookinfo 是 Istio 官方的演示应用，包含 productpage、reviews、details、ratings 四个服务，非常适合演示流量管理能力：

# 部署 Bookinfo 应用
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

# 确认服务与 Pod 均已就绪
kubectl get services
kubectl get pods

5. 配置网关对外暴露服务

通过 Gateway 与 VirtualService 资源将 productpage 服务暴露到集群外部：

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: bookinfo-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"
---
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: bookinfo
spec:
  hosts:
    - "*"
  gateways:
    - bookinfo-gateway
  http:
    - route:
        - destination:
            host: productpage
            port:
              number: 9080

应用上述配置后，即可通过 Ingress 网关访问应用：

kubectl apply -f bookinfo-gateway.yaml

# 获取入口网关的外部地址
kubectl get svc istio-ingressgateway -n istio-system

6. 基于权重的流量路由

利用 VirtualService 实现「灰度发布」，将 reviews 服务的流量按 80% 与 20% 的比例分发到不同版本：

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
    - reviews
  http:
    - route:
        - destination:
            host: reviews
            subset: v1
          weight: 80
        - destination:
            host: reviews
            subset: v2
          weight: 20

其中 subset 对应 DestinationRule 中定义的不同版本子集，实际生产中可以配合 Deployment 的不同标签版本进行更细粒度的灰度控制。

常见问题

1. 为什么 Pod 里没有注入 Sidecar？

最常见的原因是命名空间没有打上 istio-injection=enabled 标签，或者应用部署发生在打标签之前。可以通过 kubectl get pods -l istio-injection 或查看 Pod 的容器数量（正常应为 2 个，业务容器 + Sidecar）来排查。如果是存量 Pod，需要重启 Deployment 触发重建才会注入。

2. 注入 Sidecar 后服务无法正常启动？

这通常与 iptables 规则冲突、资源配额不足或 Envoy 无法连接控制平面有关。检查 kubectl describe pod 中 Sidecar 容器的状态与日志，确认 istiod 服务可达、Pod 资源 requests/limits 设置合理。

3. VirtualService 不生效？

需要确认 VirtualService 与 DestinationRule 是否应用到了正确的命名空间、hosts 是否与实际服务名一致、是否存在资源命名冲突。可以使用 istioctl analyze 命令对配置进行静态分析，快速定位配置错误。

4. 如何清理测试应用？

kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml
kubectl delete -f bookinfo-gateway.yaml

总结

服务网格是云原生领域面向「服务间通信治理」的一次范式升级，Istio 凭借其强大的流量管理、安全与可观测性能力，成为该领域的标杆项目。本篇我们从服务网格的基本概念出发，梳理了数据平面与控制平面的关系，理解了 Sidecar 模式的工作原理，并通过 Istio 的安装、Sidecar 自动注入、Bookinfo 部署、网关暴露以及基于权重的灰度路由，完成了一次完整的流量管理实战。掌握 Istio 的流量管理，是走向生产级微服务治理的重要一步。下一篇我们将进入 K8s 运维系列的第 21 天，聚焦集群的安全加固，深入探讨 Pod Security 与准入控制（Admission Control）机制。