名称: operating-kubernetes 描述: 高效操作生产Kubernetes集群，包括资源管理、高级调度、网络、存储、安全硬化和自动伸缩。当部署工作负载到Kubernetes、配置集群资源、实施安全策略或故障排除操作问题时使用。

Kubernetes操作

目的

在生产中操作Kubernetes集群需要掌握资源管理、调度模式、网络架构、存储策略、安全硬化和自动伸缩。此技能提供以操作为先的框架，用于正确调整工作负载大小、实施高可用性模式、使用RBAC和Pod安全标准保护集群，以及系统化故障排除常见失败。

当部署应用程序到Kubernetes、配置集群资源、实施NetworkPolicies进行零信任安全、设置自动伸缩（HPA、VPA、KEDA）、管理持久存储或诊断操作问题如CrashLoopBackOff或资源耗尽时使用此技能。

何时使用此技能

常见触发场景:

“将我的应用程序部署到Kubernetes”
“配置资源请求和限制”
“为我的Pods设置自动伸缩”
“实施NetworkPolicies进行安全”
“我的Pod卡在Pending/CrashLoopBackOff状态”
“配置最小权限的RBAC”
“为我的数据库设置持久存储”
“跨可用区分布Pods”

覆盖的操作:

资源管理（CPU/内存、QoS类、配额）
高级调度（亲和性、污点、拓扑分布）
网络（NetworkPolicies、Ingress、Gateway API）
存储操作（StorageClasses、PVCs、CSI）
安全硬化（RBAC、Pod安全标准、策略）
自动伸缩（HPA、VPA、KEDA、集群自动伸缩器）
故障排除（系统化调试手册）

资源管理

服务质量（QoS）类

Kubernetes根据资源请求和限制分配QoS类：

保证型（最高优先级）:

CPU和内存的请求等于限制
除非超过限制，否则永不驱逐
用于关键生产服务

resources:
  requests:
    memory: "512Mi"
    cpu: "500m"
  limits:
    memory: "512Mi"  # 与请求相同
    cpu: "500m"

可突增型（中等优先级）:

请求小于限制（或仅设置请求）
可以突发超过请求
在节点压力下被驱逐
用于Web服务器、大多数应用程序

resources:
  requests:
    memory: "256Mi"
    cpu: "250m"
  limits:
    memory: "512Mi"  # 2倍请求
    cpu: "500m"

尽力型（最低优先级）:

未设置请求或限制
在压力下首先被驱逐
仅用于开发/测试

决策框架：选择哪个QoS类？

工作负载类型	QoS类	配置
关键API/数据库	保证型	请求 == 限制
Web服务器、服务	可突增型	限制为请求的1.5-2倍
批量作业	可突增型	低请求、高限制
开发/测试环境	尽力型	无限制

资源配额和LimitRanges

使用ResourceQuotas（命名空间限制）和LimitRanges（每个容器默认值）强制执行多租户：

# ResourceQuota: 命名空间级别限制
apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: team-alpha
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"

有关详细资源管理模式，包括Vertical Pod Autoscaler（VPA），请参阅references/resource-management.md。

高级调度

节点亲和性

使用必需（硬）或偏好（软）约束控制Pods调度到哪些节点：

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node.kubernetes.io/instance-type
          operator: In
          values:
          - g4dn.xlarge  # GPU实例

污点和容忍

为特定工作负载保留节点（与亲和性相反）：

# 污点GPU节点以防止非GPU工作负载
kubectl taint nodes gpu-node-1 workload=gpu:NoSchedule

# Pod容忍GPU污点
tolerations:
- key: "workload"
  operator: "Equal"
  value: "gpu"
  effect: "NoSchedule"

拓扑分布约束

跨故障域（区域、节点）均匀分布Pods：

topologySpreadConstraints:
- maxSkew: 1  # Pod计数最大差异
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
    matchLabels:
      app: critical-app

有关高级调度模式，包括Pod优先级和抢占，请参阅references/scheduling-patterns.md。

网络

NetworkPolicies（零信任安全）

使用NetworkPolicies实施默认拒绝安全：

# 默认拒绝所有流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

# 允许特定入站（前端→后端）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-allow-frontend
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Ingress vs. Gateway API

Ingress（传统）:

广泛支持、成熟生态系统
表达能力有限
用于现有应用程序

Gateway API（现代）:

角色导向设计（集群运维vs.应用开发）
更强大表达能力（HTTPRoute、TCPRoute、TLSRoute）
推荐用于新应用程序（在Kubernetes 1.29+中GA）

# Gateway API示例
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-routes
spec:
  parentRefs:
  - name: production-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: backend
      port: 8080

有关详细网络模式，包括服务网格集成，请参阅references/networking.md。

存储

StorageClasses（定义性能层级）

StorageClasses为不同工作负载需求定义存储层级：

# AWS EBS SSD（高性能）
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  iopsPerGB: "50"
  encrypted: "true"
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
reclaimPolicy: Delete

存储决策矩阵

工作负载	性能	访问模式	Storage Class
数据库	高	ReadWriteOnce	SSD（gp3/io2）
共享文件	中等	ReadWriteMany	NFS/EFS
日志（临时）	低	ReadWriteOnce	标准HDD
ML模型	高	ReadOnlyMany	对象存储（S3）

访问模式:

ReadWriteOnce（RWO）: 单节点读写（最常见）
ReadOnlyMany（ROX）: 多节点只读
ReadWriteMany（RWX）: 多节点读写（需要网络存储）

有关详细存储操作，包括卷快照和CSI驱动，请参阅references/storage.md。

安全

RBAC（基于角色的访问控制）

使用RBAC实施最小权限访问：

# Role（命名空间范围）
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
# RoleBinding（将角色分配给用户）
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: production
subjects:
- kind: User
  name: jane@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Pod安全标准

在命名空间级别强制执行安全Pod配置：

# 命名空间带有限制PSS（最安全）
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Pod安全级别:

限制型: 最安全，移除所有特权提升（用于应用程序）
基线型: 最小限制，防止已知提升
特权型: 无限制（仅用于系统工作负载）

有关详细安全模式，包括策略强制执行（Kyverno/OPA）和密钥管理，请参阅references/security.md。

自动伸缩

Horizontal Pod Autoscaler（HPA）

基于CPU、内存或自定义指标扩展Pod副本：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 等待5分钟后再缩小

KEDA（事件驱动自动伸缩）

基于事件（队列、cron计划、Prometheus指标）扩展，超出CPU/内存：

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: rabbitmq-scaler
spec:
  scaleTargetRef:
    name: message-processor
  minReplicaCount: 0   # 队列空时缩放到零
  maxReplicaCount: 30
  triggers:
  - type: rabbitmq
    metadata:
      queueName: tasks
      queueLength: "10"  # 当>10条消息时扩展

自动伸缩决策矩阵

场景	使用HPA	使用VPA	使用KEDA	使用集群自动伸缩器
有流量峰值的无状态Web应用	✅	❌	❌	可能
单实例数据库	❌	✅	❌	可能
队列处理器（事件驱动）	❌	❌	✅	可能
Pods待定（节点不足）	❌	❌	❌	✅

有关详细自动伸缩模式，包括VPA和集群自动伸缩器配置，请参阅references/autoscaling.md。

故障排除

常见Pod问题

Pod卡在Pending状态:

kubectl describe pod <pod-name>

# 常见原因:
# - CPU/内存不足：减少请求或添加节点
# - 节点选择器不匹配：修复nodeSelector或添加标签
# - PVC未绑定：创建PVC或修复名称
# - 污点不容忍：添加容忍或移除污点

CrashLoopBackOff:

kubectl logs <pod-name>
kubectl logs <pod-name> --previous  # 检查先前崩溃

# 常见原因:
# - 应用程序崩溃：修复代码或配置
# - 缺少环境变量：添加到部署
# - 存活探针失败：增加initialDelaySeconds
# - OOMKilled：增加内存限制或修复泄漏

ImagePullBackOff:

kubectl describe pod <pod-name>

# 常见原因:
# - 镜像不存在：修复镜像名称/标签
# - 需要认证：创建imagePullSecrets
# - 网络问题：检查NetworkPolicies、防火墙规则

服务不可访问:

kubectl get endpoints <service-name>  # 应列出Pod IPs

# 如果endpoints为空:
# - 服务选择器不匹配Pod标签
# - Pods未就绪（就绪探针失败）
# - 检查NetworkPolicies阻塞流量

有关系统化故障排除手册，包括网络和存储问题，请参阅references/troubleshooting.md。

参考文档

深度解析

references/resource-management.md - 资源请求/限制、QoS类、ResourceQuotas、VPA
references/scheduling-patterns.md - 节点亲和性、污点/容忍、拓扑分布、优先级
references/networking.md - NetworkPolicies、Ingress、Gateway API、服务网格集成
references/storage.md - StorageClasses、PVCs、CSI驱动、卷快照
references/security.md - RBAC、Pod安全标准、策略强制执行、密钥
references/autoscaling.md - HPA、VPA、KEDA、集群自动伸缩器配置
references/troubleshooting.md - 系统化调试手册用于常见失败

示例

examples/manifests/ - 复制粘贴就绪的YAML清单
examples/python/ - 自动化脚本（审计、成本分析、验证）
examples/go/ - 操作器开发示例

工具

scripts/validate-resources.sh - 审计无资源限制的Pods
scripts/audit-networkpolicies.sh - 查找无NetworkPolicies的命名空间
scripts/cost-analysis.sh - 按命名空间资源成本细分

最佳实践总结

资源管理:

始终设置CPU/内存请求和限制
使用VPA进行自动调整大小
每个命名空间实施资源配额
监控实际使用情况 vs. 请求

调度:

使用拓扑分布约束实现高可用性
应用污点进行工作负载隔离（GPU、spot实例）
为关键工作负载设置Pod优先级

网络:

使用默认拒绝实施NetworkPolicies
新应用程序使用Gateway API
在入口层应用速率限制

存储:

使用CSI驱动（非传统供应器）
按性能层级定义StorageClasses
为有状态应用程序启用卷快照

安全:

强制执行Pod安全标准（应用程序使用限制型）
实施最小权限的RBAC
使用策略引擎进行护栏（Kyverno/OPA）
扫描镜像漏洞

自动伸缩:

无状态工作负载使用HPA
事件驱动工作负载使用KEDA
启用带限制的集群自动伸缩器
设置PodDisruptionBudgets以防止过度中断

Kubernetes集群运维Skill operating-kubernetes