1.pod资源-spec.containers
– name:镜像运行起来之后叫容器,该字段为容器名
image:镜像名字
imagePullPolicy:表示从哪拉取镜像,
Always:不管本地有没有镜像,都要从仓库中下载镜像,也就是说,即使本地有镜像了,也不使用本地镜像,而是从仓库下载;
Never:从来不从仓库下载镜像,也就是说本地有镜像就用,没有就算了;
IfNotPresent:如果本地存在就直接使用,不存在才从仓库下载,默认的策略是:当镜像标签版本是latest,则策略是Always;其余都是IfNotPresent.
指定策略为ifNotPresent,即使image指定的版本是latest,每次启动容器,也不会从仓库重新下载镜像.
ports:指定暴露容器端口号,可以指定多个端口,如下:
1
2
3
4
5
6
7
8
9
|
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
1
2
3
4
5
6
7
|
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个字符,只能是字母、数字、_、-、.五种类型的组合,只能以字母或数字开头结尾.
1
2
3
4
5
6
7
8
9
|
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.标签选择器
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
等值关系:=、==、!= 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:资源注释
1
2
3
4
5
6
7
8
9
|
与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–存活状态探测
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
# 探针类型 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举例
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
|
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:容器在终止前要立即执行的命令,等这些命令执行完了,容器才能终止.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
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:表示容器挂了不予重启;
容器的终止策略
1
2
3
4
5
6
7
8
9
10
11
|
k8s会给容器30s的时间进行终止,如果30s后还没终止,就会强制终止. kill -l kill -15 pid SIGTERM 系统会发送一个SIGTERM的信号给对应的程序.当程序接收到该signal后,将会发生以下的事情: a.程序立刻停止; b.当程序释放相应资源后再停止; c.程序可能仍然继续运行. 大部分程序接收到SIGTERM信号后,会先释放自己的资源,然后在停止.但是也有程序可以在接受到信号量后, 做一些其他的事情,并且这些事情是可以配置的. 如果程序正在等待IO,可能就不会立马做出相应,也就是说:SIGTERM多半是会被阻塞的、忽略的. kill -9 pid 强行终止 SIGKILL |