专栏首页架构师重磅!K8S 1.18版本将内置支持SideCar容器。

重磅!K8S 1.18版本将内置支持SideCar容器。

作者:justmine 头条号:大数据与云原生

一、前言

Kubernetes的目标不仅是使分布式应用程序的部署和运维变得简单可靠,还旨在能轻松地创建“云原生”应用程序,即易于创建在云环境中运行的分布式应用程序和服务,于是从1.18版本开始K8S将原生支持生命周期类型为SideCar的容器。

在云原生时代,通过将应用的非业务功能提到SideCar容器实现解耦,避免重复建设,给运维人员提供更为丰富而深入的控制同时,也大大减轻了开发人员的负担。

随着越来越多的应用程序开始实施这种模式,在K8S中出现了很多的问题。很快,Kubernetes意识到应该提供一种边车模式的容器,并以不同的方式处理此类容器的生命周期。

二、痛点

Sidecar容器的所有问题都与容器生命周期相关性有关。由于Pod中的常规容器之间没有区别,因此无法控制哪个容器首先启动或最后终止,但是先正确运行Sidecar容器通常是应用程序容器正确运行的要求。

Pod启动

让我们看一个Istio服务网格示例。Envoy边车负责将所有传入和传出流量代理到应用程序容器。因此,在代理启动并运行之前,应用程序应该无法发送或接收流量。此时,如果应用程序尝试出站访问,则K8S的就绪性探针便形同虚设。如果应用容器先启动,您会在日志中看到很多莫名的错误消息,明明应用已启动了,为什么还报503呢?但如果代理容器正常启动,但业务容器遭遇CrashLoopBackoffs时,应用容器根本启动失败,此时代理容器该何去何从?

其实这也不是一个非常棘手的问题,我们可以在应用程序容器的启动脚本中添加几秒钟的延迟,通过一个丑陋的解决方法间接地解决此问题,这也是Istio当下的做法。

三、解决方案

为了彻底解决上述痛点,从1.18版本开始,K8S内置的Sidecar功能将确保边车在正常业务流程开始之前就启动并运行,即通过更改pod的启动生命周期,在init容器完成后启动sidecar容器,在sidecar容器就绪后启动业务容器,从启动流程上保证顺序性。

四、新功能的影响

作业完成

如果Kubernetes作业具有Sidecar容器,则即使主容器完成后它仍将继续运行,并且作业本身永远不会达到完成状态。因为解决该问题的唯一方法是在业务过程完成时以某种方式发送信号给sidecar容器以退出。

这种解决方法存在一些问题:这意味着使用自定义逻辑扩展所有作业,并以某种方式在容器之间进行同步:通过共享的暂存卷或某些临时解决方案,例如Envoy的/quitquitquit终结点。

故从Kubernetes 1.18开始,如果所有普通容器都已到达终端状态(Succeededfor restartPolicy=OnFailureSucceeded/Failedfor restartPolicy=Never),则将向所有sidecar容器发送 SIGTERM信号。

Pod关闭

Pod关闭与Pod启动类似。如果Sidecar在业务过程之前终止,则在正常拆除业务应用程序期间可能会导致大量错误。在正常关闭期间,应用程序可以执行某种清除逻辑,例如关闭长期连接,回滚事务或将状态保存到外部存储(例如s3)。如果首先杀死了边车,则可能会导致清理逻辑无法正常运行。

一个很好的例子是argo项目中报告的一个问题。Argo尝试将容器日志存储在s3中,但是如果istio-proxy先杀死则无法这样做,因为所有流量都应流经该容器。

此类问题的解决方案类似于启动问题。通过更改Pod终止生命周期,首先向所有应用容器发送一个SIGTERM信号,等所有应用容器全部正常终止后,再向所有边车容器发送SIGTERM信号。在正常的平滑期(TerminationGracePeriod)内,如果所有的应用容器还未终止,像以前一样发送SIGKILL信号强制终止,然后发送SIGTERM信号给边车容器。

五、如何使用新功能?

通过更改Pod规范中的container.lifecycle.type将容器标记为边车类型:Sidecar,默认为Standard,如下:

apiVersion: v1
kind: Pod
metadata:
  name: bookings-v1-b54bc7c9c-v42f6
  labels:
    app: demoapp
spec:
  containers:
  - name: bookings
    image: banzaicloud/allspark:0.1.1
    ...
  - name: istio-proxy
    image: docker.io/istio/proxyv2:1.4.3
    lifecycle:
      type: Sidecar
    ...

注意:在k8s 1.18版本,边车模式仅仅作为支撑功能,故需要通过Api Server显示启用。

六、总结

本篇先详细介绍了K8S即将推出的重磅功能,可以说此功能专为云原生而设计,这也是为什么K8S会越来越受欢迎的原因,然后进一步分析了当下K8S实施边车模式的痛点,以及引入新功能的一些影响,最后通过例子演示了如何应用边车模式到Pod中,可以看出此功能将从根本上解决目前很多使用边车模式存在的问题。

七、最后

如果有什么疑问和见解,欢迎评论区交流。

如果觉得本篇有帮助的话,欢迎推荐转发

如果觉得本篇非常不错的话,可以请作者吃个鸡腿,创作的源泉将如滔滔江水连绵不断,嘿嘿。

八、参考资料

https://banzaicloud.com/blog/k8s-sidecars

https://github.com/kubernetes/enhancements/issues/753

https://kubernetes.io/blog/2016/06/container-design-patterns

本文分享自微信公众号 - 架构师修行之路(jiagoushixiuxing)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2020-02-14

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 云时代Docker原理万字详解!!!

    Docker 是一个开源的应用容器引擎,基于 Go 语言 并遵从 Apache2.0 协议开源。

    架构师修行之路
  • 程序员修神之路--有了容器为什么kubernetes还需要Pod?

    当我们采用容器化技术的时候,摒弃了传统的物理机或者虚拟机的部署方式,以一种更加轻快,便捷的方式来部署我们的应用。到容器化的进阶,再加上kubernetes对容器...

    架构师修行之路
  • 程序员修神之路--容器技术为什么会这么流行

    在传统的软件部署方式中,程序员需要把要发布的应用程序打成包发给运维人员,然后由运维人员在生产环境进行部署。当随着应用的版本迭代越来越多,应用的依赖库版本错综复杂...

    架构师修行之路
  • 重磅!K8S 1.18版本将内置支持SideCar容器。

    Kubernetes的目标不仅是使分布式应用程序的部署和运维变得简单可靠,还旨在能轻松地创建“云原生”应用程序,即易于创建在云环境中运行的分布式应用程序和服务,...

    justmine
  • 美团容器平台架构及容器技术实践

    美团的容器集群管理平台叫做HULK。漫威动画里的HULK在发怒时会变成“绿巨人”,它的这个特性和容器的“弹性伸缩”很像,所以我们给这个平台起名为HULK。貌似有...

    美团技术团队
  • 谈到云原生, 绕不开"容器化"

    在《Cloud Native Patterns》一书中,作者Cornelia Davis指出:“容器是云原生应用的基石”; 云原生基金会将微服务容器化作为云原生...

    小码甲
  • 支持100+业务线、累计发布17万次|宜信容器云的A点与B点(分享实录)

    宜信公司从2018年初开始建设容器云,至今,容器云的常用基本功能已经趋于完善,主要包括服务管理、应用商店、Nginx配置、存储管理、CI/CD、权限管理等,支持...

    宜信技术学院
  • [docker](八)docker -- 网络管理

    如图所示,Docker daemon通过调用libnetwork对外提供的API完成网络的创建和管理等功能。libnetwork中则使用了CNM来完成网络功能的...

    baron
  • 为什么保护容器和微服务很难?

    开发人员可用容器创建微服务,也就是应用的可重用组件。因为可重用,微服务能帮开发人员免掉重新开发的时间。另外,微服务可跨不同平台部署。

    用户6543014
  • 关于容器、微服务、docker的十大问题

    容器的运行无法简单参考虚拟机的实践经验。例如,几乎任何工作负载都可以立即虚拟化,但是有些工作负载适合容器化部署,有的则不适合。

    FB客服

扫码关注云+社区

领取腾讯云代金券