Pod使用

Pod对象使用进阶

Projected Volume

Projected Volume 是 kubernetes v1.11 之后的新特性。在 Kubernetes 中，有几种特殊的 Volume ；这些特殊的 Volume 是为容器提供预先定义好的数据。所以，从容器的角度来看，这些 Volume 里的信息就像是被 Kubernetes “投射”(Project)进入容器的。
目前，Kubernetes 支持的 Projected Volume 总共有 4 种：

1. Secret
2. ConfigMap
3. Downward API
4. ServiceAccountToken

Secret

Secret 的作用是把 Pod 需要访问的加密数据，存放到 Etcd 中。然后，可以在 Pod 中的容器里以挂载 Volume 的方式，访问 Secret 的信息。
Secret 最典型的使用场景，莫过于存放数据库的 Credential 信息，比如下面这个例子：

apiVersion: v1
kind: Pod
metadata:
  name: test-projected-volume 
spec:
  containers:
  - name: test-secret-volume
    image: busybox
    args:
    - sleep
    - "86400"
    volumeMounts:
    - name: mysql-cred
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: mysql-cred
    projected:
      sources:
      - secret:
          name: user
      - secret:
          name: pass

上述例子中的容器所挂载的 Volume 是 projected 类型的；而这个 Volume 的数据来源(sources)，则是名为 user 和 pass 的 Secret 对象，分别对应数据库的用户名和密码。
可以使用如下命令创建 Secret 对象：

$ cat ./username.txt
admin
$ cat ./password.txt
c1oudc0w!

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

通过挂载方式进入到容器里的 Secret，一旦其对应的 Etcd 里的数据被更新，这些 Volume 里的文件内容，同样也会被更新。但是，这个更新可能会有延迟。

ConfigMap

ConfigMap 与 Secret 的用法几乎完全相同，其区别是 ConfigMap 保存的是不需要加密的、应用所需的配置信息。

Downward API

Downward API 的作用是：让 Pod 里的容器能够直接获取到这个 Pod API 对象本身的信息。
但是有一点需要主要的是：Downward API 能够获取到的信息，一定是 Pod里的容器进程启动之前就能够确定下来的信息。而如果想获取 Pod 容器运行后才会出现的信息，应该在 Pod 中定义一个 sidecar 容器。
一般情况下，对于 Secret、ConfigMap、以及 Downward API 中定义的信息，建议使用 Volume(自动更新能力) 文件的方式获取。

Service Account

Service Account 对象的作用，就是 Kubernetes 进行权限分配的对象。比如，Service Account A，可以只被允许对 Kubernetes API 进行 GET 操作，而 Service Account B，则可以有 Kubernetes API 的所有操作的权限。
Service Account 授权信息和文件，实际上保存在一个叫 ServiceAccountToken 的 Secret 对象里。任何运行在 Kubernetes 集群上的应用，都必须使用这个 ServiceAccountToken 里保存的授权信息，才可以合法的访问 API Server。
Kubernetes 已经提供了一个默认的“服务账户”。

容器健康检查和恢复机制

**健康检查：**为 Pod 中的容器定义一个健康检查“探针”(Probe)，根据该 Probe 的返回值来确定这个容器的状态。这种机制，是生产环境保证应用健康存活的机制。如下所示为 Kubernetes 的一个例子：

apiVersion: v1
kind: Pod
metadata:
 labels:
    test: liveness
 name: test-liveness-exec
spec:
 containers:
  - name: liveness
    image: busybox
    imagePullPolicy: IfNotPresent
    args:
      - /bin/sh
      - -c
      - touch /tmp/healthy; sleep 15; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
              - cat
              - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

首先，创建这个 Pod：

kubectl create -f test-liveness-exec.yaml

然后查看这个 Pod 的状态：

kubectl get pod
NAME                                READY     STATUS    RESTARTS   AGE
test-liveness-exec                  1/1       Running   11261      27d

Kubernetes 中并没有 Docker 的 Stop 语义。虽然是(Restart)，但是却是重新创建了容器。这个功能就是 Kubernetes 里的 Pod 恢复机制，即任何时候这个容器发生了异常，它一定会被重新创建。有两点需要说明：

1. 无控制器控制的 Pod 的恢复过程，一定是在当前节点上；也就是说，如果一个 Pod 与一个节点绑定，除非这个绑定发生了变化，否则它永远不会离开这个节点，即使是宿主机宕机。
2. 如果想让 Pod 在重建过程中出现在其他可用的节点上，就必须使用 Deployment 这样的“控制器”来管理 Pod，哪怕业务场景只需要一个 Pod 副本。

对于重启策略和 Pod 里容器的状态，以及 Pod 状态的对应关系可以使用如下两个原理来描述：

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