📚 课程目录第4章 Istio安装与Sidecar注入

4. Istio 安装与 Sidecar 注入

本章聚焦 Istio 服务网格的安装部署与 Sidecar 注入机制。你将掌握使用 istioctl 命令行工具完成 Istio 控制面组件的安装，并深入理解自动与手动两种 Sidecar 注入模式的工作原理与配置方法。这是后续章节中实现精细化流量管理的基础设施前提。

4.1 使用 istioctl 安装 Istio

istioctl 是 Istio 官方提供的命令行工具，支持多种安装配置方式。相比 Helm 或 Operator，istioctl 在演示、调试和 CI/CD 流水线中更为轻量和灵活。安装过程分为下载工具、配置 Profile、应用安装三步。

4.1.1 下载与准备

# 下载指定版本的 Istio 发行包（以 1.20.3 为例）
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.3 sh -

# 将 istioctl 加入 PATH
cd istio-1.20.3
export PATH=$PWD/bin:$PATH

# 验证安装
istioctl version --remote=false

4.1.2 选择安装 Profile

Istio 内置了多个 Profile，用于适配不同环境。生产环境推荐 default 或 demo（功能全但资源消耗高）。

Profile	组件清单	适用场景
default	istiod、ingressgateway、egressgateway	生产最小集
demo	default + 遥测插件（Kiali、Prometheus、Grafana、Jaeger）	功能演示、开发测试
minimal	仅 istiod	控制面最小化
remote	仅 ingressgateway	多集群远程控制面
empty	无组件	完全自定义

4.1.3 执行安装

# 使用 default Profile 安装
istioctl install --set profile=default -y

# 验证控制面 Pod 状态
kubectl get pods -n istio-system

# 预期输出类似：
# NAME                                    READY   STATUS    RESTARTS   AGE
# istiod-5f4c8d6b7c-abcde                1/1     Running   0          2m
# istio-ingressgateway-7f9c8d6b7c-xyz    1/1     Running   0          2m
# istio-egressgateway-6b4c8d6b7c-123     1/1     Running   0          2m

提示： 若需自定义资源配置（如 HPA、Pod 资源限制），可使用 istioctl install -f custom.yaml 方式传入自定义覆盖文件。

4.2 Sidecar 注入原理

Sidecar 注入是 Istio 将 Envoy 代理自动或手动附加到 Pod 中的过程。注入后的 Pod 包含两个容器：业务容器 + Envoy 代理容器。Envoy 拦截所有进出 Pod 的流量，实现流量管理、安全、可观测性等功能。

4.2.1 注入的核心组件

istiod：控制面核心，提供注入配置（MutatingWebhookConfiguration）和证书。
MutatingWebhookConfiguration：Kubernetes 准入控制器，在 Pod 创建时自动调用 istiod 进行注入。
istio-sidecar-injector ConfigMap：存储注入模板，定义注入的容器、卷、环境变量等。

4.2.2 注入流程（自动注入）

4.3 自动注入配置

自动注入依赖命名空间级别的标签。启用后，该命名空间下新建的所有 Pod 都会自动注入 Sidecar。

4.3.1 启用自动注入

# 为命名空间打标签
kubectl label namespace default istio-injection=enabled

# 验证标签
kubectl get namespace -L istio-injection

# 创建测试 Pod（自动注入）
kubectl run nginx --image=nginx

# 查看 Pod 中的容器数量（应为 2）
kubectl get pod nginx -o jsonpath='{.spec.containers[*].name}'
# 输出：nginx istio-proxy

4.3.2 禁用自动注入

# 移除标签
kubectl label namespace default istio-injection-

# 或显式设置为 disabled
kubectl label namespace default istio-injection=disabled --overwrite

注意： 自动注入仅对新创建的 Pod 生效。若需为已有 Pod 注入 Sidecar，必须重建 Pod（如使用 kubectl rollout restart）。

4.4 手动注入配置

手动注入适用于 CI/CD 流水线、离线环境或需要精细控制注入参数的场景。通过 istioctl kube-inject 命令在部署前修改 YAML 清单。

4.4.1 手动注入命令

# 手动注入：读取 deployment.yaml，输出注入后的清单
istioctl kube-inject -f deployment.yaml > injected-deployment.yaml

# 直接应用注入后的清单
istioctl kube-inject -f deployment.yaml | kubectl apply -f -

4.4.2 手动注入与自动注入对比

特性	自动注入	手动注入
触发时机	Pod 创建时（API Server 准入阶段）	部署前（CI/CD 或命令行）
配置方式	命名空间标签 + MutatingWebhook	`istioctl kube-inject` 命令
灵活性	全局统一，无法按 Pod 差异化	可针对每个 Deployment 定制注入参数
依赖	需要 istiod 运行且 Webhook 正常	仅需 istioctl 工具，可离线使用
适用场景	开发测试、标准化生产环境	CI/CD 流水线、离线部署、特殊注入需求

4.4.3 手动注入的典型流水线用法

# 在 CI 阶段注入 Sidecar
- name: Inject Istio Sidecar
  run: |
    istioctl kube-inject \
      --injectConfigFile istio-sidecar-injector-configmap.yaml \
      --meshConfigFile mesh-config.yaml \
      --valuesFile inject-values.yaml \
      -f k8s/deployment.yaml \
      > k8s/deployment-injected.yaml

# 后续步骤直接部署注入后的清单
- name: Deploy to K8s
  run: kubectl apply -f k8s/deployment-injected.yaml

4.5 注入验证与排错

4.5.1 验证注入是否成功

# 查看 Pod 详情，确认包含 istio-proxy 容器
kubectl describe pod <pod-name>

# 检查 Sidecar 是否就绪
kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[?(@.name=="istio-proxy")].ready}'
# 输出：true

# 查看注入的 Sidecar 版本
kubectl exec <pod-name> -c istio-proxy -- pilot-agent request GET /stats | grep istio.version

4.5.2 常见问题与解决

Pod 未注入：检查命名空间标签 istio-injection=enabled 是否存在；确认 istiod 运行正常。
Sidecar 启动失败：查看 Sidecar 日志 kubectl logs <pod-name> -c istio-proxy；检查资源限制是否过小。
注入后 Pod 无法启动：检查 istio-sidecar-injector ConfigMap 中的模板语法；确认 holdApplicationUntilProxyStarts 配置是否合理。

最佳实践： 在 CI/CD 流水线中，建议将手动注入作为标准步骤，确保注入参数可追溯、可审计。自动注入更适合开发环境或标准化程度高的生产命名空间。

4.6 本章小结

通过本章学习，你已掌握：

使用 istioctl 安装 Istio 控制面，并理解不同 Profile 的适用场景。
自动注入与手动注入的工作原理与流程。
两种注入方式的配置方法、对比及典型使用场景。
注入验证与常见排错手段。