一 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 ' '; 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 ' '; cat /etc/labels; fi; 23 if [[ -e /etc/annotations ]]; then 24 echo -en ' '; 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自身的信息，然后写入主程序配置文件中，最后启动主程序。