基于Kubernetes的私有容器平台研究

孔祥文 宋辰萱

（中国市政工程华北设计研究总院有限公司 天津市 300074）

1 PaaS

PaaS（Platform as a Service）是云计算的重要组成部分，用户可以通过PaaS 平台完成应用的构建、部署、运维管理，而不需要自己搭建计算执行环境，如准备硬件资源、安装操作系统等。而Kubernetes 正是云计算PaaS 领域的集大成者，是Google 公司设计发布的，旨在提供跨主机集群的自动部署、扩展以及运行应用程序容器的开源系统。IaaS(Infrastructure as a Service)系统提供给用户的是虚拟机资源，而PaaS 负责应用的部署和运维，用户只需要专注于应用的开发。

传统的PaaS 系统主要由管理平台、计算资源池和服务资源池三个部分组成：PaaS 管理平台主要负责认证授权、应用自动化部署、运维监控等工作；应用运行在计算节点上，计算资源池提供应用所需要的完整运行环境，包括语言环境和应用框架等，一般基于Linux 的Cgroup 和Namespace 为应用提供资源隔离和限制；服务节点通过代理或接口为应用提供数据库、缓存和存储服务。传统的PaaS 架构如图1所示。

传统PaaS 平台也有很多局限性，用户开发应用时所选择的技术受限于平台支持的开发语言、框架和中间件；无法支持复杂的分布式应用；应用与平台锁定，很难迁移到其他PaaS 平台等。但随着Docker 容器技术的迅速兴起，PaaS 也迎来了新的挑战和机遇。

2 Docker

虚拟化及容器化是云计算的两大技术，Docker 中应用的就是容器技术。尽管容器技术出现很久，但却是随着Docker 容器平台的出现才变得广为人知。Docker 是第一个使得容器能够在不同机器之间移植的系统，它不仅简化了应用打包的过程，还将应用依赖的库文件甚至是整个操作系统的文件系统都打包成一个简单可移植的包，这个包能够在任何运行Docker 服务的机器上使用。

通常所说的Docker 实际上是指Docker 引擎，它是Docker 公司容器平台产品的核心部。Docker 引擎可以理解为一套轻量级应用运行时环境，应用及其依赖被隔离在相互独立的运行环境里，共享同一个OS 内核，将这种环境形象地称为“容器”。这种将多个应用部署在一台主机以相互独立的容器运行模式，在减少应用故障对其他应用影响的同时，还可以提高硬件资源利用率。

与容器相比，虚拟机通过模拟硬件环境，并启动完整的操作系统为应用运行提供独占环境，因此其中需要安装Guest OS；而容器是主机操作系统上的进程虚拟化，容器镜像中并不需要OS 内核，所以也不需要安装Guest OS,只需要应用运行相关的库和文件就可以了。相比与虚拟机实现，Docker 容器更轻量、更快捷。两者的对比关系如图2。

用户使用Docker 的一般场景如下：根据镜像标识从镜像仓库里下载镜像到本地，Docker 引擎使用本地镜像创建出多个相互隔离运行的容器。由于Docker 将应用和依赖文件都打包到了Docker镜像里，用户基于Docker 镜像将应用部署并运行到隔离的Docker容器后，就不再依赖宿主机提供运行环境支持，从而实现了应用和PaaS 平台解耦。这种机制为应用开发带来了巨大便利，用户向PaaS 平台提交的不再是代码，而是Docker 镜像，PaaS 平台也无须为应用准备各种运行时环境。新PaaS 平台架构如图3所示。

新PaaS 以Docker 容器为基础，面向云化、微服务、DevOps等应用场景，支持大数据、分布式计算、深度学习等多种计算服务，集成开发、测试、部署流水线，成为一站式应用开发运行平台。

3 Kuberntes介绍

在新PaaS 平台上运行的生产应用会涉及多个容器，这些容器必须能够跨多个主机部署运行，随着数量的不断累积，复杂性也随之提高，Kubernetes 正是为解决这个问题而生的。借助Kubernetes，用户可以构建多个容器的应用服务，跨主机调度、扩展这些容器、持续管理容器状况。简单来讲，Kubernetes 将容器扩展成逻辑概念上的“容器集”（Pod），增加了一个容器分组抽象层，用户通过选择Kubernetes 工作负载运行容器，并为其提供网络和存储服务，同时Kubernetes 确保系统中运行正确数量的容器。Kubernetes 作为一个开源的软件系统，为支撑PaaS 能力提供了如下功能：

3.1 自动装箱

根据资源需求以及其他相关约束条件，在不降低应用可用性的前提下对容器进行自动部署，基于工作负载尽力而为的特性，提高资源使用率以便节省更多资源。

3.2 弹性伸缩

支持根据CPU 或自定义监控指标的使用情况对应用程序容器进行自定义扩容或缩容。

3.3 服务发现与负载均衡

Kubernetes 为容器可以为容器提供独立的IP 地址，或针对一组相同应用程序容器提供虚拟VIP 和DNS 域名，以便用户访问Kubernetes 容器业务，并在这些容器间进行负载均衡。

3.4 容器异常自愈

如果容器启动或运行失败，Kubernetes 会重新创建失败的容器；同时Kubernetes 也为用户提供了容器检查的自定义钩子，Kubernetes 会根据钩子的执行结果来决定是否对容器进行销毁重建或负载均衡的摘除操作。

图1

图2

图3

图4

3.5 多种应用类型支持

Kubernetes 通过定义不同的工作负载，支持部署运行无状态应用、有状态应用、一次性任务应用、周期性任务应用、节点daemon 应用等。

3.6 滚动更新发布与回滚

支持对一组应用程序容器进行逐步滚动更新的机制，对应用程序运行状况进行监控以确保所有实例不会同时终止。如果在更新过程中出现问题，支持回滚更改。

3.7 密钥与配置管理

支持应用配置资源与密钥资源，用户无需重新构建镜像即可实现应用配置资源和密钥资源更新。

Kubernetes 遵循微服务架构理念设计，实现了整个系统各个功能组件之间边界清晰、部署简单的模块化，同时支持多种扩展机制，用户可以方便地进行功能扩展和自定义实现。

4 Kubernetes架构

Kubernetes 为容器管理提供了一个抽象层和一系列相关工具，支持大规模容器的编排与管理，确保应用程序的高可用和服务可移植性；同时Kubernetes 还可以更好地控制资源使用情况，如整个系统的CPU、内存和磁盘空间，在系统整体基础资源不足时支持自动添加工作节点以完成集群的扩容[1]。图4 展示了Kubernetes 的核心架构。

从图4 中可以看到，整个Kubernetes 是由Master 节点和Node节点构成。

Master 节点是Kubernetes 集群的大脑，上面运行了API 服务、调度服务、控制器管理服务和Etcd 存储服务。API 服务提供了基于Restful 的Web Service 接口，用于查询或定义各种所需要的集群和状态，API 服务内部有一套完备的安全机制。所有Kubernetes 集群对象的增删改查操作只能通过访问Kubernetes API 服务器来实现。Master 节点上的调度服务以Node 节点上实际Pod 为单位进行工作负载调度，用于为Pod 选择合适的Node 来运行。控制器管理器是所有资源对象的自动化控制中心，用于管理各资源的控制器，用于进行故障检测和自动化恢复的相关工作。Etcd 是一款分布式一致性的key-value 存储，用于保存网络配置和状态信息。

Node 节点可以是物理机或虚拟机，承载了实际运行业务的容器，是Kubernetes 集群中的工作节点。Node 节点上运行了三个重要组件：kubelet、kube-proxy、容器引擎。kubelet 处理着master 和在其上运行的节点之间的所有通信，并负责创建、启动和监视pod的运行。此外，kubelet 还会周期性地对配置的存活探针和就绪探针进行检查，并在出现问题时启动新实例。kube-proxy 是以pod 形式运行在节点上的网络代理，负责代理UDP、TCP 数据包，维护主机上的网络规则，并处理pod、主机和外部环境之间的数据包传输。容器引擎在Kubernetes 中也叫做容器运行时，负责从公有或私有镜像仓库中拉取镜像，并根据这些镜像运行容器。

5 Kubernetes配置与应用示例

使用Minikube 是运行Kubernetes 集群最简单快捷的方法。Minikube 是一个构建单节点集群的工具，对于学习测试Kubernetes、开发本地应用都很有用。由于Linux 是目前业界广泛使用的商业操作系统，以下内容着重介绍Linux 服务器上Kubernetes 的安装配置过程[2]。

安装Minikube：curl -Lo minikube https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64

&&chmod +x minikube

Minikube 安装完成后，可以在本地启动一个单节点的Kubernetes 集群：./minikube start

Kubernetes 机器组件启动后，还需要使用kubectl 工具与启动的Kubernetes 集群交互，kubectl 工具的安装也很简单，使用一条命令：curl -LO

https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl &&chmod +x kubectl

然后，在Kubernetes 中运行第一个应用：kubectl create deployment hello-node --image=k8s.gcr.io/echoserver:1.4，稍后可以看到应用已经被正常启动了。

执行kubectl get deployments，查看启动的应用controller，此时输出结果类似于：

NAME READY UP-TO-DATE AVAILABLE AGE

hello-node 1/1 1 1 1m

执行kubectl get pods 查看启动的应用实例，输出结果类似于：

NAME READY STATUS RESTARTS AGE

hello-node-5f76cf6ccf-br9b5 1/1 Running 0 1m

从以上结果中可以看到在Kubernetes 系统中运行了一个应用实例，这个应用实例的名字为hello-node-5f76cf6ccf-br9b5。

6 总结

Kubernetes 项目从一开始就没有把Docker 作为整个架构的核心，而是将其作为最底层的一个容器运行时实现，Kubernetes 着重解决的场景：运行在大规模集群里的各种应用之间的关系，如何处理这些关系才是作业编排和管理系统最困难的地方。这些关系包括但不限于：Web 应用与数据库之间的访问关系、负载均衡和后端服务之间的代理关系、Web 应用与授权组件之间的调用关系。而对编排项目的需求是希望它能够处理前面提到的所有类型的关系，甚至还要能够支持未来可能出现的更多种类的关系。