本文為您介紹節點與節點池常見問題。例如，如何更改節點的Pod數量，如何更換節點池的OS鏡像，如何解決節點相關timeout問題等。
索引
關於節點異常問題的診斷流程、排查思路、常見問題及解決方案，請參見節點異常問題排查。
分類 | FAQ |
節點池建立階段 | |
節點池管理 |
|
節點池升級 | |
調整可使用的節點Pod數量 | |
節點運行時從Docker遷移至containerd | |
虛擬節點 |
如何在節點池中選用搶佔型執行個體？
可以通過建立節點池或者spot-instance-advisor命令列的方式使用搶佔型執行個體，請參見搶佔式執行個體節點池最佳實務。
為保證節點池的統一，不支援隨用隨付、訂用帳戶節點池修改為搶佔式執行個體節點池；也不支援搶佔式執行個體節點池修改為隨用隨付、訂用帳戶節點池。
一個節點池中可以配置不同的ECS執行個體規格嗎？
可以。推薦您為節點池同時配置多個VSwitch，在多個可用性區域中選擇多個ECS執行個體規格，或通過指定vCPU、記憶體等維度配置執行個體規格，以避免由於執行個體規格不可用或庫存不足導致節點池彈出節點失敗。您可以參照控制台的彈性強度建議添加執行個體規格，也可以建立節點池後查看節點池彈性強度。
請參見ECS執行個體規格配置建議瞭解ACK不支援的執行個體規格並擷取節點的配置建議。
如何計算節點的Pod數量上限？
根據網路外掛程式的不同，Pod數量上限計算方式不同，請參見節點最大Pod數說明。
Terway：單節點支援的最大Pod數=節點最大容器網路Pod數+主機網路Pod數。
Flannel：建立叢集時配置的節點 Pod 數量即為節點的Pod數量上限。
您可以在控制台的節點頁面的節點列表，查看Pod數量上限，即容器組總額度。
節點的Pod數量上限均不支援修改。當Pod數量達到上限時，推薦您通過節點擴容等手段提升可使用的Pod數量。詳細資料，請參見調整可使用的節點Pod數量。
Pod數量達到上限時，如何調整可使用的節點Pod數量？
單Worker節點支援的最大Pod數受網路外掛程式類型影響，在大部分情境下不支援變更。在Terway模式下，單節點支援的最大Pod數依賴於ECS執行個體所提供的彈性網卡數量；在Flannel模式下，單節點最大Pod數在建立叢集時指定。指定後不支援修改。Pod數量達到上限時，推薦您通過擴容節點池增加節點，提升可使用的Pod數量。
詳細資料，請參見調整可使用的節點Pod數量。
如何更改節點配置？
為了業務的平穩運行，部分配置項（尤其是節點池可用性相關和網路相關的配置）在建立後不支援調整。例如，容器運行時、節點所屬VPC等配置項不支援修改。
針對部分支援修改的配置項，在節點池配置更新後，除特殊說明情境外（例如同步更新存量節點的 ECS 標籤、同步更新存量節點的標籤（Labels）及汙點（Taints）），不會修改節點池已有節點的配置，僅作用於新增節點。
關於支援和不支援修改的配置項及其生效情況說明，請參見編輯節點池。
如需運行一個新配置的節點，您也可以按照新配置建立一個新節點池，將舊節點池中的節點設定為不可調度，然後對其排水。等待業務全量遷移到新節點後再釋放舊節點。操作入口，請參見節點排水和調度狀態。
是否支援關閉期望節點數功能？
如果節點池的擴縮容模式為手動，您需要配置節點池的期望節點數。該功能不支援關閉。
如果您想移除、釋放指定節點，請參見移除節點。如果您想添加指定節點，請參見添加已有節點。移除節點或添加已有節點後，期望節點數自動適配為調整後的節點數，無需人為修改。
開啟期望節點數與未開啟期望節點數的節點池有什麼不同？
期望節點數是指節點池應該維持的節點數量。您可以通過調整期望節點數，達到擴容或縮容節點池的目的。但部分老節點池沒有設定到期望節點數，從而未開啟期望節點數功能。
開啟或未開啟期望節點數的節點池對於移除節點、釋放ECS等不同的操作方式，會有不同感知，具體如下表。
操作 | 開啟期望節點數節點池 | 未開啟期望節點數節點池 | 建議 |
通過ACK的OpenAPI或者控制台縮小期望節點數進行縮容。 | 縮小期望節點數後，將縮容節點池內節點，直到滿足指定的期望節點數量。 | 如果節點池內當前節點數大於期望節點數，將縮容節點，直到滿足最終期望節點數量，並將開啟期望節點數功能。 | 無。 |
通過ACK的OpenAPI或者控制台移除指定節點。 | 移除指定節點，期望節點數減少移除節點的數目。例如節點池移除指定節點前，期望節點數為10。移除3個節點後，期望節點數更新為7。 | 移除指定節點。 | 無。 |
通過 | 期望節點數不會改變。 | 無變化。 | 不推薦。 |
手動通過ECS控制台或者OpenAPI釋放ECS。 | 產生新ECS執行個體，補充到設定的期望節點數中。 | 節點池不感知。不會有新ECS執行個體產生。節點池中被刪除的節點會顯示狀態為“未知”一段時間。 | 不推薦，會導致ACK、ESS資料與實際情況不一致，請使用推薦方式移除節點。具體操作，請參見移除節點。 |
訂用帳戶ECS執行個體到期。 | 產生新的ECS執行個體，補充到設定的期望節點數。 | 節點池不感知。不會有新ECS執行個體產生。節點池節點列表中被刪除的節點會顯示狀態為“未知”一段時間。 | 不推薦，會導致ACK、ESS資料與實際情況不一致，請使用推薦方式移除節點。具體操作，請參見移除節點。 |
ESS伸縮組手動開啟“執行個體的健全狀態檢查”，並且ECS執行個體無法通過ESS健全狀態檢查（如停機）。 | 產生新ECS執行個體，補充到設定的期望節點數。 | 產生新ECS執行個體，替換停機執行個體。 | 不推薦，請不要直接動作節點池相關的伸縮組。 |
通過ESS將ECS執行個體從伸縮組中移除，並且不修改期望執行個體數。 | 產生新ECS執行個體，補充到設定的期望節點數。 | 不會產生新的ECS執行個體。 | 不推薦，請不要直接動作節點池相關的伸縮組。 |
如何將游離節點（沒有節點池納管的節點）添加到節點池？
在ACK節點池功能發布之前建立的老叢集中，可能存在未被節點池管理的游離Worker節點。如果不再需要這些節點，可直接釋放對應的ECS執行個體。若需保留，建議將其納入節點池，以便實現分組管理和自動化營運。
您可以建立並擴容一個節點池，將游離節點移除後添加到節點池中，請參見遷移游離節點至節點池。
如何更換節點池OS鏡像？
您可以按需切換作業系統類型，例如將已經停止維護（EOL）的作業系統更換為支援中的作業系統。更換前，請參見作業系統鏡像發布記錄瞭解ACK支援的作業系統類型、作業系統鏡像最新版本，以及部分作業系統的使用限制。
關於更換作業系統的注意事項及具體步驟，請參見更換作業系統。
如何釋放指定的ECS執行個體？
請通過移除節點，釋放指定的ECS執行個體。釋放ECS執行個體後，期望節點數自動適配到釋放後的節點數量，無需人為修改。另外，修改期望節點數並不能釋放指定的ECS執行個體。
添加已有節點後報錯，提示timeout，怎麼辦？
請排查節點與API Server CLB的網路是否可以連通，請先排查安全性群組是否符合要求。添加已有節點時安全性群組的使用限制，請參見上文使用限制。關於網路不通的其他問題，請參見網路管理FAQ。
如何更改ACK叢集中Worker節點的主機名稱？
叢集建立完成後，不支援自訂Worker節點的主機名稱，但是您可以通過節點池的節點命名規則來修改Worker節點的主機名稱。
建立叢集時，您可以在自訂節點名稱參數中定義Worker節點的主機名稱，請參見建立ACK託管叢集。
如何在已有叢集的GPU節點上手動升級Kernel？
下面為您介紹如何在已有叢集的GPU節點上手動升級Kernel。
當前kernel版本低於3.10.0-957.21.3。
請確認需要升級的目標kernel版本，並謹慎操作。
本文提供方案並不涉及kernel升級，僅針對在kernel升級的前提下對應的Nvidia驅動升級。
將GPU節點設定為不可調度（本例以節點 cn-beijing.i-2ze19qyi8votgjz*****為例）。
kubectl cordon cn-beijing.i-2ze19qyi8votgjz***** node/cn-beijing.i-2ze19qyi8votgjz***** already cordoned將要升級驅動的GPU節點進行排水。
kubectl drain cn-beijing.i-2ze19qyi8votgjz***** --grace-period=120 --ignore-daemonsets=true node/cn-beijing.i-2ze19qyi8votgjz***** cordoned WARNING: Ignoring DaemonSet-managed pods: flexvolume-9scb4, kube-flannel-ds-r2qmh, kube-proxy-worker-l62sf, logtail-ds-f9vbg pod/nginx-ingress-controller-78d847fb96-***** evicted卸載當前的nvidia-driver。
說明本步驟中卸載的是版本為384.111的驅動包，如果您的驅動版本不是384.111，則需要在Nvidia官網下載對應的驅動安裝包，並將本步驟中的
384.111替換成您實際的版本。登入到該GPU節點，通過
nvidia-smi查看驅動版本。sudo nvidia-smi -a | grep 'Driver Version' Driver Version : 384.111下載Nvidia驅動安裝包。
cd /tmp/ sudo curl -O https://cn.download.nvidia.cn/tesla/384.111/NVIDIA-Linux-x86_64-384.111.run說明需要在安裝包中卸載Nvidia。
卸載當前Nvidia驅動。
sudo chmod u+x NVIDIA-Linux-x86_64-384.111.run sudo sh ./NVIDIA-Linux-x86_64-384.111.run --uninstall -a -s -q
升級Kernel。
您可以根據需要升級Kernel。
重啟GPU機器。
sudo reboot重新登入GPU節點，安裝對應的kernel devel。
sudo yum install -y kernel-devel-$(uname -r)請到Nvidia官網下載和安裝您需要的Nvidia驅動， 本文以410.79為例。
# 切換到/tmp目錄 cd /tmp/ # 下載NVIDIA驅動安裝包 sudo curl -O https://cn.download.nvidia.cn/tesla/410.79/NVIDIA-Linux-x86_64-410.79.run # 為安裝包添加可執行許可權 sudo chmod u+x NVIDIA-Linux-x86_64-410.79.run # 以靜默方式運行安裝程式 sudo sh ./NVIDIA-Linux-x86_64-410.79.run -a -s -q # Warm up GPU sudo nvidia-smi -pm 1 || true sudo nvidia-smi -acp 0 || true sudo nvidia-smi --auto-boost-default=0 || true sudo nvidia-smi --auto-boost-permission=0 || true sudo nvidia-modprobe -u -c=0 -m || true查看 /etc/rc.d/rc.local，確認其中是否包含以下配置，如果沒有請手動添加。
sudo nvidia-smi -pm 1 || true sudo nvidia-smi -acp 0 || true sudo nvidia-smi --auto-boost-default=0 || true sudo nvidia-smi --auto-boost-permission=0 || true sudo nvidia-modprobe -u -c=0 -m || true重啟kubelet和Docker。
sudo service kubelet stop sudo service docker restart sudo service kubelet start將此GPU節點重新設定為可調度。
kubectl uncordon cn-beijing.i-2ze19qyi8votgjz***** node/cn-beijing.i-2ze19qyi8votgjz***** already uncordoned在GPU節點上的device plugin pod驗證版本。
kubectl exec -n kube-system -t nvidia-device-plugin-cn-beijing.i-2ze19qyi8votgjz***** nvidia-smi Thu Jan 17 00:33:27 2019 +-----------------------------------------------------------------------------+ | NVIDIA-SMI 410.79 Driver Version: 410.79 CUDA Version: N/A | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 Tesla P100-PCIE... On | 00000000:00:09.0 Off | 0 | | N/A 27C P0 28W / 250W | 0MiB / 16280MiB | 0% Default | +-------------------------------+----------------------+----------------------+ +-----------------------------------------------------------------------------+ | Processes: GPU Memory | | GPU PID Type Process name Usage | |=============================================================================| | No running processes found | +-----------------------------------------------------------------------------+說明如果通過
docker ps命令，發現GPU節點沒有容器被啟動，請參見修複GPU節點容器啟動問題。
修複GPU節點容器啟動問題
在某些特定Kubernetes版本中的GPU節點上，重啟kubelet和Docker時，發現沒有容器被啟動。
sudo service kubelet stop
# Redirecting to /bin/systemctl stop kubelet.service
sudo service docker stop
# Redirecting to /bin/systemctl stop docker.service
sudo service docker start
# Redirecting to /bin/systemctl start docker.service
sudo service kubelet start
# Redirecting to /bin/systemctl start kubelet.service
sudo docker ps
# CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES執行以下命令，查看Docker的Cgroup Driver。
sudo docker info | grep -i cgroup
Cgroup Driver: cgroupfs此時發現的Cgroup Driver類型是cgroupfs。
您可以按照以下操作，修複該問題。
備份/etc/docker/daemon.json，完成後，執行以下命令更新/etc/docker/daemon.json。
sudo cat >/etc/docker/daemon.json <<-EOF { "default-runtime": "nvidia", "runtimes": { "nvidia": { "path": "/usr/bin/nvidia-container-runtime", "runtimeArgs": [] } }, "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m", "max-file": "10" }, "oom-score-adjust": -1000, "storage-driver": "overlay2", "storage-opts":["overlay2.override_kernel_check=true"], "live-restore": true } EOF執行以下命令，重啟Docker和kubelet。
sudo service kubelet stop # Redirecting to /bin/systemctl stop kubelet.service sudo service docker restart # Redirecting to /bin/systemctl restart docker.service sudo service kubelet start # Redirecting to /bin/systemctl start kubelet.service執行以下命令，確認Docker的Cgroup Driver的類型為systemd。
sudo docker info | grep -i cgroup Cgroup Driver: systemd
節點故障時，如何將節點Pod批量轉移到其他節點上重新部署？
您可以將故障節點設定為不可調度並進行排水，將故障節點的應用Pod逐步遷移至新節點。
登入Container Service管理主控台，在節點頁面的操作列，選擇更多>節點排水。此操作會將舊節點設定為不可調度狀態，將舊節點池的應用逐步遷移至新節點池。
排查故障節點問題。關於故障排查的思路，請參見節點異常問題排查。
有跨可用性區域節點的叢集發生故障時，叢集會如何決定節點驅逐策略？
通常情況下，當節點發生故障時，節點Controller會驅逐不健康的節點，驅逐速率--node-eviction-rate預設為0.1個/秒，即每10秒鐘內至多從一個節點驅逐Pod。
而一個存在多個可用性區域節點的ACK叢集發生故障時，節點Controller會根據可用性區域的狀態以及叢集大小來決定如何驅逐。
可用性區域故障分為三種情況。
FullDisruption：該可用性區域不存在正常節點，且至少有1個異常節點。
PartialDisruption：該可用性區域至少有2個異常節點，並且異常節點的比例，即
（異常節點/(異常節點+正常節點)），大於0.55。Normal：除FullDisruption和PartialDisruption兩種情況外，其餘均為Normal狀態。
在此情境下，叢集大小分為兩種情況：
大叢集：大於50個節點的叢集。
小叢集：小於等於50個節點的叢集。
在三種故障狀態下，節點Controller的驅逐速率計算方式如下：
如果所有可用性區域都處於FullDisruption狀態，則關閉系統所有可用性區域的驅逐功能。
如果不是所有可用性區域都處於FullDisruption狀態，驅逐速率通過以下方式確定。
如果某個可用性區域處於FullDisruption狀態，那麼驅逐速率設定為正常值（0.1），不受叢集大小影響。
如果某個可用性區域處於PartialDisruption狀態，那麼驅逐速率受叢集大小因素影響。在大叢集中，該可用性區域的驅逐速率為0.01；在小叢集中，該可用性區域的驅逐速率為0，即不進行驅逐。
如果某個可用性區域處於Normal狀態，那麼驅逐速率設定為正常值（0.1），不受叢集大小因素影響。
更多資訊，請參見逐出速率限制。
ACK叢集中kubelet目錄路徑是什嗎？支援自訂嗎？
ACK不支援自訂kubelet路徑。kubelet路徑預設為/var/lib/kubelet，請勿更改。
ACK節點池中資料盤可以自訂目錄掛載嗎？
自訂目錄掛載功能目前處於灰階發布中，請提交工單申請。開啟此功能後，可自動將節點池中添加的資料盤格式化並掛載到作業系統中的指定目錄上。但掛載目錄存在以下限制。
請勿掛載到以下作業系統重要目錄上：
/
/etc
/var/run
/run
/boot
請勿掛載到以下系統及容器運行時所使用的目錄及其子目錄：
/usr
/bin
/sbin
/lib
/lib64
/ostree
/sysroot
/proc
/sys
/dev
/var/lib/kubelet
/var/lib/docker
/var/lib/containerd
/var/lib/container
不同資料盤的掛載目錄不可重複。
掛載目錄必須是以
/開頭的絕對路徑。掛載目錄中不能包含斷行符號和換行字元（C語言逸出字元
\r和\n），不能以反斜線字元\結尾。
如何修改最大檔案控制代碼數？
最大檔案控制代碼數即開啟檔案數的最大限制，Alibaba Cloud Linux和CentOS系統中包含兩個維度檔案控制代碼限制：
系統層級：所有使用者的進程能夠同時開啟檔案數的上限。
使用者層級：單個使用者進程能夠開啟檔案數的上限。
在容器環境中，還有另一個檔案控制代碼限制，即容器內部單進程的最大檔案控制代碼數。
在節點池升級情境下，通過黑屏命令自訂修改的最大檔案控制代碼數配置可能會被覆蓋。推薦使用編輯節點池進行配置。
修改節點系統級最大檔案控制代碼數
修改節點單進程最大檔案控制代碼數
登入節點，查看/etc/security/limits.conf檔案。
cat /etc/security/limits.conf通過以下參數配置節點單進程最大檔案控制代碼數：
... root soft nofile 65535 root hard nofile 65535 * soft nofile 65535 * hard nofile 65535執行
sed命令，修改最大檔案控制代碼數（其中65535為最大檔案控制代碼數的建議取值）。sed -i "s/nofile.[0-9]*$/nofile 65535/g" /etc/security/limits.conf重新登入節點，執行以下命令檢查修改是否生效。
當返回與修改值一致時，表明修改正確。
# ulimit -n 65535
修改容器最大檔案控制代碼數
修改容器最大檔案控制代碼數將會重啟Docker或containerd進程。請在業務低峰期謹慎操作。
登入節點，執行以下命令查看設定檔。
containerd節點：
cat /etc/systemd/system/containerd.serviceDocker節點：
cat /etc/systemd/system/docker.service
容器單進程最大檔案控制代碼數通過以下參數設定：
... LimitNOFILE=1048576 ******單進程最大檔案控制代碼數 LimitNPROC=1048576 ******最大進程數 ...執行如下命令，修改對應參數取值（其中1048576為最大檔案控制代碼數的建議取值）。
containerd節點：
sed -i "s/LimitNOFILE=[0-9a-Z]*$/LimitNOFILE=65536/g" /etc/systemd/system/containerd.service;sed -i "s/LimitNPROC=[0-9a-Z]*$/LimitNPROC=65537/g" /etc/systemd/system/containerd.service && systemctl daemon-reload && systemctl restart containerdDocker節點：
sed -i "s/LimitNOFILE=[0-9a-zA-Z]*$/LimitNOFILE=1048576/g" /etc/systemd/system/docker.service && sed -i "s/LimitNPROC=[0-9a-zA-Z]*$/LimitNPROC=1048576/g" /etc/systemd/system/docker.service && systemctl daemon-reload && systemctl restart docker
執行以下命令，查看容器單進程最大檔案控制代碼數。
當返回與修改值一致時，表明修改正確。
containerd節點：
# cat /proc/`pidof containerd`/limits | grep files Max open files 1048576 1048576 filesDocker節點：
# cat /proc/`pidof dockerd`/limits | grep files Max open files 1048576 1048576 files
對於不屬於任何節點池的Worker節點，如何升級它的容器運行時？
ACK節點池功能推出前建立的老叢集中，可能存在未被節點池管理的游離Worker節點。如需升級節點的容器運行時，您將該節點納入節點池進行管理。
按照如下步驟進行操作：
為什麼控制台顯示節點所屬節點池的來源為“其他節點”？
ACK 提供控制台、OpenAPI、CLI等方式向叢集中增加節點算力資源，請參見添加已有節點。如果您通過其他方式向叢集中添加了節點，ACK無法識別此類節點的來源，會在節點頁面的節點列表顯示其對應的節點池為其他節點。針對此類節點，ACK無法通過節點池來納管，無法提供節點生命週期管理、自動化營運和支援人員等產品能力。
如需繼續使用此類節點，請自行確保此類節點與叢集組件的相容性，並承擔由此引發的潛在風險，包括但不僅限於：
版本相容性：叢集控制面、系統組件升級時，節點上存量的作業系統、組件可能無法與新版本相容，可能存在業務異常風險。
工作負載調度相容性：節點對象中可用性區域、資源餘量等狀態無法評估是否能夠準確上報，無法評估上層工作負載的調度配置能夠正確應用，可能存在可用性、效能降級風險。
資料面相容性：節點側組件和作業系統與叢集的控制面和系統組件相容性未經評估，可能存在相容性風險。
營運操作相容性：在控制台、OpenAPI 中執行資料面節點營運操作過程中，由於節點的營運通道、執行環境未經評估，可能導致營運操作失效或產生異常結果。
如何為節點所在的交換器配置網路ACL？
當節點池所配置的交換器關聯了網路ACL後，若未放通必要網段，新節點將無法正常加入，節點將處於失敗或離線狀態。
請按照如下步驟放通網段並重新添加節點：