kubernetes容器編排系統(tǒng)的示例分析
這篇文章主要介紹了kubernetes容器編排系統(tǒng)的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。
成都創(chuàng)新互聯(lián)公司-專業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性價比鶴山網(wǎng)站開發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式鶴山網(wǎng)站制作公司更省心,省錢,快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋鶴山地區(qū)。費用合理售后完善，十年實體公司更值得信賴。
Kubernetes作為容器編排生態(tài)圈中重要一員，是Google大規(guī)模容器管理系統(tǒng)borg的開源版本實現(xiàn)，吸收借鑒了google過去十年間在生產(chǎn)環(huán)境上所學到的經(jīng)驗與教訓。 Kubernetes提供應(yīng)用部署、維護、 擴展機制等功能，利用Kubernetes能方便地管理跨機器運行容器化的應(yīng)用。當前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平臺，除此之外，也可以直接運行在物理機上.kubernetes是一個開放的容器調(diào)度管理平臺，不限定任何一種言語，支持java/C++/go/python等各類應(yīng)用程序 。
kubernetes是一個完備的分布式系統(tǒng)支持平臺，支持多層安全防護、準入機制、多租戶應(yīng)用支撐、透明的服務(wù)注冊、服務(wù)發(fā)現(xiàn)、內(nèi)建負載均衡、強大的故障發(fā)現(xiàn)和自我修復機制、服務(wù)滾動升級和在線擴容、可擴展的資源自動調(diào)度機制、多粒度的資源配額管理能力,完善的管理工具，包括開發(fā)、測試、部署、運維監(jiān)控，一站式的完備的分布式系統(tǒng)開發(fā)和支撐平臺。
一. 系統(tǒng)架構(gòu)
kubernetes系統(tǒng)按節(jié)點功能由master和node組成。
Master
Master作為控制節(jié)點，調(diào)度管理整個系統(tǒng)，包含以下組件：
API Server作為kubernetes系統(tǒng)的入口，封裝了核心對象的增刪改查操作，以RESTful接口方式提供給外部客戶和內(nèi)部組件調(diào)用。它維護的REST對象將持久化到etcd。
Scheduler：負責集群的資源調(diào)度，為新建的pod分配機器。這部分工作分出來變成一個組件，意味著可以很方便地替換成其他的調(diào)度器。
Controller Manager：負責執(zhí)行各種控制器，目前有兩類：
Endpoint Controller：定期關(guān)聯(lián)service和pod(關(guān)聯(lián)信息由endpoint對象維護)，保證service到pod的映射總是最新的。
Replication Controller：定期關(guān)聯(lián)replicationController和pod，保證replicationController定義的復制數(shù)量與實際運行pod的數(shù)量總是一致的。
Node
Node是運行節(jié)點，運行業(yè)務(wù)容器，包含以下組件：
Kubelet：責管控docker容器，如啟動/停止、監(jiān)控運行狀態(tài)等。它會定期從etcd獲取分配到本機的pod，并根據(jù)pod信息啟動或停止相應(yīng)的容器。同時，它也會接收apiserver的HTTP請求，匯報pod的運行狀態(tài)。
Kube Proxy：負責為pod提供代理。它會定期從etcd獲取所有的service，并根據(jù)service信息創(chuàng)建代理。當某個客戶pod要訪問其他pod時，訪問請求會經(jīng)過本機proxy做轉(zhuǎn)發(fā)。
借用一張網(wǎng)圖，表達功能組件之間關(guān)系：
二.基本概念
Node
node是kubernetes集群中相對于master而言的工作主機，在較早版本中也被稱為minion。Node可以是一臺物理主機，也可以是一臺虛擬機（VM）。在每個node上運行用于啟動和管理pod的服務(wù)——kubelet，并能夠被master管理。在node上運行的服務(wù)進程包括kubelet、kube-proxy和docker daemon。
Node的信息如下：
node地址：主機的IP地址或者nodeid
node的運行狀態(tài): pending,running,terminated
node condition: 描述running狀態(tài)node的運行條件，目前只有一種條件Ready，表示node處于健康狀態(tài)，可以接收master發(fā)來的創(chuàng)建pod的指令。
node系統(tǒng)容量：描述node可用的系統(tǒng)資源，包括CPU、內(nèi)存、最大可調(diào)度pod數(shù)量等
Pod
pod是kubernetes的最基本操作單元，包括一個或多個緊密相關(guān)的容器，一個pod可以被一個容器化的環(huán)境看作應(yīng)用層的“邏輯宿主機”（Logical host）。一個pod中的多個容器應(yīng)用通常是緊耦合的。Pod在node上被創(chuàng)建、啟動或者銷毀。
為什么kubernetes使用pod在容器之上再封裝一層呢？一個很重要的原因是,docker容器之間通信受到docker網(wǎng)絡(luò)機制的限制。在docker的，世界中，一個容器需要通過link方式才能訪問另一個容器提供的服務(wù)（端口）。大量容器之間的link將是一個非常繁重的工作。通過pod的概念將多個容器組合在一個虛擬的“主機”內(nèi)，可以實現(xiàn)容器之間僅需通過localhost就能相互通信了。
一個pod中的應(yīng)用容器共享一組資源，如：
pid命名空間：pod中的不同應(yīng)用程序可以看到其他的進程PID
網(wǎng)絡(luò)命名空間：pod中的多個容器能夠訪問同一個IP和端口范圍
IPC命名空間：pod中的多個容器能夠使用systemV ipc 或POSIX消息隊列進行通信。
UTS命名空間：pod中的多個容器共享一個主機名。
Volumes(共享存儲卷)：pod中的各個容器可以訪問在pod級別定義的volumes。
Label
label是kubernetes系統(tǒng)中的一個核心概念。Label以key/value鍵值對的形式附加到各種對象上，如pod、service、RC、Node等。Label定義了這些對象的可識別屬性，用來對它們進行管理和選擇。Label可以在創(chuàng)建對象時附加到對象上，也可以在對象創(chuàng)建后通過API進行管理。
在為對象定義好label后，其他對象就可以使用label selector來定義其他作用的對象了。
label selector的定義由多個逗號分隔的條件組成：
“l(fā)abel”: {
“key1”: ”value1”,
“key2”: ”value2”
}
Resource controller(RC)
Resource controller(RC)是kubernetes系統(tǒng)中的核心概念，用于定義pod副本的數(shù)量。在master的Controller manager進程通過RC的定義來完成pod的創(chuàng)建、監(jiān)控、啟停等操作。
根據(jù)replication controller的定義，kubernetes能夠確保在任意時刻都能運行用戶指定的pod“副本”（replica）數(shù)量。如果有過多的的pod副本在運行，系統(tǒng)會停掉一些pod；如果運行的pod副本數(shù)量太少，系統(tǒng)就會再啟動一些pod，總之，通過RC的定義，kubernetes總是保證集群中運行著用戶期望副本數(shù)量。
Service(服務(wù))
在kubernetes的世界里，雖然每個pod都會被分配一個單獨的IP地址，但這個IP地址會隨著pod的銷毀而消失。這就引出一個問題：如果有一組pod組成一個集群來提供服務(wù)，那么如何來訪問它們呢？
kubernetes的service就是用來解決這個問題的核心概念。一個service可以看作一組提供相同服務(wù)的pod的對外訪問接口。Service作用于哪些pod是通過label selector 來定義的。
pod的IP地址是docker daemon根據(jù)docker0網(wǎng)橋的IP地址段進行分配的，但service的Cluster IP地址是kubernetes系統(tǒng)中的虛擬IP地址，由系統(tǒng)動態(tài)分配。 Service的ClusterIP地址相對于pod的IP地址來說相對穩(wěn)定，service被創(chuàng)建時即被分配IP地址，在銷毀該service之前，這個IP地址都不會再變化。
由于service對象在Cluster IP Range池中分配到的IP只能在內(nèi)部訪問，所以其他pod都可以無障礙地訪問到它。但如果這個service作為前端服務(wù)，準備為集群外的客戶端提供服務(wù)，我們就需要給這個服務(wù)提供公共IP了。
kubernetes支持兩種對外提供服務(wù)的service的type定義：nodeport和loadbalancer。
Volume(存儲卷)
volume是pod中能夠被多個容器訪問的共享目錄。Kubernetes的volume概念與docker的volume比較類似，但并不完全相同。Kubernetes中的volume與pod生命周期相同，但與容器的生命周期不相關(guān)。當容器終止或重啟時，volume中的數(shù)據(jù)也不會丟失。另外，kubernetes支持多種類型的volume，并且一個pod可以同時使用任意多個volume。
（1）EmptyDir:一個EmptyDir volume是在pod分配到Node時創(chuàng)建的。從它的名稱就可以看出，它的初始內(nèi)容為空。在同一個pod中所有容器可以讀和寫EmptyDir中的相同文件。當pod從node上移除時，EmptyDir中的數(shù)據(jù)也會永久刪除。
（2）hostPath：在pod上掛載宿主機上的文件或目錄。通常用于：
容器應(yīng)用程序生成的日志文件需要永久保存，可以使用宿主機的高速文件系統(tǒng)進行存儲；
需要訪問宿主機上的docker引擎內(nèi)部數(shù)據(jù)結(jié)構(gòu)的容器應(yīng)用，可以通過定義hostPath為宿主機/var/lib/docker目錄，使容器內(nèi)部應(yīng)用可以直接訪問docker的文件系統(tǒng)
（3）gcePersistentDick:使用這種類型的volume表示使用谷歌計算引擎（Google Compute Engine, GCE）上永久磁盤（persistent disk,PD）上的文件。與EmptyDir不同，PD上的內(nèi)容會永久保存，當pod被刪除時，PD只是被卸載（unmount），但不會被刪除。需要注意的是，你需要先創(chuàng)建一個永久磁盤（PD）才能使用gcePersistentDisk。
（4）awsElasticBlockStore：與GCE類似，該類型的volume使用Amazon提供的Amazon Web Service（AWS）的EBS Volume，并可以掛載到pod中去。需要注意的是，需要先創(chuàng)建一個EBS Volume才能使用awsElasticBlockStore。
（5）nfs：使用NFS（網(wǎng)絡(luò)文件系統(tǒng)）提供的共享目錄掛載到Pod中。在系統(tǒng)中需要一個支行中的NFS系統(tǒng)。
（6）iscsi：使用iSCSI存儲設(shè)備上的目錄掛載到pod中。
（7）glusterfs：使用開源BlusterFS網(wǎng)絡(luò)文件系統(tǒng)的目錄掛載到pod中。
（8）rbd：使用Linux塊設(shè)備共享存儲（Rados Block Device）掛載到pod中。
（9）gitRepo：通過掛載一個空目錄，并從GIT庫clone一個git repository以供pod使用。
（10）secret:一個secret volume用于為pod提供加密的信息，你可以將定義在kubernetes中的secret直接掛載為文件讓pod訪問。Secret volume是通過tmfs（內(nèi)存文件系統(tǒng)）實現(xiàn)的，所以這種類型的volume總是不會持久化的。
（11）persistentVolumeClaim：從PV（persistentVolume）中申請所需的空間，PV通常是種網(wǎng)絡(luò)存儲，如GCEPersistentDisk、AWSElasticBlockStore、NFS、iSCSI等。
Namespace（命名空間）
namespace（命名空間）是kubernetes系統(tǒng)中另一個非常重要的概念，通過將系統(tǒng)內(nèi)部的對象“分配”到不同的namespace中，形成邏輯上分組的不同項目、小組或用戶組，便于不同的分組在共享使用整個集群的資源的同時還能分別管理。
kubernetes集群在啟動后，會創(chuàng)建一個名為“default”的namespace。接下來，如果不特別指明namespace，則用戶創(chuàng)建的pod、RC、Service都將被系統(tǒng)創(chuàng)建到名為“default”的namespace中。
使用namespace來組織kubernetes的各種對象，可以實現(xiàn)對用戶的分組，即“多租戶”管理。對不同的租房還可以進行單獨的資源配額設(shè)備和管理，使得整個集群配置非常靈活、方便。
Annotation（注解）
annotation與label類似，也使用key/value鍵值對的形式進行定義。Label具有嚴格的全名規(guī)則，它定義的是kubernetes對象的元數(shù)據(jù)（metadata），并且用于label selector。Annotation則是用戶任意定義的“附加”信息，以便于外部工具進行查找。
用annotation來記錄的信息包括：
build信息、release信息、docker鏡像信息等，如時間戳、release id號、PR號、鏡像hash值、docker Controller地址等
典型流程
以創(chuàng)建一個Pod為例，kubernetes典型的流程如下圖所示：
三.組件
Replication Controller
為了區(qū)分Controller Manager中的Replication Controller(副本控制器)和資源對象Replication Controller，我們將資源對象簡寫為RC，而Replication Controller特指“副本控制器”。
Replication Controller的核心作用是確保在任何時間集群中一個RC所關(guān)聯(lián)的pod都保持一定數(shù)量的pod副本處于正常運行狀態(tài)。如果該類pod的pod副本數(shù)量太多，則Replication Controller會銷毀一些pod副本；反之Replication Controller會添加pod副本，直到該類pod的pod副本數(shù)量達到預設(shè)的副本數(shù)量。最好不要超過RC直接創(chuàng)建pod，因為Replication Controller會通過RC管理pod副本，實現(xiàn)自動創(chuàng)建、補足、替換、刪除pod副本，這樣就能提高系統(tǒng)的容災能力，減少由于節(jié)點崩潰等意外狀況造成的損失。即使應(yīng)用程序只用到一個pod副本，也強烈建設(shè)使用RC來定義pod。
Replication Controller管理的對象是pod，因此其操作與pod的狀態(tài)及重啟策略息息相關(guān)。
副本控制器的常用使用模式：
（1）重新調(diào)度：不管想運行1個副本還是1000副本，副本控制器能夠確保指定pod數(shù)量的副本存在于集群中，如果節(jié)點故障或副本被終止運行等意外情況，將會重新調(diào)度直到達到預期的副本正常運行。
（2）彈性伸縮：手動或通過自動擴容代理修改副本控制器的spec.replicas屬性值，非常容易實現(xiàn)擴大或縮小副本的數(shù)量。
（3）滾動更新：副本控制器被設(shè)計成通過逐個替換pod的方式來輔助服務(wù)的滾動更新。推薦的方式是創(chuàng)建一個新的只有一個副本的RC，若新的RC副本數(shù)量加1，則舊的RC的副本數(shù)量減1，直到這個舊的RC副本數(shù)量為零，然后刪除該舊的RC。
在滾動更新的討論中，我們發(fā)現(xiàn)一個應(yīng)用在滾動更新時，可能存在多個版本的release。事實上，在生產(chǎn)環(huán)境中一個已經(jīng)發(fā)布的應(yīng)用程序存在多個release版本是很正常的現(xiàn)象。通過RC的標簽選擇器，我們能很方便地實現(xiàn)對一個應(yīng)用的多版本release的跟蹤。
node controller
Node Controller負責發(fā)現(xiàn)、管理和監(jiān)控集群中的各個node節(jié)點。Kubelet在啟動時通過API Server注冊節(jié)點信息，并定時向API Server發(fā)送節(jié)點信息。API Server接收到這些信息后，將這些信息寫入etcd。存入etcd的節(jié)點信息包括節(jié)點健康狀況、節(jié)點資源、節(jié)點名稱、節(jié)點地址信息、操作系統(tǒng)版本、docker版本、kubelet版本等。節(jié)點健康狀況包含“就緒（true）”、“未就緒(false)”和“未知（unknown）”三種。
（1）Controller Manager 在啟動時如果設(shè)置了—cluster-cidr參數(shù)，那么為每個沒有設(shè)置spec.podCIDR的node生成一個CIDR地址，并用該CIDR設(shè)置節(jié)點的spec.PodCIDR屬性，這樣的目的是防止不同節(jié)點的CIDR地址發(fā)生沖突。
（2）逐個讀取節(jié)點的信息，多次嘗試修改nodeStatusMap中的節(jié)點狀態(tài)信息，將該節(jié)點信息和node controller的nodeStatusMap中保存的節(jié)點信息比較。如果判斷中沒有收到kubelet發(fā)送的節(jié)點信息、第一次收到節(jié)點kubelet發(fā)送的節(jié)點信息，或在該處理過程中節(jié)點狀態(tài)變成非“健康”狀態(tài)，則在nodeStatusMap中保存該節(jié)點的狀態(tài)信息，并用node controller所在節(jié)點的系統(tǒng)時間作為探測時間和節(jié)點狀態(tài)變化時間。
如果判斷出在某一段時間內(nèi)沒有收到節(jié)點的狀態(tài)信息，則設(shè)置節(jié)點狀態(tài)為“未知（unknown）”，并且通過api server保存節(jié)點狀態(tài)。
（3）逐個讀取節(jié)點信息，如果節(jié)點狀態(tài)變?yōu)榉恰熬途w”狀態(tài)，則將節(jié)點加入待刪除隊列，否則將節(jié)點從該隊列中刪除。如果節(jié)點狀態(tài)為非“就緒”狀態(tài)，且系統(tǒng)指定了Cloud Provider，則node controller調(diào)用Cloud Provider查看節(jié)點，若發(fā)現(xiàn)并節(jié)點故障，則刪除etcd中的節(jié)點信息，并刪除和該節(jié)點相關(guān)的pod等資源的信息。
ResourceQuota controller
作為容器集群的管理平臺， kubernetes也提供了資源配額管理這一高級功能，資源配額管理確保指定的對象在任何時候都不會超量占用系統(tǒng)資源，避免了由于某些業(yè)務(wù)進程的設(shè)計或?qū)崿F(xiàn)的缺陷導致整個系統(tǒng)運行紊亂甚至意外宕機，對整個集群的平穩(wěn)運行和穩(wěn)定性有非常重要的作用。
目前kubernetes支持三個層次的資源配額管理：
（1）容器級別，可以對CPU和內(nèi)存的資源配額管理。
（2）pod級別，可以對pod內(nèi)所有容器的可用資源進行限制。
（3）namespace級別，為namespace（可以用于多租戶）級別的資源限制，包括：pod數(shù)量、replication Controller數(shù)量、service數(shù)量、ResourceQuota數(shù)量、secret數(shù)量、可持有的PV（persistent volume）數(shù)量。
kubernetes的配額管理是通過準入機制（admission control）來實現(xiàn)的，與配額相關(guān)的兩種準入控制器是LimitRanger和ResoureQuota，其中LimitRanger作用于pod和container上，ResourceQuota則作用于namespace上。此外，如果定義了資源配額，則scheduler在pod調(diào)度過程中也會考慮這一因素，確保pod調(diào)度不會超出配額限制。
典型的資源控制流程如下圖所示：
namaspace controller
用戶通過API Server可以創(chuàng)建新的namespace并保存在etcd中，namespace controller定時通過api server讀取這些namespace信息。如果namespace被API標識為優(yōu)雅刪除（設(shè)置刪除期限，deletionTimestamp屬性被設(shè)置），則將該namespace的狀態(tài)設(shè)置為“terminating”并保存到etcd中。同時namespace controller刪除該namespace下的serviceAccount、RC、Pod、Secret、PersistentVolume、ListRange、SesourceQuota和event等資源對象。
當namespace的狀態(tài)被設(shè)置為“terminating”后，由Adminssion Controller的NamespaceLifecycle插件來阻止為該namespace創(chuàng)建新的資源。同時，在namespace controller刪除完該namespace中的所有資源對象后，Namespace Controller對該namespace執(zhí)行finalize操作，刪除namespace的spec.finalizers域中的信息。
如果Namespace Controller觀察到namespace設(shè)置了刪除期限（即DeletionTimestamp屬性被設(shè)置），同時namespacer 的spec.finalizers域值是空的，那么namespace controller將通過API Server刪除該namespace資源。
kubernetes安全控制
ServiceAccount Controller和token Controller是與安全相關(guān)的兩個控制器。ServiceAccount Controller在Controller Manager啟動時被創(chuàng)建。它監(jiān)聽Service Account的刪除事件和Namespace的創(chuàng)建、修改事件。如果在該Service Account的namespace中沒有default Service Account，那么ServiceAccount Controller為該Service Account的namespace創(chuàng)建一個default ServiceAccount。
在API Server的啟動中添加“—admission_control=ServiceAccount”后，API Server在啟動時會自己創(chuàng)建一個key和crt（/var/run/kubernetes/apiserver.crt和apiserver.key），然后在啟動./kube-controller-manager時添加參數(shù)service_account_privatge_key_file=/var/run/kubernetes/apiserver.key，這樣啟動kubernetes master后，就會發(fā)現(xiàn)在創(chuàng)建Service Account時系統(tǒng)會自動為其創(chuàng)建一個secret。
如果Controller Manager在啟動時指定參數(shù)為service-account-private-key-file，而且該參數(shù)所指定的文件包含一個PEM-encoded的編碼的RSA算法的私鑰，那么，Controler Manager會創(chuàng)建token controller對象。
Token controller
token controller對象監(jiān)聽Service Account的創(chuàng)建、修改和刪除事件，并根據(jù)事件的不同做不同的處理。如果監(jiān)聽到的事件是創(chuàng)建和修改Service Account事件，則讀取該Service Account的信息；如果該Service Account沒有Service Account Secret(即用于訪問Api server的secret)，則用前面提及的私鑰為該Service Account創(chuàng)建一個JWT Token，將該Token和ROOT CA（如果啟動時參數(shù)指定了該 ROOT CA）放入新建的secret中，將該新建的secret放入該Service Account中，同時修改etcd中Service Account的內(nèi)容。如果監(jiān)聽到的事件是刪除Service Account事件，則刪除與該Service Account相關(guān)的secret。
token controller對象同時監(jiān)聽secret的創(chuàng)建、修改和刪除事件，并根據(jù)事件的不同做不同的處理。如果監(jiān)聽到的事件是創(chuàng)建和修改secret事件，那么讀取該secret中annotation所指定的Service Account信息，并根據(jù)需要為該secret創(chuàng)建一個和其Service Account相關(guān)的token；如果監(jiān)聽到的事件是刪除secret事件，則刪除secret和相關(guān)的Service Account的引用關(guān)系。
service controller&endpoint controller
Kubernetes service是一個定義pod集合的抽象，或者被訪問都看作一個訪問策略，有時也被稱為微服務(wù)。
kubernetes中的service是種資源對象，各所有其他資源對象一樣，可以通過API Server的POST接口創(chuàng)建一個新的實例。在下面的例子代碼中創(chuàng)建了一個名為“MyServer”的Service，它包含一個標簽選擇器，通過該標簽選擇器選擇所有包含標簽為“app=MyApp”的pod作為該service的pod集合。Pod集合中的每個pod的80端口被映射到節(jié)點本地的9376端口，同時kubernetes指派一個集群IP（即虛擬IP）給該service。
{
“kind”: ”service”,
“apiVersion”: ”v1”,
“metadata”: {
“name”: ”MyService”
},
“spec”: {
“selector”: {
“app”: ”MyApp”
},
“ports”: [
{
“protocol”: ”TCP”,
“port”: 80,
“targetPort”: 9376
}
]
},
｝四.功能特性
Service 集群訪問流程（服務(wù)發(fā)現(xiàn)）
在kubernetes集群中的每個node上都運行著一個叫“kube-proxy”的進程，該進程會觀察master節(jié)點添加和刪除“service”和“endpoint”的行為，如圖中第1步所示。
kube-proxy為每個service在本地主機上開一個端口（隨機選擇）。任何訪問該端口的連接都被代理到相應(yīng)的一個后端pod上。Kube-proxy根據(jù)round robin算法及service的session粘連（SessionAffinity）決定哪個后臺pod被選中，如第2步所示。
最后，如第3步所示，kube-proxy在本機的iptables中安裝相應(yīng)的規(guī)則，這些規(guī)則使得iptables將捕獲的流量重定向到前面提及的隨機端口。通過該端口流量再被kube-proxy轉(zhuǎn)到相應(yīng)的后端pod上。
在創(chuàng)建了服務(wù)后，服務(wù)endpoint模型會創(chuàng)建后端pod的IP和端口列表（包含中endpoint對象中），kube-proxy就是從這個endpoint列表中選擇服務(wù)后端的。集群內(nèi)的節(jié)點通過虛擬IP和端口能夠訪問service后臺的pod。
在默認情況下，kubernetes會為server指定一個集群IP（或虛擬IP、cluster IP），但在某些情況下，希望能夠自己指定該集群IP。為了給service指定集群IP，用戶只需要在定義service時，在service的spec.clusterIP域中設(shè)置所需要的IP地址即可。
Scheduler（調(diào)度）
scheduler在整個kubernetes系統(tǒng)中承擔了“承上啟下”的重要功能，“承上”是指它負責接收Controller Manager創(chuàng)建的新pod，為其安排一個落腳的“家”——目標node；“啟下”是指安置工作完成后，目標node上的kubelet服務(wù)進程接管后繼工作，負責pod生命周期中的“下半生”。
具體來說，scheduler的作用是將待調(diào)度的pod（API新創(chuàng)建的Pod、Controller Manager為補足副本而創(chuàng)建的pod等）按照特定的調(diào)度算法和調(diào)度策略綁定（binding）到集群中的某個合適的node上，并將綁定信息寫入etcd中。在整個調(diào)度過程中涉及三個對象，分別是：待調(diào)度的pod列表、可用node列表、以及調(diào)度算法和策略。簡單地說，就是通過調(diào)度算法調(diào)度，為待調(diào)度pod列表中的每個pod從node列表中選擇一個最適合的node。
隨后，目標node上的kublet通過API Server監(jiān)聽到scheduler產(chǎn)生的pod綁定事件，然后獲對應(yīng)的取pod，下載image鏡像，并啟動容器。
Scheduler（調(diào)度策略）
scheduler當前提供的默認調(diào)度流程分為兩步：
（1）預選調(diào)度過程，即遍歷所有目標node，篩選出符合要求的候選節(jié)點。為此kubernetes內(nèi)置了多種預先策略（xxx predicates）供用戶選擇。
（2）確定最優(yōu)節(jié)點，在第一步的基礎(chǔ)上，采用優(yōu)先策略（xxx priority）計算出每個候選節(jié)點的積分，積分最高都勝出。
scheduler的調(diào)度流程是通過插件方式加載的“調(diào)度算法提供者（AlgorithmProvider）”具體實現(xiàn)的。一個AlgorithmProvider其實就是包括了一組預選策略與一組優(yōu)選策略的結(jié)構(gòu)體，注冊AlgorithmProvider的函數(shù)如下：
func RegisterAlgorithmProvider(name string, predicateKeys, priorityKeys util.StringSet)
它包含3個參數(shù)，name string 參數(shù)為算法名；
predicateKeys參數(shù)為算法集合用到的預選策略集合
priorityKeys 參數(shù)為算法用到的優(yōu)選策略集合
scheduler 中可用的預選策略包含7個，每個節(jié)點只有通過PodFitsPorts、PodFitsResources、NoDiskConflict、PodSelectorMatches、PodFitsHost 5個默認預先策略后，才能初步被選中，進入下一個流程。
每個節(jié)點通過優(yōu)選策略時都會算出一個得分，計算各項得分，最終選出得分值最大的節(jié)點作為優(yōu)選的結(jié)果（也是調(diào)度算法的結(jié)果）。LeastRequestedPriority，選擇資源消耗最小節(jié)點：
(1)計算出所有備選節(jié)點上運行的pod和備選pod的CPU占用量totalMilliCPU
(2)計算出所有備選節(jié)點上運行的pod和備選pod的內(nèi)存占用量totalMomory
(3)計算每個節(jié)點的得分，計算規(guī)則大致如下：
score=int(((nodeCpuCapacity-totalMilliCPU)10)/nodeCpuCapacity+((nodeMemoryCapacity-totalMemory)10/nodeMemoryCapacity)/2)
CalculateNodeLabelPriority，根據(jù)CheckNodeLabelPresence策略打分
BalancedResourceAllocation，選擇資源使用最均衡節(jié)點
(1)計算出所有備選節(jié)點上運行的pod和備選pod的CPU占用量totalMilliCPU
(2)計算出所有備選節(jié)點上運行的pod和備選pod的內(nèi)存占用量totalMomory
(3)計算每個節(jié)點的得分，計算規(guī)則大致如下：
score=int(10-math.abs(totalMilliCPU/nodeCpuCapacity-totalMemory/nodeMemoryCapacity) * 10)
節(jié)點管理
節(jié)點管理包含節(jié)點的注冊、狀態(tài)上報、Pod管理、容器健康檢查、資源監(jiān)控等部分。
節(jié)點注冊
在kubernetes集群中，在每個node節(jié)點上都會啟動一個kubelet服務(wù)進程。該進程用于處理master節(jié)點下發(fā)到本節(jié)點的任務(wù)，管理pod及pod中的容器。每個kubelet進程會在API Server上注冊節(jié)點自身信息，定期向master節(jié)點匯報節(jié)點資源使用情況，并通過cAdvisor監(jiān)控容器和節(jié)點資源。
節(jié)點通過設(shè)置kubelet的啟動參數(shù)“—register-node”，來決定是否向API Server注冊自己。如果該參數(shù)為true，那么kubelet將試著通過API Server注冊自己。作為自注冊，kubelet啟動還包含下列參數(shù)：
--api-servers，告訴kubelet API Server的位置；
--kubeconfig，告訴kubelet在哪兒可以找到用于訪問API Server的證書；
--cloud-provider，告訴kubelet如何從云服務(wù)商（IAAS）那里讀取到和自己相關(guān)的元數(shù)據(jù)。
狀態(tài)上報
kubelet在啟動時通過API Server注冊節(jié)點，并定時向API Server發(fā)送節(jié)點新消息，API Server在接收到這些信息后，將這些信息寫入etcd。通過kubelet的啟動參數(shù)“—node-status-update-frequency”設(shè)置kubelet每隔多少時間向API Server報告節(jié)點狀態(tài)，默認為10秒。
Pod管理
kubelet通過以下幾種方式獲取自身node上所要運行的pod清單：
（1）文件：kubelet啟動參數(shù)“--config”指定的配置文件目錄下的文件。通過—file-check-frequency設(shè)置檢查該文件目錄的時間間隔，默認為20秒。
（2）HTTP端點（URL）：通過“—manifest-url”參數(shù)設(shè)置。通過—http-check-frequency設(shè)置檢查該HTTP端點的數(shù)據(jù)時間間隔，默認為20秒。
（3）API Server：kubelet通過API Server監(jiān)聽etcd目錄，同步pod清單。
所有以非API Server方式創(chuàng)建的pod都叫作static pod。Kubelet將static pod的狀態(tài)匯報給API Server，API Server為static pod創(chuàng)建一個mirror pod和其相匹配。Mirror pod的狀態(tài)將真實反映static pod的狀態(tài)。當static pod被刪除時，與之相對應(yīng)的mirror pod也會被刪除。Kubelet通過API Server client使用watch+list的方式監(jiān)聽“/registry/node/<當前node名稱>”和“/registry/pods”目錄，將獲取的信息同步到本地緩存中。
kubelet監(jiān)聽etcd，所有針對pod的操作將會被kubelet監(jiān)聽到。如果發(fā)現(xiàn)有新的綁定到本節(jié)點的pod，則按照pod清單的要求創(chuàng)建該pod。如果發(fā)現(xiàn)本地的pod被修改，則kubelet會做出相應(yīng)的修改，如刪除pod中的某個容器時，則通過docker client刪除該容器。如果發(fā)現(xiàn)刪除本節(jié)點的pod，則刪除相應(yīng)的pod，并通過docker client刪除pod中的容器。
kubelet讀取監(jiān)聽到的信息，如果是創(chuàng)建和修改pod任務(wù)，則做如下處理：
（1）為該pod創(chuàng)建一個數(shù)據(jù)目錄。
（2）從API Server讀取該pod清單。
（3）為該pod掛載外部卷（Extenal Volume）。
（4）下載pod用到的secret。
（5）檢查已經(jīng)運行在節(jié)點中的pod，如果該 pod沒有容器或pause容器沒有啟動，則先停止pod里所有容器進程。如果在pod中有需要刪除的容器，則刪除這些容器。
（6）用“kubernetes/pause”鏡像為每個pod創(chuàng)建一個容器，該pause容器用于接管pod中所有其他容器的網(wǎng)絡(luò)。
（7）為pod中的每個容器做如下處理：
為容器計算一個hash值，然后用容器的名字去docker查詢對應(yīng)容器的hash值。若查到容器，且兩者hash值不同，則停止docker中容器進程，并停止與之關(guān)聯(lián)的pause容器進程；若兩者相同不做任何處理
如果容器被中止了，且容器沒有指定的restartPolicy（重啟策略），則不做任何處理。
調(diào)用docker client下載容器鏡像，調(diào)用docker client運行容器。
容器健康檢查
pod通過兩類探針來檢查容器的健康狀態(tài)。一個是LivenessProbe探針，用于判斷容器是否健康，告訴kubelet一個容器什么時候處于不健康的狀態(tài)。如果LivenessProbe探針探測到容器不健康，則kubelet將刪除容器，并根據(jù)容器的重啟策略做相應(yīng)的處理。如果一個容器不包含LivenessProbe探針，那么kubelet認為該容器的LivenessProbe探針返回的值永遠是“success”.另一類是ReadinessProbe探針，用于判斷容器是否啟動完成，且準備接收請求。如果ReadinessProbe探針檢測到失敗，則pod的狀態(tài)將被修改。Endpoint controller將從service的endpoint中刪除包含該容器所在pod的IP地址的endpoint條目。
感謝你能夠認真閱讀完這篇文章，希望小編分享的“kubernetes容器編排系統(tǒng)的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持創(chuàng)新互聯(lián)，關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，更多相關(guān)知識等著你來學習!
網(wǎng)頁標題：kubernetes容器編排系統(tǒng)的示例分析
網(wǎng)頁地址：http://m.jiaotiyi.com/article/gdhhci.html