开发者是否要了解Kuberntes呢？
现在Kubernters越来越热了，很多公司都在开发、测试以及生产上逐步使用上了Kubernetes作为容器集群管理平台。最新调查显示，在5000+的大型企业中，有超过40%的生产环境已经使用上Kubernetes(*)。但是一般的理解，Kubernetes是更偏运维类的系统，开发似乎不用太关注，是否是这样？答案是否定的！
虽然说，多数开发者可以不用改动原有应用就可以把这些应用迁移/搬移到容器平台里（这里用“搬移”意思是，更多的是使用者把容器直接作为虚机对待），但是如果需要更好的使用Kubernetes，则开发者需要理解kubernetes的一些架构以及原理，并对程序架构以及一些实现细节作出调整。本文从一些细节上解释一下程序需要做出的适配点，以更好的把程序运行到Kuberentes上。
处理好IP无关性/动态性
在程序中，要做到把程序间的相互调用做到不写死IP，而且要能适配容器的IP的漂移。要做到IP无关性，可以通过以下几个方式：
- 通过微服务的服务注册与发现的方式来获取对端IP。注意这个是容器IP，一般在集群外是不可见的。如果还有Kubernetes集群外的应用，要直接访问POD(特别是Springcloud类应用混布)，则需要考虑网络模型的问题。在阿里云里，提供了Terway的网络模式，利用了弹性网卡技术(ENI)可以直接支持ECS与POD的互通，很好的支持程序往容器化演进。
(terway已经开源https://github.com/AliyunContainerService/terway，求star) - 通过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的设计原则。
