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

做者：justmine 头条号：大数据与云原生 微信公众号：大数据与云原生 创做不易，在知足创做共用版权协议的基础上能够转载，但请以超连接形式注明出处。 为了方便阅读，微信公众号已按分类排版，后续的文章将在移动端首发，想学习云原生相关知识，请关注我。

1、前言

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

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

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

2、痛点

Sidecar容器的全部问题都与容器生命周期相关性有关。因为Pod中的常规容器之间没有区别，所以没法控制哪一个容器首先启动或最后终止，可是先正确运行Sidecar容器一般是应用程序容器正确运行的要求。

Pod启动

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

其实这也不是一个很是棘手的问题，咱们能够在应用程序容器的启动脚本中添加几秒钟的延迟，经过一个丑陋的解决方法间接地解决此问题，这也是Istio当下的作法。

3、解决方案

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

4、新功能的影响

做业完成

若是Kubernetes做业具备Sidecar容器，则即便主容器完成后它仍将继续运行，而且做业自己永远不会达到完成状态。由于解决该问题的惟一方法是在业务过程完成时以某种方式发送信号给sidecar容器以退出。

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

故从Kubernetes 1.18开始，若是全部普通容器都已到达终端状态（Succeededfor restartPolicy=OnFailure或Succeeded/Failedfor restartPolicy=Never），则将向全部sidecar容器发送 SIGTERM信号。

Pod关闭

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

一个很好的例子是argo项目中报告的一个问题。Argo尝试将容器日志存储在s3中，可是若是istio-proxy先杀死则没法这样作，由于全部流量都应流经该容器。

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

5、如何使用新功能？

经过更改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显示启用。

6、总结

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

7、最后

若是有什么疑问和看法，欢迎评论区交流。

若是以为本篇有帮助的话，欢迎推荐和转发。

若是以为本篇很是不错的话，能够请做者吃个鸡腿，创做的源泉将如滔滔江水连绵不断，嘿嘿。

8、参考资料

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

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

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

原文出处：https://www.cnblogs.com/justmine/p/12292861.html