問題來自於乙個朋友，不是筆者親身經歷由於kube-apiserver的日誌中同樣無法提取出能夠幫助解決問題的有用資訊，起初我們只能猜測可能是kube-apiserver的快取更新異常導致的。正要從這個切入點解決問題的時候，有乙個詭異的問題 建立的pod無法通過kubectl 查詢到 那麼問題來了 kube api的list操作是沒有快取的，資料是kube-apiserver直接從etcd拉取返回給客戶端的 ，初步判斷可能是etcd這裡有問題
etcd是cap架構，乙個強一致性的kv儲存，在寫操作成功的情況下兩次請求不應該讀取到不一樣的資料，我們通過etcdctl直接查詢了etcd的集群狀態和集群資料，得到的結果是集群狀態正常 raftindex一致，觀察etcd的日誌也沒有發現報錯資訊，唯一可疑的地方是3個節點的dbsize差別比較大，接著我們又將client訪問的endpoint指定為不同節點位址來查詢每個key的數量，結果發現3個節點返回的key數量不一致，並且直接通過etcdctl查詢剛建立的pod，發現訪問某些endpoint可以查到該pod，而訪問其他endpoint則查不到 至此，基本可以確定etcd集群的節點存在資料不一致現象
初步驗證
通常集群正常執行沒有外部變更，一般不會出現這麼嚴重的問題，查詢etcd集群近幾天的發布記錄時發現故障前一天對該集群的一次發布中，由於之前dbsize配置不合理 導致db被寫滿集群無法寫入新的資料，為此運維人員更新了集群dbsize和compaction相關配置並且重啟了etcd 重啟後繼續對ectd手動執行了compact和defrag操作來壓縮db空間
通過上述場景 我們基本可以初步判斷一下幾個可疑的觸發條件
1.dbsize滿
2.dbsize和compaction配置更新
3.compaction操作和defrag操作
4.重啟etcd
k8s灰度更新 k8s實現灰度發布
灰度發布在實際生產部署中是經常被使用的方式，常規的方法是手動從前端lb 負載均衡 上將後端伺服器摘掉，然後，停服務，最後上傳 完成軟連線更新。在使用ci cd工具時，這個過程變得自動化了，我們只需要通過jenkins這個功能強大的開源持續整合和部署工具，就可以聯合gitlab 或 gogs 來實現自...
K8S的Deployment滾動公升級指令整理
deployment公升級與回滾kubectl set image deployment nginx deployment nginx nginx 1.9.1 kubectl set resources deployment nginx deployment c nginx limits cpu 2...
K8S學習總結（一）
kubernetes是容器集群管理系統，是乙個開源的平台，可以實現容器集群的自動化部署 自動化擴縮容 維護等功能。master元件可以再集群中任何節點上執行，通常將所有master元件執行於一台伺服器上，並且不會在該伺服器上執行任何使用者容器。kube apiserver用於提供資源請求 呼叫介面 ...