作者：Kubernetes v1.27 发布团队^[1]

宣布发布 Kubernetes v1.27，这是 2023 年的第一个版本！

此版本包含 60 个增强功能。其中 18 个增强功能进入 Alpha 阶段，29 个进入 Beta 阶段，13 个进入 Stable 阶段。

版本主题和标志

Kubernetes v1.27：Chill Vibes

Kubernetes v1.27 的主题是 Chill Vibes。

这有点儿傻，但在这个版本中，有一些重要的变化激发了这个主题。在 Kubernetes 版本发布周期中，有几个截止日期需要满足才能保留功能。如果某个功能错过了任何一个截止日期，它可以通过例外流程进行。处理这些例外是版本发布的一个非常正常的部分。但是 v1.27 是第一个版本，任何人都记不起来在增强功能冻结之后我们没有收到任何例外请求。即使在版本发布过程中，事情比我们以往习惯的要平静得多。

我们能够享受到这样一个更加平静的版本发布，有一个特定的原因，那就是人们在幕后投入了大量工作来改善我们如何管理版本发布。这就是这个主题庆祝的内容，人们为社区做出了改进。

特别感谢 Britnee Laverack^[2] 设计了这个标志。Britnee 还设计了 Kubernetes 1.24: Stargazer^[3] 的标志。

新特性（主要主题）

冻结 k8s.gcr.io 镜像仓库

用 GA 了数月的 registry.k8s.io 替换旧的镜像仓库 k8s.gcr.io。Kubernetes 项目创建并运行 registry.k8s.io 镜像仓库，完全由社区控制。这意味着旧的镜像仓库 k8s.gcr.io 将被冻结，将不再发布 Kubernetes 和相关子项目的更多镜像。

这个改变对贡献者意味着什么？

• 如果你是子项目的维护者，你需要更新你的清单和 Helm chart 以使用新的镜像仓库。欲了解更多信息，请查看此项目^[4]。

这个改变对最终用户意味着什么？

• Kubernetes v1.27 发布将不会发布到 k8s.gcr.io 镜像仓库。
• v1.24、v1.25 和 v1.26 的补丁版本将在四月后不再发布到旧的镜像仓库。
• 从 v1.25 开始，将默认镜像仓库设置为 registry.k8s.io。这个值可以在 kubeadm 和 kubelet 中进行重写，但如果将其设置为 k8s.gcr.io，由于新版本不会出现在旧的镜像仓库中，新版本将无法使用旧的镜像仓库。
• 如果你想提高集群的可靠性，并消除对社区拥有的镜像仓库的依赖，或者在限制外部流量的网络中运行 Kubernetes，你应该考虑托管本地镜像仓库镜像。一些云供应商可能会为此提供托管解决方案。

SeccompDefault 升级为稳定版

要使用 seccomp profile defaulting，你必须为要使用它的每个节点启用 –seccomp-default 命令行标志^[5]运行 kubelet。如果启用，kubelet 将默认使用 RuntimeDefault seccomp profile，它由容器运行时定义，而不是使用 Unconfined 模式（seccomp disabled）。默认配置旨在提供一组强大的安全默认值，同时保留工作负载的功能。容器运行时和它们的发布版本之间的默认配置可能不同。

你可以在相关的 Kubernetes Enhancement Proposal (KEP) 中找到有关升级和降级策略的详细信息：Enable seccomp by default^[6]。

可变作业调度指令（Mutable scheduling directives for Jobs）升级为 GA

这个特性在 v1.22 中引入，开始是一个 beta 级别，现在已经稳定了。在大多数情况下，一个并行作业将希望以约束条件运行 pod，比如所有 pod 都在同一个区域，或者只在 GPU 模型 x 或 y 上运行，而不是混合使用。suspend 字段是实现这些语义的第一步。suspend 允许自定义队列控制器决定何时启动作业。但是，一旦作业被取消暂停，自定义队列控制器就无法影响作业的 pod 实际着陆位置。

此功能允许在作业启动前更新作业的调度指令，这使得自定义队列控制器能够影响 pod 的放置位置，同时将实际的 pod-to-node 分配卸载到 kube-scheduler 上。这仅允许在从未取消暂停的挂起作业中更新。可以更新的作业的 pod 模板中的字段是节点亲和性、节点选择器、容忍性、标签、注释和调度门^[7]。在 KEP: Allow updating scheduling directives of jobs^[8] 中找到更多详细信息。

DownwardAPIHugePages 升级为稳定版

在 Kubernetes v1.20 中，downward API^[9] 添加了对 requests.hugepages-和 limits.hugepages-的支持，以保持与其他资源（如 CPU、内存和临时存储）的一致性。此功能在此版本中升级为稳定版本。在 KEP: Downward API HugePages^[10] 中可以找到更多详细信息。

Pod 调度可用性进入 beta 阶段

在创建时，Pod 已准备好进行调度。Kubernetes 调度程序会尽力找到节点以放置所有待定的 Pod。然而，在实际情况中，一些 Pod 可能会长时间处于缺少必要资源（missing-essential-resources）的状态。这些 Pod 实际上会以不必要的方式使调度程序（以及下游集成器，如 Cluster Autoscaler）繁忙。

通过指定/移除 Pod 的 .spec.schedulingGates，可以控制何时将 Pod 视为可调度。

schedulingGates 字段包含一个字符串列表，每个字符串字面量被视为在将 Pod 视为可调度之前必须满足的条件。这个字段只能在创建 Pod 时初始化（由客户端创建或在准入期间改变）。创建后，可以以任意顺序移除每个 schedulingGate，但不允许添加新的 scheduling gate。

通过 Kubernetes API 访问节点日志

此功能可以帮助集群管理员通过允许查询服务日志来调试运行在节点上的服务的问题。要使用此功能，请确保在该节点上启用了 NodeLogQuery 特性门^[11]，而且 kubelet 配置选项 enableSystemLogHandler 和 enableSystemLogQuery 都设置为 true。在 Linux 上，我们假设服务日志可通过 journald 获取。在 Windows 上，我们假设服务日志可在应用程序日志提供程序中获取。在 Linux 和 Windows 上，你还可以分别从 /var/log/ 和 C：\var\log 目录获取日志。

集群管理员可以在整个集群或其子集上尝试此 alpha 版本特性。

ReadWriteOncePod 持久卷访问模式进入 beta 阶段

Kubernetes v1.22 引入了一种名为 ReadWriteOncePod 的持久卷^[12]（PV）和持久卷声明^[13]（PVC）的新访问模式。此访问模式使你可以将卷访问限制为群集中的单个 Pod，确保只有一个 Pod 可以同时向卷写入。这对于需要单写者访问存储的有状态工作负载特别有用。

ReadWriteOncePod beta 版本增加了对使用 ReadWriteOncePod PVC 的 Pod 进行调度程序抢占^[14]的支持。调度程序抢占允许高优先级的 Pod 抢占低优先级的 Pod。例如，当调度一个使用 ReadWriteOncePod PVC 的 Pod A 时，如果发现另一个使用相同 PVC 的 Pod B 并且 Pod A 的优先级更高，则调度程序将返回一个 Unschedulable 状态，并尝试抢占 Pod B。有关更多背景，请参见 KEP: ReadWriteOncePod PersistentVolume AccessMode^[15]。

在滚动升级后遵守 PodTopologySpread

matchLabelKeys 是用于选择用于计算扩展的 Pod 的一组 Pod 标签键列表。这些键用于从 Pod 标签中查找值。这些键值标签与 labelSelector 进行 AND 运算，以选择用于计算传入 Pod 的扩展的现有 Pod 组。在 Pod 标签中不存在的键将被忽略。空列表表示只针对 labelSelector 进行匹配。

使用 matchLabelKeys，用户不需要在不同的修订版本之间更新 pod.spec。控制器/操作器只需为不同的修订版本设置相同标签键的不同值。调度程序将根据 matchLabelKeys 自动假定这些值。例如，如果用户使用 Deployment，则可以使用 pod-template-hash 键控制，它由 Deployment 控制器自动添加，以区分单个 Deployment 中的不同修订版本。

使用挂载加速 SELinux 卷标记

在此版本中，如何将 SELinux 标签应用于 Pod 使用的卷升级为 beta 版本。此功能通过使用正确的 SELinux 标签挂载卷而不是递归更改每个卷上的文件来加速容器启动。带有 SELinux 支持的 Linux 内核允许卷的第一次挂载使用 -o context= 挂载选项设置整个卷上的 SELinux 标签。这样，所有文件将在固定时间内分配给给定标签，而无需递归遍历整个卷。

context 挂载选项无法应用于 bind 挂载或已挂载卷的重新挂载。对于 CSI 存储，CSI 驱动程序执行卷的第一次挂载，因此必须是 CSI 驱动程序实际应用此挂载选项。我们在 CSIDriver 对象中添加了一个新字段 SELinuxMount，以便驱动程序可以宣布它们是否支持 -o context 挂载选项。

如果 Kubernetes 知道 Pod 的 SELinux 标签以及负责 Pod 卷的 CSI 驱动程序宣布 SELinuxMount：true，并且该卷具有 Access Mode ReadWriteOncePod，则它将要求 CSI 驱动程序使用 mount 选项 context= 挂载卷，并告诉容器运行时不要重新标记卷的内容（因为所有文件已经具有正确的标签）。从 KEP: Speed up SELinux volume relabeling using mounts^[16] 中获取更多信息。

稳健的 VolumeManager 重构进入 beta 阶段

这是卷管理器重构，它允许 kubelet 在 kubelet 启动期间填充有关现有卷如何挂载的其他信息。一般来说，这使卷清理更加健壮。如果在节点上启用了 NewVolumeManagerReconstruction 特性门，则在 kubelet 启动期间将获得有关已挂载卷的增强发现。

在 Kubernetes v1.25 之前，kubelet 在 kubelet 启动期间使用不同的默认行为来发现已挂载的卷。如果禁用此特性门（默认情况下启用），则选择传统的发现行为。

在 Kubernetes v1.25 和 v1.26 中，此行为切换是 SELinuxMountReadWriteOncePod 特性门的一部分。

可变 Pod 调度指令进入 beta 阶段

这允许在调度准备就绪门被阻止的 Pod 上使用更受限制的节点亲和性/选择器进行改变。它使得在允许调度之前改变 Pod 的调度指令成为可能，并使外部资源控制器能够影响 Pod 的放置，同时将实际的 Pod 到节点分配卸载给 kube-scheduler。

这为在 Kubernetes 中添加调度功能打开了一扇新的大门。具体来说，构建轻量级调度程序来实现 kube-scheduler 不支持的功能，同时依赖于现有的 kube-scheduler 来支持所有上游功能并处理 Pod 到节点的绑定。如果自定义功能不需要实现调度程序插件——这需要重新构建和维护自定义 kube-scheduler 二进制文件——则应首选此模式，

Kubernetes v1.27 中的特性升级和弃用

升级为稳定版

此版本包括共计 9 个增强功能升级为稳定版：

• kubectl 使用的默认容器注释^[17]
• CronJob 中的时区支持^[18]
• 暴露有关资源请求和限制的指标，表示 Pod 模型^[19]
• 服务器端未知字段验证^[20]
• 节点拓扑管理器^[21]
• 向 Pod.Spec.Container.{Liveness,Readiness,Startup} 探针添加 gRPC 探测^[22]
• 向探针添加可配置的优雅期^[23]
• OpenAPI v3^[24]
• 使用支持的 Go 版本^[25]

弃用和移除

此版本有多项移除：

• 从 CSIStorageCapacity 中移除 storage.k8s.io/v1beta1^[26]
• 移除对弃用的 seccomp 注释的支持^[27]
• 移除 –master-service-namespace 命令行参数^[28]
• 移除 ControllerManagerLeaderMigration 特性门^[29]
• 移除 –enable-taint-manager 命令行参数^[30]
• 移除 –pod-eviction-timeout 命令行参数^[31]
• 移除 CSI 迁移特性门^[32]
• 移除 CSIInlineVolume 特性门^[33]
• 移除 EphemeralContainers 特性门^[34]
• 移除 LocalStorageCapacityIsolation 特性门^[35]
• 移除 NetworkPolicyEndPort 特性门^[36]
• 移除 StatefulSetMinReadySeconds 特性门^[37]
• 移除 IdentifyPodOS 特性门^[38]
• 移除 DaemonSetUpdateSurge 特性门^[39]

版本说明

有关 Kubernetes v1.27 的完整详细信息，请参阅我们的版本说明^[40]。

下载

Kubernetes v1.27 可在 GitHub^[41] 上下载。要开始使用 Kubernetes，你可以使用 minikube^[42]、kind^[43] 等本地 Kubernetes 集群。你还可以使用 kubeadm^[44] 轻松安装 v1.27。

发行团队

Kubernetes 只有在其社区的支持、承诺和辛勤工作下才能实现。每个发行团队都由专注的社区志愿者组成，他们一起构建组成 Kubernetes 版本的许多部分。这需要来自社区各个角落的具有专业技能的人员，从代码本身到其文档和项目管理。

特别感谢我们的发行主管 Xander Grzywinski，他引导我们顺利而成功地完成了发行周期，并感谢发行团队的所有成员互相支持并为社区生产 v1.27 版本而努力工作。

生态系统更新

• 2023 年欧洲 KubeCon + CloudNativeCon 将于 2023 年 4 月 17 日至 21 日在荷兰阿姆斯特丹举行！你可以在活动网站^[45]上找到有关会议和注册的更多信息。
• cdCon + GitOpsCon 将于 2023 年 5 月 8 日至 9 日在加拿大温哥华举行！有关会议和注册的更多信息，请访问活动网站^[46]。

项目速度

CNCF K8s DevStats^[47] 项目聚合了许多与 Kubernetes 和各种子项目的速度相关的有趣数据点。这包括从个人贡献到贡献的公司数量，是对投入到发展这个生态系统的广度和深度的说明。

在为期 14 周^[48]的 v1.27 发布周期（1 月 9 日至 4 月 11 日）中，我们看到了来自 1020 家公司^[49]和 1603 个个人^[50]的贡献。

即将到来的版本网络研讨会

加入 Kubernetes v1.27 发布团队的成员，于 2023 年 4 月 14 日星期五上午 10 点 PDT，了解本次发布的主要功能，以及弃用和移除情况，帮助计划升级。有关更多信息和注册，请访问 CNCF Online Program 网站上的活动页面^[51]。

参与其中

参与 Kubernetes 最简单的方法是加入与你感兴趣的特别兴趣小组^[52]（SIG）。

你有想要广播给 Kubernetes 社区的内容吗？在我们的每周社区会议^[53]上分享你的声音，并通过以下渠道：

• 在 Kubernetes 贡献者网站^[54]上了解更多有关为 Kubernetes 做出贡献的信息。
• 在 Twitter 上关注我们的最新动态 @Kubernetesio^[55]。
• 在 Discuss^[56] 上加入社区讨论。
• 加入 Slack^[57] 社区。
• 在 Server Fault^[58] 上发布问题（或回答问题）。
• 分享^[59]你的 Kubernetes 故事。
• 在博客^[60]上了解有关 Kubernetes 的更多信息。
• 了解有关 Kubernetes 发布团队^[61]的更多信息。

参考资料

[1]Kubernetes v1.27 发布团队: https://github.com/kubernetes/sig-release/blob/master/releases/release-1.27/release-team.md

[2]Britnee Laverack: https://www.instagram.com/artsyfie/

[3]Kubernetes 1.24: Stargazer: https://kubernetes.io/blog/2022/05/03/kubernetes-1-24-release-announcement/#release-theme-and-logo

[4]项目: https://github.com/kubernetes-sigs/community-images

[5]命令行标志: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet

[6]Enable seccomp by default: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2413-seccomp-by-default

[7]调度门: https://kubernetes.io/docs/concepts/scheduling-eviction/pod-scheduling-readiness/

[8]Allow updating scheduling directives of jobs: https://github.com/kubernetes/enhancements/tree/master/keps/sig-scheduling/2926-job-mutable-scheduling-directives

[9]downward API: https://kubernetes.io/docs/concepts/workloads/pods/downward-api/

[10]Downward API HugePages: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2053-downward-api-hugepages

[11]特性门: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/

[12]持久卷: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistent-volumes

[13]持久卷声明: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims

[14]调度程序抢占: https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/

[15]ReadWriteOncePod PersistentVolume AccessMode: https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2485-read-write-once-pod-pv-access-mode

[16]Speed up SELinux volume relabeling using mounts: https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/1710-selinux-relabeling

[17]kubectl 使用的默认容器注释: https://github.com/kubernetes/enhancements/issues/2227

[18]CronJob 中的时区支持: https://github.com/kubernetes/enhancements/issues/3140

[19]暴露有关资源请求和限制的指标，表示 Pod 模型: https://github.com/kubernetes/enhancements/issues/1748

[20]服务器端未知字段验证: https://github.com/kubernetes/enhancements/issues/2885

[21]节点拓扑管理器: https://github.com/kubernetes/enhancements/issues/693

[22]向 Pod.Spec.Container.{Liveness,Readiness,Startup} 探针添加 gRPC 探测: https://github.com/kubernetes/enhancements/issues/2727

[23]向探针添加可配置的优雅期: https://github.com/kubernetes/enhancements/issues/2238

[24]OpenAPI v3: https://github.com/kubernetes/enhancements/issues/2896

[25]使用支持的 Go 版本: https://github.com/kubernetes/enhancements/issues/3744

[26]从 CSIStorageCapacity 中移除 storage.k8s.io/v1beta1: https://github.com/kubernetes/kubernetes/pull/108445

[27]移除对弃用的 seccomp 注释的支持: https://github.com/kubernetes/kubernetes/pull/114947

[28]移除 –master-service-namespace 命令行参数: https://github.com/kubernetes/kubernetes/pull/112797

[29]移除 ControllerManagerLeaderMigration 特性门: https://github.com/kubernetes/kubernetes/pull/113534

[30]移除 –enable-taint-manager 命令行参数: https://github.com/kubernetes/kubernetes/pull/111411

[31]移除 –pod-eviction-timeout 命令行参数: https://github.com/kubernetes/kubernetes/pull/113710

[32]移除 CSI 迁移特性门: https://github.com/kubernetes/kubernetes/pull/110410

[33]移除 CSIInlineVolume 特性门: https://github.com/kubernetes/kubernetes/pull/111258

[34]移除 EphemeralContainers 特性门: https://github.com/kubernetes/kubernetes/pull/111402

[35]移除 LocalStorageCapacityIsolation 特性门: https://github.com/kubernetes/kubernetes/pull/111513

[36]移除 NetworkPolicyEndPort 特性门: https://github.com/kubernetes/kubernetes/pull/110868

[37]移除 StatefulSetMinReadySeconds 特性门: https://github.com/kubernetes/kubernetes/pull/110896

[38]移除 IdentifyPodOS 特性门: https://github.com/kubernetes/kubernetes/pull/111229

[39]移除 DaemonSetUpdateSurge 特性门: https://github.com/kubernetes/kubernetes/pull/111194

[40]版本说明: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.27.md

[41]GitHub: https://github.com/kubernetes/kubernetes/releases/tag/v1.27.0

[42]minikube: https://minikube.sigs.k8s.io/docs/

[43]kind: https://kind.sigs.k8s.io/

[44]kubeadm: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

[45]活动网站: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/

[46]活动网站: https://events.linuxfoundation.org/cdcon-gitopscon/

[47]CNCF K8s DevStats: https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1&refresh=15m

[48]为期 14 周: https://github.com/kubernetes/sig-release/tree/master/releases/release-1.27

[49]1020 家公司: https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=v1.26.0%20-%20now&var-metric=contributions

[50]1603 个个人: https://k8s.devstats.cncf.io/d/66/developer-activity-counts-by-companies?orgId=1&var-period_name=v1.26.0%20-%20now&var-metric=contributions&var-repogroup_name=Kubernetes&var-repo_name=kubernetes%2Fkubernetes&var-country_name=All&var-companies=All

[51]活动页面: https://community.cncf.io/events/details/cncf-cncf-online-programs-presents-cncf-live-webinar-kubernetes-v127-release/

[52]特别兴趣小组: https://github.com/kubernetes/community/blob/master/sig-list.md

[53]社区会议: https://github.com/kubernetes/community/tree/master/communication

[54]Kubernetes 贡献者网站: https://www.kubernetes.dev/

[55]@Kubernetesio: https://twitter.com/kubernetesio

[56]Discuss: https://discuss.kubernetes.io/

[57]Slack: https://communityinviter.com/apps/kubernetes/community

[58]Server Fault: https://serverfault.com/questions/tagged/kubernetes

[59]分享: https://docs.google.com/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform

[60]博客: https://kubernetes.io/blog/

[61]Kubernetes 发布团队: https://github.com/kubernetes/sig-release/tree/master/release-team

数字经济时代以数字技术和互联网为基础，以数据为核心，具有智能化特征的一种新形态。

然而，不少企业发现自己面对的是一个充满挑战的局面：一方面是数据爆炸性增长带来的存储压力，根据IDC的预测，2025年全球数据总量将达到180ZB，是2018年（33ZB）的5.4倍；另一方面，数据安全也面临非常严峻的挑战，Gartner预测,到2025年75%的组织将面临一种或多种勒索软件的威胁。

面对数字化经济所带来的挑战，亚马逊云科技坚持创新，不断丰富存储服务的功能和类型，如亚马逊云科技的Amazon S3等，以及分布式文件系统，如Hadoop的HDFS等。同时在数据保护和合规上持续改进，以帮助客户更有效地构建起云上安全环境及满足合规要求，为其业务保驾护航。

丰富的存储服务，满足不同业务需求

众所周知，存储与计算、网络一起共同构成了传统数据中心的三大基础能力，在云时代同样如此，存储也是公有云的核心基础服务。

实际上，公有云市场大幕正是从云存储服务开启的。2006年3月14日亚马逊云科技推出了自己的第一项云服务Amazon S3，这也是世界上首个公有云的云存储服务。

如今，Amazon S3的服务类型已经达到8种，存储的对象数量超过230万亿个，平均每秒有超过1亿次请求。已经成为对象存储的事实标准。亚马逊云科技的存储服务也从最初的Amazon S3，扩展到包括块存储、文件存储、数据库服务等在内的多种数据存储服务。Amazon S3还是成百上千个数据湖的基础。

为了致敬Amazon S3，亚马逊云科技会在每年的3月14日这一天举办Pi day活动，纪念S3服务的诞生。这一天，亚马逊云科技的专家会在Twitch上举办长达4个小时的教学和培训，不仅有关于Amazon S3的最佳实践，还有Amazon在数据服务方面的最新创新。

除了不断丰富存储类型之外，亚马逊云一直通过创新降低数据的存储成本，其中的Amazon S3智能分层服务尤为值得一提。

一般而言，数据存储的费用与访问频度和性能相关，读得越频繁、读取性能要求越高，费用就越高。亚马逊云科技Amazon S3的不同存储服务分别对应不同的访问频度和不同性能要求，但客户有时候很难确定到底该选择哪一种（不知道或者难以预测）。Amazon S3智能分层就为解决这个问题推出的创新服务。

2018年推出的这项可根据访问频次自动将数据移动到最经济的访问层，在保证性能的同时不会产生额外的检索费用或运营开销。比如，如果客户将每年仅访问几次的数据从Amazon S3 Standard-IA迁移到Amazon S3 Glacier Instant Retrieval，就可节省高达近70%的存储成本。鉴于Amazon S3智能分层广受欢迎，如今亚马逊云科技还将它从Amazon S3扩展至云原生文件存储Amazon EFS。从该服务推出以来，已经为客户节省了超过2.5亿美元的存储成本。

除了Amazon S3智能分层服务外，亚马逊云科技还提供多种技术手段来监控并确保实际成本在预算之内。比如，可通过亚马逊云科技Budgets设定预算，在花费超过预算或者预测会超过预算时预警；可通过Amazon CloudWatch监控每日的存储用量和每分钟的数据访问请求，或者根据数据访问请求设定预警值。正是得益于这些创新，17年来亚马逊云科技将存储成本平均降低了70%，为全球客户累计节约了超过10亿美金的支出。

多层保护，确保数据安全与合规

亚马逊云科技一方面帮助客户把数据方便、高效地存储到云上，另一方面也在致力于为上云数据提供最大程度的安全保证，帮助客户确保合规。为此，亚马逊云科技还首创了安全责任共担模型，即亚马逊云科技负责云基础设施和服务的安全, 而客户负责云基础设施之上的操作系统、应用和数据安全。

通过多年持续不断的努力，如今亚马逊云科技打造出了多种安全服务，包括Amazon IAM、Amazon CloudTrail、Amazon Config、Amazon VPC Flow Logs等，可以实现多重认证和加密、持续监控，结合各种存储服务本身的功能，用户可以建立其一个多层次的数据安全防护体系。

以Amazon S3为例，在数据访问控制上，Amazon S3提供基于Attribute-based access control（ABAC）的控制策略，结合亚马逊云科技IAM服务、Amazon S3 Bucket Policy和Amazon S3 Object Tags等可以实现对S3的访问控制。ABAC相比传统的Role-Based Access Control（RBAC）拥有更多优势，包括可以随着资源的增加而扩展需求，可以节省Policy的数量，可以更粒度的进行控制，以及更快速地对团队进行修改等。

在数据保护上Amazon S3也提供了多种手段。比如，可以通过版本管理和多因子认证来减少数据错误删除，还支持存储加密和传输加密。而在监控方面，Amazon S3支持通过亚马逊云科技IAM Access Analyzer持续分析是否有资源被公开或者跨账号访问，以及验证各种策略是否正确书写等；还可以启用Amazon Macie服务，它使用人工智能算法对Amazon S3存储桶中的数据进行分析，以发现潜在的安全风险，保护敏感数据。

同样，亚马逊云科技的文件存储服务Amazon EFS也为客户提供了极强的控制力，比如可以通过POSIX权限严密控制对文件系统的访问；使用Amazon Virtual Private Cloud (Amazon VPC) 管理网络访问；使用亚马逊云科技Identity and Access Management (IAM) 控制对Amazon EFS API的访问；对静态和动态数据进行加密以保护存储的数据和传输中的数据等。

另外，亚马逊云科技还致力于简化安全策略的设置和管理。比如，通过创建访问点（Access Point），用户和应用程序可以使用它来访问Amazon EFS文件系统和Amazon S3，并根据IAM中定义的访问控制和基于策略的权限强制实现更细粒度的访问控制，以简化对对象和文件的共享访问。相比传统方式（如POSIX ACL）访问点在设置、管理和维护上都更为简单，提高了效率同时降低了潜在风险。

而在合规方面，亚马逊云科技的各项云服务符合PCI DSS、HIPAA、SOC 1/2/3等国际安全标准和条款，可以保障用户数据的合法性和安全性，帮助客户实现合规。

一站式数据备份与恢复，守住最后的防线

近年来，勒索软件事件一直处于高发态势，给企业数据安全带来了严重威胁。为了应对勒索软件的威胁、减少人为误操作带来的损失以及合规的需求，企业对数据备份和灾备的需求不断增加。然而，一直以来，云上备份就面临管理复杂、安全合规、高昂成本等挑战，这是企业面临的难题，也是亚马逊云科技要解决的问题。

亚马逊云科技的解决之道就是云上的一站式备份服务Amazon Backup——一种完全托管的、基于策略的备份服务，可以轻松地集中管理和自动化跨Amazon云服务的数据备份。

Amazon Backup支持亚马逊云科技的全部存储服务（块、文件、对象），以及各类数据库、计算和存储网关，可以一站式保护其中的数据。Amazon Backup通过图形界面来简化操作以帮助用户降低整个运维的成本，用户还可以通过预设的策略进行自动化的备份，降低手动备份带来的问题。

而安全合规方面，Amazon Backup深度集成了亚马逊云科技自带的KMS数据加密服务，整个备份操作权限数据访问权限都可以用IAM进行细颗粒度监控，满足个人信息安全规范等安全合规的要求。

对于很多企业，特别是传统企业，有不少数据保留在传统数据中心。对此亚马逊云科技提供了亚马逊云科技Storage Gateway服务，它部署在客户数据中心，可以与Amazon的数据中心连通，并通过Amazon Backup实现云下、云上数据的统一存储和备份。在此过程中，亚马逊云科技还与合作伙伴（如NetApp、IBM、Veritas等）开展合作，实现对来自第三方软件的数据进行存储和备份。利用Amazon Backup的图形化管理控制台，客户只需要点击鼠标，就能够实现跨应用，跨数据源的集中备份操作。用户可以针对不同的数据类型设置备份策略和备份数据保留周期，实现自动备份。Amazon Backup所有的备份数据都支持KMS加密，备份恢复操作权限和数据访问权限都可以通过IAM细颗粒度授权，同时支持备份库锁定和备份审计功能，满足企业法规遵从需求。勒索病毒攻击事件时有发生，国内也有很多企业都遭受到了巨大损失，利用Amazon backup的集中数据备份，以及备份库锁定功能，可以有效的防止勒索病毒的攻击，生产数据备份到备份库，设置备份库锁定功能，病毒或者恶意操作都无法改变或者删除备份库里的数据。这样能确保客户在遇到生产数据损坏或者遇到恶意攻击时，能够有效恢复数据，

最后，值得一提的是，亚马逊云科技云服务在种类丰富的各种云服务外，还提供了各种安全最佳实践。作为用户，利用好这些服务，并遵守亚马逊云科技的安全最佳实践，就可以为自己的数据提供最大程度的安全保障。

结束语

在一个全面数字化和云化的时代，数据已经成为关键生产要素，数字化和云化能够帮助企业优化业务流程，提高效率和灵活性，企业可以实现更快、更准确和更简单的业务操作，同时也能够快速地适应市场变化和业务需求的变化。作为云时代的技术引领者，亚马逊云科技在存储领域的探索，帮助正在数字化转型中的各行各业从数据中收获价值打下了很好的基础。同时，其产品和技术创新的思路给业界提供了很好的参考。

点击“阅读原文”，了解Amazon Backup更多信息！

Istio在Rainbond Service Mesh体系下的落地实践

两年前Service Mesh（服务网格）一出来就受到追捧，很多人认为它是微服务架构的最终形态，因为它可以让业务代码和微服务架构解耦，也就是说业务代码不需要修改就能实现微服务架构，但解耦还不够彻底，使用还是不方便，虽然架构解耦了，但部署还没有解耦。

• 无法根据不同环境或客户需要选择合适的Service Mesh框架。
• 无法做到在开发环境不用学习和使用Service Mesh，生产环境按需开启。

插件式 Service Mesh架构实现思路

目前成熟的ServiceMesh框架也有许多，但是对于用户而言。并不存在万能的ServiceMesh框架，可以解决各种场景的问题。因此我们希望对于用户而言，他只需要关心自己的业务代码。而应用的治理能力，则可以通过不同的ServiceMesh框架进行拓展。用户的业务代码与ServiceMesh框架完全解耦。如下图所示。用户可以随时替换某个应用所使用的ServiceMesh架构。选择与业务最匹配的解决方案。

基于以上思路，我们可以将istio、linkerd、dapr等微服务架构做成插件，开发过程中完全不需要知道Service Mesh框架的存在，只需要处理好业务的依赖关系，当交付到生产环境或客户环境，有些需要性能高、有些需要功能全、有些客户已经指定等各种差异化需求，根据环境和客户需要按需开启不同类型的插件即可，当Service Mesh框架有问题，随时切换。这样Service Mesh框架就变成赋能的工具，老的业务系统重新部署马上就能开启服务治理能力。

Rainbond就是基于上述思路实现的，当前版本已经实现了三个服务治理插件。

• kubernetes 原生Service 模式
• 基于envoy的Service Mesh模式
• Istio服务治理模式

后面我们详细讲解Istio服务治理模式的使用过程。

使用Istio治理模式的实践

有了以上概念，我们可以来看看Rainbond如何与Istio结合。在Rainbond中，用户可以对不同的应用设置不同的治理模式，即用户可以通过切换应用的治理模式，来按需治理应用。这样带来的好处便是用户可以不被某一个ServiceMesh框架所绑定，且可以快速试错，能快速找到最适合当前业务的ServiceMesh框架。

安装Istio 控制面（control plane）

首先在切换到Istio治理模式时，如果未安装Istio的控制面，则会提示需要安装对应的控制面。因此我们需要安装Istio的控制面，控制面在一个集群中只需安装一次，它提供了统一的管理入口，用来管理工作在Istio治理模式下的服务。完成配置下发等功能。结合Rainbond现有的helm安装方式，我们可以便捷的安装好对应的组件。

1. 创建团队

在5.5.0版本中，我们支持了用户在创建团队时指定命名空间。由于默认helm安装的命名空间为 istio-system ，所以为了减少用户配置。我们首先需要创建出对应的团队。如下图所示。团队英文名对应的则是该团队在集群中的命名空间。此处填写 istio-system 。

2. 对接商店

Rainbond支持基于helm直接部署应用，所以接下来对接Rainbond官方helm仓库，后续基于Helm商店部署Istio即可， 在应用市场页面，点击添加商店，选择helm商店，输入相关信息即可完成对接。

商店地址：https://openchart.goodrain.com/goodrain/rainbond

3. 安装 Istio 控制面

商店创建完成后，即可看到对应的 helm 应用，目前Rainbond提供了 istio 1.11.4 版本的helm包，根据 Istio官方文档，该版本对Kubernetes集群的版本支持为 1.19, 1.20, 1.21, 1.22。

• 安装 base 应用

  选择helm商店中的base应用进行部署，团队选择之前创建的命名空间为 istio-system 的团队。该应用包主要部署了Istio相关的集群资源和 CRD 资源。

  

• 安装 istio-discovery 应用**

  同上述base应用一样，选择正确的团队。安装 istio-discovery 应用。有了这两个应用，就可以拥有 Istio 基础的治理能力了。

示例应用开启Istio治理模式

1. 切换治理模式

我们以SpringBoot后台管理系统 若依 为例，如下图所示，用户可以先从开源应用商店安装一个若依SpringBoot 应用，版本选择3.6.0，点击治理模式切换，选择Istio治理模式。

在点击切换为Istio治理模式后，会需要用户手动设置内部域名，此处的内部域名将会是该组件在Kubernetes集群中的service名称，在同一个团队下唯一。这里我们修改为可读性较高的内部域名。

2. 修改配置文件

在这一步完成后，我们还需要进入ruoyi-ui 挂载一个新的配置文件。这主要是因为默认情况下，ruoyi-ui 的配置文件web.conf 中后端服务地址为 127.0.0.1，在之前使用 Rainbond 内置 ServiceMesh 模式时，由于 Rainbond 会获取到后端服务的地址，注入到ruoyi-ui 内部, 赋予ruoyi-ui 一个本地访问地址（127.0.0.1）访问后端服务。所以无需修改就能使用。

但使用 Istio 治理模式时，组件间通过内部域名进行通信，因此需要通过挂载配置文件的方式修改对应的代理地址，ruoyi-ui 的配置文件可以通过右上方的Web终端 访问到容器中，复制/app/nginx/conf.d/web.conf 这个文件的内容。修改代理地址后保存，如下图所示。之前我们设置了控制台的内部域名为ruoyi-admin，所以这里替换为ruoyi-admin。

3. 重启应用

在完成以上两步后，我们需要重启整个应用。在启动应用后，进入组件页面查看，应该可以看到每个组件都有一个类似的 Sidecar 容器，这就是Istio的数据面 (data plane)，在应用切换为Istio治理模式以后，该应用下的所有组件都会自动注入对应的 Sidecar 容器，不需要用户额外设置。

至此，该应用已纳入Istio治理范围。用户如果需要对该应用有更多的配置，则可以参考 Istio官方文档 进行扩展。

通过Kiali监控和管理Istio

在之前的步骤中，我们使用 Istio 治理模式纳管了 若依 。接下来则带大家一起看看如何使用 Kiali 观测应用间的通信链路。在这一步中，用户需要有 kubectl 命令。

1. 安装 prometheus

在Istio中，各个组件通过暴露HTTP接口的方式让Prometheus定时抓取数据（采用了Exporters的方式）。所以Istio控制平面安装完成后，需要在istio-system的命名空间中部署Prometheus，将Istio组件的各相关指标的数据源默认配置在Prometheus中。

同上述base应用一样，选择正确的团队，安装Prometheus应用。

2. 安装kiali

kiali提供可视化界面监控和管理Istio，能够展示服务拓扑关系，进行服务配置。

安装 kiali-operator 应用，同上述base应用一样，选择正确的团队。

安装过程将自动创建Service，通过Rainbond平台第三方组件的形式可将 kiali 的访问端口暴露出来。如下图所示：

在端口界面添加访问端口，添加以后打开对外服务使用生成的网关策略即可进行访问。

kiali登录时需要身份认证token，使用以下命令获取token：

kubectl describe secret $(kubectl get secret -n istio-system | grep istiod-token |awk '{print $1}') -n istio-system

访问到kiali以后，在Applications一栏，选中应用所在的命名空间，就可以看到我们刚刚创建的应用。点击进入，可以看到如下的流量路线。

在 Graph 一栏，也可以看到对应的应用内的流量请求。更多的配置及相关功能参考 Kiali官方文档

总结

本文简单介绍了在Rainbond中使用Istio治理模式的操作。以及Rainbond与Istio治理模式的结合。Rainbond为用户提供了一个可选的插件体系，使用户可以根据自己的需求选择不同的Service Mesh框架。在与Istio的结合上，我们主要为用户完成了指定应用数据平面的注入。用户也可以通过该机制扩展自己所需的ServiceMesh框架。后续文章我们将详细讲解如何制作插件，尽请关注。

---

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

Github：https://github.com/goodrain/rainbond

官网：https://www.rainbond.com?channel=k8s

微信群：请搜索添加群助手微信号 wylhzmyj

钉钉群：请搜索群号 31096419

 

Rainbond 5.5 版本主要优化扩展性。服务治理模式可以扩展第三方 ServiceMesh 架构，兼容kubernetes 管理命令和第三方管理平台。

主要功能点解读：

1. 支持 Istio，并支持扩展第三方 ServiceMesh 框架

Rainbond 专注于无侵入，松耦合的设计理念。在当前版本中，Rainbond 引入了应用级治理模式的切换功能，实现了服务治理能力的动态切换，无需业务逻辑变更，为业务提供了不同的治理能力。可以通过应用级插件的形式扩展第三方 ServcieMesh 框架，比如 Istio、Linkerd、Dapr 等，本次我们优先支持了Istio，用户可以通过 helm 安装 Istio 相关组件，实现应用治理模式的切换。从而享受到Istio相关的治理能力。如下图所示：

我们希望用户最终使用时，服务治理能力与业务逻辑是完全解耦的，用户可以根据不同的业务使用不同的治理能力。可以根据自己的需要扩展不同的治理模式，后续我们会有专门的文章来详细介绍如何扩展第三方 ServiceMesh 框架。

2. 兼容 kubernetes 管理命令和第三方管理平台

在之前的版本中，我们以应用为中心，使用户可以便捷的管理自己的业务。但通过Rainbond生成的名字空间、应用名和服务名使用 UUID，对熟悉 Kubernetes 的人非常不友好，在 Kubernetes 展示的 ID 无法跟业务关联，就无法使用 Kubernetes 命令或 Kubernetes 的第三方工具管理。因此我们现在支持了集群内各类资源的重命名。用户可以自定义团队、应用、服务、组件、镜像的英文名，在Kubernetes 中会以英文名展示。

用户设置了应用的英文名为 rbd，分别设置了组件的英文名后，在集群生成的资源如下图所示。

详细变更点：

新增功能

• 【应用管理】支持Istio治理模式的切换；
• 【应用管理】支持修改应用和组件的集群资源名；

优化功能

• 【组件管理】优化组件构建的镜像名称；
• 【数据库】新版本集群数据库使用utf8mb4编码；
• 【升级】优化应用升级时无变更组件不进行更新操作；
• 【组件管理】优化组件首次设置健康检测的提示；

BUG 修复

• 【组件管理】修复实例运行内存为0的问题；
• 【网关】修复网关策略跳转页面错误的问题；
• 【应用管理】修复应用运行组件数展示错误的问题；
• 【应用管理】修复应用无法正常回滚的问题；
• 【插件管理】修复默认插件构建失败的问题；
• 【应用管理】修复发布应用时，插件分享事件同步发生错误的问题；
• 【插件管理】修复安装插件不生效的问题；
• 【组件管理】修复域名创建的第三方组件无法通过内部依赖访问的问题；
• 【应用管理】修复TCP策略网关端口可以随意设置的问题；
• 【升级】修复应用升级失败重试无响应的问题；
• 【应用管理】修复helm应用状态展示错误的问题；
• 【升级】修复回滚功能不可用的问题；
• 【组件管理】修复内部域名可以重复的问题；
• 【插件】修复插件内存不限制时报错的问题；
• 【升级】修复配置文件升级后无法修改的问题；
• 【组件管理】修复创建中组件无法继续部署的问题；

References Link

[1] Rainbond 5.5安装

[2] Rainbond 5.4升级到5.5

[3] Istio控制平面安装

---

Rainbond 是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

Github：https://github.com/goodrain/rainbond

官网：https://www.rainbond.com?channel=k8s

微信群：请搜索添加群助手微信号 wylhzmyj

钉钉群：请搜索群号 31096419

CentOS如何改变云Linux领域？

Red Hat在2021年底将丢弃CentOS 8，用户们纷纷考虑面前的选择。
作者：Matt Asay  编译：沈建苗

在前不久的AWS re:Invent大会上，大型机现代化、数据库更新版和基于ARM的 Graviton3等新品赚足了眼球，诸位看官可能因此疏忽了一点：Amazon Linux 2022。AWS首席执行官Adam Selipsky在主题演讲中并没有提及它，但AWS计算服务副总裁Deepak Singh确实为此发了推文。但Amazon Linux 2022可能名至实归，因为它是那种了不起的产品，旨在提供稳定性、安全性和性能，又不显山露水。

这也是一个值得关注的版本。Amazon Linux 2022首次不基于Red Hat Enterprise Linux（RHEL）代码，而且从未基于CentOS。CentOS这个长期的RHEL克隆版在2020年底掀起了不小的动静，当时Red Hat宣布不使用定点（fixed-point）发布模式，改而使用“基于流”的滚动发布模式。相反，Amazon Linux 2022而是基于Fedora社区上游项目。

觉得这没什么大不了？那么你也许应该问问其他大型云提供商：鉴于Red Hat已宣布CentOS 8将于2021年底寿终正寝，它们打算怎么办。想销售美国政府基于CentOS的服务？CentOS不再符合FedRAMP。改用RHEL或另一款受支持的操作系统，不然休想与联邦政府做生意。我去。

无论是AWS有先见之明还是纯属走运，AWS专注于Fedora很可能带来可观的回报。但是对于白蹭CentOS的日子即将到头、下一步不知道该如何是好的企业来说，也许有必要记住一点：“免费软件”常常不是免费的。

 

“IT史上被滥用最多的软件”

每家云供应商立足于CentOS有其道理。毕竟，每家都这么做，每家。不妨看看全球一些最大的软件即服务（SaaS）提供商的底层操作系统，你会发现CentOS的影子无处不在。深入了解IBM的咨询业务，会发现该公司多年来如何告诉其客户“就使用 CentOS”。永远不会允许别人出售超昂贵包包仿制品的欧洲时尚品牌运行CentOS。中国的整个电信基础设施都运行在CentOS上。（是的，千真万确。）Facebook也基于CentOS。

CentOS的这种广泛使用也并不仅限于测试和开发实例。有一家大型云提供商的许多大客户在运行CentOS，CentOS的知情人士提到了这家云提供商的高管所说的这番话：“CentOS是IT史上被滥用最多的软件。CentOS前十大用户拥有超过50000个实例，它们是《财富》100强中的知名公司。它们知道自己在做什么。并不是开发人员运行开发/测试实例。它们不是小公司。”

原因何在？因为CentOS一直被认为很安全。当然，Red Hat试图告诉客户，在生产环境中跑CentOS相当于手持剪刀在跑步（“尽管去跑吧，但你一定会受伤！”），但事实上它非常接近RHEL，而Red Hat花数年时间培育市场、传达“RHEL即安全”的讯息。

CentOS Stream在Red Hat收购CentOS几年后宣布发布，Red Hat反而使CentOS不太安全。突然间，CentOS 从“可信赖的RHEL克隆版”变成了“有点拉垮的RHEL测试版代码”。如前所述，许多人纷纷抱怨，但不清楚他们是否会极喜欢这个替代版。多年来，CentOS社区一直努力跟上人气。人气旺是好事，但当 (a) 你没有因这种人气而获得报酬，以及 (b) 全球一些最大的公司（银行和电信公司等）在CentOS上运营其大量的业务，因此要求对代码进行各种更改时，情况就不那么好了。这是导致维护人员倦怠的主因，也是企业在跑时被所持的剪刀所伤的主因。

必须有所给予。

Red Hat出面稳定CentOS社区的办法是雇用主要的贡献者。就Red Hat而言，它希望为OpenStack和OpenShift等更高级的社区项目提供稳定的代码基础。Fedora无法提供这个基础，因为它的迭代步伐太快了。当然，Red Hat也想让吃白食的企业明白，不存在真正意义上的“免费软件”。为了避免被开发人员和小公司讨厌，Red Hat对RHEL开发者版本进行了重大更改，使其极易访问或使用（即免费！），同时让RHEL可供最多16台服务器免费使用，从而为学校及其他小组织提供了一种经济高效的方法，以运行经过测试、认证和支持的Linux。

云端的高光时刻

这一切无法帮助不得不应对CentOS变化的托管服务提供商。正如我所认为，这些公司不需要Red Hat来支持，它们多年来一直在不受支持的情况下运行CentOS。但是它们依赖的Linux的本质发生了变化，而且是重大变化。运行经过良好测试的企业级Linux的克隆版是一回事，在没有任何安全或性能保障的测试版软件上运行完全是另一回事。

这开始看起来酷似“手持剪刀在跑”的场景，Red Hat在CentOS Stream之前试图用这种场景来抹黑CentOS，但未能如愿。鉴于操作系统（一家公司的应用程序、数据库等依赖的基础）相比企业在上层软件方面的高昂支出较为便宜，“捡了芝麻丢了西瓜”的做法突然显得很可笑。

该怎么办？一个显而易见的答案是向Red Hat支付RHEL费用。针对不愿意这么做的用户，谷歌建议使用CentOS的替代版，并与Red Hat合作，帮助客户迁移到受支持的操作系统。微软对Azure客户给出什么样的建议则不太清楚。AWS已经改用Fedora，并提供支持。是的，这底层代码也许用alpha代码来加以描述最为恰当，但AWS工程师会积极为上游做出贡献以改进它，AWS全力支持它。

AWS的竞争对手在这方面要棘手一点。没有人真的想支持另一个Linux发行版。这就是我们选用RHEL、SUSE和Ubuntu的原因。AWS第一个向市场推出了其Linux。鉴于其市场份额，AWS可能是唯一一家实力大得足以说服独立软件开发商（ISV）及其他厂商支持与RHEL不兼容的Linux的供应商。现在，谷歌和微软要弄清楚如何在后CentOS时代存活，它们可没有足够大的市场份额来说服ISV及其他厂商支持其操作系统。记住，Red Hat赢得Linux市场的手段是围绕其经过认证的操作系统创建一个生态系统。坊间有传闻称，谷歌和微软可能联合支持一款与SUSE兼容的产品，但现在下结论为时过早。

唯一可以肯定的是，Linux再次备受关注。这可能不是一件好事，因为它理应是不会引起任何人注意的幕后基石。

文章来源：
https://www.infoworld.com/article/3643708/how-centos-changes-the-cloud-linux-game.html

我们在使用智能手机的时候，手机APP从应用市场一键安装，安装好即点即用，当有新版本一键升级，如果不想用了长按图标删除，整个过程非常简单，小朋友都能熟练掌握。而对于企业应用，由于结构复杂、可用性要求高、配置多等特点，导致企业应用的管理工作异常复杂。企业内部一般都会有专门的运维工程师来负责保障企业应用的正常运行。

Rainbond 是一款云原生企业应用管理平台，本文将以它为例讲解，如何像管理手机 APP 一样简化管理企业应用。

建立企业应用商店，从应用商店一键安装企业应用

手机 APP 的安装已经做到了极致的简单，在预装好的 AppStore 中一键安装想要的APP即可。这种一键安装的体验流程，哪怕一个小朋友都可以很好的掌握。企业应用部署难度大，组件数量多，其安装的复杂程度远高于手机 APP 。那么在企业应用的安装领域，能否做到安装手机APP一样的一键式体验呢？

类比手机 APP 的安装过程，应用商店这个集合了大批 APP 的平台是必不可少的一环，正是有苹果 AppStore、Google Play 这样生态繁盛的应用商店，才让手机消费者随心所欲的安装手机 APP。Rainbond应用商店是企业级的AppStore。每个用户都可以将自己部署在 Rainbond 上的企业应用发布到应用商店中去，供其他用户使用，其他用户只要从应用商店一键安装和升级，使用体验和手机AppStore的体验类似。

为了最终用户的使用体验，开发手机APP的企业需要按应用商店的标准开发和上架，企业应用商店的实现也是类似的思路，企业应用的供应商需要按企业应用商店的标准打包和上架，Rainbond内置的应用商店有一整套的应用打包、测试和上架过程，比如从源码打包、二进制文件打包、容器打包等，这些打包过程都不需要改动原有代码。按应用商店的规范打包和上架，不仅简化了应用的安装和升级过程，同时也建立了企业应用的验收标准。

企业应用管理复杂，该如何简化管理？

对于一个手机 APP 而言，实际上我们可以做的管理操作很少，仅仅涉及到安装、升级、删除。而一个企业应用则要复杂得多，一个企业应用所需要的管理操作，至少包含了以下这些点：

• 生命周期管理：就像手机用户需要安装、使用、升级、删除 APP一样，安装、升级、启动、关闭、删除等生命周期管理相关的操作，是企业应用所需要的最基础的管理操作。
• 批量管理：手机 APP 只有一个组件需要管理，而企业应用往往是多个服务组件相互依赖组合形成的。所以会需要有批量操作的需求。
• 资源分配：手机用户从来不用关心需要为一个 APP 分配多少资源，而企业应用的管理者必须关心为每个组件分配合理的计算资源。计算资源分配不足会让企业应用运行不畅甚至无法运行，过多的分配计算资源会导致资源浪费。
• 伸缩特性：手机 APP 并没有运行多份的需求，它只需要保证在手机中正常运行， 满足主人的个人使用压力即可。企业应用无论是在高可用方面还是在抗并发方面，都会对横向伸缩能力提出要求。
• 可观测性：手机用户从来不关心是否能够看到手机 APP 的运行状态，只关心它们的功能。但是企业应用管理者会对企业应用提出很高的可观测性要求，包括运行状态、资源占用、性能表现、运行稳定性等。
• 故障恢复：手机用户允许 APP 偶尔出现闪退，无非是重新打开一次罢了。而企业应用管理者对企业应用的期待是，即使企业应用出现了问题，也可以快速从故障状态中恢复过来。
• 迁移/备份：手机 APP 的用户数据都保存在云端，数据的迁移、备份操作简单。企业应用重视数据，对迁移备份等操作要求很高，有的场景甚至要求跨集群迁移备份。

经过对比，可以发现企业应用在管理方面需要注重的点，比手机APP复杂得多。但这不意味着企业应用管理人员一定要付出更多的努力来管理企业应用。选择正确的企业应用管理工具，会使得企业应用管理工作事半功倍。

Rainbond从三个方面简化企业应用的管理：

1. 让常规的管理简单容易上手，比如：安装、升级、启动、关闭、删除、伸缩、配置域名等管理操作都可以一步完成。
2. 复杂的运维过程实现自动化，比如：安装/升级/启动的操作过程、健康检测、服务高可用、自动伸缩等。
3. 过程实时监控和可视化，由于管理过程实现了简单操作和自动化，就需要加强监控和可视化了解应用运行情况，做到过程可控可管。

让企业应用常规管理简单容易上手

前文已经分析过，手机用户对 APP 的管理操作是仅限于开启、关闭等简单的操作。对于企业应用而言，我们希望企业应用管理者主动发起的管理操作，也是足够简单的操作。企业应用管理人员完全通过图形化界面，来完成对企业应用的生命周期管理操作。

对于企业应用整体而言，可以执行批量的管理操作：

涉及到生命周期管理的操作包括但不限于：

• 企业应用整体的启动、停用、更新、构建、升级
• 面向企业应用内部所有组件的批量启动、关闭、更新、构建、重启、删除

对于希望将企业应用完整的迁移到其他集群，或者做一份备份的场景而言，图形化操作的迁移/备份功能可以解决问题：

对于指定的服务组件而言，可以进行的主动管理操作会更多：

除了较为常见的生命周期管理之外，企业应用的管理者还可以有更多的主动操作：

• 版本管理，在多个构建版本之间一键升级或回滚

• 伸缩管理，主动的为服务组件设置计算资源、实例数量

• 环境配置，主动为服务组件设置环境变量，挂载配置文件

• 存储管理，主动为服务组件添加持久化设置，使数据持久化的保存

• 端口管理，主动为服务组件添加端口访问策略

• 插件管理，主动为服务组件安装可以扩展运维能力的插件

• 进入 Web终端，直接操作当前服务组件的容器shell环境

常规企业应用管理操作基本都是UI界面，过程也不需要学习底层技术，通过界面摸索就可以上手。

复杂的运维过程实现自动化

企业应用确实比手机 APP 复杂太多，但是我们又希望企业应用的管理者尽量少操管理的心，那么提供自动化的运维能力就十分有必要。

Rainbond 被设计成一款具备强大自动化运维能力的平台。这些自动化运维能力，可以最大限度的解放企业应用管理人员的双手，切实提升生产力。这些自动化运维能力提炼自许多工程师长久以来的运维工作经验，这些能力往往表现在企业 IT 系统的底层，平日里不显山露水，但是却关乎企业应用运行的好坏。

1. 常规管理的过程实现自动化企业应用的常规管理本身是挺复杂的，为了前端的操作简单，后端的实现过程就必须自动化。 比如：
   • 安装过程自动化，安装过程需要为每一个服务自动化完成软件包安装、服务配置、端口管理、服务启动等步骤。
   • 升级过程自动化，升级过程需要自动化完成对比版本差异、差异安装、滚动升级等步骤。
   • 启动过程自动化，当一个企业应用有多个子服务时，还需要自动处理它的服务启动顺序。
2. 健康检测与故障恢复企业应用管理人员不希望为了应对不知何时会发生的企业应用故障而每时每刻值守在机房。因此 Rainbond 提供健康检测能力，来替代企业应用管理人员，时刻关注着企业应用的健康状况。并且提供可选的异常处理手段，在异常发生时自动处理。

   Rainbond 平台支持两种模式的探针来自动检测服务组件中所有实例的健康状况。TCP模式的探针，会每隔一段时间侦测服务组件的指定端口是否可以联通，这种检测是基于网络和端口的联通性来实现的。而HTTP模式的探针，会每隔一段时间，请求指定的URL，并根据HTTP返回码来判断实例的健康状况。相对而言，TCP探针应用的范围更广泛，而 HTTP 探针会更加精确。因为可能存在这样一种软件设计缺陷，WEB SERVER 处于正常工作状态，端口可以正常监听，但是业务接口已经无法提供正确的返回，这对于最终用户而言，也是一种应该被检测到的错误。

   对于检测失败之后的处理，平台提供两种策略，下线与重启。

   将问题实例从负载均衡中下线，这是一种降级行为。触发下线后，不会再有新的请求到达问题实例，问题实例从巨大的访问压力中得以缓解。接下来，如果服务组件足够健壮，它会在处理完大量的积压请求后恢复，重新通过健康检测后上线。这里包含一个隐藏的假设，要求服务组件具备多实例特征，否则问题实例的下线会导致服务组件整体无法提供服务。

   重启则是一种相对武断的处理方式。但不可否认的是，在服务组件不那么健壮的情况下，重启实例是最简单有效的恢复手段。

   

3. 高可用能力Rainbond 为企业应用提供了高可用能力的支持。在一个 Rainbond 集群中，往往存在多种不同身份的服务器节点，而每种不同身份的服务器节点也不止一台。这意味着 Rainbond 本身就是高可用的，运行在其上的企业应用，也可以自由的在不同的宿主机节点之间漂移。

   在 Rainbond 集群中的某台服务器出现故障时，Rainbond 集群并不会受其影响，也会将受到服务器故障影响的企业应用重新调度到其他正常的服务器中去。企业应用管理人员只需要在事后修复故障的服务器，整个 Rainbond 集群又会完成自愈，而企业应用在这个过程中受到的影响是可以忽略不计，尤其是当企业应用本身伸缩了多个实例的状态下，可以做到最终用户无感的处理体验。

4. 自动伸缩能力如果企业应用的最终用户是人，那么它的访问压力情况，都会有潮汐特征。好比一款供企业内部人员使用的OA系统，工作日的流量远比休息日高，工作时间的流量远比下班时间高。那么可否让这款 OA 系统根据流量的大小，自动调整实例的数量。令其忙时启动足够数量的实例抵御访问压力，闲时自动降低实例数量，将资源留给其他企业应用。Rainbond 平台可以赋予企业应用自动伸缩的能力。

   Rainbond 平台对于其托管的每个企业应用的当前状态了如指掌。当然也了解当前企业应用的资源使用数量是否已经接近分配的上限。通过自动伸缩的设置，可以为企业应用设置一个上限，当 Rainbond 发现企业应用使用的资源已经超过这个设定值时，自动的扩展实例的数量。这个设定值，可以是内存使用量/率或CPU使用量/率，亦或是两种资源的综合设定值。

   

管理过程可观测和可视化，做到可控可管

手机用户不会想着观察 APP 内部的运行状态，但是企业应用管理人员不这么想。可观测性是一切管理工作的前提，只有看得见，才能摸得着。

Rainbond 提供的可观测性无处不在，从集群维度开始，到应用级别，最终到每一个服务组件级别，都体现着丰富的可观测性。

对于一个企业应用而言，看到它内部的拓扑结构，和所有组件的运行状态是最基本的可观测性要求。Rainbond 提供了应用拓扑图界面，并根据不同的颜色来体现每一个服务组件的运行状态。绿色代表运行中，黑色代表已停止，而红色代表服务组件处于异常状态。

对于单个服务组件而言，其可观测性的粒度要更细致。服务组件的总览页面中，描述了当前服务组件的详细信息，服务组件的每个实例，也都体现自己的运行状态。

下方的操作记录，更是详细描述了服务组件发生过的每一件事。

服务组件的监控页面，集中的体现了有关其运行状态的各种可视化图表。

• 体现业务性能情况的实时分析曲线

• 有助于优化程序的5分钟请求排行

• 各个实例的资源用量曲线

• 支持基于 Prometheus 体系的 Exporter 指标自行绘图

Rainbond 的监控大屏系统，提供全局可观测性的中心。

写在最后

Rainbond 提供一个解决企业应用的管理问题的全新思路，它不仅优化了管理和使用体验，还能高效管理应用供应商，应用商店也让管理人员对应用自主可控，减少对供应商的依赖。

---

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

Kubernetes 1.23发布：双栈IPv4/IPv6、CronJobs和临时卷

作者：Jack Wallen  编译：沈建苗

在云原生开发界，一眨眼工夫，你就会错过某些东西。发展速度就是这么快，快到仿佛昨天（实际上是8月22日）刚发布了Kubernetes 1.22，今天就迎来了Kubernetes 1.23 GA（正式版）。这个新版本功能丰富，增强之处超过45项（其中11项已升级到稳定版，15项已改进，19项是全新的）。虽然这些新功能可能不会全部跻身Top 10，但一些功能对使用Kubernetes的人而言可能大有帮助。然而，真正的焦点在于1.23中已升级到正式版（即稳定版）的功能，因此它们已准备好用于生产环境。

不妨先看看已升级到稳定版的功能（因为这些是你想立马开始使用的功能），然后介绍所有其他较为隐秘的改进。

升级到稳定版

首先你会发现四项非常令人兴奋的功能：IPv4/IPv6双栈支持、CronJobs（计划任务）、临时卷和HPA API。不妨逐一介绍。

 

IPv4/IPv6双栈支持

有了IPv6/IPv6双栈支持，Kubernetes现在可以在集群中直接支持双栈模式。这意味着你可以将IPv4地址和IPv6地址分配给任何特定的pod或服务。这是使用.spec.ipFamilyPolicy字段来配置的，该字段可设置为以下值之一：

•SingleStack

•PreferDualStack

•RequireDualStack

要使用双栈支持，你需要将.spec.ipFamilyPolicy设置为PreferDualStack或RequireDualStack。该功能在Kubernetes中默认启用，还包括通过IPv4和IPv6地址进行的pod集群外出站路由。

CronJobs
有了CronJobs功能，就可以在Kubernetes集群中运行周期性任务。Kubernetes CronJobs与Linux cron系统非常相似。CronJobs在Kubernetes 1.4问世后就已存在了，自从它在版本1.5中获得CRI支持以来就在生产环境被广泛接受。

CronJob在YAML文件中定义如下：
kind: CronJob

每10分钟输出一次“Hello Newstack”的示例CronJob清单文件可能如下所示：

对于那些不知道cron语法的人来说，它就像这样：

MINUTE（分钟） HOUR（小时） DAY OF MONTH（月日） MONTH（月） DAY OF WEEK（星期几）

如果你不确定如何创建cronjob，强烈建议从Crontab Guru（https://crontab.guru/）开始入手，该编辑器让你可以将值插入到cronjob
，看看它们到底生成了什么。

临时卷

自Kubernetes 1.19以来，临时卷就已存在，让你可以为特定的pod创建卷，pod终止后删除临时卷。换句话说，这些是临时卷。

Kubernetes支持四种类型的临时卷，它们是：

•emptyDir—Pod启动时可用的空卷，使用来自kubelet基本目录或内存中的存储空间。
•configMap、downdownAPI、secret—将不同类别的Kubernetes数据注入到指定的Pod中。

•CSI临时卷—类似其他类型的卷，但由特殊的CSI驱动程序提供。

•通用临时卷—由所有存储驱动程序提供（支持持久存储）

使用临时存储的示例清单文件可能如下所示：

HPA API v2

Horizo​​ntal Pod Autoscaleer API对Kubernetes来说并不陌生。实际上，它在2016年就首次引入了。该功能负责自动扩展复制控制器、部署、副本集或状态集中的Pod数量。基于以下类型的指标来加以扩展：

•资源使用情况—当Pod超过内存或CPU使用情况的阈值时。这可以表示为原始值或百分比。

•自定义指标—这基于Kubernetes报告的指标（即每秒客户端请求率）。

•外部指标—这基于外部应用程序或服务提供的指标。

Autosaclers使用控制循环来运行，周期则由–horizo​​ntal-pod-autoscaler-sync-period标志来控制。默认值是15秒。在控制循环期间，控制器根据Horizo​​ntalPodAutoscaler定义中配置的指标来查询Pod的资源使用情况。

弃用的功能和升级为Beta版的功能

Kubernetes 1.23也有三项值得注意的弃用功能。这包括：

•HPA v2beta2 API

•FlexVolume

•针对klog的标志

两项功能也升级为Beta版，包括：

•PodSecurity—取代了PodSecurityPolicy准入控制器。
•结构化日志—来自kubelet和kube-scheduler的大多数日志消息已经过转换，建议用户尝试JSON输出。

处于Alpha版的新功能

Kubernetes 1.23还包括几项现处于alpha版的新功能。这包括：

•CRD的表达式语言验证—如果启用CustomResourceValidationExpressions，自定义资源将由使用通用表达式语言（CEL）的规则进行验证。

•服务器端字段验证—如果启用ServerSideFieldValidation，检测到请求中未知或重复的字段时，用户将收到来自服务器的警告。

•OpenAPI v3—如果启用OpenAPIV，用户将能够为所有Kubernetes类型请求OpenAPI v3规范。

想了解新版本的更多信息，请查阅完整的发布说明：https://www.kubernetes.dev/resources/release/。

文章来源：https://thenewstack.io/kubernetes-1-23-dual-stack-ipv4-ipv6-cronjobs-ephemeral-volumes/

 

Rainbond是一体化的云原生应用管理平台，它提供“以应用为中心”的抽象，使用者不需要学习K8s和容器，平台将K8s和容器封装在内部，这种封装方式能极大提高使用的易用性和安装的便利性，但封装的内部组件如何替换是一个问题，本文将讲解如何使用Harbor替换掉Rainbond原有的默认镜像仓库。

Harbor简介

Harbor 是一个用于存储和分发Docker镜像的企业级Registry服务器，也是首个中国原创的云原生基金会（CNCF）的开源企业级DockerRegistry项目，通过添加一些企业必需的功能特性，例如安全、标识和管理等，扩展了开源Docker Distribution。作为一个企业级私有Registry服务器，Harbor提供了更好的性能和安全。提升用户使用Registry构建和运行环境传输镜像的效率。

通Harbor解决Rainbond镜像管理问题

​ Rainbond之前默认使用的是Docker 提供的基础Registry，使用的过程中有很多问题，例如镜像安全性，镜像清理复杂麻烦等等问题，经过不断的调研，而Harbor不仅能解决这些问题，还能扩充很多镜像管理能力，Harbor 的功能主要包括四大类：多用户的管控（基于角色访问控制和项目隔离）、镜像管理策略（存储配额、制品保留、漏洞扫描、来源签名、不可变制品、垃圾回收等）、安全与合规（身份认证、扫描和CVE例外规则等）和互操作性（Webhook、内容远程复制、可插拔扫描器、REST API、机器人账号等）。

对接Harbor

​ 目前harbor支持两种形式对接Rainbond,一种是作为rainbond内部基础存储仓库，另外一种就是作为外部自定义镜像仓库。

• Harbor作为Rainbond内部基础存储仓库，进行对接非常简单，只需要在初始化平台集群的时候进行自定义即可。

​

​ Yaml文件的格式要求非常严格，避免大家在配置的时候出现问题，已把正确的yaml文件放在下面，复制就可以使用。

​ 注意：一定修改仓库的名字，仓库的项目名称, 用户名，以及密码，不然会出现镜像上传失败的问题。

1. 例：
2. apiVersion: rainbond.io/v1alpha1
3. kind: RainbondCluster
4. metadata:
5. name: rainbondcluster
6. namespace: rbd-system
7. spec:
8. imageHub:
9. domain: www.est.com/test
10. password: Harbor12345
11. username: admin

`

• Harbor作为rainbond的外部仓库进行提供服务，是基于harbor以及rainbond的webhook功能，配置如下。
• 保证组件已经开启了镜像仓库的webhook功能，且应用状态不是已关闭状态，并且需要将应用的 webhooks url 配置到目标镜像仓库的 webhooks 中

• 目标镜像仓库里面，新建一个webhook，然后在 Endpoint 地址填写应用的 webhooks url，配置符合需求的触发事件类型即可

• 通过Harbor实现镜像可视化存储管理，提高了工作的便利性。

• 基于Rainbond进行构建的时候实现漏洞自动扫描，提高了安全管理。

• 通过镜像自动清理的策略，合理利用存储，降低存储成本。
• 推荐使用策略：应用到仓库匹配, 保留最近推送的3个 artifacts基于条件tags匹配基于条件 无 Tag
• 推荐定时清理：自定义 cron : 0 0 0 1 */1 * (秒，分，时，日，月，周)
• 镜像是否被签名，漏洞的等级，也可以设置成为镜像安全策略之一，这样可以保证签名过的镜像或者漏洞等级低的镜像才可以被拉取。

整合后的整体流程

​ 通过上面流程图可以看到，整个搭载配置的过程，用户可以自定义镜像源进行拉取镜像，经过Rainbond平台自动推送到Harbor镜像仓库里面，然后等镜像扫描完成以后在进行自动拉取，自动进行构建容器实例。

---

Rainbond 是完全开源的企业级，面向应用的云原生 DevOps， 开发、测试、生产运维一体化平台，不要求开发者掌握容器、Kubernetes 等复杂能力，面向开发者友好；提供从源码或简单镜像持续构建云原生应用的能力，对源码无侵入，业务持续发布到云端；高效的自动化运维，帮助开发者高效管理高可用的、安全的且去中心化的业务系统。

“做好开源客服系统” 

春松客服是拥有坐席管理、渠道管理、机器人客服、数据分析、CRM 等功能于一身的新一代客服系统。将智能机器人与人工客服完美融合，同时整合了多种渠道，结合 CRM 系统，为客户打标签，建立客户的人群画像等，帮助企业向客户提供更加专业客服服务。

客服系统是企业的重要工具，尤其是移动互联网时代，微信公众号、移动电话或是 Facebook Messenger 等渠道分散了企业的服务渠道，企业需要响应来自任何地点任何时间的客户。同时，企业的口碑至关重要，企业服务需要在客户获得、客户激活、客户留存等阶段无懈可击。

春松客服提供多个开箱即用的供企业免费使用的模块：

• 账号及组织机构管理：按组织、角色分配账号权限
• 坐席监控：设置坐席监控角色的人员可以看到并干预访客会话
• 联系人和客户管理：CRM 模块，管理联系人和客户，细粒度维护客户信息，自定义标签和打标签，记录来往历史等
• 网页聊天组件：一分钟接入对话窗口，支持技能组、邀请和关联联系人等
• 坐席工作台：汇聚多渠道访客请求，坐席根据策略自动分配，自动弹屏，转接等
• 机器人客服：与Chatopera 云服务集成，通过插件形式安装，插件也以开源形式提供，查看插件源码。
• 企业聊天：支持企业员工在春松客服系统中群聊和私聊
• 质检：历史会话、服务小结、服务反馈及相关报表

为了使Rainbond的用户能够快速的体验春松客服，我们在Rainbond上制作了春松客服应用并将其发布至Rainbond开源应用商店。

在开源应用商店中搜索 春松客服 应用进行一键部署。

部署完成后的效果图：

---

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

使用 Rainbond 作为智慧城市底座之后，给我们带来了成倍的运维效率提升。 —— 咸阳市大数据管理局 熊礼智

咸阳市大数据管理局负责全市信息共享工作的组织领导，协调解决与政府信息共享有关的重大问题，研究拟订并组织实施全市大数据战略、规划和政策措施，引导和推动大数据研究和应用工作，建立全市统一的数据服务中心和信息共享机制。通过“端-边-网-云-智” 的全新技术架构，实现管理高效、服务便民、产业发展、生态和谐的目标效用，达成新一代信息技术与城市现代化深度融合，迭代演进的新模式、新理念。

智慧城市的建设中，对智慧城市应用的管理是个很基础的问题。传统的情况下，服务于民生的各类应用系统，都是由相应的政府部门各自部署管辖，这造成了一些困扰。各个城市部门往往各自为政，彼此之间形成数据孤岛，很难互通互联。无论是数据还是应用，都很难统一管理起来。

在咸阳智慧城市建设工作中重点建设数据交换共享平台和应用管理平台。数据交换共享平台负责打通城市各个部门的数据孤岛，进行数据清理和规约之后，最后达成所有城市部门的 IT 应用之间互联互通的效果。

在建设咸阳市智慧城市期间，我们在智慧城市应用管理领域遭遇了很多棘手的问题。为了解决这些痛点，我们借助 Rainbond 这款产品，建设起了可以提供自动化运维能力的应用管理平台。我从四个部分分享解决难题的整个过程：

痛点：回顾智慧城市应用，在部署实施以及后期运维上的难点痛点。

定位：我们如何定位智慧城市应用管理平台，以及希望通过它解决什么样的问题。

落地：简要阐述智慧城市应用管理平台的选型过程，以及部署落地的过程。

实战：讲一个真实的案例，来说明引入应用管理平台后，快速开发落地一个智慧城市应用的全过程。

传统模式下的痛点

我将痛点归纳如下：

• 缺乏统一管理：以往各个城市部门的应用系统的部署是杂乱无章的。每家单位都在建设自己的 IT 系统，没有统一的管理可言。

• 遗留系统多：很多城市部门的应用系统使用的时间都很久了，有的系统甚至已经失去了厂家的支持。而有的系统采用的技术已经过时，无法方便的迁移到可以被集中管理的环境中去，也没有办法很好的将它们监控起来，获得其实时的状态。

• 资源分配不合理：每家单位都在进行 IT 系统的建设，这必然导致做了很多重复性的建设工作，资源浪费随之而来。而且在缺乏资源监控的情况下，没有谁能说清楚各自的应用系统到底应该使用多少资源。访问量不论多少，都分配了同样的资源，缺乏合理性。

• 运维困难：每家单位建设 IT 系统的方式方法五花八门。而这些单位自身往往缺乏相应的技术人才来维护这些系统，一旦出了问题，每套业务系统的维护方式都不一样。

• 缺乏可观测性：以往的 IT 系统建设，往往仅仅关注应用程序本身，而忽略了可观测性的建设。无法做到问题快速发现，往往 IT 系统的失灵，是由用户反馈而来的。

对应用管理平台的定位

应用管理平台负责承载和管理所有智慧城市下属的应用系统，包括新建设起来的数据交换共享平台。后续所有新开发的智慧城市应用会直接基于应用管理平台部署，以往老旧的遗留系统也会随着迭代更新不断迁移到应用管理平台。这么做的目的就是为了能够逐步整合各个城市部门的数据与应用，统一管理。

建设智慧城市的过程中，必然会不断涌现出大批新的城市部门应用系统，如何在建设过程中不重走老路很重要。智慧城市应用管理平台在这个过程中扮演的角色是GPaaS 平台，数据交换共享平台是VPaaS 的一部分。二者相结合，可以将海量城市数据在云端实现汇集融通计算，在提高城市智慧体运行速度的同时也大大降低了运行成本。我将应用管理平台和数据交换共享平台的定位总结如下：

• 应用管理平台向下统一纳管所有计算资源。实现计算资源统一分配调度。这些计算资源以多个机房内托管的虚拟机或者物理机的形式提供。应用管理平台应提供资源监控面板，并在底层计算资源出现问题时发送报警信息。

• 应用管理平台向上承载包括数据交换共享平台在内的所有智慧城市应用系统。提供统一风格的管理面板，以及丰富的自动化运维能力，最大程度降低应用运维管理的难度。智慧城市应用可以以极低的代价迁移到应用管理平台上来，能够实时统计应用的访问流量和资源占用情况，实现计算资源面向应用按需分配，自动调整。

• 应用管理平台横向延伸到各个城市部门。数据交换共享平台需要借助应用管理平台的这一能力，与城市部门现有 IT 系统接驳。

• 应用管理平台可以接纳老旧遗留系统。对于无法直接迁移到应用管理平台的各类老旧遗留系统，比如 Windows 应用等，应可以至少做到逻辑层面的接入，能够以统一风格的面板进行简单管理，以及健康检测等监控能力。

落地过程与价值体现

我们选型并对比了多款 PaaS 平台类产品，最终选择了 Rainbond 。回顾当时的选型过程，以及系统建成到现在的使用体验，我将其优势总结如下：

• 易用性好：Rainbond 是多家选型产品中，易用性做的最好的一款产品。一站式的产品化体验让我们在智慧城市应用的开发部署，乃至后期的运行维护工作中都大大降低了学习成本。数据交换共享平台这个核心应用，仅用不到一周的时间，就完成了向云端的迁移。

• 强大的自动化运维能力：在运维管理方面，其自动化运维能力非常优秀，节省了大量运维成本，使运维效率成倍提升。

• 可观测性：Rainbond 提供了全面的监控报警系统，无论是计算资源还是上层的应用系统，一旦出现问题都可以很快暴露出来。结合自动化运维能力，问题应用系统可以做到自愈自恢复。而通过观察应用系统访问量和资源消耗情况，可以更合理的进行资源分配工作。

• 开源生态：Rainbond 本身是个开源产品，也拥抱开源社区生态。其内部的应用商店系统，提供了大量我们需要的第三方中间件，这些中间件可以一键部署到应用管理平台上去，这节约了大量的时间和精力。否则基于服务器从零搭建这些中间件系统非常耗时耗力。

基于 Rainbond 建设的应用管理平台于 2019年11月落地交付使用。这套应用管理平台底层对接了3个不同的集群，分别是开发测试环境、普通生产环境和涉密生产环境。时至今日，其上部署的各类城市应用已经超过了 100 套，组件数量超过500个。

最先被迁移到应用管理平台上的数据交换共享平台。向开发测试环境迁移的过程比较轻松，我们投入了两名开发人员、两名运维人员，在好雨科技交付工程师的配合下，基于源代码就将所有的组件部署到了应用管理平台上。所有的学习和迁移工作只持续了一周左右就完成了。接下来要考虑的，是在生产环境中部署这套应用系统。我们在这里借助了 Rainbond 内部组件库提供的能力，将开发测试环境中的数据交换共享平台，发布到了内部组件库中，在生产环境中就可以一键部署了。后续的升级操作也都借由应用模版配套的版本管理功能完成，这极大的节约了部署升级成本。

数据交换共享平台需要借助平台能力，延伸到各个城市部门接驳其已有的 IT 系统。最开始 Rainbond 并不支持这个特殊的需求，最终定制了特制的网关，使数据交换共享平台可以通过网关和城市部门已有的 IT 系统交互。

数据交换共享平台部署形态：

在应用的运维管理方面，最让我们觉得好用的，是 Rainbond 提供的统一网关配置功能。通过非常简单的配置，就可以将平台上部署的应用系统对外暴露服务地址。而且经过了定制，我们使用的 Rainbond 网关支持了国密证书，使得我们在安可方面的要求也得到了满足。

经过长时间的考验，基于 Rainbond 建设的应用管理平台的稳定性得到了肯定。尤其是在2020年新冠疫情爆发时，短时间开发部署的外来人口统计系统，也在应用管理平台的支持下，经受住了大并发考验，完成了统计任务。

实战应对疫情考验

2020年2月，由于复工返岗高峰的到来，大规模的人口流动重新启动，为遏制疫情蔓延扩散，做好外来返工人员的防控和服务工作，咸阳市需要用最短的时候完成咸阳市外来人口登记系统的开发和上线，并在3天内完成整个咸阳市130万人信息上报和管控服务。

咸阳市外来人口登记业务是一个前后端分离的业务系统。主要包含了前端页面、后台服务、缓存、数据库、短信业务5个服务组件。

此时，应用管理平台已经落地了半年，我们已经能够非常熟练的基于 Rainbond 进行开发和部署，所以业务的开发上线并没有遇到阻碍，我们很快就完成了业务的上线。

Rainbond提供服务组件的伸缩功能，只需要一键，就可以为当前服务组件快速伸缩出多个实例，并且自动提供负载均衡。为了能够让业务流量过大时，可以自动扩展实例数量，我们还设置了基于内存使用率来触发的自动伸缩功能。在运维层面更加自动化。这将大幅度降低单个实例处理业务的压力。

在咸阳市外来人口登记业务的所有组件中，我们为前端页面、后台服务这两个服务组件都伸缩了最多5个实例，这两个服务组件也是经常进行实时更新的组件，基于多个实例，Rainbond提供滚动更新的功能，使业务的升级不会影响到线上的业务运行。

为了更好的监控“咸阳市外来人口登记业务”各个服务组件的压力情况，我们为前端页面、后台服务、数据库分别安装了Rainbond自带的服务实时性能分析插件。业务运行期间，这个插件为我们带来很多的有用信息，多次帮助开发人员发现业务系统的不足之处，使开发人员可以在业务雪崩宕机之前修正代码并上线。

对于前端页面、后台服务这样的基于Http协议提供服务的组件，插件将提供平均响应时间、吞吐率、在线人数三项实时数据，以及最近5分钟耗时URL排行、历史数据等持续性数据。

整个填报期间，4套业务系统平均在线人数保持在4000人以上，峰值达到5000+，经由统一网关负载的总流量超过 20000。

总结和期待

Rainbond 满足了咸阳市大数据管理局对应用管理平台的预期，运行至今非常稳定。但是，当管理应用系统上百套后后，我们对应用整体监控提出更高要求，需要从更高维度了解所有应用系统运行情况，我了解到他们有更高维度的大屏产品，希望在二期建设过程中，能解决这个问题。

关于Rainbond

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

已有上百家企业使用Rainbond管理关键业务场景，涵盖制造、能源、高校、公安、政府、交通、军工等十几个行业。客户有 京东方、百胜中国、中航信、中公高科等大型企业。

一.离线交付的痛点

在传统行业，如政府、能源、军工、公安、工业、交通等行业，为了防止数据泄露和运行安全考虑，一般情况下网络会采取内外网隔离的策略，以防范不必要的风险，毕竟在安全防护方面，网络物理隔离是网络安全防御最有效的手段，而网络隔离在软件交付过程中，对于外部软件开发厂商来说将会带来一系列的交付难题，也增加大量成本投入。例如：

1. 现场安装部署和验收测试，效率低下

交付过程中需要将应用程序及依赖的所有资源安装到离线客户环境，而客户环境有可能是物理服务器、虚拟机、私有云及K8s容器等各种环境，加上离线环境网络的限制，就会导致离线环境安装和部署效率低下。由于安装配置过程繁复，容易出错，在最终交付环境中需要重新进行验证测试工作，也需要浪费很多时间。如果部署的是微服务架构的应用系统复杂性更高，工作量还会加倍。

2. 离线环境定制开发和产品升级，成本高

定制开发需要开发人员投入，成本本来就高，在离线环境需要根据客户反馈持续迭代，迭代过程产品不断升级，每升级一次就要走一次安装部署和验证测试过程，成本很高。如果有些工作必须驻场开发，成本更高。

3. 网络不通，无法远程运维

交付完成后，应用需要持续运维，保障运行稳定性和功能持续可用，在网络无法联通的情况下，出任何问题都需要安排人员现场支持，甚至需要安排人员长期驻场。

二.技术选型

上述问题的根本原因是因为，应用系统的多环境适配、应用安装部署、应用升级、应用运维等操作自动化程度不高，需要大量人员手工操作，所以效率很低，解决问题的重点在解决应用管理的自动化。 当前，云原生技术已经越来越成熟，而云原生技术主要解决的就是应用管理的自动化问题，具体有两种开源实现方案 ： 1. Rancher+Helm

Rancher是一款K8s管理工具，他提供K8s的管理UI，包管理使用Helm。对应离线交付的问题，Rancher可以安装在多种运行环境（物理服务器、虚拟机、私有云），并且提供部分应用自动化运维功能，它可以解决 多环境适配和 应用运维问题，而 应用安装部署和 应用升级问题可以通过Helm包解决。

2. Rainbond+应用模版

Rainbond是“以应用为中心”的应用管理平台，应用模版是Rainbond对应用打包的方案，Rainbond提供应用的全生命周期管理（应用开发、应用编排、应用交付和应用运维）。Rainbond可以部署到各种运行环境上（物理服务器、虚拟机、私有云），还可以部署到已有K8s集群和Ranchar上，解决客户多环境适配问题；Rainbond提供应用运维面板解决应用运维问题，使用比较简单，不需要懂容器概念；Rainbond的应用模版是一个亮点，只要在Rainbond上运行起来的应用就可以一键发布成应用模版，简化了应用模版的制作，而且应用模版可以导出离线包，特别适合离线环境的 应用安装部署和 应用升级。

下面分别比较一下两个方案

Rainbond相比Rancher最大的优点就是易用性，不需要学习K8s和容器相关技术和概念，另外，Rainbond提供的一体化开发环境和模块编排功能，能大幅度提高定制开发的效率。Rancher最大的优点是完全兼容K8s体系，如果了解K8s能很快上手。

Helm和应用模版比较

对比项	Helm	应用模板
安装和升级	少量配置	全自动
制作流程	人工编写	全自动
导出和导入离线包	不支持	支持
配置调整	支持预定义的配置调整	支持
模块定制	不支持	支持
兼容其他K8s版本	兼容	需要预先安装Rainbond

Rainbond的应用模版 跟 OAM的设计思路完全一致，“以应用为中心”的设计理念，屏蔽掉容器基础设施的复杂性和差异性，为平台的使用者带来低心智负担的、标准化的、一致的应用管理与交付体验。

综合对比，在离线交付场景Rainbond+应用模版的方案优势明显，下面我们结合实际例子，来讲解Rainbond+应用模版交付离线客户的整个过程。

三.使用Rainbond应用模版进行离线环境的应用交付

基于Rainbond进行离线环境的应用交付，只需将开发环境已开发好的业务发布至应用市场，基于应用市场导出应用模板的离线包，在交付环境中进行导入操作，导入后基于应用市场一键安装即可自动运行。

预先准备环境

• 拥有两套Rainbond集群，模拟开发环境及交付环境(开发环境为在线环境，交付环境为离线环境)。

• 开发环境安装，参考 在线安装 文档；

• 交付环境安装，参考 离线安装 文档；

• 拥有U盘、光盘等离线环境下应用模板离线包传输介质。

1.业务部署 整个流程始于开发环境，我们首先需要将业务搬迁至Rainbond之上。在开发环境基于部署自己的业务，可以支持源代码或是镜像。当前以Spring Cloud微服务框架 Pig 为例，部署参考SpringCloud Pig 在Rainbond部署及应用制作。

2.应用发布

将开发测试环境已开发完成的应用发布至内部组件库：点击应用左侧导航栏 发布 按钮，选择 发布到组件库 ，该过程需要 新建应用模板，应用模板定义了以下信息:

选项名	说明
名称	定义应用名称（必填）
发布范围	应用模板的可见范围，当前团队为当前团队可见，企业所有团队可见（必选）
分类标签	应用标签，可按照架构、行业、部署方式进行分类
简介	应用描述，帮助使用者了解此应用
Logo	应用的Logo图片

创建应用模板后定义应用发布版本：

选项名	说明
版本号	当同应用多次发布时，如果版本号相同，则会覆盖已发布的版本，如果不同，将发布为新版本，应用升级或回滚时，平台根据版本判断（必填）
版本别名	应用别名，例如 高级版，初级版
版本说明	当前发布版本的说明，可区分不同版本的功能差异等信息

发布组件模型配置：

选项名	说明
连接信息	当连接信息中出现密码类的信息，可选择每次部署时自动生成随机值
环境变量	编辑该组件默认的环境变量
伸缩规则	定义该组件可伸缩的最大最小节点数，及节点伸缩步长，最小安装内存限制。

发布插件模型信息：

要发布的应用中其组件携带有插件时，会进行展示并在发布过程中跟随组件发布。

所有信息配置完毕后，点击发布按钮进行发布，业务开发过程中定义的组件间依赖关系、环境配置、持久化存储、插件、运行环境及上述定义的所有信息都将会被打包发布。

3.应用导出

将应用模板进行本地化导出，在首页应用市场中找到已发布的应用，点击最后方扩展按钮，选择导出应用模板，选择应用版本后点击应用模板规范下的导出按钮，导出过程完全自动化，待导出完成后点击下载按钮即可将应用模板下载至本地，保存至U盘等移动存储设备中，带到离线交付环境中去。

接下来进入离线交付流程，交付人员携带着装有离线包的U盘等移动存储设备，开始导入应用模版。

4.应用导入

使用已导出的应用模板在交付环境中导入，点击应用市场界面的离线导入按钮，选择本地的应用模板上传，上传完毕后选择导入范围： 企业或团队，企业为当前交付环境所有人可见，团队为指定团队下的人员可见；点击确认导入即进入自动化导入步骤。

5.一键部署

应用导入后点击安装按钮在当前交付环境即可一键部署该业务系统，该环境业务运行环境与开发环境完全一致，到此完成离线环境下的软件交付。

6.增量升级

软件在更新迭代过程中需要进行某些模块的升级，进行此类升级时即可使用增量升级来节省发布及导入导出时间。

要达成增量升级的效果，需要重新进行应用发布操作，选择之前已创建的应用模板，修改版本号，如之前版本设置为2.9，则此次发布设置为3.0。

在应用发布步骤选择需要进行升级的组件进行发布，而不需要选择所有组件。发布完成后，导出新版本的应用模版离线包，在交付环境中再次导入。

交付环境导入后，平台会对应用模板不同版本进行对比，并通过应用拓扑图中的待升级选项提示用户进行升级。展示版本间属性变更情况，用户选择需要升级的版本进行升级即可，平台将自动执行升级操作，变更组件构建版本。

升级过程中不会变动环境配置类信息，这类信息需要人为改动才会生效：

• 环境变量的值

• 配置文件的内容

• 持久化存储

7.一键回滚

在升级版本上线后出现异常情况需要回滚时，平台提供了一键回滚功能，在升级记录界面选择对应记录点击回滚按钮即可对升级操作进行回滚。

在回滚的过程中，新增组件并不会被删除，如需变更，需要人为操作。

8.应用运维功能

软件产品交付完成以后需要进行长期的运维，在运维层面，交付人员需要考虑服务的可用性、可伸缩性、资源监控，Rainbond提供了诸多运维功能，例如：

• 服务性能分析

  通过Rainbond插件机制扩展性能分析功能，服务实时性能分析插件运行在目标分析服务同一个网络空间内，监控网卡的流量来统计分析服务的工作性能，对服务本身的工作流程和性能无影响，收集服务的平均响应时间，吞吐率等主要指标。

• 资源监控报警

  基于 Prometheus 对平台及业务进行监控，基于 ETCD动态发现 需要监控的 targets，自动配置与管理 Prometheus 服务。

• 实例伸缩

  对服务组件进行垂直伸缩或水平伸缩，在流量高峰期灵活进行扩容。

• 网关管理

  应用网关支持灰度发布和A/B测试功能。

四.场景拓展

上面的例子主要针对常见的离线软件交付场景，但在真实的离线交付场景中，还可能存在以下场景，如：

• 离线模块定制，每个客户交付的模块不一定，根据需要在客户现场开启或关闭模块，或者模块编排。

• 离线定制开发，在离线场景下进行完整的软件开发过程，包括源码管理、源码编译、开发测试环境管理、团队协作、版本发布流程等。

上面两个功能定制场景，通过Rainbond也可以支持，大家可先自行探索。或者关注公众号「好雨云」，后续会发布上述场景的详细教程。

五.总结

本文我们分析了离线交付场景的问题，对比了可能的技术方案，并使用一个例子完整讲解离线交付全过程，整个过程自动化程度很高。使用Rainbond进行离线交付肯定可以提高效率，但到底在哪些方面提高我们的效率，我再总结一下：

• 离线环境应用系统一键导出和导入

  交付过程中只需要携带基于Rainbond导出的应用模板离线包在交付环境进行导入，即可一键安装整套业务系统。

• 开发环境和离线环境完全一致

  Rainbond屏蔽了底层环境的差异，基于应用模板进行交付，模板对应用的运行环境、依赖关系进行打包，开发环境和离线环境完全一致，不需要进行重复性测试。

• 一体化客户定制环境

  软件交付过程中，不同的客户会有不同的定制需求，也就意味着需要为不同客户开发不同的模块，这些定制的模块在不同项目中都不尽相同，通过Rainbond提供的应用编排，就可以针对不同客户编排和开启不同功能模块；如果需要定制开发，就可基于交付环境已部署的Rainbond直接进行离线代码开发工作，包括源码编译、配置组件运行环境等，在交付环境中完成所有定制工作。

• 离线环境客户持续交付

  对于项目实施团队而言，在实施过程中需要不断将 新功能、缺陷修复 等快速落实到交付环境或用户手中，传统的持续交付过程中，离线环境下需要交付人员驻场，手动执行更新上线操作，该过程不仅增加了交付时间，且长期的手动执行操作会增加部署的风险；而Rainbond的持续交付能力，能够实现应用后续的增量导入、导出和版本升级，能够带来以下优势:

  • 通过自动化方式实现，有效缩短代码提交到部署上线的时间。

  • 软件在整个生命周期内都处于可部署升级的状态。

  • 简化升级步骤，使软件版本更加清晰。

  • 让交付过程成为可预期的、可视化的过程。

• 离线环境下自动化运维

  服务高可用，自容错和自恢复机制，减少人工运维，提高业务系统稳定性。

六.关于Rainbond

Rainbond是一个开源的云原生应用管理平台，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

已有上百家企业使用Rainbond管理关键业务场景，涵盖制造、能源、高校、公安、政府、交通、军工等十几个行业。客户有 京东方、百胜中国、中航信、中公高科等大型企业。

GitLab和Rainbond整合实现一体化开发环境

GitLab擅长源代码管理，Rainbond擅长应用自动化管理，整合Gitlab和Rainbond就能各取所长，本文详细讲述如何整合Gitlab和Rainbond，并通过整合实现一体化开发环境。

一.通过Rainbond一键安装 Gitlab

Rainbond作为应用运行环境，Gitlab可以运行在Rainbond之上，为了便于Gitlab安装，我们制作了Gitlab安装包放到了Rainbond的应用市场，实现Gitlab的一键安装。

1. 安装Rainbond，安装步骤。

2. 从应用市场搜索“Gitlab”，点击安装，一键完成Gitlab所有安装和配置工作，包括数据安装和初始化。
   
   

3. 安装完成，通过Rainbond管理和运维Gitlab。
   
   

二.Rainbond源码构建对接Gitlab Oauth，实现一键代码部署

使用过Rainbond的小伙伴一定知道，在Rainbond上创建组件有三种方式：源代码创建、镜像创建、应用市场创建。

源码构建方式通过配置源码地址实现代码构建，Gitlab虽然可以提供源码地址，但构建新应用需要拷贝源码地址及设置用户名密码，这个过程很麻烦，也容易犯错。

为了与 GitLab 配合有更好的体验，Rainbond做了产品化的支持，通过OAuth2.0协议与GitLab进行对接。

1.配置GitLab Applications

进入 User Settings → Applications

选项名	填写内容	说明
Name	Rainbond	填写自定义的 Application 名称
Redirect URI	https://IP:7070/console/oauth/redirect	回跳路径，用于接收第三方平台返回的凭证
Scopes	api、read_user、read_repository	GitLab的权限设置，需要开启 api、read_user、read_repository

创建后请保存 Application ID 和 Secret，后面会用到。

使用私有化部署 Rainbond 时，需配置 GItLab 允许向本地网络发送 Webhook 请求

进入 Admin area → settings → NetWork → Outbound requests

勾选 Allow requests to the local network from hooks and services 选项即可

2.配置Rainbond OAuth

进入 Rainbond 首页企业视图 → 设置 → Oauth 第三方服务集成 → 开启并查看配置 → 添加

选项名	填写内容	说明
OAuth类型	gitlab	认证的 Oauth 类型
OAuth名称	自定义（GitLab-Demo）	填写自定义的 Oauth 服务名称
服务地址	http://xx.gitlab.com	GitLab 服务访问地址
客户端ID	上一步获取的Application ID	GitLab 生成的 Application ID
客户端密钥	上一步获取的Application Secret	GitLab 生成的 Application Secret
平台访问域名	使用默认填写内容	用于OAuth认证完回跳时的访问地址

3.Rainbond OAuth认证

进入 Rainbond 首页企业视图 → 个人中心 → OAuth 账户绑定 → 对应账号 → 去认证

4.对接后效果

接下来展示Rainbond与Gitlab对接后平台的效果图。

当我们对接成功后，进入基于源码构建的页面会展示下图中的效果，展示所有的仓库列表。

通过Rainbond OAuth2与GitLab进行对接后，在Rainbond平台登录不同的账号时，需进入个人中心认证，认证后Rainbond会根据账号不同的权限展示不同的代码仓库。

三.Rainbond对接Gitlab WebHook，自动触发构建

当我们完成整合Rainbond 和 Gitlab Oauth ，选择指定仓库，点击创建组件，可选择代码版本（自动获取代码分支以及tag）和 开启自动构建。

创建完成后在组件中配置WebHook自动构建，提交代码，Commit信息包含“@deploy”关键字，就可以触发WebHook自动构建。

Commit信息关键字触发GitLab WebHook原生是不支持的，在这之前有社区用户提出在提交代码触发构建时，每一次提交都会触发构建，用户并不想这样做，所以Rainbond研发团队研发了根据提交的Commit信息包含关键字去触发自动构建。

下图中展示了用户从创建组件到持续开发的整个流程。

四.总结

一体化开发环境的能力：

• 代码管理：代码相关的所有管理功能，提供web界面的管理（Gitlab）

• wiki ：在线编辑文档，提供版本管理功能（Gitlab）

• 问题管理：Issue管理（Gitlab）

• 持续集成：代码自动编译和构建（Rainbond）

• 环境管理：快速搭建开发或测试环境，保证开发、测试、生产环境一致性（Rainbond）

• 架构编排：无侵入的Service Mesh架构编排（Rainbond）

• 模块复用：通过组件库 实现公司内部模块、应用、服务积累和复用，同时实现了软件资产管理（Rainbond）

• 持续交付：开发、测试、生产环境持续交付流程（Rainbond）

• 应用管理：应用监控和运维面板（Rainbond）

• 团队管理： 多团队管理，成员、角色管理（Rainbond）

一体化开发环境的价值：

1. 开箱即用

2. 让开发团队专注在写业务代码，不要在环境上浪费时间

3. 应用粒度抽象，使用简单，上手快

4. 过程自动化，提高操作效率（持续集成、环境管理、持续交付等）

五.感谢以下开源项目

Rainbond：开源云原生应用管理平台 https://www.rainbond.com/

Gitlab：知名代码仓库 https://about.git‍lab.cn/