开发者应该了解Kubernetes对于程序的影响点

2019-10-29    来源:多智时代

容器云强势上线!快速搭建集群,上万Linux镜像随意使用

开发者是否要了解Kuberntes呢?

现在Kubernters越来越热了,很多公司都在开发、测试以及生产上逐步使用上了Kubernetes作为容器集群管理平台。最新调查显示,在5000+的大型企业中,有超过40%的生产环境已经使用上Kubernetes(*)。但是一般的理解,Kubernetes是更偏运维类的系统,开发似乎不用太关注,是否是这样?答案是否定的!

虽然说,多数开发者可以不用改动原有应用就可以把这些应用迁移/搬移到容器平台里(这里用“搬移”意思是,更多的是使用者把容器直接作为虚机对待),但是如果需要更好的使用Kubernetes,则开发者需要理解kubernetes的一些架构以及原理,并对程序架构以及一些实现细节作出调整。本文从一些细节上解释一下程序需要做出的适配点,以更好的把程序运行到Kuberentes上。

处理好IP无关性/动态性

在程序中,要做到把程序间的相互调用做到不写死IP,而且要能适配容器的IP的漂移。要做到IP无关性,可以通过以下几个方式:

  1. 通过微服务的服务注册与发现的方式来获取对端IP。注意这个是容器IP,一般在集群外是不可见的。如果还有Kubernetes集群外的应用,要直接访问POD(特别是Springcloud类应用混布),则需要考虑网络模型的问题。在阿里云里,提供了Terway的网络模式,利用了弹性网卡技术(ENI)可以直接支持ECS与POD的互通,很好的支持程序往容器化演进。

    (terway已经开源https://github.com/AliyunContainerService/terway,求star)

  2. 通过Kubernetes的SLB Service或者Ingress的方式访问POD。特别是对于传统非改造的的应用直接搬迁,需要使用这个模式。因为SLB/Ingress的对外IP是固定。如果是集群中访问,则使用service的域名方式访问更好。

处理好程序的外部配置

通常,原有的程序都是将相关配置写到本地配置文件的。到了容器特别是Kubernetes后,这个方式务必改变,因为程序的启动过程已经无法人为干预,同时需要能适配支持程序实例的伸缩,而不是固定将程序设计成固定的实例数。

充分利用Kubernetes的configmap/secret

对于启动时的配置以及环境变量配置,尽可能配置到configmap以及secret中。这里需要注意的是,configmap/secret的改动是无法改变已经运行的容器的环境变量。如果是通过volume方式使用,则对应的文件在不确定时间时在已有的程序中生效。所以对于configmap/secret的使用,后续的变更都要通过rolling upgrade的方式使其新配置生效

利用配置中心

对于运行态的配置变更,需要利用微服务体系中的配置中心的概念来处理,需要其更好支持以下核心特性:

  • 必须支持动态推送

  • 必须支持版本管理

  • 必须支持容错和恢复

  • 支持安全通信

    在阿里云上可以免费使用配置中心:ACM,其已经很好的提供了以上特性。并且其已经开源出来,叫NACOS(https://nacos.io)

理解好程序的启动过程和启动时间

虽然很多时候我们听到容器的宣传是“秒级”启动,但是对于程序如何在容器/Kubernetes里启动,是需要程序有明确的认识的。

这里需要特别注意的是:“秒级启动”不能等同于“秒级可用”。因为程序在容器的启动过程大体如下:

开发者应该了解Kubernetes对于程序的影响点

这里标示的时间级别以一个普通tomcat业务程序为例(例如其需要连接mysql等)

所以开发者需要考虑这个过程对于程序的影响

利用好Kubernetes的健康检查双保险

以往健康检查的概念是做health check,但是到Kubernetes则变为了两重的检查,分别为:liveness和readiness,为什么呢?从上面的程序启动过程可以看见,容器启动并不代表程序已经可以被访问,特别是对于java类程序,还有springboot/tomcat等的启动过程,这个过程也是比较费时的。如果在这个时候去访问程序则是很容易timeout的。

  • Liveness: 确保应用还存活,不然Kubernetes就会重启这个POD

  • Liveness prob合理设置initialDelaySeconds值,避免不断重启POD(考虑使用99%的最大延迟最为配置值比较合适)

  • Readiness: 确保应用已经可以接收流量了,不然不会分发流量给他,常见问题如:首次访问超时

  • 用于检查的三种类型探针:http, cmd, tcp,可以根据程序情况使用

基于这个设计原则,程序需要考虑提供两个被检查的接口。一个即刻欧用于判断程序是否存活,例如直接返回http 200。一个接口用于判断程序是否能正常处理请求,特别是对于程序依赖连接数据库、redis等外资源才能提供服务,则这个接口需要去检查这些外部资源是否可以使用。这两个接口是明确的含义,千万别用反了。

小结

对于IT系统架构越来越复杂的越来越智能的今天,开发者已经可以把更多的精力放在了业务开发上,但是从架构设计上,还是需要对Kubernetes有个深刻的认识,以免违背Kubernetes的设计原则。

标签: 网络模型 阿里云 数据 

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点!
本站所提供的图片等素材,版权归原作者所有,如需使用,请与原作者联系。

上一篇:区块链的下一个10年?

下一篇:云时代下,企业IT运维如何应势而变?