Kubernetes技術(shù)分享

1、Kubernetes技術(shù)分享架構(gòu)簡(jiǎn)介集群搭建常用命令應(yīng)用實(shí)例Kubernetes簡(jiǎn)介Kubernetes是谷歌嚴(yán)格保密十幾年的秘密武器Borg的一個(gè)開源版本，是一個(gè)全新的基于容器技術(shù)的分布式架構(gòu)領(lǐng)先方案。Borg是谷歌內(nèi)部使用的大規(guī)模集群管理系統(tǒng)，基于容器技術(shù)，目的是實(shí)現(xiàn)資源管理的自動(dòng)化，以及跨多個(gè)數(shù)據(jù)中心的資源利用率的最大化；K8s是第一個(gè)將”一切以服務(wù)為中心，一切圍繞服務(wù)運(yùn)轉(zhuǎn)”作為指導(dǎo)思想的創(chuàng)新型產(chǎn)品K8s是Go語(yǔ)言開發(fā)，是Docker的上層架構(gòu)，就好像Java與J2EE的關(guān)系一樣K8s是一個(gè)開放的開發(fā)平臺(tái)，不局限于任何語(yǔ)言Kubernetes主要功能主要功能k8s能方便地管理跨機(jī)器運(yùn)行容

2、器化的應(yīng)用提供應(yīng)用部署、維護(hù)、擴(kuò)展機(jī)制集群管理、安全防護(hù)、準(zhǔn)入機(jī)制、多應(yīng)用支撐、服務(wù)注冊(cè)、服務(wù)發(fā)現(xiàn)、智能負(fù)載均衡、故障發(fā)現(xiàn)、自我修復(fù)、服務(wù)滾動(dòng)升級(jí)、在線擴(kuò)容、資源配額管理使用Docker對(duì)應(yīng)用程序包裝、實(shí)例化、運(yùn)行以集群的方式運(yùn)行、管理跨機(jī)器的容器解決Docker跨機(jī)器容器之間的通訊問題k8s的自我修復(fù)機(jī)制使得容器集群總是運(yùn)行在用戶期望的狀態(tài)為什么使用為什么使用Kubernetes?K8s不僅僅支持Docker，還支持Rocket，這是另一種容器技術(shù)。全面擁抱微服務(wù)架構(gòu)使用k8s我們系統(tǒng)可以隨時(shí)的整體遷移k8s系統(tǒng)具備了超強(qiáng)的橫向擴(kuò)容能力k8s提供完善的管理工具，涵蓋了包括開發(fā)、部署測(cè)試、運(yùn)維

3、監(jiān)控在內(nèi)的各個(gè)環(huán)節(jié)K8s集群K8s架構(gòu)K8s體系結(jié)構(gòu)Master集群控制管理節(jié)點(diǎn)，所有的命令都經(jīng)由master處理負(fù)責(zé)整個(gè)集群的管理和控制，基本上Kubernetes所有的控制命令都是發(fā)給它，它來負(fù)責(zé)具體的執(zhí)行過程，我們后面所有執(zhí)行的命令基本都是在Master節(jié)點(diǎn)上運(yùn)行的1.Kubernetes API Server（kube-apiserver），提供Http Rest接口的關(guān)鍵服務(wù)進(jìn)程，是Kubernetes里所有資源的增、刪、改、查等操作的唯一入口，也是集群控制的入口進(jìn)程2.Kubernetes Controller Manager（kube-controller-manager），Ku

4、bernetes里所有資源對(duì)象的自動(dòng)化控制中心，可以理解為資源對(duì)象的“大總管”3.Kubernetes Scheduler（kube-scheduler），負(fù)責(zé)資源調(diào)度（Pod調(diào)度）的進(jìn)程，相當(dāng)于公交公司的“調(diào)度室”4.etcd Server，Kubernetes里所有的資源對(duì)象的數(shù)據(jù)全部是保存在etcd中,(集群部署，不與master放同一臺(tái)機(jī)器)MasterMasteretcdetcd是一個(gè)高可用的鍵值存儲(chǔ)系統(tǒng)，主要用于共享配置和服務(wù)發(fā)現(xiàn)。對(duì)比與ZooKeeper，etcd更輕量級(jí)1.etcd是由CoreOS開發(fā)并維護(hù)的，靈感來自于 ZooKeeper 和 Doozer，提供了與ZooKe

5、eper相似的功能，它使用Go語(yǔ)言編寫，并通過Raft一致性算法處理日志復(fù)制以保證強(qiáng)一致性。Raft是一個(gè)新的一致性算法，適用于分布式系統(tǒng)的日志復(fù)制，Raft通過選舉的方式來實(shí)現(xiàn)一致性。Google的容器集群管理系統(tǒng)Kubernetes、開源PaaS平臺(tái)Cloud Foundry和CoreOS的Fleet都廣泛使用了etcd。在分布式系統(tǒng)中，如何管理節(jié)點(diǎn)間的狀態(tài)一直是一個(gè)難題，etcd像是專門為集群環(huán)境的服務(wù)發(fā)現(xiàn)和注冊(cè)而設(shè)計(jì)，它提供了數(shù)據(jù)TTL失效、數(shù)據(jù)改變監(jiān)視、多值、目錄監(jiān)聽、分布式鎖原子操作等功能，可以方便的跟蹤并管理集群節(jié)點(diǎn)的狀態(tài)etcd簡(jiǎn)單: 支持curl方式的用戶API（HTTP+J

6、SON）安全: 可選的SSL客戶端證書認(rèn)證快速: 單實(shí)例每秒 1000 次讀寫能力可靠: 使用Raft保證強(qiáng)一致性Etcd的應(yīng)用場(chǎng)景包括服務(wù)發(fā)現(xiàn)（Service Discovery）、消息發(fā)布與訂閱、負(fù)載均衡、分布式通知與協(xié)調(diào)、分布式鎖、分布式隊(duì)列。如果你熟悉ZooKeeper, 你會(huì)發(fā)現(xiàn)etcd實(shí)現(xiàn)了ZooKeeper的功能Node除了Master，Kubernetes集群中的其他機(jī)器被稱為Node節(jié)點(diǎn)， 早期版本也稱為Minion節(jié)點(diǎn)Node節(jié)點(diǎn)才是Kubernetes集群中的工作負(fù)載節(jié)點(diǎn)，每個(gè)Node都會(huì)被Master分配一些工作負(fù)載（Docker容器），當(dāng)某個(gè)Node宕機(jī)，其上的工作負(fù)

7、載會(huì)被Master自動(dòng)轉(zhuǎn)移到其他節(jié)點(diǎn)上去1.kubelet，負(fù)責(zé)Pod對(duì)應(yīng)的容器的創(chuàng)建、啟停等任務(wù)，同時(shí)與Master節(jié)點(diǎn)密切協(xié)作，實(shí)現(xiàn)集群管理的基本功能。一旦Node被納入集群管理范圍，kubelet進(jìn)程就會(huì)向Master匯報(bào)自身的情報(bào)，這樣Master可以獲知每個(gè)Node的資源使用情況，并實(shí)現(xiàn)高效均衡的資源調(diào)度策略。而某個(gè)Node超過指定時(shí)間不上報(bào)信息，會(huì)被Master判定為“失聯(lián)”，Node狀態(tài)被標(biāo)記為不可用（Not Ready），隨后Master會(huì)觸發(fā)“工作負(fù)載大轉(zhuǎn)移”的自動(dòng)流程；2.kube-proxy，實(shí)現(xiàn)Kubernetes Service的通信與負(fù)載均衡機(jī)制的重要組件；3.Do

8、cker Engine（docker），Docker引擎，負(fù)責(zé)本機(jī)的容器創(chuàng)建和管理工作；Node Pod是最小部署單元，一個(gè)Pod由一個(gè)或多個(gè)容器組成，Pod中容器共享存儲(chǔ)和網(wǎng)絡(luò)，在同一臺(tái)Docker主機(jī)上運(yùn)行。 同一個(gè)Pod里的容器共享同一個(gè)網(wǎng)絡(luò)命名空間，可以使用localhost互相通信 1.每個(gè)Pod都有一個(gè)特殊的被稱為“根容器”的Pause容器，還包含一個(gè)或多個(gè)緊密相關(guān)的用戶業(yè)務(wù)容器；2.一個(gè)Pod里的容器與另外主機(jī)上的Pod容器能夠直接通信；3.如果Pod所在的Node宕機(jī)，會(huì)將這個(gè)Node上的所有Pod重新調(diào)度到其他節(jié)點(diǎn)上；4.普通Pod及靜態(tài)Pod，前者存放在etcd中，后者存放

9、在具體Node上的一個(gè)具體文件中，并且只能在此Node上啟動(dòng)運(yùn)行；5.Docker Volume對(duì)應(yīng)Kubernetes中的Pod Volume；6.每個(gè)Pod可以設(shè)置限額的計(jì)算機(jī)資源有CPU和Memory； Requests，資源的最小申請(qǐng)量；Limits，資源最大允許使用的量；PodPodPod、容器與、容器與Node關(guān)系關(guān)系Endpoint（IP+Port） 標(biāo)識(shí)服務(wù)進(jìn)程的訪問點(diǎn)Event 是一個(gè)事件記錄，記錄了事件最早產(chǎn)生的時(shí)間、最后重復(fù)時(shí)間、重復(fù)次數(shù)、發(fā)起者、類型，以及導(dǎo)致此事件的原因等信息。Event通常關(guān)聯(lián)到具體資源對(duì)象上，式排查故障的重要參考信息；Endpoint、EventS

10、ervice Service一個(gè)應(yīng)用服務(wù)抽象，定義了Pod邏輯集合和訪問這個(gè)Pod集合的策略。 Service代理Pod集合對(duì)外表現(xiàn)是為一個(gè)訪問入口，分配一個(gè)集群IP地址，來自這個(gè)IP的請(qǐng)求將負(fù)載均衡轉(zhuǎn)發(fā)后端Pod中的容器。 Service通過LableSelector選擇一組Pod提供服務(wù)。 在K8s集群中微服務(wù)的負(fù)載均衡是由Kube-proxy實(shí)現(xiàn)的，在K8s的每個(gè)節(jié)點(diǎn)上都有一個(gè)Service其實(shí)就是我們經(jīng)常提起的微服務(wù)架構(gòu)中的一個(gè)“微服務(wù)”，kubernetes中的核心。通過分析、識(shí)別并建模系統(tǒng)中的所有服務(wù)為微服務(wù)Kubernetes Service，最終我們的系統(tǒng)由多個(gè)提供不同業(yè)務(wù)能力

11、而又彼此獨(dú)立的微服務(wù)單元所組成，服務(wù)之間通過TCP/IP進(jìn)行通信，從而形成了我們強(qiáng)大而又靈活的彈性網(wǎng)絡(luò)，擁有了強(qiáng)大的分布式能力、彈性擴(kuò)展能力、容錯(cuò)能力ServiceServiceService 如上圖示，每個(gè)Pod都提供了一個(gè)獨(dú)立的Endpoint（Pod IP+ContainerPort）以被客戶端訪問，多個(gè)Pod副本組成了一個(gè)集群來提供服務(wù)，一般的做法是部署一個(gè)負(fù)載均衡器來訪問它們，為這組Pod開啟一個(gè)對(duì)外的服務(wù)端口如8000，并且將這些Pod的Endpoint列表加入8000端口的轉(zhuǎn)發(fā)列表中，客戶端可以通過負(fù)載均衡器的對(duì)外IP地址+服務(wù)端口來訪問此服務(wù)。運(yùn)行在Node上的kube-pro

12、xy其實(shí)就是一個(gè)智能的軟件負(fù)載均衡器，它負(fù)責(zé)把對(duì)Service的請(qǐng)求轉(zhuǎn)發(fā)到后端的某個(gè)Pod實(shí)例上，并且在內(nèi)部實(shí)現(xiàn)服務(wù)的負(fù)載均衡與會(huì)話保持機(jī)制。Service不是共用一個(gè)負(fù)載均衡器的IP地址，而是每個(gè)Servcie分配一個(gè)全局唯一的虛擬IP地址，這個(gè)虛擬IP被稱為Cluster IP。Service Node IP Node節(jié)點(diǎn)的IP地址，是Kubernetes集群中每個(gè)節(jié)點(diǎn)的物理網(wǎng)卡的IP地址，是真是存在的物理網(wǎng)絡(luò)，所有屬于這個(gè)網(wǎng)絡(luò)的服務(wù)器之間都能通過這個(gè)網(wǎng)絡(luò)直接通信； Pod IP Pod的IP地址，是Docker Engine根據(jù)docker0網(wǎng)橋的IP地址段進(jìn)行分配的，通常是一個(gè)虛擬的二

13、層網(wǎng)絡(luò)，位于不同Node上的Pod能夠彼此通信，需要通過Pod IP所在的虛擬二層網(wǎng)絡(luò)進(jìn)行通信，而真實(shí)的TCP流量則是通過Node IP所在的物理網(wǎng)卡流出的； Cluster IP Service的IP地址。特性如下： 僅僅作用于Kubernetes Servcie這個(gè)對(duì)象，并由Kubernetes管理和分配IP地址；無法被Ping，因?yàn)闆]有一個(gè)“實(shí)體網(wǎng)絡(luò)對(duì)象”來響應(yīng)；只能結(jié)合Service Port組成一個(gè)具體的通信端口； Node IP網(wǎng)、Pod IP網(wǎng)域Cluster IP網(wǎng)之間的通信，采用的是Kubernetes自己設(shè)計(jì)的一種編程方式的特殊的路由規(guī)則，與IP路由有很大的不同；Label

14、Label可以附加到各種資源對(duì)象上，一個(gè)資源對(duì)象可以定義任意數(shù)量的Label。給某個(gè)資源定義一個(gè)Label，相當(dāng)于給他打一個(gè)標(biāo)簽，隨后可以通過Label Selector（標(biāo)簽選擇器）查詢和篩選擁有某些Label的資源對(duì)象。我們可以通過給指定的資源對(duì)象捆綁一個(gè)或多個(gè)Label來實(shí)現(xiàn)多維度的資源分組管理功能，以便于靈活、方便的進(jìn)行資源分配、調(diào)度、配置、部署等管理工作； Label Selector示例：select * from pod where pods name=XXX,env=YYY，支持操作符有=、!=、in、not in； 部署和升級(jí)Pod，聲明某種Pod的副本數(shù)量在任意時(shí)刻都符合某

15、個(gè)預(yù)期值； Pod期待的副本數(shù)；用于篩選目標(biāo)Pod的Label Selector；當(dāng)Pod副本數(shù)量小于預(yù)期數(shù)量的時(shí)候，用于創(chuàng)建新Pod的Pod模板（template）；Replication Controller（RC） 下一代的Replication Controlle，RC與RS唯一區(qū)別就是lableselector支持不同，RS支持新的基于集合的標(biāo)簽，RC僅支持基于等式的標(biāo)簽。Replication Controlle只支持基于等式的selector（env=dev或environment!=qa）但Replica Set還支持新的、基于集合的selector（version in (v

16、1.0, v2.0)或env notin (dev, qa)），這對(duì)復(fù)雜的運(yùn)維管理帶來很大方便。Replica Set 擁有更加靈活強(qiáng)大的升級(jí)、回滾功能。在新的版本中，官方推薦使用Replica Set和Deployment來代替RC，兩者相似度90%，相對(duì)于RC一個(gè)最大升級(jí)是我們隨時(shí)指導(dǎo)當(dāng)前Pod“部署”的進(jìn)度。Deployment使用了Replica Set，除非需要自定義升級(jí)功能或根本不需要升級(jí)Pod，一般情況下，我們推薦使用Deployment而不直接使用Replica Set； 典型使用場(chǎng)景： 創(chuàng)建一個(gè)Deployment對(duì)象來生成對(duì)應(yīng)的Replica Set并完成Pod副本的創(chuàng)建過

17、程； 檢查更新Deployment的狀態(tài)來查看部署動(dòng)作是否完成（Pod副本的數(shù)量是否達(dá)到預(yù)期的值）； 更新Deployment以創(chuàng)建新的Pod；（比如鏡像升級(jí)） 如果當(dāng)前Deployment不穩(wěn)定，則回滾到一個(gè)早先的Deployment版本； 掛起或者恢復(fù)一個(gè)Deployment；Deployment 意思是Pod橫向自動(dòng)擴(kuò)容，目標(biāo)是實(shí)現(xiàn)自動(dòng)化、智能化擴(kuò)容或縮容。 Pod負(fù)載度量指標(biāo)： CPUUtilizationPercentage 通常使用一分鐘內(nèi)的平均值，可以通過Heapster擴(kuò)展組件獲取這個(gè)值。一個(gè)Pod自身的CPU利用率是該P(yáng)od當(dāng)前CPU的使用量除以它的Pod Request的值

18、。例如Pod Request定義值為0.4，當(dāng)前Pod使用量為0.2，則它的CPU使用率為50%。但如果沒有定義Pod Request值，則無法使用CPUUtilizationPercentage來實(shí)現(xiàn)Pod橫向自動(dòng)擴(kuò)容的能力； 應(yīng)用程序自定義的度量指標(biāo)，比如服務(wù)在每秒內(nèi)的相應(yīng)的請(qǐng)求書（TPS或QPS）Horizontal Pod Autoscaler（HPA）數(shù)據(jù)卷，是Pod中能夠被多個(gè)容器訪問的共享目錄。定義在Pod之上，被一個(gè)Pod里的多個(gè)容器掛載到具體的文件目錄之下；與Pod生命周期相同?？梢宰屢粋€(gè)Pod里的多個(gè)容器共享文件、讓容器的數(shù)據(jù)寫到宿主機(jī)的磁盤上或者寫文件到 共享存儲(chǔ)中Vol

19、ume命名空間將對(duì)象邏輯上分配到不同Namespace，可以是不同的項(xiàng)目、用戶等區(qū)分管理，并設(shè)定控制策略，從而實(shí)現(xiàn)多租戶。 命名空間也稱為虛擬集群。NamespaceNode、Pod、Replication Controller和Service等都可以看作是一種“資源對(duì)象”，幾乎所有的資源對(duì)象都可以通過Kubernetes提供的kubectl工具執(zhí)行增、刪、改、查等操作并將其保存在ectd中持久化存儲(chǔ)。Kubectl關(guān)閉CentOS自帶的防火墻服務(wù) systemctl disable firewall # systemctl stop firewall 安裝Etcd和Kubernetes軟件（

20、會(huì)自動(dòng)安裝docker軟件） yuminstallyetcdkubernetes 按順序啟動(dòng)所有服務(wù) systemctlstartetcd systemctlstart docker # systemctl start kube-apiserver # systemctl start kube-controller-manager # systemctl start kube-scheduler # systemctl start kubelet # systemctl start tube-proxy64位位 CentOS7 單機(jī)版單機(jī)版Kubernetes集群環(huán)境安裝集群環(huán)境安裝由于篇幅，

21、k8s集群安裝文檔，后續(xù)附件提供Kubernetes集群環(huán)境安裝集群環(huán)境安裝訪問地址：3:30001/#!/login獲取token: #kubectl -n kube-system describe $(kubectl -n kube-system get secret -n kube-system -o name | grep namespace) | grep tokenKubernetes-dashboardGrafana地址：2:30108/Kubernetes監(jiān)控監(jiān)控Kubernetes負(fù)載均衡負(fù)載均衡nginx

22、 ingressKubernetes 暴露服務(wù)的方式目前只有三種：LoadBlancer Service、NodePort Service、Ingress；前兩種估計(jì)都應(yīng)該很熟悉，下面詳細(xì)的了解下這個(gè) Ingress Ingress由兩部分組成：Ingress Controller 和 Ingress 服務(wù)。 Ingress Contronler 通過與 Kubernetes API 交互，動(dòng)態(tài)的去感知集群中 Ingress 規(guī)則變化，然后讀取它，按照自定義的規(guī)則，規(guī)則就是寫明了哪個(gè)域名對(duì)應(yīng)哪個(gè)service，生成一段 Nginx 配置，再寫到 Nginx-ingress-control的 Pod 里，這個(gè) Ingress Contronler 的pod里面運(yùn)行著一個(gè)nginx服務(wù)，控制器會(huì)把生成的nginx配置寫入/etc/nginx.conf文件中，然后 reload 一下 使用配置生效。以此來達(dá)到域名分配置及動(dòng)態(tài)更新的問題。Kubernetes負(fù)載均衡負(fù)載均衡nginx ingressDemo地址：1/demo/查看nginx-ingress容器里的nginx配置，是動(dòng)態(tài)變化的查看容器日志，輪詢?cè)L問兩臺(tái)tomcatKubernetes負(fù)載均