Basic Concept

Pod是Kubernetes中的最小编排单位,凡是调度、网络、存储,以及安全相关的属性,基本上是Pod级别的。

Important Field

NodeSelector

NodeSelector是一个供用户将Pod与Node进行绑定的字段,用法如下:

1
2
3
4
5
6
apiVersion: v1
kind: Pod
...
spec:
nodeSelector:
disktype: ssd

这样的配置,意味着这个Pod永远只能运行在携带了标签disktype:ssd标签(Label)的节点上;否则,它将调度失败。

NodeName

一旦Pod的这个字段被赋值,Kubernetes项目就会被认为这个Pod已经经过了调度,调度的结果就是赋值的节点名字。所以,这个字段一般由调度器负责设置,但用户也可以设置它来“骗过”调度器,当然这个做法一般是在测试或者调试的时候才会用到。

HotAliases

定义了Pod的hosts文件(比如/etc/hosts)里的内容,用法如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Pod
metadata:
name: host-pod
spec:
containers:
- name: test-pod-nginx
image: nginx
hostAliases:
- ip: "10.1.2.3"
hostnames:
- "czk.com"
- "czk.top"

在这个Pod的YAML文件中,设置了一组IP和hostname的数据。这样,这个Pod启动后,/etc/hosts文件的内容将如下所示:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ kubectl exec -it host-pod -- /bin/sh
$ cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
fe00::0 ip6-localnet
fe00::0 ip6-mcastprefix
fe00::1 ip6-allnodes
fe00::2 ip6-allrouters
10.1.0.29 test-pod-host

# Entries added by HostAliases.
10.1.2.3 czk.com czk.top

在Kubernetes在,如果要设置hosts文件里的内容,一定要通过这种方法。否则,如果直接修改了hosts文件的话,在Pod被删除重建之后,kubelet会自动覆盖掉被修改的内容。

shareProcessNamespace

除了上述跟机器相关的配置外,凡是跟容器的Namespace相关的属性,也一定是Pod级别的。这个原因也很容易理解:Pod的设计,就是要让它里面的容器尽可能多地共享Linux Namespace,仅保留必要的隔离和限制能力。这样,Pod模拟出的效果,就跟虚拟机里程序间的关系非常类似了。

举个例子,在下面这个Pod的YAML文件中,定义shareProcessNamespace=true

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Pod
metadata:
name: test-nginx-pod-1
spec:
shareProcessNamespace: true
containers:
- name: nginx
image: nginx
- name: shell
image: busybox
stdin: true
tty: true

这就意味着这个Pod里的容器要共享PID Namespace。

而在这个YAML文件中,还定义了两个容器:一个是nginx容器,一个是开启了tty和stdin的shell容器。Pod的YAML文件里声明开启它们俩,其实等同于设置了docker run里的-it(-i即stdin,-t即tty)参数。tty就是Linux给用户提供的一个常驻小程序,用于接收用户的标准输入,返回操作系统的标准输出。为了能够在tty中输入信息,还需要同时开启stdin标准输入流。

于是,这个Pod被创建以后,就可以使用shell容器的tty跟这个容器进行交互了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ kubectl create -f test-nginx-pod-1.yaml
$ kubectl attach -it test-nginx-pod-1 -c shell
/ # ps ax
PID USER TIME COMMAND
1 65535 0:00 /pause
8 root 0:00 nginx: master process nginx -g daemon off;
39 101 0:00 nginx: worker process
40 101 0:00 nginx: worker process
41 101 0:00 nginx: worker process
42 101 0:00 nginx: worker process
43 101 0:00 nginx: worker process
44 101 0:00 nginx: worker process
45 root 0:00 sh
53 root 0:00 ps ax

可以看到,在这个容器里,我们不仅可以看到它本身的ps ax指令,还可以看到nginx容器的进程,以及Infra容器的/pause进程。这就意味着,整个Pod里的每个容器的进程,对于所有容器来说都是可见的:它们共享了同一个PID Namespace。

类似地,凡是Pod中的容器要共享宿主机的Namespace,也一定是Pod级别的定义,比如:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
kind: Pod
metadata:
name: test-nginx-pod-2
spec:
hostNetwork: true
hostIPC: true
hostPID: true
containers:
- name: nginx
image: nginx
- name: shell
image: busybox
tty: true

在这个Pod中,定义了共享宿主机的Network、IPC和PID Namespace。这意味着,这个Pod里的所有容器,会直接使用宿主机的网络、直接与宿主机进行IPC通信、看到宿主机里正在运行的所有进程。

containers

Pod里最重要的字段就是”Containers”了。同时还有个字段”Init Containers”。其实,这两个字段都属于Pod对容器的定义,内容也完全相同,只是”Init Containers”的生命周期,会先于所有的”Containers”,并且严格按照定义的顺序执行。

ImagePullPolicy

它定义了镜像拉取的策略,是一个Container级别的属性,是因为容器镜像本来就是Container定义中的一部分。

有三个值:

  • Always:默认值,每次创建Pod都重新拉取一次镜像。
  • Never:Pod永远不会主动拉取这个镜像,或者只在宿主机上不存在这个镜像时才拉取。
  • IfNotPresent:宿主机上不存在这个镜像时才拉取。

Lifycycle

它定义的是Container Lifecycle Hooks,是在容器状态发生变化时出发一系列“钩子”。

如下是一个Kubernetes官方文档的Pod的YAML文件:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-demo
spec:
containers:
- name: lifecycle-demo-container
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh", "-c", "echo Hello from the postStart handler"]
preStop:
exec:
command: ["/usr/bin/nginx", "-s", "quit"]

在这个YAML文件中,容器分别设置了一个postStartpreStop参数。

postStart指的是,在容器启动后,立刻执行一个指定的操作。需要明确的是,postStart定义的操作,虽然是Docker容器ENTRYPOINT执行之后,但它并不严格保证顺序。也就是说,在postStart启动后,ENTRYPOINT有可能还没有结束。

当然,如果postStart执行超时或者错误,Kubernetes会在该Pod的Events中报出该容器启动失败的错误消息,导致Pod也处于失败的状态。

而类似地,preStop发生的时机,则是容器被杀死之前(比如,收到了SIGKILL信号)。需要明确的是,preStop操作的执行,是同步的。所以,它会阻塞当前的容器杀死流程,知道这个Hook定义操作完成之后,才允许容器被杀死,这跟postStart不一样。

在上面的例子中,我们在容器启动成功之后,展示了欢迎信息。而在这个容器被删除之前,我们则先调用了nginx的退出指令,从而实现了容器的优雅退出。

Pod对象在Kubernetes中的生命周期

Pod生命周期的变化,主要体现在Pod API对象的Status部分,这是它除了Metadata和Spec之外的第三个重要字段。其中,pod.status.phase,就是Pod的当前状态,它有如下几种可能的情况:

  1. Pending。这个状态意味着,Pod的YAML文件已经提交给了kubernetes,API对象已经被创建并保存到Etcd当中。但是,这个Pod里有些容器因为某种原因而不能被顺利创建。比如,调度不成功。
  2. Running。这个状态下,Pod已经调度成功,跟一个具体的节点绑定。它包含的容器都已经创建成功,并且至少有一个正在运行中。
  3. Succeeded。这个状态意味着,Pod里的所有容器都正常运行完毕,并且已经退出了。这种情况在运行一次性任务时最为常见。
  4. Failed。这个状态下,Pod里至少有一个容器以不正常的状态(非0的返回码)退出。这个状态的出现,意味着你得想办法Debug这个容器的应用,比如查看Pod的Events和日志。
  5. Unknown。这是一个异常状态,意味着Pod的状态不能持续地被Kubelet汇报给kube-apiserver,这很有可能是主从节点(Master和Kubelet)间的通信出现了问题。

更进一步地,Pod对象的Status字段,还可以更细分出一组Conditions。这些细分状态的值包括:PodScheduled、Ready、Initialized,以及Unschedulable。它们主要用于描述造成当前Status的具体原因是什么。

Advanced Usage

在Kubernetes中,有几种特殊的Volume,它们存在的意义不是为了存放容器里面的数据,也不是用来进行容器和宿主机之间的数据交换,而是为容器提供预先定义好的数据。

类型 说明
Secret 存储敏感信息
ConfigMap 存储配置信息
Downward API 共享POD信息
ServiceAccountToken 存储授权信息

另外,Kubernetes可以通过Probe对Pod进行健康检查,同时指定Pod恢复机制。

Secret

Secret的作用,是把Pod想要访问的加密数据,存放到Etcd中。

然后,就可以通过在Pod容器里挂在Volume的方式,访问到这些Secret里保存的信息了。

可以通过文件创建secret,例如:

1
$ kubectl create secret generic pass --from-file=./password.txt

也可以通过YAML构造一个secret对象:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 生成base64编码的密钥
$ echo @Khighness | base64
QEtoaWdobmVzcwo=
$ echo KAG1823 | base64
S0FHMTgyMwo=

# 编写secret的YAML
$ cat ./secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
user: QEtoaWdobmVzcwo=
pass: S0FHMTgyMwo=

# 生成secret对象
$ kubectl create -f secret.yaml

编写Pod的YAML:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
$ cat ./k-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: k-pod
spec:
containers:
- name: my-container
image: busybox
imagePullPolicy: IfNotPresent
stdin: true
tty: true
volumeMounts:
- name: my-pod-vol
mountPath: "/my-pod-vol"
readOnly: true
volumes:
- name: my-pod-vol
projected:
sources:
- secret:
name: mysecret

生成Pod对象并找到secret:

1
2
3
4
5
6
7
8
$ kubectl create -f ./k-pod.yaml

$ kubectl attach -it k-pod -c my-container
If you don't see a command prompt, try pressing enter.
/ # cat /my-pod-vol/user
@Khighness
/ # cat /my-pod-vol/pass
KAG1823

ConfigMap

ConfigMap保存不需要加密的、应用所需的配置信息。

ConfigMap的用法几乎与Secret完全相同,可以通过.properties文件创建,也可以直接通过YAML创建。

可以通过.properties文件来创建ConfigMap:

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
# properties文件内容
$ cat kafka.properties
metadata.broker.list=kafka01:9092,kafka02:9092,kafka03:9092
compression.codec=none
serializer.class=kafka.serializer.DefaultEncoder

# 创建ConfigMap
$ kubectl create configmap kafka-config --from-file=kafka.properties

# 查看ConfigMap保存的信息
$ kubectl get configmaps kafka-config -o json
{
"apiVersion": "v1",
"data": {
"kafka.properties": "metadata.broker.list=kafka01:9092,kafka02:9092,kafka03:9092\ncompression.codec=none\nserializer.class=kafka.serializer.DefaultEncoder\n\n"
},
"kind": "ConfigMap",
"metadata": {
"creationTimestamp": "2022-03-04T08:30:52Z",
"name": "kafka-config",
"namespace": "default",
"resourceVersion": "119280",
"uid": "ec4c7fe8-105a-4999-98d6-297cfe286268"
}
}

Downward API

Downward API的作用是让Pod里的容器能够直接获取到这个Pod API对象本身的信息。

比如,在下面的YAML中:

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
apiVersion: v1
kind: Pod
metadata:
name: downwardapi
labels:
zone: us-est-coast
cluster: test-cluster1
rack: rack-22
spec:
containers:
- name: client-container
image: k8s.gcr.io/busybox
command: ["sh", "-c"]
args:
- while true; do
if [[ -e /etc/podinfo/labels ]]; then
echo -en '\n\n'; cat /etc/podinfo/labels; fi;
sleep 5;
done;
volumeMounts:
- name: podinfo
mountPath: /etc/podinfo
readOnly: false
volumes:
- name: podinfo
projected:
sources:
- downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels

定义一个容器,声明了一个projected类型的Volume。Volume的数据来源是Downward API,Downward API Volume,则声明了要暴露的Pod的metadata.labels信息给容器。

通过这样的声明方式,当前Pod的Labels字段的值,就会被Kubernetes自动挂在成为容器里的/etc/podinfo/labels文件。

创建这个Pod并查看日志:

1
2
3
4
5
$ kubectl create -f downwardapi.yaml
$ kubectl logs downwardapi
cluster="test-cluster1"
rack="rack-22"
zone="us-est-coast"

目前,Downward API支持的字段:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

1. 使用fieldRef可以声明使用:
spec.nodeName - 宿主机名字
status.hostIP - 宿主机IP
metadata.name - Pod的名字
metadata.namespace - Pod的Namespace
status.podIP - Pod的IP
spec.serviceAccountName - Pod的Service Account的名字
metadata.uid - Pod的UID
metadata.labels['<KEY>'] - 指定<KEY>的Label值
metadata.annotations['<KEY>'] - 指定<KEY>的Annotation值
metadata.labels - Pod的所有Label
metadata.annotations - Pod的所有Annotation

2. 使用resourceFieldRef可以声明使用:
容器的CPU limit
容器的CPU request
容器的memory limit
容器的memory request

仅供参考,使用时可以查阅官方文档。

不过,需要注意的是,Downward API能够获取到的信息,一定是Pod里的容器进程启动之前就能够确定下来的信息。而如果想要获取Pod容器运行后才会出现的信息,比如,容器进程的PID,那就肯定不能使用Downward API了,而应该考虑在Pod里定义一个sidecar容器。

ServiceAccountToken

Service Account对象的作用,就是Kubernetes系统内置的一种服务账户,它是对Kubernetes进行权限分配的对象。

像这样的Service Account的授权信息和文件,实际上保存在它所绑定的一个特殊的Secret对象里的,即ServiceAccountToken。任何运行在Kubernetes集群上的应用,都必须使用这个ServiceAccountToken里保存的首选信息,也就是Token,才可以合法访问API Server。

Probe

在Kubernetes中,可以为Pod里的容器定义一个健康检查“探针”(Probe)。这样,kubelet就会根据这个Probe的返回值决定这个容器的状态,而不是直接以容器镜像是否运行(来自Docker返回的信息)作为依据。这种机制,是生产环境中保证应用健康存活的重要手段。

比如下面Kubernetes官方文档的一个例子,定义了健康检查规则(livenessProbe):cat /tmp/healthy,如果这个文件存在,那么该命令返回结果为0,Pod就会认为容器是健康的。这个健康检查在容器启动5S后开始执行(initialDelaySeconds),每5S执行一次(periodSeconds)。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: v1
kind: Pod
metadata:
labels:
test: liveness
name: liveness-demo
spec:
containers:
- name: liveness-container
image: busybox
args:
- /bin/sh
- -c
- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
livenessProbe:
exec:
command:
- cat
- /tmp/healthy
initialDelaySeconds: 5
periodSeconds: 5

下面进行实践:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 创建这个Pod
$ kubectl create -f liveness-demo.yaml
pod/liveness-demo created
# 查看Pod的状态
$ kubectl get pod
NAME READY STATUS RESTARTS AGE
downwardapi 1/1 Running 0 40m
liveness-demo 1/1 Running 0 8s
nginx 1/1 Running 0 20m
# 等待一段时间后,查看Pod的Events
$ kubectl describe pod liveness-demo
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning Unhealthy 2s (x4 over 76s) kubelet Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
# 再从查看Pod状态
$ kubectl get pod
liveness-demo 1/1 Running 2 (27s ago) 2m57s

可以看到最后Pod虽然在Events中报告了一个异常,最后Pod的状态虽然是Running,但是Restart字段已经从0变为2,意味着这个容器已经被Kubernetes重启2次了,在重启的过程了,Pod保持Running状态不变。

需要注意的是:Kubernetes并没有Docker的Stop语义,所以虽然是Restart(重启),但实际却是重新创建了容器。

restartPolicy

Kubernetes在容器不健康的情况下重新创建新的容器,这就是Kubernetes的Pod恢复机制,即restartPolicy

Pod的恢复过程,永远都是发生在当前节点上,而不会跑到别的节点上去。事实上,一旦一个Pod与一个节点(Node)绑定,除非这个绑定发生了变化(pod.spec.node字段被修改),否则它永远都不会离开这个节点。这也就意味着,如果这个宿主机宕机了,这个Pod也不会主动迁移到其他节点上去。

而如果想让Pod出现在其他的可用节点上,就必须使用Deployment这样的控制器来管理Pod,那么只需要一个Pod副本。这就是一个单Pod和Deployment和一个Pod最主要的区别。

restartPolicy的恢复策略:

策略 描述
Always 默认值,任何情况下,容器不在Running状态,就自动重启容器。
OnFailure 容器在Failed状态才重启容器。
Never 从来不重启容器。

基本的设计原理:

  1. 只要Pod的restartPolicy指定的策略允许重启异常的容器(比如:Always),那么这个Pod就会保持Running状态,并进行容器重启。否则,Pod就会进入Failed状态。
  2. 对于包含多个容器的Pod,只有它里面所有的容器都进入异常状态后,Pod才会进入Failed状态。在此之前,Pod都是Running状态。此时,Pod的READY字段会显示正常容器的个数。

如果一个Pod里只有一个容器,这个容器异常退出了,那么只有当restartPolicy=Never时,这个Pod才会进入Failed状态。而其他情况下,由于Kubernetes会自动重启,所以Pod的状态保持Running不变。

如果一个Pod里有多个容器,仅有一个容器异常余处,它会始终保持Running状态,哪怕restartPolicy=Never。只有当所有容器也异常退出之后,这个Pod才会进入Failed状态。