共計 3453 個字符，預計需要花費 9 分鐘才能閱讀完成。
本篇內容介紹了“Demo 怎么部署”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
閑淡
Kubernates 是建立在擴展性的具備二次開發的功能層次豐富的體系化系統
首先其最核心的功能是管理容器集群，能管理容器化的集群（包括存儲，計算），當然這個是建立在對容器運行時(CRI)，網絡接口(CNI), 存儲服務接口（CSI/FV）的基礎上；
其次是面向應用 (包括無狀態 / 有狀態, 批處理 / 服務型應用) 的部署和路由能力，特別是基于微服務架構的應用管理，具備了其服務定義和服務發現，以及基于 configmap 的統一配置能力；
在基礎資源（主要是抽象底層 IaaS 的資源）和應用層的抽象模型之上是治理層，包含彈性擴容，命名空間 / 租戶，等。當然，基于其原子內核的基礎能力，在 Kubernetes 的核心之上搭建統一的日志中心和全方位監控等服務是水到渠成的，CNCF 更是有其認定推薦。
來張
Kubernetes Architecture
的一張圖解釋下上述描述。在 2018 年 Kubernetes 往事實的 paas 底座的標配邁出質的一步，有人說原因在于基于擴展的二次開發能力，有人說在于其聲明式編程和背靠 Google 和 Redhat 的強大社區運作，我覺得回歸本質是在于下圖中的__Layered 架構和其問題域的領域建模抽象__。
以微服務架構視角，Kubernetes 在一定意義上是微服務框架（這時較叫微服務平臺或 toolkit 集更合適），支持微服務的服務發現 / 注冊的基本能力。借用如下圖做一個簡單描述。
話題再展開一下，微服務領域涉及眾多問題，大概可以用下圖說明。
kubernetes 解決得只是少部分，而像動態路由，穩定性控制（斷路器，隔水艙等），分布式服務追蹤等是個空白，這也就是 servicemesh 要解決的，是在 CNCF 的 Trail
Map 占有重要一席；當然 Dubbo 是基本具備完備的微服務，也就是使得其集成到 k8s 體系下具有相當的意義。Dubbo 在 serviemesh 中基于 sidecar 的方案是解決跨語言訴求的通用 servicemesh 方案，需要新開一個話題來展開說；而引用 serviemsh 的
：
A
service mesh is a dedicated infrastructure layer for handling
service-to-service communication. It’s responsible for the reliable
delivery of requests through the complex topology of services that
comprise a modern, cloud native application.
首先服務網格是一個云原生環境下基礎設施層，功能在于處理服務間通信，職責是負責實現請求的可靠傳遞，被使得被監控跟蹤，被治理，最終使得微服務架構被賦予高可控的穩定性和快速的問題定位排查能力。
可以得出現有 Dubbo 集成云原生基礎設施 kubernetes 的基礎能力而并解決微服務相關核心問題也算是一種狹義上的 servicemesh 方案，只是是 Java 領域的罷了；當玩笑理解也行，哈哈。
思路 / 方案
kubernetes 是天然可作為微服務的地址注冊中心，類似于 zookeeper，
阿里巴巴內部用到的 VIPserver，Configserver。
具體來說，kubernetes 中的 Pod 是對于應用的運行實例，Pod 的被調度部署 / 啟停都會調用 API-Server 的服務來保持其狀態到 ETCD；kubernetes 中的 service 是對應微服務的概念，定義如下
A Kubernetes Service is an abstraction layer which
defines a logical set of Pods and enables external traffic exposure,
load balancing and service discovery for those Pods.
概括來說 kubernetes service 具有如下特點
每個 Service 都有一個唯一的名字，及對應 IP。IP 是 kubernetes 自動分配的，名字是開發者自己定義的。
Service 的 IP 有幾種表現形式，分別是 ClusterIP，NodePort,LoadBalance,Ingress。ClusterIP 主要用于集群內通信；NodePort，Ingress，LoadBalance 用于暴露服務給集群外的訪問入口。
乍一看，kubernetes 的 service 都是唯一的 IP，在原有的 Dubbo/HSF 固定思維下：Dubbo/HSF 的 service 是有整個服務集群的 IP 聚合而成，貌似是有本質區別的，細想下來差別不大，因為 kubernetes 下的唯一 IP 只是一個 VIP，背后掛在了多個 endpoint，那才是事實上的處理節點。
此處只討論集群內的 Dubbo 服務在同一個 kubernetes 集群內訪問；至于 kubernetes 外的 consumer 訪問 kubernetes 內的 provider，涉及到網絡地址空間的問題，一般需要 GateWay/loadbalance 來做映射轉換，不展開討論。針對 kubernetes 內有兩種方案可選：
DNS：默認 kubernetes 的 service 是靠 DNS 插件(最新版推薦是 coreDNS)，Dubbo 上有個
proposal
是關于這個的。我的理解是 static resolution 的機制是最簡單最需要支持的一種 service discovery 機制，具體也可以參考 Envoy 在此的
，由于 HSF/Dubbo 一直突出其軟負載的地址發現能力，反而忽略 Static 的策略。同時螞蟻的 SOFA 一直是支持此種策略，那一個 SOFA 工程的工程片段做一個解釋。這樣做有兩個好處，1）當軟負載中心 crash 不可用造成無法獲取地址列表時，有一定的機制 Failover 到此策略來處理一定的請求。
2）在 LDC/ 單元化下，螞蟻的負載中心集群是機房 / 區域內收斂部署的，首先保證軟負載中心的 LDC 化了進而穩定可控，當單元需要請求中心時，此 VIP 的地址發現就排上用場了。
API：DNS 是依靠 DNS 插件進行的，相當于額外的運維開銷，所以考慮直接通過 kubernetes 的 client 來獲取 endpoint。事實上，通過訪問 kubernetes 的 API
server 接口是可以直接獲取某個 servie 背后的 endpoint 列表，同時可以監聽其地址列表的變化。從而實現 Dubbo/HSF 所推薦的軟負載發現策略。具體可以參考代碼：
以上兩種思路都需要考慮以下兩點
kubernetes 和 Dubbo 對于 service 的名字是映射一致的。Dubbo 的服務是由 serviename，group，version 三個來確定其唯一性，而且 servicename 一般其服務接口的包名稱，比較長。需要映射 kubernetes 的 servie 名與 dubbo 的服務名。要么是像 SOFA 那樣增加一個屬性來進行定義，這個是改造大點，但最合理；要么是通過固定規則來引用部署的環境變量，可用于快速驗證。
端口問題。默認 Pod 與 Pod 的網絡互通算是解決了。需要驗證。
Demo 驗證
下面通過阿里云的容器鏡像服務和 EDAS 中的 kubernetes 服務來做一次 Demo 部署。
訪問阿里云 -》容器鏡像服務，創建鏡像倉庫并綁定 github 代碼庫。如下圖
點擊管理進行創建好的倉庫，通過鏡像服務下的構建功能，把 demo 構建成 image，并發布到指定倉庫。如下圖。
切換到企業級分布式應用服務（EDAS）產品，在資源管理 –》集群 下創建 kubernetes 集群并綁定 ECS，如下圖.
應用管理 -》創建應用，類型為 kubernetes 應用 并且指定在容器鏡像服務中的鏡像。如下圖。
創建完成后，進行應用部署。如下圖
補充
應用名不能有大寫字母，是要小寫，否則有部署失敗的問題。
在創建應用時，選中鏡像后，下一步的按鈕無法點擊，需要點擊選擇繼續。
EDAS 有兩套獨立的 kubernetes 服務，一套是基于阿里云的容器服務，一套是 Lark 自己搞的。本人體驗的是后者。
Docker 與 IDE 集成的開發聯調，需要考慮集成 IDEA 的相關插件。
“Demo 怎么部署”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站，丸趣 TV 小編將為大家輸出更多高質量的實用文章！
