Kubernetes 前言

??Kubernetes，又稱為 k8s（首字母為 k、首字母與尾字母之間有 8 個字符避乏、尾字母為 s互亮，所以簡稱 k8s）或者簡稱為 “kube” 汉操，是一種可自動實施 Linux 容器操作的開源平臺。它可以幫助用戶省去應(yīng)用容器化過程的許多手動部署和擴展操作鹰霍。

1.1 為什么需要 kubernetes

??真正的生產(chǎn)型應(yīng)用會涉及多個容器闻鉴。這些容器必須跨多個服務(wù)器主機進(jìn)行部署。Kubernetes 可以提供所需的編排和管理功能茂洒，以便您針對這些工作負(fù)載大規(guī)模部署容器孟岛。借助 Kubernetes 編排功能，您可以構(gòu)建跨多個容器的應(yīng)用服務(wù)、跨集群調(diào)度渠羞、擴展這些容器斤贰，并長期持續(xù)管理這些容器的健康狀況。
Kubernetes 通過將容器分類組成 “容器集” （pod）次询，解決了容器增殖帶來的許多常見問題容器集為分組容器增加了一個抽象層荧恍，可幫助我們調(diào)用工作負(fù)載，并為這些容器提供所需的聯(lián)網(wǎng)和存儲等服務(wù)屯吊。Kubernetes 的其它部分可幫助我們在這些容器集之間達(dá)成負(fù)載平衡送巡，同時確保運行正確數(shù)量的容器，充分支持我們的工作負(fù)載盒卸。
??如果能正確實施 Kubernetes骗爆，再輔以其它開源項目（例如 Atomic 注冊表、Open vSwitch蔽介、heapster摘投、OAuth 以及 SELinux），我們就能夠輕松編排容器基礎(chǔ)架構(gòu)的各個部分虹蓄。

1.2 kubernetes 有哪些用途

• 跨多臺主機進(jìn)行容器編排犀呼。
• 更加充分地利用硬件，最大程度獲取運行企業(yè)應(yīng)用所需的資源薇组。
• 有效管控應(yīng)用部署和更新圆凰，并實現(xiàn)自動化操作。
• 掛載和增加存儲体箕，用于運行有狀態(tài)的應(yīng)用专钉。
• 快速、按需擴展容器化應(yīng)用及其資源累铅。
• 對服務(wù)進(jìn)行聲明式管理跃须，保證所部署的應(yīng)用始終按照部署的方式運行。
• 利用自動布局娃兽、自動重啟菇民、自動復(fù)制以及自動擴展功能，對應(yīng)用實施狀況檢查和自我修復(fù)投储。

1.3 kubernetes核心概念

??Kubernetes 有各類資源對象來描述整個集群的運行狀態(tài)（Node第练、Pod、Replication Controller玛荞、Service等都可以看作一種“資源對象”）娇掏。這些對象都需要通過調(diào)用 kubernetes api 來進(jìn)行創(chuàng)建、修改勋眯、刪除并將其保存在etcd中持久化存儲婴梧，可以通過 kubectl 命令工具下梢，也可以直接調(diào)用 k8s api，或者使用對象語言的客戶端庫（例如：golang 塞蹭， python ）孽江。
??從這個角度來看，Kubernetes其實是一個高度自動化的資源控制系統(tǒng)番电，它通過跟蹤對比etcd庫里保存的“資源期望狀態(tài)”與當(dāng)前環(huán)境中的“實際資源狀態(tài)”的差異來實現(xiàn)自動控制和自動糾錯的高級功能岗屏。
??每個 kubernetes 對象都會包含兩個關(guān)鍵字段：Object Spec 和 Object Status。spec 描述了對象所期望達(dá)到的狀態(tài)漱办，status 描述了該對象的實際狀態(tài)这刷。

k8s核心概念.png

1.3.1 Master

??Kubernetes里的Master指的是集群控制節(jié)點，每個Kubernetes集群里需要有一個Master節(jié)點來負(fù)責(zé)整個集群的管理和控制洼冻，基本上Kubernetes的所有控制命令都發(fā)給它崭歧，它來負(fù)責(zé)具體的執(zhí)行過程隅很，我們后面執(zhí)行的所有命令基本都是在Master節(jié)點上運行的撞牢。Master節(jié)點通常會占據(jù)一個獨立的服務(wù)器（高可用部署建議用3臺服務(wù)器），其主要原因是它太重要了叔营，是整個集群的“首腦”屋彪，如果宕機或者不可用，那么對集群內(nèi)容器應(yīng)用的管理都將失效绒尊。

??Master節(jié)點上運行著以下一組關(guān)鍵進(jìn)程：

• Kubernetes API Server (kube-apiserver)：提供了HTTP Rest接口的關(guān)鍵服務(wù)進(jìn)程畜挥，是Kubernetes里所有資源的增、刪婴谱、改蟹但、查等操作的唯一入口，也是集群控制的入口進(jìn)程谭羔。
• Kubernetes Controller Manager (kube-controller-manager)：Kubernetes里所有資源對象的自動化控制中心华糖，可以理解為資源對象的“大總管”。
• Kubernetes Scheduler (kube-scheduler)：負(fù)責(zé)資源調(diào)度（Pod調(diào)度）的進(jìn)程瘟裸，相當(dāng)于公交公司的“調(diào)度室”客叉。
  ?另外，在Master節(jié)點上還需要啟動一個etcd服務(wù)话告，因為Kubernetes里的所有資源對象的數(shù)據(jù)全部是保存在etcd中的兼搏。

1.3.2 Node

??除了Master，Kubernetes集群中的其他機器被稱為Node節(jié)點沙郭，在較早的版本中也被稱為Minion佛呻。與Master一樣，Node節(jié)點可以是一臺物理主機病线，也可以是一臺虛擬機件相。Node節(jié)點才是Kubernetes集群中的工作負(fù)載節(jié)點再扭，每個Node都會被Master分配一些工作負(fù)載（Docker容器），當(dāng)某個Node宕機時夜矗，其上的工作負(fù)載會被Master自動轉(zhuǎn)移到其他節(jié)點上去泛范。

??每個Node節(jié)點上都運行著以下一組關(guān)鍵進(jìn)程：

• kubelet：負(fù)責(zé)Pod對應(yīng)的容器的創(chuàng)建、啟停等任務(wù)紊撕，同時與Master節(jié)點密切協(xié)作罢荡，實現(xiàn)集群管理的基本功能。
• kube-proxy：實現(xiàn)Kubernetes Service的通信與負(fù)載均衡機制的重要組件对扶。
• Docker Engine （docker）：Docker引擎区赵，負(fù)責(zé)本機的容器創(chuàng)建和管理工作。
  ??Node節(jié)點可以在運行期間動態(tài)增加到Kubernetes集群中浪南，前提是這個節(jié)點上已經(jīng)正確安裝笼才、配置和啟動了上述關(guān)鍵進(jìn)程，在默認(rèn)情況下kubelet會向Master注冊自己络凿，這也是Kubernetes推薦的Node管理方式骡送。一旦Node被納入集群管理范圍，kubelet進(jìn)程就會定時向Master節(jié)點匯報自身的情報絮记，例如操作系統(tǒng)摔踱、Docker版本、機器的CPU和內(nèi)存情況怨愤，以及當(dāng)前有哪些Pod在運行等派敷，這樣Master可以獲知每個Node的資源使用情況，并實現(xiàn)高效均衡等資源調(diào)度策略撰洗。而某個Node超過指定時間不上報信息時篮愉，會被Master判斷為“失聯(lián)”，Node的狀態(tài)被標(biāo)記為不可用（Not Ready）差导，隨后Master會觸發(fā)“工作負(fù)載大轉(zhuǎn)移”的自動流程试躏。

1.3.3 pod

??Pod是Kubernetes的最重要也最基本的概念，如下圖所示是Pod的組成示意圖柿汛，我們看到每個Pod都有一個特殊的被成為“根容器”的Pause容器冗酿。Pause容器對應(yīng)的鏡像屬于Kubernetes平臺的一部分，除了Pause容器络断，每個Pod還包含一個或多個緊密相關(guān)的用戶業(yè)務(wù)容器裁替。

Pod的組成

??為什么Kubernetes會設(shè)計出一個全新的Pod概念并且Pod有這樣特殊的組成結(jié)構(gòu)？
??原因之一：在一組容器作為一個單元的情況下貌笨，我們難以對“整體”簡單地進(jìn)行判斷及有效地進(jìn)行行動弱判。比如，一個容器死亡了锥惋，此時算是整體死亡么昌腰？引入業(yè)務(wù)無關(guān)并且不易死亡的Pause容器作為Pod的根容器开伏，以它的狀態(tài)代表整體容器組的狀態(tài)，就簡單遭商、巧妙地解決了這個難題固灵。
??原因之二：Pod里的多個業(yè)務(wù)容器共享Pause容器的IP，共享Pause容器掛接的Volume劫流，這樣既簡化了密切關(guān)聯(lián)的業(yè)務(wù)容器之間的通信問題巫玻，也很好地解決了它們之間的文件共享問題。
??Kubernetes為每個Pod都分配了唯一的IP地址祠汇，稱之為Pod IP仍秤，一個Pod里的多個容器共享Pod IP地址。Kubernetes要求底層網(wǎng)絡(luò)支持集群內(nèi)任意兩個Pod之間的TCP/IP直接通信可很，這通常采用虛擬而層網(wǎng)絡(luò)技術(shù)來實現(xiàn)诗力，例如Flannel、Open vSwitch等我抠，因此我們需要牢記一點：在Kubernetes里苇本，一個Pod里的容器與另外主機上的Pod容器能夠直接通信。

??Pod其實有兩種類型：普通的Pod及靜態(tài)Pod（Static Pod）屿良，后者比較特殊圈澈，它并不存放在Kubernetes的etcd存儲里惫周，而是存放在某個具體的Node上的一個具體文件中尘惧，并且只在此Node上啟動運行。而普通的Pod一旦被創(chuàng)建递递，就會被放入到etcd中存儲喷橙，隨后會被Kubernetes Master調(diào)度到某個具體的Node上并進(jìn)行綁定（Binding），隨后該Pod被對應(yīng)的Node上的kubelet進(jìn)程實例化成一組相關(guān)的Docker容器并且啟動起來登舞。在默認(rèn)情況下贰逾，當(dāng)Pod里的某個容器停止時，Kubernetes會自動檢測到這個問題并且重新啟動這個Pod（重啟Pod里的所有容器）菠秒，如果Pod所在的Node宕機疙剑，則會將這個Node上的所有Pod重新調(diào)度到其他節(jié)點上。Pod践叠、容器與Node的關(guān)系圖如下圖所示言缤。

Pod、容器與Node的關(guān)系

1.3.4 Label（標(biāo)簽）

??Label是Kubernetes系統(tǒng)中另外一個核心概念禁灼。一個Label是一個key=value的鍵值對管挟，其中key與vaue由用戶自己指定。Label可以附加到各種資源對象上弄捕，例如Node僻孝、Pod导帝、Service、RC等穿铆，一個資源對象可以定義任意數(shù)量的Label您单，同一個Label也可以被添加到任意數(shù)量的資源對象上去，Label通常在資源對象定義時確定荞雏，也可以在對象創(chuàng)建后動態(tài)添加或者刪除睹限。
??我們可以通過指定的資源對象捆綁一個或多個不同的Label來實現(xiàn)多維度的資源分組管理功能，以便于靈活讯檐、方便地進(jìn)行資源分配羡疗、調(diào)度、配置别洪、部署等管理工作叨恨。例如：部署不同版本的應(yīng)用到不同的環(huán)境中；或者監(jiān)控和分析應(yīng)用（日志記錄挖垛、監(jiān)控痒钝、告警）等。一些常用等label示例如下痢毒。
版本標(biāo)簽："release" : "stable" , "release" : "canary"...
環(huán)境標(biāo)簽："environment" : "dev" , "environment" : "production"
架構(gòu)標(biāo)簽："tier" : "frontend" , "tier" : "backend" , "tier" : "middleware"
分區(qū)標(biāo)簽："partition" : "customerA" , "partition" : "customerB"...
質(zhì)量管控標(biāo)簽："track" : "daily" , "track" : "weekly"
??Label相當(dāng)于我們熟悉的“標(biāo)簽”送矩，給某個資源對象定義一個Label，就相當(dāng)于給它打了一個標(biāo)簽哪替，隨后可以通過Label Selector（標(biāo)簽選擇器）查詢和篩選擁有某些Label的資源對象栋荸，Kubernetes通過這種方式實現(xiàn)了類似SQL的簡單又通用的對象查詢機制。

1.3.5 Replication Controller

??RC是Kubernetes系統(tǒng)中的核心概念之一凭舶，簡單來說晌块，它其實是定義了一個期望的場景，即聲明某種Pod的副本數(shù)量在任意時刻都符合某個預(yù)期值帅霜，所以RC的定義包括如下幾個部分匆背。

• Pod期待的副本數(shù)（replicas）。
• 用于篩選目標(biāo)Pod的Label Selector身冀。
• 當(dāng)Pod的副本數(shù)量小于預(yù)期數(shù)量時钝尸，用于創(chuàng)建新Pod的Pod模版（template）。

1.3.6 Deployment

??Deployment是Kubernetes v1.2引入的概念搂根，引入的目的是為了更好地解決Pod的編排問題珍促。為此，Deployment在內(nèi)部使用了Replica Set來實現(xiàn)目的兄墅，無論從Deployment的作用與目的踢星，它的YAML定義，還是從它的具體命令行操作來看隙咸，我們都可以把它看作RC的一次升級沐悦，兩者相似度超過90%成洗。
??Deployment相對于RC的一個最大升級是我們隨時知道當(dāng)前Pod“部署”的進(jìn)度。實際上由于一個Pod的創(chuàng)建藏否、調(diào)度瓶殃、綁定節(jié)點及在目標(biāo)Node上啟動對應(yīng)的容器這一完整過程需要一定的時間，所以我們期待系統(tǒng)啟動N個Pod副本的目標(biāo)狀態(tài)副签，實際上是一個連續(xù)變化的“部署過程”導(dǎo)致的最終狀態(tài)遥椿。
??Deployment的典型使用場景有以下幾個。

• 創(chuàng)建一個Deployment對象來生成對應(yīng)的Replica Set并完成Pod副本的創(chuàng)建過程淆储。
• 檢查Deployment的狀態(tài)來看部署動作是否完成（Pod副本的數(shù)量是否達(dá)到預(yù)期的值）冠场。
• 更新Deployment以創(chuàng)建新的Pod（比如鏡像升級）。
• 如果當(dāng)前Deployment不穩(wěn)定本砰，則回滾到一個早先的Deployment版本碴裙。
• 暫停Deployment以便于一次性修改多個PodTemplateSpec的配置項，之后再恢復(fù)Deployment点额，進(jìn)行新的發(fā)布舔株。
• 擴展Deployment以應(yīng)對高負(fù)載。
• 查看Deployment的狀態(tài)还棱，以此作為發(fā)布是否成功的指標(biāo)载慈。
• 清理不再需要的舊版本ReplicaSets。

1.3.7 StatefulSet

??在Kubernetes系統(tǒng)中珍手，Pod的管理對象RC办铡、Deployment、DaemonSet和Job都是面向無狀態(tài)的服務(wù)珠十。但現(xiàn)實中有很多服務(wù)是有狀態(tài)的料扰，特別是一些復(fù)雜的中間件集群凭豪，例如MySQL集群焙蹭、MongoDB集群、Kafka集群嫂伞、Zookeeper集群等孔厉，這些應(yīng)用集群有以下一些共同點。

??每個節(jié)點都有固定的身份ID帖努，通過這個ID撰豺，集群中的成員可以相互發(fā)現(xiàn)并且通信。
??集群的規(guī)模是比較固定的拼余，集群規(guī)模不能隨意變動污桦。
??集群里的每個節(jié)點都是有狀態(tài)的，通常會持久化數(shù)據(jù)到永久存儲中匙监。
??如果磁盤損壞凡橱，則集群里的某個節(jié)點無法正常運行小作，集群功能受損。

??如果用RC/Deployment控制Pod副本數(shù)的方式來實現(xiàn)上述有狀態(tài)的集群稼钩，則我們會發(fā)現(xiàn)第一點是無法滿足的顾稀，因為Pod的名字是隨機產(chǎn)生的，Pod的IP地址也是在運行期才確定且可能有變動的坝撑，我們事先無法為每個Pod確定唯一不變的ID静秆，為了能夠在其他節(jié)點上恢復(fù)某個失敗的節(jié)點，這種集群中的Pod需要掛接某種共享存儲巡李，為了解決這個問題抚笔，Kubernetes從v1.4版本開始引入了PetSet這個新的資源對象，并且在v1.5版本時更名為StatefulSet侨拦，StatefulSet從本質(zhì)上來說塔沃，可以看作Deployment/RC的一個特殊變種，它有如下一些特性阳谍。

??StatefulSet里的每個Pod都有穩(wěn)定蛀柴、唯一的網(wǎng)絡(luò)標(biāo)識，可以用來發(fā)現(xiàn)集群內(nèi)的其他成員矫夯。假設(shè)StatefulSet的名字叫kafka鸽疾，那么第一個Pod叫kafak-0，第二個Pod叫kafak-1训貌，以此類推制肮。
??StatefulSet控制的Pod副本的啟停順序是受控的，操作第n個Pod時递沪，前n-1個Pod已經(jīng)時運行且準(zhǔn)備好的狀態(tài)豺鼻。
??StatefulSet里的Pod采用穩(wěn)定的持久化存儲卷，通過PV/PVC來實現(xiàn)款慨，刪除Pod時默認(rèn)不會刪除與StatefulSet相關(guān)的存儲卷（為了保證數(shù)據(jù)的安全）儒飒。

??StatefulSet除了要與PV卷捆綁使用以存儲Pod的狀態(tài)數(shù)據(jù)，還要與Headless Service配合使用檩奠，即在每個StatefulSet的定義中要聲明它屬于哪個Headless Service桩了。Headless Service與普通Service的關(guān)鍵區(qū)別在于，它沒有Cluster IP埠戳，如果解析Headless Service的DNS域名井誉，則返回的是該Service對應(yīng)的全部Pod的Endpoint列表。StatefulSet在Headless Service的基礎(chǔ)上又為StatefulSet控制的每個Pod實例創(chuàng)建了一個DNS域名整胃，這個域名的格式為：$(podname).$(headless service name)

??比如一個3節(jié)點的Kafka的StatefulSet集群颗圣，對應(yīng)的Headless Service的名字為kafka，StatefulSet的名字為kafka，則StatefulSet里面的3個Pod的DNS名稱分別為kafka-0.kafka在岂、kafka-1.kafka荚藻、kafka-3.kafka，這些DNS名稱可以直接在集群的配置文件中固定下來洁段。

1.3.8 Service(服務(wù))

??Service也是Kubernetes里的最核心的資源對象之一应狱，Kubernetes里的每個Service其實就是我們經(jīng)常提起的微服務(wù)架構(gòu)中的一個“微服務(wù)”，之前我們所說的Pod祠丝、RC等資源對象其實都是為這節(jié)所說的“服務(wù)”------Kubernetes Service作“嫁衣”的疾呻。下圖顯示了Pod、RC與Service的邏輯關(guān)系写半。

Pod岸蜗、RC與Service的關(guān)系

??從圖中我們看到，Kubernetes的Service定義了一個服務(wù)的訪問入口地址叠蝇，前端的應(yīng)用（Pod）通過這個入口地址訪問其背后的一組由Pod副本組成的集群實例璃岳，Service與其后端Pod副本集群之間則是通過Label Selector來實現(xiàn)“無縫對接”的。而RC的作用實際上是保證Service的服務(wù)能力和服務(wù)質(zhì)量始終處于預(yù)期的標(biāo)準(zhǔn)悔捶。

1.3.9 Volume(存儲卷)

??Volume是Pod中能夠被多個容器訪問的共享目錄铃慷。Kubernetes的Volume概念、用途和目的與Docker的Volume比較類似蜕该，但兩者不能等價犁柜。首先，Kubernetes中的Volume定義在Pod上堂淡，然后被一個Pod里的多個容器掛載到具體的文件目錄下馋缅；其次，Kubernetes中的Volume中的數(shù)據(jù)也不會丟失绢淀。最后萤悴，Kubernetes支持多種類型的Volume，例如Gluster皆的、Ceph等先進(jìn)的分布式文件系統(tǒng)覆履。

1.3.10 Namespace

??Namespace（命名空間）是Kubernetes系統(tǒng)中的另一個非常重要的概念，Namespace在很多情況下用于實現(xiàn)多租戶的資源隔離祭务。Nameaspace通過將集群內(nèi)部的資源對象“分配”到不同的Namespce中内狗，形成邏輯上分組的不同項目、小組或用戶組义锥，便于不同的分組在共享使用整個集群的資源的同時還能被分別管理。

1.3.11 Annotation（注解）

??Annotation與Label類似岩灭，也使用key/value鍵值對的形式進(jìn)行定義拌倍。不同的是Label具有嚴(yán)格的命名規(guī)則，它定義的是Kubernetes對象的元數(shù)據(jù)（Metadata），并且用于Label Selector柱恤。而Annotation則是用戶任意定義的“附加”信息数初，以便于外部工具進(jìn)行查找，很多時候梗顺，Kubernetes的模塊自身會通過Annotation的方式標(biāo)記資源對象的特殊信息泡孩。
??通常來說，用Annotation來記錄的信息如下寺谤。

• build信息仑鸥、release信息、Docker鏡像信息等变屁，例如時間戳眼俊、release id號、PR號粟关、鏡像hash值疮胖、docker registry地址等。
• 日志庫闷板、監(jiān)控庫澎灸、分析庫等資源庫的地址信息。
• 程序調(diào)試工具信息遮晚，例如工具击孩、版本號等。
• 團(tuán)隊等聯(lián)系信息鹏漆，例如電話號碼巩梢、負(fù)責(zé)人名稱、網(wǎng)址等艺玲。

1.3.12 其他

• Kubelet
  運行在節(jié)點上的服務(wù)括蝠，可讀取容器清單（container manifest），確保指定的容器啟動并運行饭聚。
• kubectl
  Kubernetes 的命令行配置工具忌警。
  ??上述組件是Kubernetes系統(tǒng)的核心組件，它們共同構(gòu)成了Kubernetes系統(tǒng)的框架和計算模型秒梳。通過對它們進(jìn)行靈活組合法绵，用戶就可以快速、方便地對容器集群進(jìn)行配置酪碘、創(chuàng)建和管理朋譬。除了本章所介紹的核心組件，在Kubernetes系統(tǒng)中還有許多輔助配置的資源對象兴垦，例如LimitRange徙赢、Resurce字柠。另外，一些系統(tǒng)內(nèi)部使用的對象Binding狡赐、Event等請參考Kubernetes的API文檔窑业。

1.4 kubernetes 術(shù)語

官方把 kubernetes 術(shù)語分為 12 個分類：
系統(tǒng)結(jié)構(gòu)、社區(qū)枕屉、核心對象常柄、擴展、基礎(chǔ)搀擂、網(wǎng)絡(luò)西潘、操作、安全哥倔、存儲秸架、工具、用戶類型咆蒿、工作負(fù)載
想要了解更多 kubernetes 術(shù)語东抹，請參照官方術(shù)語表。

地址：<u>https://kubernetes.io/docs/reference/glossary/?fundamental=true</u>

Pods

在Kubernetes中沃测，最小的管理元素不是一個個獨立的容器缭黔，而是Pod,Pod是最小的，管理蒂破，創(chuàng)建馏谨，計劃的最小單元。

Labels

標(biāo)簽其實就一對 key/value 附迷，被關(guān)聯(lián)到對象上惧互，比如Pod；標(biāo)簽的使用我們傾向于能夠標(biāo)示對象的特殊特點喇伯，并且對用戶而言是有意義的（就是一眼就看出了這個Pod是數(shù)據(jù)庫）喊儡，但是標(biāo)簽對內(nèi)核系統(tǒng)是沒有直接意義的。標(biāo)簽可以用來劃分特定組的對象（比如稻据，所有女的）艾猜，標(biāo)簽可以在創(chuàng)建一個對象的時候直接給與，也可以在后期隨時修改捻悯，每一個對象可以擁有多個標(biāo)簽匆赃，但是，key值必須是唯一的
"labels": {
"key1" : "value1",
"key2" : "value2"
}

Namespace

Namespace 是對一組資源和對象的抽象集合今缚，比如可以用來將系統(tǒng)內(nèi)部的對象劃分為不同的項目組或用戶組算柳。常見的pods, services, replication controllers和deployments等都是屬于某一個namespace的（默認(rèn)是default），而node, persistentVolumes等則不屬于任何namespace荚斯。

Namespace常用來隔離不同的用戶埠居，比如Kubernetes自帶的服務(wù)一般運行在kube-system namespace中查牌。

Replication Controller

Replication Controller 保證了在所有時間內(nèi)事期，都有特定數(shù)量的Pod副本正在運行滥壕，如果太多了，Replication Controller就殺死幾個兽泣，如果太少了绎橘，Replication Controller會新建幾個，和直接創(chuàng)建的pod不同的是唠倦，Replication Controller會替換掉那些刪除的或者被終止的pod称鳞，不管刪除的原因是什么（維護(hù)阿，更新啊稠鼻，Replication Controller都不關(guān)心）冈止。基于這個理由候齿，我們建議即使是只創(chuàng)建一個pod熙暴，我們也要使用Replication Controller。Replication Controller 就像一個進(jìn)程管理器慌盯，監(jiān)管著不同node上的多個pod,而不是單單監(jiān)控一個node上的pod周霉，Replication Controller 會委派本地容器來啟動一些節(jié)點上服務(wù)（Kubelet ,Docker）。

Node

Node是Pod真正運行的主機亚皂，可以物理機俱箱，也可以是虛擬機。為了管理Pod灭必，每個Node節(jié)點上至少要運行container runtime（比如docker或者rkt）狞谱、kubelet和kube-proxy服務(wù)。

image.png

ReplicaSets

ReplicaSet是下一代復(fù)本控制器禁漓。ReplicaSet和 Replication Controller之間的唯一區(qū)別是現(xiàn)在的選擇器支持跟衅。Replication Controller只支持基于等式的selector（env=dev或environment!=qa），但ReplicaSet還支持新的璃饱，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）与斤。在試用時官方推薦ReplicaSet。

Services

Kubernetes Pod是平凡的荚恶，它門會被創(chuàng)建撩穿，也會死掉（生老病死），并且他們是不可復(fù)活的谒撼。 ReplicationControllers動態(tài)的創(chuàng)建和銷毀Pods(比如規(guī)模擴大或者縮小食寡，或者執(zhí)行動態(tài)更新)。每個pod都由自己的ip廓潜，這些IP也隨著時間的變化也不能持續(xù)依賴抵皱。這樣就引發(fā)了一個問題：如果一些Pods（讓我們叫它作后臺善榛，后端）提供了一些功能供其它的Pod使用（讓我們叫作前臺），在kubernete集群中是如何實現(xiàn)讓這些前臺能夠持續(xù)的追蹤到這些后臺的呻畸？

答案是：Service

Kubernete Service 是一個定義了一組Pod的策略的抽象移盆，我們也有時候叫做宏觀服務(wù)。這些被服務(wù)標(biāo)記的Pod都是（一般）通過label Selector決定的（下面我們會講到我們?yōu)槭裁葱枰粋€沒有l(wèi)abel selector的服務(wù)）

舉個例子伤为，我們假設(shè)后臺是一個圖形處理的后臺咒循，并且由3個副本。這些副本是可以相互替代的绞愚，并且前臺并需要關(guān)心使用的哪一個后臺Pod叙甸，當(dāng)這個承載前臺請求的pod發(fā)生變化時，前臺并不需要直到這些變化位衩，或者追蹤后臺的這些副本裆蒸，服務(wù)是這些去耦

對于Kubernete原生的應(yīng)用，Kubernete提供了一個簡單的Endpoints API糖驴，這個Endpoints api的作用就是當(dāng)一個服務(wù)中的pod發(fā)生變化時僚祷，Endpoints API隨之變化，對于哪些不是原生的程序遂赠，Kubernetes提供了一個基于虛擬IP的網(wǎng)橋的服務(wù)久妆，這個服務(wù)會將請求轉(zhuǎn)發(fā)到對應(yīng)的后臺pod。

Volumes

容器中的磁盤的生命周期是短暫的跷睦，這就帶來了一系列的問題筷弦，第一，當(dāng)一個容器損壞之后抑诸，kubelet 會重啟這個容器烂琴，但是文件會丟失-這個容器會是一個全新的狀態(tài)，第二蜕乡，當(dāng)很多容器在同一Pod中運行的時候奸绷，很多時候需要數(shù)據(jù)文件的共享。Kubernete Volume解決了這個問題层玲。

PV/PVC/StorageClass

PersistentVolume（PV）是集群中已由管理員配置的一段網(wǎng)絡(luò)存儲号醉。 集群中的資源就像一個節(jié)點是一個集群資源。 PV是諸如卷之類的卷插件辛块，但是具有獨立于使用PV的任何單個pod的生命周期畔派。 該API對象捕獲存儲的實現(xiàn)細(xì)節(jié)，即NFS润绵，iSCSI或云提供商特定的存儲系統(tǒng)线椰。

PersistentVolumeClaim（PVC）是用戶存儲的請求。 它類似于pod尘盼。 Pod消耗節(jié)點資源憨愉，PVC消耗光伏資源烦绳。 莢可以請求特定級別的資源（CPU和內(nèi)存）。 權(quán)利要求可以請求特定的大小和訪問模式（例如配紫，可以一旦讀/寫或只讀許多次安裝）径密。

雖然PersistentVolumeClaims允許用戶使用抽象存儲資源，但是常見的是笨蚁，用戶需要具有不同屬性（如性能）的PersistentVolumes睹晒，用于不同的問題趟庄。 群集管理員需要能夠提供多種不同于PersistentVolumes的PersistentVolumes括细，而不僅僅是大小和訪問模式，而不會使用戶了解這些卷的實現(xiàn)細(xì)節(jié)戚啥。 對于這些需求奋单，存在StorageClass資源。

StorageClass為管理員提供了一種描述他們提供的存儲的“類”的方法猫十。 不同的類可能映射到服務(wù)質(zhì)量級別览濒，或備份策略，或者由群集管理員確定的任意策略拖云。 Kubernetes本身對于什么類別代表是不言而喻的贷笛。 這個概念有時在其他存儲系統(tǒng)中稱為“配置文件”

例子

<u>https://kubernetes.io/docs/user-guide/persistent-volumes/walkthrough/</u>

Deployment

Deployment為Pod和ReplicaSet提供了一個聲明式定義(declarative)方法，用來替代以前的ReplicationController來方便的管理應(yīng)用宙项。典型的應(yīng)用場景包括：

• 定義Deployment來創(chuàng)建Pod和ReplicaSet
• 滾動升級和回滾應(yīng)用
• 擴容和縮容
• 暫停和繼續(xù)Deployment
  比如一個簡單的nginx應(yīng)用可以定義為：

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80 

擴容：
kubectl scale deployment nginx-deployment --replicas 10
如果集群支持 horizontal pod autoscaling 的話乏苦，還可以為Deployment設(shè)置自動擴展：
kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80
更新鏡像也比較簡單:
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
回滾：
kubectl rollout undo deployment/nginx-deployment

Secret

Secret解決了密碼、token尤筐、密鑰等敏感數(shù)據(jù)的配置問題矩欠，而不需要把這些敏感數(shù)據(jù)暴露到鏡像或者Pod Spec中病梢。Secret可以以Volume或者環(huán)境變量的方式使用。
Secret有三種類型：

• Service Account：用來訪問Kubernetes API，由Kubernetes自動創(chuàng)建美侦，并且會自動掛載到Pod的/run/secrets/kubernetes.io/serviceaccount目錄中；
• Opaque：base64編碼格式的Secret殴玛，用來存儲密碼毕荐、密鑰等；
• kubernetes.io/dockerconfigjson：用來存儲私有docker registry的認(rèn)證信息冕碟。

StatefulSet

StatefulSet是為了解決有狀態(tài)服務(wù)的問題（對應(yīng)Deployments和ReplicaSets是為無狀態(tài)服務(wù)而設(shè)計）拦惋，其應(yīng)用場景包括：

• 穩(wěn)定的持久化存儲，即Pod重新調(diào)度后還是能訪問到相同的持久化數(shù)據(jù)鸣哀，基于PVC來實現(xiàn)
• 穩(wěn)定的網(wǎng)絡(luò)標(biāo)志架忌，即Pod重新調(diào)度后其PodName和HostName不變，基于Headless Service（即沒有Cluster IP的Service）來實現(xiàn)
• 有序部署我衬，有序擴展叹放，即Pod是有順序的饰恕，在部署或者擴展的時候要依據(jù)定義的順序依次依次進(jìn)行（即從0到N-1，在下一個Pod運行之前所有之前的Pod必須都是Running和Ready狀態(tài)）井仰，基于init containers來實現(xiàn)
• 有序收縮埋嵌，有序刪除（即從N-1到0）

從上面的應(yīng)用場景可以發(fā)現(xiàn)，StatefulSet由以下幾個部分組成：

• 用于定義網(wǎng)絡(luò)標(biāo)志（DNS domain）的Headless Service
• 用于創(chuàng)建PersistentVolumes的volumeClaimTemplates
• 定義具體應(yīng)用的StatefulSet

DaemonSet

DaemonSet保證在每個Node上都運行一個容器副本俱恶，常用來部署一些集群的日志雹嗦、監(jiān)控或者其他系統(tǒng)管理應(yīng)用。典型的應(yīng)用包括：

• 日志收集合是，比如fluentd了罪，logstash等
• 系統(tǒng)監(jiān)控，比如Prometheus Node Exporter聪全，collectd泊藕，New Relic agent，Ganglia gmond等
• 系統(tǒng)程序难礼，比如kube-proxy, kube-dns, glusterd, ceph等

Service Account

Service account是為了方便Pod里面的進(jìn)程調(diào)用Kubernetes API或其他外部服務(wù)而設(shè)計的娃圆。

CronJob

CronJob即定時任務(wù)，就類似于Linux系統(tǒng)的crontab蛾茉，在指定的時間周期運行指定的任務(wù)讼呢。在Kubernetes 1.5，使用CronJob需要開啟batch/v2alpha1 API谦炬，即–runtime-config=batch/v2alpha1悦屏。

Job

Job負(fù)責(zé)批量處理短暫的一次性任務(wù) (short lived one-off tasks)，即僅執(zhí)行一次的任務(wù)吧寺，它保證批處理任務(wù)的一個或多個Pod成功結(jié)束窜管。

Kubernetes支持以下幾種Job：

• 非并行Job：通常創(chuàng)建一個Pod直至其成功結(jié)束
• 固定結(jié)束次數(shù)的Job：設(shè)置.spec.completions，創(chuàng)建多個Pod稚机，直到.spec.completions個Pod成功結(jié)束
• 帶有工作隊列的并行Job：設(shè)置.spec.Parallelism但不設(shè)置.spec.completions幕帆，當(dāng)所有Pod結(jié)束并且至少一個成功時，Job就認(rèn)為是成功

Security Context 和 PSP

Security Context的目的是限制不可信容器的行為赖条，保護(hù)系統(tǒng)和其他容器不受其影響失乾。
Kubernetes提供了三種配置Security Context的方法：

• Container-level Security Context：僅應(yīng)用到指定的容器
• Pod-level Security Context：應(yīng)用到Pod內(nèi)所有容器以及Volume
• Pod Security Policies（PSP）：應(yīng)用到集群內(nèi)部所有Pod以及Volume

Pod Security Policies（PSP）是集群級的Pod安全策略，自動為集群內(nèi)的Pod和Volume設(shè)置Security Context纬乍。
使用PSP需要API Server開啟extensions/v1beta1/podsecuritypolicy碱茁，并且配置PodSecurityPolicyadmission控制器。

Resource Quotas

資源配額（Resource Quotas）是用來限制用戶資源用量的一種機制仿贬。
它的工作原理為：

• 資源配額應(yīng)用在Namespace上纽竣，并且每個Namespace最多只能有一個ResourceQuota對象
• 開啟計算資源配額后，創(chuàng)建容器時必須配置計算資源請求或限制（也可以用LimitRange設(shè)置默認(rèn)值）
• 用戶超額后禁止創(chuàng)建新的資源

Network Policy

Network Policy提供了基于策略的網(wǎng)絡(luò)控制，用于隔離應(yīng)用并減少攻擊面蜓氨。它使用標(biāo)簽選擇器模擬傳統(tǒng)的分段網(wǎng)絡(luò)聋袋，并通過策略控制它們之間的流量以及來自外部的流量。
在使用Network Policy之前穴吹，需要注意：

• apiserver開啟extensions/v1beta1/networkpolicies
• 網(wǎng)絡(luò)插件要支持Network Policy幽勒，如Calico、Romana港令、Weave Net和trireme等

Ingress

通常情況下啥容，service和pod的IP僅可在集群內(nèi)部訪問。集群外部的請求需要通過負(fù)載均衡轉(zhuǎn)發(fā)到service在Node上暴露的NodePort上顷霹，然后再由kube-proxy將其轉(zhuǎn)發(fā)給相關(guān)的Pod咪惠。
而Ingress就是為進(jìn)入集群的請求提供路由規(guī)則的集合，如下圖所示

image.png

Ingress可以給service提供集群外部訪問的URL泼返、負(fù)載均衡硝逢、SSL終止、HTTP路由等绅喉。為了配置這些Ingress規(guī)則，集群管理員需要部署一個Ingress controller叫乌，它監(jiān)聽Ingress和service的變化柴罐，并根據(jù)規(guī)則配置負(fù)載均衡并提供訪問入口。

ThirdPartyResources

ThirdPartyResources是一種無需改變代碼就可以擴展Kubernetes API的機制憨奸，可以用來管理自定義對象革屠。

hirdPartyResources將在v1.7棄用
ThirdPartyResources將在v1.7棄用，并在未來版本中刪除排宰。建議從v1.7開始似芝，遷移到CustomResourceDefinition。

ConfigMap

ConfigMap用于保存配置數(shù)據(jù)的鍵值對板甘，可以用來保存單個屬性党瓮，也可以用來保存配置文件。ConfigMap跟secret很類似盐类，但它可以更方便地處理不包含敏感信息的字符串寞奸。

PodPreset

PodPreset用來給指定標(biāo)簽的Pod注入額外的信息，如環(huán)境變量在跳、存儲卷等枪萄。這樣，Pod模板就不需要為每個Pod都顯式設(shè)置重復(fù)的信息猫妙。