1.獲取資源
kubectlget
2.查看資源詳情
kubectl describe <reousrce_type> <reousrce_name>
3.kubernetes設(shè)計Pod中為何要有pause根容器
Pause作為Pod的根容器，可以代表整個容器組的狀態(tài)
Pod里的多個業(yè)務容器共享Pause容器的IP，共享Pause容器掛接的Volume，簡化了業(yè)務容器之間的通信問題，也解決了它們之間文件共享問題
4.修改RC（Replication Controller）的副本數(shù)量來實現(xiàn)Pod的動態(tài)縮放
# 維持三個副本kubectl scale rc --replicas=3
5.創(chuàng)建Horizontal Pod Autoscaler
# 自動進行副本數(shù)量管理，當cpu占用大于90%，pod副本數(shù)量為1~10kubectl autoscale deployment --cpu-percent=90--min=1--max=10
6.StatefulSet
管理有狀態(tài)服務，如mysql集群、kafka集群、zookeeper集群等
StatefulSet可以看作Deployment/RC的變種
如果StatefulSet名稱為kafka，那么第一個Pod叫kafka-0，第二個叫kafka-1，以此類推
7.查看資源yaml
kubectlget -o=yaml
8.刪除資源
# 刪除所有Podkubernetes delete pods--all# 刪除包含某個Label的Pod和Servicekubernetes delete pods,services-1name=
9.執(zhí)行容器的命令
# 執(zhí)行Pod的date命令，默認使用Pod中的第一個容器執(zhí)行kubectl exec <pod_name> date# 指定Pod中的某個容器執(zhí)行date命令kubectl exec -c date# 通過bash獲得Pod中某個容器的TTY，相當于登錄容器kubectl exec-ti-c /bin/bash
10.查看容器的日志
# 查看容器輸出到stdout的日志kubectl logs <pod_name># 跟蹤查看容器的日志，相當于tail -f命令的結(jié)果kubectl logs-f-c
11.創(chuàng)建資源對象
# 根據(jù)yaml配置文件一次性創(chuàng)建Service和RCkubectl create-fmy-service.yaml-fmy-rc.yaml# 根據(jù)<directory>目錄下的所有.yaml、.yml、.json文件的定義進行創(chuàng)建kubectl create-f
12.創(chuàng)建或更新資源對象
# 用法與kubectl create類似，但是create不能做更新kubectl apply-fapp.yaml
13.在線編輯運行中的資源對象
# 編輯運行中的deploymentkubectl edit deploy nginx
14.將Pod的開放端口映射到本地
# 將集群上Pod的80端口映射到本地的8888端口，瀏覽器可通過localhost:8888進行訪問kubectl port-forward--address0.0.0.0 \ pod/8888:80
15.在Pod和本地之間復制文件
# 把Pod上的/etc/fstab 復制到本地的/tmpkubernetescp:/etc/fstab /tmp
16.資源對象的標簽設(shè)置
# 為default namespace設(shè)置testing=truekubectl label namespaces defaulttesting=true
17.檢查可用的API資源類型列表
# 該命令經(jīng)常用于檢查特定類型的資源是否已經(jīng)定義，列出所有資源對象類型kubectl api-resources
18.通過kubectl創(chuàng)建ConfigMap
# 通過--from-file，指定文件，key就是文件名，value就是文件內(nèi)容kubectl create configmap --from-file=--from-file=# 通過--from-file參數(shù)從目錄中進行創(chuàng)建，該目錄下的每個配置文件名都被設(shè)置為key，文件的內(nèi)容被設(shè)置為valuekubectl create configmap --from-file=# 使用--from-literal，直接將指定key和valuekubectl create configmap --from-literal=key1=value1--from-literal=key2=value2
19.Pod掛載ConfigMap
# 環(huán)境變量方式（1）apiVersion: v1kind: Podmetadata:? name: cm-test-podspec:? containers:? ? - name: cm-test? ? ? image: busybox? ? ? command: ["/bin/sh","-c","env | grep APP"]? ? ? env:# 定義環(huán)境變量名稱? ? ? ? - name: APPLOGLEVEL# key"apploglevel"對應的值? ? ? ? ? valueFrom:? ? ? ? ? ? configMapKeyRef:# configmap的名稱? ? ? ? ? ? ? name: cm-appvars# key為apploglevel? ? ? ? ? ? ? key: apploglevel? ? ? ? - name: APPDATADIR? ? ? ? ? valueFrom:? ? ? ? ? ? configMapKeyRef:? ? ? ? ? ? ? name: cm-appvars? ? ? ? ? ? ? key: appdatadir? restartPolicy: Never? # 環(huán)境變量方式（2），k8s1.6開始，引入了一個新字段evnFrom，會自動將ConfigMap種所有定義的key-value生成為環(huán)境變量apiVersion: v1kind: Podmetadata:? name: cm-test-podspec:? containers:? ? - name: cm-test? ? ? image: busybox? ? ? command: ["/bin/sh","-c","env"]? ? ? envFrom:? ? ? ? - configMapRef:# configmap名稱? ? ? ? ? name: cm-appvars? restartPolicy: Never? # 通過volumeMount使用ConfigMapapiVersion: v1kind: Podmetadata:? name: cm-test-podspec:? containers:? ? - name: cm-test? ? ? image: busybox? ? ? ports:? ? ? - containerPort: 8087? ? ? volumeMounts:# 引用volume名稱? ? ? ? - name: vname# 掛載到容器內(nèi)的目錄? ? ? ? ? mountPath: /configfiles? volumes:# 定義volume名稱? ? - name: vname? ? ? configMap:# configmap名稱? ? ? ? name: cm-appvars
20.進入容器內(nèi)部
kubectl exec-tibash
21.在容器內(nèi)獲取Pod信息(Downward API)
可以獲取Pod名稱、命名空間、IP等；通過查看Pod日志獲取信息
# 環(huán)境變量方式：將Pod信息注入為環(huán)境變量# metadata.name：Pod的名稱，當Pod通過RC生成時，其名稱是RC隨機產(chǎn)生的唯一名稱。# status.podIP：Pod的IP地址，之所以叫作status.podIP而非metadata.IP，是因為Pod的IP屬于狀態(tài)數(shù)據(jù)，而非元數(shù)據(jù)。# metadata.namespace：Pod所在的NamespaceapiVersion: v1kind: Podmetadata:? name: dapi-test-podspec:? containers:? ? - name: dapi-test? ? ? image: busybox? ? ? command:? ? ? ? - /bin/sh? ? ? ? - '-c'? ? ? ? - env? ? ? env:? ? ? ? - name: MY_POD_NAME? ? ? ? ? valueFrom:? ? ? ? ? ? fieldRef:? ? ? ? ? ? ? fieldPath: metadata.name? ? ? ? - name: MY_POD_NAMESPACE? ? ? ? ? valueFrom:? ? ? ? ? ? fieldRef:? ? ? ? ? ? ? fieldPath: metadata.namespace? ? ? ? - name: MY_POD_IP? ? ? ? ? valueFrom:? ? ? ? ? ? fieldRef:? ? ? ? ? ? ? fieldPath: status.podIP# 環(huán)境變量方式：將容器資源信息注入為環(huán)境變量apiVersion: v1kind: Podmetadata:? name: dapi-test-podspec:? containers:? ? - name: dapi-test? ? ? image: busybox? ? ? imagePullPolicy: Never? ? ? ports:? ? ? ? - containerPort: 8087? ? ? command:? ? ? ? - /bin/sh? ? ? ? - '-c'? ? ? env:? ? ? ? - name: MY_CPU_REQUEST? ? ? ? ? valueFrom:? ? ? ? ? ? resourceFieldRef:? ? ? ? ? ? ? containerName: dapi-test? ? ? ? ? ? ? resource: requests.cpu? ? ? ? - name: MY_CPU_LIMIT? ? ? ? ? valueFrom:? ? ? ? ? ? resourceFieldRef:? ? ? ? ? ? ? containerName: dapi-test? ? ? ? ? ? ? resource: limits.cpu? ? ? ? - name: MY_MEM_LIMIT? ? ? ? ? valueFrom:? ? ? ? ? ? resourceFieldRef:? ? ? ? ? ? ? containerName: dapi-test? ? ? ? ? ? ? resource: limits.memory# 掛載volume方式---
22.Pod狀態(tài)
Pending：API Server已經(jīng)創(chuàng)建該Pod，但在Pod內(nèi)還有一個或多個容器的鏡像還沒被創(chuàng)建，包括正在下載鏡像的過程；
Running：Pod內(nèi)所有的容器均已創(chuàng)建，且至少有一個容器處于運行狀態(tài)，正在啟動狀態(tài)或正在重啟狀態(tài)；
Succeeded：Pod內(nèi)所有容器均已成功執(zhí)行后退出，且不會重啟；
Failed：Pod內(nèi)所有容器均已退出，但至少有一個容器退出為失敗狀態(tài)；
Unknow：由于某種原因無法獲取該Pod狀態(tài)，可能由于網(wǎng)絡通信不暢導致。
23.Pod重啟策略
Pod重啟策略（RestartPolicy）應用于Pod內(nèi)的所有容器，并且在Pod所處的Node上由kubelet進行判斷和重啟操作。當某個容器異常退出或健康檢查失敗時，kubelet將根據(jù)RestartPolicy的設(shè)置來進行相應的操作。
Pod的重啟策略包括 Always(默認)、OnFailure、Never：
Always：當容器失敗時，由kubelet自動重啟該容器；
OnFailure：當容器終止運行且退出碼不為0時，由kubelet重啟該容器；
Never：不論容器運行狀態(tài)如何，kubelet都不會重啟該容器。
kubelet重啟失效容器的時間間隔以sync-frequnecy乘以2n來計算，例如1、2、4、8倍等，最長延遲5min，并且在重啟后10min后重置該時間。
Pod重啟策略與控制方式：
RC和DaemonSet：必須設(shè)置為Always，需要保證該容器持續(xù)運行；
Job：OnFailure或Never，確保容器執(zhí)行完后不會再運行；
Kubelet：在Pod失效時自動重啟它，不論將RestartPolicy設(shè)置為什么值，也不會對Pod進行健康檢查。
24.Pod健康檢查和服務可用性檢查
Kubernetes對Pod的健康檢查可以通過兩類探針來檢查：LivenessProbe和ReadinessProbe。
LivenessProbe探針：用于判斷容器是否存活（Running狀態(tài)），如果LivenessProbe探測到容器不健康，則kubelet將殺死該容器，并根據(jù)容器的重啟策略進行相應的處理。如果一個容器不包括LivenessProbe探針，那么kubelet則會認為該容器的LivenessProbe探針返回的結(jié)果永遠是success。
ReadinessProbe探針：用于判斷容器是否可用（Ready狀態(tài)），達到Ready狀態(tài)的Pod才可以接收請求。對于背Service管理的Pod，Service與Pod Endpoint的關(guān)聯(lián)關(guān)系也將基于Pod受否Reday進行設(shè)置。如果在運行過程中Ready變?yōu)镕lase，則系統(tǒng)自動將其從Service的后端Endpoint列表中隔離出去，后續(xù)再把恢復到Ready狀態(tài)的Pod加入到Endpoint列表。這樣可以保證客戶端再訪問Service時不會被轉(zhuǎn)發(fā)到不可用的Pod實例上。
LivenessProbe和ReadinessProbe均可配置以下三種實現(xiàn)方式：
ExecAction：在容器內(nèi)執(zhí)行一個命令，如果該命令返回值為0，則表明容器健康。
# initialDelaySeconds 啟動容器后進行首次健康檢查的時間# timeoutSeconds 健康檢查發(fā)送請求后等待響應的超時時間# 通過執(zhí)行“cat /tmp/health”命令來判斷一個容器運行是否正常。在該Pod運行后，將在創(chuàng)建/tmp/health文件10s后刪除該文件，而LivenessProbe健康檢查的初始探測時間（initialDelaySeconds）為15s，探測結(jié)果是Fail，將導致kubelet殺掉該容器并重啟它apiVersion: v1kind: Podmetadata:? labels:? ? test: liveness? name: liveness-execspec:? containers:? ? - name: liveness? ? ? image: nginx? ? ? args:? ? ? ? - /bin/sh? ? ? ? - '-c'? ? ? ? - echo ok > /temp/healthy; sleep 10; rm -rf /temp/healthy; sleep 600? ? ? livenessProbe:? ? ? ? exec:? ? ? ? ? command:? ? ? ? ? ? - cat? ? ? ? ? ? - /temp/healthy? ? ? ? initialDelaySeconds: 15? ? ? ? timeoutSeconds: 1
TCPSocketAction：通過容器的IP地址和端口號執(zhí)行TCP檢查，如果能夠建立TCP連接，則表明容器健康。
apiVersion: v1kind: Podmetadata:? labels:? ? test: liveness? name: liveness-execspec:? containers:? ? - name: liveness? ? ? image: nginx? ? ? ports:? ? ? ? - containerPort: 80? ? ? livenessProbe:? ? ? ? tcpSocket:? ? ? ? ? port: 80? ? ? ? initialDelaySeconds: 15? ? ? ? timeoutSeconds: 1
HTTPGetAction：通過容器的IP地址、端口號及路徑調(diào)用HTTP GET方法，如果響應的狀態(tài)碼大于等于200小于400，認為容器健康。
apiVersion: v1kind: Podmetadata:? labels:? ? test: liveness? name: liveness-execspec:? containers:? ? - name: liveness? ? ? image: nginx? ? ? ports:? ? ? ? - containerPort: 80? ? ? livenessProbe:? ? ? ? httpGet:? ? ? ? ? path: /_status/heathz? ? ? ? ? port: 80? ? ? ? initialDelaySeconds: 15? ? ? ? timeoutSeconds: 1
Kubernetes的ReadinessProbe機制可能無法滿足某些復雜應用對容器內(nèi)服務可用狀態(tài)的判斷，1.11版本開始，引入Ready++，1.14版本達到穩(wěn)定版，稱其為Pod Readiness Gates。
25.Deployment全自動調(diào)度
# 會創(chuàng)建3個Nginx應用的PodapiVersion: apps/v1kind: Deploymentmetadata:? name: nginx-deploymentspec:? replicas: 3? selector:? ? matchLabels:? ? ? app: nginx-server? template:? ? metadata:? ? ? labels:? ? ? ? app: nginx-server? ? spec:? ? ? containers:? ? ? ? - name: nginx-deployment? ? ? ? ? image: nginx? ? ? ? ? ports:? ? ? ? ? ? - containerPort: 80
26.NodeSelector定向調(diào)度
Kubernetes Master上的Scheduler服務（kubernetes-scheduler進程）負責實現(xiàn)Pod的調(diào)度，整個調(diào)度過程通過執(zhí)行一系列復雜的算法，最終為每個Pod都計算出一個最佳的目標節(jié)點，這一過程是自動完成的，通常我們無法知道Pod最終會調(diào)度到哪個節(jié)點上。如果需要將Pod調(diào)度到指定節(jié)點上，可以通過Node標簽（Label）和Pod的nodeSelector屬性相匹配 。
# 1.通過kubectl label命令給目標Node打上標簽kubectl label nodes <node_name> <label_key>=<label_value># 2.在Pod的定義中加上nodeSelector的設(shè)置apiVersion: apps/v1kind: Deploymentmetadata:? name: nginx-deploymentspec:? replicas: 3? template:? ? spec:? ? ? containers:? ? ? ? - name: nginx? ? ? ? ? image: nginx? ? ? ? ? ports:? ? ? ? ? ? - containerPort: 80? ? ? nodeSelector:? ? ? ? <label_key>:
27.NodeAffinity親和性調(diào)度
NodeAffinity意為Node親和性的調(diào)度策略，適用于替換NodeSelector的全新調(diào)度策略。目前有兩種節(jié)點親和性表達。
RequiredDuringSchedulingIgnoredDuringExecution：必須滿足指定規(guī)則才可以調(diào)度Pod到Node上，相當于硬限制。
PreferredDuringSchedulingIgnoredDuringExecution：強調(diào)優(yōu)先滿 足指定規(guī)則，調(diào)度器會嘗試調(diào)度Pod到Node上，但并不強求，相當于軟 限制。多個優(yōu)先級規(guī)則還可以設(shè)置權(quán)重（weight）值，以定義執(zhí)行的先 后順序。
IgnoredDuringExecution的意思是：如果一個Pod所在的節(jié)點在Pod運 行期間標簽發(fā)生了變更，不再符合該Pod的節(jié)點親和性需求，則系統(tǒng)將 忽略Node上Label的變化，該Pod能繼續(xù)在該節(jié)點運行。
apiVersion: apps/v1kind: Deploymentmetadata:? name: nginx-deploymentspec:? replicas: 3? selector:? ? matchLabels:? ? ? app: nginx-server? template:? ? metadata:? ? ? labels:? ? ? ? app: nginx-server? ? spec:? ? ? affinity:? ? ? ? nodeAffinity:? ? ? ? ? requiredDuringSchedulingIgnoredDuringExecution:? ? ? ? ? ? nodeSelectorTerms:? ? ? ? ? ? ? - matchExpressions:# kubernetes預定義標簽? ? ? ? ? ? ? ? ? - key: beta.kubernetes.io/arch# 也有NotIn? ? ? ? ? ? ? ? ? ? operator: In? ? ? ? ? ? ? ? ? ? values:? ? ? ? ? ? ? ? ? ? ? - amd64? ? ? ? ? preferredDuringSchedulingIgnoredDuringExecution:? ? ? ? ? ? - weight: 1? ? ? ? ? ? ? preference:? ? ? ? ? ? ? ? matchExpressions:? ? ? ? ? ? ? ? ? - key: disk-type? ? ? ? ? ? ? ? ? ? operator: In? ? ? ? ? ? ? ? ? ? values:? ? ? ? ? ? ? ? ? ? ? - ssd? ? ? containers:? ? ? ? - name: nginx-deployment? ? ? ? ? image: nginx? ? ? ? ? ports:? ? ? ? ? ? - containerPort: 80
注意：如果同時定義了nodeSelector和nodeAffinity，那么必須都得到滿足；如果nodeAffinity指定了多個nodeSelectorTerms，那么滿足其中一個就可以；如果nodeSelectorTerms種有多個matchExpressions，則一個點滿足matchExpressions才能運行該Pod。
28.PodAffinity親和與互斥調(diào)度策略
PodAffinity根據(jù)節(jié)點上正在運行的Pod的標簽而不是節(jié)點的標簽進行判斷和調(diào)度，要求對節(jié)點和Pod兩個條件進行匹配。
例如：如果在具有標簽X的Node上運行了一個或多個符合條件Y的Pod，那么Pod應該運行在這個Node上；
這里X指的是一個集群中的節(jié)點、機架、區(qū)域等概念，通過Kubernetes內(nèi)置節(jié)點標簽中的key來進行聲明，這個key的名字為topologyKey，意為表達節(jié)點所屬的topology范圍。與節(jié)點不同的是，Pod是屬于某個命名空間的，所以條件Y表達的是一個或者多個命名空間中的一個Label Selecotr。
和節(jié)點親和性相同，Pod親和與互斥的條件設(shè)置也是 requiredDuringSchedulingIgnoredDuringExecution和
preferredDuringSchedulingIgnoredDuringExecution。Pod的親和性被定義于PodSpec的affinity字段下的podAffinity子字段中。Pod間的互斥性則被定義于同一層次的podAntiAffinity子字段中。
# 1.創(chuàng)建一個名為pod-flag的Pod，帶有標簽security=S1和app=nginx，使用該Pod作為其他Pod親和于互斥的目標PodapiVersion: v1kind: Podmetadata:? name: pod-flag? labels:? ? security: S1? ? app: nginxspec:? containers:? ? - name: nginx? ? ? image: nginx# 2.創(chuàng)建第二個pod來說明pod的親和性，親和標簽為security=S1，對應目標pod，創(chuàng)建后與pod-flag在同一nodeapiVersion: v1kind: Podmetadata:? name: pod-affinityspec:? affinity:? ? podAffinity:? ? ? requiredDuringSchedulingIgnoredDuringExecution:? ? ? ? - labelSelector:? ? ? ? ? ? matchExpressions:? ? ? ? ? ? ? - key: security? ? ? ? ? ? ? ? operator: In? ? ? ? ? ? ? ? values:? ? ? ? ? ? ? ? ? - S1? ? ? ? ? topologyKey: kubernetes.io/hostname? containers:? ? - name: with-pod-affinity? ? ? image: nginx# 3.pod的互斥性調(diào)度，該pod不與目標pod運行在同一節(jié)點# 要求該pod與security=S1的pod為同一個zone，但不與app=nginx的pod為同一個nodeapiVersion: v1kind: Podmetadata:? name: anti-affinityspec:? affinity:? ? podAffinity:? ? ? requiredDuringSchedulingIgnoredDuringExecution:? ? ? ? - labelSelector:? ? ? ? ? ? matchExpressions:? ? ? ? ? ? ? - key: security? ? ? ? ? ? ? ? operator: In? ? ? ? ? ? ? ? values:? ? ? ? ? ? ? ? ? - S1? ? ? ? ? topologyKey: failure-domain.beta.kubernetes.io/zone? ? podAntiAffinity:? ? ? requiredDuringSchedulingIgnoredDuringExecution:? ? ? ? - labelSelector:? ? ? ? ? matchExpressions:? ? ? ? ? ? ? - key: app? ? ? ? ? ? ? ? operator: In? ? ? ? ? ? ? ? values:? ? ? ? ? ? ? ? ? - nginx? ? ? ? ? topologyKey: kubernetes.io/hostname? containers:? ? - name: with-pod-affinity? ? ? image: nginx
29.Taints和Tolerations（污點和容忍）
Taint需要和Toleration配合使用，讓Pod避開那些不適合的Node。在Node上設(shè)置一個或多個Taint之后，除非Pod明確聲明能夠容忍這些污點，否則無法在這些Node上運行。Toleration是Pod的屬性，讓Pod能夠運行在標注了Taint的Node上。
# 污點值：NoSchedule(一定不被調(diào)度) PreferNoSchedule(盡量不被調(diào)度) NoExecute(不被調(diào)度，并且驅(qū)除已有pod)# 設(shè)置污點，key、value隨便寫kubectl taintnode =:污點值# 刪除污點kubectl taintnode :NoSchedule-# 這里的key可以不用指定valuekubectl taintnode :NoExecute-kubectl taintnode -kubectl taintnode :NoSchedule-
這個設(shè)置為node加上了一個Taint，該Taint的鍵為key，值為value，Taint的效果是NoSchedule。意味著除非Pod明確聲明可以容忍該Taint，否則不會被調(diào)度到該node上。
# 設(shè)置污點容忍，該Pod可以運行在污點為<key>的node上apiVersion: v1kind: Podmetadata:? name: taint-podspec:? tolerations:? ? - key: ? ? ? operator: Equal? ? ? value: value# operator: Exists 效果與以上相同? ? ? effect: NoSchedule? containers:? ? - name: nginx? ? ? image: nginx
Pod的Toleration聲明中的key和effect需要與Taint的設(shè)置保持一致，并且滿足以下條件之一：
operator的值是Exists（無需指定value）。
operator的值是Equal并且value相等。
如果不指定operator，則默認為Equal，另外，有如下兩個特例：
空的key配合Exists操作符能夠匹配所有的鍵和值。
空的effect匹配所有的effect。
effect取值：
NoSchedule：Pod沒有聲明容忍該taint，則調(diào)度器不會把該Pod調(diào)度到這一節(jié)點上。
PreferNoSchedult：調(diào)度器會嘗試不把該Pod調(diào)度到這個節(jié)點上（不強制）。
NoExecute：如果該Pod已經(jīng)在該節(jié)點運行，則會被驅(qū)逐；如果沒有，則調(diào)度器不會把該Pod調(diào)度到這一節(jié)點（ 可以設(shè)置驅(qū)逐時間，eg:tolerationSeconds =5000，在5s鐘后被驅(qū)逐）。
30.Pod Priority Preemption：Pod優(yōu)先級調(diào)度
當發(fā)生資源不足的情況時，系統(tǒng)可以選擇釋放一些不重要的負載（優(yōu)先級最低的），保障最重要的負載能夠有足夠的資源穩(wěn)定運行。
# 1.定義一個名為high-priority的優(yōu)先級類別，優(yōu)先級為1000000，數(shù)字越大，優(yōu)先級越大，超過一億的數(shù)字被系統(tǒng)保留，用于指派給系統(tǒng)組件apiVersion: scheduling.k8s.io/v1kind: PriorityClassmetadata:? name: high-priorityvalue: 1000000globalDefault: falsedescription: This priority class should be used for XYZ service pods only# 2.在Pod上引用上述Pod優(yōu)先級類別，priorityClassName: high-priorityapiVersion: v1kind: Podmetadata:? name: nginxspec:? containers:? ? - name: nginx? ? ? image: nginx? ? ? imagePullPolicy: IfNotPresent? priorityClassName: high-priority
31.DaemonSet：在每個Node上都調(diào)度一個Pod
DaemonSet的Pod調(diào)度策略與RC類似，除了使用系統(tǒng)內(nèi)置的算法在每個Node上進行調(diào)度，也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node范圍進行調(diào)度。
# 每個Node上都啟動一個fluentd容器，其中掛載了物理機的兩個目錄/var/log和/var/lib/docker/containersapiVersion: apps/v1kind: DaemonSetmetadata:? name: fluentd-cloud-logging? namespace: kube-system? labels:? ? k8s-app: fluentd-cloud-loggingspec:? selector:? ? matchLabels:? ? ? k8s-app: fluentd-cloud-logging? template:? ? metadata:? ? ? namespace: kube-system? ? ? labels:? ? ? ? k8s-app: fluentd-cloud-logging? ? spec:? ? ? containers:? ? ? ? - name: fluentd-cloud-logging? ? ? ? ? image: ist0ne/fluentd-elasticsearch? ? ? ? ? imagePullPolicy: IfNotPresent? ? ? ? ? resources:? ? ? ? ? ? limits:? ? ? ? ? ? ? cpu: 100m? ? ? ? ? ? ? memory: 200Mi? ? ? ? ? env:? ? ? ? ? ? - name: FLUENTD_ARGS? ? ? ? ? ? ? value: '-q'? ? ? ? ? volumeMounts:? ? ? ? ? ? - name: varlog? ? ? ? ? ? ? mountPath: /var/log? ? ? ? ? ? ? readOnly: false? ? ? ? ? ? - name: containers? ? ? ? ? ? ? mountPath: /var/lib/docker/containers? ? ? ? ? ? ? readOnly: false? ? ? volumes:? ? ? ? - name: containers? ? ? ? ? hostPath:? ? ? ? ? ? path: /var/lib/docker/containers? ? ? ? - name: varlog? ? ? ? ? hostPath:? ? ? ? ? ? path: /var/log
32.Init Container：初始化容器
用于在啟動應用容器之前啟動一個或多個初始化容器，完成應用容器所需的預置條件。init container與應用容器在本質(zhì)上是一樣的，但它們是僅運行一次就結(jié)束的任務。根據(jù)Pod的重啟策略（RestarPolicy），當init container執(zhí)行失敗，而且設(shè)置了RestartPolicy=Never時，Pod將會啟動失??；而設(shè)置RestartPolicy=Always時，Pod將會被系統(tǒng)重啟。
# initContainersapiVersion: v1kind: Podmetadata:? name: nginx-podspec:? initContainers:? ? - name: install? ? ? image: busybox? containers:? ? - name: nginx? ? ? image: nginx? ? ? ports:? ? ? ? - containerPort: 80
33.Deployment的升級與回滾
# 修改鏡像名稱kubectlsetimage deployment =:# 查看修改狀態(tài)kubectl rollout status deployment <deployment_name># 查看歷史版本kubectl rollout history deployment <deployment_name># 回滾到上個版本kubectl rollout undo deployment <deployment_name># 回滾到指定版本（3是查看歷史版本里面的版本號）kubectl rollout undo deployment --to-revision=3
34.暫停和恢復Deployment的部署操作，以完成復雜的修改
對于一次復雜的Deployment配置修改，為了避免頻繁觸發(fā)Deployment的更新操作，可以先暫停Deployment的更新操作，然后進行配置修改，再恢復Deployment，一次性觸發(fā)完整的更新操作，就可以避免不必要的Deployment更新操作。
# 暫停deployment更新操作kubectl rollout pause deployment <deployment_name># 修改deployment鏡像信息kubectlsetimage deployment =:# 查看修改deployment的歷史記錄，發(fā)現(xiàn)并沒有觸發(fā)新的deployment部署操作kubectl rollout history deploy <deploy_name># 再次更新容器資源限制kubectlsetresources deploy -c=--limits=cpu=200m,memory=512Mi# 最后，恢復這個deployment的部署操作kubectl rollout resume deploy <deploy_name>
注意：暫停狀態(tài)的Deployment無法回滾！
35.使用kubectl rolling-update命令完成RC的滾動升級
kubectl rolling-update --image=:
36.Pod手動擴容機制
# 將pod數(shù)量維持在10個kubectl scale deploy --replicas10
37.Pod自動擴容機制
Kubernetes從1.1版本開始，新增了名為Horizontal Pod AutoScaler（HPA）的控制器，用于實現(xiàn)基于CPU使用率進行自動Pod擴縮容的功能。HPA控制器基于Master的kube-controller-manager服務啟動參數(shù)--horizontal-pod-autoscaler-sync-period定義探測周期（默認為15s），周期性地檢測目標Pod的資源性能指標，并與HPA資源對象中的擴縮容條件進行對比，在滿足條件時對Pod副本數(shù)量進行調(diào)整。
HPA工作原理：
Kubernetes中的某個Metrics Server（Heapster或自定義Metrics Server）持續(xù)采集所有Pod副本的指標數(shù)據(jù)。HPA控制器通過Metrics Server的API（Heapster的API或聚合API）獲取這些數(shù)據(jù)，基于用戶定義的擴縮容規(guī)則進行計算，得到目標Pod副本數(shù)量。當目標Pod數(shù)量與當前副本數(shù)量不同時，HPA控制器就向Pod的副本控制器（Deployment、RC或ReplicaSet）發(fā)起scale操作，調(diào)整Pod的副本數(shù)量，完成擴縮容操作。
HPA配置詳解：
Kubernetes將HPA資源對象提供給用戶來定義擴縮容的規(guī)則。
HPA資源對象處于Kubernetes的API組“autoscaling”中，目前包括v1和v2兩個版本。其中autoscaling/v1僅支持CPU使用率的自動擴縮容，autoscaling/v2則用于支持基于任意指標的自動化擴縮容配置，包括基于資源使用率、Pod指標、其他指標等類型的指標數(shù)據(jù)。
（1）基于autoscaling/v1版本的HPA配置，僅可設(shè)置CPU使用率：
apiVersion: autoscaling/v1kind: HorizontalPodAutoscalermetadata:? name: php-apachespec:# 目標作用對象，可以是Deployment、ReplicationController或ReplicaSet? scaleTargetRef:? ? apiVersion: apps/v1? ? kind: Deployment? ? name: php-apache# Pod副本數(shù)量的最小值和最大值? minReplicas: 1? maxReplicas: 10# 期望每個Pod的CPU使用率都為50%，該使用率基于Pod設(shè)置的CPU Request值進行計算? targetCPUUtilizationPercentage: 50
注意：使用autoscaling/v1版本的HPA，需預先安裝Heapster組件或Metrics Server，用于采集CPU使用率。
（2）基于autoscaling/v2beta2的HPA配置：
apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata:? name: php-apachespec:# 目標作用對象，可以是Deployment、ReplicationController或ReplicaSet? scaleTargetRef:? ? apiVersion: apps/v1? ? kind: Deployment? ? name: php-apache# Pod副本數(shù)量的最小值和最大值? minReplicas: 1? maxReplicas: 10# 目標指標。在metrics中通過參數(shù)type定義指標類型；通過參數(shù)target定義響應的指標目標值，系統(tǒng)將在指標數(shù)據(jù)達到目標值觸發(fā)擴縮容操作? metrics:? ? - type: Resource? ? ? resource:? ? ? ? name: cpu? ? ? ? target:? ? ? ? ? type: Utilization? ? ? ? ? averageUtilization: 50
可以將metrics中的type（指標類型）設(shè)置為以下三種：
Resource：基于資源的指標值，可以設(shè)置的資源為CPU和內(nèi)存。
Pods：基于Pod的指標，系統(tǒng)將對全部Pod副本的指標值進行平均值計算。
Object：基于某種資源對象（如Ingress）的指標或應用系統(tǒng)的任意自定義指標。
Resource類型的指標可以設(shè)置CPU和內(nèi)存。對于CPU使用率，在target參數(shù)中設(shè)置averageutilization定義目標平均CPU使用率。對于內(nèi)存資源，在target參數(shù)中設(shè)置AverageValue定義目標平均內(nèi)存使用值。指標數(shù)據(jù)可以通過API“metrics.k8s.io”進行查詢，要求預先啟動Metrics Server服務。
Pods類型和Object類型都屬于自定義指標類型，指標的數(shù)據(jù)通常需要搭建自定義Metrics Server和監(jiān)控工具進行采集和處理。指標數(shù)據(jù)可以通過API“custom.metrics.k8s.io”進行查詢，要求預先自定義Metrics Server服務。
類型為Pods的指標數(shù)據(jù)來源于Pod對象本身，其target類型只能使用AverageValue。
# 其中Pod的指標名為packets-per-second，在目標指標平均值為1000時觸發(fā)擴縮容操作metircs:? - type: Pods? ? pods:? ? ? metric:? ? ? ? name: packets-per-second? ? ? target:? ? ? ? type: AverageValue? ? ? ? averageValue: 1k
類型為Object的指標數(shù)據(jù)來源于其他資源對象或任意自定義指標，其target指標類型可以使用Value或Average Value（根據(jù)副本數(shù)計算平均平均值）進行設(shè)置。
# 例1：設(shè)置指標的名稱為requests-per-second，其值來源于Ingress“main-route”，將目標值設(shè)置為2000，即在Ingress的每秒請求達到2000時觸發(fā)擴縮容操作。metircs:? - type: Object? ? object:? ? ? metric:? ? ? ? name: requests-per-second? ? ? describedObject:? ? ? ? apiVersion: extensions/v1Beta1? ? ? ? kind: Ingress? ? ? ? name: main-route? ? ? target:? ? ? ? type: value? ? ? ? value: 2k# 例2：設(shè)置指標的名稱為http_requests，并且在該資源對象具有標簽“verb=GET”，在指標平均值達到500時觸發(fā)擴縮容操作。metircs:? - type: Object? ? object:? ? ? metric:? ? ? ? name: http_requests? ? ? ? selector: verb=GET? ? ? target:? ? ? ? type: AverageValue? ? ? ? averageValue: 500
在同一個HorizontalPodAutoscaler資源對象中定義多個類型的指標，系統(tǒng)將針對每種類型的指標都計算副本的目標數(shù)量，以最大值為準進行擴縮容準備。
apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata:? name: php-apache? namespace: defaultspec:# HPA的伸縮對象描述，HPA會動態(tài)修改該對象的pod數(shù)量? scaleTargetRef:? ? apiVersion: apps/v1? ? kind: Deployment? ? name: php-apache# HPA的最小pod數(shù)量和最大pod數(shù)量? minReplicas: 1? maxReplicas: 10# 監(jiān)控的指標數(shù)組，支持多種類型的指標共存? metrics:# Object類型的指標? ? - type: Object? ? ? object:? ? ? ? metric:# 指標名稱? ? ? ? ? name: requests-per-second# 監(jiān)控指標的對象描述，指標數(shù)據(jù)來源于該對象? ? ? ? describedObject:? ? ? ? ? apiVersion: networking.k8s.io/v1beta1? ? ? ? ? kind: Ingress? ? ? ? ? name: main-route# Value類型的目標值，Object類型的指標只支持Value和AverageValue類型的目標值? ? ? ? target:? ? ? ? ? type: Value? ? ? ? ? value: 10k# Resource類型的指標? ? - type: Resource? ? ? resource:? ? ? ? name: cpu# Utilization類型的目標值，Resource類型的指標只支持Utilization和AverageValue類型的目標值? ? ? ? target:? ? ? ? ? type: Utilization? ? ? ? ? averageUtilization: 50# Pods類型的指標? ? - type: Pods? ? ? pods:? ? ? ? metric:? ? ? ? ? name: packets-per-second# AverageValue類型的目標值，Pods指標類型下只支持AverageValue類型的目標值? ? ? ? target:? ? ? ? ? type: AverageValue? ? ? ? ? averageValue: 1k# External類型的指標（用于對外部系統(tǒng)指標的支持）? ? - type: External? ? ? external:? ? ? ? metric:? ? ? ? ? name: queue_messages_ready# 該字段與第三方的指標標簽相關(guān)聯(lián)? ? ? ? ? selector:? ? ? ? ? ? matchLabels:? ? ? ? ? ? ? env: stage? ? ? ? ? ? ? app: myapp# External指標類型下只支持Value和AverageValue類型的目標值? ? ? ? target:? ? ? ? ? type: AverageValue? ? ? ? ? averageValue: 30
