最近乙個月大蕉斷更了，主要就在做一些跟 k8s 相關的事情，就在昨天剛剛交付產品了乙個版本，這幾周幾乎把大蕉榨乾了。但是大蕉從來不是乙個怕事的人，幹就完了，乙個當十個用，沒什麼大問題。
但是經過了幾個月基於k8s寫應用，我還是建議你別輕易嘗試用 k8s ，這時候就有人問了，我看你前幾個月還叫我們沒事多學學 k8s 呢，為什麼今天就說輕易別基於 k8s 寫應用呢？
且聽我細細說來。
基於 docker 定義執行環境實在是太方便了，你可能沒法像以前一樣有一大堆的發布指令碼排查發布環境的問題了。
這樣線上環境太穩定，可能會裁剪一部分的開發運維人員。對於乙個 python 應用來說，以前我們需要安裝 linux，安裝python，安裝 pip，安裝相關的依賴庫。可是對於 docker 映象定義方式 dockerfile 來說。
from python:3
run pip install mysql-python
應用公升級和回滾真的太方便了，你可能沒法像以前一樣搞一大堆的發布步驟。
加乙個配置檔案，換乙個依賴包，公升級一下linux核心版本，還要相容一下。搞得每次發布都能由你自己搞。有了 k8s 你已經沒這個機會了。這樣你的價值會大大縮水。用 k8s 公升級只需要這一行就夠了。
這樣 k8s 集群會對你的應用進行滾動公升級，你不需要害怕公升級的時候因為同時重啟的問題導致服務不可用，它都幫你解決了。它公升級的做法是先啟動乙個容器，確認這個容器正常服務了，再乾掉原來的容器。
當然，發布出問題也是很常見的，以前的回滾要找發布包，回滾依賴，一堆事情做。現在有了 k8s ，回滾也變得簡單起來。
回滾的步驟跟公升級是一樣的，會先啟動原來映象版本的容器，然後再乾掉現在版本的容器。這一波操作，會導致你的存在感降低，你無法在發布的時候進行一頓瘋**作了，很可惜，你很可能會被優化掉。
服務間暴露和呼叫真的太方便了，只能由你解決的呼叫 bug 可能一去不復返了。
想想這個場景，乙個新人加入團隊，面對**裡一堆的根據 ip 呼叫的邏輯，這個新人能怎麼辦呢？必然只能問你啊，這個 ip 是什麼，另外乙個 ip 又是什麼？k8s 自帶名字服務和負載均衡，如果只是在集群內呼叫，你終於不需要再用 ip + 埠的模式呼叫集群內的其他服務了，無論是 rpc 還是 http 呼叫，都需要ip + 埠吧？很遺憾 k8s 集群預設並不會給你分配任何乙個固定 ip 和埠，所有的 ip 和 埠都是動態分配的，你已經不能使用 ip **了。那麼 k8s 是怎麼做到的呢？
如果你是靠各種邪術寫魔法**混職場的，我強烈建議你千萬別用 k8s ，你很可能會混不下去。
最後一天上班，明天要肥家啦。在這裡預祝大家春節快樂，不要怕，帶好口罩~大蕉保佑你！！mua~
k8s 資源爭用
由磁碟空間不足引發集群訪問的問題.k8s node節點磁碟空間不足,var lib docker overlay2 空間過大,將docker的資料目錄切換到其它磁碟,修改docker配置文檔案 usr lib systemd system docker.service,execstart usr b...
k8s環境搭建 基於minik8s方法
關閉selinux 開啟ipv6 sudo bash selinux ipv6.shcurl lo minikube chmod x minikube sudo mv minikube usr local bin curl lo kubectl s chmod x kubectl上面的命令極有可能超...
基於k8s的集群穩定架構
我司的集群時刻處於崩潰的邊緣，通過近三個月的掌握，發現我司的集群不穩定的原因有以下幾點 1 發版流程不穩定 2 缺少監控平台 最重要的原因 3 缺少日誌系統 4 極度缺少有關操作文件 5 請求路線不明朗 總的來看，問題的主要原因是缺少可預知的監控平台，總是等問題出現了才知道。次要的原因是伺服器作用不...