pod的yaml文件各个参数的介绍

目录

NodeSelector：将pod调度到对应的标签的node节点

 nodeName：将创建的pod之间调度到指定的节点上面

shareProcessNamespace：判断pod中的容器是否会共用一个pid namespace。

 hostNetwork: 判断是否和宿主机用同一个network namespace

ImagePullPolicy：镜像的拉去策略

Lifecycle：是在容器状态发生变化时触发一系列“钩子”。

---

NodeSelector：将pod调度到对应的标签的node节点

编写一下文件，

root@master01:/opt/k8s/yaml/test# cat nginx-deploy.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        node: compute
      containers:
      - name: nginx
        image: nginx:1.8
        ports:
        - containerPort: 80
        volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: nginx-vol
      volumes:
      - name: nginx-vol
        hostPath:
          path: "/var/data"

给node打上标签。

apply查看，发现都调度到了node1上面

 nodeName：将创建的pod之间调度到指定的节点上面

apply一下，并查看，发现都调度到了node02上面

 那如果nodeSelector和nodeName一起存在呢？看一下

nodeSelector指向的是node01，而nodeName指向的是node02

 出错啦！但是调度的节点还是node02，并且会一直的创建pod。

将位置换一下，看看会发生什么？

 发现和上面的一样，出错，调度为node02，不断更新。

 我们describe一下，看看原因，发现亲和度失败。

 看到这里，我们是不是可以总结一下，nodeName调度的优先级的要高于nodeSelector的，但是执行过nodeName后并不是就不管nodeSelector了，而是再检查一下nodeSelector是否正确，如果不正确的话，亲和性（nodeAffinity）也将会报错。

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

 查看容器的hosts文件，发现已经有了

 为什么不在容器创建后再写入/etc/hosts文件中呢？

因为如果这样的话，当容器出现意外情况down机时，再重新启动容器的话，会将原来编写的/etc/hosts文件覆盖掉，所以你可以直接再yaml中编写，这样重新启动时也会自动配置，或者说你制作容器时，就直接数据写入/etc/hosts中。

shareProcessNamespace：判断pod中的容器是否会共用一个pid namespace。

如下配置，创建两个容器。一个为nginx，一个为shell。 因为busybox中没有常驻进程，所以我们需要再其中加入常驻进程来保持容器时启动的状态，其中 stdin为i，tty为t，也就是咱们，kubectl exec -it 容器   中的it，来进行交互式的输入输出的。

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

我们进入shell容器中ps看一下，发现我们的shell容器竟然能够得到我们nginx中的进程，这就是两个容器共用了一个pid namespace

没有设置共用pid namespace的ps

 

 hostNetwork: 判断是否和宿主机用同一个network namespace

如下配置，设置hsotNetwork为true。就可以共用宿主机的网络了

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

 apply一下，再查看，发现可以在容器中直接看到宿主机的网络信息，而且还可以看到宿主机下的进程，

 原始的，只能看到lo（回环网卡），tunl0（caclio的网卡），eth0@if12（容器本身创建的网卡）

 我们来kill一下进程，看看会不会影响宿主机,这里有一个nginx的进程， 

 删除后，发现进程在容器中是kill掉了，但是宿主机上面却没有

容器中

宿主机中

 所以在容器中删掉的并不是真正的进程，这也符合容器的namespace了。

ImagePullPolicy：镜像的拉去策略

 如下配置

镜像拉去策略有三种：

Always：即每次创建 Pod 都重新拉取一次镜像，也是默认的镜像拉去策略

Never：即Pod永远不会拉去这个镜像

IfNotpresent：即宿主机上不存在这个镜像时才拉取。

Lifecycle：是在容器状态发生变化时触发一系列“钩子”。

配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo1
  labels:
    app: nginx
spec:
  nodeSelector:
    node: compute
  containers:
  - name: nginx-demo1
    image: nginx:1.8
    lifecycle: 
      postStart: 
        exec: 
          command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"] 
      preStop: 
        exec: 
          command: ["/usr/sbin/nginx","-s","quit"]
    volumeMounts:
    - name: test
      mountPath: /var/share/nginx/html
    ports:
    - name: web
      containerPort: 80
  volumes:
    - name: test
      hostPath:
        path: /var/data

apply一下，看见已经写入/user/share/message

先说 postStart 吧。它指的是，在容器启动后，立刻执行一个指定的操作。需要明确的是，postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。

而类似地，preStop 发生的时机，则是容器被杀死之前（比如，收到了 SIGKILL 信号）。而需要明确的是，preStop 操作的执行，是同步的。所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。

容器健康检查：

livenessProbe ：

作用：用探针来检查容器是否健康，如果不健康的话会重启容器。

apiVersion: v1
kind: Pod
metadata:
  labels:
    info: liveness
  name: liveness-test
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

yaml中定义了一个busybox文件，启动的时候会创建一个/tmp/healthy文件，过30S后，会删除这个文件。接下来定义了一个livenessProbe的探针，内容为，运行cat /tmp/healthy命令，如果命令执行成功，将会返回0，告诉kubernetes容器运行正常；如果命令执行失败，将会返回一个非0的数，告诉容器运行异常，进行重启，这里说明一下，他并不会检查异常后直接显示失败，而是会重启容器，容器状态还是Runing状态。initiaDeplaySeconds为启动5S后进行检查，periodSeconds为每5S检查一次。

describe一下容器发现会出现下图框内内容，但是pod状态为Runing。

 用来检测web是否运行正常的两个常用配置，，你的 Pod 其实可以暴露一个健康检查 URL（比如 /healthz），或者直接让健康检查去检测应用的监听端口。

1. ################################

...
livenessProbe:
     httpGet:
       path: /healthz
       port: 8080
       httpHeaders:
       - name: X-Custom-Header
         value: Awesome
       initialDelaySeconds: 3
       periodSeconds: 3

2. ################################

    ...
    livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

PodPreset：用来补充yaml文件的。（k8s1.20以上版本禁用了此功能）

首先，先编写一个我们闭着眼都能写出的一个yaml文件，

apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
spec:
  containers:
    - name: website
      image: nginx
      ports:
        - containerPort: 80

再创建一个详细一点的yaml文件，并apply一下。

apiVersion: settings.k8s.io/v1alpha1
kind: PodPreset
metadata:
  name: allow-database
spec:
  selector:
    matchLabels:
      role: frontend
  env:
    - name: DB_PORT
      value: "6379"
  volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
    - name: cache-volume
      emptyDir: {}

我们再查看一下pod的API对象，会发现我们写的podpreset中的内容都写到了这个pod中

$ kubectl get pod website -o yaml
apiVersion: v1
kind: Pod
metadata:
  name: website
  labels:
    app: website
    role: frontend
  annotations:
    podpreset.admission.kubernetes.io/podpreset-allow-database: "resource version"
spec:
  containers:
    - name: website
      image: nginx
      volumeMounts:
        - mountPath: /cache
          name: cache-volume
      ports:
        - containerPort: 80
      env:
        - name: DB_PORT
          value: "6379"
  volumes:
    - name: cache-volume
      emptyDir: {}

其中的annotations表示这个 Pod 对象被 PodPreset 改动过。

需要说明的是，PodPreset 里定义的内容，只会在 Pod API 对象被创建之前追加在这个对象本身上，而不会影响任何 Pod 的控制器的定义。

比如，我们现在提交的是一个 nginx-deployment，那么这个 Deployment 对象本身是永远不会被 PodPreset 改变的，被修改的只是这个 Deployment 创建出来的所有 Pod。这一点请务必区分清楚。

这里有一个问题：如果你定义了同时作用于一个 Pod 对象的多个 PodPreset，会发生什么呢？

实际上，Kubernetes 项目会帮你合并（Merge）这两个 PodPreset 要做的修改。而如果它们要做的修改有冲突的话，这些冲突字段就不会被修改。