為什么在遠程kubelet無法訪問時不會重新安排pod
[英]Why pods aren't rescheduled when the remote kubelet is unreachable
問題描述
我目前正在對kubernetes集群進行一些測試。 我想知道為什么在某些情況下不會重新安排吊艙：
- 節點無法訪問時
- 當遠程小冊子沒有回答時
實際上，當一個吊艙被重新安排時，唯一的情況是當kubelet通知主人。 這是故意的嗎？ 為什么？ 如果我關閉了一個服務器，其中有一個運行獨特pod的rc，我的服務就會關閉。
也許有些事我誤解了。
此致，Smana
1 個解決方案
解決方案1
4 2015-09-04 10:18:24
檢測無法訪問的節點和重新調度pod有一個很長的默認超時，也許你沒有等待足夠長的時間？
您可以使用多個標志調整超時：
- kubelet上的node-status-update-frequency（ http://kubernetes.io/v1.0/docs/admin/kubelet.html ）
- kube-controller-manager上的node-monitor-grace-period和pod_eviction_timeout（ http://kubernetes.io/v1.0/docs/admin/kube-controller-manager.html ）
當 Pod 未成功啟動時，如何識別/失敗 Azure Devops 管道
[英]How to identify/Fail the Azure Devops pipeline when the pods aren't successfully started
我的 Pod 獲得 SIGTERM 並作為信號處理程序的一部分正常退出，但無法找到為什么 SIGTERM 從 kubelet 發送到我的 pod 的根本原因？
[英]My Pods getting SIGTERM and exited gracefully as part of signalhandler but unable to find root cause of why SIGTERM sent from kubelet to my pods?
Kubernetes：沒有資源請求的被驅逐的 Pod 是否能成功重新調度？
[英]Kubernetes: do evicted pods with no resource requests get rescheduled successfully?
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.
相關問題
為什么重新安排時 OOMKilled 吊艙沒有准備好？
獲取未運行的 Kubernetes pod 的計數
當 Pod 未成功啟動時，如何識別/失敗 Azure Devops 管道
我的 Pod 獲得 SIGTERM 並作為信號處理程序的一部分正常退出，但無法找到為什么 SIGTERM 從 kubelet 發送到我的 pod 的根本原因？
Kubernetes：沒有資源請求的被驅逐的 Pod 是否能成功重新調度？
Sparklyr k8s gClouid - Pod 未運行
即使刪除Pod，kubelet仍會記錄洪水
/var/lib/kubelet/pods 下的目錄權限
注冊節點時，kubelet似乎沒有使用正確的用戶
運行 kubelet 時出錯
相關標簽