标签：原来   service   负载平衡   冲突   控制台   问题   成熟   主页   核心部分   

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专线的方式提供混合云的打通。相信总有一款适合你。

浅谈如何打造一个安全稳定高效的容器云平台

标签：原来   service   负载平衡   冲突   控制台   问题   成熟   主页   核心部分   

原文地址：http://blog.51cto.com/14084875/2327288