Ubuntu上Kubernetes的资源如何分配

Ubuntu上Kubernetes资源分配指南

在Ubuntu系统上部署Kubernetes集群时，资源分配是保障应用性能、集群稳定性的核心环节。合理的资源分配需结合请求与限制设置、调度策略、自动扩缩及监控优化等多维度措施，以下是具体实施方案：

一、基础概念：Requests与Limits

资源分配的核心是资源请求（Requests）和资源限制（Limits），二者共同定义了容器的资源边界：

• Requests（请求）：容器启动时所需的最小资源量，是Kubernetes调度器判断节点是否可容纳Pod的关键依据。只有当节点上可分配的CPU/内存资源≥Pod的Requests值时，Pod才会被调度到该节点。
• Limits（限制）：容器可使用的最大资源量，用于防止容器过度消耗资源（如内存溢出导致节点崩溃）。超过Limits的容器会被限制（CPU）或杀死（内存，触发OOM）。

示例配置（YAML）：

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"  # 0.25核
      limits:
        memory: "128Mi"
        cpu: "500m"  # 0.5核

单位说明：

• CPU：m表示毫核（1核=1000m），如500m=0.5核；
• 内存：Mi=兆字节、Gi=吉字节（推荐使用二进制单位，避免十进制混淆）。

二、Requests与Limits设置技巧

1. 根据应用负载调整：
   • 有状态/稳态应用（如数据库、Redis）：设置较高的Requests（如数据库需预留足够内存），确保性能稳定；
   • 无状态/波动性应用（如Web服务、批处理）：设置略高于平均负载的Requests，避免资源浪费。
2. 避免极端配置：
   • Requests不宜过高：会导致节点资源碎片化，降低集群利用率；
   • Limits不宜过低：可能导致应用因资源不足被杀死（如内存不足触发OOM）。
3. QoS等级优化： Kubernetes根据Requests/Limits配置将Pod分为三类QoS等级，影响调度和驱逐优先级：
   • Guaranteed：CPU和内存均设置Requests=Limits（如requests.cpu: "1", limits.cpu: "1"），适用于关键业务（如数据库），享有最高优先级；
   • Burstable：至少一个资源设置Requests（如requests.cpu: "500m", limits.cpu: "1"），适用于普通应用（如Web服务），平衡性能与资源利用率；
   • BestEffort：未设置Requests/Limits（默认），适用于临时任务（如测试），优先级最低，易被驱逐。

三、调度策略：精准分配节点资源

1. 节点选择器（NodeSelector）： 通过标签将Pod调度到特定节点（如带gpu=true标签的节点运行AI应用）。示例：

   spec:
     nodeSelector:
       gpu: "true"  # 仅调度到带有gpu=true标签的节点
   

2. 亲和性与反亲和性（Affinity/Anti-Affinity）：
   • 亲和性（Affinity）：将Pod调度到满足条件的节点（如“与Redis Pod在同一节点”，提升数据访问速度）；
   • 反亲和性（Anti-Affinity）：将Pod调度到不满足条件的节点（如“不在同一节点运行多个副本”，提高高可用性）。 示例（反亲和性）：

   affinity:
     podAntiAffinity:
       requiredDuringSchedulingIgnoredDuringExecution:
       - labelSelector:
           matchExpressions:
           - key: app
             operator: In
             values:
             - my-app
         topologyKey: "kubernetes.io/hostname"  # 不在同一节点运行
   

3. 污点（Taint）与容忍（Toleration）：
   • 污点：给节点添加污点（如kubectl taint nodes node1 key=value:NoSchedule），阻止不兼容的Pod调度；
   • 容忍：Pod配置容忍规则（如tolerations字段），允许调度到带污点的节点（如特殊应用需要运行在不稳定的节点上）。

四、自动扩缩：动态适配负载变化

1. 水平Pod自动伸缩（HPA）： 根据CPU/内存使用率或自定义指标（如QPS）自动调整Pod副本数，应对流量波动。示例配置：

   apiVersion: autoscaling/v2
   kind: HorizontalPodAutoscaler
   metadata:
     name: my-hpa
   spec:
     scaleTargetRef:
       apiVersion: apps/v1
       kind: Deployment
       name: my-deployment
     minReplicas: 2
     maxReplicas: 10
     metrics:
     - type: Resource
       resource:
         name: cpu
         target:
           type: Utilization
           averageUtilization: 70  # CPU利用率达到70%时扩容
   

2. 垂直Pod自动伸缩（VPA）： 根据Pod的历史资源使用情况，自动调整Requests/Limits（如从500mCPU提升至1核），无需修改YAML。需配合kubectl apply -f vpa.yaml部署VPA控制器。

五、资源配额：控制命名空间资源使用

通过ResourceQuota限制命名空间的资源总量，防止单个团队/应用占用过多集群资源。示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-quota
  namespace: my-namespace
spec:
  hard:
    requests.cpu: "4"       # 命名空间内所有Pod的CPU Requests总和不超过4核
    requests.memory: "8Gi"  # 内存Requests总和不超过8Gi
    limits.cpu: "8"         # CPU Limits总和不超过8核
    limits.memory: "16Gi"   # 内存Limits总和不超过16Gi
    pods: "20"              # Pod数量不超过20个

作用：

• 避免资源竞争，保障关键业务的资源使用权；
• 促进多团队/应用的公平共享。

六、监控与优化：持续调整资源分配

1. 监控工具： 使用kubectl top命令或Prometheus+Grafana监控集群/节点/Pod的资源使用情况（CPU、内存、磁盘、网络），识别瓶颈（如某Pod内存使用率长期≥90%）。
2. 优化措施：
   • 根据监控数据调整Requests/Limits（如某应用平均内存使用量为200Mi，可将Requests从128Mi提升至256Mi）；
   • 清理无用资源（如终止闲置的Pod、删除未使用的镜像）；
   • 升级节点配置（如增加节点CPU/内存，提升集群整体容量）。

通过以上步骤，可在Ubuntu系统上为Kubernetes集群实现精准、动态、安全的资源分配，确保应用性能与集群稳定性的平衡。

声明：本文内容由网友自发贡献，本站不承担相应法律责任。对本内容有异议或投诉，请联系2913721942#qq.com核实处理，我们将尽快回复您，谢谢合作！