关于into100沙龙：into100沙龙是TOP100Summit全球软件案例研究峰会的一个下属品牌，从2015年１月起，每月在北京、上海、深圳等地巡回举办的技术沙龙。活动旨在交流软件研发及互联网技术的实战经验，分享TOP100峰会那些优秀的案例实践，通过平台结识更多友人，挖掘并传播业界最具价值的技术实践。 作者简介
演讲主题：基于 Kubernetes 构建容器云平台 时间：2015年11月7日 地点：当当网5会议室 （1）Kubernetes的一些基本的概念和设计理念。 （3）我们在构建时速云容器云平台时的相关技术运用，以及在公有云上提供容器服务的经验分享。 正文 （1）Mesos是一个分布式，可伸缩的资源管理框架，它本身对上层框架怎么去进行任务指派是不负责的，只对上层框架提供resource offering，它也被称作分布式系统的内核。所以Mesos要管理Docker容器的话需要配合 Marathon 等上层框架来进行管理、调度。 开始之初即为容器设计，并可以支持Docker、rkt 等多种容器引擎，对容器的支持也更友好；来自Google内部Borg系统的理念，有10多年的大规模容器使用、管理经验；轻量级、插件式的架构设计，灵活、易扩展；活跃的开发社区，commit数量在github上排名第2，500多个代码贡献者。 在Kubernetes的设计中没有单机版本，只有集群模式。在这种master-slave 的集群设计中，所有状态信息存储在一个高可用、分布式的存储后端，目前用etcd实现；master 可以使用多节点方式实现高可用；在每个节点上主要由kubelet 来管理，包括和Docker 通信、监控容器等；为了解决有状态容器的问题，同样支持各种存储方式，作为容器数据的持久化支持。 river后面可以看到。 如图所示，我们在每个服务上定义一个label，在请求到某个服务时，会通过匹配 label 分配到后端对应的服务节点，并进行负载均衡。在Docker，现在也是用这种新的概念，就是Docker在服务发现和负载均衡方面，也采取了这上面的很多概念。 方面，也采取了这上面的很多概念。Kubernetes本身不提供任何底层网络相关的支持，它只对第三方网络解决方案提出具体的要求，只要满足这些要求的网络解决方案都可以作为Kubernetes的支撑网络。而且未来Kubernetes也不会网络有任何实现。 注意事项：内网会给每个Pod动态分配IP地址，地址可能会因Pod为的重建而变动，通过service环境变量或者dns方式的方式解决，随着集群规模的扩大，注意调整service-cluster-iip-range网段设置。 Kubernetes的监控现在还不成熟，官方推荐使用 heapster，influexdb 的组合作为解决方案。但是heapster有很多性能问题，需要自己做一些修改才能用于生产环境。 要求。提供对应用开发、运维的整个生命周期的管理。 如果代码没有托管在第三方平台的话，可以把编译好的war包或者二进制文件通过tce 客户端直接进行镜像构建；然后通过控制台可以设置成公有或者私有，同样也可以对镜像进行评论；接着可以把镜像直接部署到系统集群，或者自己的私有集群中；最后通过平台进行日志管理，各种资源的监控，对应用进行运维，而不需要关心底层的资源问题。 内部服务通信，使用内网域名别名。通过内网DNS的方式，避免Pod重启、迁移，ip地址发生变化后，关联服务无法连接的问题。通过内网域名也可以非常方便的进行服务编排。 首先用户需要在平台上创建自己的集群管理节点，这个是我们负责管理的。然后在需要添加的机器上运行一条命令，就可以把该机器加到自己的集群当中；如果用户需要批量添加云主机，只需要绑定用户凭证，就可以将IaaS云平台的主机批量加入集群。 我们也在深度使用自己的平台，包括开发和测试环境，我们都会跑在自己的公有云平台上；官方的博客、社区、文档、周报等等都是部署在平台上。同样开启了持续集成功能，比如改完代码提交，会触发自动构建镜像，然后Push我们的镜像仓库里，如果需要升级，只需要点击一个重启部署，服务就自动升级了；如果不想服务间断，我们也提供灰度升级的功能。 1、gcr.io 上的镜像各种被墙，碰到很多问题，也不是很明显，在各个论坛、社区里也看到很多人提这个问题。现在我们把这些镜像移到了我们自己的镜像服务器上，为开发者提供高速镜像下载服务，只需要从我们的镜像服务器下载，然后在本地改一下tag 就行。 2、kube-proxy性能问题，如果服务数量多了以后，延时就会非常高，所以目前我们替换掉了kube-proxy。 3、ETCD性能，在新版本上已经解决了，原来是不会利用多核的特性，老版本上我们是自己重新编译ETCD解决的。 4、在主机集群管理的时候，它有一个hyperkube的组件，其中缺少 cadvisor监控，需要自己重新编译才能解决。 5、拉取私有镜像，Kubernetes拉取私有镜像的时候，目前有两种方式：如果你有一个特权帐号，可以在节点上dockerlogin。第二种，也是Kubernetes官方推荐的，在每个namespace上创建secret 对象授权。 我觉得还是有希望把Docker打造成虚拟机的，在Google内部据说把虚拟机都是放到容器里跑的。但是现在想打造成虚拟机的话，一些技术还不太成熟，一个是容器的隔离性和安全性还都不完善；另外它的数据持久化还不成熟。
我们引导用户的时候，并不想把它介绍成虚拟机，而是利用它快速启动，标准化，做迁移比较容易等等来解释。但是现在很多容器平台，用户确实是拿它当虚拟机用的，有一次分享中一个朋友介绍，他以前是做IaaS的，考虑是不是改做容器方向，后来跟做容器的朋友聊完以后，说既然大家都在把容器当虚拟机用，那做IaaS挺好的，这个也是IaaS擅长的领域，容器公司是在帮IaaS做宣传了。 有很多用户，原来是用虚拟空间的，虽然便宜，但是经常宕机，而且一个用户的服务很可能影响其他人的，因为隔离性不够，这时容器平台稳定、高隔离的优势就显现出来了。而如果买IaaS 平台的一台机器，如果机器 down了，你的服务估计要过很久才能恢复，如果要做高可用，你需要买至少2台，还需要自己做负载均衡、容灾等相关配置管理。在容器云平台上，可以保证你的服务在节点down掉的情况下，很快在其他可用节点上恢复，保证服务的高可用，而且可以秒级轻松对服务进行扩展。 需要在各种用户需求和容器的特性之间进行取舍，不推荐直接修改容器内部，但是支持操作数据卷中的数据，可以直接上传、下载数据，为了方便调试，也提供Web Terminal进入容器内部，帮助用户慢慢的去理解、适应容器云平台。 如上图，帮用户创建 lnmp、lamp 等等基于镜像的开发环境，将运行时和代码分离，保证用户代码安全的情况下，做到开发环境的高可用，以及在开发团队之间的高一致性，并轻松实现一键升级。 我们也会利用Pod或者Stack级别的编排帮助用户。比如要在已有镜像上加一个服务，一般要重新构建镜像才能启动多个服务，而通过Pod编排，可以把紧耦合的服务部署到同一个节点，而且可以共享存储，端口空间等。Stack编排可以帮助用户跨节点部署多个服务，并且保证服务之间的关联。 Docker与十二因子 |
注册
登录
