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