博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
Kubernetes init container
阅读量:6515 次
发布时间:2019-06-24

本文共 1979 字,大约阅读时间需要 6 分钟。

目录

简介

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

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

kubernetes v1.3引入了一些alpha版本的新特性init container(在v1.5版本时被更新为beta版本),用于在启动应用容器之前 启动一个或多个“初始化”容器,完成应用容器所需的预置条件。init container与应用容器本质上是一样的,但它们是仅运行一次就结束的任务,并且必须在成功执行完成后,系统才能继续执行下一个容器。根据pod的重启策略,当init container执行失败,在设置了RestartPolicy=Never时,pod将自动启动失败;而设置RestartPolicy=Always时,Pod将会被系统自动重启。

配置

下面以一个nginx应用为例,在启动nginx之前,通过初始化容器busybox为nginx创建一个index.html的主页文件。这里为init container和nginx设置了一个共享的volume,以供nginx访问init container设置的index.html文件:

nginx-init-containers.yaml内容如下:

apiVersion: v1kind: Podmetadata:  name: nginx  annotations:spec:  initContainers:  - name: install    image: busybox    command:    - wget    - "-O"    - "/work-dir/index.html"    - "http://kubernetes.io"    volumeMounts:    - name: workdir      mountPath: "/work-dir"  containers:  - name: workdir    image: nginx    ports:    - containerPort: 80    volumeMounts:    - name: workdir      mountPath: /usr/share/nginx/html  dnsPolicy: Default    volumes:    - name: workdir      emptyDir: {}

init container与应用容器的区别

简单的说明一下两者的区别:

  • init container的运行方式与应用容器不同,它们必须先于应用容器执行完成,当设置了多个init container时,将按顺序逐个运行,并且只有前一个init container运行成功后才能运行后一个init container。当所有init container都成功运行后,kubernetes才会初始化pod的各种信息,并开始创建和运行应用容器。
  • 在init container的定义中也可以设置资源限制、volume的使用和安全策略等等。但资源限制的设置与应用容器不同:
    • 如果多个init container都定义了资源请求/资源限制,则取最大的值作为所有init container的资源请求值/资源限制值。
    • pod的有效资源请求值/资源限制值取以下二者中的较大值:
      • 所有应用容器的资源请求值/限制值之和
      • init container的有效资源请求值/限制值
    • 调度算法将基于pod的有效资源请求值/限制值进行计算,也就是说init container可以为初始化操作预留系统资源,即使后续应用容器无须使用这些资源。
    • pod的有效QoS等级适用于init container和应用容器。
    • 资源配额和限制将根据pod的有效资源请求/限制,与调度机制一致。
  • init container不能设置readinessProbe探针,因为必须在它们成功运行以后才能继续运行pod中定义的普通容器。将pod重启时,init container将会重新运行,常见的pod重启场景如下:
    • init container的镜像被更新时,init container将重新运行,导致pod重启,仅更新应用容器的镜像只会使得应用容器被重启。
    • pod的infrastructure容器更新时,pod将会重启。
    • 或pod中的所有应用容器都终止了,并且RestartPolicy=Always时,则pod将会重启。

转载于:https://www.cnblogs.com/breezey/p/8810079.html

你可能感兴趣的文章
context.getSystemService的简单说明
查看>>
php中的正则函数:正则匹配,正则替换,正则分割 所有的操作都不会影响原来的字符串....
查看>>
三个小时学会wordpress模板制作
查看>>
【网络协议】TCP协议简单介绍
查看>>
利用SMB jcifs实现对windows中的共享文件夹的操作
查看>>
Spring(十七):Spring AOP(一):简介
查看>>
html5常用属性text-shadow、vertical-align、background如何使用
查看>>
微软正式宣布Azure MongoDB Atlas免费方案
查看>>
Jessica Kerr:高绩效团队简史
查看>>
开发者需要知道的有关软件架构的五件事
查看>>
GitLab 9提供了子群组、部署面板和集成监控
查看>>
继爆款超级账本后,IBM再次推出新产品
查看>>
贝壳金控赵文乐:基于 Spring Cloud 的服务治理实践
查看>>
Python数据可视化的10种技能
查看>>
最新2018年全球DevOps薪资报告:行业和团队选择指南
查看>>
IODA架构简介
查看>>
MyHeritage是如何实现发布到生产环境的
查看>>
Netflix:当你按下“播放”的时候发生了什么?
查看>>
Apache HBase的现状和发展
查看>>
OCaml已经做好iOS开发准备
查看>>