专栏首页IT大咖说向Kubernetes容器云平台迁移,你必须知道的9件事

向Kubernetes容器云平台迁移,你必须知道的9件事

内容来源:2017 年 11 月 25 日,当当网数字业务事业部技术总监李志伟在“Kubernetes Meetup | 北京站”进行《Kubernetes容器云的互联网企业实践》演讲分享。

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

摘要

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

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

现有平台面临的挑战

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

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

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

为什么选择Kubernetes

上面提到的这些问题在我们的生产实践中都有不同程度的遇到,虽然有很多的解决方案,但是我们最终还是选择了Kubernetes。

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

业务容器镜像一次构建,就能够运行在多种环境上,这种方式减少了对运行环境的以来,给运维平台带来了足够的灵活性,解决了服务商锁定的问题,我们当时考虑的是如果某个IDC服务商不满足服务要求如何做到快速迁移,一般来说大批量的服务迁移代价非常高,需要很长时间,容器化之后业务迁移时间只需要30分钟左右。

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

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

要想向容器云迁移,企业内部需要一定的运维能力,如果企业的规模还不够大,也可以考虑一些国内的容器云服务提供商。下面来说下我们自己所做的一些准备工作。

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

业务迁移中使用的规范

从2015年底1.0版到之后的1.2、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-n1、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开发人员终于可以不再考虑部署环境的细节了。

以上为全部分享内容,谢谢大家!

相关推荐 推荐文章

  • 中国移动:Kubernetes在PaaS建设和NFV领域中的应用
  • docker + kubernetes=共生?相爱相杀?

本文分享自微信公众号 - IT大咖说(itdakashuo)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-06-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 云计算的下一个时代——“容器时代”

    摘要 随着容器技术的发展,容器成为了目前最受欢迎和关注的项目。京东在容器的实践过程中,结合虚拟机,对容器技术做了优化和改进,他们是怎么做的? ? 容器趋势分析 ...

    IT大咖说
  • 中国移动:Kubernetes在PaaS建设和NFV领域中的应用

    摘要 为了承载IT支撑系统、大数据、IoT 等应用的 PaaS 平台中,从技术架构上对 Kubernetes 的考虑和分析,并与现有的 OpenStack 技术...

    IT大咖说
  • 为什么不建议把数据库部署在docker容器内?

    近2年Docker非常的火热,各位开发者恨不得把所有的应用、软件都部署在Docker容器中,但是您确定也要把数据库也部署的容器中吗?

    IT大咖说
  • Docker+ Kubernetes已成为云计算的主流(二十五)

    最近正在抽时间编写k8s的相关教程,很是费时,等相关内容初步完成后,再和大家分享。对于k8s,还是上云更为简单、稳定并且节省成本,因此我们需要对主流云服务的容器...

    雪雁-心莱科技
  • Kubernetes 案例分析:从开源第一到企业落地

    企业在 Kubernetes 落地的过程当中都会面临这样那样的问题,今天我把才云 Caicloud 过去在企业落地的过程当中出现的一些问题做个归纳总结,同时也把...

    CNCF
  • 2019 容器使用量报告

    最近 sysdig 发布了 2019 容器使用报告,内容还比较有趣,特别来介绍一下。关注公众号「Moelove」回复 docker2019 即可获取完整 PDF...

    Jintao Zhang
  • Docker+ Kubernetes已成为云计算的主流(二十六)

    Amazon Web Services (AWS) 是亚马逊公司旗下云计算服务平台,为全世界范围内的客户提供云解决方案。AWS面向用户提供包括弹性计算、存储、数...

    心莱科技雪雁
  • 10个最佳的Docker容器集群编排工具

    docker毫无疑问是一个优秀的开源工具。但是,仅靠docker引擎和容器就不能进行复杂的应用程序部署。对于部署复杂的应用程序体系结构的容器群集,必须进行适当的...

    泽阳
  • 2018年Docker使用情况报告

    该报告基于从生产环境的90,000个容器中收集的实际数据,是去年样本量的两倍,并在多个垂直行业广泛分布。公司规模从北美,拉丁美洲,欧洲,中东和非洲以及亚太地区的...

    奋斗蒙
  • 为什么Kubernetes要引入pod的概念,而不直接操作Docker容器

    首先我们要明确一个概念,Kubernetes并不是只支持Docker这一个容器运行时,通过我的另一篇文章什么是Kubernetes的CRI-容器运行时接口介绍的...

    Jerry Wang

扫码关注云+社区

领取腾讯云代金券