Application on kubernetes实践

Application on kubernetes实践

本文档是GCE推出的文章的概要总结，详细的内容可以查看后文链接。该文档用于指导应用迁移到kubernetes中，给出的实践总结，希望能够帮助到需要将应用运行到kubernetes的开发者。

建立更小的镜像

Docker公司创新的提出容器镜像概念，通过定义Dockerfile以及执行docker build可以制作出来一个镜像，但是针对生产环境中运行的容器镜像需要考虑如下的内容。

1. Baseimage：尽量维护统一的baseimage,裁剪baseimage,使得尽可能的小，统一在baseimage中配置（时区，用户等）以及安装依赖baseimage的image所需要的公共的工具和库
2. 镜像仓库：统一的镜像仓库，构建从代码提交->自动编译打包镜像->推送仓库->生产发布整套流程，通过tag来区分不同的版本，通过不同的镜像仓库来区分不同级别的镜像（生产、测试）
3. 减少镜像的层级，在不降低Dockerfile的可读性，有目的的合并Dockerfile中的语句，减少镜像的层级
4. 镜像漏洞扫描：定时更新漏洞库，定时对镜像进行全量、增量进行

通过kubernetes中的namespaces来进行资源划分和管理

当多个组织使用同一套kubernetes集群的时候，同一个namespace下资源对象的名称是不能相同的，需要基于使用者划分到不同的namespace.通过namespace使得资源的管理更加的简单
这里针对不同namespace,kubernetes提供了更多的机制让做更多的事情成为可能

1. 基于namespace设置quotos
2. 通过net policy 基于namespce进行网络隔离

使用readiness和liveness进行健康检查

健康检查是用来表示实例是否正常的工作，用来判断请求的流量是否转发到该后端。如果该实例无法正常工作，发送到该services流量将不会发送到不健康的pods.kubernetes提供了两类健康检查探针　Readiness, Liveness。

1. Readiness:将用于表示pod可以处理服务请求，readiness 探没有通过，kubernetes不会将流量发送给该pod进行处理
2. liveness:表示应用是否正常工作，如果该探针执行失败，则将会导致kubernetes移除pod并进行重建

探针支持三种类型：HTTP, Command, TCP
探针详细的配置参数可以查阅kubernetes官方文档

指定pod中资源的request&limits

request声明对于资源的使用量，scheduler会根据request调度到合适的节点，来承载应用
limit声明该pod对资源的使用上限

优雅退出

改造应用本身捕获信号，处理退出处理，或者是使用kuernetes中的preStop hook来进行优雅的pod删除
首先分析pod优雅退出的过程

1. pod设置成Ternminnating状态，从所有services的endpoint移除
2. preStop hook被执行,preStop hook 是在不修改应用处理SIGTERM信号，最好的处理优雅的pod删除
3. pod内部应用处理好接受到的SIGTERM，应用本身将会停止所有long-lived的connections.
4. pod等待优雅删除时间
5. 如果container在优雅周期内没有关闭，将会收到SIGKILL，进行pod移除操作。

映射外部服务

详细查看外部dns

无中断的升级节点

通过两种方式
1. 设置Rolling update ,通过滚动升级时实现平台的升级
2. 迁移到其他的node pools，通过将node切换到运维模式。

ref
https://medium.com/google-cloud/kubernetes-best-practices-season-one-11119aee1d10