商务服饰网站建设,龙岩天宫山缆车门票多少钱,域名怎么选才正确,镇江市机关效能与作风建设网站前言
Kubernetes 社区大约每 4 个月发布次要版本#xff0c;次要版本包括新增功能和改进。补丁发布更为频繁#xff08;有时每周都会发布#xff09;#xff0c;适用于次要版本中的关键 Bug 修复。修补程序版本包括针对安全漏洞或主要 bug 的修复。对于受支持版本列表以…前言
Kubernetes 社区大约每 4 个月发布次要版本次要版本包括新增功能和改进。补丁发布更为频繁有时每周都会发布适用于次要版本中的关键 Bug 修复。修补程序版本包括针对安全漏洞或主要 bug 的修复。对于受支持版本列表以外的群集AKS 将不会在正常运行时间或其他方面做出任何保证。为了使AKS版本始终能获得支持需要制定计划将AKS升级至受支持版本。在AKS Kubernetes 发布日历https://learn.microsoft.com/zh-cn/azure/aks/supported-kubernetes-versions?tabsazure-cli#aks-kubernetes-release-calendar上参考即将推出的版本发布和弃用事项。
AKS版本升级路径说明
升级受支持的 AKS 群集时不能跳过 Kubernetes 次要版本。Kubernetes 控制平面版本倾斜策略不支持跳过次要版本。例如对于以下升级过程 1.28.x -1.29.x允许。 1.27.x -1.28.x允许。 1.27.x -1.29.x允许。
若要从 1.27.x -1.29.x 升级请执行以下操作 从 1.27.x -1.28.x 升级。 从 1.28.x -1.29.x 升级。
仅当从不受支持的版本升级回受支持的最低版本时才能跳过多个版本。例如如果 1.27 是最低受支持的次要版本可以从不受支持的 1.25.x 升级到受支持的 1.27.x。
从跳过两个或更多次要版本的不支持版本执行升级时执行升级时不保证任何功能并且不在服务级别协议和有限保修范围内。运行不受支持的版本的群集具有将控制平面升级与节点池升级分离的灵活性。但是如果版本明显过期建议重新创建群集。
AKS升级策略
从 Kubernetes 1.19 开始开源社区已将支持时间延长到 1 年。AKS 承诺启用修补程序并提供与上游承诺使用量匹配的支持。对于版本 1.19 和更高版本上的 AKS 群集每年至少升级一次以便始终使用受支持的版本。
AKS升级将会有什么影响 AKS次要版本升级将会更新弃用API如果在升级AKS前不对弃用API进行处理两个版本的AKS API不兼容会造成AKS升级失败和使用弃用API的资源部署失败。已弃用 API 的迁移指南https://kubernetes.io/zh-cn/docs/reference/using-api/deprecation-guide/。 所有pod将会重启。2024年06月06日国内关闭了docker hub镜像缓存服务在这期间pod没有重启过的在AKS升级后镜像会丢失而且无法从docker hub中拉取从而导致pod拉取镜像失败。 没有对节点池预设的labels和Taints在AKS升级后会被清除。 会对有依赖性的服务产生影响需要按照启动的先后顺序重启服务。
升级步骤
升级状态跟踪表 升级路线
例1.22.6 → 1.27.3 → 1.28.9 → 1.29.4
AKS Upgrade PreCheck 在升级前进行AKS现状检查并进行统计需要处理的邮件发送至各位Owner及时处理。 与客户及涉及到的各个应用沟通时间窗口并安排升级计划。 提前发送邮件book需要参与AKS升级的相关人员应用开发/Cloud Team/SRE Team的时间。
检查是否存在即将废弃的API 微软提供的查询语句
查询query
AzureDiagnostics
| where Category kube-audit
| where log_s has deprecated and TimeGenerated ago(1d)
| extend log parse_json(tostring(parse_json(log_s)))
| extend removed_release toreal(tostring(log.annotations[k8s.io/removed-release]))
| where removed_release 1.26 or removed_release 1.27
| extend verb tostring(log.verb)
| extend userAgent tostring(log.userAgent)
| extend username tostring(log.user.username)
| extend resource tostring(log.objectRef.resource)
| extend apiGroup tostring(log.objectRef.apiGroup)
| extend apiVersion tostring(log.objectRef.apiVersion)
| extend requestURI tostring(split(log.requestURI, ?)[0])
| extend source_ip tostring(log.sourceIPs[0])
| extend api strcat(apiGroup, /, apiVersion)
| project TimeGenerated, userAgent, username, api, resource, verb, requestURI, source_ip, Resource命令检查废弃API
例从 v1.27 版本开始不再提供 storage.k8s.io/v1beta1 API 版本的 CSIStorageCapacity。
$ kubectl get csistoragecapacities.storage.k8s.io -A -ojsonpath{$.items[?(.apiVersionstorage.k8s.io/v1beta1)].metadata.name};
注意在AKS升级前需要为所有可能的中断做好准备。 这些中断包括 API 中断性变更、弃用以及 Helm 和容器存储接口 (CSI) 等依赖项导致的中断。 预测这些中断并在不停机的情况下迁移关键工作负载可能比较困难。可以将 AKS 群集配置为自动停止包含次要版本更改和已弃用 API 的升级操作并提醒你注意此问题。 此功能有助于避免意外中断并使你有时间在继续升级之前及时解决已弃用的 API。参考发生 API 中断性变更时自动停止 Azure Kubernetes 服务 (AKS) 群集升级
检查部署源文件api version
检查部署源文件中的api version例如helm等如果存在目标版本即将要废弃的api version需要在AKS升级前计划修改在修改前注意检查是否开启资源自动同步。
检查公共Image 检查是否存在已经丢失公共镜像源的服务。 检查是否存在仍然在使用被自动清除策略删除的镜像。
附扫描namespace下所有镜像的检查命令
$ kubectl describe pod -n namespace | grep Image | awk {print $2} | grep -v ID | sort -u
检查节点亲和性
检查是否存在有节点依赖的服务。
$ kubectl get deployments.apps -A -ojsonpath{$.items[?(.spec.template.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution)].metadata.name};
$ kubectl get statefulsets.apps -A -ojsonpath{$.items[?(.spec.template.spec.affinity.deAffinity.requiredDuringSchedulingIgnoredDuringExecution)].metadata.name};
$ kubectl get deployments.apps -A -ojsonpath{$.items[?(.apiVersionapps/v1)].spec.template.spec.nodeSelector};
$ kubectl get statefulsets.apps -A -ojsonpath{$.items[?(.apiVersionapps/v1)].spec.template.spec.nodeSelector};
查看所有节点及labels并记录。
$ kubectl get node --show-labels
检查是否有污点
检查节点是否标记有污点并记录。
$ kubectl get nodes -o jsonpath{range $.items[?(.spec.taints)]}{.metadata.name} {.spec.taints}{\n}{end}
检查PDB设置
升级前备份并删除PDB系统PDB除外否则会导致AKS集群升级失败。
参考排查由于 PDB 导致的逐出失败而导致的 UpgradeFailed 错误https://learn.microsoft.com/zh-cn/troubleshoot/azure/azure-kubernetes/create-upgrade-delete/error-code-poddrainfailure
检查地址空间
升级前确认地址空间充足。
打开Azure Portal Kubernetes 服务 设置 - 节点池 选择节点池 配置 - 子网 点击子网 复制Subnet并搜索 检查服务器类型配额是否足够
查看使用的服务器类型 检查升级节点激增数 $ az aks nodepool show --name nodePool --resource-group resourceGroup --cluster-name clusterName |grep maxSurge
设置节点激增数设置AKS集群升级中同时升级的节点数一般是按照节点池总数的三分之一或二分之一设置。
# Set max surge for a new node pool
az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33%# Update max surge for an existing node pool
az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 5 检查并记录升级前所有pod状态
升级前记录所有pod状态在AKS升级完成后作为参考。
检查JDK版本
在AKS升级到1.25版本后Pod可能由于内存饱和或内存不足而停止工作。
现象 节点上的内存压力 与升级前应用的内存使用量相比增加了应用的内存使用率 节点上的 CPU 限制 由于 OOM 错误而导致 Pod 失败
在以下环境中运行的应用可能会降低性能 对于 低于版本 11.0.18 或版本 1.8.0 372 的 JRE 版本 Java 运行时环境 (JRE) () 低于版本 5.0 的 .NET 版本 Node.js
参考群集升级到 Kubernetes 1.25 后Pod 中会出现内存饱和
https://learn.microsoft.com/zh-cn/troubleshoot/azure/azure-kubernetes/create-upgrade-delete/aks-memory-saturation-after-upgrade
扫描namespace下所有pod的JDK版本
$ vim show_pods_jdk_version.sh#!/usr/bin/bashfor pod in kubectl get po -n $1 | awk {print $1} | grep -v NAMEdo echo $pod result$(kubectl exec -it -n $1 $pod -- java -version 2/dev/null) if [[ $? ! 0 ]]; then echo no_jdk else echo kubectl exec -it -n $1 $pod -- java -version 2/dev/null | grep openjdk version\|java version fidone$ bash show_pods_jdk_version.sh namespace AKS Upgrade Cut Over
Kubernetes服务 群集配置 升级版本 选择下一个次版本 保存 强制升级(可选项)
用户也可以尝试临时性的disable该检查强制让aks先完成升级。但这就意味着后续升级到新版本之后用户业务pod可能会直接无法使用新k8s版本上老旧的api已经下架
参考Stop Azure Kubernetes Service (AKS) cluster upgrades automatically on API breaking changes
https://docs.azure.cn/en-us/aks/stop-cluster-upgrade-api-breaking-changes#bypass-validation-to-ignore-api-changes $ az aks update --name myAKSCluster --resource-group myResourceGroup --enable-force-upgrade --upgrade-override-until 2023-10-01T13:00:00Z //预估的时间窗口 AKS Upgrade PostCheck
检查node labels
设置labels
$ kubectl label nodes node keyvalue
检查污点
设置污点
$ kubectl taint nodes node keyvalue:NoSchedule
检查所有pod状态
对比在PreCheck中记录的pod状态检查如有问题及时处理。
通知应用自检查
确保所有pod正常启动后检查业务系统状态更新完成CMDB并汇总业务的反馈信息做升级报告提交。
