istio 1.21+ 在 linux 上安装必须用 istioctl install，先通过 curl -l https://istio.io/download/latest | sh - 下载解压，进入目录后运行 istioctl version --remote=false 验证客户端版本与集群 kubectl version --short 的 server 版本兼容（±1 minor），再将 bin/ 加入 path 并 source 配置文件。
直接上结论：Istio 1.21+ 版本在 Linux 上安装，istioctl install 是唯一推荐方式，istioctl manifest apply 已被弃用；不验证 istiod 和 istio-ingressgateway 的 Pod 状态，90% 的后续流量配置会失败。
怎么下载并配置 istioctl（必须匹配集群 Kubernetes 版本）
新版 Istio 对 Kubernetes 版本有硬性要求：1.23–1.27 是当前稳定支持区间。低于 1.23 可能缺 CRD 支持，高于 1.27 则部分 admission webhook 会拒绝注入。
- 用官方脚本拉取最新版（自动适配架构）：
curl -L https://istio.io/download/latest | sh - - 进入解压目录后，**立刻验证版本兼容性**：
istioctl version --remote=false—— 输出的 client version 必须和你集群的kubectl version --short中的 server version 尽量接近（±1 minor 版本内） - 把
bin/加进 PATH 后，别忘了运行source ~/.bashrc或source ~/.zshrc，否则终端新开后istioctl找不到 - 如果集群是 air-gapped 环境，不能走 curl，就去
https://github.com/istio/istio/releases手动下载对应istio-*.tar.gz，注意选linux-amd64（x86_64）或linux-arm64（ARM 服务器）
istioctl install 时 profile=default 和 profile=demo 的真实区别
不是“功能多少”的问题，而是组件生命周期和资源占用逻辑完全不同。选错 profile 会导致 Kiali/Grafana 无法访问、遥测数据断流，甚至影响 mTLS 自动启用。
-
profile=default：只部署istiod、istio-ingressgateway（无 egress）、基础 CRD；Sidecar 注入默认开启 mTLS STRICT 模式；适合生产环境起步 -
profile=demo：额外部署kiali、grafana、jaeger、prometheus，但所有组件都跑在istio-system下且无资源限制；istio-ingressgateway默认监听 80/443，但 Service Type 是LoadBalancer—— 在裸机或非云 K8s 上会卡在Pending状态 - 想保留 demo 的可观测性但避免 LoadBalancer 卡住？先
istioctl install --set profile=demo，再立刻执行：kubectl patch svc istio-ingressgateway -n istio-system -p '{"spec":{"type":"NodePort"}}' - 千万别在生产环境直接用
profile=demo：它的 Prometheus 是单点、无持久化、无告警规则，Kiali 默认 admin/admin 登录，没改密码就暴露在公网等于送钥匙
为什么 kubectl get pods -n istio-system 显示 Running 但服务就是不通
常见假象：Pod 状态是 Running，但容器就绪探针（readiness probe）失败，Envoy 根本没起来。最典型的是 istiod 的 853 端口没响应，或 istio-ingressgateway 的 15021 健康检查返回 503。
- 查真实就绪状态：
kubectl get pods -n istio-system -o wide，重点看 RESTARTS 列 —— 非零值说明容器反复崩溃，大概率是 RBAC 权限不足或证书生成失败 - 盯紧
istiod日志：kubectl logs -n istio-system deploy/istiod，出现failed to generate certificate或no endpoints available就是证书系统没初始化成功 -
istio-ingressgateway的 Service 如果是ClusterIP类型，外部根本访问不到；确认它是否绑定了 NodePort 或已关联云厂商 LB；用kubectl get svc -n istio-system istio-ingressgateway -o yaml查spec.ports和status.loadBalancer - 自动注入没生效的静默错误：namespace 被打了
istio-injection=enabled标签，但 Pod YAML 里写了sidecar.istio.io/inject: "false"，优先级更高，注入会被跳过
部署 Bookinfo 后访问 404 或 503 的关键排查点
Bookinfo 不是“部署完就通”，它依赖 Gateway + VirtualService + DestinationRule 三层联动。少一层，浏览器就只能看到 404 或 upstream connect error。
- 确保
bookinfo的四个 Deployment 全是2/2 Ready：kubectl get pods—— 如果是1/2，说明 Envoy sidecar 启动失败，大概率是 namespace 注入标签没打，或istiod还没 ready - Gateway 必须显式绑定到
istio-ingressgateway的 workload：spec.selector.istio字段值必须是ingressgateway（不是istio-ingressgateway），否则流量进不来 - VirtualService 的
host必须和你实际访问的域名一致（比如用curl -H "Host: bookinfo.example.com" http://$INGRESS_HOST:$INGRESS_PORT/productpage，那 VS 的 host 就得写bookinfo.example.com） - DestinationRule 必须存在且
host匹配 service 名（如details.default.svc.cluster.local），否则流量路由阶段直接 503；用istioctl analyze可快速扫出这类配置断裂
真正卡住人的地方从来不是命令输错，而是 istiod 的证书初始化失败、istio-ingressgateway 的 Service 类型不匹配、或者 VirtualService 的 host 和 curl 的 Host 头对不上——这三个点漏查一个，后面所有流量策略都是空中楼阁。
