容器云平台和 Kubernetes 之间不得不说的那些事

我们知道，传统的应用部署方式是将应用直接部署于单独的物理机或虚拟机中。但是在企业数字化转型的浪潮下，如何满足日益丰满的业务需求，如何高效践行敏捷研发，如何更好的将应用落地实施于客户现场，保障稳定高可用并利于维护，是传统企业不得不面对并解决的问题。

　　用友云技术中台为助力企业数字化转型提供了大量利器，比如本文将着重提及的容器云平台，就是其中之一。

　 容器云平台，是基于容器的运行时引擎，利用 Kubernetes 等容器调度方案，用以解决开发、测试、运行环境统一，服务快速部署，运行期服务管理、调度等问题而建设的平台。

　　那么，容器云平台到底是如何建设的呢？利用了容器技术的哪些优势呢？又是如何利用 Kubernetes 实现对外提供服务的呢？最后，容器云平台到底有什么能力，为企业提供了哪些价值呢？

　　本文将就这这些疑问，为您一一解答。相信您读过之后，一定会了解到关于容器云和 Kubernetes 之前更多的秘密。

一、容器云平台的技术选型容器化技术——Docker

　　Docker 是使用 Go 语言进行开发，基于 Linux 内核的 cgroup、Namespace 等技术，对应用的进程进行封装隔离，最终在操作系统层面实现的虚拟化技术。Docker 无疑是目前最受欢迎的开源容器引擎，它采用了集装箱搬运的思想，可以将任何应用及其依赖打包成一个轻量级、可移植、自包含的容器，为应用提供了一个基于容器的标准化运输系统。使用 Docker 技术，可以彻底释放计算虚拟化的威力，提高应用的可维护性，降低云计算应用开发的成本。可以说 Docker 技术的出现，让应用的部署、测试和分发都变得前所未有的高效和轻松。

具体来说，使用 Docker 容器技术，可以为容器云平台带来以下技术优势：

　　1） 支持跨平台适配　

　容器带来的最大好处之一就是其适配性，越来越多的云平台都支持容器，用户再也无需担心应平台的捆绑，同时也能让应用多平台混合部署成为可能。目前支持容器的 IaaS 平台包括但不限于亚马逊平台（AWS）、Google 云平台（GCP）、微软云平台（Azure）、OpenStack 等，还包括如 Chef、Puppet、Ansible 等配置管理工具。

　　2） 优化持续部署与测试过程

　　容器消除了线上线下的环境差异，保证了应用生命周期内环境的一致性和标准化。开发人员使用镜像实现标准开发环境的构建，开发完成后通过封装着完整环境和应用的镜像进行迁移操作。由此，测试和运维人员可以直接部署应用镜像来进行测试和发布，大大简化了持续集成、测试和发布的过程。

　　3） 环境标准化和版本控制

　　基于容器提供的环境一致性和标准化，你可以使用 Git 等工具对容器镜像进行版本控制。相比于代码的版本控制来说，你甚至能够对整个应用运行环境实现版本控制，一旦出现故障可以执行快速回滚操作。相比以前的虚拟机镜像，容器压缩和备份速度更快，镜像启动也像启动一个普通应用一样快速。

　　4） 高资源利用率与隔离

　　容器没有管理程序的额外开销，与底层共享操作系统，因此其性能更加优良，系统负载更低，在同等条件下可以更充分地利用系统资源。同时，容器拥有不错的资源隔离与限制能力，可以精确地对应用分配 CPU 和内存等资源，防止应用间相互影响。

　　5） 具备容器跨平性

　　Linux 容器虽然早在 Linux 2.6 版本内核已经存在，但是缺少容器的跨平台性，难以推广。容器在原有 Linux 容器的基础上大胆革新，为容器设定了一整套标准化的配置方法，将应用依赖的运行环境打包成镜像，真正实现了“构建一次，到处运行”的理念，大大提高了容器的跨平台性。

　　6） 应用镜像仓库

　　Docker 官方构建了一个镜像仓库，组织和管理形式类似于 GitHub，其上已累积了成千上万的镜像。因为 Docker 具有跨平台适配性，它为用户提供了一个非常有用的应用商店，所有人都可以自由地从其中下载镜像做为服务组件。这为开发者提供了巨大便利。

将 Kubernetes 容器编排系统作为容器云平台的底层技术支撑，可以带来如下特性：

　　1） 自动包装　　根据资源需求和其他约自动放置容器，同时不会牺牲可用性，混合关键和最大努力的工作负载，以提高资源利用率并节省更多资源。

　　2） 自我修复　　重新启动失败的容器，在节点不可用时，替换和重新调度节点上的容器，对用户定义的健康检查不响应的容器会被中止，并且在容器准备好服务之前不会把其向客户端广播。

　　3） 横向缩放　　

使用简单的命令或 UI，或者根据 CPU 的使用情况自动调整应用程序副本数。

　　4） 服务发现和负载均衡

　　不需要修改应用程序来使用不熟悉的服务发现机制，为容器提供自己的 IP 地址和一组容器的单个 DNS 名称，并可以在它们之间进行负载均衡。

　　5） 自动部署和回滚

　　支持灰度、滚动式部署应用程序，并支持对其配置进行更改。同时监控应用程序运行状况，以确保它不会同时终止所有实例。当出现问题，自动触发服务自愈功能恢复应用。

　　6） 密钥安全性保证

　　部署和更新密钥和应用程序配置，不会重新编译您的镜像，不会在堆栈配置中暴露密钥（secrets）。

　　7） 批处理

　　可以批量管理资源池节点机，可以根据需要自动替换出现故障的容器。

应运而生的容器云平台

　　传统企业在转型过程中遇到的种种问题，不断地推进着系统架构的演变。传统的物理机及虚拟机部署方式已经不能满足企业现代化系统建设的需求。而随之到来的，是向以容器为核心的基础设施的转变。但是，这个转变并不是一次温和的改革，而是涵盖了对网络、存储、调度、操作系统、分布式原理等各个方面的容器化理解和改造。企业级应用开发更是需要基于容器技术，实现支持多人协作的 CI/CD 平台。　　因此，企业迫切需要一套具有完备功能的容器云平台，以使原有的基于虚拟机的部署方案，彻底转变为更加灵活和轻量的“容器+编排调度”应用落地方案。　　用友在经过技术过硬的研发团队集成、适配、打磨、优化、扩展后，推出了功能强大的完美适配企业转型需求的容器云产品。

利用容器部署应用，对外提供服务过程详解

在之前的技术文章中我们提到，Kubernetes 中的 Pod 是部署应用的最小单位。一个 Pod 封装一个应用容器，存储资源、一个独立的网络 IP 以及管理控制容器运行方式的策略选项。业务涉及到的所有应用均运行在容器云平台所管理的一个个的 Pod 当中。

　　当应用的 Pod 创建好之后，就要考虑建立完整的访问链路系统，最终实现对外提供服务的能力。建立网络访问的第一步，是实现各个 Pod 在所依赖宿主机——利用 Kubernetes 搭建的集群间内部的联通和访问。

集群内部 Pod 访问逻辑

实现集群内部访问有两种方案，分别如下：

　　1） 直接使用 docker 分配的 IP 地址

　　在 Pod 运行时，docker 会为其分配一个独立的 IP 地址。拼接这个 IP 地址和服务的端口号，即可直接访问此 Pod 中的服务。但是这种方式有一个巨大的问题，即 Pod 在重启或销毁重建后，将会分配新的 IP 地址。

　　2） 通过 ClusterIP 方式访问

　　Pod 的 IP 地址实际存在于某个物理网卡或虚拟网卡上 ，而 ClusterIP 是创建 Service 的时候，由系统内部分配的一个全局唯一的虚拟 IP.这个虚拟 IP 在网络中是无法寻址到的，它没有绑定到任何网卡设备上。这增加了它的访问的灵活性。我们可以通过服务的 ClusterIP 加应用容器的服务端口号来进行访问。

Service 的业务入口访问机制

当 Pod 的访问有优选方案之后，我们接下来面临了下一个问题：Pod 的 IP 和 ClusterIP 都是在每次创建后随之变化的，如何在应用的 Pod 重启后，保证服务的可访问性呢？此时，k8s 中的 Service 可以解决此问题，它为应用的访问提供了一套业务的入口机制。

　　Service 为 k8s 系统提供了容器集群负载均衡功能，并开放式地支持了用户所需要的各种负载均衡方案和使用场景。逻辑层面上，Service 被认为是真实应用的一个抽象，每一个 service 关联着一系列的 Pod，根据 LabelSeletor 来刷选 Pod 进行关联，对外表现为一个单一的入口，依托于 Proxy 转发到 Pod 内部。实际上来说，k8s 在 Service 和 Pod 之间是通过 Endpoints 衔接的，这个 Endpoint 由根据关联到 Pod 的 IP 信息组合而成。

　　简单来说，Service 就是一个把所有 Pod 都池化为一个组，然后对外统一固定成一个 IP.Pod 可以通过 Deployment 中所选择的 Label 来进行设置，最终可以按照对应的配置访问。

集群外访问逻辑

一般来说，服务对外访问有这几种常见的模式：HostNetwork-true、Nodeport、ingress、Loadbalancer 等几种。

　　1） HostNetwork-true 模式

　　这种方式顾名思义，就是将业务中的端口直接暴露在宿主机上。业务中监听的端口在宿主机中通过 netstat 命令就可以直接看到。宿主机所在的局域网上所有网络接口都可以访问到该应用程序。

　　2） Loadblancer 模式

　　在这种方式下，kubernetes 可以请求底层云平台创建一个负载均衡器，将每个 Node 作为后端，进行服务分发。

　　3） Nodeport 模式

　　在此模式下，系统会在每一个节点机上开放一个特定端口，任何发送到该端口的流量都被转发到对应服务。这种模式下启动的 Pod 会生成一个名为 nodePort 的附加端口，用于指定在节点上打开端口。如果不指定，这个端口将随机生成。我们一般建议将端口设定在一定的范围内，如 30000-32767.这种访问方式可以在 Service 指定好 Nodeport 的 Type 之后，通过何一台 Node 的 IP+nodePort 就可以对业务发起访问。但是，NodePort 这种方式有个弊端，它会在集群中的任何一台机器上起动一个端口进行监听，即便工作负载从未在这个节点上部署过。这势必造成一些端口的浪费。

4） ingress 模式　　

随着后期的发展，理想的方式是通过一个外部的负载均衡器，绑定固定的端口，比如 80，然后根据域名或者服务名向后面的 Service ip 转发请求。Ingress 模式就是实现这种方案的模式。

　　Ingress 包含了两大主件 Ingress Controller 和 Ingress.k8s 的 Ingress 对象提供了另一种服务暴露的方法，它只占用一台主机的 HTTP 端口，通过虚拟主机或者虚拟目录的方式为 K8S 上的所有 HTTP 服务提供暴露服务，还能实现 HTTPS、负载均衡、状态统计等功能。

容器云平台的技术落地方式

在之前的介绍中可以看到，ingress 模式是最理想的实现方案。因此，容器云平台采用以 Ingress 为主的入口方式。

　　在 Kubernetes 集群中，Ingress 是入站连接到达集群服务的规则集合，可提供七层负载均衡能力，用户可以通过 Ingress 配置提供外部可访问的 URL、负载均衡、SSL、基于名称的虚拟主机等。在实际的项目中，应用容器数可能是几十个容器，有的已经达到几百个规模。这其中，有的是部署的业务应用数目少，但是容器副本多；有的则是部署的业务就达到百个。面对不同的实际业务场景，我们要对链路进行更好的规划，使其稳定性得到保障。在给客户制定部署方案的时，需要将泛域名解析这一容器云平台中已有的链路环节拆分出来。在访问应用的时候，通过 Nginx 入口后，跳过统一泛域名解析跳转这一环节，直接将 Nginx 的请求转发到 Ingress 当中，这样能够减少链路层的数据传递，使系统更加稳定高效。

容器云平台的能力和价值　

开发者中心提供的容器云平台，是一个致力于打造以应用为中心的容器管理平台。目前，其提供了极具特色的核心竞争力，如完备容器云服务：提供多数据中心、多租户、多环境、多资源池能力，可以根据需求随意定义；如全面支撑微服务应用：从服务定义、服务拆分、服务扩展、服务编排、服务运行形成完整的理论和实践。

　　举例来说，它提供了以下能力，经过长时间的线上实践，在客户的落地使用中为客户提供了巨大的价值。

　　1） 资源的逻辑管理能力

　　主要实现对主机、存储和网络的集中管理，对租户提供资源的统一分配及应用的统一部署，实现与 IaaS 资源的互动，动态替换和补充资源。

2） 弹性伸缩和扩容缩容能力

　　能够快速实现资源动态调度和扩缩容，能够定义动态弹性伸缩策略，应用容量可根据策略自动进行服务的动态扩展。支持水平和垂直，手工与自动等方式；基于业务运行态动态调整，提供不同场景化产品需求能品化的能力。

一款支撑微服务架构应用全生命周期管理的平台，为开发者提供从开发到运维、运营的一系列开发套件和服务，包含 RPC 框架、配置中心、注册中心、服务链路追踪、服务限流、服务熔断、服务统计、服务评价等组件和服务。

4） 统一的运营监控能力

　　提供可视化、自助式运维工具，实现对所有产品线、产品、租户、集群、资源、应用、容器等企业数字化资源进行集中式运维和监控。

容器云平台对企业的价值

企业为什么需要容器云平台

企业数字化转型，使得众多企业不断创新、顺应趋势、改变思路，开始尝试或采用容器化技术，根据业务特性选择适合的业务，通过逐步推进来建设自己的企业级容器云平台。

　　容器云以容器为资源分割和调度的基本单位，封装整个软件运行时环境，为开发者和系统管理员提供用于构建，发布和运行分布式应用的平台。当容器云专注于资源共享与隔离、容器编排与部署时，它更接近传统的 IaaS（基础设施即服务）；当容器云渗透到应用支撑与运行时环境时，它更接近于传统的 PaaS（平台即服务）。

　　容器云平台推进了软件开发、测试、部署、运维和运营模式的创新，承载了企业和 IT 基础设施和基础技术服务，为企业业务应用的建设和发展提供了强有力的支撑，同时促进了与产业链生态环境中上下游系统的高效对接和协同创新。