文章目录
- 01 引言
- 02 总结
- 2.1 定义与基本用法
- 2.2 容器共享volume
- 2.3 配置管理
- 2.4 容器获取pod信息(Downward API)
- 2.5 生命周期、重启策略及健康检查
- 2.6 pod调度
- 2.7 初始化容器
- 2.8 升级与回滚
- 2.9 扩缩容
- 2.10 使用StatefulSet搭建MongoDB集群
- 03 文末
01 引言
至此,pod的相关知识已经讲解完了,下面是整理的脑图:
02 总结
下面是关于pod的文章详情总结:
- 《k8s教程(pod篇)-定义与基本用法》
- 《k8s教程(pod篇)-容器共享volume》
- 《k8s教程(pod篇)-配置管理》
- 《k8s教程(pod篇)-容器获取pod信息(Downward API)》
- 《k8s教程(pod篇)-生命周期、重启策略及健康检查》
- 《k8s教程(pod篇)-调度概述》
- 《k8s教程(pod篇)-全自动调度》
- 《k8s教程(pod篇)-定向调度》
- 《k8s教程(pod篇)-node亲和性调度》
- 《k8s教程(pod篇)-亲和性与互斥性调度》
- 《k8s教程(pod篇)-污点与容忍》
- 《k8s教程(pod篇)-优先级调度》
- 《k8s教程(pod篇)-DaemonSet(每个node上只调度一个pod)》
- 《k8s教程(pod篇)-批处理调度》
- 《k8s教程(pod篇)-定时任务》
- 《k8s教程(pod篇)-容灾调度》
- 《k8s教程(pod篇)-调度总结》
- 《k8s教程(pod篇)-初始化容器》
- 《k8s教程(pod篇)-升级与回滚》
- 《k8s教程(pod篇)-扩缩容》
- 《k8s教程(pod篇)-使用StatefulSet搭建MongoDB集群》
2.1 定义与基本用法
详情参考: 《k8s教程(pod篇)-定义与基本用法》
pod定义的完整内容如下:
apiVersion: v1
kind: Pod
metadata:
name: string
namespace: string
labels:
- name: string
annotations:
- name: string
spec:
containers:
- name: string
image: string
imagePullPolicy: [Always Never IfNotPresent]
command: [string]
args: [string]
workingDir: string
volumeMounts:
- name: string
mountPath: string
readonly: boolean
ports:
- name: string
containerPort: int
hostPort: int
protocol: string
env:
- name: string
- value: string
resources:
limits:
cpu: string
memory: string
requests:
cpu: string
memory: string
livenessProbe:
exec:
command: [string]
httpGet:
path: string
port: number
host: string
scheme: string
httpHeaders:
- name: string
value: string
tcpSocket:
port: number
initialDelaySeconds: 0
timeoutSeconds: 0
periodSeconds: 0
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure]
nodeselector: object
imagePullSecrets:
- name: string
hostNetwork: false
volumes:
- name: string
emptyDir: {}
hostPath:
path: string
secret:
secretName: string
items:
- key: string
path: string
configMap:
- name: string
items:
- key: string
path: string
属性含义:
2.2 容器共享volume
详情参考: 《k8s教程(pod篇)-容器共享volume》
容器共享volume:同一个 Pod 中的多个容器能够共享Pod级别的存储卷 Volume。
举例:在 Pod 内包含两个容器(tomcat 和 busybox),在 Pod 级别设置 Volume “app-logs
”,用于 tomcat 容器向其中写日志文件,busybox 容器从中读日志文件。
apiversion: v1
kind: Pod
metadata:
name: volume-pod
spec:
containers:
- name: tomcat
image: tomcat
ports:
- containerPort: 8080
volumeMounts:
- name: app-logs
mountPath: /usr/local/tomcat/logs
- name: busybox
image: busybox
command: ["sh","-c","tail-f /logs/catalina*.log"]
volumeMounts:
- name: app-logs
mountPath: /logs
volumes:
- name: app-logs
emptyDir: {}
这里设置的 Volume 名称为 app-logs,类型为 emptyDir(也可以设置为其他类型),挂载到 tomcat容器内 的/usr/local/tomcat/logs目录下,同时挂载到busybox容器内的/logs目录下。
tomcat容器在启动后会向/usr/local/tomcat/logs目录写文件,busybox 容器就可以读取其中的文件了。
2.3 配置管理
详情参考: 《k8s教程(pod篇)-配置管理》
Pod可以使用 ConfigMap进行配置管理,ConfigMap以一个或多个key:value的形式保存在Kubenetes系统中供应用使用,它既可以表示一个变量的值(例如: apploglevel=info
),也可以用于表示一个完整的配置文件内容(例如:server.xml=<?xml...>
)。
典型用法如下:
- 生成容器的环境变量;
- 设置容器启动命令的启动参数(需要设置为环境变量);
- 以Volume的形式挂载为容器内部的文件或目录。
下面展示将两个配置文件(server.xml
和logging.properties
)定义为ConfigMap
的用法,设置key为配置文件的别名,value则是配置文件的全部文本内容:
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-appconfigfiles
data:
key-serverxml: |
<?xml version='1.0'encoding='utf-8'?>
.......此处省略内容
key-loggingproperties:
"handlers=catalina.org.apache.juli ......此处省略内容"
接着使用kubectl命令创建该ConfigMap:
$ kubectl create -f cm-appconfigfiles.yaml
configmap "cm-appconfigfiles" created
然在Pod “cm-test-app” 的定义中,将ConfigMap “cm-appconfigfiles”中的内容以文件的形式挂载到容器内部的/configfiles目录下,Pod配置文件cm-test-app.yaml的内容如下:
apiVersion: v1
kind: Pod
metadata:
name: cm-test-app
spec:
containers:
- name: cm-test-app
image: kubeguide/tomcat-app:v1
ports:
- containerPort: 8080
volumeMounts:
- name: serverxml #引用Volume的名称
mountPath: /configfiles #挂载到容器内的目录
volumes:
- name: serverxml #定义Volume的名称
configMap:
name: cm-appconfigfiles #使用ConfigMap"cm-appconfigfiles"
items:
- key: key-serverxml # key=key-serverxml
path: server.xml #value将server.ml文件名进行挂载
- key: key-loggingproperties # key=key-loggingproperties
path: logging.properties #value将logging,properties文件名进行挂载
创建完该Pod之后,登录容器,查看到在**/configfiles目录下存在server.xml
和logging.properties
文件,他们的内容就是ConigMap “cm-appconfigfiles”** 中两个key定义的内容:
2.4 容器获取pod信息(Downward API)
详情参考:《k8s教程(pod篇)-容器获取pod信息(Downward API)》
Downward API可以通过以下两种方式将Pod和容器的元数据信息注入容器内部:
- 环境变量:将Pod或Container信息设置为容器内的环境变量;
- Volume挂载:将Pod或Container信息以文件的形式挂载到容器内部。
下面仅举例通过Downward API将Pod的 IP、名称和所在命名空间注入容器的环境变量中(通过Volume挂载的方式可以看原文):
apiVersion: v1
kind: Pod
metadata:
name: dapi-envars-fieldref
spec:
containers:
- name: test-container
image: busybox
command: ["sh","-c"]
args:
- while true;do
echo -en '\n';
printenv MY NODE NAME MY POD NAME MY POD NAMESPACE;
printenv MY POD IP MY POD SERVICE ACCOUNT;
sleep 10;
done;
env:
- name: MY NODE NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
- name: MY POD NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MY POD NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: MY POD IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: MY POD SERVICE ACCOUNT
valueFrom:
fieldRef:
fieldPath: spec.serviceAccountName
restartPolicy: Never
yaml设置的环境变量有:
-
spec.nodeName
:Pod所在Node的名称; -
metadata.name
:Pod名称; -
metadata.namespace
:Pod所在命名空间的名称; -
status.podIP
:Pod的IP地址; -
spec.serviceAccountName
:Pod使用的ServiceAccount名称。
使用命令创建pod之后,进入容器,可以看到环境变量的配置了:
2.5 生命周期、重启策略及健康检查
详情参考: 《k8s教程(pod篇)-生命周期、重启策略及健康检查》
Pod的生命周期:
状态值 | 描述 |
Pending | API Server已经创建了pod,但在pod内还有一个或多个容器的镜像没有创建,包括正在下载镜像的过程 |
Running | pod内所有容器均已创建,且至少有一个容器处于运行状态、正在启动状态或正在重启状态 |
Succeeded | pod内所有容器均成功执行后退出,且不会在重启 |
Failed | pod内所有容器均已退出,但至少有一个容器为退出失败状态 |
Unknown | 由于某种原因无法获取该Pod的状态,可能由于网络通信不畅导致的 |
Pod的重启策略:当某个容器异常退出或者健康检查 失败时,kubelet
将根据RestartPolicy
的设置进行相应的操作,pod的重启策略包括Always
、OnFailure
和Never
(默认值为Always
):
重启策略 | 描述 |
Always | 当容器失效时,由kubelet自动重启该容器 |
OnFailure | 当容器终止运行且退出码不为0时,由kubelet自动重启该容器 |
Never | 不论容器运行状态如何,kubelet都不会重启该容器 |
Pod健康检查:Kubernetes对Pod的健康状态可以通过三类探针来检查:LivenessProbe、ReadinessProbe及StartupProbe,其中最主要的探针为LivenessProbe与ReadinessProbe,kubelet会定期执行这两类探针来诊断容器的健康状况。
探针 | 作用 |
LivenessProbe探针 | 用于判断容器是否存活(Running状态),如果LivenessProbe探针探测到容器不健康,则kubelet“将“杀掉”该容器,并根据容器的重启策略做相应的处理。如果一个容器不包含LivenessProbe探针,那么kubelet认 为该容器的LivenessProbe探针返回的值永远是Success |
ReadinessProbe探针 | 用于判断容器服务是否可用(Ready状态),达到Ready状态的Pod才可以接收请求。对于被Service管理的Pod、Service与PodEndpoint的关联关系也将基于Pod是否Ready进行设置。如果在运行过程中Ready 状态变为False,则系统自动将其从Service的后端Endpoint列表中隔离出去,后续再把恢复到Ready状态的Pod加回后端Endpoint列表。这样就能保证客户端在访问Service时不会被转发到服务不可用的Pod实例上。需要注意的是ReadinessProbe也是定期触发执行的,存在于Pod的整个生命周期中 |
StartupProbe探针 | 某些应用会遇到启动比较慢的情况,例如应用程序启动时需要与远程服务器建立网络连接,或者遇到网络访问较慢等情况时,会造成容器启动缓慢,此时ReadinessProbe就不适用了,因为这属于“有且仅有一次” 的超长延时,可以通过StartupProbe探针解决该问题 |
2.6 pod调度
详情参考:
- 《k8s教程(pod篇)-调度概述》
- 《k8s教程(pod篇)-全自动调度》
- 《k8s教程(pod篇)-定向调度》
- 《k8s教程(pod篇)-node亲和性调度》
- 《k8s教程(pod篇)-亲和性与互斥性调度》
- 《k8s教程(pod篇)-污点与容忍》
- 《k8s教程(pod篇)-优先级调度》
- 《k8s教程(pod篇)-DaemonSet(每个node上只调度一个pod)》
- 《k8s教程(pod篇)-批处理调度》
- 《k8s教程(pod篇)-定时任务》
- 《k8s教程(pod篇)-容灾调度》
之前已经写了总结了,可以参考: 《k8s教程(pod篇)-调度总结》
2.7 初始化容器
详情参考:《k8s教程(pod篇)-初始化容器》
init container(初始化容器),用于在启动应用容器(app container
)之前启动一个或多个初始化容器,完成应用容器所需的预置条件。
下面以nginx应用为例,在启动nginx之前,通过初始化容器busybox,为nginx 创建一个index.html主页文件:
apiversion: v1
kind: Pod
metadata:
name: nginx
annotations:
spec:
# These containers are run during pod initialization
initContainers:
- name: install
image: busybox
command:
- wget
-"-o"
-"/work-dir/index.html"
- http://kubernetes.io
volumeMounts:
- name: workdir
mountPath: "/work-dir"
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
volumeMounts:
- name: workdir
mountPath: /usr/share/nginx/html
dnsPolicy: Default
volumes:
- name: workdir
emptyDir: {}
创建完成后,在运行init container的过程中查看Pod的状态,可见init过程还未完成:
$ kubectl create -f nginx-init-containers.yaml
pod "nginx"created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 0/1 Init:0/1 0 1m
在init container成功运行完成后,系统继续启动Nginx容器,再次查看Pod的状态:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 7s
查看Pod的事件,可以看到系统首先创建并运行init container
容器(名为install
),成功后继续创建和运行Nginx
容器。
2.8 升级与回滚
详情参考:《k8s教程(pod篇)-升级与回滚》
Pod的升级方式有两种:
- 通过kubectl set image命令为Deployment设置新的镜像名称
- 使用kubectl edit命令修改Deployment的配置,将
spec.template.spec.containers[0].image
从nginx: 1.7.9更改为nginx:1.9.1
Pod的回滚方式:
- 撤销本次发布并回滚到上一个部署版本:
Pod暂停和恢复Deployment操作:
- 通过kubectl rollout pause命令暂停Deployment的更新操作:
- 修改完后,恢复这个Deployment的部署操作:
2.9 扩缩容
详情参考: 《k8s教程(pod篇)-扩缩容》
Pod扩缩容分为两种:
- 手动扩缩容:例如通过kubectl scale命令可以将Pod副本数量从初始的3个更新为5个
- 自动扩缩容:使用HPA控制器,用于实现基于CPU使用率进行自动Pod扩缩容的功能,详情查看 《k8s教程(pod篇)-扩缩容》。
2.10 使用StatefulSet搭建MongoDB集群
详情参考: 《k8s教程(pod篇)-使用StatefulSet搭建MongoDB集群》
原理图如下:
为了完成MongoDB集群的搭建,需要部署以下三个资源对象,分别为:
- StorageClass:用于StatefulSet自动为各个应用Pod申请PVC;
- Headless Service:用于设置MongoDB实例的域名;
- StatefulSet
详情查看原文:《k8s教程(pod篇)-使用StatefulSet搭建MongoDB集群》
03 文末本文主要总结了前段时间对k8s pod的知识点整理,希望能帮助到大家,谢谢大家的阅读,本文完!