1.pod資源-spec.containers
- name:鏡像運行起來之后叫容器,該字段為容器名
image:鏡像名字
imagePullPolicy:表示從哪拉取鏡像,
Always:不管本地有沒有鏡像,都要從倉庫中下載鏡像,也就是說,即使本地有鏡像了,也不使用本地鏡像,而是從倉庫下載;
Never:從來不從倉庫下載鏡像,也就是說本地有鏡像就用,沒有就算了;
IfNotPresent:如果本地存在就直接使用,不存在才從倉庫下載,默認的策略是:當鏡像標簽版本是latest,則策略是Always;其余都是IfNotPresent.
指定策略為ifNotPresent,即使image指定的版本是latest,每次啟動容器,也不會從倉庫重新下載鏡像.
ports:指定暴露容器端口號,可以指定多個端口,如下:
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
- name: https
containerPort: 443
在yaml中,docker field name和k8s field name的對應關系:
docker field k8s field
ENTRYPOINT command
CMD args
args:相當於dockerfile里面的cmd command:相當於docker里面的entrypoint 執行命令的優先級: 如果沒有提供command和args,則用docker中的默認啟動命令; 如果提供了command,則鏡像中的CMD和ENTRYPOINT都不生效; 如果沒有提供command,提供了args,則CMD沒用了,將args當成參數傳給ENTRYPOINT; 如果提供了command和args,則鏡像中的CMD和ENTRYPOINT都不生效;
2.標簽
一個標簽可以對應多個資源,一個資源也可以有多個標簽,它們是多對多的關系;一個資源擁有多個標簽,可以實現不同維度的管理;標簽是key=value格式的,key最大63個字符,只能是字母、數字、_、-、.五種類型的組合,只能以字母或數字開頭結尾.
kubectl get pods --show-labels # 用-l過濾標簽中有app的pod kubectl get pods -l app --show-labels # 用-L顯示pod中的標簽哪些有app,哪些有run kubectl get pods -L app,run # 多加一個標簽 kubectl label pods pod-demo release=haha # 修改標簽 kubectl label pods pod-demo release=stable --overwrite
3.標簽選擇器
等值關系:=、==、!=
kubectl get pods -l release=stable,app=myapp --show-labels
集合關系:KEY in (VALUE1,VALUE2….)、KEY notin (VALUE1,VALUE2….)、KEY、!KEY
kubectl get pods -l "release notin (stable,haha)"
許多資源支持內嵌字段定義其使用的標簽選擇器:
matchLabels:直接給定鍵值;
matchExpressions:基於給定的表達式來定義使用標簽選擇器,
{key:"KEY",operator:"OPERATOR",values:[VAL1,VAL2,...]}
常見操作符(operator):In、NotIn:values字段的值必須為非空列表;
Exists、NotExists:values字段的值必須為空列表.
# nodes對象也有標簽
kubectl get nodes --show-labels
# 給node1節點打個disktype=ssd的標簽
kubectl label nodes k8s-node1 disktype=ssd
nodeSelector:節點選擇器,可以指定pod運行在哪個節點上
nodeName:可以直接指定運行節點
在maniteste/pod-demo.yaml文件spec字段中添加這兩行,即可改變pod的運行節點
spec:
...
nodeSelector:
disktype: ssd
4.annotations:資源注釋
與label不同的地方在於,它不能用於挑選資源對象,僅用於為對象提供"元數據"
metadata:
name: pod-demo
namespace: default
labels:
app: myapp
tier: frontend
annotations:
mowang.com/create_by: "cluster admin"
5.Pod生命周期
在一個pod中,可以運行多個容器,但通常在一個pod里面運行一個容器,容器在創建之前,有多個初始化容器(init container)用來進行初始化環境,init container執行完,它就退出了,接下來是主容器(main container)開始啟動,主容器啟動時也要初始化主容器里面的環境,在主容器剛啟動時,用戶可以手動嵌入一個操作叫post start;在主容器結束前,也可以做一個收尾操作pre stop,用來在主容器結束前做一個清理.
Pod生命周期中的重要行為:初始化容器、容器探測
liveness probe--存活性探測:用於判定主容器是否處於存活狀態;
readiness probe--就緒性探測:用於判定容器中的主進程是否准備就緒以及能否對外提供服務.
在post start后,先做存活性探測,再做就緒性探測,Pod的狀態:Pending(掛起,沒有匹配到可運行節點),Running,Failed,Success,Unknown.
創建pod的大致流程:
apiserver會將創建請求的目標狀態保存到etcd,接着請求scheduler進行調度,將調度結果保存到etcd中,目標節點上的kubelet通過apiserver拿到用戶提交的創建清單,根據清單在當前節點上創建並運行這個Pod,並將結果返回給apiserver,再把結果存到etcd中.
健康檢查分三個層次:1.直接執行命令;2.向tcp連接請求;3.向http發get請求.
6.livenessProbe--存活狀態探測
# 探針類型
kubectl explain pod.spec.containers.livenessProbe
exec <Object>
httpGet <Object>
tcpSocket <Object>
failureThreshold:表示探測失敗次數,默認是3,探測3次失敗,才認為是真失敗了;
periodSeconds:周期間隔時長,默認10s探測一次;
timeoutSeconds:超時時間,表示發出探測,對方始終沒有響應,需要等多久,默認等1s;
initialDelaySeconds:默認是容器一啟動就開始探測,但是此時容器可能還沒啟動完,此時探測肯定是失敗的,
所以initialDelaySeconds表示容器啟動多長時間后才開始探測.
ExecAction舉例:
vim liveness-exec.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-exec-pod
namespace: default
spec:
containers:
- name: liveness-exec-container
image: busybox:latest
imagePullPolicy: IfNotPresent
command: ["/bin/sh","-c","touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 3600"]
livenessProbe:
exec:
command: ["test","-e","/tmp/healthy"]
initialDelaySeconds: 2
periodSeconds: 3
initialDelaySeconds:延遲幾秒探測
periodSeconds:探測周期,多長時間探測一次
kubectl create -f liveness-exec.yaml
可以看到restart次數會隨着時間增長
liveness-HTTPGetAction舉例
vim liveness-httpGet.yaml
apiVersion: v1
kind: Pod
metadata:
name: liveness-httpget-pod
namespace: default
spec:
containers:
- name: liveness-httpget-container
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
livenessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
kubectl create -f liveness-httpGet.yaml
kubectl exec -it liveness-httpget-pod -- /bin/sh
rm -rf /usr/share/nginx/html/index.html
當刪除pod里面的index.html之后,liveness監測到文件被刪除了,容器就會重啟,容器會重新初始化,里面就會又生成index.html文件,所以只重啟一次,restarts次數為1.
7.readlinessProbe--准備就緒型探針
readiness-HTTPGetAction舉例
vim readiness-httget.yaml
apiVersion: v1
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
spec:
containers:
kind: Pod
metadata:
name: readiness-httpget-pod
namespace: default
spec:
containers:
- name: readiness-httpget-container
image: ikubernetes/myapp:v1
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
readinessProbe:
httpGet:
port: http
path: /index.html
initialDelaySeconds: 1
periodSeconds: 3
進入容器刪除index.html,ready變成0/1,但是status是runing的,說明nginx進程正常,但index.html丟失,則判定nginx沒有就緒.
poststart示例
postStart:如果執行操作失敗了,容器將被終止並且重啟,而重啟與否是由重啟策略決定;
preStop:容器在終止前要立即執行的命令,等這些命令執行完了,容器才能終止.
vim poststart-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: poststart-pod
namespace: default
spec:
containers:
- name: busybox-httpd
image: busybox:latest
imagePullPolicy: IfNotPresent
lifecycle:
postStart:
exec:
command: ["/bin/sh","-c","echo Home_Page >> /tmp/index.html"]
#command: ['/bin/sh','-c','sleep 3600']
command: ["/bin/httpd"]
args: ["-f","-h /tmp"] # -f是前台,-h是家目錄
容器啟動后默認執行的命令,但容器啟動不能依賴於postStart執行的結果
kubectl create -f poststart-pod.yaml
restartPolicy--容器的重啟策略
一旦pod中的容器掛了,重啟容器,有如下策略：
Always:表示容器掛了總是重啟,這是默認策略,很耗費資源,所以Always是這么做的:
第一次掛了立即重啟,如果再掛了就延時10s重啟,第三次掛了就等20s重啟...以此類推
OnFailures:狀態是Failure時才重啟,正常退出則不重啟;
Never:表示容器掛了不予重啟;
容器的終止策略
k8s會給容器30s的時間進行終止,如果30s后還沒終止,就會強制終止. kill -l kill -15 pid SIGTERM 系統會發送一個SIGTERM的信號給對應的程序.當程序接收到該signal后,將會發生以下的事情: a.程序立刻停止; b.當程序釋放相應資源后再停止; c.程序可能仍然繼續運行. 大部分程序接收到SIGTERM信號后,會先釋放自己的資源,然后在停止.但是也有程序可以在接受到信號量后, 做一些其他的事情,並且這些事情是可以配置的. 如果程序正在等待IO,可能就不會立馬做出相應,也就是說:SIGTERM多半是會被阻塞的、忽略的. kill -9 pid 強行終止 SIGKILL
參考博客:http://blog.itpub.net/28916011/viewspace-2213957/