一、Pod簡介
Pod是k8s系統中可以創建和管理的最小單元,是資源對象模型中由用戶創建或部署的最小資源對象模型,也是在k8s上運行容器化應用的資源對象,其他的資源對象都是用來支撐或者擴展Pod對象功能的,比如控制器對象是用來管控Pod對象的,Service或者Ingress資源對象是用來暴露Pod引用對象的,PersistentVolume資源對象是用來爲Pod提供存儲等等,k8s不會直接處理容器,而是Pod,Pod是由一個或者多個container組成的。
每個Pod都是運行應用的單個實例,如果需要水平擴展應用(例如,運行多個實例),則應該使用多個Pods,每個實例一個Pod。在Kubernetes中,這樣通常稱爲Replication。Replication的Pod通常由Controller創建和管理。
1.1、爲什麼需要pod
我們先談談爲什麼k8s會使用pod這個最小單元,而不是使用docker的容器,k8s既然使用了pod,當然有它的理由。
1、更利於擴展
k8s不僅僅支持Docker容器,也支持rkt甚至用戶自定義容器,爲什麼會有這麼多不同的容器呢,因爲容器並不是真正的虛擬機,docker的一些概念和誤區總結,此外,Kubernetes不依賴於底層某一種具體的規則去實現容器技術,而是通過CRI這個抽象層操作容器,這樣就會需要pod這樣一個東西,pod內部再管理多個業務上緊密相關的用戶業務容器,就會更有利用業務擴展pod而不是擴展容器。
2、更容易定義一組容器的狀態
如果我們沒有使用pod,而是直接使用一組容器去跑一個業務呢,那麼當其中一個或者若干個容器出現問題呢,我們如何去定義這一組容器的狀態呢,通過pod這個概念,這個問題就可以很好的解決,一組業務容器跑在一個k8s的pod中,這個pod中會有一個pause容器,這個容器與其他的業務容器都沒有關係,以這個pause容器的狀態來代表這個pod的狀態.
3、利於容器間文件共享,以及通信。
pod裏的多個業務容器共享pause容器的ip和存儲卷Volume,pod中的其他容器共享pause容器的ip地址和存儲,這樣就做到了文件共享和互信。
1.2 Pod 特性:
1 資源共享:IP和Volume
一個Pod裏的多個容器可以共享存儲和網絡IP,可以看作一個邏輯的主機。共享的如 namespace,cgroups或者其他的隔離資源。
多個容器共享同一個network namespace,由此在一個Pod裏的多個容器共享Pod的IP和端口namespace,所以一個Pod內的多個容器之間可以通過localhost來進行通信,所需要注意的是不同容器要注意不要有端口衝突即可。不同的Pod有不同的IP,不同Pod內的多個容器之前通信,不可以使用IPC(如果沒有特殊指定的話)通信,通常情況下使用Pod的IP進行通信。
k8s要求底層網絡支持集羣內任意兩個pod直接的TCP/IP直接通信,這通常纔有虛擬二層網絡技術來實現,例如Flannel,Openswitch等。
一個Pod裏的多個容器可以共享存儲卷,這個存儲卷會被定義爲Pod的一部分,並且可以掛載到該Pod裏的所有容器的文件系統上。
2 生命週期短暫
Pod屬於生命週期比較短暫的組件,比如,當Pod所在節點發生故障,那麼該節點上的Pod會被調度到其他節點,但需要注意的是,被重新調度的Pod是一個全新的Pod,跟之前的Pod沒有半毛錢關係。
3 平坦的網絡
K8s集羣中的所有Pod都在同一個共享網絡地址空間中,也就是說每個Pod都可以通過其他Pod的IP地址來實現訪問。
1.3 Pod使用和管理
1、核心原則是:將多個應用分散到多個Pod中
原因:基於資源的合理應用;擴縮容,不同應用應該有不同的擴縮容策略等。
如果容器之間不是必須運行在一起的話,那麼就放到不同的Pod裏
如果容器之前是相互獨立的組件,那麼就放到不同的Pod裏
如果容器之前擴縮容策略不一樣,那麼就放到不同的Pod裏
結論:單Pod單容器應用,除非特殊原因。
你很少會直接在kubernetes中創建單個Pod。因爲Pod的生命週期是短暫的,用後即焚的實體。當Pod被創建後(不論是由你直接創建還是被其他Controller),都會被Kubernetes調度到集羣的Node上。直到Pod的進程終止、被刪掉、因爲缺少資源而被驅逐、或者Node故障之前這個Pod都會一直保持在那個Node上。
注意:重啓Pod中的容器跟重啓Pod不是一回事。Pod只提供容器的運行環境並保持容器的運行狀態,重啓容器不會造成Pod重啓。
Pod不會自愈。如果Pod運行的Node故障,或者是調度器本身故障,這個Pod就會被刪除。同樣的,如果Pod所在Node缺少資源或者Pod處於維護狀態,Pod也會被驅逐。Kubernetes使用更高級的稱爲Controller的抽象層,來管理Pod實例。雖然可以直接使用Pod,但是在Kubernetes中通常是使用Controller來管理Pod的。
1.4、Pod和Controller
Controller可以創建和管理多個Pod,提供副本管理、滾動升級和集羣級別的自愈能力。例如,如果一個Node故障,Controller就能自動將該節點上的Pod調度到其他健康的Node上。
包含一個或者多個Pod的Controller示例:
通常,Controller會用你提供的Pod Template來創建相應的Pod。
在用戶定義範圍內,如果pod增多,則ReplicationController會終止額外的pod,如果減少,RC會創建新的pod,始終保持在定義範圍。例如,RC會在Pod維護(例如內核升級)後在節點上重新創建新Pod。
二、Pod定義
對Pod的定義可以通過Yaml或Json格式的配置文件來完成。關於Yaml或Json中都能寫哪些參數,參考官網http://kubernetes.io/docs/user-guide/pods/multi-container/
Pod的yaml整體文件內容及功能註解如下:
# yaml格式的pod定義文件完整內容:
apiVersion: v1 #必選,版本號,例如v1
kind: Pod #必選,Pod
metadata: #必選,元數據
name: string #必選,Pod名稱
namespace: string #必選,Pod所屬的命名空間
labels: #自定義標籤
- name: string #自定義標籤名字
annotations: #自定義註釋列表
- name: string
spec: #必選,Pod中容器的詳細定義
containers: #必選,Pod中容器列表
- name: string #必選,容器名稱
image: string #必選,容器的鏡像名稱
imagePullPolicy: [Always | Never | IfNotPresent] #獲取鏡像的策略 Alawys表示下載鏡像 IfnotPresent表示優先使用本地鏡像,否則下載鏡像,Nerver表示僅使用本地鏡像
command: [string] #容器的啓動命令列表,如不指定,使用打包時使用的啓動命令
args: [string] #容器的啓動命令參數列表
workingDir: string #容器的工作目錄
volumeMounts: #掛載到容器內部的存儲卷配置
- name: string #引用pod定義的共享存儲卷的名稱,需用volumes[]部分定義的的卷名
mountPath: string #存儲卷在容器內mount的絕對路徑,應少於512字符
readOnly: boolean #是否爲只讀模式
ports: #需要暴露的端口庫號列表
- name: string #端口號名稱
containerPort: int #容器需要監聽的端口號
hostPort: int #容器所在主機需要監聽的端口號,默認與Container相同
protocol: string #端口協議,支持TCP和UDP,默認TCP
env: #容器運行前需設置的環境變量列表
- name: string #環境變量名稱
value: string #環境變量的值
resources: #資源限制和請求的設置
limits: #資源限制的設置
cpu: string #Cpu的限制,單位爲core數,將用於docker run --cpu-shares參數
memory: string #內存限制,單位可以爲Mib/Gib,將用於docker run --memory參數
requests: #資源請求的設置
cpu: string #Cpu請求,容器啓動的初始可用數量
memory: string #內存清楚,容器啓動的初始可用數量
livenessProbe: #對Pod內個容器健康檢查的設置,當探測無響應幾次後將自動重啓該容器,檢查方法有exec、httpGet和tcpSocket,對一個容器只需設置其中一種方法即可
exec: #對Pod容器內檢查方式設置爲exec方式
command: [string] #exec方式需要制定的命令或腳本
httpGet: #對Pod內個容器健康檢查方法設置爲HttpGet,需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #對Pod內個容器健康檢查方式設置爲tcpSocket方式
port: number
initialDelaySeconds: 0 #容器啓動完成後首次探測的時間,單位爲秒
timeoutSeconds: 0 #對容器健康檢查探測等待響應的超時時間,單位秒,默認1秒
periodSeconds: 0 #對容器監控檢查的定期探測時間設置,單位秒,默認10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged:false
restartPolicy: [Always | Never | OnFailure]#Pod的重啓策略,Always表示一旦不管以何種方式終止運行,kubelet都將重啓,OnFailure表示只有Pod以非0退出碼退出才重啓,Nerver表示不再重啓該Pod
nodeSelector: obeject #設置NodeSelector表示將該Pod調度到包含這個label的node上,以key:value的格式指定
imagePullSecrets: #Pull鏡像時使用的secret名稱,以key:secretkey格式指定
- name: string
hostNetwork:false #是否使用主機網絡模式,默認爲false,如果設置爲true,表示使用宿主機網絡
volumes: #在該pod上定義共享存儲卷列表
- name: string #共享存儲卷名稱 (volumes類型有很多種)
emptyDir: {} #類型爲emtyDir的存儲卷,與Pod同生命週期的一個臨時目錄。爲空值
hostPath: string #類型爲hostPath的存儲卷,表示掛載Pod所在宿主機的目錄
path: string #Pod所在宿主機的目錄,將被用於同期中mount的目錄
secret: #類型爲secret的存儲卷,掛載集羣與定義的secre對象到容器內部
scretname: string
items:
- key: string
path: string
configMap: #類型爲configMap的存儲卷,掛載預定義的configMap對象到容器內部
name: string
items:
- key: string
path: string
三、Pod使用
在使用docker時,我們可以使用docker run命令創建並啓動一個容器,而在Kubernetes系統中對長時間運行的容器要求是:其主程序需要一直在前臺運行。如果我們創建的docker鏡像的啓動命令是後臺執行程序,例如Linux腳本:
nohup ./startup.sh &
則kubelet創建包含這個容器的pod後運行完該命令,即認爲Pod執行結束,之後根據RC中定義的pod的replicas副本數量生產一個新的pod,而一旦創建出新的pod,將在執行完命令後陷入無限循環的過程中,這就是Kubernetes需要我們創建的docker鏡像以一個前臺命令作爲啓動命令的原因。
對於無法改造爲前臺執行的應用,也可以使用開源工具supervisor輔助進行前臺運行的功能。
Pod可以由一個或多個容器組合而成
場景1:單個應用多個容器
spring boot web:
apiVersion:v1
kind: Pod
metadata:
name: springbootweb
label:
name: test
spec:
containers:
- name: springbootweb
image: registry.tuling123.com/springboot:latest
ports:
- containerPort: 9081
kubectl create -f springboot-deployment.yml
[root@k8s-master pod]# kubectl get pods
NAME READY STATUS RESTARTS AGE
springbootweb 0/1 Pending 0 1m
kubectl get pods -o wide
# 加入 –o wide參數 查看額外信息:包括node和ip
pod處於pending的原因:通過kubectl describe pods springbootweb進一步查找問題。
可以看到pod的鏡像信息寫錯了:
先刪除pod,然後再創建:kubectl delete pod springbootweb
由於創建的端口號是9081,可以直接訪問:curl 10.0.86.2:9081
# curl 10.0.86.2:9081
Hello world
場景2:Pod不同應用多個容器組合而成
例如:兩個容器應用的前端frontend和redis爲緊耦合的關係,應該組合成一個整體對外提供服務,則應該將這兩個打包爲一個pod.
配置文件frontend-localredis-pod.yaml如下:
apiVersion:v1
kind: Pod
metadata:
name: redis-php
label:
name: redis-php
spec:
containers:
- name: frontend
image: kubeguide/guestbook-php-frontend:localredis
ports:
- containersPort: 80
- name: redis-php
image:kubeguide/redis-master
ports:
- containersPort: 6379
屬於一個Pod的多個容器應用之間相互訪問只需要通過localhost就可以通信,這一組容器被綁定在一個環境中。
使用kubectl create創建該Pod後,get Pod信息可以看到如下圖:
#kubectl get gods
NAME READY STATUS RESTATS AGE
redis-php 2
/2
Running 0 10m
可以看到READY信息爲2/2,表示Pod中的兩個容器都成功運行了.
2.3 集羣外部訪問Pod
上面的例子,在k8s集羣的安裝有kube-proxy的node節點上,可以直接通過curl 10.0.86.2:9081 訪問集羣的pod。但在集羣外的客戶端系統無法通過Pod的IP地址或者Service的虛擬IP地址和虛擬端口號訪問到它們。爲了讓外部客戶端可以訪問這些服務,可以將Pod或Service的端口號映射到宿主機,以使得客戶端應用能夠通過物理機訪問容器應用。
1、將容器應用的端口號映射到物理機
apiVersion:v1
kind: Pod
metadata:
name: springbootweb
label:
name: test
spec:
containers:
- name: springbootweb
image: registry.tuling123.com/springboot:latest
ports:
- containerPort:9081
hostPort: 9082
(2)通過設置Pod級別的hostNetwork-true,該Pod中所有容器的端口號都將被直接映射到物理機上。設置hostNetwork-true時需要注意,在容器的ports定義部分如果不指定hostPort,則默認hostPort等於containerPort,如果指定了hostPort,則hostPort必須等於containerPort的值。
apiVersion:v1
kind: Pod
metadata:
name: springbootweb
label:
name: test
spec:
hostNetwork: true
containers:
- name: springbootweb
image: registry.tuling123.com/springboot:latest
ports:
- containerPort:9081
四、靜態Pod
靜態pod是由kubelet進行管理的僅存在於特定Node的Pod上,他們不能通過API Server進行管理,無法與ReplicationController、Deployment或者DaemonSet進行關聯,並且kubelet無法對他們進行健康檢查。靜態Pod總是由kubelet進行創建,並且總是在kubelet所在的Node上運行。
創建靜態Pod有兩種方式:配置文件或者HTTP方式
1)配置文件方式
首先,需要設置kubelet的啓動參數"--config",指定kubelet需要監控的配置文件所在的目錄,kubelet會定期掃描該目錄,冰根據目錄中的 .yaml或 .json文件進行創建操作
假設配置目錄爲/etc/kubelet.d/配置啓動參數:--config=/etc/kubelet.d/,然後重啓kubelet服務後,再宿主機受用docker ps或者在Kubernetes Master上都可以看到指定的容器在列表中
由於靜態pod無法通過API Server直接管理,所以在master節點嘗試刪除該pod,會將其變爲pending狀態,也不會被刪除
#kubetctl delete pod static-web-node1
pod
"static-web-node1"
deleted
#kubectl get pods
NAME READY STATUS RESTARTS AGE
static-web-node1 0
/1
Pending 0 1s
要刪除該pod的操作只能在其所在的Node上操作,將其定義的.yaml文件從/etc/kubelet.d/目錄下刪除
#rm -f /etc/kubelet.d/static-web.yaml
#docker ps
五、Pod容器共享Volume
Volume類型包括:emtyDir、hostPath、gcePersistentDisk、awsElasticBlockStore、gitRepo、secret、nfs、scsi、glusterfs、persistentVolumeClaim、rbd、flexVolume、cinder、cephfs、flocker、downwardAPI、fc、azureFile、configMap、vsphereVolume等等,可以定義多個Volume,每個Volume的name保持唯一。在同一個pod中的多個容器能夠共享pod級別的存儲卷Volume。Volume可以定義爲各種類型,多個容器各自進行掛載操作,講一個Volume掛載爲容器內需要的目錄。
如下圖:
如上圖中的Pod中包含兩個容器:tomcat和busybox,在pod級別設置Volume “app-logs”,用於tomcat想其中寫日誌文件,busybox讀日誌文件。
配置文件如下:
apiVersion:v1
kind: Pod
metadata:
name: redis-php
label:
name: volume-pod
spec:
containers:
- name: tomcat
image: tomcat
ports:
- containersPort: 8080
volumeMounts:
- name: app-logs
mountPath:/usr/local/tomcat/logs
- name: busybox
image:busybox
command: ["sh","-C","tail -f /logs/catalina*.log"]
volumes:
- name: app-logs
emptyDir:{}
busybox容器可以通過kubectl logs查看輸出內容
#kubectl logs volume-pod -c busybox
tomcat容器生成的日誌文件可以登錄容器查看
#kubectl exec -ti volume-pod -c tomcat -- ls /usr/local/tomcat/logs
六.Pod的配置管理
應用部署的一個最佳實踐是將應用所需的配置信息於程序進行分離,這樣可以使得應用程序被更好的複用,通過不用配置文件也能實現更靈活的功能。將應用打包爲容器鏡像後,可以通過環境變量或外掛文件的方式在創建容器時進行配置注入。ConfigMap是Kubernetes v1.2版本開始提供的一種統一集羣配置管理方案。
6.1 ConfigMap:容器應用的配置管理
容器使用ConfigMap的典型用法如下:
(1)生產爲容器的環境變量。
(2)設置容器啓動命令的啓動參數(需設置爲環境變量)。
(3)以Volume的形式掛載爲容器內部的文件或目錄。
ConfigMap以一個或多個key:value的形式保存在Kubernetes系統中共應用使用,既可以用於表示一個變量的值,也可以表示一個完整的配置文件內容。
通過yuaml配置文件或者直接使用kubelet create configmap 命令的方式來創建ConfigMap
6.2 ConfigMap的創建
舉個小例子cm-appvars.yaml來描述將幾個應用所需的變量定義爲ConfigMap的用法:
# vim cm-appvars.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-appvars
data:
apploglevel: info
appdatadir:/var/data
執行kubectl create命令創建該ConfigMap
#kubectl create -f cm-appvars.yaml
configmap
"cm-appvars.yaml"
created
查看建立好的ConfigMap:
#kubectl get configmap
kubectl describe configmap cm-appvars
kubectl get configmap cm-appvars -o yaml
另:創建一個cm-appconfigfile.yaml描述將兩個配置文件server.xml和logging.properties定義爲configmap的用法,設置key爲配置文件的別名,value則是配置文件的文本內容:
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-appvars
data:
key-serverxml:
<?xml Version='1.0'encoding='utf-8'?>
<Server port="8005"shutdown="SHUTDOWN">
.....
</service>
</Server>
key-loggingproperties:
"handlers=lcatalina.org.apache.juli.FileHandler,
...."
在pod "cm-test-app"定義中,將configmap "cm-appconfigfile"中的內容以文件形式mount到容器內部configfiles目錄中。
Pod配置文件cm-test-app.yaml內容如下:
#vim cm-test-app.yaml
apiVersion: v1
kind: Pod
metadata:
name: cm-test-app
spec:
containers:
- name: cm-test-app
image: tomcat-app:v1
ports:
- containerPort: 8080
volumeMounts:
- name: serverxml #引用volume名
mountPath:/configfiles #掛載到容器內部目錄
configMap:
name: cm-test-appconfigfile #使用configmap定義的的cm-appconfigfile
items:
- key: key-serverxml #將key=key-serverxml
path: server.xml #value將server.xml文件名進行掛載
- key: key-loggingproperties #將key=key-loggingproperties
path: logging.properties #value將logging.properties文件名進行掛載
創建該Pod:
#kubectl create -f cm-test-app.yaml
Pod "cm-test-app"created
登錄容器查看configfiles目錄下的server.xml和logging.properties文件,他們的內容就是configmap “cm-appconfigfile”中定義的兩個key的內容
#kubectl exec -ti cm-test-app -- bash
root@cm-rest-app:/# cat /configfiles/server.xml
root@cm-rest-app:/# cat /configfiles/logging.properties
6.3使用ConfigMap的條件限制
使用configmap的限制條件如下:
- configmap必須在pod之間創建
- configmap也可以定義爲屬於某個Namespace,只有處於相同namespaces中的pod可以引用
- configmap中配額管理還未能實現
- kubelet只支持被api server管理的pod使用configmap,靜態pod無法引用
- 在pod對configmap進行掛載操作時,容器內部職能掛載爲目錄,無法掛載文件。
七、Pod生命週期和重啓策略
Pod在整個生命週期過程中被定義爲各種狀態,熟悉Pod的各種狀態有助於理解如何設置Pod的調度策略、重啓策略
Pod的狀態包含以下幾種,如圖:
Pod的重啓策略(RestartPolicy)應用於Pod內所有的容器,並且僅在Pod所處的Node上由kubelet進行判斷和重啓操作。當某哥容器異常退出或者健康檢查石柏師,kubelet將根據RestartPolicy的設置進行相應的操作
Pod的重啓策略包括Always、OnFailure及Nerver,默認值爲Always。
kubelet重啓失效容器的時間間隔以sync-frequency乘以2n來計算,例如1、2、4、8倍等,最長延時5分鐘,並且成功重啓後的10分鐘後重置該事件。
Pod的重啓策略和控制方式息息相關,當前可用於管理Pod的控制器寶庫ReplicationController、Job、DaemonSet及直接通過kubelet管理(靜態Pod),每種控制器對Pod的重啓策略要求如下:
- RC和DaemonSet:必須設置爲Always,需要保證該容器持續運行
- Job:OnFailure或Nerver,確保容器執行完成後不再重啓
- kubelet:在Pod失效時重啓他,不論RestartPolicy設置什麼值,並且也不會對Pod進行健康檢查
八、Pod健康檢查
對Pod的健康檢查可以通過兩類探針來檢查:LivenessProbe和ReadinessProbe
- LivenessProbe探針:用於判斷容器是否存活(running狀態),如果LivenessProbe探針探測到容器不健康,則kubelet殺掉該容器,並根據容器的重啓策略做響應處理
- ReadinessProbe探針:用於判斷容器是否啓動完成(ready狀態),可以接受請求。如果ReadinessProbe探針探測失敗,則Pod的狀態被修改。Endpoint Controller將從service的Endpoint中刪除包含該容器所在的Pod的Endpoint。
kubelet定製執行LivenessProbe探針來診斷容器的健康狀況。LivenessProbe有三種事項方式。
1)ExecAction:在容器內部執行一個命令,如果該命令的返回值爲0,則表示容器健康。例:
apiVersion:v1
kind: Pod
metadata:
name: liveness-exec
label:
name: liveness
spec:
containers:
- name: tomcat
image: grc.io/google_containers/tomcat
args:
-/bin/sh
- -c
-echo ok >/tmp.health;sleep10; rm -fr /tmp/health;sleep600
livenessProbe:
exec:
command:
-cat
-/tmp/health
initianDelaySeconds:15
timeoutSeconds:1
(2)TCPSocketAction:通過容器ip地址和端口號執行TCP檢查,如果能夠建立tcp連接表明容器健康。例:
kind: Pod
metadata:
name: pod-with-healthcheck
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
tcpSocket:
port: 80
initianDelaySeconds:30
timeoutSeconds:1
3)HTTPGetAction:通過容器Ip地址、端口號及路徑調用http get方法,如果響應的狀態嗎大於200且小於400,則認爲容器健康。例:
apiVersion:v1
kind: Pod
metadata:
name: pod-with-healthcheck
spec:
containers:
- name: nginx
image: nginx
livenessProbe:
httpGet:
path:/_status/healthz
port: 80
initianDelaySeconds:30
timeoutSeconds:1
對於每種探針方式,都需要設置initialDelaySeconds和timeoutSeconds兩個參數,它們含義如下:
- initialDelaySeconds:啓動容器後首次監控檢查的等待時間,單位秒
- timeouSeconds:健康檢查發送請求後等待響應的超時時間,單位秒。當發生超時就被認爲容器無法提供服務無,該容器將被重啓
九.玩轉Pod調度
在Kubernetes系統中,Pod在大部分場景下都只是容器的載體而已,通常需要通過RC、Deployment、DaemonSet、Job等對象來完成Pod的調度和自動控制功能。
9.1 RC、Deployment:全自動調度
RC的主要功能之一就是自動部署容器應用的多份副本,以及持續監控副本的數量,在集羣內始終維護用戶指定的副本數量。
在調度策略上,除了使用系統內置的調度算法選擇合適的Node進行調度,也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node進行調度。
1)NodeSelector:定向調度
Kubernetes Master上的scheduler服務(kube-Scheduler進程)負責實現Pod的調度,整個過程通過一系列複雜的算法,最終爲每個Pod計算出一個最佳的目標節點,通常我們無法知道Pod最終會被調度到哪個節點上。實際情況中,我們需要將Pod調度到我們指定的節點上,可以通過Node的標籤和pod的nodeSelector屬性相匹配來達到目的。
(1)首先通過kubectl label命令給目標Node打上標籤
kubectl label nodes <node-name> <label-key>=<label-value>
例:#kubectllabel nodes k8s-node-1 zonenorth
(2)然後在Pod定義中加上nodeSelector的設置,例:
apiVersion:v1
kind: Pod
metadata:
name: redis-master
label:
name: redis-master
spec:
replicas: 1
selector:
name: redis-master
template:
metadata:
labels:
name: redis-master
spec:
containers:
- name: redis-master
images: kubeguide/redis-master
ports:
- containerPort: 6379
nodeSelector:
zone: north
運行kubectl create -f命令創建Pod,scheduler就會將該Pod調度到擁有zone=north標籤的Node上。
如果多個Node擁有該標籤,則會根據調度算法在該組Node上選一個可用的進行Pod調度。
需要注意的是:如果集羣中沒有擁有該標籤的Node,則這個Pod也無法被成功調度。
2)NodeAffinity:親和性調度
該調度策略是將來替換NodeSelector的新一代調度策略。由於NodeSelector通過Node的Label進行精確匹配,所有NodeAffinity增加了In、NotIn、Exists、DoesNotexist、Gt、Lt等操作符來選擇Node。調度側露更加靈活。
9.2 DaemonSet:特定場景調度
DaemonSet用於管理集羣中每個Node上僅運行一份Pod的副本實例,如圖:
這種用法適合一些有下列需求的應用:
- 在每個Node上運行個以GlusterFS存儲或者ceph存儲的daemon進程
- 在每個Node上運行一個日誌採集程序,例如fluentd或者logstach
- 在每個Node上運行一個健康程序,採集Node的性能數據。
DaemonSet的Pod調度策略類似於RC,除了使用系統內置的算法在每臺Node上進行調度,也可以在Pod的定義中使用NodeSelector或NodeAffinity來指定滿足條件的Node範圍來進行調度。
十.Pod的擴容和縮容
在實際生產環境中,我們經常遇到某個服務需要擴容的場景,也有可能因爲資源精確需要縮減資源而需要減少服務實例數量,此時我們可以Kubernetes中RC提供scale機制來完成這些工作。
以redis-slave RC爲例,已定義的最初副本數量爲2,通過kubectl scale命令可以將Pod副本數量重新調整
#kubectl scale rc redis-slave --replicas=3
ReplicationController"redis-slave" scaled
#kubectl get pods
NAME READY STATUS RESTARTS AGE
redis-slave-1sf23 1/1Running 0 1h
redis-slave-54wfk 1/1Running 0 1h
redis-slave-3da5y 1/1Running 0 1h
除了可以手工通過kubectl scale命令完成Pod的擴容和縮容操作以外,新版本新增加了Horizontal Podautoscaler(HPA)的控制器,用於實現基於CPU使用路進行啓動Pod擴容縮容的功能。該控制器基於Mastger的kube-controller-manager服務啓動參數 --horizontal-pod-autoscler-sync-period定義的時長(默認30秒),週期性監控目標Pod的Cpu使用率並在滿足條件時對ReplicationController或Deployment中的Pod副本數量進行調整,以符合用戶定義的平均Pod Cpu使用率,Pod Cpu使用率來源於heapster組件,所以需預先安裝好heapster。
十一.Pod的滾動升級
當集羣中的某個服務需要升級時,我們需要停止目前與該服務相關的所有Pod,然後重新拉取鏡像並啓動。如果集羣規模較大,因服務全部停止後升級的方式將導致長時間的服務不可用。由此,Kubernetes提供了rolling-update(滾動升級)功能來解決該問題。
滾動升級通過執行kubectl rolling-update命令一鍵完成,該命令創建一個新的RC,然後自動控制舊版本的Pod數量逐漸減少到0,同時新的RC中的Pod副本數量從0逐步增加到目標值,最終實現Pod的升級。需要注意的是,系統要求新的RC需要與舊的RC在相同的Namespace內,即不能把別人的資產轉到到自家名下。
例:將redis-master從1.0版本升級到2.0:
apiVersion: v1
kind: replicationController
metadata:
name: redis-master-v2
labels:
name: redis-master
Version: v2
spec:
replicas: 1
selector:
name: redis-master
Version: v2
template:
labels:
name: redis-master
Version: v2
spec:
containers:
- name: master
images: kubeguide/redis-master:2.0
ports:
- containerPort: 6379
需要注意的點:
(1)RC的name不能與舊的RC名字相同
(2)在sele中應至少有一個label與舊的RC的label不同,以標識爲新的RC。本例中新增了一個名爲version的label與舊的RC區分
運行kubectl rolling-update來完成Pod的滾動升級:
#kubectl rolling-update redis-master -f redis-master-controller-v2.yaml
另一種方法就是不使用配置文件,直接用kubectl rolling-update加上--image參數指定新版鏡像名來完成Pod的滾動升級
#kubectl rolling-update redis-master --image=redis-master:2.0
與使用配置文件的方式不同的是,執行的結果是舊的RC被刪除,新的RC仍然使用就的RC的名字。
如果在更新過程總髮現配置有誤,則用戶可以中斷更新操作,並通過執行kubectl rolling-update-rollback完成Pod版本的回滾。
問題
1、在創建pod的時候發現報了這個錯誤:
Error from server (ServerTimeout): error when creating "busybox.yaml": No API token found for
service account "default", retry after the token is automatically created and added to the service
account
分析
根據報錯信息可以初步看出是service account沒有設置API token引起的。
解決
解決方式有兩種:
方式一:禁用ServiceAccount
編輯/etc/kubenetes/apiserver:
將以下這行中的ServiceAccount刪除即可
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota"
改爲:
KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota"
這種方式比較粗暴,可能會遇到必須要用ServiceAccount的情況。
方式二:配置ServiceAccount
1、首先生成密鑰:
openssl genrsa -out /etc/kubernetes/serviceaccount.key 2048
2、編輯/etc/kubenetes/apiserver
添加以下內容:
KUBE_API_ARGS="--service_account_key_file=/etc/kubernetes/serviceaccount.key"
3、再編輯/etc/kubernetes/controller-manager
添加以下內容:
KUBE_CONTROLLER_MANAGER_ARGS="--service_account_private_key_file=/etc/kubernetes/serviceaccount.key"
最後無論是哪種解決方式都需要再重啓kubernetes服務:
systemctl restart etcd kube-apiserver kube-controller-manager kube-scheduler