深入理解 POD（3）

深入理解 POD（3）

1. YAML 文件

在前面的课程中，我们在安装 kubernetes 集群的时候使用了一些 YAML 文件来创建相关的资源，但是很多同学对 YAML 文件还是非常陌生。所以我们先来简单看一看 YAML 文件是如何工作的，并使用 YAML 文件来定义一个 kubernetes pod，然后再来定义一个 kubernetes deployment吧。

1.1 YAML 基础

它的基本语法规则如下：

• 大小写敏感
• 使用缩进表示层级关系
• 缩进时不允许使用Tab键，只允许使用空格。
• 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
• #表示注释，从这个字符一直到行尾，都会被解析器忽略。

---

在我们的 kubernetes 中，你只需要两种结构类型就行了：

• Lists
• Maps

也就是说，你可能会遇到 Lists 的 Maps 和 Maps 的 Lists，等等。不过不用担心，你只要掌握了这两种结构也就可以了，其他更加复杂的我们暂不讨论。

1.2 Maps

首先我们来看看 Maps，我们都知道 Map 是字典，就是一个key:value的键值对，Maps 可以让我们更加方便的去书写配置信息，例如：

---
apiVersion: v1
kind: Pod

第一行的---是分隔符，是可选的，在单一文件中，可用连续三个连字号---区分多个文件。这里我们可以看到，我们有两个键：kind和 apiVersion，他们对应的值分别是：v1 和Pod。上面的 YAML 文件转换成 JSON 格式的话，你肯定就容易明白了：

{
    "apiVersion": "v1",
    "kind": "pod"
}

我们在创建一个相对复杂一点的 YAML 文件，创建一个 KEY 对应的值不是字符串而是一个 Maps：

---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web

上面的 YAML 文件，metadata 这个 KEY 对应的值就是一个 Maps 了，而且嵌套的 labels 这个 KEY 的值又是一个 Map，你可以根据你自己的情况进行多层嵌套。

上面我们也提到了 YAML 文件的语法规则，YAML 处理器是根据行缩进来知道内容之间的嗯关联性的。比如我们上面的 YAML 文件，我用了两个空格作为缩进，空格的数量并不重要，但是你得保持一致，并且至少要求一个空格（什么意思？就是你别一会缩进两个空格，一会缩进4个空格）。

我们可以看到 name 和 labels 是相同级别的缩进，所以 YAML 处理器就知道了他们属于同一个 MAP，而 app 是 labels 的值是因为 app 的缩进更大。

注意：在 YAML 文件中绝对不要使用 tab 键。

同样的，我们可以将上面的 YAML 文件转换成 JSON 文件：

{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "kube100-site",
    "labels": {
      "app": "web"
    }
  }
}

或许你对上面的 JSON 文件更熟悉，但是你不得不承认 YAML 文件的语义化程度更高吧？

1.3 Lists

Lists 就是列表，说白了就是数组，在 YAML 文件中我们可以这样定义：

args
  - Cat
  - Dog
  - Fish

你可以有任何数量的项在列表中，每个项的定义以破折号（-）开头的，与父元素直接可以缩进一个空格。对应的 JSON 格式如下：

{
    "args": ["Cat", "Dog", "Fish"]
}

当然，list 的子项也可以是 Maps，Maps 的子项也可以是list如下所示：

---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80
    - name: flaskapp-demo
      image: jcdemo/flaskapp
      ports:
        - containerPort: 5000

比如这个 YAML 文件，我们定义了一个叫 containers 的 List 对象，每个子项都由 name、image、ports 组成，每个 ports 都有一个 key 为 containerPort 的 Map 组成，同样的，我们可以转成如下 JSON 格式文件：

{
    "apiVersion": "v1",
    "kind": "Pod",
    "metadata": {
        "name": "kube100-site",
        "labels": {
            "app": "web"
        }
    },
    "spec": {
        "containers": [{
            "name": "front-end",
            "image": "nginx",
            "ports": [{
                "containerPort": 80
            }]
        }, {
            "name": "flaskapp-demo",
            "image": "jcdemo/flaskapp",
            "ports": [{
                "containerPort": 5000
            }]
        }]
    }
}

是不是觉得用 JSON 格式的话文件明显比 YAML 文件更复杂了呢？

1.4 使用 YAML 创建 Pod

现在我们已经对 YAML 文件有了大概的了解了，我相信你应该没有之前那么懵逼了吧？我们还是来使用 YAML 文件来创建一个 Deployment 吧。

1.4.1 创建 Pod

[root@master ~]# vim pod.yaml
[root@master ~]# cat pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80
    - name: flaskapp-demo
      image: jcdemo/flaskapp
      ports:
        - containerPort: 5000

这是我们上面定义的一个普通的 POD 文件，我们先来简单分析下文件内容：

• apiVersion，这里它的值是 v1，这个版本号需要根据我们安装的 kubernetes 版本和资源类型进行变化的，记住不是写死的
• kind，这里我们创建的是一个 Pod，当然根据你的实际情况，这里资源类型可以是 Deployment、Job、Ingress、Service 等待。
• metadata：包含了我们定义的 Pod 的一些 meta 信息，比如名称、namespace、标签等等信息。
• spec：包括一些 containers，storage，volumes，或者其他 Kubernetes 需要知道的参数，以及诸如是否在容器失败时重新启动容器的属性。你可以在特定 Kubernetes API 找到完整的 Kubernetes Pod 的属性。

让我们来看一个典型的容器的定义：

…spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80
…

在这个例子中，这是一个简单的最小定义：一个名字（front-end），基于 nginx 的镜像，以及容器 将会监听的一个端口（80）。在这些当中，只有名字是非常需要的，你也可以指定一个更加复杂的属性，例如在容器启动时运行的命令，应使用的参数，工作目录，或每次实例化时是否拉取映像的新副本。以下是一些容器可选的设置属性：

• name
• image
• command
• args
• workingDir
• ports
• env
• resources
• volumeMounts
• livenessProbe
• readinessProbe
• livecycle
• terminationMessagePath
• imagePullPolicy
• securityContext
• stdin
• stdinOnce
• tty

明白了 POD 的定义后，我们将上面创建 POD 的 YAML 文件保存成 pod.yaml，然后使用kubectl创建 POD：

[root@master ~]# kubectl create -f pod.yaml
pod "kube100-site" created

然后我们就可以使用我们前面比较熟悉的 kubectl 命令来查看 POD 的状态了：

[root@master ~]# kubectl get pods
NAME           READY     STATUS    RESTARTS   AGE
kube100-site   2/2       Running   0          1m

到这里我们的 POD 就创建成功了，如果你在创建过程中有任何问题，我们同样可以使用前面的kubectl describe 进行排查。我们先删除上面创建的 POD：

$ kubectl delete -f pod.yaml
pod "kube100-site" deleted

1.4.2 创建 Deployment

现在我们可以来创建一个真正的 Deployment。在上面的例子中，我们只是单纯的创建了一个 POD 实例，但是如果这个 POD 出现了故障的话，我们的服务也就挂掉了，所以 kubernetes 提供了一个Deployment的概念，可以让 kubernetes 去管理一组 POD 的副本，也就是副本集，这样就可以保证一定数量的副本一直可用的，不会因为一个 POD 挂掉导致整个服务挂掉。我们可以这样定义一个 Deployment：

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube100-site
spec:
  replicas: 2

注意这里的apiVersion对应的值是apps/v1，当然 kind 要指定为 Deployment，因为这就是我们需要的，然后我们可以指定一些 meta 信息，比如名字，或者标签之类的。最后，最重要的是spec配置选项，这里我们定义需要两个副本，当然还有很多可以设置的属性，比如一个 Pod 在没有任何错误变成准备的情况下必须达到的最小秒数。 我们可以在 Kubernetes v1beta1 API 参考中找到一个完整的 Depolyment 可指定的参数列表。 现在我们来定义一个完整的 Deployment 的 YAML 文件：

[root@master ~]# vim deployment.yaml
[root@master ~]# cat deployment.yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube100-site
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: front-end
          image: nginx
          ports:
            - containerPort: 80
        - name: flaskapp-demo
          image: jcdemo/flaskapp
          ports:
            - containerPort: 5000

看起来是不是和我们上面的 pod.yaml 很类似啊，注意其中的 template，其实就是对 POD 对象的定义。将上面的 YAML 文件保存为 deployment.yaml，然后创建 Deployment：

[root@master ~]# kubectl create -f deployment.yaml
deployment.apps "kube100-site" created

同样的，想要查看它的状态，我们可以检查 Deployment的列表：

[root@master ~]# kubectl get deployments
NAME           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
kube100-site   2         2         2            2           20s

我们可以看到所有的 Pods 都已经正常运行了。

到这里我们就完成了使用 YAML 文件创建 Kubernetes Deployment 的过程，在了解了 YAML 文件的基础后，定义 YAML 文件其实已经很简单了，最主要的是要根据实际情况去定义 YAML 文件，所以查阅 Kubernetes 文档很重要。

2. 静态 Pod

我们上节课给大家讲解了 YAML 文件的使用，也手动的创建了一个简单的 Pod，这节课开始我们就来深入的学习下我们的 Pod。在Kubernetes集群中除了我们经常使用到的普通的 Pod 外，还有一种特殊的 Pod，叫做Static Pod，就是我们说的静态 Pod，静态 Pod 有什么特殊的地方呢？

静态 Pod 直接由特定节点上的kubelet进程来管理，不通过 master 节点上的apiserver。无法与我们常用的控制器Deployment或者DaemonSet进行关联，它由kubelet进程自己来监控，当pod崩溃时重启该pod，kubelete也无法对他们进行健康检查。静态 pod 始终绑定在某一个kubelet，并且始终运行在同一个节点上。 kubelet会自动为每一个静态 pod 在 Kubernetes 的 apiserver 上创建一个镜像 Pod（Mirror Pod），因此我们可以在 apiserver 中查询到该 pod，但是不能通过 apiserver 进行控制（例如不能删除）。

创建静态 Pod 有两种方式：配置文件和 HTTP 两种方式

2.1 配置文件

配置文件就是放在特定目录下的标准的 JSON 或 YAML 格式的 pod 定义文件。用kubelet --pod-manifest-path=<the directory>来启动kubelet进程，kubelet 定期的去扫描这个目录，根据这个目录下出现或消失的 YAML/JSON 文件来创建或删除静态 pod。

比如我们在 node01 这个节点上用静态 pod 的方式来启动一个 nginx 的服务。我们登录到node01节点上面，可以通过下面命令找到kubelet对应的启动配置文件

[root@node01 ~]# systemctl status kubelet | grep Active
   Active: active (running) since 一 2021-02-15 04:36:35 CST; 2 days ago

配置文件路径为：

[root@node01 ~]# sed -n "3p" /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"

打开这个文件我们可以看到其中有一条如下的环境变量配置： Environment="KUBELET_SYSTEM_PODS_ARGS=--pod-manifest-path=/etc/kubernetes/manifests --allow-privileged=true"

所以如果我们通过kubeadm的方式来安装的集群环境，对应的kubelet已经配置了我们的静态 Pod 文件的路径，那就是/etc/kubernetes/manifests，所以我们只需要在该目录下面创建一个标准的 Pod 的 JSON 或者 YAML 文件即可：

如果你的 kubelet 启动参数中没有配置上面的--pod-manifest-path参数的话，那么添加上这个参数然后重启 kubelet 即可。

[root@node01 ~]# cat <<EOF >/etc/kubernetes/manifests/static-web.yaml
apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    app: static
spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
EOF

2.2 通过 HTTP 创建静态 Pods

kubelet 周期地从–manifest-url=参数指定的地址下载文件，并且把它翻译成 JSON/YAML 格式的 pod 定义。此后的操作方式与–pod-manifest-path=相同，kubelet 会不时地重新下载该文件，当文件变化时对应地终止或启动静态 pod。

2.3 静态pods的动作行为

kubelet 启动时，由--pod-manifest-path= or --manifest-url=参数指定的目录下定义的所有 pod 都会自动创建，例如，我们示例中的 static-web。（可能要花些时间拉取nginx 镜像，耐心等待…）

[root@node01 ~]# docker ps -a | head -2
CONTAINER ID        IMAGE                                                                                            COMMAND                  CREATED              STATUS                    PORTS               NAMES
35e480e819a1        nginx@sha256:10b8cc432d56da8b61b070f4c7d2543a9ed17c2b23010b43af434fd40e2ca4aa                    "/docker-entrypoin..."   15 seconds ago       Up 15 seconds                                 k8s_web_static-web-node01_default_70913446a862843697c1c446d325f177_0

现在我们通过kubectl工具可以看到这里创建了一个新的镜像 Pod：

[root@node01 ~]# kubectl get pods
NAME                READY     STATUS    RESTARTS   AGE
kube100-site        2/2       Running   0          24m
static-web-node01   1/1       Running   0          3m  #这里创建了一个新的镜像 Pod

静态 pod 的标签会传递给镜像 Pod，可以用来过滤或筛选。 需要注意的是，我们不能通过 API 服务器来删除静态 pod（例如，通过kubectl命令），kebelet 不会删除它。

[root@node01 ~]# kubectl delete pod static-web-node01
pod "static-web-node01" deleted

[root@node01 ~]# kubectl get pods
NAME                READY     STATUS    RESTARTS   AGE
kube100-site        2/2       Running   0          26m
static-web-node01   1/1       Running   0          25s   #自动重启容器

我们尝试手动终止容器，可以看到kubelet很快就会自动重启容器。

[root@node01 ~]# docker ps -a | head -2
CONTAINER ID        IMAGE                                                                                            COMMAND                  CREATED              STATUS                    PORTS               NAMES
35e480e819a1        nginx@sha256:10b8cc432d56da8b61b070f4c7d2543a9ed17c2b23010b43af434fd40e2ca4aa                    "/docker-entrypoin..."   About a minute ago   Up About a minute                             k8s_web_static-web-node01_default_70913446a862843697c1c446d325f177_0

2.4 静态pods的动态增加和删除

运行中的kubelet周期扫描配置的目录（我们这个例子中就是/etc/kubernetes/manifests）下文件的变化，当这个目录中有文件出现或消失时创建或删除pods。

[root@node01 ~]#  mv /etc/kubernetes/manifests/static-web.yaml /tmp
[root@node01 ~]#  sleep 20
[root@node01 ~]#  docker ps -a
// no nginx container is running

[root@node01 ~]#  mv /tmp/static-web.yaml  /etc/kubernetes/manifests
[root@node01 ~]#  sleep 20

[root@node01 ~]# docker ps -a | head -2
CONTAINER ID        IMAGE                                                                                            COMMAND                  CREATED             STATUS                    PORTS               NAMES
35e480e819a1        nginx@sha256:10b8cc432d56da8b61b070f4c7d2543a9ed17c2b23010b43af434fd40e2ca4aa                    "/docker-entrypoin..."   3 minutes ago       Up 3 minutes                                  k8s_web_static-web-node01_default_70913446a862843697c1c446d325f177_0

其实我们用 kubeadm 安装的集群，master 节点上面的几个重要组件都是用静态 Pod 的方式运行的，我们登录到 master 节点上查看/etc/kubernetes/manifests目录：

[root@master ~]# ls /etc/kubernetes/manifests/
etcd.yaml  kube-apiserver.yaml  kube-controller-manager.yaml  kube-scheduler.yaml

现在明白了吧，这种方式也为我们将集群的一些组件容器化提供了可能，因为这些 Pod 都不会受到 apiserver 的控制，不然我们这里kube-apiserver怎么自己去控制自己呢？万一不小心把这个 Pod 删掉了呢？所以只能有kubelet自己来进行控制，这就是我们所说的静态 Pod。

3. Pod Hook

我们知道Pod是Kubernetes集群中的最小单元，而 Pod 是有容器组组成的，所以在讨论 Pod 的生命周期的时候我们可以先来讨论下容器的生命周期。

实际上 Kubernetes 为我们的容器提供了生命周期钩子的，就是我们说的Pod Hook，Pod Hook 是由 kubelet 发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中。我们可以同时为 Pod 中的所有容器都配置 hook。

Kubernetes 为我们提供了两种钩子函数：

• PostStart：这个钩子在容器创建后立即执行。但是，并不能保证钩子将在容器ENTRYPOINT之前运行，因为没有参数传递给处理程序。主要用于资源部署、环境准备等。不过需要注意的是如果钩子花费太长时间以至于不能运行或者挂起， 容器将不能达到running状态。
• PreStop：这个钩子在容器终止之前立即被调用。它是阻塞的，意味着它是同步的， 所以它必须在删除容器的调用发出之前完成。主要用于优雅关闭应用程序、通知其他系统等。如果钩子在执行期间挂起， Pod阶段将停留在running状态并且永不会达到failed状态。

如果PostStart或者PreStop钩子失败， 它会杀死容器。所以我们应该让钩子函数尽可能的轻量。当然有些情况下，长时间运行命令是合理的， 比如在停止容器之前预先保存状态。

另外我们有两种方式来实现上面的钩子函数：

• Exec - 用于执行一段特定的命令，不过要注意的是该命令消耗的资源会被计入容器。
• HTTP - 对容器上的特定的端点执行HTTP请求。

3.1 示例1 环境准备

以下示例中，定义了一个Nginx Pod，其中设置了PostStart钩子函数，即在容器创建成功后，写入一句话到/usr/share/message文件中。

[root@node01 ~]# vim hook-demo1.yaml
[root@node01 ~]# cat hook-demo1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: hook-demo1
spec:
  containers:
  - name: hook-demo1
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]

#验证结果
[root@node01 ~]# kubectl create -f hook-demo1.yaml 
pod "hook-demo1" created
[root@node01 ~]# kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
hook-demo1                      1/1       Running   0          8s

[root@node01 ~]# kubectl exec hook-demo1 -it /bin/bash
root@hook-demo1:/# cat /usr/share/message
Hello from the postStart handler

3.2 示例2 优雅删除资源对象

当用户请求删除含有 pod 的资源对象时（如Deployment等），K8S 为了让应用程序优雅关闭（即让应用程序完成正在处理的请求后，再关闭软件），K8S提供两种信息通知：

• 默认：K8S 通知 node 执行docker stop命令，docker 会先向容器中PID为1的进程发送系统信号SIGTERM，然后等待容器中的应用程序终止执行，如果等待时间达到设定的超时时间，或者默认超时时间（30s），会继续发送SIGKILL的系统信号强行 kill 掉进程。
• 使用 pod 生命周期（利用PreStop回调函数），它执行在发送终止信号之前。

默认所有的优雅退出时间都在30秒内。kubectl delete 命令支持 --grace-period=<seconds>选项，这个选项允许用户用他们自己指定的值覆盖默认值。值'0'代表 强制删除 pod. 在 kubectl 1.5 及以上的版本里，执行强制删除时必须同时指定 --force --grace-period=0。

强制删除一个 pod 是从集群状态还有 etcd 里立刻删除这个 pod。 当 Pod 被强制删除时， api 服务器不会等待来自 Pod 所在节点上的 kubelet 的确认信息：pod 已经被终止。在 API 里 pod 会被立刻删除，在节点上， pods 被设置成立刻终止后，在强行杀掉前还会有一个很小的宽限期。

以下示例中，定义了一个Nginx Pod，其中设置了PreStop钩子函数，即在容器退出之前，优雅的关闭 Nginx:

apiVersion: v1
kind: Pod
metadata:
  name: hook-demo2
spec:
  containers:
  - name: hook-demo2
    image: nginx
    lifecycle:
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

---

[root@node01 ~]# vim hook-demo2.yaml 
[root@node01 ~]# cat hook-demo2.yaml 
---
apiVersion: v1
kind: Pod
metadata:
  name: hook-demo2
  labels:
    app: hook
spec:
  containers:
  - name: hook-demo2
    image: nginx
    ports:
    - name: webport
      containerPort: 80
    volumeMounts:
    - name: message
      mountPath: /usr/share/
    lifecycle:
      preStop:
        exec:
          command: ['/bin/sh', '-c', 'echo Hello from the preStop Handler > /usr/share/message']
  volumes:
  - name: message
    hostPath:
      path: /tmp

[root@node01 ~]# kubectl create -f hook-demo2.yaml 
pod "hook-demo2" created
[root@node01 ~]# kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
hook-demo2                      1/1       Running   0          7s

[root@node01 ~]# kubectl delete pod hook-demo2
pod "hook-demo2" deleted
[root@node01 ~]# kubectl get pods    #稍等时间即删除
NAME                            READY     STATUS        RESTARTS   AGE
hook-demo2                      0/1       Terminating   0          55s

[root@node01 ~]# cat /tmp/message 
Hello from the preStop Handler

另外Hook调用的日志没有暴露个给 Pod 的 event，所以只能通过describe命令来获取，如果有错误将可以看到FailedPostStartHook或FailedPreStopHook这样的 event。

4. 健康检查

上节课我们和大家一起学习了Pod中容器的生命周期的两个钩子函数，PostStart与PreStop，其中PostStart是在容器创建后立即执行的，而PreStop这个钩子函数则是在容器终止之前执行的。除了上面这两个钩子函数以外，还有一项配置会影响到容器的生命周期的，那就是健康检查的探针。

在Kubernetes集群当中，我们可以通过配置liveness probe（存活探针）和readiness probe（可读性探针）来影响容器的生存周期。

• kubelet 通过使用 liveness probe 来确定你的应用程序是否正在运行，通俗点将就是是否还活着。一般来说，如果你的程序一旦崩溃了， Kubernetes 就会立刻知道这个程序已经终止了，然后就会重启这个程序。而我们的 liveness probe 的目的就是来捕获到当前应用程序还没有终止，还没有崩溃，如果出现了这些情况，那么就重启处于该状态下的容器，使应用程序在存在 bug 的情况下依然能够继续运行下去。
• kubelet 使用 readiness probe 来确定容器是否已经就绪可以接收流量过来了。这个探针通俗点讲就是说是否准备好了，现在可以开始工作了。只有当 Pod 中的容器都处于就绪状态的时候 kubelet 才会认定该 Pod 处于就绪状态，因为一个 Pod 下面可能会有多个容器。当然 Pod 如果处于非就绪状态，那么我们就会将他从我们的工作队列(实际上就是我们后面需要重点学习的 Service)中移除出来，这样我们的流量就不会被路由到这个 Pod 里面来了。

和前面的钩子函数一样的，我们这两个探针的支持两种配置方式：

• exec：执行一段命令
• http：检测某个 http 请求
• tcpSocket：使用此配置， kubelet

将尝试在指定端口上打开容器的套接字。如果可以建立连接，容器被认为是健康的，如果不能就认为是失败的。实际上就是检查端口

4.1 exec

好，我们先来给大家演示下存活探针的使用方法，首先我们用exec执行命令的方式来检测容器的存活，如下:

[root@node01 ~]# vim liveness-exec.yaml
[root@node01 ~]# cat liveness-exec.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
  labels:
    test: liveness
spec:
  containers:
  - name: liveness
    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

我们这里需要用到一个新的属性：livenessProbe，下面通过exec执行一段命令，其中periodSeconds属性表示让kubelet每隔5秒执行一次存活探针，也就是每5秒执行一次上面的cat /tmp/healthy命令，如果命令执行成功了，将返回0，那么kubelet就会认为当前这个容器是存活的并且很监控，如果返回的是非0值，那么kubelet就会把该容器杀掉然后重启它。另外一个属性initialDelaySeconds表示在第一次执行探针的时候要等待5秒，这样能够确保我们的容器能够有足够的时间启动起来。大家可以想象下，如果你的第一次执行探针等候的时间太短，是不是很有可能容器还没正常启动起来，所以存活探针很可能始终都是失败的，这样就会无休止的重启下去了，对吧？所以一个合理的initialDelaySeconds非常重要。

另外我们在容器启动的时候，执行了如下命令：

bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

意思是说在容器最开始的30秒内有一个/tmp/healthy文件，在这30秒内执行cat /tmp/healthy命令都会返回一个成功的返回码。30秒后，我们删除这个文件，现在执行cat /tmp/healthy是不是就会失败了，这个时候就会重启容器了。

我们来创建下该Pod

[root@node01 ~]# kubectl apply -f liveness-exec.yaml 
pod "liveness-exec" created

[root@node01 ~]#  kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
liveness-exec                   1/1       Running   0          44s

在30秒内，查看Pod的Event：

[root@node01 ~]# kubectl describe pod liveness-exec

我们可以观察到容器是正常启动的，在隔一会儿，比如40s后，再查看下Pod的Event，在最下面有一条信息显示 liveness probe失败了，容器被删掉并重新创建。

然后通过kubectl get pod liveness-exec可以看到RESTARTS值加1了。

[root@node01 ~]#  kubectl get pods
NAME                            READY     STATUS    RESTARTS   AGE
liveness-exec                   1/1       Running   1          1m

4.2 HTTP GET

同样的，我们还可以使用HTTP GET请求来配置我们的存活探针，我们这里使用一个liveness镜像来验证演示下，

[root@node01 ~]# vim liveness-http.yaml
[root@node01 ~]# cat liveness-http.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-http
spec:
  containers:
  - name: liveness
    image: cnych/liveness
    args:
    - /server
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: X-Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

同样的，根据periodSeconds属性我们可以知道kubelet需要每隔3秒执行一次liveness probe，该探针将向容器中的 server 的8080端口发送一个 HTTP GET 请求。如果 server 的 /healthz 路径的 handler 返回一个成功的返回码，kubelet就会认定该容器是活着的并且很健康,如果返回失败的返回码，kubelet将杀掉该容器并重启它。。initialDelaySeconds 指定kubelet在该执行第一次探测之前需要等待3秒钟。

通常来说，任何大于200小于400的返回码都会认定是成功的返回码。其他返回码都会被认为是失败的返回码。

我们可以来查看下上面的healthz的实现：

http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
    duration := time.Now().Sub(started)
    if duration.Seconds() > 10 {
        w.WriteHeader(500)
        w.Write([]byte(fmt.Sprintf("error: %v", duration.Seconds())))
    } else {
        w.WriteHeader(200)
        w.Write([]byte("ok"))
    }
})

大概意思就是最开始前10s返回状态码200，10s过后就返回500的status_code了。所以当容器启动3秒后，kubelet 开始执行健康检查。第一次健康监测会成功，因为是在10s之内，但是10秒后，健康检查将失败，因为现在返回的是一个错误的状态码了，所以kubelet将会杀掉和重启容器。

同样的，我们来创建下该Pod测试下效果

[root@node01 ~]# kubectl apply -f liveness-http.yaml 
pod "liveness-http" created

[root@node01 ~]#  kubectl get pods
NAME                            READY     STATUS             RESTARTS   AGE
liveness-http                   1/1       Running            0          10s

10秒后，查看 Pod 的 event，确认liveness probe失败并重启了容器。

[root@node01 ~]# kubectl describe pod liveness-http

然后我们来通过端口的方式来配置存活探针，使用此配置，kubelet将尝试在指定端口上打开容器的套接字。 如果可以建立连接，容器被认为是健康的，如果不能就认为是失败的。

[root@node01 ~]# cat liveness-readiness.yaml
apiVersion: v1
kind: Pod
metadata:
  name: goproxy
  labels:
    app: goproxy
spec:
  containers:
  - name: goproxy
    image: cnych/goproxy
    ports:
    - containerPort: 8080
    readinessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

我们可以看到，TCP 检查的配置与 HTTP 检查非常相似，只是将httpGet替换成了tcpSocket。 而且我们同时使用了readiness probe和liveness probe两种探针。 容器启动后5秒后，kubelet将发送第一个readiness probe（可读性探针）。 该探针会去连接容器的8080端，如果连接成功，则该 Pod 将被标记为就绪状态。然后Kubelet将每隔10秒钟执行一次该检查。

除了readiness probe之外，该配置还包括liveness probe。 容器启动15秒后，kubelet将运行第一个 liveness probe。 就像readiness probe一样，这将尝试去连接到容器的8080端口。如果liveness probe失败，容器将重新启动。

有的时候，应用程序可能暂时无法对外提供服务，例如，应用程序可能需要在启动期间加载大量数据或配置文件。 在这种情况下，您不想杀死应用程序，也不想对外提供服务。 那么这个时候我们就可以使用readiness probe来检测和减轻这些情况。 Pod中的容器可以报告自己还没有准备，不能处理Kubernetes服务发送过来的流量。

从上面的YAML文件我们可以看出readiness probe的配置跟liveness probe很像，基本上一致的。唯一的不同是使用readinessProbe而不是livenessProbe。两者如果同时使用的话就可以确保流量不会到达还未准备好的容器，准备好过后，如果应用程序出现了错误，则会重新启动容器。

另外除了上面的initialDelaySeconds和periodSeconds属性外，探针还可以配置如下几个参数：

• timeoutSeconds：探测超时时间，默认1秒，最小1秒。
• successThreshold：探测失败后，最少连续探测成功多少次才被认定为成功。默认是 1，但是如果是liveness则必须是 1。最小值是 1。
• failureThreshold：探测成功后，最少连续探测失败多少次才被认定为失败。默认是 3，最小值是 1。

这就是liveness probe（存活探针）和readiness probe（可读性探针）的使用方法。

5. 初始化容器

上节课我们学习了容器的健康检查的两个探针：liveness probe（存活探针）和readiness probe（可读性探针）的使用方法，我们说在这两个探针是可以影响容器的生命周期的，包括我们之前提到的容器的两个钩子函数PostStart和PreStop。我们今天要给大家介绍的是Init Container（初始化容器）。

Init Container就是用来做初始化工作的容器，可以是一个或者多个，如果有多个的话，这些容器会按定义的顺序依次执行，只有所有的Init Container执行完后，主容器才会被启动。我们知道一个Pod里面的所有容器是共享数据卷和网络命名空间的，所以Init Container里面产生的数据可以被主容器使用到的。

是不是感觉Init Container和之前的钩子函数有点类似啊，只是是在容器执行前来做一些工作，是吧？从直观的角度看上去的话，初始化容器的确有点像PreStart，但是钩子函数和我们的Init Container是处在不同的阶段的，我们可以通过下面的图来了解下：

从上面这张图我们可以直观的看到PostStart和PreStop包括liveness和readiness是属于主容器的生命周期范围内的，而Init Container是独立于主容器之外的，当然他们都属于Pod的生命周期范畴之内的，现在我们应该明白Init Container和钩子函数之类的区别了吧。

另外我们可以看到上面我们的Pod右边还有一个infra的容器，这是一个什么容器呢？我们可以在集群环境中去查看下人任意一个Pod对应的运行的Docker容器，我们可以发现每一个Pod下面都包含了一个pause-amd64的镜像，这个就是我们的infra镜像，我们知道Pod下面的所有容器是共享同一个网络命名空间的，这个镜像就是来做这个事情的，所以每一个Pod当中都会包含一个这个镜像。

很多同学最开始 Pod 启动不起来就是因为这个 infra 镜像没有被拉下来，因为默认该镜像是需要到谷歌服务器上拉取的，所以需要提前拉取到节点上面。

我们说Init Container主要是来做初始化容器工作的，那么他有哪些应用场景呢？

• 等待其他模块Ready：这个可以用来解决服务之间的依赖问题，比如我们有一个 Web 服务，该服务又依赖于另外一个数据库服务，但是在我们启动这个 Web 服务的时候我们并不能保证依赖的这个数据库服务就已经启动起来了，所以可能会出现一段时间内 Web 服务连接数据库异常。要解决这个问题的话我们就可以在 Web 服务的 Pod 中使用一个 InitContainer，在这个初始化容器中去检查数据库是否已经准备好了，准备好了过后初始化容器就结束退出，然后我们的主容器 Web 服务被启动起来，这个时候去连接数据库就不会有问题了。
• 做初始化配置：比如集群里检测所有已经存在的成员节点，为主容器准备好集群的配置信息，这样主容器起来后就能用这个配置信息加入集群。
• 其它场景：如将 pod 注册到一个中央数据库、配置中心等。

我们先来给大家演示下服务依赖的场景下初始化容器的使用方法，如下Pod的定义方法

[root@node01 ~]# vim init-pod.yaml
[root@node01 ~]# cat init-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: init-pod
  labels:
    app: init
spec:
  containers:
  - name: init-container
    image: busybox
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh', '-c', 'until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox
    command: ['sh', '-c', 'until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

我们可以先创建上面的Pod，然后查看下Pod的状态

[root@node01 ~]# kubectl apply -f init-pod.yaml 
pod "init-pod" created

[root@node01 ~]# kubectl get pods
NAME                            READY     STATUS     RESTARTS   AGE
init-pod                        0/1       Init:0/2   0          3s

然后再创建下面的Service，对比下前后状态。

Service的对应YAML内容：

#myservice
[root@node01 ~]# vim myservice.yaml 
[root@node01 ~]# cat myservice.yaml 
---
kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 6376
    
[root@node01 ~]# kubectl apply -f myservice.yaml 
service "myservice" unchanged
[root@node01 ~]# kubectl get pods         #状态已完成一个
NAME                            READY     STATUS     RESTARTS   AGE
init-pod                        0/1       Init:1/2   0          3m   

查看下Pod的状态

#mydb
[root@node01 ~]# vim mydb.yaml
[root@node01 ~]# cat mydb.yaml
---
kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 6377
    
[root@node01 ~]# kubectl apply -f mydb.yaml 
service "mydb" created
[root@node01 ~]# kubectl get pods         #可以看见状态已经处于运行状态
NAME                            READY     STATUS    RESTARTS   AGE
init-pod                        1/1       Running   0          9m

查看下Pod的状态

我们在Pod启动过程中，初始化容器会按顺序在网络和数据卷初始化之后启动。每个容器必须在下一个容器启动之前成功退出。如果由于运行时或失败退出，导致容器启动失败，它会根据Pod的restartPolicy指定的策略进行重试。 然而，如果 Pod 的 restartPolicy 设置为 Always，Init 容器失败时会使用 RestartPolicy 策略。

在所有的初始化容器没有成功之前，Pod将不会变成 Ready状态。正在初始化中的Pod处于Pending状态，但应该会将条件Initializing设置为 true。

接下来我们再来尝试创建一个做初始化配置工作的Pod：

[root@node01 ~]# vim init-demo.yaml
[root@node01 ~]# cat init-demo.yaml
apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: workdir
      mountPath: /usr/share/nginx/html
  initContainers:
  - name: install
    image: busybox
    command:
    - wget
    - "-O"
    - "/work-dir/index.html"
    - http://www.baidu.com
    volumeMounts:
    - name: workdir
      mountPath: "/work-dir"
  volumes:
  - name: workdir
    emptyDir: {}

我们可以看到这里又出现了volumes，spec.volumes指的是Pod中的卷，spec.containers.volumeMounts，是将指定的卷 mount 到容器指定的位置，相当于docker里面的-v 宿主机目录：容器目录，我们前面用到过hostPath，我们这里使用的是emptyDir{}，这个就相当于一个共享卷，是一个临时的目录，生命周期等同于Pod的生命周期。

初始化容器执行完，会下载一个 html 文件映射到emptyDir{}，而主容器也是和 spec.volumes 里的emptyDir{} 进行映射，所以nginx容器的/usr/share/nginx/html`目录下会映射 index.html 文件。

我们来创建下该Pod，然后验证nginx容器是否运行:

[root@node01 ~]# kubectl apply -f init-demo.yaml 
pod "init-demo" created

输出显示了nginx容器正在运行：

[root@node01 ~]# kubectl get pod init-demo
NAME        READY     STATUS    RESTARTS   AGE
init-demo   1/1       Running   0          11s

在 init-demo 容器里的 nginx 容器打开一个 shell：

[root@node01 ~]# kubectl exec -it init-demo -- /bin/bash

在Shell里，直接查看下 index.html 的内容：

root@init-demo:/# cat /usr/share/nginx/html/index.html

如果我们看到有百度相关的信息那么证明我们上面的初始化的工作就完成了。

这就是我们初始化容器的使用方法，到这里我们就把Pod的整个生命周期当中的几个主要阶段讲完了，第一个是容器的两个钩子函数：PostStart和PreStop，还有就是容器健康检查的两个探针：liveness probe和readiness probe，以及这节课的Init Container。