在容器和服务发现相关的内容里, docker 和 kubernetes 排在前面. 在整个工具链里, docker,jenkins 和 kubernetes 比较受用户的关注.
容器是未来的一个趋势. 我在 2013 年的时候就开始接触容器, 后来发现 docker 开源之后非常合适我们, 所以我们就开始在内部尝试容器化.
我们坚信容器是下一个未来, 是将来的大主流, 所以容器上面的编排是非常重要的. 据数据显示, 用容器的公司在九个月之内都会把自己容器的规模 double 一下. 未来容器占有率的增长速度可能会比我们想象的还要快. 根据我们内部以及用户的数据来看, 用容器比用 VMS 的成本降低约 50%.
通过这么一组数据, 我想表达一个观点, 计算的下一个时代已经来临了.
京东云上的服务解析
京东做容器有很长一段时间了. 我们从 2003 年开始应用容器, 到 2006 年的时候, 京东内部已经大规模容器化.
传统的虚拟化技术就是在宿主机里套一层虚拟机管理软件, 让虚拟机去做所有的安全隔离修复. 而容器的优点就在于启动快体积小, 应用发布方便.
在虚拟化时代, 它的安全是强隔离的, 生态也比较完善. 经过十年的发展, 虚拟化的网络存储都相当成熟. 我们把虚拟化和容器结合了起来.
"蜂鸟" 特性一 -- 安全隔离
容器最大的问题还在于隔离性. 虽然我们相信自己开发出的应用比较安全, 可以在公司内部用传统的容器部署方案, 但在公用云上不行, 因为我们永远不知道各种各样的用户有什么目的, 公用云用户的应用是不可信的. 我们要在公用云上给我们的用户提供完整安全的服务.
"蜂鸟" 特性二 -- 快速启动
有时启动一个虚拟机会更慢, 可能因为是拉一个镜像就使它变慢了, 或者给自己的镜像做备份的时候里面装一些应用. 应用和镜像大了, 整体的启动就会慢一些. 我们启动 VM 工作进行了一些简化, 改写了 KVM, 让 KVM 适配 docker 标准的镜像. 既利用了虚拟化的安全, 生态和它的成熟度, 同时要保留容器启动速度, 体积和应用的优势.
"蜂鸟" 特性三 -- 生态兼容
我们也提出了很多标准化的东西. 我们的接口, 模块都是标准化的, 并兼容 docker 的 API 管理工具, 有很好的兼容性.
"蜂鸟" 特性四 -- 多样化配置
蜂鸟的容器云服务核心是多样化配置. 传统最小的云主机一般是 1 核 1G, 但在蜂鸟容器云服务里, 最小的配置可以做到 1 核 64 兆, 成本缩减了 1/12.
"蜂鸟" 容器服务的 K8s 应用解读
JCLOUD 容器和我们在京东云上创建的云主机可以放到同一个 VPC 里, 也就意味着我们支持 VM 和容器相互通信.
存储的插件也是我们自己做的. 京东云借鉴了 OpenStack 所有 API 的设计和架构. 存储这一块我们用的是自己的云硬盘. 在京东云里, 容器和主机是对等关系, 它们共用底下的网络和存储.
京东容器云服务和传统的一些业界做法不太一样. 我们把虚拟机和容器融为一体, 和网络深度结合.
我们保留了 Kubernetes 的原生组件, 换了 POD, 还有网络和存储.
京东的容器实践之路
京东有世界上最大的容器集群之一, 能保证京东 618, 双 11 的大促. 我们内部 99% 的应用已经做好了容器化. 刚接触容器的时候, 为了减少损耗和风险, 我们把 VM 换成容器. 但还没有利用到 docker 的精髓. 因为 Docker 不仅提供隔离的方案, 还有提供应用分发的解决. 直到 2.0 版本的时候, 才变成一个真正的容器 kubernetes 集群, 应用也可以 double 到镜像里.
在容器工具层内部, 我们开始用的是 docker. 如果直接用 docker 的话, 在公用云里面是没法直接提供服务的, 所以我们把这个容器工具改造 hypervisor, 这样就能给用户提供安全的隔离. 内部我们用的网络比较简单, 在外部我们组建了一个很强网络团队, 去开发 CDN 网络, 毕竟公用云环境跟内部的环境是完全不一样的. 在公用云里稍微有一些定制化. 内外部容器最大的不同主要是这些.
容器云有一个非常典型的应用, 就是数据采集, 我们也可以叫爬虫. 对于爬虫最大的问题还是 ip. 我们提供了丰富的 ip 池, 包含了一百个 C 的 ip. 每个用户来申请 ip 的时候, 都会给它分配均匀. 每个用户爬取采集的网站是不一样的. 所以我们对每个用户都有一个黑名单的 ip, 这样就能保证每个 ip 都是可用的.
对于微服务的概念大家可能已经耳熟能详了. 我们在京东云上面提供的电商云服务, 就是电商云标准的一个微服务框架. 我们先是把电商中心, 用户中心, 商品中心, 客服中心这些拆成一个微服务, 通过容器部署上去.
微服务是 docker 非常好的应用场景, 也是业界用得最大的应用场景.
很多企业里微服务还是用得最多的一个场景. 容器刚好解决了微服务的好多痛点. 容器够小, 微服务也小, 刚好可以匹配, 解决部署微服务对机器数量的要求. 每个容器都是独立的, 而且是和应用绑定, 容器刚好能解决微服务多语言的问题.
做微服务的时候不应该强制每个服务用同样的语言实现. 每个服务有自己不同的使命, 对于不同的服务, 应该采用不同的语言去解决, 反而能够提高效率.
容器的横向扩容和纵向扩容跟微服务息息相关.
不管是微服务还是容器服务, 最终目的还是要提高整个团队开发和部署效率.
其实用容器和用虚拟机省下来的钱可能只有一点点, 但是在这个人工上省的钱是非常多的. 所以微服务和容器主要的优势不是节省的机器成本, 而是节省管理和能源上的成本.
DevOps 的开发环境, 测试环境和市场环境统一化之后带来的好处就是, 如果有一个相对比较完整的开发环境, 不依赖于别人的进度, 对每个开发者而言, 效率能够提高升很多.
不管是容器也好, 微服务也好, 这种理念需要整个团队所有人都认可之后, 才能产生这个工具应该产生的效率和效用.
来源: https://juejin.im/post/5ae028acf265da0b9f3ff2f5