k8s 开船记-脚踏两只船:船儿还是旧的好,不翻船才是硬道理

自从上次开始脚踏两只船(2个独立的k8s集群同时运行),园子暂时用奢侈的土豪方式过上了安稳的船上生活。 这种方式除了费钱之外,还带来一个问题,我们的集装箱自动装船系统(基于gitlab-ci的自动化部署)不灵了,不支持同时向2艘船装同样的货(2个gitlab-runner运行同1个job),后来,我们通过 gitlab 的秘密武器 parallel-matrix 解决了。

自从上次开始脚踏两只船(2个独立的k8s集群同时运行),园子暂时用奢侈的土豪方式过上了安稳的船上生活。

这种方式除了费钱之外,还带来一个问题,我们的集装箱自动装船系统(基于gitlab-ci的自动化部署)不灵了,不支持同时向2艘船装同样的货(2个gitlab-runner运行同1个job),后来,我们通过 gitlab 的秘密武器 parallel-matrix 解决了。

deploy-prod:
  stage: deploy
  tags:
    - k8s-prod
  variables:
    DEPLOY_CLUSTER: ${DEPLOY_CLUSTER}
  parallel:
    matrix:
      - DEPLOY_CLUSTER: [k8s-cluster0, k8s-cluster1]

注:上面的 DEPLOY_RUNNER 变量在部署中并没有实际用到,只是为了欺骗 gitlab-runner 以实现多个 runner 运行同一个 job。

这2艘船,一艘是旧船,引擎用的是 kubernetes 1.17.0。一艘是新船,引擎用的是 kubernetes 1.23.3,新船是今年春节后投入使用的,出现因大量 pod 同时  CrashLoopBackOff 而翻船的是新船。

上次翻船的博文中园友 Dicky_Zhang 的评论:

版本不对吧,一般不是建议使用1.23.5以上得版本吗,你们使用得.3,虽然说可能问题不大

让我们对新船产生了更多的怀疑,现在有了2只船,就更好验证了。

上周末我们停航了旧船(下线旧k8s集群),只投用新船,周六一切正常,周日又出现部分 pod 无缘无故 CrashLoopBackOff,后来投用新船恢复,证明了单独航行新船肯定会出问题

这周一2艘船并驾齐驱,一天平稳航行,一切正常。

今天周二依然是2艘船并驾齐驱,上午的访问高峰,新船又出问题了,整个集群有近 40% 的 pod 突然 CrashLoopBackOff(只有新闻应用因为所有 pod 都挂了,部分访问受影响),而旧船稳如泰山,证明了同时航行新旧船,新船会出问题,旧船不会

接下来,进行更重要的验证,将新船下线,在没有负载的情况下新船上的那些 CrashLoopBackOff 的 pod 很快就恢复正常。而没有新船相伴、独自航行的旧船,面对访问高峰的狂风暴雨,依然稳如泰山地如风平浪静般航行,证明了单独航行旧船不会出问题

通过今天的验证,我们推断 kubernetes 1.23.3 可能存在稳定性问题,接下来我们会尝试看能不能将新船的引擎降级为 1.22.8。

【更新1:18:00】

没找到降级的方法,准备铤而走险反其道行之——升级至 1.23.5,于是看了看 1.23.5 的 CHANGELOG ,有一个重大发现,竟然修复了一个内存泄漏(goroutine leaks)问题:

  • Bump sigs.k8s.io/apiserver-network-proxy/konnectivity-client to v0.0.30, fixing goroutine leaks in kube-apiserver. (#108438, @andrewsykim) [SIG API Machinery, Auth and Cloud Provider]

联系到我们遇到的翻船问题,我们推断内存泄漏引发翻船的嫌疑更大,升级到 1.23.5 正好可以验证。

【更新2:19:45】

引擎升级到 1.23.5 的新船已上线航行。

【更新3:3-23 10:21】

升级到 1.23.5 的新船也出现了同样的问题。

页面下部广告