重要的
考虑复制环境并首先在 dev/stage 上执行升级，以确保它适用于您和您的基础架构。
检查您到底安装了什么
可以通过获取installed state custom resource和所有设置来完成：
kubectl -n istio-system get IstioOperator installed-state -o yaml > installed-state.yaml
以下是基于官方文档升级使用的步骤istioctl
从 1.7.3 到 1.8.6，这对于其他版本将是类似的，但是升级应该不超过 1 个次要版本的差异，例如 1.5 到 1.6。
可用版本和发行版可以在Istio Github中查看。
1 - 安装istioctl1.8.6 版：获取所需的二进制文件：
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.8.6 TARGET_ARCH=x86_64 sh -
和复制istiolctl箱：
sudo cp bin/istioctl /usr/local/bin/
2 - 运行istioctl version以确认istioctl版本和控制/数据平面版本：
client version: 1.8.6
control plane version: 1.7.3
data plane version: 1.7.3 (3 proxies)
3 - 运行istioctl x precheck以查看是否设置了修订版（如果设置可能会有所不同- 请参阅部分末尾的警告）
Istio Revision "" already installed in namespace "istio-system"
有两种主要的升级策略：
供应商建议使用金丝雀，因为它更安全，并且可以在最终迁移之前进行测试。
4 -创建备份：
kubectl get istio-io --all-namespaces -oyaml > "$HOME"/istio_resource_backup.yaml
可以通过以下方式恢复：
kubectl apply -f "$HOME"/istio_resource_backup.yaml
5 - 控制平面- 安装 Canary 版本
istioctl install --set profile=default --set revision=1-8-6
通过运行以下命令检查它是否安装成功：
kubectl get pods -n istio-system -l app=istiod
NAME READY STATUS RESTARTS AGE
istiod-1-8-6-b855c557b-qq4qd 1/1 Running 0 44s
istiod-54b46bbc58-wzklh 1/1 Running 0 14m
kubectl get svc -n istio-system -l app=istiod
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istiod ClusterIP 10.109.24.78 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP,853/TCP 15m
istiod-1-8-6 ClusterIP 10.101.241.85 <none> 15010/TCP,15012/TCP,443/TCP,15014/TCP 2m12s
kubectl get mutatingwebhookconfigurations
NAME WEBHOOKS AGE
istio-sidecar-injector 1 15m
istio-sidecar-injector-1-8-6 1 98s
6 - 数据平面
与 istiod 不同，Istio 网关不运行特定于版本的实例，而是就地升级以使用新的控制平面版本。您可以通过运行以下命令来验证istio-ingress网关是否正在使用该修订：canary
istioctl proxy-status | grep $(kubectl -n istio-system get pod -l app=istio-ingressgateway -o jsonpath='{.items..metadata.name}') | awk '{print $7}'
要升级命名空间NAME_SPACE，请移除istio-injection标签，然后添加istio.io/rev标签以指向canary修订版。必须删除标签，istio-injection因为它优先于istio.io/rev标签以实现向后兼容性：
kubectl label namespace NAME_SPACE istio-injection- istio.io/rev=1-8-6
命名空间更新后，需要重新注入 pod。这可以通过重新启动它们来完成，例如：
kubectl rollout restart deployment -n NAME_SPACE
验证 Pod 现在正在使用canaryistiod：
istioctl proxy-status
NAME CDS LDS EDS RDS ISTIOD VERSION
istio-ingressgateway-6664d4b478-j7vhh.istio-system SYNCED SYNCED SYNCED NOT SENT istiod-1-8-6-b855c557b-qq4qd 1.8.6
nginx-68748d7f8c-82x8k.default SYNCED SYNCED SYNCED SYNCED istiod-1-8-6-b855c557b-qq4qd 1.8.6
nginx-68748d7f8c-fnhgz.default SYNCED SYNCED SYNCED SYNCED istiod-1-8-6-b855c557b-qq4qd 1.8.6
7 - 卸载旧的控制平面
跑：
istioctl x uninstall -f manifests/profiles/default.yaml
检查仅金丝雀控制平面正在运行：
kubectl get pods -n istio-system -l app=istiod
NAME READY STATUS RESTARTS AGE
istiod-1-8-6-b855c557b-qq4qd 1/1 Running 0 17m
其他可用的 istio 安装类型：
请熟悉istio 安装方法的优缺点。
有用的链接
更新
从评论中移出这个。从 1.7.3 更新到 1.8.6 istio 版本有更多挑战。-f应使用先前清单删除当前控制平面。向版本申请相同的manifest时，和组件1.8.6有错误：policytelemetry
Error: failed to get profile and enabled components: failed to read profile: unknown field "telemetry" in v1alpha1.IstioComponentSetSpec
经过挖掘，它出现了，即使 api 版本使用相同 - v1alpha1，新版本的istioctl operatorcan't validate manifest from 1.7.3.
我按照 asnwer from和istio 安装installed-state.yaml开始时所描述的那样进行操作，并在它们之间进行了比较：组件完全丢失，其中解释了错误。也有一些变化。diff文件的Github链接，左边是，右边是。1.7.31.8.6diffpolicytelemetry1.8.61.7.31.8.6
在这种情况下，如果不手动处理清单，可能无法升级：
1 - 检查应用的清单是默认的还是有变化的。获取默认配置文件（注意！应该使用 istioctl 1.7.3）：
istioctl profile dump default > default-profile.yaml
2 - 如果清单是默认的，那么安全地继续canary安装--set profile=default.
3 - 清单不是默认的并且具有自定义。使用istioctl 1.8.6获取默认配置文件的转储：
istioctl profile dump default > default-profile-186.yaml
将其“调整”到当前现有的清单，然后继续canary使用-f选项和adapted清单进行安装。