Merge dev-zh into main(for Chinese localization live version)

.github/labeler.yml

@@ -29,6 +29,6 @@ lang/pt:
 - content/pt-br/*
 
 lang/zh:
-- content/zh/*
+- content/zh-cn/*
 
 

CODEOWNERS

@@ -37,4 +37,4 @@
 /content/es/ @raelga @electrocucaracha @krol3
 
 # Approvers for Chinese contents
-/content/zh/ @hanyuancheung @Jacob953 @Rocksnake @Submarinee
+/content/zh-cn/ @hanyuancheung @Jacob953 @Rocksnake @Submarinee

config.toml

@@ -102,6 +102,13 @@ languageName ="Español(Spanish)"
 contentDir = "content/es"
 weight = 6
 
+[languages.zh-cn]
+title = "Cloud Native(云原生) Glossary"
+description = "CNCF 云原生 Glossary 项目旨在用作讨论云原生应用程序时常用术语的参考"
+languageName ="中文(Chinese)"
+contentDir = "content/zh-cn"
+weight = 7
+
 [markup]
   [markup.goldmark]
     [markup.goldmark.renderer]

content/zh-cn/_index.md

@@ -0,0 +1,31 @@
+
+---
+title: "云原生词汇表"
+---
+
+# 云原生词汇表
+
+云原生词汇表是由 CNCF 商业价值小组委员会 (BVS, Business Value Subcommittee) 领导的一个项目。该项目目的是在不需要先验技术知识的情况下，以清晰通俗的语言解释云原生概念。
+
+<p><img class="mt-5" src="/images/homepage/stage.jpg" alt="A woman and two men presenting technical info on a stage"></p>
+
+## 社区贡献
+
+对本机词汇表的更改、添加和改进对所有人开放。我们使用由 CNCF 管理的社区驱动流程来开发和完善这个共享词典。该词汇表提供了一个厂商中立的平台，用于管理云原生技术的共享词汇表。欢迎所有参与者根据本项目的目的和章程作出贡献。
+
+任何想要贡献的人都可以提交 GitHub issue 或 创建 PR。欲了解更多信息，请查看 [如何贡献](/zh-cn/contribute/) 和遵循 [样式指南](/zh-cn/style-guide/)，并加入 CNCF Slack 中的 #glossary 频道。这里有 #glossary-localizations 频道，供想要将 glossary 翻译成母语的人使用。
+
+## 致谢
+
+云原生词汇表可从 CNCF 营销委员会 (CNCF Marketing Committee) (商业价值小组委员会) 获得,
+包括 [Catherine Paganini](https://www.linkedin.com/in/catherinepaganini/en/), [Chris Aniszczyk](https://www.linkedin.com/in/caniszczyk/),
+[Daniel Jones](https://www.linkedin.com/in/danieljoneseb/?originalSubdomain=uk), [Jason Morgan](https://www.linkedin.com/in/jasonmorgan2/), [Katelin Ramer](https://www.linkedin.com/in/katelinramer/), [Mike Foster](https://www.linkedin.com/in/mfosterche/?originalSubdomain=ca), [Seokho Son](https://www.linkedin.com/in/seokho-son/) 以及更多的贡献者. 如想获得完整的贡献者名单, 请跳转至 [GitHub Pages 页](https://github.com/cncf/glossary/graphs/contributors).
+
+中文版的云原生词汇表由 [Chester Cheung](https://github.com/hanyuancheung), 
+[Brian Yan](https://github.com/Rocksnake), 
+[Jacob953 Yu](https://github.com/Jacob953), 
+[Submarinee](https://github.com/Submarinee) 和其他贡献者维护。
+
+## 协议
+
+所有代码贡献都在 Apache 2.0 许可下。文档在 CC BY 4.0 下分发。

content/zh-cn/blue_green_deployment.md

@@ -0,0 +1,25 @@
+---
+title: 蓝绿部署
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+蓝绿部署是一种以最小的停机时间更新运行中的计算机系统的策略。
+运营商维护两个环境，被称为 "蓝" 和 "绿"。一个为生产流量服务（所有用户目前正在使用的版本），而另一个则被更新。
+一旦在非活动（绿色）环境中的测试结束，生产流量就会被切换过来（通常通过使用负载平衡器）。
+请注意，蓝绿色的部署通常意味着一次性切换整个环境，包括许多服务。
+令人困惑的是，有时这个术语被用于系统内的单个服务。为了避免这种歧义，在提到单个组件时，最好使用 "零停机部署" 一词。
+
+## 解决的问题
+
+在更新那些由于缺乏向后兼容性而必须“同步”改变的软件时，蓝绿部署允许最小的停机时间。
+例如，蓝绿部署适用于一个由网站和数据库组成的在线商店，该商店需要更新，但新版本的数据库不能与旧版本的网站一起使用，反之亦然。
+在这种情况下，两者需要同时改变。
+如果在生产系统上这样做，客户会注意到停机时间。
+
+## 如何帮助
+
+对于需要以最小的停机时间进行更新的非云原生软件来说，蓝绿部署是一种合适的策略。
+然而，它的使用通常是一种 "气味"，即遗留软件需要重新设计，以便组件可以单独更新。

content/zh-cn/canary_deployment.md

@@ -0,0 +1,27 @@
+---
+title: 金丝雀部署
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+金丝雀部署是一种部署策略，开始时有两个环境：一个有实时流量，另一个包含没有实时流量的更新代码。
+流量逐渐从应用程序的原始版本转移到更新版本。
+它可以从移动 1% 的实时流量开始，然后是 10%，25%，以此类推，直到所有流量都通过更新的版本运行。
+企业可以在生产中测试新版本的软件，获得反馈，诊断错误，并在必要时快速回滚到稳定版本。 
+
+“金丝雀” 一词是指 “煤矿中的金丝雀” 的做法，即把金丝雀带入煤矿以保证矿工的安全。
+如果出现无味的有害气体，鸟就会死亡，而矿工们知道他们必须迅速撤离。
+同样，如果更新后的代码出了问题，现场交通就会被 "疏散" 回原来的版本。
+
+## 解决的问题
+
+无论测试策略多么彻底，在生产中总是会发现一些bug。
+将100%的流量从一个应用程序的一个版本转移到另一个版本，可能会导致更有影响的失败。
+
+## 如何帮助
+
+金丝雀部署允许企业在将大量流量转移到新版本之前，查看新软件在真实世界场景中的表现。
+这种策略使企业能够最大限度地减少停机时间，并在新部署出现问题时快速回滚。
+它还允许更深入的生产应用测试，而不会对整个用户体验产生重大影响。

content/zh-cn/cloud_computing.md

@@ -0,0 +1,17 @@
+---
+title: 云计算
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+云计算是一种通过互联网按需提供计算资源（如 CPU、网络和磁盘功能）的模型。 云计算使用户能够在远程物理位置访问和使用计算能力。 AWS、GCP、Azure、DigitalOcean 等云提供商都为第三方提供了在多个地理位置租用计算资源的能力。
+
+## 解决的问题
+
+传统上，组织在尝试扩展计算能力的使用时面临两个主要问题。他们要么获取、支持、设计和支付托管物理服务器和网络的设施，要么扩展和维护这些设施。云计算允许组织将部分计算需求外包给另一个组织。
+
+## 如何帮助
+
+云提供商为组织提供按需租用计算资源并按使用付费的能力。 这允许进行两项主要创新：组织可以在不浪费时间计划和花费金钱或资源在新的物理基础设施上的情况下进行尝试，并且他们可以根据需要和按需[扩展](/zh-cn/scalability/)。云计算允许组织根据需要采用尽可能多或尽可能少的基础设施。

content/zh-cn/cloud_native_apps.md

@@ -0,0 +1,27 @@
+---
+title: 云原生应用程序
+status: Completed
+category: 概念
+---
+
+## What it is
+
+云原生应用程序专门设计用于利用 [云计算](/zh-cn/cloud_computing/) 中的创新。
+这些应用程序可以轻松地与其各自的云架构集成，充分利用云的资源和 [可扩展性](/zh-cn/scalability/) 功能。
+它还指利用云计算驱动的基础设施创新的应用程序。
+今天的云原生应用程序包括在云提供商的数据中心和本地云原生平台上运行的应用程序。
+
+## Problem it addresses
+
+传统上，本地环境以相当定制的方式提供计算资源。
+每个数据中心都有与特定环境 [紧密耦合](/tightly_coupled_architectures/) 应用程序的服务，通常严重依赖于基础设施的手动配置，例如 [虚拟机](/zh-cn/virtual_machine/) 和服务。
+这反过来又将开发人员及其应用程序限制在该特定数据中心。
+不是为云设计的应用程序无法利用云环境的弹性和扩展能力。
+例如，需要手动干预才能正确启动的应用程序无法自动扩展，也无法在发生故障时自动重启。
+
+## How it helps
+
+虽然云原生应用程序没有“一刀切”的路径，但它们确实有一些共性。
+云原生应用程序具有弹性、可管理性，并由配套的云服务套件提供帮助。
+各种云服务实现了高度的 [可观察性](/observability/)，使用户能够在问题升级之前检测和解决问题。
+结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。

content/zh-cn/cloud_native_security.md

@@ -0,0 +1,26 @@
+---
+title: 云原生安全
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+云原生安全是一种将安全性构建到 [云原生应用程序](/zh-cn/cloud_native_apps/) 中的方法。
+它确保安全是从开发到生产的整个应用程序生命周期的一部分。
+云原生安全旨在确保与传统安全模型相同的标准，同时适应云原生环境的特殊性，即快速的代码更改和高度短暂的基础设施。
+云原生安全与称为 [测试左移](/devsecops/) 的实践高度相关。
+
+## 强调的问题
+
+传统的安全模型是根据许多不再有效的假设构建的。
+云原生应用程序变化频繁，使用大量开源工具和库，通常运行在供应商控制的基础设施中，并且会受到快速的基础设施变化的影响。
+代码审查、长质量保证周期、基于主机的漏洞扫描和最后一分钟的安全审查无法与云原生应用程序一起扩展。
+
+## 如何帮助
+
+云原生安全引入了一种新的工作方式，通过从传统的安全模型迁移到发布周期的每个步骤都涉及安全的模型来保护应用程序。
+人工审核和检查在很大程度上被自动扫描所取代。
+快速代码发布管道与在编译之前扫描代码以查找漏洞的工具集成在一起。
+开源库从受信任的来源中提取并监控漏洞。
+云原生安全模型不是减缓变化，而是通过频繁更新易受攻击的组件或确保定期更换基础设施来拥抱它。

content/zh-cn/cloud_native_tech.md

@@ -0,0 +1,23 @@
+---
+title: 云原生技术
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+云原生技术，也称为云原生技术栈，是用于构建 [云原生应用程序](/zh-cn/cloud_native_apps/) 的技术。
+使组织能够在公共云、私有云和混合云等现代动态环境中构建和运行可扩展的应用程序，他们坚持“云的承诺”并充分利用云计算的优势。
+它们从头开始设计，以利用云计算和容器的功能，服务网格、微服务和不可变的基础设施就是这种方法的例证。
+
+## 强调的问题
+
+云原生技术栈有许多不同的技术类别，可应对各种挑战。
+如果你看看 [CNCF 云原生全景图](https://landscape.cncf.io/)，你会看到它涉及到多少不同的领域。
+但在高层次上，它们解决了一组主要挑战：传统 IT 运营模式的缺点。挑战包括难以创建可扩展、容错、自我修复的应用程序，以及资源利用效率低下等。
+
+## 如何帮助
+
+虽然每种技术都解决了一个非常具体的问题，但作为一个整体，云原生技术支持松散耦合的系统，这些系统具有弹性、可管理性和可观察性。
+结合强大的自动化，它们使工程师能够以最少的工作频繁且可预测地进行高影响力的更改。
+云原生系统的理想特性更容易通过云原生堆栈实现。

content/zh-cn/cluster.md

@@ -0,0 +1,22 @@
+---
+title: 集群
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+集群是一组计算机或应用程序，它们为一个共同的目标一起工作。
+在云原生计算的背景下，这个术语最常被应用于 Kubernetes。
+Kubernetes 集群是一组服务（或工作负载），它们在各自的容器中运行，通常在不同的机器上。
+所有这些 [容器化](/zh-cn/containerization/) 服务的集合，通过网络连接，代表一个集群。
+
+## 强调的问题
+
+在单台计算机上运行的软件会出现单点故障——如果这台计算机崩溃了，或者有人不小心拔掉了电源线，那么一些关键的业务系统就可能被下线。
+这就是为什么现代软件通常被构建为 [分布式应用](/zh-cn/distributed_apps/)，以集群的形式组合在一起。
+
+## 如何帮助
+
+集群式的分布式应用在多台机器上运行，消除了单点故障。但构建分布式系统真的很难，事实上，它本身就是一门计算机科学的学科。
+对全球系统的需求和多年的试验和错误导致了一种新的技术栈的发展：[云原生技术](/zh-cn/cloud_native_tech/)，这些新技术是使分布式系统的操作和创建更容易的构件。

content/zh-cn/container-image.md

@@ -0,0 +1,26 @@
+---
+title: 容器镜像
+status: Feedback Appreciated
+category: 概念
+---
+
+## 是什么
+
+容器镜像是一个不可改变的静态文件，包含创建容器的依赖性。
+这些依赖可能包括一个可执行的二进制文件、系统库、系统工具、环境变量和其他必要的平台设置。
+容器镜像是应用程序容器化的结果，通常存储在容器注册表中，在那里可以下载并使用容器运行时接口（CRI）作为一个孤立的进程运行。
+容器镜像框架必须遵循开放容器倡议（OCI）定义的标准模式。
+
+## 强调的问题
+
+传统上，应用服务器是按环境配置的，而应用则被部署到这些环境中。
+环境之间的任何错误配置都是有问题的，常常导致停机或部署失败。
+一个应用程序的环境需要是可重复的和定义明确的；否则，与环境有关的错误的机会就会增加。
+当应用程序的环境定义不足或不准确时，应用程序的横向和纵向扩展就会成为挑战。
+
+## 如何帮助
+
+容器镜像将一个应用程序与它的任何运行时的依赖性捆绑在一起，例如一个应用程序服务器。
+这提供了所有环境的一致性，包括开发人员的机器。
+容器镜像可用于实例化所需的多个容器，允许更大的可扩展性。
+

content/zh-cn/container.md

@@ -0,0 +1,26 @@
+---
+title: 容器
+status: Completed
+category: 技术
+---
+
+## 是什么
+
+容器是由计算机操作系统管理的具有资源和能力限制的运行进程。
+容器进程可用的文件被打包为容器镜像。
+容器在同一台机器上彼此相邻运行，但通常操作系统会阻止单独的容器进程相互交互。
+
+## 解决的问题
+
+在容器可用之前，需要单独的机器来运行应用程序。每台机器都需要自己的操作系统，它占用 CPU、内存和磁盘空间，
+所有这些都是为了让单个应用程序运行。此外，操作系统的维护、升级和启动是另一个重要的工作来源。
+
+## 如何帮助
+
+容器共享相同的操作系统及其机器资源，分散了操作系统的资源开销并创建了物理机器的有效使用。
+这种能力之所以成为可能，是因为容器之间的交互通常受到限制。
+这允许更多的应用程序在同一台物理机器上运行。
+
+但是，有一些限制。由于容器共享相同的操作系统，因此可以认为进程不如替代方法安全。 容器还需要对共享资源进行限制。 为了保证资源，
+管理员必须约束和限制内存和 CPU 的使用，以使其他应用程序不会表现不佳。
+

content/zh-cn/containerization.md

@@ -0,0 +1,24 @@
+---
+title: 容器化
+status: Completed
+category: 技术
+---
+
+## 是什么
+
+容器化是将一个应用程序及其依赖关系捆绑到 [容器图像](/zh-cn/container-image/) 中的过程。
+容器构建过程需要遵守 [开放容器倡议](https://opencontainers.org)(OCI) 标准。
+只要输出的是一个符合这个标准的容器镜像，使用哪种容器化工具并不重要。
+
+## 解决的问题 
+
+在容器盛行之前，企业依靠虚拟机 (VMs) 在一台 [裸机](/bare_metal_machine/) 上协调多个应用程序。
+虚拟机比容器大得多，需要一个管理程序来运行。由于这些较大的虚拟机模板的存储、备份和传输，创建虚拟机模板也很慢。
+此外，虚拟机可能会出现配置漂移，这违反了 [不变性](/immutable_infrastructure/) 的原则。
+
+## 如何帮助
+
+容器图像是轻量级的（与传统的虚拟机不同），容器化过程需要一个带有依赖性列表的文件。
+这个文件可以被版本控制，构建过程也可以自动化，允许一个组织在自动化过程中关注其他优先事项。
+容器镜像由一个唯一的标识符来存储，该标识符与它的确切内容和配置相联系。
+当容器被安排和重新安排时，它们总是被重置为其初始状态，从而消除了配置漂移。

content/zh-cn/containers_as_a_service.md

@@ -0,0 +1,26 @@
+---
+title: 容器即服务
+status: Completed
+category: 技术
+---
+
+## 是什么
+
+容器即服务（CaaS）是一种云服务，有助于使用基于 [容器](/zh-cn/container/) 的 [抽象](/abstraction/) 管理和部署应用程序。
+这项服务可以部署在企业内部或云中。
+
+CaaS 供应商提供了一个框架或协调平台，使容器部署和管理的关键 IT 功能自动化。
+它帮助开发者建立安全和 [可扩展](/zh-cn/scalability/) 的容器化应用。
+因为用户只购买他们需要的资源（调度能力、负载平衡等），他们可以节省资金并提高效率。
+容器创造了一致的环境，以快速开发和交付可以在任何地方运行的 [云原生应用](/zh-cn/cloud_native_apps/)。
+
+## 解决的问题
+
+如果没有 CaaS，软件开发团队需要部署、管理和监控容器运行的底层基础设施。
+
+## 如何帮助
+
+当把容器化应用部署到 CaaS 平台时，用户可以通过日志聚合和监控工具获得对系统性能的可见性。
+CaaS 还包括 [自动扩展](/auto_scaling/) 和协调管理的内置功能。
+它使团队能够建立高可见性和高可用性的 [分布式系统](/zh-cn/distributed_systems/)。
+此外，通过允许快速部署，CaaS 提高了团队的开发速度。在容器确保一致的部署目标的同时，CaaS 通过减少管理部署所需的 [DevOps](/zh-cn/devops/) 资源，降低了工程运营成本。

content/zh-cn/continuous_delivery.md

@@ -0,0 +1,25 @@
+---
+title: 持续交付 (CD)
+status: Completed
+category: 概念
+---
+
+## 是什么
+
+持续交付，通常缩写为 CD，是一套实践，其中代码的变化被自动部署到验收环境中（或者，在持续部署的情况下，部署到生产中）。
+CD 关键是包括确保软件在部署前得到充分测试的程序，并提供一种在认为必要时回滚修改的方法。
+持续集成（CI）是实现持续交付的第一步（也就是说，在测试和部署之前，变化必须干净地合并）。
+
+## 解决的问题
+
+部署 [可靠](/zh-cn/reliability/) 的更新在规模上成为一个问题。
+理想情况下，我们会更频繁地部署，为终端用户提供更好的价值。
+然而，手动操作会使每一个变化都转化为高额的交易成本。
+历史上，为了避免这些成本，企业发布的频率较低，一次部署更多的变化，增加了出错的风险。
+
+## 如何帮助
+
+CD 策略创建了一个完全自动化的生产路径，使用各种部署策略测试和部署软件，如 [canary](/zh-cn/canary_deployment/) 或 [blue-green](/zh-cn/blue_green_deployment/) 发布。
+这使得开发人员可以频繁地部署代码，让他们放心地认为新的修订版已经过测试。
+通常情况下，CD 策略中使用基于主干的开发，而不是功能分支或拉动请求。
+