k8s在centos上的資源分配如何

K8s在CentOS上的資源分配實踐指南

在CentOS系統上部署Kubernetes（K8s）集群后，資源分配是保障應用性能、集群穩定的核心環節，主要涉及節點資源準備、Pod資源請求與限制、QoS級別劃分、調度策略優化及特殊資源（如GPU）管理五大維度。

一、節點資源準備：系統級配置

在CentOS節點上部署K8s前，需完成以下基礎配置，確保資源分配的基礎環境合規：

• 關閉Swap分區：K8s要求節點禁用Swap以避免內存資源過度占用（Swap會影響Pod的內存限制執行）。執行swapoff -a臨時關閉，注釋/etc/fstab中的Swap行永久生效。
• 禁用SELinux：SELinux會限制容器對節點資源的訪問，需修改/etc/selinux/config文件，將SELINUX=enforcing改為SELINUX=disabled，并重啟系統。
• 關閉防火墻：避免防火墻攔截K8s組件間的通信（如kubelet與kube-apiserver），執行systemctl stop firewalld && systemctl disable firewalld。
• 配置靜態網絡：編輯/etc/sysconfig/network-scripts/ifcfg-ens33（網卡名以實際為準），設置固定IP、網關、DNS，確保節點間網絡互通。
• 安裝必要工具：安裝Docker（或其他CRI兼容容器運行時，如Containerd）作為容器引擎，安裝kubelet、kubeadm、kubectl用于集群管理。

二、Pod資源分配：核心參數（Requests與Limits）

Pod是K8s資源分配的最小單位，通過requests（請求）和limits（限制）兩個參數控制資源使用：

• requests：容器啟動時申請的最小資源量，K8s調度器會優先將Pod調度到“剩余資源≥Pod requests”的節點，確保Pod能獲得足夠的資源啟動。
• limits：容器運行時允許使用的最大資源量，當容器嘗試突破limits時，Kubelet會采取限制措施（如CPU節流）或驅逐Pod（內存超出）。

示例配置（以Nginx Pod為例）：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:alpine
    resources:
      requests:
        memory: "64Mi"  # 請求64MB內存
        cpu: "250m"     # 請求0.25核CPU（1核=1000m）
      limits:
        memory: "128Mi" # 限制最大128MB內存
        cpu: "500m"     # 限制最大0.5核CPU

配置原則：

• requests：基于應用實際基準測試的平均資源消耗，略低10%-20%（如應用平均使用350m CPU，設置為300m），避免因requests過高導致節點資源浪費。
• limits：高于應用峰值資源消耗（如峰值使用800m CPU，設置為1000m），防止應用因突發流量被誤殺，同時避免占用過多節點資源。

三、QoS級別：資源優先級劃分

K8s根據Pod的requests與limits關系，將Pod劃分為三個QoS（服務質量）級別，影響資源緊張時的驅逐順序：

• Guaranteed：requests == limits（且CPU為整數，如cpu: "1"），優先級最高，僅在節點資源完全耗盡時才會被驅逐。適用于關鍵業務（如數據庫）。
• Burstable：requests != limits（或CPU為小數，如cpu: "0.5"），優先級中等，當節點資源緊張時，會優先驅逐Burstable Pod（但高于BestEffort）。適用于大多數普通應用（如Web服務）。
• BestEffort：未設置requests/limits，優先級最低，當節點資源不足時，會最先被驅逐。適用于無狀態、可容忍中斷的應用（如測試任務）。

示例：

# Guaranteed（requests == limits，且CPU為整數）
resources:
  requests:
    cpu: "1"
    memory: "1Gi"
  limits:
    cpu: "1"
    memory: "1Gi"

# Burstable（requests != limits）
resources:
  requests:
    cpu: "0.5"
    memory: "512Mi"
  limits:
    cpu: "1"
    memory: "1Gi"

# BestEffort（未設置requests/limits）
resources: {}

四、調度策略優化：精準分配資源

K8s調度器通過節點親和性、污點/容忍度、拓撲感知調度等策略，實現資源的精準分配：

• 節點親和性（Node Affinity）：將Pod調度到帶有特定標簽的節點（如disk=ssd），提升I/O密集型應用的性能。

  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: disk
            operator: In
            values:
            - ssd
  

• 污點（Taints）與容忍度（Tolerations）：通過給節點打污點（如kubectl taint nodes node1 key=value:NoSchedule），限制普通Pod調度到該節點；若Pod需調度到污點節點，需配置對應的容忍度。適用于維護節點（如升級內核）或專用節點（如GPU節點）。
• 拓撲感知調度（Topology-Aware Scheduling）：利用K8s的CPU Manager功能，根據節點的NUMA拓撲結構分配CPU，減少CPU跨NUMA訪問的延遲（適用于CPU密集型應用）。需在kubelet配置中啟用--cpu-manager-policy=static。

五、特殊資源管理：GPU資源分配

若需在CentOS節點上運行GPU應用（如深度學習訓練），需安裝NVIDIA Device Plugin并配置GPU資源：

• 安裝NVIDIA Device Plugin：通過DaemonSet部署插件，自動發現節點上的GPU設備并注冊到K8s集群。

  kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.13.0/nvidia-device-plugin.yml
  

• 配置Pod使用GPU：在Pod的resources.limits中指定GPU數量（如nvidia.com/gpu: 1）。

  resources:
    limits:
      nvidia.com/gpu: 1  # 請求1個GPU
  

注意：GPU資源為集群級資源，需確保節點有足夠的GPU可用（通過kubectl describe node <node-name>查看GPU總量）。

六、資源監控與調整

資源分配并非一成不變，需通過監控工具（如Prometheus+Granafa）實時觀察節點和Pod的資源使用情況（CPU、內存、GPU利用率），并根據業務增長調整requests/limits：

• 查看節點資源使用：kubectl top nodes
• 查看Pod資源使用：kubectl top pods
• 調整Pod資源：通過kubectl edit pod <pod-name>修改requests/limits，或使用kubectl patch命令動態調整（如增加CPU請求）。

通過以上步驟，可在CentOS上實現K8s資源的合理分配，保障應用性能與集群穩定性。需根據實際業務場景（如CPU密集型、內存密集型、GPU加速型）調整配置，遵循“基于測量、留有余地”的原則，避免資源浪費或不足。