1、前言
第一次接觸Kubernetes是在2016年，再一次瀏覽博文的時候，那是我第一次聽到Kubernetes這個名詞，也是第一次認識了k8s這麼一個東西。後來在慢慢了解它的時候，被它天生高可用、負載均衡、彈性計算、自動擴容縮容和全自動容災機制的設計理念吸引，於是自己便踏入了k8s這條不歸路，在調研學習的過程中，開始不斷填坑、挖坑再填坑，周而復始。
2017年，公司還在使用裸Docker部署一些無狀態的應用，隨着越來越多的Docker實例，發生故障時，人工填坑的方式，讓我們實在頭疼，有時候大半夜正在做着美夢的時候，被一個電話鈴喊起來處理着由於宿主機宕機或者網絡不可達引起的各類問題。這種慘絕人寰的處理方式更是讓我們頭疼難忍。雖然後來引用了Swarm和Compose，但隨着業務的不斷增多，已經越來越來滿足不了我們的應用場景，然後就想着把所有Docker應用遷移到Kubernetes中去管理。
2017年6月30日，k8s發佈1.7版本，2017年10月，Docker擁抱Kubernetes，也是我們正式開始使用Kubernetes的開始。但事情並沒有我們想象中的那麼簡單，k8s的設計太多複雜，概念實在是太多，搭建過程更是讓人吐血，當時可參考的文章又是少之又少。在經過一個多月的研究與不斷回血之後，終於在k8s集羣中部署了我們的第一個應用。雖然整個過程中踩了無數坑，遇到了無數個難題，但從始至終沒有放棄，最終實現一整套的流程設計，從開發提交代碼至Git，到最後成功部署到k8s集羣中，徹底釋放了雙手。遇到集羣中的宿主機宕機的時候，不用再去人工去處理，這一切k8s都幫你默默的處理了...
2、Kubernetes帶來的變革
對於開發人員
由於公司業務多，開發環境、測試環境、預生產環境和生產環境都是隔離的，而且除了生產環境，爲了節省成本，其他環境是沒有日誌收集的，在沒有用k8s的時候，查看線下測試的日誌，需要開發或者測試人員，找到對應的機器，在找到對應的容器，然後才能查看日誌，在用了k8s之後，開發和測試可以直接在k8s的dashboard到對應的namespace，即可定位到業務的容器，然後可以直接通過控制檯查看到對應的日誌，大大降低了操作時間。
把應用部署到k8s之後，代碼的發佈、回滾，以及藍綠髮布、金絲雀發佈等都變得特別簡單，不僅加快了業務代碼迭代的速度，而且全程無需人工干預。目前我們使用jenkins、gitrunner進行發版或者回滾等，從開發環境到測試環境，到最後的生產環境，完全遵守一次構建，多集羣、多環境部署，通過不同的啓動參數、不同的環境變量、不同的配置文件實現區分不同的環境。目前已經實現Python、Java、PHP、NodeJS、Go、.NET Core等多種語言的一鍵式發版、一鍵式回滾，大大提高了開發人員的開發效率。
在使用服務網格後，開發人員在開發應用的過程中，不用再關心代碼的網絡部分，這些功能都被服務網格實現，讓開發人員可以只關心代碼邏輯部分，即可實現網絡部分的功能，比如：斷流、分流、路由、負載均衡、限速和觸發故障等功能。
測試過程中，可能同時多套環境，當然也會需要再創建一套測試環境，之前測試環境的創建，需要找運維或者自行手工搭建。在遷移至k8s集羣后，只需要在jenkins上點點鼠標即可在k8s集羣上創建一套新的測試環境。
對於運維人員
如果你是一名運維人員，可能經常因爲一些重複、繁瑣的工作感覺厭倦。比如：這個需要一套新的測試環境，那個需要一套新的測試環境，之前可能需要裝系統、裝依賴環境、開通權限等等。而如今，可以直接用鏡像直接部署一套新的測試環境，甚至全程無需自己干預，開發人員通過jenkins或者自動化運維平臺即可一鍵式創建，大大降低了運維成本。
一開始，公司業務故障，可能是因爲基礎環境不一致、依賴不一致、端口衝突等等問題，現在實現鏡像部署，所有的依賴、基礎都是一樣的，大大減少了因爲這類基礎問題引發的故障。也有可能公司業務是由於服務器宕機、網絡等問題，造成服務不可用，此類情況均需要運維人員及時去修復，而如今，可能在你收到告警信息的時候，k8s已經幫你恢復了。
在沒有使用k8s時，業務應用的擴容和縮容，都需要人工去處理，從採購服務器、上架、到部署依賴環境，不僅需要大量的人力物力，而且非常容易在中間過程出現問題，又要花費大量的時間去查找問題。成功上架後，還需要在前端反代端添加或該服務器，而如今，可以利用k8s的彈性計算，一鍵式進行擴容和縮容，不僅大大提高了運維效率，而且還節省了不少的服務器資源，提高了資源利用率。
對於反代配置方面，比如可能你並不會，或者對nginx的配置規則並不熟悉，一些高級的功能你也不會實現，而如今，利用k8s的ingress即可簡單的實現那些負責的邏輯。並且也不會在遇到nginx少加一個斜槓和多加一個斜槓的問題。
對於負載均衡方面，之前負載均衡可能是Nginx、LVS、HAProxy、F5等，雲上可能是雲服務商提供的不在均衡機制。每次添加刪除節點時，都需要手動去配置前端負載均衡，手動去匹配後端節點，而如今，使用k8s內部的service可以動態發現實現自動管理節點，並且支持自動擴容縮容。之前遇到高峯流量時，經常服務器性能不夠，需要臨時加服務器面對高峯流量，而如今對於高性能k8s集羣，無需管理，自動擴容。
對於高可用方面，k8s天生的高可用功能，徹底釋放了雙手，無需再去創建各類高可用工具、檢測檢查腳本。k8s支持進程級別的健康檢查，如發現接口超時或者返回值不正確，會自動處理該問題。
對於中間件搭建方面，根據定義好的deploy文件，可以實現秒級搭建各類中間件高可用集羣，如Redis、RabbitMQ、Zookeeper等，並且大大減少了出錯的概率。
對於應用端口方面，傳統行業中，一個服務器可能跑了很多進程，每個進程都有一個端口，需要人爲的去配置端口，並且還需要考慮端口衝突的問題，如果有防火牆的話，還需要配置防火牆，在k8s中，端口統一管理，統一配置，每個應用的端口都可設置成一樣的，之後通過service進行負載均衡。
無論是對於開發人員、測試人員還是運維人員，k8s的誕生，不僅減少了工作的複雜性，還減少了各種成本。上述帶來的變革只是其中比較小的一部分，更多優點只有用了才能體會到。
3、Kubernetes帶來的挑戰
首先是對於k8s的學習本身就是很難的，概念太多，無從入手，可能學習了一個月也無法入門，甚至連集羣也搭建不出來，使人望而卻步。並且k8s對運維的技術能力要求比較高，已經不僅僅侷限於傳統運維，有時候你可能要修改業務代碼等。並且需要掌握的知識也需要很多，你可能需要掌握公司所有使用到的代碼，比如代碼是如何進行編譯的、如何正確發佈、如何修改代碼配置文件等，這對於運維人員，也是一種挑戰。Kubernetes之所以被叫做k8s，業界有兩種說法，通俗的說法是k和s之間有8個字母，另一種比較說法是k8s集羣至少需要搭建8遍才能搭建成功。當然，在實際使用時，可能不止8遍。k8s的誕生，把運維從傳統轉變到了DevOps方向，需要面臨的問題會更多，需要面臨的新技術也有很多，但是當你掌握到了k8s的核心使用，就會受益終身。
對於開發人員來說，對開發方式也有一些變化。從k8s的誕生到如火如荼，慢慢的k8s變成了一種標準，開發再進行代碼開發時需要遵循Docker和k8s規範，嚴格遵守一次構建，多次部署原則，所有的配置都通過參數、變量或者k8s配置管理注入。並且對應用，要求是無狀態的，因爲Docker每次重啓都會以最乾淨的基礎啓動。無論公司有沒有進行業務容器化，遵循Docker和k8s規範都將成爲未來的趨勢，2019年7月，某公司因爲代碼不能和k8s兼容，導致一年虧損38億美元...
4、這是重點
在這些年踩了無數坑以後，也領悟到了每個技術人員學習k8s的痛點在哪裏，首先是k8s概念不清楚就開始放肆的把應用部署到k8s集羣中，產生的問題無從入手去解決，其次是k8s集羣無論如何也搭建不出來，集羣擴容也難以下手，然後是持續集成持續部署方面無從下手等等問題，想要搭建一整套k8s集羣不僅僅侷限於k8s集羣的搭建。還需要對構建、發版、測試、部署流程化，也需要將GitLab、GitRunner、Jenkins、Harbor、Kubernetes等聯繫起來。這都是每個使用k8s會遇到的問題。
來一波猝不及防的廣告~
其實上述列出了1234項主要是爲了介紹一本即將上市的Kubernetes實戰技術書籍，這本書可以帶你避免在使用k8s的過程遇到的各類坑。
這本書不僅能幫你快速搭建一整套集羣，也會幫你解決在使用過程中遇到的各類問題，對於使用過程中的每個坑，大部分都已經幫你填上，讓你少走很多彎路，少掉不少頭髮，讓你能夠快速走進k8s的正途。這本書適用於大部分企業，可以快速構建公司的k8s平臺，並且容器化各類中間件、業務應用代碼，如Java、NodeJS等。同樣也介紹了SpringCloud各類組件的容器化。
本書以實戰爲主線，深入淺出地介紹了Kubernetes在企業生產中的應用。全書共6章，主要內容包括：第1章講解Kubernetes的高可用安裝，分爲kubeadm和二進制安裝方式。第2章介紹了Docker和Kubernetes常用的理論基礎。第3章主要講解Kubernetes的常見應用的容器化。第4章主要介紹持續集成和持續部署，包括Jenkins最新的功能Pipeline的使用，從Pipeline的語法到項目實操，傳統Java和Spring Cloud應用的容器化以及自動化構建部署。第5章主要講解了Kubernetes的Nginx Ingress的安裝和常用配置。第6章講解了備受關注的Server Mesh。