代管式 Cloud Service Mesh 发布渠道
Cloud Service Mesh 经常发布更新,以提供安全更新、修复 并引入新功能。发布渠道之间的平衡 Cloud Service Mesh 版本的稳定性和功能集。Cloud Service Mesh 发布渠道与 Google Kubernetes Engine (GKE) 发布渠道相关联。Google 会自动管理每个版本的版本和升级频率 。
本文档介绍了发布渠道的对比以及如何更新 非受管代理
可用发布渠道
您可以获得以下发布渠道。每个渠道都在功能可用性和更新流失率之间进行权衡取舍。每个渠道中的功能都有不同的成熟度级别。 我们会向所有发布渠道提供重要的安全补丁,以保护您的集群和 Google 的基础架构。
渠道 | 全新代管式 Cloud Service Mesh 可用性 | 属性 |
---|---|---|
快速 | 每次发布 Cloud Service Mesh 后 | 尽早获取最新的 Cloud Service Mesh 版本,并在新功能加入版本后立即使用它们。您的控制层面会经常更新,以跟进可用的最新补丁程序版本并提供更新的功能。快速渠道最适合用于在预生产环境中测试较新的 Cloud Service Mesh 版本和 API。 |
常规 | “快速”已提升为“普通”* | 在 Cloud Service Mesh 和 Istio 功能首次发布后的合理时间内可以尽快访问,但应该访问经过较长时间验证合格的版本。兼顾功能可用性和版本稳定性,是我们向大多数用户推荐的做法。 |
稳定版 | 常规提升为稳定版* | 优先考虑新功能的稳定性。此渠道中的变更和新版本将最后发布,也就是说在通过快速渠道和常规渠道验证后发布,这样就有更多验证时间。 |
* 向下一个渠道的提升时间表取决于多种因素,包括开源 Istio 发布、Anthos 发布和修补时间表,因此可能会发生变化。如需及时了解最新信息,请将 Cloud Service Mesh 版本说明的网址添加到您的 Feed 阅读器,或直接添加 Feed 网址:https://cloud.google.com/feeds/servicemesh-release-notes.xml
|
当托管式 Cloud Service Mesh 的次要版本具有足够的使用率且 在快速渠道中证明效果稳定,则会升级为常规渠道 。最后,次要版本会被提升为仅接收高优先级更新的稳定渠道。根据观察到的运行该版本的控制层面性能,每次提升都标志着稳定性和生产就绪性逐步提高。
所有渠道都基于正式版 (GA)(但如标记的那样,有些功能并不总是正式版)。新的 Cloud Service Mesh 版本会先发布到快速渠道,然后随着时间的推移升级到常规和稳定渠道。这样一来,您就可以选择满足业务、稳定性和功能性需求的渠道。
集群的 Cloud Service Mesh 渠道由其 GKE 集群渠道决定。
GKE 渠道 | Cloud Service Mesh 通道 |
---|---|
快速 | 快速 |
常规 | 常规 |
稳定版 | 稳定版 |
(无渠道) | 常规 |
每个渠道的 Cloud Service Mesh 版本
您的 Cloud Service Mesh 通道由您的 GKE 集群决定 。如果您稍后更改 GKE 集群渠道,则会保留原始的 Cloud Service Mesh 渠道。
下表显示了当前渠道到 Cloud Service Mesh 版本的映射:
渠道 | Cloud Service Mesh 版本 |
---|---|
快速 | 1.19 |
常规 | 1.19 |
稳定版 | 1.19 |
默认频道
在新安装的 Cloud Service Mesh(集群中安装了一个代管式渠道)中,该渠道将是该集群的默认渠道。
如果具有现有 Istio 或 Cloud Service Mesh 安装的集群配置了默认标记,则它必须被指向代管式修订版本。否则,无需执行任何操作。
您可以使用 istio-injection=enabled
标签作为别名,该别名将注入指向您用于渠道的其他标签,例如默认修订版本。我们文档中显示为注入使用 istio.io/rev
命名空间标签的地方都可以改用 istio-injection=enabled
标签。
注入标签
要允许 Cloud Service Mesh 管理给定命名空间中的工作负载, 命名空间必须使用与已安装的渠道对应的标签进行标记。 代管式 Cloud Service Mesh 支持两种类型的标签:
- 标准修订版本标签,即
asm-managed-stable
、asm-managed
、asm-managed-rapid
,对应于渠道stable
、regular
和rapid
。 - 默认注入标签(例如
istio-injection=enabled
),对应于该集群的默认渠道。使用默认注入标签可简化修订版本之间的迁移。例如,当 迁移 从代管式 Cloud Service Mesh 迁移到托管式 Cloud Service Mesh, 可以分别为每个命名空间重新添加标签。无论 Cloud Service Mesh 文档显示什么位置 使用istio.io/rev
命名空间标签进行注入,则可使用istio-injection=enabled
标签。
注入标签的其他示例包括使用 sidecar.istio.io/inject
(通常用于网关)和 istio.io/rev
(可用于命名空间和工作负载)为工作负载添加标签。
默认注入标签
如需将默认注入标签应用于命名空间,请运行以下命令:
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
修订版本标签
与其他 Kubernetes 标签一样,修订版本标签是键值对。修订版本标签中的键始终为 istio.io/rev
,但值会有所不同。
如需选择发布渠道,请将以下修订版本名称之一应用于您的命名空间:
修订版本名称 | 渠道 |
---|---|
asm-managed |
普通 |
asm-managed-rapid |
快速 |
asm-managed-stable |
稳定版 |
例如,如需将常规发布渠道应用于命名空间:
kubectl label namespace NAMESPACE istio.io/rev=asm-managed --overwrite
我们建议您使用集群所用的发布渠道。
如需查看命名空间正在使用的发布渠道,请执行以下操作:
kubectl get namespace NAMESPACE -o jsonpath='{.metadata.labels.istio\.io/rev}{"\n"}'
更新非代管式代理
每次发布 Cloud Service Mesh 版本后,请重启您的 服务和网关虽然使用 Service 网格的 控制平面和代理的版本不同,我们建议您 更新代理,以便为其配置新的 Cloud Service Mesh 版本。
检查控制层面和代理版本。
如果控制层面版本比代理版本更新,请为您的服务和网关重启非代管式代理。
kubectl rollout restart deployment -n NAMESPACE