用web做的网站怎么合成一个/网站快速有排名

作者简介

涂家英，SUSE 资深架构师，专注 Cloud-Native 相关产品和解决方案设计，在企业级云原生平台建设领域拥有丰富的经验。

数字时代下的容器云管理平台

数字时代，市场竞争加剧，业务需求日新月异，敏态 IT 建设被越来越多的企业纳入重点发展规划，以容器、Kubernetes 为核心的云原生是目前敏态 IT 中最热门的技术架构。

CNCF 把云原生划分为多个领域，包括基础设施、应用开发与部署、服务发布与治理、运行时、网络、存储、观测与分析、安全与合规等，每个领域中都有非常丰富的开源项目。从技术视角来看，云原生建设就是在各领域中找到能够满足自身需求的技术，并组合起来，为我们所用。在这个过程中，我们直面的问题包括：如何选择合适的技术？如何对这一技术组合进行统一管理？如何调整和优化这些技术以实现高效、稳定的运行？

对此，容器云管理平台的概念应运而生，简单地说就是提供一系列开箱即用的功能，并围绕 Kubernetes 提供更多的扩展和创新。容器云管理平台是一个中间态的产品，对下能够实现集群的生命周期管理，对上能够实现对 Kubernetes 上运行的应用的生命周期管理，同时还需具备企业所需的功能，如租户管理、安全管理、用户认证以及权限管理等。

目前，国内有不少厂商专注于这个领域，提供了很多优秀的解决方案，面对琳琅满目的产品，我们该如何选择？

平台选型

在日常与企业客户的交流中我不难们发现，大家在建设云原生平台过程中，讨论最多的就是规划和选型问题。如果把选型过程比作通关游戏，那么我们会遇到性质思考、模式思考和能力思考三个关卡。

性质思考

从企业实际应用场景来看，容器云管理平台是一个跨部门平台，至少会涉及基础设施部门、研发部门、安全部门；当然，不同企业对部门的划分可能会更细致。而且，容器云管理平台和业务应用又有着紧密的关联性，会影响业务应用的构建发布流程和运行运维方式，所以从整体看来容器云管理平台具备了 2 个特点：技术上的确定性和能力上的特异性。

• 技术上的确定性：在建设容器云管理平台时，相关的技术栈基本是确定的，例如容器编排调度引擎使用 Kubernetes，监控使用 Prometheus，日志使用 ELK 或者 Loki，模板商店使用 Helm 等，还有像容器运行时、网络、存储等也都有很清晰的选择范围。
• 能力上的特异性：每个企业 IT 部门都有自己的工作方式、流程、组织架构和内部环境，对容器云管理平台建设都有自己的看法。有些企业的容器云管理平台相对独立；有些可能需要与内部的其他系统做集成和联动，如与内部监控集成形成统一环境监控，与内部日志平台集成形成统一认证，与内部用户认证平台集成实现 sso 单点登录，需要与组织架构相对应的多租户能力等，这就需要不同的能力支持。从这个角度来讲，完全按照自身需求，自研一套容器云管理平台是企业的最优选择。

但是自研的门槛比较高，需要一定的团队和技术实力，大多数企业都不具备这样的能力。商用是更务实的选择，有很多厂商提供了相应的平台产品，但也有不少挑战。虽然平台都基于 Kubernetes 搭建，但是不同的产品理念，可能造就了不同的功能侧重点，以及未来不同的发展和延伸路线；还有一些产品存在不同程度的捆绑，一旦选错可能将深陷泥淖。

综合来看，选择开源的、兼容性好的商用产品能够在一定程度上实现自研和商用的平衡。一方面，企业可以通过标准化的产品能力和厂商的专业技术支持及赋能，快速培养和提升自身团队对云原生的认知和技术水平。另一方面，在团队能力达标，且标准化的能力已经无法满足内部需求时，企业可以基于开源产品更便捷地进行二次开发。

实际上，在团队实力达标的情况下，我们也不太建议一开始就完全自研平台，因为从 0-1 的建设可能会踩很多坑，遇到很多问题，一些功能直接复用开源产品造好的轮子会事半功倍。同时，使用开源产品确保了技术的延续性，在购买商业支持后，可以大幅减少人力成本支出，提升工作效率，有更多的时间专注于自身的主营业务。

模式思考

在明确了性质选择后，我们转角就遇到了第二个选型问题：应该选择全功能模式还是组合功能模式？

当前，各种容器云管理平台产品丰富，大致可以分为两类：功能全面型和开放兼容型。

功能全面型：平台中功能基本覆盖了云原生所有元素，如包括了 Kubernetes 集群管理、应用管理、DevOps、微服务治理、中间件等各大板块能力，并且高度封装。
开放兼容型：平台中功能以保有核心能力为主，如 Kubernetes 集群管理、应用管理，其他能力以开箱即用的插件方式提供，具备高度的可替换性。

功能全面的容器云管理平台能够屏蔽掉很多技术细节，企业可以拿来即用；开放兼容型产品可以提供更灵活的组合方式。

在早期，容器和 Kubernetes 技术还不是那么普及，功能全面型的产品是比较好的选择，企业可以借助其全面的能力快速构建，屏蔽掉一些技术门槛，预研云原生技术和带来的价值；当今，容器和 Kubernetes 技术已经比较普及，整个 CNCF 生态也进入了繁荣时期，云原生的建设更多是积木式、集成式的组合。

“专业的事情交给专业的人去做”，大而全平台的问题在于整体功能都是内聚的、互相依赖的、标准化的。用户往往在使用时发现，很多地方并不能很好地契合自身需求，还需要替换功能模块。然而在高内聚的布局下，模块的剥离和替换往往难以实现，或者成本很高。所以，越来越多的用户会选择开放兼容性好的产品，在需要替换平台中的某些功能模块时，只需要关闭相应模块，直接进行替换或者集成即可。

同时我们也看到，越来越多功能全面的平台也开始化整为零，固化必备的基础能力，周边能力则以模块插件方式提供，方便用户进行替换。

能力思考

走到这一步，选型的思路就比较清晰了。我们遇到的最后一个问题是：除了性质和模式，还需要考虑哪些因素呢？

基于与众多客户的接触，我们提炼出两点：

• 沉淀包含很多方面，比如产品的迭代历史、使用人数、行业落地案例等。这些沉淀可以很好地反映产品的成熟度和稳定性，毕竟大家都不想在生产环境中做第一个吃螃蟹的人，更希望有一个成功的参照物可以借鉴。
• 创新是一个企业的灵魂，云原生就像是一列飞驰的高铁，好的产品提供者应该能紧跟技术发展，并不断推陈出新。企业在使用容器云管理平台的同时，在不同的阶段总会出现不同的需求场景和问题，能不能走在用户前面引领用户，并陪伴用户成长，也是选型考虑的一个重要因素。

通过以上三个关卡，想必大家已经有了选型的初步想法。下面让我们从应用场景出发，再对产品选型能力指标做一些考量。

场 景

多集群及环境统一管理

企业中不同类型的 Kubernetes 集群越来越多，混合管理的需求与日俱增。我们在与客户聊集群规划的时候经常听到：

• 我们需要在不同的环境建设 Kubernetes 集群，包括开发、测试、UAT、生产。
• 这些应用比较重要，需要单独的集群支撑，方便重点运维。
• 我们 X 应用是外采的，它的底座也是 Kubernetes 集群，要把平台管理起来。
• 我们之前 X 部门走的比较靠前，当时用开源工具部署了一个 Kubernetes，现在需要暂时管理起来，后续再考虑新建集群并迁移。
• 我们除了私有云以外，某公有云上也使用了 Kubernetes 集群（也想在公有云上使用 Kubernetes 集群），能否方便地实现混合云管理。
• 我们现在容器和 VM 是共存的状态，整体应用包含了容器运行部分和 VM 运行部分，有没有能统一管理容器和 VM 的方式……

在云原生时代，随着企业的不断发展，多云混合云的场景变得越来越普遍。以某零售企业为例，其 APP 商城平常运行在私有数据中心，在早期业务量不大的时候，即使在大促时也完全可以承载和支撑。但随着企业的不断发展，大促带来的访问压力已经到了本地无法支撑的程度，但是为了应对大促而去扩大私有数据中心规模的做法又不够经济，这会造成平时大量的资源闲置。

最终，该企业采用了混合云方案，在公有云上使用 Kubernetes 集群，通过统一入口管理私有云集群和公有云集群。当大促来临时，通过公有云临时扩充集群节点，应对压力。

由此可以看出，多集群以及环境的统一管理是考量容器云管理平台的重要能力指标。Kubernetes 作为通用基础架构，可以很好地应对多云带来的差异性，满足企业的多云策略需求。从 ROI 的角度看，容器云管理平台覆盖的公有云类型越多，就越能增强 FinOps 和多云议价能力。

增强式安全防护

从前，大家更关注应用如何容器化、怎样上 Kubernetes；而当下，大家越来越关注安全问题。容器安全处于早期发展阶段，还存在一些问题。从技术角度看，Kubernetes 自身的安全能力较低，之前版本内置了 PSP 功能，但也局限在一些与权限相关的防护上；而且，高版本已经废弃了这一功能。CIS 虽然提供了 Kubernetes 基线扫描，但主要用于检测 Kubernetes 的配置是否有安全隐患，防护面很有限。从知识储备角度看，在多数企业内，懂云原生的工程师不太懂安全，懂安全的又不太了解云原生，这导致容器安全防护建设工作无从下手。

近几年，云原生相关安全事件层出不穷，当事企业遭受了不少损失，安全建设已成为当下亟需解决的问题。一个合格的云原生安全防护平台至少应具备以下能力：

• CICD 嵌入能力：可以在流水线中启用防护，比如镜像打包完成后的扫描，实现一定程度的安全左移。
• 准入控制能力：可以在应用部署时进行相应防护，尽量降低不安全因素进入集群，如可信仓库和镜像白名单、有安全隐患的部署配置阻断等。
• 运行时防护能力：可以在容器运行态上进行相应防护，如网络防护、进程防护、文件防护。
• 以零信任为核心的安全防护理念：可以实现零日攻击防护以及一些未知的攻击行为。

目前有不少厂商专注这一领域，提供的产品也各有特色，可以有效帮助我们补强 Kubernetes 安全能力不足的问题。综合考虑使用体验、易用性以及统一管理等方面，如果容器云管理平台能提供足够的安全防护能力，那将是最佳的选择。

数据中心到边缘

边缘计算是近两年的热门领域，很多企业都在积极布局，利用容器和 Kubernetes 技术充分发挥云边协同的效能。业界对边缘的定义至今没有统一，不同的企业由于不同的业态对边缘的定义也不尽相同，对于银行来说边缘可以是网点也可以是各种金融终端设备，对于制造业来说边缘可以是工厂侧也可以是产线侧。

对于有边缘应用场景的企业来说，选型时首先要考虑平台是否具备实现云边协同的能力，还要考虑云边协同的方案是否有延展性，大能适应各类服务器，小能覆盖各类小型计算资源设备，另外还要考虑能否实现高度的自动化交付从而提升效率。

比如现在边端有海量的设备，一般的部署流程大致是：

安装操作系统 ➞ 安装相应的 Kubernetes 发行版 ➞ 部署边端集群并注册到云端管理平台 ➞ 部署各类应用

目前热门的边缘计算交付方式分为两个步骤：

Day1: 设备通过定制镜像自动部署操作系统及集群，并实现自动注册

Day2: 按照编排需求，GitOps 自动同步各类应用到不同边缘集群

可以看出，后者通过自动化极大简化了交付过程，从而提升了整体效率。如果平台能够提供足够弹性的云边协同方案以及高度自动化交付，将为企业带来强劲的边缘计算建设助力。

现在，在实施大多数边缘计算方案的时候，还需要在边缘端投入不少的人力进行前期工作，如操作系统安装，半自动化的 Kubernetes 发行版安装以及云端注册等，自动化程度越高就越能降低人力成本。

写在最后

本文站在行业大视角，为大家提供了一些普遍适用的容器云管理平台考量要素。云原生领域可选择的平台很多，有开源也有闭源，虽然表面上看产品功能有同质化趋势，但其底蕴和理念是不同的。

以 Rancher 为例，作为最早的一款全开源的容器管理平台，其 1.x 版本陪伴用户走过了 docker swarm、mesos 和 Kubernetes 的三国鼎立时期；2.x 版本则紧跟社区和技术发展，专注于 Kubernetes 管理。一路走来，Rancher 积累了大量用户，一直是全球使用人数最多的容器云管理平台，它将始终致力于帮助用户管理任意位置的 Kubernetes 集群，实现无处不在的计算。

在此过程中，我们也在不断总结用户的需求和痛点，围绕 Kubernetes 推出了很多开源产品，如存储产品 Longhorn，边缘计算产品 K3s 和 Elemental，持续交付产品 Fleet，超融合产品 Harvester，个人使用产品 Rancher Desktop，安全产品 NeuVector。此外，我们仍在不断孵化新产品，如 CICD 产品 EPINIO，AiOps 产品 OPNI，旨在帮助用户解决更多问题，通过 Rancher 更轻松地设计和构建自己的云原生平台。