文章目录
1. pod的生命周期
Pod 是 kubernetes 系统的基础单元,是由用户创建或部署的最小组件,也是 kubernetes 系统上运行容器化应用的资源对象。
Kubernetes 集群中其他资源对象都是为 pod 这个资源对象做支撑来实现 kubernetes 管理应用服务的目的。
Pod 可以包含多个容器,应用运行在这些容器里面,同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像,除了如下两点:
- 它们总是运行到完成。
- Init 容器不支持 Readiness,因为它们必须在 Pod 就绪之前运行完成。
- 每个 Init 容器必须运行成功,下一个才能够运行。
如果 Pod 的 Init 容器失败,Kubernetes 会不断地重启该 Pod,直到 Init 容器成功为止。然而,如果 Pod 对应的 restartPolicy 值为 Never,它不会重新启动。
Init 容器能做什么?
- Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
- Init 容器可以安全地运行这些工具,避免这些工具导致应用镜像的安全性降低。
- 应用镜像的创建者和部署者可以各自独立工作,而没有必要联合构建一个单独的应用镜像。
- Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此,Init容器可具有访问 Secrets 的权限,而应用容器不能够访问。
- 由于 Init 容器必须在应用容器启动之前运行完成,因此 Init容器提供了一种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。一旦前置条件满足,Pod内的所有的应用容器会并行启动。
一、初始化容器
初始化容器即 pod 内主容器启动之前要运行的容器,主要是做一些前置工作,初始化容器具有以下特征:
1.初始化容器必须首先执行,若初始化容器运行失败,集群会一直重启初始化容器直至完成,注意,如果 pod 的重启策略为 Never,那初始化容器启动失败后就不会重启。
2.初始化容器必须按照定义的顺序执行,初始化容器可以通过 pod 的 spec.initContainers
进行定义。
二、init容器实验
一个pod中的init容器就是在主容器运行之前,做一些初始化的校验,它必须是按 照顺序走的,运行到结束,必须是完整的。一个pod中可以没有init容器,也可以有多个init容器。当所有的init 容器运行结束后,才开始运行主容器。
主容器有自己的开始和结束点。开始和结束中间有一些探针,readness就绪探针探测主容器可不可以用,访问下服务是否可用。liveness是存活探针,可以一直探测主容器的活动状态,当检测到容器出现问题时,会调用restartPolicy
init容器运行结束后就会消失
我们先写一个简单的资源清单,不定义init容器:
vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp
spec:
containers:
- name: myapp
image: myapp:v1
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80
hostPort: 80
resources:
limits:
memory: 100M
requests:
memory: 50M
nodeSelector:
kubernetes.io/hostname: server3
hostNetwork: true
运行,查看到这个资源清单里只运行了一个容器
把pod信息的输出转化为一个yaml文件:
kubectl get pod -o yaml
当我们创建测试pod的资源清单时发现格式混乱,是因为里面含有缩进
所以我们使用纯vi不缩进的形式来编写:
\vi init.yaml
apiVersion: v1
kind: Pod
metadata:
name: myapp-pod
labels:
app: myapp
spec:
containers:
- name: myapp-container
image: busybox:1.28
command: ['sh', '-c', 'echo The app is running! && sleep 3600']
initContainers:
- name: init-myservice
image: busybox:1.28
command: ['sh', '-c',