020.掌握Pod-Pod基础使用

一 Pod定义详解

1.1 完整Pod定义文件

  1 apiVersion: v1			#必选，版本号，例如v1,版本号必须可以用 kubectl api-versions 查询到
  2 kind: Pod				#必选，Pod
  3 metadata:				#必选，元数据
  4   name: string			#必选，Pod名称，需符合RFC 1035规范
  5   namespace: string			#必选，Pod所属的命名空间，默认为"default"
  6   labels:				#自定义标签
  7     - name: string			#自定义标签名字
  8   annotations:			#自定义注释列表
  9     - name: string
 10 spec:				#必选，Pod中容器的详细定义
 11   containers:			#必选，Pod中容器列表
 12   - name: string			#必选，容器名称，需符合RFC 1035规范
 13     image: string			#必选，容器的镜像名称
 14     imagePullPolicy: [ Always|Never|IfNotPresent ]	#获取镜像的策略，Alawys表示每次都尝试下载镜像，IfnotPresent表示优先使用本地镜像,否则下载镜像，Nerver表示仅使用本地镜像
 15     command: [string]		#容器的启动命令列表，如不指定，使用打包时使用的启动命令
 16     args: [string]			#容器的启动命令参数列表
 17     workingDir: string		#容器的工作目录
 18     volumeMounts:			#挂载到容器内部的存储卷配置
 19     - name: string			#引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
 20       mountPath: string		#存储卷在容器内mount的绝对路径，应少于512字符
 21       readOnly: boolean		#是否为只读模式，默认为读写模式
 22     ports:				#需要暴露的端口库号列表
 23     - name: string			#端口的名称
 24       containerPort: int		#容器需要监听的端口号
 25       hostPort: int		        #容器所在主机需要监听的端口号，默认与Container相同
 26       protocol: string		#端口协议，支持TCP和UDP，默认TCP
 27     env:				#容器运行前需设置的环境变量列表
 28     - name: string			#环境变量名称
 29       value: string		        #环境变量的值
 30     resources:			#资源限制和请求的设置
 31       limits:			#资源限制的设置
 32         cpu: string		        #CPU的限制，单位为core数，将用于docker run --cpu-shares参数
 33         memory: string		#内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
 34       requests:			#资源请求的设置
 35         cpu: string		        #CPU请求，容器启动的初始可用数量
 36         memory: string		#内存请求,容器启动的初始可用数量
 37     livenessProbe:			#对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
 38       exec:			        #对Pod容器内检查方式设置为exec方式
 39         command: [string]		#exec方式需要制定的命令或脚本
 40       httpGet:			#对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
 41         path: string
 42         port: number
 43         host: string
 44         scheme: string
 45         HttpHeaders:
 46         - name: string
 47           value: string
 48       tcpSocket:			#对Pod内个容器健康检查方式设置为tcpSocket方式
 49          port: number
 50        initialDelaySeconds: 0	#容器启动完成后首次探测的时间，单位为秒
 51        timeoutSeconds: 0		#对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
 52        periodSeconds: 0		#对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
 53        successThreshold: 0
 54        failureThreshold: 0
 55        securityContext:
 56          privileged: false
 57     restartPolicy: [Always | Never | OnFailure]	#Pod的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
 58     nodeSelector: obeject		#设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
 59     imagePullSecrets:		#Pull镜像时使用的secret名称，以key：secretkey格式指定
 60     - name: string
 61     hostNetwork: false		#是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
 62     volumes:			#在该pod上定义共享存储卷列表
 63     - name: string			#共享存储卷名称 （volumes类型有很多种）
 64       emptyDir: {}			#类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
 65       hostPath: string		#类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
 66         path: string		#Pod所在宿主机的目录，将被用于同期中mount的目录
 67       secret:			#类型为secret的存储卷，挂载集群与定义的secre对象到容器内部
 68         scretname: string
 69         items:
 70         - key: string
 71           path: string
 72       configMap:			#类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
 73         name: string
 74         items:
 75         - key: string
 76           path: string

二 Pod的基本用法

2.1 创建Pod

Pod可以由1个或多个容器组合而成，通常对于紧耦合的两个应用，应该组合成一个整体对外提供服务，则应该将这两个打包为一个pod。

属于一个Pod的多个容器应用之间相互访问只需要通过localhost即可通信，这一组容器被绑定在一个环境中。

  1 [root@k8smaster01 study]# vi frontend-localredis-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: redis-php
  6   label:
  7     name: redis-php
  8 spec:
  9   containers:
 10   - name: frontend
 11     image: kubeguide/guestbook-php-frontend:localredis
 12     ports:
 13     - containersPort: 80
 14   - name: redis-php
 15     image: kubeguide/redis-master
 16     ports:
 17     - containersPort: 6379
 18
 19 [root@k8smaster01 study]# kubectl create -f frontend-localredis-pod.yaml
 20 

2.2 查看Pod

  1 [root@k8smaster01 study]# kubectl get pods	                #READY为2/2，表示此Pod中运行了yaml定义的两个容器
  2 NAME        READY   STATUS    RESTARTS   AGE
  3 redis-php   2/2     Running   0          7m45s
  4 [root@k8smaster01 study]# kubectl describe pod redis-php	#查看详细信息
  5 

三 静态Pod

3.1 静态Pod概述

静态pod是由kubelet进行管理的仅存在于特定Node的Pod上，他们不能通过API Server进行管理，无法与ReplicationController、Deployment或者DaemonSet进行关联，并且kubelet无法对他们进行健康检查。静态Pod总是由kubelet进行创建，并且总是在kubelet所在的Node上运行。

创建静态Pod有两种方式：配置文件或者HTTP方式。

3.2 配置文件方式创建

  1 [root@k8snode01 ~]# mkdir -p /etc/kubelet.d
  2 [root@k8snode01 ~]# vi /etc/kubelet.d/static-web.yaml
  3 apiVersion: v1
  4 kind: Pod
  5 metadata:
  6   name: static-web
  7   label:
  8     name: static-web
  9 spec:
 10   containers:
 11   - name: static-web
 12     image: nginx
 13     ports:
 14     - name: web
 15       containersPort: 80
 16
 17 [root@k8snode01 ~]# vi /etc/systemd/system/kubelet.service
 18 ……
 19   --config=/etc/kubelet.d/ \·				#加入此参数
 20 ……
 21 [root@k8snode01 ~]# systemctl daemon-reload
 22 [root@k8snode01 ~]# systemctl restart kubelet.service	#重启kubelet
 23 [root@k8snode01 ~]# docker ps				#查看创建的pod

提示：由于静态pod不能通过API Server进行管理，因此在Master节点执行删除操作后会变为Pending状态，且无法删除。删除该pod只能在其运行的node上，将定义POD的yaml删除。

3.3 HTTP方式

通过设置kubelet的启动参数--mainfest-url，会定期从该URL下载Pod的定义文件，并以.yaml或.json文件的格式进行解析，从而创建Pod。

四 Pod容器共享Volume

4.1 共享Volume

在同一个Pod中的多个容器能够共享Pod级别的存储就Volume。Volume可以被定义为各种类型，多个容器各自进行挂载操作，将一个Volume挂载为容器内部需要的目录。

示例1：

Pod级别设置Volume “app-logs”，同时Pod包含两个容器，Tomcat向该Volume写日志，busybox读取日志文件。

  1 [root@k8smaster01 study]# vi pod-volume-applogs.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: volume-pod
  6 spec:
  7   containers:
  8   - name: tomcat
  9     image: tomcat
 10     ports:
 11     - containerPort: 8080
 12     volumeMounts:
 13     - name: app-logs
 14       mountPath: /usr/local/tomcat/logs
 15   - name: logreader
 16     image: busybox
 17     command: ["sh","-c","tail -f /logs/catalina*.log"]
 18     volumeMounts:
 19     - name: app-logs
 20       mountPath: /logs
 21   volumes:
 22   - name: app-logs
 23     emptyDir: {}

解释：

Volume名：app-logs；

emptyDir：为Pod分配到Node的时候创建。无需指定宿主机的目录文件，为Kubernetes自动分配的目录。

  1 [root@k8smaster01 study]# kubectl create -f pod-volume-applogs.yaml	#创建
  2 [root@k8smaster01 study]# kubectl get pods				#查看
  3 [root@k8smaster01 study]# kubectl logs volume-pod -c busybox	#读取log

  1 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- ls /usr/local/tomcat/logs
  2 catalina.2019-06-29.log      localhost_access_log.2019-06-29.txt
  3 host-manager.2019-06-29.log  manager.2019-06-29.log
  4 localhost.2019-06-29.log
  5 [root@k8smaster01 study]# kubectl exec -it volume-pod -c tomcat -- tail /usr/local/tomcat/logs/catalina.2019-06-29.log

提示：通过tomcat容器可查看日志，对比busybox通过共享Volume查看的日志是否一致。

五 Pod配置管理

5.1 Pod配置概述

应用部署的一个最佳实践是将应用所需的配置信息与程序进行分离，使程序更加灵活。将相应的应用打包为镜像，可以通过环境变量或者外挂volume的方式在创建容器的时候进行配置注入，从而实现更好的复用。

Kubernetes提供一种统一的应用配置管理方案：ConfigMap。

5.2 ConfigMap概述

ConfigMap供容器使用的主要场景：

• 生成容器内部的环境变量；
• 设置容器的启动命令的参数（需设置为环境变量）；
• 以volume的形式挂载为容器内部的文件或者目录。

ConfigMap以一个或多个key:value的形式定义。value可以是string也可以是一个文件内容，可以通过yaml配置文件或者通过kubectl create configmap 的方式创建configMap。

5.3 创建ConfigMap资源对象——yaml方式

  1 [root@k8smaster01 study]# vi cm-appvars.yaml
  2 apiVersion: v1
  3 kind: ConfigMap
  4 metadata:
  5   name: cm-appvars
  6 data:
  7   apploglevel: info
  8   appdatadir: /var/data
  9
 10 [root@k8smaster01 study]# kubectl create -f cm-appvars.yaml
 11 configmap/cm-appvars created
 12 [root@k8smaster01 study]# kubectl get configmaps
 13 NAME         DATA   AGE
 14 cm-appvars   2      8s
 15 [root@k8smaster01 study]# kubectl describe configmaps cm-appvars

  1 [root@k8smaster01 study]# kubectl get configmaps cm-appvars -o yaml

5.4 创建ConfigMap资源对象——命令行方式

语法1

  1 # kubectl create configmap NAME --from-file=[key=]source --from-file=[key=]source

解释：通过--from-file参数从文件中创建，可以指定key名称，也可以制定多个key。

语法2

  1 # kubectl create configmap NAME --from-file=config-files-dir

解释：通过--from-file参数从目录中创建，该目录下的每个配置文件名都被设置为key，文件的内容被设置为value。

语法3

  1 # kubectl create configmap NAME --from-literal=key1=value1 --from-literal=key2=value2

解释：通过--from-literal参数从文本中创建，直接将指定的key#=value#创建为ConfigMap的内容。

5.5 Pod使用ConfigMap

容器应用使用ConfigMap有两种方式：

• 通过环境变量获取ConfigMap中的内容；
• 通过Volume挂载的方式将ConfigMap中的内容挂载为容器内容的文件或目录。

  1 [root@k8smaster01 study]# vi cm-test-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: cm-test-pod
  6 spec:
  7   containers:
  8   - name: cm-test
  9     image: busybox
 10     command: ["/bin/sh","-c","env|grep APP"]	#容器里执行查看环境变量的命令
 11     env:
 12     - name: APPLOGLEVEL				#定义容器环境变量名称
 13       valueFrom:
 14         configMapKeyRef:			#环境变量的值来自ConfigMap
 15           name: cm-appvars			#指定来自cm-appvars的ConfigMap
 16           key: apploglevel			#key为apploglevel
 17     - name: APPDATADIR
 18       valueFrom:
 19         configMapKeyRef:
 20           name: cm-appvars
 21           key: appdatadir
 22
 23 [root@k8smaster01 study]# kubectl create -f cm-test-pod.yaml
 24 [root@k8smaster01 study]# kubectl get pods
 25 NAME          READY   STATUS      RESTARTS   AGE
 26 cm-test-pod   0/1     Completed   2          24s

【挂载形式-待补充】

5.6 ConfigMap限制

• Configmap必须在pod创建之间创建；
• ConfigMap受到namespace的限制，只有同一个命名空间下才能引用；
• ConfigMap暂时无法配置配额；
• 静态的pod无法使用ConfigMap；
• 在使用volumeMount挂载的时候，configMap基于items创建的文件会整体的将挂载数据卷的容器的目录下的文件全部覆盖。

六 Pod获取自身信息

6.1 Downward API

pod拥有唯一的名字、IP地址，并且处于某个Namespace中。pod的容器内获取pod的信息科通过Downward API实现。具体有以下两种方式：

• 环境变量：用于单个变量，可以将pod信息和container信息注入容器内部；
• volume挂载：将数组类信息生成为文件，挂载至容器内部。

举例1：通过Downward API将Pod的IP、名称和所在的Namespace注入容器的环境变量。

  1 [root@k8smaster01 study]# vi dapi-test-pod.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod
  6 spec:
  7   containers:
  8     - name: test-container
  9       image: busybox
 10       command: [ "/bin/sh", "-c", "env" ]
 11       env:
 12         - name: MY_POD_NAME
 13           valueFrom:
 14             fieldRef:
 15               fieldPath: metadata.name
 16         - name: MY_POD_NAMESPACE
 17           valueFrom:
 18             fieldRef:
 19               fieldPath: metadata.namespace
 20         - name: MY_POD_IP
 21           valueFrom:
 22             fieldRef:
 23               fieldPath: status.podIP
 24   restartPolicy: Never

提示：Downward API提供如下变量：

metadata.name：Pod的名称，当Pod通过RC生成时，其名称是RC随机产生的唯一名称；

status.podIP：Pod的IP地址，POd的IP属于状态数据，而非元数据；

metadata.namespace：Pod所在的namespace。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod | grep MY_POD
  3 MY_POD_NAMESPACE=default
  4 MY_POD_IP=172.30.240.4
  5 MY_POD_NAME=dapi-test-pod
  6 

举例2：通过Downward API将Container的自愿请求和限制信息注入容器的环境变量。

  1 [root@k8smaster01 study]# vi dapi-test-pod-container-vars.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod-container-vars
  6 spec:
  7   containers:
  8     - name: test-container
  9       image: busybox
 10       imagePullPolicy: Never
 11       command: [ "/bin/sh", "-c" ]
 12       args:
 13       - while true; do
 14           echo -en '\n';
 15           printenv MY_CPU_REQUEST MY_CPU_LIMIT;
 16           printenv MY_MEM_REQUEST MY_MEM_LIMIT;
 17           sleep 3600;
 18         done;
 19       resources:
 20         requests:
 21           memory: "32Mi"
 22           cpu: "125m"
 23         limits:
 24           memory: "64Mi"
 25           cpu: "250m"
 26       env:
 27         - name: MY_CPU_REQUEST
 28           valueFrom:
 29             resourceFieldRef:
 30               containerName: test-container
 31               resource: requests.cpu
 32         - name: MY_CPU_LIMIT
 33           valueFrom:
 34             resourceFieldRef:
 35               containerName: test-container
 36               resource: limits.cpu
 37         - name: MY_MEM_REQUEST
 38           valueFrom:
 39             resourceFieldRef:
 40               containerName: test-container
 41               resource: requests.memory
 42         - name: MY_MEM_LIMIT
 43           valueFrom:
 44             resourceFieldRef:
 45               containerName: test-container
 46               resource: limits.memory
 47   restartPolicy: Never

提示：Downward API提供如下变量：

requests.cpu：容器的CPU请求值；

limits.cpu：容器的CPU限制值；

requests.memory：容器的内存请求值；

limits.memory：容器的内存限制值。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-container-vars.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-container-vars
  3 1
  4 1
  5 33554432
  6 67108864

举例3：通过Downward API将Pod的Label、Annotation列表通过Volume挂载为容器内的一个文件。

  1 [root@k8smaster01 study]# vi dapi-test-pod-volume.yaml
  2 apiVersion: v1
  3 kind: Pod
  4 metadata:
  5   name: dapi-test-pod-volume
  6   labels:
  7     zone: us-est-coast
  8     cluster: test-cluster1
  9     rack: rack-22
 10   annotations:
 11     build: two
 12     builder: john-doe
 13 spec:
 14   containers:
 15     - name: test-container
 16       image: busybox
 17       imagePullPolicy: Never
 18       command: [ "/bin/sh", "-c" ]
 19       args:
 20       - while true; do
 21           if [[ -e /etc/labels ]]; then
 22             echo -en '\n\n'; cat /etc/labels; fi;
 23           if [[ -e /etc/annotations ]]; then
 24             echo -en '\n\n'; cat /etc/annotations; fi;
 25           sleep 3600;
 26         done;
 27       volumeMounts:
 28         - name: podinfo
 29           mountPath: /etc
 30           readOnly: false
 31   volumes:
 32     - name: podinfo
 33       downwardAPI:
 34         items:
 35           - path: "labels"
 36             fieldRef:
 37               fieldPath: metadata.labels
 38           - path: "annotations"
 39             fieldRef:
 40               fieldPath: metadata.annotations

注意：Volume中的ddownwardAPI的items语法，将会以path的名称生成文件。如上所示，会在容器内生产/etc/labels和/etc/annotations两个文件，分别包含metadata.labels和metadata.annotations的全部Label。

  1 [root@k8smaster01 study]# kubectl create -f dapi-test-pod-volume.yaml
  2 [root@k8smaster01 study]# kubectl logs dapi-test-pod-volume
  3 

提示：DownwardAPI意义：

在某些集群中，集群中的每个节点需要将自身的标识（ID）及进程绑定的IP地址等信息事先写入配置文件中，进程启动时读取此类信息，然后发布到某个类似注册服务中心。此时可通过DowanwardAPI，将一个预启动脚本或Init Container，通过环境变量或文件方式获取Pod自身的信息，然后写入主程序配置文件中，最后启动主程序。