Istio 作为服务网格领域的代表项目，为 Kubernetes 上的微服务提供了流量管理、安全加密、可观测性三大核心能力。不过很多团队在第一次部署 Istio 时，往往因为对它的架构和工作方式不够了解，踩了不少坑。这篇文章将结合实际操作，完整演示在 Kubernetes 集群上部署 Istio 的全过程，并解释每一步背后的原理，让你不仅知道怎么做，还知道为什么这么做。
一、Istio 的核心架构与部署前准备
在动手安装之前，有必要先搞清楚 Istio 的整体架构。Istio 采用控制面与数据面分离的设计：控制面负责管理和配置所有代理，核心组件包括 istiod，它合并了早期版本中的 Pilot、Citadel、Galley 三个组件的功能，负责服务发现、证书签发和配置分发；数据面则由 Envoy 代理组成，这些代理以 sidecar 的形式注入到每个业务 Pod 中，拦截进出 Pod 的所有网络流量，从而实现流量路由、熔断、重试、mTLS 加密等能力。
理解 sidecar 注入机制非常重要。Istio 会向每个业务 Pod 中注入一个名为 istio-proxy 的容器，这个容器与业务容器共享网络命名空间，配合 iptables 规则把出入流量劫持到 Envoy。注入方式有两种：一种是基于命名空间标签的自动注入，另一种是使用 istioctl kube-inject 手动注入。生产环境推荐自动注入，管理成本更低。
部署前的环境要求如下：Kubernetes 集群版本建议 1.24 以上，集群节点资源方面，控制面大约需要 2 核 CPU 和 2GB 内存，每个注入 sidecar 的 Pod 会额外增加大约 0.5 核 CPU 和 128MB 内存的开销，规划容量时要预留出来。可以用下面的命令检查集群状态：
# 检查 Kubernetes 集群版本 kubectl version --short # 检查节点资源情况 kubectl top nodes # 确认默认 StorageClass 是否存在（部分组件需要持久化） kubectl get storageclass
二、使用 istioctl 安装 Istio
官方推荐的安装方式是使用 istioctl 命令行工具，它比 Helm 安装更简单，且能在安装前做配置校验。首先到 Istio 官网下载对应版本的安装包，解压后把 istioctl 加入系统 PATH：
# 下载并解压 istioctl（版本号根据实际情况调整） curl -L https://istio.io/downloadistio | ISTIO_VERSION=1.22.0 sh - cd istio-1.22.0 export PATH=$PWD/bin:$PATH # 验证安装 istioctl version
istioctl 提供了几种内置的安装配置 profile，常用的有 default、demo、minimal 和 profile。demo 包含了全套组件，适合本地学习和演示；default 是面向生产的精简配置；minimal 只安装 istiod，适合只需要流量管理的场景。可以先查看 profile 的差异：
# 查看所有可用的 profile istioctl profile list # 查看 default profile 的详细配置 istioctl profile dump default
对于测试环境，可以直接使用 demo profile 一键安装：
istioctl install --set profile=demo -y # 验证 Istio 组件是否正常启动 kubectl get pods -n istio-system
执行完成后，istio-system 命名空间下应该能看到 istiod 和 istio-ingressgateway 两个 Pod 处于 Running 状态。如果 istiod 一直无法启动，优先检查镜像拉取问题，国内环境可以提前给节点配置镜像加速，或者手动修改镜像地址。
三、让应用接入网格并验证
Istio 安装好之后，默认不会对任何业务 Pod 生效，需要给命名空间打上 istio-injection=enabled 标签来开启自动注入：
# 创建业务命名空间并开启 sidecar 自动注入 kubectl create namespace bookinfo kubectl label namespace bookinfo istio-injection=enabled # 部署官方示例应用 Bookinfo kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo # 确认每个 Pod 都包含两个容器（业务容器 + istio-proxy） kubectl get pods -n bookinfo
观察 Pod 状态时，READY 列显示 2/2 就说明 sidecar 注入成功。接着通过 Ingress 网关把应用暴露出去：
# 部署网关路由规则和虚拟服务 kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml -n bookinfo # 获取 ingress 网关的外部访问地址 kubectl get svc istio-ingressgateway -n istio-system # 如果使用 NodePort 方式，拼接访问地址 export GATEWAY_URL=$INGRESS_HOST:$HTTP_PORT curl -s http://$GATEWAY_URL/productpage | grep -o "<title>.*</title>"
能正常返回页面标题，说明流量已经完整地经过了网关、虚拟服务、sidecar 这一整条链路。此时可以再观察 Kiali 之类的可视化组件（demo profile 自带），直观地看到服务之间的调用关系图，这对验证流量走向非常有帮助。
四、常见问题排查
部署过程最常见的坑是 Pod 没有被注入 sidecar。原因通常有几种：命名空间标签是在 Pod 创建之后才打的，注入只对新建 Pod 生效，需要删除重建；Pod 定义中显式设置了 sidecar.istio.io/inject: "false" 注解；或者使用了较老版本中基于 sidecar-injector webhook 的机制与当前版本不兼容。排查时先执行 kubectl get namespace <ns> --show-labels 确认标签，再重建 Pod 即可。
第二个常见问题是开启 mTLS 之后服务调用失败。Istio 1.6 之后默认开启 STRICT 模式的 mTLS，如果集群中存在未注入 sidecar 的客户端去调用网格内的服务，握手会直接失败。解决办法是先把 PeerAuthentication 策略设置为 PERMISSIVE 兼容模式，等所有调用方都接入网格后再切回 STRICT：
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
name: default
namespace: istio-system
spec:
mtls:
mode: PERMISSIVE
第三个问题是 Ingress 网关无法访问。如果使用 LoadBalancer 类型的 Service 但集群没有对应的负载均衡器实现，EXTERNAL-IP 会一直是 pending 状态，此时可以改成 NodePort 方式临时访问。另外要检查 Gateway 资源中配置的 hosts 与实际访问域名是否一致，端口是否匹配，这些细节经常被忽略。
五、总结
整体来看，Istio 的部署本身并不复杂，复杂的是理解它的流量模型和故障排查思路。建议先在测试环境用 demo profile 完整跑一遍 Bookinfo 示例，熟悉 sidecar 注入、网关路由、虚拟服务这些核心概念之后，再逐步引入灰度发布、熔断限流、mTLS 等高级特性。生产环境上线时，记得对 istiod 做高可用部署，并根据实际流量规模调整 sidecar 的资源配额，避免代理本身成为性能瓶颈。
IstioKubernetes服务网格修改时间：2026-09-13 03:58:30