Kubernetes之Pod说明 - 运维小结

一、什么是Pod kubernetes中的一切都可以理解为是一种资源对象，pod，rc，service，都可以理解是 一种资源对象。pod的组成示意图如下，由一个叫”pause“的根容器，加上一个或多个用户自定义的容器构造。pause的状态带便了这一组容器的状态，pod里多个业务容器共享pod的Ip和数据卷。在kubernetes环境下，pod是容器的载体，所有的容器都是在pod中被管理，一个或多个容器放在pod里作为一个单元方便管理。

pod是kubernetes可以部署和管理的最小单元，如果想要运行一个容器，先要为这个容器创建一个pod。同时一个pod也可以包含多个容器，之所以多个容器包含在一个pod里，往往是由于业务上的紧密耦合。【需要注意】这里说的场景都非必须把不同的容器放在同一个pod里，但是这样往往更便于管理，甚至后面会讲到的，紧密耦合的业务容器放置在同一个容器里通信效率更高。具体怎么使用还要看实际情况,综合权衡。

在Kubrenetes集群中Pod有如下两种使用方式： a）一个Pod中运行一个容器。这是最常见用法。在这种方式中，你可以把Pod想象成是单个容器的封装，kuberentes管理的是Pod而不是直接管理容器。 b）在一个Pod中同时运行多个容器。当多个应用之间是紧耦合的关系时，可以将多个应用一起放在一个Pod中，同个Pod中的多个容器之间互相访问可以通过localhost来通信（可以把Pod理解成一个虚拟机，共享网络和存储卷）。也就是说一个Pod中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个Pod中的容器可以互相协作成为一个service单位 (即一个容器共享文件），另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。

就像每个应用容器，pod被认为是临时实体。在Pod的生命周期中，pod被创建后，被分配一个唯一的ID（UID），调度到节点上，并一致维持期望的状态直到被终结（根据重启策略）或者被删除。如果node死掉了，分配到了这个node上的pod，在经过一个超时时间后会被重新调度到其他node节点上。一个给定的pod（如UID定义的）不会被“重新调度”到新的节点上，而是被一个同样的pod取代，如果期望的话甚至可以是相同的名字，但是会有一个新的UID（查看replication controller获取详情）。

1. kubernetes为什么使用pod作为最小单元，而不是container 直接部署一个容器看起来更简单，但是这里也有更好的原因为什么在容器基础上抽象一层呢？根本原因是为了管理容器，kubernetes需要更多的信息，比如重启策略，它定义了容器终止后要采取的策略;或者是一个可用性探针，从应用程序的角度去探测是否一个进程还存活着。基于这些原因，kubernetes架构师决定使用一个新的实体，也就是pod，而不是重载容器的信息添加更多属性，用来在逻辑上包装一个或者多个容器的管理所需要的信息。

2. kubernetes为什么允许一个pod里有多个容器 pod里的容器运行在一个逻辑上的"主机"上，它们使用相同的网络名称空间 (即同一pod里的容器使用相同的ip和相同的端口段区间) 和相同的IPC名称空间。它们也可以共享存储卷。这些特性使它们可以更有效的通信，并且pod可以使你把紧密耦合的应用容器作为一个单元来管理。也就是说当多个应用之间是紧耦合关系时，可以将多个应用一起放在一个Pod中，同个Pod中的多个容器之间互相访问可以通过localhost来通信（可以把Pod理解成一个虚拟机，共享网络和存储卷）。

因此当一个应用如果需要多个运行在同一主机上的容器时，为什么不把它们放在同一个容器里呢?首先，这样何故违反了一个容器只负责一个应用的原则。这点非常重要，如果我们把多个应用放在同一个容器里，这将使解决问题变得非常麻烦，因为它们的日志记录混合在了一起，并且它们的生命周期也很难管理。因此一个应用使用多个容器将更简单，更透明，并且使应用依赖解偶。并且粒度更小的容器更便于不同的开发团队共享和复用。

【需要注意】这里说到为了解偶把应用分别放在不同容器里，前面我们也强调为了便于管理管紧耦合的应用把它们的容器放在同一个pod里。一会强调耦合，一个强调解偶看似矛盾，实际上普遍存在，高内聚低耦合是我们的追求，然而一个应用的业务逻辑模块不可能完全完独立不存在耦合，这就需要我们从实际上来考量，做出决策。

因为，虽然可以使用一个pod来承载一个多层应用，但是更建议使用不同的pod来承载不同的层，因这这样你可以为每一个层单独扩容并且把它们分布到集群的不同节点上。

3. Pod中如何管理多个容器 Pod中可以同时运行多个进程（作为容器运行）协同工作，同一个Pod中的容器会自动的分配到同一个 node 上，同一个Pod中的容器共享资源、网络环境和依赖，它们总是被同时调度。需要注意：一个Pod中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。例如，你有一个容器作为web服务器运行，需要用到共享的volume，有另一个"sidecar"容器来从远端获取资源更新这些文件，如下图所示：

Pod中共享的环境包括Linux的namespace，cgroup和其他可能的隔绝环境，这一点跟Docker容器一致。在Pod的环境中，每个容器中可能还有更小的子隔离环境。Pod中的容器共享IP地址和端口号，它们之间可以通过localhost互相发现。它们之间可以通过进程间通信，需要明白的是同一个Pod下的容器是通过lo网卡进行通信。例如SystemV信号或者POSIX共享内存。不同Pod之间的容器具有不同的IP地址，不能直接通过IPC通信。Pod中的容器也有访问共享volume的权限，这些volume会被定义成pod的一部分并挂载到应用容器的文件系统中。

总而言之。Pod中可以共享两种资源：网络和存储。 1. 网络：每个Pod都会被分配一个唯一的IP地址。Pod中的所有容器共享网络空间，包括IP地址和端口。Pod内部的容器可以使用localhost互相通信。Pod中的容器与外界通信时，必须分配共享网络资源（例如使用宿主机的端口映射）。 2. 存储：可以Pod指定多个共享的Volume。Pod中的所有容器都可以访问共享的volume。Volume也可以用来持久化Pod中的存储资源，以防容器重启后文件丢失。

容器的依赖关系和启动顺序 当前,同一个pod里的所有容器都是并行启动并且没有办法确定哪一个容器必须早于哪一个容器启动。如果要想确保第一个容器早于第二个容器启动，那么就要使用到"init container"了，后面会说到。

同一pod的容器间网络通信 同一pod下的容器使用相同的网络名称空间,这就意味着他们可以通过”localhost“来进行通信,它们共享同一个Ip和相同的端口空间。

同一个pod暴露多个容器 通常pod里的容器监听不同的端口,想要被外部访问都需要暴露出去.你可以通过在一个服务里暴露多个端口或者使用不同的服务来暴露不同的端口来实现。

二、如何使用Pod 通常把Pod分为两类： - 自主式Pod ：这种Pod本身是不能自我修复的，当Pod被创建后（不论是由你直接创建还是被其他Controller），都会被Kuberentes调度到集群的Node上。直到Pod的进程终止、被删掉、因为缺少资源而被驱逐、或者Node故障之前这个Pod都会一直保持在那个Node上。Pod不会自愈。如果Pod运行的Node故障，或者是调度器本身故障，这个Pod就会被删除。同样的，如果Pod所在Node缺少资源或者Pod处于维护状态，Pod也会被驱逐。 - 控制器管理的Pod：Kubernetes使用更高级的称为Controller的抽象层，来管理Pod实例。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。虽然可以直接使用Pod，但是在Kubernetes中通常是使用Controller来管理Pod的。如下图：

每个Pod都有一个特殊的被称为"根容器"的Pause 容器。 Pause容器对应的镜像属于Kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或者多个紧密相关的用户业务容器。

Kubernetes设计这样的Pod概念和特殊组成结构有什么用意呢？ 原因一：在一组容器作为一个单元的情况下，难以对整体的容器简单地进行判断及有效地进行行动。比如一个容器死亡了，此时是算整体挂了么？那么引入与业务无关的Pause容器作为Pod的根容器，以它的状态代表着整个容器组的状态，这样就可以解决该问题。 原因二：Pod里的多个业务容器共享Pause容器的IP，共享Pause容器挂载的Volume，这样简化了业务容器之间的通信问题，也解决了容器之间的文件共享问题。

1. 静态pod 静态Pod是由kubelet进行管理，仅存在于特定Node上的Pod。它们不能通过API Server进行管理，无法与ReplicationController、Deployment或DaemonSet进行关联，并且kubelet也无法对其健康检查。静态Pod总是由kubelet创建，并且总在kubelet所在的Node上运行。创建静态Pod的方式：通过配置文件方式完成。

2. Pod容器共享Volume 同一个Pod中的多个容器可以共享Pod级别的存储卷Volume,Volume可以定义为各种类型，多个容器各自进行挂载，将Pod的Volume挂载为容器内部需要的目录。例如：Pod级别的Volume:“app-logs”,用于tomcat向其中写日志文件，busybox读日志文件。

pod-volumes-applogs.yaml文件的配置内容

apiVersion: v1
kind: Pod
metadata:
  name: volume-pod
spec:
  containers:
  - name: tomcat
    image: tomcat
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: app-logs
      mountPath: /usr/local/tomcat/logs
  - name: busybox
    image: busybox
    command: ["sh","-c","tailf /logs/catalina*.log"]
    volumeMounts:
    - name: app-logs
      mountPath: /logs
  volumes:
  - name: app-logs
    emptuDir: {}

查看日志 # kubectl logs <pod_name> -c <container_name> # kubectl exec -it <pod_name> -c <container_name> – tail /usr/local/tomcat/logs/catalina.xx.log

3. Pod的配置管理 Kubernetes v1.2的版本提供统一的集群配置管理方案 – ConfigMap：容器应用的配置管理

ConfigMap使用场景： - 生成为容器内的环境变量。 - 设置容器启动命令的启动参数（需设置为环境变量）。 - 以Volume的形式挂载为容器内部的文件或目录。

ConfigMap以一个或多个key:value的形式保存在kubernetes系统中供应用使用，既可以表示一个变量的值（例如：apploglevel=info），也可以表示完整配置文件的内容（例如：server.xml=<?xml…>…）。可以通过yaml配置文件或者使用kubectl create configmap命令的方式创建ConfigMap。

3.1）创建ConfigMap 通过yaml文件方式 cm-appvars.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  apploglevel: info
  appdatadir: /var/data

常用命令 # kubectl create -f cm-appvars.yaml # kubectl get configmap # kubectl describe configmap cm-appvars # kubectl get configmap cm-appvars -o yaml

通过kubectl命令行方式 通过kubectl create configmap创建，使用参数–from-file或–from-literal指定内容，可以在一行中指定多个参数。

1）通过–from-file参数从文件中进行创建，可以指定key的名称，也可以在一个命令行中创建包含多个key的ConfigMap。
# kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source

2）通过–from-file参数从目录中进行创建，该目录下的每个配置文件名被设置为key，文件内容被设置为value。
# kubectl create configmap NAME --from-file=config-files-dir

3）通过–from-literal从文本中进行创建，直接将指定的key=value创建为ConfigMap的内容。
# kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2

容器应用对ConfigMap的使用有两种方法： - 通过环境变量获取ConfigMap中的内容。 - 通过Volume挂载的方式将ConfigMap中的内容挂载为容器内部的文件或目录。

通过环境变量的方式 ConfigMap的yaml文件: cm-appvars.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cm-appvars
data:
  apploglevel: info
  appdatadir: /var/data

Pod的yaml文件：cm-test-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: cm-test-pod
spec:
  containers:
  - name: cm-test
    image: busybox
    command: ["/bin/sh","-c","env|grep APP"]
    env:
    - name: APPLOGLEVEL
      valueFrom:
        configMapKeyRef:
          name: cm-appvars
          key: apploglevel
    - name: APPDATADIR
      valueFrom:
        configMapKeyRef:
          name: cm-appvars
          key: appdatadir

创建命令： # kubectl create -f cm-test-pod.yaml # kubectl get pods --show-all # kubectl logs cm-test-pod

使用ConfigMap的限制条件 - ConfigMap必须在Pod之前创建 - ConfigMap也可以定义为属于某个Namespace。只有处于相同Namespace中的Pod可以引用它。 - kubelet只支持可以被API Server管理的Pod使用ConfigMap。静态Pod无法引用。 - 在Pod对ConfigMap进行挂载操作时，容器内只能挂载为“目录”，无法挂载为文件。

4. Pod的生命周期 - Pod的状态

- Pod的重启策略

说明： 可以管理Pod的控制器有Replication Controller，Job，DaemonSet，及kubelet（静态Pod）。 - RC和DaemonSet：必须设置为Always，需要保证该容器持续运行。 - Job：OnFailure或Never，确保容器执行完后不再重启。 - kubelet：在Pod失效的时候重启它，不论RestartPolicy设置为什么值，并且不会对Pod进行健康检查。

- 常见的状态转换场景

5. Pod健康检查 Pod的健康状态由两类探针来检查：LivenessProbe 和 ReadinessProbe。

- LivenessProbe 1. 用于判断容器是否存活（running状态）。 2. 如果LivenessProbe探针探测到容器非健康，则kubelet将杀掉该容器，并根据容器的重启策略做相应处理。 3. 如果容器不包含LivenessProbe探针，则kubelet认为该探针的返回值永远为“success”。

- ReadinessProbe 1. 用于判断容器是否启动完成（read状态），可以接受请求。 2. 如果ReadnessProbe探针检测失败，则Pod的状态将被修改。Endpoint Controller将从Service的Endpoint中删除包含该容器所在Pod的Endpoint。

kubelet定期执行LivenessProbe探针来判断容器的健康状态。

LivenessProbe参数： initialDelaySeconds：启动容器后首次进行健康检查的等待时间，单位为秒。 timeoutSeconds：健康检查发送请求后等待响应的时间，如果超时响应kubelet则认为容器非健康，重启该容器，单位为秒。

LivenessProbe三种实现方式： 1）ExecAction：在一个容器内部执行一个命令，如果该命令状态返回值为0，则表明容器健康。

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: tomcagcr.io/google_containers/busybox
    args:
    - /bin/sh
    - -c
    - echo ok > /tmp/health;sleep 10;rm -fr /tmp/health;sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/health
      initialDelaySeconds: 15
      timeoutSeconds: 1

2）TCPSocketAction：通过容器IP地址和端口号执行TCP检查，如果能够建立TCP连接，则表明容器健康。

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containnerPort: 80
    livenessProbe:
      tcpSocket:
        port: 80
      initialDelaySeconds: 15
      timeoutSeconds: 1

3）HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于等于400，则认为容器健康。

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-healthcheck
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containnerPort: 80
    livenessProbe:
      httpGet:
        path: /_status/healthz
        port: 80
      initialDelaySeconds: 15
      timeoutSeconds: 1

6. Pod调度 在kubernetes集群中，Pod（container）是应用的载体，一般通过RC、Deployment、DaemonSet、Job等对象来完成Pod的调度与自愈功能。

- RC、Deployment：全自动调度 RC的功能即保持集群中始终运行着指定个数的Pod。在调度策略上主要有： - 系统内置调度算法[最优Node] - NodeSelector[定向调度] - NodeAffinity[亲和性调度]