Kubernetes1.3有哪些新功能

本篇內(nèi)容介紹了“Kubernetes1.3有哪些新功能”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

支持更多類型的應(yīng)用

1 Init container

Init container 是1.3 中的 alpha feature，目的是支持一類需要在啟動(dòng) Pod“普通容器”前，先進(jìn)行 Pod 初始化的應(yīng)用。執(zhí)行該初始化任務(wù)的容器被成為“初始化容器”（init container）。例如，在啟動(dòng)應(yīng)用之前，初始化數(shù)據(jù)庫(kù)，或等待數(shù)據(jù)庫(kù)啟動(dòng)等。下圖是一個(gè)包含 init container 的 Pod：

對(duì)于此類 Pod，kubernetes 的運(yùn)行策略如下：

• 初始化容器按順序依次執(zhí)行，即圖中容器 1->2

• 若其中某一個(gè)初始化容器運(yùn)行失敗，則整個(gè) Pod 失敗

• 當(dāng)所有初始化容器運(yùn)行成功，啟動(dòng)普通容器，即圖中容器 A 和 B

在 alpha 版本中使用 init container 需要用 annotation，下圖是來(lái)自 k8s 的一個(gè)例子（略有裁剪）：

可以看到，我們?cè)趩?dòng) nginx 普通容器之前，先用 init container 來(lái)獲取 index.html，之后訪問(wèn) nginx 就會(huì)直接返回該文件。當(dāng) init container 功能穩(wěn)定后，k8s 會(huì)直接在 pod.spec 內(nèi)加上 init Containers 字段，如下所示：

init container 看起來(lái)是一個(gè)小功能，但是在實(shí)現(xiàn)上還是需要考慮不少問(wèn)題，比如幾個(gè)比較重要的點(diǎn)：

資源問(wèn)題：當(dāng)調(diào)度存在 init container 的 Pod 時(shí)，應(yīng)該怎樣計(jì)算所需要的資源？?jī)蓚€(gè)極端情況：如果對(duì) init container 和 regular container 所需要的資源求和，那么當(dāng) init container 成功初始化 Pod 之后，就不會(huì)再使用所請(qǐng)求的資源，而系統(tǒng)認(rèn)為在使用，會(huì)造成浪費(fèi)；反之，不計(jì)算 init container 的資源又會(huì)導(dǎo)致系統(tǒng)不穩(wěn)定（init container 所使用的資源未被算入調(diào)度資源內(nèi)）。目前的方法是取折中：由于初始化容器和普通容器不會(huì)同時(shí)運(yùn)行，因此 Pod 的資源請(qǐng)求是兩者中的最大值。對(duì)于初始化容器，由于他們是依次運(yùn)行，因此選擇其中的最大值；對(duì)于普通容器，由于是同時(shí)運(yùn)行，選擇容器資源的和。

Pod Status: 目前，Pod 有 Pending, Running, Terminating 等狀態(tài)。對(duì)于有初始化容器的 Pod，如果仍然使用 Pending 狀態(tài)，則很難區(qū)分 Pod 當(dāng)前在運(yùn)行初始化容器還是普通容器。因此，理想情況下，我們需要增加一個(gè)類似于 Initializing 的狀態(tài)。在 alpha 版本中暫時(shí)還未添加。

健康檢查及可用性檢查：有了 init container 之后，我們?cè)撊绾螜z查容器的健康狀態(tài)？alpha 版本將兩個(gè)檢查都關(guān)閉了，但 init container 是會(huì)在 node 上實(shí)實(shí)在在運(yùn)行的容器，理論上是需要進(jìn)行檢查的。對(duì)于可用性檢查，關(guān)閉掉是一個(gè)可行的辦法，因?yàn)?init container 的可用性其實(shí)就是當(dāng)它運(yùn)行結(jié)束的時(shí)候。對(duì)于健康檢查，node 需要知道某個(gè) Pod 是否處在初始化階段；如果處在初始化階段，那么 node 就可以對(duì) init container 進(jìn)行健康檢查。因此，kubernetes 很有可能在添加類似 Initializing 的 Pod 狀態(tài)之后，開啟 init container 的健康檢查。

圍繞 init container 的問(wèn)題還有很多，比如 QoS，Pod 的更新等等，其中不少都是有待解決的問(wèn)題，這里就不一一展開了 :)

2 PetSet

PetSet 應(yīng)該算是社區(qū)期待已久的功能，其目的是支持有狀態(tài)和集群化的應(yīng)用，目前也是 alpha 階段。PetSet 的應(yīng)用場(chǎng)景很多，包括類似 zookeeper、etcd 之類的 quorum leader election 應(yīng)用，類似 Cassandra 的 Decentralized quorum 等。PetSet 中，每個(gè) Pod 都有唯一的身份，分別包括：名字，網(wǎng)絡(luò)和存儲(chǔ)；并由新的組件 PetSet Controller 負(fù)責(zé)創(chuàng)建和維護(hù)。下面依次看一看 kubernetes 是如何維護(hù) Pod 的唯一身份。

名字比較容易理解，當(dāng)我們創(chuàng)建一個(gè) RC 之后，kubernetes 會(huì)創(chuàng)建指定副本數(shù)量的 Pod，當(dāng)使用 kubectl 獲取 Pod 信息時(shí)，我們會(huì)得到如下信息：

其中，5 個(gè)字符的后綴為 kubernetes 自動(dòng)生成。當(dāng) Pod 重啟，我們會(huì)得到不同的名字。對(duì)于 PetSet 來(lái)講，Pod 重啟必須保證名字不變。因此，PetSet 控制器會(huì)維護(hù)一個(gè) identityMap，每一個(gè) PetSet 中的每個(gè) Pod 都會(huì)有一個(gè)唯一名字，當(dāng) Pod 重啟，PetSet 控制器可以感知到是哪個(gè) Pod，然后通知 API server 創(chuàng)建新的同名 Pod。目前的感知方法很簡(jiǎn)單，PetSet 控制器維護(hù)的 identityMap 將 Pod 從 0 開始進(jìn)行編號(hào)，然后同步的過(guò)程就像報(bào)數(shù)一樣，哪個(gè)編號(hào)不在就重啟哪個(gè)編號(hào)。

此外，該編號(hào)還有另外一個(gè)作用，PetSet 控制器通過(guò)編號(hào)來(lái)確保 Pod 啟動(dòng)順序，只有 0 號(hào) Pod 啟動(dòng)之后，才能啟動(dòng) 1 號(hào) Pod。

網(wǎng)絡(luò)身份的維護(hù)主要通過(guò)穩(wěn)定的 hostname 和 domain name 來(lái)維護(hù)，他們通過(guò) PetSet 的配置文件指定。例如，下圖是一個(gè) PetSet 的 Yaml 文件（有裁剪），其中 metadata.name 指定了 Pod 的 hostname 前綴（后綴即前面提到的從 0 開始的索引），spec.ServiceName 指定了 domain name。

       通過(guò)上面的 Yaml 文件創(chuàng)建出來(lái)兩個(gè) Pod：web-0 和 web-1。其完整的域名為 web-0.nginx.default.svc.cluster.local，其中 web-0 為 hostname，nginx 為 Yaml 中指定的 domain name，剩下的部分與普通 service 無(wú)異。當(dāng)創(chuàng)建請(qǐng)求被下發(fā)到節(jié)點(diǎn)上時(shí)，kubelet 會(huì)通過(guò) container runtime 設(shè)置 UTS namespace，如下圖所示（省略了部分組件如 apiserver）。

此時(shí)，hostname 已經(jīng)在容器層面設(shè)置完成，剩下還需要為 hostname 增加集群層面的解析，以及添加 domain name 的解析，這部分工作理所當(dāng)然就交給了 kube dns。了解 Kubernetes 的讀者應(yīng)該知道，要添加解析，我們需要?jiǎng)?chuàng)建 service；同理，這里也需要為 PetSet 創(chuàng)建 service。不同的是，普通的 service 默認(rèn)后端的 Pod 是可替換的，并采用諸如 roundrobin，client ip 的方式選擇后端的 Pod，這里，由于每個(gè) Pod 都是一個(gè) Pet，我們需要定位每一個(gè) Pod，因此，我們創(chuàng)建的 service 必須要能滿足這個(gè)要求。在 PetSet 中，利用了 kubernetes headless service。Headless service 不會(huì)分配 cluster IP 來(lái) load balance 后端的 Pod，但會(huì)在集群 DNS 服務(wù)器中添加記錄：創(chuàng)建者需要自己去利用這些記錄。下圖是我們需要?jiǎng)?chuàng)建的 headless service，注意其中的 clusterIP 被設(shè)置為 None，表明這是一個(gè) headless service。

Kube dns 進(jìn)行一番處理之后，會(huì)生成如下的記錄：

可以看到，訪問(wèn) web-0.nginx.default.svc.cluster.local 會(huì)返回 pod IP，訪問(wèn) nginx.default.svc.cluster.local 會(huì)返回所有 Pet 中的 pods IP。一個(gè)常見的方式是通過(guò)訪問(wèn) domain 的方式來(lái)獲取所有的 peers，然后依次和單獨(dú)的 Pod 通信。

存儲(chǔ)身份這塊采用的是 PV/PVC 實(shí)現(xiàn)，當(dāng)我們創(chuàng)建 PetSet 時(shí)，需要指定分配給 Pet 的數(shù)據(jù)卷，如下圖：

這里，volumeClaimTemplates 指定每個(gè) Pet 需要的存儲(chǔ)資源。注意目前所有 Pet 都得到相同大小和類型的數(shù)據(jù)卷。當(dāng) PetSet 控制器拿到請(qǐng)求時(shí)，會(huì)為每一個(gè) Pet 創(chuàng)建 PVC，然后將每個(gè) Pet 和對(duì)應(yīng)的 PVC 聯(lián)系起來(lái)：

之后的 PetSet 只需要確保每個(gè) Pet 都與相對(duì)應(yīng)的 PVC 綁定在一起即可，其他工作，類似于創(chuàng)建數(shù)據(jù)卷，掛載等工作，都交給其他組件。

通過(guò)名字，網(wǎng)絡(luò)，存儲(chǔ)，PetSet 能夠 cover 大多數(shù)的案例。但是，目前還存在很多需要完善的地方，感興趣的讀者可以參考：https://github.com/kubernetes/kubernetes/issues/28718

3 Scheduled Job

Scheduled Job 本質(zhì)上是集群 cron，類似 mesos chronos，采用標(biāo)準(zhǔn)的 cron 語(yǔ)法。遺憾的是在 1.3 中還并未達(dá)到發(fā)布的標(biāo)準(zhǔn)。Scheduled Job 其實(shí)在很早就提出來(lái)過(guò)，但當(dāng)時(shí) kubernetes 的重點(diǎn)還在 API 層面，并且即使有很大需求，也計(jì)劃在 Job（1.2GA）之后實(shí)現(xiàn)。當(dāng) scheduled job 在之后的版本發(fā)布之后，用戶可以用一條簡(jiǎn)單的命令在 kubernetes 上運(yùn)行 Job，例如：kubectl run cleanup -image=cleanup --runAt="0 1 0 0 *"  -- /scripts/cleanup.sh一些關(guān)于 scheduled job 的更新可以參考：https://github.com/kubernetes/kubernetes/pull/25595

4 Disruption Budget

Disruption Budget 的提出是為了向 Pod 提供一個(gè)反饋機(jī)制，確保應(yīng)用不會(huì)被集群自身的變動(dòng)而受影響。例如，當(dāng)集群需要進(jìn)行重調(diào)度時(shí)，應(yīng)用可以通過(guò) Disruption Budget 來(lái)說(shuō)明 Pod 能不能被遷移。Disruption Budget 只負(fù)責(zé)集群自身發(fā)起的變動(dòng)，不負(fù)責(zé)突發(fā)事件比如節(jié)點(diǎn)突然掉線，或者應(yīng)用本身的問(wèn)題比如不斷重啟的變動(dòng)。Disruption Budget 同樣沒(méi)有在 1.3 中發(fā)布。

與 kubernetes 大多數(shù)資源類似，我們需要通過(guò) Yaml 文件創(chuàng)建一個(gè) PodDisruptionBudget 資源，例如，下圖所示的 Disruption Budget 選中了所有帶有 app:nginx 標(biāo)簽的 pod，并且要求至少有 3 個(gè) Pod 在同時(shí)運(yùn)行。

Controller manager 內(nèi)有一個(gè)新的組件 Disruption Budget Controller，來(lái)負(fù)責(zé)維護(hù)所有 Budget 的狀態(tài)，例如上圖中的 status 表明當(dāng)前共有 4 個(gè)健康的 Pod（currentHealthy），應(yīng)用要求至少有 3 個(gè)（desiredHealthy），總共有 5 個(gè)Pod（expectedPods）。為了維護(hù)這個(gè)狀態(tài)，Disruption Budget Controller 會(huì)遍歷所有的 Budget 和所有的 Pod。有了 Budget 的狀態(tài)，需要改變 Pod 狀態(tài)的組件都要先查詢之。若其操作導(dǎo)致最小可用數(shù)低于應(yīng)用要求，則操作會(huì)被拒絕。Disruption Budget 與 QoS 聯(lián)系很緊密。例如，如果一個(gè) QoS level 很低的應(yīng)用有著非常嚴(yán)格的 Disruption Budget，系統(tǒng)應(yīng)該如何處理？目前，kubernetes 還沒(méi)有嚴(yán)格的處理這個(gè)問(wèn)題，一個(gè)可行的辦法是對(duì) Disruption Budget 做優(yōu)先級(jí)處理，確保高優(yōu)先級(jí)的應(yīng)用擁有高優(yōu)先級(jí)的 Disruption Budget；此外，Disruption Budget 可以加入 Quota 系統(tǒng)，高優(yōu)先級(jí)的應(yīng)用可以獲得更多 Disruption Budget Quota。關(guān)于 Disruption Budget 的討論可以參考：https://github.com/kubernetes/kubernetes/issues/12611

支持更好的集群管理

1 Cascading Deletion

在 kubernetes 1.2 之前，刪除控制單元都不會(huì)刪除底層的資源。例如，通過(guò) API 刪除 RC 之后，其管理的 Pod 不會(huì)被刪除（使用 kubectl 可以刪除，但 kubectl 里面有 reaper 邏輯，會(huì)依次刪除底層的所有 Pod，本質(zhì)上是客戶端邏輯）。另外一個(gè)例子，當(dāng)刪除下圖中的 Deployment 時(shí)，ReplicaSet 不會(huì)被自動(dòng)刪除，當(dāng)然，Pod 也不會(huì)被回收。

Cascading deletion 指的就是在刪除控制單元后，將被管理單元也同時(shí)回收。但是，kubernetes 1.3 中的 cascading deletion 并不是簡(jiǎn)單地講 kubectl 中的邏輯復(fù)制到 server 端，而是做了更高層次的工作：垃圾回收。簡(jiǎn)單來(lái)講，garbagecollector controller 維護(hù)了幾乎所有集群資源的列表，并接收資源修改的事件。controller 根據(jù)事件類型更新資源關(guān)系圖，并將受影響的資源放入 Dirty Queue 或者 Orphan Queue 中。具體實(shí)現(xiàn)可以參考官方文檔和 garbage collector controller 實(shí)現(xiàn)：https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/garbage-collection.md

2 Node eviction

Node/kubelet eviction 指的是在節(jié)點(diǎn)將要超負(fù)荷之前，提前將 Pod 剔除出去的過(guò)程，主要是為了內(nèi)存和磁盤資源。在 kubernetes 1.3 之前，kubelet 不會(huì)“提前”感知節(jié)點(diǎn)的負(fù)荷，只會(huì)對(duì)已知的問(wèn)題進(jìn)行處理。當(dāng)內(nèi)存吃緊時(shí)，kubernetes 依靠?jī)?nèi)核 OOM killer；磁盤方面則定期對(duì) image 和 container 進(jìn)行垃圾回收。但是，這種方式有局限性，OOM killer 本身需要消耗一定資源，并且時(shí)間上有不確定性；回收容器和鏡像不能處理容器寫日志的問(wèn)題：如果應(yīng)用不斷寫日志，則會(huì)消耗掉所有磁盤，但不會(huì)被 kubelet 處理。

Node eviction 通過(guò)配置 kubelet 解決了以上問(wèn)題。當(dāng)啟動(dòng) kubelet 時(shí)，我們通過(guò)指定 memory.available, nodefs.available, nodefs.inodesFree 等參數(shù)來(lái)確保節(jié)點(diǎn)穩(wěn)定工作。例如，memory.available < 200Mi  表示當(dāng)內(nèi)存少于 200Mi時(shí)，kubelet 需要開始移除 Pod（可以配置為立即移除或者延遲移除，即 hard vs soft）。kubernetes 1.3 中，node eviction 的特性是 opt-in，默認(rèn)關(guān)閉，可以通過(guò)配置 kubelet 打開相關(guān)功能。

盡管 node eviction 是 kubelet 層面采取的措施，我們也必須考慮與整個(gè)集群的交互關(guān)系。其中最重要的一點(diǎn)是如何將這個(gè)問(wèn)題反饋給 scheduler，不然被剔除的 Pod 很有可能會(huì)被重新調(diào)度回來(lái)。為此，kubernetes 添加了新的 node condition：MemoryPressure, DiskPressure。當(dāng)節(jié)點(diǎn)的狀態(tài)包含其中任意一種時(shí)，調(diào)度器會(huì)避免往該節(jié)點(diǎn)調(diào)度新的 Pod。這里還有另外一個(gè)問(wèn)題，即如果節(jié)點(diǎn)的資源使用剛好在閾值附近，那么節(jié)點(diǎn)的狀態(tài)可能會(huì)在 Pressure 和 Not Pressure 之間抖動(dòng)。防抖動(dòng)的方法有很多種，例如平滑濾波，即將歷史數(shù)據(jù)也考慮在內(nèi)，加權(quán)求值。k8s 目前采用較為簡(jiǎn)單的方法：即如果節(jié)點(diǎn)處于 Pressure 狀態(tài)，為了轉(zhuǎn)變成 Not Pressure 狀態(tài)，資源使用情況必須低于閾值一段時(shí)間（默認(rèn) 5 分鐘）。這種方法會(huì)導(dǎo)致 false alarm，比如，若一個(gè)應(yīng)用每隔一段時(shí)間請(qǐng)求一塊內(nèi)存，之后很快釋放掉，那么可能會(huì)導(dǎo)致節(jié)點(diǎn)一直處于 Pressure 狀態(tài)。但大多數(shù)情況下，該方法能處理抖動(dòng)的情況。

說(shuō)到 eviction pod，那么另外一個(gè)不得不考慮的問(wèn)題就是找一個(gè)倒霉的 Pod。這里 kubernetes 定義了不少規(guī)則，總結(jié)下來(lái)主要是兩點(diǎn)：1. 根據(jù) QoS 來(lái)判斷，QoS 低的應(yīng)用先考慮；2. 根據(jù)使用量判斷，使用量與總請(qǐng)求量比例大的 Pod 優(yōu)先考慮。具體細(xì)節(jié)可以參考：https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/kubelet-eviction.md

3 Network Policy

Network policy 的目的是提供 Pod 之間的隔離，用戶可以定義任意 Pod 之間的通信規(guī)則，粒度為端口。例如，下圖的規(guī)則可以解釋成：擁有標(biāo)簽“db”的 Pod，只能被擁有標(biāo)簽“frontend”的 Pod 訪問(wèn)，且只能訪問(wèn) tcp 端口 6379。

Network policy 目前處于 beta 版本，并且只是 API。也就是說(shuō)，kubernetes 不會(huì)真正實(shí)現(xiàn)網(wǎng)絡(luò)隔離：如果我們將上述 Yaml 文件提交到 kubernetes，并不會(huì)有任何反饋，kubernetes 只是保存了這個(gè) Policy 內(nèi)容。真正實(shí)現(xiàn) policy 功能需要其他組件，比如 calico 實(shí)現(xiàn)了一個(gè) controller，會(huì)讀取用戶創(chuàng)建的 Policy 來(lái)實(shí)現(xiàn)隔離，可以參考：https://github.com/projectcalico/k8s-policy/。關(guān)于 Network Policy 的細(xì)節(jié)，可以參考：https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/network-policy.md

4 Federation

Federation cluster 翻譯成中文叫“聯(lián)合集群”，即將多個(gè) kubernetes 集群聯(lián)合成一個(gè)整體，并且不改變?cè)?kubernetes 集群的工作方式。根據(jù) kubernetes 官方設(shè)計(jì)文檔，federation 的設(shè)計(jì)目的主要是滿足服務(wù)高可用，混合云等需求。在 1.3 版本之前，kubernetes 實(shí)現(xiàn)了 federation-lite，即一個(gè)集群中的機(jī)器可以來(lái)自于相同 cloud 的不同 zone；1.3 版本中，federation-full 的支持已經(jīng)是 beta 版本，即每個(gè)集群來(lái)自不同的 cloud（或相同）。

 Federation的核心組件主要是 federation-apiserver 和 federation-controller-manager，以 Pod 形式運(yùn)行在其中一個(gè)集群中。如下圖所示，外部請(qǐng)求直接與 Federation Control Panel 通信，由 Federation 分析請(qǐng)求并發(fā)送至 kubernetes 集群。

在應(yīng)用層面，F(xiàn)ederation 目前支持 federated services，即一個(gè)應(yīng)用跨多個(gè)集群的訪問(wèn)

“Kubernetes1.3有哪些新功能”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！