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自身的信息，然后写入主程序配置文件中，最后启动主程序。