Merge remote-tracking branch 'upstream/main' into dev-1.24

2022-05-02 10:29:49 -07:00
parent 7f13ad092c a8b640bd6f
commit 5ead53b3e8
141 changed files with 5085 additions and 666 deletions
@@ -16,6 +16,15 @@ date: 2018-10-01
 --->
 **作者**： [Ahmet Alp Balkan](https://twitter.com/ahmetb) (Google)

+<!-- 
+**Update (December 2021):** _Kubernetes now has built-in gRPC health probes starting in v1.23.
+To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
+This article was originally written about an external tool to achieve the same task._
+-->
+**更新（2021 年 12 月）：** “Kubernetes 从 v1.23 开始具有内置 gRPC 健康探测。
+了解更多信息，请参阅[配置存活探针、就绪探针和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。
+本文最初是为有关实现相同任务的外部工具所写。”
+
 <!--
 [gRPC](https://grpc.io) is on its way to becoming the lingua franca for
 communication between cloud-native microservices. If you are deploying gRPC
@@ -3,7 +3,7 @@ layout: blog
 title: "弃用 Dockershim 的常见问题"
 date: 2020-12-02
 slug: dockershim-faq
-aliases: [ '/dockershim' ]
+aliases: [ '/zh/dockershim' ]
 ---
 <!-- 
 layout: blog
@@ -55,8 +55,8 @@ evergreen: true
 <!-- Note that as a new built-in command, `kubectl debug` takes priority over any kubectl plugin named “debug”. You must rename the affected plugin. -->
 请注意，作为新的内置命令，`kubectl debug` 优先于任何名为 “debug” 的 kubectl 插件。你必须重命名受影响的插件。

-<!-- Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug`. For more information about `kubectl debug`, see [Debugging Running Pods](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-running-pod/). -->
-`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh/docs/tasks/debug-application-cluster/debug-running-pod/)。
+<!-- Invocations using `kubectl alpha debug` are now deprecated and will be removed in a subsequent release. Update your scripts to use `kubectl debug`. For more information about `kubectl debug`, see [Debugging Running Pods](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/). -->
+`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh/docs/tasks/debug/debug-application/debug-running-pod/)。

 <!-- ### Beta: API Priority and Fairness -->
 ### 测试版：API 优先级和公平性 {#beta-api-priority-and-fairness)
@@ -1,12 +1,14 @@
 ---
 layout: blog
 title: "更新：弃用 Dockershim 的常见问题"
+linkTitle: "弃用 Dockershim 的常见问题"
 date: 2022-02-17
 slug: dockershim-faq
 ---
 <!-- 
 layout: blog
 title: "Updated: Dockershim Removal FAQ"
+linkTitle: "Dockershim Removal FAQ"
 date: 2022-02-17
 slug: dockershim-faq
 aliases: [ '/dockershim' ]
@@ -312,13 +314,13 @@ runtime where possible.
 <!--
 Another thing to look out for is anything expecting to run for system maintenance
 or nested inside a container when building images will no longer work. For the
-former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the
+former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the
 latter you can use newer container build options like [img], [buildah],
 [kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
 -->
 另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。
 对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案
-(参阅[从 docker cli 到 crictl 的映射](/zh/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))。
+(参阅[从 docker cli 到 crictl 的映射](/zh/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl))。
 对于后者，可以用新的容器创建选项，例如
 [img](https://github.com/genuinetools/img)、
 [buildah](https://github.com/containers/buildah)、
@@ -335,10 +337,10 @@ options are available as you migrate things over.

 <!--
 For instructions on how to use containerd and CRI-O with Kubernetes, see the
-Kubernetes documentation on [Container Runtimes]
+Kubernetes documentation on [Container Runtimes].
 -->
 有关如何在 Kubernetes 中使用 containerd 和 CRI-O 的说明，
-请参阅 [Kubernetes 相关文档](/docs/setup/production-environment/container-runtimes/)
+请参阅 [Kubernetes 相关文档](/docs/setup/production-environment/container-runtimes/)。

 <!--
 ### What if I have more questions?
@@ -353,6 +355,13 @@ to our end user community forum: https://discuss.kubernetes.io/.
 如果你使用了供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。
 对于最终用户的问题，请把问题发到我们的最终用户社区的论坛：https://discuss.kubernetes.io/。

+<!--
+You can discuss the decision to remove dockershim via a dedicated
+[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917).
+-->
+你可以通过专用 [GitHub 问题](https://github.com/kubernetes/kubernetes/issues/106917) 
+讨论删除 dockershim 的决定。
+
 <!--
 You can also check out the excellent blog post
 [Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical
@@ -361,6 +370,24 @@ discussion of the changes.
 你也可以看看这篇优秀的博客文章：[等等，Docker 被 Kubernetes 弃用了?](https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m)
 对这些变化进行更深入的技术讨论。

+<!--
+### Is there any tooling that can help me find dockershim in use
+-->
+### 是否有任何工具可以帮助我找到正在使用的 dockershim
+
+<!--
+Yes! The [Detector for Docker Socket (DDS)][dds] is a kubectl plugin that you can
+install and then use to check your cluster. DDS can detect if active Kubernetes workloads
+are mounting the Docker Engine socket (`docker.sock`) as a volume.
+Find more details and usage patterns in the DDS project's [README][dds].
+-->
+是的！ [Docker Socket 检测器 (DDS)][dds] 是一个 kubectl 插件，
+你可以安装它用于检查你的集群。 DDS 可以检测运行中的 Kubernetes
+工作负载是否将 Docker 引擎套接字 (`docker.sock`) 作为卷挂载。
+在 DDS 项目的 [README][dds] 中查找更多详细信息和使用方法。
+
+[dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket
+
 <!--
 ### Can I have a hug?
 -->
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:transparent;}.cls-2{fill:#040606;}</style></defs><title>kubernetes.io-54664</title><rect class="cls-1" x="-4.55738" y="-4.48481" width="223.25536" height="134.51136"/><path class="cls-2" d="M169.05853,71.307c.23549,6.07483,5.42615,10.38072,14.09569,10.38072,7.0783,0,12.91766-3.06693,12.91766-9.85009,0-4.71846-2.65436-7.49024-8.78885-8.66954l-4.77685-.94382c-3.06756-.59028-5.19066-1.17992-5.19066-3.0079,0-2.00568,2.06471-2.89047,4.65943-2.89047,3.77525,0,5.3081,1.887,5.42678,4.1288H194.951c-.41258-5.89838-5.1304-9.8501-12.73994-9.8501-7.845,0-12.50382,4.30588-12.50382,9.90912,0,6.84157,5.54483,7.96247,10.3217,8.84662l3.95171.70834c2.83082.53062,4.06977,1.35638,4.06977,3.0079,0,1.47444-1.41541,2.94887-4.77748,2.94887-4.89553,0-6.488-2.53631-6.54705-4.71845Zm-27.4259-5.13164a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58415,8.58415,0,0,1,8.61115,8.557q.00009.02706,0,.0541a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M158.79589,81.098h7.49149V50.95811h-7.49149v2.41825a15.58033,15.58033,0,1,0-9.01133,28.37034q.05285.00018.10567,0a15.47693,15.47693,0,0,0,8.90566-2.77179ZM106.59844,66.17532a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473m17.16387-25.47987V53.37636a15.58048,15.58048,0,1,0-9.01195,28.37034q.05251.00018.105,0a15.48233,15.48233,0,0,0,8.90691-2.77179V81.098h7.49023V40.69545ZM96.21772,50.95811H88.72811V81.098h7.49023Zm0-10.26266H88.72811v7.49023h7.49023ZM60.41805,66.17532a8.58414,8.58414,0,0,1,8.557-8.61113q.02673-.00009.05346,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61177q-.02736.00009-.05472,0a8.58412,8.58412,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M77.58067,40.69545V53.37636A15.58033,15.58033,0,1,0,68.56935,81.7467q.05283.00018.10567,0a15.4769,15.4769,0,0,0,8.90565-2.77179V81.098h7.4915V40.69545ZM25.38259,66.176a8.58414,8.58414,0,0,1,8.557-8.61114q.02736-.00009.05472,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.027,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61176q-.02736.00009-.05472,0a8.58413,8.58413,0,0,1-8.61177-8.55641q-.00009-.02768,0-.05535m17.16388,14.9227H50.038V50.95872H42.54647V53.377a15.58048,15.58048,0,1,0-9.01069,28.37035q.0522.00016.10441,0a15.48032,15.48032,0,0,0,8.90628-2.77179Z"/></svg>
@@ -0,0 +1,78 @@
+---
+title: adidas Case Study
+linkTitle: adidas
+case_study_styles: true
+cid: caseStudies
+featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/adidas/banner1.png
+heading_title_text: adidas
+use_gradient_overlay: true
+subheading: >
+  Staying True to Its Culture, adidas Got 40% of Its Most Impactful Systems Running on Kubernetes in a Year
+case_study_details:
+  - Company: adidas
+  - Location: Herzogenaurach, Germany
+  - Industry: Fashion
+---
+
+<h2>Challenge</h2>
+
+<p>In recent years, the adidas team was happy with its software choices from a technology perspective—but accessing all of the tools was a problem. For instance, "just to get a developer VM, you had to send a request form, give the purpose, give the title of the project, who's responsible, give the internal cost center a call so that they can do recharges," says Daniel Eichten, Senior Director of Platform Engineering. "The best case is you got your machine in half an hour. Worst case is half a week or sometimes even a week."</p>
+
+<h2>Solution</h2>
+
+<p>To improve the process, "we started from the developer point of view," and looked for ways to shorten the time it took to get a project up and running and into the adidas infrastructure, says Senior Director of Platform Engineering Fernando Cornago. They found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus.</p>
+
+<h2>Impact</h2>
+
+<p>Just six months after the project began, 100% of the adidas e-commerce site was running on Kubernetes. Load time for the e-commerce site was reduced by half. Releases went from every 4-6 weeks to 3-4 times a day. With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform.</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/adidas/banner2.png"
+  author="FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS"
+>}}
+"For me, Kubernetes is a platform made by engineers for engineers. It's relieving the development team from tasks that they don't want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+In recent years, the adidas team was happy with its software choices from a technology perspective—but accessing all of the tools was a problem.
+{{< /case-studies/lead >}}
+
+<p>For engineers at adidas, says Daniel Eichten, Senior Director of Platform Engineering, "it felt like being an artist with your hands tied behind your back, and you're supposed to paint something."</p>
+
+<p>For instance, "just to get a developer VM, you had to send a request form, give the purpose, give the title of the project, who's responsible, give the internal cost center a call so that they can do recharges," says Eichten. "Eventually, after a ton of approvals, then the provisioning of the machine happened within minutes, and then the best case is you got your machine in half an hour. Worst case is half a week or sometimes even a week."</p>
+
+<p>To improve the process, "we started from the developer point of view," and looked for ways to shorten the time it took to get a project up and running and into the adidas infrastructure, says Senior Director of Platform Engineering Fernando Cornago.</p>
+
+{{< case-studies/quote author="DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS" >}}
+"I call our cloud native platform the field of dreams. We built it, and we never anticipated that people would come and just love it."
+{{< /case-studies/quote >}}
+
+<p>"We were engineers before," adds Eichten. "We know what a typical engineer needs, is craving for, what he or she doesn't want to take care of. For us it was pretty clear. We filled the gaps that no one wants to take care of, and we make the stuff that is usually painful as painless as possible." The goals: to improve speed, operability, and observability.</p>
+
+<p>Cornago and Eichten found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus. "Choosing Kubernetes was pretty clear," says Eichten. "Day zero, deciding, easy. Day one, installing, configuring, easy. Day two, keeping it up and running even with small workloads, if something goes wrong, you don't know how these things work in detail, you're lost. For day two problems, we needed a partner who's helping us."</p>
+
+<p>In early 2017, adidas chose Giant Swarm to consult, install, configure, and run all of its Kubernetes clusters in AWS and on premise. "There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster," says Eichten. "Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly."</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/adidas/banner3.png"
+  author="DANIEL EICHTEN, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS"
+>}}
+"There is no competitive edge over our competitors like Puma or Nike in running and operating a Kubernetes cluster. Our competitive edge is that we teach our internal engineers how to build cool e-comm stores that are fast, that are resilient, that are running perfectly."
+{{< /case-studies/quote >}}
+
+<p>Adds Cornago: "For me, our Kubernetes platform is made by engineers for engineers. It's relieving the development team from tasks that they don't want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it."</p>
+
+<p>Case in point: For Cyber Week, the team has to create a lot of custom metrics. In November 2017, "because we used the same Prometheus that we use for monitoring the cluster, we really filled the Prometheus database, and we were not able to reduce the retention period [enough]," says Cornago. So during the freeze period before the peak shopping week, five engineers from the platform team worked with five engineers from the e-comm team to figure out a federated solution that was implemented in two days.</p>
+
+<p>In addition to being ready for Cyber Week—100% of the adidas e-commerce site was running on Kubernetes then, just six months after the project began—the cloud native stack has had other impressive results. Load time for the e-commerce site was reduced by half. Releases went from every 4-6 weeks to 3-4 times a day. With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform.</p>
+
+<p>And adoption has spread quickly among adidas's 300-strong engineering corps. "I call our cloud native platform the field of dreams," says Eichten. "We built it, and we never anticipated that people would come and just love it."</p>
+
+<p>For one thing, "everybody who can touch a line of code" has spent one full week onboarding and learning the platform with members of the 35-person platform engineering team, says Cornago. "We try to spend 50% of our time sitting with the teams, because this is the only way to understand how our platform is being used. And this is how the teams will feel safe that there is someone on the other side of the wall, also feeling the pain."</p>
+
+<p>Additionally, Cornago and Eichten took advantage of the fact that as a fashion athletic wear brand, adidas has sports and competition in its DNA. "Top-down mandates don't work at adidas, but gamification works," says Cornago. "So this year we had a DevOps Cup competition. Every team created new technical capabilities and had a hypothesis of how this affected business value. We announced the winner at a big internal tech summit with more than 600 people. It's been really, really useful for the teams."</p>
+
+<p>So if they had any advice for other companies looking to start a cloud native journey, it would be this: "There is no one-size-fits-all for all companies," says Cornago. "Apply your company's culture to everything that you do."</p>
@@ -0,0 +1,84 @@
+---
+title: Babylon Case Study
+linkTitle: Babylon
+case_study_styles: true
+cid: caseStudies
+logo: babylon_featured_logo.svg
+featured: true
+weight: 1
+quote: >
+   Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/babylon/banner4.jpg
+heading_title_text: Babylon
+use_gradient_overlay: true
+subheading: >
+  AppDirect: How Cloud Native Is Enabling Babylon's Medical AI Innovations
+case_study_details:
+  - Company: Babylon
+  - Location: United Kingdom
+  - Industry: AI, Healthcare
+---
+
+<h2>Challenge</h2>
+
+<p>A large number of Babylon's products leverage machine learning and artificial intelligence, and in 2019, there wasn't enough computing power in-house to run a particular experiment. The company was also growing (from 100 to 1,600 in three years) and planning expansion into other countries.</p>
+
+<h2>Solution</h2>
+
+<p>Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, so the infrastructure team turned to Kubeflow, a toolkit for machine learning on Kubernetes. "We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success," says AI Infrastructure Lead Jérémie Vallée. The team began building a self-service AI training platform on top of Kubernetes.</p>
+
+<h2>Impact</h2>
+
+<p>Instead of waiting hours or days to be able to compute, teams can get access instantaneously. Clinical validations used to take 10 hours; now they are done in under 20 minutes. The portability of the cloud native platform has also enabled Babylon to expand into other countries.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/babylon/banner1.jpg"
+  author="JÉRÉMIE VALLÉE, AI INFRASTRUCTURE LEAD AT BABYLON"
+>}}
+"Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+Babylon's mission is to put accessible and affordable healthcare services in the hands of every person on earth.
+{{< /case-studies/lead >}}
+
+<p>Since its launch in the U.K. in 2013, the startup has facilitated millions of digital consultations around the world. In the U.K., patients were typically waiting a week or two for a doctor's appointment. Through Babylon's NHS service, GP at Hand—which has more than 75,000 registered patients—39% get an appointment through their phone within 30 minutes, and 89% within 6 hours.</p>
+
+<p>That's just the start. "We try to combine different types of technology with the medical expertise that we have in-house to build products that will help patients manage and understand their health, and also help doctors be more efficient at what they do," says Jérémie Vallée, AI Infrastructure Lead at Babylon. </p>
+
+<p>A large number of these products leverage machine learning and artificial intelligence, and in 2019, researchers hit a pain point. "We have some servers in-house where our researchers were doing a lot of AI experiments and some training of models, and we came to a point where we didn't have enough compute in-house to run a particular experiment," says Vallée. </p>
+
+<p>Babylon had migrated its user-facing applications to a Kubernetes platform in 2018, "and we had a lot of Kubernetes knowledge thanks to the migration," he adds. To optimize some of the models that had been created, the team turned to Kubeflow, a toolkit for machine learning on Kubernetes. "We tried to create a Kubernetes core server, we deployed Kubeflow, and we orchestrated the whole experiment, which ended up being a really good success," he says.</p>
+
+<p>Based on that experience, Vallée's team was tasked with building a self-service platform to help Babylon's AI teams become more efficient, and by extension help get products to market faster. The main requirements: (1) the ability to give researchers and engineers access to the compute they needed, regardless of the size of the experiments they may need to run; (2) a way to provide teams with the best tools that they needed to do their work, on demand and in a centralized way; and (3) the training platform had to be close to the data that was being managed, because of the company's expansion into different countries.</p>
+
+{{< case-studies/quote author="CAROLINE HARGROVE, CHIEF TECHNOLOGY OFFICER AT BABYLON" >}}
+"Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation."
+{{< /case-studies/quote >}}
+
+<p>Kubernetes was an enabler on every count. "Kubernetes is a great platform for machine learning because it comes with all the scheduling and scalability that you need," says Vallée. The need to keep data in every country in which Babylon operates requires a multi-region, multi-cloud strategy, and some countries might not even have a public cloud provider at all. "We wanted to make this platform portable so that we can run training jobs anywhere," he says. "Kubernetes offered a base layer that allows you to deploy the platform outside of the cloud provider, and then deploy whatever tooling you need. That was a very good selling point for us."</p>
+
+<p>Once the team decided to build the Babylon AI Research platform on top of Kubernetes, they referred to the Cloud Native Landscape to build out the stack: Prometheus and Grafana for monitoring; an Istio service mesh to control the network on the training platform and control what access all of the workflows would have; Helm to deploy the stack; and Flux to manage the GitOps part of the pipeline.</p>
+
+<p>The cloud native AI platform has had a huge impact at Babylon. The first research projects run on the platform mostly involved machine learning and natural language processing. These experiments required a huge amount of compute—1600 CPU, 3.2 TB RAM—which was much more than Babylon had in-house. Plus, access to compute used to take hours, or sometimes even days, depending on how busy the platform team was. "Now, with Kubernetes and the self-service platform that we provide, it's pretty much instantaneous," says Vallée.</p>
+
+<p>Another important type of work that's done on the platform is clinical validation for new applications such as Babylon's Symptom Checker, which calculates the probability of a disease given the evidence input by the user. "Being in healthcare, we want all of our models to be safe before they're going to hit production," says Vallée. Using Argo for GitOps "enabled us to scale the process massively."</p>
+
+{{< case-studies/quote 
+  image="/images/case-studies/babylon/banner2.jpg"
+  author="JEAN MARIE FERDEGUE, DIRECTOR OF PLATFORM OPERATIONS AT BABYLON"
+>}}
+"Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases."
+{{< /case-studies/quote >}}
+
+<p>Researchers used to have to wait up to 10 hours to get results on new versions of their models. With Kubernetes, that time is now down to under 20 minutes. Plus, previously they could only run one clinical validation at a time, now they can run many parallel ones if they need to—a huge benefit considering that in the past three years, Babylon has grown from 100 to 1,600 employees.</p>
+
+<p>"Delivering a self-service platform where users are empowered to run their own workload has enabled our data scientist community to do hyper parameter tuning and general algorithm development without any cloud skill and without the help of platform engineers, thus accelerating our innovation," says Chief Technology Officer Caroline Hargrove.</p>
+
+<p>Adds Director of Platform Operations Jean Marie Ferdegue: "Giving a Kubernetes-based platform to our data scientists has meant increased security, increased innovation through empowerment, and a more affordable health service as our cloud engineers are building an experience that is used by hundreds on a daily basis, rather than supporting specific bespoke use cases."</p>
+
+<p>Plus, as Babylon continues to expand, "it will be very easy to onboard new countries," says Vallée. "Fifteen months ago when we deployed this platform, we had one big environment in the U.K., but now we have one in Canada, we have one in Asia, and we have one coming in the U.S. This is one of the things that Kubernetes and the other cloud native projects have enabled for us."</p>
+
+<p>Babylon's road map for cloud native involves onboarding all of the company's AI efforts to the platform. Increasingly, that includes AI services of care. "I think this is going to be an interesting field where AI and healthcare meet," Vallée says. "It's kind of a complex problem and there's a lot of issues around this. So with our platform, we want to say, 'What can we do to make this less painful for our developers and machine learning engineers?'"</p>
@@ -0,0 +1,86 @@
+---
+title: Booking.com Case Study
+linkTitle: Booking.com
+case_study_styles: true
+cid: caseStudies
+logo: booking.com_featured_logo.png
+featured: true
+weight: 3
+quote: >
+  We realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/booking/banner1.jpg
+heading_title_text: Booking.com
+use_gradient_overlay: true
+subheading: >
+  After Learning the Ropes with a Kubernetes Distribution, Booking.com Built a Platform of Its Own
+case_study_details:
+  - Company: Booking.com
+  - Location: Netherlands
+  - Industry: Travel
+---
+
+<h2>Challenge</h2>
+
+<p>In 2016, Booking.com migrated to an OpenShift platform, which gave product developers faster access to infrastructure. But because Kubernetes was abstracted away from the developers, the infrastructure team became a "knowledge bottleneck" when challenges arose. Trying to scale that support wasn't sustainable.</p>
+
+<h2>Solution</h2>
+
+<p>After a year operating OpenShift, the platform team decided to build its own vanilla Kubernetes platform—and ask developers to learn some Kubernetes in order to use it. "This is not a magical platform," says Ben Tyler, Principal Developer, B Platform Track. "We're not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we're going to do everything we can to make sure they have access to that knowledge."</p>
+
+<h2>Impact</h2>
+
+<p>Despite the learning curve, there's been a great uptick in adoption of the new Kubernetes platform. Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn't. On the new platform, it can take as few as 10 minutes. About 500 new services were built on the platform in the first 8 months.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/booking/banner2.jpg"
+  author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM"
+>}}
+"As our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better, more native Kubernetes experience, which is great. It's a super healthy dynamic."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+Booking.com has a long history with Kubernetes: In 2015, a team at the travel platform prototyped a container platform based on Mesos and Marathon.
+{{< /case-studies/lead >}}
+
+<p>Impressed by what the technology offered, but in need of enterprise features at its scale—the site handles more than 1.5 million room-night reservations a day on average—the team decided to adopt an OpenShift platform.</p>
+
+<p>This platform, which was wrapped in a Heroku-style, high-level CLI interface, "was definitely popular with our product developers," says Ben Tyler, Principal Developer, B Platform Track. "We gave them faster access to infrastructure."</p>
+
+<p>But, he adds, "anytime something went slightly off the rails, developers didn't have any of the knowledge required to support themselves."</p>
+
+<p>And after a year of operating this platform, the infrastructure team found that it had become "a knowledge bottleneck," he says. "Most of the developers who used it did not know it was Kubernetes underneath. An application failure and a platform failure both looked like failures of that Heroku-style tool."</p>
+
+<p>Scaling the necessary support did not seem feasible or sustainable, so the platform team needed a new solution. The understanding of Kubernetes that they had gained operating the OpenShift platform gave them confidence to build a vanilla Kubernetes platform of their own and customize it to suit the company's needs.</p>
+
+{{< case-studies/quote author="EDUARD IACOBOAIA, SENIOR SYSTEM ADMINISTRATOR, B PLATFORM TRACK AT BOOKING.COM" >}}
+"For entering the landscape, OpenShift was definitely very helpful. It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge."
+{{< /case-studies/quote >}}
+
+<p>"For entering the landscape, OpenShift was definitely very helpful," says Eduard Iacoboaia, Senior System Administrator, B Platform Track. "It shows you what the technology can do, and it makes it easy for you to use it. After we spent some time on it, we realized that we needed to learn Kubernetes better in order to fully use the potential of it. At that point, we made the shift to build our own Kubernetes platform. We definitely benefit in the long term for taking that step and investing the time in gaining that knowledge."</p>
+
+<p>Iacoboaia's team had customized a lot of OpenShift tools to make them work at Booking.com, and "those integrations points were kind of fragile," he says. "We spent much more time understanding all the components of Kubernetes, how they work, how they interact with each other." That research led the team to switch from OpenShift's built-in Ansible playbooks to Puppet deployments, which are used for the rest of Booking's infrastructure. The control plane was also moved from inside the cluster onto bare metal, as the company runs tens of thousands of bare-metal servers and a large infrastructure for running applications on bare metal. (Booking runs Kubernetes in multiple clusters in multiple data centers across the various regions where it has compute.) "We decided to keep it as simple as possible and to also use the tools that we know best," says Iacoboaia.</p>
+
+<p>The other big change was that product engineers would have to learn Kubernetes in order to onboard. "This is not a magical platform," says Tyler. "We're not claiming that you can just use it with your eyes closed. Developers need to do some learning, and we're going to do everything we can to make sure they have access to that knowledge." That includes trainings, blog posts, videos, and Udemy courses.</p>
+
+<p>Despite the learning curve, there's been a great uptick in adoption of the new Kubernetes platform. "I think the reason we've been able to strike this bargain successfully is that we're not asking them to learn a proprietary app system," says Tyler. "We're asking them to learn something that's open source, where the knowledge is transferable. They're investing in their own careers by learning Kubernetes."</p>
+
+<p>One clear sign that this strategy has been a success is that in the support channel, when users have questions, other product engineers are jumping in to respond. "I haven't seen that kind of community engagement around a particular platform product internally before," says Tyler. "It helps a lot that it's visibly an ecosystem standard outside of the company, so people feel value in investing in that knowledge and sharing it with others, which is really, really powerful."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/booking/banner3.jpg"
+  author="BEN TYLER, PRINCIPAL DEVELOPER, B PLATFORM TRACK AT BOOKING.COM"
+>}}
+"We have a tutorial. You follow the tutorial. Your code is running. Then, it's business-logic time. The time to gain access to resources is decreased enormously."
+{{< /case-studies/quote >}}
+
+<p>There's other quantifiable evidence too: Before containers, creating a new service could take a couple of days if the developers understood Puppet, or weeks if they didn't. On the new platform, it takes 10 minutes. "We have a tutorial. You follow the tutorial. Your code is running. Then, it's business-logic time," says Tyler. "The time to gain access to resources is decreased enormously." About 500 new services were built in the first 8 months on the platform, with hundreds of releases per day.</p>
+
+<p>The platform offers different "layers of contracts, so to speak," says Tyler. "At the very base, it's just Kubernetes. If you're a pro Kubernetes user, here's a Kubernetes API, just like you get from GKE or AKS. We're trying to be a provider on that same level. But our whole job inside the company is to be a bigger value add than just vanilla infrastructure, so we provide a set of base images for our main stacks, Perl and Java."</p>
+
+<p>And "as our users learn Kubernetes and become more sophisticated Kubernetes users, they put pressure on us to provide a better more native Kubernetes experience, which is great," says Tyler. "It's a super healthy dynamic."</p>
+
+<p>The platform also includes other CNCF technologies, such as Envoy, Helm, and Prometheus. Most of the critical service traffic for Booking.com is routed through Envoy, and Prometheus is used primarily to monitor infrastructure components. Helm is consumed as a packaging standard. The team also developed and open sourced Shipper, an extension for Kubernetes to add more complex rollout strategies and multi-cluster orchestration.</p>
+
+<p>To be sure, there have been internal discussions about the wisdom of building a Kubernetes platform from the ground up. "This is not really our core competency—Kubernetes and travel, they're kind of far apart, right?" says Tyler. "But we've made a couple of bets on CNCF components that have worked out really well for us. Envoy and Kubernetes, in particular, have been really beneficial to our organization. We were able to customize them, either because we could look at the source code or because they had extension points, and we were able to get value out of them very quickly without having to change any paradigms internally."</p>
@@ -0,0 +1,80 @@
+---
+title: Booz Allen Case Study
+linkTitle: Booz Allen Hamilton
+case_study_styles: true
+cid: caseStudies
+logo: booz-allen-featured-logo.svg
+featured: true
+weight: 2
+quote: >
+  Kubernetes is a great solution for us. It allows us to rapidly iterate on our clients' demands.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/booz-allen/banner4.jpg
+heading_title_text: Booz Allen Hamilton
+use_gradient_overlay: true
+subheading: >
+  How Booz Allen Hamilton Is Helping Modernize the Federal Government with Kubernetes
+case_study_details:
+  - Company: Booz Allen Hamilton
+  - Location: United States
+  - Industry: Government
+---
+
+<h2>Challenge</h2>
+
+<p>In 2017, Booz Allen Hamilton's Strategic Innovation Group worked with the federal government to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country. The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton's customers.</p>
+
+<h2>Solution</h2>
+
+<p>"The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture and containers, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have," says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff. To meet those requirements, Folkoff's team looked to Kubernetes for orchestration.</p>
+
+<h2>Impact</h2>
+
+<p>With the recreation.gov Kubernetes platform, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day. With monitoring, security, and logging built in, developers can create and publish new services to production within a week. Additionally, Folkoff says, "supporting the large, existing monoliths in the government is extremely expensive," and migrating into a more modern platform has resulted in perhaps 50% cost savings.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/booz-allen/banner2.jpg"
+  author="JOSH BOYD, CHIEF TECHNOLOGIST AT BOOZ ALLEN HAMILTON"
+>}}
+"When there's a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that's the problem we're trying to help the government solve with tools like Kubernetes."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+The White House launched an IT modernization effort in 2017, and in addition to improving cybersecurity and shifting to the public cloud and a consolidated IT model, "the federal government is looking to provide a better experience to citizens in every way that we interact with the government through every channel," says Booz Allen Hamilton Senior Lead Technologist Martin Folkoff.
+{{< /case-studies/lead >}}
+
+<p>To that end, Folkoff's Strategic Innovation Group worked with the federal government last year to relaunch the decade-old recreation.gov website, which provides information and real-time booking for more than 100,000 campsites and facilities on federal lands across the country.</p>
+
+<p>The infrastructure needed to be agile, reliable, and scalable—as well as repeatable for the other federal agencies that are among Booz Allen Hamilton's customers. "The only way that we thought we could be successful with this problem across all the different agencies is to create a microservice architecture, so that we could be very dynamic and very agile to any given agency for whatever requirements that they may have," says Folkoff.</p>
+
+{{< case-studies/quote author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON" >}}
+"With CNCF, there's a lot of focus on scale, and so there's a lot of comfort knowing that as the project grows, we're going to be comfortable using that tool set."
+{{< /case-studies/quote >}}
+
+<p>Booz Allen Hamilton, which has provided consulting services to the federal government for more than a century, introduced microservices, Docker containers, and AWS to its federal agency clients about five years ago. The next logical step was Kubernetes for orchestration. "Knowing that we had to be really agile and really reliable and scalable, we felt that the only technology that we know that can enable those kinds of things are the ones the CNCF provides," Folkoff says. "One of the things that is always important for the government is to make sure that the things that we build really endure. Using technology that is supported across multiple different companies and has strong governance gives people a lot of confidence."</p>
+
+<p>Kubernetes was also aligned with the government's open source and IT modernization initiatives, so there has been an uptick in its usage at federal agencies over the past two years. "Now that Kubernetes is becoming offered as a service by the cloud providers like AWS and Microsoft, we're starting to see even more interest," says Chief Technologist Josh Boyd. Adds Folkoff: "With CNCF, there's a lot of focus on scale, and so there's a lot of comfort knowing that as the project grows, we're going to be comfortable using that tool set."</p>
+
+<p>The greenfield recreation.gov project allowed the team to build a new Kubernetes-enabled site running on AWS, and the migration lasted only a week, when the old site didn't take bookings. "For the actual transition, we just swapped a DNS server, and it only took about 35 seconds between the old site being down and our new site being up and available," Folkoff adds. </p>
+
+{{< case-studies/quote
+  image="/images/case-studies/booz-allen/banner1.png"
+  author="MARTIN FOLKOFF, SENIOR LEAD TECHNOLOGIST AT BOOZ ALLEN HAMILTON"
+>}}
+"Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day's event"
+{{< /case-studies/quote >}}
+
+<p>In addition to its work with the Department of Interior for recreation.gov, Booz Allen Hamilton has brought Kubernetes to various Defense, Intelligence, and civilian agencies. Says Boyd: "When there's a regulatory change in an agency, or a legislative change in Congress, or an executive order that changes the way you do business, how do I deploy that and get that out to the people who need it rapidly? At the end of the day, that's the problem we're trying to help the government solve with tools like Kubernetes."</p>
+
+<p>For recreation.gov, the impact was clear and immediate. With the Kubernetes platform, Folkoff says, "if a new requirement for a permit comes out, we have the ability to design and develop and implement that completely independently of reserving a campsite. It provides a much better experience to users." Today, changes can be implemented in about 30 minutes, compared to the multiple hours or even days legacy government applications require to review the code, get approval, and deploy the fix. Recreation.gov deploys to production on average 10 times a day.</p>
+
+<p>Developer velocity has been improved. "When I want to do monitoring or security or logging, I don't have to do anything to my services or my application to enable that anymore," says Boyd. "I get all of this magic just by being on the Kubernetes platform." With all of those things built in, developers can create and publish new services to production within one week. </p>
+
+<p>Additionally, Folkoff says, "supporting the large, existing monoliths in the government is extremely expensive," and migrating into a more modern platform has resulted in perhaps 50% cost savings. "Kubernetes alone enables a dramatic reduction in cost as resources are prioritized to the day's event," he says. "For example, during a popular campsite release, camping-related services are scaled out while permit services are scaled down."</p>
+
+<p>So far, "Kubernetes is a great solution for us," says Folkoff. "It allows us to rapidly iterate on our clients' demands." Looking ahead, the team sees further adoption of the Kubernetes platform across federal agencies. Says Boyd: "You get the ability for the rapid delivery of business value for your customers. You now have observability into everything that you're doing. You don't have these onesies and twosies unicorn servers anymore. Now everything that you deploy is deployed in the same way, it's all instrumented the same way, and it's all built and deployed the same way through our CI/CD processes."</p>
+
+<p>They also see a push toward re-platforming. "There's still a lot of legacy workloads out there," says Boyd. "We've got the new challenges of greenfield development and integration with legacy systems, but also that brown field of 'Hey, how do I take this legacy monolith and get it onto a platform where now it's instrumented with all the magic of the Kubernetes platform without having to do a whole lot to my application?' I think re-platforming is a pretty big use case for the government right now."</p>
+
+<p>And given the success that they've had with Kubernetes so far, Boyd says, "I think at this point that technology is becoming pretty easy to sell." Adds Folkoff: "People are really excited about being able to deploy, scale, be reliable, and do cheaper maintenance of all of this."</p>
@@ -0,0 +1 @@
+<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" viewBox="0 0 215 127"><defs><style>.cls-1{fill:none;}.cls-2{fill:transparent;}.cls-3{clip-path:url(#clip-path);}.cls-4{fill:#ee3248;fill-rule:evenodd;}</style><clipPath id="clip-path"><rect class="cls-1" x="4.70501" y="-8.81268" width="206.90403" height="145.3255"/></clipPath></defs><rect class="cls-2" x="-3.37342" y="-3.34411" width="223.25536" height="134.51135"/><g class="cls-3"><g class="cls-3"><path class="cls-4" d="M28.02166,50.76936l7.69058-.0617c6.9525.12305,7.75228,4.1837,4.61435,13.41275-2.64567,7.87531-6.76768,12.67414-14.58165,12.61279h-6.091ZM169.22325,61.044c4.55274-11.01316,10.52065-15.19686,22.76431-15.50454,10.9518-.24609,15.81224,4.79908,11.813,17.41187C199.49376,76.67151,191.67987,82.209,179.86693,82.209c-12.98175.06134-16.24263-7.87514-10.64368-21.165m8.429.73843c2.83006-7.01411,6.95215-11.87463,13.04345-11.93633,5.47555-.06125,6.46007,3.938,3.99905,12.36706-3.13794,10.82842-7.69068,15.5659-13.90466,15.44286-6.89106-.06135-6.768-6.82946-3.13784-15.87359m-15.07382-8.67536,2.09172-6.02932a34.76316,34.76316,0,0,0-10.95146-1.66134c-7.62924-.0616-13.35114,2.33806-15.6892,7.69066-3.69162,8.183,1.4766,10.70564,7.69084,13.59749,9.10583,4.245,3.876,11.56684-4.86069,10.82842-3.50688-.3077-6.58311-1.90724-9.65961-3.38384l-1.96859,6.15264A33.79646,33.79646,0,0,0,142.64393,82.209c9.0444-.55369,14.64308-4.184,16.91972-9.90595,2.584-6.52159-1.41525-10.52064-7.38324-12.42789-12.42831-3.99939-4.98338-15.75088,10.398-6.76811M95.57659,46.15492a19.153,19.153,0,0,1,2.215,3.62993L87.76306,81.47059H93.854l8.36766-26.45618,9.59791,26.45618h8.61375l-.36939-.98451,10.89012-34.33116h-6.15273l-7.99827,25.34837-9.22879-25.34837c-3.999,0-7.99836.06135-11.99767,0m-34.39259,0a14.395,14.395,0,0,1,2.21468,3.62993L53.43173,81.47059H79.826L81.05656,77.533H63.21437L67.152,65.16635H78.96492l1.23051-3.87627H68.3825L71.95081,49.9695H89.17822L90.347,46.15492c-9.72121,0-19.44208.06135-29.163,0m-42.26817,0a16.4482,16.4482,0,0,1,2.21468,3.62993L11.102,81.47059h8.61366l5.04517-.06135c14.766,0,21.77988-7.32179,24.73333-16.85828,4.245-13.5973-.92316-18.33469-13.47418-18.33469Z"/></g></g></svg>
@@ -0,0 +1,82 @@
+---
+title: Denso Case Study
+linkTitle: Denso
+case_study_styles: true
+cid: caseStudies
+logo: denso_featured_logo.svg
+featured: true
+weight: 4
+quote: >
+  We got Kubernetes experts involved on our team, and it dramatically accelerated development speed.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/denso/banner2.jpg
+heading_title_text: Denso
+use_gradient_overlay: true
+subheading: >
+  How DENSO Is Fueling Development on the Vehicle Edge with Kubernetes
+case_study_details:
+  - Company: Denso
+  - Location: Japan
+  - Industry: Automotive, Edge
+---
+
+<h2>Challenge</h2>
+
+<p>DENSO Corporation is one of the biggest automotive components suppliers in the world. With the advent of connected cars, the company launched a Digital Innovation Department to expand into software, working on vehicle edge and vehicle cloud products. But there were several technical challenges to creating an integrated vehicle edge/cloud platform: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says R&D Product Manager Seiichi Koizumi.</p>
+
+<h2>Solution</h2>
+
+<p>Koizumi's team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes (GKE, EKS, AKS).</p>
+
+<h2>Impact</h2>
+
+<p>Critical layer features can take 2-3 years to implement in the traditional, waterfall model of development at DENSO. With the Kubernetes platform and agile methods, there's a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and a new prototype is introduced every week. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," says Koizumi.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/denso/banner1.png"
+  author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO"
+>}}
+"Another disruptive innovation is coming, so to survive in this situation, we need to change our culture."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+Spun off from Toyota in 1949, DENSO Corporation is one of the top automotive suppliers in the world today, with consolidated net revenue of $48.3 billion.
+{{< /case-studies/lead >}}
+
+<p>The company's mission is "contributing to a better world by creating value together with a vision for the future"—and part of that vision in recent years has been development on the vehicle edge and vehicle cloud.</p>
+
+<p>With the advent of connected cars, DENSO established a Digital Innovation Department to expand its business beyond the critical layer of the engine, braking systems, and other automotive parts into the non-critical analytics and entertainment layer. Comparing connected cars to smartphones, R&D Product Manager Seiichi Koizumi says DENSO wants the ability to quickly and easily develop and install apps for the "blank slate" of the car, and iterate them based on the driver's preferences. Thus "we need a flexible application platform," he says.</p>
+
+<p>But working on vehicle edge and vehicle cloud products meant there were several technical challenges: "the amount of computing resources, the occasional lack of mobile signal, and an enormous number of distributed vehicles," says Koizumi. "We are tackling these challenges to create an integrated vehicle edge/cloud platform."</p>
+
+{{< case-studies/quote author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO" >}}
+"We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."
+{{< /case-studies/quote >}}
+
+<p>Koizumi's team realized that because mobility services evolve every day, they needed the flexibility of the cloud native ecosystem for their platform. As they evaluated technologies, they were led by these criteria: Because their service-enabler business needed to support multiple cloud and on-premise environments, the solution needed to be cloud agnostic, with no vendor lock-in and open governance. It also had to support an edge-cloud integrated environment.</p>
+
+<p>After considering other orchestrators, DENSO went with Kubernetes for orchestration and added Prometheus, Fluentd, Envoy, Istio, and Helm to the platform. During implementation, the team used "design thinking to clarify use cases and their value proposition," says Koizumi. Next, an agile development team worked on a POC, then an MVP, in DevOps style. "Even in the development phase, we are keeping a channel to end users," he adds.</p>
+
+<p>One lesson learned during this process was the value of bringing in experts. "We tried to learn Kubernetes and cloud native technologies from scratch, but it took more time than expected," says Koizumi. "We got Kubernetes experts involved on our team, and it dramatically accelerated development speed."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/denso/banner4.jpg"
+  author="SEIICHI KOIZUMI, R&D PRODUCT MANAGER, DIGITAL INNOVATION DEPARTMENT AT DENSO"
+>}}
+"By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation."
+{{< /case-studies/quote >}}
+
+<p>Today, DENSO is using a vehicle edge computer, a private Kubernetes cloud, and managed Kubernetes on GKE, EKS, and AKS. "We are developing a vehicle edge/cloud integrated platform based on a microservice and service mesh architecture," says Koizumi. "We extend cloud into multiple vehicle edges and manage it as a unified platform."</p>
+
+<p>Cloud native has enabled DENSO to deliver applications via its new dash cam, which has a secure connection that collects data to the cloud. "It's like a smartphone," he says. "We are installing new applications and getting the data through the cloud, and we can keep updating new applications all through the dash cam."</p>
+
+<p>The unified cloud native platform, combined with agile development, has had a positive impact on productivity. Critical layer features—those involving engines or braking systems, for example—can take 2-3 years to implement at DENSO, because of the time needed to test safety, but also because of the traditional, waterfall model of development. With the Kubernetes platform and agile methods, there's a 2-month development cycle for non-critical software. Now, ten new applications are released a year, and with the department's scrum-style development, a new prototype is introduced every week.</p>
+
+<p>Application portability has also led to greater developer efficiency. "There's no need to care about differences in the multi-cloud platform anymore," says Koizumi. Now, "we are also trying to have the same portability between vehicle edge and cloud platform."</p>
+
+<p>Another improvement: Automotive Tier-1 suppliers like DENSO always have multiple Tier-2 suppliers. "To provide automotive-grade high-availability services, we tried to do the same thing on a multi-cloud platform," says Koizumi. Before Kubernetes, maintaining two different systems simultaneously was difficult. "By utilizing Kubernetes managed services, such as GKE/EKS/AKS, we can unify the environment and simplify our maintenance operation," he says.</p>
+
+<p>Cloud native has also profoundly changed the culture at DENSO. The Digital Innovation Department is known as "Noah's Ark," and it has grown from 2 members to 70—with plans to more than double in the next year. The way they operate is completely different from the traditional Japanese automotive culture. But just as the company embraced change brought by hybrid cars in the past decade, Koizumi says, they're doing it again now, as technology companies have moved into the connected car space. "Another disruptive innovation is coming," he says, "so to survive in this situation, we need to change our culture."</p>
+
+<p>Looking ahead, Koizumi and his team are expecting serverless and zero-trust security architecture to be important enhancements of Kubernetes. They are glad DENSO has come along for the ride. "Mobility service businesses require agility and flexibility," he says. "DENSO is trying to bring cloud native flexibility into the vehicle infrastructure."</p>
@@ -0,0 +1,78 @@
+---
+title: ING Case Study
+linkTitle: ING
+case_study_styles: true
+cid: caseStudies
+weight: 50
+featured: true
+quote: >
+  The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us.
+
+new_case_study_styles: true
+heading_background: /images/case-studies/ing/banner1.jpg
+heading_title_logo: /images/ing_logo.png
+subheading: >
+  Driving Banking Innovation with Cloud Native
+case_study_details:
+  - Company: ING
+  - Location: Amsterdam, Netherlands
+  - Industry: Finance
+---
+
+<h2>Challenge</h2>
+
+<p>After undergoing an agile transformation, <a href="https://www.ing.com/">ING</a> realized it needed a standardized platform to support the work their developers were doing. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with <a href="https://www.docker.com/">Docker</a>, Docker Swarm, <a href="https://kubernetes.io/">Kubernetes</a>, <a href="https://mesosphere.com/">Mesos</a>. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel.</p>
+
+<h2>Solution</h2>
+
+<p>Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app <a href="https://www.yolt.com/">Yolt</a> in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.</p>
+
+<h2>Impact</h2>
+
+<p>"Cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Infrastructure Architect Onno Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."</p>
+
+{{< case-studies/quote author="Thijs Ebbers, Infrastructure Architect, ING">}}
+"The big cloud native promise to our business is the ability to go from idea to production within 48 hours. We are some years away from this, but that's quite feasible to us."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+ING has long embraced innovation in banking, launching the internet-based ING Direct in 1997.
+{{< /case-studies/lead >}}
+
+<p>In that same spirit, the company underwent an agile transformation a few years ago. "Our DevOps teams got empowered to be autonomous," says Infrastructure Architect Thijs Ebbers. "It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it's not really useful for a company to have one hundred wheels, instead of one good wheel."</p>
+
+<p>Looking to standardize the deployment process within the company's strict security guidelines, the team looked at several solutions and found that in the past year, "Kubernetes won the container management framework wars," says Ebbers. "We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."</p>
+
+<p>They also embraced Docker to address a major pain point in ING's CI/CD pipeline. Before containerization, "Every development team had to order a VM, and it was quite a heavy delivery model for them," says Infrastructure Architect Onno Van der Voort. "Another use case for containerization is when the application travels through the pipeline, they fire up Docker containers to do test work against the applications and after they've done the work, the containers get killed again."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/ing/banner3.jpg"
+  author="Thijs Ebbers, Infrastructure Architect, ING"
+>}}
+"We decided to standardize ING on a Kubernetes framework." Everything is run on premise due to banking regulations, he adds, but "we will be building an internal public cloud. We are trying to get on par with what public clouds are doing. That's one of the reasons we got Kubernetes."
+{{< /case-studies/quote >}}
+
+<p>Because of industry regulations, applications are only allowed to go through the pipeline, where compliance is enforced, rather than be deployed directly into a container. "We have to run the complete platform of services we need, many routing from different places," says Van der Voort. "We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex." For that reason, ING has chosen to start on the <a href="https://www.openshift.org/">OpenShift Origin</a> Kubernetes distribution.</p>
+
+<p>Already, "cloud native technologies are helping our speed, from getting an application to test to acceptance to production," says Van der Voort. "If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready."</p>
+
+<p>The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. Some legacy applications are also being rewritten as cloud native in order to run on the framework. At least two smaller greenfield projects built on Kubernetes will go into production this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/ing/banner4.jpg"
+  author="Onno Van der Voort,  Infrastructure Architect, ING"
+>}}
+"We have to run the complete platform of services we need, many routing from different places. We need this Kubernetes framework for deploying the containers, with all those components, monitoring, logging. It's complex."
+{{< /case-studies/quote >}}
+
+<p>The team, however, doesn't see the bank's back-end systems going onto the Kubernetes platform. "Our philosophy is it only makes sense to move things to cloud if they are cloud native," says Van der Voort. "If you have traditional architecture, build traditional patterns, it doesn't hold any value to go to the cloud." Adds Cloud Platform Architect Alfonso Fernandez-Barandiaran: "ING has a strategy about where we will go, in order to improve our agility. So it's not about how cool this technology is, it's about finding the right technology and the right approach."</p>
+
+<p>The Kubernetes framework will be hosting some greenfield projects that are high priority for ING: applications the company is developing in response to <a href="https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en">PSD2</a>, the European Commission directive requiring more innovative online and mobile payments that went into effect at the beginning of 2018. For example, a bank-account management app called <a href="https://www.yolt.com/">Yolt</a>, serving the U.K. market (and soon France and Italy), was built on a Kubernetes platform and has gone into production. ING is also developing blockchain-enabled applications that will live on the Kubernetes platform. "We've been contacted by a lot of development teams that have ideas with what they want to do with containers," says Ebbers.</p>
+
+{{< case-studies/quote author="Alfonso Fernandez-Barandiaran, Cloud Platform Architect, ING" >}}
+Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology."
+{{< /case-studies/quote >}}
+
+<p>Even with the particular requirements that come in banking, ING has managed to take a lead in technology and innovation. "Every time we have constraints, we look for maybe a better way that we can use this technology," says Fernandez-Barandiaran.</p>
+
+<p>The results, after all, are worth the effort. "The big cloud native promise to our business is the ability to go from idea to production within 48 hours," says Ebbers. "That would require all these projects to be mature. We are some years away from this, but that's quite feasible to us."</p>
@@ -0,0 +1,79 @@
+---
+title: JD.com Case Study
+linkTitle: jd-com
+case_study_styles: true
+cid: caseStudies
+featured: false
+
+new_case_study_styles: true
+heading_background: /images/case-studies/jdcom/banner1.jpg
+heading_title_logo: /images/jdcom_logo.png
+subheading: >
+  JD.com: How JD.com Pioneered Kubernetes for E-Commerce at Hyperscale
+case_study_details:
+  - Company: JD.com
+  - Location: Beijing, China
+  - Industry: eCommerce
+---
+
+<h2>Challenge</h2>
+
+<p>With more than 300 million active users and total 2017 revenue of more than $55 billion, <a href="https://corporate.JD.com/home">JD.com</a> is China's largest retailer, and its operations are the epitome of hyperscale. For example, there are more than a trillion images in JD.com's product databases—with 100 million being added daily—and this enormous amount of data needs to be instantly accessible. In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com's Chief Architect. But by the end of 2015, with tens of thousands of nodes running in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," says Liu. "We needed infrastructure for the next five years of development, now."</p>
+
+<h2>Solution</h2>
+
+<p>JD.com turned to Kubernetes to accommodate its clusters. At the beginning of 2016, the company began to transition from OpenStack to Kubernetes, and today, JD.com runs the world's largest Kubernetes cluster. "Kubernetes has provided a strong foundation on top of which we have customized the solution to suit our needs as China's largest retailer."</p>
+
+<h2>Impact</h2>
+
+<p>"We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform," says Liu. Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. With the further optimizations the team is working on, Liu believes there is the potential to save hundreds of millions of dollars a year. But perhaps the best indication of success was the annual Singles Day shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes's scalability, we were able to handle an extremely high level of demand."</p>
+
+{{< case-studies/quote author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" >}}
+"Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable. Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That's the big win."
+{{< /case-studies/quote >}}
+
+{{< case-studies/lead >}}
+With more than 300 million active users and $55.7 billion in annual revenues last year, JD.com is China's largest retailer, and its operations are the epitome of hyperscale.
+{{< /case-studies/lead >}}
+
+<p>For example, there are more than a trillion images in JD.com's product databases for customers, with 100 million being added daily. And this enormous amount of data needs to be instantly accessible to enable a smooth online customer experience.</p>
+
+<p>In 2014, JD.com moved its applications to containers running on bare metal machines using OpenStack and Docker to "speed up the delivery of our computing resources and make the operations much simpler," says Haifeng Liu, JD.com's Chief Architect. But by the end of 2015, with hundreds of thousands of nodes in multiple data centers, "we encountered a lot of problems because our platform was not strong enough, and we suffered from bottlenecks and scalability issues," Liu adds. "We needed infrastructure for the next five years of development, now."</p>
+
+<p>After considering a number of orchestration technologies, JD.com decided to adopt Kubernetes to accommodate its ever-growing clusters. "The main reason is because Kubernetes can give us more efficient, scalable and much simpler application deployments, plus we can leverage it to do flexible platform scheduling," says Liu.</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/jdcom/banner3.jpg"
+  author="HAIFENG LIU, CHIEF ARCHITECT, JD.com"
+>}}
+"We customized Kubernetes and built a modern system on top of it. This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time."
+{{< /case-studies/quote >}}
+
+<p>The fact that Kubernetes is based on Google's Borg also gave the company confidence. The team liked that Kubernetes has a clear and simple architecture, and that it's developed mostly in Go, which is a popular language within JD.com.  Though he felt that at the time Kubernetes "was not mature enough," Liu says, "we adopted it anyway."</p>
+
+<p>The team spent a year developing the new container engine platform based on Kubernetes, and at the end of 2016, began promoting it within the company. "We wanted the cluster to be the default way for creating services, so scalability is easier," says Liu. "We talked to developers, interest grew, and we solved problems together." Some of these problems included networking performance and etcd scalability. "But during the past two years, Kubernetes has become more mature and very stable," he adds.</p>
+
+<p>Today, the company runs the world's largest Kubernetes cluster. "We customized Kubernetes and built a modern system on top of it," says Liu. "This entire ecosystem of Kubernetes plus our own optimizations have helped us save costs and time. We have greater data center efficiency, better managed resources, and smarter deployment with the Kubernetes platform."</p>
+
+{{< case-studies/quote
+  image="/images/case-studies/jdcom/banner4.jpg"
+  author="HAIFENG LIU, CHIEF ARCHITECT, JD.com"
+>}}
+"My advice is first you need to combine this technology with your own businesses, and the second is you need clear goals. You cannot just use the technology because others are using it. You need to consider your own objectives."
+{{< /case-studies/quote >}}
+
+<p>The results are clear: Deployment time went from several hours to tens of seconds. Efficiency has improved by 20-30%, measured in IT costs. But perhaps the best indication of success was the annual <a href="https://JD.comcorporateblog.com/shoppers-snap-up-quality-and-imported-products-on-JD.com-com-for-record-breaking-singles-day-festival/">Singles Day</a> shopping event, which ran on the Kubernetes platform for the first time in 2018. Over 11 days, transaction volume on JD.com was $23 billion, and "our e-commerce platforms did great," says Liu. "Infrastructure led the way to prep for 11.11. We took the approach of predicting volume, emulating the behavior of customers to prepare beforehand, and drilled for malfunctions. Because of Kubernetes's scalability, we were able to handle an extremely high level of demand."</p>
+
+<p>JD.com is now in its second stage with Kubernetes: The platform is already stable, scalable, and flexible, so the focus is on how to run things much more efficiently to further reduce costs. With the optimizations the team is working on with resource management, Liu believes there is the potential to save hundreds of millions of dollars a year.</p>
+
+<p>"We run Kubernetes and container clusters on roughly tens of thousands of physical bare metal nodes," he says. "Using Kubernetes and leveraging our own machine learning pipeline to predict how many resources we need for each application we use, and our own intelligent scaling algorithm, we can improve our resource usage. If we boost the resource usage, for example, by several percent, that means we can reduce huge hardware costs. Then we don't need that many servers to get that same amount of workload. That can save us a lot of resources."</p>
+
+{{< case-studies/quote author="HAIFENG LIU, CHIEF ARCHITECT, JD.com" >}}
+"We can share our successful experience with the community, and we also receive good feedback from others. So it's mutually beneficial."
+{{< /case-studies/quote >}}
+
+<p>JD.com, which won CNCF's 2018 End User Award, is also using <a href="https://helm.sh/">Helm</a>, <a href="https://github.com/containernetworking">CNI</a>, <a href="https://goharbor.io/">Harbor</a>, and <a href="https://vitess.io/">Vitess</a> on its platform. JD.com developers have made considerable contributions to Vitess, the CNCF project for scalable MySQL cluster management, and the company hopes to donate its own project to CNCF in the near future. Community participation is a priority for JD.com. "We have a good partnership with this community," says Liu. "We can share our successful experience with the community, and we also receive good feedback from others. So it's mutually beneficial."</p>
+
+<p>To that end, Liu offers this advice for other companies considering adopting cloud native technology. "First you need to combine this technology with your own businesses, and the second is you need clear goals," he says. "You cannot just use the technology because others are using it. You need to consider your own objectives."</p>
+
+<p>For JD.com's objectives, these cloud native technologies have been an ideal fit with the company's own homegrown innovation. "Kubernetes helped us reduce the complexity of operations to make distributed systems stable and scalable," says Liu. "Most importantly, we can leverage Kubernetes for scheduling resources to reduce hardware costs. That's the big win."</p>
@@ -30,9 +30,9 @@ One or more forms of [authorization](/docs/reference/access-authn-authz/authoriz
 ## 节点到控制面

 Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。
-所有从集群（或所运行的 Pods）发出的 API 调用都终止于 apiserver。
+所有从集群（或所运行的 Pods）发出的 API 调用都终止于 API 服务器。
 其它控制面组件都没有被设计为可暴露远程服务。
-apiserver 被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求，
+API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求，
 并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。
 一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用，
 特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests)
@@ -41,7 +41,7 @@ apiserver 被配置为在一个安全的 HTTPS 端口（通常为 443）上监
 <!--
 Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates.
 -->
-应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 apiserver。
+应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。
 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。
 请查看 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
 以了解如何自动提供 kubelet 客户端证书。
@@ -52,12 +52,12 @@ The `kubernetes` service (in `default` namespace) is configured with a virtual I

 The control plane components also communicate with the cluster apiserver over the secure port.
 -->
-想要连接到 apiserver 的 Pod 可以使用服务账号安全地进行连接。
+想要连接到 API 服务器的 Pod 可以使用服务账号安全地进行连接。
 当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。
 `kubernetes` 服务（位于 `default` 名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发
-请求到 apiserver 的 HTTPS 末端。
+请求到 API 服务器的 HTTPS 末端。

-控制面组件也通过安全端口与集群的 apiserver 通信。
+控制面组件也通过安全端口与集群的 API 服务器通信。

 <!--
 As a result, the default operating mode for connections from the nodes and pods running on the nodes to the control plane is secured by default and can run over untrusted and/or public networks.
@@ -72,9 +72,9 @@ There are two primary communication paths from the control plane (apiserver) to
 -->
 ## 控制面到节点

-从控制面（apiserver）到节点有两种主要的通信路径。
-第一种是从 apiserver 到集群中每个节点上运行的 kubelet 进程。
-第二种是从 apiserver 通过它的代理功能连接到任何节点、Pod 或者服务。
+从控制面（API 服务器）到节点有两种主要的通信路径。
+第一种是从 API 服务器到集群中每个节点上运行的 kubelet 进程。
+第二种是从 API 服务器通过它的代理功能连接到任何节点、Pod 或者服务。

 <!--
 ### apiserver to kubelet
@@ -89,14 +89,14 @@ These connections terminate at the kubelet's HTTPS endpoint. By default, the api
 -->
 ### API 服务器到 kubelet

-从 apiserver 到 kubelet 的连接用于：
+从 API 服务器到 kubelet 的连接用于：

 * 获取 Pod 日志
 * 挂接（通过 kubectl）到运行中的 Pod
 * 提供 kubelet 的端口转发功能。

 这些连接终止于 kubelet 的 HTTPS 末端。
-默认情况下，apiserver 不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击，
+默认情况下，API 服务器不检查 kubelet 的服务证书。这使得此类连接容易受到中间人攻击，
 在非受信网络或公开网络上运行也是 **不安全的**。

 <!--
@@ -107,10 +107,10 @@ untrusted or public network.

 Finally, [Kubelet authentication and/or authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) should be enabled to secure the kubelet API.
 -->
-为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 apiserver 
-提供一个根证书包，用于 kubelet 的服务证书。
+为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 API
+服务器提供一个根证书包，用于 kubelet 的服务证书。

-如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 apiserver 和
+如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 API 服务器和
 kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。

 最后，应该启用
@@ -122,9 +122,9 @@ kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。

 The connections from the apiserver to a node, pod, or service default to plain HTTP connections and are therefore neither authenticated nor encrypted. They can be run over a secure HTTPS connection by prefixing `https:` to the node, pod, or service name in the API URL, but they will not validate the certificate provided by the HTTPS endpoint nor provide client credentials so while the connection will be encrypted, it will not provide any guarantees of integrity. These connections **are not currently safe** to run over untrusted and/or public networks.
 -->
-### apiserver 到节点、Pod 和服务
+### API 服务器到节点、Pod 和服务

-从 apiserver 到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。
+从 API 服务器到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。
 这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。
 不过这些连接既不会验证 HTTPS 末端提供的证书，也不会提供客户端证书。
 因此，虽然连接是加密的，仍无法提供任何完整性保证。
@@ -140,8 +140,8 @@ SSH tunnels are currently deprecated so you shouldn't opt to use them unless you
 -->
 ### SSH 隧道 {#ssh-tunnels}

-Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，apiserver
-建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务）
+Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，API
+服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务）
 并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。
 这一隧道保证通信不会被暴露到集群节点所运行的网络之外。

@@ -63,7 +63,7 @@ valid. For example, if you try to create a Node from the following JSON manifest
 1. 节点上的 `kubelet` 向控制面执行自注册；
 2. 你，或者别的什么人，手动添加一个 Node 对象。

-在你创建了 Node {{< glossary_tooltip text="object" term_id="object" >}}或者节点上的
+在你创建了 Node {{< glossary_tooltip text="对象" term_id="object" >}}或者节点上的
 `kubelet` 执行了自注册操作之后，控制面会检查新的 Node 对象是否合法。
 例如，如果你尝试使用下面的 JSON 对象来创建 Node 对象：

@@ -100,10 +100,9 @@ it becomes healthy.
 You, or a {{< glossary_tooltip term_id="controller" text="controller">}}, must explicitly
 delete the Node object to stop that health checking.
 -->
-Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经
-变得健康。
-你，或者某个{{< glossary_tooltip term_id="controller" text="控制器">}}必需显式地
-删除该 Node 对象以停止健康检查操作。
+Kubernetes 会一直保存着非法节点对应的对象，并持续检查该节点是否已经变得健康。
+你，或者某个{{< glossary_tooltip term_id="controller" text="控制器">}}必须显式地删除该
+Node 对象以停止健康检查操作。
 {{< /note >}}

 <!--
@@ -127,7 +126,7 @@ first and re-added after the update.
 -->
 ### 节点名称唯一性     {#node-name-uniqueness}

-节点的[名称](/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。
+节点的[名称](/zh/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。
 没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。
 就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容）
 和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。
@@ -177,8 +176,8 @@ When the [Node authorization mode](/docs/reference/access-authn-authz/node/) and
 kubelets are only authorized to create/modify their own Node resource.
 -->
 启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和
-[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
-时，仅授权 `kubelet` 创建或修改其自己的节点资源。
+[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时，
+仅授权 `kubelet` 创建或修改其自己的节点资源。

 {{< note >}}
 <!--
@@ -257,7 +256,7 @@ kubectl cordon $NODENAME
 See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/)
 for more details.
 -->
-更多细节参考[安全腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
+更多细节参考[安全地腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。

 {{< note >}}
 <!--
@@ -285,10 +284,10 @@ A node's status contains the following information:

 一个节点的状态包含以下信息:

-* [地址](#addresses)
-* [状况](#condition)
-* [容量与可分配](#capacity)
-* [信息](#info)
+* [地址（Addresses）](#addresses)
+* [状况（Condition）](#condition)
+* [容量与可分配（Capacity）](#capacity)
+* [信息（Info）](#info)

 <!--
 You can use `kubectl` to view a Node's status and other details:
@@ -327,7 +326,7 @@ The `conditions` field describes the status of all `Running` nodes. Examples of
 -->
 ### 状况 {#condition}

-`conditions` 字段描述了所有 `Running` 节点的状态。状况的示例包括：
+`conditions` 字段描述了所有 `Running` 节点的状况。状况的示例包括：

 <!--
 {{< table caption = "Node conditions, and a description of when each condition applies." >}}
@@ -393,7 +392,7 @@ for all Pods assigned to that node. The default eviction timeout duration is
 如果 Ready 状况的 `status` 处于 `Unknown` 或者 `False` 状态的时间超过了
 `pod-eviction-timeout` 值（一个传递给
 {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}
-的参数），[节点控制器](#node-controller) 会对节点上的所有 Pod 触发
+的参数），[节点控制器](#node-controller)会对节点上的所有 Pod 触发
 {{< glossary_tooltip text="API-发起的驱逐" term_id="api-eviction" >}}。
 默认的逐出超时时长为 **5 分钟**。

@@ -417,7 +416,7 @@ all the Pod objects running on the node to be deleted from the API server, and f
 names.
 -->
 节点控制器在确认 Pod 在集群中已经停止运行前，不会强制删除它们。
-你可以看到这些可能在无法访问的节点上运行的 Pod 处于 `Terminating` 或者 `Unknown` 状态。
+你可以看到可能在这些无法访问的节点上运行的 Pod 处于 `Terminating` 或者 `Unknown` 状态。
 如果 kubernetes 不能基于下层基础设施推断出某节点是否已经永久离开了集群，
 集群管理员可能需要手动删除该节点对象。
 从 Kubernetes 删除节点对象将导致 API 服务器删除节点上所有运行的 Pod 对象并释放它们的名字。
@@ -480,7 +479,7 @@ the Kubernetes API.
 ### 信息（Info） {#info}

 Info 指的是节点的一般信息，如内核版本、Kubernetes 版本（`kubelet` 和 `kube-proxy` 版本）、
-容器运行时详细信息，以及 节点使用的操作系统。
+容器运行时详细信息，以及节点使用的操作系统。
 `kubelet` 从节点收集这些信息并将其发布到 Kubernetes API。

 <!--
@@ -492,6 +491,7 @@ availability of each node, and to take action when failures are detected.
 For nodes there are two forms of heartbeats:
 -->
 ## 心跳  {#heartbeats}
+
 Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性，并在检测到故障时采取行动。

 对于节点，有两种形式的心跳:
@@ -504,7 +504,7 @@ Kubernetes 节点发送的心跳帮助你的集群确定每个节点的可用性
  Each Node has an associated Lease object.
 -->
 * 更新节点的 `.status`
-* `kube-node-lease` {{<glossary_tooltip term_id="namespace" text="命名空间">}}中的
+* `kube-node-lease` {{<glossary_tooltip term_id="namespace" text="名字空间">}}中的
  [Lease（租约）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
  每个节点都有一个关联的 Lease 对象。

@@ -570,26 +570,29 @@ controller deletes the node from its list of nodes.
 The third is monitoring the nodes' health. The node controller is
 responsible for:

- In the case that a node becomes unreachable, updating the NodeReady condition
-  of within the Node's `.status`. In this case the node controller sets the
-  NodeReady condition to `ConditionUnknown`.
+- In the case that a node becomes unreachable, updating the `Ready` condition
+  in the Node's `.status` field. In this case the node controller sets the
+  `Ready` condition to `Unknown`.
 - If a node remains unreachable: triggering
  [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/)
  for all of the Pods on the unreachable node. By default, the node controller
-  waits 5 minutes between marking the node as `ConditionUnknown` and submitting
+  waits 5 minutes between marking the node as `Unknown` and submitting
  the first eviction request.

-The node controller checks the state of each node every `-node-monitor-period` seconds.
+By default, the node controller checks the state of each node every 5 seconds.
+This period can be configured using the `--node-monitor-period` flag on the
+`kube-controller-manager` component.
 -->
 第三个是监控节点的健康状况。节点控制器负责：

- 在节点不可达的情况下，在 Node 的 `.status` 中更新 NodeReady 状况。
+- 在节点不可达的情况下，在 Node 的 `.status` 中更新 `Ready` 状况。
  在这种情况下，节点控制器将 NodeReady 状况更新为 `Unknown` 。
 - 如果节点仍然无法访问：对于不可达节点上的所有 Pod 触发
-  [API-发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)。
+  [API 发起的逐出](/zh/docs/concepts/scheduling-eviction/api-eviction/)操作。
  默认情况下，节点控制器在将节点标记为 `Unknown` 后等待 5 分钟提交第一个驱逐请求。

-节点控制器每隔 `--node-monitor-period` 秒检查每个节点的状态。
+默认情况下，节点控制器每 5 秒检查一次节点状态，可以使用 `kube-controller-manager`
+组件上的 `--node-monitor-period` 参数来配置周期。

 <!--
 ### Rate limits on eviction
@@ -606,11 +609,11 @@ from more than 1 node per 10 seconds.
 <!--
 The node eviction behavior changes when a node in a given availability zone
 becomes unhealthy. The node controller checks what percentage of nodes in the zone
-are unhealthy (NodeReady condition is `ConditionUnknown` or `ConditionFalse`) at
+are unhealthy (the `Ready` condition is `Unknown` or `False`) at
 the same time:
 -->
 当一个可用区域（Availability Zone）中的节点变为不健康时，节点的驱逐行为将发生改变。
-节点控制器会同时检查可用区域中不健康（NodeReady 状况为 `Unknown` 或 `False`）
+节点控制器会同时检查可用区域中不健康（`Ready` 状况为 `Unknown` 或 `False`）
 的节点的百分比：

 <!--
@@ -713,7 +716,7 @@ If you want to explicitly reserve resources for non-Pod processes, follow this t
 -->
 ## 节点拓扑  {#node-topology}

-{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
+{{< feature-state state="beta" for_k8s_version="v1.18" >}}

 <!--
 If you have enabled the `TopologyManager`
@@ -766,11 +769,11 @@ enabled by default in 1.21.
 <!--
 Note that by default, both configuration options described below,
 `ShutdownGracePeriod` and `ShutdownGracePeriodCriticalPods` are set to zero,
-thus not activating Graceful node shutdown functionality.
+thus not activating the graceful node shutdown functionality.
 To activate the feature, the two kubelet config settings should be configured appropriately and set to non-zero values.
 -->
-注意，默认情况下，下面描述的两个配置选项，`ShutdownGracePeriod` 和
-`ShutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活体面节点关闭功能。
+注意，默认情况下，下面描述的两个配置选项，`shutdownGracePeriod` 和
+`shutdownGracePeriodCriticalPods` 都是被设置为 0 的，因此不会激活体面节点关闭功能。
 要激活此功能特性，这两个 kubelet 配置选项要适当配置，并设置为非零值。

 <!-- 
@@ -794,12 +797,12 @@ Graceful Node Shutdown feature is configured with two [`KubeletConfiguration`](/
 节点体面关闭的特性对应两个
 [`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项：

-* `ShutdownGracePeriod`：
+* `shutdownGracePeriod`：
  * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod
    还是[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
-* `ShutdownGracePeriodCriticalPods`：
+* `shutdownGracePeriodCriticalPods`：
  * 在节点关闭期间指定用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)
-    的持续时间。该值应小于 `ShutdownGracePeriod`。
+    的持续时间。该值应小于 `shutdownGracePeriod`。

 <!--  
 For example, if `ShutdownGracePeriod=30s`, and
@@ -808,7 +811,7 @@ For example, if `ShutdownGracePeriod=30s`, and
 for gracefully terminating normal pods, and the last 10 seconds would be
 reserved for terminating [critical pods](/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical).
 -->
-例如，如果设置了 `ShutdownGracePeriod=30s` 和 `ShutdownGracePeriodCriticalPods=10s`，
+例如，如果设置了 `shutdownGracePeriod=30s` 和 `shutdownGracePeriodCriticalPods=10s`，
 则 kubelet 将延迟 30 秒关闭节点。
 在关闭期间，将保留前 20（30 - 10）秒用于体面终止常规 Pod，
 而保留最后 10 秒用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。
@@ -817,11 +820,6 @@ reserved for terminating [critical pods](/docs/tasks/administer-cluster/guarante
 When pods were evicted during the graceful node shutdown, they are marked as failed.
 Running `kubectl get pods` shows the status of the the evicted pods as `Shutdown`.
 And `kubectl describe pod` indicates that the pod was evicted because of node shutdown:
-
-```
-Reason:         Terminated
-Message:        Pod was terminated in response to imminent node shutdown.
-```
 -->
 {{< note >}}
 当 Pod 在正常节点关闭期间被驱逐时，它们会被标记为已经失败（Failed）。
@@ -970,8 +968,8 @@ containing the pod priority class values and their respective shutdown periods.
 -->
 如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。

-使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` 功能特性，
-并将 kubelet 配置中的 `ShutdownGracePeriodByPodPriority` 设置为期望的配置，
+使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` 特性门控，
+并将 kubelet 配置中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置，
 其中包含 Pod 的优先级类数值以及对应的关闭期限。

 <!--
@@ -1005,8 +1003,7 @@ must be set to false.
 -->
 要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控，
 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn`
-[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
-设置为 false。
+[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。

 <!--
 A user can also optionally configure `memorySwap.swapBehavior` in order to
@@ -98,7 +98,7 @@ Before choosing a guide, here are some considerations:
 * [Authorization](/docs/reference/access-authn-authz/authorization/) is separate from authentication, and controls how HTTP calls are handled.
 * [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
 * [Using Sysctls in a Kubernetes Cluster](/docs/concepts/cluster-administration/sysctl-cluster/) describes to an administrator how to use the `sysctl` command-line tool to set kernel parameters .
-* [Auditing](/docs/tasks/debug-application-cluster/audit/) describes how to interact with Kubernetes' audit logs.
+* [Auditing](/docs/tasks/debug/debug-cluster/audit/) describes how to interact with Kubernetes' audit logs.
 -->
 ## 保护集群  {#securing-a-cluster}

@@ -116,7 +116,7 @@ Before choosing a guide, here are some considerations:
  阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。
 * [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/)
  描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。
-* [审计](/zh/docs/tasks/debug-application-cluster/audit/)
+* [审计](/zh/docs/tasks/debug/debug-cluster/audit/)
  描述了如何与 Kubernetes 的审计日志交互。

 <!--
@@ -411,9 +411,9 @@ see the [Troubleshooting](#troubleshooting) section.
 The kubelet reports the resource usage of a Pod as part of the Pod
 [`status`](/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status).

-If optional [tools for monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+If optional [tools for monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
 are available in your cluster, then Pod resource usage can be retrieved either
-from the [Metrics API](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api)
+from the [Metrics API](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api)
 directly or from your monitoring tools.
 -->
 ## 监控计算和内存资源用量
@@ -422,8 +422,8 @@ kubelet 会将 Pod 的资源使用情况作为 Pod
 [`status`](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#object-spec-and-status)
 的一部分来报告的。

-如果为集群配置了可选的[监控工具](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)，
-则可以直接从[指标 API](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#the-metrics-api) 
+如果为集群配置了可选的[监控工具](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)，
+则可以直接从[指标 API](/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-api) 
 或者监控工具获得 Pod 的资源使用情况。

 <!--
@@ -210,12 +210,12 @@ Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列
 <!--
 ### Container Resource Monitoring

-[Container Resource Monitoring](/docs/tasks/debug-application-cluster/resource-usage-monitoring/) records generic time-series metrics
+[Container Resource Monitoring](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) records generic time-series metrics
 about containers in a central database, and provides a UI for browsing that data.
 -->
 ### 容器资源监控

-[容器资源监控](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/)
+[容器资源监控](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/)
 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。

 <!--
@@ -241,4 +241,3 @@ saving container logs to a central log store with search/browsing interface.
 * 进一步了解[控制器](/zh/docs/concepts/architecture/controller/)
 * 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/)
 * 阅读 etcd 官方[文档](https://etcd.io/docs/)
-
@@ -83,7 +83,7 @@ metadata:
  name: standard
 provisioner: kubernetes.io/aws-ebs
 parameters:
-  type: gp3
+  type: gp2
 reclaimPolicy: Retain
 allowVolumeExpansion: true
 mountOptions:
@@ -143,7 +143,7 @@ the specification. Some external provisioners are listed under the repository
 -->
 你不限于指定此处列出的 "内置" 制备器（其名称前缀为 "kubernetes.io" 并打包在 Kubernetes 中）。
 你还可以运行和指定外部制备器，这些独立的程序遵循由 Kubernetes 定义的
-[规范](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)。
+[规范](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)。
 外部供应商的作者完全可以自由决定他们的代码保存于何处、打包方式、运行方式、使用的插件（包括 Flex）等。
 代码仓库 [kubernetes-sigs/sig-storage-lib-external-provisioner](https://github.com/kubernetes-sigs/sig-storage-lib-external-provisioner)
 包含一个用于为外部制备器编写功能实现的类库。你可以访问代码仓库
@@ -431,8 +431,9 @@ parameters:

 <!--
 * `type`: `io1`, `gp2`, `gp2`, `sc1`, `st1`. See
+* `type`: `io1`, `gp2`, `sc1`, `st1`. See
  [AWS docs](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)
-  for details. Default: `gp3`.
+  for details. Default: `gp2`.
 * `zone` (Deprecated): AWS zone. If neither `zone` nor `zones` is specified, volumes are
  generally round-robin-ed across all active zones where Kubernetes cluster
  has a node. `zone` and `zones` parameters must not be used at the same time.
@@ -453,8 +454,8 @@ parameters:
  encrypting the volume. If none is supplied but `encrypted` is true, a key is
  generated by AWS. See AWS docs for valid ARN value.
 -->
-* `type`：`io1`，`gp2`，`gp3`，`sc1`，`st1`。详细信息参见
-  [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp3`。
+* `type`：`io1`，`gp2`，`sc1`，`st1`。详细信息参见
+  [AWS 文档](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html)。默认值：`gp2`。
 * `zone`(弃用)：AWS 区域。如果没有指定 `zone` 和 `zones`，
  通常卷会在 Kubernetes 集群节点所在的活动区域中轮询调度分配。
  `zone` 和 `zones` 参数不能同时使用。
@@ -92,6 +92,37 @@ Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和
 <!--
 ## Using Pods

+The following is an example of a Pod which consists of a container running the image `nginx:1.14.2`.
+
+{{< codenew file="pods/simple-pod.yaml" >}}
+
+To create the Pod shown above, run the following command:
+-->
+## 使用 Pod   {#using-pods}
+
+下面是一个 Pod 示例，它由一个运行镜像 `nginx:1.14.2` 的容器组成。
+
+{{< codenew file="pods/simple-pod.yaml" >}}
+
+要创建上面显示的 Pod，请运行以下命令：
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml
+```
+
+<!--
+Pods are generally not created directly and are created using workload resources.
+See [Working with Pods](#working-with-pods) for more information on how Pods are used
+with workload resources.
+
+### Workload resources for managing pods
+-->
+Pod 通常不是直接创建的，而是使用工作负载资源创建的。
+有关如何将 Pod 用于工作负载资源的更多信息，请参阅 [使用 Pod](#working-with-pods)。
+
+### 用于管理 pod 的工作负载资源
+
+<!--
 Usually you don't need to create Pods directly, even singleton Pods. 
 Instead, create them using workload resources such as {{< glossary_tooltip text="Deployment"
 term_id="deployment" >}} or {{< glossary_tooltip text="Job" term_id="job" >}}.
@@ -100,8 +131,6 @@ If your Pods need to track state, consider the

 Pods in a Kubernetes cluster are used in two main ways:
 -->
-## 使用 Pod   {#using-pods}
-
 通常你不需要直接创建 Pod，甚至单实例 Pod。
 相反，你会使用诸如
 {{< glossary_tooltip text="Deployment" term_id="deployment" >}} 或
@@ -187,9 +216,9 @@ that updates those files from a remote source, as in the following diagram:
 -->

 例如，你可能有一个容器，为共享卷中的文件提供 Web 服务器支持，以及一个单独的
-“sidecar（挂斗）”容器负责从远端更新这些文件，如下图所示：
+"边车 (sidercar)" 容器负责从远端更新这些文件，如下图所示：

-{{< figure src="/images/docs/pod.svg" alt="example pod diagram" width="50%" >}}
+{{< figure src="/images/docs/pod.svg" alt="Pod creation diagram" class="diagram-medium" >}}

 <!--
 Some Pods have {{< glossary_tooltip text="init containers" term_id="init-container" >}}
@@ -287,7 +316,7 @@ _Pod 模板（Pod Template）_ 来替你创建 Pod 并管理它们。
 Pod 模板是包含在工作负载对象中的规范，用来创建 Pod。这类负载资源包括
 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、
 [Job](/zh/docs/concepts/workloads/controllers/job/) 和
-[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/)等。
+[DaemonSets](/zh/docs/concepts/workloads/controllers/daemonset/) 等。

 <!--
 Each controller for a workload resource uses the `PodTemplate` inside the workload
@@ -314,7 +343,7 @@ spec:
    spec:
      containers:
      - name: hello
-        image: busybox
+        image: busybox:1.28
        command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      restartPolicy: OnFailure
    # 以上为 Pod 模版
@@ -345,7 +374,7 @@ details are abstracted away. That abstraction and separation of concerns simplif
 system semantics, and makes it feasible to extend the cluster's behavior without
 changing existing code.
 -->
-在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}}并不直接监测
+在节点上，{{< glossary_tooltip term_id="kubelet" text="kubelet" >}} 并不直接监测
 或管理与 Pod 模版相关的细节或模版的更新，这些细节都被抽象出来。
 这种抽象和关注点分离简化了整个系统的语义，并且使得用户可以在不改变现有代码的
 前提下就能扩展集群的行为。
@@ -412,7 +441,7 @@ Kubernetes 并不禁止你直接管理 Pod。对运行中的 Pod 的某些字段
 Pods enable data sharing and communication among their constituent
 containters.
 -->
-### 资源共享和通信    {#resource-sharing-and-communication}
+### 资源共享和通信 {#resource-sharing-and-communication}

 Pod 使它的成员容器间能够进行数据共享和通信。

@@ -459,14 +488,13 @@ can find each other via `localhost`. The containers in a Pod can also communicat
 with each other using standard inter-process communications like SystemV semaphores
 or POSIX shared memory.  Containers in different Pods have distinct IP addresses
 and can not communicate by IPC without
-[special configuration](/docs/concepts/policy/pod-security-policy/).
+and can not communicate by OS-level IPC without special configuration.
 Containers that want to interact with a container running in a different Pod can
 use IP networking to communicate.
 -->
 在同一个 Pod 内，所有容器共享一个 IP 地址和端口空间，并且可以通过 `localhost` 发现对方。
 他们也能通过如 SystemV 信号量或 POSIX 共享内存这类标准的进程间通信方式互相通信。
-不同 Pod 中的容器的 IP 地址互不相同，没有
-[特殊配置](/zh/docs/concepts/policy/pod-security-policy/) 就不能使用 IPC 进行通信。
+不同 Pod 中的容器的 IP 地址互不相同，没有特殊配置，无法通过 OS 级 IPC 进行通信就不能使用 IPC 进行通信。
 如果某容器希望与运行于其他 Pod 中的容器通信，可以通过 IP 联网的方式实现。

 <!--
@@ -129,6 +129,6 @@ you can view processes in other containers.

 {{% heading "whatsnext" %}}
 <!--
-* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container).
+* Learn how to [debug pods using ephemeral containers](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container).
 -->
-* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)
+* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)
@@ -860,7 +860,7 @@ K8s components to start a container.

 图 8 给出的是一个 Mermaid 时序图，展示启动容器时 K8s 组件间的控制流。

-{{< figure src="/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}}
+{{< figure src="/zh/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}}


 <!--
@@ -106,7 +106,7 @@ To run the link checker:
 2. 执行如下命令：

  ```
-  make docker-internal-linkcheck
+  make container-internal-linkcheck
  ```

 <!-- 
@@ -2,7 +2,7 @@
 title: Pod 安全策略
 id: pod-security-policy
 date: 2018-04-12
-full_link: /zh/docs/concepts/policy/pod-security-policy/
+full_link: /zh/docs/concepts/security/pod-security-policy/
 short_description: >
  为 Pod 的创建和更新操作启用细粒度的授权。

@@ -17,7 +17,7 @@ tags:
 title: Pod Security Policy
 id: pod-security-policy
 date: 2018-04-12
-full_link: /docs/concepts/policy/pod-security-policy/
+full_link: /docs/concepts/security/pod-security-policy/
 short_description: >
  Enables fine-grained authorization of pod creation and updates.

@@ -43,4 +43,9 @@ A cluster-level resource that controls security sensitive aspects of the Pod spe
 Pod 安全策略是集群级别的资源，它控制着 Pod 规约中的安全性敏感的内容。
 `PodSecurityPolicy`对象定义了一组条件以及相关字段的默认值，Pod 运行时必须满足这些条件。Pod 安全策略控制实现上体现为一个可选的准入控制器。

+<!--
+PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. We recommend migrating to [Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin.
+-->
+PodSecurityPolicy 自 Kubernetes v1.21 起已弃用，并将在 v1.25 中删除。 
+我们建议迁移到 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)或第三方准入插件。

@@ -88,7 +88,7 @@ that was transgressed as well as the specific policies on the fields that were
 violated from the PodSecurity enforcement.

 See [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
-for more information
+for more information.
 -->
 ## pod-security.kubernetes.io/audit-violations {#pod-security-kubernetes-io-audit-violations}

@@ -99,4 +99,38 @@ PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container
 注解值给出审计策略违规的详细说明，它包含所违反的 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)级别以及
 PodSecurity 执行中违反的特定策略及对应字段。

-有关详细信息，请参阅 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)。
+有关详细信息，请参阅 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)。
+
+<!--
+## authorization.k8s.io/decision
+
+Example: `authorization.k8s.io/decision: "forbid"`
+
+This annotation indicates whether or not a request was authorized in Kubernetes audit logs.
+
+See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.
+-->
+## authorization.k8s.io/decision {#authorization-k8s-io-decision}
+
+例子：`authorization.k8s.io/decision: "forbid"`
+
+此注解在 Kubernetes 审计日志中表示请求是否获得授权。
+
+有关详细信息，请参阅[审计](/zh/docs/tasks/debug-application-cluster/audit/)。
+
+<!--
+## authorization.k8s.io/reason
+
+Example: `authorization.k8s.io/reason: "Human-readable reason for the decision"`
+
+This annotation gives reason for the [decision](#authorization-k8s-io-decision) in Kubernetes audit logs.
+
+See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.
+-->
+## authorization.k8s.io/reason {#authorization-k8s-io-reason}
+
+例子：`authorization.k8s.io/reason: "Human-readable reason for the decision"`
+
+此注解给出了 Kubernetes 审计日志中 [decision](#authorization-k8s-io-decision) 的原因。
+
+有关详细信息，请参阅[审计](/zh/docs/tasks/debug-application-cluster/audit/)。
@@ -1,8 +1,11 @@

 <!-- 
+kubeadm: easily bootstrap a secure Kubernetes cluster
+
 ### Synopsis 
 -->

+kubeadm: 轻松创建一个安全的 Kubernetes 集群
 ### 摘要

 <!--
@@ -90,9 +93,9 @@ Example usage:
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-help for kubeadm
+<p>help for kubeadm</p>
 -->
-kubeadm 操作的帮助信息 
+<p>kubeadm 操作的帮助信息<p>
 </td>
 </tr>

@@ -102,9 +105,9 @@ kubeadm 操作的帮助信息
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-[EXPERIMENTAL] The path to the 'real' host root filesystem.
+<p>[EXPERIMENTAL] The path to the 'real' host root filesystem.</p>
 -->
-[实验] 指向 '真实' 宿主机根文件系统的路径。
+<p>[实验] 指向 '真实' 宿主机根文件系统的路径。<p>
 </td>
 </tr>

@@ -1,69 +0,0 @@
-
-<!-- 
-### Synopsis 
-->
-
-### 概要
-
-<!--
-Kubeadm experimental sub-commands
-->
-
-kubeadm 实验子命令
-
-<!--
-### Options
-->
-
-### 选项
-
-   <table style="width: 100%; table-layout: fixed;">
-<colgroup>
-<col span="1" style="width: 10px;" />
-<col span="1" />
-</colgroup>
-<tbody>
-
-<tr>
-<td colspan="2">-h, --help</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">
-<!--
-help for alpha
-->
-alpha 操作的帮助命令
-</td>
-</tr>
-
-</tbody>
-</table>
-
-<!--
-### Options inherited from parent commands
-->
-
-### 从父命令继承的选项
-
-   <table style="width: 100%; table-layout: fixed;">
-<colgroup>
-<col span="1" style="width: 10px;" />
-<col span="1" />
-</colgroup>
-<tbody>
-
-<tr>
-<td colspan="2">--rootfs string</td>
-</tr>
-<tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">
-<!--
-[EXPERIMENTAL] The path to the 'real' host root filesystem.
-->
-[实验] 指向 '真实' 宿主机的根文件系统的路径。
-</td>
-</tr>
-
-</tbody>
-</table>
-
@@ -1,3 +1,18 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+<!--
+Commands related to handling kubernetes certificates
+-->
+处理 Kubernetes 证书的相关命令

 <!--
 ### Synopsis
@@ -7,7 +22,7 @@
 <!--
 Commands related to handling kubernetes certificates
 -->
-与处理 kubernetes 证书相关的命令
+处理 Kubernetes 证书相关的命令

 <!--
 ### Options
@@ -25,8 +40,8 @@ Commands related to handling kubernetes certificates
 <td colspan="2">-h, --help</td>
 </tr>
 <tr>
-<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">help for certs</td -->
-<td></td><td style="line-height: 130%; word-wrap: break-word;"><!-- help for certs-->certs 命令的帮助</td>
+<!-- td></td><td style="line-height: 130%; word-wrap: break-word;"><p>help for certs</p></td -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><!-- help for certs--><p>certs 命令的帮助</p></td>
 </tr>

 </tbody>
@@ -48,8 +63,8 @@ Commands related to handling kubernetes certificates
 <td colspan="2">--rootfs string</td>
 </tr>
 <tr>
-<!-- td></td><td style="line-height: 130%; word-wrap: break-word;">[EXPERIMENTAL] The path to the 'real' host root filesystem.</td -->
-<td></td><td style="line-height: 130%; word-wrap: break-word;">[实验] 到'真实'主机根文件系统的路径。</td>
+<!-- td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[EXPERIMENTAL] The path to the 'real' host root filesystem.</p></td -->
+<td></td><td style="line-height: 130%; word-wrap: break-word;"><p>[实验] 到'真实'主机根文件系统的路径。</p></td>
 </tr>

 </tbody>
@@ -1,3 +1,18 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+<!--
+Generate certificate keys
+-->
+生成证书密钥

 <!--
 ### Synopsis
@@ -37,10 +52,12 @@ kubeadm certs certificate-key [flags]
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
+<p>
 <!--
 help for certificate-key
 -->
 certificate-key 操作的帮助命令
+</p>
 </td>
 </tr>

@@ -64,10 +81,12 @@ certificate-key 操作的帮助命令
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
+<p>
 <!--
 [EXPERIMENTAL] The path to the 'real' host root filesystem.
 -->
 [实验] 到 '真实' 主机根文件系统的路径。
+</p>
 </td>
 </tr>

@@ -1,3 +1,18 @@
+<!--
+The file is auto-generated from the Go source code of the component using a generic
+[generator](https://github.com/kubernetes-sigs/reference-docs/). To learn how
+to generate the reference documentation, please read
+[Contributing to the reference documentation](/docs/contribute/generate-ref-docs/).
+To update the reference conent, please follow the 
+[Contributing upstream](/docs/contribute/generate-ref-docs/contribute-upstream/)
+guide. You can file document formatting bugs against the
+[reference-docs](https://github.com/kubernetes-sigs/reference-docs/) project.
+-->
+
+<!--
+Renew certificates for a Kubernetes cluster
+-->
+为 Kubernetes 集群更新证书

 <!--
 ### Synopsis
@@ -30,10 +45,12 @@ kubeadm certs renew [flags]
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
+<p>
 <!--
 help for renew
 -->
 renew 操作的帮助命令
+</p>
 </td>
 </tr>

@@ -58,10 +75,12 @@ renew 操作的帮助命令
 </tr>
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
+<p>
 <!--
 [EXPERIMENTAL] The path to the 'real' host root filesystem.
 -->
 [实验] 到 '真实' 主机根文件系统的路径。
+</p>
 </td>
 </tr>

@@ -6,9 +6,9 @@


 <!--
-Generate the certificate for serving etcd, and save them into etcd/server.cert and etcd/server.key files.
+Generate the certificate for serving etcd, and save them into etcd/server.crt and etcd/server.key files.
 -->
-生成用于提供 etcd 服务的证书，并将其保存到 etcd/server.cert 和 etcd/server.key 文件中。
+生成用于提供 etcd 服务的证书，并将其保存到 etcd/server.crt 和 etcd/server.key 文件中。

 <!--
 Default SANs are localhost, 127.0.0.1, 127.0.0.1, ::1
@@ -52,9 +52,9 @@ kubeadm init phase certs etcd-server [flags]
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-The path where to save and store the certificates.
+<p>The path where to save and store the certificates.</p>
 -->
-保存和存储证书的路径。
+<p>保存和存储证书的路径。<p>
 </td>
 </tr>

@@ -64,9 +64,9 @@ The path where to save and store the certificates.
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-Path to kubeadm configuration file.
+<p>Path to a kubeadm configuration file.</p>
 -->
-kubeadm 配置文件的路径。
+<p>kubeadm 配置文件的路径。<p>
 </td>
 </tr>

@@ -76,9 +76,9 @@ kubeadm 配置文件的路径。
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-help for etcd-server
+<p>help for etcd-server</p>
 -->
-etcd-server 操作的帮助命令
+<p>etcd-server 操作的帮助命令<p>
 </td>
 </tr>

@@ -93,9 +93,9 @@ etcd-server 操作的帮助命令
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-Choose a specific Kubernetes version for the control plane.
+<p>Choose a specific Kubernetes version for the control plane.</p>
 -->
-为控制平面指定特定的 Kubernetes 版本。
+<p>为控制平面指定特定的 Kubernetes 版本。<p>
 </td>
 </tr>

@@ -122,9 +122,9 @@ Choose a specific Kubernetes version for the control plane.
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-[EXPERIMENTAL] The path to the 'real' host root filesystem.
+<p>[EXPERIMENTAL] The path to the 'real' host root filesystem.</p>
 -->
-[实验] 到 '真实' 主机根文件系统的路径。
+<p>[实验] 到 '真实' 主机根文件系统的路径。<p>
 </td>
 </tr>

@@ -1,3 +1,8 @@
+<!-- 
+Upgrade your cluster smoothly to a newer version with this command 
+-->
+
+此命令能将集群平滑升级到新版本

 <!--
 ### Synopsis
@@ -34,9 +39,9 @@ kubeadm upgrade [flags]
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-help for upgrade
+<p>help for upgrade</p>
 -->
-upgrade 操作的帮助命令
+<p>upgrade 操作的帮助命令<p>
 </td>
 </tr>

@@ -62,9 +67,9 @@ upgrade 操作的帮助命令
 <tr>
 <td></td><td style="line-height: 130%; word-wrap: break-word;">
 <!--
-[EXPERIMENTAL] The path to the 'real' host root filesystem.
+<p>[EXPERIMENTAL] The path to the 'real' host root filesystem.</p>
 -->
-[实验] 指向 '真实' 宿主机根文件系统的路径。
+<p>[实验] 指向 '真实' 宿主机根文件系统的路径。<p>
 </td>
 </tr>

@@ -67,8 +67,6 @@ For control-plane nodes additional steps are performed:
 1. Generating control-plane component manifests, certificates and kubeconfig.

 1. Adding new local etcd member.
-
-1. Adding this node to the ClusterStatus of the kubeadm cluster.
 -->
 对于控制平面节点，执行额外的步骤：

@@ -78,8 +76,6 @@ For control-plane nodes additional steps are performed:

 1. 添加新的本地 etcd 成员。

-1. 将此节点添加到 kubeadm 集群的 ClusterStatus。
-
 <!-- 
 ### Using join phases with kubeadm {#join-phases}
 -->
@@ -123,6 +119,13 @@ For example:
 sudo kubeadm join --skip-phases=preflight --config=config.yaml
 ```

+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+
+<!--
+Alternatively, you can use the `skipPhases` field in `JoinConfiguration`.
+-->
+或者，你可以使用 `JoinConfiguration` 中的 `skipPhases` 字段。
+
 <!--
 ### Discovering what cluster CA to trust
 -->
@@ -523,11 +526,11 @@ the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/
 命令转换。

 <!--
-For more information on the fields and usage of the configuration you can navigate to our API reference
-page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories).
+For more information on the fields and usage of the configuration you can navigate to our
+[API reference](/docs/reference/config-api/kubeadm-config.v1beta3/).
 -->
-有关配置的字段和用法的更多信息，你可以导航到我们的 API 参考页
-并从[列表]中选择一个版本(https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories)。
+有关配置的字段和用法的更多信息，你可以导航到我们的
+[API 参考页](/zh/docs/reference/config-api/kubeadm-config.v1beta3/)。


 ## {{% heading "whatsnext" %}}
@@ -401,12 +401,12 @@ based on demand.
 <!--
 - *Set up node health checks*: For important workloads, you want to make sure
 that the nodes and pods running on those nodes are healthy. Using the
-[Node Problem Detector](/docs/tasks/debug-application-cluster/monitor-node-health/)
+[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/)
 daemon, you can ensure your nodes are healthy.
 -->
 - *安装节点健康检查*：对于重要的工作负载，你会希望确保节点以及在节点上
  运行的 Pod 处于健康状态。通过使用
-  [Node Problem Detector](/zh/docs/tasks/debug-application-cluster/monitor-node-health/)，
+  [Node Problem Detector](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)，
  你可以确保你的节点是健康的。

 <!--
@@ -43,7 +43,7 @@ Windows 应用程序构成了许多组织中运行的服务和应用程序的很
 control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
 * It is important to note that creating and deploying services and workloads on Kubernetes
 behaves in much the same way for Linux and Windows containers.
-[Kubectl commands](/docs/reference/kubectl/overview/) to interface with the cluster are identical.
+[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical.
 The example in the section below is provided to jumpstart your experience with Windows containers.
 -->
 ## 在你开始之前
@@ -278,7 +278,34 @@ with one of its main goals being that this approach should not break compatibili
 目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上，
 因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。
 推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。
+<!--
+If the `IdentifyPodOS` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is
+enabled, you can (and should) set `.spec.os.name` for a Pod to indicate the operating system
+that the containers in that Pod are designed for. For Pods that run Linux containers, set
+`.spec.os.name` to `linux`. For Pods that run Windows containers, set `.spec.os.name`
+to Windows.

+The scheduler does not use the value of `.spec.os.name` when assigning Pods to nodes. You should
+use normal Kubernetes mechanisms for
+[assigning pods to nodes](/docs/concepts/scheduling-eviction/assign-pod-node/)
+to ensure that the control plane for your cluster places pods onto nodes that are running the
+appropriate operating system.
+ no effect on the scheduling of the Windows pods, so taints and tolerations and node selectors are still required
+ to ensure that the Windows pods land onto appropriate Windows nodes.
+ -->
+ {{< note >}}
+如果 `IdentifyPodOS` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是启用的，
+你可以（并且应该）为 Pod 设置 `.spec.os.name` 以表明该 Pod
+中的容器所针对的操作系统。 对于运行 Linux 容器的 Pod，设置 
+`.spec.os.name` 为 `linux`。 对于运行 Windows 容器的 Pod，设置 `.spec.os.name`
+为 `Windows`。
+
+在将 Pod 分配给节点时，调度程序不使用 `.spec.os.name` 的值。你应该使用正常的 Kubernetes
+机制[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)，
+确保集群的控制平面将 Pod 放置到适合运行的操作系统。
+对 Windows Pod 的调度没有影响，因此仍然需要污点、容忍度以及节点选择器，
+以确保 Windows Pod 调度至合适的 Windows 节点。
+ {{< /note >}}
 <!--
 ### Ensuring OS-specific workloads land on the appropriate container host
 -->
@@ -18,12 +18,12 @@ min-kubernetes-server-version: 1.18
 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version
 {{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version
 {{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions
-when upgrading is unsupported.
+when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
 -->
 本页介绍如何将 `kubeadm` 创建的 Kubernetes 集群从 {{< skew currentVersionAddMinor -1 >}}.x 版本
 升级到 {{< skew currentVersion >}}.x 版本以及从 {{< skew currentVersion >}}.x
 升级到 {{< skew currentVersion >}}.y（其中 `y > x`）。略过次版本号的升级是
-不被支持的。
+不被支持的。更多详情请访问[版本倾斜政策](https://kubernetes.io/releases/version-skew-policy/)。

 <!--
 To see information about upgrading clusters created using older versions of kubeadm,
@@ -72,16 +72,36 @@ The upgrade workflow at high level is the following:
 <!--
 ### Additional information

- [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) before kubelet MINOR version
-  upgrades is required. In the case of control plane nodes, they could be running CoreDNS Pods or other critical workloads.
+- The instructions below outline when to drain each node during the upgrade process.
+If you are performing a **minor** version upgrade for any kubelet, you **must**
+first drain the node (or nodes) that you are upgrading. In the case of control plane nodes,
+they could be running CoreDNS Pods or other critical workloads. For more information see
+[Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/).
 - All containers are restarted after upgrade, because the container spec hash value is changed.
 -->
+
 ### 附加信息

- 在对 kubelet 作次版本升版时需要[腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
-  对于控制面节点，其上可能运行着 CoreDNS Pods 或者其它非常重要的负载。
+- 下述说明了在升级过程中何时腾空每个节点。如果你正在对任何 kubelet 进行小版本升级，
+  你需要先腾空待升级的节点（或多个节点）。对于控制面节点，其上可能运行着 CoreDNS Pods
+  或者其它非常重要的负载。更多信息见[腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。
 - 升级后，因为容器规约的哈希值已更改，所有容器都会被重新启动。

+<!--
+- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded,
+you can execute `systemctl status kubelet`  or view the service logs with `journalctl -xeu kubelet`.
+- Usage of the `--config` flag of `kubeadm upgrade` with
+[kubeadm configuration API types](/docs/reference/config-api/kubeadm-config.v1beta3)
+with the purpose of reconfiguring the cluster is not recommended and can have unexpected results. Follow the steps in
+[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure) instead.
+-->
+
+- 要验证 kubelet 服务在升级后是否成功重启，可以执行 `systemctl status kubelet`
+  或 `journalctl -xeu kubelet` 查看服务日志。
+- 不建议使用 `kubeadm upgrade` 的 `--config 参数和 [kubeadm 配置 API 类型](/zh/docs/reference/config-api/kubeadm-config.v1beta3)
+  来重新配置集群，这样会产生意想不到的结果。请按照[重新配置 kubeadm 集群](/zh/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure)
+  中的步骤来进行。
+
 <!-- steps -->

 <!--
@@ -95,19 +115,23 @@ Find the latest patch release for Kubernetes {{< skew currentVersion >}} using t

 {{< tabs name="k8s_install_versions" >}}
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
-```
+
+```shell
 apt update
 apt-cache madison kubeadm
 # 在列表中查找最新的 {{< skew currentVersion >}} 版本
 # 它看起来应该是 {{< skew currentVersion >}}.x-00，其中 x 是最新的补丁版本
 ```
+
 {{% /tab %}}
 {{% tab name="CentOS、RHEL 或 Fedora" %}}
-```
+
+```shell
 yum list --showduplicates kubeadm --disableexcludes=kubernetes
 # 在列表中查找最新的 {{< skew currentVersion >}} 版本
 # 它看起来应该是 {{< skew currentVersion >}}.x-0，其中 x 是最新的补丁版本
 ```
+
 {{% /tab %}}
 {{< /tabs >}}

@@ -140,24 +164,24 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc

 {{< tabs name="k8s_install_kubeadm_first_cp" >}}
 {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
+
 ```shell
 # 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-00 中的 x
 apt-mark unhold kubeadm && \
 apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
 apt-mark hold kubeadm
 -
-# 从 apt-get 1.1 版本起，你也可以使用下面的方法
-apt-get update && \
-apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
-```
+
 {{% /tab %}}
 {{% tab name="CentOS、RHEL 或 Fedora" %}}
 ```shell
 # 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-0 中的 x
 yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
 ```
+
 {{% /tab %}}
 {{< /tabs >}}
+<br />

 <!--
 - Verify that the download works and has the expected version:
@@ -226,7 +250,7 @@ yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kuberne
  -->
  一旦该命令结束，你应该会看到：

-  ```
+  ```console
  [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy!

  [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.
@@ -259,7 +283,7 @@ Same as the first control plane node but use:
 -->
 与第一个控制面节点相同，但是使用：

-```
+```shell
 sudo kubeadm upgrade node
 ```

@@ -268,7 +292,7 @@ instead of:
 -->
 而不是：

-```
+```shell
 sudo kubeadm upgrade apply
 ```

@@ -299,34 +323,33 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
 <!--
 ### Upgrade kubelet and kubectl

-  Upgrade the kubelet and kubectl
+-  Upgrade the kubelet and kubectl:
 -->
 ### 升级 kubelet 和 kubectl

- 升级 kubelet 和 kubectl
+- 升级 kubelet 和 kubectl：

  {{< tabs name="k8s_install_kubelet" >}}
  {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}

-  <pre>
-  # 用最新的补丁版本替换 {{< skew currentVersion >}}.x-00 中的 x
-  apt-mark unhold kubelet kubectl && \
-  apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
-  apt-mark hold kubelet kubectl
-  - 
-  # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
-  apt-get update && \
-  apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
-  </pre>
+    ```shell
+    # 用最新的补丁版本替换 {{< skew currentVersion >}}.x-00 中的 x
+    apt-mark unhold kubelet kubectl && \
+    apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
+    apt-mark hold kubelet kubectl
+    ```
+
  {{% /tab %}}
  {{% tab name="CentOS、RHEL 或 Fedora" %}}
- 
-  <pre> 
-  # 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-00 中的 x
-  yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
-  </pre>
+
+    ```shell
+    # 用最新的补丁版本号替换 {{< skew currentVersion >}}.x-00 中的 x
+    yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
+    ```
+
  {{% /tab %}}
  {{< /tabs >}}
+<br />

 <!--
 - Restart the kubelet
@@ -380,24 +403,22 @@ without compromising the minimum required capacity for running your workloads.

  {{< tabs name="k8s_install_kubeadm_worker_nodes" >}}
  {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
-  
+
  ```shell
  # 将 {{< skew currentVersion >}}.x-00 中的 x 替换为最新的补丁版本号
  apt-mark unhold kubeadm && \
  apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \
  apt-mark hold kubeadm
-  - 
-  # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
-  apt-get update && \
-  apt-get install -y --allow-change-held-packages kubeadm={{< skew currentVersion >}}.x-00
  ```
+
  {{% /tab %}}
  {{% tab name="CentOS、RHEL 或 Fedora" %}}
-  
+
  ```shell
  # 用最新的补丁版本替换 {{< skew currentVersion >}}.x-00 中的 x
  yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
  ```
+
  {{% /tab %}}
  {{< /tabs >}}

@@ -445,26 +466,22 @@ without compromising the minimum required capacity for running your workloads.

  {{< tabs name="k8s_kubelet_and_kubectl" >}}
  {{% tab name="Ubuntu、Debian 或 HypriotOS" %}}
-  
+
  ```shell
  # 将 {{< skew currentVersion >}}.x-00 中的 x 替换为最新的补丁版本
  apt-mark unhold kubelet kubectl && \
  apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
  apt-mark hold kubelet kubectl
-  
-  # 从 apt-get 的 1.1 版本开始，你也可以使用下面的方法：
-  
-  apt-get update && \
-  apt-get install -y --allow-change-held-packages kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00
  ```
-  
+
  {{% /tab %}}
  {{% tab name="CentOS, RHEL or Fedora" %}}
-  
+
  ```shell
  # 将 {{< skew currentVersion >}}.x-0 x 替换为最新的补丁版本
  yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
  ```
+
  {{% /tab %}}
  {{< /tabs >}}

@@ -524,7 +541,7 @@ kubectl get nodes
 <!--
 The `STATUS` column should show `Ready` for all your nodes, and the version number should be updated.
 -->
-`STATUS` 应显示所有节点为 `Ready` 状态，并且版本号已经被更新。 
+`STATUS` 应显示所有节点为 `Ready` 状态，并且版本号已经被更新。

 <!--
 ## Recovering from a failure state
@@ -624,6 +641,5 @@ and post-upgrade manifest file for a certain component, a backup file for it wil
 -->
 `kubeadm upgrade node` 在工作节点上完成以下工作：

- 从集群取回 kubeadm `ClusterConfiguration`。 
+- 从集群取回 kubeadm `ClusterConfiguration`。
 - 为本节点升级 kubelet 配置。
-
@@ -184,6 +184,10 @@ Now you can decode the `password` data:
 现在你可以解码 `password` 的数据：

 ```shell
+# 这是一个用于文档说明的示例。
+# 如果你这样做，数据 'MWYyZDFlMmU2N2Rm' 可以存储在你的 shell 历史中。
+# 可以进入你电脑的人可以找到那个记住的命令并可以在你不知情的情况下 base-64 解码这个 Secret。
+# 通常最好将这些步骤结合起来，如页面后面所示。
 echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
 ```

@@ -194,6 +198,21 @@ echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
 1f2d1e2e67df
 ```

+<!--
+In order to avoid storing a secret encoded value in your shell history, you can
+run the following command:
+-->
+为了避免在 shell 历史记录中存储 Secret 的编码值，可以执行如下命令:
+
+```shell
+kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode
+```
+
+<!--
+The output shall be similar as above.
+-->
+输出应与上述类似。
+
 <!-- ## Clean Up -->
 ## 清理    {#clean-up}

@@ -59,7 +59,7 @@ Here is the configuration file for the Pod:
   ```shell
   # 创建包含用户名和密码的文件:
   echo -n "admin" > ./username.txt
-   echo -n "1f2d1e2e67df" > ./password.txt-->
+   echo -n "1f2d1e2e67df" > ./password.txt

   # 将上述文件引用到 Secret：
   kubectl create secret generic user --from-file=./username.txt
@@ -631,7 +631,7 @@ in the `securityContext` section of your Pod or Container manifest. The
 [SeccompProfile](/docs/reference/generated/kubernetes-api/{{< param "version"
 >}}/#seccompprofile-v1-core) object consisting of `type` and `localhostProfile`.
 Valid options for `type` include `RuntimeDefault`, `Unconfined`, and
-`Localhost`. `localhostProfile` must only be set set if `type: Localhost`. It
+`Localhost`. `localhostProfile` must only be set if `type: Localhost`. It
 indicates the path of the pre-configured profile on the node, relative to the
 kubelet's configured Seccomp profile location (configured with the `-root-dir`
 flag).
@@ -45,8 +45,8 @@ Kubernetes node. `crictl` and its source are hosted in the
 <!--
 ## Installing crictl

-You can download a compressed archive `crictl` from the cri-tools [release
-page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
+You can download a compressed archive `crictl` from the cri-tools
+[release page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
 different architectures. Download the version that corresponds to your version
 of Kubernetes. Extract it and move it to a location on your system path, such as
 `/usr/local/bin/`.
@@ -70,20 +70,21 @@ The `crictl` command has several subcommands and runtime flags. Use
 有关详细信息，请使用 `crictl help` 或 `crictl <subcommand> help` 获取帮助信息。

 <!--
-`crictl` connects to `unix:///var/run/dockershim.sock` by default. For other
-runtimes, you can set the endpoint in multiple different ways:
+You can set the endpoint for `crictl` by doing one of the following:
 -->
-`crictl` 默认连接到 `unix:///var/run/dockershim.sock`。
-对于其他的运行时，你可以用多种不同的方法设置端点：
+你可以用以下方法之一来为 `crictl` 设置端点：

 <!--
- By setting flags `--runtime-endpoint` and `--image-endpoint`
- By setting environment variables `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT`
- By setting the endpoint in the config file `--config=/etc/crictl.yaml`
+* Set the `--runtime-endpoint` and `--image-endpoint` flags.
+* Set the `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT` environment
+  variables.
+* Set the endpoint in the configuration file `/etc/crictl.yaml`. To specify a
+  different file, use the `--config=PATH_TO_FILE` flag when you run `crictl`.
 -->
- 通过设置参数 `--runtime-endpoint` 和 `--image-endpoint`
- 通过设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`
- 通过在配置文件中设置端点 `--config=/etc/crictl.yaml`
+- 设置参数 `--runtime-endpoint` 和 `--image-endpoint`。
+- 设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`。
+- 在配置文件 `--config=/etc/crictl.yaml` 中设置端点。
+  要设置不同的文件，可以在运行 `crictl` 时使用 `--config=PATH_TO_FILE` 标志。

 <!--
 You can also specify timeout values when connecting to the server and enable or
@@ -95,20 +96,26 @@ file or using the `--timeout` and `--debug` command-line flags.

 <!--
 To view or edit the current configuration, view or edit the contents of
-`/etc/crictl.yaml`.
+`/etc/crictl.yaml`. For example, the configuration when using the `containerd`
+container runtime would be similar to this:
 -->
 要查看或编辑当前配置，请查看或编辑 `/etc/crictl.yaml` 的内容。
+例如，使用 `containerd` 容器运行时的配置会类似于这样：

-```shell
-cat /etc/crictl.yaml
 ```
-```
-runtime-endpoint: unix:///var/run/dockershim.sock
-image-endpoint: unix:///var/run/dockershim.sock
+runtime-endpoint: unix:///var/run/containerd/containerd.sock
+image-endpoint: unix:///var/run/containerd/containerd.sock
 timeout: 10
 debug: true
 ```

+<!--
+To learn more about `crictl`, refer to the [`crictl`
+documentation](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md).
+-->
+要进一步了解 `crictl`，参阅
+[`crictl` 文档](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。
+
 <!--
 ## Example crictl commands

@@ -140,7 +147,12 @@ List all pods:
 crictl pods
 ```

-```none
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
 POD ID              CREATED              STATE               NAME                         NAMESPACE           ATTEMPT
 926f1b5a1d33a       About a minute ago   Ready               sh-84d7dcf559-4r2gq          default             0
 4dccb216c4adb       About a minute ago   Ready               nginx-65899c769f-wv2gp       default             0
@@ -157,7 +169,12 @@ List pods by name:
 crictl pods --name nginx-65899c769f-wv2gp
 ```

-```none
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```
 POD ID              CREATED             STATE               NAME                     NAMESPACE           ATTEMPT
 4dccb216c4adb       2 minutes ago       Ready               nginx-65899c769f-wv2gp   default             0
 ```
@@ -170,6 +187,12 @@ List pods by label:
 ```shell
 crictl pods --label run=nginx
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 POD ID              CREATED             STATE               NAME                     NAMESPACE           ATTEMPT
 4dccb216c4adb       2 minutes ago       Ready               nginx-65899c769f-wv2gp   default             0
@@ -187,6 +210,12 @@ List all images:
 ```shell
 crictl images
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 IMAGE                                     TAG                 IMAGE ID            SIZE
 busybox                                   latest              8c811b4aec35f       1.15MB
@@ -203,6 +232,12 @@ List images by repository:
 ```shell
 crictl images nginx
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 IMAGE               TAG                 IMAGE ID            SIZE
 nginx               latest              cd5239a0906a6       109MB
@@ -216,6 +251,12 @@ Only list image IDs:
 ```shell
 crictl images -q
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a
 sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5
@@ -235,6 +276,12 @@ List all containers:
 ```shell
 crictl ps -a
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 CONTAINER ID        IMAGE                                                                                                             CREATED             STATE               NAME                       ATTEMPT
 1f73f2d81bf98       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   7 minutes ago       Running             sh                         1
@@ -251,6 +298,12 @@ List running containers:
 ```shell
 crictl ps
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 CONTAINER ID        IMAGE                                                                                                             CREATED             STATE               NAME                       ATTEMPT
 1f73f2d81bf98       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   6 minutes ago       Running             sh                         1
@@ -266,6 +319,12 @@ CONTAINER ID        IMAGE
 ```shell
 crictl exec -i -t 1f73f2d81bf98 ls
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 bin   dev   etc   home  proc  root  sys   tmp   usr   var
 ```
@@ -282,6 +341,12 @@ Get all container logs:
 ```shell
 crictl logs 87d3992f84f74
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
 10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
@@ -296,6 +361,12 @@ Get only the latest `N` lines of logs:
 ```shell
 crictl logs --tail=1 87d3992f84f74
 ```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```none
 10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
 ```
@@ -312,8 +383,10 @@ deleted by the Kubelet.
 用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。
 在运行的 Kubernetes 集群中，沙盒会随机地被 kubelet 停止和删除。

-1. <!--Create a JSON file like the following:-->
-   编写下面的 JSON 文件：
+<!--
+1. Create a JSON file like the following:
+-->
+1. 编写下面的 JSON 文件：

   ```json
   {
@@ -329,14 +402,18 @@ deleted by the Kubelet.
   }
   ```

-2. <!--Use the `crictl runp` command to apply the JSON and run the sandbox.-->
-   使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。
+<!--
+2. Use the `crictl runp` command to apply the JSON and run the sandbox.
+-->
+2. 使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。

   ```shell
   crictl runp pod-config.json
   ```

-   <!--The ID of the sandbox is returned.-->
+   <!--
+   The ID of the sandbox is returned.
+   -->
   返回了沙盒的 ID。

 <!--
@@ -351,20 +428,29 @@ deleted by the Kubelet.
 用 `crictl` 创建容器对容器运行时排错很有帮助。
 在运行的 Kubernetes 集群中，沙盒会随机的被 kubelet 停止和删除。

-1. <!--Pull a busybox image-->
-   拉取 busybox 镜像
+<!--
+1. Pull a busybox image
+-->
+1. 拉取 busybox 镜像

-   ```bash
+   ```shell
   crictl pull busybox
+   ```
+   ```none
   Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
   ```

-2. <!--Create configs for the pod and the container:-->
-   创建 Pod 和容器的配置：
+<!--
+2. Create configs for the pod and the container:
+-->
+2. 创建 Pod 和容器的配置：

-   <!--**Pod config**:-->
+   <!--
+   **Pod config**:
+   -->
   **Pod 配置**：
-   ```yaml
+
+   ```json
   {
       "metadata": {
           "name": "nginx-sandbox",
@@ -378,9 +464,12 @@ deleted by the Kubelet.
   }
   ```

-   <!--**Container config**:-->
+   <!--
+   **Container config**:
+   -->
   **容器配置**：
-   ```yaml
+
+   ```json
   {
     "metadata": {
         "name": "busybox"
@@ -397,22 +486,31 @@ deleted by the Kubelet.
   }
   ```

-3. <!--Create the container, passing the ID of the previously-created pod, the
+<!--
+3. Create the container, passing the ID of the previously-created pod, the
   container config file, and the pod config file. The ID of the container is
-   returned.-->
-   创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。
+   returned.
+-->
+3. 创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。

   ```bash
   crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json
   ```

-4. <!--List all containers and verify that the newly-created container has its
-   state set to `Created`.-->
-   查询所有容器并确认新创建的容器状态为 `Created`。
+<!--
+4. List all containers and verify that the newly-created container has its
+   state set to `Created`.
+-->
+4. 查询所有容器并确认新创建的容器状态为 `Created`。

   ```bash
   crictl ps -a
   ```
+   <!--
+   The output is similar to this:
+   -->
+   输出类似于这样：
+ 
   ```none
   CONTAINER ID        IMAGE               CREATED             STATE               NAME                ATTEMPT
   3e025dd50a72d       busybox             32 seconds ago      Created             busybox             0
@@ -430,7 +528,13 @@ To start a container, pass its ID to `crictl start`:
 ```shell
 crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
 ```
-```none
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```
 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
 ```

@@ -442,136 +546,23 @@ Check the container has its state set to `Running`.
 ```shell
 crictl ps
 ```
-```none
-CONTAINER ID        IMAGE               CREATED              STATE               NAME                ATTEMPT
-3e025dd50a72d       busybox             About a minute ago   Running             busybox             0
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
 ```
-<!-- discussion -->
+CONTAINER ID   IMAGE    CREATED              STATE    NAME     ATTEMPT
+3e025dd50a72d  busybox  About a minute ago   Running  busybox  0
+```
+
+## {{% heading "whatsnext" %}}

 <!--
-See [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)
-for more information.
+* [Learn more about `crictl`](https://github.com/kubernetes-sigs/cri-tools).
+* [Map `docker` CLI commands to `crictl`](/docs/reference/tools/map-crictl-dockercli/).
 -->
-更多信息请参考 [kubernetes-sigs/cri-tools](https://github.com/kubernetes-sigs/cri-tools)。
+* [进一步了解 `crictl`](https://github.com/kubernetes-sigs/cri-tools).
+* [将 `docker` CLI 命令映射到 `crictl`](/zh/docs/reference/tools/map-crictl-dockercli/).

-<!--
-## Mapping from docker cli to crictl
-->
-## Docker CLI 和 crictl 的映射
-
-<!--
-The exact versions for below mapping table are for docker cli v1.40 and crictl v1.19.0. Please note that the list is not exhaustive. For example, it doesn't include experimental commands of docker cli.
-->
-以下的映射表格只适用于 Docker CLI v1.40 和 crictl v1.19.0 版本。
-请注意该表格并不详尽。例如，其中不包含 Docker CLI 的实验性命令。
-
-<!--
-{{< note >}}
-The output format of CRICTL is similar to Docker CLI, despite some missing columns for some CLI. Make sure to check output for the specific command if your script output parsing.
-{{< /note >}}
-->
-{{< note >}}
-尽管有些命令的输出缺少了一些数据列，CRICTL 的输出格式与 Docker CLI 是类似的。
-如果你的脚本程序需要解析命令的输出，请确认检查该特定命令的输出。
-{{< /note >}}
-
-<!--
-### Retrieve Debugging Information
-
-{{< table caption="mapping from docker cli to crictl - retrieve debugging information" >}}
-->
-### 获取调试信息
-
-{{< table caption="Docker CLI 和 crictl 的映射 - 获取调试信息" >}}
-<!--
-docker cli | crictl | Description | Unsupported Features
-- | -- | -- | --
-`attach` | `attach` | Attach to a running container | `--detach-keys`, `--sig-proxy`
-`exec` | `exec` | Run a command in a running container | `--privileged`, `--user`, `--detach-keys`
-`images` | `images` | List images |  
-`info` | `info` | Display system-wide information |  
-`inspect` | `inspect`, `inspecti` | Return low-level information on a container, image or task |  
-`logs` | `logs` | Fetch the logs of a container | `--details`
-`ps` | `ps` | List containers |  
-`stats` | `stats` | Display a live stream of container(s) resource usage statistics | Column: NET/BLOCK I/O, PIDs
-`version` | `version` | Show the runtime (Docker, ContainerD, or others) version information |  
-{{< /table >}}
-->
-docker cli | crictl | 描述 | 不支持的功能
-- | -- | -- | --
-`attach` | `attach` | 连接到一个运行中的容器 | `--detach-keys`, `--sig-proxy`
-`exec` | `exec` | 在运行中的容器里运行一个命令 | `--privileged`, `--user`, `--detach-keys`
-`images` | `images` | 列举镜像 |  
-`info` | `info` | 显示系统级的信息 |  
-`inspect` | `inspect`, `inspecti` | 返回容器、镜像或者任务的详细信息 |  
-`logs` | `logs` | 获取容器的日志 | `--details`
-`ps` | `ps` | 列举容器 |  
-`stats` | `stats` | 实时显示容器的资源使用统计信息 | 列：NET/BLOCK I/O, PIDs
-`version` | `version` | 显示运行时（Docker、ContainerD、或者其他) 的版本信息 |  
-{{< /table >}}
-
-<!--
-### Perform Changes
-
-{{< table caption="mapping from docker cli to crictl - perform changes" >}}
-->
-### 进行改动
-
-{{< table caption="Docker CLI 和 crictl 的映射 - 进行改动" >}}
-<!--
-docker cli | crictl | Description | Unsupported Features
-- | -- | -- | --
-`create` | `create` | Create a new container |  
-`kill` | `stop` (timeout = 0) | Kill one or more running container | `--signal`
-`pull` | `pull` | Pull an image or a repository from a registry | `--all-tags`, `--disable-content-trust`
-`rm` | `rm` | Remove one or more containers |  
-`rmi` | `rmi` | Remove one or more images |  
-`run` | `run` | Run a command in a new container |  
-`start` | `start` | Start one or more stopped containers | `--detach-keys`
-`stop` | `stop` | Stop one or more running containers |  
-`update` | `update` | Update configuration of one or more containers | `--restart`, `--blkio-weight` and some other resource limit not supported by CRI.
-{{< /table >}}
-->
-docker cli | crictl | 描述 | 不支持的功能
-- | -- | -- | --
-`create` | `create` | 创建一个新的容器 |  
-`kill` | `stop` (timeout=0) | 杀死一个或多个正在运行的容器 | `--signal`
-`pull` | `pull` | 从镜像仓库拉取镜像或者代码仓库 | `--all-tags`, `--disable-content-trust`
-`rm` | `rm` | 移除一个或多个容器 |  
-`rmi` | `rmi` | 移除一个或多个镜像 |  
-`run` | `run` | 在新容器里运行一个命令 |  
-`start` | `start` | 启动一个或多个停止的容器 | `--detach-keys`
-`stop` | `stop` | 停止一个或多个正运行的容器 |  
-`update` | `update` | 更新一个或多个容器的配置 | CRI 不支持 `--restart`、`--blkio-weight` 以及一些其他的资源限制选项。
-{{< /table >}}
-
-<!--
-### Supported only in crictl
-
-{{< table caption="mapping from docker cli to crictl - supported only in crictl" >}}
-->
-### 仅 crictl 支持
-
-{{< table caption="Docker CLI 和 crictl 的映射 - 仅 crictl 支持" >}}
-<!--
-crictl | Description
-- | --
-`imagefsinfo` | Return image filesystem info
-`inspectp` | Display the status of one or more pods
-`port-forward` | Forward local port to a pod
-`pods` | List pods
-`runp` | Run a new pod
-`rmp` | Remove one or more pods
-`stopp` | Stop one or more running pods
-{{< /table >}}
-->
-crictl | 描述
-- | --
-`imagefsinfo` | 返回镜像的文件系统信息
-`inspectp` | 显示一个或多个 Pod 的状态
-`port-forward` | 转发本地端口到 Pod 
-`pods` | 列举 Pod
-`runp` | 运行一个新的 Pod
-`rmp` | 移除一个或多个 Pod
-`stopp` | 停止一个或多个正运行的 Pod
-{{< /table >}}
@@ -1,4 +1,4 @@
---
+:---
 reviewers:
 - janetkuo
 - thockin
@@ -120,12 +120,12 @@ Again, the information from `kubectl describe ...` should be informative.  The m
 #### My pod is crashing or otherwise unhealthy

 Once your pod has been scheduled, the methods described in [Debug Running Pods](
-/docs/tasks/debug-application-cluster/debug-running-pod/) are available for debugging.
+/docs/tasks/debug/debug-application/debug-running-pod/) are available for debugging.
 -->
 #### Pod 处于 Crashing 或别的不健康状态

 一旦 Pod 被调度，就可以采用
-[调试运行中的 Pod](/zh/docs/tasks/debug-application-cluster/debug-running-pod/)
+[调试运行中的 Pod](/zh/docs/tasks/debug/debug-application/debug-running-pod/)
 中的方法来进一步调试。

 <!--
@@ -160,12 +160,12 @@ worker node, but it can't run on that machine. Again, the information from
 ### My pod is crashing or otherwise unhealthy 

 Once your pod has been scheduled, the methods described in [Debug Running Pods](
-/docs/tasks/debug-application-cluster/debug-running-pod/) are available for debugging.
+/docs/tasks/debug/debug-application/debug-running-pod/) are available for debugging.
 -->
 ### 我的 Pod 一直 Crashing 或者其他不健康状态

 一旦 Pod 已经被调度，就可以依据
-[调试运行中的 Pod](/zh/docs/tasks/debug-application-cluster/debug-running-pod/)
+[调试运行中的 Pod](/zh/docs/tasks/debug/debug-application/debug-running-pod/)
 展开进一步的调试工作。

 <!-- 
@@ -0,0 +1,17 @@
+---
+title: "应用故障排除"
+description: 调试常见的容器应用问题.
+weight: 20
+--- 
+
+<!-- 
+title: "Troubleshooting Applications"
+description: Debugging common containerized application issues.
+weight: 20
+-->
+
+<!-- 
+This doc contains a set of resources for fixing issues with containerized applications. It covers things like common issues with Kubernetes resources (like Pods, Services, or StatefulSets), advice on making sense of container termination messages, and ways to debug running containers.
+-->
+此文档包含了一些用来解决容器应用问题的资源。它涵盖了 Kubernetes 资源（如 Pod、Service 或 StatefulSets）
+的常见问题，理解容器终止消息的建议以及调试正在运行的容器的方法。
@@ -0,0 +1,211 @@
+---
+title: 获取正在运行容器的 Shell
+content_type: task
+---
+
+<!-- overview -->
+
+<!--
+This page shows how to use `kubectl exec` to get a shell to a
+running Container.
+-->
+本文介绍怎样使用 `kubectl exec` 命令获取正在运行容器的 Shell。
+
+## {{% heading "prerequisites" %}}
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+<!-- steps -->
+
+<!--
+## Getting a shell to a Container
+-->
+
+## 获取容器的 Shell
+
+<!--
+In this exercise, you create a Pod that has one Container. The Container
+runs the nginx image. Here is the configuration file for the Pod:
+-->
+
+在本练习中，你将创建包含一个容器的 Pod。容器运行 nginx 镜像。下面是 Pod 的配置文件：
+
+{{< codenew file="application/shell-demo.yaml" >}}
+
+<!--
+Create the Pod:
+-->
+
+创建 Pod：
+
+```shell
+kubectl create -f https://k8s.io/examples/application/shell-demo.yaml
+```
+
+<!--
+Verify that the Container is running:
+-->
+
+检查容器是否运行正常：
+
+```shell
+kubectl get pod shell-demo
+```
+
+<!--
+Get a shell to the running Container:
+-->
+
+获取正在运行容器的 Shell：
+
+```shell
+kubectl exec -it shell-demo -- /bin/bash
+```
+{{< note >}}
+
+<!--
+The double dash symbol "--" is used to separate the arguments you want to pass to the command from the kubectl arguments.
+-->
+双破折号 "--" 用于将要传递给命令的参数与 kubectl 的参数分开。
+{{< /note >}}
+
+<!--
+In your shell, list the root directory:
+-->
+
+在 shell 中，打印根目录：
+
+```shell
+root@shell-demo:/# ls /
+```
+
+<!--
+In your shell, experiment with other commands. Here are
+some examples:
+-->
+
+在 shell 中，实验其他命令。下面是一些示例：
+
+```shell
+root@shell-demo:/# ls /
+root@shell-demo:/# cat /proc/mounts
+root@shell-demo:/# cat /proc/1/maps
+root@shell-demo:/# apt-get update
+root@shell-demo:/# apt-get install -y tcpdump
+root@shell-demo:/# tcpdump
+root@shell-demo:/# apt-get install -y lsof
+root@shell-demo:/# lsof
+root@shell-demo:/# apt-get install -y procps
+root@shell-demo:/# ps aux
+root@shell-demo:/# ps aux | grep nginx
+```
+
+<!--
+## Writing the root page for nginx
+-->
+
+## 编写 nginx 的根页面
+
+<!--
+Look again at the configuration file for your Pod. The Pod
+has an `emptyDir` volume, and the Container mounts the volume
+at `/usr/share/nginx/html`.
+-->
+
+在看一下 Pod 的配置文件。该 Pod 有个 `emptyDir` 卷，容器将该卷挂载到了 `/usr/share/nginx/html`。
+
+<!--
+In your shell, create an `index.html` file in the `/usr/share/nginx/html`
+directory:
+-->
+
+在 shell 中，在 `/usr/share/nginx/html` 目录创建一个 `index.html` 文件：
+
+```shell
+root@shell-demo:/# echo Hello shell demo > /usr/share/nginx/html/index.html
+```
+
+<!--
+In your shell, send a GET request to the nginx server:
+-->
+
+在 shell 中，向 nginx 服务器发送 GET 请求：
+
+```shell
+root@shell-demo:/# apt-get update
+root@shell-demo:/# apt-get install curl
+root@shell-demo:/# curl localhost
+```
+
+<!--
+The output shows the text that you wrote to the `index.html` file:
+-->
+
+输出结果显示了你在 `index.html` 中写入的文本。
+
+```shell
+Hello shell demo
+```
+
+<!--
+When you are finished with your shell, enter `exit`.
+-->
+
+当用完 shell 后，输入 `exit` 退出。
+
+<!--
+## Running individual commands in a Container
+-->
+
+## 在容器中运行单个命令
+
+<!--
+In an ordinary command window, not your shell, list the environment
+variables in the running Container:
+-->
+
+在普通的命令窗口（而不是 shell）中，打印环境运行容器中的变量：
+
+```shell
+kubectl exec shell-demo env
+```
+
+<!--
+Experiment running other commands. Here are some examples:
+-->
+
+实验运行其他命令。下面是一些示例：
+
+```shell
+kubectl exec shell-demo ps aux
+kubectl exec shell-demo ls /
+kubectl exec shell-demo cat /proc/1/mounts
+```
+
+<!-- discussion -->
+
+<!--
+## Opening a shell when a Pod has more than one Container
+-->
+
+## 当 Pod 包含多个容器时打开 shell
+
+<!--
+If a Pod has more than one Container, use `--container` or `-c` to
+specify a Container in the `kubectl exec` command. For example,
+suppose you have a Pod named my-pod, and the Pod has two containers
+named main-app and helper-app. The following command would open a
+shell to the main-app Container.
+-->
+
+如果 Pod 有多个容器，`--container` 或者 `-c` 可以在 `kubectl exec` 命令中指定容器。
+例如，您有个名为 my-pod 的容器，该 Pod 有两个容器分别为 main-app 和 healper-app。
+下面的命令将会打开一个 shell 访问 main-app 容器。
+
+```shell
+kubectl exec -it my-pod --container main-app -- /bin/bash
+```
+
+## {{% heading "whatsnext" %}}
+
+* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands/#exec)
@@ -0,0 +1,453 @@
+---
+title: 审计
+content_type: concept
+---
+<!--
+reviewers:
+- soltysh
+- sttts
+- ericchiang
+content_type: concept
+title: Auditing
+-->
+<!-- overview -->
+
+{{< feature-state state="beta" >}}
+
+<!--
+Kubernetes _auditing_ provides a security-relevant, chronological set of records documenting
+the sequence of actions in a cluster. The cluster audits the activities generated by users,
+by applications that use the Kubernetes API, and by the control plane itself.
+
+Auditing allows cluster administrators to answer the following questions:
+-->
+Kubernetes _审计（Auditing）_ 功能提供了与安全相关的、按时间顺序排列的记录集，
+记录每个用户、使用 Kubernetes API 的应用以及控制面自身引发的活动。
+
+审计功能使得集群管理员能够回答以下问题：
+
+<!--
+ - what happened?
+ - when did it happen?
+ - who initiated it?
+ - on what did it happen?
+ - where was it observed?
+ - from where was it initiated?
+ - to where was it going?
+-->
+ - 发生了什么？
+ - 什么时候发生的？
+ - 谁触发的？
+ - 活动发生在哪个（些）对象上？
+ - 在哪观察到的？
+ - 它从哪触发的？
+ - 活动的后续处理行为是什么？
+
+<!-- body -->
+
+<!--
+Audit records begin their lifecycle inside the
+[kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)
+component. Each request on each stage
+of its execution generates an audit event, which is then pre-processed according to
+a certain policy and written to a backend. The policy determines what's recorded
+and the backends persist the records. The current backend implementations
+include logs files and webhooks.
+-->
+审计记录最初产生于
+[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)
+内部。每个请求在不同执行阶段都会生成审计事件；这些审计事件会根据特定策略
+被预处理并写入后端。策略确定要记录的内容和用来存储记录的后端。
+当前的后端支持日志文件和 webhook。
+
+<!--
+Each request can be recorded with an associated _stage_. The defined stages are:
+
+- `RequestReceived` - The stage for events generated as soon as the audit
+  handler receives the request, and before it is delegated down the handler
+  chain.
+- `ResponseStarted` - Once the response headers are sent, but before the
+  response body is sent. This stage is only generated for long-running requests
+  (e.g. watch).
+- `ResponseComplete` - The response body has been completed and no more bytes
+  will be sent.
+- `Panic` - Events generated when a panic occurred.
+-->
+每个请求都可被记录其相关的 _阶段（stage）_。已定义的阶段有：
+
+- `RequestReceived` - 此阶段对应审计处理器接收到请求后，并且在委托给
+  其余处理器之前生成的事件。
+- `ResponseStarted` - 在响应消息的头部发送后，响应消息体发送前生成的事件。
+  只有长时间运行的请求（例如 watch）才会生成这个阶段。
+- `ResponseComplete` - 当响应消息体完成并且没有更多数据需要传输的时候。
+- `Panic` - 当 panic 发生时生成。
+
+<!-- 
+The configuration of an
+[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+is different from the
+[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+API object.
+-->
+{{< note >}}
+[审计事件配置](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+的配置与 [Event](/zh/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
+API 对象不同。
+{{< /note >}}
+
+<!--
+The audit logging feature increases the memory consumption of the API server
+because some context required for auditing is stored for each request.
+Additionally, memory consumption depends on the audit logging configuration.
+-->
+审计日志记录功能会增加 API server 的内存消耗，因为需要为每个请求存储审计所需的某些上下文。
+此外，内存消耗取决于审计日志记录的配置。
+
+<!--
+## Audit Policy
+
+Audit policy defines rules about what events should be recorded and what data
+they should include. The audit policy object structure is defined in the
+[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy).
+When an event is processed, it's
+compared against the list of rules in order. The first matching rule sets the
+_audit level_ of the event. The defined audit levels are:
+-->
+## 审计策略  {#audit-policy}
+
+审计政策定义了关于应记录哪些事件以及应包含哪些数据的规则。
+审计策略对象结构定义在
+[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
+处理事件时，将按顺序与规则列表进行比较。第一个匹配规则设置事件的
+_审计级别（Audit Level）_。已定义的审计级别有：
+
+<!--
+- `None` - don't log events that match this rule.
+- `Metadata` - log request metadata (requesting user, timestamp, resource,
+  verb, etc.) but not request or response body.
+- `Request` - log event metadata and request body but not response body.
+  This does not apply for non-resource requests.
+- `RequestResponse` - log event metadata, request and response bodies.
+  This does not apply for non-resource requests.
+-->
+- `None` - 符合这条规则的日志将不会记录。
+- `Metadata` - 记录请求的元数据（请求的用户、时间戳、资源、动词等等），
+  但是不记录请求或者响应的消息体。
+- `Request` - 记录事件的元数据和请求的消息体，但是不记录响应的消息体。
+  这不适用于非资源类型的请求。
+- `RequestResponse` - 记录事件的元数据，请求和响应的消息体。这不适用于非资源类型的请求。
+
+<!--
+You can pass a file with the policy to `kube-apiserver`
+using the `--audit-policy-file` flag. If the flag is omitted, no events are logged.
+Note that the `rules` field __must__ be provided in the audit policy file.
+A policy with no (0) rules is treated as illegal.
+
+Below is an example audit policy file:
+-->
+你可以使用 `--audit-policy-file` 标志将包含策略的文件传递给 `kube-apiserver`。
+如果不设置该标志，则不记录事件。
+注意 `rules` 字段 __必须__ 在审计策略文件中提供。没有（0）规则的策略将被视为非法配置。
+
+以下是一个审计策略文件的示例：
+
+{{< codenew file="audit/audit-policy.yaml" >}}
+
+<!--
+You can use a minimal audit policy file to log all requests at the `Metadata` level:
+-->
+你可以使用最低限度的审计策略文件在 `Metadata` 级别记录所有请求：
+
+```yaml
+# 在 Metadata 级别为所有请求生成日志
+apiVersion: audit.k8s.io/v1beta1
+kind: Policy
+rules:
+- level: Metadata
+```
+
+<!--
+If you're crafting your own audit profile, you can use the audit profile for Google Container-Optimized OS as a starting point. You can check the
+[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
+script, which generates the audit policy file. You can see most of the audit policy file by looking directly at the script.
+
+You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
+for details about the fields defined.
+-->
+如果你在打磨自己的审计配置文件，你可以使用为 Google Container-Optimized OS
+设计的审计配置作为出发点。你可以参考
+[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)
+脚本，该脚本能够生成审计策略文件。你可以直接在脚本中看到审计策略的绝大部份内容。
+
+你也可以参考 [`Policy` 配置参考](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
+以获取有关已定义字段的详细信息。
+
+<!--
+## Audit backends
+
+Audit backends persist audit events to an external storage.
+Out of the box, the kube-apiserver provides two backends:
+
+- Log backend, which writes events into the filesystem
+- Webhook backend, which sends events to an external HTTP API
+
+In all cases, audit events follow a structure defined by the Kubernetes API in the
+[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event).
+-->
+
+## 审计后端   {#audit-backends}
+
+审计后端实现将审计事件导出到外部存储。`Kube-apiserver` 默认提供两个后端：
+
+- Log 后端，将事件写入到文件系统
+- Webhook 后端，将事件发送到外部 HTTP API
+
+在这所有情况下，审计事件均遵循 Kubernetes API 在
+[`audit.k8s.io` API 组](/zh/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
+中定义的结构。
+
+<!--
+In case of patches, request body is a JSON array with patch operations, not a JSON object
+with an appropriate Kubernetes API object. For example, the following request body is a valid patch
+request to `/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`.
+-->
+{{< note >}}
+对于 patch 请求，请求的消息体需要是设定 patch 操作的 JSON 所构成的一个串，
+而不是一个完整的 Kubernetes API 对象 JSON 串。
+例如，以下的示例是一个合法的 patch 请求消息体，该请求对应
+`/apis/batch/v1/namespaces/some-namespace/jobs/some-job-name`。
+
+```json
+[
+  {
+    "op": "replace",
+    "path": "/spec/parallelism",
+    "value": 0
+  },
+  {
+    "op": "remove",
+    "path": "/spec/template/spec/containers/0/terminationMessagePolicy"
+  }
+]
+```
+{{< /note >}}
+
+<!--
+### Log backend
+
+The log backend writes audit events to a file in [JSONlines](https://jsonlines.org/) format.
+You can configure the log audit backend using the following `kube-apiserver` flags:
+
+Log backend writes audit events to a file in JSON format. You can configure
+log audit backend using the following [kube-apiserver][kube-apiserver] flags:
+-->
+### Log 后端
+
+Log 后端将审计事件写入 [JSONlines](https://jsonlines.org/)  格式的文件。
+你可以使用以下 `kube-apiserver` 标志配置 Log 审计后端：
+
+<!--
+- `--audit-log-path` specifies the log file path that log backend uses to write
+  audit events. Not specifying this flag disables log backend. `-` means standard out
+- `--audit-log-maxage` defined the maximum number of days to retain old audit log files
+- `--audit-log-maxbackup` defines the maximum number of audit log files to retain
+- `--audit-log-maxsize` defines the maximum size in megabytes of the audit log file before it gets rotated
+-->
+- `--audit-log-path` 指定用来写入审计事件的日志文件路径。不指定此标志会禁用日志后端。`-` 意味着标准化
+- `--audit-log-maxage` 定义保留旧审计日志文件的最大天数
+- `--audit-log-maxbackup` 定义要保留的审计日志文件的最大数量
+- `--audit-log-maxsize` 定义审计日志文件的最大大小（兆字节）
+
+<!--
+If your cluster's control plane runs the kube-apiserver as a Pod, remember to mount the `hostPath`
+to the location of the policy file and log file, so that audit records are persisted. For example:
+-->
+如果你的集群控制面以 Pod 的形式运行 kube-apiserver，记得要通过 `hostPath`
+卷来访问策略文件和日志文件所在的目录，这样审计记录才会持久保存下来。例如：
+
+```shell
+  --audit-policy-file=/etc/kubernetes/audit-policy.yaml
+  --audit-log-path=/var/log/kubernetes/audit/audit.log
+```
+
+接下来挂载数据卷：
+
+```yaml
+volumeMounts:
+  - mountPath: /etc/kubernetes/audit-policy.yaml
+    name: audit
+    readOnly: true
+  - mountPath: /var/log/kubernetes/audit/
+    name: audit-log
+    readOnly: false
+```
+
+<!-- 
+and finally configure the `hostPath`:
+-->
+最后配置 `hostPath`：
+
+```yaml
+...
+volumes:
+- name: audit
+  hostPath:
+    path: /etc/kubernetes/audit-policy.yaml
+    type: File
+
+- name: audit-log
+  hostPath:
+    path: /var/log/kubernetes/audit/
+    type: DirectoryOrCreate
+```
+
+<!--
+### Webhook backend
+
+The webhook audit backend sends audit events to a remote web API, which is assumed to
+be a form of the Kubernetes API, including means of authentication. You can configure
+a webhook audit backend using the following kube-apiserver flags:
+-->
+### Webhook 后端   {#webhook-backend}
+
+Webhook 后端将审计事件发送到远程 Web API，该远程 API 应该暴露与 `kube-apiserver`
+形式相同的 API，包括其身份认证机制。你可以使用如下 kube-apiserver 标志来配置
+Webhook 审计后端：
+
+<!--
+- `--audit-webhook-config-file` specifies the path to a file with a webhook
+  configuration. The webhook configuration is effectively a specialized
+  [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters).
+- `--audit-webhook-initial-backoff` specifies the amount of time to wait after the first failed
+  request before retrying. Subsequent requests are retried with exponential backoff.
+
+The webhook config file uses the kubeconfig format to specify the remote address of
+the service and credentials used to connect to it.
+-->
+- `--audit-webhook-config-file` 设置 Webhook 配置文件的路径。Webhook 配置文件实际上是一个
+  [kubeconfig 文件](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/)。
+- `--audit-webhook-initial-backoff` 指定在第一次失败后重发请求等待的时间。随后的请求将以指数退避重试。
+
+Webhook 配置文件使用 kubeconfig 格式指定服务的远程地址和用于连接它的凭据。
+
+<!--
+## Event batching {#batching}
+
+Both log and webhook backends support batching. Using webhook as an example, here's the list of
+available flags. To get the same flag for log backend, replace `webhook` with `log` in the flag
+name. By default, batching is enabled in `webhook` and disabled in `log`. Similarly, by default
+throttling is enabled in `webhook` and disabled in `log`.
+-->
+## 事件批处理  {#batching}
+
+日志和 Webhook 后端都支持批处理。以 Webhook 为例，以下是可用参数列表。要获取日志
+后端的同样参数，请在参数名称中将 `webhook` 替换为 `log`。
+默认情况下，在 `webhook` 中批处理是被启用的，在 `log` 中批处理是被禁用的。
+同样，默认情况下，在 `webhook` 中启用带宽限制，在 `log` 中禁用带宽限制。
+
+<!--
+  - `--audit-webhook-mode` defines the buffering strategy. One of the following:
+  - `batch` - buffer events and asynchronously process them in batches. This is the default.
+  - `blocking` - block API server responses on processing each individual event.
+  - `blocking-strict` - Same as blocking, but when there is a failure during audit logging at the
+     RequestReceived stage, the whole request to the kube-apiserver fails.
+-->
+- `--audit-webhook-mode` 定义缓存策略，可选值如下：
+  - `batch` - 以批处理缓存事件和异步的过程。这是默认值。
+  - `blocking` - 在 API 服务器处理每个单独事件时，阻塞其响应。
+  - `blocking-strict` - 与 `blocking` 相同，不过当审计日志在 RequestReceived 阶段
+    失败时，整个 API 服务请求会失效。
+
+<!--
+The following flags are used only in the `batch` mode.
+
+- `--audit-webhook-batch-buffer-size` defines the number of events to buffer before batching.
+  If the rate of incoming events overflows the buffer, events are dropped.
+- `--audit-webhook-batch-max-size` defines the maximum number of events in one batch.
+- `--audit-webhook-batch-max-wait` defines the maximum amount of time to wait before unconditionally
+  batching events in the queue.
+- `--audit-webhook-batch-throttle-qps` defines the maximum average number of batches generated
+  per second.
+- `--audit-webhook-batch-throttle-burst` defines the maximum number of batches generated at the same
+  moment if the allowed QPS was underutilized previously.
+-->
+以下参数仅用于 `batch` 模式。
+
+- `--audit-webhook-batch-buffer-size` 定义 batch 之前要缓存的事件数。
+  如果传入事件的速率溢出缓存区，则会丢弃事件。
+- `--audit-webhook-batch-max-size` 定义一个 batch 中的最大事件数。
+- `--audit-webhook-batch-max-wait` 无条件 batch 队列中的事件前等待的最大事件。
+- `--audit-webhook-batch-throttle-qps` 每秒生成的最大批次数。
+- `--audit-webhook-batch-throttle-burst` 在达到允许的 QPS 前，同一时刻允许存在的最大 batch 生成数。
+
+<!--
+## Parameter tuning
+
+Parameters should be set to accommodate the load on the API server.
+
+For example, if kube-apiserver receives 100 requests each second, and each request is audited only
+on `ResponseStarted` and `ResponseComplete` stages, you should account for ≅200 audit
+events being generated each second. Assuming that there are up to 100 events in a batch,
+you should set throttling level at least 2 queries per second. Assuming that the backend can take up to
+5 seconds to write events, you should set the buffer size to hold up to 5 seconds of events;
+that is: 10 batches, or 1000 events.
+-->
+## 参数调整   {#parameter-tuning}
+
+需要设置参数以适应 API 服务器上的负载。
+
+例如，如果 kube-apiserver 每秒收到 100 个请求，并且每个请求仅在 `ResponseStarted`
+和 `ResponseComplete` 阶段进行审计，则应该考虑每秒生成约 200 个审计事件。
+假设批处理中最多有 100 个事件，则应将限制级别设置为每秒至少 2 个查询。
+假设后端最多需要 5 秒钟来写入事件，你应该设置缓冲区大小以容纳最多 5 秒的事件，
+即 10 个 batch，即 1000 个事件。
+
+<!--
+In most cases however, the default parameters should be sufficient and you don't have to worry about
+setting them manually. You can look at the following Prometheus metrics exposed by kube-apiserver
+and in the logs to monitor the state of the auditing subsystem.
+
+- `apiserver_audit_event_total` metric contains the total number of audit events exported.
+- `apiserver_audit_error_total` metric contains the total number of events dropped due to an error
+  during exporting.
+-->
+但是，在大多数情况下，默认参数应该足够了，你不必手动设置它们。
+你可以查看 kube-apiserver 公开的以下 Prometheus 指标，并在日志中监控审计子系统的状态。
+
+- `apiserver_audit_event_total` 包含所有暴露的审计事件数量的指标。
+- `apiserver_audit_error_total` 在暴露时由于发生错误而被丢弃的事件的数量。
+
+<!--
+### Log entry truncation {#truncate}
+
+Both log and webhook backends support limiting the size of events that are logged.
+As an example, the following is the list of flags available for the log backend:
+-->
+### 日志条目截断   {#truncate}
+
+日志后端和 Webhook 后端都支持限制所输出的事件的尺寸。
+例如，下面是可以为日志后端配置的标志列表：
+
+<!--
+- `audit-log-truncate-enabled` whether event and batch truncating is enabled.
+- `audit-log-truncate-max-batch-size` maximum size in bytes of the batch sent to the underlying backend.
+- `audit-log-truncate-max-event-size` maximum size in bytes of the audit event sent to the underlying backend.
+-->
+- `audit-log-truncate-enabled`：是否弃用事件和批次的截断处理。
+- `audit-log-truncate-max-batch-size`：向下层后端发送的各批次的最大尺寸字节数。
+- `audit-log-truncate-max-event-size`：向下层后端发送的审计事件的最大尺寸字节数。
+
+<!--
+By default truncate is disabled in both `webhook` and `log`, a cluster administrator should set
+`audit-log-truncate-enabled` or `audit-webhook-truncate-enabled` to enable the feature.
+-->
+默认情况下，截断操作在 `webhook` 和 `log` 后端都是被禁用的，集群管理员需要设置
+`audit-log-truncate-enabled` 或 `audit-webhook-truncate-enabled` 标志来启用此操作。
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
+-->
+* 了解 [Mutating webhook 审计注解](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations)。
+
@@ -0,0 +1,566 @@
+---
+reviewers:
+- Random-Liu
+- feiskyer
+- mrunalp
+title: 使用 crictl 对 Kubernetes 节点进行调试
+content_type: task
+---
+
+<!--
+reviewers:
+- Random-Liu
+- feiskyer
+- mrunalp
+title: Debugging Kubernetes nodes with crictl
+content_type: task
+-->
+
+<!-- overview -->
+
+{{< feature-state for_k8s_version="v1.11" state="stable" >}}
+
+<!--
+`crictl` is a command-line interface for CRI-compatible container runtimes.
+You can use it to inspect and debug container runtimes and applications on a
+Kubernetes node. `crictl` and its source are hosted in the
+[cri-tools](https://github.com/kubernetes-sigs/cri-tools) repository.
+-->
+
+`crictl` 是 CRI 兼容的容器运行时命令行接口。
+你可以使用它来检查和调试 Kubernetes 节点上的容器运行时和应用程序。
+`crictl` 和它的源代码在
+[cri-tools](https://github.com/kubernetes-sigs/cri-tools) 代码库。
+
+## {{% heading "prerequisites" %}}
+
+<!--
+`crictl` requires a Linux operating system with a CRI runtime.
+-->
+`crictl` 需要带有 CRI 运行时的 Linux 操作系统。
+
+<!-- steps -->
+
+<!--
+## Installing crictl
+
+You can download a compressed archive `crictl` from the cri-tools
+[release page](https://github.com/kubernetes-sigs/cri-tools/releases), for several
+different architectures. Download the version that corresponds to your version
+of Kubernetes. Extract it and move it to a location on your system path, such as
+`/usr/local/bin/`.
+-->
+## 安装 crictl
+
+你可以从 cri-tools [发布页面](https://github.com/kubernetes-sigs/cri-tools/releases)
+下载一个压缩的 `crictl` 归档文件，用于几种不同的架构。
+下载与你的 kubernetes 版本相对应的版本。
+提取它并将其移动到系统路径上的某个位置，例如`/usr/local/bin/`。
+
+<!--
+## General usage
+
+The `crictl` command has several subcommands and runtime flags. Use
+`crictl help` or `crictl <subcommand> help` for more details.
+-->
+## 一般用法
+
+`crictl` 命令有几个子命令和运行时参数。
+有关详细信息，请使用 `crictl help` 或 `crictl <subcommand> help` 获取帮助信息。
+
+<!--
+You can set the endpoint for `crictl` by doing one of the following:
+-->
+你可以用以下方法之一来为 `crictl` 设置端点：
+
+<!--
+* Set the `--runtime-endpoint` and `--image-endpoint` flags.
+* Set the `CONTAINER_RUNTIME_ENDPOINT` and `IMAGE_SERVICE_ENDPOINT` environment
+  variables.
+* Set the endpoint in the configuration file `/etc/crictl.yaml`. To specify a
+  different file, use the `--config=PATH_TO_FILE` flag when you run `crictl`.
+-->
+- 设置参数 `--runtime-endpoint` 和 `--image-endpoint`。
+- 设置环境变量 `CONTAINER_RUNTIME_ENDPOINT` 和 `IMAGE_SERVICE_ENDPOINT`。
+- 在配置文件 `--config=/etc/crictl.yaml` 中设置端点。
+  要设置不同的文件，可以在运行 `crictl` 时使用 `--config=PATH_TO_FILE` 标志。
+
+<!--
+You can also specify timeout values when connecting to the server and enable or
+disable debugging, by specifying `timeout` or `debug` values in the configuration
+file or using the `--timeout` and `--debug` command-line flags.
+-->
+你还可以在连接到服务器并启用或禁用调试时指定超时值，方法是在配置文件中指定
+`timeout` 或 `debug` 值，或者使用 `--timeout` 和 `--debug` 命令行参数。
+
+<!--
+To view or edit the current configuration, view or edit the contents of
+`/etc/crictl.yaml`. For example, the configuration when using the `containerd`
+container runtime would be similar to this:
+-->
+要查看或编辑当前配置，请查看或编辑 `/etc/crictl.yaml` 的内容。
+例如，使用 `containerd` 容器运行时的配置会类似于这样：
+
+```
+runtime-endpoint: unix:///var/run/containerd/containerd.sock
+image-endpoint: unix:///var/run/containerd/containerd.sock
+timeout: 10
+debug: true
+```
+
+<!--
+To learn more about `crictl`, refer to the [`crictl`
+documentation](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md).
+-->
+要进一步了解 `crictl`，参阅
+[`crictl` 文档](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md)。
+
+<!--
+## Example crictl commands
+
+The following examples show some `crictl` commands and example output.
+-->
+## crictl 命令示例
+
+{{< warning >}}
+<!--
+If you use `crictl` to create pod sandboxes or containers on a running
+Kubernetes cluster, the Kubelet will eventually delete them. `crictl` is not a
+general purpose workflow tool, but a tool that is useful for debugging.
+-->
+如果使用 `crictl` 在正在运行的 Kubernetes 集群上创建 Pod 沙盒或容器，
+kubelet 最终将删除它们。
+`crictl` 不是一个通用的工作流工具，而是一个对调试有用的工具。
+{{< /warning >}}
+
+<!--
+### List pods
+
+List all pods:
+-->
+### 打印 Pod 清单
+
+打印所有 Pod 的清单：
+
+```shell
+crictl pods
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于：
+
+```
+POD ID              CREATED              STATE               NAME                         NAMESPACE           ATTEMPT
+926f1b5a1d33a       About a minute ago   Ready               sh-84d7dcf559-4r2gq          default             0
+4dccb216c4adb       About a minute ago   Ready               nginx-65899c769f-wv2gp       default             0
+a86316e96fa89       17 hours ago         Ready               kube-proxy-gblk4             kube-system         0
+919630b8f81f1       17 hours ago         Ready               nvidia-device-plugin-zgbbv   kube-system         0
+```
+
+<!--
+List pods by name:
+-->
+根据名称打印 Pod 清单：
+
+```shell
+crictl pods --name nginx-65899c769f-wv2gp
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```
+POD ID              CREATED             STATE               NAME                     NAMESPACE           ATTEMPT
+4dccb216c4adb       2 minutes ago       Ready               nginx-65899c769f-wv2gp   default             0
+```
+
+<!--
+List pods by label:
+-->
+根据标签打印 Pod 清单：
+
+```shell
+crictl pods --label run=nginx
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+POD ID              CREATED             STATE               NAME                     NAMESPACE           ATTEMPT
+4dccb216c4adb       2 minutes ago       Ready               nginx-65899c769f-wv2gp   default             0
+```
+
+<!--
+### List images
+
+List all images:
+-->
+### 打印镜像清单
+
+打印所有镜像清单：
+
+```shell
+crictl images
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+IMAGE                                     TAG                 IMAGE ID            SIZE
+busybox                                   latest              8c811b4aec35f       1.15MB
+k8s-gcrio.azureedge.net/hyperkube-amd64   v1.10.3             e179bbfe5d238       665MB
+k8s-gcrio.azureedge.net/pause-amd64       3.1                 da86e6ba6ca19       742kB
+nginx                                     latest              cd5239a0906a6       109MB
+```
+
+<!--
+List images by repository:
+-->
+根据仓库打印镜像清单：
+
+```shell
+crictl images nginx
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+IMAGE               TAG                 IMAGE ID            SIZE
+nginx               latest              cd5239a0906a6       109MB
+```
+
+<!--
+Only list image IDs:
+-->
+只打印镜像 ID：
+
+```shell
+crictl images -q
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+sha256:8c811b4aec35f259572d0f79207bc0678df4c736eeec50bc9fec37ed936a472a
+sha256:e179bbfe5d238de6069f3b03fccbecc3fb4f2019af741bfff1233c4d7b2970c5
+sha256:da86e6ba6ca197bf6bc5e9d900febd906b133eaa4750e6bed647b0fbe50ed43e
+sha256:cd5239a0906a6ccf0562354852fae04bc5b52d72a2aff9a871ddb6bd57553569
+```
+
+<!--
+### List containers
+
+List all containers:
+-->
+### 打印容器清单
+
+打印所有容器清单：
+
+```shell
+crictl ps -a
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+CONTAINER ID        IMAGE                                                                                                             CREATED             STATE               NAME                       ATTEMPT
+1f73f2d81bf98       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   7 minutes ago       Running             sh                         1
+9c5951df22c78       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   8 minutes ago       Exited              sh                         0
+87d3992f84f74       nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f                                     8 minutes ago       Running             nginx                      0
+1941fb4da154f       k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a   18 hours ago        Running             kube-proxy                 0
+```
+
+<!--
+List running containers:
+-->
+打印正在运行的容器清单：
+
+```shell
+crictl ps
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+CONTAINER ID        IMAGE                                                                                                             CREATED             STATE               NAME                       ATTEMPT
+1f73f2d81bf98       busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47                                   6 minutes ago       Running             sh                         1
+87d3992f84f74       nginx@sha256:d0a8828cccb73397acb0073bf34f4d7d8aa315263f1e7806bf8c55d8ac139d5f                                     7 minutes ago       Running             nginx                      0
+1941fb4da154f       k8s-gcrio.azureedge.net/hyperkube-amd64@sha256:00d814b1f7763f4ab5be80c58e98140dfc69df107f253d7fdd714b30a714260a   17 hours ago        Running             kube-proxy                 0
+```
+
+<!--
+### Execute a command in a running container
+-->
+### 在正在运行的容器上执行命令
+
+```shell
+crictl exec -i -t 1f73f2d81bf98 ls
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+bin   dev   etc   home  proc  root  sys   tmp   usr   var
+```
+
+<!--
+### Get a container's logs
+
+Get all container logs:
+-->
+### 获取容器日志
+
+获取容器的所有日志：
+
+```shell
+crictl logs 87d3992f84f74
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+10.240.0.96 - - [06/Jun/2018:02:45:49 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
+10.240.0.96 - - [06/Jun/2018:02:45:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
+10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
+```
+
+<!--
+Get only the latest `N` lines of logs:
+-->
+获取最近的 `N` 行日志：
+
+```shell
+crictl logs --tail=1 87d3992f84f74
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```none
+10.240.0.96 - - [06/Jun/2018:02:45:51 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"
+```
+
+<!--
+### Run a pod sandbox
+
+Using `crictl` to run a pod sandbox is useful for debugging container runtimes.
+On a running Kubernetes cluster, the sandbox will eventually be stopped and
+deleted by the Kubelet.
+-->
+### 运行 Pod 沙盒
+
+用 `crictl` 运行 Pod 沙盒对容器运行时排错很有帮助。
+在运行的 Kubernetes 集群中，沙盒会随机地被 kubelet 停止和删除。
+
+<!--
+1. Create a JSON file like the following:
+-->
+1. 编写下面的 JSON 文件：
+
+   ```json
+   {
+       "metadata": {
+           "name": "nginx-sandbox",
+           "namespace": "default",
+           "attempt": 1,
+           "uid": "hdishd83djaidwnduwk28bcsb"
+       },
+       "logDirectory": "/tmp",
+       "linux": {
+       }
+   }
+   ```
+
+<!--
+2. Use the `crictl runp` command to apply the JSON and run the sandbox.
+-->
+2. 使用 `crictl runp` 命令应用 JSON 文件并运行沙盒。
+
+   ```shell
+   crictl runp pod-config.json
+   ```
+
+   <!--
+   The ID of the sandbox is returned.
+   -->
+   返回了沙盒的 ID。
+
+<!--
+### Create a container
+
+Using `crictl` to create a container is useful for debugging container runtimes.
+On a running Kubernetes cluster, the sandbox will eventually be stopped and
+deleted by the Kubelet.
+-->
+### 创建容器
+
+用 `crictl` 创建容器对容器运行时排错很有帮助。
+在运行的 Kubernetes 集群中，沙盒会随机的被 kubelet 停止和删除。
+
+<!--
+1. Pull a busybox image
+-->
+1. 拉取 busybox 镜像
+
+   ```shell
+   crictl pull busybox
+   ```
+   ```none
+   Image is up to date for busybox@sha256:141c253bc4c3fd0a201d32dc1f493bcf3fff003b6df416dea4f41046e0f37d47
+   ```
+
+<!--
+2. Create configs for the pod and the container:
+-->
+2. 创建 Pod 和容器的配置：
+
+   <!--
+   **Pod config**:
+   -->
+   **Pod 配置**：
+
+   ```json
+   {
+       "metadata": {
+           "name": "nginx-sandbox",
+           "namespace": "default",
+           "attempt": 1,
+           "uid": "hdishd83djaidwnduwk28bcsb"
+       },
+       "log_directory": "/tmp",
+       "linux": {
+       }
+   }
+   ```
+
+   <!--
+   **Container config**:
+   -->
+   **容器配置**：
+
+   ```json
+   {
+     "metadata": {
+         "name": "busybox"
+     },
+     "image":{
+         "image": "busybox"
+     },
+     "command": [
+         "top"
+     ],
+     "log_path":"busybox.log",
+     "linux": {
+     }
+   }
+   ```
+
+<!--
+3. Create the container, passing the ID of the previously-created pod, the
+   container config file, and the pod config file. The ID of the container is
+   returned.
+-->
+3. 创建容器，传递先前创建的 Pod 的 ID、容器配置文件和 Pod 配置文件。返回容器的 ID。
+
+   ```bash
+   crictl create f84dd361f8dc51518ed291fbadd6db537b0496536c1d2d6c05ff943ce8c9a54f container-config.json pod-config.json
+   ```
+
+<!--
+4. List all containers and verify that the newly-created container has its
+   state set to `Created`.
+-->
+4. 查询所有容器并确认新创建的容器状态为 `Created`。
+
+   ```bash
+   crictl ps -a
+   ```
+   <!--
+   The output is similar to this:
+   -->
+   输出类似于这样：
+ 
+   ```none
+   CONTAINER ID        IMAGE               CREATED             STATE               NAME                ATTEMPT
+   3e025dd50a72d       busybox             32 seconds ago      Created             busybox             0
+   ```
+
+<!--
+### Start a container
+
+To start a container, pass its ID to `crictl start`:
+-->
+### 启动容器
+
+要启动容器，要将容器 ID 传给 `crictl start`：
+
+```shell
+crictl start 3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```
+3e025dd50a72d956c4f14881fbb5b1080c9275674e95fb67f965f6478a957d60
+```
+
+<!--
+Check the container has its state set to `Running`.
+-->
+确认容器的状态为 `Running`。
+
+```shell
+crictl ps
+```
+
+<!--
+The output is similar to this:
+-->
+输出类似于这样：
+
+```
+CONTAINER ID   IMAGE    CREATED              STATE    NAME     ATTEMPT
+3e025dd50a72d  busybox  About a minute ago   Running  busybox  0
+```
+
+## {{% heading "whatsnext" %}}
+
+<!--
+* [Learn more about `crictl`](https://github.com/kubernetes-sigs/cri-tools).
+* [Map `docker` CLI commands to `crictl`](/docs/reference/tools/map-crictl-dockercli/).
+-->
+* [进一步了解 `crictl`](https://github.com/kubernetes-sigs/cri-tools).
+* [将 `docker` CLI 命令映射到 `crictl`](/zh/docs/reference/tools/map-crictl-dockercli/).
@@ -1,10 +1,10 @@
 ---
-title: 在本地开发和调试服务
+title: 使用 telepresence 在本地开发和调试服务
 content_type: task
 ---

 <!--
-title: Developing and debugging services locally
+title: Developing and debugging services locally using telepresence
 content_type: task
 -->

@@ -1,6 +1,7 @@
 ---
 content_type: task
 title: 节点健康监测
+weight: 20
 ---
 <!-- 
 title: Monitor Node Health
@@ -8,6 +9,7 @@ content_type: task
 reviewers:
 - Random-Liu
 - dchen1107
+weight: 20
 -->

 <!-- overview -->
@@ -1,6 +1,7 @@
 ---
 title: 资源指标管道
 content_type: concept
+weight: 15
 ---
 <!--
 reviewers:
@@ -8,6 +9,7 @@ reviewers:
 - piosz
 title: Resource metrics pipeline
 content_type: concept
+weight: 15
 -->

 <!-- overview -->
@@ -0,0 +1,113 @@
+---
+content_type: concept
+title: 资源监控工具
+---
+<!--
+reviewers:
+- mikedanese
+content_type: concept
+title: Tools for Monitoring Resources
+-->
+
+<!-- overview -->
+
+<!--
+To scale an application and provide a reliable service, you need to
+understand how the application behaves when it is deployed. You can examine
+application performance in a Kubernetes cluster by examining the containers,
+[pods](/docs/concepts/workloads/pods/),
+[services](/docs/concepts/services-networking/service/), and
+the characteristics of the overall cluster. Kubernetes provides detailed
+information about an application's resource usage at each of these levels.
+This information allows you to evaluate your application's performance and
+where bottlenecks can be removed to improve overall performance.
+-->
+要扩展应用程序并提供可靠的服务，你需要了解应用程序在部署时的行为。
+你可以通过检测容器检查 Kubernetes 集群中的应用程序性能，
+[Pods](/zh/docs/concepts/workloads/pods), 
+[服务](/zh/docs/concepts/services-networking/service/)
+和整个集群的特征。
+Kubernetes 在每个级别上提供有关应用程序资源使用情况的详细信息。
+此信息使你可以评估应用程序的性能，以及在何处可以消除瓶颈以提高整体性能。
+
+<!-- body -->
+
+<!--
+In Kubernetes, application monitoring does not depend on a single monitoring solution.
+On new clusters, you can use [resource metrics](#resource-metrics-pipeline) or
+[full metrics](#full-metrics-pipeline) pipelines to collect monitoring statistics.
+-->
+在 Kubernetes 中，应用程序监控不依赖单个监控解决方案。
+在新集群上，你可以使用[资源度量](#resource-metrics-pipeline)或
+[完整度量](#full-metrics-pipeline)管道来收集监视统计信息。
+
+<!--
+## Resource metrics pipeline
+
+The resource metrics pipeline provides a limited set of metrics related to
+cluster components such as the
+[Horizontal Pod Autoscaler](/docs/tasks/run-application/horizontal-pod-autoscale)
+controller, as well as the `kubectl top` utility.
+These  metrics are collected by the lightweight, short-term, in-memory 
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server) and
+ are exposed via the `metrics.k8s.io` API. 
+-->
+## 资源度量管道  {#resource-metrics-pipeline}
+
+资源指标管道提供了一组与集群组件，例如
+[Horizontal Pod Autoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/)
+控制器以及 `kubectl top` 实用程序相关的有限度量。
+这些指标是由轻量级的、短期、内存存储的
+[metrics-server](https://github.com/kubernetes-sigs/metrics-server) 收集的，
+通过 `metrics.k8s.io` 公开。
+
+<!--
+metrics-server discovers all nodes on the cluster and 
+queries each node's 
+[kubelet](/docs/reference/command-line-tools-reference/kubelet/) for CPU and 
+memory usage. The kubelet acts as a bridge between the Kubernetes master and 
+the nodes, managing the pods and containers running on a machine. The kubelet 
+translates each pod into its constituent containers and fetches individual 
+container usage statistics from the container runtime through the container 
+runtime interface. The kubelet fetches this information from the integrated 
+cAdvisor for the legacy Docker integration.  It then exposes the aggregated pod 
+resource usage statistics through the metrics-server Resource Metrics API.
+This API is served at `/metrics/resource/v1beta1` on the kubelet's authenticated and 
+read-only ports. 
+-->
+度量服务器发现集群中的所有节点，并且查询每个节点的
+[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
+以获取 CPU 和内存使用情况。
+Kubelet 充当 Kubernetes 主节点与节点之间的桥梁，管理机器上运行的 Pod 和容器。
+kubelet 将每个 Pod 转换为其组成的容器，并在容器运行时通过容器运行时接口
+获取各个容器使用情况统计信息。
+kubelet 从集成的 cAdvisor 获取此信息，以进行旧式 Docker 集成。
+然后，它通过 metrics-server Resource Metrics API 公开聚合的 pod 资源使用情况统计信息。
+该 API 在 kubelet 的经过身份验证和只读的端口上的 `/metrics/resource/v1beta1` 中提供。
+
+<!--
+## Full metrics pipeline
+
+A full metrics pipeline gives you access to richer metrics. Kubernetes can
+respond to these metrics by  automatically scaling or adapting the cluster
+based on its current state, using mechanisms such as the Horizontal Pod
+Autoscaler. The monitoring pipeline fetches metrics from the kubelet and
+then exposes them to Kubernetes via an adapter by implementing either the
+`custom.metrics.k8s.io` or `external.metrics.k8s.io` API. 
+-->
+## 完整度量管道  {#full-metrics-pipeline}
+
+一个完整度量管道可以让你访问更丰富的度量。
+Kubernetes 还可以根据集群的当前状态，使用 Pod 水平自动扩缩器等机制，
+通过自动调用扩展或调整集群来响应这些度量。
+监控管道从 kubelet 获取度量值，然后通过适配器将它们公开给 Kubernetes，
+方法是实现 `custom.metrics.k8s.io` 或 `external.metrics.k8s.io` API。
+
+<!--
+[Prometheus](https://prometheus.io), a CNCF project, can natively monitor Kubernetes, nodes, and Prometheus itself.
+Full metrics pipeline projects that are not part of the CNCF are outside the scope of Kubernetes documentation.  
+-->
+[Prometheus](https://prometheus.io) 是一个 CNCF 项目，可以原生监控 Kubernetes、
+节点和 Prometheus 本身。
+完整度量管道项目不属于 CNCF 的一部分，不在 Kubernetes 文档的范围之内。
+
@@ -1384,8 +1384,8 @@ procedure.
 <!--
 *Option 1:* Use the Storage Version Migrator

-1. Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
-2. Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
+1.  Run the [storage Version migrator](https://github.com/kubernetes-sigs/kube-storage-version-migrator)
+2.  Remove the old version from the CustomResourceDefinition `status.storedVersions` field.
 -->

 *选项 1：* 使用存储版本迁移程序（Storage Version Migrator）
@@ -1409,13 +1409,29 @@ The following is an example procedure to upgrade from `v1beta1` to `v1`.
 2.  Write an upgrade procedure to list all existing objects and write them with
    the same content. This forces the backend to write objects in the current
    storage version, which is `v1`.
-3.  Update the CustomResourceDefinition `Status` by removing `v1beta1` from
-    `storedVersions` field.
+3.  Remove `v1beta1` from the CustomResourceDefinition `status.storedVersions` field.
 -->
 1.  在 CustomResourceDefinition 文件中将 `v1` 设置为存储版本，并使用 kubectl 应用它。
    `storedVersions`现在是`v1beta1, v1`。
 2.  编写升级过程以列出所有现有对象并使用相同内容将其写回存储。
    这会强制后端使用当前存储版本（即 `v1`）写入对象。
-3.  通过从 `storedVersions` 字段中删除 `v1beta1` 来更新 CustomResourceDefinition
-    的`Status`。 
+3.  从 CustomResourceDefinition  的 `status.storedVersions` 字段中删除 `v1beta1`。

+<!--
+The `kubectl` tool currently cannot be used to edit or patch the `status` subresource on a CRD: see the [Kubectl Subresource Support KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource) for more details.
+
+The easier way to patch the status subresource from the CLI is directly interacting with the API server using the `curl` tool, in this example:
+-->
+{{< note >}}
+`kubectl` 工具目前不能用于编辑或修补 CRD 上的 `status` 子资源：请参阅
+[kubectl Subresource Support KEP](https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2590-kubectl-subresource)
+了解更多细节。
+
+从 CLI 给 `status` 子资源打补丁的更简单的方法是使用 `curl` 工具直接与 API 服务器交互，示例:
+```bash
+kubectl proxy &
+curl --header "Content-Type: application/json-patch+json" \
+  --request PATCH http://localhost:8001/apis/apiextensions.k8s.io/v1/customresourcedefinitions/<your CRD name here>/status \
+  --data '[{"op": "replace", "path": "/status/storedVersions", "value":["v1"]}]'
+```
+{{< /note >}}
@@ -148,12 +148,12 @@ The common use for HorizontalPodAutoscaler is to configure it to fetch metrics f
 (`metrics.k8s.io`, `custom.metrics.k8s.io`, or `external.metrics.k8s.io`).  The `metrics.k8s.io` API is
 usually provided by an add-on named Metrics Server, which needs to be launched separately.
 For more information about resource metrics, see
-[Metrics Server](/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server).
+[Metrics Server](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server).
 -->
 HorizontalPodAutoscaler 的常见用途是将其配置为从{{< glossary_tooltip text="聚合 API" term_id="aggregation-layer" >}}
 （`metrics.k8s.io`、`custom.metrics.k8s.io` 或 `external.metrics.k8s.io`）获取指标。
 `metrics.k8s.io` API 通常由名为 Metrics Server 的插件提供，需要单独启动。有关资源指标的更多信息，
-请参阅 [Metrics Server](/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline/#metrics-server)。
+请参阅 [Metrics Server](/zh/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/#metrics-server)。

 <!--
 [Support for metrics APIs](#support-for-metrics-apis) explains the stability guarantees and support status for these
@@ -29,49 +29,78 @@ Kubernetes 提供 `certificates.k8s.io` API，可让你配置由你控制的证
 {{< note >}}
 <!--
 Certificates created using the `certificates.k8s.io` API are signed by a
-dedicated CA. It is possible to configure your cluster to use the cluster root
+[dedicated CA](#a-note-to-cluster-administrators). It is possible to configure your cluster to use the cluster root
 CA for this purpose, but you should never rely on this. Do not assume that
 these certificates will validate against the cluster root CA.
 -->
-使用 `certificates.k8s.io` API 创建的证书由指定 CA 颁发。将集群配置为使用集群根目录
-CA 可以达到这个目的，但是你永远不要依赖这一假定。不要以为
-这些证书将针对群根目录 CA 进行验证。
+使用 `certificates.k8s.io` API 创建的证书由指定 [CA](#a-note-to-cluster-administrators) 颁发。
+将集群配置为使用集群根目录 CA 可以达到这个目的，但是你永远不要依赖这一假定。
+不要以为这些证书将针对群根目录 CA 进行验证。
 {{< /note >}}

 ## {{% heading "prerequisites" %}}

-{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+{{< include "task-tutorial-prereqs.md" >}}
+
+<!-- 
+You need the `cfssl` tool. You can download `cfssl` from
+[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases).
+
+Some steps in this page use the `jq` tool. If you don't have `jq`, you can
+install it via your operating system's software sources, or fetch it from
+[https://stedolan.github.io/jq/](https://stedolan.github.io/jq/).
+-->
+你需要 `cfssl` 工具。
+你可以从 [https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases)
+下载 `cfssl`。
+
+本文中某些步骤使用 `jq` 工具。如果你没有 `jq`，你可以通过操作系统的软件源安装，
+或者从 [https://stedolan.github.io/jq/](https://stedolan.github.io/jq/) 获取。

 <!-- steps -->

 <!--
-## Trusting TLS in a Cluster
+## Trusting TLS in a cluster

-Trusting the custom CA from an application running as a pod usually requires
+Trusting the [custom CA](#a-note-to-cluster-administrators) from an application running as a pod usually requires
 some extra application configuration. You will need to add the CA certificate
 bundle to the list of CA certificates that the TLS client or server trusts. For
 example, you would do this with a golang TLS config by parsing the certificate
 chain and adding the parsed certificates to the `RootCAs` field in the
-[`tls.Config`](https://godoc.org/crypto/tls#Config) struct.
-
-You can distribute the CA certificate as a
-[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your
-pods have access to use.
+[`tls.Config`](https://pkg.go.dev/crypto/tls#Config) struct.
 -->
 ## 集群中的 TLS 信任

-信任 Pod 中运行的应用程序所提供的 CA 通常需要一些额外的应用程序配置。
+信任 Pod 中运行的应用程序所提供的[自定义 CA](#a-note-to-cluster-administrators) 通常需要一些额外的应用程序配置。
 你需要将 CA 证书包添加到 TLS 客户端或服务器信任的 CA 证书列表中。
 例如，你可以使用 Golang TLS 配置通过解析证书链并将解析的证书添加到
-[`tls.Config`](https://godoc.org/crypto/tls#Config) 结构中的 `RootCAs`
+[`tls.Config`](https://pkg.go.dev/crypto/tls#Config) 结构中的 `RootCAs`
 字段中。

-你可以用你的应用能够访问到的
-[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap)
-的形式来发布 CA 证书。
+{{< note >}}
+<!-- 
+Even though the custom CA certificate may be included in the filesystem (in the
+ConfigMap `kube-root-ca.crt`),
+you should not use that certificate authority for any purpose other than to verify internal
+Kubernetes endpoints. An example of an internal Kubernetes endpoint is the
+Service named `kubernetes` in the default namespace.
+
+If you want to use a custom certificate authority for your workloads, you should generate
+that CA separately, and distribute its CA certificate using a 
+[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your pods 
+have access to read.
+-->
+即使自定义 CA 证书可能包含在文件系统中（在 ConfigMap `kube-root-ca.crt` 中），
+除了验证内部 Kubernetes 端点之外，你不应将该证书颁发机构用于任何目的。
+内部 Kubernetes 端点的一个示例是默认命名空间中名为 `kubernetes` 的服务。
+
+如果你想为你的工作负载使用自定义证书颁发机构，你应该单独生成该 CA，
+并使用你的 Pod 有读权限的 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap)
+分发该 CA 证书。
+{{< /note >}}

 <!--
-## Requesting a Certificate
+## Requesting a certificate

 The following section demonstrates how to create a TLS certificate for a
 Kubernetes service accessed through DNS.
@@ -90,17 +119,7 @@ This tutorial uses CFSSL: Cloudflare's PKI and TLS toolkit [click here](https://
 {{< /note >}}

 <!--
-## Download and install CFSSL
-
-The cfssl tools used in this example can be downloaded at
-[https://github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases).
-->
-## 下载并安装 CFSSL
-
-本例中使用的 cfssl 工具可以在 [github.com/cloudflare/cfssl/releases](https://github.com/cloudflare/cfssl/releases) 下载。
-
-<!--
-## Create a Certificate Signing Request
+## Create a certificate signing request

 Generate a private key and certificate signing request (or CSR) by running
 the following command:
@@ -118,16 +137,11 @@ cat <<EOF | cfssl genkey - | cfssljson -bare server
    "192.0.2.24",
    "10.0.34.2"
  ],
-  "CN": "system:node:my-pod.my-namespace.pod.cluster.local",
+  "CN": "my-pod.my-namespace.pod.cluster.local",
  "key": {
    "algo": "ecdsa",
    "size": 256
-  },
-  "names": [
-    {
-      "O": "system:nodes"
-    }
-  ]
+  }
 }
 EOF
 ```
@@ -136,37 +150,37 @@ EOF
 Where `192.0.2.24` is the service's cluster IP,
 `my-svc.my-namespace.svc.cluster.local` is the service's DNS name,
 `10.0.34.2` is the pod's IP and `my-pod.my-namespace.pod.cluster.local`
-is the pod's DNS name. You should see the following output:
+is the pod's DNS name. You should see the output similar to:
 -->
 其中 `192.0.2.24` 是服务的集群 IP，`my-svc.my-namespace.svc.cluster.local`
 是服务的 DNS 名称，`10.0.34.2` 是 Pod 的 IP，而
 `my-pod.my-namespace.pod.cluster.local` 是 Pod 的 DNS 名称。
-你能看到以下的输出：
+你能看到的输出类似于：

 ```
-2017/03/21 06:48:17 [INFO] generate received request
-2017/03/21 06:48:17 [INFO] received CSR
-2017/03/21 06:48:17 [INFO] generating key: ecdsa-256
-2017/03/21 06:48:17 [INFO] encoded CSR
+2022/02/01 11:45:32 [INFO] generate received request
+2022/02/01 11:45:32 [INFO] received CSR
+2022/02/01 11:45:32 [INFO] generating key: ecdsa-256
+2022/02/01 11:45:32 [INFO] encoded CSR
 ```

 <!--
 This command generates two files; it generates `server.csr` containing the PEM
-encoded [pkcs#10](https://tools.ietf.org/html/rfc2986) certification request,
+encoded [PKCS#10](https://tools.ietf.org/html/rfc2986) certification request,
 and `server-key.pem` containing the PEM encoded key to the certificate that
 is still to be created.
 -->
 此命令生成两个文件；它生成包含 PEM 编码
-[pkcs#10](https://tools.ietf.org/html/rfc2986) 证书请求的 `server.csr`，
+[PKCS#10](https://tools.ietf.org/html/rfc2986) 证书请求的 `server.csr`，
 以及 PEM 编码密钥的 `server-key.pem`，用于待生成的证书。

 <!--
-## Create a Certificate Signing Request object to send to the Kubernetes API
+## Create a CertificateSigningRequest object to send to the Kubernetes API

 Generate a CSR yaml blob and send it to the apiserver by running the following
 command:
 -->
-## 创建证书签名请求对象发送到 Kubernetes API
+## 创建证书签名请求（CSR）对象发送到 Kubernetes API

 使用以下命令创建 CSR YAML 文件，并发送到 API 服务器：

@@ -178,7 +192,7 @@ metadata:
  name: my-svc.my-namespace
 spec:
  request: $(cat server.csr | base64 | tr -d '\n')
-  signerName: kubernetes.io/kubelet-serving
+  signerName: example.com/serving
  usages:
  - digital signature
  - key encipherment
@@ -188,9 +202,9 @@ EOF

 <!--
 Notice that the `server.csr` file created in step 1 is base64 encoded
-and stashed in the `.spec.request` field. We are also requesting a
+and stashed in the `.spec.request` field. You are also requesting a
 certificate with the "digital signature", "key encipherment", and "server
-auth" key usages, signed by the `kubernetes.io/kubelet-serving` signer.
+auth" key usages, signed by an example `example.com/serving` signer.
 A specific `signerName` must be requested.
 View documentation for [supported signer names](/docs/reference/access-authn-authz/certificate-signing-requests/#signers)
 for more information.
@@ -199,9 +213,9 @@ The CSR should now be visible from the API in a Pending state. You can see
 it by running:
 -->
 请注意，在步骤 1 中创建的 `server.csr` 文件是 base64 编码并存储在
-`.spec.request` 字段中的。我们还要求提供 “digital signature（数字签名）”，
+`.spec.request` 字段中的。你还要求提供 “digital signature（数字签名）”，
 “密钥加密（key encipherment）” 和 “服务器身份验证（server auth）” 密钥用途，
-由 `kubernetes.io/kubelet-serving` 签名程序签名的证书。
+由 `example.com/serving` 示例签名程序签名的证书。
 你也可以要求使用特定的 `signerName`。更多信息可参阅
 [支持的签署者名称](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signers)。

@@ -215,28 +229,30 @@ kubectl describe csr my-svc.my-namespace
 Name:                   my-svc.my-namespace
 Labels:                 <none>
 Annotations:            <none>
-CreationTimestamp:      Tue, 21 Mar 2017 07:03:51 -0700
+CreationTimestamp:      Tue, 01 Feb 2022 11:49:15 -0500
 Requesting User:        yourname@example.com
+Signer:                 example.com/serving
 Status:                 Pending
 Subject:
-        Common Name:    my-svc.my-namespace.svc.cluster.local
+        Common Name:    my-pod.my-namespace.pod.cluster.local
        Serial Number:
 Subject Alternative Names:
-        DNS Names:      my-svc.my-namespace.svc.cluster.local
+        DNS Names:      my-pod.my-namespace.pod.cluster.local
+                        my-svc.my-namespace.svc.cluster.local
        IP Addresses:   192.0.2.24
                        10.0.34.2
 Events: <none>
 ```

 <!--
-## Get the Certificate Signing Request Approved
+## Get the CertificateSigningRequest approved {#get-the-certificate-signing-request-approved}

 Approving the [certificate signing request](/docs/reference/access-authn-authz/certificate-signing-requests/)
 is either done by an automated approval process or on a one off basis by a cluster
 administrator. If you're authorized to approve a certificate request, you can do that
 manually using `kubectl`; for example:
 -->
-## 批准证书签名请求
+## 批准证书签名请求（CSR）  {#get-the-certificate-signing-request-approved}

 [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)
 的批准或者是通过自动批准过程完成的，或由集群管理员一次性完成。
@@ -250,29 +266,167 @@ kubectl certificate approve my-svc.my-namespace
 certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
 ```

-<!--
-## Download the Certificate and Use It
-
-Once the CSR is signed and approved you should see the following:
-->
-## 下载证书并使用它
-
-CSR 被签署并获得批准后，你应该看到以下内容：
+<!-- You should now see the following: -->
+你现在应该能看到如下输出：

 ```shell
 kubectl get csr
 ```

 ```none
-NAME                  AGE       REQUESTOR               CONDITION
-my-svc.my-namespace   10m       yourname@example.com    Approved,Issued
+NAME                  AGE   SIGNERNAME            REQUESTOR              REQUESTEDDURATION   CONDITION
+my-svc.my-namespace   10m   example.com/serving   yourname@example.com   <none>              Approved
+```
+
+<!-- 
+This means the certificate request has been approved and is waiting for the
+requested signer to sign it.
+-->
+这意味着证书请求已被批准，并正在等待请求的签名者对其签名。
+
+<!--  
+## Sign the CertificateSigningRequest {#sign-the-certificate-signing-request}
+
+Next, you'll play the part of a certificate signer, issue the certificate, and upload it to the API.
+
+A signer would typically watch the CertificateSigningRequest API for objects with its `signerName`,
+check that they have been approved, sign certificates for those requests,
+and update the API object status with the issued certificate.
+-->
+## 签名证书签名请求（CSR） {#sign-the-certificate-signing-request}
+
+接下来，你将扮演证书签署者的角色，颁发证书并将其上传到 API 服务器。
+
+签名者通常会使用其 `signerName` 查看对象的 CertificateSigningRequest API，
+检查它们是否已被批准，为这些请求签署证书，并使用已颁发的证书更新 API 对象状态。
+
+<!-- 
+### Create a Certificate Authority
+
+You need an authority to provide the digital signature on the new certificate.
+
+First, create a signing certificate by running the following:
+-->
+### 创建证书颁发机构
+
+你需要授权在新证书上提供数字签名。
+
+首先，通过运行以下命令创建签名证书：
+
+```shell
+cat <<EOF | cfssl gencert -initca - | cfssljson -bare ca
+{
+  "CN": "My Example Signer",
+  "key": {
+    "algo": "rsa",
+    "size": 2048
+  }
+}
+EOF
+```
+
+<!-- You should see output similar to: -->
+你应该看到类似于以下的输出：
+
+```none
+2022/02/01 11:50:39 [INFO] generating a new CA key and certificate from CSR
+2022/02/01 11:50:39 [INFO] generate received request
+2022/02/01 11:50:39 [INFO] received CSR
+2022/02/01 11:50:39 [INFO] generating key: rsa-2048
+2022/02/01 11:50:39 [INFO] encoded CSR
+2022/02/01 11:50:39 [INFO] signed certificate with serial number 263983151013686720899716354349605500797834580472
+```
+
+<!-- 
+This produces a certificate authority key file (`ca-key.pem`) and certificate (`ca.pem`). 
+-->
+这会产生一个证书颁发机构密钥文件（`ca-key.pem`）和证书（`ca.pem`）。
+
+
+<!-- ### Issue a certificate -->
+### 颁发证书
+
+{{< codenew file="tls/server-signing-config.json" >}}
+
+<!-- 
+Use a `server-signing-config.json` signing configuration and the certificate authority key file 
+and certificate to sign the certificate request:
+-->
+使用 `server-signing-config.json` 签名配置、证书颁发机构密钥文件和证书来签署证书请求：
+
+```shell
+kubectl get csr my-svc.my-namespace -o jsonpath='{.spec.request}' | \
+  base64 --decode | \
+  cfssl sign -ca ca.pem -ca-key ca-key.pem -config server-signing-config.json - | \
+  cfssljson -bare ca-signed-server
+```
+
+<!-- You should see output similar to: -->
+你应该看到类似于以下的输出：
+
+```
+2022/02/01 11:52:26 [INFO] signed certificate with serial number 576048928624926584381415936700914530534472870337
+```
+
+<!-- This produces a signed serving certificate file, `ca-signed-server.pem`. -->
+这会生成一个签名的服务证书文件，`ca-signed-server.pem`。
+
+<!-- 
+### Upload the signed certificate
+
+Finally, populate the signed certificate in the API object's status:
+-->
+
+### 上传签名证书
+
+最后，在 API 对象的状态中填充签名证书：
+
+```shell
+kubectl get csr my-svc.my-namespace -o json | \
+  jq '.status.certificate = "'$(base64 ca-signed-server.pem | tr -d '\n')'"' | \
+  kubectl replace --raw /apis/certificates.k8s.io/v1/certificatesigningrequests/my-svc.my-namespace/status -f -
+```
+
+{{< note >}}
+<!-- 
+This uses the command line tool [`jq`](https://stedolan.github.io/jq/) to populate the base64-encoded
+content in the `.status.certificate` field.
+If you do not have `jq`, you can also save the JSON output to a file, populate this field manually, and
+upload the resulting file.
+-->
+这使用命令行工具 [`jq`](https://stedolan.github.io/jq/)
+在 `.status.certificate` 字段中填充 base64 编码的内容。
+如果你没有 `jq` 工具，你还可以将 JSON 输出保存到文件中，手动填充此字段，然后上传结果文件。
+{{< /note >}}
+
+<!-- 
+Once the CSR is approved and the signed certificate is uploaded, run:
+-->
+批准 CSR 并上传签名证书后，运行：
+
+```shell
+kubectl get csr
+```
+
+<!-- The output is similar to: -->
+输入类似于：
+
+```none
+NAME                  AGE   SIGNERNAME            REQUESTOR              REQUESTEDDURATION   CONDITION
+my-svc.my-namespace   20m   example.com/serving   yourname@example.com   <none>              Approved,Issued
 ```

 <!--
-You can download the issued certificate and save it to a `server.crt` file
-by running the following:
+## Download the certificate and use it
+
+Now, as the requesting user, you can download the issued certificate
+and save it to a `server.crt` file by running the following:
 -->
-你可以通过运行以下命令下载颁发的证书并将其保存到 `server.crt` 文件中：
+## 下载证书并使用它
+
+现在，作为请求用户，你可以通过运行以下命令下载颁发的证书并将其保存到 `server.crt` 文件中：
+
+CSR 被签署并获得批准后，你应该看到以下内容：

 ```shell
 kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
@@ -280,31 +434,74 @@ kubectl get csr my-svc.my-namespace -o jsonpath='{.status.certificate}' \
 ```

 <!--
-Now you can use `server.crt` and `server-key.pem` as the keypair to start
-your HTTPS server.
+Now you can populate `server.crt` and `server-key.pem` in a
+{{< glossary_tooltip text="Secret" term_id="secret" >}}
+that you could later mount into a Pod (for example, to use with a webserver
+that serves HTTPS). 
 -->
-现在你可以将 `server.crt` 和 `server-key.pem` 作为键值对来启动 HTTPS 服务器。
+现在你可以将 `server.crt` 和 `server-key.pem` 填充到
+{{<glossary_tooltip text="Secret" term_id="secret" >}} 中，
+稍后你可以将其挂载到 Pod 中（例如，用于提供 HTTPS 的网络服务器）。
+
+```shell
+kubectl create secret tls server --cert server.crt --key server-key.pem
+```
+
+```none
+secret/server created
+```
+
+<!-- 
+Finally, you can populate `ca.pem` into a {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}
+and use it as the trust root to verify the serving certificate:
+-->
+最后，你可以将 `ca.pem` 填充到
+{{<glossary_tooltip text="ConfigMap" term_id="configmap" >}}
+并将其用作信任根来验证服务证书：
+
+```shell
+kubectl create configmap example-serving-ca --from-file ca.crt=ca.pem
+```
+
+```none
+configmap/example-serving-ca created
+```

 <!--
-## Approving Certificate Signing Requests
+## Approving CertificateSigningRequests {#approving-certificate-signing-requests}

 A Kubernetes administrator (with appropriate permissions) can manually approve
-(or deny) Certificate Signing Requests by using the `kubectl certificate
+(or deny) CertificateSigningRequests by using the `kubectl certificate
 approve` and `kubectl certificate deny` commands. However if you intend
 to make heavy usage of this API, you might consider writing an automated
 certificates controller.
 -->
-## 批准证书签名请求
+## 批准证书签名请求（CSR）  {#approving-certificate-signing-requests}

 Kubernetes 管理员（具有适当权限）可以使用 `kubectl certificate approve` 和
-`kubectl certificate deny` 命令手动批准（或拒绝）证书签名请求。
+`kubectl certificate deny` 命令手动批准（或拒绝）证书签名请求（CSR）。
 但是，如果你打算大量使用此 API，则可以考虑编写自动化的证书控制器。

+{{< caution >}}
+<!-- 
+The ability to approve CSRs decides who trusts whom within your environment. The
+ability to approve CSRs should not be granted broadly or lightly.
+
+You should make sure that you confidently understand both the verification requirements
+that fall on the approver **and** the repercussions of issuing a specific certificate
+before you grant the `approve` permission.
+-->
+批准证书 CSR 的能力决定了在你的环境中谁信任谁。
+不应广泛或轻率地授予批准 CSR 的能力。
+
+在授予 `approve` 权限之前，你应该确保自己充分了解批准人的验证要求**和**颁发特定证书的后果。
+{{< /caution >}}
+
 <!--
-Whether a machine or a human using kubectl as above, the role of the approver is
+Whether a machine or a human using kubectl as above, the role of the _approver_ is
 to verify that the CSR satisfies two requirements:
 -->
-无论上述机器或人使用 kubectl，批准者的作用是验证 CSR 满足如下两个要求：
+无论上述机器或人使用 kubectl，“批准者”的作用是验证 CSR 满足如下两个要求：

 <!--
 1. The subject of the CSR controls the private key used to sign the CSR. This
@@ -325,28 +522,20 @@ to verify that the CSR satisfies two requirements:
 <!--
 If and only if these two requirements are met, the approver should approve
 the CSR and otherwise should deny the CSR.
+
+For more information on certificate approval and access control, read
+the [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/)
+reference page.
 -->
 当且仅当满足这两个要求时，审批者应该批准 CSR，否则拒绝 CSR。

-<!--
-## A Word of Warning on the Approval Permission
-
-The ability to approve CSRs decides who trusts who within the cluster. This
-includes who the Kubernetes API trusts. The ability to approve CSRs should
-not be granted broadly or lightly. The requirements of the challenge
-noted in the previous section and the repercussions of issuing a specific
-certificate should be fully understood before granting this permission.
-->
-## 关于批准权限的警告
-
-批准 CSR 的能力决定了群集中的信任关系。这也包括 Kubernetes API 所信任的人。
-批准 CSR 的能力不能过于广泛和轻率。
-在给予本许可之前，应充分了解上一节中提到的挑战和发布特定证书的后果。
+有关证书批准和访问控制的更多信息，
+请阅读[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)参考页。

 <!--
-## A Note to Cluster Administrators
+## Configuring your cluster to provide signing

-This tutorial assumes that a signer is setup to serve the certificates API. The
+This page assumes that a signer is setup to serve the certificates API. The
 Kubernetes controller manager provides a default implementation of a signer. To
 enable it, pass the `--cluster-signing-cert-file` and
 `--cluster-signing-key-file` parameters to the controller manager with paths to
@@ -354,8 +543,7 @@ your Certificate Authority's keypair.
 -->
 ## 给集群管理员的一个建议

-本教程假设已经为 certificates API 配置了签名者。Kubernetes 控制器管理器
-提供了一个签名者的默认实现。要启用它，请为控制器管理器设置
+本页面假设已经为 certificates API 配置了签名者。
+Kubernetes 控制器管理器提供了一个签名者的默认实现。要启用它，请为控制器管理器设置
 `--cluster-signing-cert-file` 和 `--cluster-signing-key-file` 参数，
 使之取值为你的证书机构的密钥对的路径。
-
@@ -156,7 +156,7 @@ Markdown 在如何处理列表方面没有严格的规则。在我们从 Jekyll
  consecutive lists. **The HTML comment needs to be at the left margin.**
 - Bullet lists can have paragraphs or block elements within them.

-      Indent the content to be one tab stop beyond the text of the bullet
+      Indent the content to be the same as the first line of the bullet
      point. **This paragraph and the code block line up with the second `l` in
      `Bullet` above.**

@@ -669,12 +669,12 @@ HTML。
 ## Visualizations with Mermaid

 You can use [Mermaid JS](https://mermaidjs.github.io) visualizations.
-The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html)
+The Mermaid JS version is specified in [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/main/layouts/partials/head.html)
 -->
 ## 使用 Mermaid 来可视化

 你可以使用 [Mermaid JS](https://mermaidjs.github.io) 来进行可视化展示。
-Mermaid JS 版本在 [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/master/layouts/partials/head.html)
+Mermaid JS 版本在 [/layouts/partials/head.html](https://github.com/kubernetes/website/blob/main/layouts/partials/head.html)
 中设置。

 <!--
@@ -156,11 +156,11 @@ cassandra   ClusterIP   None         <none>        9042/TCP   45s

 <!--
 If you don't see a Service named `cassandra`, that means creation failed. Read
-[Debug Services](/docs/tasks/debug-application-cluster/debug-service/)
+[Debug Services](/docs/tasks/debug/debug-application/debug-service/)
 for help troubleshooting common issues.
 -->
 如果没有看到名为 `cassandra` 的服务，则表示创建失败。
-请阅读[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)，以解决常见问题。
+请阅读[调试服务](/zh/docs/tasks/debug/debug-application/debug-service/)，以解决常见问题。

 <!--
 ## Using a StatefulSet to create a Cassandra ring
@@ -466,15 +466,15 @@ Do not leave your WordPress installation on this page. If another user finds it,


 <!--
-* Learn more about [Introspection and Debugging](/docs/tasks/debug-application-cluster/debug-application-introspection/)
+* Learn more about [Introspection and Debugging](/docs/tasks/debug/debug-application)
 * Learn more about [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 * Learn more about [Port Forwarding](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
-* Learn how to [Get a Shell to a Container](/docs/tasks/debug-application-cluster/get-shell-running-container/)
+* Learn how to [Get a Shell to a Container](/docs/tasks/debug/debug-application/get-shell-running-container/)
 -->

-* 了解更多关于 [Introspection and Debugging](/zh/docs/tasks/debug-application-cluster/debug-application-introspection/)
+* 了解更多关于 [Introspection and Debugging](/zh/docs/tasks/debug/debug-application)
 * 了解更多关于 [Jobs](/zh/docs/concepts/workloads/controllers/jobs-run-to-completion/)
 * 了解更多关于 [Port Forwarding](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)
-* 了解如何 [Get a Shell to a Container](/zh/docs/tasks/debug-application-cluster/get-shell-running-container/)
+* 了解如何 [Get a Shell to a Container](/zh/docs/tasks/debug/debug-application/get-shell-running-container/)


@@ -1,33 +1,87 @@
+kind: ServiceAccount
+apiVersion: v1
+metadata:
+  name: kube-dns-autoscaler
+  namespace: kube-system
+---
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: system:kube-dns-autoscaler
+rules:
+  - apiGroups: [""]
+    resources: ["nodes"]
+    verbs: ["list", "watch"]
+  - apiGroups: [""]
+    resources: ["replicationcontrollers/scale"]
+    verbs: ["get", "update"]
+  - apiGroups: ["apps"]
+    resources: ["deployments/scale", "replicasets/scale"]
+    verbs: ["get", "update"]
+# 待以下 issue 修复后，请删除 Configmaps
+# kubernetes-incubator/cluster-proportional-autoscaler#16
+  - apiGroups: [""]
+    resources: ["configmaps"]
+    verbs: ["get", "create"]
+---
+kind: ClusterRoleBinding
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: system:kube-dns-autoscaler
+subjects:
+  - kind: ServiceAccount
+    name: kube-dns-autoscaler
+    namespace: kube-system
+roleRef:
+  kind: ClusterRole
+  name: system:kube-dns-autoscaler
+  apiGroup: rbac.authorization.k8s.io
+
+---
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: dns-autoscaler
+  name: kube-dns-autoscaler
  namespace: kube-system
  labels:
-    k8s-app: dns-autoscaler
+    k8s-app: kube-dns-autoscaler
+    kubernetes.io/cluster-service: "true"
 spec:
  selector:
    matchLabels:
-      k8s-app: dns-autoscaler
+      k8s-app: kube-dns-autoscaler
  template:
    metadata:
      labels:
-        k8s-app: dns-autoscaler
+        k8s-app: kube-dns-autoscaler
    spec:
+      priorityClassName: system-cluster-critical
+      securityContext:
+        seccompProfile:
+          type: RuntimeDefault
+        supplementalGroups: [ 65534 ]
+        fsGroup: 65534
+      nodeSelector:
+        kubernetes.io/os: linux
      containers:
      - name: autoscaler
-        image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.6.0
+        image: k8s.gcr.io/cpa/cluster-proportional-autoscaler:1.8.4
        resources:
-          requests:
-            cpu: 20m
-            memory: 10Mi
+            requests:
+                cpu: "20m"
+                memory: "10Mi"
        command:
-        - /cluster-proportional-autoscaler
-        - --namespace=kube-system
-        - --configmap=dns-autoscaler
-        - --target=<SCALE_TARGET>
-        # When cluster is using large nodes(with more cores), "coresPerReplica" should dominate.
-        # If using small nodes, "nodesPerReplica" should dominate.
-        - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"min":1}}
-        - --logtostderr=true
-        - --v=2
+          - /cluster-proportional-autoscaler
+          - --namespace=kube-system
+          - --configmap=kube-dns-autoscaler
+          # 应该保持目标与 cluster/addons/dns/kube-dns.yaml.base 同步
+          - --target=<SCALE_TARGET>
+          #当集群使用大节点（有更多核）时，“coresPerReplica”应该占主导地位。
+          #如果使用小节点，“nodesPerReplica“ 应该占主导地位。
+          - --default-params={"linear":{"coresPerReplica":256,"nodesPerReplica":16,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}}
+          - --logtostderr=true
+          - --v=2
+      tolerations:
+      - key: "CriticalAddonsOnly"
+        operator: "Exists"
+      serviceAccountName: kube-dns-autoscaler
@@ -0,0 +1,31 @@
+apiVersion: apps/v1
+kind: Deployment
+metadata:
+  name: mongo
+  labels:
+    app.kubernetes.io/name: mongo
+    app.kubernetes.io/component: backend
+spec:
+  selector:
+    matchLabels:
+      app.kubernetes.io/name: mongo
+      app.kubernetes.io/component: backend
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        app.kubernetes.io/name: mongo
+        app.kubernetes.io/component: backend
+    spec:
+      containers:
+      - name: mongo
+        image: mongo:4.2
+        args:
+          - --bind_ip
+          - 0.0.0.0
+        resources:
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        ports:
+        - containerPort: 27017
@@ -0,0 +1,14 @@
+apiVersion: v1
+kind: Service
+metadata:
+  name: mongo
+  labels:
+    app.kubernetes.io/name: mongo
+    app.kubernetes.io/component: backend
+spec:
+  ports:
+  - port: 27017
+    targetPort: 27017
+  selector:
+    app.kubernetes.io/name: mongo
+    app.kubernetes.io/component: backend
@@ -21,17 +21,18 @@ spec:
        - "-c"
        - |
          set -ex
-          # Generate mysql server-id from pod ordinal index.
+          # 基于 Pod 序号生成 MySQL 服务器的 ID。
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          echo [mysqld] > /mnt/conf.d/server-id.cnf
-          # Add an offset to avoid reserved server-id=0 value.
+          # 添加偏移量以避免使用 server-id=0 这一保留值。
          echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
          # Copy appropriate conf.d files from config-map to emptyDir.
+          # 将合适的 conf.d 文件从 config-map 复制到 emptyDir。
          if [[ $ordinal -eq 0 ]]; then
-            cp /mnt/config-map/master.cnf /mnt/conf.d/
+            cp /mnt/config-map/primary.cnf /mnt/conf.d/
          else
-            cp /mnt/config-map/slave.cnf /mnt/conf.d/
+            cp /mnt/config-map/replica.cnf /mnt/conf.d/
          fi
        volumeMounts:
        - name: conf
@@ -45,15 +46,15 @@ spec:
        - "-c"
        - |
          set -ex
-          # Skip the clone if data already exists.
+          # 如果已有数据，则跳过克隆。
          [[ -d /var/lib/mysql/mysql ]] && exit 0
-          # Skip the clone on master (ordinal index 0).
+          # 跳过主实例（序号索引 0）的克隆。
          [[ `hostname` =~ -([0-9]+)$ ]] || exit 1
          ordinal=${BASH_REMATCH[1]}
          [[ $ordinal -eq 0 ]] && exit 0
-          # Clone data from previous peer.
+          # 从原来的对等节点克隆数据。
          ncat --recv-only mysql-$(($ordinal-1)).mysql 3307 | xbstream -x -C /var/lib/mysql
-          # Prepare the backup.
+          # 准备备份。
          xtrabackup --prepare --target-dir=/var/lib/mysql
        volumeMounts:
        - name: data
@@ -88,7 +89,7 @@ spec:
          timeoutSeconds: 5
        readinessProbe:
          exec:
-            # Check we can execute queries over TCP (skip-networking is off).
+            # 检查我们是否可以通过 TCP 执行查询（skip-networking 是关闭的）。
            command: ["mysql", "-h", "127.0.0.1", "-e", "SELECT 1"]
          initialDelaySeconds: 5
          periodSeconds: 2
@@ -105,22 +106,22 @@ spec:
          set -ex
          cd /var/lib/mysql

-          # Determine binlog position of cloned data, if any.
+          # 确定克隆数据的 binlog 位置（如果有的话）。
          if [[ -f xtrabackup_slave_info && "x$(<xtrabackup_slave_info)" != "x" ]]; then
-            # XtraBackup already generated a partial "CHANGE MASTER TO" query
-            # because we're cloning from an existing slave. (Need to remove the tailing semicolon!)
+            # XtraBackup 已经生成了部分的 “CHANGE MASTER TO” 查询
+            # 因为我们从一个现有副本进行克隆。(需要删除末尾的分号!)
            cat xtrabackup_slave_info | sed -E 's/;$//g' > change_master_to.sql.in
-            # Ignore xtrabackup_binlog_info in this case (it's useless).
+            # 在这里要忽略 xtrabackup_binlog_info （它是没用的）。
            rm -f xtrabackup_slave_info xtrabackup_binlog_info
          elif [[ -f xtrabackup_binlog_info ]]; then
-            # We're cloning directly from master. Parse binlog position.
+            # 我们直接从主实例进行克隆。解析 binlog 位置。
            [[ `cat xtrabackup_binlog_info` =~ ^(.*?)[[:space:]]+(.*?)$ ]] || exit 1
            rm -f xtrabackup_binlog_info xtrabackup_slave_info
            echo "CHANGE MASTER TO MASTER_LOG_FILE='${BASH_REMATCH[1]}',\
                  MASTER_LOG_POS=${BASH_REMATCH[2]}" > change_master_to.sql.in
          fi

-          # Check if we need to complete a clone by starting replication.
+          # 检查我们是否需要通过启动复制来完成克隆。
          if [[ -f change_master_to.sql.in ]]; then
            echo "Waiting for mysqld to be ready (accepting connections)"
            until mysql -h 127.0.0.1 -e "SELECT 1"; do sleep 1; done
@@ -133,11 +134,11 @@ spec:
                          MASTER_PASSWORD='', \
                          MASTER_CONNECT_RETRY=10; \
                        START SLAVE;" || exit 1
-            # In case of container restart, attempt this at-most-once.
+            # 如果容器重新启动，最多尝试一次。
            mv change_master_to.sql.in change_master_to.sql.orig
          fi

-          # Start a server to send backups when requested by peers.
+          # 当对等点请求时，启动服务器发送备份。
          exec ncat --listen --keep-open --send-only --max-conns=1 3307 -c \
            "xtrabackup --backup --slave-info --stream=xbstream --host=127.0.0.1 --user=root"
        volumeMounts:
@@ -11,7 +11,7 @@ spec:
    args:
    - /bin/sh
    - -c
-    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
+    - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
@@ -3,6 +3,7 @@ kind: PodSecurityPolicy
 metadata:
  name: restricted
  annotations:
+    # docker/default 标识 seccomp 的配置文件，但它与 Docker 运行时没有特别关联
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
@@ -45,3 +46,4 @@ spec:
      - min: 1
        max: 65535
  readOnlyRootFilesystem: false
+
@@ -0,0 +1,70 @@
+#!/bin/sh
+mkdir -p /tmp/pss
+cat <<EOF > /tmp/pss/cluster-level-pss.yaml
+apiVersion: apiserver.config.k8s.io/v1
+kind: AdmissionConfiguration
+plugins:
+- name: PodSecurity
+  configuration:
+    apiVersion: pod-security.admission.config.k8s.io/v1beta1
+    kind: PodSecurityConfiguration
+    defaults:
+      enforce: "baseline"
+      enforce-version: "latest"
+      audit: "restricted"
+      audit-version: "latest"
+      warn: "restricted"
+      warn-version: "latest"
+    exemptions:
+      usernames: []
+      runtimeClasses: []
+      namespaces: [kube-system]
+EOF
+cat <<EOF > /tmp/pss/cluster-config.yaml
+kind: Cluster
+apiVersion: kind.x-k8s.io/v1alpha4
+nodes:
+- role: control-plane
+  kubeadmConfigPatches:
+  - |
+    kind: ClusterConfiguration
+    apiServer:
+        extraArgs:
+          admission-control-config-file: /etc/config/cluster-level-pss.yaml
+        extraVolumes:
+          - name: accf
+            hostPath: /etc/config
+            mountPath: /etc/config
+            readOnly: false
+            pathType: "DirectoryOrCreate"
+  extraMounts:
+  - hostPath: /tmp/pss
+    containerPath: /etc/config
+    # optional: if set, the mount is read-only.
+    # default false
+    readOnly: false
+    # optional: if set, the mount needs SELinux relabeling.
+    # default false
+    selinuxRelabel: false
+    # optional: set propagation mode (None, HostToContainer or Bidirectional)
+    # see https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation
+    # default None
+    propagation: None
+EOF
+kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml
+kubectl cluster-info --context kind-psa-with-cluster-pss
+# 等待 15 秒（任意）ServiceAccount 准入控制器可用
+sleep 15
+cat <<EOF > /tmp/pss/nginx-pod.yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+    - image: nginx
+      name: nginx
+      ports:
+        - containerPort: 80
+EOF
+kubectl apply -f /tmp/pss/nginx-pod.yaml
@@ -0,0 +1,28 @@
+#!/bin/sh
+# 直到 v1.23 发布，kind 节点镜像需要从 k/k master 分支构建
+# 参考：https://kind.sigs.k8s.io/docs/user/quick-start/#building-images
+kind create cluster --name psa-ns-level --image kindest/node:v1.23.0
+kubectl cluster-info --context kind-psa-ns-level
+# 等待 15 秒（任意）ServiceAccount 准入控制器可用
+sleep 15
+kubectl create ns example
+kubectl label --overwrite ns example \
+  pod-security.kubernetes.io/enforce=baseline \
+  pod-security.kubernetes.io/enforce-version=latest \
+  pod-security.kubernetes.io/warn=restricted \
+  pod-security.kubernetes.io/warn-version=latest \
+  pod-security.kubernetes.io/audit=restricted \
+  pod-security.kubernetes.io/audit-version=latest
+cat <<EOF > /tmp/pss/nginx-pod.yaml
+apiVersion: v1
+kind: Pod
+metadata:
+  name: nginx
+spec:
+  containers:
+    - image: nginx
+      name: nginx
+      ports:
+        - containerPort: 80
+EOF
+kubectl apply -n example -f /tmp/pss/nginx-pod.yaml
@@ -0,0 +1,15 @@
+{
+    "signing": {
+        "default": {
+            "usages": [
+                "digital signature",
+                "key encipherment",
+                "server auth"
+            ],
+            "expiry": "876000h",
+            "ca_constraint": {
+                "is_ca": false
+            }
+        }
+    }
+}
				`@@ -0,0 +1 @@`
				<svg id="Layer_1" data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 215 127"><defs><style>.cls-1{fill:transparent;}.cls-2{fill:#040606;}</style></defs><title>kubernetes.io-54664</title><rect class="cls-1" x="-4.55738" y="-4.48481" width="223.25536" height="134.51136"/><path class="cls-2" d="M169.05853,71.307c.23549,6.07483,5.42615,10.38072,14.09569,10.38072,7.0783,0,12.91766-3.06693,12.91766-9.85009,0-4.71846-2.65436-7.49024-8.78885-8.66954l-4.77685-.94382c-3.06756-.59028-5.19066-1.17992-5.19066-3.0079,0-2.00568,2.06471-2.89047,4.65943-2.89047,3.77525,0,5.3081,1.887,5.42678,4.1288H194.951c-.41258-5.89838-5.1304-9.8501-12.73994-9.8501-7.845,0-12.50382,4.30588-12.50382,9.90912,0,6.84157,5.54483,7.96247,10.3217,8.84662l3.95171.70834c2.83082.53062,4.06977,1.35638,4.06977,3.0079,0,1.47444-1.41541,2.94887-4.77748,2.94887-4.89553,0-6.488-2.53631-6.54705-4.71845Zm-27.4259-5.13164a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58415,8.58415,0,0,1,8.61115,8.557q.00009.02706,0,.0541a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M158.79589,81.098h7.49149V50.95811h-7.49149v2.41825a15.58033,15.58033,0,1,0-9.01133,28.37034q.05285.00018.10567,0a15.47693,15.47693,0,0,0,8.90566-2.77179ZM106.59844,66.17532a8.58413,8.58413,0,0,1,8.557-8.61113q.02706-.00009.05409,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58413,8.58413,0,0,1-8.55641,8.61177q-.02738.00009-.05473,0a8.58413,8.58413,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473m17.16387-25.47987V53.37636a15.58048,15.58048,0,1,0-9.01195,28.37034q.05251.00018.105,0a15.48233,15.48233,0,0,0,8.90691-2.77179V81.098h7.49023V40.69545ZM96.21772,50.95811H88.72811V81.098h7.49023Zm0-10.26266H88.72811v7.49023h7.49023ZM60.41805,66.17532a8.58414,8.58414,0,0,1,8.557-8.61113q.02673-.00009.05346,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.02706,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61177q-.02736.00009-.05472,0a8.58412,8.58412,0,0,1-8.61113-8.557q-.00009-.02738,0-.05473M77.58067,40.69545V53.37636A15.58033,15.58033,0,1,0,68.56935,81.7467q.05283.00018.10567,0a15.4769,15.4769,0,0,0,8.90565-2.77179V81.098h7.4915V40.69545ZM25.38259,66.176a8.58414,8.58414,0,0,1,8.557-8.61114q.02736-.00009.05472,0a8.58414,8.58414,0,0,1,8.61114,8.557q.00009.027,0,.05409a8.58414,8.58414,0,0,1-8.55642,8.61176q-.02736.00009-.05472,0a8.58413,8.58413,0,0,1-8.61177-8.55641q-.00009-.02768,0-.05535m17.16388,14.9227H50.038V50.95872H42.54647V53.377a15.58048,15.58048,0,1,0-9.01069,28.37035q.0522.00016.10441,0a15.48032,15.48032,0,0,0,8.90628-2.77179Z"/></svg>