linux12k8s --＞ 06Pod详解
Posted FikL-09-19
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了linux12k8s --＞ 06Pod详解相关的知识，希望对你有一定的参考价值。
文章目录
Pod详解
一、Pod介绍
1、pod的结构
每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：
# 主容器 pause
# 业务容器 user container1 user container2
-
用户程序所在的容器，数量可多可少
-
Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：
- 可以以它为依据，评估整个Pod的健康状态
-
可以在根容器上设置Ip地址，其它容器都此Ip（Pod IP），以实现Pod内部的网路通信
这里是Pod内部的通讯，Pod的之间的通讯采用虚拟二层网络技术来实现，我们当前环境用的是Flannel。
2、Pod定义
1、k8s集群中部署的最小单元
2、Pod最主要的功能管理是将一个业务或者一个调用链的所有服务（容器）
3、包含多个容器（一组容器的集合）
4、一个Pod中容器共享网络命名空间，Pod是短暂的
Pod是在集群中运行部署应用或服务的最小单元，他是可以支持很多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
比如：你运行一个操作系统发行版的软件仓库，一个nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块工作才能提供一个微服务，这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。这就是k8s中的Pod。
目前k8s中业务主要可以分为长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet 和 StatefulSet。
# Pod是k8s中最小部署单元，用来管理一个调用链的容器，它之中的主容器（pause）为整个调用链的容器提供基础网络，共享存储，监控业务容器的运行状态
1、k8s中的命名规范
1、必须小写
2、必须以字母开头
3、名称当中只能够包含字母、数字和中划线(-)
1、下面是Pod的资源清单：
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，资源类型，例如 Pod
metadata: #必选，元数据
name: string #必选，Pod名称
annotations: #选做，描述信息
nginx: nginx
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] #容器的启动命令参数列表
workingDir: string #容器的工作目录
volumeMounts: #挂载到容器内部的存储卷配置
- name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean #是否为只读模式
ports: #需要暴露的端口库号列表
- name: string #端口的名称
containerPort: 80 #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与Container相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
env: #容器运行前需设置的环境变量列表
- name: string #环境变量名称
value: string #环境变量的值
resources: #资源限制和请求的设置
limits: #资源限制的设置
cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: string #Cpu请求，容器启动的初始可用数量
memory: string #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 （volumes类型有很多种）
emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录，将被用于同期中mount的目录
secret: #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
2、查看每种资源的可配置项
# 在这里，可通过一个命令来查看每种资源的可配置项
# kubectl explain 资源类型 查看某种资源可以配置的一级属性
# kubectl explain 资源类型.属性 查看属性的子属性
[root@k8s-m-01 ~]# kubectl explain pod
KIND: Pod
VERSION: v1
FIELDS:
apiVersion <string>
kind <string>
metadata <Object>
spec <Object>
status <Object>
[root@k8s-m-01 ~]# kubectl explain pod.metadata
KIND: Pod
VERSION: v1
RESOURCE: metadata <Object>
FIELDS:
annotations <map[string]string>
clusterName <string>
creationTimestamp <string>
deletionGracePeriodSeconds <integer>
deletionTimestamp <string>
finalizers <[]string>
generateName <string>
generation <integer>
labels <map[string]string>
managedFields <[]Object>
name <string>
namespace <string>
ownerReferences <[]Object>
resourceVersion <string>
selfLink <string>
uid <string>
3、案例
1、案例1 – 部署nginx、tomcat
# kubectl explain Pod #查apiVersion版本号 v1
[root@k8s-m-01 ~]# vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: test-pod
spec:
containers:
- name: nginx
image: nginx
- name: tomcat
image: tomcat
2、案例2 – wordpress
# 1、nginx php mysql
# 2、 制作镜像
# 3、创建nginx配置文件，然后构建镜像
# 4、编写配置清单，部署
[root@k8s-m-01 ~]# vim wordpress.yaml
apiVersion: v1
kind: Pod
metadata:
name: wordpress
spec:
containers:
- name: nginx
image: nginx
- name: php
image: alvinos/php:v2-fpm-mysql
- name: mysql
image: mysql:5.7
env:
- name: MYSQL_ROOT_PASSWORD
value: "123"
# k8s部署一个yaml的应用：kubectl apply -f [配置清单]
[root@k8s-m-01 ~]# kubectl apply -f pod.yaml
pod/test-pod create
ImgPullErr : # 镜像拉取失败
ContainerCreating ： # 容器创建中
# 扩展 1、进入不是默认空间的容器
[root@k8s-m-01 ~]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pc-deployment-5c767764f5-fq47c 1/1 Running 2 78m
[root@k8s-m-01 ~]# kubectl exec -it pc-deployment-5c767764f5-fq47c -n dev -c nginx -- bash
root@pc-deployment-5c767764f5-fq47c:/# curl localhost
<h1>Welcome to nginx!</h1>
# 2、权限问题
[root@k8s-m-01 ~]# ll -a
drwxr-xr-x 3 root root 33 Jul 30 14:43 .kube
# 必须要有这个文件，否则无法创建删除pod
在kubernetes中基本所有资源的一级属性都是一样的，主要包含5部分：
-
apiVersion <string> 版本，由kubernetes内部定义，版本号必须可以用 kubectl api-versions 查询到
-
kind <string> 类型，由kubernetes内部定义，版本号必须可以用 kubectl api-resources 查询到
-
metadata <Object> 元数据，主要是资源标识和说明，常用的有name、namespace、labels等
-
spec <Object> 描述，这是配置中最重要的一部分，里面是对各种资源配置的详细描述
-
status <Object> 状态信息，里面的内容不需要定义，由kubernetes自动生成
在上面的属性中，spec是接下来研究的重点，继续看下它的常见子属性:
- containers <[]Object> 容器列表，用于定义容器的详细信息
- nodeName <String> 根据nodeName的值将pod调度到指定的Node节点上
- nodeSelector <map[]> 根据NodeSelector中定义的信息选择将该Pod调度到包含这些label的Node 上
- hostNetwork <boolean> 是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
- volumes <[]Object> 存储卷，用于定义Pod上面挂在的存储信息
- restartPolicy <string> 重启策略，表示Pod在遇到故障的时候的处理策略
4、kubernetes没有提供单独运行Pod的命令，都是通过Pod控制器来实现的
# 命令格式： kubectl run (pod控制器名称) [参数]
# --image 指定Pod的镜像
# --port 指定端口
# --namespace 指定namespace
[root@k8s-m-01 ~]# kubectl run nginx --image=nginx:latest --port=80 --namespace dev
deployment.apps/nginx created
1、 查看pod信息
# 1、查看Pod基本信息
[root@k8s-m-01 ~]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 43s
# 2、查看Pod的详细信息
[root@k8s-m-01 ~]# kubectl describe pod nginx -n dev
Name: nginx
Namespace: dev
Priority: 0
Node: node1/192.168.5.4
Start Time: Wed, 08 May 2021 09:29:24 +0800
Labels: pod-template-hash=5ff7956ff6
run=nginx
Annotations: <none>
Status: Running
IP: 10.244.1.23
IPs:
IP: 10.244.1.23
Controlled By: ReplicaSet/nginx
Containers:
nginx:
Container ID: docker://4c62b8c0648d2512380f4ffa5da2c99d16e05634979973449c98e9b829f6253c
Image: nginx:latest
Image ID: docker-pullable://nginx@sha256:485b610fefec7ff6c463ced9623314a04ed67e3945b9c08d7e53a47f6d108dc7
Port: 80/TCP
Host Port: 0/TCP
State: Running
Started: Wed, 08 May 2021 09:30:01 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-hwvvw (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-hwvvw:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-hwvvw
Optional: false
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned dev/nginx-5ff7956ff6-fg2db to node1
Normal Pulling 4m11s kubelet, node1 Pulling image "nginx:latest"
Normal Pulled 3m36s kubelet, node1 Successfully pulled image "nginx:latest"
Normal Created 3m36s kubelet, node1 Created container nginx
Normal Started 3m36s kubelet, node1 Started container nginx
2、访问Pod
# 1、获取pod IP
[root@k8s-m-01 ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE ...
nginx 1/1 Running 0 190s 10.244.1.23 node1 ...
# 2、访问POD
[root@k8s-m-01 ~]# curl http://10.244.1.23:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
</head>
<body>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
3、删除指定Pod
# 1、删除指定Pod
[root@k8s-m-01 ~]# kubectl delete pod nginx -n dev
pod "nginx" deleted
# 2、此时，显示删除Pod成功，但是再查询，发现又新产生了一个
[root@k8s-m-01 ~]# kubectl get pods -n dev
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 21s
# 这是因为当前Pod是由Pod控制器创建的，控制器会监控Pod状况，一旦发现Pod死亡，会立即重建
# 此时要想删除Pod，必须删除Pod控制器
# 3、先来查询一下当前namespace下的Pod控制器
[root@k8s-m-01 ~]# kubectl get deploy -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 9m7s
# 4、接下来，删除此PodPod控制器
[root@k8s-m-01 ~]# kubectl delete deploy nginx -n dev
deployment.apps "nginx" deleted
# 5、稍等片刻，再查询Pod，发现Pod被删除了
[root@k8s-m-01 ~]# kubectl get pods -n dev
No resources found in dev namespace.
3、配置操作
创建一个pod-nginx.yaml，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: nginx
namespace: dev
spec:
containers:
- image: nginx:latest
name: pod
ports:
- name: nginx-port
containerPort: 80
protocol: TCP
然后就可以执行对应的创建和删除命令了：
# 创建：kubectl create -f pod-nginx.yaml
# 删除：kubectl delete -f pod-nginx.yaml
3、Pod存在的意义
# 1、创建容器使用docker，一个docker对应一个容器,一个容器有进程,一个容器运行一个应用程序
# 2、pod是多进程，运行多个应用程序
# 3、一个Pod有多个容器，每个容器里面运行一个应用程序
# 4、Pod存在未来亲密性应用
1、两个应用之间进行交互
2、网络之间调用
3、两个应用需要频繁调用
4、Pod实现机制
1、共享网络 === 》 容器本身之间相互隔离的
2、共享存储
# 1、共享网络
通过Pause容器，把其他业务容器加入Pause容器里面，让所有业务中在同一个名称空间中，可以实现网络共享
# 2、共享存储
引入数据卷概念volumes,用数据卷进行持久化数据存储
二、Pod配置
主要来研究pod.spec.containers属性，这也是pod配置中最为关键的一项配置。
[root@k8s-m-01 ~]# kubectl explain pod.spec.containers
KIND: Pod
VERSION: v1
RESOURCE: containers <[]Object> # 数组，代表可以有多个容器
FIELDS:
name <string> # 容器名称
image <string> # 容器需要的镜像地址
imagePullPolicy <string> # 镜像拉取策略
command <[]string> # 容器的启动命令列表，如不指定，使用打包时使用的启动命令
args <[]string> # 容器的启动命令需要的参数列表
env <[]Object> # 容器环境变量的配置
ports <[]Object> # 容器需要暴露的端口号列表
resources <Object> # 资源限制和资源请求的设置
1、基本配置
创建pod-base.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-base
namespace: dev
labels:
user: heima
spec:
containers:
- name: nginx
image: nginx
- name: busybox
image: busybox:1.30
上面定义了一个比较简单Pod的配置，里面有两个容器：
- nginx：用nginx版本的nginx镜像创建， （nginx是一个轻量级web容器）
- busybox：用1.30版本的busybox镜像创建，（busybox是一个小巧的linux命令集合）
# 1、创建Pod
[root@master pod]# kubectl apply -f pod-base.yaml
pod/pod-base created
# 2、查看Pod状况
# READY 1/2 : 表示当前Pod中有2个容器，其中1个准备就绪，1个未就绪
# RESTARTS : 重启次数，因为有1个容器故障了，Pod一直在重启试图恢复它
[root@master pod]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-base 1/2 Running 4 95s
# 3、可以通过describe查看内部的详情
# 此时已经运行起来了一个基本的Pod，虽然它暂时有问题
[root@master pod]# kubectl describe pod pod-base -n dev
2、镜像拉取
创建pod-imagepullpolicy.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-imagepullpolicy
namespace: dev
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: Always # 用于设置镜像拉取策略
- name: busybox
image: busybox:1.30
1、三种拉取策略(重启策略)
imagePullPolicy，用于设置镜像拉取策略，kubernetes支持配置三种拉取策略：
# 1、IfNotPresent:(默认值)
本地有则使用本地镜像，本地没有则从远程仓库拉取镜像（本地有就本地，本地没远程下载）
# 2. Always：
创建Pod都会重新从远程仓库拉取一次镜像（一直远程下载）
# 3. Never：
只使用本地镜像，从不去远程仓库拉取，本地没有就报错 （一直使用本地）
# 1、20版本后默认的是Onfailure :当容器终止且退出码部位0，则kubetle则重新启动容器
默认值说明：
如果镜像tag为具体版本号， 默认策略是：IfNotPresent
如果镜像tag为：latest（最终版本） ，默认策略是always
# 1、创建Pod
[root@master pod]# kubectl create -f pod-imagepullpolicy.yaml
pod/pod-imagepullpolicy created
# 2、查看Pod详情
# 此时明显可以看到nginx镜像有一步Pulling image "nginx"的过程
[root@master pod]# kubectl describe pod pod-imagepullpolicy -n dev
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled <unknown> default-scheduler Successfully assigned dev/pod-imagePullPolicy to k8s-n-01
Normal Pulling 32s kubelet, k8s-n-01 Pulling image "nginx"
Normal Pulled 26s kubelet, k8s-n-01 Successfully pulled image "nginx"
Normal Created 26s kubelet, k8s-n-01 Created container nginx
Normal Started 25s kubelet, k8s-n-01 Started container nginx
Normal Pulled 7s (x3 over 25s) kubelet, k8s-n-01 Container image "busybox:1.30" already present on machine
Normal Created 7s (x3 over 25s) kubelet, k8s-n-01 Created container busybox
Normal Started 7s (x3 over 25s) kubelet, k8s-n-01 Started container busybox
3、启动命令
# 在前面的案例中，一直有一个问题没有解决，就是的busybox容器一直没有成功运行，那么到底是什么原因导致这个容器的故障呢？
原来busybox并不是一个程序，而是类似于一个工具类的集合，kubernetes集群启动管理后，它会自动关闭。
# 解决方法就是让其一直在运行，这就用到了command配置。
1、创建pod-command.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-command
namespace: dev
spec:
containers:
- name: nginx
image: nginx
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","touch /tmp/hello.txt;while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done;"]
# 注:
"/bin/sh","-c", 使用sh执行命令
touch /tmp/hello.txt; 创建一个/tmp/hello.txt 文件
while true;do /bin/echo $(date +%T) >> /tmp/hello.txt; sleep 3; done; 每隔3秒向文件中写入当前时间
2、command，用于在pod中的容器初始化完毕之后运行一个命令。
# 1、创建Pod
[root@master pod]# kubectl create -f pod-command.yaml
pod/pod-command created
# 2、查看Pod状态
# 此时发现两个pod都正常运行了
[root@master pod]# kubectl get pods pod-command -n dev
NAME READY STATUS RESTARTS AGE
pod-command 2/2 Runing 0 2s
# 3、进入pod中的busybox容器，查看文件内容
# 补充一个命令: kubectl exec pod名称 -n 命名空间 -it -c 容器名称 /bin/sh 在容器内部执行命令
# 使用这个命令就可以进入某个容器的内部，然后进行相关操作了
# 可以查看txt文件的内容
[root@master pod]# kubectl exec pod-command -n dev -it -c busybox /bin/sh
/ # tail -f /tmp/hello.txt
13:35:35
13:35:38
13:35:41
3、总结说明
通过上面发现command已经可以完成启动命令和传递参数的功能，为什么这里还要提供一个args选项，用于传递参数呢?这其实跟docker有点关系，kubernetes中的command、args两项其实是实现覆盖Dockerfile中ENTRYPOINT的功能。
# 1 如果command和args均没有写，那么用Dockerfile的配置。
# 2 如果command写了，但args没有写，那么Dockerfile默认的配置会被忽略，执行输入的command
# 3 如果command没写，但args写了，那么Dockerfile中配置的ENTRYPOINT的命令会被执行，使用当前args的参数
# 4 如果command和args都写了，那么Dockerfile的配置被忽略，执行command并追加上args参数
4、环境变量
1、创建pod-env.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-env
namespace: dev
spec:
containers:
- name: busybox
image: busybox:1.30
command: ["/bin/sh","-c","while true;do /bin/echo $(date +%T);sleep 60; done;"]
env: # 设置环境变量列表
- name: "username"
value: "admin"
- name: "password"
value: "123456"
2、env，环境变量，用于在pod中的容器设置环境变量。
# 1、创建Pod
[root@k8s-m-01 ~]# kubectl create -f pod-env.yaml
pod/pod-env created
# 2、进入容器，输出环境变量
[root@k8s-m-01 ~]# kubectl exec pod-env -n dev -c busybox -it /bin/sh
/ # echo $username
admin
/ # echo $password
123456
这种方式不是很推荐，推荐将这些配置单独存储在配置文件中，这种方式将在后面介绍。
5、端口设置
端口设置就是containers的ports选项
1、首先看下ports支持的子选项：
[root@k8s-m-01 ~]# kubectl explain pod.spec.containers.ports
KIND: Pod
VERSION: v1
RESOURCE: ports <[]Object>
FIELDS:
name <string> # 端口名称，如果指定，必须保证name在pod中是唯一的
containerPort<integer> # 容器要监听的端口(0<x<65536)
hostPort <integer> # 容器要在主机上公开的端口，如果设置，主机上只能运行容器的一个副本(一般省略)
hostIP <string> # 要将外部端口绑定到的主机IP(一般省略)
protocol <string> # 端口协议。必须是UDP、TCP或SCTP。默认为“TCP”。
2、编写一个测试案例，创建pod-ports.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-ports
namespace: dev
spec:
containers:
- name: nginx
image: nginx
ports: # 设置容器暴露的端口列表
- name: nginx-port
containerPort: 80
protocol: TCP
# 1、创建Pod
[root@k8s-m-01 ~]# kubectl create -f pod-ports.yaml
pod/pod-ports created
# 2、查看pod
# 在下面可以明显看到配置信息
[root@k8s-m-01 ~]# kubectl get pod pod-ports -n dev -o yaml
......
spec:
containers:
- image: nginx
imagePullPolicy: IfNotPresent
name: nginx
ports:
- containerPort: 80
name: nginx-port
protocol: TCP
......
访问容器中的程序需要使用的是podIp:containerPort
6、资源配额
容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。
针对这种情况，kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，他有两个子选项：
-
limits：用于限制运行时容器的最大占用资源，当容器占用资源超过limits时会被终止，并进行重启
-
requests ：用于设置容器需要的最小资源，如果环境资源不够，容器将无法启动
可以通过上面两个选项设置资源的上下限。
1、编写一个测试案例，创建pod-resources.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-resources
namespace: dev
spec:
containers:
- name: nginx
image: nginx
resources: # 资源配额
limits: # 限制资源（上限）
cpu: "2" # CPU限制，单位是core数
memory: "10Gi" # 内存限制
requests: # 请求资源（下限）
cpu: "1" # CPU限制，单位是core数
memory: "10Mi" # 内存限制
2、在这对cpu和memory的单位做一个说明：
cpu：core数，可以为整数或小数
memory： 内存大小，可以使用Gi、Mi、G、M等形式
# 1、运行Pod
[root@k8s-m-01 ~]# kubectl create -f pod-resources.yaml
pod/pod-resources created
# 2、查看发现pod运行正常
[root@k8s-m-01 ~]# kubectl get pod pod-resources -n dev
NAME READY STATUS RESTARTS AGE
pod-resources 1/1 Running 0 39s
# 3、停止(删除)Pod
[root@k8s-m-01 ~]# kubectl delete -f pod-resources.yaml
pod "pod-resources" deleted
# 4、编辑pod，修改resources.requests.memory的值为10Gi
[root@k8s-m-01 ~]# vim pod-resources.yaml
# 5、再次启动pod
[root@k8s-m-01 ~]# kubectl create -f pod-resources.yaml
pod/pod-resources created
# 6、查看Pod状态，发现Pod启动失败
[root@k8s-m-01 ~]# kubectl get pod pod-resources -n dev -o wide
NAME READY STATUS RESTARTS AGE
pod-resources 0/2 Pending 0 20s
# 7、查看pod详情会发现，如下提示
[root@k8s-m-01 ~]# kubectl describe pod pod-resources -n dev
......
Warning FailedScheduling <unknown> default-scheduler 0/2 nodes are available: 2 Insufficient memory.(内存不足)
三、Pod生命周期
1、pod的生命周期
我们一般将pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含下面的过程：
-
pod创建过程
-
运行初始化容器（init container）过程
-
运行主容器（main container）
-
容器启动后钩子（post start）、容器终止前钩子（pre stop）
-
容器的存活性探测（liveness probe）、就绪性探测（readiness probe）
-
-
pod终止过程
1、创建pod,并调度到合适的节点上
2、创建pause基础主容器，提供共享名称空间 # (info容器) == 根容器 == 主容器
3、从上到下依次创建业务容器
4、启动业务容器，启动那一刻会同时运行主容器上定义的Poststart钩子事件
5、持续存活状态监测、就绪状态监测
6、结束时，执行prestop钩子事件
7、终止业务容器，在终止主容器
8、销毁Pod
2、在整个生命周期中，Pod会出现5种状态（相位），
# 1、挂起（Pending）：
API Server 创建了 pod 资源对象已存入 etcd 中，但它尚未被调度完成，或者仍处于从仓库下载镜像的过程中。
# 2、运行中（Running）：
Pod 已经被调度至某节点，并且所有容器都已经被 kubelet 创建完成
# 3、成功（Succeeded）：
Pod 中的所有容器都已经成功终止并且不会被重启。
# 4、失败（Failed）：
Pod 中的所有容器都已终止了，并且至少有一个容器是因为失败终止。即容器以非 0 状态退出或者被系统禁止。
# 5、未知（Unknown）:
Api Server 无法正常获取到 Pod 对象的状态信息，通常是由于无法与所在工作节点的kubelet 通信所致。
===================================================================================================
# 6、ImgPullErr : （不常用）
镜像拉取失败
# 7、ContainerCreating ： (不常用)
容器创建中
kubernetes在集群启动之后，集群中的各个组件也都是以Pod方式运行的。可以通过下面命令查看：
[root@k8s-m-01 ~]# kubectl get pod -n kube-system
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-6955765f44-68g6v 1/1 Running 0 2d1h
kube-system coredns-6955765f44-cs5r8 1/1 Running 0 2d1h
kube-system etcd-master 1/1 Running 0 2d1h
kube-system kube-apiserver-master 1/1 Running 0 2d1h
kube-system kube-controller-manager-master 1/1 Running 0 2d1h
kube-system kube-flannel-ds-amd64-47r25 1/1 Running 0 2d1h
kube-system kube-flannel-ds-amd64-ls5lh 1/1 Running 0 2d1h
kube-system kube-proxy-685tk 1/1 Running 0 2d1h
kube-system kube-proxy-87spt 1/1 Running 0 2d1h
kube-system kube-scheduler-master 1/1 Running 0 2d1h
3、创建和终止
1、pod的创建过程
1. 用户通过kubectl或其他api客户端提交需要创建的Pod信息给apiServer
2. apiServer开始生成Pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
3. apiServer开始反映etcd中的Pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动
4. scheduler发现有新的Pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer
5. node节点上的kubelet发现有pod调度过来，尝试调用docker启动容器，并将结果回送至apiServer
6. apiServer将接收到的pod状态信息存入etcd中
2、pod的终止过程
1. 用户向apiServer发送删除pod对象的命令
2. apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
3. 将pod标记为terminating状态（正在删除状态）
4. kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
5. 端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
6. 如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行
7. pod对象中的容器进程收到停止信号
8. 宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
9. kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见
3、初始化容器
初始化容器是在pod的主容器启动之前要运行的容器，主要是做一些主容器的前置工作，它具有两大特征：
1. 初始化容器必须运行完成直至结束，若某初始化容器运行失败，那么kubernetes需要重启它直到成功完成
2. 初始化容器必须按照定义的顺序执行，当且仅当前一个成功之后，后面的一个才能运行
初始化容器有很多的应用场景，下面列出的是最常见的几个：
1、提供主容器镜像中不具备的工具程序或自定义代码
2、初始化容器要先于应用容器串行启动并运行完成，因此可用于延后应用容器的启动直至其依赖的条件得到满足
案例，模拟下面这个需求：
假设要以主容器来运行nginx，但是要求在运行nginx之前先要能够连接上mysql和redis所在服务器
为了简化测试，事先规定好mysql(192.168.15.201)和redis(192.168.15.202)服务器的地址
1、创建pod-initcontainer.yaml，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-initcontainer
namespace: dev
spec:
containers:
- name: main-container
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
initContainers:
- name: test-mysql
image: busybox:1.30
command: ['sh', '-c', 'until ping 192.168.15.201 -c 1 ; do echo waiting for mysql...; sleep 2; done;']
- name: test-redis
image: busybox:1.30
command: ['sh', '-c', 'until ping 192.168.15.202 -c 1 ; do echo waiting for reids...; sleep 2; done;']
# 1、创建pod
[root@k8s-m-01 ~]# kubectl create -f pod-initcontainer.yaml
pod/pod-initcontainer created
# 2、查看pod状态
# 发现pod卡在启动第一个初始化容器过程中，后面的容器不会运行
root@master ~]# kubectl describe pod pod-initcontainer -n dev
........
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 49s default-scheduler Successfully assigned dev/pod-initcontainer to k8s-n-01
Normal Pulled 48s kubelet, k8s-n-01 Container image "busybox:1.30" already present on machine
Normal Created 48s kubelet, k8s-n-01 Created container test-mysql
Normal Started 48s kubelet, k8s-n-01 Started container test-mysql
# 3、动态查看pod
[root@k8s-m-01 ~]# kubectl get pods pod-initcontainer -n dev -w
NAME READY STATUS RESTARTS AGE
pod-initcontainer 0/1 Init:0/2 0 15s
pod-initcontainer 0/1 Init:1/2 0 52s
pod-initcontainer 0/1 Init:1/2 0 53s
pod-initcontainer 0/1 PodInitializing 0 89s
pod-initcontainer 1/1 Running 0 90s
# 4、接下来新开一个shell，为当前服务器新增两个ip，观察pod的变化
[root@k8s-m-01 ~]# ifconfig eth0:1 192.168.15.201 netmask 255.255.255.0 up
[root@k8s-m-01 ~]# ifconfig eth0:2 192.168.15.202 netmask 255.255.255.0 up
4、钩子函数
钩子函数能够感知自身生命周期中的事件，并在相应的时刻到来时运行用户指定的程序代码。
kubernetes在主容器的启动之后和停止之前提供了两个钩子函数：
1、post start： # 容器创建之后执行，如果失败了会重启容器
2、pre stop ： # 容器终止之前执行，执行完成之后容器将成功终止，在其完成之前会阻塞删除容器的操作
钩子处理器支持使用下面三种方式定义动作：
-
Exec命令：在容器内执行一次命令
…… lifecycle: postStart: exec: command: - cat - /tmp/healthy …… -
TCPSocket：在当前容器尝试访问指定的socket
…… lifecycle: postStart: tcpSocket: port: 8080 …… -
HTTPGet：在当前容器中向某url发起http请求
…… lifecycle: postStart: httpGet: path: / #URI地址 port: 80 #端口号 host: 192.168.15.100 #主机地址 scheme: HTTP #支持的协议，http或者https ……
接下来，以exec方式为例，演示下钩子函数的使用，创建pod-hook-exec.yaml文件，内容如下：
apiVersion: v1
kind: Pod
metadata:
name: pod-hook-exec
namespace: dev
spec:
containers:
- name: main-container
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
lifecycle:
postStart:
exec: # 在容器启动的时候执行一个命令，修改掉nginx的默认首页内容
command: ["/bin/sh", "-c", "echo postStart... > /usr/share/nginx/html/index.html"]
preStop:
exec: # 在容器停止之前停止nginx服务
command: ["/usr/sbin/nginx","-s","quit"]
# 1、创建pod
[root@k8s-m-01 ~]# kubectl create -f pod-hook-exec.yaml
pod/pod-hook-exec created
# 2、查看pod
[root@k8s-m-01 ~]# kubectl get pods pod-hook-exec -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE
pod-hook-exec 1/1 Running 0 29s 10.244.2.48 k8s-n-02
# 3、访问pod
[root@k8s-m-01 ~]# curl 10.244.2.48
postStart...
4、容器探测
容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例" 摘除 "，不承担业务流量。kubernetes提供了两种探针来实现容器探测，分别是：
# 1、存活性检查 ：
容器是否正常启动，探测失败，立即删除容器
# 2、就绪性检查 ：
容器是否能够正常提供服务，探测失败，立即移除负载均衡
-
liveness probes： 存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器
-
readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量
livenessProbe 决定是否重启容器，readinessProbe 决定是否将请求转发给容器。
上面两种探针目前均支持三种探测方式：
-
Exec命令：在容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则不正常
…… livenessProbe: exec: command: - cat - /tmp/healthy …… -
TCPSocket：将会尝试访问一个用户容器的端口，如果能够建立这条连接，则认为程序正常，否则不正常
…… livenessProbe: tcpSocket: port: 8080 …… -
HTTPGet：调用容器内Web应用的URL，如果返回的状态码在200和399之间，则认为程序正常，否则不正常
…… livenessProbe: httpGet: path: / #URI地址 port: 80 #端口号 host: 127.0.0.1 #主机地址 scheme: HTTP #支持的协议，http或者https ……
下面以liveness probes为例，做几个演示：
方式一：Exec
1、创建pod-liveness-exec.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-exec
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
exec:
command: ["/bin/cat","/tmp/hello.txt"] # 执行一个查看文件的命令
2、 创建pod，观察效果
# 1、创建Pod
[root@k8s-m-01 ~]# kubectl create -f pod-liveness-exec.yaml
pod/pod-liveness-exec created
# 2、查看Pod详情
[root@k8s-m-01 ~]# kubectl describe pods pod-liveness-exec -n dev
......
Normal Created 20s (x2 over 50s) kubelet, k8s-n-01 Created container nginx
Normal Started 20s (x2 over 50s) kubelet, k8s-n-01 Started container nginx
Normal Killing 20s kubelet, k8s-n-01 Container nginx failed liveness probe, will be restarted
Warning Unhealthy 0s (x5 over 40s) kubelet, k8s-n-01 Liveness probe failed: cat: can't open '/tmp/hello11.txt': No such file or directory
# 观察上面的信息就会发现nginx容器启动之后就进行了健康检查
# 检查失败之后，容器被kill掉，然后尝试进行重启（这是重启策略的作用，后面讲解）
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
[root@k8s-m-01 ~]# kubectl get pods pod-liveness-exec -n dev
NAME READY STATUS RESTARTS AGE
pod-liveness-exec 0/1 CrashLoopBackOff 2 3m19s
# 当然接下来，可以修改成一个存在的文件，比如/tmp/hello.txt，再试，结果就正常了......
# command: ["/bin/ls","/tmp/"] #正确配置（查看文件的命令)
方式二：TCPSocket
1、创建pod-liveness-tcpsocket.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-tcpsocket
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
tcpSocket:
port: 8080 # 尝试访问8080端口
2、创建pod，观察效果
# 1、创建Pod
[root@k8s-m-01 ~]# kubectl create -f pod-liveness-tcpsocket.yaml
pod/pod-liveness-tcpsocket created
# 2、查看Pod详情
[root@k8s-m-01 ~]# kubectl describe pods pod-liveness-tcpsocket -n dev
......
Normal Scheduled 31s default-scheduler Successfully assigned dev/pod-liveness-tcpsocket to k8s-n-02
Normal Pulled <invalid> kubelet, k8s-n-02 Container image "nginx:1.17.1" already present on machine
Normal Created <invalid> kubelet, k8s-n-02 Created container nginx
Normal Started <invalid> kubelet, k8s-n-02 Started container nginx
Warning Unhealthy <invalid> (x2 over <invalid>) kubelet, k8s-n-02 Liveness probe failed: dial tcp 10.244.2.44:8080: connect: connection refused
# 观察上面的信息，发现尝试访问8080端口,但是失败了
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
[root@k8s-m-01 ~]# kubectl get pods pod-liveness-tcpsocket -n dev
NAME READY STATUS RESTARTS AGE
pod-liveness-tcpsocket 0/1 CrashLoopBackOff 2 3m19s
# 当然接下来，可以修改成一个可以访问的端口，比如80，再试，结果就正常了......
# port: 80 (正确配置)
方式三：HTTPGet
1、创建pod-liveness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-httpget
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
httpGet: # 其实就是访问http://127.0.0.1:80/hello
scheme: HTTP #支持的协议，http或者https
port: 80 #端口号
path: /hello #URI地址
2、创建pod，观察效果
# 1、创建Pod
[root@k8s-m-01 ~]# kubectl create -f pod-liveness-httpget.yaml
pod/pod-liveness-httpget created
# 2、查看Pod详情
[root@k8s-m-01 ~]# kubectl describe pod pod-liveness-httpget -n dev
.......
Normal Pulled 6s (x3 over 64s) kubelet, k8s-n-01 Container image "nginx:1.17.1" already present on machine
Normal Created 6s (x3 over 64s) kubelet, k8s-n-01 Created container nginx
Normal Started 6s (x3 over 63s) kubelet, k8s-n-01 Started container nginx
Warning Unhealthy 6s (x6 over 56s) kubelet, k8s-n-01 Liveness probe failed: HTTP probe failed with statuscode: 404
Normal Killing 6s (x2 over 36s) kubelet, k8s-n-01 Container nginx failed liveness probe, will be restarted
# 3、观察上面信息，尝试访问路径，但是未找到,出现404错误
# 稍等一会之后，再观察pod信息，就可以看到RESTARTS不再是0，而是一直增长
[root@k8s-m-01 ~]# kubectl get pod pod-liveness-httpget -n dev
NAME READY STATUS RESTARTS AGE
pod-liveness-httpget 1/1 Running 5 3m17s
# 当然接下来，可以修改成一个可以访问的路径path，比如/，再试，结果就正常了......
# path: / （正确配置）
至此，已经使用liveness Probe演示了三种探测方式，但是查看livenessProbe的子属性，会发现除了这三种方式，还有一些其他的配置，在这里一并解释下：
[root@k8s-m-01 ~]# kubectl explain pod.spec.containers.livenessProbe
FIELDS:
exec <Object>
tcpSocket <Object>
httpGet <Object>
initialDelaySeconds <integer> # 容器启动后等待多少秒执行第一次探测
timeoutSeconds <integer> # 探测超时时间。默认1秒，最小1秒
periodSeconds <integer> # 执行探测的频率。默认是10秒，最小1秒
failureThreshold <integer> # 连续探测失败多少次才被认定为失败。默认是3。最小值是1
successThreshold <integer> # 连续探测成功多少次才被认定为成功。默认是1
下面稍微配置两个，演示下效果即可：
[root@k8s-m-01 ~]# more pod-liveness-httpget.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-liveness-httpget
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
httpGet:
scheme: HTTP
port: 80
path: /
initialDelaySeconds: 30 # 容器启动后30s开始探测
timeoutSeconds: 5 # 探测超时时间为5s
5、重启策略
- Always ：容器失效时，自动重启该容器，这也是默认值。
- OnFailure ： 容器终止运行且退出码不为0时重启
- Never ： 不论状态为何，都不重启该容器
# 1. Always： (默认)
当容器失效时，由 kubelet 自动重启该容器。
# 2. OnFailure：
当容器终止运行且退出码不为 0 时，由 kubelet 自动重启该容器
# 3. Never：
不论容器运行状态如何，kubelet 都不会重启该容器。
kubelet 重启失效容器的时间间隔以 sync-frequency 乘以 2n 来计算；例如 1、2、4、8 倍等，最长延时5min ，并且在成功重启后的 10 min 后重置该时间。
Pod 的重启策略与控制方式息息相关，当前可用于管理 Pod 的控制器包括 ReplicationController、Job、DaemonSet 及直接通过 kubelet 管理（静态 Pod）。每种控制器对 Pod 的重启策略要求如下：
# 1．RC 和 DaemonSet：必须设置为 Always，需要保证该容器持续运行。
# 2．Job 和 CronJob：OnFailure 或 Never，确保容器执行完成后不再重启。
# 3．kubelet：在 Pod 失效时自动重启它，不论将 RestartPolicy 设置为什么值，也不会对 Pod 进行健康检查。
重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。
Pod 重启策略（ RestartPolicy ）应用于 Pod 内的所有容器，井且仅在 Pod 所处的 Node 上由 kubelet 进行判断和重启操作。
当某个容器异常退出或者健康检查失败时， kubelet 将根据 RestartPolicy 设置来进行相应的操作。Pod 的重启策略包括：Always、OnFailure 和 Never，默认值为 Always
1、创建pod-restartpolicy.yaml：
apiVersion: v1
kind: Pod
metadata:
name: pod-restartpolicy
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
ports:
- name: nginx-port
containerPort: 80
livenessProbe:
httpGet:
scheme: HTTP
port: 80
path: /hello
restartPolicy: Never # 设置重启策略为Never （默认Always&#x以上是关于linux12k8s --＞ 06Pod详解的主要内容，如果未能解决你的问题，请参考以下文章
linux12k8s --＞16 kubernetes必备面试题