緣起
2018年3月,我正式成為運維負責人,接管集團內部的雲平台賬戶。
上一任運維負責人是個天才,他給我留了一堆完全沒有密碼的服務器,涵蓋了騰訊雲和阿里雲,此外還有一大堆無效的DNS記錄,CDN域名,處理這些垃圾的善后工作,陸陸續續花了我一年多時間。
2018年6月,因緣巧合之下,阿里雲P8口授我 Kubernetes,我當天下午立即決定,無論遇到多大的困難,必定要將其落地。
當時我們的系統已經有一部分運行在阿里雲的 docker swarm 上面,但我看了一下 release note ,覺得那玩意肯定是棄子。於是,在三個月左右的時間內,通過看英文版的《kubernetes in action》和參與社群,我從 0 docker 基礎的渣渣升級為集團內部首席雲原生步道師。並升級為社群的管理員。
阿里雲Kubernetes
早期產品經理
此外,我還成為了阿里雲 Kubernetes 的早期產品經理。很多產品建議都是我提出來,由他們內部加以評估改進的。
- 容器鏡像服務支持私有倉庫海外機器構建
- kubernetes web控制台:支持ephemeral-storage的設置
- 容器鏡像服務:支持gcr.io等鏡像的代理
- kubernetes:盡快廢棄 dashboard,並將其功能集成到阿里雲控制台
- Kubernetes:改進創建svc
- kubernetes:改進RBAC
- 阿里雲kubernetes:SchedulingDisabled節點會被自動剔除出虛擬服務器組
- Kubernetes:擴充"節點不可調度"的功能,改為"維護節點"
- Kubernetes:改進創建集群選項
- k8s:增強雲盤數據卷
- k8s:變更service的證書標簽無法生效
- k8s:增加集群節點管理的相關文檔
- 雲監控:改進K8S雲監控
- 容器服務:pv顯示不友好
- K8S:進入POD終端之后的可操作時間過短
- k8s:配置deployment頁面有問題
- k8s:volume的相關局限性以及改進
- k8s:namespace信息同步有問題
- k8s:取消ingress的TLS不生效
- 阿里雲鏡像倉庫:優化用戶體驗
- k8s:維護master的時候會多出一些奇怪的負載均衡
- k8s:改進HPA
- 希望阿里雲容器服務K8S 能夠支持自主綁定 SLB
- k8s-給路由(Ingress)加上 TLS的時候會有問題
- k8s:改進LoadBalancer型服務和負載均衡的綁定
- k8s-使用私有鏡像創建部署(deployment)的時候會有問題
- 無意中發現 K8S的部署詳情頁面有 bug
- 希望阿里雲的容器kubernetes界面不要強行翻譯專有名詞!!!
- K8S-創建應用頁面的相關教程改進
- 優化K8S部署應用的用戶體驗
- 讓用戶靈活選擇 K8S master 付費方式
- 容器服務-健康檢查形同雞肋
- 容器服務-改進日志服務
2018-05-13 至今,圍繞容器領域,陸陸續續提了幾十個建議。雖然有一部分沒被采納,但我覺得我應該擔得起“阿里雲Kubernetes早期產品經理”這個稱號。
最有印象的 BUG 是這個
k8s:取消ingress的TLS不生效
當時我跟進了近三個月,還發了個視頻給當時的阿里雲產品經理。
NoOps
傳統應用的瀑布模型,我就不吐槽有多糟糕啦,懂的人自然懂。當初在那個運維負責人坑了我一把之后,我看到 Kubernetes 簡直像看到了救星一樣。后來我就用 Kubernetes 回收了大部分的服務器,至於那些沒密碼的服務器,要么用休克療法半夜重置密碼后重啟,要么耗個一兩年,備份雲盤后直接退款。
Kubernetes 時代服務器的忘記密碼
可參考我寫的
擴容阿里雲kubernetes集群,並升級節點內核
略有區別的在於,
節點維護這里要設置為“不可調度”。然后慢慢耗死節點里面的 pod 。
當節點里面剩下的 pod 都不再重要時,便可以直接刪除節點並退款相應的ECS。
吐槽
阿里雲能不能別老是給我發代金券了,我的域名再續下去得有百年了。
參考鏈接
[1]
2017年雲趨勢——從DevOps到NoOps
http://dockone.io/article/2126