下载并验证 istioctl 版本：执行 curl -l https://istio.io/download/latest | sh -，解压后运行 istioctl version --remote=false，确保 client 与 kubernetes server 版本相差 ≤1 minor（如 1.25.x 与 1.26.x），且 server 版本在 1.23–1.27 区间。
Istio 1.21+ 在 Linux 上必须用 istioctl install 安装，istioctl manifest apply 已被彻底弃用；跳过版本兼容性验证或 Pod 状态检查，90% 的流量策略会静默失效。
怎么下载并验证 istioctl 版本（关键第一步）
新版 Istio 对 Kubernetes 版本敏感：只稳定支持 kubectl version --short 输出的 server 版本在 1.23–1.27 区间。低于 1.23 缺 CRD 支持，高于 1.27 会导致 admission webhook 拒绝注入 Sidecar。
- 用官方脚本拉取（自动适配架构）：
curl -L https://istio.io/download/latest | sh - - 进入解压目录后立刻验证：
istioctl version --remote=false—— client version 必须与集群 server version 相差 ≤1 minor（例如 client 1.25.x 和 server 1.26.x 可接受，但 1.25.x 和 1.28.x 不行） - 把
bin/加进 PATH 后，必须执行source ~/.bashrc或source ~/.zshrc，否则新终端打不开istioctl - 离线环境去
https://github.com/istio/istio/releases手动下载istio-*.tar.gz，注意选linux-amd64（x86_64）或linux-arm64
istioctl install 时 profile=default 和 profile=demo 的真实区别
不是“功能多寡”的问题，而是组件生命周期、资源模型和默认行为完全不同。选错 profile 会导致 Kiali 登录失败、遥测断流、mTLS 不生效甚至 Ingress Gateway 卡在 Pending。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
-
profile=default：只部署istiod和istio-ingressgateway（无 egress），Sidecar 注入默认启用mTLS STRICT；适合生产起步 -
profile=demo：额外部署kiali、grafana、jaeger、prometheus，但全部跑在istio-system下且无资源限制；istio-ingressgatewayService Type 默认是LoadBalancer—— 在裸机或非云 K8s 上会卡住 - 想保留 demo 的可观测性但避开 LoadBalancer？先运行
istioctl install --set profile=demo -y，再立刻执行：kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec":{"type":"NodePort"}}' - 生产环境严禁直接用
profile=demo：它的 Prometheus 是单点、无持久化、无告警规则；Kiali 默认账号密码是admin/admin
安装后必须检查的三个状态（跳过就等于没装）
所有 Istio 流量控制能力都依赖这些 Pod 和 Service 处于 Ready 状态。仅 kubectl get pods -n istio-system 看个数远远不够。
- 确认
istiodPod 是Running且就绪（1/1或2/2）：kubectl get pods -n istio-system -l app=istiod - 确认
istio-ingressgatewayPod 就绪且 Service 已分配端口：kubectl get svc istio-ingressgateway -n istio-system，输出中PORT(S)列应含80:...或443:... - 如果启用了 egress，还要检查
istio-egressgatewayPod 是否 Running；否则后续出站流量会被拦截丢弃
为命名空间启用自动注入并验证 Sidecar 是否生效
自动注入不是“开关一开就完事”，它依赖 istiod 的 webhook 正常工作，而 webhook 依赖前面三步全部成功。
- 给目标命名空间打标签：
kubectl label namespace default istio-injection=enabled（注意不是istio-injection=enabled拼错） - 部署应用后，检查 Pod 的
READY列是否为2/2（主容器 +istio-proxy）：kubectl get pods - 若仍是
1/1，先查istiod日志：kubectl logs -n istio-system deploy/istiod -c discovery | grep -i "admission"，常见原因是 webhook 配置未加载或证书不匹配 - 临时绕过注入失败可手动注入：
istioctl kube-inject -f my-app.yaml | kubectl apply -f -，但仅限调试，不可用于长期部署
最易被忽略的点是：即使所有 Pod 显示 Running，只要 istiod 的 readiness probe 失败（比如因资源不足或配置错误），Sidecar 注入就会静默降级——你不会看到报错，但流量策略完全不生效。务必用 kubectl wait --for=condition=ready pod -n istio-system -l app=istiod 确认其真正就绪。
