k8s关于metadata、spec.containers、spec.volumes的属性介绍（yaml格式）

目录

一.metadata常用属性

二.spec.containers子属性介绍

explain pod.spec.containers给出的参考

1.command示例演示

2.env和envFrom示例演示

3.ports部分详解

4.resources部分详解

5.startupProbe格式演示

6.terminationMessagePath和terminationMessagePolicy格式演示

7.volumeDevices格式演示

8.volumeMounts格式演示

三.spec.volumes子属性介绍

---

一.metadata常用属性

[root@k8s-master pod]# kubectl explain pod.metadata
KIND:       Pod
VERSION:    v1
​
FIELD: metadata <ObjectMeta>
​
FIELDS:
​
  labels    <map[string]string>
    #指定资源的label列表
​
  name  <string>
    #自定义名称
  namespace <string>
    #指定名称空间

二.spec.containers子属性介绍

explain pod.spec.containers给出的参考

[root@k8s-master pod]# kubectl explain pod.spec.containers
KIND:       Pod
VERSION:    v1
​
FIELD: containers <[]Container>
​
DESCRIPTION:
    List of containers belonging to the pod. Containers cannot currently be
    added or removed. There must be at least one container in a Pod. Cannot be
    updated.
    A single application container that you want to run within a pod.
    
FIELDS:
  args  <[]string>
    #容器的启动命令需要的参数列表，主要用于和docker和Dockerfile相关的配置
​
  command   <[]string>
    #启动容器后执行的命令，不指定时使用打包时使用的启动命令
​
  env   <[]EnvVar>
    #容器环境变量的配置列表
​
  envFrom   <[]EnvFromSource>
    #使用了ConfigMap来指定变量文件时，用envFrom来指定
​
  image <string>
    #镜像名称
​
  imagePullPolicy   <string>
    #镜像拉取策略，指定tag为latest默认always，tag为具体版本号，默认IfNotPresent。
    #always表示每次都尝试重新拉取镜像；
    #ifNotPresent表示如果本地有那个镜像就使用本地的，不存在时才拉取；
    #Nerver表示仅使用本地有的镜像，绝不拉取，本地没有时报错
​
  lifecycle <Lifecycle>
    #定义容器的生命周期，使得容器在启动和终止时执行特定的任务
    #可选portStart（在容器创建后立即执行的操作。这可以用于执行一些初始化任务，比如检查容器依赖的服务是否可用，或者向外部系统注册当前容器的信息等）
    #和preStop（在容器终止之前执行的操作。这可以用于执行一些清理任务，比如保存数据、发送信号给其他服务表明当前容器即将停止等）两个配置
​
  livenessProbe <Probe>
    #指定对容器进行存活性检测，检测失败会执行重启容器等操作。
    #HTTP（通过向容器提供的 HTTP 端点发送请求，并根据返回的状态码来判断容器的存活状态）
    #TCP（通过尝试建立 TCP 连接来判断容器的存活状态）
    #Exec（通过在容器内执行特定的命令，并根据命令的返回状态来判断容器的存活状态）三种探测方式
​
  name  <string> -required-
    #容器名称
​
  ports <[]ContainerPort>
    #容器需要暴露的端口列表
​
  readinessProbe    <Probe>
    #对容器实行就绪检测，确定容器是否已经准备好接受流量，检测失败则会剔除该服务直至再次检测成功
    #和livenessProbe具有同样含义的三种方式
​
  resources <ResourceRequirements>
    #资源限制和资源请求的配置
​
  restartPolicy <string>
    #指定容器的重新启动策略
    #Always（无论什么原因导致容器退出，将始终尝试重新启动容器，以确保容器一直处于运行状态）
    #OnFailture（只有在容器以非零状态退出时才会尝试重新启动容器。换句话说，如果容器正常退出（状态码为 0），则不会重新启动它）
    #Never（永远不会尝试重新启动容器。这意味着一旦容器退出，它将保持停止状态，直到人为干预为止）
​
  startupProbe  <Probe>
    #后文有格式演示，与livenessProbe和readinessProbe类似，仅在容器启动时运行一次，用于确定容器是否已经准备好接收流量
  stdin <boolean>
    #true/false，是否可以通过 kubectl attach 命令将本地标准输入连接到容器的标准输入，从而与容器进行交互
​
  stdinOnce <boolean>
    #同stdin，但只接受第一个进程的标准输入，后即关闭
​
  terminationMessagePath    <string>
    #指定容器终止时记录终止消息的文件路径
​
  terminationMessagePolicy  <string>
    #指定容器终止时记录终止消息的策略
    #File，使用terminationMessagePath所设置的值来记录
    #FallbackToLogsOnError，如果无法将终止消息写入文件，则将使用容器的日志作为终止消息的内容
    #后文有格式演示
  tty   <boolean>
    #是否分配一个交互终端环境
​
  volumeDevices <[]VolumeDevice>
    #设置将主机上的块设备映射到容器内部
    #name指定名称，devicePath指定设备路径
    #后文有格式演示
  volumeMounts  <[]VolumeMount>
    #后文有格式演示，用于将卷挂载到容器内部特定的位置，mountPath指定目标路径，readOnly可以设置是否只读
​
  workingDir    <string>
    #用于指定容器启动时的进程所在目录，对于需要在特定目录下执行命令或者读取特定路径的应用程序非常有用

1.command示例演示

（1）运行一个pod，其中有httpd和busybox两个容器，启动busybox后执行以下操作：每隔60s向/hello.txt中追加一次hello。

使用/bin/sh来执行命令，-c后面指定要执行的命令，sleep可以减少循环过多导致的资源浪费

[root@k8s-master pod]# cat mybusybox.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mybusybox
  namespace: myns
spec:
  containers:
  - name: httpd
    image: httpd
  - name: busybox  #busybox比较特殊，它相当于一个工具而不是一个软件程序，直接运行时会报错的
    image: busybox
    command: ["/bin/sh","-c","touch /hello.txt;while true;do /bin/echo hello >> /hello.txt; sleep 60; done;"]
    
[root@k8s-master pod]# kubectl exec -it mybusybox -c busybox -n myns -- /bin/sh -c "cat /hello.txt"
hello
hello
hello
hello
#在对运行的容器进行操作时也可以使用-c去指定要执行的命令，而不需要页面进入容器

（2）注意：当你的k8s是docker部署，还存在Dockerfile的情况，args选项的配置显得比较重要，command和args要实现去覆盖Dockerfile中的ENTRYPOINT功能

• command和args都没有写时，会使用Dockerfile的配置
• command写，args没有写，Dockerfile默认的配置不会生效，执行command部分
• command没写，args写，Dockerfile中配置的ENTRYPOINT的命令会生效，并使用当前args的参数
• command和args都写，Dockerfile的配置被忽略，执行command和args指定的参数

2.env和envFrom示例演示

（1）运行一个pod，pod内运行busybox容器，容器运行后为在其中创建一个用户，通过引用设置的环境变量来为该用户设置名称和密码

[root@k8s-master pod]# cat user.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myuser
  namespace: myns
spec:
  containers:
  - name: my-user
    image: busybox
    command: ["/bin/sh","-c","while true;do /bin/adduser -D $username; echo $username:$password | /bin/chpasswd; sleep 3600; done;"]
    env:
    - name: "username"
      value: "SLB"
    - name: "password"
      value: "hello123"
[root@k8s-master pod]# kubectl exec -it myuser -c my-user -n myns -- /bin/sh -c "cat /etc/passwd | grep SLB"
SLB:x:1000:1000:Linux User,,,:/home/SLB:/bin/sh
注意：env设置的变量在容器内都可以引用
 
[root@k8s-master pod]# kubectl exec -it myuser -c my-user -n myns -- /bin/sh
/ # echo $username
SLB
/ # echo $password
hello123

（2）常用方式是使用ConfigMap来将env变量存放在单独的配置文件中，再在配置中通过configMapRef进行引用，如下所示

#create去在同一个命名空间内创建一个user-config来存放用户的两个变量数据
[root@k8s-master pod]# kubectl create configmap user-config --from-literal=username=SLB1 --from-literal=password=hello123 -n myns
configmap/user-config created
​
[root@k8s-master pod]# kubectl get configMap user-config -n myns -o yaml
apiVersion: v1
data:
  password: hello123
  username: SLB1
kind: ConfigMap
metadata:
  creationTimestamp: "2023-11-11T14:14:51Z"
  name: user-config
  namespace: myns
  resourceVersion: "45414"
  uid: 86c13358-0a38-4120-84eb-e15c01aa91f3
​
[root@k8s-master pod]# cat user.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myuser
  namespace: myns
spec:
  containers:
  - name: my-user
    image: busybox
    command: ["/bin/sh","-c","while true;do /bin/adduser -D $username; echo $username:$password | /bin/chpasswd; sleep 3600; done;"]
    envFrom:
    - configMapRef:  
        name: user-config
​
[root@k8s-master pod]# kubectl exec -it myuser -c my-user -n myns -- /bin/sh -c "cat /etc/passwd | grep SLB1"
SLB1:x:1000:1000:Linux User,,,:/home/SLB1:/bin/sh

3.ports部分详解

（1）kubectl explain pod.spec.containers.ports

[root@k8s-master pod]# kubectl explain pod.spec.containers.ports
KIND:       Pod
VERSION:    v1
​
  hostIP    <string>
    #要将外部端口绑定到的主机的IP
​
  hostPort  <integer>
    #容器在主机上公开的端口，如果设置了这个选项，主机上只能是运行容器副本
  name  <string>
    #端口的名称，需要具有唯一性
​
  protocol  <string>
    #端口协议，UDP/TCP/STCP，默认TCP
  containerPort <integer> -required-
    #容器要监听的端口（0~65535）

（2）示例

创建一个nginx容器，暴露80端口

[root@k8s-master pod]# cat nginx.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
  - name: mynginx
    image: nginx
    ports:
    - name: mynginx-port
      containerPort: 80
​
[root@k8s-master pod]# kubectl describe pod mynginx -n myns | grep -A 10 "Containers:" | tail -n +2
  mynginx:
    Container ID:   containerd://727e31321598fc3065f38d9ecb50b601f81a7723d916c2d550951c6510dcfc06
    Image:          nginx
    Image ID:       docker.io/library/nginx@sha256:86e53c4c16a6a276b204b0fd3a8143d86547c967dc8258b3d47c3a21bb68d3c6
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Running
      Started:      Sat, 11 Nov 2023 22:30:08 +0800
    Ready:          True
    Restart Count:  0

4.resources部分详解

（1）容器运行时的资源配额可以通过resources部分来指定，若该容器资源配置过少自己启动不了，配置过多又会影响其他容器的正常运行

（2）参数解析

limits是用于限制容器的上限资源占用情况，一旦容器真正启动后占用资源超过limits处配置，则会被终止并重启

requests是用于规定容器的下限资源占用情况，若环境资源不足，容器无法启动

cpu是用于指定core数

memory是用于指定内存大小，单位可以是M(10^6字节)、Mi(二进制兆节，为1024^2字节)、G(10^9字节、Gi(二进制千兆字节，为1024^3字节)等

（3）示例

运行一个nginx的pod，资源上限为2cpu、1G内存，资源下为2cpu、2M内存

[root@k8s-master pod]# cat nginx.yaml 
apiiVersion: v1
kind: Pod
metadata:
  name: mynginx
  namespace: myns
  labels:
    run: nginx
    user: sulibao
spec:
  containers:
  - name: mynginx
    image: nginx
    ports:
    - name: mynginx-port
      containerPort: 80
    resources:
      limits:
        cpu: "2"
        memory: "1G"
      requests:
        cpu: "2"
        memory: "2M"

5.startupProbe格式演示

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx
    startupProbe:
      httpGet:
        path: /my
        port: 8080

6.terminationMessagePath和terminationMessagePolicy格式演示

terminationMessagePolicy 设置为 File，且通过 terminationMessagePath 指定了记录终止消息的文件路径

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx
    terminationMessagePath: /var/log/termination.log
    terminationMessagePolicy: File

7.volumeDevices格式演示

volumeDevices 将 /dev/sdb 设备映射到 mydevice 的卷中，并将其挂载到 mycontainer 容器内部

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx
    volumeDevices:
    - name: mydevice
      devicePath: /dev/sdb
  volumes:
  - name: mydevice
    hostPath:
      path: /dev/sdb

8.volumeMounts格式演示

volumeMounts 将 myvolume 的卷挂载到了 /data 路径上，且设置为只读模式

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: nginx
    volumeMounts:
    - name: myvolume
      mountPath: /data
      readOnly: true
  volumes:
  - name: myvolume
    hostPath:
      path: /mnt/data

三.spec.volumes子属性介绍

[root@k8s-master pod]# kubectl explain pod.spec.volumes
KIND:       Pod
VERSION:    v1
​
FIELD: volumes <[]Volume>
​
  azureDisk <AzureDiskVolumeSource>
    #azureDisk挂载到容器内部
​
  azureFile <AzureFileVolumeSource>
    #azureDisk挂载到容器内部，容器可以访问Azure存储中的文件
​
  cephfs    <CephFSVolumeSource>
    #Ceph 文件系统挂载到 Pod 内部，使得容器可以访问 Ceph 集群中的文件系统
​
  cinder    <CinderVolumeSource>
    #将 OpenStack Cinder 卷挂载到 Pod 内部，使得容器可以访问 OpenStack 中的块存储卷
​
  configMap <ConfigMapVolumeSource>
    #将ConfigMap中的配置数据挂载到Pod内部，可以自己创建ConfigMap使得容器可以访问这些配置数据
​
  csi   <CSIVolumeSource>
    #将外部存储系统通过 CSI 插件挂载到 Pod 内部，使得容器可以访问这些外部存储
​
  emptyDir  <EmptyDirVolumeSource>
    #在 Pod 启动时创建一个空目录，并将其挂载到 Pod 内部，使得容器可以在该目录中进行读写操作。这个空目录的生命周期与 Pod 相关联，当 Pod 被删除时，这个空目录也会被清除，不应该用于持久化存储配置
    
  hostPath  <HostPathVolumeSource>
    #将主机上的特定文件或目录挂载到Pod内部，使得容器可以访问主机上的文件系统内容。这种方式可以用于访问主机上的特定配置文件、日志目录或其他主机文件系统中的内容。
    #hostPath中的路径path是Pod创建节点的绝对路径，Pod删除后该路径下的数据不会被删除
​
  name  <string> -required-
    #指定卷的名称，该名称将在容器的 volumeMounts 中使用，以将卷挂载到容器中
    
  nfs   <NFSVolumeSource>
    #将远程的 NFS 存储挂载到 Pod 内部，使得容器可以访问远程存储中的文件。这种方式可以用于实现多个 Pod 之间共享文件或数据，同时也可以将持久化的存储挂载到 Pod 中，而且这些存储可以跨节点访问
    #通过server指定nfs服务器地址
​
  persistentVolumeClaim <PersistentVolumeClaimVolumeSource>
    #将持久化存储声明（Persistent Volume Claim）挂载为卷，用于访问持久化存储（如 PersistentVolumes）
​
  secret    <SecretVolumeSource>
    #将 Secret 对象中的数据挂载为卷，使得容器可以访问其中的敏感数据，如密码、CA证书等