Amazon EKS 升级测验
本测验用于检验你对 Amazon EKS cluster（集群）升级流程、最佳实践、故障排查以及相关注意事项的理解。
测验概览
- EKS cluster 升级规划
- control plane（控制平面）升级
- node group（节点组）升级
- add-on（附加组件）和组件升级
- 升级测试与验证
- 升级故障排查
选择题
1. 规划 Amazon EKS cluster 升级时，最重要的第一步是什么？
A. 立即执行 control plane 升级 B. 一次性升级所有 workload（工作负载） C. 审查升级兼容性并制定测试计划 D. 同时升级所有 node group
显示答案
答案：C. 审查升级兼容性并制定测试计划
说明： 规划 Amazon EKS cluster 升级时，最重要的第一步是审查升级兼容性并制定测试计划。此步骤有助于识别升级过程中可能出现的问题，最大限度减少 workload 中断，并为成功升级奠定基础。
升级兼容性审查和测试规划的关键组成部分：
版本兼容性审查：
- 检查 Kubernetes 版本之间的 API 变更
- 审查正在使用的 API 版本和功能的支持状态
- 识别已弃用或已移除的 API
workload 兼容性评估：
- 审查应用程序 manifest 中的 API 版本
- 验证正在使用的 controller 和 operator 的兼容性
- 审查 Custom Resource Definition (CRD) 和 webhook 兼容性
add-on 和工具兼容性验证：
- CNI、CoreDNS、kube-proxy 版本兼容性
- Ingress controller、service mesh 兼容性
- 监控、日志记录、备份工具兼容性
测试计划制定：
- 在非生产环境中进行升级测试
- 关键 workload 功能测试计划
- 回滚程序和标准定义
实施方法：
审查升级路径和兼容性：
bash# Check current EKS cluster version aws eks describe-cluster --name my-cluster --query "cluster.version" # Check available EKS versions aws eks describe-addon-versions --kubernetes-version 1.28 # Check deprecated API usage kubectl get --raw /metrics | grep "deprecated_api_requests_total" # Review API versions in use kubectl get deployment,statefulset,daemonset,cronjob,job -A -o json | jq '.items[].apiVersion' | sort | uniq使用 workload 兼容性检查工具：
bash# Check deprecated API versions using pluto pluto detect-helm --output wide pluto detect-kubectl --output wide # Use kube-no-trouble kubectl-no-trouble创建测试 cluster 并测试升级：
bash# Create test cluster eksctl create cluster \ --name test-upgrade \ --version 1.27 \ --region us-west-2 \ --nodegroup-name standard-workers \ --node-type m5.large \ --nodes 2 # Upgrade test cluster eksctl upgrade cluster \ --name test-upgrade \ --version 1.28 \ --approve创建升级计划文档：
markdown# EKS Cluster Upgrade Plan ## Current State - Cluster version: 1.27 - Node groups: 3 (system: 1.27, app: 1.27, batch: 1.27) - Key add-ons: AWS VPC CNI 1.12.0, CoreDNS 1.8.7, kube-proxy 1.27.1 ## Target State - Cluster version: 1.28 - Node groups: 3 (system: 1.28, app: 1.28, batch: 1.28) - Key add-ons: AWS VPC CNI 1.13.0, CoreDNS 1.9.3, kube-proxy 1.28.1 ## Compatibility Review Results - Deprecated APIs: batch/v1beta1 CronJob -> batch/v1 CronJob - Add-on compatibility: All compatible - Custom resources: No updates needed ## Upgrade Steps 1. Upgrade and test non-production environment 2. Upgrade control plane 3. Upgrade add-ons 4. Sequentially upgrade node groups 5. Validation and monitoring ## Rollback Plan - Rollback criteria: Critical workload failure - Rollback procedure: Create new node group (previous version), migrate workloads
升级兼容性审查的关键领域：
API 变更：
- Kubernetes 1.22：移除了许多 beta API
- Kubernetes 1.25：移除了 PodSecurityPolicy
- Kubernetes 1.26：移除了 HorizontalPodAutoscaler v2beta2
- Kubernetes 1.27：FlowSchema 和 PriorityLevelConfiguration API 变更
- Kubernetes 1.28：移除并更改了一些 beta API
Node 组件兼容性：
- kubelet 版本最多可比 control plane 落后 2 个次要版本
- 建议 kube-proxy 与 control plane 版本一致
- 验证 container runtime 兼容性
add-on 兼容性：
- CNI plugin 版本兼容性
- CoreDNS 版本兼容性
- Ingress controller、service mesh 兼容性
其他选项的问题：
- A. 立即执行 control plane 升级：未进行兼容性审查和测试就升级，可能导致意外问题，并带来较高的 workload 中断风险。
- B. 一次性升级所有 workload：这是一种有风险的方法；如果出现问题，可能影响整个系统。分阶段方法更安全。
- D. 同时升级所有 node group：同时升级所有 node 会带来中断所有 workload 的风险，并且在出现问题时使回滚变得困难。
2. 升级 Amazon EKS cluster 的 control plane 时，正确的方法是什么？
A. 先升级 node group，然后升级 control plane B. 先升级 control plane，然后升级 node group C. 同时升级 control plane 和 node group D. 创建新 cluster 并迁移 workload，而不进行升级
显示答案
答案：B. 先升级 control plane，然后升级 node group
说明： 升级 Amazon EKS cluster 的 control plane 时，正确的方法是先升级 control plane，然后升级 node group。此方法遵循 Kubernetes 版本兼容性模型，并最大限度减少升级过程中可能出现的问题。
先升级 control plane 的原因：
Kubernetes 版本兼容性模型：
- control plane 最多可比 node 领先 2 个次要版本
- node 不能领先于 control plane
- 此模型确保向后兼容性
API Server 兼容性：
- 新版本 API server 可以与旧版本 kubelet 通信
- 相反，新版本 kubelet 可能与旧版本 API server 存在兼容性问题
支持渐进式升级：
- control plane 升级后，可以逐步升级 node group
- 限制影响范围，并在出现问题时便于回滚
实施方法：
control plane 升级：
bash# Control plane upgrade using AWS CLI aws eks update-cluster-version \ --name my-cluster \ --kubernetes-version 1.28 # Check upgrade status aws eks describe-update \ --name my-cluster \ --update-id <update-id>bash# Control plane upgrade using eksctl eksctl upgrade cluster \ --name my-cluster \ --version 1.28 \ --approve验证 control plane 升级完成：
bash# Check cluster version aws eks describe-cluster \ --name my-cluster \ --query "cluster.version" \ --output text # Check cluster status kubectl get componentstatuses kubectl get nodes准备 node group 升级：
bash# Check current node groups aws eks list-nodegroups \ --cluster-name my-cluster # Check node group version aws eks describe-nodegroup \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --query "nodegroup.version" \ --output text
control plane 升级流程：
升级前准备：
- 验证 cluster 状态
- 执行备份
- 验证关键 workload
启动升级：
- 使用 AWS Management Console、AWS CLI 或 eksctl
- 监控升级进度
升级期间监控：
- control plane endpoint 可用性
- 系统 workload 状态
- 日志和事件监控
升级后验证：
- 验证 control plane 组件状态
- 测试 API server 功能
- 确认系统 workload 正常运行
control plane 升级注意事项：
升级时间：
- 通常需要 20-30 分钟
- 会因 cluster 规模和复杂度而异
- 建议在维护窗口期间执行
升级期间的 API Server 可用性：
- 升级期间可能出现临时 API server 中断
- 现有 workload 会继续运行
- 新 Deployment 和配置更改可能会延迟
升级失败响应：
- 联系 AWS support team
- 收集 cluster 状态和日志
- 执行替代计划
最佳实践：
升级前验证 cluster 状态：
bash# Check cluster status kubectl get nodes kubectl get pods --all-namespaces kubectl get componentstatuses # Check events kubectl get events --all-namespaces --sort-by='.lastTimestamp' # Check resource usage kubectl top nodes kubectl top pods --all-namespaces升级前备份 etcd：
bash# etcd backup (for self-managed clusters) ETCDCTL_API=3 etcdctl snapshot save snapshot.db # For EKS, backup key resources kubectl get all --all-namespaces -o yaml > all-resources.yaml规划渐进式 node group 升级：
bash# Node group upgrade plan # 1. Start with less critical node groups # 2. Upgrade one node group at a time # 3. Validate after each node group upgrade升级后验证系统组件：
bash# Check system pod status kubectl get pods -n kube-system # Check CoreDNS status kubectl get pods -n kube-system -l k8s-app=kube-dns # Check CNI plugin status kubectl get pods -n kube-system -l k8s-app=aws-node
其他选项的问题：
- A. 先升级 node group，然后升级 control plane：这违反了 Kubernetes 版本兼容性模型，kubelet 版本领先于 API server 版本可能导致兼容性问题。
- C. 同时升级 control plane 和 node group：同时升级风险较高；如果出现问题，可能影响整个 cluster。也难以进行渐进式验证。
- D. 创建新 cluster 并迁移 workload，而不进行升级：这种方法可行，但存在资源重复、迁移流程复杂以及额外成本等问题，因此不建议用于典型升级。
3. 升级 Amazon EKS node group 的最安全且最有效的方法是什么？
A. 同时终止所有 node，并替换为新版本 B. 使用 managed node group 升级或 blue/green deployment 策略 C. 仅升级 control plane，不升级 node group D. 在每个 node 上手动升级 kubelet 版本
显示答案
答案：B. 使用 managed node group 升级或 blue/green deployment 策略
说明： 升级 Amazon EKS node group 的最安全且最有效的方法是使用 managed node group 升级功能，或实施 blue/green deployment 策略。这些方法可以在最大限度减少 workload 中断的同时安全地升级 node。
managed node group 升级和 blue/green deployment 的主要优势：
managed node group 升级：
- AWS 托管的 rolling upgrade 流程
- 遵守 Pod Disruption Budgets (PDB)
- 自动 drain 和 cordon
- 升级失败时自动回滚
blue/green deployment 策略：
- 创建新版本 node group
- 渐进式 workload 迁移
- 验证后移除旧 node group
- 出现问题时可快速回滚
实施方法：
managed node group 升级：
bash# Managed node group upgrade using AWS CLI aws eks update-nodegroup-version \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --kubernetes-version 1.28 # Check upgrade status aws eks describe-update \ --name my-cluster \ --nodegroup-name my-nodegroup \ --update-id <update-id>bash# Managed node group upgrade using eksctl eksctl upgrade nodegroup \ --cluster my-cluster \ --name my-nodegroup \ --kubernetes-version 1.28blue/green deployment 策略：
bash# Create new node group eksctl create nodegroup \ --cluster my-cluster \ --name my-nodegroup-v2 \ --node-type m5.large \ --nodes 3 \ --nodes-min 3 \ --nodes-max 6 \ --node-labels "kubernetes.io/role=worker,environment=production,version=v2" \ --node-ami auto \ --kubernetes-version 1.28 # Workload migration (using node affinity) kubectl apply -f - <<EOF apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 template: spec: affinity: nodeAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 preference: matchExpressions: - key: version operator: In values: - v2 EOF # Remove old node group eksctl delete nodegroup \ --cluster my-cluster \ --name my-nodegroup-v1
node group 升级流程：
managed node group 升级流程：
- 设置最大不可用 node 数
- 创建新 node 并加入 cluster
- drain 并终止现有 node
- 重复直到所有 node 都完成升级
blue/green deployment 流程：
- 创建新版本 node group
- 将测试 workload 部署到新 node group
- 逐步迁移 workload
- 所有 workload 迁移后移除旧 node group
node group 升级注意事项：
配置 Pod Disruption Budget (PDB)：
yamlapiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: app-pdb spec: minAvailable: 2 # or maxUnavailable: 1 selector: matchLabels: app: my-app设置 Node Affinity 和 Anti-affinity：
yamlapiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: template: spec: affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - my-app topologyKey: "kubernetes.io/hostname"利用 Taints 和 Tolerations：
yaml# Apply taint to new node group eksctl create nodegroup \ --cluster my-cluster \ --name my-nodegroup-v2 \ --node-labels "version=v2" \ --taints "upgrade=v2:NoSchedule" \ --kubernetes-version 1.28 # Apply toleration to specific workloads apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: template: spec: tolerations: - key: "upgrade" operator: "Equal" value: "v2" effect: "NoSchedule"
最佳实践：
升级前准备：
bash# Check node status kubectl get nodes # Check pod distribution kubectl get pods -o wide --all-namespaces # Check resource usage kubectl top nodes kubectl top pods --all-namespaces渐进式升级：
- 一次升级一个 node group
- 从不太关键的 workload 开始
- 每一步后进行验证
升级期间增强监控：
- 监控 node 状态
- 监控 pod 事件
- 监控应用程序性能和可用性
制定回滚计划：
- 定义明确的回滚标准
- 记录回滚程序
- 为快速回滚做好准备
其他选项的问题：
- A. 同时终止所有 node，并替换为新版本：此方法会同时中断所有 workload，严重影响 Service 可用性。
- C. 仅升级 control plane，不升级 node group：不升级 node group 会阻止充分利用新的 Kubernetes 功能，并且随着版本差异增大，可能出现兼容性问题。
- D. 在每个 node 上手动升级 kubelet 版本：此方法不建议用于 EKS managed node，出错可能性高，并且难以保持一致性。
4. Amazon EKS cluster 升级期间进行 add-on 管理的正确方法是什么？
A. 忽略 add-on 升级 B. 在 control plane 升级前升级所有 add-on C. 在 control plane 升级后，将 add-on 升级到兼容版本 D. 移除所有 add-on 并重新安装
显示答案
答案：C. 在 control plane 升级后，将 add-on 升级到兼容版本
说明： Amazon EKS cluster 升级期间进行 add-on 管理的正确方法是在 control plane 升级后，将 add-on 升级到兼容版本。此方法可确保 Kubernetes 版本与 add-on 之间的兼容性，最大限度减少升级过程中可能出现的问题。
在 control plane 之后升级 add-on 的主要优势：
版本兼容性保证：
- 为每个 Kubernetes 版本选择兼容的 add-on 版本
- 防止 control plane API 与 add-on 之间出现兼容性问题
- 提供稳定的升级路径
支持分阶段升级：
- 验证 control plane 升级后再升级 add-on
- 出现问题时易于隔离原因
- 支持逐步验证
利用 EKS Managed Add-ons：
- AWS 托管的 add-on 生命周期
- 提供已验证的兼容版本
- 自动安全补丁和更新
实施方法：
升级 EKS Managed Add-ons：
bash# Check available add-on versions aws eks describe-addon-versions \ --addon-name vpc-cni \ --kubernetes-version 1.28 # Upgrade add-on aws eks update-addon \ --cluster-name my-cluster \ --addon-name vpc-cni \ --addon-version v1.13.0-eksbuild.1 \ --resolve-conflicts PRESERVE升级关键 EKS add-on：
bash# Upgrade VPC CNI aws eks update-addon \ --cluster-name my-cluster \ --addon-name vpc-cni \ --addon-version v1.13.0-eksbuild.1 # Upgrade CoreDNS aws eks update-addon \ --cluster-name my-cluster \ --addon-name coredns \ --addon-version v1.9.3-eksbuild.3 # Upgrade kube-proxy aws eks update-addon \ --cluster-name my-cluster \ --addon-name kube-proxy \ --addon-version v1.28.1-eksbuild.1升级 self-managed add-on：
bash# Upgrade add-ons using Helm helm repo update helm upgrade --install metrics-server metrics-server/metrics-server \ --namespace kube-system \ --version 3.8.2 \ --set apiService.create=true
关键 EKS add-on 及兼容性：
Amazon VPC CNI：
- 网络接口管理
- Pod IP 分配
- 版本兼容性很重要
CoreDNS：
- cluster 内 DNS Service
- Service discovery
- 每个 Kubernetes 版本都有推荐版本
kube-proxy：
- 网络代理
- Service IP 路由
- 建议与 control plane 版本一致
其他常见 add-on：
- Cluster Autoscaler
- Metrics Server
- AWS Load Balancer Controller
- External DNS
add-on 升级注意事项：
冲突解决策略：
- OVERWRITE：覆盖现有设置
- PRESERVE：保留现有自定义设置
- NONE：发生冲突时升级失败
升级顺序：
- 根据重要性和依赖关系确定顺序
- 通常为 CNI -> CoreDNS -> kube-proxy -> 其他 add-on
升级验证：
- 每次 add-on 升级后验证功能
- 监控日志和事件
- 验证对 workload 的影响
最佳实践：
验证 add-on 版本兼容性：
bash# Check compatible add-on versions for each Kubernetes version aws eks describe-addon-versions \ --kubernetes-version 1.28 \ --query "addons[].{Name:addonName,LatestVersion:addonVersions[0].addonVersion}"升级前验证 add-on 状态：
bash# Check current add-on status aws eks describe-addon \ --cluster-name my-cluster \ --addon-name vpc-cni # Check add-on pod status kubectl get pods -n kube-system -l k8s-app=aws-node分阶段 add-on 升级：
- 一次升级一个 add-on
- 每次升级后进行验证
- 为出现问题时的回滚做好准备
备份自定义设置：
bash# Backup add-on configuration kubectl get configmap aws-node -n kube-system -o yaml > vpc-cni-configmap-backup.yaml
其他选项的问题：
- A. 忽略 add-on 升级：不升级 add-on 可能导致与 Kubernetes 版本的兼容性问题，也不会应用安全补丁或 bug fix。
- B. 在 control plane 升级前升级所有 add-on：在 control plane 升级前升级 add-on，可能导致新版本 add-on 与旧版本 control plane 不兼容。
- D. 移除所有 add-on 并重新安装：此方法不必要地复杂且有风险，add-on 配置和设置可能会丢失。
5. 对 Amazon EKS cluster 升级期间可能出现的问题进行故障排查时，最有效的方法是什么？
A. 立即创建新 cluster B. 发生问题时只依赖 AWS support team C. 使用系统化故障排查方法和日志分析 D. 忽略升级问题
显示答案
答案：C. 使用系统化故障排查方法和日志分析
说明： 对 Amazon EKS cluster 升级期间可能出现的问题进行故障排查时，最有效的方法是使用系统化故障排查方法和日志分析。此方法有助于识别根本原因、应用适当解决方案，并防止类似问题再次发生。
系统化故障排查方法的关键组成部分：
问题识别和定义：
- 识别症状和影响范围
- 确认问题发生的时间和条件
- 识别与正常运行的差异
信息收集和分析：
- 收集日志和事件
- 验证资源状态和配置
- 分析错误消息和模式
假设形成和验证：
- 识别可能原因
- 测试并验证假设
- 确认根本原因
解决方案实施和验证：
- 应用适当的解决方案
- 验证解决方案有效性
- 采取措施防止复发
实施方法：
升级问题诊断：
bash# Check cluster status aws eks describe-cluster \ --name my-cluster \ --query "cluster.status" # Check upgrade status aws eks describe-update \ --name my-cluster \ --update-id <update-id> # Check control plane logs aws eks update-cluster-config \ --name my-cluster \ --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' # Check logs in CloudWatch Logs aws logs filter-log-events \ --log-group-name /aws/eks/my-cluster/cluster \ --filter-pattern "Error"node group 问题诊断：
bash# Check node group status aws eks describe-nodegroup \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup # Check node status kubectl get nodes kubectl describe node <node-name> # Check node logs kubectl logs -n kube-system <node-agent-pod>add-on 问题诊断：
bash# Check add-on status aws eks describe-addon \ --cluster-name my-cluster \ --addon-name vpc-cni # Check add-on pod status kubectl get pods -n kube-system -l k8s-app=aws-node kubectl describe pod -n kube-system <addon-pod-name> kubectl logs -n kube-system <addon-pod-name>
常见升级问题和解决方案：
control plane 升级失败：
- 症状：升级状态显示 “Failed”
- 原因：API server 配置问题、资源约束、网络问题
- 解决方案：
- 检查升级错误消息
- 联系 AWS support team
- 提供 cluster 状态和日志
node group 升级失败：
- 症状：node 未变为 Ready，Pod 调度失败
- 原因：Instance 启动问题、kubelet 配置错误、CNI 问题
- 解决方案：
- 检查 node 日志
- 验证 Instance 状态
- 验证 security group 和 IAM 权限
add-on 升级问题：
- 症状：add-on Pod 处于 CrashLoopBackOff 或 Error 状态
- 原因：版本兼容性问题、配置冲突、资源约束
- 解决方案：
- 检查 Pod 日志
- 解决配置冲突
- 使用兼容版本重试
workload 兼容性问题：
- 症状：应用程序 Pod 启动失败、API 错误
- 原因：使用已弃用的 API、不兼容的功能
- 解决方案：
- 更新 manifest
- 检查应用程序日志
- 解决兼容性问题
最佳实践：
收集用于故障排查的日志：
bash# Collect cluster information kubectl cluster-info dump > cluster-info.txt # Collect node information kubectl describe nodes > nodes-info.txt # Collect system pod logs kubectl logs -n kube-system -l k8s-app=aws-node > vpc-cni-logs.txt kubectl logs -n kube-system -l k8s-app=kube-dns > coredns-logs.txt kubectl logs -n kube-system -l k8s-app=kube-proxy > kube-proxy-logs.txt # Collect events kubectl get events --all-namespaces --sort-by='.lastTimestamp' > events.txt准备回滚程序：
bash# Node group rollback (create new node group) eksctl create nodegroup \ --cluster my-cluster \ --name rollback-nodegroup \ --node-type m5.large \ --nodes 3 \ --nodes-min 3 \ --nodes-max 6 \ --node-ami auto \ --kubernetes-version 1.27 # previous version # Workload migration kubectl cordon -l eks.amazonaws.com/nodegroup=problematic-nodegroup kubectl drain --ignore-daemonsets --delete-emptydir-data -l eks.amazonaws.com/nodegroup=problematic-nodegroup记录故障排查过程：
markdown# Upgrade Troubleshooting Report ## Problem Description - Symptom: CoreDNS pods in CrashLoopBackOff state after node group upgrade - Impact: Service discovery failure, application connection issues - Occurrence time: 2023-07-15 14:30 UTC, immediately after node group upgrade ## Investigation Process 1. Check CoreDNS pod status 2. Analyze CoreDNS logs 3. Verify node status and resources 4. Review network policies ## Findings - Configuration error found in CoreDNS pod logs - CoreDNS ConfigMap incorrectly modified during upgrade ## Resolution 1. Restore CoreDNS ConfigMap 2. Restart CoreDNS pods 3. Verify service connectivity ## Preventive Measures 1. Backup critical configurations before upgrade 2. Implement automated validation tests 3. Improve phased upgrade process与 AWS support team 有效协作：
- 提供清晰的问题描述
- 共享相关日志和错误消息
- 说明已执行的故障排查步骤
其他选项的问题：
- A. 立即创建新 cluster：这是一种极端方法，会消耗大量时间和资源，却无法解决根本原因。
- B. 发生问题时只依赖 AWS support team：AWS support team 是重要资源，但先执行基本故障排查步骤可以缩短解决时间。
- D. 忽略升级问题：忽略升级问题可能对 cluster 稳定性、安全性和性能产生长期影响。
6. Amazon EKS cluster 升级后进行验证的最全面方法是什么？
A. 只验证 node 数量 B. 只验证 cluster 版本 C. 执行多阶段验证，包括系统组件、workload 功能和性能指标 D. 升级后不验证，立即在生产环境中使用
显示答案
答案：C. 执行多阶段验证，包括系统组件、workload 功能和性能指标
说明： Amazon EKS cluster 升级后进行验证的最全面方法是执行多阶段验证，包括系统组件、workload 功能和性能指标。此方法有助于验证升级已成功完成，并且 cluster 正按预期运行。
多阶段验证的关键组成部分：
系统组件验证：
- control plane 组件状态
- node 状态和版本
- 系统 Pod 和 add-on 状态
workload 功能验证：
- 应用程序 Deployment 和扩缩容
- Service 连接和路由
- Storage 和 volume 功能
性能指标验证：
- 资源使用率和效率
- 延迟和吞吐量
- 错误率和可用性
实施方法：
系统组件验证：
bash# Check cluster version aws eks describe-cluster \ --name my-cluster \ --query "cluster.version" \ --output text # Check control plane component status kubectl get componentstatuses # Check node status and versions kubectl get nodes -o wide # Check system pod status kubectl get pods -n kube-systemworkload 功能验证：
bash# Create test deployment kubectl create deployment nginx-test --image=nginx # Scale deployment kubectl scale deployment nginx-test --replicas=3 # Create service and test connectivity kubectl expose deployment nginx-test --port=80 --type=ClusterIP kubectl run -it --rm --restart=Never busybox --image=busybox -- wget -O- nginx-test # Test volume functionality kubectl apply -f - <<EOF apiVersion: v1 kind: PersistentVolumeClaim metadata: name: test-pvc spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi EOF kubectl apply -f - <<EOF apiVersion: v1 kind: Pod metadata: name: volume-test spec: containers: - name: volume-test image: busybox command: ["sh", "-c", "echo 'test' > /data/test.txt && sleep 3600"] volumeMounts: - name: data mountPath: /data volumes: - name: data persistentVolumeClaim: claimName: test-pvc EOF性能指标验证：
bash# Check node resource usage kubectl top nodes # Check pod resource usage kubectl top pods --all-namespaces # Perform load test kubectl run -it --rm --restart=Never loadtest --image=busybox -- sh -c "while true; do wget -q -O- http://nginx-test; done"
验证领域和清单：
control plane 验证：
- API server 响应能力
- etcd 状态和性能
- Controller manager 和 scheduler 功能
Data Plane 验证：
- node 状态和可用性
- kubelet 功能
- Container runtime 状态
Networking 验证：
- Pod-to-pod 通信
- Service discovery
- Ingress 和 egress traffic
Storage 验证：
- volume provisioning
- 数据持久性
- Storage class 功能
Security 验证：
- Authentication 和 authorization
- Network policies
- Encryption 和 security contexts
最佳实践：
分阶段验证方法：
bash# Phase 1: System component validation ./validate-system-components.sh # Phase 2: Basic workload functionality validation ./validate-basic-workloads.sh # Phase 3: Advanced feature validation ./validate-advanced-features.sh # Phase 4: Performance and load testing ./validate-performance.sh自动化验证测试：
yaml# Validation job definition apiVersion: batch/v1 kind: Job metadata: name: cluster-validation spec: template: spec: containers: - name: validation image: validation-tools:latest command: ["/scripts/validate-cluster.sh"] restartPolicy: Never记录验证结果：
bash# Collect validation results kubectl get nodes -o wide > validation-results/nodes.txt kubectl get pods --all-namespaces > validation-results/pods.txt kubectl get events --all-namespaces --sort-by='.lastTimestamp' > validation-results/events.txt # Collect performance metrics kubectl top nodes > validation-results/node-metrics.txt kubectl top pods --all-namespaces > validation-results/pod-metrics.txt逐步切换生产流量：
- 使用 canary deployment
- 逐步增加流量
- 监控指标并检测异常
其他选项的问题：
- A. 只验证 node 数量：node 数量验证是基础验证，但可能遗漏 node 状态、系统组件和 workload 功能等重要方面。
- B. 只验证 cluster 版本：cluster 版本验证有助于确认升级完成，但缺少功能验证。
- D. 升级后不验证，立即在生产环境中使用：不验证就用于生产环境存在风险，潜在问题可能影响用户。