如何结合业务场景构建开源容器?这四位过来人传授你实战经验

原创
开发
开源与容器技术分论坛着眼于开源容器的构建,结合实际场景,旨在帮助开发者了解国内外相关企业的容器应用案例,在选型、落地过程中的实践经验以及总结思考。

【51CTO.com原创稿件】2018年5月18-19日,由51CTO主办的全球软件与运维技术峰会在北京召开。来自全球企业的技术精英汇聚北京,畅谈软件技术前沿,共同探索运维技术的新边界。在本次大会上,除了众星云集的主论坛环节,12场分论坛更是各具特色,分别聚焦了时下最受关注的容器、AI、区块链、大数据、高并发、物联网等前沿技术领域。

WOT2018开源与容器技术分论坛现场

其中,开源与容器技术分论坛着眼于开源容器的构建,结合实际场景,旨在帮助开发者了解国内外相关企业的容器应用案例,在选型、落地过程中的实践经验以及总结思考。

知乎容器平台演进及与大数据融合实践

知乎计算平台负责人张阜兴结合知乎在生产环境集群中所遇到的问题,和大家交流容器使用方式和注意事项,以及在大数据处理和容器技术融合方面所做的尝试探索。张阜兴表示,知乎容器平台演进分为四个阶段:从 Mesos 到 Kubernetes,从单集群到混合云架构,从滚动部署到部署发布分离,以及从无状态到有状态。

[[232933]]

知乎计算平台负责人 张阜兴

由于容器平台是基础组件中的基础组件,因此每一个坑可能都是一个生产环境的重大故障。张阜兴为听众着重分享了在容器平台会遇到的几个坑:

·K8S events:在一个月黑风高的夜晚,K8S API Server无法访问开始报警,整个K8S 集群失去控制。后来查明原因,是 events 引起的锅。它是 K8S 集群变更事件记录,默认会写入到etcd中,etcd 的 TTL 是采用遍历实现,效率比较差,随着集群规模变大,终于导致 etcd 集群崩溃了。查明原因后,通过 K8S 的配置将 events 隔离到独立的 etcd 集群,同时这个 etcd 集群只用单节点去除 raft 的开销,在每天晚上清空这个节点,替代 TTL 机制。

·K8S Eviction:在 1.5 版本之前的 Kubernetes 里,Controller Manager 会将不能访问的 Node 上的 Pods 删除,如果 API server 全部挂掉超过一定时间再恢复后,Controller Manager 会删除所有 Pod 实例。在 1.5 版本后,可以通过配置 unhealthy-zone-threshold, 防止在 node 节点大规模异常时对集群Pods进行误驱逐。

·Docker 容器端口泄露:Docker Daemon 从分配使用端口到记录下这个端口的过程不是原子 的,如果 Docker Daemon 在中间阶段退出后,在重启恢复流程中忽略了这个已经分配的端口,就会导致容器端口泄露。

·TCP Connection Reset:在 Docker NAT 网络模式下会出现 TCP Connection Reset 的问题。主要是系统默认的配置对于网络数据包乱序过于严格,对于公网等比较差的网络环境,当乱序包超过 TCP 窗口后连接被 Reset 掉了。

张阜兴总结说,从实践的经验看,基本思路就是按业务方进行集群隔离,利用K8S进行多集群部署和管理,利用Docker进行资源隔离和监控,利用Docker实现更细粒度资源分配。在管理运维上,践行DevOps理念,让平台更加专注于工具开发本身,而不是限于琐碎的运维操作中不能自拔。

展望未来,知乎将尝试更多的组件利用K8S实现集群隔离,更细粒度的资源分配和进程级资源监控,从而在生产环境中更好的管理和维护,提升资源利用率,并在此之上,为业务提供更好的PaaS平台服务,最终实现数据中心资源统一交由 K8S 来分配调度的 DCOS。

容器技术在雪球的实践

雪球网***运维开发架构师董明鑫的演讲,主要介绍雪球在测试及生产环境的容器技术使用实践以及网络模式、负载均衡、日志收集、监控系统等相关组件的演进迭代。从雪球最初引入容器技术的原因开始说起,探讨各种方案的优劣,向大家展示了雪球如何一点一点变更基础设施,逐渐发展完善的过程,以及通过数据展示容器技术对于稳定性和生产效率的巨大提升。 

[[232934]]

雪球网***运维开发架构师 董明鑫

随着业务的发展,不同业务之间受到影响的概率比较高,雪球希望业务之间不被相互打扰,为了满足这种隔离的需求,雪球发现容器技术其实比较合适,因为容器本身镜像比较小,比较灵活,启动速度快,相比虚拟机,更适合雪球的业务发展,经过比较,雪球最终选择了Docker。

在运行过程中,雪球发现,使用Docker需要解决的问题主要有三个:网络连通性、多节点的服务部署更新、以及优秀的监控方案。雪球希望做一个平台,实现容器的物理机管理、容器的管理,以及IP和MAC地址和流程控制的管理。

经过一段时间的使用,雪球发现自研的容器管理平台虽然实现了流程控制与权限控制,并且将代码与环境固化,使多版本镜像管理更加方便,部署效率和扩缩容效率都有所提升,但是,流程控制逻辑与机器管理、网络管理之间耦合严重,而且,无法实现自动选择物理机和自动分配容器 IP,没有自愈功能。于是,雪球引入了Swarm,做了一个三层部署的模式。

后期,雪球又对此进行了优化,自助化的流程解放了运维的工作,引入了优化的调度方案,支持多机房多云环境。

***,雪球引入Kubernetes,每一个项目里可能有多个互联网数据中心(IDC),每一个IDC有不同的集群(Cluster),为每一个项目分配一个命名空间(Namespace),有自己的部署(Deployment)。由于Kubernetes本身的解决方案比较全面,而雪球也已经有了很多解决方案,例如日志、负载均衡、监控等。如何才能更低成本地引入Kubernetes,而且让开发尽量感知不到,***的办法是做合约的兼容性,最终,雪球只使用了Kubernetes的Deployment和HPA。

Kubernetes 网络更进一步

灵雀云K8S***专家刘梦馨的演讲围绕Kubernetes 网络模型、Kubernetes网络模型问题和网络改进三部分展开。他表示,Kubernetes网络模型在功能、性能和稳定性方面均存在一些问题,灵雀云通过固定IP、IP虚拟服务器(IP Virtual Server,简写为IPVS)和自研Ingress的方式加以改进。 

[[232935]]

灵雀云K8S***专家 刘梦馨

首先,在功能方面,Kubernetes 网络模型由于IP不固定,无法对IP资源进行精细管控,无法使用基于IP的监控和基于IP的安全策略,此外,一些IP发现的服务部署十分困难,给运维人员增加了很大的工作难度。

为了解决这一问题,灵雀云把IP当做重要资源,进行单独管理。灵雀云自研的CNI IPAM 插件,实现了IP导入和IP权限管理功能,可以进行网段的添加和删除,可在Kubernetes进行网段的精细化配置。

其次,在性能方面,由于Kubernetes最早是基于Iptables来做的,Iptables 没有增量更新功能,更新一条规则需要整体flush,更新时间长,这段时间之内流量会有不同程度的影响;Iptables规则串行,没有预料到Kubernetes在一个机器上会有很多规则的情况,流量需要经过所有规则的匹配,匹配之后再进行转发,否则对时间、CPN和内存都是极大的消耗,尤其在大规模情况下对性能的影响十分明显。

刘梦馨指出,Kubernetes升级到1.8或1.9版本以后,安装时可以选择IPVS模式,它是对Iptables的替换,在IPVS模式下添加规则是增量式的,不会强制进行全量更新,也不会进行串行的匹配,会通过一定的规则进行哈希map映射,很快地映射到对应的规则,不会出现大规模情况下性能线性下降的状况。

***,在稳定性方面,Kubernetes网络缺少健康检查功能,NodePort 屏蔽了Pod的直接访问,上层健康检查失效,网络分区、网络问题导致的转发异常时有发生。

灵雀云采用自研的OpenResty Ingress,方便新增功能,可以进行多端口监听。官方的Nginx Ingress只能监听80和43端口,但很多客户要对更多的端口进行监听,如根据端口区分的服务,灵雀云对此进行了一些改动,其自研的Ingress支持多端口功能。

分布式镜像仓库技术解析

资深容器技术开发者肖徳时的演讲主题是《分布式镜像仓库技术实战解析》,主要涉及OCI Distribution Specification解析、镜像分发的现状和痛点、业界对镜像分发技术实战解析和经验总结。肖徳时表示,容器镜像仓库一直以单机版本存在于社区,当前国内***的开源镜像仓库管理系统Harbor也只能在架构上提供简单的前端HA或者复制模式,无法实现Cloud Native下的真正分布式应用实现。

[[232936]]

资深容器技术开发者 肖徳时

肖徳时介绍说,OCI是开放容器联盟的缩写,是业界容器标准的行业联盟,目前主要发布了以下容器标准:runc是符合容器行业标准的创建和启动容器的命令行工具,runtime-spec是符合容器行业标准的容器运行时标准,image-spec是符合容器行业标准的容器镜像格式标准,distribution-spec是符合容器行业标准的容器分发标准。

distribution-spec目前还没正式发布1.0,基本围绕镜像仓库(Docker Registry HTTP API V2)的标准作为基础规范,定义范围包括:Namespace-oriented URI Layout、PUSH/PULL registry server for V2 image manifest format、Resumable layer PUSH support、V2 Client library implementation等。

对于目前镜像分发的现状和痛点,他表示,Docker Registry所缺少的特性非常多,会导致企业无法落地,无法满足企业的任何生产需求。

镜像分发的目的就是需要一个仓库,是能打包、存储、分发容器的仓库:

·Docker Hub是公有云实现,没有可以参考的技术架构;

·私有Docker DTR实现,偏向主备HA单机模式管理,无法适应分布式环境下的复杂镜像分发需求;

·Docker Registry 2.0的开源代码distribution,没有考虑企业特性,只能当作类库使用。

针对这些痛点,业界对镜像分发技术进行了很多实战性的探索:

腾讯的做法就是要进行快速分发,以更快的速度,向200个节点分发500M的镜像比Docker原生方式的分发时间降低了91%;部署FID,上层系统如Kubernetes,无需修改任何代码与逻辑,即可享受P2P加速。

目前,国内使用的比较多的是Harbor,例如Vmware所推出的 Harbor 基于Docker Distribution 的企业级 Registry 服务。Harbor是一个开源项目,提供了一个管理界面,可以实现分组,并可以加入一些企业特性。

***,肖徳时总结说,P2P技术可以提高分发镜像的效率,单层体积越大分发效率越高。镜像存储可以采用共享层模式降低存储的冗余度。高可用方案仍然需要大量生产实践,分发标准正在进化中。

以上内容是51CTO记者根据WOT2018全球软件与运维技术峰会的《开源与容器技术》分论坛演讲内容整理,更多关于WOT的内容请关注51cto.com。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

责任编辑:Barry 来源: 51CTO
相关推荐

2017-03-13 15:48:06

实践录京东金融金融科技

2018-11-30 16:48:17

2009-06-30 14:06:49

求职者面试官

2019-02-07 11:27:52

实践录京东金融金融科技

2018-09-19 11:06:03

述职项目技术

2010-10-26 10:21:11

求职

2015-11-10 09:40:55

IT实施计划IT

2021-11-29 10:43:14

业务转型员工CIO

2013-08-06 10:19:51

投资创业

2017-02-22 16:55:29

移动·开发技术周刊

2011-07-07 10:49:41

JavaScript

2020-06-23 08:11:40

PyTorch模型神经网络

2009-02-12 09:36:56

创业就业应届生

2019-12-03 10:46:07

PHP高并发架构

2018-11-13 11:38:38

CIO信息化建设

2010-07-06 16:22:14

2015-11-10 09:50:51

IT实施计划IT

2009-10-20 09:17:27

2020-09-11 13:20:34

高德大数据出游

2021-03-19 08:50:11

数据中台业务中台架构
点赞
收藏

51CTO技术栈公众号