本文介绍了容器的现状和发展趋势, 容器集群编排引擎选型, 跨主机网络通信, 定制化方案, 公有云, 私有云及混合云的场景及实现等内容, 说明如何打造简单而强大的容器云平台.
1. 容器技术现状及发展趋势
什么是容器?
我们可以将容器理解为一种沙盒, 每个容器具有独立的操作系统资源, 不同的容器之间相互隔离, 也可以建立通信, 应用跑在各自的容器中, 避免了环境中有冲突的资源使用, 做到一次封装, 到处运行.
那容器与虚拟机的区别在哪?
容器可以看做轻量的虚拟机, 虚机启动可能需要数分钟或者更长, 而容器只需几十毫秒. 传统虚拟技术是在硬件层面实现虚拟化, 有性能损耗, 而容器技术是以共享内核的方式实现, 几乎无损耗. 虚拟机更擅长于彻底隔离整个运行环境. 例如, 云服务提供商通常采用虚拟机技术隔离不同的用户. 而 Docker 通常用于隔离不同的应用, 例如前端, 后端以及数据库.
以 Docker 为代表的容器技术的出现, 给云计算提供了全新的视角, 使创建和部署应用如堆积木一样简单, 我们在创建应用或服务时, 不用考虑资源和维护成本, 使得应用的部署极为简单快捷, 失败的成本大大降低, 让我们的注意力更多的聚焦在应用和服务本身, 而不是繁琐的系统和环境配置中.
几年来, 容器技术的发展也十分迅猛, 从管理单一容器应用到管理多容器, 多主机的分布式应用. 企业也纷纷面临着由传统应用向云端分布式应用的转变, 使用容器技术将应用转型为微服务.
随着容器采用率越来越快, 容器的生态环境也需要快速迭代. 需要有一个平台可以对容器集群进行高效灵活的管理, 方便的搞定容器编排和容器部署, 容器云平台应运而生. 容器云平台应具备哪些能力, 如何打造一个安全, 稳定, 高效的容器云平台, 我们从下面几方面来谈一谈.
2. 容器集群编排引擎选型
容器编排是容器云平台的核心部分和基础能力, 为实现大规模的容器化部署提供一个抽象层的处理. 典型的容器编排引擎需要实现以下几个功能: 集群(跨主机提供计算能力), 调度(决定容器部署在哪个节点), 可伸缩(支持应用实例的自动或手动扩容缩容), 容错(应用或主机故障的情况下自动重启容器), 隔离(保障容器安全).
Docker Native(swarm)
Docker 自带原生编排工具, 添加已经在多节点运行的 Docker 到 Swarm 中, Swarm 的设置是很简单的: 你只需在其中一个节点上调用 docker swarm init, 然后在任何其他你想添加的节点上调用 docker swarm join 即可. 使用与 Docker Engine 和 Docker Compose 相同的语法提供编排支持.
swarm 会自动地做一些如负载均衡, 保持容器副本数量等工作, 所以 swarm 对外提供的和 k8s 类似也是属于一个 "服务" 的概念.
- docker service create \
- -name helloworld \
- -replicas 5 \
- -network my-network \
- --constraint engine.labels.cloud==aliyun \
- --constraint node.role==manager \
-p 80:80/tcp nginx:latest.
Swarm 也可以使用约束和标签来做一些非常基本的容器调度. 使用约束可以向服务添加关联, 并且它将尝试仅启动具有特殊标签的容器.
Kubenetes
kubelet 将控制给定节点上的容器或 pod 与主控制节点的连接. kubeproxy 用于为 Kubernetes 中定义的服务提供负载平衡和高可用性.
Kubernetes 使用 Pods 的概念作为基本单位, 而不是单个容器. 每个 pod 是一组容器(集合大小可以是一个).
kubernetes 把集群带到了一个全新的高度, 代价是学习曲线比较陡. 它用一个不同的命令行接口, 不同的编程接口及不同的 YAML 文件定义等. 换言之, 你不能使用 docker 命令行接口也不能用 docker compose 来定义容器. 好在 kubernetes 提供了各种 API 供开发者调用, 也使得容器云平台和 kubernetes 的结合成为可能. 是否能发挥出 kubernetes 的强大功能也是容器云平台是否好用的判断标准之一.
Mesos+Marathon
Mesos 是一个开源集群管理系统, 支持各种工作负载.
marathon 为运行在 mesos 之上的框架 (Framework), 为运行 Docker 容器(以及本地 Mesos 容器) 提供支持. 它的双层调度机制可以使得集群规模大很多. 其它框架的调度器是直接面对整个集群, Mesos 的优势在于, 第一层调度先将整个 Node 分配给一个 Framework, 然后 Framework 的调度器面对的集群规模小很多, 然后在里面进行二次调度, 而且如果有多个 Framework, 例如有多个 Marathon, 则可以并行调度不冲突.
学习成本较高, 复杂性较高, 多层管理工具, 很多 marathon 的高级功能作为 Marathon 之上运行的附加框架提供(如 marathon-lb).
总结:
Docker Native 更新迭代快, 封装较少, 所以较为灵活, 对于简单的 web/stateless 应用来说是个不错的选择. 然而如果需要部署复杂的, 大规模的生产环境应用, 则可能不是那么适用. kubenetes 相较于 mesos, 提供更加丰富和成熟的功能体验. label 的定义使用使得 k8s 更加灵活
如果你是一名开发人员, 正需要一种科学的办法来加速你的应用程序开发过程或者微服务的构建, 那么我们建议你选择 Docker.
如果你是一个 dev/devops 团队, 想要搭建一个系统致力于 Docker 容器编排, 并愿意亲力亲为底层基础设施的集成解决方案(或依赖于公共云基础设施, 如谷歌引擎或 Azure 容器服务),Kubernetes 是你值得考虑的好技术.
如果您想构建一个可靠的平台, 可以运行多个关键任务, 包括 Docker 容器, 遗留程序 (例如: Java) 和分布式数据服务 (例如: Spark,Kafka,Cassandra,Elastic), 并想要可移植的云服务或数据中心, 那么 Mesos(或者我们自己的 Mesos 分布, Mesosphere DC/OS) 是适合你的.
3. SDN(跨主机网络通信)
在这里主要讨论的是多主机容器网络解决方案(SDN 网络).
多主机联网意味着将不同主机上的容器连接到同一个虚拟网络, 下面介绍三种方式实现:
docker 的 overlay 网络 使用 docker network create -d overlay my-overlay 创建命名为 my-overlay 的网络. Overlay 网络是 docker 原生实现跨主机通信的网络驱动类型, 同时还需要一个键值型的服务发现和配置共享软件. Overlay 实现跨主机容器互联的通信过程是这样的:
1.宿主机 A 上的容器 1 通过容器的 eth0 发送出去, 并通过路由表发往 br0,br0 相当于交换机, 如果目标容器在同一宿主机, 则直接通过 br0 通信, 如果不在则通过 vxlan;
2.br0 收到请求会交给 vxlan1, 并通过宿主机的 eth1 发送出去;
3.请求到达宿主机 B, 发现是 vxlan 报文则交给宿主机 B 上的 vxlan 设备;
4.Vxlan 设备处理后交给 br0,br0 根据 Mac 表完成请求投递.
overlay 虽然可以方便的实现跨主机访问需求, 但在传递过程中性能损耗较大, 不太适合在生产过程中使用, 经常用于开发测试或者小并发量的容器集群.
flannel 网络
flanel 需要先于 docker 启动, docker 启动前需要配置 flannel 的信息, 在 docker 启动时启用 flannel 网络. flannel 支持 flannel 和 Etcd 之间的 TLS 加密通道, 以及 Flannel 对等体之间数据路径的加密, 在数据性上更加安全. 但 flannel 在进行路由转发的基础上进行了封包解包的操作, 这样浪费了 CPU 的计算资源. flanne 没有提供网络隔离方案, 需要使用者定制化解决隔离问题.
calico 网络
Calico 整个过程中始终都是根据 iptables 规则进行路由转发, 并没有进行封包, 解包的过程, 这和 flannel 比起来效率就会快多了. 请求从源容器经过源宿主机, 经过数据中心的路由, 然后到达目的宿主机最后分配到目的容器. Calico 支持网络隔离, 可以方便的隔离租户数据, 隔离方案有 NetworkPolicy, 微分段等.
由于 Calico 是纯三层解决方案, 并不支持所有的第 3 层或第 4 层协议. 只有 TCP,UDP,ICMP 和 ICMPv6 得到 Calico 的支持, flannel 等其他解决方案由于是 udp 封装或者是 vxlan 方式, 可以支持通过 L3 封装 L2 数据包, 所以支持所有协议.
小结:
Calico 不支持任何种类的加密方法, 以及支持部分协议的通信, 但是 Calico 在这三个解决方案中达到了最佳的性能, 而且支持隔离策略, 因此更适合内部环境和多租户环境. 适合打造企业私有云或者混合云.
4. 定制化方案
根据客户需求提供定制化方案, 比如:
1)K8S 重构
API Server 减负: 分析 API 请求, 大量使用缓存技术
etcd: 监控, 演戏故障恢复; configmap
Controller 重构: Node Controller,Service Controller
2)容器 reuse 策略
容器优先自动拉起先前退出的容器, 而不是总是启动新的容器.
3)IP 保留池
设计 IP 保留池, 已应用为单位进行 IP 保留, 容器删除则 IP 回池, 该应用的容器创建使用池中的 IP.
4)容器 rebuild 等
容器修改镜像, 配置文件, 环境变量等, 则在当前容器所在节点新启动一个容器而不用重新调度, 并使用原来的数据卷.
容器云平台不是简单的堆砌开源解决方案, 而是有在理解的基础上进行对客户需求进行深入定制的能力.
5. 公有云, 私有云及混合云的场景及实现
公有云:
公有云实现规模化才能生存
公司对全盘云化没做好准备时, 更愿意把公有云视为需求量不可预测的工作负载或者全新应用开发的试验地. 公有云市场面临瓶颈.
私有云:
真正的私有云是做减法
私有云并不是把公有云的所有功能都照搬进来, 80%的企业私有云需要的是一个基本的云功能. 降低企业私有云使用门槛, 加快云计算进入数据中心
混合云:
企业的应用部署在安全性, 可控性, 定制化等方面有各种顾虑, 有的想把关键数据留在内部网络, 接入系统部署在公有云, 或者直接在内部网络部署应用, 通过公有云进行管理, 所以就有混合云的需求存在, 作为服务商我们开发者中心应该提供相应的方案实现混合云的架构需求. 大部分的 "混合云" 产品只有打通了控制层面, 更多是把焦点放在管控面, 除了管控面的统一调度, 实现数据层面的统一以及自由流动, 构建无缝的用户体验, 才是混合云的本质. 实现控制面和数据面彻底打通才是真正的混合云.
6. 打造简单而强大的容器云平台
我们从编排选型, 网络通信, 定制化能力和平台接入方面阐述了容器云平台的关键指标和适用场景, 打造一个安全, 稳定, 高效的容器云平台, 需要我们在 simplicity(使用简单)和 power(功能强大)之间找到一个平衡点. 我们可以将功能模块化, 在保证核心功能稳定高可用的基础上, 根据不同的使用场景和用户人群, 提供相应的技术选型和不同维度的服务, 做到简单而强大.
用友云开发者中心采用 Mesos+Kubenetes 双编排架构, 可以按照用户需求提供不同的服务, 容器间通信 (SDN 网络) 采用 calico 方案, 并使用 networkpolicy 实现网络隔离策略, 支持在控制台主页进行一键设置, 更安全可靠. 核心模块的存储采用 OSS 及 Fastdfs 分布式存储, 确保了多集群访问, 以及通过挂载卷的方式实现容器的文件共享, 并提供了容灾策略, 使用户的数据更安全.
对 marathon 框架及 k8s 进行了深度优化, 对升级和自动扩缩进行了优化, 实现了真正的不间断升级和热更新.
开发者中心既有公有云的展现, 又提供了定制化的专属云版本, 并可通过接入 *** 和建立 vpc 专线的方式提供混合云的打通. 相信总有一款适合你.
来源: http://www.bubuko.com/infodetail-2875250.html