4. Istio安装与部署：三种方式，总有一款适合你
好，咱们进入实战环节。安装Istio，说白了就三种主流方式：istioctl、Operator、还有Helm。我个人最常用的是前两种，Helm虽然也能装，但管理起来稍微有点绕。今天咱们重点聊istioctl和Operator，最后再讲讲多集群部署的模式选择。
4.1 使用istioctl安装：最直接，也最灵活
istioctl是官方推荐的安装工具。它就像一个瑞士军刀，能装、能配、能诊断。我刚开始接触Istio时，用的就是它。
安装步骤其实很简单：
- 下载Istio发行版，里面就包含了
istioctl二进制文件。 - 把它放到你的
PATH里。 - 运行
istioctl install。
但这里有个坑。默认安装的是default配置文件，它只开了最基本的组件。如果你需要可观测性（比如Grafana、Kiali），就得用demo配置。嗯，这里要注意，demo配置不适合生产环境，它把很多调试端口都暴露出来了。
我个人习惯的做法：
先跑一个istioctl profile list看看有哪些配置档。然后基于某个配置档，再用-f参数覆盖自定义的YAML文件。这样既保留了基础配置，又能灵活调整。
# 查看可用配置档
istioctl profile list
# 基于default配置，再叠加自定义配置
istioctl install --set profile=default -f my-overlay.yaml你可能会问，my-overlay.yaml里写什么？举个例子，你想开启访问日志，或者调整Pilot的副本数，都可以写在这里。说白了，这就是一个增量配置，Istio会帮你合并。
避坑指南：我曾经在生产环境直接用了istioctl install默认配置，结果发现Pilot的内存占用比预期高。后来我通过my-overlay.yaml限制了Pilot的资源配额，问题就解决了。所以，生产环境一定要做资源规划。
4.2 Operator安装方式：声明式管理，运维更省心
如果你熟悉Kubernetes的Operator模式，那Istio Operator会让你感觉很亲切。它把Istio的安装和升级，都变成了Kubernetes的自定义资源（CR）。你只需要提交一个IstioOperator的YAML，Operator就会自动帮你搞定一切。
安装Operator本身也很简单：
# 安装Istio Operator
istioctl operator init
# 查看Operator是否运行
kubectl get pod -n istio-operator然后，你就可以提交一个IstioOperator资源了：
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
name: my-istio-install
namespace: istio-system
spec:
profile: default
components:
pilot:
k8s:
resources:
requests:
cpu: 500m
memory: 1Gi
limits:
cpu: 1000m
memory: 2GiOperator的好处是，你后续想改配置，直接编辑这个CR就行，Operator会自动调和。你想想看，这比每次手动跑istioctl install要优雅得多。
注意：Operator方式虽然方便，但它的版本升级策略需要你留意。升级Operator本身，和升级Istio控制面，是两回事。我曾经因为没搞清楚这个，导致Operator版本和Istio版本不匹配，折腾了半天。建议你先升级Operator，再升级Istio CR。
4.3 多集群部署模式选择：primary-remote vs primary-primary
聊完单集群，咱们看看多集群。这是生产环境绕不开的话题。Istio支持两种多集群模式：primary-remote和primary-primary。
先看个表格，直观对比一下：
| 特性 | Primary-Remote | Primary-Primary |
|---|---|---|
| 控制面数量 | 1个（Primary集群） | 每个集群各1个 |
| 数据面 | Remote集群的数据面由Primary控制 | 各自管理自己的数据面 |
| 网络要求 | Remote集群需要能访问Primary的API Server | 集群间网络互通（通常需要VPN或专线） |
| 故障隔离 | Primary挂了，Remote集群的数据面会受影响 | 单个集群故障不影响其他集群 |
| 管理复杂度 | 较低，只有一个控制面 | 较高，需要维护多个控制面 |
| 适用场景 | 中心化管控，Remote集群规模较小 | 高可用要求，每个集群独立自治 |
4.3.1 Primary-Remote：中心化管控
这种模式，说白了就是一个“老大”带着一群“小弟”。老大（Primary集群）运行着完整的Istio控制面，小弟（Remote集群）只运行数据面组件（比如Ingress Gateway、Egress Gateway），以及一个叫istio-remote的Agent。
Remote集群的Pod，通过这个Agent去连接Primary集群的Pilot，获取配置。所以，Remote集群必须能访问Primary集群的API Server。
我建议：如果你的公司有多个Kubernetes集群，但大部分流量都集中在某个中心集群，或者你想统一管理服务网格的配置，那Primary-Remote模式就很合适。我在一个客户那里就是这样做的，他们有一个核心集群，其他几个边缘集群都作为Remote加入，管理起来非常方便。
4.3.2 Primary-Primary：去中心化，高可用
这种模式下，每个集群都是“老大”，都有自己的控制面。它们之间通过东西向网关（East-West Gateway）来同步服务发现信息和证书。说白了，就是每个集群都独立自治，但又能互相发现服务。
这种模式对网络要求比较高。集群之间需要二层互通，或者至少能通过VPN/专线打通。否则，东西向网关无法正常工作。
避坑指南：我曾经在一个跨地域的多集群场景中，选择了Primary-Primary模式。结果发现，两个集群之间的延迟太高，导致东西向网关的心跳超时，服务发现经常中断。后来我们改用了Primary-Remote模式，把控制面部署在延迟较低的中心集群，问题才解决。所以，网络延迟是选择模式的关键因素。
4.3.3 如何选择？
嗯，这里我直接给结论：
- 如果你追求管理简单，且Remote集群规模不大，选Primary-Remote。
- 如果你追求高可用，每个集群都需要独立自治，选Primary-Primary。
- 如果你的集群跨地域，网络延迟较高，建议优先考虑Primary-Remote，把控制面放在延迟最低的集群。
最后，不管选哪种模式，多集群的证书管理都是个大坑。建议你提前规划好证书的签发和轮换策略，不然等到证书过期，整个网格都会瘫痪。这个咱们后面章节会详细讲。