第12章 Kubernetes開發(fā)中的新功能
12.1 對Windows容器的支持
12.1.1 Windows Node部署
12.1.2 Windows容器支持的Kubernetes特性和發(fā)展趨勢
12.2 對GPU的支持
12.2.1 環(huán)境準(zhǔn)備
12.2.2 在容器中使用GPU資源
12.2.3 發(fā)展趨勢
12.3 Pod的垂直擴(kuò)縮容
12.3.1 前提條件
12.3.2 安裝Vertical Pod Autoscaler
12.3.3 為Pod設(shè)置垂直擴(kuò)縮容
12.3.4 注意事項(xiàng)
12.4 Kubernetes的演進(jìn)路線和開發(fā)模式

本章對Kubernetes開發(fā)中的一些新功能進(jìn)行介紹，包括對Windows容器的支持、對GPU的支持、Pod的垂直擴(kuò)縮容，并講解Kubernetes的演進(jìn)路線（Roadmap）和開發(fā)模式。
12.1 對Windows容器的支持
Kubernetes從1.5版本開始，就引入了管理基于Windows Server 2016操作系統(tǒng)的Windows容器的功能。
隨著Windows Server version 1709的發(fā)布，Kubernetes 1.9對Windows容器的支持提升為Beta版，Kubernetes 1.14對Windows容器的支持提升為GA穩(wěn)定版。
目前Windows Server的最新版本是2019，與Kubernetes的對接更加成熟。
目前Windows Server可以作為Node加入Kubernetes集群中，集群的Master仍需在Linux環(huán)境中運(yùn)行。
在Kubernetes上改進(jìn)了Windows容器的一些關(guān)鍵功能，包括：
對Pod網(wǎng)絡(luò)模型的支持，可為一個(gè)Pod內(nèi)的多個(gè)容器設(shè)置共享的網(wǎng)絡(luò)命名空間（共享kernel模式）；
為每個(gè)Pod都設(shè)置了單個(gè)網(wǎng)絡(luò)Endpoint，以降低網(wǎng)絡(luò)復(fù)雜性；
使用Windows Server的Virtual Filtering Platform (VFP) Hyper-v Switch Extension技術(shù)，實(shí)現(xiàn)了類似于Linux iptables的負(fù)載均衡器；
Pod支持容器運(yùn)行時(shí)接口（CRI）和Node的統(tǒng)計(jì)信息；
支持使用kubeadm命令將Windows Server節(jié)點(diǎn)添加到集群中。
下面對Windows Node部署，以及Kubernetes支持的Windows容器特性和發(fā)展趨勢進(jìn)行講解。

12.1.1 Windows Node部署
需要在Windows Server上安裝的Kubernetes Node相關(guān)組件包括Docker、kubelet、kube-proxy和kubectl。
Docker版本要求在18.03及以上，推薦使用最新版本。
可參考官方文檔https://docs.docker.com/install/windows/docker-ee/#use-a-script-to-install-docker-ee在Windows Server上安裝Docker。
從Kubernetes的版本發(fā)布頁面（https://github.com/kubernetes/kubernetes/releases）下載Windows Node相關(guān)文件，
例如Kubernetes Windows Node 1.14的下載頁面為https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#node-binaries，
在該頁面下載kubernetes-node-windows-amd64.tar.gz文件，將其解壓縮后得到可執(zhí)行文件kubelet.exe、kube-proxy.exe、kubectl.exe和kubeadm.exe，如圖12.1所示。
下面介紹如何在Windows Server 2019上搭建Kubernetes Node，
詳細(xì)的操作文檔請參考https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/getting-startedkubernetes-windows。
1）制作kubelet運(yùn)行容器所需的pause鏡像。
下載Microsoft提供的nanoserver鏡像（需要與Windows Server的版本相匹配）：
C:\> docker pull mcr.microsoft.com/windows/nanoserver:1809
將該鏡像重命名為microsoft/nanoserver:latest：
C:\> docker tag mcr.microsoft.com/windows/nanoserver:1809 microsoft.com/nanoserver:latest
編寫Dockerfile：
FROM microsoft.com/nanoserver
CMD cmd /c ping -t localhost
運(yùn)行docker build命令制作pause鏡像，并將鏡像名設(shè)置為kubeletwin/pause：
C:\> docker build -t kubeletwin/pause
2）將Kubernetes Windows Node的壓縮包文件解壓縮到C:\k目錄下，得到kubelet.exe、kube-proxy.exe和kubectl.exe文件。
3）將連接Kubernetes Master所需的kubeconfig文件和SSL安全證書文件從Linux Node復(fù)制到C:\k目錄下，將文件名改為config。
可以使用kubectl.exe命令驗(yàn)證能否訪問Master：
[Environment]::SetEnvironmentVariable("KUBECONFIG","C:\k\config",[EnvironmentVariableTarget]::User)
C:\k> kubectl config view
4）選擇一個(gè)容器網(wǎng)絡(luò)方案，目前支持的網(wǎng)絡(luò)方案有如下3種：
（1）基于3層路由的網(wǎng)絡(luò)方案。
需要Top of Rack（機(jī)柜上面安裝的）交換機(jī)或路由器的支持，Windows節(jié)點(diǎn)的容器IP池應(yīng)由該交換機(jī)或路由器管理。
在Windows節(jié)點(diǎn)上需要?jiǎng)?chuàng)建一個(gè)虛擬的l2bridge網(wǎng)橋，用于連通Pod IP與物理機(jī)之間的網(wǎng)絡(luò)。
ToR交換機(jī)或路由器負(fù)責(zé)Pod的IP地址分配，并負(fù)責(zé)設(shè)置Pod IP與其他物理機(jī)聯(lián)通的靜態(tài)路由規(guī)則。
如圖12.2所示為基于3層路由的容器網(wǎng)絡(luò)方案，這種網(wǎng)絡(luò)方案與Linux的直接路由方案比較相似，但是對交換機(jī)或路由器的要求較高。
在圖12.2中，物理機(jī)網(wǎng)絡(luò)為10.127.132.*，Linux Master的IP地址為10.127.132.128，Linux Node的IP地址為10.127.132.129，Windows Node的IP地址為10.127.132.213。
Linux Node上的容器網(wǎng)絡(luò)IP范圍為 10.10.187.0/26，Windows Node上的容器網(wǎng)絡(luò)IP范圍為10.10.187.64/26，
要求ToR交換機(jī)或路由器管理Windows容器IP地址的分配并設(shè)置到其他主機(jī)的路由規(guī)則。
（2）基于Open vSwitch的網(wǎng)絡(luò)方案。
這種方案依賴Open vSwitch，部署流程比較復(fù)雜。如圖12.3所示為通用的網(wǎng)絡(luò)部署架構(gòu)。
（3）基于Flannel的網(wǎng)絡(luò)方案。
在Linux上為Kubernetes搭建CNI網(wǎng)絡(luò)的Flannel系統(tǒng)時(shí)，要求Linux的Kubernetes環(huán)境也使用Flannel網(wǎng)絡(luò)，能夠?qū)崿F(xiàn)Windows容器網(wǎng)絡(luò)與Linux容器網(wǎng)絡(luò)的互聯(lián)互通。
5）下載Windows Node的部署腳本和配置文件并修改配置。
目前Kubernetes在Windows Node上的部署腳本和CNI網(wǎng)絡(luò)插件可以從GitHub代碼庫（https://github.com/Microsoft/SDN/tree/master/Kubernetes）下載，
將該代碼庫windows子目錄的文件下載并保存到C:\k目錄下，再從另外幾個(gè)目錄下載CNI網(wǎng)絡(luò)插件相關(guān)的文件，例如flannel、wincni等，如圖12.4所示。
6）以Flannel為例配置CNI網(wǎng)絡(luò)的關(guān)鍵信息。
下載https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel中的文件并將其保存到C:\k目錄。
還需要將Flannel的可執(zhí)行文件flanneld.exe保存到C:\flannel目錄下。
start-kubelet.ps1腳本中的關(guān)鍵網(wǎng)絡(luò)配置參數(shù)如下：
Param(
[parameter(Mandatory = $false)] $clusterCIDR="10.244.0.0/16",
[parameter(Mandatory = $false)] $KubeDnsServiceIP="169.169.0.100",
[parameter(Mandatory = $false)] $serviceCIDR="169.169.0.0/16",
[parameter(Mandatory = $false)] $KubeDnsSuffix="svc.cluster.local",
[parameter(Mandatory = $false)] $InterfaceName="Ethernet",
[parameter(Mandatory = $false)] $LogDir="C:\k\logs",
[ValidateSet("process","hyperv")] $IsolationType="process",
$NetworkName = "cbr0",
[switch] $RegisterOnly
)
對于以下參數(shù)，可以在執(zhí)行start.ps1時(shí)用命令行參數(shù)指定，也可以直接修改start-kubelet.ps1腳本進(jìn)行設(shè)置。
clusterCIDR：用于設(shè)置Flannel的容器IP池，需要與kube-controller-manager的--cluster-cidr保持一致。
KubeDnsServiceIP：將其設(shè)置為Kubernetes集群DNS服務(wù)的ClusterIP，例如169.169.0.100。
serviceCIDR：將其設(shè)置為Kubernetes集群Service的ClusterIP池，例如169.169.0.0/16。
InterfaceName：Windows主機(jī)的網(wǎng)卡名，例如Ethernet。
LogDir：日志目錄，例如C:\k\logs。
在Update-CNIConfig函數(shù)內(nèi)設(shè)置Nameservers（DNS服務(wù)器）的IP地址，例如169.169.0.100：
function Update-CNIConfig($podCIDR){
...
}

7）運(yùn)行start.ps1腳本，將Windows Node加入Kubernetes集群：
.\tart.ps1 -ManagementIP "192.168.18.9" -ClusterCIDR "10.244.0.0/16" -ServiceCIDR "169.169.0.0/16" -KubeDnsServiceIP "169.169.0.100"
將其中的-ManagementIP參數(shù)設(shè)置為Windows Node的主機(jī)IP地址。
該腳本的啟動(dòng)過程如下。
（1）創(chuàng)建一個(gè)名為External、類型為L2Bridge的HNSNetwork虛擬網(wǎng)卡，其管理IP為Windows主機(jī)IP，如圖12.5所示。
（2）啟動(dòng)flanneld程序，創(chuàng)建一個(gè)名為cbr0、類型為L2Bridge的虛擬網(wǎng)卡（HNSNetwork），將其作為容器網(wǎng)絡(luò)的網(wǎng)橋，之后flanneld正常退出，如圖12.6所示。
（3）在名為cbr0的虛擬網(wǎng)卡創(chuàng)建成功后，在一個(gè)新的powershell窗口啟動(dòng)kubelet，如圖12.7所示。
（4）在一個(gè)新的powershell窗口啟動(dòng)kube-proxy，如圖12.8所示。
（5）在腳本啟動(dòng)成功之后，可以在Master上查看新加入的Windows Node：
# kubectl get nodes
查看這個(gè)Node的Label，可以看到其包含“kubernetes.io/os=windows”的Label，與Linux Node有所區(qū)分（Linux Node的標(biāo)簽為“kubernetes.io/os=linux”）：
# kubectl get no --show-labels
8）在Windows Node上部署容器應(yīng)用。
現(xiàn)在，我們可以像在Linux Node上部署容器應(yīng)用一樣，在Windows Node上部署Windows容器應(yīng)用。
下面是一個(gè)Web服務(wù)示例，可以從https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/manifests/simpleweb.yml獲得YAML配置文件，
其中容器鏡像使用的是mcr.microsoft.com/windows/servercore:1809，并通過powershell命令行啟動(dòng)了一個(gè)Web服務(wù)。
在Deployment的配置中需要設(shè)置nodeSelector為“kubernetes.io/os: windows”，以將Windows容器調(diào)度到Windows Node上：
用kubectl命令完成部署：
# kubectl apply -f simpleweb.yml
在Pod創(chuàng)建成功后，查看Pod的狀態(tài)：
# kubectl get pod -o wide
查看Service的信息：
# kubectl get svc win-webserver
下面在Linux環(huán)境中訪問Windows容器的服務(wù)。
使用容器IP訪問Windows容器的服務(wù)：
# curl 10.244.2.20:80
使用服務(wù)IP訪問Windows容器的服務(wù)：
# curl 169.169.219.15:80
對于類型為NodePort的服務(wù)，通過Windows Server的IP和NodePort也能訪問Windows容器的服務(wù)：
# curl 192.168.18.9:40001
在Windows環(huán)境中使用容器IP或服務(wù)IP也能訪問Windows容器的服務(wù)：
C:\> curl -UseBasicParsing 10.244.2.20:80

12.1.2 Windows容器支持的Kubernetes特性和發(fā)展趨勢
Kubernetes在1.14版本中對Windows容器的支持達(dá)到GA穩(wěn)定版，要求Windows Server的版本為Windows Server 2019，
支持的功能特性包括：
支持將Secret或ConfigMap掛載為環(huán)境變量或文件；
Volume存儲卷支持emptyDir和hostPath；
支持的持久化存儲卷PV類型包括FlexVolume（SMB+iSCSI類型）、AzureFile和AzureDisk；
支持livenessProbe和readinessProbe健康檢查機(jī)制；
支持容器的postStart和preStop命令；
支持CRI類型為Dockershim；
支持的控制器包括ReplicaSet、ReplicationController、Deployments、StatefulSets、DaemonSet、Job和CronJob；
支持Service的類型包括NodePort、ClusterIP、LoadBalancer、ExternalName和Headless Service；
支持CPU和內(nèi)存的資源限制；
支持Resource Quotas；
支持基于任意指標(biāo)數(shù)據(jù)的HPA機(jī)制；
支持的CNI網(wǎng)絡(luò)插件包括Azure-CNI、OVN-Kubernetes和Flannel（VxLAN和Host-Gateway模式）。
kubelet.exe和kube-proxy.exe可以以Windows服務(wù)的形式運(yùn)行。
已知的功能限制包括：
不支持容器以特權(quán)模式運(yùn)行；
不支持hostNetwork網(wǎng)絡(luò)模式；
不支持CSI插件；
不支持NFS類型的存儲卷；
在掛載存儲卷時(shí)無法設(shè)置subpath；
Windows容器內(nèi)的OS版本必須與宿主機(jī)OS的版本一致，否則容器無法啟動(dòng)。
Windows容器在Kubernetes上計(jì)劃完成的功能包括：
支持更多的Overlay網(wǎng)絡(luò)方案，包括Calico CNI插件；
支持更多的CRI容器運(yùn)行時(shí)；
支持通過kubeadm安裝Windows Node；
支持基于Hyper-V虛擬化技術(shù)在1個(gè)Pod中包含多個(gè)容器（目前在1個(gè)Pod中只能有1個(gè)容器）；
支持設(shè)置terminationGracePeriodSeconds實(shí)現(xiàn)對Pod的優(yōu)雅刪除；
支持設(shè)置run_as_username以自定義用戶名運(yùn)行容器內(nèi)的程序。
可以預(yù)見，在不久的將來，Kubernetes能完善Windows容器和Linux容器的混合管理，實(shí)現(xiàn)跨平臺的容器云平臺。

12.2 對GPU的支持
隨著人工智能和機(jī)器學(xué)習(xí)的迅速發(fā)展，基于GPU的大數(shù)據(jù)運(yùn)算越來越普及。
在Kubernetes的發(fā)展規(guī)劃中，GPU資源有著非常重要的地位。
用戶應(yīng)該能夠?yàn)槠涔ぷ魅蝿?wù)請求GPU資源，就像請求CPU或內(nèi)存一樣，而Kubernetes將負(fù)責(zé)調(diào)度容器到具有GPU資源的節(jié)點(diǎn)上。
目前Kubernetes對NVIDIA和AMD兩個(gè)廠商的GPU進(jìn)行了實(shí)驗(yàn)性的支持。
Kubernetes對NVIDIA GPU的支持是從1.6版本開始的，對AMD GPU的支持是從1.9版本開始的，并且都在快速發(fā)展。
Kubernetes從1.8版本開始，引入了Device Plugin（設(shè)備插件）模型，為設(shè)備提供商提供了一種基于插件的、無須修改kubelet核心代碼的外部設(shè)備啟用方式，
設(shè)備提供商只需在計(jì)算節(jié)點(diǎn)上以DaemonSet方式啟動(dòng)一個(gè)設(shè)備插件容器供kubelet調(diào)用，即可使用外部設(shè)備。
目前支持的設(shè)備類型包括GPU、高性能NIC卡、FPGA、InfiniBand等，
關(guān)于設(shè)備插件的說明詳見官方文檔https://kubernetes.io/docs/concepts/extend-kubernetes/computestorage-net/device-plugins。
下面對如何在Kubernetes中使用GPU資源進(jìn)行說明。

12.2.1 環(huán)境準(zhǔn)備
（1）在Kubernetes的1.8和1.9版本中，需要在每個(gè)工作節(jié)點(diǎn)上都為kubelet服務(wù)開啟--feature-gates="DevicePlugins=true"特性開關(guān)。
該特性開關(guān)從Kubernetes 1.10版本開始默認(rèn)啟用，無須手動(dòng)設(shè)置。
（2）在每個(gè)工作節(jié)點(diǎn)上都安裝NVIDIA GPU或AMD GPU驅(qū)動(dòng)程序，如下所述。
使用NVIDIA GPU的系統(tǒng)要求包括：
NVIDIA驅(qū)動(dòng)程序的版本為361.93及以上；
nvidia-docker的版本為2.0及以上；
配置Docker默認(rèn)使用NVIDIA運(yùn)行時(shí)；
Kubernetes的版本為1.11及以上。
Docker使用NVIDIA運(yùn)行時(shí)的配置示例（通常配置文件為/etc/docker/daemon.json）如下：
...
NVIDIA設(shè)備驅(qū)動(dòng)的部署YAML文件可以從NVIDIA的GitHub代碼庫https://github.com/NVIDIA/k8s-device-plugin/blob/v1.11/nvidia-device-plugin.yml獲取：
...
使用AMD GPU的系統(tǒng)要求包括：
服務(wù)器支持ROCm（Radeon Open Computing platform）；
ROCm kernel驅(qū)動(dòng)程序或AMD GPU Linux驅(qū)動(dòng)程序?yàn)樽钚掳姹荆?br> Kubernetes的版本為1.10及以上。
AMD設(shè)備驅(qū)動(dòng)的部署YAML文件可以從NVIDIA的GitHub代碼庫（https://github.com/RadeonOpenCompute/k8s-device-plugin/blob/master/k8s-ds-amdgpu-dp.ya ml）獲取：
...
在完成上述配置后，容器應(yīng)用就能使用GPU資源了。

12.2.2 在容器中使用GPU資源
GPU資源在Kubernetes中的名稱為nvidia.com/gpu（NVIDIA類型）或amd.com/gpu（AMD類型），可以對容器進(jìn)行GPU資源請求的設(shè)置。
在下面的例子中為容器申請1個(gè)GPU資源：
...
目前對GPU資源的使用配置有如下限制：
GPU資源請求只能在limits字段進(jìn)行設(shè)置，系統(tǒng)將默認(rèn)設(shè)置requests字段的值等于limits字段的值，不支持只設(shè)置requests而不設(shè)置limits；
在多個(gè)容器之間或者在多個(gè)Pod之間不能共享GPU資源；
每個(gè)容器只能請求整數(shù)個(gè)（1個(gè)或多個(gè)）GPU資源，不能請求1個(gè)GPU的部分資源。
如果在集群中運(yùn)行著不同類型的GPU，則Kubernetes支持通過使用Node Label（節(jié)點(diǎn)標(biāo)簽）和Node Selector（節(jié)點(diǎn)選擇器）將Pod調(diào)度到合適的GPU所屬的節(jié)點(diǎn)。
1.為Node添加合適的Label標(biāo)簽
對于NVIDIA類型的GPU，可以使用kubectl label命令為Node設(shè)置不同的標(biāo)簽：
# kubectl label nodes <node-with-k80> accelerator=nvidia-tesla-k80
# kubectl label nodes <node-with-p100> accelerator=nvidia-tesla-p100
對于AMD類型的GPU，可以使用AMD開發(fā)的Node Labeller工具自動(dòng)為Node設(shè)置合適的Label。
Node Labeller以DaemonSet的方式部署，可以從https://github.com/RadeonOpenCompute/k8s-device-plugin/blob/master/k8s-ds-amdgpu-labeller.yaml下載YAML配置文件。
在Node Labeller的啟動(dòng)參數(shù)中可以設(shè)置不同的Label以表示不同的GPU信息。
目前支持的Label如下:
（1）Device ID，啟動(dòng)參數(shù)為-device-id。
（2）VRAM Size，啟動(dòng)參數(shù)為-vram。
（3）Number of SIMD，啟動(dòng)參數(shù)為-simd-count。
（4）Number of Compute Unit，啟動(dòng)參數(shù)為-cu-count。
（5）Firmware and Feature Versions，啟動(dòng)參數(shù)為-firmware。
（6）GPU Family, in two letters acronym，啟動(dòng)參數(shù)為-family，family類型以兩個(gè)字母縮寫表示，完整的啟動(dòng)參數(shù)為family.SI、family.CI等。
其中，SI的全稱為Southern Islands；CI的全稱為Sea Islands；KV的全稱為Kaveri；VI的全稱為Volcanic Islands；CZ的全稱為Carrizo；AI的全稱為Arctic Islands；RV的全稱為Raven。
通過Node Labeller工具自動(dòng)為Node設(shè)置的Label示例如下：
# kubectl describe node cluster-node-23

2.設(shè)置Node Selector指定調(diào)度Pod到目標(biāo)Node上
以NVIDIA GPU為例：
...
上面的配置可確保將Pod調(diào)度到含有“accelerator=nvidia-tesla-k80”Label的節(jié)點(diǎn)運(yùn)行。

12.2.3 發(fā)展趨勢
發(fā)展趨勢如下:
GPU和其他設(shè)備將像CPU那樣成為Kubernetes系統(tǒng)的原生計(jì)算資源類型，以Device Plugin的方式供kubelet調(diào)用。
目前的API限制較多，Kubernetes未來會(huì)有功能更豐富的API，能支持以可擴(kuò)展的形式進(jìn)行GPU等硬件加速器資源的供給、調(diào)度和使用。
Kubernetes將能自動(dòng)確保使用GPU的應(yīng)用程序達(dá)到最佳性能。

12.3 Pod的垂直擴(kuò)縮容
Kubernetes在1.9版本中加入了對Pod的垂直擴(kuò)縮容（簡稱為VPA）支持，
這一功能使用CRD的方式為Pod定義垂直擴(kuò)縮容的規(guī)則，根據(jù)Pod的運(yùn)行行為來判斷Pod的資源需求，從而更好地為Pod提供調(diào)度支持。
該項(xiàng)目的地址為https://github.com/kubernetes/autoscaler，其中包含了三個(gè)不同的工具，分別是：
能夠在AWS、Azure和GCP上提供集群節(jié)點(diǎn)擴(kuò)縮容的ClusterAutoScaler，已經(jīng)進(jìn)入GA階段；
提供Pod垂直擴(kuò)縮容的Vertical Pod Autoscaler，目前處于Beta階段；
Addon Resizer，是Vertical Pod Autoscaler的簡化版，能夠根據(jù)節(jié)點(diǎn)數(shù)量修改Deployment資源請求，目前處于Beta階段。

12.3.1 前提條件
垂直擴(kuò)縮容目前的版本為0.4，需要在Kubernetes 1.11以上版本中運(yùn)行。
該組件所需的運(yùn)行指標(biāo)由Metrics Server提供，因此在安裝Autoscaler前要先啟動(dòng)Metrics Server。

12.3.2 安裝Vertical Pod Autoscaler
首先使用Git獲取Autoscaler的源碼：
# git clone https://github.com/kubernetes/autoscaler.git
下載結(jié)束之后，執(zhí)行如下腳本，啟動(dòng)VPA：
# autoscaler/vertical-pod-autoscaler/hack/vpa-up.sh
可以看到，在安裝過程中生成了常見的Deployment、Secret、Service及RBAC內(nèi)容，還生成了兩個(gè)CRD，接下來會(huì)用新生成的CRD設(shè)置Pod的垂直擴(kuò)縮容。

12.3.3 為Pod設(shè)置垂直擴(kuò)縮容
在下載的Git代碼中包含一個(gè)子目錄example，可以使用其中的redis.yaml來嘗試使用VPA功能。
查看其中的redis.yaml文件，可以看到VPA的定義：
# cat autoscaler/vertical-pod-autoscaler/examples/redis.yaml
...
該定義非常簡短：對名稱為redis-master的Deployment進(jìn)行自動(dòng)垂直擴(kuò)縮容。
在https://git.io/fhAeY頁面可以找到該對象的完整定義，除了包括targetRef，還包括如下內(nèi)容：
（1）UpdatePolicy：用于指定監(jiān)控資源需求時(shí)的操作策略。
UpdateMode：默認(rèn)值為Auto。
Off：僅監(jiān)控資源狀況并提出建議，不進(jìn)行自動(dòng)修改。
Initial：在創(chuàng)建Pod時(shí)為Pod指派資源。
Recreate：在創(chuàng)建Pod時(shí)為Pod指派資源，并且在Pod的生命周期中可以通過刪除、重建Pod，將其資源數(shù)量更新為Pod申請的數(shù)量。
Auto：目前相當(dāng)于Recreate。
（2）ResourcePolicy：用于指定資源計(jì)算的策略，如果這一字段被省略，則將會(huì)為在targetRef中指定的控制器生成的所有Pod的容器進(jìn)行資源測算并根據(jù)UpdatePolicy的定義進(jìn)行更新。
ContainerName：容器名稱，如果為“*”，則對所有沒有設(shè)置資源策略的容器都生效。
Mode：為Auto時(shí)，表示為指定容器啟用VPA；為Off時(shí)，表示關(guān)閉指定容器的VPA。
MinAllowed：最小允許的資源值。
MaxAllowed：最大允許的資源值。
通過kubectl將測試文件提交到集群上運(yùn)行：
# kubectl apply -f autoscaler/vertical-pod-autoscaler/examples/redis.yaml
在創(chuàng)建結(jié)束之后，VPA會(huì)監(jiān)控資源狀況，大約5分鐘后重新獲取VPA對象的內(nèi)容：
# kubectl describe vpa redis-vpa
可以看到，在VPA對象中已經(jīng)有了新的推薦設(shè)置。
接下來查看Redis的Pod資源請求：
# kubectl describe pod redis-master-xxx
不難看出，Pod的資源狀況和Deployment中的原始定義已經(jīng)不同，和VPA中的推薦數(shù)量一致。

12.3.4 注意事項(xiàng)
注意事項(xiàng)如下：
VPA對Pod的更新會(huì)造成Pod的重新創(chuàng)建和調(diào)度。
對于不受控制器支配的Pod，VPA僅能在其創(chuàng)建時(shí)提供支持。
VPA的準(zhǔn)入控制器是一個(gè)Webhook，可能會(huì)和其他同類Webhook存在沖突，從而導(dǎo)致無法正確執(zhí)行。
VPA無法和使用CPU、內(nèi)存指標(biāo)的HPA共用。
VPA能夠識別多數(shù)內(nèi)存不足的問題，但并非全部。
尚未在大規(guī)模集群上測試VPA的性能。
如果多個(gè)VPA對象都匹配同一個(gè)Pod，則會(huì)造成不可預(yù)知的后果。
VPA目前不會(huì)修改limits字段的內(nèi)容。

12.4 Kubernetes的演進(jìn)路線和開發(fā)模式
Kubernetes將每個(gè)版本的待開發(fā)功能由SIG-Release小組進(jìn)行文檔管理和發(fā)布，
網(wǎng)址為https://github.com/kubernetes/sig-release，可以跟蹤每個(gè)大版本的功能列表，如圖12.9所示。
以release-1.14為例，從release-1.14.md文檔中可以查看這個(gè)版本的詳細(xì)信息，如圖12.10所示。
版本發(fā)布的詳細(xì)時(shí)間表如圖12.11所示。
單擊頁面鏈接“Enhancements Tracking Sheet”，可以查看該版本所包含的全部功能列表，按開發(fā)階段分為Alpha、Beta和Stable三個(gè)類別，可以直觀地看到各功能模塊的實(shí)現(xiàn)階段。
每個(gè)功能都有HTTP鏈接，可以單擊該鏈接跳轉(zhuǎn)至GitHub中的相關(guān)issue頁面，進(jìn)一步查看該功能的詳細(xì)信息。
在WIP Features by Release表中還可以看到各功能特性在Kubernetes各版本中的開發(fā)過程，如圖12.12所示。
每個(gè)版本中的每個(gè)Feature都由一個(gè)特別興趣小組（Special Interest Group，SIG）負(fù)責(zé)開發(fā)和維護(hù)，
各SIG小組的介紹可以在https://github.com/kubernetes/community/blob/master/sig-list.md找到，如圖12.13所示。
目前已經(jīng)成立的SIG小組有30個(gè)，涵蓋了安全、自動(dòng)擴(kuò)縮容、大數(shù)據(jù)、AWS云、文檔、網(wǎng)絡(luò)、存儲、調(diào)度、UI、Windows容器等方方面面，為完善Kubernetes的功能群策群力，共同開發(fā)。
有興趣、有能力的讀者可以申請加入感興趣的SIG小組，并可以通過Slack聊天頻道與來自世界各地的開發(fā)組成員開展技術(shù)探討和解決問題。
同時(shí)，可以參加SIG小組的周例會(huì)，共同參與一個(gè)功能模塊的開發(fā)工作。