Kubernetes對(duì)計(jì)算資源進(jìn)行了更高層次的抽象，通過(guò)將容器進(jìn)行細(xì)致的組合，將最終的應(yīng)用服務(wù)交給用戶。Kubernetes在模型建立之初就考慮了容器跨機(jī)連接的要求，支持多種網(wǎng)絡(luò)解決方案，同時(shí)在Service層次構(gòu)建集群范圍的SDN網(wǎng)絡(luò)。其目的是將服務(wù)發(fā)現(xiàn)和負(fù)載均衡放置到容器可達(dá)的范圍，這種透明的方式便利了各個(gè)服務(wù)間的通信，并為微服務(wù)架構(gòu)的實(shí)踐提供了平臺(tái)基礎(chǔ)。而在Pod層次上，作為Kubernetes可操作的最小對(duì)象，其特征更是對(duì)微服務(wù)架構(gòu)的原生支持。

　　架構(gòu)及部署

　　Architecture

　　Kubernetes是2014年6月開(kāi)源的，采用Golang的語(yǔ)言開(kāi)發(fā)，每一個(gè)組件互相之間使用的是Master API的方式，Kubernetes的架構(gòu)模式是用Master-slave模式，并且支持多種聯(lián)機(jī)網(wǎng)絡(luò)，支持多種分布式存儲(chǔ)架構(gòu)。

　　Master的核心組件是API server，對(duì)外提供REST API服務(wù)接口。kubernetes所有的信息都存儲(chǔ)在分布式系統(tǒng)ETCD中. Scheduler是kubernetes的調(diào)度器，用于調(diào)度集群的主機(jī)資源。Controller用于管理節(jié)點(diǎn)注冊(cè)以及容器的副本個(gè)數(shù)等控制功能。

　　在Node上的核心組件是kubelet，它是任務(wù)執(zhí)行者，會(huì)跟apiserver進(jìn)行交互，獲取資源調(diào)度信息。 kubelet會(huì)根據(jù)資源和任務(wù)的信息和調(diào)度狀態(tài)與Docker去交互，調(diào)用Docker的API, 創(chuàng)建、刪除與管理容器，而kube-Proxy可以根據(jù)從API里獲取的信息以及整體的Pod架構(gòu)狀態(tài)組成虛擬NAT網(wǎng)絡(luò)。

　　快速部署過(guò)程

　　在最新更新的kubernetes 1.4版本中，社區(qū)開(kāi)發(fā)了專用的部署組件kubeadm, 用來(lái)完成kubernetes集群整體的部署過(guò)程。Kubeadm是對(duì)以往手動(dòng)或腳本部署的簡(jiǎn)化，集成了manifest配置、參數(shù)設(shè)置、認(rèn)證設(shè)置、集群網(wǎng)絡(luò)部署以及安全證書的獲取。需要注意的是kubeadm目前默認(rèn)從gcr.io的鏡像中心獲取鏡像，若需使用其他鏡像源，需要更改源碼編譯出定制版本。

　　Ubuntu 16.04環(huán)境的使用過(guò)程如下： ?設(shè)定部署主機(jī)資源

　　1)在所有節(jié)點(diǎn)上(包括master和node)部署基礎(chǔ)運(yùn)行環(huán)境

　　2)部署Master

　　3)添加節(jié)點(diǎn)

　　4)部署網(wǎng)絡(luò)

　　關(guān)于網(wǎng)絡(luò)，對(duì)于隔離要求較高的場(chǎng)景需求，采用calico是比較合適的選擇。calico會(huì)幫助容器在主機(jī)間搭建純二層的網(wǎng)絡(luò)，在每個(gè)主機(jī)上維護(hù)一個(gè)路由表，用來(lái)獲取目標(biāo)容器所在主機(jī)的可達(dá)路徑，以及本機(jī)容器的路有項(xiàng)。利用iptables的防火墻機(jī)制去做隔離。容器之間跨主機(jī)進(jìn)行交互時(shí)，IP包從容器出發(fā)，經(jīng)過(guò)本地路有表選路，通過(guò)目標(biāo)網(wǎng)段所在主機(jī)的路有項(xiàng)，到達(dá)目標(biāo)主機(jī)，然后在目標(biāo)主機(jī)內(nèi)，進(jìn)入路有選路前，先經(jīng)由iptables隔離規(guī)則（可設(shè)置）進(jìn)行判斷決定是否丟棄或返回，然后再經(jīng)路有選路到目標(biāo)容器，最終到達(dá)目標(biāo)容器。整個(gè)過(guò)程沒(méi)有任何封包解包的過(guò)程，傳輸效率較高。

　　隔離規(guī)則可以設(shè)定在同一用戶名下的哪些容器可以被隔離成一組，被隔離的容器間可通信，而與其它容器不可通信?；蛘咴O(shè)置規(guī)則來(lái)組成更加豐富的隔離效果。

　　部署組件詳解

　　在kubernetes 1.4版本利用kubeadm部署過(guò)程中，安裝的插件包括kube-discovery，kube-proxy和kube-dns,分別負(fù)責(zé)部署階段配置的分發(fā), NAT網(wǎng)絡(luò)和集群系統(tǒng)的dns服務(wù)。值得注意的是kube-proxy不再通過(guò)manifest來(lái)運(yùn)行，是通過(guò)插件用demonset的方式來(lái)部署。

　　1)kubeadm

　　在kubeadm init運(yùn)行階段，首先創(chuàng)建驗(yàn)證token以及靜態(tài)pod文件（manifest的文件），以及運(yùn)行所需的證書和kubeconfig。完成這些工作后，kubeadm會(huì)等待apiserver的啟動(dòng)并正常運(yùn)行，以及等待首個(gè)節(jié)點(diǎn)的接入。

　　由于master節(jié)點(diǎn)啟動(dòng)kubelet來(lái)運(yùn)行manifest文件，并且在kubelet.conf中設(shè)置了需要連接當(dāng)前主機(jī)為master，因此此master 也會(huì)作為node節(jié)點(diǎn)接入，并且master作為節(jié)點(diǎn)運(yùn)行也為kube-discovery提供運(yùn)行的必須環(huán)境。

　　當(dāng)節(jié)點(diǎn)加入并且apiserver運(yùn)行正常后，將標(biāo)示master的角色，kubeadm.alpha.kubernetes.io/role=master。

　　2)Kube-discovery

　　隨后在部署運(yùn)行kube-discovery時(shí)，在kube-discovery所運(yùn)行的pod上設(shè)置node的親和性，并將它限制成為必須在master上運(yùn)行的pod。由于kube-discovery的主要功能是證書及token等配置的管理與分發(fā)，并且后續(xù)的節(jié)點(diǎn)加入時(shí)只需要一個(gè)簡(jiǎn)單的master ip信息，因此將kube-discovery限制到了master節(jié)點(diǎn)運(yùn)行，以此統(tǒng)一服務(wù)的入口。 ?這些通過(guò)在pod的annotations來(lái)實(shí)現(xiàn) ?requiredDuringSchedulingIgnoredDuringExecution表示在調(diào)度過(guò)程中需要滿足的條件，和后面的nodeSelectorTerms在一起類似于nodeselector。這樣設(shè)置即可將pod限制到master主機(jī)中。

　　3)Kube-dns

　　從kubernetes 1.3開(kāi)始，kube-dns已經(jīng)不再使用etcd+skydns+kube2sky的方式。而是使用了dns緩存及轉(zhuǎn)發(fā)工具dnsmasq，以及利用skydns庫(kù)和本地內(nèi)存緩存組合而成的kube-dns。

　　Kube-dns將從kubernetes master中監(jiān)聽(tīng)變動(dòng)的service和endpoint信息，并建立從service ip 到service name的域名映射(對(duì)于無(wú)service的，將會(huì)建立pod ip和相應(yīng)域名的映射)。Kube-dns將這些信息存放在本地的內(nèi)存緩沖中，并監(jiān)聽(tīng)127.0.0.1:10053提供服務(wù)。

　　Dnsmasq是簡(jiǎn)單的域名服務(wù)、緩存和轉(zhuǎn)發(fā)工具，這里利用它的轉(zhuǎn)發(fā)功能將kube-dns的dns服務(wù)轉(zhuǎn)接到外部，參數(shù)–server=127.0.0.1:10053。

　　二.運(yùn)維管理

　　租戶資源管理Namespace(命名空間)

　　namespace 是kubernete用來(lái)做租戶管理的對(duì)象。每個(gè)租戶獨(dú)享自己的邏輯空間，包括replication controller、 pod、 service、 deployment、configmap等。 ?常用的查看方式：

　　kubectl get --namespace=

　　或查看所有namespace的某類資源

　　kubectl get --all-namespaces

　　例如：查看所有的pod，并希望看到所部署的節(jié)點(diǎn)位置

　　kubectl get pod –all-namespaces –o wide

　　查看namespace為 test的replication controller，以及l(fā)abet

　　kubectl get rc –namespace=test –show-labels

　　配置管理ConfigMap

　　當(dāng)服務(wù)運(yùn)行在容器中時(shí)，需要訪問(wèn)外部的變量，或者需要根據(jù)環(huán)境的不同更改配置文件，比如，DB以傳統(tǒng)的方式運(yùn)行在容器云之外，當(dāng)服務(wù)啟動(dòng)時(shí)，需要初始化包含DB信息的配置文件。當(dāng)需要切換db時(shí)，就需要更改配置文件， 當(dāng)容器中有服務(wù)在運(yùn)行時(shí)， 并不推薦登陸到容器內(nèi)進(jìn)行文件配置更改。

　　合理的方式是利用kubernetes的配置管理，將配置信息寫入到ConfigMap, 并掛載到對(duì)應(yīng)的pod中。 

　　例如golang程序golang-sample需要訪問(wèn)配置文件db.json,內(nèi)容如下：

　　當(dāng)pod創(chuàng)建運(yùn)行后，服務(wù)在pod容器內(nèi)只需要讀取固定位置的配置文件， 當(dāng)配置需要改變時(shí)， 更新ConfigMap并重新分發(fā)到pod內(nèi)，這樣重啟容器后，容器內(nèi)所掛載的配置也會(huì)相應(yīng)更新。當(dāng)需要pod容器同時(shí)使用一個(gè)ConfigMap 時(shí)，更新ConfigMap內(nèi)容的同時(shí)，可以批量更新容器的配置。

　　主機(jī)運(yùn)維管理

　　對(duì)于運(yùn)維操作來(lái)說(shuō)，kubectl是一個(gè)很便利的命令行工具，首先可以對(duì)各種資源進(jìn)行操作，比如添加、獲取、刪除，通過(guò)更多命令參數(shù)得到指定的信息。

　　獲取資源列表及詳細(xì)信息的方式可通過(guò)kubectl get 來(lái)進(jìn)行，具體的操作運(yùn)行kubectl get –help即可。

　　實(shí)踐使用過(guò)程中，對(duì)節(jié)點(diǎn)的運(yùn)維操作會(huì)影響到應(yīng)用的使用和資源的調(diào)度，比如由于配置升級(jí)需要對(duì)節(jié)點(diǎn)主機(jī)進(jìn)行重啟，需要考慮已經(jīng)運(yùn)行在其上的容器的狀況，用戶的希望是對(duì)資源池的操作盡量少的影響容器應(yīng)用，同時(shí)資源池的變動(dòng)和上層的容器服務(wù)解藕。

　　當(dāng)需要對(duì)主機(jī)進(jìn)行維護(hù)升級(jí)時(shí)，首先將節(jié)點(diǎn)主機(jī)設(shè)置成不可調(diào)度模式：

　　這樣新創(chuàng)建的容器即可以分配到該主機(jī)，可以通過(guò)kubectl patch 對(duì)資源對(duì)象進(jìn)行實(shí)時(shí)修改，比如為service增加端口，為pod修改容器鏡像版本。Annotation 可以幫助用戶更好的設(shè)置kubernete自定義插件。用戶可以在自建組件中獲取資源中對(duì)應(yīng)的annotation以此進(jìn)行操作。通過(guò)kubectl label可以方便的對(duì)資源打標(biāo)簽，比如對(duì)node打標(biāo)簽，然后容器調(diào)度時(shí)可指定分配到對(duì)應(yīng)標(biāo)簽的主機(jī)。

　　Kubernetes作為容器集群管理工具,為應(yīng)用平臺(tái)提供了基于云原生的微服務(wù)支持，其活躍的社區(qū)吸引了廣大開(kāi)發(fā)者的熱情關(guān)注，刺激了容器周邊生態(tài)的快速發(fā)展，同時(shí)為眾多互聯(lián)網(wǎng)企業(yè)采用容器集群架構(gòu)升級(jí)內(nèi)部IT平臺(tái)設(shè)施，構(gòu)建高效大規(guī)模計(jì)算體系提供了技術(shù)基礎(chǔ)。

　?。ㄔ膩?lái)自CSDN）