先来研究pod.spec.containers属性，这是pod配置中最为关键的一项配置

[root@master ~]# kubectl explain pod.spec.containers
KIND:     Pod
VERSION:  v1

RESOURCE: containers <[]Object>        #数组，代表可以有多个容器
FIELDS:
    name  <string>            #容器名称
    image  <string>           #容器需要的镜像地址
    imagePullPolicy  <string>        #镜像拉取策略
    command  <[]string>       #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args     <[]string>       #容器的启动命令需要的参数列表
    env      <[]Object>       #容器环境变量的配置
    ports               #容器需要暴露的端口号列表
    resources <Object>    #资源限制和资源请求的设置

这里再写一个比较简单的Pod配置文件，主要还是熟悉格式：

apiVersion: v1
kind: Pod
metadata:
  name: pod-base          # 直接和文件名保持一致就可以了
  namespace: dev         # 定义所在的命名空间
  labels:
    user: Hud98           # 这个标签随便写个
spec:
  containers:            # 关于容器的定义,定义了两个镜像
  - name: nginx
    image: nginx:latest
  - name: busybox
    image: busybox:1.30
[root@master ~]# kubectl get pod  pod-base -n dev
NAME       READY   STATUS             RESTARTS         AGE
pod-base   1/2     CrashLoopBackOff   10 (2m40s ago)   24m

1、镜像拉取策略

imagePullPolicy,用于设置镜像拉取策略，Kubernetes支持配置三种拉取策略：

● Always：总是从远程仓库拉取镜像

● IfNotPresent：本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就本地 本地没有就远程）

● Never：只使用本地镜像，从不去远程仓库拉取，本地没有就报错（一直使用本地）

默认值说明：

        ● 如果镜像tag为具体版本号，默认策略是：IfNotPresent

        ● 如果镜像tag为：latest（最终版本），默认策略是always

这里再新建一个写了拉取策略的yaml文件看看:

apiVersion: v1
kind: Pod
metadata:
  name: pod-base          # 直接和文件名保持一致就可以了
  namespace: dev         # 定义所在的命名空间
  labels:
    user: Hud98           # 这个标签随便写个
spec:
  containers:            # 关于容器的定义,定义了两个镜像
  - name: nginx
    image: nginx:1.17.0
    imagePullPolicy: Never    #看一下策略格式就行
  - name: busybox
    image: busybox:1.30

 2、启动命令

      在上面我已经生成了一个pod-base的yaml文件，看看它的状态

[root@master ~]# kubectl get pod -n dev
NAME       READY   STATUS             RESTARTS        AGE
pod-base   1/2     CrashLoopBackOff   39 (105s ago)   172m

       在这个pod中有一个nginx和一个busybox镜像，但是吧我们通过describe指令查看之后发现，这个busybox容器一直没有成功的运行，那么到底是什么原因导致了这个容器的故障呢？

       这里是因为busybox他并不是一个程序，而是类似于一个工具类的集合，Kubernetes集群启动管理后，他会自动关闭。解决的方法就是让其一直运行，这里就要用到了command配置。

创建pod-command.yaml文件内容如下：

apiVersion: v1
kind: Pod
metadata:
  name: pod-base          
  namespace: dev         
  labels:
    user: Hud98           
spec:
  containers:         
  - name: nginx
    image: nginx
    imagePullPolicy: Always  
  - name: busybox
    image: busybox:1.30
    command: ["bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]

现在来查看一下新创建的Pod：pod-command

[root@master ~]# kubectl get pod -n dev
NAME          READY   STATUS             RESTARTS         AGE
pod-base      1/2     CrashLoopBackOff   58 (4m55s ago)   4h32m
pod-command   2/2     Running            0                16m

command用于在pod中的容器初始化完毕之后运行一个命令

简单解释一下上面命令的意思：

 "/bin/sh","-c",使用sh执行命令

touch /tmp/hello.txt;  创建一个tmp/hello.txt文件

while true;do /bin/echo $(date+%T) >> /tmp/hello.txt;sleep 3;done; 每隔三秒向文件中写入当前时间

来看看容器现在是否在做我们要求的工作：

# 进入pod中的busybox容器，查看文件内容
# 这里补充一个命令kubectl exec pod名称 -n 命名空间 -it -c 容器名称 /bin/sh 在容器内部执行命令
# 使用这个命令就可以进入某个容器的内部，然后进行相关的操作了
# 比如可以查看txt文件的内容
[root@master ~]# kubectl exec pod-command -n dev -it -c busybox /bin/sh
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
/ # cat^Ctmp/hello.txt 
08:38:23
08:38:26
08:38:29

特别说明：

        通过上面的command已经可以完成启动命令和传递参数的功能，那为什么这里还要提供一个args选项，用于传递参数呢？其实这个跟Docker有点关系，Kubernetes中的command和args两项其实是实现覆盖Dockerfile中的ENTRYPOINT功能。

       1、如果command和args均没有写，那么用Dockerfile的配置

       2、如果command写了，但args没写，那么Dockerfile默认的配置会被忽略执行输入的command

       3、如果command没写，但args写了，那么Dockerfile中配置的ENTRYPOINT的命令会被执行，使用当前args的参数

       4、如果command和args都写了，那么Dockerfile的配置会被忽略，执行command并追加上args参数