秒云容器云平台：一站式云原生PaaS平台

本篇文章开始之前，我们以目前室内装修里比较流行的2种方式做对比，来讲一下所谓的“半包”和“全包”的区别。简单讲半包和全包的差别其实就是辅材和主材由谁提供的问题。辅材包括：水泥、沙子、红砖、水管、电线等等。主材包括：瓷砖、地板、橱柜、洁具等。

半包方式：施工方负责施工和辅材的采购，主材由业主采购。

全包方式：所有材料采购和施工都由施工方负责。

半包的优点是主材由业主自己采购，可以控制费用，或者能挑选到自己中意而装修公司没有的主材。缺点是所有主材必须业主自己亲力亲为的一项一项选购，比如今天买个门，浴室柜，明天再买个橱柜，还要再跟装修师傅约定好安装时间，这边约定好了时间后主材那边迟迟不送，可能会延误工期。

全包也叫一站式装修，对于业主来说是最省心的一种装修方式，装修公司包工包料，所有材料都由装修公司负责，装修公司跟各大主材提供商合作，业主只需要去一次展厅确定自己所选的材料即可，并且后续的售后也是由装修公司直接和各主材提供商对接，业主当甩手掌柜即可。全包唯一的缺点是业主只能在装修公司合作的主材提供商那里挑选材料，可选的材料品牌和型号有限。不过现在比较大的装修公司合作的厂商基本都是市面上主流的，基本和业主自己去建材市场看到的品牌是一样的。所以综合看下来，全包的装修方式利大于弊。

从上面两种方式可以看出，全包目前作为主流的室内装修解决方案，既为业主在装修前选购主材时省时、省心，也为业主在装修后出现售后问题处理时省事、省力，提供一站式装修解决方案。

回到我们今天的主题，当各行各业的客户进行数字化转型的过程中，期望通过以容器、Kubernetes、微服务、DevOps等云原生技术打造现代化的IT基础设施，享受云原生带来的红利，以实现敏捷、高效、可扩展、高性能的IT架构，支撑业务的快速迭代和敏捷交付，提升市场竞争力。

Gartner 在2019年的容器报告中预测，到 2020 年将有 50%的传统老旧应用被以云原生化的方式改造，到 2022 年将有 75%的全球化企业将在生产中使用云原生的容器化应用。

IDC也给出了预测：2023年，90%的企业应用将通过云原生来部署。

Kubernetes作为云原生操作系统，也是云原生落地过程中最基础的支撑平台，为容器化应用的编排和调度以及运行支撑提供了完善的解决方案。

但是Kubernetes在企业落地的过程中，却给用户带来了各种各样的问题。首先是K8s的部署，早期的部署方式，完全是基于二进制文件部署的，没有一定的技术积累和多次试错的话，基本上是不可能成功的。当时开源社区也广泛流传着《10 Most Common Reasons Kubernetes Deployments Fail》这样的文章，可见早期部署K8s的门槛还是非常高的。后来为了优化和解决开源K8s的部署问题，社区也出现了像kubeadm、minikube、kubespray...这样的开源工具，虽然这些工具显著的提升了部署K8s的效率，但它们大多是通过Linux命令行工具操作的，所以也带来了相关操作命令的学习成本，一个企业的IT运维人员不可能只维护K8s这一套管理平台的。

其次，关于K8s的使用和运维，K8s官方提供两种手段，是一个基于命令的CLI工具：kubectl，另一个是GUI的Dashboard。kubectl是最主要的使用方式，通过命令行与K8s集群的API Server进行交互，完成包括集群管理、节点管理、工作负载管理、用户认证管理等共8个类别的操作，上一张图先来感受下kubectl的丰富命令。

这其中有些简单的资源对象可以通过K8s命令kubectl run/create直接创建，大部分的K8s资源对象，都是需要用户自己编写YAML文件，然后通过kubectl create/apply命令来完成创建。YAML是一个纯文本的标记语言，语法相对比较复杂，一个相对完善的K8s工作负载的YAML，可达成百甚至是上千行内容，对于企业IT运维人员来讲，一时半会也难以理解和上手，学习曲线非常高。再说K8s Dashboard，它本身是一个辅助性的Web GUI，也是通过kubectl创建而来，通过Web界面提供了一些简单的工作负载创建操作，但是只能作为入门使用，完全无法满足IT运维人员日常的需求。

第三，我们从Kubernetes官方的定义“Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.” 可以看出，它的核心功能是针对容器化应用的自动化部署、扩展和管理的系统，简单讲就是一个容器编排调度系统，其余的运维工作还得由用户自己考虑实现方案，好在CNCF基金会为云原生的技术普及和发展提供了强大的生态支持，我们从它的云原生全景图来感受下：

有了这全景图，算是减轻了用户一部分技术调研和组件选择的问题，基本上只要从这个里面选择即可，但是这些组件如何采用及落地，还是得用户自己研究。

我们简单的从一个容器化应用的完整生命周期管理来看，它包括：构建、推送、编排、调度、拉取、运行、支撑、运维等这几个主要阶段。K8s只是完成了其中的编排、调度、拉取、运行、支撑的工作。结合我们文章开篇讲的房屋装修，它其实只是完成了装修过程中的“半包”工作。那它没有完成的阶段，我们来看下用户要如何去做：

构建：主要讲的是构建镜像，构建镜像一般是通过编写Dockerfile来完成，它的语法学习门槛基本上和YAML是如出一辙的。

推送：构建好的镜像，要推送到镜像仓库，比如Harbor或者Docker Registry，用户需要提前准备好这么一个镜像仓库，并且独立的来运维这个镜像仓库，Harbor和Docker Registry都有自己的Web管理平台。

运维：这个范畴是比较大的，我们主要从容器应用可观测性的角度上来看，可观测性主要由三部分构成：“指标（Metric）”、“日志（Logging）”、“链路（Tracing）”，这其中的每一部分，在CNCF LandScape上都有相应的解决方案。

• 指标（Metric），就是我们常说的资源监控和性能监控，针对平台、集群、主机以及容器应用的各种指标（如CPU、内存、磁盘、应用自定义指标）进行实时监控和告警。目前社区主流的解决方案是“Prometheus + Grafana”，Prometheus对指标采集，并实时监控和告警，Grafana使用Prometheus作为数据源，提供一个Web管理平台来创建监控图表并作展示。

• 日志（Logging），针对容器应用的日志统一采集、集中查看与检索，包括容器的标准输出&标准错误，文件型日志（如/var/log/xxx.log）。目前社区主流的解决方案是ELK/EFK（Elasticsearch + Logstash/Fluentd + Kibana），实现日志数据的采集、索引、搜索以及可视化。可视化通过Kibana提供的Web管理平台实现。

• 链路（Tracing），主要是面向Service Mesh场景，针对微服务架构下的，服务之间的流量拓扑和调用链跟踪，为故障排查提供有效的定位手段。目前社区主流的解决方案是Istio + Kiali+ Jaeger，Kiali作为Istio的Web Dashboard，提供一个可视化的方式对流量进行监控，如应用拓扑查看。Jaeger提供一个可视化端到端的调用链跟踪及查看。

看完上述应用生命周期几个阶段要单独引入的开源组件，先不管如何部署和配置，仅仅看到有那么多独立的管理平台，恐怕用户已经望而却步了，别急... 还没完，云原生基础架构里关于微服务和DevOps的部分还没怎么提及，微服务我们主要讲治理部分，目前社区主流的解决方案是基于Istio服务网格来实现，也是实现上述链路追踪的基础。DevOps（开发运维一体化），是思想、方法论加工具集的组合，工具集我们主要讲 CI/CD（持续集成/持续部署）工具，主要实现应用的自动化编译、测试及部署等流程，那么用户得利用现有GitLab仓库里的GitLab CI功能或者是单独部署一套Jenkins/JenkinsX或是其它主流持续集成工具。

围绕Kubernetes的云原生体系开源项目实在太丰富了，这里不再一一叙述。最后再多提一个问题。当我们在生产环境部署Kubernetes时，通常为了保证隔离性和可靠性，会考虑部署多个集群或者跨多个区域部署，这样的话，上述的维护工作量可能要加倍，还不包括后续对于集群的升级、安全管控、数据备份等操作... 试想下，当你同时需要管理Kubernetes，Prometheus，EFK，Jenkins、Istio等工具，你就需要单独登录各自的Web管理界面，如此多的操作界面，界面操作复杂，功能逻辑不易理解，展示风格不统一，一定会让人抓狂。

秒云容器云平台，应“运”而生

秒云，核心目标是让用户“一秒入云”，秒云产品团队积累了近十年的云计算产品开发及运维经验，深刻理解用户在使用云原生开源组件的各种痛点，本着“让容器使用更简单”的产品理念，把数十种“不简单”的开源组件以“可插拔式”的方式有机集成，深度整合，以应用为中心，最大化的屏蔽底层技术细节，研发出的企业级秒云容器云平台产品，给用户提供简单易用、所见即所得、一致性用户体验的管理平台，极大的降低用户学习和使用K8s和各种开源组件的技术门槛，真正做到平台开箱即用，组件即插即用。

来先一起看下秒云容器云平台的整体技术栈吧。

通过其上罗列的近30+核心开源组件列表，构建了秒云容器云平台产品完整的技术栈，也使秒云容器云平台成为以DevOps为理念,面向微服务应用的云原生PaaS平台，其特点主要体现以下几个方面：

• 全生命周期的云原生应用管理平台

基于Docker和双编排引擎（Kubernetes+Swarm）构建的容器平台，提供界面化的Linux和Windows应用统一编排以及兼容原生的K8s YAML编排，面向云原生应用的快速交付与管理，并提供全生命周期的看护与运行支撑。 结合CI/CD和微服务治理（Service Mesh）功能，提升应用的持续迭代、流量监控和治理能力。

• 所见即所得的CI/CD流水线编排

秒云容器云平台深度集成Jenkins，支持可视化的流水线编排，平台内置近10种开发语言的流水线模板，20+现成的可选步骤，可灵活定义应用交付链的每个环节，方便用户快速构建产品从代码编译、镜像构建、集成测试、环境部署等全自动化的敏捷交付流程。

• 全链路可视化的微服务治理

秒云容器云平台深度集成 Istio服务网络，提供开箱即用、可视化、无侵入式的微服务治理方案，让应用的升级发布策略更灵活，流量治理更智能，涵盖灰度发布、流量治理、流量监控、链路追踪等多种服务治理功能。

• 企业级应用市场

集成企业常见的开发语言、操作系统、数据库与缓存、持续集成、分布式存储、网盘等应用，面向生产环境，满足可用性、监控、性能、扩展、版本管理等需求，支持一键部署、升级及运维，并与Helm无缝集成，获取社区海量应用。

    除此之外，秒云容器云平台还具备以下特点：

• 真正意义上的多租户模型

基于“三级的操作视角、二级资源分配”多租户管理模型，平台管理员只需创建租户并为租户分配相应集群资源，后续租户下所有的资源管理都有租户管理员来完成，平台管理员无需干预。租户间用户体系完全独立，应用、网络等资源相互隔离。租户管理员可通过在租户内创建项目，并为项目分配资源以及管理项目用户来实现资源的二次分配，实现真正意义上的自治管理。

• 混合多集群及外部集群统一管理

支持本地化的Kubernetes和Docker Swarm混合多集群编排，一个集群关联一个编排引擎，并支持直接纳管外部已有Kubernetes集群，满足企业对于多环境及统一管理的需求，帮助企业更全面的覆盖不同的应用场景。

• 平台及应用全面的可观测能力

平台内置了丰富的运维工具来提升平台及应用的可观测性，包括多维度的监控告警、容器日志集中查看、应用拓扑查看及链路追踪；同时秒云自有的日志分析系统产品可与秒云容器云平台无缝对接，本身也是作为一个场景化应用构建于秒云的容器底座之上，实现云原生场景下的应用实时日志统一采集、泛化、检索与可视化，方便应用出现问题时进行故障排查及调用链跟踪，提升云原生应用的整体运维能力。

• Windows原生容器支持

通过把Kubernetes的所有优势引入Windows，提供原生Windows容器支持，极大降低了企业使用Windows容器的复杂性，并为基于Windows传统应用程序的现代化提供快捷的途径。

秒云容器云平台也是国内率先深度整合Windows Container的容器云平台厂商之一。

• 虚拟机&容器统一管理

针对无法直接容器化的应用，秒云容器云平台支持统一管理和调度容器和虚拟机，允许在一个Kubernetes集群内同时调度并运行容器和虚拟机，提供一致性的体验，来消除云原生应用和传统应用之间的壁垒，为传统应用向云原生应用改造迁移提供逐步进阶的选择。

• 集群共享GPU调度

支持容器可按一对一，多对一，按显存或按百分比共享1个或多个GPU，从而实现集群共享GPU调度，同时还支持将GPU资源与多租户资源的分配模型相结合。

• 统一运维中心平台

运维中心平台是秒云管理平台之上的一个运维平台，可以统一管理分散部署的秒云容器平台，并实现应用的统一发布，以及统一的监控和运维，给企业带来的价值是大大降低了运维支持的成本。

一图总结秒云容器云平台简单易用的特点

秒云，让容器使用更简单

秒云容器云平台作为企业级开箱即用的平台，实现了真正意义上的“一站式”云原生PaaS平台，并把秒云容器云平台“让容器使用更简单”的理念贯彻到底，让这个“简单”的平台赋予不同角色人群“不简单”的价值。

打造“首个信创容器云平台”

在信创领域，秒云系列产品从2019年开始陆续与兆芯、海光、鲲鹏、飞腾等国产芯片，以及中标麒麟、银河麒麟、统信UOS、深度操作系统等国产操作系统完成兼容性互认证，同时也是国内首家支持申威处理器的容器云平台。作为国产化软硬件适配最多最全的容器云平台，全面应对信创行业云原生业务场景，支持用户对原有业务系统进行轻量化改造并实现快速部署上云和灵活调度需求。

    关于近期“Kubernetes宣布后续不再支持Docker”的解释说明

在当前Kubernetes版本，kubelet使用dockershim实现对Docker的CRI支持，由于Docker本身并不支持CRI（容器运行时接口）这一Kubernets运行时接口，所以一直以来使用的其实是dockershim这一桥接服务，通过dockershim转换Docker API与CRI。为了允许不同的运行时的顺畅互操作性，后续Kubernetes 1.20版本以后将不再提供Dockershim这项桥接服务，同时也意味着在未来的Kubernetes环境中，Docker的占比将逐渐下降。

对于普通用户来说，并没有多大的差距。使用Docker工具构建的容器镜像仍能在Kubernetes上正常运行，现阶段已经运行在Kubernetes环境中的Docker镜像也不会受到影响。在Dockershim被弃用之后，如果考虑使用CRI运行时，可以使用CRI-O、containerd等运行时。

秒云产品团队也将在后续的产品版本演进过程中，同步这一变更，同时为用户提供平滑的过渡方案以及专业的技术支持。

如何获取秒云容器云平台

访问https://miaoyun.io/download.html，即可获取秒云容器云平台离线安装包，可支持部署在公有云的云主机、私有云的虚拟机以及物理机上，一条命令即可安装体验秒云一站式企业级容器云平台。