Kubernetes容器云的互联网企业实践

内容来源：2017 年 11 月 25 日，当当网数字业务事业部技术总监李志伟在“Kubernetes Meetup | 北京站”进行《Kubernetes容器云的互联网企业实践》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：3488 | 9分钟阅读

嘉宾演讲视频及PPT回顾： t.cn/R1dGfA5

摘要

本次演讲主要分享了在Kubernetes领域的实践和经验，分别介绍了将原应用迁移到Kubernetes的前期准备以及迁移过程当中使用的规范。

现有平台面临的挑战

不一样企业开始往容器方向发展的初衷是不同的，有些企业是由于没有运维工程师或运维团队，而想要借助某个平台实现运维自动化。

有些企业多是因为计算资源的利用率比较低。虽然一些大型的互联网公司都是动辄拥有成千上万台服务器，但实际上以我我的的经从来看计算资源的利用率都不高，这里有不少历史的缘由，其中之一就是为了得到更好的隔离性，而实现隔离最好的办法就是采用从物理机到基于虚拟的私有云技术。

对于有着比较长历史的公司，应用部署每每会和本地的运行环境强相关，使得迁移变得很是困难，这时也须要有一个好的解决方案来解耦。另外业务总量的繁多，也会带来管理的复杂度的提升。

为何选择Kubernetes

上面提到的这些问题在咱们的生产实践中都有不一样程度的遇到，虽然有不少的解决方案，可是咱们最终仍是选择了Kubernetes。

Kubernetes首要解决了计算资源利用率低下的问题，得益于此咱们的服务器数量减小了一半。容器化解决了计算资源利用率问题。

业务容器镜像一次构建，就可以运行在多种环境上，这种方式减小了对运行环境的以来，给运维平台带来了足够的灵活性，解决了服务商锁定的问题，咱们当时考虑的是若是某个IDC服务商不知足服务要求如何作到快速迁移，通常来讲大批量的服务迁移代价很是高，须要很长时间，容器化以后业务迁移时间只须要30分钟左右。

经过Kubernetes的架构设计思想咱们还能够规范网站系统的架构设计。最后还有一点就是它实现了运维自动化。

向容器云平台迁移前的准备工做

要想向容器云迁移，企业内部须要必定的运维能力，若是企业的规模还不够大，也能够考虑一些国内的容器云服务提供商。下面来讲下咱们本身所作的一些准备工做。

首先天然是搭建Kubernetes集群，私有Docker镜像仓库构建采用的是harbor，而后是独立出来的集群监控，CI/CD基础设置使用的是Jenkins和helm，分布式存储解决方案用的是Glusterfs。

业务迁移中使用的规范

从2015年末1.0版到以后的1.二、1.3版Kubernetes中的问题仍是比较多的，企业要使用它是须要必定勇气的。但如今基本上趋于成熟，对于大部分应用不用太多的改造也能够跑的很好。

即便是这样，也不是全部的应用均可以迁移到容器云中，若是应用可以很好的符合云原生的设计原则固然能够迁移进来，可是大部分的应用并非按照这样的设计原则设计的。这个时候最好的办法是先将业务迁移进来，而后再逐步演进成微服务架构。

在这个过程当中咱们刚开始其实也没有任何规范，以后才陆续制定了相关规范，下面来具体看下迁移规范。

容器镜像封装的基本原则

早期不少系统架构师都将Docker当作轻量级的虚拟机在使用，但这并非最佳实践，要想正确的使用Docker须要符合如下基本原则：

- 尽量设计成无状态服务，它带来的好处就是可以很是容易的作水平扩展

- 尽量消除没必要要的运行环境依赖，若是容器内业务依赖太多水平扩展就会变的很是困难，在传统的部署形式下，不管是虚拟机部署仍是物理机部署都常常会产生各类各样不必的依赖，对于有必定历史的企业这个问题就会很是严重

- 须要持久化的数据写入到分布式存储卷

- 尽量保证业务单一性，这样可以让分布式应用很容易扩展，一样它也是微服务架构中的设计原则

- 控制输出到stdout和stderr的日志写入量

- 配置与容器镜像内容分离

- 容器中使用K8S内部dns代替ip地址配置形式

- 日志采用集中化处理方案（EFk）

- 采用独立的容器处理定时任务

NameSpace的使用

因为考虑到测试环境和staging等运行环境的资源利用率并不高，因此就想在一个集群内部同时运行开发、测试、staging、生产环境。经过NameSpace实现不一样运行环境的隔离，同时应用软件在不一样的运行环境之间也不会产生命名冲突。

Service的命名规范

在v1.5版以前Service的命名不能超过24个字符，v1.5版以后最多63个字符。另外还须要知足正则regex[a-z]([-a-z0-9]*[a-z0-9])?的要求，这意味着首字母必须是a-z的字母，末字母不能是-，其余部分能够是字母数字和-符号。通常来讲命名方式都是使用“业务名-应用服务器类型-其余标识”的形式，如book-tomcat-n一、book-mysql-m1等。

应用健康检查规范

应用健康检查规范是实现自动化运维的重要组成部分，也是系统故障自动发现和自我恢复的重要手段。目前有两种健康检查方式，分别是进程级和业务级。

进程级健康检查是Kubernetes自己具有的，它用来检验容器进程是否存活，是默认开启的。

业务级的健康检查由咱们本身实现，它有三点要求，一是必需要检查自身核心业务是否正常，二是健康检查程序执行时间要小于健康检查周期，三是健康检查程序消耗资源要合理控制，避免出现服务抖动。

健康检查程序在不一样环境下有着不一样的实现：

web服务下采用HTTPGET方式进行健康检查，须要实现一个“/healthz”URL，这个URL对应的程序须要检查全部核心服务是否正常，健康检查程序还应该在异常状况下输出每个检查项的状态明细。

其余网络服务下能够采用探查容器指定端口状态来判断容器健康状态。

非网络服务下须要在容器内部执行特定命令，根据退出码判断容器健康状态。

Yaml中Image tag配置规范

部署容器镜像时应该避免使用latest tag形式，不然一旦出现问题就难以跟踪到当前运行的Image版本，也难以进行回滚操做。因此建议每一个容器Image的tag应该用版本号来标识。

使用ConfigMap实现应用平滑迁移

早期的1.0版本配置信息都是写在配置文件中的，要作迁移就须要改不少东西，当时就只有几种方法能够传递配置信息，其中一种是经过环境变量传递，而后内部还要有一个对应机制进行转化，这实际上是很是麻烦的过程。可是如今有了ConfigMap以后，就只须要将原先的配置文件导入到ConfigMap中就好了。

迁移中遇到的其余问题

关于CI/CD

咱们在作迁移的时候采用的是Jenkins来实现CI/CD的，而后经过Helm来实现软件包管理，Helm是Kubernetes的官方子项目，做为企业内部的应用管理是很是方便的，它使得开发者不用再去关注Kubernetes自己而只须要专一于应用开发就够了。

时区的配置问题

从官方下载的镜像都会有默认时区，通常咱们使用的时候都须要更改时区，更改时区的方式有多种，这里简单说两种。一是将容器镜像的/etc/loacltime根据须要设置为对应的时区，二是采用配置文件中的volume挂载宿主机对应的localtime文件的方式。推荐采用第二种方式。

外部网络访问Service

在没有Ingress的时候咱们是使用内建Nginx容器来转发集群内部服务，如今则是经过Ingress转发集群内部服务，Ingress经过NodePort方式暴露给外网。

最佳组合

上图展现的是Kubernetes的最佳组合，它以DevOps做为基础，上层是k8s加上Containers，顶层构筑的是微服务应用。这样的组合带来的不只是一个容器云，更多的是改变了研发流程和组织结构，这主要是受微服务的架构思想影响。

过去完成一个应用的版本发布可能要多人协同，一旦有紧急发布的时候就会发现这实际上是很是笨重的。可是若是是基于微服务架构作的应用，每每一到两我的就能够维护一个微服务，他们本身就能够决定这个微服务是否独立部署上线。

关于微服务和Kubernetes还有一个优点必需要强调，配合CI/CD开发人员终于能够再也不考虑部署环境的细节了。