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

ゝ一纸荒年。 2022-01-11 12:17 570阅读 0赞

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

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

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

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

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

**一、容器云平台的技术选型**

容器化技术——Docker

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

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

具体来说，使用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

Kubernetes（k8s）是一个基于容器技术的分布式架构解决方案。它是用于自动部署，扩展和管理容器化应用程序的开源系统。它在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。同时，Kubernetes还提供了完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。可以说利用Kubernetes，可以提高大规模容器集群管理的便捷性。

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

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

1） 自动包装

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

2） 自我修复

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

3） 横向缩放

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

4） 服务发现和负载均衡

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

5） 自动部署和回滚

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

6） 密钥安全性保证

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

7） 批处理

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

应运而生的容器云平台

传统企业在转型过程中遇到的种种问题，不断地推进着系统架构的演变。传统的物理机及虚拟机部署方式已经不能满足企业现代化系统建设的需求。而随之到来的，是向以容器为核心的基础设施的转变。但是，这个转变并不是一次温和的改革，而是涵盖了对网络、存储、调度、操作系统、分布式原理等各个方面的容器化理解和改造。企业级应用开发更是需要基于容器技术，实现支持多人协作的CI/CD平台。

因此，企业迫切需要一套具有完备功能的容器云平台，以使原有的基于虚拟机的部署方案，彻底转变为更加灵活和轻量的“容器+编排调度”应用落地方案。

用友云技术中台的容器云平台，经过严谨的技术选型，天生继承了选用技术的优良基因。在经过技术过硬的研发团队集成、适配、打磨、优化、扩展后，推出了功能强大的完美适配企业转型需求的容器云产品。  
![容器云平台和Kubernetes之间不得不说的那些事][Kubernetes 2]

**二、利用容器部署应用，对外提供服务过程详解**  
　 在之前的技术文章中我们提到，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这种方式有个弊端，它会在集群中的任何一台机器上起动一个端口进行监听，即便工作负载从未在这个节点上部署过。这势必造成一些端口的浪费。

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

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资源的互动，动态替换和补充资源。

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

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

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

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

3） 支撑微服务治理能力

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

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

4） 统一的运营监控能力

提供可视化、自助式运维工具，实现对所有产品线、产品、租户、集群、资源、应用、容器等企业数字化资源进行集中式运维和监控。  
![容器云平台和Kubernetes之间不得不说的那些事][Kubernetes 7]

**四、容器云平台对企业的价值**

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

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

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

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

企业需要什么样的容器云平台

用友云平台技术中台——开发者中心是集容器云平台、DevOps平台、微服务治理平台于一体的综合性企业级应用托管PaaS平台。开发者中心是企业IT信息化建设的基础设施平台，并对微服务进行集中管控、智能运维和容器云全生命周期等运营管理。

在开发者中心的集中管控框架下，可以对主机、网络、存储、应用环境、开发、部署、集成、运维等过程进行分析和规划；以资源的集中管理及应用的统一快速部署、不中断业务的灰度发布；方便快捷的操作管控及更智能的运维监控为核心目标，构建一个高可用、高性能、高扩展的综合性托管企业级应用的PaaS平台，并为企业解决统一规范管理产品。使用开发者中心，还可以提高资源利用率，降低IT成本，解决运维困难成本高，产品更新效率低。微服务实施困难。大数据环境复杂等日常运维中遇到的痛点问题。

开发者中心还提供了多云的接入能力，可以对接阿里云、华为云、AWS等多家云厂商，同时支持VMWare、Openstack、BareMetal等操作系统。在IaaS基础上提供容器支撑服务和安全机制；在容器支撑服务上提供DevOps能力、AI能力、微服务架构能力、中间件服务能力、大数据分析能力等。平台支持多种语言运行环境如Java、Node.js、Golang、Python、静态网站等，或使用Dockerfile构建应用。

开发者中心以容器云为基础设施，不仅提供轻量便捷的公有云产品形态，也提供带有企业特色的专属云形态；不仅提供all-in-one的简化部署方式，也提供Multi-node的分布式部署方式，为企业提供更多选择，更适合企业建设的PaaS基础平台。

转载于:https://blog.51cto.com/14084875/2411232

[Kubernetes]: https://s1.51cto.com/images/blog/201906/19/925149cfbc85e524188a5a0f3ed380d0.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[Kubernetes 1]: https://s1.51cto.com/images/blog/201906/19/2ee54004708b8481b9fe1f7054fce0ce.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[Kubernetes 2]: https://s1.51cto.com/images/blog/201906/19/217dbb6a824420ebb959b0f7c2012acf.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[Kubernetes 3]: https://s1.51cto.com/images/blog/201906/19/7018d9e4b7da3b5fe429d043995b23ee.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[Kubernetes 4]: https://s1.51cto.com/images/blog/201906/19/05ccd5b1e8fb8307eddee59448a17dec.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[Kubernetes 5]: https://s1.51cto.com/images/blog/201906/19/a43a07f5a682e5fdbe601bad4fb7cc36.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[Kubernetes 6]: https://s1.51cto.com/images/blog/201906/19/56e77f00ee15c98f3d0e998856d563e2.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=
[Kubernetes 7]: https://s1.51cto.com/images/blog/201906/19/e4a3a8f568b297e635f8a409bac0352f.png?x-oss-process=image/watermark,size_16,text_QDUxQ1RP5Y2a5a6i,color_FFFFFF,t_100,g_se,x_10,y_10,shadow_90,type_ZmFuZ3poZW5naGVpdGk=