kubernetes flannel pod CrashLoopBackoff解決

背景

某環境客戶部署了一個kubernetes集羣，發現flannel的pod一直重啓，始終處於CrashLoopBackOff狀態。

排查

1. 對於始終CrashLoopBackOff的pod，通常是應用自己的問題，須要查看具體pod的日誌，經過kubectl logs -f --tail -n kube-system flannel-xxx顯示，「pod cidr not assigned」，而後flannel退出

2. 檢查日誌顯示的節點10.0.0.17的cidr，發現確實爲空，而正常的環境倒是正常的。

3. 檢查flannel的啓動參數，發現爲--kube-subnet-mgr,–kube-subnet-mgr表明其使用kube類型的subnet-manager。該類型有別於使用etcd的local-subnet-mgr類型，使用kube類型後，flannel上各Node的IP子網分配均基於K8S Node的spec.podCIDR屬性—" contact the Kubernetes API for subnet assignment instead of etcd.",而在第2步，咱們已經發現節點的podcidr爲空。

4. node節點分配podCIDR，須要kube-controller-manager開啓allocate-node-cidrs爲true，它和cluster-cidr參數共同使用的時候，controller-manager會爲全部的Node資源分配容器IP段， 並將結果寫入到PodCIDR字段.檢查環境kube-controller-manager的配置文件，發現問題所在。以下圖，環境設置了cluster-cidr爲192.168.2.0/24,同時設置了node-cidr-mask-size爲24,node-cidr-mask-size參數,用來表示kubernetes管理集羣中節點的cidr掩碼長度,默認是24位，須要從cluster-cidr裏面分配地址段，而設置的cluster-cidr顯然沒法知足這個掩碼要求,致使kube-controller-manager爲節點分配地址失敗。

後記

綜上，能夠修改node-cidr-mask-size參數爲24以上的數解決node無法分配podcidr問題，可是同時發現環境部署使用的kubernetes自動化工具分配集羣的service-cluster-ip-range也是從cluster-cidr裏面取一段，分配不知足居然使用了和cluster-cidr同樣的地址，形成網段衝突。最終，讓客戶從新規劃了網段，修改cluster-cidr掩碼從24位改成16位，後續flannel均啓動正常。