深入剖析Kubernetes学习笔记：Pod基本概念（14）

一、凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。

1、这些属性的共同特征是，它们描述的是“机器”这个整体，而不是里面运行的“程序”。

1、比如，配置这个“机器”的网卡（即：Pod 的网络定义），
2、配置这个“机器”的磁盘（即：Pod 的存储定义），
3、配置这个“机器”的防火墙（即：Pod 的安全定义）。
4、更不用说，这台“机器”运行在哪个服务器之上（即：Pod 的调度）。

2、NodeSelector：是一个供用户将 Pod 与 Node 进行绑定的字段

apiVersion: v1
kind: Pod
...
spec:
 nodeSelector:
   disktype: ssd

这样的一个配置，意味着这个 Pod 永远只能运行在携带了“disktype: ssd”标签（Label）的节点上；否则，它将调度失败。

3、NodeName：一旦Pod的这个字段被赋值，Kubernetes 项目就会被认为这个 Pod 已经经过了调度

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

4、HostAliases：定义了Pod的hosts文件（比如 /etc/hosts）里的内容

apiVersion: v1
kind: Pod
...
spec:
  hostAliases:
  - ip: "10.1.2.3"
    hostnames:
    - "foo.remote"
    - "bar.remote"
...

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

cat /etc/hosts
# Kubernetes-managed hosts file.
127.0.0.1 localhost
...
10.244.135.10 hostaliases-pod
10.1.2.3 foo.remote
10.1.2.3 bar.remote

二、凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的

这个原因也很容易理解：Pod 的设计，就是要让它里面的容器尽可能多地共享 Linux Namespace，仅保留必要的隔离和限制能力。

这样，Pod 模拟出的效果，就跟虚拟机里程序间的关系非常类似了。

1、shareProcessNamespace=true这个 Pod 里的容器要共享 PID Namespace。

举个例子，在下面这个 Pod 的 YAML 文件中，我定义了 shareProcessNamespace=true：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

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

2、tty和stdin等同于设置了 docker run 里的 -it（-i 即 stdin，-t 即 tty）参数。

如果你还是不太理解它们俩的作用的话，可以直接认为 tty 就是 Linux 给用户提供的一个常驻小程序，用于接收用户的标准输入，返回操作系统的标准输出。

当然，为了能够在 tty 中输入信息，你还需要同时开启 stdin（标准输入流）。

于是，这个 Pod 被创建后，你就可以使用 shell 容器的 tty 跟这个容器进行交互了。我们一起实践一下

$ kubectl create -f nginx.yaml

接下来，我们使用 kubectl attach 命令，连接到 shell 容器的 tty 上：

$ kubectl attach -it nginx -c shell

这样，我们就可以在 shell 容器里执行 ps 指令，查看所有正在运行的进程：

$ kubectl attach -it nginx -c shell
/ # ps ax
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   14 101       0:00 nginx: worker process
   15 root      0:00 sh
   21 root      0:00 ps ax

三、凡是 Pod 中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostNetwork: true
  hostIPC: true
  hostPID: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

1、hostNetwork: true这个 Pod 里的所有容器，会直接使用宿主机的网络、直接与宿主机进行 IPC 通信

在这个 Pod 中，我定义了共享宿主机的 Network、IPC 和 PID Namespace。这就意味着，这个 Pod 里的所有容器，

会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、看到宿主机里正在运行的所有进程。

2、Containers

1、Containers的分类

2、Container 的主要字段

3、ImagePullPolicy镜像拉取的策略

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

1、Always

2、Never 或者 IfNotPresent

4、Lifecycle在容器状态发生变化时触发一系列“钩子

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 > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

1、postStart

2、preStop

3、优雅退出

四、Pod 对象在 Kubernetes 中的生命周期。

Pod 生命周期的变化，主要体现在 Pod API 对象的Status 部分，这是它除了 Metadata 和 Spec 之外的第三个重要字段。其中，pod.status.phase，

就是 Pod 的当前状态，它有如下几种可能的情况：

1、Status 部分

1、Pending

2、Running

3、Succeeded

4、Failed

5、Unknown

2、造成当前 Status 的具体原因是什么。

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

1、Unschedulable

2、Ready

Pod 的这些状态信息，是我们判断应用运行情况的重要标准，尤其是 Pod 进入了非“Running”状态后，你一定要能迅速做出反应，根据它所代表的异常情况开始跟踪和定位，而不是去手忙脚乱地查阅文档。

3、在学习完这篇文章后，我希望你能仔细阅读

$GOPATH/src/k8s.io/kubernetes/vendor/k8s.io/api/core/v1/types.go 里，type Pod struct ，尤其是 PodSpec 部分的内容。

争取做到下次看到一个 Pod 的 YAML 文件时，不再需要查阅文档，就能做到把常用字段及其作用信手拈来。