Kubernetes項(xiàng)目脫胎于Google內(nèi)部的大規(guī)模集群管理工具Borg
##2.1. K8s (Kubernetes)是什么？
本文轉(zhuǎn)自維基百科：https://zh.wikipedia.org/wiki/Kubernetes
Kubernetes（常簡(jiǎn)稱為K8s）是用于自動(dòng)部署梢莽、擴(kuò)展和管理容器化（containerized）應(yīng)用程序的開源系統(tǒng)嗓袱。該系統(tǒng)由Google設(shè)計(jì)并捐贈(zèng)給Cloud Native Computing Foundation（今屬Linux基金會(huì)）來使用。
它旨在提供“跨主機(jī)集群的自動(dòng)部署胸蛛、擴(kuò)展以及運(yùn)行應(yīng)用程序容器的平臺(tái)”污茵。 它支持一系列容器工具, 包括Docker等。CNCF于2017年宣布首批Kubernetes認(rèn)證服務(wù)提供商（KCSPs）葬项，包含IBM泞当、華為、MIRANTIS民珍、inwinSTACK迎椊笫浚科技等[5]服務(wù)商。
歷史
Google Container Engine簡(jiǎn)報(bào)
Kubernetes（在希臘語意為“舵手”或“駕駛員”）由Joe Beda嚷量、Brendan Burns和Craig McLuckie創(chuàng)立陋桂，并由其他谷歌工程師，包括Brian Grant和Tim Hockin等進(jìn)行加盟創(chuàng)作蝶溶，并由谷歌在2014年首次對(duì)外宣布 嗜历。 該系統(tǒng)的開發(fā)和設(shè)計(jì)都深受谷歌的Borg系統(tǒng)的影響，其許多頂級(jí)貢獻(xiàn)者之前也是Borg系統(tǒng)的開發(fā)者。在谷歌內(nèi)部梨州，Kubernetes的原始代號(hào)曾經(jīng)是Seven痕囱，即星際迷航中的Borg(博格人)。Kubernetes標(biāo)識(shí)中舵輪有七個(gè)輪輻就是對(duì)該項(xiàng)目代號(hào)的致意暴匠。
Kubernetes v1.0于2015年7月21日發(fā)布鞍恢。 隨著v1.0版本發(fā)布，谷歌與Linux 基金會(huì)合作組建了Cloud Native Computing Foundation (CNCF)[并將Kubernetes作為種子技術(shù)來提供巷查。
Rancher Labs在其Rancher容器管理平臺(tái)中包含了Kubernetes的發(fā)布版有序。Kubernetes也在很多其他公司的產(chǎn)品中被使用，例如Red HatOpenShift岛请， CoreOS的Tectonic旭寿， 以及IBM的IBM私有云產(chǎn)品，以及 VMware的PKS等等崇败。
設(shè)計(jì)
Kubernetes在設(shè)計(jì)結(jié)構(gòu)上定義了一系列的構(gòu)建模塊盅称，其目的是為了提供一個(gè)可以共同提供部署、維護(hù)和擴(kuò)展應(yīng)用程序的機(jī)制后室。組成Kubernetes的組件設(shè)計(jì)概念為松耦合和可擴(kuò)展的缩膝，這樣可以使之滿足多種不同的工作負(fù)載“杜可擴(kuò)展性在很大程度上由Kubernetes API提供疾层，此API主要被作為擴(kuò)展的內(nèi)部組件以及Kubernetes上運(yùn)行的容器來使用。
Pod
Kubernetes的基本調(diào)度單元稱為“pod”贡避。通過該種抽象類別可以把更高級(jí)別的抽象內(nèi)容增加到容器化組件痛黎。一個(gè)pod一般包含一個(gè)或多個(gè)容器，這樣可以保證它們一直位于主機(jī)上刮吧，并且可以共享資源湖饱。Kubernetes中的每個(gè)pod都被分配一個(gè)唯一的（在集群內(nèi)的）IP地址這樣就可以允許應(yīng)用程序使用同一端口，而避免了發(fā)生沖突的問題杀捻。 Pod可以定義一個(gè)卷井厌，例如本地磁盤目錄或網(wǎng)絡(luò)磁盤，并將其暴露在pod中的一個(gè)容器之中致讥。pod可以通過Kubernetes API手動(dòng)管理仅仆，也可以委托給控制器來實(shí)現(xiàn)自動(dòng)管理。
標(biāo)簽和選擇器
Kubernetes使客戶端（用戶或內(nèi)部組件）將稱為“標(biāo)簽”的鍵值對(duì)附加到系統(tǒng)中的任何API對(duì)象拄踪，如pod和節(jié)點(diǎn)蝇恶。相應(yīng)地，“標(biāo)簽選擇器”是針對(duì)匹配對(duì)象的標(biāo)簽的查詢方法惶桐。
標(biāo)簽和選擇器是Kubernetes中的主要分組機(jī)制撮弧，用于確定操作適用的組件潘懊。
例如，如果應(yīng)用程序的Pods具有系統(tǒng)的標(biāo)簽 tier (比如"front-end"贿衍、"back-end") 和一個(gè) release_track (比如"canary"授舟、"production")，那么對(duì)所有"back-end" 和 "canary" 節(jié)點(diǎn)的操作可以使用如下所示的標(biāo)簽選擇器：
tier=back-end AND release_track=canary
控制器
控制器是通過管理一組pod來實(shí)現(xiàn)來將實(shí)際集群狀態(tài)轉(zhuǎn)移到所需集群狀態(tài)的對(duì)帳循環(huán)機(jī)制贸辈。一種控制器指的是一組具有相同特征的“復(fù)制控制器”释树，控制器通過在集群中運(yùn)行指定數(shù)量的pod副本來處理復(fù)制和縮放。在基礎(chǔ)節(jié)點(diǎn)出現(xiàn)故障的情況下擎淤，它還可以用于處理創(chuàng)建替換pod奢啥。[22]其它控制器也是核心Kubernetes系統(tǒng)的一部分，包括“DaemonSet控制器”為每臺(tái)機(jī)器（或機(jī)器的一些子集）上運(yùn)行的單個(gè)pod嘴拢，和用于運(yùn)行pod的“作業(yè)控制器”桩盲。 控制器管理的pod組由作為控制器定義的部分的標(biāo)簽選擇器來確定。
服務(wù)
Kubernetes服務(wù)本質(zhì)是一組協(xié)同工作的pod席吴，類同多層架構(gòu)應(yīng)用中的一層赌结。構(gòu)成服務(wù)的pod組通過標(biāo)簽選擇器來定義。Kubernetes通過給服務(wù)分配靜態(tài)IP地址和域名來提供服務(wù)發(fā)現(xiàn)機(jī)制孝冒，并且以輪循調(diào)度的方式將流量負(fù)載均衡到能與選擇器匹配的pod的IP地址的網(wǎng)絡(luò)連接上（即使是故障導(dǎo)致pod從一臺(tái)機(jī)器移動(dòng)到另一臺(tái)機(jī)器）柬姚。 默認(rèn)情況下，服務(wù)任務(wù)會(huì)暴露在集群中（例如庄涡，多個(gè)后端pod可能被分組成一個(gè)服務(wù)量承，前端pod的請(qǐng)求在它們之間負(fù)載平衡）；除此以外穴店，服務(wù)任務(wù)也可以暴露在集群外部（例如宴合，從客戶端訪問前端pod）。
建構(gòu)
Kubernetes遵循主從式架構(gòu)設(shè)計(jì)迹鹅。Kubernetes的組件可以分為管理單個(gè)的 node 組件和控制平面部分的組件。
Kubernetes Master是集群的主要控制單元贞言，其用于管理其工作負(fù)載并指導(dǎo)整個(gè)系統(tǒng)的通信斜棚。Kubernetes控制平面由各自的進(jìn)程組成，每個(gè)組件都可以在單個(gè)主節(jié)點(diǎn)上運(yùn)行该窗，也可以在支持high-availability clusters的多個(gè)主節(jié)點(diǎn)上運(yùn)行弟蚀。是Kubernetes控制平面的各種組件如下：
etcd
etcd 是由CoreOS開發(fā)，用于可靠地存儲(chǔ)集群的配置數(shù)據(jù)的一種持久性酗失，輕量型的义钉，分布式的鍵-值數(shù)據(jù)存儲(chǔ)組件。該組件可表示在任何給定時(shí)間點(diǎn)處的集群的整體狀態(tài)规肴。其他組件在注意到存儲(chǔ)的變化之后捶闸，會(huì)變成相應(yīng)的狀態(tài)夜畴。
API服務(wù)器
API服務(wù)器是一個(gè)關(guān)鍵組件 并使用 Kubernetes API 和 JSON over HTTP來提供了Kubernetes的內(nèi)部和外部接口。 API服務(wù)器處理和驗(yàn)證 REST請(qǐng)求并更新 API 對(duì)象的狀態(tài)etcd删壮，從而允許客戶端在Worker節(jié)點(diǎn)之間配置工作負(fù)載和容器贪绘。
調(diào)度器
T調(diào)度程序是可插拔式組件，其基于資源可用性來選擇未調(diào)度的pod（由調(diào)度程序管理的基本實(shí)體）應(yīng)該運(yùn)行哪個(gè)節(jié)點(diǎn)央碟。調(diào)度程序跟蹤每個(gè)節(jié)點(diǎn)上的資源利用率税灌，以確保工作負(fù)載不會(huì)超過可用資源。為此亿虽，調(diào)度程序必須知道資源需求菱涤，資源可用性以及各種其他用戶提供的約束和策略指令，例如服務(wù)質(zhì)量洛勉，親和力/反關(guān)聯(lián)性要求粘秆，數(shù)據(jù)位置等。實(shí)質(zhì)上坯认，調(diào)度程序的作用是將資源“供應(yīng)”與工作負(fù)載“需求”相匹配以維持系統(tǒng)的穩(wěn)定和可靠翻擒。
控制器管理
控制器管理器是核心Kubernetes控制器，其包括DaemonSet控制器和復(fù)制控制器等牛哺。該控制器可與API服務(wù)器進(jìn)行通信以在需要時(shí)創(chuàng)建陋气，更新和刪除他們管理的資源（pod，服務(wù)端點(diǎn)等）
Kubernetes 節(jié)點(diǎn)
Node也稱為Worker或Minion引润，是部署容器（工作負(fù)載）的單機(jī)器（或虛擬機(jī)）巩趁。集群中的每個(gè)節(jié)點(diǎn)都必須具備容器的運(yùn)行環(huán)境（runtime） ——比如 Docker，以及下面提到的其他組件淳附，以便與這些容器的網(wǎng)絡(luò)配置進(jìn)行通信议慰。
Kubelet
Kubelet負(fù)責(zé)每個(gè)節(jié)點(diǎn)的運(yùn)行狀態(tài)（即確保節(jié)點(diǎn)上的所有容器都正常運(yùn)行）。它按照控制面板的指示來處理啟動(dòng)奴曙，停止和維護(hù)應(yīng)用程序容器（按組織到pod中）别凹。
Kubelet會(huì)監(jiān)視pod的狀態(tài)，如果不處于所需狀態(tài)洽糟，則pod將被重新部署到同一個(gè)節(jié)點(diǎn)炉菲。節(jié)點(diǎn)狀態(tài)每隔幾秒就會(huì)傳遞消息至中繼主機(jī)。主控器檢測(cè)到節(jié)點(diǎn)故障后坤溃，復(fù)制控制器將觀察此狀態(tài)更改拍霜，并在其他健康節(jié)點(diǎn)上啟動(dòng)pod。[來源請(qǐng)求]
容器
容器從屬于pod薪介。在運(yùn)行應(yīng)用祠饺、庫(kù)及其依賴的微服務(wù)中择葡，容器是最低層級(jí)的章办。通過綁定一個(gè)外部IP侈百，容器可以被外網(wǎng)訪問更扁。
Kube代理
Kube代理是網(wǎng)絡(luò)代理和負(fù)載均衡的實(shí)現(xiàn)，支持服務(wù)抽象以及其他網(wǎng)絡(luò)操作试疙。根據(jù)傳入請(qǐng)求的IP和端口诵棵，該組件會(huì)將流量轉(zhuǎn)發(fā)到指定的合適的容器中。
cAdvisor
cAdvisor 是監(jiān)視和收集例如每個(gè)節(jié)點(diǎn)上的容器的CPU祝旷，內(nèi)存履澳，文件和網(wǎng)絡(luò)使用情況等的資源使用情況和性能指標(biāo)的代理組件。
##2.2. K8s中的對(duì)象
1. k8s中的對(duì)象
K8s中常用的對(duì)象分類有以下幾種：
workload類怀跛，即工作負(fù)載類對(duì)象
pod
controller
deployment
stateful
daemonset
job
discovery & loadbalance類距贷，與網(wǎng)絡(luò)傳輸相關(guān)的對(duì)象
service
endpoint
ingress
config&storage，數(shù)據(jù)存儲(chǔ)吻谋、配置存儲(chǔ)類型的對(duì)象
configmap
secret
volume
persistentVolumeClaim
cluster忠蝗，集群類對(duì)象
Node
namespace
persitenceVolume
clusterRole
ClusterRoleVindeing
ResoruceQuota
工作負(fù)載，以pod為中心
pod是一個(gè)容器集合漓拾。
Pod是集群中可以創(chuàng)建和部署的最小且最簡(jiǎn)單的Kubernetes對(duì)象的單元阁最。
Pod也是一種封裝。它封裝了應(yīng)用容器骇两，存儲(chǔ)資源速种、獨(dú)立的網(wǎng)絡(luò)IP以及決定容器如何運(yùn)行的策略選項(xiàng)。
每個(gè)pod中預(yù)置了一個(gè)Pause容器低千，其namespace配阵、IPC資源、網(wǎng)絡(luò)和存儲(chǔ)資源被pod內(nèi)其它容器共享示血。Pod中的所有容器緊密協(xié)作棋傍，并且作為一個(gè)整體被管理、調(diào)度和運(yùn)行难审。
2. Pod
pod是一個(gè)非持久化實(shí)體瘫拣。
pod有以下幾個(gè)生命周期：
pending，即掛起告喊，即pod對(duì)象已經(jīng)被kubernetes所接受拂铡，等待創(chuàng)建。
running葱绒，運(yùn)行中，pod已經(jīng)綁定到node上斗锭，所有pod中所有容器已經(jīng)創(chuàng)建地淀。
succeed，成功狀態(tài)岖是，pod的所有的容器已經(jīng)成功終止帮毁。
failed实苞，失敗狀態(tài)，即有最少又一個(gè)容器正常退出烈疚。
3. service
pod是一個(gè)非持久化的實(shí)體隨時(shí)都有可能被銷毀掉或者重新創(chuàng)建黔牵，所以pod的所在節(jié)點(diǎn)是不確定的，而service就是用于將pod固定在某一個(gè)ip上爷肝，
servie是與云原生應(yīng)用中“微服務(wù)”概念一一對(duì)應(yīng)猾浦。
kubernetes集群為每一個(gè)service分配一個(gè)集群唯一的IP地址，在 service的生命周期內(nèi)灯抛，該ip地址不變金赦；在內(nèi)部DNS指出下，輕松實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)機(jī)制对嚼。
service通過label selector關(guān)聯(lián)到實(shí)際支撐業(yè)務(wù)運(yùn)行的pod上夹抗，并通過集群內(nèi)置的服務(wù)負(fù)載均衡分發(fā)到后端pod上。
通過nodeport或者設(shè)置loadbalance機(jī)制實(shí)現(xiàn)集群外部對(duì)service的訪問纵竖。
##2.3. Pod生命周期
本文轉(zhuǎn)自：https://juejin.im/post/5cc008745188250a9c356107
簡(jiǎn)述
Kubernetes 是一種用于在一組主機(jī)上運(yùn)行和協(xié)同容器化應(yīng)用程序的系統(tǒng)漠烧，提供應(yīng)用部署、規(guī)劃靡砌、更新維護(hù)的機(jī)制已脓。應(yīng)用運(yùn)行在 kubernetes 集群之上，實(shí)現(xiàn)服務(wù)的擴(kuò)容乏奥、縮容摆舟，執(zhí)行滾動(dòng)更新以及在不同版本的應(yīng)用程序之間調(diào)度流量以測(cè)試功能或回滾有問題的部署。Kubernetes 實(shí)現(xiàn)管理服務(wù)的各項(xiàng)功能是通過定義各種類型的資源來實(shí)現(xiàn)的邓了，如 deployment恨诱、pod、service骗炉、volume 等照宝。下面通過該文章來簡(jiǎn)述 pod 的基礎(chǔ)信息并詳述 pod 的生命周期。
Pod簡(jiǎn)介
Pod 是 kubernetes 系統(tǒng)的基礎(chǔ)單元句葵，是由用戶創(chuàng)建或部署的最小組件厕鹃，也是 kubernetes 系統(tǒng)上運(yùn)行容器化應(yīng)用的資源對(duì)象。Kubernetes 集群中其他資源對(duì)象都是為 pod 這個(gè)資源對(duì)象做支撐來實(shí)現(xiàn) kubernetes 管理應(yīng)用服務(wù)的目的乍丈。
Kubernetes 集群組件主要包括主節(jié)點(diǎn)組件API Server剂碴、Controller Manager、Scheduler 以及子節(jié)點(diǎn)組件 kubelet轻专、container Runtime（如docker）忆矛、kube-proxy 等。從與集群各組件交互角度講述 pod 的創(chuàng)建、運(yùn)行催训、銷毀等生命周期洽议，Pod 生命周期中的幾種不同狀態(tài)包括pending、running漫拭、succeeded亚兄、failed、Unknown采驻。
與API Server交互
API Server 提供了集群與外部交互的接口审胚，通過 kubectl 命令或者其他 API 客戶端提交 pod spec 給 API Server 作為pod創(chuàng)建的起始。
Pod 與 API Server 交互的主要流程如下：
API Server 在接收到創(chuàng)建pod的請(qǐng)求之后挑宠，會(huì)根據(jù)用戶提交的參數(shù)值來創(chuàng)建一個(gè)運(yùn)行時(shí)的pod對(duì)象菲盾。
根據(jù) API Server 請(qǐng)求的上下文的元數(shù)據(jù)來驗(yàn)證兩者的 namespace 是否匹配，如果不匹配則創(chuàng)建失敗各淀。
Namespace 匹配成功之后懒鉴，會(huì)向 pod 對(duì)象注入一些系統(tǒng)數(shù)據(jù)，如果 pod 未提供 pod 的名字碎浇，則 API Server 會(huì)將 pod 的 uid 作為 pod 的名字临谱。
API Server 接下來會(huì)檢查 pod 對(duì)象的必需字段是否為空，如果為空奴璃，創(chuàng)建失敗悉默。
上述準(zhǔn)備工作完成之后會(huì)將在 etcd 中持久化這個(gè)對(duì)象，將異步調(diào)用返回結(jié)果封裝成 restful.response苟穆，完成結(jié)果反饋抄课。
至此，API Server 創(chuàng)建過程完成雳旅，剩下的由 scheduler 和 kubelet 來完成跟磨，此時(shí) pod 處于 pending 狀態(tài)。
與scheduler交互
當(dāng)提交創(chuàng)建 pod 的請(qǐng)求與 API Server 的交互完成之后攒盈，接下來由 scheduler 進(jìn)行工作抵拘，該組件主要是完成 pod 的調(diào)度來決定 pod 具體運(yùn)行在集群的哪個(gè)節(jié)點(diǎn)上。注意型豁，此處聲明一點(diǎn)僵蛛，API Server 完成任務(wù)之后，將信息寫入到 etcd 中迎变，此時(shí) scheduler 通過 watch 機(jī)制監(jiān)聽到寫入到 etcd 的信息然后再進(jìn)行工作充尉。
Scheduler 讀取到寫入到 etcd 中的 pod 信息，然后基于一系列規(guī)則從集群中挑選一個(gè)合適的節(jié)點(diǎn)來運(yùn)行它衣形，調(diào)度時(shí)主要通過三步來確定 pod 運(yùn)行節(jié)點(diǎn)：
節(jié)點(diǎn)預(yù)選：基于一系列預(yù)選規(guī)則（如 PodFitsResource 和 MatchNode-Selector 等）對(duì)每個(gè)節(jié)點(diǎn)進(jìn)行檢查驼侠，將不符合的節(jié)點(diǎn)過濾掉從而完成節(jié)點(diǎn)預(yù)選。
節(jié)點(diǎn)優(yōu)選：對(duì)預(yù)選出的節(jié)點(diǎn)進(jìn)行優(yōu)先級(jí)排序，以便選出最適合運(yùn)行 pod 對(duì)象的節(jié)點(diǎn)泪电。
從優(yōu)先級(jí)結(jié)果中挑選出優(yōu)先級(jí)最高的節(jié)點(diǎn)來運(yùn)行 pod 對(duì)象，當(dāng)此類節(jié)點(diǎn)多個(gè)時(shí)則隨機(jī)選擇一個(gè)纪铺。
注：如果有特殊 pod 資源需要運(yùn)行在特殊節(jié)點(diǎn)上相速，此時(shí)可以通過組合節(jié)點(diǎn)標(biāo)簽以及 pod 標(biāo)簽和標(biāo)簽選擇器等來實(shí)現(xiàn)高級(jí)調(diào)度，如 MatchInterPodAffinity鲜锚、MatchNodeSelector 和 PodToleratesNodeTaints 等預(yù)選策略突诬，他們?yōu)橛脩籼峁┳远x Pod 親和性或反親和性、節(jié)點(diǎn)親和性以及基于污點(diǎn)及容忍度的調(diào)度機(jī)制芜繁。
預(yù)選策略
預(yù)選策略就是節(jié)點(diǎn)過濾器旺隙，例如 MathNodeSelector 實(shí)現(xiàn)的規(guī)則，以及 PodFitsResources 實(shí)現(xiàn)的規(guī)則等骏令。執(zhí)行預(yù)選操作時(shí)蔬捷，如果不存在適合的節(jié)點(diǎn)，此時(shí) pod 會(huì)一直處于 pending 狀態(tài)榔袋，直到至少有一個(gè)可用節(jié)點(diǎn)周拐。
支持的預(yù)選策略列舉一下（1.10版本）：
CheckNodeCondition
General
NoDiskConflict
PodToleratesNodeTaintsPodToleratesNodeNoExecuteTaints
CheckServiceAffinity
MaxEBsVolumeCount
MaxGCEPDVolumeCount
MaxAzureDiskVolumeCount
CheckVolumeBinding
NoVolumeZoneConflict
CheckNodeMemoryPressure
CheckNodePIDPressure
CheckNodeDiskPressure
MatchInterPodAffinity
簡(jiǎn)單介紹幾種：
CheckNodeCondition：檢查是否可以在節(jié)點(diǎn)報(bào)告磁盤、網(wǎng)絡(luò)不可用或未準(zhǔn)備好的情況下將 pod 對(duì)象調(diào)度其上凰兑。
NoDiskConflict：檢查 pod 對(duì)象請(qǐng)求的存儲(chǔ)卷在此節(jié)點(diǎn)上是否可用妥粟，若不存在沖突則通過檢查。
MathNodeSelector：若 pod 對(duì)象定義了 spec.NodeSelector 屬性吏够，則檢查節(jié)點(diǎn)標(biāo)簽是否能匹配此屬性值勾给。
優(yōu)選函數(shù)
常用優(yōu)選函數(shù)：
BalancedResourceAllocation
LeaastRequstedPriority
NodePreferAvoidPodsPriority
NodeAffinityPriority
TaintTolerationPriority
InterPodAffinityPriority
SelectorSpreadPriority
NodeLabelPriority
MostRequestedPriority
ImageLoccalityPriority
此外調(diào)度器支持為每個(gè)優(yōu)選函數(shù)指定一個(gè)簡(jiǎn)單的整數(shù)值表示權(quán)重，進(jìn)行節(jié)點(diǎn)優(yōu)先級(jí)分值的計(jì)算锅知，計(jì)算公式如下：
FinalScoreNode = (weight1 * priorityFunc1) + (weight2 * priorityFunc2)+ ....
列舉說明幾個(gè)優(yōu)選函數(shù)：
TaintToleraionPriority：基于Pod資源對(duì)節(jié)點(diǎn)的污點(diǎn)容忍調(diào)度偏好進(jìn)行其優(yōu)先級(jí)的評(píng)估播急，它將 Pod 對(duì)象的 tolerations 列表與節(jié)點(diǎn)的污點(diǎn)進(jìn)行匹配度檢查，成功匹配的條目越多喉镰，則節(jié)點(diǎn)得分越低旅择。
NodeAffinityPriority：基于節(jié)點(diǎn)親和性調(diào)度偏好進(jìn)行優(yōu)先級(jí)評(píng)估，它將根據(jù) Pod 資源中的 nodeSelector 對(duì)給定節(jié)點(diǎn)進(jìn)行匹配度計(jì)算侣姆，成功匹配到的條目越多則節(jié)點(diǎn)得分越高生真。
對(duì)于上述節(jié)點(diǎn)調(diào)度中還包括一些節(jié)點(diǎn)親和度：硬親和度和軟親和性、資源親和調(diào)度捺宗。硬親和調(diào)度和軟親和調(diào)度以及反親和調(diào)度柱蟀、污點(diǎn)容忍度等，都是 pod 調(diào)度的策略蚜厉，不一一詳述长已。
當(dāng) scheduler 通過一系列策略選定 pod 運(yùn)行節(jié)點(diǎn)之后將結(jié)果信息更新至 API Server，由 API Server 更新至 etcd 中，并由 API Server 反映調(diào)度結(jié)果术瓮，接下來由 kubelet 在所選定的節(jié)點(diǎn)上啟動(dòng) pod康聂。
Kubelet組件啟動(dòng)pod
kubelet 組件的作用不單單是創(chuàng)建 pod，另外還包括節(jié)點(diǎn)管理胞四、cAdvisor 資源監(jiān)控管理恬汁、容器健康檢查等功能。
啟動(dòng)pod流程分析
kubelet 通過 API Server 監(jiān)聽 etcd 目錄辜伟，同步 pod 列表氓侧。如果發(fā)現(xiàn)有新的 pod 綁定到本節(jié)點(diǎn)，則按照 pod 清單要求創(chuàng)建 pod导狡，如果是發(fā)現(xiàn) pod 被更新约巷，則做出相應(yīng)更改。
讀取到 pod 的信息之后旱捧，如果是創(chuàng)建和修改 pod 的任務(wù)独郎，則做如下處理：
為該 pod 創(chuàng)建一個(gè)數(shù)據(jù)目錄
從 API Server 讀取該 pod 清單
為該 pod 掛載外部卷
下載 pod 所需的 Secret
檢查已經(jīng)運(yùn)行在節(jié)點(diǎn)中 pod，如果該 pod 沒有容器或者 Pause 容器沒有啟動(dòng)廊佩，則先停止pod里所有的容器進(jìn)程囚聚。
使用 pause 鏡像為每個(gè)pod創(chuàng)建一個(gè)容器，該容器用于接管 Pod 中所有其他容器的網(wǎng)絡(luò)标锄。
為 pod 中的每個(gè)容器做如下處理：1.為容器計(jì)算一個(gè) hash 值顽铸，然后用容器的名字去查詢對(duì)于 docker 容器的 hash 值。若查找到容器料皇，且兩者的 hash 值不同谓松，則停止 docker 中容器中進(jìn)程，并停止與之關(guān)聯(lián)的 pause 容器践剂，若相同鬼譬，則不做處理。若容器被終止了逊脯，且容器沒有指定的重啟策略优质，則不做任何處理調(diào)用 docker client 下載容器鏡像，并啟動(dòng)容器军洼。
詳述pod聲明周期中的重要行為
除了創(chuàng)建應(yīng)用容器（主容器及輔助容器之外巩螃，注意，如果集群中部署了 istio匕争，則會(huì)在 pod 啟動(dòng)的時(shí)候注入一個(gè)新的和 istio 相關(guān)的容器避乏，那是另一個(gè)美好故事的開端），還可以為 pod 對(duì)象定義其聲明周期中的多種行為甘桑，如初始化容器拍皮、容器探測(cè)以及就緒性探測(cè)等歹叮。
容器生命周期的幾種行為
初始化容器
初始化容器即 pod 內(nèi)主容器啟動(dòng)之前要運(yùn)行的容器，主要是做一些前置工作铆帽，初始化容器具有以下特征：
初始化容器必須首先執(zhí)行咆耿，若初始化容器運(yùn)行失敗，集群會(huì)一直重啟初始化容器直至完成爹橱，注意票灰，如果 pod 的重啟策略為 Never，那初始化容器啟動(dòng)失敗后就不會(huì)重啟宅荤。
初始化容器必須按照定義的順序執(zhí)行，初始化容器可以通過 pod 的 spec.initContainers 進(jìn)行定義浸策。
聲明周期鉤子函數(shù)
Kubernetes 為容器提供了兩種生命周期鉤子：
Poststart:于容器創(chuàng)建完成之后立即運(yùn)行的鉤子程序冯键。
preStop:容器終止之前立即運(yùn)行的程序，是以同步方式的進(jìn)行庸汗，因此其完成之前會(huì)阻塞 刪除容器的調(diào)用
備注：鉤子程序的執(zhí)行方式有“Exec”和“HTTP”兩種惫确。
容器探測(cè)
容器探測(cè)分為存活性探測(cè)和就緒性探測(cè)容器探測(cè)是kubelet對(duì)容器健康狀態(tài)進(jìn)行診斷，容器探測(cè)的方式主要以下三種：
ExecAction：在容器中執(zhí)行命令蚯舱，根據(jù)返回的狀態(tài)碼判斷容器健康狀態(tài)改化，返回0即表示成功，否則為失敗枉昏。
TCPSocketAction: 通過與容器的某TCP端口嘗試建立連接進(jìn)行診斷陈肛，端口能打開即為表示成功，否則失敗兄裂。
HTTPGetAction：向容器指定 URL 發(fā)起 HTTP GET 請(qǐng)求句旱，響應(yīng)碼為2xx或者是3xx為成功，否則失敗晰奖。
Pod終止過程
終止過程主要分為如下幾個(gè)步驟：
用戶發(fā)出刪除 pod 命令
Pod 對(duì)象隨著時(shí)間的推移更新谈撒，在寬限期（默認(rèn)情況下30秒），pod 被視為“dead”狀態(tài)
將 pod 標(biāo)記為“Terminating”狀態(tài)
第三步同時(shí)運(yùn)行匾南，監(jiān)控到 pod 對(duì)象為“Terminating”狀態(tài)的同時(shí)啟動(dòng) pod 關(guān)閉過程
第三步同時(shí)進(jìn)行啃匿，endpoints 控制器監(jiān)控到 pod 對(duì)象關(guān)閉，將pod與service匹配的 endpoints 列表中刪除
如果 pod 中定義了 preStop 鉤子處理程序蛆楞，則 pod 被標(biāo)記為“Terminating”狀態(tài)時(shí)以同步的方式啟動(dòng)執(zhí)行溯乒；若寬限期結(jié)束后，preStop 仍未執(zhí)行結(jié)束臊岸，第二步會(huì)重新執(zhí)行并額外獲得一個(gè)2秒的小寬限期
Pod 內(nèi)對(duì)象的容器收到 TERM 信號(hào)
寬限期結(jié)束之后橙数，若存在任何一個(gè)運(yùn)行的進(jìn)程，pod 會(huì)收到 SIGKILL 信號(hào)
Kubelet 請(qǐng)求 API Server 將此 Pod 資源寬限期設(shè)置為0從而完成刪除操作
此外 kubelet 除了啟動(dòng)之外帅戒，kubelet 中還有 cAdvisor灯帮，用于收集容器 CPU崖技、內(nèi)存、文件系統(tǒng)和網(wǎng)絡(luò)使用情況等信息钟哥，與 prometheus 結(jié)合實(shí)現(xiàn)對(duì)集群內(nèi) pod 監(jiān)控迎献。
此外，除了上述三個(gè)組件在創(chuàng)建 pod 過程中的交互腻贰，還有 controller-manager 來保證 pod 處于用戶期望狀態(tài)（即保證 pod 永遠(yuǎn)處于存活狀態(tài)）等功能以及 proxy 用于集群內(nèi) pod 之間通信等吁恍。
##2.4. Helm是什么
本文轉(zhuǎn)自：https://juejin.im/entry/5b4f09035188251ac446ded1
Helm介紹
在Kubernetes中部署容器云的應(yīng)用也是一項(xiàng)有挑戰(zhàn)性的工作，Helm就是為了簡(jiǎn)化在Kubernetes中安裝部署容器云應(yīng)用的一個(gè)客戶端工具播演。通過helm能夠幫助開發(fā)者定義冀瓦、安裝和升級(jí)Kubernetes中的容器云應(yīng)用，同時(shí)写烤，也可以通過helm進(jìn)行容器云應(yīng)用的分享翼闽。在Kubeapps Hub中提供了包括Redis、MySQL和Jenkins等參見的應(yīng)用洲炊，通過helm可以使用一條命令就能夠?qū)⑵洳渴鸢惭b在自己的Kubernetes集群中感局。
helm的整體架構(gòu)如下圖所示，Helm架構(gòu)由Helm客戶端暂衡、Tiller服務(wù)器端和Chart倉(cāng)庫(kù)所組成询微；Tiller部署在Kubernetes中，Helm客戶端從Chart倉(cāng)庫(kù)中獲取Chart安裝包狂巢，并將其安裝部署到Kubernetes集群中撑毛。
Helm是管理Kubernetes包的工具，Helm能提供下面的能力：
創(chuàng)建新的charts
將charts打包成tgz文件
與chart倉(cāng)庫(kù)交互
安裝和卸載Kubernetes的應(yīng)用
管理使用Helm安裝的charts的生命周期
在Helm中唧领，有三個(gè)需要了解的重要概念：
chart：是創(chuàng)建Kubernetes應(yīng)用實(shí)例的信息集合代态；
config：創(chuàng)建發(fā)布對(duì)象的chart的配置信息
release：chart的運(yùn)行實(shí)例，包含特定的config
Helm組件
在Helm中有兩個(gè)主要的組件疹吃，既Helm客戶端和Tiller服務(wù)端：
Helm客戶端蹦疑，這是一個(gè)供終端用戶使用的命令行工具，客戶端負(fù)責(zé)以下的工作：
本地chart開發(fā)
管理倉(cāng)庫(kù)
與Tiller服務(wù)器交互
發(fā)送需要被安裝的charts
請(qǐng)求關(guān)于發(fā)布版本的信息
請(qǐng)求更新或者卸載已安裝的發(fā)布版本
Tiller服務(wù)端： Tiller服務(wù)部署在Kubernetes集群中萨驶，Helm客戶端通過與Tiller服務(wù)器進(jìn)行交互歉摧，并最終與Kubernetes API服務(wù)器進(jìn)行交互。 Tiller服務(wù)器負(fù)責(zé)如下的工作：
監(jiān)聽來自于Helm客戶端的請(qǐng)求
組合chart和配置來構(gòu)建一個(gè)發(fā)布
在Kubernetes中安裝腔呜，并跟蹤后續(xù)的發(fā)布
通過與Kubernetes交互叁温，更新或者chart
客戶端負(fù)責(zé)管理chart，服務(wù)端負(fù)責(zé)管理發(fā)布核畴。
Helm技術(shù)實(shí)現(xiàn)
Helm客戶端是使用Go語言編寫的膝但，它通過gRPC協(xié)議與Tiller服務(wù)器交互。
Tiller服務(wù)器也是使用Go語言編寫的谤草，它使用Kubernetes客戶端類庫(kù)與Kubernetes進(jìn)行通訊跟束。
Tiller服務(wù)器通過Kubernetes的ConfigMap存儲(chǔ)信息莺奸，因此本身沒有用于存儲(chǔ)數(shù)據(jù)庫(kù)。
##2.4. Helm的使用
1. helm下載安裝
下載地址為：
https://github.com/helm/helm/releases
helm分為服務(wù)端與客戶端冀宴，服務(wù)端為Tiller灭贷，客戶端為helm。
解壓后略贮，將helm添加到PATH量里甚疟，方便執(zhí)行。
服務(wù)端安裝的話逃延，需要有一個(gè)k8s集群览妖，同時(shí)本地能訪問該集群（即kubectl工具能正常使用）
安裝Tiller
helm init --stable-repo-url=https://burdenbear.github.io/kube-charts-mirror --tiller-namespace=kube-system --skip-refresh=true --service-account=tiller
由于防火墻的存在，helm自帶的倉(cāng)庫(kù)被墻揽祥，stable-repo-url是為了將默認(rèn)倉(cāng)庫(kù)替換為國(guó)內(nèi)可訪問的一個(gè)鏡像地址黄痪。
tiller-namespaces是指將tiller安裝于相應(yīng)的k8s namespace。
service-account指定相應(yīng)的k8s serviceAccount盔然，比較重要。
若對(duì)鏡像有要求是嗜，可以通過tiller-image指定鏡像愈案。
更多參數(shù)，請(qǐng)參考
helm init help
將以下內(nèi)容鹅搪，保存成一個(gè)文件站绪，比如helm-sa.yaml
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
? name: tiller
? namespace: kube-system
subjects:
? - kind: ServiceAccount
? ? name: tiller
? ? namespace: kube-system
roleRef:
? kind: ClusterRole
? name: cluster-admin
? apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: ServiceAccount
metadata:
? name: tiller
? namespace: kube-system
? labels:
? ? kubernetes.io/cluster-service: "true"
執(zhí)行：
kubectl apply -f helm-sa.yaml
服務(wù)端安裝完成，可以通過以下命令來驗(yàn)證：
kubectl get pod -n kube-system | grep tiller
安裝helm客戶端
helm init -c --stable-repo-url=https://burdenbear.github.io/kube-charts-mirror
通過以下命令驗(yàn)證：
helm version
若一切正常丽柿，可以看到服務(wù)端與本地客戶端的版本信息恢准。同時(shí)意味著，連接服務(wù)端已成功甫题。
2. 使用helm安裝一個(gè)nginx
helm install stable/nginx
該命令的意思是：安裝（install）stable倉(cāng)庫(kù)里的nginx
提示成功后馁筐，可以通過以下命令查看相應(yīng)的Release狀態(tài)
helm list
相關(guān)參數(shù)的使用幫助，都可以通過help命令來獲取坠非。
比如:
helm help
helm install help
helm repo help
helm package help
3. helm倉(cāng)庫(kù)
什么是chart包：chart包是helm描述相關(guān)應(yīng)用信息的一種格式文件敏沉，可以認(rèn)為是一個(gè)安裝程序，類似yum的rpm文件炎码。
什么是helm倉(cāng)庫(kù)：helm倉(cāng)庫(kù)其實(shí)為chart倉(cāng)庫(kù)盟迟。是存放chart包的地方。
前面安裝nignx的時(shí)候潦闲，我們用到helm自帶的chart倉(cāng)庫(kù)stable攒菠。
通過以下命令，可以查看當(dāng)前倉(cāng)庫(kù)列表：
helm repo list
由于大部分公開的chart倉(cāng)庫(kù)歉闰，并不支持上傳辖众，或者有嚴(yán)格的審核制度卓起，因此大部分情況，我們都需要自己創(chuàng)建一個(gè)私有的chart倉(cāng)庫(kù)赵辕。推薦使用ChartMuseum作為自己的私有倉(cāng)庫(kù)既绩。（也可以直接使用harbor1.6.0+）
這邊假設(shè)我們已經(jīng)安裝好，并且相應(yīng)的倉(cāng)庫(kù)地址為：http://my.repo.com/maybeStable
在helm客戶端這邊將此遠(yuǎn)程倉(cāng)庫(kù)添加到本地：
helm repo add myRepoName http://my.repo.com/maybeStable
并執(zhí)行來更新相應(yīng)的chart倉(cāng)庫(kù)索引：
helm repo update
之后还惠，便可以使用該倉(cāng)庫(kù)里的所有chart包了饲握。
官方維護(hù)的stable的chart項(xiàng)目：（可搜索相關(guān)項(xiàng)目）
https://github.com/helm/charts/tree/master/stable
圖形化界面：
官方倉(cāng)庫(kù)：
google提供的：（google自家用的，不保證對(duì)外可用蚕键，但是大部分是可用的）
stable倉(cāng)庫(kù)：
https://console.cloud.google.com/storage/browser/kubernetes-charts
incubator倉(cāng)庫(kù)：
https://console.cloud.google.com/storage/browser/kubernetes-charts-incubator
kubeapps提供：
非圖形化救欧，直接獲取index.yaml
https://charts.bitnami.com/bitnami/index.yaml
此文件為該倉(cāng)庫(kù)所有charts的索引文件，可以找到對(duì)應(yīng)的chart包下載地址锣光。
大部分倉(cāng)庫(kù)都可以通過獲取index.yaml來獲取該倉(cāng)庫(kù)的索引文件笆怠，進(jìn)而獲取相關(guān)的chart。
index.yaml的地址誊爹，一般為：倉(cāng)庫(kù)地址+/index.yaml
比如bitnami這邊的倉(cāng)庫(kù)地址為：https://charts.bitnami.com/bitnami蹬刷，對(duì)應(yīng)的index.yaml地址即為https://charts.bitnami.com/bitnami/index.yaml
4. 創(chuàng)建自己的chart包
使用命令：
helm create myChart
即可創(chuàng)建一個(gè)默認(rèn)模板的chart包，在此模板基礎(chǔ)上進(jìn)行自己的chart內(nèi)容配置即可频丘。
5. 打包一個(gè)chart包
在chart包的上級(jí)目錄办成，（即當(dāng)前目錄可看到myChart文件夾），執(zhí)行以下命令：
helm package myChart
根據(jù)chart包里面的配置文件（Chart.yaml）生成對(duì)應(yīng)版本搂漠，對(duì)應(yīng)名稱的tgz包（即chart包）
6. 上傳chart包到遠(yuǎn)程倉(cāng)庫(kù)
若使用網(wǎng)宿的容器服務(wù)迂卢，可以直接通過容器服務(wù)的"本地倉(cāng)庫(kù)"里面的上傳功能。
若使用harbor桐汤，可直接在harbor的界面上進(jìn)行操作而克。
若使用ChartMuseum，可以使用以下push插件怔毛。
https://github.com/chartmuseum/helm-push
將本地chart员萍，push到對(duì)應(yīng)的倉(cāng)庫(kù)，這邊用push一個(gè)目錄(myChart)的方式來舉例：
helm push myChart/ myRepoName
該命令的意思是拣度，將myChart這個(gè)目錄充活，打包成對(duì)應(yīng)的chart包，并且上傳到myRepoName這個(gè)遠(yuǎn)程倉(cāng)庫(kù)里蜡娶。myRepoName是前面添加的倉(cāng)庫(kù)混卵。
