基于Kubernetes的私有容器云建设实践

应用向容器云迁移是容器云建设过程中花费最多精力的地方,由于需要适应容器云背后的理念转变和对现有应用改造进行改造,迁移过程中受到了很多挑战,最大的挑战是Dubbo应用的迁移问题,由于Flannel的Overlay网络使容器化的Dubbo应用不能与Overlay网络之外的应用连通,最后我们修改了网络策略,使得Dubbo的应用可以无缝的迁移到容器云中.

下一阶段容器云工作的重点,是推动应用向Cloud Native和微服务化方向改造.

容器云面临的最大挑战来自于理念转变,容器技术改变了软件交付的生态,容器时代需要技术人员以新的理念构建应用,如何让技术人员顺利的完成理念的转变是每个容器云的建设者们需要认真考虑的问题.

Q&A

Q：请教一下处理CI时,比如集群自动化部署方面的粒度是怎样的?比如修复一个bug改了一个class文件,然后本地测试完之后需要到线上部署进AB测试,那么就直接通过CI自动部署到集群服务器吗?

A：我们的做法是只要有修改就触发重新构建,这只适合我们公司的情况,您可以根据自己的情况做出粒度选择.

Q：自动生成Dockerfile的目的是什么?这样做有什么优势?

A：这个问题有两个方面,第一个是标准化规范化的问题,我们的应用大多是Java Web,相似度很高,所以可以自动生成,没有什么特殊需要开发自己写的；另外,我们在CI平台里,留出了编辑Docker的口子,也可以针对特殊的情况自己编写,但是这种是非常少数的情况.CI跟每个企业的业务情况紧密相关,还是具体情况具体分析吧.

Q：我起了一些Pod,对外有Service,然后我想让Pod实现单任务,但问题是,Service对Pod选择机制是随机的,也就是说有可能会出现多个任务请求到一个Pod上,达不到我的要求,怎么解决?

A：这个问题我个人的理解,您要解决的问题跟一个Service对应多个Pod的场景不太吻合,我建议您考虑其他的方式实现,比如多个sevice-pod的组合等等,或者考虑其他的方式.

Q：「Kubernetes master 高可用」如何设计?多个数据中间是stand-by关系?

A：API Server是无状态的,可以部署多个,前端负载均衡,Scheduler/ControllerManager有状态可以做成主备.Kubernetes还算稳定(当然我们的量小).

Q：贵司使用的Kubernetes版本是?RBD锁死的问题只能通过手动解锁来解决吗?有其他方案吗?

A：我们上线比较早,生产系统还是1.2版本,我们正在升级1.6版本.RBD我只尝试了手动解锁的方法,别的方法没有尝试.

Q：想问下关于你们Kubernetes分布式存储的选择,以及在使用当中遇到了那些问题?

A：我们应用不挂盘,所以使用Ceph的场景不多.使用RBD没遇到什么问题,有些场景我们需要共享存储(Filesystem),因为我们人手有限,没精力尝试Ceph FS或者其他方式,这算个问题吧.

Q：在EFK的架构中有Kafka的存在,目的何在?是保证日志不丢失,还是提高吞吐量?

A：主要是做Buffering缓冲,我们这个里还有个别日志需要中间处理的过程,从Kafka取出加工,再放入Kafka,最后到Elasticsearch.

Q：能否详细介绍下CI系统考核的重要标准:对常用技术栈和配置进行标准化.具体对哪些指标做了标准化?技术方面如何实现的?

A：对于Java应用,我们只提供JDK 7和JDK 8,规定日志目录的位置,提供标准的Log4j,配置与代码分离,war包与环境不管等等强制的要求.

Q：Docker Registry的镜像复制是如何实现的?

A：根据模板生成了,比如对于Java Web,在规定好日志输出目录等情况系,可变的只是工程名称等很少部分,名称CI系统知道,所以就可以自动生成了.

Q：kube-proxy 那边性能怎么样? 还有一个问题就是一些特定的容器的固定IP是怎么做的?

A：我们量比较小,没有性能瓶颈,1.2(具体记不清了)以后kube-proxy是纯iptables实现,没那么差吧,业内也有用HAProxy等代替的,个人觉得没必要.特定的容器固定IP我们没有实现,我们没有这种场景.你可以折中一下,给个NodePort,固定IP我个人觉得尽量少用为好.

Q：镜像的自描述能否展开讲讲呢?

A：就是每个镜像里都有描述它构建过程的Dockerfile.

Q：对于你们现在使用的这套容器云平台,服务之间的依赖是怎么实现的?怎么区分的环境?另外应用健康检查和追踪用的是什么方案?

（编辑：宁德站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!