Demo怎么部署

本篇內(nèi)容介紹了“Demo怎么部署”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

閑淡

Kubernates是建立在擴(kuò)展性的具備二次開(kāi)發(fā)的功能層次豐富的體系化系統(tǒng)

• 首先其最核心的功能是管理容器集群，能管理容器化的集群（包括存儲(chǔ)，計(jì)算），當(dāng)然這個(gè)是建立在對(duì)容器運(yùn)行時(shí)(CRI)，網(wǎng)絡(luò)接口(CNI),存儲(chǔ)服務(wù)接口（CSI/FV）的基礎(chǔ)上；

• 其次是面向應(yīng)用(包括無(wú)狀態(tài)/有狀態(tài),批處理/服務(wù)型應(yīng)用)的部署和路由能力，特別是基于微服務(wù)架構(gòu)的應(yīng)用管理，具備了其服務(wù)定義和服務(wù)發(fā)現(xiàn)，以及基于configmap的統(tǒng)一配置能力；

• 在基礎(chǔ)資源（主要是抽象底層IaaS的資源）和應(yīng)用層的抽象模型之上是治理層，包含彈性擴(kuò)容，命名空間/租戶，等。當(dāng)然，基于其原子內(nèi)核的基礎(chǔ)能力，在Kubernetes的核心之上搭建統(tǒng)一的日志中心和全方位監(jiān)控等服務(wù)是水到渠成的，CNCF更是有其認(rèn)定推薦。

來(lái)張 Kubernetes Architecture 的一張圖解釋下上述描述。在2018年Kubernetes往事實(shí)的paas底座的標(biāo)配邁出質(zhì)的一步，有人說(shuō)原因在于基于擴(kuò)展的二次開(kāi)發(fā)能力，有人說(shuō)在于其聲明式編程和背靠Google和Redhat的強(qiáng)大社區(qū)運(yùn)作，我覺(jué)得回歸本質(zhì)是在于下圖中的__Layered架構(gòu)和其問(wèn)題域的領(lǐng)域建模抽象__。

cdn.yuque.com/lark/0/2018/png/1217/1531965342241-d95bf6b8-037e-4923-8ce1-245d7872b0e7.png">

以微服務(wù)架構(gòu)視角，Kubernetes在一定意義上是微服務(wù)框架（這時(shí)較叫微服務(wù)平臺(tái)或toolkit集更合適），支持微服務(wù)的服務(wù)發(fā)現(xiàn)/注冊(cè)的基本能力。借用如下圖做一個(gè)簡(jiǎn)單描述。

話題再展開(kāi)一下，微服務(wù)領(lǐng)域涉及眾多問(wèn)題，大概可以用下圖說(shuō)明。

kubernetes解決得只是少部分，而像動(dòng)態(tài)路由，穩(wěn)定性控制（斷路器，隔水艙等），分布式服務(wù)追蹤等是個(gè)空白，這也就是servicemesh要解決的，是在CNCF的Trail Map占有重要一席；當(dāng)然Dubbo是基本具備完備的微服務(wù)，也就是使得其集成到k8s體系下具有相當(dāng)?shù)囊饬x。Dubbo在serviemesh中基于sidecar的方案是解決跨語(yǔ)言訴求的通用servicemesh方案，需要新開(kāi)一個(gè)話題來(lái)展開(kāi)說(shuō)；而引用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. 

首先服務(wù)網(wǎng)格是一個(gè)云原生環(huán)境下基礎(chǔ)設(shè)施層，功能在于處理服務(wù)間通信，職責(zé)是負(fù)責(zé)實(shí)現(xiàn)請(qǐng)求的可靠傳遞，被使得被監(jiān)控跟蹤，被治理，最終使得微服務(wù)架構(gòu)被賦予高可控的穩(wěn)定性和快速的問(wèn)題定位排查能力。

可以得出現(xiàn)有Dubbo集成云原生基礎(chǔ)設(shè)施kubernetes的基礎(chǔ)能力而并解決微服務(wù)相關(guān)核心問(wèn)題也算是一種狹義上的servicemesh方案，只是是Java領(lǐng)域的罷了；當(dāng)玩笑理解也行，哈哈。

思路/方案

kubernetes是天然可作為微服務(wù)的地址注冊(cè)中心，類似于zookeeper， 阿里巴巴內(nèi)部用到的VIPserver，Configserver。 具體來(lái)說(shuō)，kubernetes中的Pod是對(duì)于應(yīng)用的運(yùn)行實(shí)例，Pod的被調(diào)度部署/啟停都會(huì)調(diào)用API-Server的服務(wù)來(lái)保持其狀態(tài)到ETCD；kubernetes中的service是對(duì)應(yīng)微服務(wù)的概念，定義如下

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.

概括來(lái)說(shuō)kubernetes service具有如下特點(diǎn)

• 每個(gè)Service都有一個(gè)唯一的名字，及對(duì)應(yīng)IP。IP是kubernetes自動(dòng)分配的，名字是開(kāi)發(fā)者自己定義的。

• Service的IP有幾種表現(xiàn)形式，分別是ClusterIP，NodePort,LoadBalance,Ingress。 ClusterIP主要用于集群內(nèi)通信；NodePort，Ingress，LoadBalance用于暴露服務(wù)給集群外的訪問(wèn)入口。

乍一看，kubernetes的service都是唯一的IP，在原有的Dubbo/HSF固定思維下：Dubbo/HSF的service是有整個(gè)服務(wù)集群的IP聚合而成，貌似是有本質(zhì)區(qū)別的，細(xì)想下來(lái)差別不大，因?yàn)閗ubernetes下的唯一IP只是一個(gè)VIP，背后掛在了多個(gè)endpoint，那才是事實(shí)上的處理節(jié)點(diǎn)。

此處只討論集群內(nèi)的Dubbo服務(wù)在同一個(gè)kubernetes集群內(nèi)訪問(wèn)；至于kubernetes外的consumer訪問(wèn)kubernetes內(nèi)的provider，涉及到網(wǎng)絡(luò)地址空間的問(wèn)題，一般需要GateWay/loadbalance來(lái)做映射轉(zhuǎn)換，不展開(kāi)討論。針對(duì)kubernetes內(nèi)有兩種方案可選：

1. DNS： 默認(rèn)kubernetes的service是靠DNS插件(最新版推薦是coreDNS)， Dubbo上有個(gè) proposal 是關(guān)于這個(gè)的。我的理解是static resolution的機(jī)制是最簡(jiǎn)單最需要支持的一種service discovery機(jī)制，具體也可以參考Envoy在此的 觀點(diǎn) ，由于HSF/Dubbo一直突出其軟負(fù)載的地址發(fā)現(xiàn)能力，反而忽略Static的策略。同時(shí)螞蟻的SOFA一直是支持此種策略，那一個(gè)SOFA工程的工程片段做一個(gè)解釋。這樣做有兩個(gè)好處，1）當(dāng)軟負(fù)載中心crash不可用造成無(wú)法獲取地址列表時(shí)，有一定的機(jī)制Failover到此策略來(lái)處理一定的請(qǐng)求。 2）在LDC/單元化下，螞蟻的負(fù)載中心集群是機(jī)房/區(qū)域內(nèi)收斂部署的，首先保證軟負(fù)載中心的LDC化了進(jìn)而穩(wěn)定可控，當(dāng)單元需要請(qǐng)求中心時(shí)，此VIP的地址發(fā)現(xiàn)就排上用場(chǎng)了。

1. API：DNS是依靠DNS插件進(jìn)行的，相當(dāng)于額外的運(yùn)維開(kāi)銷(xiāo)，所以考慮直接通過(guò)kubernetes的client來(lái)獲取endpoint。事實(shí)上，通過(guò)訪問(wèn)kubernetes的API server接口是可以直接獲取某個(gè)servie背后的endpoint列表，同時(shí)可以監(jiān)聽(tīng)其地址列表的變化。從而實(shí)現(xiàn)Dubbo/HSF所推薦的軟負(fù)載發(fā)現(xiàn)策略。具體可以參考代碼：

以上兩種思路都需要考慮以下兩點(diǎn)

1. kubernetes和Dubbo對(duì)于service的名字是映射一致的。Dubbo的服務(wù)是由serviename，group，version三個(gè)來(lái)確定其唯一性，而且servicename一般其服務(wù)接口的包名稱，比較長(zhǎng)。需要映射kubernetes的servie名與dubbo的服務(wù)名。要么是像SOFA那樣增加一個(gè)屬性來(lái)進(jìn)行定義，這個(gè)是改造大點(diǎn)，但最合理；要么是通過(guò)固定規(guī)則來(lái)引用部署的環(huán)境變量，可用于快速驗(yàn)證。

2. 端口問(wèn)題。默認(rèn)Pod與Pod的網(wǎng)絡(luò)互通算是解決了。需要驗(yàn)證。

Demo驗(yàn)證

下面通過(guò)阿里云的容器鏡像服務(wù)和EDAS中的kubernetes服務(wù)來(lái)做一次Demo部署。

1. 訪問(wèn)阿里云-》容器鏡像服務(wù)，創(chuàng)建鏡像倉(cāng)庫(kù)并綁定github代碼庫(kù)。如下圖

1. 點(diǎn)擊管理進(jìn)行創(chuàng)建好的倉(cāng)庫(kù)，通過(guò)鏡像服務(wù)下的構(gòu)建功能，把demo構(gòu)建成image，并發(fā)布到指定倉(cāng)庫(kù)。如下圖。

1. 切換到企業(yè)級(jí)分布式應(yīng)用服務(wù)（EDAS）產(chǎn)品，在資源管理 - 》集群 下創(chuàng)建kubernetes集群并綁定ECS，如下圖.

1. 應(yīng)用管理 -》創(chuàng)建應(yīng)用，類型為kubernetes應(yīng)用 并且指定在容器鏡像服務(wù)中的鏡像。如下圖。

1. 創(chuàng)建完成后，進(jìn)行應(yīng)用部署。如下圖

補(bǔ)充

• 應(yīng)用名不能有大寫(xiě)字母，是要小寫(xiě)，否則有部署失敗的問(wèn)題。

• 在創(chuàng)建應(yīng)用時(shí)，選中鏡像后，下一步的按鈕無(wú)法點(diǎn)擊，需要點(diǎn)擊選擇繼續(xù)。

• EDAS有兩套獨(dú)立的kubernetes服務(wù)，一套是基于阿里云的容器服務(wù)，一套是Lark自己搞的。本人體驗(yàn)的是后者。

• Docker與IDE集成的開(kāi)發(fā)聯(lián)調(diào)，需要考慮集成IDEA的相關(guān)插件。

“Demo怎么部署”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！