1. 鏡像倉庫被設置爲公有，導致鏡像泄露風險：
錯誤現象：
公有鏡像倉庫可能會被雲上其它用戶拉取，導致泄露鏡像安全風險；部分運維或者開發同學，因爲沒有設置準確的 secret 到 Deployment，爲了解決無法拉取鏡像問題，直接開放鏡像倉庫爲公有。
解決方法：
鏡像倉庫的命名空間一定要設置爲私有，準確設置綁定雲效中docker 鏡像賬號，通過雲效發佈應用；
嚴格設定容器鏡像倉庫的維護權限；
2. 鏡像拉取失敗：
錯誤現象：
## 查看 pod 部署日誌
kubectl logs {pod}
## 錯誤信息
Failed to pull image "registry-vpc.{region_id}.aliyuncs.com/{app_name}-daily/{app_name}:20190823150817":
rpc error: code = Unknown desc = Error response from daemon:
pull access denied for registry-vpc.{region_id}.aliyuncs.com/{app_name}-daily/{app_name}, repository does not exist or may require 'docker login'錯誤原因：
- 當前 tag 的鏡像不存在、鏡像地址錯誤、鏡像網絡不通，沒法訪問；
解決方法：
只需修改正確地址或者打通網絡即可；
- Deployment 或者 Statefulset 的imagePullSecrets 沒有設置或者設置錯誤
解決方法：
控制檯或者使用命令建立保密字典，然後使用 imagePullSecrets 引入，或者自己建立 Secret:
## deplyment yaml 設置：
imagePullSecrets:
- name: acr-credential-be5ac8be6a88c42ac1d831b85135a585 3. SLB被容器服務清除，導致故障，需要重建和安全配置：
錯誤現象:
與容器服務關聯配置的負載均衡(SLB)被清除；
錯誤原因:
因爲有狀態副本或者 Deployment集部署刪除，存在級聯刪除 Service 情況，開發和運維人員使用重建方式修改自己配置的時候，導致 service 級聯相應 SLB 被刪除，導致故障，需要緊急重建 SLB 並多方增加訪問控制等配置。
Service 配置任意修改或者刪除，比如將 SLB 模式修改爲 NodePort 或者 Cluster 模式，導致 SLB 負載均衡配置被清除。
解決與防止方法：
kubernetes 使用 NodePort，再通過手動建立負載均衡(SLB)與 NodePort 關聯，解耦 Service 與 SLB 級聯關係。
使用 Ingress 暴露服務，Service 使用虛擬集羣 IP，與 Ingress 關聯。
使用此種方式需要注意 SLB 到後端服務的負載均衡，具體參考負載均衡 中負載均衡請求部分。
4. ECS 添加到集羣失敗：
錯誤現象:
集羣增加已有節點或者擴容失敗。
錯誤日誌例如下：
2019-07-31 19:44:59cf7c629dbf1dc4088a5a6b316fa5e561a | Wait k8s node i-9dpfd2n6ijvdd5tb642r join cluster timeout
2019-07-31 19:44:59cf7c629dbf1dc4088a5a6b316fa5e561a | Failed to check instance i-9dpfd2n6ijvdd5tb642r healthy : Wait for cn-north-2-gov-1.i-9dpfd2n6ijvdd5tb642r join to cluster cf7c629dbf1dc4088a5a6b316fa5e561a timeout
2019-07-31 19:44:59cf7c629dbf1dc4088a5a6b316fa5e561a | Failed to init instance i-9dpfd2n6ijvdd5tb642r, err Wait for cn-north-2-gov-1.i-9dpfd2n6ijvdd5tb642r join to cluster cf7c629dbf1dc4088a5a6b316fa5e561a timeout
2019-07-31 19:44:59cf7c629dbf1dc4088a5a6b316fa5e561a | Failed to attach node i-9dpfd2n6ijvdd5tb642r, err Wait for cn-north-2-gov-1.i-9dpfd2n6ijvdd5tb642r join to cluster cf7c629dbf1dc4088a5a6b316fa5e561a timeout 錯誤原因:
- 單個集羣內節點數量配額達到閾值，導致 ECS 幾點沒法加入；
- 虛擬網絡 VPC中路由表的路由條目達到閾值,導致新增節點沒法添加路由條目；
- kubernetes apiserver 的 SLB 負載均衡設置有訪問控制，導致添加的 ECS 沒法訪問 ApiServer;
- 添加的 ECS 節點自身安全組限制或者底層網絡故障，導致沒法訪問 apiserver;
解決方法:
- 聯繫阿里雲同學增加集羣或者路由表閾值；
- 配置 SLB 訪問控制，增加白名單；
- 配置安全組，增加白名單，或者重建 ECS，釋放故障 ECS;
5. 集羣中，個別 POD 網絡訪問不通：
錯誤現象:
個別應用產生一定比例的訪問超時錯誤報告，經過監控系統 sunfire 配置發現特定的A 應用 pod 與另外一個應用B pod 網絡不通；
網絡測試：
- A pod 訪問不通 B pod;
- B pod 能訪問通 A pod;
- A pod 宿主機 ECS 能訪問通 B pod宿主機 ECS；
- B pod 宿主機 ECS 能訪問通 A pod宿主機 ECS；
- A pod 訪問通 B pod宿主機 ECS；
- B pod 訪問通 A pod宿主機 ECS；
抓包並與阿里雲同學網絡排查發現， 雲上 VPC 的 NC 網絡控制模塊沒有正確下發路由信息，導致網絡故障。
解決方法:
聯繫阿里雲 vpc 同學，排查 vpc 中 NC 路由下發問題。
6. 部分 ECS 網絡故障，Master 訪問Node 的 kube-proxy 端口訪問不通：
錯誤現象:
新添加一批 ECS 節點，個別 ECS 總是添加失敗，報告超時，排除 SLB 訪問控制等原因；
監控 kubelet-TelnetStatus.Value 報警；
【阿里雲監控】應用分組-k8s-cbf861623f10144c488813375a8a0d489-worker-1個實例發生報警, 觸發規則：kubelet-TelnetStatus.Value
14:16 可用性監控[kubelet dingtalk-a-prod-node-X06/172.16.6.9] ，狀態碼（631>400 ），持續時間1天3分鐘 錯誤原因:
經過觀察和多次測試，失敗的 ECS 網絡很不穩定，經常網絡不通；
該故障排查錯層較長，一直沒懷疑機器問題；
ECS 宿主機基礎設施有問題，排除釋放此宿主機上的 ECS。
解決方法:
新建 ECS, 釋放故障 ECS，重新加入 kubernetes 集羣。