服务器Service Mesh配置：从零搭建Istio流量治理

Service Mesh（服务网格）解决的核心问题是：在不改动业务代码的前提下，为微服务之间的通信加上流量控制、加密、可观测性。
如果你的服务器已经运行 Kubernetes，想在集群里配置 Service Mesh，最常用的方案是 Istio。
下面以 Istio 为例，讲清楚从零到流量路由生效的完整过程。

先确认你的环境能不能装 Istio

Istio 运行在 Kubernetes 之上，所以前提是你已经有一个可用的 K8s 集群。
执行以下命令确认集群状态：

kubectl cluster-info
kubectl get nodes

预期结果是节点状态为 Ready。
如果这条命令都报错，先解决 K8s 本身的问题，不要继续装 Istio。

还需要确认两件事：

• kubectl 版本：建议与集群版本差距不超过一个小版本，用 kubectl version --short 查看。
• 资源余量：Istio 控制面（istiod）本身占用不高，但每个注入 Sidecar 的 Pod 会额外消耗 CPU 和内存。节点剩余内存建议不低于 2 GB。

下载 istioctl 命令行工具：

curl -L https://istio.io/downloadIstio | sh -
cd istio-*
export PATH=$PWD/bin:$PATH
istioctl version

istioctl version 能输出版本号，说明工具可用。

安装控制面并开启自动注入

Istio 官方提供多种安装配置档（profile），生产环境常用 default，资源紧张可以用 demo 先跑通。
执行：

istioctl install --set profile=demo -y

安装完成后检查关键组件：

kubectl get pods -n istio-system

istiod 应为 Running。
如果 istio-ingressgateway 处于 Pending，通常是节点没有可用端口或云厂商 LoadBalancer 未就绪，可先用 NodePort 验证。

下面给目标命名空间打标签，让 Istio 自动注入 Sidecar：

kubectl label namespace default istio-injection=enabled

验证标签是否生效：

kubectl get namespace -L istio-injection

default 一行应显示 enabled。

部署示例应用并验证 Sidecar 注入

用官方 bookinfo 示例验证最直接：

kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
kubectl get pods

关键看 READY 列，正常应该显示 2/2，说明业务容器和 istio-proxy 两个容器都在运行。
如果显示 1/1，说明 Sidecar 没有注入。

常见原因是命名空间标签没打对，或者 Pod 是在打标签之前就已经创建的。已存在的 Pod 不会自动补注入，需要重建：

kubectl rollout restart deployment -n default

配置流量路由并观察效果

Service Mesh 的价值要通过路由规则体现。
假设你想把 90% 流量发给 v1、10% 发给 v2，先定义 DestinationRule 和 VirtualService：

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

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

应用后检查规则是否被 istiod 接受：

kubectl apply -f destination-rule.yaml
kubectl apply -f virtual-service.yaml
istioctl analyze

istioctl analyze 没有输出 Error 或 Warning，说明配置语法和引用关系正常。
再通过 ingress gateway 访问几次，观察是否按权重返回不同版本页面。

容易踩的坑和排查思路

• Sidecar 没注入：先查命名空间标签，再确认 Pod 是否在打标签后创建。
• 端口冲突：Istio 默认接管 15001、15006 等端口，如果节点上有其他程序占用，Sidecar 会启动失败，用 kubectl logs -c istio-proxy 查看。
• DNS 解析失败：Sidecar 注入后，Pod 的 DNS 请求会经过 istio-proxy，确保 kube-dns 或 coredns 服务正常运行。
• 资源不足导致 OOM：Sidecar 默认内存限制较低，高流量场景需要在 Deployment 的 annotation 中调整 sidecar.istio.io/proxyMemory。
• 卸载不干净：直接删除 istio-system 命名空间可能残留 webhook，正确做法是 istioctl uninstall --purge。

如果只是学习验证，
装完后建议用 kubectl delete -f samples/bookinfo/platform/kube/bookinfo.yaml 清理示例应用，
避免长期占用资源。

后续可以继续深入的方向

跑通基础路由后，可以再尝试 mTLS 加密、请求超时与重试、Prometheus 指标采集。
这些能力都不需要改业务代码，但每一步都建议先在测试命名空间验证，确认无误再推到生产。