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