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

摘要： 主要介绍开发者对于程序上kubernetes须要注意的点

开发者是否要了解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/AliyunCont...，求star)

1. 经过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里启动，是须要程序有明确的认识的。

这里须要特别注意的是：“秒级启动”不能等同于“秒级可用”。由于程序在容器的启动过程大致以下：

这里标示的时间级别以一个普通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的设计原则。

本文做者：了哥-duff

阅读原文

本文为云栖社区原创内容，未经容许不得转载。