Deployments介紹
Deployment（簡寫為deploy）是Kubernetes控制器的一種高級別實現，它構建於ReplicaSet控制器之上，它可用於為Pod和ReplicaSet資源提供聲明式更新。相比較來說，Pod和ReplicaSet是較低級別的資源，以至於很少被直接使用。Deployment控制器資源的主要職責同樣是為了保證Pod資源健康運行，其大部分功能通過調用ReplicaSet控制器實現，並增添了部分特性。
▪事件和狀態查看：必要時可以查看Deployment對象的更新進度和狀態。
▪版本記錄：將Deployment對象的更新操作予以保存，以便后續可能執行的回滾操作使用。
▪回滾：更新操作啟動后的任一時刻（包括完成后）發現問題，都可以通過回滾機制將應用返回到前一個或由用戶指定的歷史記錄中的版本。
▪暫停和啟動：更新過程中能夠隨時暫停和繼續完成后面的步驟。
▪多種更新方案：一是Recreate，即重建更新機制，單批次更新所有Pod對象；另一個是RollingUpdate，即滾動更新機制，多批次逐步替換舊有的Pod至新的版本。Deployment資源的擴縮容機制與ReplicaSet相同，修改.spec.replicas即能實時觸發其規模變動操作。另外，kubectl scale是專用於擴展特定控制器類型的應用規模的命令，包括Deployment、ReplicaSet和StatefulSet等。創建 Deployment
depoly-demoapp-v10.yaml
apiVersion: v1
kind: Namespace
metadata:
name: demoapp
---
apiVersion: v1
kind: Service
metadata:
labels:
app: demoappv10
name: demoappv10
namespace: demoapp
spec:
ports:
- name: http-8080
port: 8080
protocol: TCP
targetPort: 8080
selector:
app: demoapp
version: v1.0
type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app: demoappv10
version: v1.0
name: demoappv10
namespace: demoapp
spec:
replicas: 2
selector:
matchLabels:
app: demoapp
strategy: {}
template:
metadata:
creationTimestamp: null
labels:
app: demoapp
version: v1.0
spec:
containers:
- image: ikubernetes/demoapp:v1.0
name: demoapp
env:
- name: PORT
value: "8080"
resources: {}創建deployment資源
# kubectl apply -f depoly-demoapp-v10.yamlnamespace/demoapp created
deployment.apps/demoappv10 created訪問服務
# curl `kubectl get svc/demoappv10 -n demoapp -o jsonpath="{.spec.clusterIP}"`:8080iKubernetes demoapp v1.0 !! ClientIP: 172.20.151.128, ServerName: demoappv10-69f6cf9477-v9m6g, ServerIP: 172.20.154.216!查看deployment資源
# kubectl get deploy -n demoappNAME READY UP-TO-DATE AVAILABLE AGE
demoappv10 2/2 2 2 104s在檢查集群中的 Deployment 時，所顯示的字段有：
NAME 列出了名字空間中 Deployment 的名稱。
READY 顯示應用程序的可用的“副本”數。顯示的模式是“就緒個數/期望個數”。
UP-TO-DATE 顯示為了達到期望狀態已經更新的副本數。
AVAILABLE 顯示應用可供用戶使用的副本數。
AGE 顯示應用程序運行的時間。查看 Deployment 滾動更新狀態
# kubectl rollout status deploy/demoappv10 -n demoappdeployment "demoappv10" successfully rolled out查看ReplicaSet
# kubectl get rs -n demoappNAME DESIRED CURRENT READY AGE
demoappv10-78b6586d58 2 2 2 4m59sReplicaSet 輸出中包含以下字段：
NAME 列出名字空間中 ReplicaSet 的名稱；
DESIRED 顯示應用的期望副本個數，即在創建 Deployment 時所定義的值。 此為期望狀態；
CURRENT 顯示當前運行狀態中的副本個數；
READY 顯示應用中有多少副本可以為用戶提供服務；
AGE 顯示應用已經運行的時間長度。注意 ReplicaSet 的名稱格式始終為 [Deployment 名稱]-[哈希]。 該名稱將成為所創建的 Pod 的命名基礎。 其中的哈希字符串與 ReplicaSet 上的 pod-template-hash 標簽一致。查看pod 標簽
# kubectl get pods -n demoapp --show-labelsNAME READY STATUS RESTARTS AGE LABELS
demoappv10-78b6586d58-64hq4 1/1 Running 0 6m48s app=demoapp,pod-template-hash=78b6586d58,version=v1.0
demoappv10-78b6586d58-f72jw 1/1 Running 0 6m48s app=demoapp,pod-template-hash=78b6586d58,version=v1.0查看Deployment 修訂歷史
# kubectl rollout history deployment/demoappv10 -n demoappdeployment.apps/demoappv10
REVISION CHANGE-CAUSE
1 <none>Deployment 添加注解
# kubectl annotate deployment/demoappv10 kubernetes.io/change-cause="kubectl apply -f depoly-demoapp-v10.yaml" -n demoappdeployment.apps/demoappv10 annotated確認Deployment 添加注解
# kubectl rollout history deployment/demoappv10 -n demoappdeployment.apps/demoappv10
REVISION CHANGE-CAUSE
1 kubectl apply -f depoly-demoapp-v10.yamlPod-template-hash 標簽
Deployment 控制器將 pod-template-hash 標簽添加到 Deployment 所創建或收留的每個 ReplicaSet 。
此標簽可確保 Deployment 的子 ReplicaSets 不重疊。 標簽是通過對 ReplicaSet 的 PodTemplate 進行哈希處理。 所生成的哈希值被添加到 ReplicaSet 選擇算符、Pod 模板標簽，並存在於在 ReplicaSet 可能擁有的任何現有 Pod 中。
不要更改此標簽。Deployment 更新策略
Deployment控制器支持滾動更新（rolling updates）和重新創建（recreate）兩種更新策略，默認使用滾動更新策略。重建式更新類同前文中ReplicaSet的第一種更新方式，即先刪除現存的Pod對象，而后由控制器基於新模板重新創建出新版本資源對象。通常，只有當應用的新舊版本不兼容（例如依賴的后端數據庫的格式不同且無法兼容）時才會使用recreate策略。但重建策略會導致應用在更新期間不可用，因而建議用戶使用藍綠部署的方式進行，除非系統資源不足以支撐藍綠部署的實現。Deployment控制器的滾動更新操作並非在同一個ReplicaSet控制器對象下刪除並創建Pod資源，而是將它們分置於兩個不同的控制器之下，當前ReplicaSet對象的Pod副本數量不斷減少的同時，新ReplicaSet對象的Pod對象數量不斷增加，直到現有ReplicaSet對象的Pod副本數為0，而新控制器的副本數量變得完全符合期望值，如圖8-9所示。新舊版本之間區別彼此Pod對象的關鍵標簽為pod-templatehash。多批次更新模式的默認間隔標准是前一批次的所有Pod對象均已就緒，方可啟動后一批次的更新。而Deployment還提供了兩個配置滾動更新批次的字段，以允許用戶自定義更新過程的滾動速率，這兩個字段分別用於定義滾動更新期間的Pod總數可向上或向下偏離期望值的幅度。
spec.strategy.rollingUpdate.maxSurge：指定升級期間存在的總Pod對象數量最多可超出期望值的個數，其值可以是0或正整數，也可以是相對於期望值的一個百分比；例如，如果期望值為10，maxSurge屬性值為2，則表示Pod對象總數至多不能超過12個。
spec.strategy.rollingUpdate.maxUnavailable：升級期間正常可用的Pod副本數（包括新舊版本）最多不能低於期望值的個數，其值可以是0或正整數，也可以是相對於期望值的一個百分比；默認值為1，這意味着如果期望值是10，則升級期間至少要有9個Pod對象處於正常提供服務的狀態。
maxSurge和maxUnavailable屬性的值不可同時為0，否則Pod對象的副本數量在符合用戶期望的數量后無法做出合理變動以進行滾動更新操作。Deployment還支持使用spec.minReadySeconds字段來控制滾動更新的速度，其默認值為0，表示新建的Pod對象一旦“就緒”將立即被視作可用，隨后即可開始下一輪更新過程。而為該字段指定一個正整數值能夠定義新建的Pod對象至少要成功運行多久才會被視作可用，即就緒之后還要等待minReadySeconds指定的時長才能開始下一批次的更新。在一個批次內新建的所有Pod就緒后但轉為可用狀態前，更新操作會被阻塞，並且任何一個Pod就緒探測失敗，都會導致滾動更新被終止。因此，為minReadySeconds賦予一個合理的正整數值，不僅能夠減緩滾動更新的速度，還能夠讓Deployment提前發現一部分程序Bug導致的升級故障。Deployment可保留一部分滾動更新歷史（修訂記錄）中舊版本的ReplicaSet對象。Deployment資源可保存的歷史版本數量由spec.revisionHistoryLimit屬性進行定義。為了保存升級歷史，需要在創建Deployment對象時為命令使用--record選項。 新版本已廢棄。盡管滾動更新以節約系統資源著稱，但它也存在着一些劣勢。直接改動現有環境，會為系統引入不確定性風險，而且一旦在更新過程中遇到問題，回滾操作的過程會較為緩慢。有鑒於此，金絲雀部署可能是較為理想的實現方式。當然，如果不考慮系統資源的可用性，那么傳統的藍綠部署將是更好的選擇。策略
先增新，后減舊：將maxSurge設定為小於等於期望值的正整數或相對於期望值的一個百分比，而maxUnavailable的值為0。
先減舊，后增新：將maxUnavailable設定為小於等於期望值的正整數或相對於期望值的一個百分比，而maxSurge的值為0。
同時增減（少減多增）：將maxSurge和maxUnavailabe字段的值同時設定為小於等於期望值的正整數或相對於期望值的一個百分比，二者可以使用不同值。Deployment默認為滾動更新設置了同時增減的策略，增減的幅度為期望值的25%，它通過兩個批次的創建和3個批次的刪除即能完成整個應用的更新，若Pod對象的整體副本數小於4的話，就只能按一次1個Pod對象的方式進行。擴縮容 Deployment
手動擴縮容
# kubectl scale deployment/demoappv10 --replicas=10 -n demoapp自動擴縮容
# kubectl autoscale deployment/demoappv10 --min=10 --max=15 --cpu-percent=80 -n demoapp可以為 Deployment 設置自動縮放器，並基於現有 Pod 的 CPU 利用率選擇要運行的 Pod 個數下限和上限暫停Deployment 的上線過程
在你更新一個 Deployment 的時候，或者計划更新它的時候， 你可以在觸發一個或多個更新之前暫停 Deployment 的上線過程。 當你准備應用這些變更時，你可以重新恢復 Deployment 上線過程。 這樣做使得你能夠在暫停和恢復執行之間應用多個修補程序，而不會觸發不必要的上線操作。暫停 Deployment 上線之前的初始狀態將繼續發揮作用，但新的更新在 Deployment 上線被暫停期間不會產生任何效果。暫停上線
# kubectl rollout pause deployment/demoappv10 -n demoapp更新 Deployment
# kubectl set resources deployment/demoappv10 -c=nginx --limits=cpu=200m,memory=512Mi -n demoapp恢復 Deployment 的上線過程
恢復 Deployment 上線並觀察新的 ReplicaSet 的創建過程，其中包含了所應用的所有更新# kubectl rollout resume deployment/demoappv10 -n demoappDeployment 狀態
Deployment 的生命周期中會有許多狀態。上線新的 ReplicaSet 期間可能處於 Progressing（進行中），可能是 Complete（已完成），也可能是 Failed（失敗）以至於無法繼續進行。進行中的 Deployment
執行下面的任務期間，Kubernetes 標記 Deployment 為進行中（Progressing）_：
Deployment 創建新的 ReplicaSet
Deployment 正在為其最新的 ReplicaSet 擴容
Deployment 正在為其舊有的 ReplicaSet(s) 縮容
新的 Pod 已經就緒或者可用（就緒至少持續了 MinReadySeconds 秒）。當上線過程進入“Progressing”狀態時，Deployment 控制器會向 Deployment 的 .status.conditions 中添加包含下面屬性的狀況條目：
type: Progressing
status: "True"
reason: NewReplicaSetCreated | reason: FoundNewReplicaSet | reason: ReplicaSetUpdated你可以使用 kubectl rollout status 監視 Deployment 的進度。完成的 Deployment
當 Deployment 具有以下特征時，Kubernetes 將其標記為完成（Complete）;
與 Deployment 關聯的所有副本都已更新到指定的最新版本，這意味着之前請求的所有更新都已完成。
與 Deployment 關聯的所有副本都可用。
未運行 Deployment 的舊副本。當上線過程進入“Complete”狀態時，Deployment 控制器會向 Deployment 的 .status.conditions 中添加包含下面屬性的狀況條目：
type: Progressing
status: "True"
reason: NewReplicaSetAvailable這一 Progressing 狀況的狀態值會持續為 "True"，直至新的上線動作被觸發。 即使副本的可用狀態發生變化（進而影響 Available 狀況），Progressing 狀況的值也不會變化。
你可以使用 kubectl rollout status 檢查 Deployment 是否已完成。 如果上線成功完成，kubectl rollout status 返回退出代碼 0。失敗的 Deployment
你的 Deployment 可能會在嘗試部署其最新的 ReplicaSet 受挫，一直處於未完成狀態。 造成此情況一些可能因素如下：
配額（Quota）不足
就緒探測（Readiness Probe）失敗
鏡像拉取錯誤
權限不足
限制范圍（Limit Ranges）問題
應用程序運行時的配置錯誤檢測此狀況的一種方法是在 Deployment 規約中指定截止時間參數： （.spec.progressDeadlineSeconds）。 .spec.progressDeadlineSeconds 給出的是一個秒數值，Deployment 控制器在（通過 Deployment 狀態） 標示 Deployment 進展停滯之前，需要等待所給的時長。以下 kubectl 命令設置規約中的 progressDeadlineSeconds，從而告知控制器 在 10 分鍾后報告 Deployment 的上線沒有進展：# kubectl patch deployment/demoappv10 -p '{"spec":{"progressDeadlineSeconds":600}}' -n demoapp超過截止時間后，Deployment 控制器將添加具有以下屬性的 Deployment 狀況到 Deployment 的 .status.conditions 中：
type: Progressing
status: "False"
reason: ProgressDeadlineExceeded
這一狀況也可能會比較早地失敗，因而其狀態值被設置為 "False"， 其原因為 ReplicaSetCreateError。 一旦 Deployment 上線完成，就不再考慮其期限。除了報告 Reason=ProgressDeadlineExceeded 狀態之外，Kubernetes 對已停止的 Deployment 不執行任何操作。更高級別的編排器可以利用這一設計並相應地采取行動。 例如，將 Deployment 回滾到其以前的版本。如果你暫停了某個 Deployment 上線，Kubernetes 不再根據指定的截止時間檢查 Deployment 上線的進展。 你可以在上線過程中間安全地暫停 Deployment 再恢復其執行，這樣做不會導致超出最后時限的問題。對失敗 Deployment 的操作
可應用於已完成的 Deployment 的所有操作也適用於失敗的 Deployment。 你可以對其執行擴縮容、回滾到以前的修訂版本等操作，或者在需要對 Deployment 的 Pod 模板應用多項調整時，將 Deployment 暫停。清理策略
你可以在 Deployment 中設置 .spec.revisionHistoryLimit 字段以指定保留此 Deployment 的多少個舊有 ReplicaSet。其余的 ReplicaSet 將在后台被垃圾回收。 默認情況下，此值為 10。顯式將此字段設置為 0 將導致 Deployment 的所有歷史記錄被清空，因此 Deployment 將無法回滾。金絲雀發布
Deployment資源允許用戶控制更新過程中的滾動節奏，例如“暫停”或“繼續”更新操作，尤其是借助於前文講到的maxSurge和maxUnavailable屬性還能實現更為精巧的過程控制。例如，在第一批新的Pod資源創建完成后立即暫停更新過程，此時，僅有一小部分新版本的應用存在，主體部分還是舊的版本。然后，通過應用層路由機制根據請求特征精心篩選出小部分用戶的請求路由至新版本的Pod應用，並持續觀察其是否能穩定地按期望方式運行。默認，Service只會隨機或輪詢地將用戶請求分發給所有的Pod對象。確定沒有問題后再繼續進行完余下的所有Pod資源的滾動更新，否則便立即回滾至第一步更新操作。這便是所謂的金絲雀部署。為了盡可能降低對現有系統及其容量的影響，基於Deployment的金絲雀發布過程通常建議采用“先增后減且可用Pod對象總數不低於期望值”的方式進行。首次添加的Pod對象數量取決於其接入的第一批請求的規則及單個Pod的承載能力，視具體需求而定。Deployment資源規范
Deployment是標准的API資源類型，它以ReplicaSet資源為基礎資源進行應用編排，並能夠自動實現策略式滾動更新或單批次重建式更新，因而它的spec字段中嵌套使用的字段包含了ReplicaSet控制器支持的所有字段，而Deployment也正是利用這些信息完成其二級資源ReplicaSet對象的創建。另外，Deployment還支持幾個專用於定義部署及相關策略的字段，具體使用說明如下。apiVersion: apps/v1 # API群組及版本
kind: Deployment # 資源類型特有標識
metadata:
name <string> # 資源名稱，在作用域中要唯一
namespace <string> # 名稱空間, Deployment隸屬名稱空間級別
labels <map[string]string> # 該資源對象的標簽，鍵值型數據，常被用作標簽選擇器的挑選條件
annotations <map[string]string> # 非標識目的的元數據，鍵值格式，但不可作為標簽選擇器的挑選條件，其意義或解釋方式一般由客戶端自行定義。
spec:
minReadySeconds <integer> # Pod就緒后多少秒內任一容器無崩潰方可視為“就緒”
replicas <integer> # 期望的Pod副本數，默認為1
selector <object> # 標簽選擇器，必須匹配template字段中Pod模板的標簽
matchExpressions <[]Object> # 基於表達式指定的標簽選擇器列表，每個選擇器形如{key: KEY_NAME, operator: OPERATOR, value: [VALUE1,VALUE2,...]},選擇器列表間為 邏輯與關系；使用In或NotIn操作符時，其value必須為非空的字符串列表，而使用Exists或DostNotExist時，其value必須為空。
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: Exists, values:}
matchLabels <map[string]string> # 定義匹配的標簽，必須要設置，直接給定鍵值對指定標簽選擇器
app: nginx
template <object> # Pod模板對象
metadata <Object> # 定義模板元數據
labels <map[string]string> #定義模板label，Deployment.spec.template.metadata.labels
spec <Object> # 定義pod信息
volumes <[]Object> # 定義一個存儲卷
name <string> # 存儲卷名稱標識，僅可使用DNS標簽格式的字符，在當前Pod中必須唯一
containers <[]Object> -required- # 定義pod中容器列表，可以多個至少一個
name <string> -required- # 容器名稱
image <string> # 鏡像地址
command <[]string> # 容器啟動執行的命令或腳本
args <[]string> # 參數傳遞，它們將覆蓋鏡像中默認定義的參數。
env <[]Object> # 配置環境變量
name <string> -required- # 變量名稱。必須要用引號引起來
value <string> # 當前變量的值
valueFrom <Object> # 環境變量值的引用源，例如當前Pod資源的名稱、名稱空間、標簽等，不能與非空值的value字段同時使用，即環境變量的值要么源於value字段，要么源於valueFrom字段，二者不可同時提供數據。
fieldRef <Object> # 當前Pod資源的指定字段，目前支持使用的字段包括metadata.name、metadata.namespace、metadata.labels、metadata.annotations、spec.nodeName、spec.serviceAccountName、status.hostIP和status.podIP等。
configMapKeyRef <Object> # ConfigMap對象中的特定Key。
secretKeyRef <Object> # Secret對象中的特定Key。
resourceFieldRef <Object> # 當前容器的特定系統資源的最小值（配額）或最大值（限額），目前支持的引用包括limits.cpu、limits.memory、limits.ephemeral-storage、requests.cpu、requests.memory和requests.ephemeral-storage。
envFrom <[]Object> # 直接將ConfigMap資源中的所有鍵值一次性地導入。
prefix <string> # 為引用的ConfigMap對象中的所有變量添加一個前綴名
configMapRef # 定義引用的ConfigMap對象
name <string> # ConfigMap對象的名稱
optional <boolean> # 該ConfigMap對象是否為可選
secretRef <Object> # Secret對象中的特定Key。
name <string> # 引用的Secret對象名稱
key <string> # 引用的Secret對象上的鍵，其值將傳遞給環境變量
optional <boolean> # 是否為可選引用
imagePullPolicy <string> # 拉取鏡像策略有三種：Always(每次創建都會拉取鏡像),IfNotPresent(優先使用本地鏡像)，none(從不下載鏡像)
ports <[]Object> # 定義容器端口列表
containerPort <integer> -required- # 定義一個端口
name <string> # 端口名稱
protocol <string> # 端口協議 SCTP、TCP、UDP
resources <Object> # #對資源的請求設置和限制設置
limits <map[string]string> # 資源限制設置，上限
requests <map[string]string> # 資源請求的設置
livenessProbe <Object> # 存活探針
exec <Object> # 命令式探針
httpGet <Object> # http GET類型的探針
tcpSocket <Object> # tcp Socket類型的探針
initialDelaySeconds <integer> # 發起初次探測請求的延后時長
periodSeconds <integer> # 請求周期
timeoutSeconds <integer> # 超時時長
successThreshold <integer> # 成功閾值
failureThreshold <integer> # 失敗閾值
volumeMounts <[]Object> #
volumeDevices <[]Object> #
workingDir <string> #
revisionHistoryLimit <integer> # 滾動更新歷史記錄數量，默認為10
strategy <Object> # 滾動更新策略
type <string> # 滾動更新類型，可用值有Recreate和Rollingupdate
rollingUpdate <Object> # 滾動更新參數，專用於RollingUpdate類型
maxSurge <string> # 更新期間可比期望的Pod數量多出的數量或比例，默認值為 25%。指定升級期間存在的總Pod對象數量最多可超出期望值的個數，其值可以是0或正整數，也可以是相對於期望值的一個百分比；例如，如果期望值為10，maxSurge屬性值為2，則表示Pod對象總數至多不能超過12個。
maxUnavailable <string> # 更新期間可比期望的Pod數量缺少的數量或比例，默認值為 25%。升級期間正常可用的Pod副本數（包括新舊版本）最多不能低於期望值的個數，其值可以是0或正整數，也可以是相對於期望值的一個百分比；默認值為1，這意味着如果期望值是10，則升級期間至少要有9個Pod對象處於正常提供服務的狀態。
progressDeadlineSeconds <integer> # 滾動更新故障超時時長，默認為600秒
paused <boolean> # 是否暫停部署過程示例
kind: Deployment #類型，是deployment控制器，kubectl explain Deployment
apiVersion: apps/v1 #API版本，# kubectl explain Deployment.apiVersion
metadata: #pod的元數據信息，kubectl explain Deployment.metadata
labels: #自定義pod的標簽，# kubectl explain Deployment.metadata.labels
app: wgs-nginx-deployment-label #標簽名稱為app值為wgs-nginx-deployment-label，后面會用到此標簽
name: wgs-nginx-deployment #pod的名稱
namespace: wgs #pod的namespace，默認是defaule
spec: #定義deployment中容器的詳細信息，kubectl explain Deployment.spec
replicas: 1 #創建出的pod的副本數，即多少個pod，默認值為1
selector: #定義標簽選擇器
matchLabels: #定義匹配的標簽，必須要設置
app: wgs-nginx-selector #匹配的目標標簽，
template: #定義模板，必須定義，模板是起到描述要創建的pod的作用
metadata: #定義模板元數據
labels: #定義模板label，Deployment.spec.template.metadata.labels
app: wgs-nginx-selector #定義標簽，等於Deployment.spec.selector.matchLabels
spec: #定義pod信息
containers: #定義pod中容器列表，可以多個至少一個，pod不能動態增減容器
- name: wgs-nginx-container #容器名稱
image: nginx:1.16.1 #鏡像地址
#command: ["/apps/tomcat/bin/run_tomcat.sh"] #容器啟動執行的命令或腳本
#imagePullPolicy: IfNotPresent
imagePullPolicy: Always #拉取鏡像策略有三種：Always(每次創建都會拉取鏡像),IfNotPresent(優先使用本地鏡像)，none(從不下載鏡像)
ports: #定義容器端口列表
- containerPort: 80 #定義一個端口
protocol: TCP #端口協議
name: http #端口名稱
- containerPort: 443 #定義一個端口
protocol: TCP #端口協議
name: https #端口名稱
env: #配置環境變量
- name: "password" #變量名稱。必須要用引號引起來
value: "123456" #當前變量的值
- name: "age" #另一個變量名稱
value: "18" #另一個變量的值
resources: #對資源的請求設置和限制設置
limits: #資源限制設置，上限
cpu: 500m #cpu的限制，單位為core數，可以寫0.5或者500m等CPU壓縮值
memory: 512Mi #內存限制，單位可以為Mib/Gib，將用於docker run --memory參數
requests: #資源請求的設置
cpu: 200m #cpu請求數，容器啟動的初始可用數量,可以寫0.5或者500m等CPU壓縮值
memory: 256Mi #內存請求大小，容器啟動的初始可用數量，用於調度pod時候使用
nodeSelector:
group: web參考文檔
https://kubernetes.io/zh-cn/docs/concepts/workloads/controllers/deployment/