哪個先被淘汰？
作為一個微服務管理和通訊的完整解決方案，兩個都不會被淘汰。但是不可否認的是，他們提供的部分功能會被基礎設施所取代。比如說服務發現，服務註冊的功能，如果你的微服務是部署在 kubernetes 叢集上，那麼利用 kubernetes 的服務註冊和發現的功能會更簡單。又比如說負載均衡，流量管理和 circuit breaker 之類的功能，如果用了 istio ，那麼這些功能也會被自然轉到 envoy 代理上。總之很多功能會從應用程式剝離出來，下沉到基礎設施。
為什麼是K8S?試想下傳統的後端部署辦法：把程式包（包括可執行二進位制檔案、配置檔案等）放到伺服器上，接著執行啟動指令碼把程式跑起來，同時啟動守護指令碼定期檢查程式執行狀態、必要的話重新拉起程式。
有問題嗎？顯然有！最大的一個問題在於：如果服務的請求量上來，已部署的服務響應不過來怎麼辦？傳統的做法往往是，如果請求量、記憶體、CPU超過閾值做了告警，運維馬上再加幾臺伺服器，部署好服務之後，接入負載均衡來分擔已有服務的壓力。
問題出現了：從監控告警到部署服務，中間需要人力介入！那麼，有沒有辦法自動完成服務的部署、更新、解除安裝和擴容、縮容呢？
這，就是K8S要做的事情。
JAVA大軍，如何快速掌握K8S相對於簡單易學的Docker來說，k8s系統龐雜而且概念眾多，同一個功能有很多不同方法來完成，讓你無所適從，學習起來要困難的多。對於普通碼農來講不需要建立完整的生產環境，只需要搭建一個本地開發環境，這時你只需要瞭解k8s的核心概念就夠了，這樣可以大大縮短學習時間。
那麼該怎麼具體學習呢？
阿里是使用k8s最成功的一家，前段時間也是諮詢了在阿里任職的朋友，他直接甩給了我一份 k8s 開發筆記，並且說 Java 開發者不用深入學習，跟著開發筆記操作一遍就可以了；
筆記分享這份筆記分為：理論篇與實戰篇，共12部分；
本份開發筆記以程式碼+配圖+文字的方式進行講解，內容循序漸進，從理論到實戰、從發現問題到解決問題、開發中犯的錯，一步不落的展現在你的面前；此筆記的內容對於 java 大軍來說完全夠用；部分內容可看下方截圖；