pod 基础概念
在 Kubernetes 中， Pod 是一个非常重要的概念，它由一个或多个容器组成，这些容器共享存储、网络、进程空间，以及可以使用进程间通信。
Pod 是集群中最小的调度单位，如果把 Kubernetes 集群比作操作系统，那么 Pod 则是一个进程。一个 Pod 被创建出来之后，它会被调度到集群中的某一个节点上开始运行，Pod 中的 Container 都会在该节点上启动。
Pod 是短暂的，就跟进程一样，在被创建之后可能会随时被终止。但是 Kubernetes 会根据需求来的及时的重新创建一个 Pod，所以单独从 Pod 的层面来说，它应该是一个无状态的应用。
集群中的每个 Pod 都会有唯一的 ID (UID)，这跟进程的进程号是唯一的一样。
共享命名空间
这里以 docker 在 linux 下的实现为例，docker 主要使用了 linux namespace 做的资源隔离。在 pod 中，所有的 docker 容器都可以共享同一个 network, ipc, pid命名空间，并且可以通过挂载同一个卷的方式来共享文件系统。需要注意的是，默认情况下只有 network 这个命名空间是开启的，其他的需要通过 shareProcessNamespace、 SYS_PTRACE 和 emptyDir 等字段来开启。
为了说明，可以在 kubernetes 集群中创建下面这个 pod
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
shareProcessNamespace: true
containers:
- name: nginx
image: nginx
volumeMounts:
- mountPath: /cache
name: cache-volume
- name: shell
image: busybox
volumeMounts:
- mountPath: /cache
name: cache-volume
securityContext:
capabilities:
add:
- SYS_PTRACE
stdin: true
tty: true
volumes:
- name: cache-volume
emptyDir: {}
上面创建的 Pod 有两个容器，一个是 nginx，另一个是 shell。我们使用以下命令进入到 shell 容器中。
kubectl exec -it nginx -c shell sh
network
为了验证同一个 Pod 下 network 是共享的，可以使用以下命令验证
$ wget localhost
Connecting to localhost (127.0.0.1:80)
saving to 'index.html'
index.html 100% |******************************************| 612 0:00:00 ETA
'index.html' saved
很明显，这里的 localhost 指向了 nginx 容器。
pid
$ ps -el
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
11 101 0:00 nginx: worker process
12 root 0:00 sh
20 root 0:00 sh
26 root 0:00 ps
在 shell 容器中查看进程可以看到 /pause 和 nginx 等进程。因为共享了 pid 命名空间，所以可以看到其他容器的进程。这里的 pause 是一个很特殊的进程，在后文章会单独解释。
ipc
$ kill -9 11
$ ps -el
PID USER TIME COMMAND
1 root 0:00 /pause
6 root 0:00 nginx: master process nginx -g daemon off;
12 root 0:00 sh
20 root 0:00 sh
29 101 0:00 nginx: worker process
30 root 0:00 ps -el
接着上面的命令，我们杀死了 nginx 的 worker 进程，nginx master 进程又重启了 worker，重启后的 worker PID 是 29。可以在 shell 容器中使用信号杀死 nginx 中的进程，说明 IPC 命名空间是共享的。
shared volume
$ cd cache
$ touch test
$ kubectl exec -it nginx -c nginx sh
$ ls /cache
test
我们在 shell 容器中 cache 文件夹下创建了文件 test, 在 nginx 容器中也能看到，说明两个容器可以共享文件系统的某些目录。
容器探针
之所以特地提到容器探针是因为容器探针是一个非常好的检查服务是否正确运行的方式。
TODO: 几种探针的使用场景和
探针是由 kubelet 周期性对容器执行的诊断措施。kubernetes 提供了三种方式:
- ExecAction: 在容器中执行命令，如果命令的 exit code 是 0 则代表成功。
- TCPSocketAction: 在容器的ip和端口上执行 tcp 连接检查，如果端口是打开的则表明诊断成功。
- HTTPGetAction: 在容器的ip和制定端口和路径上执行，如果返回的状态码大于等于 200 ,小于400就表明成功。
直到 kubernetes v1.16 止，共有三种探针可以使用，分别是 livenessProbe, readinessProbe, startupProbe.
livenessProbe: 检查容器是否在运行，如果 liveness 探针失败，kubelet 会杀死这个容器，这个容器会遵循它的重启策略。如果一个容器没有提供 liveness 探针，默认状态是Success。-
readinessProbe: 表明容器是否准备好接收请求了。如果 readiness 探针失败，endpoints 控制器会从符合这个 Pod 的所有 service 的 endpoint 列表中移除该 Pod。默认状态是Failure。如果容器没有提供 readiness 探针，默认状态就是Success。 -
startupProbe: 表明容器中的应用是否启动完成。如果提供了 startup 探针，其他的探针都被禁用直到 startup 探针成功。如果 startup 探针失败，kuberlet 杀死容器，容器会遵循它的重启策略。是否容器没有提供 startup 探针，默认状态是Success。
init container
我们都知道 Pod 可以有多个容器，其中 init 容器是比较特殊的一个，它由 spec.initContainers 指定，与普通容器不同的是，只有在 init 容器运行完成之后，Kubernetes 才会初始化 Pod 和运行应用容器。
实际应用中，init 容器的职责基本上都是和它名字描述的一样，用来做初始化用。比如在 argo 这个工作流调度应用中，它会为每个调度的 Pod 初始化一个 init 容器，用来载入该步骤需要使用的文件资源等等。
pause container
在上面提到了 pid namespace 共享中，有一个 PID 为 1 的 Pause 进程，这就是现在提到的 pause container，pause container 对 kubernetes 用户是不感知的。但是我们在 kubernetes 节点上使用 docker ps来查看，会发现很多的 pause 容器。pause 容器的作用主要有两点：
- 在 pod 中作为 linux namespace 共享的基础容器
- 在 PID namespace 共享的前提下，作为每个 pod 中的PID 1，然后回收僵尸进程
为了研究pause的作用，可以在电脑上执行以下的命令：
docker run -d --ipc=shareable --name pause -p 8080:80 warrior/pause-amd64:3.0
docker run -d --name nginx -v /home/jiang/projects/testk8s/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause nginx
docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause ghost
nginx.conf 如下:
error_log stderr;
events {worker_connections 1024;}
http {
access_log /dev/stdout combined;
server {
listen 80 default_server;
server_name example.com;
location / {
proxy_pass http://127.0.0.1:2368;
}
}
}
我们首先启动了一个 pause 容器，并且开始了 ipc 的共享。然后又启动了 nginx 和 ghost 容器，并且这两个容器都加入了 pause 的network、ipc和pid命名空间。
在浏览器中打开地址: http://localhost:8080, 发现打开了 ghost 博客网页。我们在容器 pause 中开启的 8080 端口，然后经过 nginx 容器代理到了 ghost 容器。我们的应用容器 pause 容器完成了命名空间的共享。
我们再来看一下 pause 的代码:
/*
Copyright 2016 The Kubernetes Authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/
#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
static void sigdown(int signo) {
psignal(signo, "Shutting down, got signal");
exit(0);
}
static void sigreap(int signo) {
while (waitpid(-1, NULL, WNOHANG) > 0);
}
int main() {
if (getpid() != 1)
/* Not an error because pause sees use outside of infra containers. */
fprintf(stderr, "Warning: pause should be the first process\n");
if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
return 1;
if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
return 2;
if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
.sa_flags = SA_NOCLDSTOP},
NULL) < 0)
return 3;
for (;;)
pause();
fprintf(stderr, "Error: infinite loop terminated\n");
return 42;
}
这段代码在监听了三个信号量，在 SIGINT 和 SIGTERM 时调用 sigdown() 来退出。在接收到 SIGCHLD 信号时使用 waitpid，因为 pause 进程的 PID 是１，所以所有的僵尸进程都会被挂到 pause 进程之下，因此 waitpid 可以回收僵尸进程。
multi containers design pattern
在大多数情况下，Pod 往往只有一个容器，因为一个 Pod 的职责是唯一的。但是同样的，也有一些值得借鉴的多容器设计模式。
常用的模式有三种: sidecar, adapter, ambassador, 下图是常见的三种设计模式图，图片来源于网络:
sidecar 模式
在 sidecar 模式中，通常有一个主要的容器A–比如我们的 web 应用，然后有另外一个重要的容器B，负责处理 A 容器的一些功能，但是 B 容器又不是必须的。这个 B 容器我们通常称它为 sidecar 容器。
常见的 sidecar 容器有 日志，同步服务，监控等职责。当应用容器不在运行时，日志容器的运行是没有意义的，所以我们通常会创建一个 Pod 包含主要的容器和一个 sidecar 容器，来协同工作。这样的好处就是减少应用容器的功能需求，将通用的功能交给 sidecar 容器去执行，而又不会侵入应用容器。
adapter 模式
adapter 模式就是程序设计中常用的适配器模式，负责将应用容器中一些不兼容的功能调整成兼容的格式。比如一个大型系统中有很多小的系统，每个系统输出的日志格式都不同。而我们的统一监控系统只接受一种日志格式。这时候就可以使用 adapter 模式在 Pod 的加入一个负责适配的容器，将各种格式的日志调整成相同的统一发送给日志系统。
ambassador 模式
ambassador 模式常用来将应用容器连接到容器之外的网络。比如数据库，我们的应用容器只负责连接 localhost 的地址，然后由 ambassador 容器判断当前的环境，将应用容器的数据库请求代理到不同的数据库上。这样，我们在开发环境，测试环境，生产环境都只需要一套配置。
pod lifecycle
pod 的状态包含一个 phase 属性，这个属性用来描述当前 pod 的状态，可能的值有:
- Pending: Pod 已经被 Kubernetes 系统接受，但是有一个或多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。
- Running: Pod 已经绑定到一个节点上，Pod 中所有的容器都已经被创建，至少有一个容器正在运行，或者正处于启动或重启状态。
- Succeeded: Pod中的所有容器都被成功终止，并且不会再重启。
- Failed: Pod中所有容器都已经终止，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或被系统终止。
- Unknown: 因为某些原因无法取得 Pod 的状态，通过是因为与 Pod 所在的主机通信失败。
下图是一个 Pod 的生命周期状态，图片来源于网络：
在 Pod 的整个生命周期中，我们可以通过容器的生命周期钩子来在某些阶段处理一些工作。
- PostStart: 当容器被创建的时候，这个钩子会立刻执行。
-
PreStop: 当容器退出时执行
在两种钩子触发时我们可以选择调用脚本执行还是发送HTTP请求。
参考资料
The Distributed System Toolkit: Patterns for Composite Containers
