K8s on 吾爱主机

Kubernetes 1.36.2 补丁升级实战：DRA、CSI 与控制面稳定性检查清单

Sat, 11 Jul 2026 09:03:43 +0800

Kubernetes 1.36.2 是 1.36 分支的补丁版本，官方 GitHub Release 发布于 2026-06-12。它不是一个“炫技型”的大版本，而是非常适合平台团队纳入日常升级窗口的稳定性修复版本：其中包含 Dynamic Resource Allocation（DRA）调度路径、CSI 卷重新发布、Endpoint Controller、Secret 环境变量处理以及 kubeadm 证书 dry-run 等多个容易在生产环境放大的边界问题。

本文基于 Kubernetes 官方 Release、1.36 分支 CHANGELOG 与官方版本支持说明整理，面向正在运行 1.36.x、准备从 1.35/1.34 规划升级，或正在试点 GPU、DPU、RDMA 等设备资源编排能力的团队，给出一份可执行的升级与验证清单。

为什么这个补丁版本值得关注

Kubernetes 补丁版本通常不会引入破坏性 API 变化，但它会修复控制面和节点侧的真实缺陷。1.36.2 的重点可以概括为三类：

调度正确性：DRA 相关修复覆盖设备分区、共享计数器、多 allocatable 设备以及 ResourceClaim allocationMode: All 等场景。对于使用新资源模型管理 GPU、加速卡或其他专用设备的集群，这类问题可能导致 Pod 错误分配、长时间 Pending，甚至设备冲突。
存储与节点稳定性：kubelet 在 CSI requiresRepublish=true 周期性 NodePublishVolume 失败时，曾可能删除挂载目录并让 Pod 继续看到陈旧卷内容。该类问题不一定马上表现为 CrashLoop，却可能带来数据一致性和排障难度。
控制面兼容性：Endpoint Controller 处理早期未更新过 ipFamilies 字段的 Service 时可能 panic；另外还修复了 Secret 二进制非 UTF-8 数据作为环境变量来源时的回归问题。

与此同时，官方发布说明显示 Kubernetes 1.36.2 构建使用 Go 1.26.4。对自建发行包、二次编译或维护私有镜像仓库的团队来说，这意味着需要同步确认构建链、制品校验与 SBOM 记录。

核心修复解读

1. DRA 调度：从“能调度”到“调度正确”

Dynamic Resource Allocation 是 Kubernetes 近几个版本持续增强的资源建模能力，用于表达比传统 CPU/Memory 更复杂的设备资源。1.36.2 中有多项 DRA 修复：

修复在 SharedCounters 与多 allocatable 设备组合下，调度器可能把互斥设备分区分配给多个 Pod 的问题。
修复同时使用多节点 claim 与 per-node claim 的 Pod 可能卡在 Pending 的问题。
修复 ResourceClaim 使用 allocationMode: All 且选择消耗 shared counters 的设备时，kube-scheduler 可能 panic 的问题。

如果你的集群还没有启用 DRA，这些修复可能暂时没有直接影响；但如果你在做 AI 训练、推理平台、边缘设备管理或高性能网络设备调度，建议把 1.36.2 视为 1.36 分支的最低生产基线之一。

2. CSI republish：不要忽略“陈旧卷内容”

CHANGELOG 提到，kubelet 在处理 CSIDriver.spec.requiresRepublish=true 的周期性 NodePublishVolume 调用时，如果 republish 返回错误，曾可能删除 CSI mount directory，导致 Pod 继续持有陈旧卷内容，后续成功 republish 也无法自动修复。

这类问题的危险之处在于：应用容器未必马上退出，监控也未必能通过简单的 Pod 状态发现异常。对依赖 CSI 动态刷新凭据、配置或挂载状态的系统来说，升级后应该重点观察：

kubectl get csidriver -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.requiresRepublish}{"\n"}{end}'
kubectl get events -A --field-selector involvedObject.kind=Pod | grep -i 'NodePublishVolume\|MountVolume'

如果存在 requiresRepublish=true 的驱动，建议在灰度节点上执行挂载异常注入或至少复盘历史 kubelet 日志，确认升级前是否出现过 republish 失败后应用读到旧数据的迹象。

3. Endpoint Controller 与旧 Service 兼容性

1.36.2 修复了 Endpoint Controller 在处理 ipFamilies 为空的 Service 时可能 panic 的问题。官方说明将其描述为 pre-dual-stack services that were never spec-updated，也就是双栈能力引入前创建、之后长期未触碰规格字段的老 Service。

这对老集群很重要：很多生产集群中存在“创建多年但业务仍在使用”的 Service。升级前可以先做一次巡检：

kubectl get svc -A -o json | jq -r '
 .items[] | select((.spec.ipFamilies // []) | length == 0) |
 [.metadata.namespace, .metadata.name, .spec.clusterIP] | @tsv'

如果发现命中项，先在测试环境复现或通过无害字段更新触发默认值补齐，再安排控制面升级，会比升级窗口里临时定位 controller panic 更稳妥。

4. Secret 二进制环境变量回归

官方 CHANGELOG 还提到修复了 1.34+ 中一个回归：容器环境变量值来自 Secret API 对象且包含 binary non-UTF8 data 时的处理问题。虽然“二进制 Secret 直接进环境变量”不是推荐实践，但历史系统、第三方 Chart 或迁移遗留配置中并不少见。

建议升级前用以下思路排查：

kubectl get deploy,statefulset,daemonset -A -o yaml | grep -n "secretKeyRef" -C 3

对命中的工作负载，优先确认 Secret 内容是否应改为文件挂载、是否存在非 UTF-8 值，以及应用侧是否真的需要以环境变量方式读取。升级补丁可以修复回归，但配置治理仍应同步推进。

升级前检查清单

确认版本与支持窗口

Kubernetes 官方 Releases 页面说明，项目维护最近三个 minor release 分支；当前页面描述为 1.36、1.35、1.34。Kubernetes 1.19 及之后版本大约提供 1 年补丁支持。因此，1.36.2 对 1.36 用户是常规补丁升级，对更老分支则应结合版本偏斜策略规划跨 minor 升级。

kubectl version --short
kubectl get nodes -o wide
kubectl get --raw /version

如果控制面、kubelet、kubectl 或外部组件版本跨度较大，先阅读官方 version skew policy，再决定是否直接升级到 1.36.x。

备份 etcd 与关键配置

补丁升级也要按生产变更对待，至少完成：

ETCDCTL_API=3 etcdctl snapshot save /backup/etcd-$(date +%F-%H%M).db \
 --endpoints=https://127.0.0.1:2379 \
 --cacert=/etc/kubernetes/pki/etcd/ca.crt \
 --cert=/etc/kubernetes/pki/etcd/server.crt \
 --key=/etc/kubernetes/pki/etcd/server.key

kubectl get all,cm,secret,ingress,pvc -A -o yaml > /backup/k8s-resources-$(date +%F).yaml

托管 Kubernetes 也应在云厂商控制台确认升级回滚策略、节点池灰度能力与控制面维护窗口。

先升级测试集群或单个节点池

推荐顺序：

在测试集群升级控制面到 1.36.2。
升级一组低风险节点池。
验证 DRA、CSI、Service、Job、Secret 相关用例。
扩大到生产控制面与生产节点池。

对 kubeadm 集群，还应关注 1.36.2 修复的 kubeadm init phase certs --dry-run 复制现有 CA 文件问题。如果你的自动化流程依赖 dry-run 生成或校验证书，应在升级后重新跑一遍流水线。

升级后验证清单

升级完成后，不要只看 kubectl get nodes。建议至少执行：

kubectl get componentstatuses 2>/dev/null || true
kubectl get --raw='/readyz?verbose'
kubectl get pods -A --field-selector=status.phase!=Running,status.phase!=Succeeded
kubectl get events -A --sort-by=.lastTimestamp | tail -n 80
kubectl -n kube-system logs -l component=kube-scheduler --tail=200

重点观察：

kube-scheduler 是否仍出现 DRA ResourceClaim 相关 panic 或调度失败。
CSI 插件与 kubelet 日志中是否还有 NodePublishVolume 反复失败。
老 Service 是否触发 Endpoint/EndpointSlice 控制器异常。
使用 Secret 环境变量的 Pod 是否能正常启动。
suspended Job 修改 nodeSelector、tolerations、node affinity 等 scheduling directives 是否符合预期。

实践建议

未使用 DRA 的普通集群：可以按常规补丁窗口升级，但仍需完成 etcd 备份、控制面健康检查与节点池灰度。
使用 DRA 或设备插件的集群：建议优先升级测试环境，并围绕 ResourceClaim、共享计数器、多 allocatable 设备构造回归用例。
CSI 驱动复杂的集群：重点确认 requiresRepublish=true 驱动，升级后观察挂载内容刷新是否正常。
历史包袱较重的老集群：先巡检空 ipFamilies Service、Secret 环境变量与长期未更新的 workload spec，避免把老问题带进升级窗口。

总结

Kubernetes 1.36.2 的价值不在于新功能数量，而在于把 1.36 分支中几个高风险边界问题向前修掉：DRA 调度正确性、CSI republish 行为、Endpoint Controller 兼容性、Secret 二进制数据回归以及 kubeadm dry-run 证书流程。对于平台团队来说，最稳妥的做法是把它纳入一次小而完整的补丁升级：先备份，再灰度，最后用针对性清单验证关键路径。

如果你的集群已经在 1.36.x，建议优先评估 1.36.2；如果仍在 1.35/1.34，则应结合官方版本支持与版本偏斜策略制定 minor 升级计划，而不是只追补丁号。

参考资料

Kubernetes GitHub Release：https://github.com/kubernetes/kubernetes/releases/tag/v1.36.2
Kubernetes 1.36 CHANGELOG：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.36.md
Kubernetes 官方 Releases 与支持分支说明：https://kubernetes.io/releases/

Kubernetes (K8s) 完全指南：架构、核心概念与实战命令

Thu, 25 Jun 2026 16:30:00 +0000

前言

Kubernetes（简称 K8s）是 Google 开源的容器编排平台，已成为云原生领域的事实标准。当前最新版本为 v1.36（2026 年发布）。它能自动化容器化应用的部署、扩缩容和管理。无论是微服务架构、CI/CD 流水线，还是混合云部署，K8s 都是核心基础设施。

1. 架构概述

1.1 整体架构

┌─────────────────────────────────────────────────────┐
│ Control Plane │
│ ┌──────────┐ ┌──────────┐ ┌────────┐ ┌──────────┐ │
│ │ API │ │Scheduler │ │Controller│ │ etcd │ │
│ │ Server │ │ │ │ Manager │ │ │ │
│ └──────────┘ └──────────┘ └────────┘ └──────────┘ │
└─────────────────────────────────────────────────────┘
 │
 ┌───────────┼───────────┐
 ▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Worker 1 │ │ Worker 2 │ │ Worker 3 │
│ ┌──────────┐ │ │ ┌──────────┐ │ │ ┌──────────┐ │
│ │ kubelet │ │ │ │ kubelet │ │ │ │ kubelet │ │
│ ├──────────┤ │ │ ├──────────┤ │ │ ├──────────┤ │
│ │kube-proxy│ │ │ │kube-proxy│ │ │ │kube-proxy│ │
│ ├──────────┤ │ │ ├──────────┤ │ │ ├──────────┤ │
│ │Container │ │ │ │Container │ │ │ │Container │ │
│ │ Runtime │ │ │ │ Runtime │ │ │ │ Runtime │ │
│ └──────────┘ │ │ └──────────┘ │ │ └──────────┘ │
└──────────────┘ └──────────────┘ └──────────────┘

1.2 Control Plane 组件

组件	作用
API Server	集群的统一入口，所有操作通过 REST API 进行
etcd	分布式键值存储，保存集群的所有状态数据
Scheduler	监听未调度的 Pod，根据资源/亲和性等分配到合适的节点
Controller Manager	运行各种控制器（Deployment、ReplicaSet、Node 等），确保实际状态与期望状态一致

1.3 Worker Node 组件

组件	作用
kubelet	每个节点上的代理，管理 Pod 生命周期，汇报节点状态
kube-proxy	网络代理，实现 Service 的负载均衡和网络规则
Container Runtime	容器运行时（containerd、CRI-O 等）

2. 核心概念

2.1 Pod

Pod 是 K8s 最小的部署单元，包含一个或多个容器。

# pod.yaml
apiVersion: v1
kind: Pod
metadata:
 name: my-pod
 labels:
 app: myapp
 version: v1
spec:
 containers:
 - name: nginx
 image: nginx:1.25
 ports:
 - containerPort: 80
 resources:
 requests:
 cpu: "100m"
 memory: "128Mi"
 limits:
 cpu: "500m"
 memory: "256Mi"
 livenessProbe:
 httpGet:
 path: /healthz
 port: 80
 initialDelaySeconds: 10
 periodSeconds: 5
 readinessProbe:
 httpGet:
 path: /ready
 port: 80
 initialDelaySeconds: 5
 periodSeconds: 3
 - name: sidecar
 image: busybox
 command: ["sh", "-c", "while true; do echo hello; sleep 10; done"]

2.2 Deployment

Deployment 管理 ReplicaSet，实现应用的声明式更新。

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: myapp
 namespace: default
spec:
 replicas: 3
 selector:
 matchLabels:
 app: myapp
 strategy:
 type: RollingUpdate
 rollingUpdate:
 maxSurge: 1 # 滚动更新时最多多出 1 个 Pod
 maxUnavailable: 0 # 更新时不允许不可用
 template:
 metadata:
 labels:
 app: myapp
 spec:
 containers:
 - name: myapp
 image: myapp:1.0
 ports:
 - containerPort: 8080
 env:
 - name: DB_HOST
 valueFrom:
 configMapKeyRef:
 name: myconfig
 key: db_host
 - name: DB_PASSWORD
 valueFrom:
 secretKeyRef:
 name: mysecret
 key: db_password
 resources:
 requests:
 cpu: "250m"
 memory: "256Mi"
 limits:
 cpu: "1"
 memory: "512Mi"

2.3 Service

Service 为 Pod 提供稳定的网络访问入口。

# ClusterIP（集群内部访问）
apiVersion: v1
kind: Service
metadata:
 name: myapp-svc
spec:
 type: ClusterIP
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 protocol: TCP

---
# NodePort（外部通过节点端口访问）
apiVersion: v1
kind: Service
metadata:
 name: myapp-nodeport
spec:
 type: NodePort
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080
 nodePort: 30080 # 外部通过 <NodeIP>:30080 访问

---
# LoadBalancer（云厂商负载均衡）
apiVersion: v1
kind: Service
metadata:
 name: myapp-lb
spec:
 type: LoadBalancer
 selector:
 app: myapp
 ports:
 - port: 80
 targetPort: 8080

2.4 Ingress

Ingress 管理外部对集群服务的 HTTP/HTTPS 访问。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
 annotations:
 nginx.ingress.kubernetes.io/rewrite-target: /
 cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
 ingressClassName: nginx
 tls:
 - hosts:
 - app.example.com
 secretName: app-tls
 rules:
 - host: app.example.com
 http:
 paths:
 - path: /
 pathType: Prefix
 backend:
 service:
 name: myapp-svc
 port:
 number: 80
 - path: /api
 pathType: Prefix
 backend:
 service:
 name: api-svc
 port:
 number: 8080

2.5 ConfigMap 和 Secret

# ConfigMap - 存储配置数据
apiVersion: v1
kind: ConfigMap
metadata:
 name: myconfig
data:
 db_host: "mysql.default.svc.cluster.local"
 db_port: "3306"
 app.properties: |
 server.port=8080
 logging.level=INFO

---
# Secret - 存储敏感数据（base64 编码）
apiVersion: v1
kind: Secret
metadata:
 name: mysecret
type: Opaque
data:
 db_password: cGFzc3dvcmQxMjM=  # echo -n 'password123' | base64
 api_key: c2VjcmV0a2V5

2.6 其他核心资源

# StatefulSet - 有状态应用（数据库、消息队列）
apiVersion: apps/v1
kind: StatefulSet
metadata:
 name: mysql
spec:
 serviceName: "mysql"
 replicas: 3
 selector:
 matchLabels:
 app: mysql
 template:
 metadata:
 labels:
 app: mysql
 spec:
 containers:
 - name: mysql
 image: mysql:8.0
 volumeMounts:
 - name: data
 mountPath: /var/lib/mysql
 volumeClaimTemplates:
 - metadata:
 name: data
 spec:
 accessModes: ["ReadWriteOnce"]
 resources:
 requests:
 storage: 10Gi

---
# DaemonSet - 每个节点运行一个 Pod
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: log-agent
spec:
 selector:
 matchLabels:
 app: log-agent
 template:
 metadata:
 labels:
 app: log-agent
 spec:
 containers:
 - name: fluentd
 image: fluentd:latest

---
# CronJob - 定时任务
apiVersion: batch/v1
kind: CronJob
metadata:
 name: backup
spec:
 schedule: "0 2 * * *" # 每天凌晨 2 点
 jobTemplate:
 spec:
 template:
 spec:
 containers:
 - name: backup
 image: backup-tool:latest
 command: ["/bin/sh", "-c", "run-backup.sh"]
 restartPolicy: OnFailure

3. 常用 kubectl 命令

3.1 集群信息

# 集群信息
kubectl cluster-info
kubectl get nodes
kubectl get nodes -o wide # 详细信息
kubectl describe node <node-name>

# 查看所有资源
kubectl get all -A # 所有命名空间
kubectl get all -n kube-system # 指定命名空间

3.2 资源管理

# 创建资源
kubectl apply -f deployment.yaml
kubectl create namespace my-ns
kubectl create configmap myconfig --from-file=config.properties
kubectl create secret generic mysecret --from-literal=password=123

# 查看资源
kubectl get pods
kubectl get pods -o wide # 显示 IP 和节点
kubectl get pods --show-labels # 显示标签
kubectl get pods -l app=myapp # 按标签过滤
kubectl get pods -A # 所有命名空间
kubectl get pods -w # 实时监听变化
kubectl get pods --field-selector=status.phase=Running

kubectl get svc
kubectl get deploy
kubectl get ingress
kubectl get configmap
kubectl get secret
kubectl get pvc # 持久卷声明
kubectl get events --sort-by='.lastTimestamp'

# 查看详情
kubectl describe pod <pod-name>
kubectl describe svc <svc-name>
kubectl describe node <node-name>

# 删除资源
kubectl delete pod <pod-name>
kubectl delete -f deployment.yaml
kubectl delete pods --all # 删除所有 Pod
kubectl delete pods --all -n my-ns

3.3 部署与更新

# 滚动更新
kubectl set image deployment/myapp myapp=myapp:2.0
kubectl apply -f deployment.yaml # 声明式更新

# 查看更新状态
kubectl rollout status deployment/myapp
kubectl rollout history deployment/myapp

# 回滚
kubectl rollout undo deployment/myapp # 回到上一个版本
kubectl rollout undo deployment/myapp --to-revision=2 # 回到指定版本

# 扩缩容
kubectl scale deployment/myapp --replicas=5
kubectl autoscale deployment/myapp --min=3 --max=10 --cpu-percent=80

3.4 调试与日志

# 查看日志
kubectl logs <pod-name>
kubectl logs <pod-name> -f # 实时追踪
kubectl logs <pod-name> --tail=100 # 最后 100 行
kubectl logs <pod-name> -c <container> # 多容器 Pod 指定容器
kubectl logs -l app=myapp # 按标签查看日志
kubectl logs --previous # 查看上次崩溃的日志

# 进入容器
kubectl exec -it <pod-name> -- /bin/bash
kubectl exec -it <pod-name> -c <container> -- /bin/sh

# 端口转发
kubectl port-forward <pod-name> 8080:80
kubectl port-forward svc/myapp-svc 8080:80

# 文件复制
kubectl cp <pod-name>:/path/file ./file
kubectl cp ./file <pod-name>:/path/file

# 查看 Pod 事件
kubectl get events --field-selector involvedObject.name=<pod-name>

# 调试 Pod（临时容器）
kubectl debug <pod-name> -it --image=busybox

3.5 命名空间管理

kubectl get namespaces
kubectl create namespace dev
kubectl config set-context --current --namespace=dev # 切换默认命名空间
kubectl delete namespace dev

4. 网络模型

4.1 Service 类型对比

类型	访问范围	使用场景
ClusterIP	集群内部	微服务间通信（默认）
NodePort	外部通过节点IP:Port	开发测试
LoadBalancer	云厂商 LB	生产环境
ExternalName	DNS CNAME	引用外部服务

4.2 网络策略

# 只允许同命名空间中 label 为 role=frontend 的 Pod 访问
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
 name: allow-frontend
 namespace: production
spec:
 podSelector:
 matchLabels:
 app: backend
 policyTypes:
 - Ingress
 ingress:
 - from:
 - podSelector:
 matchLabels:
 role: frontend
 ports:
 - port: 8080

5. 存储

5.1 PersistentVolume 与 PVC

# PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
 name: my-pv
spec:
 capacity:
 storage: 10Gi
 accessModes:
 - ReadWriteOnce
 storageClassName: standard
 hostPath:
 path: /data/pv

---
# PersistentVolumeClaim
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
 name: my-pvc
spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 5Gi
 storageClassName: standard

---
# 在 Pod 中使用
spec:
 containers:
 - name: app
 volumeMounts:
 - name: data
 mountPath: /data
 volumes:
 - name: data
 persistentVolumeClaim:
 claimName: my-pvc

5.2 StorageClass（动态供给）

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
 name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
 type: gp3
 iopsPerGB: "10"
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

6. RBAC 权限管理

# 创建角色
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 namespace: dev
 name: pod-reader
rules:
 - apiGroups: [""]
 resources: ["pods", "pods/log"]
 verbs: ["get", "list", "watch"]
 - apiGroups: ["apps"]
 resources: ["deployments"]
 verbs: ["get", "list"]

---
# 绑定角色到用户
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: read-pods
 namespace: dev
subjects:
 - kind: User
 name: developer
 apiGroup: rbac.authorization.k8s.io
roleRef:
 kind: Role
 name: pod-reader
 apiGroup: rbac.authorization.k8s.io

7. 集群搭建方式

方式	适用场景	复杂度
minikube	本地学习开发	⭐
kind	CI/CD 测试	⭐⭐
kubeadm	生产部署	⭐⭐⭐
k3s	边缘/IoT/轻量	⭐⭐
托管服务	EKS/AKS/GKE	⭐⭐

8. 生产最佳实践

资源限制 — 始终设置 requests 和 limits
健康检查 — 配置 livenessProbe 和 readinessProbe
副本数 — 至少 2 个副本保证高可用
滚动更新 — 设置合理的 maxSurge 和 maxUnavailable
命名空间隔离 — 按环境（dev/staging/prod）分命名空间
网络策略 — 限制 Pod 间不必要的通信
RBAC — 最小权限原则
监控告警 — Prometheus + Grafana
日志收集 — EFK/Loki 栈
备份 etcd — 定期备份集群状态

总结

K8s 核心知识点：

架构 — Control Plane + Worker Node
Pod — 最小部署单元
Deployment — 无状态应用管理，滚动更新
Service — 为 Pod 提供稳定访问入口
Ingress — HTTP/HTTPS 路由
ConfigMap/Secret — 配置与敏感数据管理
StatefulSet — 有状态应用
PV/PVC — 持久化存储
RBAC — 权限控制
kubectl — 集群操作的核心命令