0
点赞
收藏
分享

微信扫一扫

k8s教程(23)-初始化容器


文章目录

  • ​​01 引言​​
  • ​​02 举例​​
  • ​​2.1 配置资源文件​​
  • ​​2.2 创建并查看pod状态​​
  • ​​03 初始化容器与应用容器的区别​​
  • ​​3.1 运行方式不同​​
  • ​​3.2 资源与策略设置等​​
  • ​​3.3 探针设置​​
  • ​​03 文末​​

01 引言

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

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

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

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

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

k8s教程(23)-初始化容器_kubernetes

备注:根据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​​容器:

k8s教程(23)-初始化容器_Pod_02


启动成功后,登录进​​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的有效资源请求/限制,与调度机制一致。

3.3 探针设置

init container不能设置​​readinessProbe​​探针,因为必须在它们成功运行后才能继续运行在Pod中定义的普通容器。

Pod重新启动时,​​init container​​将会重新运行,常见的Pod重启场景如下:

  • init container的镜像被更新时,init container将会重新运行,导致Pod重启。仅更新应用容器的镜像只会使得应用容器被重启。
  • Pod的infrastructure容器更新时,Pod将会重启。
  • Pod中的所有应用容器都终止了,并且RestartPolicy=Always,则Pod会重启。

03 文末

本文主要讲解pod的初始化容器,希望能帮助到大家,谢谢大家的阅读,本文完!


举报

相关推荐

0 条评论