Kubernetes 进阶实战监控、配额、健康检查、认证授权、存储与有状态应用全解析一份涵盖 Metrics Server、HPA、ResourceQuota、LimitRange、健康探针、RBAC、Dashboard、动态存储和 StatefulSet 的完整学习笔记写在前面在前面的文章中我们已经完成了 Kubernetes 集群的部署、核心控制器Deployment/DaemonSet/Job的学习以及网络策略和调度的深入探讨。今天这篇文章是Kubernetes 进阶知识的集大成者内容覆盖了生产环境中至关重要的几个方面监控与扩缩容Metrics Server HPA水平 Pod 自动扩缩容资源管控ResourceQuota资源配额和 LimitRange限制范围应用自愈LivenessProbe、ReadinessProbe 健康检查安全体系认证Authentication与 RBAC 授权Authorization管理界面Kubernetes Dashboard 部署与使用存储进阶动态卷供应Local Path、NFS Provisioner有状态应用StatefulSet 实战Nginx、Etcd、Redis、MySQL这是一篇非常硬核的长文建议收藏后慢慢消化。所有 YAML 和命令均基于 K8s v1.30 实测。一、Metrics Server 与 HPA自动扩缩容的基石1.1 部署 Metrics ServerMetrics Server 是 Kubernetes 内置的资源指标采集器它从 kubelet 收集 CPU 和内存使用数据通过 Metrics API 暴露给kubectl top和 HPA。# 下载部署文件wgethttps://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.1/components.yaml# 添加 --kubelet-insecure-tls因自签名证书sed-i/metric-resolution/a\ - --kubelet-insecure-tlscomponents.yaml kubectl apply-fcomponents.yaml验证部署kubectltopnodekubectltoppods-nkube-system1.2 HPA 基于 CPU 自动扩缩容创建一个 Deployment 并配置 HPAkubectl create deployment web--imagenginx kubectl autoscale deployment web--max5--min2--cpu-percent80关键前提Pod 必须设置resources.limits.cpu否则 HPA 无法计算利用率。resources:limits:cpu:100mmemory:200Mi压力测试# 安装压测工具aptinstall-yapache2-utils# 压测替换为 Service IPwhiletrue;doab-n300000-c100http://service-ip/;sleep1;done观察 HPA 逐步扩容到最大副本数watchkubectl get hpa; echo; kubectl top pods1.3 HPA 基于内存自动扩缩容apiVersion:autoscaling/v2kind:HorizontalPodAutoscalermetadata:name:webspec:minReplicas:2maxReplicas:5scaleTargetRef:apiVersion:apps/v1kind:Deploymentname:webmetrics:-resource:name:memorytarget:type:UtilizationaverageUtilization:60type:Resource注意内存扩缩容需要 Pod 内存使用率持续高于阈值才会触发且缩容有 5 分钟冷却期--horizontal-pod-autoscaler-downscale-stabilization。1.4 扩容/缩容时间参数调优修改 kube-controller-manager 静态 Pod 参数# /etc/kubernetes/manifests/kube-controller-manager.yaml---horizontal-pod-autoscaler-sync-period10s# 采样周期默认15s---horizontal-pod-autoscaler-initial-readiness-delay20s# 启动就绪窗口默认30s---horizontal-pod-autoscaler-downscale-stabilization60s# 缩容冷却默认5min二、ResourceQuota 与 LimitRange资源管控2.1 ResourceQuota命名空间资源配额ResourceQuota 限制一个命名空间内资源的总量如 Pod 数量、CPU/内存总量。apiVersion:v1kind:ResourceQuotametadata:name:myquotaspec:hard:pods:10requests.cpu:4requests.memory:8Gilimits.cpu:8limits.memory:16Gipersistentvolumeclaims:5重要规则一旦命名空间设置了requests.cpu或requests.memory配额该命名空间下的所有 Pod必须显式指定 requests 和 limits否则创建被拒绝。# 测试不指定 resources 的 Podkubectl run web--imagenginx# Error from server (Forbidden): ... must specify limits.cpu, limits.memory, requests.cpu, requests.memory2.2 LimitRange默认资源限制LimitRange 为命名空间内的 Pod/容器设置默认的 requests/limits 以及最小/最大值约束。apiVersion:v1kind:LimitRangemetadata:name:mylimitspec:limits:-type:Containermax:cpu:1memory:1Gimin:cpu:100mmemory:128Midefault:cpu:500mmemory:512MidefaultRequest:cpu:200mmemory:256Mi约束关系min defaultRequest default max验证创建未指定 resources 的 Pod查看其自动注入的值kubectl get pod web-oyaml|grep-A5resources三、健康检查LivenessProbe 与 ReadinessProbe3.1 为什么需要健康检查没有健康检查时即使容器内应用崩溃如删除了 index.htmlPod 状态依然是Running流量仍会被转发导致服务不可用。3.2 三种探针类型探针作用失败后果LivenessProbe判断容器是否存活重启容器ReadinessProbe判断容器是否就绪可接收流量从 Service Endpoints 中摘除StartupProbe判断慢启动容器是否完成初始化重启容器期间禁用其他探针3.3 HTTP 探针最常用livenessProbe:httpGet:path:/index.htmlport:80scheme:HTTPinitialDelaySeconds:5periodSeconds:5failureThreshold:3timeoutSeconds:10验证 LivenessProbe删除主页文件后容器会被重启。验证 ReadinessProbe删除某 Pod 的主页文件该 Pod 的READY状态变为0/1且从 Service Endpoints 中移除。3.4 Exec 探针在容器内执行命令返回 0 表示成功livenessProbe:exec:command:-cat-/tmp/healthy3.5 TCP 探针尝试建立 TCP 连接成功则视为健康livenessProbe:tcpSocket:port:803.6 滚动更新中的应用在滚动更新时ReadinessProbe 可以防止流量被路由到尚未就绪的新 Pod避免服务中断。四、认证与 RBAC 授权4.1 Kubernetes API 访问控制链路客户端请求 → 传输安全(TLS) → 认证(Authentication) → 鉴权(Authorization) → 准入控制(Admission) → 存储4.2 认证方式Kubernetes 支持多种认证插件X509 客户证书最常用kubeconfig 默认服务账号令牌Pod 访问 API静态令牌文件已废弃启动引导令牌kubeadm 使用Webhook 令牌认证4.3 创建用户X509 证书方式客户端生成私钥和 CSRopenssl genrsa-outlaoma.key2048openssl req-new-keylaoma.key-outlaoma.csr-subj/CNlaoma/Okubernets管理员签发证书openssl x509-req-inlaoma.csr-CA/etc/kubernetes/pki/ca.crt-CAkey/etc/kubernetes/pki/ca.key-CAcreateserial-outlaoma.crt-days1095客户端构建 kubeconfigkubectl config set-cluster kubernetes--kubeconfigconfig --certificate-authorityca.crt --embed-certs--serverhttps://10.1.8.30:6443 kubectl config set-credentials laoma--kubeconfigconfig --client-keylaoma.key --client-certificatelaoma.crt --embed-certs kubectl config set-context laoma--kubeconfigconfig--clusterkubernetes--userlaoma kubectl config use-context laoma--kubeconfigconfig4.4 RBAC 授权模型RBAC 的核心四要素资源作用域说明Role命名空间定义某命名空间内的权限ClusterRole集群定义集群范围的权限RoleBinding命名空间将 Role 绑定到用户/组/SAClusterRoleBinding集群将 ClusterRole 绑定到用户/组/SA4.5 常用预定义 ClusterRoleClusterRole权限范围view只读权限get/list/watchedit读写权限不含 RBAC 和 Secretadmin命名空间内所有权限cluster-admin集群所有权限4.6 实战创建 Role 并绑定创建 Roleauth 命名空间apiVersion:rbac.authorization.k8s.io/v1kind:Rolemetadata:namespace:authname:pod-readerrules:-apiGroups:[]resources:[pods]verbs:[get,list,watch]绑定到用户 laomakubectl create rolebinding laoma-pod-reader--rolepod-reader--userlaoma-nauth验证kubectl get pods-nauth--kubeconfigconfig4.7 服务账号ServiceAccountPod 使用 ServiceAccount 身份访问 API。每个命名空间默认有一个defaultSA。apiVersion:v1kind:ServiceAccountmetadata:name:my-sa---apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:my-sa-adminroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:cluster-adminsubjects:-kind:ServiceAccountname:my-sanamespace:defaultPod 使用指定 SAspec:serviceAccountName:my-sa创建临时令牌v1.22 推荐kubectl create token my-sa五、Kubernetes Dashboard5.1 部署 Dashboardwgethttps://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml kubectl apply-frecommended.yaml5.2 暴露访问将 Service 改为 NodePort 类型kubectl edit svc kubernetes-dashboard-nkubernetes-dashboard# 修改 type: NodePort获取访问端口kubectl get svc-nkubernetes-dashboard5.3 创建管理员 TokenapiVersion:v1kind:ServiceAccountmetadata:name:admin-usernamespace:kubernetes-dashboard---apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:admin-userroleRef:apiGroup:rbac.authorization.k8s.iokind:ClusterRolename:cluster-adminsubjects:-kind:ServiceAccountname:admin-usernamespace:kubernetes-dashboard获取 Tokenkubectl-nkubernetes-dashboard create token admin-user使用 Token 登录 DashboardBearer Token 方式。六、动态卷供应Dynamic Provisioning6.1 什么是动态卷供应传统方式需要管理员预先创建 PV静态供应。动态供应通过StorageClass自动创建 PV用户只需创建 PVC 即可。6.2 Local Path Provisioner本地存储适用于使用节点本地磁盘的场景。wgethttps://github.com/rancher/local-path-provisioner/blob/v0.0.35/deploy/local-path-storage.yaml kubectl apply-flocal-path-storage.yaml验证kubectl get sc local-path# 输出: local-path rancher.io/local-path Delete WaitForFirstConsumer创建 PVC 和 Pod 测试apiVersion:v1kind:PersistentVolumeClaimmetadata:name:local-path-pvcspec:accessModes:[ReadWriteOnce]resources:requests:storage:5GistorageClassName:local-path6.3 NFS Provisioner网络存储适合多节点共享存储的场景。部署 NFS 服务器aptinstall-ynfs-kernel-servermkdir-m777/sharesecho/shares *(rw,sync,no_root_squash)/etc/exports systemctl restart nfs-server部署 NFS Provisioner# 创建 RBAC、Deployment、StorageClass参考完整 YAMLkubectl apply-fnfs-provisioner.yamlStorageClass 示例apiVersion:storage.k8s.io/v1kind:StorageClassmetadata:name:nfs-storageprovisioner:fuseim.pri/ifsreclaimPolicy:DeletevolumeBindingMode:Immediate使用方式与 Local Path 类似只需指定storageClassName: nfs-storage。七、StatefulSet有状态应用管理7.1 StatefulSet vs Deployment特性StatefulSetDeploymentPod 名称固定序号web-0, web-1…随机后缀网络标识Headless Service 固定 DNS共享 Service存储PVC 模板每个 Pod 独立 PVC共享或不使用 PVC启停顺序有序0→N 启动N→0 停止无序适用场景数据库、消息队列、分布式系统无状态 Web/API7.2 StatefulSet 核心三要素Headless ServiceclusterIP: None为每个 Pod 提供固定 DNS 解析VolumeClaimTemplate为每个 Pod 自动创建独立的 PVC有序部署/更新按序号顺序操作7.3 实战部署 Nginx StatefulSet创建 Headless ServiceapiVersion:v1kind:Servicemetadata:name:nginxspec:clusterIP:Noneselector:app:nginxports:-port:80targetPort:80创建 StatefulSetapiVersion:apps/v1kind:StatefulSetmetadata:name:nginxspec:serviceName:nginxreplicas:3selector:matchLabels:app:nginxtemplate:metadata:labels:app:nginxspec:containers:-name:nginximage:nginxvolumeMounts:-name:nginx-datamountPath:/usr/share/nginx/htmlvolumeClaimTemplates:-metadata:name:nginx-dataspec:accessModes:[ReadWriteOnce]storageClassName:nfs-storageresources:requests:storage:10Gi验证固定 DNSkubectl runtest--imagebusybox-it--rm--sh/# curl nginx-0.nginx/# curl nginx-1.nginx7.4 实战部署 Etcd 集群Etcd 是典型的有状态分布式协调服务3 节点集群apiVersion:apps/v1kind:StatefulSetmetadata:name:etcdspec:serviceName:etcdreplicas:3selector:matchLabels:app:etcdtemplate:metadata:labels:app:etcdspec:containers:-name:etcdimage:registry.aliyuncs.com/google_containers/etcd:3.5.10-0env:-name:ETCD_NAMEvalueFrom:fieldRef:fieldPath:metadata.name-name:ETCD_INITIAL_CLUSTERvalue:etcd-0http://etcd-0.etcd:2380,etcd-1http://etcd-1.etcd:2380,etcd-2http://etcd-2.etcd:2380# ... 其他环境变量volumeMounts:-name:etcd-datamountPath:/var/lib/etcdvolumeClaimTemplates:-metadata:name:etcd-dataspec:accessModes:[ReadWriteOnce]storageClassName:nfs-storageresources:requests:storage:10Gi验证集群状态kubectlexecetcd-0 -- etcdctl member list kubectlexecetcd-0 -- etcdctl put /test key value kubectlexecetcd-2 -- etcdctl get /test key7.5 实战部署 Redis 主从集群一个包含 1 主 2 从的 Redis 集群使用 Sentinel 实现高可用。核心配置spec:containers:-name:redisimage:redis:7.0-alpinecommand:[/bin/sh,-c]args:-|NODE_ID$(hostname | awk -F- {print $2}) # 配置主从 if [ $NODE_ID ! 0 ]; then echo replicaof redis-0.redis 6379 /data/redis.conf fi # 启动 Redis redis-server /data/redis.conf # 配置 Sentinelcat/data/sentinel.conf EOF sentinel monitor mymaster redis-0.redis 6379 2 sentinel auth-pass mymaster redis123 EOF redis-sentinel /data/sentinel.conf验证故障切换# 删除主节点kubectl delete pod redis-0# 等待重建后查看角色kubectlexecredis-0 -- redis-cli-aredis123 info replication# 预期role:slave另一个节点已升为主八、总结与避坑指南核心知识点速查表组件用途关键命令/文件Metrics Server资源监控kubectl top node/podHPA自动扩缩容kubectl autoscaleResourceQuota命名空间资源限额kubectl get quotaLimitRange默认资源限制kubectl get limitrange健康探针应用自愈和流量管理livenessProbe/readinessProbeRBAC权限控制Role/ClusterRole BindingStorageClass动态卷供应provisioner parametersStatefulSet有状态应用Headless Service PVC 模板常见问题与解决方案问题解决方案kubectl top报错检查 Metrics Server 是否 Running添加--kubelet-insecure-tlsHPA 不生效确认 Pod 已设置resources.limitsPod 创建被拒绝配额检查 ResourceQuota确保 Pod 指定了 requests/limitsStatefulSet Pod 启动顺序乱检查 Headless Service 配置是否正确PVC 一直 Pending检查 StorageClass 是否存在PV 是否满足 PVC 要求RBAC 权限不生效确认 RoleBinding 的 namespace 与用户操作的 namespace 一致写在最后这篇文章从监控扩缩容到资源管控从健康检查到认证授权再到动态存储和有状态应用涵盖了 Kubernetes 生产环境中最重要的进阶主题。这些知识是 CKA/CKAD 考试的高频考点也是实际运维中的必备技能。如果你一路看到这里相信你对 Kubernetes 的理解已经上了一个新台阶。后续可以继续深入Service MeshIstio/LinkerdGitOpsArgoCD/Flux多集群管理Karmada/Federation觉得有帮助的话欢迎点赞、收藏、转发本文所有 YAML 和命令均基于 Kubernetes v1.30 containerd Calico 实测版本差异请适当调整。