容器云技术平台与架构实践_由于使用容器技术,可以降低性能开销并在同一台服务器部署千个微服务,因为容器比虚

说起 “容器” ，大家的第一反应肯定是日常生活中使用的锅碗瓢盆，或者装运货物的箱子盒子，用来盛放各种各样的物品。那么拿港口码头来说，每天都要通过船舶向外运送大量的货物。装货的时候肯定不会直接扔进船舱，所以每个码头都会用大量的集装箱来运载货物。有了这些集装箱，货物不用杂乱无章地堆放在一起，又可以按照分类一层一层地摆放，更易于管理，同时也方便运输。

那么我们今天说的 “容器” 究竟是什么呢？它的灵感其实就来源于那些 “集装箱” 。在说 “容器” 之前，先来简单讲一下我们很耳熟的 —— “虚拟机（VM）”，并对比一下两者的区别。

虚拟机与容器

虚拟机（VM），大家肯定不会陌生了，作为一名计算机专业毕业的小编，在大学课程中也会使用虚拟机来学习 Linux 操作系统。顾名思义，虚拟机就是用来模拟计算机系统的软件，让使用者可以在一台计算机上运行看似多台计算机的设备。在一些需要不同类型的硬件或操作系统上运行软件的需求，虚拟机是一个好帮手，这样就无需使用其他的硬件了。

自从虚拟化技术和云计算服务出现以来，大大小小的 IT 公司都将虚拟机作为降低成本和提高效率的一种方式。但是，虚拟机会占用大量系统资源。每个虚拟机不仅要运行一个完整的操作系统，还需要运行操作系统要运行的所有虚拟硬件。这样就会消耗大量的内存和 CPU 资源。与运行单独的物理计算机相比，这样是比较经济的；但对于某些应用程序而言却是很浪费的。

这种情况下，就促进了容器的发展。

容器（Container）是一种更轻量级，更灵活的虚拟化处理方式，它将一个应用程序所需的一切打包在一起。容器包括所有代码，各种依赖甚至操作系统，这让应用程序几乎在任何地方都可以运行。因此它的诞生，解决了一个重要问题：如何确保应用程序从一个环境移动到另一个环境的正确运行。它只是虚拟了操作系统，而不像虚拟机一样去虚拟底层计算机。

△ 虚拟机（VM）与容器（Container）

那么对比虚拟机，容器有哪些特点呢？

• 可移植性

目前容器技术的现代形式主要体现在应用程序容器化（如 Docker）和系统容器化（如 LXC）中。这两种形式的容器都能让 IT 团队从底层架构中抽象出程序代码，从而实现跨各种部署环境的可移植性。

• 轻量级

容器通常位于物理服务器及其主机操作系统之上。它可以通过单个操作系统安装来运行多个工作环境。因此容器特别 “轻” —— 它们只有几兆字节，只需几秒钟即可启动。

• 降低成本

与虚拟机相比，内存，CPU 和存储效率的提高是容器技术的关键优势。由于可以在同一基础架构上支持更多容器，那么这些资源的减少就可以转化为巨大的成本节省，同时还可以减少管理开销。

虚拟机容器重量级轻量级表现有限原生表现每个 VM 都在自己的操作系统中运行所有容器共享主机操作系统硬件级虚拟化操作系统虚拟化启动时间（以分钟为单位）启动时间（以毫秒为单位）分配所需的内存需要更少的内存完全隔离进程级隔离

△ 虚拟机和容器的特点对比

我们为什么使用容器？

我们为什么使用虚拟机（云主机）？ 为什么使用物理机？ 这一系列的问题并没有一个统一的标准答案。因为以上几类技术栈都有自身最适用的场景，在最佳实践之下，它们分别都是不可替代的。 原本没有虚拟机，所有类型的业务应用都直接跑在物理主机上面，计算资源和存储资源都难于增减，要么就是一直不够用，要么就一直是把过剩的资源浪费掉，所以后来我们看到大家越来越多得使用虚拟机（或云主机），物理机的使用场景被极大地压缩到了像数据库系统这样的特殊类型应用上面。

原本也没有容器，我们把大部分的业务应用跑在虚拟机（或云主机）上面，把少部分特殊类型的应用仍然跑在物理主机上面。但现在所有的虚拟机技术方案，都无法回避两个主要的问题，一个问题是虚拟化Hypervisor管理软件本身的资源消耗与磁盘IO性能降低，另一个是虚拟机仍然还是一个独立的操作系统，对很多类型的业务应用来说都显得太重了，导致我们在处理虚拟机的扩缩容与配置管理工作时效率低下。所以，我们后来发现了容器的好处，所有业务应用可以直接运行在物理主机的操作系统之上，可以直接读写磁盘，应用之间通过计算、存储和网络资源的命名空间进行隔离，为每个应用形成一个逻辑上独立的“容器操作系统”。除此之外，容器技术还有以下优点：简化部署、多环境支持、快速启动、服务编排、易于迁移。

容器技术的一些缺点：仍然不能做到彻底的安全隔离，技术栈复杂度飚升，尤其是在应用了容器集群技术之后。所以如果只是小规模的使用，做实验或测试是可以的，上生产环境需要三思而后行。（看各家企业的具体情况而定）

容器技术与 DevOps

说到容器技术，就不得不提一下 DevOps。DevOps（Development 和 Operations 的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

2014 年 11 月，Docker 作为有潜在趋势的容器技术进入了 DevOps 的世界。它通过简单的包装和应用程序运输加快了持续部署的能力，进而得到了普及。Docker 作为一项开源工具，可以将应用程序及其依赖（如配置文件等）打包到容器中，就可以在任何 Linux 服务器上运行该容器，而不会出现任何兼容性问题。

容器化是一个相当古老的概念，但 Docker 带来了一些新的东西，早期的技术却没有。

• Docker 旨在整合大多数最近时期常用的 DevOps 工具，如 Puppet，Ansible，Jenkins等。
• 有了 Docker ，开发人员可以轻松地将其生产环境复制为可立即运行的容器应用程序，让工作更有效率。
• Docker 允许应用程序在笔记本电脑，内部服务器，公共云或私有云等上运行，从而实现灵活性和可移植性。管理和部署应用程序要容易得多。
• Docker 实现了一个高级 API ，以提供单独运行进程的轻量级容器。

如今，Docker 主要由开发人员和系统管理员用于与 DevOps 相关联地构建和运行分布式应用程序。

容器技术与微服务

微服务作为一个新兴的软件架构，和容器技术也有着密不可分的关系。微服务就是把一个大型的单个应用程序和服务拆分为数十个小型的服务。一个微服务的策略可以让工作变得更为简便，它最大的一个优点是可以比传统的应用程序更有效地利用计算资源。

大多数服务都有不同的资源要求。无论是网络，磁盘，CPU 还是内存，某个资源会比其他资源使用得更多。虽然云供应商可以提供针对内存，磁盘 IO 或 CPU 的不同设置，但系统仍然会留下大量的冗余资源。

△ 资源冗余

有了微服务，混合具有不同资源分配配置文件的服务可以提供最佳利用率。

△ 微服务提供最佳利用率

由于微服务类似于小型应用程序，因此我们必须将微服务部署到自己的虚拟机实例。可以想象，将整个虚拟机专门用于部署应用程序的一小部分并不是最有效的选择。但是，使用容器技术，可以降低性能开销并在同一台服务器部署上千个微服务，因为容器比虚拟机需要的计算资源要少得多。微服务进行容器化是很有必要的。它可以提高利用率和可用性，降低成本。

基于 Docker 的分布式计算资源网，节点分散在全国各地及海外，提供电信、联通、移动和多线网络，融合微服务、DevOps 理念，满足精益开发、运维一体化，大幅降低分布式计算资源构建复杂度，大幅降低使用成本。

容器、容器云与Kubernetes技术演进

容器与容器集群技术的演进

容器技术的演进路线

 

 

 

注：上图取自《容器技术及其应用白皮书[v1.0]》

容器集群技术的演进

上图描述了容器技术的演进，此后的近三年来的容器技术演进发展为主要是以容器集群技术为中心，如下所示。

 

 

器的运行原理与基本组件

Docker容器主要基于以下三个关键技术实现的：– Namespaces – Cgroups技术 – Image镜像

 

 

 

容器引擎容器引擎（Engine）或者容器运行时（Runtime）是容器系统的核心，也是很多人使用“容器”这个词语的指代对象。容器引擎能够创建和运行容器，而容器的定义一般是以文本方式保存的，比如 Dockerfile。

 

 

 

Docker Engine ：目前最流行的容器引擎，也是业界的事实标准。Rkt：CoreOS 团队推出的容器引擎，有着更加简单的架构，一直作为 Docker 的直接竞争对手存在，是 kubernetes 调度系统支持的容器引擎之一。containerd：这个新的Daemon是对Docker内部组件的一个重构以便支持OCI规范，containerd 主要职责是镜像管理（镜像、元信息等）、容器执行（调用最终运行时组件执行），向上为 Docker Daemon 提供了 gRPC 接口，向下通过 containerd-shim 结合 runC，使得引擎可以独立升级。docker-shim：shim 通过调用 containerd 启动 docker 容器，所以每启动一个容器都会起一个新的docker-shim进程。docker-shim是通过指定的三个参数：容器id，boundle目录和运行时（默认为runC）来调用runC的api创建一个容器。runC ：是 Docker 按照开放容器格式标准（OCF, Open Container Format）制定的一种具体实现，实现了容器启停、资源隔离等功能，所以是可以不用通过 docker 引擎直接使用runC运行一个容器的。也支持通过改变参数配置，选择使用其他的容器运行时实现。RunC可以说是各大CaaS厂商间合纵连横、相互妥协的结果，注：RunC在各个CaaS厂商的推动下在生产环境得到广泛的应用。Kubernetes目前基本只支持RunC容器，对于Docker超出其容器抽象层之外的功能，一概不支持。同样，Mesos也通过其Unified Containerizer只支持RunC容器，目前还支持Docker，但是未来的规划是只支持Unified Containerizer。CF也通过Garden只支持RunC，不支持Docker超出RunC之前的功能。

 

 

 

为什么在容器的启动或运行过程中需要一个 docker-containerd-shim 进程呢？其目的有如下几点： – 它允许容器运行时(即 runC)在启动容器之后退出，简单说就是不必为每个容器一直运行一个容器运行时(runC) – 即使在 containerd 和 dockerd 都挂掉的情况下，容器的标准 IO 和其它的文件描述符也都是可用的 – 向 containerd 报告容器的退出状态

rkt与containerd的区别是什么？一个主要的不同之处是，rkt作为一个无守护进程的工具（daemonless tool），可以用来在生产环境中，集成和执行那些特别的有关键用途的容器。举个例子，CoreOS Container Linux使用rkt来以一个容器镜像的方式执行Kubernetes的agent，即kublet。更多的例子包括在Kubernetes生态环境中，使用rkt来用一种容器化的方式挂载volume。这也意味着rkt能被集成进并和Linux的init系统一起使用，因为rkt自己并不是一个init系统。kubernets支持容器进行部署，其所支持的容器不只是仅仅局限于docker，CoreOS的rkt也是容器玩家之一，虽然跟docker比起来还是明显处于绝对下风，但有竞争总要好过没有。

容器编排和管理系统

容器是很轻量化的技术，相对于物理机和虚机而言，这意味着在等量资源的基础上能创建出更多的容器实例出来。一旦面对着分布在多台主机上且拥有数百套容器的大规模应用程序时，传统的或单机的容器管理解决方案就会变得力不从心。另一方面，由于为微服务提供了越来越完善的原生支持，在一个容器集群中的容器粒度越来越小、数量越来越多。在这种情况下，容器或微服务都需要接受管理并有序接入外部环境，从而实现调度、负载均衡以及分配等任务。 简单而高效地管理快速增涨的容器实例，自然成了一个容器编排系统的主要任务。

容器集群管理工具能在一组服务器上管理多容器组合成的应用，每个应用集群在容器编排工具看来是一个部署或管理实体，容器集群管理工具全方位为应用集群实现自动化，包括应用实例部署、应用更新、健康检查、弹性伸缩、自动容错等等。 容器编排和管理系统的分层结构图

 

 

 

容器编排和管理系统界的主要选手– Kubernetes：Google 开源的容器管理系统，起源于内部历史悠久的 Borg 系统。因为其丰富的功能被多家公司使用，其发展路线注重规范的标准化和厂商“中立”，支持底层不同的容器运行时和引擎（比如 Rkt），逐渐解除对 Docker 的依赖。Kubernetes的核心是如何解决自动部署，扩展和管理容器化（containerized）应用程序。目前该项目在github上Star数量为43k。 – Docker Swarm： 在 Docker 1.2 版本后将 Swarm 集成在了 Docker 引擎中。用户能够轻松快速搭建出来 docker 容器集群，几乎完全兼容 docker API 的特性。目前该项目在github上Star数量为5.3k。 – Mesosphere Marathon：Apache Mesos 的调度框架目标是成为数据中心的操作系统，完全接管数据中心的管理工作。Mesos理念是数据中心操作系统（DCOS），为了解决IaaS层的网络、计算和存储问题，所以Mesos的核心是解决物理资源层的问题。Marathon是为Mesosphere DC/OS和Apache Mesos设计的容器编排平台。目前该项目在github上Star数量为3.7k。

注：国内外有很多公司在从事基于上面三个基础技术平台的创新创业，为企业提供增值服务，其中做得不错的如Rancher，其产品可以同时兼容 kubernetes、mesos 和 swarm 集群系统，此外还有很多商用解决方案，如OpenShift。

中国市场的表现在中国市场，2017 年 6 月 Kubernetes 中国社区 K8SMeetup 曾组织了国内首个针对中国容器开发者和企业用户的调研。近 100 个受访用户和企业中给我们带来了关于 Kubernetes 在中国落地状况的一手调查资料显示： – 在容器编排工具中，Kubernetes占据了70%市场份额，此外是Mesos约11%，Swarm不足7%； – 在中国受访企业用户中，Kubernetes 平台上运行的应用类型非常广泛，几乎包括了除hadoop大数据技术栈以外的各种类型应用； – 中国受访企业运行 Kubernetes 的底层环境分布显示，29%的客户使用裸机直接运行容器集群，而在包括OpenStack、VMWare、阿里云和腾讯云在内的泛云平台上运行容器集群服务的客户占到了60%；

关于CNCF基金会

主要的容器技术厂商（包括 Docker、CoreOS、Google、Mesosphere、RedHat 等）成立了 Cloud Native Computing Foundation (CNCF) 。 CNCF对云原生的定义是：– 云原生技术帮助公司和机构在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。 – 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术可以使开发者轻松地对系统进行频繁并可预测的重大变更。 – 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式普惠，让这些创新为大众所用。

下图是截止2018.11的CNCF部分云原生项目列表：

 

 

 

云原生以容器为核心技术，分为运行时（Runtime）和 Orchestration 两层，Runtime 负责容器的计算、存储、网络；Orchestration 负责容器集群的调度、服务发现和资源管理。注：上图只截取了原图的核心组件部分，完整图表详见https://landscape.cncf.io/images/landscape.png

Kubernetes的核心组件

Kubernetes的核心组件示意图

 

 

 

etcd是Kubernetes的存储状态的分布式数据库，采用raft协议作为一致性算法（raft协议原理可参见一个动画演示http://thesecretlivesofdata.com/raft/）。API Server组件主要提供认证与授权、运行一组准入控制器以及管理API版本等功能，通过REST API向外提供服务，允许各类组件创建、读取、写入、更新和监视资源（Pod, Deployment, Service等）。Scheduler组件，根据集群资源和状态选择合适的节点用于创建Pod。Controller Manager组件，实现ReplicaSet的行为。Kubelet组件，负责监视绑定到其所在节点的一组Pod，并且能实时返回这些Pod的运行状态。创建Pod的整个流程时序图

 

 

 

容器网络

容器的大规模使用，也对网络提供了更高的要求。网络的不灵活也是很多企业的短板，目前也有很多公司和项目在尝试解决这些问题，希望提出容器时代的网络方案。 Docker采用插件化的网络模式，默认提供bridge、host、none、overlay、macvlan和Network plugins这几种网络模式，运行容器时可以通过–network参数设置具体使用那一种模式。

– bridge：这是Docker默认的网络驱动，此模式会为每一个容器分配Network Namespace和设置IP等，并将容器连接到一个虚拟网桥上。如果未指定网络驱动，这默认使用此驱动。 – host：此网络驱动直接使用宿主机的网络。

– none：此驱动不构造网络环境。采用了none 网络驱动，那么就只能使用loopback网络设备，容器只能使用127.0.0.1的本机网络。

– overlay：此网络驱动可以使多个Docker daemons连接在一起，并能够使用swarm服务之间进行通讯。也可以使用overlay网络进行swarm服务和容器之间、容器之间进行通讯，

– macvlan：此网络允许为容器指定一个MAC地址，允许容器作为网络中的物理设备，这样Docker daemon就可以通过MAC地址进行访问的路由。对于希望直接连接网络网络的遗留应用，这种网络驱动有时可能是最好的选择。

– Network plugins：可以安装和使用第三方的网络插件。可以在Docker Store或第三方供应商处获取这些插件。

在默认情况，Docker使用bridge网络模式。

容器网络模型（CNM）

CNM在2015年由Docker引入，CNM有IP 地址管理（IPAM）和网络插件功能。IPAM插件可以创建IP地址池并分配，删除和释放容器IP。网络插件API用于创建/删除网络，并从网络中添加/删除容器。

容器网络接口（CNI）

CNI诞生于2015年4月，由CoreOS公司推出，CNI是容器中的网络系统插件，它使得类似Kubernetes之类的管理平台更容易的支持IPAM、SDN或者其它网络方案。CNI实现的基本思想为：Contianer runtime在创建容器时，先创建好network namespace，这在实际操作过程中，首先创建出来的容器是Pause容器。之后调用CNI插件为这个netns配置网络，最后在启动容器内的进程。

CNI Plugin负责为容器配置网络，包括两个基本接口： – 配置网络：AddNetwork(net NetworkConfig, rt RuntimeConf) (types.Result, error) – 清理网络：DelNetwork(net NetworkConfig, rt RuntimeConf) error

每个CNI插件只需实现两种基本操作：创建网络的ADD操作，和删除网络的DEL操作（以及一个可选的VERSION查看版本操作）。所以CNI的实现确实非常简单，把复杂的逻辑交给具体的Network Plugin实现。

Kubernetes CNI 插件

 

 

 

Flannel：CoreOS 开源的网络方案，为 kubernetes 设计，它的功能是让集群中的不同节点主机创建的Docker容器都具有全集群唯一的虚拟IP地址。Flannel的底层通信协议的可选余地有很多，比如UDP、VXlan、AWS VPC等等，不同协议实现下的网络通信效率相差较多，默认为使用UDP协议，部署和管理简单。目前为止，还不支持k8s的Network Policy。Calico：一个纯三层的网络解决方案，使用 BGP 协议进行路由，可以集成到 openstack 和 docker。Calico节点组网可以直接利用数据中心的网络结构（无论是L2或者L3），不需要额外的NAT，隧道或者Overlay Network，网络通信性能好。Calico基于iptables还提供了丰富而灵活的网络Policy，保证通过各个节点上的ACLs来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。如果企业生产环境可以开启BGP协议，可以考虑calico bgp方案。不过在现实中的网络并不总是支持BGP路由的，因此Calico也设计了一种IPIP模式，使用Overlay的方式来传输数据。Weave Net：weaveworks 给出的网络的方案，使用 vxlan 技术通过Overlay网络实现的， 支持网络的隔离和安全，安装和使用都比较简单。Contiv: 思科开源，兼容CNI模型以及CNM模型，支持 VXLAN 和 VLAN 方案，配置较复杂。支持Tenant，支持租户隔离，支持多种网络模式（L2、L3、overlay、cisco sdn solution）。Contiv带来的方便是用户可以根据容器实例IP直接进行访问。Canal：基于 Flannel 和 Calico 提供 Kubernetes Pod 之间网络防火墙的项目。Cilium：利用 Linux 原生技术提供的网络方案，支持 L7 和 L3、L4 层的访问策略。Romana：Panic Networks 推出的网络开源方案，基于 L3 实现的网络连通，因此没有 Overlay 网络带来的性能损耗，但是只能通过 IP 网段规划来实现租户划分。从理论上说，这些CNI工具的网络速度应该可以分为3个速度等级。 最快的是Romana、Gateway模式的Flannel、BGP模式的Calico。 次一级的是IPIP模式的Calico、Swarm的Overlay网络、VxLan模式的Flannel、Fastpath模式的Weave。 * 最慢的是UDP模式的Flannel、Sleeve模式的Weave。

Flannel

UDP封包使用了Flannel自定义的一种包头协议，数据是在Linux的用户态进行封包和解包的，因此当数据进入主机后，需要经历两次内核态到用户态的转换。网络通信效率低且存在不可靠的因素。VxLAN封包采用的是内置在Linux内核里的标准协议，因此虽然它的封包结构比UDP模式复杂，但由于所有数据装、解包过程均在内核中完成，实际的传输速度要比UDP模式快许多。Vxlan方案在做大规模应用时复杂度会提升，故障定位分析复杂。Flannel的Gateway模式与Calico速度相当，甚至理论上还要快一点。Flannel的Host-Gateway模式，在这种模式下，Flannel通过在各个节点上的Agent进程，将容器网络的路由信息刷到主机的路由表上，这样一来所有的主机就都有整个容器网络的路由数据了。Host-Gateway的方式没有引入像Overlay中的额外装包解包操作，完全是普通的网络路由机制，它的效率与虚拟机直接的通信相差无几。Host-Gateway的模式就只能用于二层直接可达的网络，由于广播风暴的问题，这种网络通常是比较小规模的。路由网络对现有网络设备影响比较大，路由器的路由表有空间限制，一般是两三万条，而容器的大部分应用场景是运行微服务，数量集很大。Flannel网络通信原理示意图

 

 

 

各CNI网络插件的功能对比：

 

 

 

容器存储

因为容器存活时间很短的特点，容器的状态（存储的数据）必须独立于容器的生命周期，也因为此，容器的存储变得非常重要。 – Ceph：分布式存储系统，同时支持块存储、文件存储和对象存储，发展时间很久，稳定性也得到了验证。之前在 OpenStack 社区被广泛使用，目前在容器社区也是很好的选项。 – GlusterFS：RedHat 旗下的产品，部署简单，扩展性强。 – 商业存储：DELL EMC，NetApp等 – CSI（Container Storage Interface）：定义云应用调度平台和各种存储服务接口的项目，核心的目标就是存储 provider 只需要编写一个 driver，就能集成到任何的容器平台上。 – Rook：基于 Ceph 作为后台存储技术，深度集成到 Kubernetes 容器平台的容器项目，因为选择了 Ceph 和 Kubernetes 这两个都很热门的技术，并且提供自动部署、管理、扩展、升级、迁移、灾备和监控等功能

Kubernetes支持的存储类型

awsElasticBlockStoreazureDiskazureFilecephfsconfigMapcsidownwardAPIemptyDirfc (fibre channel)flockergcePersistentDiskgitRepo (deprecated)glusterfshostPathiscsilocalnfspersistentVolumeClaimprojectedportworxVolumequobyterbdscaleIOsecretstorageosvsphereVolumeKubernetes以in-tree plugin的形式来对接不同的存储系统，满足用户可以根据自己业务的需要使用这些插件给容器提供存储服务。同时兼容用户使用FlexVolume和CSI定制化插件。

 

 

一般来说，Kubernetes中Pod通过如下三种方式来访问存储资源： – 直接访问 – 静态provision – 动态provision（使用StorageClass动态创建PV）

服务发现

容器和微服务的结合创造了另外的热潮，也让服务发现成功了热门名词。可以轻松扩展微服务的同时，也要有工具来实现服务之间相互发现的需求。 DNS 服务器监视着创建新 Service 的 Kubernetes API，从而为每一个 Service 创建一组 DNS 记录。 如果整个集群的 DNS 一直被启用，那么所有的 Pod应该能够自动对 Service 进行名称解析。在技术实现上是通过kubernetes api监视Service资源的变化，并根据Service的信息生成DNS记录写入到etcd中。dns为集群中的Pod提供DNS查询服务，而DNS记录则从etcd中读取。 – kube-dns：kube-dns是Kubernetes中的一个内置插件，目前作为一个独立的开源项目维护。Kubernetes DNS pod 中包括 3 个容器：kube-dns，sidecar，dnsmasq – CoreDNS：CoreDNS是一套灵活且可扩展的权威DNS服务器，作为CNCF中的托管的一个项目，自k8s 1.11 版本起被正式作为集群DNS附加选项，且在用户使用kubeadm时默认生效。提供更好的可靠性、灵活性和安全性，可以选择使用CoreDNS替换Kubernetes插件kube-dns。

状态数据存储

目前主要有三种工具，大部分的容器管理系统也都是同时可以支持这三种工具。 – etcd：CoreOS 开源的分布式 key-value 存储，通过 HTTP/HTTPS 协议提供服务。etcd 只是一个 key-value 存储，默认不支持服务发现，需要三方工具来集成。kubernetes 默认使用 etcd 作为存储。 – ZooKeeper：Hadoop 的一个子项目，本来是作为 Hadoop 集群管理的数据存储，目前也被应用到容器领域，开发语言是 Java。 – Consul：HashiCorp 开发的分布式服务发现和配置管理工具

这些工具的主要作用就是保证这个集群的动态信息能统一保存，并保证一致性，这样每个节点和容器就能正确地获取到集群当前的信息。

健康检查

Kubernetes提供两种类型的健康检查，支持进行三种类型的探测：HTTP、Command和TCP。 – Readiness探针旨在让Kubernetes知道您的应用何时准备好其流量服务。 Kubernetes确保Readiness探针检测通过，然后允许服务将流量发送到Pod。 如果Readiness探针开始失败，Kubernetes将停止向该容器发送流量，直到它通过。 – Liveness探针让Kubernetes知道你的应用程序是活着还是死了。 如果你的应用程序还活着，那么Kubernetes就不管它了。 如果你的应用程序已经死了，Kubernetes将删除Pod并启动一个新的替换它。

容器监控

我们习惯于在两个层次监控：应用以及运行它们的主机。现在由于容器处在中间层，以及 Kubernetes 本身也需要监控，因此有 4 个不同的组件需要监控并且搜集度量信息。

1）cAdvisor + InfluxDB + Grafana：一个简单的跨多主机的监控系统Cadvisor：将数据，写入InfluxDBInfluxDB ：时序数据库，提供数据的存储，存储在指定的目录下Grafana ：提供了WEB控制台，自定义查询指标，从InfluxDB查询数据，并展示。

2）Heapster + InfluxDB + Grafana：Heapster是一个收集者，将每个Node上的cAdvisor的数据进行汇总，然后导到InfluxDB，支持从Cluster、Node、Pod的各个层面提供详细的资源使用情况。Heapster：在Kubernetes集群中获取Metrics和事件数据，写入InfluxDB，Heapster收集的数据比cAdvisor多，而且存储在InfluxDB的也少。InfluxDB：时序数据库，提供数据的存储，存储在指定的目录下。Grafana：提供了WEB控制台，自定义查询指标，从InfluxDB查询数据，并展示。

3）Prometheus+Grafana：Prometheus是个集DB、Graph、Statistics、Alert 于一体的监控工具。提供多维数据模型（时序列数据由metric名和一组key/value组成）和在多维度上灵活的查询语言(PromQl)，提供了很高的写入和查询性能。对内存占用量大，不依赖分布式存储，单主节点工作，所以不具有高可用性，支持pull/push两种时序数据采集方式。

考虑到Prometheus在扩展性和高可用方面的缺点，在超大规模应用时可以考察下thanos这样的面向解决Prometheus的长时间数据存储与服务高可用解决方案的开源项目：https://github.com/improbable-eng/thanos

容器集群的四个监控层次

 

 

 

镜像 registry

镜像 registry 是存储镜像的地方，可以方便地在团队、公司或者世界各地分享容器镜像，也是运行容器最基本的基础设施。 – Docker Registry：Docker 公司提供的开源镜像服务器，也是目前最流行的自建 registry 的方案 – Harbor：企业级的镜像 registry，提供了权限控制和图形界面

每种对应技术几乎都有自己的基础镜像，例如： – https://hub.docker.com/_/java/ （该镜像仍存在，但已经很长时间未更新） – https://hub.docker.com/_/python/ – https://hub.docker.com/_/nginx/ – https://hub.docker.com/_/alpine/ 一个常用的基础镜像Alpine Linux（体积小于5MB）

基于docker技术的容器云（PaaS）平台基本理解

目前很多的容器云平台通过Docker及Kubernetes等技术提供应用运行平台，从而实现运维自动化，快速部署应用、弹性伸缩和动态调整应用环境资源，提高研发运营效率。

从宏观到微观（从抽象到具体）的思路来理解：云计算→PaaS→ App Engine→XAE[XXX App Engine] （XAE泛指一类应用运行平台，例如GAE、SAE、BAE等）。

本文简要介绍了与容器云相关的几个重要概念：PaaS、App Engine、Docker、Kubernetes。

1. PaaS概述

1.1. PaaS概念

1. PaaS(Platform as a service)，平台即服务，指将软件研发的平台（或业务基础平台）作为一种服务，以SaaS的模式提交给用户。
2. PaaS是云计算服务的其中一种模式，云计算是一种按使用量付费的模式的服务，类似一种租赁服务，服务可以是基础设施计算资源（IaaS），平台（PaaS），软件（SaaS）。租用IT资源的方式来实现业务需要，如同水力、电力资源一样，计算、存储、网络将成为企业IT运行的一种被使用的资源，无需自己建设，可按需获得。
3. PaaS的实质是将互联网的资源服务化为可编程接口，为第三方开发者提供有商业价值的资源和服务平台。简而言之，IaaS就是卖硬件及计算资源，PaaS就是卖开发、运行环境，SaaS就是卖软件。

1.2. IaaS/PaaS/SaaS说明

 

 

1.3. PaaS的特点（三种层次）

2. App Engine概述

2.1. App Engine概念

App Engine是PaaS模式的一种实现方式，App Engine将应用运行所需的 IT 资源和基础设施以服务的方式提供给用户，包括了中间件服务、资源管理服务、弹性调度服务、消息服务等多种服务形式。App Engine的目标是对应用提供完整生命周期（包括设计、开发、测试和部署等阶段）的支持，从而减少了用户在购置和管理应用生命周期内所必须的软硬件以及部署应用和IT 基础设施的成本，同时简化了以上工作的复杂度。常见的App Engine有：GAE(Google App Engine)，SAE(Sina App Engine)，BAE(Baidu App Engine)。

App Engine利用虚拟化与自动化技术实现快速搭建部署应用运行环境和动态调整应用运行时环境资源这两个目标。一方面实现即时部署以及快速回收，降低了环境搭建时间，避免了手工配置错误，快速重复搭建环境，及时回收资源， 减少了低利用率硬件资源的空置。另一方面，根据应用运行时的需求对应用环境进行动态调整，实现了应用平台的弹性扩展和自优化，减少了非高峰时硬件资源的空置。

简而言之，App Engine主要目标是：Easy to maintain(维护), Easy to scale(扩容), Easy to build(构建)。

2.2. 架构设计

 

2.3. 组成模块说明

3. 容器云平台技术栈

• Namespace[资源隔离]
  Namespaces机制提供一种资源隔离方案。PID,IPC,Network等系统资源不再是全局性的，而是属于某个特定的Namespace。每个namespace下的资源对于其他namespace下的资源都是透明，不可见的。

• CGroups[资源控制]
  CGroup（control group）是将任意进程进行分组化管理的Linux内核功能。CGroup本身是提供将进程进行分组化管理的功能和接口的基础结构，I/O或内存的分配控制等具体的资源管理功能是通过这个功能来实现的。CGroups可以限制、记录、隔离进程组所使用的物理资源（包括：CPU、memory、IO等），为容器实现虚拟化提供了基本保证。CGroups本质是内核附加在程序上的一系列钩子（hooks），通过程序运行时对资源的调度触发相应的钩子以达到资源追踪和限制的目的。

4. Docker概述

更多详情请参考：Docker整体架构图

4.1. Docker介绍

1. Docker - Build, Ship, and Run Any App, Anywhere
2. Docker是一种Linux容器工具集，它是为“构建（Build）、交付（Ship）和运行（Run）”分布式应用而设计的。
3. Docker相当于把应用以及应用所依赖的环境完完整整地打成了一个包，这个包拿到哪里都能原生运行。因此可以在开发、测试、运维中保证环境的一致性。
4. Docker的本质：Docker=LXC(Namespace+CGroups)+Docker Images，即在Linux内核的Namespace[资源隔离]和CGroups[资源控制]技术的基础上通过镜像管理机制来实现轻量化设计。

4.2. Docker的基本概念

4.2.1. 镜像

Docker 镜像就是一个只读的模板，可以把镜像理解成一个模子（模具），由模子（镜像）制作的成品（容器）都是一样的（除非在生成时加额外参数），修改成品（容器）本身并不会对模子（镜像）产生影响（除非将成品提交成一个模子），容器重建时，即由模子（镜像）重新制作成一个成品（容器），与其他由该模子制作成的成品并无区别。

例如：一个镜像可以包含一个完整的 ubuntu 操作系统环境，里面仅安装了 Apache 或用户需要的其它应用程序。镜像可以用来创建 Docker 容器。Docker 提供了一个很简单的机制来创建镜像或者更新现有的镜像，用户可以直接从其他人那里下载一个已经做好的镜像来直接使用。

4.2.2. 容器

Docker 利用容器来运行应用。容器是从镜像创建的运行实例。它可以被启动、开始、停止、删除。每个容器都是相互隔离的、保证安全的平台。可以把容器看做是一个简易版的 Linux 环境（包括root用户权限、进程空间、用户空间和网络空间等）和运行在其中的应用程序。

4.2.3. 仓库

仓库是集中存放镜像文件的场所。有时候会把仓库和仓库注册服务器（Registry）混为一谈，并不严格区分。实际上，仓库注册服务器上往往存放着多个仓库，每个仓库中又包含了多个镜像，每个镜像有不同的标签（tag）。

4.3. Docker的优势

 

1. 容器的快速轻量

   容器的启动，停止和销毁都是以秒或毫秒为单位的，并且相比传统的虚拟化技术，使用容器在CPU、内存，网络IO等资源上的性能损耗都有同样水平甚至更优的表现。

2. 一次构建，到处运行

   当将容器固化成镜像后，就可以非常快速地加载到任何环境中部署运行。而构建出来的镜像打包了应用运行所需的程序、依赖和运行环境， 这是一个完整可用的应用集装箱，在任何环境下都能保证环境一致性。

3. 完整的生态链

   容器技术并不是Docker首创，但是以往的容器实现只关注于如何运行，而Docker站在巨人的肩膀上进行整合和创新，特别是Docker镜像的设计，完美地解决了容器从构建、交付到运行，提供了完整的生态链支持。

5. Kubernetes概述

更多详情请参考：Kubernetes总架构图

5.1. Kubernetes介绍

Kubernetes是Google开源的容器集群管理系统。它构建Docker技术之上，为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能，本质上可看作是基于容器技术的Micro-PaaS平台，即第三代PaaS的代表性项目。

5.2. Kubernetes的基本概念

5.2.1. Pod

Pod是若干个相关容器的组合，是一个逻辑概念，Pod包含的容器运行在同一个宿主机上，这些容器使用相同的网络命名空间、IP地址和端口，相互之间能通过localhost来发现和通信，共享一块存储卷空间。在Kubernetes中创建、调度和管理的最小单位是Pod。一个Pod一般只放一个业务容器和一个用于统一网络管理的网络容器。

5.2.2. Replication Controller

Replication Controller是用来控制管理Pod副本(Replica，或者称实例)，Replication Controller确保任何时候Kubernetes集群中有指定数量的Pod副本在运行，如果少于指定数量的Pod副本，Replication Controller会启动新的Pod副本，反之会杀死多余的以保证数量不变。另外Replication Controller是弹性伸缩、滚动升级的实现核心。

5.2.3. Service

Service是真实应用服务的抽象，定义了Pod的逻辑集合和访问这个Pod集合的策略，Service将代理Pod对外表现为一个单一访问接口，外部不需要了解后端Pod如何运行，这给扩展或维护带来很大的好处，提供了一套简化的服务代理和发现机制。

5.2.4. Label

Label是用于区分Pod、Service、Replication Controller的Key/Value键值对，实际上Kubernetes中的任意API对象都可以通过Label进行标识。每个API对象可以有多个Label，但是每个Label的Key只能对应一个Value。Label是Service和Replication Controller运行的基础，它们都通过Label来关联Pod，相比于强绑定模型，这是一种非常好的松耦合关系。

5.2.5. Node

Kubernets属于主从的分布式集群架构，Kubernets Node（简称为Node，早期版本叫做Minion）运行并管理容器。Node作为Kubernetes的操作单元，将用来分配给Pod（或者说容器）进行绑定，Pod最终运行在Node上，Node可以认为是Pod的宿主机。

5.3. Kubernetes架构

 

容器云平台在传统企业落地的一些思考和探索

过去的两三年，容器相关的东西非常火热。和所有新生事物一样，一开始也是杂乱无章。

开源项目上，从 Docker，Swarm，Mesos，到 Kubernetes，再到 OpenShift，各种以容器为基础的技术和产品层出不穷。

技术使用选型上，大家对于怎么用容器也是各有千秋。以阿里为例，他们主推的是富容器Pounch Container，而大家普遍采用的是 Docker 容器，还有 OpenStack 社区力推的 Kata。关于阿里的 Pounch Container，我个人很是疑问，他们是想成为主流呢，还是会被主流淹没呢？会不会重走一遍用KVM 替代 Xen 的路子呢？

而对传统企业来说，虽然越来越多的企业对它在感兴趣，但是容器云落地更是问题多多，我这里列出的只是我接触过的一些比较典型的问题。

我认为人们在为新事物做选择题的时候，往往会用老的思维模式。以容器云平台为例，就比较自然地把它归类到已经熟悉了的虚拟化和IaaS这一类的资源型平台。这种做法就会产生很多问题。我认为这是一种错位。

要解决这些问题，我认为需要将容器云平台提升到 PaaS 层面。这里面有两点需要提一下：

一是企业CIO在这里面的关键作用。当然了，在有些企业是别的类似的角色。只有这个角色，才能统一地将企业的开发和运维统一纳入考虑范围。

二是咨询方案供应商。现在，随着新的技术的层出不穷，有些企业已经有了一些无所适从，既想用，又不知道怎么用。这时候，咨询公司就有了用武之地。

对企业用户来说，他们更看重的是 PaaS 部分的功能，因为这些功能能直接对软件开发和公司业务产生价值；对基于 Kubernetes 或 OpenShift 做产品化的公司来说，他们也应该更加聚焦 PaaS 部分。而 CaaS 部分，我认为，应该由相应的社区来主导。

找到了问题症结和解决方法，那回答问题就相对容易了。

我之前看过一份麦肯锡关于企业数字化转型的一个报告。报告里面提到，科技公司的两个关键所在，就是流程标准化和工具赋能。那结合 PaaS 平台能给用户带来的优势，其实正好，PaaS 平台给企业所带来的，正好就是流程标准化，包括开发流程、软件架构、应用管理等，以及充分利用各种工具和平台所带来的工具赋能。

普遍认为，传统企业数字化转型需要经历三个阶段，分别是 云IT，云 DT，和云 DI 三个阶段。 这和将云分为 IaaS、PaaS 和 SaaS 三个层面有些巧合。
而在云IT阶段，可以大概地认为是IaaS 阶段，它的任务是向企业提供弹性云资源。 
云DT阶段，是 PaaS 在企业中起关键作用的阶段。PaaS 能带来IT基础设施、应用架构、开发流程、组织结构的互联网化。 
云DI阶段，是SaaS服务发挥关键作用的阶段。AI 作为这一阶段的主要驱动力之一，将以SaaS的形式，被嵌入到各种业务系统之中，来驱动业务创新。

现在和过去的混合云，我想把他们称为混合云1.0，因为主要是网络和存储打通，但是在应用层面没有打通。没打通是有原因的，那是因为没法打通，有很多原因，其中一条是因为格式不同。现在有了容器云PaaS 之后，以容器为应用的统一载体，那打通就相对容易了。

另外，随着混合云和多云概念的火热，云管理平台（CMP）的热度似乎一下子上来了。我认为，在当前存在多种不同IT环境的时期，CMP 的价值是明显的。但是，随着容器云部署在各种IT环境之上，它自己就会承担起部分CMP的功能，到那个时候，CMP 主要就会是PaaS平台的CMP了。

阶段1：孤岛式 IT 环境。问题是资源浪费；不能满足有快速需求的业务。

阶段2：能解决阶段1 的问题，但产生了新的问题，那就是无法满足互联网业务要求。当传统行业不再满足于在本行业的领先地位，希望能够对接到互联网业务的时候，上面的模式就会出现新的痛点。对接互联网所面临的最大的问题，就是巨大的用户量所带来的请求量和数据量，会是原来的N倍，能不能撑得住，大家都心里没底。例如有的客户推出互联网理财秒杀抢购，原来的架构无法承载近百倍的瞬间流量。
阶段3：解决之道

落地是一个非常复杂的问题，甚至都不完全是技术问题。它牵扯到IT架构、应用架构、组织架构多个方面。这不单单是一个技术问题，更是一个组织问题。在推动过程中，更加能够感觉到康威定律的作用，需要更高层次管理者的介入，方能够推动这些在企业的落地。

微服务和容器化的改造，更加容易发生在一个扁平化的组织里面，由一个能够体会到基层技术细节的痛的CIO，高瞻远瞩地推动这件事情。这也是为什么微服务的落地一般率先落地在互联网公司，因为互联网公司的组织架构很平台，哪怕是高层，也离一线非常的近，了解一线的痛。另一个原因是互联网业务强大的驱动力。

在一些相对先进的企业，会在运维组和开发组之间，有个中间件组，或者叫做架构组，来负责推动微服务化改造的事情，架构组就既需要负责劝说业务开发实施微服务化，也要劝说运维组实施容器化，如果架构组的权威性不足，推动往往也会比较困难。

备注：这里有采纳网易云刘超的一些观点，特此感谢。

目标很明确，也有有价值，但是道路的困难大家都知道，那么还是从第一步做起吧。

一、OpenShift 作为 PaaS 平台为红帽带来了很高的溢价。其实，从功能而论，OpenShift 相比 Kubernetes 并没有新增多少新的功能。但是，它第一次打造了面向DevOps的PaaS平台的产品，这是具有开创性的。就像新打开一扇大门一样，门并没有多少价值，但是门后的风景才是真正的价值。

二、根据前面的分析，PaaS 平台在企业的落地需要有咨询商这一角色的存在，而无疑IBM深谙这个领域。因此我对红帽的PaaS产品和IBM的咨询服务能力会怎么结合充满期待。

三、IBM发的公告里面特意提到了混合云，不知道IBM 会不会利用 OpenShift 来实现我前面画的那种混合云2.0。

另外，有时候我会想，为什么只有红帽能推出OpenShift 这种PaaS平台呢？我认为这和只有 Google 能推出 Kubernetes 是一样的，那就是公司的基因。正是因为他们自己长期使用容器，长期实践DevOps，才能比较自然地做出大家普遍能接受的产品。