ae有么有做gif的网站一流的山西网站建设
升级 Azure Kubernetes 服务 (AKS) 集群不仅是为了保持最新状态，更是为了保护您的工作负载、提升性能并降低运营风险。但如果操作不当，可能会导致停机、工作负载中断，甚至访问问题。
在本指南中，我们将介绍：
- 生产环境安全的 AKS 升级策略
- 如何处理身份验证和授权 (RBAC)
- 防止中断的最佳实践
- 与实际 DevOps 和 CKA 准备相关的技巧
升级 AKS 前的关键注意事项
- 在点击“升级”按钮之前，请谨慎规划：
- 检查支持的版本
- AKS 仅允许升级到支持的版本（例如，1.27 → 1.28，而不是 1.27 → 1.29）。
- 与应用程序团队协调
- 避免在升级期间进行部署，并将潜在的重启情况告知您的团队。
- 查看 Kubernetes 发行说明
- 了解重大变更、已弃用的 API 和已知问题。
- 可选地规划停机时间
- 虽然 AKS 会进行滚动升级，但节点会重启。优雅的中断处理至关重要。
- 评估版本一致性
- 控制平面、节点池、kube-proxy、CoreDNS 和指标服务器都应保持一致。
- 优先在较低环境中测试
在将升级推广到生产环境之前，请务必在预发布环境中进行测试。
AKS 分步升级（Azure 门户或 CLI）
步骤 1：升级控制平面
az aks update \
--resource-group myRG \
--name myAKSCluster \
--kubernetes-version 1.28.3 \
--yes
选择下一个稳定的 Kubernetes 版本。
在此过程中监控日志、事件和 API 可用性。
步骤 2：升级节点池
对于每个节点池，请谨慎升级：
az aks nodepool update \
--resource-group myRG \
--cluster-name myAKSCluster \
--name mynodepool \
--kubernetes-version 1.28.3 \
--mode Upgrade
AKS 将：
- 封锁节点
- 优雅地清空 Pod
- 升级节点
- 取消封锁并继续到下一个节点
- 除非执行高级工作流程，否则无需手动封锁/清空。
升级后身份验证和授权 (RBAC)
AKS 使用 Azure AD 进行身份验证（如果已启用），并使用 Kubernetes RBAC 进行授权。升级后，请确认：
身份验证
确保用户仍然可以通过 Azure AD 登录：
az aks update \
--resource-group myRG \
--name myAKSCluster \
--enable-aad
如有需要，请重新同步凭据：
az aks get-credentials \
--resource-group myRG \
--name myAKSCluster --overwrite-existing
授权 (RBAC)
检查所有 RoleBinding 和 ClusterRoleBinding 是否完好无损。
kind: RoleBinding
metadata:name: view-podsnamespace: dev
subjects:
- kind: Username: "devops@company.com"
roleRef:kind: Rolename: pod-readerapiGroup: rbac.authorization.k8s.io
升级后使用 kubectl auth can-i 测试访问权限：
kubectl auth can-i list pods --as=devops@company.com -n dev
升级后：后期检查和验证
升级后：
- kubectl get nodes – 检查版本一致性
- kubectl get pods -A – 确保工作负载正在运行
- kubectl logs – 验证应用程序健康状况
- kubectl describe node – 检查 kubelet 状态和标签
同时确保以下组件：
- CoreDNS
- kube-proxy
- Metrics Server
…已更新并与新的 K8s 版本兼容。
AKS 生产环境升级最佳实践
- 先升级控制平面，再升级节点池
- 一次升级一个节点池
- 避免升级期间工作负载发生变化
- 将升级安排在工作时间以外
- 使用 PodDisruptionBudgets 避免大规模驱逐
- 升级后运行功能和负载测试
- 始终先在开发/预发布环境中进行测试
- 使用可用区，实现更安全的升级
升级演示：
我的集群设置
- 我的集群是用于演示的 1.31.7 节点集群。
- 下一个支持的主要版本是 1.32.0。
- 只有一个名为 agentpool 的节点池。
我只是向您展示一个基本的升级流程和一些简要信息。在 AKS 升级方面，有两个方面：
- 控制平面。它由 Microsoft 管理，对客户来说是一个黑匣子。
- 工作平面。它由节点池组成，每个节点池内都包含一个节点虚拟机。
节点池升级
Microsoft 大约每周为 AKS 节点创建一个新的节点映像。节点镜像包含最新的操作系统安全补丁、操作系统内核更新、Kubernetes 安全更新、kubelet 等二进制文件的更新版本以及组件版本更新。
集群升级
Kubernetes 社区大约每三个月发布一次 Kubernetes 的小版本。您可以在 https://github.com/Azure/AKS/releases 查看这些版本的列表。
集群升级可以包含节点池升级。只有当您的 Kubernetes 版本与所选版本相差 3 个或更多小版本时，才可以升级控制平面。
在我的 AKS 集群中，由于这是测试环境，我选择同时升级控制平面和节点池。
我的节点池虚拟机运行的是 Ubuntu Linux 操作系统，Kubernetes 版本为 1.31.7，如图所示。
您可以考虑只升级控制平面，以便在升级所有节点池之前进行更精细的控制测试。点击“保存”启动升级过程。升级过程可能需要几分钟甚至二十多分钟。
升级过程的一般流程是，将一个包含升级镜像的新节点部署到节点池中。AKS 会开始从正在升级的节点池中的现有节点中移除 Pod。这个过程会以优雅的方式完成，以最大限度地减少中断。Pod 会被调度到具有更新 Kubernetes 版本的新节点上。升级期间，您可以在“事件”边栏选项卡中监控进度和任何问题。
查看节点池，我们看到它处于“正在升级”状态，目标节点数从 1 个增加到 2 个，以支持具有更新版本的新节点。Kubernetes 版本为 1.32.0，表明其预期版本。
点击代理节点池，我们可以看到 2个节点。第二个节点是新的更新版本。您可以看到正在重新调度到新节点的 Pod 数量。
一段时间后，我们可以看到集群升级完成。
节点池镜像已更新
节点池中的每个节点都更新了重新调度到其中的 Pod 数量。
我们也可以在“集群配置”边栏选项卡中确认。
总结
AKS 的升级比手动 Kubernetes 集群更容易——但规划、RBAC 检查和工作负载准备工作仍然需要您自行负责。
- 计划升级
计划升级允许您提前安排 Kubernetes 版本更新，确保始终运行受支持且安全的版本。这种主动的方法意味着您可以让您的团队和应用程序做好升级准备，最大限度地减少中断，并确保分配必要的资源以实现平稳过渡。通过定期升级，您将受益于新功能、性能改进和关键的安全补丁。
- 身份验证验证
身份验证验证是确保只有授权用户和服务才能在升级过程中和升级后访问您的 AKS 集群的关键步骤。通过验证您的身份验证机制（例如 Azure Active Directory 或其他身份提供程序）是否已正确配置，您可以防止未经授权的访问和潜在的安全漏洞。务必确认不同的用户角色和权限已正确设置，以在整个升级过程中保持必要的安全态势。
- RBAC 确认
基于角色的访问控制 (RBAC) 确认涉及审查和验证 AKS 集群中与用户、组和服务帐户相关的权限。确保升级前 RBAC 设置准确且最新，意味着用户在更新后仍将拥有适当的资源访问权限。此步骤不仅有助于维护安全性，还能通过防止未经授权的更改或需要特定访问权限的工作负载中断来提高运营效率。
通过结合这些要素（计划内升级、身份验证验证和 RBAC 确认），您可以像专业人士一样升级 AKS 集群，避免意外情况并确保最大程度地减少停机时间。这种周密的准备工作使您能够在 Kubernetes 部署演进过程中为应用程序提供稳定安全的环境。