我是靠谱客的博主 朴实小海豚,最近开发中收集的这篇文章主要介绍Kubernetes踩坑:kubelet GC导致init containers不断重建活动预告:云原生消息中间件平台构建及应用实践,觉得挺不错的,现在分享给大家,希望可以做个参考。

概述

本文由作者授权发布,未经许可,请勿转载。

作者:李岚清,网易杭州研究院云计算技术中心资深工程师

什么是init container

init Container就是用来做初始化工作的容器,可以是一个或者多个,如果有多个的话,这些容器会按定义的顺序依次执行,只有所有的Init Container执行完后,app container才会被启动。因此,init container 提供了一种机制来阻塞或延迟应用容器的启动,直到满足了一组先决条件。

主要有以下应用场景:

  • 等待其它模块Ready:比如我们有一个应用里面有两个容器化的服务,一个是Web Server,另一个是数据库。其中Web Server需要访问数据库。但是当我们启动这个应用的时候,并不能保证数据库服务先启动起来,所以可能出现在一段时间内Web Server有数据库连接错误。为了解决这个问题,我们可以在运行Web Server服务的Pod里使用一个InitContainer,去检查数据库是否准备好,直到数据库可以连接,Init Container才结束退出,然后Web Server容器被启动,发起正式的数据库连接请求。

  • 初始化配置,下载依赖:比如某个应用的某个依赖是经常变动的,通常不会打到镜像里面。这个时候就可以在应用init container中动态下载依赖或者配置,然后再启动应用容器。

遇到了什么问题

pod状态,在InitRunning之间不断变换,发现init容器被不断删除、重建、重复运行。

分析原因

kubelet有两个命令行参数:

  • --maximum-dead-containers: 每个节点上最多有几个处于exit状态的容器
  • --maximum-dead-containers-per-container:每个container最多有几个处于exit状态的容器

如果dead 容器超过上述配置,kubelet会自动GC。而init container是run to completed类型的容器,如果数量太多,会被kubelet GC。而一旦被GC,kubelet又会重建该init container,从而引起上面的问题。

社区也有人反馈过这个问题 #77859。

推荐解决方式

建议采用默认配置:

--maximum-dead-containers=-1
--maximum-dead-containers-per-container=1

这两个参数当前的状态是Deprecated,建议使用 --eviction-hard or --eviction-soft 替代。

fs.Int32Var(&f.MaxContainerCount, "maximum-dead-containers", f.MaxContainerCount, "Maximum number of old instances of containers to retain globally.  Each container takes up some disk space. To disable, set to a negative number.")

fs.MarkDeprecated("maximum-dead-containers", "Use --eviction-hard or --eviction-soft instead. Will be removed in a future version.")

作者简介

李岚清,网易杭州研究院云计算技术中心轻舟容器编排团队资深系统开发工程师,具有多年Kubernetes开发、运维经验,主导实现了容器网络管理、容器混部等生产级核心系统研发,推动网易集团内部电商、音乐、传媒、教育等多个业务的容器化。

 

活动预告:云原生消息中间件平台构建及应用实践


  • 讲师:刘泽波,网易杭研资深平台开发工程师
  • 时间: 6月23日 19:00-20:00
  • 地点:在线直播

讲师简介

刘泽波,网易杭州研究院资深平台开发工程师,在消息和云原生领域有多年的研发经验,目前在网易轻舟消息中间件团队从事 PaaS 中台及消息中间件产品的研发工作。

议题摘要

本议题主要介绍,如何利用 K8s 平台的能力,来打造一套面向大规模生产环境云原生消息中间件服务,介绍云原生消息中间件平台的构建思路,以及在实际应用中的经验与教训。帮助用户构建容错性好、易于管理、易于观察、易于扩展的消息中间件平台,帮助业务轻松实现大规模消息中间件集群的可靠、可预测、高频次的重大变更。

议题大纲

1、背景介绍

2、构建云原生消息中间件平台

- 云原生消息中间件平台总览

- 消息中间件容器化部署

- 监控及自动化运维

- PaaS 服务底座

- 消息中间件 Service Mesh 化

3、云原生消息中间件应用实战

- 云原生消息中间件在传媒上的实践

- 云原生消息中间件在网易疾风物联网平台上的实践

4、后续规划与展望

听众收益

  1. 了解消息中间件容器化、服务化的实现思路
  2. 了解消息中间件 RocketMQ/Kafka K8s 及 Service Mesh 化的构建思路
  3. 了解大规模消息中间件容器化应用过程中遇到的问题

一图 get 网易杭研大神分享核心信息:

报名预约:云原生消息中间件平台构建及应用实践

议题1回顾:Envoy xDS 详解

议题2回顾:Service Mesh 技术在美团的落地和挑战

最后

以上就是朴实小海豚为你收集整理的Kubernetes踩坑:kubelet GC导致init containers不断重建活动预告:云原生消息中间件平台构建及应用实践的全部内容,希望文章能够帮你解决Kubernetes踩坑:kubelet GC导致init containers不断重建活动预告:云原生消息中间件平台构建及应用实践所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错,欢迎将靠谱客网站推荐给程序员好友。

本图文内容来源于网友提供,作为学习参考使用,或来自网络收集整理,版权属于原作者所有。
点赞(59)

评论列表共有 0 条评论

立即
投稿
返回
顶部