当前位置：首页 > news >正文

Kubernetes生产级落地：RBAC、配额、安全与弹性协同实践

news 2026/6/22 4:08:30

1. 项目概述：当Kubernetes不再只是“能跑起来”

“Kubernetes: Beyond Baby Steps”这个标题，我第一次看到时就在笔记本上划了三道横线——不是因为它多酷，而是因为它精准戳中了国内大量技术团队的真实状态：集群搭好了，Pod能调度了，kubectl get pods返回绿色的Running，大家拍手庆祝，然后……就卡在原地了。三年前我在某中型电商做容器平台建设时，运维组同事指着监控面板说：“集群跑了半年，没出大问题，但一加新业务就OOM，一调权限就403，一查日志全是Forbidden，连谁删了命名空间都查不到。”这不是个例，而是从“能用”跃迁到“稳用、安用、智用”的必经断层。

这个断层背后，藏着五个被严重低估的硬核能力：RBAC权限的最小化落地实践、资源配额与弹性伸缩的协同设计逻辑、安全基线的可验证性闭环、多租户隔离的工程化实现路径、以及故障归因的可观测性基建支撑。热搜词里反复出现的“rbac权限管理设计”“security violation”“resource quotas”，根本不是孤立概念，而是同一枚硬币的五面：你无法只配RBAC而不定义资源配额，也无法只设autoscaling却不约束安全上下文。我见过太多团队把RBAC当成“给开发开个账号+加个cluster-admin”，结果上线三天就被误删了etcd备份Job；也见过把HorizontalPodAutoscaler（HPA）参数设成--cpu-percent=80就以为万事大吉，结果流量突增时节点直接OOM，因为没配LimitRange和ResourceQuota，Pod疯狂抢占内存。

这篇文章不讲怎么用kubeadm init初始化集群——那属于“婴儿学步”阶段；也不堆砌API Server参数列表——那是K8s源码阅读笔记。它聚焦于真实生产环境里，那些让集群从“可用”变成“敢用”的关键决策点。你会看到：

RBAC策略如何用kubectl auth can-i --list反向验证，而不是靠猜；
ResourceQuota和LimitRange怎样配合HPA，在流量高峰时既保服务又防雪崩；
SecurityContext里的runAsNonRoot: true为什么必须搭配fsGroup: 1001，否则挂载卷直接报错；
当kubectl describe pod显示FailedScheduling时，如何用kubectl top nodes和kubectl describe quota交叉定位是资源不足还是配额锁死；
甚至包括一个被90%教程忽略的细节：ServiceAccount的automountServiceAccountToken: false该在什么场景下关闭，关了之后怎么让Prometheus Operator正常拉取metrics。

适合谁读？如果你已经能手动部署单Master集群，但遇到以下任一情况，这篇就是为你写的：

新业务上线前，需要写一份能让安全团队签字的权限方案；
集群CPU使用率常年低于30%，但扩容新节点时总提示Insufficient memory；
开发抱怨“明明配了HPA，为啥QPS涨了Pod数纹丝不动”；
审计要求提供“谁在何时以何种权限执行了什么操作”的完整审计日志；
或者，你正被Error from server (Forbidden): users "dev-user" is forbidden这类报错反复折磨。

接下来的内容，全部来自我们为12家客户落地K8s平台时踩过的坑、验过的参数、压测过的效果。没有理论推演，只有命令行输出截图背后的血泪教训。

2. 核心能力拆解：为什么“Beyond Baby Steps”本质是五个能力的耦合

2.1 RBAC不是权限开关，而是访问控制的“电路图”

新手常把RBAC理解成“给用户分配角色”，这就像把电路设计简化成“给灯泡通电”。真正的RBAC是基于动词（verb）、资源（resource）、子资源（subresource）和命名空间（namespace）四维坐标的访问控制矩阵。比如，一个开发需要“在dev命名空间里部署Deployment并查看其Pod日志”，这对应三条独立规则：

verbs: ["create", "update", "patch"],resources: ["deployments"]
verbs: ["get", "list"],resources: ["pods"],resourceNames: []（允许查所有Pod）
verbs: ["get"],resources: ["pods"],subresources: ["log"]（仅允许查日志，不能exec）

提示：kubectl auth can-i create deployments --namespace=dev --as=system:serviceaccount:dev:dev-sa这条命令能模拟ServiceAccount的权限，比翻YAML文件快十倍。我习惯在写完RoleBinding后立刻执行它，失败就改YAML，成功再kubectl apply。

更关键的是RBAC策略的继承关系。ClusterRoleBinding绑定到system:authenticated组，意味着所有通过认证的用户（包括ServiceAccount）都获得该权限。而system:serviceaccounts组默认包含所有ServiceAccount，这是很多“越权操作”的根源。我们曾发现一个CI/CD流水线用defaultServiceAccount部署应用，而该SA绑定了cluster-admin——因为某位同事为图省事，在测试环境执行了kubectl create clusterrolebinding default-view --clusterrole=view --group=system:serviceaccounts。

2.2 Resource Quotas与LimitRange：资源管控的“双保险”

ResourceQuota（资源配额）和LimitRange（限制范围）常被混为一谈，但它们解决的是完全不同的问题：

ResourceQuota是“总量封顶”：限制某个命名空间内所有Pod加起来最多用多少CPU、内存、多少个ConfigMap。它像银行账户的余额上限，超了就拒绝创建新资源。
LimitRange是“个体底线”：为每个Pod或Container设置默认的Request/Limit值，并强制要求必须设置。它像信用卡的最低还款额，不设就给你自动填上。

二者必须配合使用。举个真实案例：某金融客户集群设置了ResourceQuota限制dev命名空间最多用4核CPU，但没配LimitRange。开发提交的Deployment YAML里没写resources.requests.cpu，K8s默认按0分配，导致该命名空间瞬间创建了20个“零资源请求”的Pod，占满整个命名空间的配额，其他高优服务无法调度。

正确的做法是：

先用LimitRange设定默认值：

apiVersion: v1 kind: LimitRange metadata: name: limits namespace: dev spec: limits: - default: memory: 512Mi cpu: 250m defaultRequest: memory: 256Mi cpu: 100m type: Container

再用ResourceQuota限制总量：

apiVersion: v1 kind: ResourceQuota metadata: name: compute-quota namespace: dev spec: hard: requests.cpu: "4" requests.memory: 8Gi limits.cpu: "8" limits.memory: 16Gi pods: "20" # 同时运行的Pod总数上限

这样，即使开发忘记写resources，K8s也会自动注入requests.cpu: 100m，而20个Pod最多消耗2核CPU，远低于4核配额，留出缓冲空间。

2.3 Autoscaling的“三重门”：HPA、VPA、Cluster Autoscaler的协同逻辑

很多人以为配置HPA（Horizontal Pod Autoscaler）就实现了自动扩缩容，但生产环境里，它只是“三重门”的第一道。真正的弹性需要三层联动：

HPA（水平扩缩容）：根据CPU/内存/自定义指标（如QPS）调整Pod副本数；
VPA（垂直扩缩容）：动态调整单个Pod的CPU/Memory Request/Limit；
Cluster Autoscaler（集群自动扩缩容）：当节点资源不足时，自动增加云服务器实例。

三者顺序不能乱。我们曾在一个视频转码业务中踩坑：HPA根据CPU使用率扩Pod，但Pod的requests.cpu设得过低（100m），导致大量Pod挤在少数节点上，节点CPU负载95%却无法触发Cluster Autoscaler——因为CA只看节点是否“不可调度”（即是否有Pod因资源不足无法调度），而现有Pod还能勉强运行。此时VPA本可提升Pod的requests，但客户禁用了VPA，理由是“怕影响线上”。结果就是：HPA拼命扩Pod，节点越来越慢，最终雪崩。

解决方案是用HPA驱动VPA，VPA驱动CA：

HPA负责快速响应流量变化（秒级）；
VPA每15分钟分析历史使用率，将Pod的requests逐步调高至实际使用率的120%（留20%缓冲），避免“小马拉大车”；
CA监听VPA调高requests后产生的“Pending Pod”，当连续5分钟有Pending，则扩容节点。

实操心得：VPA的updateMode: "Auto"模式虽方便，但可能在半夜把生产Pod重启（因更新Limit）。我们一律用"Off"模式，配合Prometheus告警：当container_cpu_usage_seconds_total{container!="POD"} / on(container, pod) group_left(namespace) container_spec_cpu_quota_second{container!="POD"}> 0.8持续10分钟，就人工审核并执行vpa-updater。

2.4 Security Context：安全不是加功能，而是减特权

K8s安全的核心思想是最小权限原则（Principle of Least Privilege），而SecurityContext就是实现它的手术刀。新手常犯的错误是：

认为runAsNonRoot: true就够了，却忘了Pod里进程仍可能以root用户启动（只要UID≠0）；
设置readOnlyRootFilesystem: true，但没给/tmp挂载emptyDir，导致应用写临时文件失败；
开启privileged: true只为运行Docker-in-Docker，却不知cap-add: NET_ADMIN就能满足网络调试需求。

我们为某政务云平台制定的安全基线中，强制要求以下七项：

SecurityContext字段	推荐值	原因
`runAsNonRoot`	`true`	防止root提权漏洞利用
`runAsUser`	`1001`	指定非root UID，避免应用自行创建root用户
`fsGroup`	`1001`	确保挂载卷的文件属组正确，否则`readOnlyRootFilesystem`会报错
`readOnlyRootFilesystem`	`true`	阻断恶意进程写入二进制文件
`allowPrivilegeEscalation`	`false`	禁用`sudo`等提权操作
`capabilities.drop`	`["ALL"]`	删除所有Linux Capabilities，再按需添加（如`["NET_BIND_SERVICE"]`）
`seccompProfile.type`	`"RuntimeDefault"`	启用运行时默认Seccomp策略（K8s 1.19+）

特别注意fsGroup：当readOnlyRootFilesystem: true时，K8s会尝试将挂载卷的属组改为fsGroup指定的GID。如果Pod里进程以UID 1001运行，但卷属组是0（root），就会因权限不足无法写入。所以runAsUser和fsGroup必须配对设置。

2.5 Audit Logging与Event：故障归因的“行车记录仪”

“集群很稳，但出问题时找不到人”是运维最头疼的事。K8s的审计日志（Audit Log）和事件（Event）就是你的行车记录仪。但默认配置下，它们几乎没用：

Audit Policy默认只记录Metadata级别事件（如创建Pod），不记录RequestResponse（如谁删了哪个Pod的具体参数）；
Event默认只保留1小时，且不落盘，节点重启就丢失；
kubectl get events只能看到当前命名空间的事件，跨命名空间故障无法关联。

我们为某券商实施的审计方案分三层：

API Server审计日志：启用--audit-policy-file=/etc/kubernetes/audit-policy.yaml，策略文件明确记录所有delete、patch、exec操作的RequestResponse，日志发送到ELK集群，保留180天；
集群事件中心化：部署event-exporter，将所有命名空间的Event推送到Kafka，再由Flink实时计算“10分钟内删除Pod超过5次的用户”，触发企业微信告警；
Pod级操作追踪：在Pod的SecurityContext中启用seccompProfile，记录进程系统调用，配合eBPF工具（如Tracee）捕获恶意行为。

注意：Audit Log开启RequestResponse级别会显著增加磁盘IO。我们在32核64G的Master节点上实测，峰值写入速率达12MB/s。因此必须配置--audit-log-maxage=30 --audit-log-maxbackup=10 --audit-log-maxsize=100，否则磁盘很快写满。

3. 实操全流程：从零构建一个“Beyond Baby Steps”的生产集群

3.1 环境准备：为什么KubeKey比kubeadm更适合生产

选择KubeKey而非kubeadm，不是因为前者更“高级”，而是它解决了kubeadm在生产环境的三个致命短板：

kubeadm不管理节点OS依赖：kubeadm只管K8s组件，但生产环境需要统一内核参数（如vm.swappiness=1）、禁用swap、配置iptables规则。KubeKey的config-sample.yaml中hosts字段可直接定义preInstall脚本，自动执行sysctl -w vm.swappiness=1；
kubeadm不处理高可用（HA）证书：kubeadm init生成的证书默认只绑定单个Master IP，HA场景需手动替换证书SAN。KubeKey在cluster配置中指定controlPlaneEndpoint，自动生成含所有Master IP的证书；
kubeadm不集成存储/网络插件：kubeadm init后需手动kubectl apply -f calico.yaml，而KubeKey支持--with-kubesphere一键安装KubeSphere，内置OpenEBS（存储）、Calico（网络）、Metrics Server（监控）。

我们的标准部署流程（Ubuntu 22.04）：

下载KubeKey：curl -sfL https://get-kk.kubesphere.io | VERSION=v3.0.7 sh -；
生成配置文件：./kk create config --with-kubesphere v3.4.1 --with-kubernetes v1.25.6；
编辑config-sample.yaml，重点修改三处：
- hosts: 添加所有节点IP、SSH用户、私钥路径；
- network.plugin: 改为calico（比Flannel更安全，支持NetworkPolicy）；
- registry: 配置私有Harbor地址，避免拉取镜像超时。
执行部署：./kk create cluster -f config-sample.yaml。

实操心得：KubeKey部署耗时约12分钟（3 Master + 2 Worker），比kubeadm手动部署快3倍。但首次部署后，务必立即执行kubectl get nodes -o wide确认所有节点Ready，再检查kubectl get pod -A确保calico-node、coredns、kube-proxy全部Running。我们曾因节点时间不同步（NTP未配置），导致etcd证书校验失败，Pod卡在ContainerCreating。

3.2 RBAC权限体系落地：从“全有”到“全无”的渐进式收权

我们采用“先放后收”策略，避免一步到位导致业务中断：
阶段一：粗粒度授权（部署后24小时内）

创建cluster-admin级别的ServiceAccount供CI/CD使用（ci-sa），绑定cluster-adminClusterRole；
为每个业务线创建命名空间（如finance-prod、marketing-dev），并绑定adminClusterRole（非cluster-admin，仅限该命名空间）。

阶段二：细粒度收敛（第2-7天）

用kubectl auth can-i --list --as=system:serviceaccount:finance-prod:default扫描各命名空间默认SA的权限，发现defaultSA拥有*/*权限，立即执行：

kubectl delete rolebinding default-editor -n finance-prod kubectl delete rolebinding default-viewer -n finance-prod

为finance-prod编写专属Role：

# finance-role.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: finance-prod name: finance-deployer rules: - apiGroups: [""] resources: ["pods", "services", "configmaps", "secrets"] verbs: ["get", "list", "create", "update", "delete"] - apiGroups: ["apps"] resources: ["deployments", "statefulsets"] verbs: ["get", "list", "create", "update", "delete", "patch"]

绑定到财务组的ServiceAccount：

kubectl create serviceaccount finance-sa -n finance-prod kubectl create rolebinding finance-rb --role=finance-deployer --serviceaccount=finance-prod:finance-sa -n finance-prod

阶段三：审计加固（第8-30天）

启用审计日志后，用Logstash解析requestURI字段，统计高频delete操作；
发现marketing-dev命名空间中，dev-sa频繁删除ConfigMap，立即回收其delete权限，改为get/list/create/update；
对所有ServiceAccount执行kubectl get sa -A -o json | jq '.items[] | select(.secrets != null) | .metadata.name'，清理无用Secret。

注意：RBAC变更后，务必用kubectl auth can-i验证。我们曾因拼写错误将resources: ["deployments"]写成["deployment"]，导致kubectl rollout restart deploy失败，错误信息却是Forbidden: User "system:serviceaccount:dev:dev-sa" cannot get resource "deployments" in API group "apps" in the namespace "dev"，排查耗时2小时。

3.3 资源配额与弹性伸缩联调：让HPA真正“智能”

以一个Spring Boot电商API为例，目标：QPS从100升至1000时，Pod数从3扩到12，节点CPU使用率稳定在65%±5%。

步骤1：设定基础资源请求
根据压测数据，单Pod在QPS=100时CPU使用率30%，内存占用400Mi。按2倍冗余设requests：

resources: requests: cpu: 300m memory: 800Mi limits: cpu: 600m memory: 1200Mi

步骤2：配置ResourceQuota
finance-prod命名空间预估最大QPS=2000，需24个Pod，总资源上限：

CPU: 24 × 0.6 = 14.4核 → 设limits.cpu: "16"
Memory: 24 × 1200Mi = 28.8Gi → 设limits.memory: 32Gi

# quota.yaml apiVersion: v1 kind: ResourceQuota metadata: name: finance-quota namespace: finance-prod spec: hard: requests.cpu: "12" requests.memory: 24Gi limits.cpu: "16" limits.memory: 32Gi pods: "30"

步骤3：配置HPA
使用Prometheus指标（而非CPU），因CPU波动大，QPS更精准：

kubectl autoscale deployment finance-api \ --min=3 --max=12 \ --cpu-percent=70 \ --metric "qps" --metric-value="1000" \ --namespace=finance-prod

提示：--cpu-percent=70是兜底策略，主策略用自定义指标。需先部署prometheus-adapter，并配置Rule：

- seriesQuery: 'http_server_requests_total{job="finance-api",code=~"2.."}' resources: overrides: namespace: {resource: "namespace"} pod: {resource: "pod"} name: as: "qps" metricsQuery: 'sum(rate(<<.Series>>{<<.LabelMatchers>>}[2m])) by (<<.GroupBy>>)'

步骤4：压力测试验证
用hey -z 5m -q 100 -c 50 http://finance-api.finance-prod.svc.cluster.local持续压测，观察：

kubectl get hpa：TARGETS列从<unknown>/1000变为850/1000，REPLICAS从3升至8；
kubectl top nodes：节点CPU从40%升至62%，未超70%阈值；
kubectl describe quota：limits.cpu已用12.6/16，仍有缓冲。

若REPLICAS卡在8不再增长，检查kubectl get events -n finance-prod是否有FailedComputeMetricsReplicas事件，大概率是Prometheus指标采集延迟。

3.4 安全基线加固：从“能跑”到“合规”的七步法

我们依据CIS Kubernetes Benchmark v1.8制定加固清单，以下是生产环境必须执行的七步：

第1步：禁用匿名访问

# 编辑 /etc/kubernetes/manifests/kube-apiserver.yaml # 在spec.containers[0].command下添加： - --anonymous-auth=false

验证：curl -k https://localhost:6443/api/v1/namespaces返回Unauthorized而非Forbidden。

第2步：启用AlwaysPullImages准入控制器

# /etc/kubernetes/manifests/kube-apiserver.yaml - --enable-admission-plugins=NodeRestriction,AlwaysPullImages,PodSecurityPolicy

防止Pod使用本地缓存的旧镜像（可能含漏洞）。

第3步：强制Pod Security Admission（PSA）
K8s 1.25+默认启用PSA，需为命名空间打标签：

kubectl label ns finance-prod \ pod-security.kubernetes.io/enforce=restricted \ pod-security.kubernetes.io/enforce-version=v1.25 \ pod-security.kubernetes.io/warn=baseline \ pod-security.kubernetes.io/warn-version=v1.25 \ pod-security.kubernetes.io/audit=restricted \ pod-security.kubernetes.io/audit-version=v1.25

第4步：配置NetworkPolicy
禁止finance-prod命名空间Pod访问公网，只允许访问数据库：

# network-policy.yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-egress namespace: finance-prod spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: name: db ports: - protocol: TCP port: 3306

第5步：加密Secrets
启用KMS插件，用云厂商KMS加密etcd中的Secrets：

# /etc/kubernetes/manifests/kube-apiserver.yaml - --encryption-provider-config=/etc/kubernetes/encryption-config.yaml

encryption-config.yaml内容需由云厂商提供。

第6步：限制ServiceAccount Token

# 禁用default SA自动挂载Token kubectl patch serviceaccount default -p '{"automountServiceAccountToken": false}' -n finance-prod # 为需要Token的Pod单独启用 kubectl patch deploy finance-api -p '{"spec":{"template":{"spec":{"automountServiceAccountToken": true}}}}' -n finance-prod

第7步：启用Pod Disruption Budget（PDB）
保障滚动更新时最小可用Pod数：

# pdb.yaml apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: finance-pdb namespace: finance-prod spec: minAvailable: 2 selector: matchLabels: app: finance-api

注意：PSA标签打错会导致所有Pod创建失败。我们曾将enforce=restricted误写为enforce=restrictedv1，kubectl apply后kubectl get pods全为CreateContainerConfigError。修复方法：临时删除标签kubectl label ns finance-prod pod-security.kubernetes.io/enforce-，再重试。

4. 故障排查实战：那些让你凌晨三点爬起来的典型问题

4.1 “Forbidden”报错的三层归因法

当kubectl get pods返回Error from server (Forbidden): ...，别急着查RBAC，按此顺序排查：

第一层：认证（Authentication）是否通过？

检查kubectl config view中user字段的证书是否过期（client-certificate-data解码后看Not After）；
若用--token，确认Token未过期（kubectl get secrets -n kube-system | grep default-token，解码ca.crt）；
最简单验证：curl -k --cert /path/to/admin.crt --key /path/to/admin.key https://master-ip:6443/api/v1/namespaces，返回200则认证OK。

第二层：授权（Authorization）是否允许？

用kubectl auth can-i模拟：kubectl auth can-i list pods --namespace=finance-prod --as=system:serviceaccount:finance-prod:finance-sa；
若返回no，检查RoleBinding是否绑定到正确命名空间（-n finance-prod），且Role中resources拼写正确（pods不是pod）；
特别注意：kubectl auth can-i不检查resourceNames，若Role中指定了resourceNames: ["my-pod"]，需用kubectl auth can-i get pod/my-pod验证。

第三层：准入控制（Admission Control）是否拦截？

查看API Server日志：journalctl -u kube-apiserver | grep "admission"；
常见拦截：PSA标签不匹配（pod-security.kubernetes.io/enforce=restricted但Pod用了privileged: true）；
临时绕过：kubectl delete validatingwebhookconfiguration psa-validating-webhook（仅调试用，事后恢复）。

实操心得：我们写了个脚本check-rbac.sh，自动执行以上三步并输出诊断报告。当收到“Forbidden”告警时，运维只需运行./check-rbac.sh finance-sa finance-prod，30秒内定位到是PSA拦截（因Pod未设runAsNonRoot），而非RBAC配置错误。

4.2 “Insufficient memory”之谜：配额、请求、节点的三角博弈

现象：kubectl get pods显示大量Pod处于Pending，kubectl describe pod提示0/5 nodes are available: 5 Insufficient memory.，但kubectl top nodes显示节点内存使用率仅40%。

根因分析：

Insufficient memory指节点剩余可分配内存 < Pod的requests.memory，而非实际使用内存；
kubectl top nodes显示的是实际使用内存，而K8s调度器看的是allocatable（可分配）内存，等于capacity - system-reserved - kube-reserved；
若ResourceQuota已用尽，即使节点有空闲内存，调度器也不会分配。

排查步骤：

查节点allocatable：kubectl get node node-1 -o wide，看INTERNAL-IP右侧的ALLOCATABLE列；
查节点已分配：kubectl describe node node-1 | grep -A 10 "Allocated resources"，看memory行；
查命名空间配额：kubectl describe quota -n finance-prod，看limits.memory已用百分比；
查Pending Pod的requests：kubectl get pod pending-pod -o yaml | grep -A 5 resources。

典型案例：某客户节点capacity.memory: 64Gi，allocatable.memory: 58Gi，但kubectl describe node显示Allocated resources中memory: 55Gi，剩余仅3Gi。而Pending Pod的requests.memory: 4Gi，故报Insufficient memory。此时kubectl top nodes显示使用率40%（25.6Gi），极具迷惑性。

解决方案：

紧急：kubectl scale deploy finance-api --replicas=2减少Pod数，释放内存；
长期：调高节点--system-reserved（如--system-reserved=memory=4Gi），或优化Pod的requests.memory（从4Gi降至2Gi）。

4.3 HPA不工作的五大盲区

HPA显示<unknown>/80%或<waiting for metrics>，常见原因：

现象	根因	验证命令	解决方案
`kubectl get hpa`显示`<unknown>`	Metrics Server未就绪	`kubectl get apiservice v1beta1.metrics.k8s.io`	`kubectl delete apiservice v1beta1.metrics.k8s.io`，重装Metrics Server
`TARGETS`列为空	HPA未关联到Deployment	`kubectl get hpa -o wide`看`REFERENCE`列	`kubectl autoscale deploy finance-api --min=2 --max=10 --cpu-percent=70`
`REPLICAS`不变	Pod的`requests.cpu`未设置	`kubectl get pod -o wide`看`CPU(cores)`列是否为`<unknown>`	在Deployment YAML中添加`resources.requests.cpu: 100m`
`TARGETS`显示`0%/80%`	CPU使用率长期为0	`kubectl top pods`看实际CPU	检查应用是否空闲，或HPA指标源错误（如用`cpu`而非`qps`）
`REPLICAS`卡在最小值	`minReplicas`设置过低	`kubectl get hpa -o yaml`看`minReplicas`字段	`kubectl patch hpa finance-hpa -p '{"spec":{"minReplicas":3}}'`

注意：kubectl top pods依赖Metrics Server，若其异常，top命令会卡住。此时用kubectl get --raw "/apis/metrics.k8s.io/v1beta1/pods"直接调用API，返回{"kind":"PodMetricsList","apiVersion":"metrics.k8s.io/v1beta1","items":[]}说明Metrics Server正常，返回空则需排查。

4.4 审计日志“静默”之困：Policy配置的隐藏陷阱

现象：API Server日志中无审计日志输出，/var/log/kubernetes/audit.log为空。

排查链路：

检查kube-apiserver.yaml是否启用审计：--audit-log-path=/var/log/kubernetes/audit.log；
检查--audit-policy-file路径是否正确，文件是否存在；
关键陷阱：Audit Policy文件中level: Metadata仅记录元数据，RequestResponse才记录请求体。若策略中level设为None或Metadata，则看不到delete的具体参数；
检查日志目录权限：ls -ld /var/log/kubernetes/，应为drwxr-xr-x 2 root root，否则API Server无法写入。

修复步骤：

创建/etc/kubernetes/audit-policy.yaml：

apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse verbs: ["delete", "patch", "post", "put"] resources: - group: "" resources: ["pods", "services", "configmaps", "secrets"] - level: Metadata verbs: ["get", "list", "watch"] resources: - group: "" resources: ["pods", "services", "configmaps", "secrets"]

修改kube-apiserver.yaml：

- --audit-policy-file=/etc/kubernetes/audit-policy.yaml - --audit-log-path=/var/log/kubernetes/audit.log - --audit-log-maxage=30 - --audit-log-maxbackup=10 - --audit-log-maxsize=100

重启API Server：docker ps | grep kube-apiserver | awk '{print $1}' | xargs docker restart。

实操心得：Audit Log开启RequestResponse后，单次kubectl delete pod my-pod会在日志中生成3行：Request（含JSON body）、ResponseComplete（含HTTP状态码）、Response（含返回JSON）。我们用Logstash过滤objectRef.resource:pods和verb:delete，实时推送告警。