如何将 AKS 中的 Istio 从版本 1.7 升级到 1.8
how to upgrade Istio in AKS from version 1.7 to 1.8
我是 ISTIO 的新手，想澄清我的以下疑问。
Details
Current AKS version 1.18.14
planning upgrade to AKS 1.19.11
Current istio version 1.7
Planning upgrade to 1.8
我们计划在生产环境中将 AKS 集群 1.18.14 中的 Istio 版本从 1.7 升级到 1.8。
但是我不确定在生产中应该遵循的正确升级方法，因为 Istio 提供了多种方法。
我不知道当前 Istio 设置是如何在我的环境中完成的，以及我们使用了哪些配置文件设置，因为它是很久以前完成的。可以理解下面是安装 istio 的步骤..
Istio 的安装方式如下：
已创建清单：
istioctl 清单生成 --set profile=default -f /manifests/overlay/overlay.yaml > $HOME/generated-manifest.yaml
已安装的 istio：
istioctl install --set profile=default -f /manifests/overlay/overlay.yaml
根据部署的清单验证了 istio：
istioctl verify-install -f $HOME/generated-manifest.yaml
有什么方法可以导出所有现有设置（当前 运行）并进行升级吗？
所以我正在寻找一种生产就绪的方法来升级 Istio 并放置所有现有设置。
重要
首先考虑复制环境并在 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 - 安装 istioctl 版本 1.8.6：
获取所需的二进制文件：
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.8.6 TARGET_ARCH=x86_64 sh -
并复制istiolctl bin:
sudo cp bin/istioctl /usr/local/bin/
2 - 运行 istioctl version 确认 istioctl 版本和 control/data 平面版本：
client version: 1.8.6
control plane version: 1.7.3
data plane version: 1.7.3 (3 proxies)
3 - 运行 istioctl x precheck 查看是否设置了修订版（it may be different if set - 请参阅本节末尾的警告）
Istio Revision "" already installed in namespace "istio-system"
主要有两种升级策略:
供应商 suggests 使用 Canary，因为它更安全并且可以在最终迁移之前进行测试。
4 - Create a backup:
kubectl get istio-io --all-namespaces -oyaml > "$HOME"/istio_resource_backup.yaml
可以通过以下方式恢复：
kubectl apply -f "$HOME"/istio_resource_backup.yaml
5 - 控制平面 - 安装金丝雀版本
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 - 数据平面
Unlike istiod, Istio gateways do not run revision-specific instances, but are instead in-place upgraded to use the new control plane revision. You can verify that the istio-ingress gateway is using the canary revision by running the following command:
istioctl proxy-status | grep $(kubectl -n istio-system get pod -l app=istio-ingressgateway -o jsonpath='{.items..metadata.name}') | awk '{print }'
To upgrade the namespace NAME_SPACE, remove the istio-injection label, and add the istio.io/rev label to point to the canary revision. The istio-injection label must be removed because it takes precedence over the istio.io/rev label for backward compatibility:
kubectl label namespace NAME_SPACE istio-injection- istio.io/rev=1-8-6
命名空间更新后，pods 需要重新注入。这可以通过重新启动它们来完成，例如与：
kubectl rollout restart deployment -n NAME_SPACE
验证 pods 现在正在使用 canary istiod:
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
仅检查 canary 控制平面是 运行ning：
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 installation methods' pros and cons。
有用的链接
更新
从评论中移走这个。从 1.7.3 更新到 1.8.6 istio 版本有更多挑战。
要删除当前的控制平面 -f 和以前的清单，应该使用。
向1.8.6版本申请同一份清单时，policy和telemetry组件出现错误：
Error: failed to get profile and enabled components: failed to read profile: unknown field "telemetry" in v1alpha1.IstioComponentSetSpec
挖掘后，它出现了，即使 api 版本使用相同 - v1alpha1，较新版本的 istioctl operator 无法验证来自 1.7.3 的清单。
我在 1.7.3 和 1.8.6 istio 安装的 asnwer 开头描述了 installed-state.yaml，并在它们之间得到了 diff：policy telemetry 组件在 1.8.6 中完全缺失，这解释了错误。也有一些变化。 Github link to the diff file，左边是1.7.3，右边是1.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
“调整”它以适应当前现有的清单，然后使用 -f 选项和 adapted 清单继续安装 canary。
我是 ISTIO 的新手，想澄清我的以下疑问。
Details
Current AKS version 1.18.14
planning upgrade to AKS 1.19.11
Current istio version 1.7
Planning upgrade to 1.8
我们计划在生产环境中将 AKS 集群 1.18.14 中的 Istio 版本从 1.7 升级到 1.8。
但是我不确定在生产中应该遵循的正确升级方法，因为 Istio 提供了多种方法。
我不知道当前 Istio 设置是如何在我的环境中完成的，以及我们使用了哪些配置文件设置，因为它是很久以前完成的。可以理解下面是安装 istio 的步骤..
Istio 的安装方式如下：
已创建清单：
istioctl 清单生成 --set profile=default -f /manifests/overlay/overlay.yaml > $HOME/generated-manifest.yaml
已安装的 istio：
istioctl install --set profile=default -f /manifests/overlay/overlay.yaml
根据部署的清单验证了 istio：
istioctl verify-install -f $HOME/generated-manifest.yaml
有什么方法可以导出所有现有设置（当前 运行）并进行升级吗？
所以我正在寻找一种生产就绪的方法来升级 Istio 并放置所有现有设置。
重要
首先考虑复制环境并在 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 - 安装 istioctl 版本 1.8.6：
获取所需的二进制文件：
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.8.6 TARGET_ARCH=x86_64 sh -
并复制istiolctl bin:
sudo cp bin/istioctl /usr/local/bin/
2 - 运行 istioctl version 确认 istioctl 版本和 control/data 平面版本：
client version: 1.8.6
control plane version: 1.7.3
data plane version: 1.7.3 (3 proxies)
3 - 运行 istioctl x precheck 查看是否设置了修订版（it may be different if set - 请参阅本节末尾的警告）
Istio Revision "" already installed in namespace "istio-system"
主要有两种升级策略:
供应商 suggests 使用 Canary，因为它更安全并且可以在最终迁移之前进行测试。
4 - Create a backup:
kubectl get istio-io --all-namespaces -oyaml > "$HOME"/istio_resource_backup.yaml
可以通过以下方式恢复：
kubectl apply -f "$HOME"/istio_resource_backup.yaml
5 - 控制平面 - 安装金丝雀版本
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 - 数据平面
Unlike istiod, Istio gateways do not run revision-specific instances, but are instead in-place upgraded to use the new control plane revision. You can verify that the
istio-ingressgateway is using thecanaryrevision by running the following command:
istioctl proxy-status | grep $(kubectl -n istio-system get pod -l app=istio-ingressgateway -o jsonpath='{.items..metadata.name}') | awk '{print }'
To upgrade the namespace
NAME_SPACE, remove theistio-injectionlabel, and add theistio.io/revlabel to point to thecanaryrevision. Theistio-injectionlabel must be removed because it takes precedence over theistio.io/revlabel for backward compatibility:
kubectl label namespace NAME_SPACE istio-injection- istio.io/rev=1-8-6
命名空间更新后，pods 需要重新注入。这可以通过重新启动它们来完成，例如与：
kubectl rollout restart deployment -n NAME_SPACE
验证 pods 现在正在使用 canary istiod:
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
仅检查 canary 控制平面是 运行ning：
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 installation methods' pros and cons。
有用的链接
更新
从评论中移走这个。从 1.7.3 更新到 1.8.6 istio 版本有更多挑战。
要删除当前的控制平面 -f 和以前的清单，应该使用。
向1.8.6版本申请同一份清单时，policy和telemetry组件出现错误：
Error: failed to get profile and enabled components: failed to read profile: unknown field "telemetry" in v1alpha1.IstioComponentSetSpec
挖掘后，它出现了，即使 api 版本使用相同 - v1alpha1，较新版本的 istioctl operator 无法验证来自 1.7.3 的清单。
我在 1.7.3 和 1.8.6 istio 安装的 asnwer 开头描述了 installed-state.yaml，并在它们之间得到了 diff：policy telemetry 组件在 1.8.6 中完全缺失，这解释了错误。也有一些变化。 Github link to the diff file，左边是1.7.3，右边是1.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
“调整”它以适应当前现有的清单，然后使用 -f 选项和 adapted 清单继续安装 canary。