K8s是運維層面的東西，不是專職程式設計師，何況是專職Java程式設計師的分內工作。當然，並不是不建議你學，技多不壓身。這兩個框架和k8s並不對立，淘汰也無從談起

可能你有點誤會，就如何很多評論所說，一個是開發框架，一個是運維層面。但是老實說，springcloud和dubbo都在和k8s進行整合，比如springcloud-kuberneters，另外dubbo也是在積極的k8s做相容的。這是一個共贏的場面 而不誰淘汰誰。

另外快速掌握k8s這個，其實就是看官方文件學，沒記錯的話k8s也是有中文文件的。

Kubernetes 統治部署時代已經是事實了，生態完備，介面規範，基金會穩如磐石。唯一的瓶頸，在於學習曲線，內容大，層次深。只掌握Java 程式設計知識的程式設計師是掌握不了的。對於任何普通程式設計師，Kubernetes 都需要學習 DNS、負載均衡器、代理、NAT 網路穿透、CIDR 網段管理、虛擬檔案系統、… 很多作業系統底層的知識。

從效能上，springcloud、dubbo 和 k8s 沒法比較，差距太大，最典型的就是服務閘道器，k8s 採用 kernel iptable 路由規則和 ipvs 實現，Java 系則是 http 代理，效能差距很大。

從生態上，k8s 非常完善，文件齊全，springcloud 正在與 netflix 出現工具停更問題，dubbo 則不受國外軟體界認可。

k8s 會催生一些新職業，負責構建雲設施的高階系統程式設計師，需要對 Linux 系統有深厚理解，對網路、IO、記憶體管理、容器化、虛擬資料中心有深厚瞭解，才能駕馭得了。

在服務註冊發現和API閘道器的部分，兩個框架和k8S是有重疊和衝突的。k8裡是基於service和動態ip的，springcloud是基於介面函式和固定ip，因為K8現在的熱門，很多開發框架也都在向K8方向上做相容處理，但用起來感覺繁瑣，不如直接使用K8的系統機制去完成。所以我也覺得在一部分功能上，K8是有替代性的。

springcloud不過是解決分散式開發的介面規範罷了，可有可無。使用springcloud能夠更好的升級轉移底層基礎架構，不至於影響核心業務程式碼。如果有更好的分散式技術，直接從springcloud轉，成本很低。k8s通俗點就是管理容器的，分散式應用之間還有很多技術要從業務層面去解決的，比如說資料一致和鎖的問題，服務訂閱和發現，統一介面認證和鑑權，我對k8s不瞭解，或許k8s就能夠做到負載均衡，閘道器和限流等，但如果是從springcloud轉為k8s上自帶的分散式技術，也不需要太大成本。我對springcloud的瞭解就是解耦安全，開發流暢，且對未來基礎技術轉換沒有任何擔憂。

是istio解決服務治理問題吧，替代springcloud很難啊，springcloud可不止是服務治理，k8s作為容器編排基礎設施，也只有服務發現、負載均衡少數服務治理功能