k8s教程（pod篇）-初始化容器

杨林伟

已于 2023-01-04 11:18:14 修改

阅读量1.2k

点赞数

分类专栏： # k8s 文章标签： kubernetes 容器化技术云原生

于 2022-12-28 22:00:00 首次发布

本文链接：https://blog.csdn.net/qq_20042935/article/details/128464261

版权

k8s 专栏收录该内容

41 篇文章 45 订阅

订阅专栏

文章目录

01 引言
02 举例
- 2.1 配置资源文件
- 2.2 创建并查看pod状态
03 初始化容器与应用容器的区别
03 文末

01 引言

声明：本文为《Kubernetes权威指南：从Docker到Kubernetes实践全接触（第5版）》的读书笔记

在很多应用场景中，应用在启动之前都需要进行如下初始化操作：

等待其他关联组件正确运行（例如数据库或某个后台服务）；
基于环境变量或配置模板生成配置文件；
从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中；
下载相关依赖包，或者对系统进行一些预配置操作。

Kubernetes 1.3版本引入了一个Alpha版本的新特性init container(初始化容器)，用于在启动应用容器（app container)之前启动一个或多个初始化容器，完成应用容器所需的预置条件。

与应用容器在本质上是一样的，但它们是仅运行一次就结束的任务，并且必须在成功运行完成后，系统才能继续执行下一个容器，如下图所示：
在这里插入图片描述

备注：根据Pod的重启策略（RestartPolicy)，当init container运行失败而且设置了RestartPolicy=Never时，Pod将会启动失败；而设置RestartPolicy=Always时，Pod将会被系统自动重启。

02 举例

下面以Nginx应用为例，在启动Nginx之前，通过初始化容器busybox，为Nginx 创建一个index.html主页文件。

2.1 配置资源文件

这里为init container和Nginx设置了一个共享的Volume，以供Nginx访问init container设置的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: {}

2.2 创建并查看pod状态

创建完成后，在运行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容器：
在这里插入图片描述
启动成功后，登录进Nginx容器,可以看到/usr/share/nginx/html目录下的 index.html文件为init container所生成。

03 初始化容器与应用容器的区别

3.1 运行方式不同

init container 的运行方式与应用容器不同，它们必须先于应用容器执行完成，当设置了多个init container时，将按顺序逐个运行，并且只有前一个init container运行成功后才能运行后一个init container。

在所有init container都成功运行后，Kubernetes才会初始化Pod的各种信息，并开始创建和运行应用容器。

3.2 资源与策略设置等

在init container的定义中也可以设置资源限制、Volume的使用和安全策略等等，资源限制的设置与应用容器略有不同：

如果多个init container都定义了资源请求/资源限制，则取最大的值作为所有init container的资源请求值/资源限制值。
Pod的有效（effective）资源请求值/资源限制值取以下二者中的较大值：①所有应用容器的资源请求值/资源限制值之和；②init container的有效资源请求值/资源限制值。
调度算法将基于Pod的有效资源请求值/资源限制值进行计算，也就是说 init container可以为初始化操作预留系统资源，即使后续应用容器无须使用这些资源。
Pod的有效QoS等级适用于init container和应用容器。资源配额和限制将根据Pod的有效资源请求值/资源限制值计算生效。
Pod级别的cgroup：将基于Pod的有效资源请求/限制，与调度机制一致。