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设置技巧

根据应用负载调整：
- 有状态/稳态应用（如数据库、Redis）：设置较高的Requests（如数据库需预留足够内存），确保性能稳定；
- 无状态/波动性应用（如Web服务、批处理）：设置略高于平均负载的Requests，避免资源浪费。
避免极端配置：
- Requests不宜过高：会导致节点资源碎片化，降低集群利用率；
- Limits不宜过低：可能导致应用因资源不足被杀死（如内存不足触发OOM）。
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（默认），适用于临时任务（如测试），优先级最低，易被驱逐。

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

节点选择器（NodeSelector）：通过标签将Pod调度到特定节点（如带gpu=true标签的节点运行AI应用）。示例：
```
spec:
  nodeSelector:
    gpu: "true"  # 仅调度到带有gpu=true标签的节点
```
亲和性与反亲和性（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"  # 不在同一节点运行
```
污点（Taint）与容忍（Toleration）：
- 污点：给节点添加污点（如kubectl taint nodes node1 key=value:NoSchedule），阻止不兼容的Pod调度；
- 容忍：Pod配置容忍规则（如tolerations字段），允许调度到带污点的节点（如特殊应用需要运行在不稳定的节点上）。

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

水平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%时扩容

垂直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个

作用：

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

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

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

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