Die Gewissheit, dass Kubernetes überall und für alle gut funktioniert.
-
Verbinden Sie sich mit der Kubernetes-Community in unserem Slack Kanal, Diskussionsforum, oder beteiligen Sie sich an der Kubernetes-dev-Google-Gruppe. Eine wöchentliches Community-Meeting findet per Videokonferenz statt, um den Stand der Dinge zu diskutieren, folgen Sie
- diesen Anweisungen für Informationen wie Sie teilnehmen können.
Haben Sie ein besonderes Interesse daran, wie Kubernetes mit einer anderen Technologie arbeitet? Werfen Sie einen Blick auf unsere kontinuierlich wachsende
- Listen von SIGs, von AWS und Openstack bis hin zu Big Data und Skalierbarkeit, es gibt einen Platz für Sie, an dem Sie mitwirken können, und Anweisungen zur Gründung einer neuen SIG finden, wenn Ihr besonderes Interesse (noch) nicht abgedeckt ist.
-
+
+
+
+
+
-
Als Mitglied der Kubernetes-Community sind Sie herzlich eingeladen, an allen SIG-Treffen teilzunehmen, die Sie interessieren. Eine Registrierung ist nicht erforderlich.
+
+
+
Die Kubernetes-Community - Nutzer, Mitwirkende und die Kultur, die wir gemeinsam aufgebaut haben - ist einer der Hauptgründe für den kometenhaften Aufstieg dieses Open-Source-Projekts. Unsere Kultur und unsere Werte wachsen und entwickeln sich mit dem Wachstum und der Veränderung des Projekts selbst. Wir alle arbeiten gemeinsam an der ständigen Verbesserung des Projekts und der Art und Weise, wie wir daran arbeiten.
+
Wir sind die Leute, die Probleme und Pull-Requests einreichen, an SIG-Treffen (Special Interest Groups), Kubernetes-Treffen und der KubeCon teilnehmen, sich für die Einführung und Innovation von Kubernetes einsetzen, kubectl get pods ausführen und auf tausend andere wichtige Arten beitragen. Lies weiter, um zu erfahren, wie Du dich engagieren und Teil dieser faszinierenden Gemeinschaft werden kannst.
+
+
-
+
-
-
Verhaltensregeln
-
Die Kubernetes-Community schätzt Respekt und Inklusivität und setzt einen Verhaltenskodex
- in allen Interaktionen durch. Wenn Sie einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder Sitzung,
- in Slack oder in einem anderen Kommunikationsmechanismus feststellen, wenden Sie sich
- bitte an das Kubernetes Code of Conduct Committeeconduct@kubernetes.io. Ihre Anonymität wird geschützt.
-
Unser Benutzerforum ist ein großartiger Ort, um Community-Support zu erhalten.
-
-
-
-
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Gemeinschaftswerte
+Die Werte der Kubernetes-Community sind der Grundstein für den anhaltenden Erfolg des Projekts.
+Diese Prinzipien leiten jeden Aspekt des Kubernetes-Projekts.
+
+
+
+Die Kubernetes-Gemeinschaft legt Wert auf Respekt und Inklusivität und setzt bei allen Interaktionen einen Verhaltenskodex durch. Wenn Du einen Verstoß gegen den Verhaltenskodex bei einer Veranstaltung oder einem Treffen, in Slack oder in einem anderen Kommunikationsmechanismus bemerkst, wende dich an das Kubernetes Code of Conduct Committee unter conduct@kubernetes.io. Alle Berichte werden vertraulich behandelt. Du kannst hier mehr über den Ausschuss erfahren.
+
+
+
+ Technische Problemlösung für jeden Anwendungsfall
+
+
+
+
+
+
+
+
+
+
+
+
+
Bevorstehende Veranstaltungen
+ {{< upcoming-events >}}
+
+
+
+
+
+
+
Globale Gemeinschaft
+Mit mehr als 150 Treffen auf der ganzen Welt, Tendenz steigend, solltest du deine lokalen Kube-Leute finden. Wenn keins in der Nähe ist, nimm die Sache in die Hand und gründe dein eigenes.
+
diff --git a/content/de/docs/concepts/cluster-administration/_index.md b/content/de/docs/concepts/cluster-administration/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/concepts/configuration/_index.md b/content/de/docs/concepts/configuration/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/concepts/containers/_index.md b/content/de/docs/concepts/containers/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/concepts/overview/_index.md b/content/de/docs/concepts/overview/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/concepts/policy/_index.md b/content/de/docs/concepts/policy/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/concepts/services-networking/_index.md b/content/de/docs/concepts/services-networking/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/concepts/storage/_index.md b/content/de/docs/concepts/storage/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/reference/glossary/etcd.md b/content/de/docs/reference/glossary/etcd.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/reference/glossary/index.md b/content/de/docs/reference/glossary/index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/reference/glossary/kube-apiserver.md b/content/de/docs/reference/glossary/kube-apiserver.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/reference/glossary/kube-controller-manager.md b/content/de/docs/reference/glossary/kube-controller-manager.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/reference/glossary/kube-scheduler.md b/content/de/docs/reference/glossary/kube-scheduler.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/reference/glossary/kubelet.md b/content/de/docs/reference/glossary/kubelet.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/reference/kubectl/_index.md b/content/de/docs/reference/kubectl/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/setup/release/_index.md b/content/de/docs/setup/release/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/access-application-cluster/_index.md b/content/de/docs/tasks/access-application-cluster/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/access-kubernetes-api/_index.md b/content/de/docs/tasks/access-kubernetes-api/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/administer-cluster/_index.md b/content/de/docs/tasks/administer-cluster/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/configure-pod-container/_index.md b/content/de/docs/tasks/configure-pod-container/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/debug-application-cluster/_index.md b/content/de/docs/tasks/debug-application-cluster/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/federation/_index.md b/content/de/docs/tasks/federation/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/inject-data-application/_index.md b/content/de/docs/tasks/inject-data-application/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/manage-daemon/_index.md b/content/de/docs/tasks/manage-daemon/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/run-application/_index.md b/content/de/docs/tasks/run-application/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/service-catalog/_index.md b/content/de/docs/tasks/service-catalog/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/tls/_index.md b/content/de/docs/tasks/tls/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/docs/tasks/tools/_index.md b/content/de/docs/tasks/tools/_index.md
old mode 100755
new mode 100644
diff --git a/content/de/includes/partner-style.css b/content/de/includes/partner-style.css
new file mode 100644
index 0000000000..dc120872e0
--- /dev/null
+++ b/content/de/includes/partner-style.css
@@ -0,0 +1,201 @@
+/* SECTIONS */
+.section {
+ clear: both;
+ padding: 0px;
+ margin-bottom: 2em;
+}
+
+.kcsp_section {
+ clear: both;
+ padding: 0px;
+ margin-bottom: 2em;
+}
+
+/* COLUMN SETUP */
+.col {
+ display: block;
+ float:left;
+ margin: 1% 0 1% 1.6%;
+ background-color: #f9f9f9;
+}
+.col:first-child { margin-left: 0; }
+
+
+/* GROUPING */
+.group:before,
+.group:after {
+ content:"";
+ display:table;
+}
+.group:after {
+ clear:both;
+}
+.group {
+ zoom:1; /* For IE 6/7 */
+}
+
+/* GRID OF THREE */
+.span_3_of_3 {
+ width: 35%;
+ background-color: #f9f9f9;
+ padding: 20px;
+}
+.span_2_of_3 {
+ width: 35%;
+ background-color: #f9f9f9;
+ padding: 20px;
+}
+.span_1_of_3 {
+ width: 35%;
+ background-color: #f9f9f9;
+ padding: 20px;
+}
+
+.col-container {
+ display: table; /* Make the container element behave like a table */
+ width: 100%; /* Set full-width to expand the whole page */
+ padding-bottom: 30px;
+}
+
+.col-nav {
+ display: table-cell; /* Make elements inside the container behave like table cells */
+ width: 18%;
+ background-color: #f9f9f9;
+ padding: 20px;
+ border: 5px solid white;
+}
+
+/* GO FULL WIDTH AT LESS THAN 480 PIXELS */
+
+@media only screen and (max-width: 480px) {
+ .col { margin: 1% 0 1% 0%;}
+ .span_3_of_3, .span_2_of_3, .span_1_of_3 { width: 100%; }
+}
+
+@media only screen and (max-width: 650px) {
+ .col-nav {
+ display: block;
+ width: 100%;
+ }
+}
+
+.button{
+ max-width: 100%;
+ box-sizing: border-box;
+ margin: 0;
+ display: inline-block;
+ border-radius: 6px;
+ padding: 0 20px;
+ line-height: 40px;
+ color: #ffffff;
+ font-size: 16px;
+ background-color: #3371e3;
+ text-decoration: none;
+ }
+
+h5 {
+ font-size: 16px;
+ line-height: 1.5em;
+ margin-bottom: 2em;
+}
+
+#usersGrid a {
+ display: inline-block;
+ background-color: #f9f9f9;
+}
+
+#ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer {
+ position: relative;
+ width: 100%;
+ display: flex;
+ justify-content: space-between;
+ flex-wrap: wrap;
+}
+
+#isvContainer {
+ margin-bottom: 80px;
+}
+
+#kcspContainer {
+ margin-bottom: 80px;
+}
+
+#distContainer {
+ margin-bottom: 80px;
+}
+
+#ktpContainer {
+ margin-bottom: 80px;
+}
+
+.partner-box {
+ position: relative;
+ width: 47%;
+ max-width: 48%;
+ min-width: 48%;
+ margin-bottom: 20px;
+ padding: 20px;
+ flex: 1;
+ display: flex;
+ justify-content: left;
+ align-items: flex-start;
+}
+
+.partner-box img {
+ background-color: #f9f9f9;
+}
+
+.partner-box > div {
+ margin-left: 30px;
+}
+
+.partner-box a {
+ color: #3576E3;
+}
+
+@media screen and (max-width: 1024px) {
+ .partner-box {
+ flex-direction: column;
+ justify-content: flex-start;
+ }
+
+ .partner-box > div {
+ margin: 20px 0 0;
+ }
+}
+
+@media screen and (max-width: 568px) {
+ #ktpContainer, #distContainter, #kcspContainer, #isvContainer, #servContainer {
+ justify-content: center;
+ }
+
+ .partner-box {
+ flex-direction: column;
+ justify-content: flex-start;
+ width: 100%;
+ max-width: 100%;
+ min-width: 100%;
+ }
+
+ .partner-box > div {
+ margin: 20px 0 0;
+ }
+}
+
+@media screen and (max-width: 568px) {
+ #ktpContainer, #distContainer, #kcspContainer, #isvContainer, #servContainer {
+ justify-content: center;
+ }
+
+ .partner-box {
+ flex-direction: column;
+ justify-content: flex-start;
+ width: 100%;
+ max-width: 100%;
+ min-width: 100%;
+ }
+
+ .partner-box > div {
+ margin: 20px 0 0;
+ }
+}
diff --git a/content/de/partners/_index.html b/content/de/partners/_index.html
index e99b03b62a..ecf3e2542b 100644
--- a/content/de/partners/_index.html
+++ b/content/de/partners/_index.html
@@ -1,91 +1,53 @@
---
title: Partner
bigheader: Kubernetes Partner
-abstract: Entwicklung des Kubernetes-Ökosystems.
+abstract: Erweiterung des Kubernetes-Ökosystems.
class: gridPage
cid: partners
---
-
-
Kubernetes arbeitet mit Partnern zusammen, um eine starke, dynamische Codebasis zu schaffen, die ein Spektrum von aufeinander abgestimmten Plattformen unterstützt.
-
-
-
-
- Kubernetes zertifizierte Service Provider
-
- Geprüfte Service Provider mit großer Erfahrung, die Unternehmen bei der erfolgreichen Einführung von Kubernetes unterstützen.
-
-
-
+ {{< cncf-landscape helpers=true >}}
-
-
+
\ No newline at end of file
diff --git a/content/en/blog/_posts/2019-03-29-kube-proxy-subtleties-debugging-an-intermittent-connection-resets.md b/content/en/blog/_posts/2019-03-29-kube-proxy-subtleties-debugging-an-intermittent-connection-resets.md
index 12dd2d79a3..bed35dabb5 100644
--- a/content/en/blog/_posts/2019-03-29-kube-proxy-subtleties-debugging-an-intermittent-connection-resets.md
+++ b/content/en/blog/_posts/2019-03-29-kube-proxy-subtleties-debugging-an-intermittent-connection-resets.md
@@ -144,10 +144,9 @@ ways to address it.
- Specifically add an iptables rule to drop the packets that are marked as
*INVALID*, so it won’t reach to client pod and cause harm.
-The fix is drafted (https://github.com/kubernetes/kubernetes/pull/74840), but
-unfortunately it didn’t catch the v1.14 release window. However, for the users
-that are affected by this bug, there is a way to mitigate the problem by applying
-the following rule in your cluster.
+The [fix](https://github.com/kubernetes/kubernetes/pull/74840) is available in v1.15+.
+However, for the users that are affected by this bug, there is a way to mitigate the
+problem by applying the following rule in your cluster.
```yaml
apiVersion: extensions/v1beta1
diff --git a/content/en/blog/_posts/2020-12-02-dockershim-faq.md b/content/en/blog/_posts/2020-12-02-dockershim-faq.md
index edcab9fe53..70e6c9b114 100644
--- a/content/en/blog/_posts/2020-12-02-dockershim-faq.md
+++ b/content/en/blog/_posts/2020-12-02-dockershim-faq.md
@@ -28,7 +28,7 @@ as cgroups v2 and user namespaces are being implemented in these newer CRI
runtimes. Removing support for the dockershim will allow further development in
those areas.
-[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim
+[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim
### Can I still use Docker in Kubernetes 1.20?
@@ -42,9 +42,11 @@ startup if using Docker as the runtime.
Given the impact of this change, we are using an extended deprecation timeline.
It will not be removed before Kubernetes 1.22, meaning the earliest release without
-dockershim would be 1.23 in late 2021. We will be working closely with vendors
-and other ecosystem groups to ensure a smooth transition and will evaluate things
-as the situation evolves.
+dockershim would be 1.23 in late 2021.
+_Update_: removal of dockershim is scheduled for Kubernetes v1.24, see
+[Dockershim Removal Kubernetes Enhancement Proposal][drkep].
+We will be working closely with vendors and other ecosystem groups to ensure a smooth transition and will evaluate
+things as the situation evolves.
### Can I still use dockershim after it is removed from Kubernetes?
diff --git a/content/en/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md b/content/en/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md
new file mode 100644
index 0000000000..88c9fc890b
--- /dev/null
+++ b/content/en/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md
@@ -0,0 +1,72 @@
+---
+layout: blog
+title: "Spotlight on SIG Node"
+date: 2021-09-27
+slug: sig-node-spotlight-2021
+---
+
+**Author:** Dewan Ahmed, Red Hat
+
+## Introduction
+
+In Kubernetes, a _Node_ is a representation of a single machine in your cluster. [SIG Node](https://github.com/kubernetes/community/tree/master/sig-node) owns that very important Node component and supports various subprojects such as Kubelet, Container Runtime Interface (CRI) and more to support how the pods and host resources interact. In this blog, we have summarized our conversation with [Elana Hashman (EH)](https://twitter.com/ehashdn) & [Sergey Kanzhelev (SK)](https://twitter.com/SergeyKanzhelev), who walk us through the various aspects of being a part of the SIG and share some insights about how others can get involved.
+
+## A summary of our conversation
+
+### Could you tell us a little about what SIG Node does?
+
+SK: SIG Node is a vertical SIG responsible for the components that support the controlled interactions between the pods and host resources. We manage the lifecycle of pods that are scheduled to a node. This SIG's focus is to enable a broad set of workload types, including workloads with hardware specific or performance sensitive requirements. All while maintaining isolation boundaries between pods on a node, as well as the pod and the host. This SIG maintains quite a few components and has many external dependencies (like container runtimes or operating system features), which makes the complexity we deal with huge. We tame the complexity and aim to continuously improve node reliability.
+
+### "SIG Node is a vertical SIG" could you explain a bit more?
+
+EH: There are two kinds of SIGs: horizontal and vertical. Horizontal SIGs are concerned with a particular function of every component in Kubernetes: for example, SIG Security considers security aspects of every component in Kubernetes, or SIG Instrumentation looks at the logs, metrics, traces and events of every component in Kubernetes. Such SIGs don't tend to own a lot of code.
+
+Vertical SIGs, on the other hand, own a single component, and are responsible for approving and merging patches to that code base. SIG Node owns the "Node" vertical, pertaining to the kubelet and its lifecycle. This includes the code for the kubelet itself, as well as the node controller, the container runtime interface, and related subprojects like the node problem detector.
+
+### How did the CI subproject start? Is this specific to SIG Node and how does it help the SIG?
+
+SK: The subproject started as a follow up after one of the releases was blocked by numerous test failures of critical tests. These tests haven’t started falling all at once, rather continuous lack of attention led to slow degradation of tests quality. SIG Node was always prioritizing quality and reliability, and forming of the subproject was a way to highlight this priority.
+
+### As the 3rd largest SIG in terms of number of issues and PRs, how does your SIG juggle so much work?
+
+EH: It helps to be organized. When I increased my contributions to the SIG in January of 2021, I found myself overwhelmed by the volume of pull requests and issues and wasn't sure where to start. We were already tracking test-related issues and pull requests on the CI subproject board, but that was missing a lot of our bugfixes and feature work. So I began putting together a triage board for the rest of our pull requests, which allowed me to sort each one by status and what actions to take, and documented its use for other contributors. We closed or merged over 500 issues and pull requests tracked by our two boards in each of the past two releases. The Kubernetes devstats showed that we have significantly increased our velocity as a result.
+
+In June, we ran our first bug scrub event to work through the backlog of issues filed against SIG Node, ensuring they were properly categorized. We closed over 130 issues over the course of this 48 hour global event, but as of writing we still have 333 open issues.
+
+### Why should new and existing contributors consider joining SIG Node?
+
+SK: Being a SIG Node contributor gives you skills and recognition that are rewarding and useful. Understanding under the hood of a kubelet helps architecting better apps, tune and optimize those apps, and gives leg up in issues troubleshooting. If you are a new contributor, SIG Node gives you the foundational knowledge that is key to understanding why other Kubernetes components are designed the way they are. Existing contributors may benefit as many features will require SIG Node changes one way or another. So being a SIG Node contributor helps building features in other SIGs faster.
+
+SIG Node maintains numerous components, many of which have dependency on external projects or OS features. This makes the onboarding process quite lengthy and demanding. But if you are up for a challenge, there is always a place for you, and a group of people to support.
+
+### What do you do to help new contributors get started?
+
+EH: Getting started in SIG Node can be intimidating, since there is so much work to be done, our SIG meetings are very large, and it can be hard to find a place to start.
+
+I always encourage new contributors to work on things that they have some investment in already. In SIG Node, that might mean volunteering to help fix a bug that you have personally been affected by, or helping to triage bugs you care about by priority.
+
+To come up to speed on any open source code base, there are two strategies you can take: start by exploring a particular issue deeply, and follow that to expand the edges of your knowledge as needed, or briefly review as many issues and change requests as you possibly can to get a higher level picture of how the component works. Ultimately, you will need to do both if you want to become a Node reviewer or approver.
+
+[Davanum Srinivas](https://twitter.com/dims) and I each ran a cohort of group mentoring to help teach new contributors the skills to become Node reviewers, and if there's interest we can work to find a mentor to run another session. I also encourage new contributors to attend our Node CI Subproject meeting: it's a smaller audience and we don't record the triage sessions, so it can be a less intimidating way to get started with the SIG.
+
+### Are there any particular skills you’d like to recruit for? What skills are contributors to SIG Usability likely to learn?
+
+SK: SIG Node works on many workstreams in very different areas. All of these areas are on system level. For the typical code contributions you need to have a passion for building and utilizing low level APIs and writing performant and reliable components. Being a contributor you will learn how to debug and troubleshoot, profile, and monitor these components, as well as user workload that is run by these components. Often, with the limited to no access to Nodes, as they are running production workloads.
+
+The other way of contribution is to help document SIG node features. This type of contribution requires a deep understanding of features, and ability to explain them in simple terms.
+
+Finally, we are always looking for feedback on how best to run your workload. Come and explain specifics of it, and what features in SIG Node components may help to run it better.
+
+### What are you getting positive feedback on, and what’s coming up next for SIG Node?
+
+EH: Over the past year SIG Node has adopted some new processes to help manage our feature development and Kubernetes enhancement proposals, and other SIGs have looked to us for inspiration in managing large workloads. I hope that this is an area we can continue to provide leadership in and further iterate on.
+
+We have a great balance of new features and deprecations in flight right now. Deprecations of unused or difficult to maintain features help us keep technical debt and maintenance load under control, and examples include the dockershim and DynamicKubeletConfiguration deprecations. New features will unlock additional functionality in end users' clusters, and include exciting features like support for cgroups v2, swap memory, graceful node shutdowns, and device management policies.
+
+### Any closing thoughts/resources you’d like to share?
+
+SK/EH: It takes time and effort to get to any open source community. SIG Node may overwhelm you at first with the number of participants, volume of work, and project scope. But it is totally worth it. Join our welcoming community! [SIG Node GitHub Repo](https://github.com/kubernetes/community/tree/master/sig-node) contains many useful resources including Slack, mailing list and other contact info.
+
+## Wrap Up
+
+SIG Node hosted a [KubeCon + CloudNativeCon Europe 2021 talk](https://www.youtube.com/watch?v=z5aY4e2RENA) with an intro and deep dive to their awesome SIG. Join the SIG's meetings to find out about the most recent research results, what the plans are for the forthcoming year, and how to get involved in the upstream Node team as a contributor!
\ No newline at end of file
diff --git a/content/en/blog/_posts/2021-09-29-data-duplication-in-data-heavy-k8s-env.md b/content/en/blog/_posts/2021-09-29-data-duplication-in-data-heavy-k8s-env.md
new file mode 100644
index 0000000000..42e9186692
--- /dev/null
+++ b/content/en/blog/_posts/2021-09-29-data-duplication-in-data-heavy-k8s-env.md
@@ -0,0 +1,243 @@
+---
+layout: blog
+title: "How to Handle Data Duplication in Data-Heavy Kubernetes Environments"
+date: 2021-09-29
+slug: how-to-handle-data-duplication-in-data-heavy-kubernetes-environments
+---
+
+**Authors:**
+Augustinas Stirbis (CAST AI)
+
+## Why Duplicate Data?
+
+It’s convenient to create a copy of your application with a copy of its state for each team.
+For example, you might want a separate database copy to test some significant schema changes
+or develop other disruptive operations like bulk insert/delete/update...
+
+**Duplicating data takes a lot of time.** That’s because you need first to download
+all the data from a source block storage provider to compute and then send
+it back to a storage provider again. There’s a lot of network traffic and CPU/RAM used in this process.
+Hardware acceleration by offloading certain expensive operations to dedicated hardware is
+**always a huge performance boost**. It reduces the time required to complete an operation by orders
+of magnitude.
+
+## Volume Snapshots to the rescue
+
+Kubernetes introduced [VolumeSnapshots](/docs/concepts/storage/volume-snapshots/) as alpha in 1.12,
+beta in 1.17, and the Generally Available version in 1.20.
+VolumeSnapshots use specialized APIs from storage providers to duplicate volume of data.
+
+Since data is already in the same storage device (array of devices), duplicating data is usually
+a metadata operation for storage providers with local snapshots (majority of on-premise storage providers).
+All you need to do is point a new disk to an immutable snapshot and only
+save deltas (or let it do a full-disk copy). As an operation that is inside the storage back-end,
+it’s much quicker and usually doesn’t involve sending traffic over the network.
+Public Clouds storage providers under the hood work a bit differently. They save snapshots
+to Object Storage and then copy back from Object storage to Block storage when "duplicating" disk.
+Technically there is a lot of Compute and network resources spent on Cloud providers side,
+but from Kubernetes user perspective VolumeSnapshots work the same way whether is it local or
+remote snapshot storage provider and no Compute and Network resources are involved in this operation.
+
+## Sounds like we have our solution, right?
+
+Actually, VolumeSnapshots are namespaced, and Kubernetes protects namespaced data from
+being shared between tenants (Namespaces). This Kubernetes limitation is a conscious design
+decision so that a Pod running in a different namespace can’t mount another application’s
+[PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC).
+
+One way around it would be to create multiple volumes with duplicate data in one namespace.
+However, you could easily reference the wrong copy.
+
+So the idea is to separate teams/initiatives by namespaces to avoid that and generally
+limit access to the production namespace.
+
+## Solution? Creating a Golden Snapshot externally
+
+Another way around this design limitation is to create Snapshot externally (not through Kubernetes).
+This is also called pre-provisioning a snapshot manually. Next, I will import it
+as a multi-tenant golden snapshot that can be used for many namespaces. Below illustration will be
+for AWS EBS (Elastic Block Storage) and GCE PD (Persistent Disk) services.
+
+### High-level plan for preparing the Golden Snapshot
+
+1. Identify Disk (EBS/Persistent Disk) that you want to clone with data in the cloud provider
+2. Make a Disk Snapshot (in cloud provider console)
+3. Get Disk Snapshot ID
+
+### High-level plan for cloning data for each team
+
+1. Create Namespace “sandbox01”
+2. Import Disk Snapshot (ID) as VolumeSnapshotContent to Kubernetes
+3. Create VolumeSnapshot in the Namespace "sandbox01" mapped to VolumeSnapshotContent
+4. Create the PersistentVolumeClaim from VolumeSnapshot
+5. Install Deployment or StatefulSet with PVC
+
+## Step 1: Identify Disk
+
+First, you need to identify your golden source. In my case, it’s a PostgreSQL database
+on PersistentVolumeClaim “postgres-pv-claim” in the “production” namespace.
+
+```terminal
+kubectl -n get pvc -o jsonpath='{.spec.volumeName}'
+```
+
+The output will look similar to:
+```
+pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d90
+```
+
+## Step 2: Prepare your golden source
+
+You need to do this once or every time you want to refresh your golden data.
+
+### Make a Disk Snapshot
+
+Go to AWS EC2 or GCP Compute Engine console and search for an EBS volume
+(on AWS) or Persistent Disk (on GCP), that has a label matching the last output.
+In this case I saw: `pvc-3096b3ba-38b6-4fd1-a42f-ec99176ed0d9`.
+
+Click on Create snapshot and give it a name. You can do it in Console manually,
+in AWS CloudShell / Google Cloud Shell, or in the terminal. To create a snapshot in the
+terminal you must have the AWS CLI tool (`aws`) or Google's CLI (`gcloud`)
+installed and configured.
+
+Here’s the command to create snapshot on GCP:
+
+```terminal
+gcloud compute disks snapshot --project= --snapshot-names= --zone= --storage-location=
+```
+{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/create-volume-snapshot-gcp.png" alt="Screenshot of a terminal showing volume snapshot creation on GCP" title="GCP snapshot creation" >}}
+
+
+GCP identifies the disk by its PVC name, so it’s direct mapping. In AWS, you need to
+find volume by the CSIVolumeName AWS tag with PVC name value first that will be used for snapshot creation.
+
+{{< figure src="/images/blog/2021-09-07-data-duplication-in-data-heavy-k8s-env/identify-volume-aws.png" alt="Screenshot of AWS web console, showing EBS volume identification" title="Identify disk ID on AWS" >}}
+
+Mark done Volume (volume-id) ```vol-00c7ecd873c6fb3ec``` and ether create EBS snapshot in AWS Console, or use ```aws cli```.
+
+```terminal
+aws ec2 create-snapshot --volume-id '' --description '' --tag-specifications 'ResourceType=snapshot'
+```
+
+## Step 3: Get your Disk Snapshot ID
+
+In AWS, the command above will output something similar to:
+```terminal
+"SnapshotId": "snap-09ed24a70bc19bbe4"
+```
+
+If you’re using the GCP cloud, you can get the snapshot ID from the gcloud command by querying for the snapshot’s given name:
+
+```terminal
+gcloud compute snapshots --project= describe | grep id:
+```
+You should get similar output to:
+```
+id: 6645363163809389170
+```
+
+## Step 4: Create a development environment for each team
+
+Now I have my Golden Snapshot, which is immutable data. Each team will get a copy
+of this data, and team members can modify it as they see fit, given that a new EBS/persistent
+disk will be created for each team.
+
+Below I will define a manifest for each namespace. To save time, you can replace
+the namespace name (such as changing “sandbox01” → “sandbox42”) using tools
+such as `sed` or `yq`, with Kubernetes-aware templating tools like
+[Kustomize](/docs/tasks/manage-kubernetes-objects/kustomization/),
+or using variable substitution in a CI/CD pipeline.
+
+Here's an example manifest:
+
+```yaml
+---
+apiVersion: snapshot.storage.k8s.io/v1
+kind: VolumeSnapshotContent
+metadata:
+ name: postgresql-orders-db-sandbox01
+ namespace: sandbox01
+spec:
+ deletionPolicy: Retain
+ driver: pd.csi.storage.gke.io
+ source:
+ snapshotHandle: 'gcp/projects/staging-eu-castai-vt5hy2/global/snapshots/6645363163809389170'
+ volumeSnapshotRef:
+ kind: VolumeSnapshot
+ name: postgresql-orders-db-snap
+ namespace: sandbox01
+---
+apiVersion: snapshot.storage.k8s.io/v1
+kind: VolumeSnapshot
+metadata:
+ name: postgresql-orders-db-snap
+ namespace: sandbox01
+spec:
+ source:
+ volumeSnapshotContentName: postgresql-orders-db-sandbox01
+```
+
+In Kubernetes, VolumeSnapshotContent (VSC) objects are not namespaced.
+However, I need a separate VSC for each different namespace to use, so the
+`metadata.name` of each VSC must also be different. To make that straightfoward,
+I used the target namespace as part of the name.
+
+Now it’s time to replace the driver field with the CSI (Container Storage Interface) driver
+installed in your K8s cluster. Major cloud providers have CSI driver for block storage that
+support VolumeSnapshots but quite often CSI drivers are not installed by default, consult
+with your Kubernetes provider.
+
+That manifest above defines a VSC that works on GCP.
+On AWS, driver and SnashotHandle values might look like:
+
+```YAML
+ driver: ebs.csi.aws.com
+ source:
+ snapshotHandle: "snap-07ff83d328c981c98"
+```
+
+At this point, I need to use the *Retain* policy, so that the CSI driver doesn’t try to
+delete my manually created EBS disk snapshot.
+
+For GCP, you will have to build this string by hand - add a full project ID and snapshot ID.
+For AWS, it’s just a plain snapshot ID.
+
+VSC also requires specifying which VolumeSnapshot (VS) will use it, so VSC and VS are
+referencing each other.
+
+Now I can create PersistentVolumeClaim from VS above. It’s important to set this first:
+
+
+```yaml
+---
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+ name: postgres-pv-claim
+ namespace: sandbox01
+spec:
+ dataSource:
+ kind: VolumeSnapshot
+ name: postgresql-orders-db-snap
+ apiGroup: snapshot.storage.k8s.io
+ accessModes:
+ - ReadWriteOnce
+ resources:
+ requests:
+ storage: 21Gi
+```
+
+If default StorageClass has [WaitForFirstConsumer](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode) policy,
+then the actual Cloud Disk will be created from the Golden Snapshot only when some Pod bounds that PVC.
+
+Now I assign that PVC to my Pod (in my case, it’s Postgresql) as I would with any other PVC.
+
+```terminal
+kubectl -n get volumesnapshotContent,volumesnapshot,pvc,pod
+```
+
+Both VS and VSC should be *READYTOUSE* true, PVC bound, and the Pod (from Deployment or StatefulSet) running.
+
+**To keep on using data from my Golden Snapshot, I just need to repeat this for the
+next namespace and voilà! No need to waste time and compute resources on the duplication process.**
diff --git a/content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md b/content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md
new file mode 100644
index 0000000000..1af75e9ceb
--- /dev/null
+++ b/content/en/blog/_posts/2021-10-05-nsa-cisa-hardening.md
@@ -0,0 +1,417 @@
+---
+layout: blog
+title: A Closer Look at NSA/CISA Kubernetes Hardening Guidance
+date: 2021-10-05
+slug: nsa-cisa-kubernetes-hardening-guidance
+---
+
+**Authors:** Jim Angel (Google), Pushkar Joglekar (VMware), and Savitha
+Raghunathan (Red Hat)
+
+{{% alert title="Disclaimer" %}}
+The open source tools listed in this article are to serve as examples only
+and are in no way a direct recommendation from the Kubernetes community or authors.
+{{% /alert %}}
+
+## Background
+
+USA's National Security Agency (NSA) and the Cybersecurity and Infrastructure
+Security Agency (CISA)
+released, "[Kubernetes Hardening Guidance](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF)"
+on August 3rd, 2021. The guidance details threats to Kubernetes environments
+and provides secure configuration guidance to minimize risk.
+
+The following sections of this blog correlate to the sections in the NSA/CISA guidance.
+Any missing sections are skipped because of limited opportunities to add
+anything new to the existing content.
+
+_Note_: This blog post is not a substitute for reading the guide. Reading the published
+guidance is recommended before proceeding as the following content is
+complementary.
+
+## Introduction and Threat Model
+
+Note that the threats identified as important by the NSA/CISA, or the intended audience of this guidance, may be different from the threats that other enterprise users of Kubernetes consider important. This section
+is still useful for organizations that care about data, resource theft and
+service unavailability.
+
+The guidance highlights the following three sources of compromises:
+
+- Supply chain risks
+- Malicious threat actors
+- Insider threats (administrators, users, or cloud service providers)
+
+The [threat model](https://en.wikipedia.org/wiki/Threat_model) tries to take a step back and review threats that not only
+exist within the boundary of a Kubernetes cluster but also include the underlying
+infrastructure and surrounding workloads that Kubernetes does not manage.
+
+For example, when a workload outside the cluster shares the same physical
+network, it has access to the kubelet and to control plane components: etcd, controller manager, scheduler and API
+server. Therefore, the guidance recommends having network level isolation
+separating Kubernetes clusters from other workloads that do not need connectivity
+to Kubernetes control plane nodes. Specifically, scheduler, controller-manager,
+etcd only need to be accessible to the API server. Any interactions with Kubernetes
+from outside the cluster can happen by providing access to API server port.
+
+List of ports and protocols for each of these components are
+defined in [Ports and Protocols](/docs/reference/ports-and-protocols/)
+within the Kubernetes documentation.
+
+> Special note: kube-scheduler and kube-controller-manager uses different ports than the ones mentioned in the guidance
+
+The [Threat modelling](https://cnsmap.netlify.app/threat-modelling) section
+from the CNCF [Cloud Native Security Whitepaper + Map](https://github.com/cncf/tag-security/tree/main/security-whitepaper)
+provides another perspective on approaching threat modelling Kubernetes, from a
+cloud native lens.
+
+## Kubernetes Pod security
+
+Kubernetes by default does not guarantee strict workload isolation between pods
+running in the same node in a cluster. However, the guidance provides several
+techniques to enhance existing isolation and reduce the attack surface in case of a
+compromise.
+
+### "Non-root" containers and "rootless" container engines
+
+Several best practices related to basic security principle of least privilege
+i.e. provide only the permissions are needed; no more, no less, are worth a
+second look.
+
+The guide recommends setting non-root user at build time instead of relying on
+setting `runAsUser` at runtime in your Pod spec. This is a good practice and provides
+some level of defense in depth. For example, if the container image is built with user `10001`
+and the Pod spec misses adding the `runAsuser` field in its `Deployment` object. In this
+case there are certain edge cases that are worth exploring for awareness:
+
+1. Pods can fail to start, if the user defined at build time is different from
+ the one defined in pod spec and some files are as a result inaccessible.
+2. Pods can end up sharing User IDs unintentionally. This can be problematic
+ even if the User IDs are non-zero in a situation where a container escape to
+ host file system is possible. Once the attacker has access to the host file
+ system, they get access to all the file resources that are owned by other
+ unrelated pods that share the same UID.
+3. Pods can end up sharing User IDs, with other node level processes not managed
+ by Kubernetes e.g. node level daemons for auditing, vulnerability scanning,
+ telemetry. The threat is similar to the one above where host file system
+ access can give attacker full access to these node level daemons without
+ needing to be root on the node.
+
+However, none of these cases will have as severe an impact as a container
+running as root being able to escape as a root user on the host, which can provide
+an attacker with complete control of the worker node, further allowing lateral
+movement to other worker or control plane nodes.
+
+Kubernetes 1.22 introduced
+an [alpha feature](/docs/tasks/administer-cluster/kubelet-in-userns/)
+that specifically reduces the impact of such a control plane component running
+as root user to a non-root user through user namespaces.
+
+That ([alpha stage](/docs/reference/command-line-tools-reference/feature-gates/#feature-stages)) support for user namespaces / rootless mode is available with
+the following container runtimes:
+
+- [Docker Engine](https://docs.docker.com/engine/security/rootless/)
+- [Podman](https://developers.redhat.com/blog/2020/09/25/rootless-containers-with-podman-the-basics)
+
+Some distributions support running in rootless mode, like the following:
+
+- [kind](https://kind.sigs.k8s.io/docs/user/rootless/)
+- [k3s](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
+- [Usernetes](https://github.com/rootless-containers/usernetes)
+
+### Immutable container filesystems
+
+The NSA/CISA Kubernetes Hardening Guidance highlights an often overlooked feature `readOnlyRootFileSystem`, with a
+working example in [Appendix B](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=42). This example limits execution and tampering of
+containers at runtime. Any read/write activity can then be limited to few
+directories by using `tmpfs` volume mounts.
+
+However, some applications that modify the container filesystem at runtime, like exploding a WAR or JAR file at container startup,
+could face issues when enabling this feature. To avoid this issue, consider making minimal changes to the filesystem at runtime
+when possible.
+
+### Building secure container images
+
+Kubernetes Hardening Guidance also recommends running a scanner at deploy time as an admission controller,
+to prevent vulnerable or misconfigured pods from running in the cluster.
+Theoretically, this sounds like a good approach but there are several caveats to
+consider before this can be implemented in practice:
+
+- Depending on network bandwidth, available resources and scanner of choice,
+ scanning for vulnerabilities for an image can take an indeterminate amount of
+ time. This could lead to slower or unpredictable pod start up times, which
+ could result in spikes of unavailability when apps are serving peak load.
+- If the policy that allows or denies pod startup is made using incorrect or
+ incomplete data it could result in several false positive or false negative
+ outcomes like the following:
+ - inside a container image, the `openssl` package is detected as vulnerable. However,
+ the application is written in Golang and uses the Go `crypto` package for TLS. Therefore, this vulnerability
+ is not in the code execution path and as such has minimal impact if it
+ remains unfixed.
+ - A vulnerability is detected in the `openssl` package for a Debian base image.
+ However, the upstream Debian community considers this as a Minor impact
+ vulnerability and as a result does not release a patch fix for this
+ vulnerability. The owner of this image is now stuck with a vulnerability that
+ cannot be fixed and a cluster that does not allow the image to run because
+ of predefined policy that does not take into account whether the fix for a
+ vulnerability is available or not
+ - A Golang app is built on top of a [distroless](https://github.com/GoogleContainerTools/distroless)
+ image, but it is compiled with a Golang version that uses a vulnerable [standard library](https://pkg.go.dev/std).
+ The scanner has
+ no visibility into golang version but only on OS level packages. So it
+ allows the pod to run in the cluster in spite of the image containing an
+ app binary built on vulnerable golang.
+
+To be clear, relying on vulnerability scanners is absolutely a good idea but
+policy definitions should be flexible enough to allow:
+
+- Creation of exception lists for images or vulnerabilities through labelling
+- Overriding the severity with a risk score based on impact of a vulnerability
+- Applying the same policies at build time to catch vulnerable images with
+ fixable vulnerabilities before they can be deployed into Kubernetes clusters
+
+Special considerations like offline vulnerability database fetch, may also be
+needed, if the clusters run in an air-gapped environment and the scanners
+require internet access to update the vulnerability database.
+
+### Pod Security Policies
+
+Since Kubernetes v1.21, the [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)
+API and related features are [deprecated](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/),
+but some of the guidance in this section will still apply for the next few years, until cluster operators
+upgrade their clusters to newer Kubernetes versions.
+
+The Kubernetes project is working on a replacement for PodSecurityPolicy.
+Kubernetes v1.22 includes an alpha feature called [Pod Security Admission](/docs/concepts/security/pod-security-admission/)
+that is intended to allow enforcing a minimum level of isolation between pods.
+
+The built-in isolation levels for Pod Security Admission are derived
+from [Pod Security Standards](/docs/concepts/security/pod-security-standards/), which is a superset of all the components mentioned in Table I [page 10](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=17) of
+the guidance.
+
+Information about migrating from PodSecurityPolicy to the Pod Security
+Admission feature is available
+in
+[Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/).
+
+One important behavior mentioned in the guidance that remains the same between
+Pod Security Policy and its replacement is that enforcing either of them does
+not affect pods that are already running. With both PodSecurityPolicy and Pod Security Admission,
+the enforcement happens during the pod creation
+stage.
+
+### Hardening container engines
+
+Some container workloads are less trusted than others but may need to run in the
+same cluster. In those cases, running them on dedicated nodes that include
+hardened container runtimes that provide stricter pod isolation boundaries can
+act as a useful security control.
+
+Kubernetes supports
+an API called [RuntimeClass](/docs/concepts/containers/runtime-class/) that is
+stable / GA (and, therefore, enabled by default) stage as of Kubernetes v1.20.
+RuntimeClass allows you to ensure that Pods requiring strong isolation are scheduled onto
+nodes that can offer it.
+
+Some third-party projects that you can use in conjunction with RuntimeClass are:
+
+- [kata containers](https://github.com/kata-containers/kata-containers/blob/main/docs/how-to/how-to-use-k8s-with-cri-containerd-and-kata.md#create-runtime-class-for-kata-containers)
+- [gvisor](https://gvisor.dev/docs/user_guide/containerd/quick_start/)
+
+As discussed here and in the guidance, many features and tooling exist in and around
+Kubernetes that can enhance the isolation boundaries between
+pods. Based on relevant threats and risk posture, you should pick and choose
+between them, instead of trying to apply all the recommendations. Having said that, cluster
+level isolation i.e. running workloads in dedicated clusters, remains the strictest workload
+isolation mechanism, in spite of improvements mentioned earlier here and in the guide.
+
+## Network Separation and Hardening
+
+Kubernetes Networking can be tricky and this section focuses on how to secure
+and harden the relevant configurations. The guide identifies the following as key
+takeaways:
+- Using NetworkPolicies to create isolation between resources,
+- Securing the control plane
+- Encrypting traffic and sensitive data
+
+### Network Policies
+
+Network policies can be created with the help of network plugins. In order to
+make the creation and visualization easier for users, Cilium supports
+a [web GUI tool](https://editor.cilium.io). That web GUI lets you create Kubernetes
+NetworkPolicies (a generic API that nevertheless requires a compatible CNI plugin),
+and / or Cilium network policies (CiliumClusterwideNetworkPolicy and CiliumNetworkPolicy,
+which only work in clusters that use the Cilium CNI plugin).
+You can use these APIs to restrict network traffic between pods, and therefore minimize the
+attack vector.
+
+Another scenario that is worth exploring is the usage of external IPs. Some
+services, when misconfigured, can create random external IPs. An attacker can take
+advantage of this misconfiguration and easily intercept traffic. This vulnerability
+has been reported
+in [CVE-2020-8554](https://www.cvedetails.com/cve/CVE-2020-8554/).
+Using [externalip-webhook](https://github.com/kubernetes-sigs/externalip-webhook)
+can mitigate this vulnerability by preventing the services from using random
+external IPs. [externalip-webhook](https://github.com/kubernetes-sigs/externalip-webhook)
+only allows creation of services that don't require external IPs or whose
+external IPs are within the range specified by the administrator.
+
+> CVE-2020-8554 - Kubernetes API server in all versions allow an attacker
+> who is able to create a ClusterIP service and set the `spec.externalIPs` field,
+> to intercept traffic to that IP address. Additionally, an attacker who is able to
+> patch the `status` (which is considered a privileged operation and should not
+> typically be granted to users) of a LoadBalancer service can set the
+> `status.loadBalancer.ingress.ip` to similar effect.
+
+### Resource Policies
+
+In addition to configuring ResourceQuotas and limits, consider restricting how many process
+IDs (PIDs) a given Pod can use, and also to reserve some PIDs for node-level use to avoid
+resource exhaustion. More details to apply these limits can be
+found in [Process ID Limits And Reservations](/docs/concepts/policy/pid-limiting/).
+
+### Control Plane Hardening
+
+In the next section, the guide covers control plane hardening. It is worth
+noting that
+from [Kubernetes 1.20](https://github.com/kubernetes/kubernetes/issues/91506),
+insecure port from API server, has been removed.
+
+### Etcd
+
+As a general rule, the etcd server should be configured to only trust
+certificates assigned to the API server. It limits the attack surface and prevents a
+malicious attacker from gaining access to the cluster. It might be beneficial to
+use a separate CA for etcd, as it by default trusts all the certificates issued
+by the root CA.
+
+### Kubeconfig Files
+
+In addition to specifying the token and certificates directly, `.kubeconfig`
+supports dynamic retrieval of temporary tokens using auth provider plugins.
+Beware of the possibility of malicious
+shell [code execution](https://banzaicloud.com/blog/kubeconfig-security/) in a
+`kubeconfig` file. Once attackers gain access to the cluster, they can steal ssh
+keys/secrets or more.
+
+### Secrets
+Kubernetes [Secrets](/docs/concepts/configuration/secret/) is the native way of managing secrets as a Kubernetes
+API object. However, in some scenarios such as a desire to have a single source of truth for all app secrets, irrespective of whether they run on Kubernetes or not, secrets can be managed loosely coupled with
+Kubernetes and consumed by pods through side-cars or init-containers with minimal usage of Kubernetes Secrets API.
+
+[External secrets providers](https://github.com/external-secrets/kubernetes-external-secrets)
+and [csi-secrets-store](https://github.com/kubernetes-sigs/secrets-store-csi-driver)
+are some of these alternatives to Kubernetes Secrets
+
+## Log Auditing
+
+The NSA/CISA guidance stresses monitoring and alerting based on logs. The key points
+include logging at the host level, application level, and on the cloud. When
+running Kubernetes in production, it's important to understand who's
+responsible, and who's accountable, for each layer of logging.
+
+### Kubernetes API auditing
+
+One area that deserves more focus is what exactly should alert or be logged. The
+document outlines a sample policy in [Appendix L: Audit Policy](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=55) that logs all
+RequestResponse's including metadata and request / response bodies. While helpful for a demo, it may not be practical for production.
+
+Each organization needs to evaluate their
+own threat model and build an audit policy that complements or helps troubleshooting incident response. Think
+about how someone would attack your organization and what audit trail could identify it. Review more advanced options for tuning audit logs in the official [audit logging documentation](/docs/tasks/debug-application-cluster/audit/#audit-policy).
+It's crucial to tune your audit logs to only include events that meet your threat model. A minimal audit policy that logs everything at `metadata` level can also be a good starting point.
+
+Audit logging configurations can also be tested with
+kind following these [instructions](https://kind.sigs.k8s.io/docs/user/auditing).
+
+### Streaming logs and auditing
+
+Logging is important for threat and anomaly detection. As the document outlines,
+it's a best practice to scan and alert on logs as close to real time as possible
+and to protect logs from tampering if a compromise occurs. It's important to
+reflect on the various levels of logging and identify the critical areas such as
+API endpoints.
+
+Kubernetes API audit logging can stream to a webhook and there's an example in [Appendix N: Webhook configuration](https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF#page=58). Using a webhook could be a method that
+stores logs off cluster and/or centralizes all audit logs. Once logs are
+centrally managed, look to enable alerting based on critical events. Also ensure
+you understand what the baseline is for normal activities.
+
+### Alert identification
+
+While the guide stressed the importance of notifications, there is not a blanket
+event list to alert from. The alerting requirements vary based on your own
+requirements and threat model. Examples include the following events:
+
+- Changes to the `securityContext` of a Pod
+- Updates to admission controller configs
+- Accessing certain files / URLs
+
+### Additional logging resources
+
+- [Seccomp Security Profiles and You: A Practical Guide - Duffie Cooley](https://www.youtube.com/watch?v=OPuu8wsu2Zc)
+- [TGI Kubernetes 119: Gatekeeper and OPA](https://www.youtube.com/watch?v=ZJgaGJm9NJE)
+- [Abusing The Lack of Kubernetes Auditing Policies](https://www.lacework.com/blog/hiding-in-plaintext-sight-abusing-the-lack-of-kubernetes-auditing-policies/)
+- [Enable seccomp for all workloads with a new v1.22 alpha feature](https://kubernetes.io/blog/2021/08/25/seccomp-default/)
+- [This Week in Cloud Native: Auditing / Pod Security](https://www.twitch.tv/videos/1147889860)
+
+## Upgrading and Application Security practices
+
+Kubernetes releases three times per year, so upgrade-related toil is a common problem for
+people running production clusters. In addition to this, operators must
+regularly upgrade the underlying node's operating system and running
+applications. This is a best practice to ensure continued support and to reduce
+the likelihood of bugs or vulnerabilities.
+
+Kubernetes supports the three most recent stable releases. While each Kubernetes
+release goes through a large number of tests before being published, some
+teams aren't comfortable running the latest stable release until some time has
+passed. No matter what version you're running, ensure that patch upgrades
+happen frequently or automatically. More information can be found in
+the [version skew](/releases/version-skew-policy/) policy
+pages.
+
+When thinking about how you'll manage node OS upgrades, consider ephemeral
+nodes. Having the ability to destroy and add nodes allows your team to respond
+quicker to node issues. In addition, having deployments that tolerate node
+instability (and a culture that encourages frequent deployments) allows for
+easier cluster upgrades.
+
+Additionally, it's worth reiterating from the guidance that periodic
+vulnerability scans and penetration tests can be performed on the various system
+components to proactively look for insecure configurations and vulnerabilities.
+
+### Finding release & security information
+
+To find the most recent Kubernetes supported versions, refer to
+[https://k8s.io/releases](https://k8s.io/releases), which includes minor versions. It's good to stay up to date with
+your minor version patches.
+
+If you're running a managed Kubernetes offering, look for their release
+documentation and find their various security channels.
+
+Subscribe to
+the [Kubernetes Announce mailing list](https://groups.google.com/g/kubernetes-announce).
+The Kubernetes Announce mailing list is searchable for terms such
+as "[Security Advisories](https://groups.google.com/g/kubernetes-announce/search?q=%5BSecurity%20Advisory%5D)".
+You can set up alerts and email notifications as long as you know what key
+words to alert on.
+
+## Conclusion
+
+In summary, it is fantastic to see security practitioners sharing this
+level of detailed guidance in public. This guidance further highlights
+Kubernetes going mainstream and how securing Kubernetes clusters and the
+application containers running on Kubernetes continues to need attention and focus of
+practitioners. Only a few weeks after the guidance was published, an open source
+tool [kubescape](https://github.com/armosec/kubescape) to validate cluster
+against this guidance became available.
+
+This tool can be a great starting point to check the current state of your
+clusters, after which you can use the information in this blog post and in the guidance to assess
+where improvements can be made.
+
+Finally, it is worth reiterating that not all controls in this guidance will
+make sense for all practitioners. The best way to know which controls matter is
+to rely on the threat model of your own Kubernetes environment.
+
+_A special shout out and thanks to Rory McCune (@raesene) for his inputs to this blog post_
diff --git a/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md
new file mode 100644
index 0000000000..cd65d69f8b
--- /dev/null
+++ b/content/en/blog/_posts/2021-10-08-clusterclass-and-managed-topologies.md
@@ -0,0 +1,141 @@
+---
+layout: blog
+title: "Introducing ClusterClass and Managed Topologies in Cluster API"
+date: 2021-10-08
+slug: capi-clusterclass-and-managed-topologies
+---
+
+**Author:** Fabrizio Pandini (VMware)
+
+The [Cluster API community](https://cluster-api.sigs.k8s.io/) is happy to announce the implementation of *ClusterClass and Managed Topologies*, a new feature that will greatly simplify how you can provision, upgrade, and operate multiple Kubernetes clusters in a declarative way.
+
+## A little bit of context…
+
+Before getting into the details, let's take a step back and look at the history of Cluster API.
+
+The [Cluster API project](https://github.com/kubernetes-sigs/cluster-api/) started three years ago, and the first releases focused on extensibility and implementing a declarative API that allows a seamless experience across infrastructure providers. This was a success with many cloud providers: AWS, Azure, Digital Ocean, GCP, Metal3, vSphere and still counting.
+
+With extensibility addressed, the focus shifted to features, like automatic control plane and etcd management, health-based machine remediation, machine rollout strategies and more.
+
+Fast forwarding to 2021, with lots of companies using Cluster API to manage fleets of Kubernetes clusters running workloads in production, the community focused its effort on stabilization of both code, APIs, documentation, and on extensive test signals which inform Kubernetes releases.
+
+With solid foundations in place, and a vibrant and welcoming community that still continues to grow, it was time to plan another iteration on our UX for both new and advanced users.
+
+Enter ClusterClass and Managed Topologies, tada!
+
+## ClusterClass
+
+As the name suggests, ClusterClass and managed topologies are built in two parts.
+
+The idea behind ClusterClass is simple: define the shape of your cluster once, and reuse it many times, abstracting the complexities and the internals of a Kubernetes cluster away.
+
+
+
+ClusterClass, at its heart, is a collection of Cluster and Machine templates. You can use it as a “stamp” that can be leveraged to create many clusters of a similar shape.
+
+```yaml
+---
+apiVersion: cluster.x-k8s.io/v1beta1
+kind: ClusterClass
+metadata:
+ name: my-amazing-cluster-class
+spec:
+ controlPlane:
+ ref:
+ apiVersion: controlplane.cluster.x-k8s.io/v1beta1
+ kind: KubeadmControlPlaneTemplate
+ name: high-availability-control-plane
+ machineInfrastructure:
+ ref:
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerMachineTemplate
+ name: control-plane-machine
+ workers:
+ machineDeployments:
+ - class: type1-workers
+ template:
+ bootstrap:
+ ref:
+ apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
+ kind: KubeadmConfigTemplate
+ name: type1-bootstrap
+ infrastructure:
+ ref:
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerMachineTemplate
+ name: type1-machine
+ - class: type2-workers
+ template:
+ bootstrap:
+ ref:
+ apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
+ kind: KubeadmConfigTemplate
+ name: type2-bootstrap
+ infrastructure:
+ ref:
+ kind: DockerMachineTemplate
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ name: type2-machine
+ infrastructure:
+ ref:
+ apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
+ kind: DockerClusterTemplate
+ name: cluster-infrastructure
+
+```
+
+The possibilities are endless; you can get a default ClusterClass from the community, “off-the-shelf” classes from your vendor of choice, “certified” classes from the platform admin in your company, or even create custom ones for advanced scenarios.
+
+## Managed Topologies
+
+Managed Topologies let you put the power of ClusterClass into action.
+
+Given a ClusterClass, you can create many Clusters of a similar shape by providing a single resource, the Cluster.
+
+
+
+Here is an example:
+
+```yaml
+---
+apiVersion: cluster.x-k8s.io/v1beta1
+ kind: Cluster
+ metadata:
+ name: my-amazing-cluster
+ namespace: bar
+ spec:
+ topology: # define a managed topology
+ class: my-amazing-cluster-class # use the ClusterClass mentioned earlier
+ version: v1.21.2
+ controlPlane:
+ replicas: 3
+ workers:
+ machineDeployments:
+ - class: type1-workers
+ name: big-pool-of-machines
+ replicas: 5
+ - class: type2-workers
+ name: small-pool-of-machines
+ replicas: 1
+```
+
+But there is more than simplified cluster creation. Now the Cluster acts as a single control point for your entire topology.
+
+All the power of Cluster API, extensibility, lifecycle automation, stability, all the features required for managing an enterprise grade Kubernetes cluster on the infrastructure provider of your choice are now at your fingertips: you can create your Cluster, add new machines, upgrade to the next Kubernetes version, and all from a single place.
+
+It is just as simple as it looks!
+
+## What’s next
+
+While the amazing Cluster API community is working hard to deliver the first version of ClusterClass and managed topologies later this year, we are already looking forward to what comes next for the project and its ecosystem.
+
+There are a lot of great ideas and opportunities ahead!
+
+We want to make managed topologies even more powerful and flexible, allowing users to dynamically change bits of a ClusterClass according to the specific needs of a Cluster; this will ensure the same simple and intuitive UX for solving complex problems like e.g. selecting machine image for a specific Kubernetes version and for a specific region of your infrastructure provider, or injecting proxy configurations in the entire Cluster, and so on.
+
+Stay tuned for what comes next, and if you have any questions, comments or suggestions:
+
+* Chat with us on the Kubernetes [Slack](http://slack.k8s.io/):[#cluster-api](https://kubernetes.slack.com/archives/C8TSNPY4T)
+* Join the SIG Cluster Lifecycle [Google Group](https://groups.google.com/g/kubernetes-sig-cluster-lifecycle) to receive calendar invites and gain access to documents
+* Join our [Zoom meeting](https://zoom.us/j/861487554), every Wednesday at 10:00 Pacific Time
+* Check out the [ClusterClass tutorial](https://cluster-api.sigs.k8s.io/tasks/experimental-features/cluster-classes.html) in the Cluster API book.
\ No newline at end of file
diff --git a/content/en/blog/_posts/2021-10-18-kpng-specialized-proxiers.md b/content/en/blog/_posts/2021-10-18-kpng-specialized-proxiers.md
new file mode 100644
index 0000000000..2c60c12f3f
--- /dev/null
+++ b/content/en/blog/_posts/2021-10-18-kpng-specialized-proxiers.md
@@ -0,0 +1,241 @@
+---
+layout: blog
+title: "Use KPNG to Write Specialized kube-proxiers"
+date: 2021-10-18
+slug: use-kpng-to-write-specialized-kube-proxiers
+---
+
+**Author**: Lars Ekman (Ericsson)
+
+The post will show you how to create a specialized service kube-proxy
+style network proxier using Kubernetes Proxy NG
+[kpng](https://github.com/kubernetes-sigs/kpng) without interfering
+with the existing kube-proxy. The kpng project aims at renewing the
+the default Kubernetes Service implementation, the "kube-proxy". An
+important feature of kpng is that it can be used as a library to
+create proxiers outside K8s. While this is useful for CNI-plugins that
+replaces the kube-proxy it also opens the possibility for anyone to
+create a proxier for a special purpose.
+
+
+## Define a service that uses a specialized proxier
+
+```
+apiVersion: v1
+kind: Service
+metadata:
+ name: kpng-example
+ labels:
+ service.kubernetes.io/service-proxy-name: kpng-example
+spec:
+ clusterIP: None
+ ipFamilyPolicy: RequireDualStack
+ externalIPs:
+ - 10.0.0.55
+ - 1000::55
+ selector:
+ app: kpng-alpine
+ ports:
+ - port: 6000
+```
+
+If the `service.kubernetes.io/service-proxy-name` label is defined the
+`kube-proxy` will ignore the service. A custom controller can watch
+services with the label set to it's own name, "kpng-example" in
+this example, and setup specialized load-balancing.
+
+The `service.kubernetes.io/service-proxy-name` label is [not
+new](https://kubernetes.io/docs/reference/labels-annotations-taints/#servicekubernetesioservice-proxy-name),
+but so far is has been quite hard to write a specialized proxier.
+
+The common use for a specialized proxier is assumed to be handling
+external traffic for some use-case not supported by K8s. In that
+case `ClusterIP` is not needed, so we use a "headless" service in this
+example.
+
+
+## Specialized proxier using kpng
+
+A [kpng](https://github.com/kubernetes-sigs/kpng) based proxier
+consists of the `kpng` controller handling all the K8s api related
+functions, and a "backend" implementing the load-balancing. The
+backend can be linked with the `kpng` controller binary or be a
+separate program communicating with the controller using gRPC.
+
+```
+kpng kube --service-proxy-name=kpng-example to-api
+```
+
+This starts the `kpng` controller and tell it to watch only services
+with the "kpng-example" service proxy name. The "to-api" parameter
+will open a gRPC server for backends.
+
+You can test this yourself outside your cluster. Please see the example
+below.
+
+Now we start a backend that simply prints the updates from the
+controller.
+
+```
+$ kubectl apply -f kpng-example.yaml
+$ kpng-json | jq # (this is the backend)
+{
+ "Service": {
+ "Namespace": "default",
+ "Name": "kpng-example",
+ "Type": "ClusterIP",
+ "IPs": {
+ "ClusterIPs": {},
+ "ExternalIPs": {
+ "V4": [
+ "10.0.0.55"
+ ],
+ "V6": [
+ "1000::55"
+ ]
+ },
+ "Headless": true
+ },
+ "Ports": [
+ {
+ "Protocol": 1,
+ "Port": 6000,
+ "TargetPort": 6000
+ }
+ ]
+ },
+ "Endpoints": [
+ {
+ "IPs": {
+ "V6": [
+ "1100::202"
+ ]
+ },
+ "Local": true
+ },
+ {
+ "IPs": {
+ "V4": [
+ "11.0.2.2"
+ ]
+ },
+ "Local": true
+ },
+ {
+ "IPs": {
+ "V4": [
+ "11.0.1.2"
+ ]
+ }
+ },
+ {
+ "IPs": {
+ "V6": [
+ "1100::102"
+ ]
+ }
+ }
+ ]
+}
+```
+
+A real backend would use some mechanism to load-balance traffic from
+the external IPs to the endpoints.
+
+
+
+## Writing a backend
+
+The `kpng-json` backend looks like this:
+
+```go
+package main
+import (
+ "os"
+ "encoding/json"
+ "sigs.k8s.io/kpng/client"
+)
+func main() {
+ client.Run(jsonPrint)
+}
+func jsonPrint(items []*client.ServiceEndpoints) {
+ enc := json.NewEncoder(os.Stdout)
+ for _, item := range items {
+ _ = enc.Encode(item)
+ }
+}
+```
+
+(yes, that is the entire program)
+
+A real backend would of course be much more complex, but this
+illustrates how `kpng` let you focus on load-balancing.
+
+You can have several backends connected to a `kpng` controller, so
+during development or debug it can be useful to let something like the
+`kpng-json` backend run in parallel with your real backend.
+
+
+## Example
+
+
+The complete example can be found [here](https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec).
+
+As an example we implement an "all-ip" backend. It direct all traffic
+for the externalIPs to a local endpoint, regardless of ports and upper
+layer protocols. There is a
+[KEP](https://github.com/kubernetes/enhancements/pull/2611) for this
+function and this example is a much simplified version.
+
+To direct all traffic from an external address to a local POD [only
+one iptables rule is
+needed](https://github.com/kubernetes/enhancements/pull/2611#issuecomment-895061013),
+for instance;
+
+```
+ip6tables -t nat -A PREROUTING -d 1000::55/128 -j DNAT --to-destination 1100::202
+```
+
+As you can see the addresses are in the call to the backend and all it
+have to do is:
+
+* Extract the addresses with `Local: true`
+* Setup iptables rules for the `ExternalIPs`
+
+A script doing that may look like:
+
+```
+xip=$(cat /tmp/out | jq -r .Service.IPs.ExternalIPs.V6[0])
+podip=$(cat /tmp/out | jq -r '.Endpoints[]|select(.Local == true)|select(.IPs.V6 != null)|.IPs.V6[0]')
+ip6tables -t nat -A PREROUTING -d $xip/128 -j DNAT --to-destination $podip
+```
+
+Assuming the JSON output above is stored in `/tmp/out` ([jq](https://stedolan.github.io/jq/) is an *awesome* program!).
+
+
+As this is an example we make it really simple for ourselves by using
+a minor variation of the `kpng-json` backend above. Instead of just
+printing, a program is called and the JSON output is passed as `stdin`
+to that program. The backend can be tested stand-alone:
+
+```
+CALLOUT=jq kpng-callout
+```
+
+Where `jq` can be replaced with your own program or script. A script
+may look like the example above. For more info and the complete
+example please see [https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec](https://github.com/kubernetes-sigs/kpng/tree/master/examples/pipe-exec).
+
+
+## Summary
+
+While [kpng](https://github.com/kubernetes-sigs/kpng) is in early
+stage of development this post wants to show how you may build your
+own specialized K8s proxiers in the future. The only thing your
+applications need to do is to add the
+`service.kubernetes.io/service-proxy-name` label in the Service
+manifest.
+
+It is a tedious process to get new features into the `kube-proxy` and
+it is not unlikely that they will be rejected, so to write a
+specialized proxier may be the only option.
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index 3a86a26e98..d8fec56d9d 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -145,7 +145,7 @@ Coil operates with a low overhead compared to bare metal, and allows you to defi
### Contiv
-[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases. [Contiv](https://contiv.io) is all open sourced.
+[Contiv](https://github.com/contiv/netplugin) provides configurable networking (native l3 using BGP, overlay using vxlan, classic l2, or Cisco-SDN/ACI) for various use cases.
### Contrail / Tungsten Fabric
@@ -248,7 +248,7 @@ Lars Kellogg-Stedman.
[Multus](https://github.com/Intel-Corp/multus-cni) is a Multi CNI plugin to support the Multi Networking feature in Kubernetes using CRD based network objects in Kubernetes.
-Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
+Multus supports all [reference plugins](https://github.com/containernetworking/plugins) (eg. [Flannel](https://github.com/containernetworking/cni.dev/blob/main/content/plugins/v0.9/meta/flannel.md), [DHCP](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/dhcp), [Macvlan](https://github.com/containernetworking/plugins/tree/master/plugins/main/macvlan)) that implement the CNI specification and 3rd party plugins (eg. [Calico](https://github.com/projectcalico/cni-plugin), [Weave](https://github.com/weaveworks/weave), [Cilium](https://github.com/cilium/cilium), [Contiv](https://github.com/contiv/netplugin)). In addition to it, Multus supports [SRIOV](https://github.com/hustcat/sriov-cni), [DPDK](https://github.com/Intel-Corp/sriov-cni), [OVS-DPDK & VPP](https://github.com/intel/vhost-user-net-plugin) workloads in Kubernetes with both cloud native and NFV based applications in Kubernetes.
### OVN4NFV-K8s-Plugin (OVN based CNI controller & plugin)
@@ -260,12 +260,6 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
-### Nuage Networks VCS (Virtualized Cloud Services)
-
-[Nuage](https://www.nuagenetworks.net) provides a highly scalable policy-based Software-Defined Networking (SDN) platform. Nuage uses the open source Open vSwitch for the data plane along with a feature rich SDN Controller built on open standards.
-
-The Nuage platform uses overlays to provide seamless policy-based networking between Kubernetes Pods and non-Kubernetes environments (VMs and bare metal servers). Nuage's policy abstraction model is designed with applications in mind and makes it easy to declare fine-grained policies for applications.The platform's real-time analytics engine enables visibility and security monitoring for Kubernetes applications.
-
### OpenVSwitch
[OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also
diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md
index e1c7dfb79b..2f630be2b9 100644
--- a/content/en/docs/concepts/configuration/secret.md
+++ b/content/en/docs/concepts/configuration/secret.md
@@ -212,7 +212,8 @@ to create a Docker registry Secret, you can do:
kubectl create secret docker-registry secret-tiger-docker \
--docker-username=tiger \
--docker-password=pass113 \
- --docker-email=tiger@acme.com
+ --docker-email=tiger@acme.com \
+ --docker-server=my-registry.example:5000
```
This command creates a Secret of type `kubernetes.io/dockerconfigjson`.
@@ -222,15 +223,21 @@ on the fly:
```json
{
- "auths": {
- "https://index.docker.io/v1/": {
- "username": "tiger",
- "password": "pass113",
- "email": "tiger@acme.com",
- "auth": "dGlnZXI6cGFzczExMw=="
- }
- }
+ "apiVersion": "v1",
+ "data": {
+ ".dockerconfigjson": "eyJhdXRocyI6eyJteS1yZWdpc3RyeTo1MDAwIjp7InVzZXJuYW1lIjoidGlnZXIiLCJwYXNzd29yZCI6InBhc3MxMTMiLCJlbWFpbCI6InRpZ2VyQGFjbWUuY29tIiwiYXV0aCI6ImRHbG5aWEk2Y0dGemN6RXhNdz09In19fQ=="
+ },
+ "kind": "Secret",
+ "metadata": {
+ "creationTimestamp": "2021-07-01T07:30:59Z",
+ "name": "secret-tiger-docker",
+ "namespace": "default",
+ "resourceVersion": "566718",
+ "uid": "e15c1d7b-9071-4100-8681-f3a7a2ce89ca"
+ },
+ "type": "kubernetes.io/dockerconfigjson"
}
+
```
### Basic authentication Secret
diff --git a/content/en/docs/concepts/containers/images.md b/content/en/docs/concepts/containers/images.md
index 9300561e46..5dfd349f80 100644
--- a/content/en/docs/concepts/containers/images.md
+++ b/content/en/docs/concepts/containers/images.md
@@ -108,7 +108,7 @@ When you (or a controller) submit a new Pod to the API server, your cluster sets
`:latest`, `imagePullPolicy` is automatically set to `Always`;
- if you omit the `imagePullPolicy` field, and you don't specify the tag for the
container image, `imagePullPolicy` is automatically set to `Always`;
-- if you omit the `imagePullPolicy` field, and you don't specify the tag for the
+- if you omit the `imagePullPolicy` field, and you specify the tag for the
container image that isn't `:latest`, the `imagePullPolicy` is automatically set to
`IfNotPresent`.
diff --git a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
index 3d72f279b6..b3fa73e5f0 100644
--- a/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
+++ b/content/en/docs/concepts/extend-kubernetes/api-extension/custom-resources.md
@@ -35,11 +35,11 @@ On their own, custom resources let you store and retrieve structured data.
When you combine a custom resource with a *custom controller*, custom resources
provide a true _declarative API_.
-A [declarative API](/docs/concepts/overview/kubernetes-api/)
-allows you to _declare_ or specify the desired state of your resource and tries to
-keep the current state of Kubernetes objects in sync with the desired state.
-The controller interprets the structured data as a record of the user's
-desired state, and continually maintains this state.
+The Kubernetes [declarative API](/docs/concepts/overview/kubernetes-api/)
+enforces a separation of responsibilities. You declare the desired state of
+your resource. The Kubernetes controller keeps the current state of Kubernetes
+objects in sync with your declared desired state. This is in contrast to an
+imperative API, where you *instruct* a server what to do.
You can deploy and update a custom controller on a running cluster, independently
of the cluster's lifecycle. Custom controllers can work with any kind of resource,
diff --git a/content/en/docs/concepts/overview/components.md b/content/en/docs/concepts/overview/components.md
index 6c5c0eefa1..fb3997b283 100644
--- a/content/en/docs/concepts/overview/components.md
+++ b/content/en/docs/concepts/overview/components.md
@@ -19,11 +19,7 @@ When you deploy Kubernetes, you get a cluster.
This document outlines the various components you need to have for
a complete and working Kubernetes cluster.
-Here's the diagram of a Kubernetes cluster with all the components tied together.
-
-
-
-
+{{< figure src="/images/docs/components-of-kubernetes.svg" alt="Components of Kubernetes" caption="The components of a Kubernetes cluster" class="diagram-large" >}}
## Control Plane Components
diff --git a/content/en/docs/concepts/overview/working-with-objects/finalizers.md b/content/en/docs/concepts/overview/working-with-objects/finalizers.md
index 9516b935c9..fdec67b220 100644
--- a/content/en/docs/concepts/overview/working-with-objects/finalizers.md
+++ b/content/en/docs/concepts/overview/working-with-objects/finalizers.md
@@ -44,7 +44,8 @@ and the controller deletes the volume.
## Owner references, labels, and finalizers {#owners-labels-finalizers}
-Like {{}}, [owner references](/concepts/overview/working-with-objects/owners-dependents/)
+Like {{}},
+[owner references](/docs/concepts/overview/working-with-objects/owners-dependents/)
describe the relationships between objects in Kubernetes, but are used for a
different purpose. When a
{{}} manages objects
diff --git a/content/en/docs/concepts/overview/working-with-objects/namespaces.md b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
index 6664a2ad4c..3a8d8da168 100644
--- a/content/en/docs/concepts/overview/working-with-objects/namespaces.md
+++ b/content/en/docs/concepts/overview/working-with-objects/namespaces.md
@@ -10,8 +10,7 @@ weight: 30
-Kubernetes supports multiple virtual clusters backed by the same physical cluster.
-These virtual clusters are called namespaces.
+In Kubernetes, _namespaces_ provides a mechanism for isolating groups of resources within a single cluster. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
diff --git a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
index e08052c017..52db68bf3d 100644
--- a/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
+++ b/content/en/docs/concepts/scheduling-eviction/scheduling-framework.md
@@ -52,7 +52,7 @@ equivalent to "Predicate" and "Scoring" is equivalent to "Priority function".
One plugin may register at multiple extension points to perform more complex or
stateful tasks.
-{{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" >}}
+{{< figure src="/images/docs/scheduling-framework-extensions.png" title="scheduling framework extension points" class="diagram-large">}}
### QueueSort {#queue-sort}
diff --git a/content/en/docs/concepts/security/overview.md b/content/en/docs/concepts/security/overview.md
index ce75653dfd..0028f873b4 100644
--- a/content/en/docs/concepts/security/overview.md
+++ b/content/en/docs/concepts/security/overview.md
@@ -29,7 +29,7 @@ computing approach to security, which is widely regarded as a best practice for
software systems.
{{< /note >}}
-{{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" >}}
+{{< figure src="/images/docs/4c.png" title="The 4C's of Cloud Native Security" class="diagram-large" >}}
Each layer of the Cloud Native security model builds upon the next outermost layer.
The Code layer benefits from strong base (Cloud, Cluster, Container) security layers.
@@ -60,6 +60,7 @@ Amazon Web Services | https://aws.amazon.com/security/ |
Google Cloud Platform | https://cloud.google.com/security/ |
IBM Cloud | https://www.ibm.com/cloud/security |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
+Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
{{< /table >}}
diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md
index f43eeff22b..f1a085176e 100644
--- a/content/en/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/en/docs/concepts/services-networking/dns-pod-service.md
@@ -217,13 +217,13 @@ following pod-specific DNS policies. These policies are specified in the
- "`Default`": The Pod inherits the name resolution configuration from the node
that the pods run on.
- See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node)
+ See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
for more details.
- "`ClusterFirst`": Any DNS query that does not match the configured cluster
domain suffix, such as "`www.kubernetes.io`", is forwarded to the upstream
nameserver inherited from the node. Cluster administrators may have extra
stub-domain and upstream DNS servers configured.
- See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers/#effects-on-pods)
+ See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers)
for details on how DNS queries are handled in those cases.
- "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should
explicitly set its DNS policy "`ClusterFirstWithHostNet`".
diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md
index e3f3a203b7..108c2be59b 100644
--- a/content/en/docs/concepts/services-networking/network-policies.md
+++ b/content/en/docs/concepts/services-networking/network-policies.md
@@ -261,7 +261,7 @@ The following restrictions apply when using this field:
at a cluster level, you (or your cluster administrator) need to disable the
`NetworkPolicyEndPort` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
for the API server with `--feature-gates=NetworkPolicyEndPort=false,…`.
-* The `endPort` field must be equal than or greater to the `port` field.
+* The `endPort` field must be equal to or greater than the `port` field.
* `endPort` can only be defined if `port` is also defined.
* Both ports must be numeric.
diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md
index db28918c98..4f8eb45f38 100644
--- a/content/en/docs/concepts/services-networking/service.md
+++ b/content/en/docs/concepts/services-networking/service.md
@@ -183,6 +183,13 @@ Accessing a Service without a selector works the same as if it had a selector.
In the example above, traffic is routed to the single endpoint defined in
the YAML: `192.0.2.42:9376` (TCP).
+{{< note >}}
+The Kubernetes API server does not allow proxying to endpoints that are not mapped to
+pods. Actions such as `kubectl proxy ` where the service has no
+selector will fail due to this constraint. This prevents the Kubernetes API server
+from being used as a proxy to endpoints the caller may not be authorized to access.
+{{< /note >}}
+
An ExternalName Service is a special case of Service that does not have
selectors and uses DNS names instead. For more information, see the
[ExternalName](#externalname) section later in this document.
@@ -414,7 +421,7 @@ endpoints, the kube-proxy does not forward any traffic for the relevant Service.
{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
If you enable the `ProxyTerminatingEndpoints`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
-`ProxyTerminatingEndpoints` for the kube-proxy, the kube-proxy checks if the node
+for the kube-proxy, the kube-proxy checks if the node
has local endpoints and whether or not all the local endpoints are marked as terminating.
If there are local endpoints and **all** of those are terminating, then the kube-proxy ignores
any external traffic policy of `Local`. Instead, whilst the node-local endpoints remain as all
@@ -1065,6 +1072,9 @@ in those modified security groups.
{{< /note >}}
+Further documentation on annotations for Elastic IPs and other common use-cases may be found
+in the [AWS Load Balancer Controller documentation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/service/annotations/).
+
#### Other CLB annotations on Tencent Kubernetes Engine (TKE)
There are other annotations for managing Cloud Load Balancers on TKE as shown below.
@@ -1121,7 +1131,7 @@ spec:
```
{{< note >}}
-ExternalName accepts an IPv4 address string, but as a DNS names comprised of digits, not as an IP address. ExternalNames that resemble IPv4 addresses are not resolved by CoreDNS or ingress-nginx because ExternalName
+ExternalName accepts an IPv4 address string, but as a DNS name comprised of digits, not as an IP address. ExternalNames that resemble IPv4 addresses are not resolved by CoreDNS or ingress-nginx because ExternalName
is intended to specify a canonical DNS name. To hardcode an IP address, consider using
[headless Services](#headless-services).
{{< /note >}}
diff --git a/content/en/docs/concepts/storage/ephemeral-volumes.md b/content/en/docs/concepts/storage/ephemeral-volumes.md
index e76f76f492..1e811fb82a 100644
--- a/content/en/docs/concepts/storage/ephemeral-volumes.md
+++ b/content/en/docs/concepts/storage/ephemeral-volumes.md
@@ -146,7 +146,7 @@ features:
parameters.
- Typical operations on volumes are supported assuming that the driver
supports them, including
- ([snapshotting](/docs/concepts/storage/volume-snapshots/),
+ [snapshotting](/docs/concepts/storage/volume-snapshots/),
[cloning](/docs/concepts/storage/volume-pvc-datasource/),
[resizing](/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims),
and [storage capacity tracking](/docs/concepts/storage/storage-capacity/).
diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md
index a029ceaeda..f2093073df 100644
--- a/content/en/docs/concepts/storage/persistent-volumes.md
+++ b/content/en/docs/concepts/storage/persistent-volumes.md
@@ -131,7 +131,9 @@ The `Retain` reclaim policy allows for manual reclamation of the resource. When
1. Delete the PersistentVolume. The associated storage asset in external infrastructure (such as an AWS EBS, GCE PD, Azure Disk, or Cinder volume) still exists after the PV is deleted.
1. Manually clean up the data on the associated storage asset accordingly.
-1. Manually delete the associated storage asset, or if you want to reuse the same storage asset, create a new PersistentVolume with the storage asset definition.
+1. Manually delete the associated storage asset.
+
+If you want to reuse the same storage asset, create a new PersistentVolume with the same storage asset definition.
#### Delete
@@ -412,11 +414,22 @@ A PersistentVolume can be mounted on a host in any way supported by the resource
The access modes are:
-* ReadWriteOnce -- the volume can be mounted as read-write by a single node
-* ReadOnlyMany -- the volume can be mounted read-only by many nodes
-* ReadWriteMany -- the volume can be mounted as read-write by many nodes
-* ReadWriteOncePod -- the volume can be mounted as read-write by a single Pod.
- This is only supported for CSI volumes and Kubernetes version 1.22+.
+`ReadWriteOnce`
+: the volume can be mounted as read-write by a single node. ReadWriteOnce access mode still can allow multiple pods to access the volume when the pods are running on the same node.
+
+`ReadOnlyMany`
+: the volume can be mounted as read-only by many nodes.
+
+`ReadWriteMany`
+: the volume can be mounted as read-write by many nodes.
+
+ `ReadWriteOncePod`
+: the volume can be mounted as read-write by a single Pod. Use ReadWriteOncePod access mode if you want to ensure that only one pod across whole cluster can read that PVC or write to it. This is only supported for CSI volumes and Kubernetes version 1.22+.
+
+
+
+The blog article [Introducing Single Pod Access Mode for PersistentVolumes](/blog/2021/09/13/read-write-once-pod-access-mode-alpha/) covers this in more detail.
+
In the CLI, the access modes are abbreviated to:
diff --git a/content/en/docs/concepts/workloads/controllers/cron-jobs.md b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
index 95a58dfc83..0e95f72011 100644
--- a/content/en/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/en/docs/concepts/workloads/controllers/cron-jobs.md
@@ -136,11 +136,16 @@ and set this flag to `false`. For example:
## {{% heading "whatsnext" %}}
-[Cron expression format](https://en.wikipedia.org/wiki/Cron)
-documents the format of CronJob `schedule` fields.
-
-For instructions on creating and working with cron jobs, and for an example of CronJob
-manifest, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
-
-For instructions to clean up failed or completed jobs automatically, see
-[Clean up Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
+* Learn about [Pods](/docs/concepts/workloads/pods/) and
+ [Jobs](/docs/concepts/workloads/controllers/job/), two concepts
+ that CronJobs rely upon.
+* Read about the [format](https://pkg.go.dev/github.com/robfig/cron/v3#hdr-CRON_Expression_Format)
+ of CronJob `.spec.schedule` fields.
+* For instructions on creating and working with CronJobs, and for an example
+ of a CronJob manifest,
+ see [Running automated tasks with CronJobs](/docs/tasks/job/automated-tasks-with-cron-jobs/).
+* For instructions to clean up failed or completed jobs automatically,
+ see [Clean up Jobs automatically](/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically)
+* `CronJob` is part of the Kubernetes REST API.
+ Read the {{< api-reference page="workload-resources/cron-job-v1" >}}
+ object definition to understand the API for Kubernetes cron jobs.
diff --git a/content/en/docs/concepts/workloads/controllers/daemonset.md b/content/en/docs/concepts/workloads/controllers/daemonset.md
index df3c4bdd8d..7eec771d7d 100644
--- a/content/en/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/en/docs/concepts/workloads/controllers/daemonset.md
@@ -235,3 +235,18 @@ all or certain hosts, if the DaemonSet provides node-level functionality that al
For example, [network plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) often include a component that runs as a DaemonSet. The DaemonSet component makes sure that the node where it's running has working cluster networking.
+## {{% heading "whatsnext" %}}
+
+* Learn about [Pods](/docs/concepts/workloads/pods).
+ * Learn about [static Pods](#static-pods), which are useful for running Kubernetes
+ {{< glossary_tooltip text="control plane" term_id="control-plane" >}} components.
+* Find out how to use DaemonSets
+ * [Perform a rolling update on a DaemonSet](/docs/tasks/manage-daemon/update-daemon-set/)
+ * [Perform a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
+ (for example, if a roll out didn't work how you expected).
+* Understand [how Kubernetes assigns Pods to Nodes](/docs/concepts/scheduling-eviction/assign-pod-node/).
+* Learn about [device plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) and
+ [add ons](/docs/concepts/cluster-administration/addons/), which often run as DaemonSets.
+* `DaemonSet` is a top-level resource in the Kubernetes REST API.
+ Read the {{< api-reference page="workload-resources/daemon-set-v1" >}}
+ object definition to understand the API for daemon sets.
diff --git a/content/en/docs/concepts/workloads/controllers/deployment.md b/content/en/docs/concepts/workloads/controllers/deployment.md
index 22b95255c5..838cb191a8 100644
--- a/content/en/docs/concepts/workloads/controllers/deployment.md
+++ b/content/en/docs/concepts/workloads/controllers/deployment.md
@@ -75,11 +75,6 @@ Follow the steps given below to create the above Deployment:
kubectl apply -f https://k8s.io/examples/controllers/nginx-deployment.yaml
```
- {{< note >}}
- You can specify the `--record` flag to write the command executed in the resource annotation `kubernetes.io/change-cause`.
- The recorded change is useful for future introspection. For example, to see the commands executed in each Deployment revision.
- {{< /note >}}
-
2. Run `kubectl get deployments` to check if the Deployment was created.
@@ -169,13 +164,13 @@ Follow the steps given below to update your Deployment:
1. Let's update the nginx Pods to use the `nginx:1.16.1` image instead of the `nginx:1.14.2` image.
```shell
- kubectl --record deployment.apps/nginx-deployment set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+ kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
```
or use the following command:
```shell
- kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1 --record
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
The output is similar to:
@@ -187,7 +182,7 @@ Follow the steps given below to update your Deployment:
Alternatively, you can `edit` the Deployment and change `.spec.template.spec.containers[0].image` from `nginx:1.14.2` to `nginx:1.16.1`:
```shell
- kubectl edit deployment.v1.apps/nginx-deployment
+ kubectl edit deployment/nginx-deployment
```
The output is similar to:
@@ -370,7 +365,7 @@ rolled back.
* Suppose that you made a typo while updating the Deployment, by putting the image name as `nginx:1.161` instead of `nginx:1.16.1`:
```shell
- kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
The output is similar to this:
@@ -479,26 +474,25 @@ Follow the steps given below to check the rollout history:
1. First, check the revisions of this Deployment:
```shell
- kubectl rollout history deployment.v1.apps/nginx-deployment
+ kubectl rollout history deployment/nginx-deployment
```
The output is similar to this:
```
deployments "nginx-deployment"
REVISION CHANGE-CAUSE
- 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml --record=true
- 2 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
- 3 kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.161 --record=true
+ 1 kubectl apply --filename=https://k8s.io/examples/controllers/nginx-deployment.yaml
+ 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
+ 3 kubectl set image deployment/nginx-deployment nginx=nginx:1.161
```
`CHANGE-CAUSE` is copied from the Deployment annotation `kubernetes.io/change-cause` to its revisions upon creation. You can specify the`CHANGE-CAUSE` message by:
- * Annotating the Deployment with `kubectl annotate deployment.v1.apps/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"`
- * Append the `--record` flag to save the `kubectl` command that is making changes to the resource.
+ * Annotating the Deployment with `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"`
* Manually editing the manifest of the resource.
2. To see the details of each revision, run:
```shell
- kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
+ kubectl rollout history deployment/nginx-deployment --revision=2
```
The output is similar to this:
@@ -506,7 +500,7 @@ Follow the steps given below to check the rollout history:
deployments "nginx-deployment" revision 2
Labels: app=nginx
pod-template-hash=1159050644
- Annotations: kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+ Annotations: kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Containers:
nginx:
Image: nginx:1.16.1
@@ -523,7 +517,7 @@ Follow the steps given below to rollback the Deployment from the current version
1. Now you've decided to undo the current rollout and rollback to the previous revision:
```shell
- kubectl rollout undo deployment.v1.apps/nginx-deployment
+ kubectl rollout undo deployment/nginx-deployment
```
The output is similar to this:
@@ -533,7 +527,7 @@ Follow the steps given below to rollback the Deployment from the current version
Alternatively, you can rollback to a specific revision by specifying it with `--to-revision`:
```shell
- kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
+ kubectl rollout undo deployment/nginx-deployment --to-revision=2
```
The output is similar to this:
@@ -567,7 +561,7 @@ Follow the steps given below to rollback the Deployment from the current version
CreationTimestamp: Sun, 02 Sep 2018 18:17:55 -0500
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision=4
- kubernetes.io/change-cause=kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1 --record=true
+ kubernetes.io/change-cause=kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
Selector: app=nginx
Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType: RollingUpdate
@@ -610,7 +604,7 @@ Follow the steps given below to rollback the Deployment from the current version
You can scale a Deployment by using the following command:
```shell
-kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
+kubectl scale deployment/nginx-deployment --replicas=10
```
The output is similar to this:
```
@@ -622,7 +616,7 @@ in your cluster, you can setup an autoscaler for your Deployment and choose the
Pods you want to run based on the CPU utilization of your existing Pods.
```shell
-kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
+kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
```
The output is similar to this:
```
@@ -651,7 +645,7 @@ For example, you are running a Deployment with 10 replicas, [maxSurge](#max-surg
* You update to a new image which happens to be unresolvable from inside the cluster.
```shell
- kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:sometag
+ kubectl set image deployment/nginx-deployment nginx=nginx:sometag
```
The output is similar to this:
@@ -730,7 +724,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* Pause by running the following command:
```shell
- kubectl rollout pause deployment.v1.apps/nginx-deployment
+ kubectl rollout pause deployment/nginx-deployment
```
The output is similar to this:
@@ -740,7 +734,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* Then update the image of the Deployment:
```shell
- kubectl set image deployment.v1.apps/nginx-deployment nginx=nginx:1.16.1
+ kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
```
The output is similar to this:
@@ -750,7 +744,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* Notice that no new rollout started:
```shell
- kubectl rollout history deployment.v1.apps/nginx-deployment
+ kubectl rollout history deployment/nginx-deployment
```
The output is similar to this:
@@ -772,7 +766,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* You can make as many updates as you wish, for example, update the resources that will be used:
```shell
- kubectl set resources deployment.v1.apps/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
+ kubectl set resources deployment/nginx-deployment -c=nginx --limits=cpu=200m,memory=512Mi
```
The output is similar to this:
@@ -785,7 +779,7 @@ apply multiple fixes in between pausing and resuming without triggering unnecess
* Eventually, resume the Deployment and observe a new ReplicaSet coming up with all the new updates:
```shell
- kubectl rollout resume deployment.v1.apps/nginx-deployment
+ kubectl rollout resume deployment/nginx-deployment
```
The output is similar to this:
@@ -895,7 +889,7 @@ The following `kubectl` command sets the spec with `progressDeadlineSeconds` to
lack of progress for a Deployment after 10 minutes:
```shell
-kubectl patch deployment.v1.apps/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
+kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
```
The output is similar to this:
```
@@ -1056,7 +1050,7 @@ A Deployment also needs a [`.spec` section](https://git.k8s.io/community/contrib
### Pod Template
-The `.spec.template` and `.spec.selector` are the only required field of the `.spec`.
+The `.spec.template` and `.spec.selector` are the only required fields of the `.spec`.
The `.spec.template` is a [Pod template](/docs/concepts/workloads/pods/#pod-templates). It has exactly the same schema as a {{< glossary_tooltip text="Pod" term_id="pod" >}}, except it is nested and does not have an `apiVersion` or `kind`.
@@ -1176,4 +1170,12 @@ a paused Deployment and one that is not paused, is that any changes into the Pod
Deployment will not trigger new rollouts as long as it is paused. A Deployment is not paused by default when
it is created.
+## {{% heading "whatsnext" %}}
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* [Run a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
+* `Deployment` is a top-level resource in the Kubernetes REST API.
+ Read the {{< api-reference page="workload-resources/deployment-v1" >}}
+ object definition to understand the API for deployments.
+* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
+ you can use it to manage application availability during disruptions.
diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md
index 9741db057e..54a4104c5e 100644
--- a/content/en/docs/concepts/workloads/controllers/job.md
+++ b/content/en/docs/concepts/workloads/controllers/job.md
@@ -25,6 +25,9 @@ due to a node hardware failure or a node reboot).
You can also use a Job to run multiple Pods in parallel.
+If you want to run a Job (either a single task, or several in parallel) on a schedule,
+see [CronJob](/docs/concepts/workloads/controllers/cron-jobs/).
+
## Running an example Job
@@ -204,6 +207,7 @@ Jobs with _fixed completion count_ - that is, jobs that have non null
{{< glossary_tooltip term_id="Service" >}}, Pods within the Job can use
the deterministic hostnames to address each other via DNS.
- From the containarized task, in the environment variable `JOB_COMPLETION_INDEX`.
+
The Job is considered complete when there is one successfully completed Pod
for each index. For more information about how to use this mode, see
[Indexed Job for Parallel Processing with Static Work Assignment](/docs/tasks/job/indexed-parallel-processing-static/).
@@ -638,6 +642,19 @@ driver, and then cleans up.
An advantage of this approach is that the overall process gets the completion guarantee of a Job
object, but maintains complete control over what Pods are created and how work is assigned to them.
-## Cron Jobs {#cron-jobs}
+## {{% heading "whatsnext" %}}
-You can use a [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/) to create a Job that will run at specified times/dates, similar to the Unix tool `cron`.
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Read about different ways of running Jobs:
+ * [Coarse Parallel Processing Using a Work Queue](/docs/tasks/job/coarse-parallel-processing-work-queue/)
+ * [Fine Parallel Processing Using a Work Queue](/docs/tasks/job/fine-parallel-processing-work-queue/)
+ * Use an [indexed Job for parallel processing with static work assignment](/docs/tasks/job/indexed-parallel-processing-static/) (beta)
+ * Create multiple Jobs based on a template: [Parallel Processing using Expansions](/docs/tasks/job/parallel-processing-expansion/)
+* Follow the links within [Clean up finished jobs automatically](#clean-up-finished-jobs-automatically)
+ to learn more about how your cluster can clean up completed and / or failed tasks.
+* `Job` is part of the Kubernetes REST API.
+ Read the {{< api-reference page="workload-resources/job-v1" >}}
+ object definition to understand the API for jobs.
+* Read about [`CronJob`](/docs/concepts/workloads/controllers/cron-jobs/), which you
+ can use to define a series of Jobs that will run based on a schedule, similar to
+ the Unix tool `cron`.
diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md
index e7b36d1b4a..70967853e8 100644
--- a/content/en/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/en/docs/concepts/workloads/controllers/replicaset.md
@@ -410,3 +410,14 @@ selector requirements as described in the [labels user guide](/docs/concepts/ove
As such, ReplicaSets are preferred over ReplicationControllers
+## {{% heading "whatsnext" %}}
+
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Learn about [Deployments](/docs/concepts/workloads/controllers/deployment/).
+* [Run a Stateless Application Using a Deployment](/docs/tasks/run-application/run-stateless-application-deployment/),
+ which relies on ReplicaSets to work.
+* `ReplicaSet` is a top-level resource in the Kubernetes REST API.
+ Read the {{< api-reference page="workload-resources/replica-set-v1" >}}
+ object definition to understand the API for replica sets.
+* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
+ you can use it to manage application availability during disruptions.
diff --git a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
index 5a10271b01..d07ecee16c 100644
--- a/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
+++ b/content/en/docs/concepts/workloads/controllers/replicationcontroller.md
@@ -248,7 +248,7 @@ The ReplicationController ensures that the desired number of pods matches its la
The ReplicationController is forever constrained to this narrow responsibility. It itself will not perform readiness nor liveness probes. Rather than performing auto-scaling, it is intended to be controlled by an external auto-scaler (as discussed in [#492](https://issue.k8s.io/492)), which would change its `replicas` field. We will not add scheduling policies (for example, [spreading](https://issue.k8s.io/367#issuecomment-48428019)) to the ReplicationController. Nor should it verify that the pods controlled match the currently specified template, as that would obstruct auto-sizing and other automated processes. Similarly, completion deadlines, ordering dependencies, configuration expansion, and other features belong elsewhere. We even plan to factor out the mechanism for bulk pod creation ([#170](https://issue.k8s.io/170)).
-The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](https://techblog.netflix.com/2012/06/asgard-web-based-cloud-management-and.html) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
+The ReplicationController is intended to be a composable building-block primitive. We expect higher-level APIs and/or tools to be built on top of it and other complementary primitives for user convenience in the future. The "macro" operations currently supported by kubectl (run, scale) are proof-of-concept examples of this. For instance, we could imagine something like [Asgard](https://netflixtechblog.com/asgard-web-based-cloud-management-and-deployment-2c9fc4e4d3a1) managing ReplicationControllers, auto-scalers, services, scheduling policies, canaries, etc.
## API Object
@@ -284,6 +284,11 @@ machine-level function, such as machine monitoring or machine logging. These po
to a machine lifetime: the pod needs to be running on the machine before other pods start, and are
safe to terminate when the machine is otherwise ready to be rebooted/shutdown.
-## For more information
+## {{% heading "whatsnext" %}}
-Read [Run Stateless Application Deployment](/docs/tasks/run-application/run-stateless-application-deployment/).
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Learn about [Deployment](/docs/concepts/workloads/controllers/deployment/), the replacement
+ for ReplicationController.
+* `ReplicationController` is part of the Kubernetes REST API.
+ Read the {{< api-reference page="workload-resources/replication-controller-v1" >}}
+ object definition to understand the API for replication controllers.
diff --git a/content/en/docs/concepts/workloads/controllers/statefulset.md b/content/en/docs/concepts/workloads/controllers/statefulset.md
index 3f89da5989..6b65ba1f3b 100644
--- a/content/en/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/en/docs/concepts/workloads/controllers/statefulset.md
@@ -297,7 +297,18 @@ Please note that this field only works if you enable the `StatefulSetMinReadySec
## {{% heading "whatsnext" %}}
+* Learn about [Pods](/docs/concepts/workloads/pods).
+* Find out how to use StatefulSets
+ * Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
+ * Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
+ * Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
+ * Learn how to [scale a StatefulSet](/docs/tasks/run-application/scale-stateful-set/).
+ * Learn what's involved when you [delete a StatefulSet](/docs/tasks/run-application/delete-stateful-set/).
+ * Learn how to [configure a Pod to use a volume for storage](/docs/tasks/configure-pod-container/configure-volume-storage/).
+ * Learn how to [configure a Pod to use a PersistentVolume for storage](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/).
+* `StatefulSet` is a top-level resource in the Kubernetes REST API.
+ Read the {{< api-reference page="workload-resources/stateful-set-v1" >}}
+ object definition to understand the API for stateful sets.
+* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how
+ you can use it to manage application availability during disruptions.
-* Follow an example of [deploying a stateful application](/docs/tutorials/stateful-application/basic-stateful-set/).
-* Follow an example of [deploying Cassandra with Stateful Sets](/docs/tutorials/stateful-application/cassandra/).
-* Follow an example of [running a replicated stateful application](/docs/tasks/run-application/run-replicated-stateful-application/).
diff --git a/content/en/docs/concepts/workloads/pods/_index.md b/content/en/docs/concepts/workloads/pods/_index.md
index 7132d19529..fa91723c5a 100644
--- a/content/en/docs/concepts/workloads/pods/_index.md
+++ b/content/en/docs/concepts/workloads/pods/_index.md
@@ -48,6 +48,21 @@ with shared namespaces and shared filesystem volumes.
## 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:
+```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
+
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" >}}.
If your Pods need to track state, consider the
@@ -97,7 +112,7 @@ For example, you might have a container that
acts as a web server for files in a shared volume, and a separate "sidecar" container
that updates those files from a remote source, as in the following diagram:
-{{< 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" >}} as well as {{< glossary_tooltip text="app containers" term_id="app-container" >}}. Init containers run and complete before the app containers are started.
@@ -309,9 +324,9 @@ in the Pod Lifecycle documentation.
* Read about [Pod topology spread constraints](/docs/concepts/workloads/pods/pod-topology-spread-constraints/).
* Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions.
* Pod is a top-level resource in the Kubernetes REST API.
- The [Pod](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+ The {{< api-reference page="workload-resources/pod-v1" >}}
object definition describes the object in detail.
-* [The Distributed System Toolkit: Patterns for Composite Containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns) explains common layouts for Pods with more than one container.
+* [The Distributed System Toolkit: Patterns for Composite Containers](/blog/2015/06/the-distributed-system-toolkit-patterns/) explains common layouts for Pods with more than one container.
To understand the context for why Kubernetes wraps a common Pod API in other resources (such as {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}} or {{< glossary_tooltip text="Deployments" term_id="deployment" >}}), you can read about the prior art, including:
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 291c8e6af3..75e4a0ba34 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -55,7 +55,7 @@ exists. If that Pod is deleted for any reason, and even if an identical replacem
is created, the related thing (a volume, in this example) is also destroyed and
created anew.
-{{< figure src="/images/docs/pod.svg" title="Pod diagram" width="50%" >}}
+{{< figure src="/images/docs/pod.svg" title="Pod diagram" class="diagram-medium" >}}
*A multi-container Pod that contains a file puller and a
web server that uses a persistent volume for shared storage between the containers.*
diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
index 719fcee457..43f537c9a5 100644
--- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
+++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md
@@ -234,7 +234,7 @@ To overcome this situation, you can either increase the `maxSkew` or modify one
The scheduler will skip the non-matching nodes from the skew calculations if the incoming Pod has `spec.nodeSelector` or `spec.affinity.nodeAffinity` defined.
- Suppose you have a 5-node cluster ranging from zoneA to zoneC:
+Suppose you have a 5-node cluster ranging from zoneA to zoneC:
{{}}
graph BT
@@ -268,7 +268,7 @@ The scheduler will skip the non-matching nodes from the skew calculations if the
class zoneC cluster;
{{< /mermaid >}}
- and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
+and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected.
{{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}}
diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md
index 1db65ec56d..1042604550 100644
--- a/content/en/docs/contribute/_index.md
+++ b/content/en/docs/contribute/_index.md
@@ -29,6 +29,8 @@ Kubernetes documentation contributors:
- Translate the documentation
- Manage and publish the documentation parts of the Kubernetes release cycle
+
+
## Getting started
@@ -44,18 +46,98 @@ to work effectively in the Kubernetes community.
To get involved with documentation:
1. Sign the CNCF [Contributor License Agreement](https://github.com/kubernetes/community/blob/master/CLA.md).
-1. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
+2. Familiarize yourself with the [documentation repository](https://github.com/kubernetes/website)
and the website's [static site generator](https://gohugo.io).
-1. Make sure you understand the basic processes for
+3. Make sure you understand the basic processes for
[opening a pull request](/docs/contribute/new-content/open-a-pr/) and
[reviewing changes](/docs/contribute/review/reviewing-prs/).
+
+
+
+{{< mermaid >}}
+flowchart TB
+subgraph third[Open PR]
+direction TB
+U[ ] -.-
+Q[Improve content] --- N[Create content]
+N --- O[Translate docs]
+O --- P[Manage/publish docs parts of K8s release cycle]
+
+end
+
+subgraph second[Review]
+direction TB
+ T[ ] -.-
+ D[Look over the K8s/website repository] --- E[Check out the Hugo static site generator]
+ E --- F[Understand basic GitHub commands]
+ F --- G[Review open PR and change review processes]
+end
+
+subgraph first[Sign up]
+ direction TB
+ S[ ] -.-
+ B[Sign the CNCF Contributor License Agreement] --- C[Join sig-docs Slack channel]
+ C --- V[Join kubernetes-sig-docs mailing list]
+ V --- M[Attend weekly sig-docs calls or slack meetings]
+end
+
+A([fa:fa-user New Contributor]) --> first
+A --> second
+A --> third
+A --> H[Ask Questions!!!]
+
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,C,D,E,F,G,H,M,Q,N,O,P,V grey
+class S,T,U spacewhite
+class first,second,third white
+{{}}
+***Figure - Getting started for a new contributor***
+
+The figure above outlines a roadmap for new contributors. You can follow some or all of the steps for `Sign up` and `Review`. Now you are ready to open PRs that achieve your contribution objectives with some listed under `Open PR`. Again, questions are always welcome!
+
Some tasks require more trust and more access in the Kubernetes organization.
See [Participating in SIG Docs](/docs/contribute/participate/) for more details about
roles and permissions.
## Your first contribution
+You can prepare for your first contribution by reviewing several steps beforehand. The figure below outlines the steps and the details follow.
+
+
+
+
+{{< mermaid >}}
+flowchart LR
+ subgraph second[First Contribution]
+ direction TB
+ S[ ] -.-
+ G[Review PRs from other K8s members] -->
+ A[Check K8s/website issues list for good first PRs] --> B[Open a PR!!]
+ end
+ subgraph first[Suggested Prep]
+ direction TB
+ T[ ] -.-
+ D[Read contribution overview] -->E[Read K8s content and style guides]
+ E --> F[Learn about Hugo page content types and shortcodes]
+ end
+
+
+ first ----> second
+
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,D,E,F,G grey
+class S,T spacewhite
+class first,second white
+{{}}
+***Figure - Preparation for your first contribution***
+
- Read the [Contribution overview](/docs/contribute/new-content/overview/) to
learn about the different ways you can contribute.
- Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/)
@@ -92,10 +174,12 @@ SIG Docs communicates with different methods:
introduce yourself!
- [Join the `kubernetes-sig-docs` mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs),
where broader discussions take place and official decisions are recorded.
-- Join the [weekly SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs). Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
+- Join the [SIG Docs video meeting](https://github.com/kubernetes/community/tree/master/sig-docs) held every two weeks. Meetings are always announced on `#sig-docs` and added to the [Kubernetes community meetings calendar](https://calendar.google.com/calendar/embed?src=cgnt364vd8s86hr2phapfjc6uk%40group.calendar.google.com&ctz=America/Los_Angeles). You'll need to download the [Zoom client](https://zoom.us/download) or dial in using a phone.
+- Join the SIG Docs async Slack standup meeting on those weeks when the in-person Zoom video meeting does not take place. Meetings are always announced on `#sig-docs`. You can contribute to any one of the threads up to 24 hours after meeting announcement.
## Other ways to contribute
- Visit the [Kubernetes community site](/community/). Participate on Twitter or Stack Overflow, learn about local Kubernetes meetups and events, and more.
- Read the [contributor cheatsheet](https://github.com/kubernetes/community/tree/master/contributors/guide/contributor-cheatsheet) to get involved with Kubernetes feature development.
- Submit a [blog post or case study](/docs/contribute/new-content/blogs-case-studies/).
+
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index c9cd5a5385..592b59ded9 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -346,7 +346,7 @@ Teams must merge localized content into the same branch from which the content w
For example:
- a localization branch sourced from `main` must be merged into `main`.
-- a localization branch sourced from `release-{{ skew "prevMinorVersion" }}` must be merged into `release-{{ skew "prevMinorVersion" }}`.
+- a localization branch sourced from `release-{{% skew "prevMinorVersion" %}}` must be merged into `release-{{% skew "prevMinorVersion" %}}`.
{{< note >}}
If your localization branch was created from `main` branch but it is not merged into `main` before new release branch `{{< release-branch >}}` created, merge it into both `main` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`.
@@ -361,5 +361,4 @@ For more information about working from forks or directly from the repository, s
## Upstream contributions
SIG Docs welcomes upstream contributions and corrections to the English source.
-
-
+
diff --git a/content/en/docs/contribute/new-content/_index.md b/content/en/docs/contribute/new-content/_index.md
index 4992a37654..501e417985 100644
--- a/content/en/docs/contribute/new-content/_index.md
+++ b/content/en/docs/contribute/new-content/_index.md
@@ -1,4 +1,118 @@
---
title: Contributing new content
+content_type: concept
+main_menu: true
weight: 20
---
+
+
+
+
+
+This section contains information you should know before contributing new
+content.
+
+
+
+{{< mermaid >}}
+flowchart LR
+ subgraph second[Before you begin]
+ direction TB
+ S[ ] -.-
+ A[Sign the CNCF CLA] --> B[Choose Git branch]
+ B --> C[One language per PR]
+ C --> F[Check out contributor tools]
+ end
+ subgraph first[Contributing Basics]
+ direction TB
+ T[ ] -.-
+ D[Write docs in markdown and build site with Hugo] --- E[source in GitHub]
+ E --- G[_'/content/../docs'_ folder contains docs for multiple languages]
+ G --- H[Review Hugo page content types and shortcodes]
+ end
+
+
+ first ----> second
+
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,C,D,E,F,G,H grey
+class S,T spacewhite
+class first,second white
+{{}}
+
+***Figure - Contributing new content preparation***
+
+The figure above depicts the information you should know
+prior to submitting new content. The information details follow.
+
+
+
+
+
+## Contributing basics
+
+- Write Kubernetes documentation in Markdown and build the Kubernetes site
+ using [Hugo](https://gohugo.io/).
+- The source is in [GitHub](https://github.com/kubernetes/website). You can find
+ Kubernetes documentation at `/content/en/docs/`. Some of the reference
+ documentation is automatically generated from scripts in
+ the `update-imported-docs/` directory.
+- [Page content types](/docs/contribute/style/page-content-types/) describe the
+ presentation of documentation content in Hugo.
+- In addition to the standard Hugo shortcodes, we use a number of
+ [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our
+ documentation to control the presentation of content.
+- Documentation source is available in multiple languages in `/content/`. Each
+ language has its own folder with a two-letter code determined by the
+ [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php)
+ . For example, English documentation source is stored in `/content/en/docs/`.
+- For more information about contributing to documentation in multiple languages
+ or starting a new translation,
+ see [localization](/docs/contribute/localization).
+
+## Before you begin {#before-you-begin}
+
+### Sign the CNCF CLA {#sign-the-cla}
+
+All Kubernetes contributors **must** read
+the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md)
+and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md)
+.
+
+Pull requests from contributors who haven't signed the CLA fail the automated
+tests. The name and email you provide must match those found in
+your `git config`, and your git name and email must match those used for the
+CNCF CLA.
+
+### Choose which Git branch to use
+
+When opening a pull request, you need to know in advance which branch to base
+your work on.
+
+Scenario | Branch
+:---------|:------------
+Existing or new English language content for the current release | `main`
+Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
+Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
+
+If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
+
+{{< note >}} If you already submitted your pull request and you know that the
+base branch was wrong, you (and only you, the submitter) can change it. {{<
+/note >}}
+
+### Languages per PR
+
+Limit pull requests to one language per PR. If you need to make an identical
+change to the same code sample in multiple languages, open a separate PR for
+each language.
+
+## Tools for contributors
+
+The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools)
+directory in the `kubernetes/website` repository contains tools to help your
+contribution journey go more smoothly.
+
diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md
index 973a29167d..548dbac5d0 100644
--- a/content/en/docs/contribute/new-content/open-a-pr.md
+++ b/content/en/docs/contribute/new-content/open-a-pr.md
@@ -28,7 +28,40 @@ If your changes are large, read [Work from a local fork](#fork-the-repo) to lear
## Changes using GitHub
If you're less experienced with git workflows, here's an easier method of
-opening a pull request.
+opening a pull request. The figure below outlines the steps and the details follow.
+
+
+
+
+{{< mermaid >}}
+flowchart LR
+A([fa:fa-user New Contributor]) --- id1[(K8s/Website GitHub)]
+subgraph tasks[Changes using GitHub]
+direction TB
+ 0[ ] -.-
+ 1[1. Edit this page] --> 2[2. Use GitHub markdown editor to make changes]
+ 2 --> 3[3. fill in Propose file change]
+
+end
+subgraph tasks2[ ]
+direction TB
+4[4. select Propose file change] --> 5[5. select Create pull request] --> 6[6. fill in Open a pull request]
+6 --> 7[7. select Create pull request]
+end
+
+id1 --> tasks --> tasks2
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,1,2,3,4,5,6,7 grey
+class 0 spacewhite
+class tasks,tasks2 white
+class id1 k8s
+{{}}
+
+***Figure - Steps for opening a PR using GitHub***
1. On the page where you see the issue, select the pencil icon at the top right.
You can also scroll to the bottom of the page and select **Edit this page**.
@@ -89,6 +122,37 @@ work from a local fork.
Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application.
+The figure below shows the steps to follow when you work from a local fork. The details for each step follow.
+
+
+
+
+{{< mermaid >}}
+flowchart LR
+1[Fork the K8s/website repository] --> 2[Create local clone and set upstream]
+subgraph changes[Your changes]
+direction TB
+S[ ] -.-
+3[Create a branch example: my_new_branch] --> 3a[Make changes using text editor] --> 4["Preview your changes locally using Hugo (localhost:1313) or build container image"]
+end
+subgraph changes2[Commit / Push]
+direction TB
+T[ ] -.-
+5[Commit your changes] --> 6[Push commit to origin/my_new_branch]
+end
+
+2 --> changes --> changes2
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff;
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class 1,2,3,3a,4,5,6 grey
+class S,T spacewhite
+class changes,changes2 white
+{{}}
+***Figure - Working from a local fork to make your changes***
+
### Fork the kubernetes/website repository
1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
@@ -289,6 +353,34 @@ Alternately, install and use the `hugo` command on your computer:
### Open a pull request from your fork to kubernetes/website {#open-a-pr}
+The figure below shows the steps to open a PR from your fork to the K8s/website. The details follow.
+
+
+
+{{< mermaid >}}
+flowchart LR
+subgraph first[ ]
+direction TB
+1[1. Go to K8s/website repository] --> 2[2. Select New Pull Request]
+2 --> 3[3. Select compare across forks]
+3 --> 4[4. Select your fork from head repository drop-down menu]
+end
+subgraph second [ ]
+direction TB
+5[5. Select your branch from the compare drop-down menu] --> 6[6. Select Create Pull Request]
+6 --> 7[7. Add a description to your PR]
+7 --> 8[8. Select Create pull request]
+end
+
+first --> second
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+class 1,2,3,4,5,6,7,8 grey
+class first,second white
+{{}}
+***Figure - Steps to open a PR from your fork to the K8s/website***
+
1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository.
2. Select **New Pull Request**.
3. Select **compare across forks**.
@@ -303,7 +395,7 @@ Alternately, install and use the `hugo` command on your computer:
8. Select the **Create pull request** button.
- Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
+Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls).
After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/).
@@ -414,7 +506,6 @@ If another contributor commits changes to the same file in another PR, it can cr
The pull request no longer shows any conflicts.
-
### Squashing commits
{{< note >}}
@@ -500,11 +591,8 @@ Most repositories use issue and PR templates. Have a look through some open
issues and PRs to get a feel for that team's processes. Make sure to fill out
the templates with as much detail as possible when you file issues or PRs.
-
-
## {{% heading "whatsnext" %}}
- Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process.
-
diff --git a/content/en/docs/contribute/new-content/overview.md b/content/en/docs/contribute/new-content/overview.md
deleted file mode 100644
index 8b4da4970a..0000000000
--- a/content/en/docs/contribute/new-content/overview.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: Contributing new content overview
-linktitle: Overview
-content_type: concept
-main_menu: true
-weight: 5
----
-
-
-
-This section contains information you should know before contributing new content.
-
-
-
-
-
-
-## Contributing basics
-
-- Write Kubernetes documentation in Markdown and build the Kubernetes site using [Hugo](https://gohugo.io/).
-- The source is in [GitHub](https://github.com/kubernetes/website). You can find Kubernetes documentation at `/content/en/docs/`. Some of the reference documentation is automatically generated from scripts in the `update-imported-docs/` directory.
-- [Page content types](/docs/contribute/style/page-content-types/) describe the presentation of documentation content in Hugo.
-- In addition to the standard Hugo shortcodes, we use a number of
- [custom Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/) in our documentation to control the presentation of content.
-- Documentation source is available in multiple languages in `/content/`. Each
- language has its own folder with a two-letter code determined by the
- [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php). For
- example, English documentation source is stored in `/content/en/docs/`.
-- For more information about contributing to documentation in multiple languages or starting a new translation, see [localization](/docs/contribute/localization).
-
-## Before you begin {#before-you-begin}
-
-### Sign the CNCF CLA {#sign-the-cla}
-
-All Kubernetes contributors **must** read the [Contributor guide](https://github.com/kubernetes/community/blob/master/contributors/guide/README.md) and [sign the Contributor License Agreement (CLA)](https://github.com/kubernetes/community/blob/master/CLA.md).
-
-Pull requests from contributors who haven't signed the CLA fail the automated tests. The name and email you provide must match those found in your `git config`, and your git name and email must match those used for the CNCF CLA.
-
-### Choose which Git branch to use
-
-When opening a pull request, you need to know in advance which branch to base your work on.
-
-Scenario | Branch
-:---------|:------------
-Existing or new English language content for the current release | `main`
-Content for a feature change release | The branch which corresponds to the major and minor version the feature change is in, using the pattern `dev-`. For example, if a feature changes in the `v{{< skew nextMinorVersion >}}` release, then add documentation changes to the ``dev-{{< skew nextMinorVersion >}}`` branch.
-Content in other languages (localizations) | Use the localization's convention. See the [Localization branching strategy](/docs/contribute/localization/#branching-strategy) for more information.
-
-
-If you're still not sure which branch to choose, ask in `#sig-docs` on Slack.
-
-{{< note >}}
-If you already submitted your pull request and you know that the base branch
-was wrong, you (and only you, the submitter) can change it.
-{{< /note >}}
-
-### Languages per PR
-
-Limit pull requests to one language per PR. If you need to make an identical change to the same code sample in multiple languages, open a separate PR for each language.
-
-## Tools for contributors
-
-The [doc contributors tools](https://github.com/kubernetes/website/tree/main/content/en/docs/doc-contributor-tools) directory in the `kubernetes/website` repository contains tools to help your contribution journey go more smoothly.
-
-
diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md
index ff6ef9d709..9240d98f3b 100644
--- a/content/en/docs/contribute/review/reviewing-prs.md
+++ b/content/en/docs/contribute/review/reviewing-prs.md
@@ -36,7 +36,38 @@ Before you start a review:
## Review process
-In general, review pull requests for content and style in English.
+In general, review pull requests for content and style in English. The figure below outlines the steps for the review process. The details for each step follow.
+
+
+
+
+{{< mermaid >}}
+flowchart LR
+ subgraph fourth[Start review]
+ direction TB
+ S[ ] -.-
+ M[add comments] --> N[review changes]
+ N --> O[new contributors should choose Comment]
+ end
+ subgraph third[Select PR]
+ direction TB
+ T[ ] -.-
+ J[read description and comments]--> K[preview changes in Netlify preview build]
+ end
+
+ A[Review open PR list]--> B[Filter open PRs by label]
+ B --> third --> fourth
+
+
+classDef grey fill:#dddddd,stroke:#ffffff,stroke-width:px,color:#000000, font-size:15px;
+classDef white fill:#ffffff,stroke:#000,stroke-width:px,color:#000,font-weight:bold
+classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000
+class A,B,J,K,M,N,O grey
+class S,T spacewhite
+class third,fourth white
+{{}}
+
+***Figure - Review process steps***
1. Go to
[https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
diff --git a/content/en/docs/reference/access-authn-authz/authorization.md b/content/en/docs/reference/access-authn-authz/authorization.md
index af73a23350..0698512772 100644
--- a/content/en/docs/reference/access-authn-authz/authorization.md
+++ b/content/en/docs/reference/access-authn-authz/authorization.md
@@ -134,6 +134,21 @@ The output is similar to this:
no
```
+Similarly, to check whether a Service Account named `dev-sa` in Namespace `dev`
+can list Pods in the Namespace `target`:
+
+```bash
+kubectl auth can-i list pods \
+ --namespace target \
+ --as system:serviceaccount:dev:dev-sa
+```
+
+The output is similar to this:
+
+```
+yes
+```
+
`SelfSubjectAccessReview` is part of the `authorization.k8s.io` API group, which
exposes the API server authorization to external services. Other resources in
this group include:
@@ -192,22 +207,33 @@ The following flags can be used:
You can choose more than one authorization module. Modules are checked in order
so an earlier module has higher priority to allow or deny a request.
-## Privilege escalation via pod creation
+## Privilege escalation via workload creation or edits {#privilege-escalation-via-pod-creation}
-Users who have the ability to create pods in a namespace can potentially
-escalate their privileges within that namespace. They can create pods that
-access their privileges within that namespace. They can create pods that access
-secrets the user cannot themselves read, or that run under a service account
-with different/greater permissions.
+Users who can create/edit pods in a namespace, either directly or through a [controller](/docs/concepts/architecture/controller/)
+such as an operator, could escalate their privileges in that namespace.
{{< caution >}}
-System administrators, use care when granting access to pod creation. A user
-granted permission to create pods (or controllers that create pods) in the
-namespace can: read all secrets in the namespace; read all config maps in the
-namespace; and impersonate any service account in the namespace and take any
-action the account could take. This applies regardless of authorization mode.
+System administrators, use care when granting access to create or edit workloads.
+Details of how these can be misused are documented in [escalation paths](/docs/reference/access-authn-authz/authorization/#escalation-paths)
{{< /caution >}}
+### Escalation paths {#escalation-paths}
+- Mounting arbitrary secrets in that namespace
+ - Can be used to access secrets meant for other workloads
+ - Can be used to obtain a more privileged service account's service account token
+- Using arbitrary Service Accounts in that namespace
+ - Can perform Kubernetes API actions as another workload (impersonation)
+ - Can perform any privileged actions that Service Account has
+- Mounting configmaps meant for other workloads in that namespace
+ - Can be used to obtain information meant for other workloads, such as DB host names.
+- Mounting volumes meant for other workloads in that namespace
+ - Can be used to obtain information meant for other workloads, and change it.
+
+{{< caution >}}
+System administrators should be cautious when deploying CRDs that
+change the above areas. These may open privilege escalations paths.
+This should be considered when deciding on your RBAC controls.
+{{< /caution >}}
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
index aa714bdaa2..8d0f9694ce 100644
--- a/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
+++ b/content/en/docs/reference/access-authn-authz/extensible-admission-controllers.md
@@ -67,7 +67,7 @@ See the [webhook request](#request) section for details on the data sent to webh
See the [webhook response](#response) section for the data expected from webhooks.
The example admission webhook server leaves the `ClientAuth` field
-[empty](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48),
+[empty](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/images/agnhost/webhook/config.go#L38-L39),
which defaults to `NoClientCert`. This means that the webhook server does not
authenticate the identity of the clients, supposedly apiservers. If you need
mutual TLS or other ways to authenticate the clients, see
@@ -79,7 +79,7 @@ The webhook server in the e2e test is deployed in the Kubernetes cluster, via
the [deployment API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deployment-v1-apps).
The test also creates a [service](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#service-v1-core)
as the front-end of the webhook server. See
-[code](https://github.com/kubernetes/kubernetes/blob/v1.15.0/test/e2e/apimachinery/webhook.go#L301).
+[code](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/e2e/apimachinery/webhook.go#L748).
You may also deploy your webhooks outside of the cluster. You will need to update
your webhook configurations accordingly.
diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
index b392117237..91aa118fa2 100644
--- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md
@@ -125,7 +125,6 @@ different Kubernetes components.
| `HPAScaleToZero` | `false` | Alpha | 1.16 | |
| `IndexedJob` | `false` | Alpha | 1.21 | 1.21 |
| `IndexedJob` | `true` | Beta | 1.22 | |
-| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
| `IngressClassNamespacedParams` | `false` | Alpha | 1.21 | 1.21 |
| `IngressClassNamespacedParams` | `true` | Beta | 1.22 | |
| `InTreePluginAWSUnregister` | `false` | Alpha | 1.21 | |
@@ -138,13 +137,13 @@ different Kubernetes components.
| `IPv6DualStack` | `true` | Beta | 1.21 | |
| `JobTrackingWithFinalizers` | `false` | Alpha | 1.22 | |
| `KubeletCredentialProviders` | `false` | Alpha | 1.20 | |
+| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
+| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
| `LocalStorageCapacityIsolation` | `false` | Alpha | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | Beta | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | Alpha | 1.15 | |
| `LogarithmicScaleDown` | `false` | Alpha | 1.21 | 1.21 |
| `LogarithmicScaleDown` | `true` | Beta | 1.22 | |
-| `KubeletInUserNamespace` | `false` | Alpha | 1.22 | |
-| `KubeletPodResourcesGetAllocatable` | `false` | Alpha | 1.21 | |
| `MemoryManager` | `false` | Alpha | 1.21 | 1.21 |
| `MemoryManager` | `true` | Beta | 1.22 | |
| `MemoryQoS` | `false` | Alpha | 1.22 | |
@@ -287,9 +286,6 @@ different Kubernetes components.
| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
| `DynamicProvisioningScheduling` | `false` | Alpha | 1.11 | 1.11 |
| `DynamicProvisioningScheduling` | - | Deprecated| 1.12 | - |
-| `DynamicKubeletConfig` | `false` | Alpha | 1.4 | 1.10 |
-| `DynamicKubeletConfig` | `true` | Beta | 1.11 | 1.21 |
-| `DynamicKubeletConfig` | `false` | Deprecated | 1.22 | - |
| `DynamicVolumeProvisioning` | `true` | Alpha | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | Deprecated | 1.16 | - |
diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md
index 0531f0847a..75698b3966 100644
--- a/content/en/docs/reference/command-line-tools-reference/kubelet.md
+++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md
@@ -51,7 +51,7 @@ kubelet [flags]
--address string Default: 0.0.0.0
-
The IP address for the Kubelet to serve on (set to 0.0.0.0 or :: for listening in gll interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
+
The IP address for the Kubelet to serve on (set to 0.0.0.0 or :: for listening in all interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)
diff --git a/content/en/docs/reference/glossary/namespace.md b/content/en/docs/reference/glossary/namespace.md
index a477150a9d..33a97d90a1 100644
--- a/content/en/docs/reference/glossary/namespace.md
+++ b/content/en/docs/reference/glossary/namespace.md
@@ -10,9 +10,9 @@ aka:
tags:
- fundamental
---
- An abstraction used by Kubernetes to support multiple virtual clusters on the same physical {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
+ An abstraction used by Kubernetes to support isolation of groups of resources within a single {{< glossary_tooltip text="cluster" term_id="cluster" >}}.
-Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces.
+Namespaces are used to organize objects in a cluster and provide a way to divide cluster resources. Names of resources need to be unique within a namespace, but not across namespaces. Namespace-based scoping is applicable only for namespaced objects _(e.g. Deployments, Services, etc)_ and not for cluster-wide objects _(e.g. StorageClass, Nodes, PersistentVolumes, etc)_.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
index 60abb96e56..a8d514ad14 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md
@@ -142,6 +142,22 @@ For information about enabling IPVS mode with kubeadm see:
For information about passing flags to control plane components see:
- [control-plane-flags](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/)
+### Running kubeadm without an Internet connection {#without-internet-connection}
+
+For running kubeadm without an Internet connection you have to pre-pull the required control-plane images.
+
+You can list and pull the images using the `kubeadm config images` sub-command:
+
+```shell
+kubeadm config images list
+kubeadm config images pull
+```
+
+You can pass `--config` to the above commands with a [kubeadm configuration file](#config-file)
+to control the `kubernetesVersion` and `imageRepository` fields.
+
+All default `k8s.gcr.io` images that kubeadm requires support multiple architectures.
+
### Using custom images {#custom-images}
By default, kubeadm pulls images from `k8s.gcr.io`. If the
@@ -151,13 +167,24 @@ requested Kubernetes version is a CI label (such as `ci/latest`)
You can override this behavior by using [kubeadm with a configuration file](#config-file).
Allowed customization are:
+* To provide `kubernetesVersion` which affects the version of the images.
* To provide an alternative `imageRepository` to be used instead of
`k8s.gcr.io`.
-* To set `useHyperKubeImage` to `true` to use the HyperKube image.
-* To provide a specific `imageRepository` and `imageTag` for etcd or DNS add-on.
+* To provide a specific `imageRepository` and `imageTag` for etcd or CoreDNS.
-Please note that the configuration field `kubernetesVersion` or the command line flag
-`--kubernetes-version` affect the version of the images.
+Image paths between the default `k8s.gcr.io` and a custom repository specified using
+`imageRepository` may differ for backwards compatibility reasons. For example,
+one image might have a subpath at `k8s.gcr.io/subpath/image`, but be defaulted
+to `my.customrepository.io/image` when using a custom repository.
+
+To ensure you push the images to your custom repository in paths that kubeadm
+can consume, you must:
+
+* Pull images from the defaults paths at `k8s.gcr.io` using `kubeadm config images {list|pull}`.
+* Push images to the paths from `kubeadm config images list --config=config.yaml`,
+where `config.yaml` contains the custom `imageRepository`, and/or `imageTag`
+for etcd and CoreDNS.
+* Pass the same `config.yaml` to `kubeadm init`.
### Uploading control-plane certificates to the cluster
@@ -209,19 +236,6 @@ value to the kubelet.
Be aware that overriding the hostname can [interfere with cloud providers](https://github.com/kubernetes/website/pull/8873).
-### Running kubeadm without an internet connection
-
-For running kubeadm without an internet connection you have to pre-pull the required control-plane images.
-
-You can list and pull the images using the `kubeadm config images` sub-command:
-
-```shell
-kubeadm config images list
-kubeadm config images pull
-```
-
-All images that kubeadm requires such as `k8s.gcr.io/kube-*`, `k8s.gcr.io/etcd` and `k8s.gcr.io/pause` support multiple architectures.
-
### Automating kubeadm
Rather than copying the token you obtained from `kubeadm init` to each node, as
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
index 5ad349e66c..b5756e5cc2 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -287,7 +287,7 @@ If your configuration is not using the latest version it is **recommended** that
the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
For more information on the fields and usage of the configuration you can navigate to our
-[API reference](/docs/reference/config-api/kubeadm-config.v1beta2/).
+[API reference](/docs/reference/config-api/kubeadm-config.v1beta3/).
## {{% heading "whatsnext" %}}
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
index 6a2c5f782f..3741c5f30d 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-upgrade.md
@@ -15,7 +15,7 @@ behind one command, with support for both planning an upgrade and actually perfo
## kubeadm upgrade guidance
-The steps for performing a upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
+The steps for performing an upgrade using kubeadm are outlined in [this document](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/).
For older versions of kubeadm, please refer to older documentation sets of the Kubernetes website.
You can use `kubeadm upgrade diff` to see the changes that would be applied to static pod manifests.
diff --git a/content/en/docs/reference/tools/_index.md b/content/en/docs/reference/tools/_index.md
index aa65af289b..389e6e77d2 100644
--- a/content/en/docs/reference/tools/_index.md
+++ b/content/en/docs/reference/tools/_index.md
@@ -8,8 +8,7 @@ no_list: true
---
-Kubernetes contains several built-in tools and external tools that are commonly used or relevant that may as well be seen as required for Kubernetes to function.
-
+Kubernetes contains several tools to help you work with the Kubernetes system.
@@ -25,10 +24,14 @@ development and testing purposes.
to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resources itself.
## Helm
+{{% thirdparty-content single="true" %}}
[Helm](https://helm.sh/) is a tool for managing packages of pre-configured
Kubernetes resources. These packages are known as _Helm charts_.
+Helm is a third party managed tool for managing packages of pre-configured
+Kubernetes resources, aka Kubernetes charts.
+
Use Helm to:
* Find and use popular software packaged as Kubernetes charts
diff --git a/content/en/docs/reference/using-api/deprecation-policy.md b/content/en/docs/reference/using-api/deprecation-policy.md
index eed4341628..6bbd9be9e1 100644
--- a/content/en/docs/reference/using-api/deprecation-policy.md
+++ b/content/en/docs/reference/using-api/deprecation-policy.md
@@ -109,7 +109,7 @@ objects.
All of this is best illustrated by examples. Imagine a Kubernetes release,
version X, which introduces a new API group. A new Kubernetes release is made
-every approximately 3 months (4 per year). The following table describes which
+every approximately 4 months (3 per year). The following table describes which
API versions are supported in a series of subsequent releases.
diff --git a/content/en/docs/setup/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md
index 1648cc4e9e..defa8b59f6 100644
--- a/content/en/docs/setup/best-practices/certificates.md
+++ b/content/en/docs/setup/best-practices/certificates.md
@@ -38,11 +38,13 @@ etcd also implements mutual TLS to authenticate clients and peers.
## Where certificates are stored
-If you install Kubernetes with kubeadm, certificates are stored in `/etc/kubernetes/pki`. All paths in this documentation are relative to that directory.
+If you install Kubernetes with kubeadm, most certificates are stored in `/etc/kubernetes/pki`. All paths in this documentation are relative to that directory, with the exception of user account certificates which kubeadm places in `/etc/kubernetes`.
## Configure certificates manually
-If you don't want kubeadm to generate the required certificates, you can create them in either of the following ways.
+If you don't want kubeadm to generate the required certificates, you can create them using a single root CA or by providing all certificates. See [Certificates](/docs/tasks/administer-cluster/certificates/) for details on creating your own certificate authority.
+See [Certificate Management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) for more on managing certificates.
+
### Single root CA
@@ -57,7 +59,16 @@ Required CAs:
| front-proxy-ca.crt,key | kubernetes-front-proxy-ca | For the [front-end proxy](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) |
On top of the above CAs, it is also necessary to get a public/private key pair for service account management, `sa.key` and `sa.pub`.
+The following example illustrates the CA key and certificate files shown in the previous table:
+```
+/etc/kubernetes/pki/ca.crt
+/etc/kubernetes/pki/ca.key
+/etc/kubernetes/pki/etcd/ca.crt
+/etc/kubernetes/pki/etcd/ca.key
+/etc/kubernetes/pki/front-proxy-ca.crt
+/etc/kubernetes/pki/front-proxy-ca.key
+```
### All certificates
If you don't wish to copy the CA private keys to your cluster, you can generate all certificates yourself.
@@ -127,6 +138,32 @@ Same considerations apply for the service account key pair:
| sa.key | | kube-controller-manager | --service-account-private-key-file |
| | sa.pub | kube-apiserver | --service-account-key-file |
+The following example illustrates the file paths [from the previous tables](/docs/setup/best-practices/certificates/#certificate-paths) you need to provide if you are generating all of your own keys and certificates:
+
+```
+/etc/kubernetes/pki/etcd/ca.key
+/etc/kubernetes/pki/etcd/ca.crt
+/etc/kubernetes/pki/apiserver-etcd-client.key
+/etc/kubernetes/pki/apiserver-etcd-client.crt
+/etc/kubernetes/pki/ca.key
+/etc/kubernetes/pki/ca.crt
+/etc/kubernetes/pki/apiserver.key
+/etc/kubernetes/pki/apiserver.crt
+/etc/kubernetes/pki/apiserver-kubelet-client.key
+/etc/kubernetes/pki/apiserver-kubelet-client.crt
+/etc/kubernetes/pki/front-proxy-ca.key
+/etc/kubernetes/pki/front-proxy-ca.crt
+/etc/kubernetes/pki/front-proxy-client.key
+/etc/kubernetes/pki/front-proxy-client.crt
+/etc/kubernetes/pki/etcd/server.key
+/etc/kubernetes/pki/etcd/server.crt
+/etc/kubernetes/pki/etcd/peer.key
+/etc/kubernetes/pki/etcd/peer.crt
+/etc/kubernetes/pki/etcd/healthcheck-client.key
+/etc/kubernetes/pki/etcd/healthcheck-client.crt
+/etc/kubernetes/pki/sa.key
+/etc/kubernetes/pki/sa.pub
+```
## Configure certificates for user accounts
You must manually configure these administrator account and service accounts:
@@ -146,7 +183,7 @@ The value of `` for `kubelet.conf` **must** match precisely the value
1. Run `kubectl` as follows for each config:
-```shell
+```
KUBECONFIG= kubectl config set-cluster default-cluster --server=https://:6443 --certificate-authority --embed-certs
KUBECONFIG= kubectl config set-credentials --client-key .pem --client-certificate .pem --embed-certs
KUBECONFIG= kubectl config set-context default-system --cluster default-cluster --user
@@ -162,4 +199,11 @@ These files are used as follows:
| controller-manager.conf | kube-controller-manager | Must be added to manifest in `manifests/kube-controller-manager.yaml` |
| scheduler.conf | kube-scheduler | Must be added to manifest in `manifests/kube-scheduler.yaml` |
+The following files illustrate full paths to the files listed in the previous table:
+```
+/etc/kubernetes/admin.conf
+/etc/kubernetes/kubelet.conf
+/etc/kubernetes/controller-manager.conf
+/etc/kubernetes/scheduler.conf
+```
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
index 58086c1eef..ff1fedb9c0 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
@@ -9,7 +9,7 @@ weight: 40
This page covers how to customize the components that kubeadm deploys. For control plane components
-you can use flags in the `ClusteConfiguration` structure or patches per-node. For the kubelet
+you can use flags in the `ClusterConfiguration` structure or patches per-node. For the kubelet
and kube-proxy you can use `KubeletConfiguration` and `KubeProxyConfiguration`, accordingly.
All of these options are possible via the kubeadm configuration API.
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
index 1f107bbc9a..322aaecd90 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md
@@ -83,6 +83,19 @@ kubeadm to tell it what to do. This crashloop is expected and normal.
After you initialize your control-plane, the kubelet runs normally.
{{< /note >}}
+### Preparing the required container images
+
+This step is optional and only applies in case you wish `kubeadm init` and `kubeadm join`
+to not download the default container images which are hosted at `k8s.gcr.io`.
+
+Kubeadm has commands that can help you pre-pull the required images
+when creating a cluster without an internet connection on its nodes.
+See [Running kubeadm without an internet connection](/docs/reference/setup-tools/kubeadm/kubeadm-init#without-internet-connection) for more details.
+
+Kubeadm allows you to use a custom image repository for the required images.
+See [Using custom images](docs/reference/setup-tools/kubeadm/kubeadm-init#custom-images)
+for more details.
+
### Initializing your control-plane node
The control-plane node is the machine where the control plane components run, including
@@ -108,8 +121,6 @@ with the default gateway to set the advertise address for this particular contro
To use a different network interface, specify the `--apiserver-advertise-address=` argument
to `kubeadm init`. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you
must specify an IPv6 address, for example `--apiserver-advertise-address=fd00::101`
-1. (Optional) Run `kubeadm config images pull` prior to `kubeadm init` to verify
-connectivity to the gcr.io container image registry.
To initialize the control-plane node run:
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md b/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
index 39930cca37..283f334874 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/dual-stack-support.md
@@ -93,6 +93,10 @@ kind: JoinConfiguration
discovery:
bootstrapToken:
apiServerEndpoint: 10.100.0.1:6443
+ token: "clvldh.vjjwg16ucnhp94qr"
+ caCertHashes:
+ - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
+ # change auth info above to match the actual token and CA certificate hash for your cluster
nodeRegistration:
kubeletExtraArgs:
node-ip: 10.100.0.3,fd00:1:2:3::3
@@ -109,6 +113,10 @@ controlPlane:
discovery:
bootstrapToken:
apiServerEndpoint: 10.100.0.1:6443
+ token: "clvldh.vjjwg16ucnhp94qr"
+ caCertHashes:
+ - "sha256:a4863cde706cfc580a439f842cc65d5ef112b7b2be31628513a9881cf0d9fe0e"
+ # change auth info above to match the actual token and CA certificate hash for your cluster
nodeRegistration:
kubeletExtraArgs:
node-ip: 10.100.0.4,fd00:1:2:3::4
@@ -118,7 +126,7 @@ nodeRegistration:
`advertiseAddress` in JoinConfiguration.controlPlane specifies the IP address that the API Server will advertise it is listening on. The value of `advertiseAddress` equals the `--apiserver-advertise-address` flag of `kubeadm join`.
```shell
-kubeadm join --config=kubeadm-config.yaml ...
+kubeadm join --config=kubeadm-config.yaml
```
### Create a single-stack cluster
@@ -150,4 +158,4 @@ networking:
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
* Read about [Dual-stack](/docs/concepts/services-networking/dual-stack/) cluster networking
-* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta2/)
+* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta3/)
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
index 5206529f5c..ee4b7a7072 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/high-availability.md
@@ -77,7 +77,7 @@ option. Your cluster requirements may need a different configuration.
- Make sure the address of the load balancer always matches
the address of kubeadm's `ControlPlaneEndpoint`.
- - Read the [Options for Software Load Balancing](https://github.com/kubernetes/kubeadm/blob/master/docs/ha-considerations.md#options-for-software-load-balancing)
+ - Read the [Options for Software Load Balancing](https://git.k8s.io/kubeadm/docs/ha-considerations.md#options-for-software-load-balancing)
guide for more details.
1. Add the first control plane nodes to the load balancer and test the
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
index 8baf5e9dd6..e14a762fc3 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm.md
@@ -262,7 +262,7 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
When using DigitalOcean, it can be the public one (assigned to `eth0`) or
the private one (assigned to `eth1`) should you want to use the optional
private network. The `kubeletExtraArgs` section of the kubeadm
- [`NodeRegistrationOptions` structure](/docs/reference/config-api/kubeadm-config.v1beta2/#kubeadm-k8s-io-v1beta2-NodeRegistrationOptions)
+ [`NodeRegistrationOptions` structure](/docs/reference/config-api/kubeadm-config.v1beta3/#kubeadm-k8s-io-v1beta3-NodeRegistrationOptions)
can be used for this.
Then restart `kubelet`:
@@ -336,7 +336,7 @@ Alternatively, you can try separating the `key=value` pairs like so:
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
-A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta2/).
+A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta3/).
## kube-proxy scheduled before node is initialized by cloud-controller-manager
diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index c3757824c5..fa8733bbb7 100644
--- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -1,1335 +1,965 @@
---
-title: Intro to Windows support in Kubernetes
-content_type: concept
-weight: 65
reviewers:
- jayunit100
- jsturtevant
- marosset
- perithompson
+title: Windows containers in Kubernetes
+content_type: concept
+weight: 65
---
-Windows applications constitute a large portion of the services and
-applications that run in many organizations.
-[Windows containers](https://aka.ms/windowscontainers) provide a modern way to
-encapsulate processes and package dependencies, making it easier to use DevOps
-practices and follow cloud native patterns for Windows applications.
-Kubernetes has become the defacto standard container orchestrator, and the
-release of Kubernetes 1.14 includes production support for scheduling Windows
-containers on Windows nodes in a Kubernetes cluster, enabling a vast ecosystem
-of Windows applications to leverage the power of Kubernetes. Organizations
-with investments in Windows-based applications and Linux-based applications
-don't have to look for separate orchestrators to manage their workloads,
-leading to increased operational efficiencies across their deployments,
-regardless of operating system.
+Windows applications constitute a large portion of the services and applications that
+run in many organizations. [Windows containers](https://aka.ms/windowscontainers)
+provide a way to encapsulate processes and package dependencies, making it easier
+to use DevOps practices and follow cloud native patterns for Windows applications.
+
+Organizations with investments in Windows-based applications and Linux-based
+applications don't have to look for separate orchestrators to manage their workloads,
+leading to increased operational efficiencies across their deployments, regardless
+of operating system.
-## Windows containers in Kubernetes
+## Windows nodes in Kubernetes
-To enable the orchestration of Windows containers in Kubernetes, include
-Windows nodes in your existing Linux cluster. Scheduling Windows containers in
+To enable the orchestration of Windows containers in Kubernetes, include Windows nodes
+in your existing Linux cluster. Scheduling Windows containers in
{{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is similar to
scheduling Linux-based containers.
In order to run Windows containers, your Kubernetes cluster must include
-multiple operating systems, with control plane nodes running Linux and workers
-running either Windows or Linux depending on your workload needs. Windows
-Server 2019 is the only Windows operating system supported, enabling
-[Kubernetes Node](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
-on Windows (including kubelet,
-[container runtime](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/containerd),
-and kube-proxy). For a detailed explanation of Windows distribution channels
-see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
+multiple operating systems.
+While you can only run the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} on Linux, you can deploy worker nodes running either Windows or Linux depending on your workload needs.
-The Kubernetes control plane, including the
-[master components](/docs/concepts/overview/components/),
-continues to run on Linux.
-There are no plans to have a Windows-only Kubernetes cluster.
+Windows {{< glossary_tooltip text="nodes" term_id="node" >}} are
+[supported](#windows-os-version-support) provided that the operating system is
+Windows Server 2019.
-In this document, when we talk about Windows containers we mean Windows
-containers with process isolation. Windows containers with
-[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)
-is planned for a future release.
+This document uses the term *Windows containers* to mean Windows containers with
+process isolation. Kubernetes does not support running Windows containers with
+[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container).
-## Supported Functionality and Limitations
+## Resource management
-### Supported Functionality
+On Linux nodes, {{< glossary_tooltip text="cgroups" term_id="cgroup" >}} are used
+as a pod boundary for resource control. Containers are created within that boundary
+for network, process and file system isolation. The Linux cgroup APIs can be used
+to gather CPU, I/O, and memory use statistics.
-#### Windows OS Version Support
+In contrast, Windows uses a _job object_ per container with a system namespace filter
+to contain all processes in a container and provide logical isolation from the
+host.
+(Job objects are a Windows process isolation mechanism and are different from
+what Kubernetes refers to as a {{< glossary_tooltip term_id="job" text="Job" >}}).
-Refer to the following table for Windows operating system support in
-Kubernetes. A single heterogeneous Kubernetes cluster can have both Windows
-and Linux worker nodes. Windows containers have to be scheduled on Windows
-nodes and Linux containers on Linux nodes.
+There is no way to run a Windows container without the namespace filtering in
+place. This means that system privileges cannot be asserted in the context of the
+host, and thus privileged containers are not available on Windows.
+Containers cannot assume an identity from the host because the Security Account Manager
+(SAM) is separate.
-| Kubernetes version | Windows Server LTSC releases | Windows Server SAC releases |
-| --- | --- | --- | --- |
-| *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
-| *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |
-| *Kubernetes v1.22* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |
+#### Memory reservations {#resource-management-memory}
-Information on the different Windows Server servicing channels including their
-support models can be found at
-[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
+Windows does not have an out-of-memory process killer as Linux does. Windows always
+treats all user-mode memory allocations as virtual, and pagefiles are mandatory
+(on Linux, the kubelet will by default not start with swap space enabled).
-We don't expect all Windows customers to update the operating system for their
-apps frequently. Upgrading your applications is what dictates and necessitates
-upgrading or introducing new nodes to the cluster. For the customers that
-chose to upgrade their operating system for containers running on Kubernetes,
-we will offer guidance and step-by-step instructions when we add support for a
-new operating system version. This guidance will include recommended upgrade
-procedures for upgrading user applications together with cluster nodes.
-Windows nodes adhere to Kubernetes
-[version-skew policy](/docs/setup/release/version-skew-policy/) (node to control plane
-versioning) the same way as Linux nodes do today.
+Windows nodes do not overcommit memory for processes running in containers. The
+net effect is that Windows won't reach out of memory conditions the same way Linux
+does, and processes page to disk instead of being subject to out of memory (OOM)
+termination. If memory is over-provisioned and all physical memory is exhausted,
+then paging can slow down performance.
+You can place bounds on memory use for workloads using the kubelet
+parameters `--kubelet-reserve` and/or `--system-reserve`; these account
+for memory usage on the node (outside of containers), and reduce
+[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)).
+As you deploy workloads, set resource limits on containers. This also subtracts from
+`NodeAllocatable` and prevents the scheduler from adding more pods once a node is full.
-The Windows Server Host Operating System is subject to the
-[Windows Server ](https://www.microsoft.com/en-us/cloud-platform/windows-server-pricing)
-licensing. The Windows Container images are subject to the
-[Supplemental License Terms for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/images-eula).
+{{< note >}}
+When you set memory resource limits for Windows containers, you should either set a
+limit and leave the memory request unspecified, or set the request equal to the limit.
+{{< /note >}}
-Windows containers with process isolation have strict compatibility rules,
-[where the host OS version must match the container base image OS version](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility).
-Once we support Windows containers with Hyper-V isolation in Kubernetes, the
-limitation and compatibility rules will change.
+On Windows, good practice to avoid over-provisioning is to configure the kubelet
+with a system reserved memory of at least 2GiB to account for Windows, Kubernetes
+and container runtime overheads.
-#### Pause Image
+#### CPU reservations {#resource-management-cpu}
-Kubernetes maintains a multi-architecture image that includes support for Windows.
-For Kubernetes v1.22 the recommended pause image is `k8s.gcr.io/pause:3.5`.
-The [source code](https://github.com/kubernetes/kubernetes/tree/master/build/pause)
-is available on GitHub.
+To account for CPU use by the operating system, the container runtime, and by
+Kubernetes host processes such as the kubelet, you can (and should) reserve a
+percentage of total CPU. You should determine this CPU reservation taking account of
+to the number of CPU cores available on the node. To decide on the CPU percentage to
+reserve, identify the maximum pod density for each node and monitor the CPU usage of
+the system services running there, then choose a value that meets your workload needs.
-Microsoft maintains a multi-architecture image with Linux and Windows amd64 support at `mcr.microsoft.com/oss/kubernetes/pause:3.5`.
-This image is built from the same source as the Kubernetes maintained image but all of the Windows binaries are [authenticode signed](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft.
-The Microsoft maintained image is recommended for production environments when signed binaries are required.
+You can place bounds on CPU usage for workloads using the
+kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to
+account for CPU usage on the node (outside of containers).
+This reduces `NodeAllocatable`.
+The cluster-wide scheduler then takes this reservation into account when determining
+pod placement.
-#### Compute
+On Windows, the kubelet supports a command-line flag to set the priority of the
+kubelet process: `--windows-priorityclass`. This flag allows the kubelet process to get
+more CPU time slices when compared to other processes running on the Windows host.
+More information on the allowable values and their meaning is available at
+[Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class).
+To ensure that running Pods do not starve the kubelet of CPU cycles, set this flag to `ABOVE_NORMAL_PRIORITY_CLASS` or above.
-From an API and kubectl perspective, Windows containers behave in much the
-same way as Linux-based containers. However, there are some notable
-differences in key functionality which are outlined in the
-[limitation section](#limitations).
+## Compatibility and limitations {#limitations}
-Key Kubernetes elements work the same way in Windows as they do in Linux. In
-this section, we talk about some of the key workload enablers and how they map
-to Windows.
+Some node features are only available if you use a specific
+[container runtime](#container-runtime); others are not available on Windows nodes,
+including:
+
+* HugePages: not supported for Windows containers
+* Privileged containers: not supported for Windows containers
+* TerminationGracePeriod: requires containerD
+
+Not all features of shared namespaces are supported. See [API compatibility](#api)
+for more details.
+
+See [Windows OS version compatibility](#windows-os-version-support) for details on
+the Windows versions that Kubernetes is tested against.
+
+From an API and kubectl perspective, Windows containers behave in much the same
+way as Linux-based containers. However, there are some notable differences in key
+functionality which are outlined in this section.
+
+### Comparison with Linux {#compatibility-linux-similarities}
+
+Key Kubernetes elements work the same way in Windows as they do in Linux. This
+section refers to several key workload enablers and how they map to Windows.
* [Pods](/docs/concepts/workloads/pods/)
- A Pod is the basic building block of Kubernetes–the smallest and simplest
- unit in the Kubernetes object model that you create or deploy. You may not
- deploy Windows and Linux containers in the same Pod. All containers in a Pod
- are scheduled onto a single Node where each Node represents a specific
- platform and architecture. The following Pod capabilities, properties and
- events are supported with Windows containers:
+ A Pod is the basic building block of Kubernetes–the smallest and simplest unit in
+ the Kubernetes object model that you create or deploy. You may not deploy Windows and
+ Linux containers in the same Pod. All containers in a Pod are scheduled onto a single
+ Node where each Node represents a specific platform and architecture. The following
+ Pod capabilities, properties and events are supported with Windows containers:
* Single or multiple containers per Pod with process isolation and volume sharing
- * Pod status fields
+ * Pod `status` fields
* Readiness and Liveness probes
* postStart & preStop container lifecycle events
* ConfigMap, Secrets: as environment variables or volumes
- * EmptyDir
+ * `emptyDir` volumes
* Named pipe host mounts
* Resource limits
-* [Controllers](/docs/concepts/workloads/controllers/)
-
- Kubernetes controllers handle the desired state of Pods. The following
- workload controllers are supported with Windows containers:
-
+* [Workload resources](/docs/concepts/workloads/controllers/) including:
* ReplicaSet
- * ReplicationController
* Deployments
* StatefulSets
* DaemonSet
* Job
* CronJob
+ * ReplicationController
+* {{< glossary_tooltip text="Services" term_id="service" >}}
+ See [Load balancing and Services](#load-balancing-and-services) for more details.
-* [Services](/docs/concepts/services-networking/service/)
-
- A Kubernetes Service is an abstraction which defines a logical set of Pods
- and a policy by which to access them - sometimes called a micro-service. You
- can use services for cross-operating system connectivity. In Windows, services
- can utilize the following types, properties and capabilities:
-
- * Service Environment variables
- * NodePort
- * ClusterIP
- * LoadBalancer
- * ExternalName
- * Headless services
-
-Pods, Controllers and Services are critical elements to managing Windows
+Pods, workload resources, and Services are critical elements to managing Windows
workloads on Kubernetes. However, on their own they are not enough to enable
the proper lifecycle management of Windows workloads in a dynamic cloud native
-environment. We added support for the following features:
+environment. Kubernetes also supports:
+* `kubectl exec`
* Pod and container metrics
-* Horizontal Pod Autoscaler support
-* kubectl Exec
-* Resource Quotas
+* {{< glossary_tooltip text="Horizontal pod autoscaling" term_id="horizontal-pod-autoscaler" >}}
+* {{< glossary_tooltip text="Resource quotas" term_id="resource-quota" >}}
* Scheduler preemption
-#### Container Runtime
-##### Docker EE
-
-{{< feature-state for_k8s_version="v1.14" state="stable" >}}
-
-Docker EE-basic 19.03+ is the recommended container runtime for all Windows
-Server versions. This works with the dockershim code included in the kubelet.
-
-##### CRI-ContainerD
-
-{{< feature-state for_k8s_version="v1.20" state="stable" >}}
-
-{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ can
-also be used as the container runtime for Windows Kubernetes nodes.
-
-Learn how to
-[install ContainerD on a Windows](/docs/setup/production-environment/container-runtimes/#install-containerd).
-
-#### Persistent Storage
-
-Kubernetes [volumes](/docs/concepts/storage/volumes/) enable complex
-applications, with data persistence and Pod volume sharing requirements, to be
-deployed on Kubernetes. Management of persistent volumes associated with a
-specific storage back-end or protocol includes actions such as:
-provisioning/de-provisioning/resizing of volumes, attaching/detaching a volume
-to/from a Kubernetes node and mounting/dismounting a volume to/from individual
-containers in a pod that needs to persist data. The code implementing these
-volume management actions for a specific storage back-end or protocol is
-shipped in the form of a Kubernetes volume
-[plugin](/docs/concepts/storage/volumes/#types-of-volumes). The following
-broad classes of Kubernetes volume plugins are supported on Windows:
-
-##### In-tree Volume Plugins
-
-Code associated with in-tree volume plugins ship as part of the core
-Kubernetes code base. Deployment of in-tree volume plugins do not require
-installation of additional scripts or deployment of separate containerized
-plugin components. These plugins can handle: provisioning/de-provisioning and
-resizing of volumes in the storage backend, attaching/detaching of volumes
-to/from a Kubernetes node and mounting/dismounting a volume to/from individual
-containers in a pod. The following in-tree plugins support Windows nodes:
-
-* [awsElasticBlockStore](/docs/concepts/storage/volumes/#awselasticblockstore)
-* [azureDisk](/docs/concepts/storage/volumes/#azuredisk)
-* [azureFile](/docs/concepts/storage/volumes/#azurefile)
-* [gcePersistentDisk](/docs/concepts/storage/volumes/#gcepersistentdisk)
-* [vsphereVolume](/docs/concepts/storage/volumes/#vspherevolume)
-
-##### FlexVolume Plugins
-
-Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume)
-plugins ship as out-of-tree scripts or binaries that need to be deployed
-directly on the host. FlexVolume plugins handle attaching/detaching of volumes
-to/from a Kubernetes node and mounting/dismounting a volume to/from individual
-containers in a pod. Provisioning/De-provisioning of persistent volumes
-associated with FlexVolume plugins may be handled through an external
-provisioner that is typically separate from the FlexVolume plugins. The
-following FlexVolume
-[plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows),
-deployed as powershell scripts on the host, support Windows nodes:
-
-* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
-* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd)
-
-##### CSI Plugins
-
-{{< feature-state for_k8s_version="v1.22" state="stable" >}}
-
-Code associated with {{< glossary_tooltip text="CSI" term_id="csi" >}} plugins
-ship as out-of-tree scripts and binaries that are typically distributed as
-container images and deployed using standard Kubernetes constructs like
-DaemonSets and StatefulSets. CSI plugins handle a wide range of volume
-management actions in Kubernetes: provisioning/de-provisioning/resizing of
-volumes, attaching/detaching of volumes to/from a Kubernetes node and
-mounting/dismounting a volume to/from individual containers in a pod,
-backup/restore of persistent data using snapshots and cloning.
-
-CSI plugins communicate with a CSI node plugin which performs the local storage operations.
-On Windows nodes CSI node plugins typically call APIs exposed by the community-managed
-[csi-proxy](https://github.com/kubernetes-csi/csi-proxy) which handles the local storage operations.
-
-Please refer to the deployment guide of the environment where you wish to deploy a Windows CSI plugin
-for further details around installation.
-You may also refer to the following [installation steps](https://github.com/kubernetes-csi/csi-proxy#installation).
-
-#### Networking
+### Networking on Windows nodes {#compatibility-networking}
Networking for Windows containers is exposed through
[CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/).
Windows containers function similarly to virtual machines in regards to
-networking. Each container has a virtual network adapter (vNIC) which is
-connected to a Hyper-V virtual switch (vSwitch). The Host Networking Service
-(HNS) and the Host Compute Service (HCS) work together to create containers
-and attach container vNICs to networks. HCS is responsible for the management
-of containers whereas HNS is responsible for the management of networking
-resources such as:
+networking. Each container has a virtual network adapter (vNIC) which is connected
+to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the
+Host Compute Service (HCS) work together to create containers and attach container
+vNICs to networks. HCS is responsible for the management of containers whereas HNS
+is responsible for the management of networking resources such as:
* Virtual networks (including creation of vSwitches)
* Endpoints / vNICs
* Namespaces
-* Policies (Packet encapsulations, Load-balancing rules, ACLs, NAT'ing rules, etc.)
+* Policies including packet encapsulations, load-balancing rules, ACLs, and NAT rules.
-The following service spec types are supported:
+#### Container networking {#networking}
-* NodePort
-* ClusterIP
-* LoadBalancer
-* ExternalName
+The Windows HNS and vSwitch implement namespacing and can
+create virtual NICs as needed for a pod or container. However, many configurations such
+as DNS, routes, and metrics are stored in the Windows registry database rather than as
+files inside `/etc`, which is how Linux stores those configurations. The Windows registry for the container
+is separate from that of the host, so concepts like mapping `/etc/resolv.conf` from
+the host into a container don't have the same effect they would on Linux. These must
+be configured using Windows APIs run in the context of that container. Therefore
+CNI implementations need to call the HNS instead of relying on file mappings to pass
+network details into the pod or container.
-##### Network modes
+The following networking functionality is _not_ supported on Windows nodes:
+
+* Host networking mode
+* Local NodePort access from the node itself (works for other nodes or external clients)
+* More than 64 backend pods (or unique destination addresses) for a single Service
+* IPv6 communication between Windows pods connected to overlay networks
+* Local Traffic Policy in non-DSR mode
+* Outbound communication using the ICMP protocol via the `win-overlay`, `win-bridge`, or using the Azure-CNI plugin.\
+ Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions, and this means:
+ * ICMP packets directed to destinations within the same network (such as pod to pod communication via ping) work as expected and without any limitations;
+ * TCP/UDP packets work as expected and without any limitations;
+ * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) cannot be transposed and thus will not be routed back to their source;
+ * Since TCP/UDP packets can still be transposed, you can substitute `ping ` with `curl ` to get some debugging insight into connectivity with the outside world.
+
+Overlay networking support in kube-proxy is a beta feature. In addition, it requires
+[KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887)
+to be installed on Windows Server 2019.
+
+#### Network modes
Windows supports five different networking drivers/modes: L2bridge, L2tunnel,
-Overlay, Transparent, and NAT. In a heterogeneous cluster with Windows and
-Linux worker nodes, you need to select a networking solution that is
-compatible on both Windows and Linux. The following out-of-tree plugins are
-supported on Windows, with recommendations on when to use each CNI:
+Overlay (beta), Transparent, and NAT. In a heterogeneous cluster with Windows and Linux
+worker nodes, you need to select a networking solution that is compatible on both
+Windows and Linux. The following out-of-tree plugins are supported on Windows,
+with recommendations on when to use each CNI:
-
-
-
-
Network Driver
-
Description
-
Container Packet Modifications
-
Network Plugins
-
Network Plugin Characteristics
-
-
-
-
-
L2bridge
-
Containers are attached to an external vSwitch. Containers are attached
- to the underlay network, although the physical network doesn't need to learn
- the container. MACs because they are rewritten on ingress/egress.
-
-
- MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS
- OutboundNAT policy.
-
- Azure-CNI allows integration of containers with Azure vNET, and allows them
- to leverage the set of capabilities that
- Azure Virtual Network
- provides. For example, securely connect to Azure services or use Azure NSGs.
- See azure-cni
- for some examples.
-
-
-
-
Overlay (Overlay networking for Windows in Kubernetes is in Alpha stage)
-
- Containers are given a vNIC connected to an external vSwitch. Each overlay
- network gets its own IP subnet, defined by a custom IP prefix.The overlay
- network driver uses VXLAN encapsulation.
-
- win-overlay should be used when virtual container networks are desired to
- be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs
- to be re-used for different overlay networks (which have different VNID tags)
- if you are restricted on IPs in your datacenter. This option requires
- KB4489899 on Windows Server
- 2019.
-
- Requires an external vSwitch. Containers are attached to an external
- vSwitch which enables intra-pod communication via logical networks (logical
- switches and routers).
-
-
- Packet is encapsulated either via
- GENEVE,
- STT tunneling to reach
- pods which are not on the same host. Packets are forwarded or dropped
- via the tunnel metadata information supplied by the ovn network controller.
-
- NAT is done for north-south communication.
-
- Deploy via Ansible.
- Distributed ACLs can be applied via Kubernetes policies. IPAM support.
- Load-balancing can be achieved without kube-proxy. NATing is done without
- using iptables/netsh.
-
-
-
-
NAT (not used in Kubernetes)
-
- Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is
- provided using an internal component called
- WinNAT.
-
+| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics |
+| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ |
+| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. | MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS OutboundNAT policy. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. |
+| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) |
+| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [Win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. |
+| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host. Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller. NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. |
+| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://blogs.technet.microsoft.com/virtualization/2016/05/25/windows-nat-winnat-capabilities-and-limitations/) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness |
-As outlined above, the [Flannel](https://github.com/coreos/flannel) CNI
-[meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)
-is also supported on
-[Windows](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental)
-via the [VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)
-(**alpha support** ; delegates to win-overlay) and
-[host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw)
-(stable support; delegates to win-bridge). This plugin supports delegating to
-one of the reference CNI plugins (win-overlay, win-bridge), to work in
-conjunction with Flannel daemon on Windows (Flanneld) for automatic node
-subnet lease assignment and HNS network creation. This plugin reads in its own
-configuration file (cni.conf), and aggregates it with the environment
-variables from the FlannelD generated subnet.env file. It then delegates to
-one of the reference CNI plugins for network plumbing, and sends the correct
-configuration containing the node-assigned subnet to the IPAM plugin (e.g.
-host-local).
+As outlined above, the [Flannel](https://github.com/coreos/flannel)
+CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel)
+is also [supported](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) on Windows via the
+[VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay)
+and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge).
-For the node, pod, and service objects, the following network flows are
-supported for TCP/UDP traffic:
+This plugin supports delegating to one of the reference CNI plugins (win-overlay,
+win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for
+automatic node subnet lease assignment and HNS network creation. This plugin reads
+in its own configuration file (cni.conf), and aggregates it with the environment
+variables from the FlannelD generated subnet.env file. It then delegates to one of
+the reference CNI plugins for network plumbing, and sends the correct configuration
+containing the node-assigned subnet to the IPAM plugin (for example: `host-local`).
-* Pod -> Pod (IP)
-* Pod -> Pod (Name)
-* Pod -> Service (Cluster IP)
-* Pod -> Service (PQDN, but only if there are no ".")
-* Pod -> Service (FQDN)
-* Pod -> External (IP)
-* Pod -> External (DNS)
-* Node -> Pod
-* Pod -> Node
+For Node, Pod, and Service objects, the following network flows are supported for
+TCP/UDP traffic:
-##### IP address management (IPAM) {#ipam}
+* Pod → Pod (IP)
+* Pod → Pod (Name)
+* Pod → Service (Cluster IP)
+* Pod → Service (PQDN, but only if there are no ".")
+* Pod → Service (FQDN)
+* Pod → external (IP)
+* Pod → external (DNS)
+* Node → Pod
+* Pod → Node
+
+#### CNI plugin limitations
+
+* Windows reference network plugins win-bridge and win-overlay do not implement
+ [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0,
+ due to a missing `CHECK` implementation.
+* The Flannel VXLAN CNI plugin has the following limitations on Windows:
+
+1. Node-pod connectivity isn't possible by design. It's only possible for local pods with Flannel v0.12.0 (or higher).
+2. Flannel is restricted to using VNI 4096 and UDP port 4789. See the official
+ [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)
+ backend docs for more details on these parameters.
+
+#### IP address management (IPAM) {#ipam}
The following IPAM options are supported on Windows:
-* [Host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
+* [host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local)
* HNS IPAM (Inbox platform IPAM, this is a fallback when no IPAM is set)
-* [Azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only)
+* [azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only)
-##### Load balancing and Services
+#### Load balancing and Services
+
+A Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}} is an abstraction
+that defines a logical set of Pods and a means to access them over a network.
+In a cluster that includes Windows nodes, you can use the following types of Service:
+
+ * `NodePort`
+ * `ClusterIP`
+ * `LoadBalancer`
+ * `ExternalName`
+
+Windows container networking differs in some important ways from Linux networking.
+The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) provides
+additional details and background.
On Windows, you can use the following settings to configure Services and load
balancing behavior:
{{< table caption="Windows Service Settings" >}}
-
-
-
-
-
Feature
-
Description
-
Supported Kubernetes version
-
Supported Windows OS build
-
How to enable
-
-
-
-
-
Session affinity
-
- Ensures that connections from a particular client are passed to the same
- Pod each time.
-
- Set service.spec.sessionAffinity to "ClientIP"
-
-
-
-
Direct Server Return (DSR)
-
- Load balancing mode where the IP address fixups and the LBNAT occurs at
- the container vSwitch port directly; service traffic arrives with the source
- IP set as the originating pod IP.
-
-
v1.20+
-
- Windows Server 2019
-
-
- Set the following flags in kube-proxy:
- --feature-gates="WinDSR=true" --enable-dsr=true
-
-
-
-
Preserve-Destination
-
- Skips DNAT of service traffic, thereby preserving the virtual IP of the target
- service in packets reaching the backend Pod. Also disables node-node forwarding.
-
-
v1.20+
-
Windows Server, version 1903 (or higher)
-
- Set "preserve-destination": "true" in service annotations
- and enable DSR in kube-proxy.
-
-
-
-
IPv4/IPv6 dual-stack networking
-
- Native IPv4-to-IPv4 in parallel with IPv6-to-IPv6 communications to, from,
- and within a cluster
-
- Ensures that source IP of incoming ingress traffic gets preserved. Also
- disables node-node forwarding.
-
-
v1.20+
-
Windows Server, version 2019 (or higher)
-
- Set service.spec.externalTrafficPolicy to "Local" and enable
- DSR in kube-proxy.
-
-
-
-
-
+| Feature | Description | Supported Kubernetes version | Supported Windows OS build | How to enable |
+| ------- | ----------- | ----------------------------- | -------------------------- | ------------- |
+| Session affinity | Ensures that connections from a particular client are passed to the same Pod each time. | v1.20+ | [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) (or higher) | Set `service.spec.sessionAffinity` to "ClientIP" |
+| Direct Server Return (DSR) | Load balancing mode where the IP address fixups and the LBNAT occurs at the container vSwitch port directly; service traffic arrives with the source IP set as the originating pod IP. | v1.20+ | Windows Server 2019 | Set the following flags in kube-proxy: `--feature-gates="WinDSR=true" --enable-dsr=true` |
+| Preserve-Destination | Skips DNAT of service traffic, thereby preserving the virtual IP of the target service in packets reaching the backend Pod. Also disables node-node forwarding. | v1.20+ | Windows Server, version 1903 (or higher) | Set `"preserve-destination": "true"` in service annotations and enable DSR in kube-proxy. |
+| IPv4/IPv6 dual-stack networking | Native IPv4-to-IPv4 in parallel with IPv6-to-IPv6 communications to, from, and within a cluster | v1.19+ | Windows Server, version 2019 | See [IPv4/IPv6 dual-stack](#ipv4ipv6-dual-stack) |
+| Client IP preservation | Ensures that source IP of incoming ingress traffic gets preserved. Also disables node-node forwarding. | v1.20+ | Windows Server, version 2019 | Set `service.spec.externalTrafficPolicy` to "Local" and enable DSR in kube-proxy |
{{< /table >}}
-#### IPv4/IPv6 dual-stack
-
-You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using
-the `IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/). See
-[enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack)
-for more details.
-
-On Windows, using IPv6 with Kubernetes require Windows Server, version 2004
-(kernel version 10.0.19041.610) or later.
-
-Overlay (VXLAN) networks on Windows do not support dual-stack networking today.
-
-### Limitations
-
-Windows is only supported as a worker node in the Kubernetes architecture and
-component matrix. This means that a Kubernetes cluster must always include
-Linux master nodes, zero or more Linux worker nodes, and zero or more Windows
-worker nodes.
-
-#### Resource Handling
-
-Linux cgroups are used as a pod boundary for resource controls in Linux.
-Containers are created within that boundary for network, process and file
-system isolation. The cgroups APIs can be used to gather cpu/io/memory stats.
-In contrast, Windows uses a Job object per container with a system namespace
-filter to contain all processes in a container and provide logical isolation
-from the host. There is no way to run a Windows container without the
-namespace filtering in place. This means that system privileges cannot be
-asserted in the context of the host, and thus privileged containers are not
-available on Windows. Containers cannot assume an identity from the host
-because the Security Account Manager (SAM) is separate.
-
-#### Resource Reservations
-
-##### Memory Reservations
-
-Windows does not have an out-of-memory process killer as Linux does. Windows
-always treats all user-mode memory allocations as virtual, and pagefiles are
-mandatory. The net effect is that Windows won't reach out of memory conditions
-the same way Linux does, and processes page to disk instead of being subject
-to out of memory (OOM) termination. If memory is over-provisioned and all
-physical memory is exhausted, then paging can slow down performance.
-
-Keeping memory usage within reasonable bounds is possible using the kubelet
-parameters `--kubelet-reserve` and/or `--system-reserve` to account for memory
-usage on the node (outside of containers). This reduces
-[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
-
-As you deploy workloads, use resource limits (must set only limits or limits
-must equal requests) on containers. This also subtracts from NodeAllocatable
-and prevents the scheduler from adding more pods once a node is full.
-
-A best practice to avoid over-provisioning is to configure the kubelet with a
-system reserved memory of at least 2GB to account for Windows, Docker, and
-Kubernetes processes.
-
-##### CPU Reservations
-
-To account for Windows, Docker and other Kubernetes host processes it is
-recommended to reserve a percentage of CPU so they are able to respond to
-events. This value needs to be scaled based on the number of CPU cores
-available on the Windows node.To determine this percentage a user should
-identify the maximum pod density for each of their nodes and monitor the CPU
-usage of the system services choosing a value that meets their workload needs.
-
-Keeping CPU usage within reasonable bounds is possible using the kubelet
-parameters `--kubelet-reserve` and/or `--system-reserve` to account for CPU
-usage on the node (outside of containers). This reduces
-[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
-
-#### Feature Restrictions
-
-* TerminationGracePeriod: not implemented
-* Single file mapping: to be implemented with CRI-ContainerD
-* Termination message: to be implemented with CRI-ContainerD
-* Privileged Containers: not currently supported in Windows containers
-* HugePages: not currently supported in Windows containers
-* The existing node problem detector is Linux-only and requires privileged
- containers. In general, we don't expect this to be used on Windows because
- privileged containers are not supported
-* Not all features of shared namespaces are supported (see API section for
- more details)
-
-#### Difference in behavior of flags when compared to Linux
-
-The behavior of the following kubelet flags is different on Windows nodes as described below:
-
-* `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update
- Node Allocatable
-
-* Eviction by using `--enforce-node-allocable` is not implemented.
-
-* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented.
-
-* `MemoryPressure` Condition is not implemented.
-
-* There are no OOM eviction actions taken by the kubelet.
-
-* Kubelet running on the windows node does not have memory restrictions.
- `--kubelet-reserve` and `--system-reserve` do not set limits on kubelet or
- processes running on the host. This means kubelet or a process on the host
- could cause memory resource starvation outside the node-allocatable and
- scheduler
-
-* An additional flag to set the priority of the kubelet process is available
- on the Windows nodes called `--windows-priorityclass`. This flag allows
- kubelet process to get more CPU time slices when compared to other processes
- running on the Windows host. More information on the allowable values and
- their meaning is available at
- [Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class).
- In order for kubelet to always have enough CPU cycles it is recommended to set
- this flag to `ABOVE_NORMAL_PRIORITY_CLASS` and above.
-
-#### Storage
-
-Windows has a layered filesystem driver to mount container layers and create a
-copy filesystem based on NTFS. All file paths in the container are resolved
-only within the context of that container.
-
-* With Docker Volume mounts can only target a directory in the container, and
- not an individual file. This limitation does not exist with CRI-containerD.
-
-* Volume mounts cannot project files or directories back to the host
- filesystem
-
-* Read-only filesystems are not supported because write access is always
- required for the Windows registry and SAM database. However, read-only
- volumes are supported
-
-* Volume user-masks and permissions are not available. Because the SAM is not
- shared between the host & container, there's no mapping between them. All
- permissions are resolved within the context of the container
-
-As a result, the following storage functionality is not supported on Windows nodes:
-
-* Volume subpath mounts. Only the entire volume can be mounted in a Windows container.
-* Subpath volume mounting for Secrets
-* Host mount projection
-* DefaultMode (due to UID/GID dependency)
-* Read-only root filesystem. Mapped volumes still support readOnly
-* Block device mapping
-* Memory as the storage medium
-* File system features like uui/guid, per-user Linux filesystem permissions
-* NFS based storage/volume support
-* Expanding the mounted volume (resizefs)
-
-#### Networking {#networking-limitations}
-
-Windows Container Networking differs in some important ways from Linux
-networking. The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture)
-contains additional details and background.
-
-The Windows host networking service and virtual switch implement namespacing
-and can create virtual NICs as needed for a pod or container. However, many
-configurations such as DNS, routes, and metrics are stored in the Windows
-registry database rather than /etc/... files as they are on Linux. The Windows
-registry for the container is separate from that of the host, so concepts like
-mapping /etc/resolv.conf from the host into a container don't have the same
-effect they would on Linux. These must be configured using Windows APIs run in
-the context of that container. Therefore CNI implementations need to call the
-HNS instead of relying on file mappings to pass network details into the pod
-or container.
-
-The following networking functionality is not supported on Windows nodes
-
-* Host networking mode is not available for Windows pods.
-
-* Local NodePort access from the node itself fails (works for other nodes or
- external clients).
-
-* Accessing service VIPs from nodes will be available with a future release of
- Windows Server.
-
-* A single service can only support up to 64 backend pods / unique destination IPs.
-
-* Overlay networking support in kube-proxy is a beta feature. In addition, it
- requires [KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887)
- to be installed on Windows Server 2019.
-
-* Local Traffic Policy in non-DSR mode.
-
-* Windows containers connected to overlay networks do not support
- communicating over the IPv6 stack. There is outstanding Windows platform
- work required to enable this network driver to consume IPv6 addresses and
- subsequent Kubernetes work in kubelet, kube-proxy, and CNI plugins.
-
-* Outbound communication using the ICMP protocol via the win-overlay,
- win-bridge, and Azure-CNI plugin. Specifically, the Windows data plane
- ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/))
- doesn't support ICMP packet transpositions. This means:
-
- * ICMP packets directed to destinations within the same network (e.g. pod to
- pod communication via ping) work as expected and without any limitations
-
- * TCP/UDP packets work as expected and without any limitations
-
- * ICMP packets directed to pass through a remote network (e.g. pod to
- external internet communication via ping) cannot be transposed and thus
- will not be routed back to their source
-
- * Since TCP/UDP packets can still be transposed, one can substitute
- `ping ` with `curl ` to be able to debug connectivity
- to the outside world.
-
-These features were added in Kubernetes v1.15:
-
-* `kubectl port-forward`
-
-##### CNI Plugins
-
-* Windows reference network plugins `win-bridge` and `win-overlay` do not
- currently implement [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md)
- v0.4.0 due to missing "CHECK" implementation.
-
-* The Flannel VXLAN CNI has the following limitations on Windows:
-
- 1. Node-pod connectivity isn't possible by design. It's only possible for
- local pods with Flannel v0.12.0 (or higher).
-
- 1. We are restricted to using VNI 4096 and UDP port 4789. The VNI limitation
- is being worked on and will be overcome in a future release (open-source
- flannel changes). See the official
- [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)
- backend docs for more details on these parameters.
-
-##### DNS {#dns-limitations}
-
-* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names
- with a '.' as a FQDN and skips PQDN resolution
-
-* On Linux, you have a DNS suffix list, which is used when trying to resolve
- PQDNs. On Windows, we only have 1 DNS suffix, which is the DNS suffix
- associated with that pod's namespace (mydns.svc.cluster.local for example).
- Windows can resolve FQDNs and services or names resolvable with only that
- suffix. For example, a pod spawned in the default namespace, will have the DNS
- suffix `default.svc.cluster.local`. On a Windows pod, you can resolve both
- `kubernetes.default.svc.cluster.local` and `kubernetes`, but not the
- in-betweens, like `kubernetes.default` or `kubernetes.default.svc`.
-
-* On Windows, there are multiple DNS resolvers that can be used. As these come
- with slightly different behaviors, using the `Resolve-DNSName` utility for
- name query resolutions is recommended.
-
-##### IPv6
-
-Kubernetes on Windows does not support single-stack "IPv6-only" networking.
-However,dual-stack IPv4/IPv6 networking for pods and nodes with single-family
-services is supported.
-See [IPv4/IPv6 dual-stack networking](#ipv4ipv6-dual-stack) for more details.
-
##### Session affinity
Setting the maximum session sticky time for Windows services using
`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` is not supported.
-##### Security
+#### DNS {#dns-limitations}
-Secrets are written in clear text on the node's volume (as compared to
-tmpfs/in-memory on linux). This means customers have to do two things:
+* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a
+ `.` as a FQDN and skips FQDN resolution
+* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On
+ Windows, you can only have 1 DNS suffix, which is the DNS suffix associated with that
+ pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs
+ and services or names resolvable with just that suffix. For example, a pod spawned
+ in the default namespace, will have the DNS suffix **default.svc.cluster.local**.
+ Inside a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local**
+ and **kubernetes**, but not the in-betweens, like **kubernetes.default** or
+ **kubernetes.default.svc**.
+* On Windows, there are multiple DNS resolvers that can be used. As these come with
+ slightly different behaviors, using the `Resolve-DNSName` utility for name query
+ resolutions is recommended.
-1. Use file ACLs to secure the secrets file location
-1. Use volume-level encryption using
- [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server)
+#### IPv6 networking
-[RunAsUsername](/docs/tasks/configure-pod-container/configure-runasusername)
-can be specified for Windows Pod's or Container's to execute the Container
-processes as a node-default user. This is roughly equivalent to
-[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups).
+Kubernetes on Windows does not support single-stack "IPv6-only" networking. However,
+dual-stack IPv4/IPv6 networking for pods and nodes with single-family services
+is supported.
-Linux specific pod security context privileges such as SELinux, AppArmor,
-Seccomp, Capabilities (POSIX Capabilities), and others are not supported.
+You can enable IPv4/IPv6 dual-stack networking for `l2bridge` networks using the
+`IPv6DualStack` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
+See [enable IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#enable-ipv4ipv6-dual-stack) for more details.
-In addition, as mentioned already, privileged containers are not supported on
-Windows.
+{{< note >}}
+Overlay (VXLAN) networks on Windows do not support dual-stack networking.
+{{< /note >}}
-#### API
+### Persistent storage {#compatibility-storage}
-There are no differences in how most of the Kubernetes APIs work for Windows.
-The subtleties around what's different come down to differences in the OS and
-container runtime. In certain situations, some properties on workload APIs
-such as Pod or Container were designed with an assumption that they are
-implemented on Linux, failing to run on Windows.
+Windows has a layered filesystem driver to mount container layers and create a copy
+filesystem based on NTFS. All file paths in the container are resolved only within
+the context of that container.
+
+* With Docker, volume mounts can only target a directory in the container, and not
+ an individual file. This limitation does not exist with CRI-containerD runtime.
+* Volume mounts cannot project files or directories back to the host filesystem.
+* Read-only filesystems are not supported because write access is always required
+ for the Windows registry and SAM database. However, read-only volumes are supported.
+* Volume user-masks and permissions are not available. Because the SAM is not shared
+ between the host & container, there's no mapping between them. All permissions are
+ resolved within the context of the container.
+
+As a result, the following storage functionality is not supported on Windows nodes:
+
+* Volume subpath mounts: only the entire volume can be mounted in a Windows container
+* Subpath volume mounting for Secrets
+* Host mount projection
+* Read-only root filesystem (mapped volumes still support `readOnly`)
+* Block device mapping
+* Memory as the storage medium (for example, `emptyDir.medium` set to `Memory`)
+* File system features like uid/gid; per-user Linux filesystem permissions
+* DefaultMode (due to UID/GID dependency)
+* NFS based storage/volume support
+* Expanding the mounted volume (resizefs)
+
+Kubernetes {{< glossary_tooltip text="volumes" term_id="volume" >}} enable complex
+applications, with data persistence and Pod volume sharing requirements, to be deployed
+on Kubernetes. Management of persistent volumes associated with a specific storage
+back-end or protocol includes actions such as provisioning/de-provisioning/resizing
+of volumes, attaching/detaching a volume to/from a Kubernetes node and
+mounting/dismounting a volume to/from individual containers in a pod that needs to
+persist data.
+
+The code implementing these volume management actions for a specific storage back-end
+or protocol is shipped in the form of a Kubernetes volume
+[plugin](/docs/concepts/storage/volumes/#types-of-volumes).
+The following broad classes of Kubernetes volume plugins are supported on Windows:
+
+##### In-tree volume plugins
+
+Code associated with in-tree volume plugins ship as part of the core Kubernetes code
+base. Deployment of in-tree volume plugins do not require installation of additional
+scripts or deployment of separate containerized plugin components. These plugins can
+handle provisioning/de-provisioning and resizing of volumes in the storage backend,
+attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a
+volume to/from individual containers in a pod. The following in-tree plugins support
+persistent storage on Windows nodes:
+
+* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore)
+* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk)
+* [`azureFile`](/docs/concepts/storage/volumes/#azurefile)
+* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk)
+* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume)
+
+#### FlexVolume plugins
+
+Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume)
+plugins ship as out-of-tree scripts or binaries that need to be deployed directly
+on the host. FlexVolume plugins handle attaching/detaching of volumes to/from a
+Kubernetes node and mounting/dismounting a volume to/from individual containers
+in a pod. Provisioning/De-provisioning of persistent volumes associated
+with FlexVolume plugins may be handled through an external provisioner that
+is typically separate from the FlexVolume plugins. The following FlexVolume
+[plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows),
+deployed as PowerShell scripts on the host, support Windows nodes:
+
+* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd)
+* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd)
+
+#### CSI plugins
+
+{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+
+Code associated with {{< glossary_tooltip text="CSI" term_id="csi" >}} plugins ship
+as out-of-tree scripts and binaries that are typically distributed as container
+images and deployed using standard Kubernetes constructs like DaemonSets and
+StatefulSets.
+CSI plugins handle a wide range of volume management actions in Kubernetes:
+provisioning/de-provisioning/resizing of volumes, attaching/detaching of volumes
+to/from a Kubernetes node and mounting/dismounting a volume to/from individual
+containers in a pod, backup/restore of persistent data using snapshots and cloning.
+CSI plugins typically consist of node plugins (that run on each node as a DaemonSet)
+and controller plugins.
+
+CSI node plugins (especially those associated with persistent volumes exposed as
+either block devices or over a shared file-system) need to perform various privileged
+operations like scanning of disk devices, mounting of file systems, etc. These
+operations differ for each host operating system. For Linux worker nodes, containerized
+CSI node plugins are typically deployed as privileged containers. For Windows worker
+nodes, privileged operations for containerized CSI node plugins is supported using
+[csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed,
+stand-alone binary that needs to be pre-installed on each Windows node.
+
+For more details, refer to the deployment guide of the CSI plugin you wish to deploy.
+
+### Command line options for the kubelet {#kubelet-compatibility}
+
+The behavior of some kubelet command line options behave differently on Windows, as described below:
+
+* The `--windows-priorityclass` lets you set the scheduling priority of the kubelet process (see [CPU resource management](#resource-management-cpu))
+* The `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)
+* Eviction by using `--enforce-node-allocable` is not implemented
+* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented
+* A kubelet running on a Windows node does not have memory
+ restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on
+ kubelet or processes running on the host. This means kubelet or a process on the host
+ could cause memory resource starvation outside the node-allocatable and scheduler.
+* The `MemoryPressure` Condition is not implemented
+* The kubelet does not take OOM eviction actions
+
+### API compatibility {#api}
+
+There are no differences in how most of the Kubernetes APIs work for Windows. The
+subtleties around what's different come down to differences in the OS and container
+runtime. In certain situations, some properties on workload resources were designed
+under the assumption that they would be implemented on Linux, and fail to run on Windows.
At a high level, these OS concepts are different:
-* Identity - Linux uses userID (UID) and groupID (GID) which are represented
- as integer types. User and group names are not canonical - they are an alias
- in `/etc/groups` or `/etc/passwd` back to UID+GID. Windows uses a larger
- binary security identifier (SID) which is stored in the Windows Security
- Access Manager (SAM) database. This database is not shared between the host
- and containers, or between containers.
-
-* File permissions - Windows uses an access control list based on SIDs, rather
- than a bitmask of permissions and UID+GID
-
-* File paths - convention on Windows is to use `\` instead of `/`. The Go IO
- libraries accept both types of file path separators. However, when you're
- setting a path or command line that's interpreted inside a container, `\` may
- be needed.
-
+* Identity - Linux uses userID (UID) and groupID (GID) which
+ are represented as integer types. User and group names
+ are not canonical - they are just an alias in `/etc/groups`
+ or `/etc/passwd` back to UID+GID. Windows uses a larger binary
+ [security identifier](https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers) (SID)
+ which is stored in the Windows Security Access Manager (SAM) database. This
+ database is not shared between the host and containers, or between containers.
+* File permissions - Windows uses an access control list based on (SIDs), whereas
+ POSIX systems such as Linux use a bitmask based on object permissions and UID+GID,
+ plus _optional_ access control lists.
+* File paths - the convention on Windows is to use `\` instead of `/`. The Go IO
+ libraries typically accept both and just make it work, but when you're setting a
+ path or command line that's interpreted inside a container, `\` may be needed.
* Signals - Windows interactive apps handle termination differently, and can
implement one or more of these:
-
- * A UI thread handles well-defined messages including `WM_CLOSE`
-
- * Console apps handle ctrl-c or ctrl-break using a Control Handler
-
+ * A UI thread handles well-defined messages including `WM_CLOSE`.
+ * Console apps handle Ctrl-C or Ctrl-break using a Control Handler.
* Services register a Service Control Handler function that can accept
- `SERVICE_CONTROL_STOP` control codes
+ `SERVICE_CONTROL_STOP` control codes.
-Exit Codes follow the same convention where 0 is success, nonzero is failure.
-The specific error codes may differ across Windows and Linux. However, exit
-codes passed from the Kubernetes components (kubelet, kube-proxy) are
-unchanged.
+Container exit codes follow the same convention where 0 is success, and nonzero is failure.
+The specific error codes may differ across Windows and Linux. However, exit codes
+passed from the Kubernetes components (kubelet, kube-proxy) are unchanged.
-##### V1.Container
+##### Field compatibility for container specifications {#compatibility-v1-pod-spec-containers}
-* V1.Container.ResourceRequirements.limits.cpu and
- V1.Container.ResourceRequirements.limits.memory - Windows doesn't use hard
- limits for CPU allocations. Instead, a share system is used. The existing
- fields based on millicores are scaled into relative shares that are followed
- by the Windows scheduler.
- See [kuberuntime/helpers_windows.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go),
- and [resource controls in Microsoft docs](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls)
+The following list documents differences between how Pod container specifications
+work between Windows and Linux:
- * Huge pages are not implemented in the Windows container runtime, and are
- not available. They require
- [asserting a user privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)
- that's not configurable for containers.
-
-* V1.Container.ResourceRequirements.requests.cpu and
- V1.Container.ResourceRequirements.requests.memory - Requests are subtracted
+* `limits.cpu` and `limits.memory` - Windows doesn't use hard limits
+ for CPU allocations. Instead, a share system is used.
+ The fields based on millicores are scaled into
+ relative shares that are followed by the Windows scheduler
+ See [`kuberuntime/helpers_windows.go`](https://github.com/kubernetes/kubernetes/blob/master/pkg/kubelet/kuberuntime/helpers_windows.go),
+ and [Implementing resource controls for Windows containers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/resource-controls)
+ in Microsoft's virtualization documentation.
+* Huge pages are not implemented in the Windows container
+ runtime, and are not available. They require [asserting a user
+ privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support)
+ that's not configurable for containers.
+* `requests.cpu` and `requests.memory` - requests are subtracted
from node available resources, so they can be used to avoid overprovisioning a
- node. However, they cannot be used to guarantee resources in an
- overprovisioned node. They should be applied to all containers as a best
- practice if the operator wants to avoid overprovisioning entirely.
+ node. However, they cannot be used to guarantee resources in an overprovisioned
+ node. They should be applied to all containers as a best practice if the operator
+ wants to avoid overprovisioning entirely.
+* `securityContext.allowPrivilegeEscalation` -
+ not possible on Windows; none of the capabilities are hooked up
+* `securityContext.capabilities` -
+ POSIX capabilities are not implemented on Windows
+* `securityContext.privileged` -
+ Windows doesn't support privileged containers
+* `securityContext.procMount` -
+ Windows doesn't have a `/proc` filesystem
+* `securityContext.readOnlyRootFilesystem` -
+ not possible on Windows; write access is required for registry & system
+ processes to run inside the container
+* `EcurityContext.runAsGroup` -
+ not possible on Windows as there is no GID support
+* `ecurityContext.runAsNonRoot` -
+ Windows does not have a root user. The closest equivalent is `ContainerAdministrator`
+ which is an identity that doesn't exist on the node.
+* `securityContext.runAsUser` -
+ use [`runAsUsername`](/docs/tasks/configure-pod-container/configure-runasusername)
+ instead
+* `securityContext.seLinuxOptions` -
+ not possible on Windows as SELinux is Linux-specific
+* `terminationMessagePath` -
+ this has some limitations in that Windows doesn't support mapping single files. The
+ default value is `/dev/termination-log`, which does work because it does not
+ exist on Windows by default.
-* V1.Container.SecurityContext.allowPrivilegeEscalation - not possible on
- Windows, none of the capabilities are hooked up
+##### Field compatibility for Pod specifications {#compatibility-v1-pod}
-* V1.Container.SecurityContext.Capabilities - POSIX capabilities are not
- implemented on Windows
+The following list documents differences between how Pod specifications work between Windows and Linux:
-* V1.Container.SecurityContext.privileged - Windows doesn't support privileged
- containers
-
-* V1.Container.SecurityContext.procMount - Windows doesn't have a /proc filesystem
-
-* V1.Container.SecurityContext.readOnlyRootFilesystem - not possible on
- Windows, write access is required for registry & system processes to run
- inside the container
-
-* V1.Container.SecurityContext.runAsGroup - not possible on Windows, no GID support
-
-* V1.Container.SecurityContext.runAsNonRoot - Windows does not have a root
- user. The closest equivalent is ContainerAdministrator which is an identity
- that doesn't exist on the node.
-
-* V1.Container.SecurityContext.runAsUser - not possible on Windows, no UID
- support as int.
-
-* V1.Container.SecurityContext.seLinuxOptions - not possible on Windows, no SELinux
-
-* V1.Container.terminationMessagePath - this has some limitations in that
- Windows doesn't support mapping single files. The default value is
- `/dev/termination-log`, which does work because it does not exist on Windows by
- default.
-
-##### V1.Pod
-
-* V1.Pod.hostIPC, v1.pod.hostpid - host namespace sharing is not possible on Windows
-
-* V1.Pod.hostNetwork - There is no Windows OS support to share the host network
-
-* V1.Pod.dnsPolicy - `ClusterFirstWithHostNet` is not supported because Host
- Networking is not supported on Windows.
-
-* V1.Pod.podSecurityContext - see V1.PodSecurityContext below
-
-* V1.Pod.shareProcessNamespace - this is a beta feature, and depends on Linux
- namespaces which are not implemented on Windows. Windows cannot share
- process namespaces or the container's root filesystem. Only the network can be
- shared.
-
-* V1.Pod.terminationGracePeriodSeconds - this is not fully implemented in
- Docker on Windows, see:
- [reference](https://github.com/moby/moby/issues/25982). The behavior today is
- that the `ENTRYPOINT` process is sent `CTRL_SHUTDOWN_EVENT`, then Windows waits 5
- seconds by default, and finally shuts down all processes using the normal
- Windows shutdown behavior. The 5 second default is actually in the Windows
- registry [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183),
+* `hostIPC` and `hostpid` - host namespace sharing is not possible on Windows
+* `hostNetwork` - There is no Windows OS support to share the host network
+* `dnsPolicy` - setting the Pod `dnsPolicy` to `ClusterFirstWithHostNet` is
+ not supported on Windows because host networking is not provided. Pods always
+ run with a container network.
+* `podSecurityContext` (see below)
+* `shareProcessNamespace` - this is a beta feature, and depends on Linux namespaces
+ which are not implemented on Windows. Windows cannot share process namespaces or
+ the container's root filesystem. Only the network can be shared.
+* `terminationGracePeriodSeconds` - this is not fully implemented in Docker on Windows,
+ see the [GitHub issue](https://github.com/moby/moby/issues/25982).
+ The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT,
+ then Windows waits 5 seconds by default, and finally shuts down
+ all processes using the normal Windows shutdown behavior. The 5
+ second default is actually in the Windows registry
+ [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183),
so it can be overridden when the container is built.
+* `volumeDevices` - this is a beta feature, and is not implemented on Windows.
+ Windows cannot attach raw block devices to pods.
+* `volumes`
+ * If you define an `emptyDir` volume, you cannot set its volume source to `memory`.
+* You cannot enable `mountPropagation` for volume mounts as this is not
+ supported on Windows.
-* V1.Pod.volumeDevices - this is a beta feature, and is not implemented on
- Windows. Windows cannot attach raw block devices to pods.
+##### Field compatibility for Pod security context {#compatibility-v1-pod-spec-containers-securitycontext}
-* V1.Pod.volumes - EmptyDir, Secret, ConfigMap, HostPath - all work and have
- tests in TestGrid
+None of the Pod [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) fields work on Windows.
- * V1.emptyDirVolumeSource - the Node default medium is disk on Windows.
- Memory is not supported, as Windows does not have a built-in RAM disk.
+### Node problem detector
-* V1.VolumeMount.mountPropagation - mount propagation is not supported on Windows.
+The node problem detector (see
+[Monitor Node Health](/docs/tasks/debug-application-cluster/monitor-node-health/))
+is not compatible with Windows.
-##### V1.PodSecurityContext
+### Pause container
-None of the PodSecurityContext fields work on Windows. They're listed here for
-reference.
+In a Kubernetes Pod, an infrastructure or “pause” container is first created
+to host the container. In Linux, the cgroups and namespaces that make up a pod
+need a process to maintain their continued existence; the pause process provides
+this. Containers that belong to the same pod, including infrastructure and worker
+containers, share a common network endpoint (same IPv4 and / or IPv6 address, same
+network port spaces). Kubernetes uses pause containers to allow for worker containers
+crashing or restarting without losing any of the networking configuration.
-* V1.PodSecurityContext.SELinuxOptions - SELinux is not available on Windows
+Kubernetes maintains a multi-architecture image that includes support for Windows.
+For Kubernetes v1.22 the recommended pause image is `k8s.gcr.io/pause:3.5`.
+The [source code](https://github.com/kubernetes/kubernetes/tree/master/build/pause)
+is available on GitHub.
-* V1.PodSecurityContext.RunAsUser - provides a UID, not available on Windows
+Microsoft maintains a different multi-architecture image, with Linux and Windows
+amd64 support, that you can find as `mcr.microsoft.com/oss/kubernetes/pause:3.5`.
+This image is built from the same source as the Kubernetes maintained image but
+all of the Windows binaries are [authenticode signed](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft.
+The Kubernetes project recommends using the Microsoft maintained image if you are
+deploying to a production or production-like environment that requires signed
+binaries.
-* V1.PodSecurityContext.RunAsGroup - provides a GID, not available on Windows
+### Container runtimes {#container-runtime}
-* V1.PodSecurityContext.RunAsNonRoot - Windows does not have a root user. The
- closest equivalent is ContainerAdministrator which is an identity that
- doesn't exist on the node.
+You need to install a
+{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}
+into each node in the cluster so that Pods can run there.
-* V1.PodSecurityContext.SupplementalGroups - provides GID, not available on Windows
+The following container runtimes work with Windows:
-* V1.PodSecurityContext.Sysctls - these are part of the Linux sysctl
- interface. There's no equivalent on Windows.
+{{% thirdparty-content %}}
-#### Operating System Version Restrictions
+#### cri-containerd
-Windows has strict compatibility rules, where the host OS version must match
-the container base image OS version. Only Windows containers with a container
-operating system of Windows Server 2019 are supported. Hyper-V isolation of
-containers, enabling some backward compatibility of Windows container image
-versions, is planned for a future release.
+{{< feature-state for_k8s_version="v1.20" state="stable" >}}
-## Getting Help and Troubleshooting {#troubleshooting}
+You can use {{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+
+as the container runtime for Kubernetes nodes that run Windows.
-Your main source of help for troubleshooting your Kubernetes cluster should
-start with this
-[section](/docs/tasks/debug-application-cluster/troubleshooting/). Some
-additional, Windows-specific troubleshooting help is included in this section.
-Logs are an important element of troubleshooting issues in Kubernetes. Make
-sure to include them any time you seek troubleshooting assistance from other
-contributors. Follow the instructions in the SIG-Windows
-[contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs).
+Learn how to [install ContainerD on a Windows node](/docs/setup/production-environment/container-runtimes/#install-containerd).
-* How do I know start.ps1 completed successfully?
+{{< note >}}
+There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)
+when using GMSA with containerd to access Windows network shares, which requires a
+kernel patch.
+{{< /note >}}
- You should see kubelet, kube-proxy, and (if you chose Flannel as your
- networking solution) flanneld host-agent processes running on your node, with
- running logs being displayed in separate PowerShell windows. In addition to
- this, your Windows node should be listed as "Ready" in your Kubernetes
- cluster.
+#### Docker EE
-* Can I configure the Kubernetes node processes to run in the background as services?
+{{< feature-state for_k8s_version="v1.14" state="stable" >}}
- Kubelet and kube-proxy are already configured to run as native Windows
- Services, offering resiliency by re-starting the services automatically in the
- event of failure (for example a process crash). You have two options for
- configuring these node components as services.
+[Docker EE](https://docs.mirantis.com/containers/v3.0/dockeree-products/dee-intro.html)-basic 19.03+ is available as a container runtime for all Windows Server versions. This works with the legacy dockershim adapter.
- * As native Windows Services
+See [Install Docker](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/deploy-containers-on-server#install-docker) for more information.
- Kubelet & kube-proxy can be run as native Windows Services using `sc.exe`.
+## Windows OS version compatibility {#windows-os-version-support}
- ```powershell
- # Create the services for kubelet and kube-proxy in two separate commands
- sc.exe create binPath= " --service "
+On Windows nodes, strict compatibility rules apply where the host OS version must
+match the container base image OS version. Only Windows containers with a container
+operating system of Windows Server 2019 are fully supported.
- # Please note that if the arguments contain spaces, they must be escaped.
- sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' "
+For Kubernetes v1.22, operating system compatibility for Windows nodes (and Pods)
+is as follows:
- # Start the services
- Start-Service kubelet
- Start-Service kube-proxy
+Windows Server LTSC release
+: Windows Server 2019
- # Stop the service
- Stop-Service kubelet (-Force)
- Stop-Service kube-proxy (-Force)
+Windows Server SAC release
+: Windows Server version 2004, Windows Server version 20H2
- # Query the service status
- Get-Service kubelet
- Get-Service kube-proxy
- ```
+The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) also applies.
- * Using nssm.exe
+## Security for Windows nodes {#security}
- You can also always use alternative service managers like
- [`nssm.exe`](https://nssm.cc/) to run these processes (flanneld, kubelet &
- kube-proxy) in the background for you. You can use this
- [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1),
- leveraging `nssm.exe` to register kubelet, kube-proxy, and `flanneld.exe`
- to run as Windows services in the background.
+On Windows, data from Secrets are written out in clear text onto the node's local
+storage (as compared to using tmpfs / in-memory filesystems on Linux). As a cluster
+operator, you should take both of the following additional measures:
- ```powershell
- register-svc.ps1 -NetworkMode -ManagementIP -ClusterCIDR -KubeDnsServiceIP -LogDir
- ```
+1. Use file ACLs to secure the Secrets' file location.
+1. Apply volume-level encryption using [BitLocker](https://docs.microsoft.com/en-us/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server).
- The parameters are explained below:
+[RunAsUsername](/docs/tasks/configure-pod-container/configure-runasusername)
+can be specified for Windows Pods or containers to execute the container
+processes as a node-default user. This is roughly equivalent to
+[RunAsUser](/docs/concepts/policy/pod-security-policy/#users-and-groups).
- - `NetworkMode`: The network mode l2bridge (flannel host-gw, also the
- default value) or overlay (flannel vxlan) chosen as a network solution
- - `ManagementIP`: The IP address assigned to the Windows node. You can use
- `ipconfig` to find this.
- - `ClusterCIDR`: The cluster subnet range. (Default: 10.244.0.0/16)
- - `KubeDnsServiceIP`: The Kubernetes DNS service IP. (Default: 10.96.0.10)
- - `LogDir`: The directory where kubelet and kube-proxy logs are redirected
- into their respective output files. (Default value C:\k)
+Linux-specific pod security context privileges such as SELinux, AppArmor, Seccomp, or capabilities (POSIX capabilities), and others are not supported.
- If the above referenced script is not suitable, you can manually configure
- `nssm.exe` using the following examples.
+Privileged containers are [not supported](#compatibility-v1-pod-spec-containers-securitycontext) on Windows.
- Register flanneld.exe:
-
- ```powershell
- nssm install flanneld C:\flannel\flanneld.exe
- nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1
- nssm set flanneld AppEnvironmentExtra NODE_NAME=
- nssm set flanneld AppDirectory C:\flannel
- nssm start flanneld
- ```
-
- Register kubelet.exe:
-
- ```powershell
- nssm install kubelet C:\k\kubelet.exe
- nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
- nssm set kubelet AppDirectory C:\k
- nssm start kubelet
- ```
-
- Register kube-proxy.exe (l2bridge / host-gw):
-
- ```powershell
- nssm install kube-proxy C:\k\kube-proxy.exe
- nssm set kube-proxy AppDirectory c:\k
- nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false
- nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
- nssm set kube-proxy DependOnService kubelet
- nssm start kube-proxy
- ```
-
- Register kube-proxy.exe (overlay / vxlan):
-
- ```powershell
- nssm install kube-proxy C:\k\kube-proxy.exe
- nssm set kube-proxy AppDirectory c:\k
- nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false
- nssm set kube-proxy DependOnService kubelet
- nssm start kube-proxy
- ```
-
- For initial troubleshooting, you can use the following flags in
- [`nssm.exe`](https://nssm.cc/) to redirect stdout and stderr to a output file:
-
- ```powershell
- nssm set AppStdout C:\k\mysvc.log
- nssm set AppStderr C:\k\mysvc.log
- ```
-
- For additional details, see official [nssm usage](https://nssm.cc/usage) docs.
-
-* My Windows Pods do not have network connectivity
-
- If you are using virtual machines, ensure that MAC spoofing is enabled on
- all the VM network adapter(s).
-
-* My Windows Pods cannot ping external resources
-
- Windows Pods do not have outbound rules programmed for the ICMP protocol
- today. However, TCP/UDP is supported. When trying to demonstrate connectivity
- to resources outside of the cluster, please substitute `ping ` with
- corresponding `curl ` commands.
-
- If you are still facing problems, most likely your network configuration in
- [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)
- deserves some extra attention. You can always edit this static file. The
- configuration update will apply to any newly created Kubernetes resources.
-
- One of the Kubernetes networking requirements (see
- [Kubernetes network model](/docs/concepts/cluster-administration/networking/))
- is for cluster communication to occur without NAT internally. To honor this
- requirement, there is an
- [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)
- for all the communication where we do not want outbound NAT to occur. However,
- this also means that you need to exclude the external IP you are trying to
- query from the ExceptionList. Only then will the traffic originating from your
- Windows pods be SNAT'ed correctly to receive a response from the outside
- world. In this regard, your ExceptionList in `cni.conf` should look as
- follows:
-
- ```conf
- "ExceptionList": [
- "10.244.0.0/16", # Cluster subnet
- "10.96.0.0/12", # Service subnet
- "10.127.130.0/24" # Management (host) subnet
- ]
- ```
-
-* My Windows node cannot access NodePort service
-
- Local NodePort access from the node itself fails. This is a known
- limitation. NodePort access works from other nodes or external clients.
-
-* vNICs and HNS endpoints of containers are being deleted
-
- This issue can be caused when the `hostname-override` parameter is not
- passed to
- [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/).
- To resolve it, users need to pass the hostname to kube-proxy as follows:
-
- ```powershell
- C:\k\kube-proxy.exe --hostname-override=$(hostname)
- ```
-
-* With flannel my nodes are having issues after rejoining a cluster
-
- Whenever a previously deleted node is being re-joined to the cluster,
- flannelD tries to assign a new pod subnet to the node. Users should remove the
- old pod subnet configuration files in the following paths:
-
- ```powershell
- Remove-Item C:\k\SourceVip.json
- Remove-Item C:\k\SourceVipRequest.json
- ```
-
-* After launching `start.ps1`, flanneld is stuck in "Waiting for the Network
- to be created"
-
- There are numerous reports of this
- [issue](https://github.com/coreos/flannel/issues/1066); most likely it is a
- timing issue for when the management IP of the flannel network is set. A
- workaround is to relaunch start.ps1 or relaunch it manually as follows:
-
- ```powershell
- PS C:> [Environment]::SetEnvironmentVariable("NODE_NAME", "")
- PS C:> C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1
- ```
-
-* My Windows Pods cannot launch because of missing `/run/flannel/subnet.env`
-
- This indicates that Flannel didn't launch correctly. You can either try to
- restart flanneld.exe or you can copy the files over manually from
- `/run/flannel/subnet.env` on the Kubernetes master to
- `C:\run\flannel\subnet.env` on the Windows worker node and modify the
- `FLANNEL_SUBNET` row to a different number. For example, if node subnet
- 10.244.4.1/24 is desired:
-
- ```none
- FLANNEL_NETWORK=10.244.0.0/16
- FLANNEL_SUBNET=10.244.4.1/24
- FLANNEL_MTU=1500
- FLANNEL_IPMASQ=true
- ```
-
-* My Windows node cannot access my services using the service IP
-
- This is a known limitation of the current networking stack on Windows.
- Windows Pods are able to access the service IP however.
-
-* No network adapter is found when starting kubelet
-
- The Windows networking stack needs a virtual adapter for Kubernetes
- networking to work. If the following commands return no results (in an admin
- shell), virtual network creation — a necessary prerequisite for Kubelet to
- work — has failed:
-
- ```powershell
- Get-HnsNetwork | ? Name -ieq "cbr0"
- Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
- ```
-
- Often it is worthwhile to modify the
- [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7)
- parameter of the start.ps1 script, in cases where the host's network adapter
- isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1`
- script to see if there are errors during virtual network creation.
-
-* My Pods are stuck at "Container Creating" or restarting over and over
-
- Check that your pause image is compatible with your OS version. The
- [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)
- assume that both the OS and the containers are version 1803. If you have a
- later version of Windows, such as an Insider build, you need to adjust the
- images accordingly. Please refer to the Microsoft's
- [Docker repository](https://hub.docker.com/u/microsoft/) for images.
- Regardless, both the pause image Dockerfile and the sample service expect
- the image to be tagged as :latest.
+## Getting help and troubleshooting {#troubleshooting}
-* DNS resolution is not properly working
+Your main source of help for troubleshooting your Kubernetes cluster should start
+with the [Troubleshooting](/docs/tasks/debug-application-cluster/troubleshooting/)
+page.
- Check the [DNS limitations for Windows](#dns-limitations).
+Some additional, Windows-specific troubleshooting help is included
+in this section. Logs are an important element of troubleshooting
+issues in Kubernetes. Make sure to include them any time you seek
+troubleshooting assistance from other contributors. Follow the
+instructions in the
+SIG Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs).
-* `kubectl port-forward` fails with "unable to do port forwarding: wincat not found"
+### Node-level troubleshooting {#troubleshooting-node}
- Port forwarding support for Windows requires wincat.exe to be available in the
- [pause infrastructure container](#pause-image).
- Ensure you are using a supported image that is compatable with your Windows OS version.
- If you would like to build your own pause infrastructure container be sure to include
- [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat).
+1. How do I know `start.ps1` completed successfully?
-* My Kubernetes installation is failing because my Windows Server node is
- behind a proxy
+ You should see kubelet, kube-proxy, and (if you chose Flannel as your networking
+ solution) flanneld host-agent processes running on your node, with running logs
+ being displayed in separate PowerShell windows. In addition to this, your Windows
+ node should be listed as "Ready" in your Kubernetes cluster.
- If you are behind a proxy, the following PowerShell environment variables
- must be defined:
-
- ```PowerShell
- [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
- [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
- ```
-
-* What is a `pause` container?
+1. Can I configure the Kubernetes node processes to run in the background as services?
- In a Kubernetes Pod, an infrastructure or "pause" container is first created
- to host the container endpoint. Containers that belong to the same pod,
- including infrastructure and worker containers, share a common network
- namespace and endpoint (same IP and port space). Pause containers are needed
- to accommodate worker containers crashing or restarting without losing any of
- the networking configuration.
+ The kubelet and kube-proxy are already configured to run as native Windows Services,
+ offering resiliency by re-starting the services automatically in the event of
+ failure (for example a process crash). You have two options for configuring these
+ node components as services.
- Refer to the [pause image](#pause-image) section to find the recommended version
- of the pause image.
+ 1. As native Windows Services
+
+ You can run the kubelet and kube-proxy as native Windows Services using `sc.exe`.
+
+ ```powershell
+ # Create the services for kubelet and kube-proxy in two separate commands
+ sc.exe create binPath= " --service "
+
+ # Please note that if the arguments contain spaces, they must be escaped.
+ sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' "
+
+ # Start the services
+ Start-Service kubelet
+ Start-Service kube-proxy
+
+ # Stop the service
+ Stop-Service kubelet (-Force)
+ Stop-Service kube-proxy (-Force)
+
+ # Query the service status
+ Get-Service kubelet
+ Get-Service kube-proxy
+ ```
+
+ 1. Using `nssm.exe`
+
+ You can also always use alternative service managers like
+ [nssm.exe](https://nssm.cc/) to run these processes (flanneld,
+ kubelet & kube-proxy) in the background for you. You can use this
+ [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1),
+ leveraging nssm.exe to register kubelet, kube-proxy, and flanneld.exe to run
+ as Windows services in the background.
+
+ ```powershell
+ register-svc.ps1 -NetworkMode -ManagementIP -ClusterCIDR -KubeDnsServiceIP -LogDir
+
+ # NetworkMode = The network mode l2bridge (flannel host-gw, also the default value) or overlay (flannel vxlan) chosen as a network solution
+ # ManagementIP = The IP address assigned to the Windows node. You can use ipconfig to find this
+ # ClusterCIDR = The cluster subnet range. (Default value 10.244.0.0/16)
+ # KubeDnsServiceIP = The Kubernetes DNS service IP (Default value 10.96.0.10)
+ # LogDir = The directory where kubelet and kube-proxy logs are redirected into their respective output files (Default value C:\k)
+ ```
+
+ If the above referenced script is not suitable, you can manually configure
+ `nssm.exe` using the following examples.
+
+ ```powershell
+ # Register flanneld.exe
+ nssm install flanneld C:\flannel\flanneld.exe
+ nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1
+ nssm set flanneld AppEnvironmentExtra NODE_NAME=
+ nssm set flanneld AppDirectory C:\flannel
+ nssm start flanneld
+
+ # Register kubelet.exe
+ # Microsoft releases the pause infrastructure container at mcr.microsoft.com/oss/kubernetes/pause:1.4.1
+ nssm install kubelet C:\k\kubelet.exe
+ nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
+ nssm set kubelet AppDirectory C:\k
+ nssm start kubelet
+
+ # Register kube-proxy.exe (l2bridge / host-gw)
+ nssm install kube-proxy C:\k\kube-proxy.exe
+ nssm set kube-proxy AppDirectory c:\k
+ nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false
+ nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0
+ nssm set kube-proxy DependOnService kubelet
+ nssm start kube-proxy
+
+ # Register kube-proxy.exe (overlay / vxlan)
+ nssm install kube-proxy C:\k\kube-proxy.exe
+ nssm set kube-proxy AppDirectory c:\k
+ nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false
+ nssm set kube-proxy DependOnService kubelet
+ nssm start kube-proxy
+ ```
+
+ For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file:
+
+ ```powershell
+ nssm set AppStdout C:\k\mysvc.log
+ nssm set AppStderr C:\k\mysvc.log
+ ```
+
+ For additional details, see [NSSM - the Non-Sucking Service Manager](https://nssm.cc/usage).
+
+1. My Pods are stuck at "Container Creating" or restarting over and over
+
+ Check that your pause image is compatible with your OS version. The
+ [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)
+ assume that both the OS and the containers are version 1803. If you have a later
+ version of Windows, such as an Insider build, you need to adjust the images
+ accordingly. See [Pause container](#pause-container) for more details.
+
+### Network troubleshooting {#troubleshooting-network}
+
+1. My Windows Pods do not have network connectivity
+
+ If you are using virtual machines, ensure that MAC spoofing is **enabled** on all
+ the VM network adapter(s).
+
+1. My Windows Pods cannot ping external resources
+
+ Windows Pods do not have outbound rules programmed for the ICMP protocol. However,
+ TCP/UDP is supported. When trying to demonstrate connectivity to resources
+ outside of the cluster, substitute `ping ` with corresponding
+ `curl ` commands.
+
+ If you are still facing problems, most likely your network configuration in
+ [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf)
+ deserves some extra attention. You can always edit this static file. The
+ configuration update will apply to any new Kubernetes resources.
+
+ One of the Kubernetes networking requirements
+ (see [Kubernetes model](/docs/concepts/cluster-administration/networking/)) is
+ for cluster communication to occur without
+ NAT internally. To honor this requirement, there is an
+ [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20)
+ for all the communication where you do not want outbound NAT to occur. However,
+ this also means that you need to exclude the external IP you are trying to query
+ from the `ExceptionList`. Only then will the traffic originating from your Windows
+ pods be SNAT'ed correctly to receive a response from the outside world. In this
+ regard, your `ExceptionList` in `cni.conf` should look as follows:
+
+ ```conf
+ "ExceptionList": [
+ "10.244.0.0/16", # Cluster subnet
+ "10.96.0.0/12", # Service subnet
+ "10.127.130.0/24" # Management (host) subnet
+ ]
+ ```
+
+1. My Windows node cannot access `NodePort` type Services
+
+ Local NodePort access from the node itself fails. This is a known
+ limitation. NodePort access works from other nodes or external clients.
+
+1. vNICs and HNS endpoints of containers are being deleted
+
+ This issue can be caused when the `hostname-override` parameter is not passed to
+ [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve
+ it, users need to pass the hostname to kube-proxy as follows:
+
+ ```powershell
+ C:\k\kube-proxy.exe --hostname-override=$(hostname)
+ ```
+
+1. With flannel, my nodes are having issues after rejoining a cluster
+
+ Whenever a previously deleted node is being re-joined to the cluster, flannelD
+ tries to assign a new pod subnet to the node. Users should remove the old pod
+ subnet configuration files in the following paths:
+
+ ```powershell
+ Remove-Item C:\k\SourceVip.json
+ Remove-Item C:\k\SourceVipRequest.json
+ ```
+
+1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created"
+
+ There are numerous reports of this [issue](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to relaunch `start.ps1` or relaunch it manually as follows:
+
+ ```powershell
+ [Environment]::SetEnvironmentVariable("NODE_NAME", "")
+ C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1
+ ```
+
+1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env`
+
+ This indicates that Flannel didn't launch correctly. You can either try
+ to restart `flanneld.exe` or you can copy the files over manually from
+ `/run/flannel/subnet.env` on the Kubernetes master to `C:\run\flannel\subnet.env`
+ on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different
+ number. For example, if node subnet 10.244.4.1/24 is desired:
+
+ ```env
+ FLANNEL_NETWORK=10.244.0.0/16
+ FLANNEL_SUBNET=10.244.4.1/24
+ FLANNEL_MTU=1500
+ FLANNEL_IPMASQ=true
+ ```
+
+1. My Windows node cannot access my services using the service IP
+
+ This is a known limitation of the networking stack on Windows. However, Windows Pods can access the Service IP.
+
+1. No network adapter is found when starting the kubelet
+
+ The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for the kubelet to work — has failed:
+
+ ```powershell
+ Get-HnsNetwork | ? Name -ieq "cbr0"
+ Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*"
+ ```
+
+ Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation.
+
+1. DNS resolution is not properly working
+
+ Check the DNS limitations for Windows in this [section](#dns-limitations).
+
+1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found"
+
+ This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`. Be sure to use a supported version of Kubernetes.
+ If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat).
+
+1. My Kubernetes installation is failing because my Windows Server node is behind a proxy
+
+ If you are behind a proxy, the following PowerShell environment variables must be defined:
+
+ ```PowerShell
+ [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine)
+ [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
+ ```
### Further investigation
-If these steps don't resolve your problem, you can get help running Windows
-containers on Windows nodes in Kubernetes through:
+If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through:
* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic
-
* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/)
-
* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows)
-## Reporting Issues and Feature Requests
+### Reporting issues and feature requests
-If you have what looks like a bug, or you would like to make a feature
-request, please use the
+If you have what looks like a bug, or you would like to
+make a feature request, please use the
[GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues).
You can open issues on
-[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and
-assign them to SIG-Windows. You should first search the list of issues in case
-it was reported previously and comment with your experience on the issue and
-add additional logs. SIG-Windows Slack is also a great avenue to get some
-initial support and troubleshooting ideas prior to creating a ticket.
+[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign
+them to SIG-Windows. You should first search the list of issues in case it was
+reported previously and comment with your experience on the issue and add additional
+logs. SIG-Windows Slack is also a great avenue to get some initial support and
+troubleshooting ideas prior to creating a ticket.
-If filing a bug, please include detailed information about how to reproduce
-the problem, such as:
+If filing a bug, please include detailed information about how to reproduce the problem, such as:
-* Kubernetes version: kubectl version
-* Environment details: Cloud provider, OS distro, networking choice and
- configuration, and Docker version
+* Kubernetes version: output from `kubectl version`
+* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version
* Detailed steps to reproduce the problem
* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)
-* Tag the issue sig/windows by commenting on the issue with `/sig windows` to
- bring it to a SIG-Windows member's attention
+
+It helps if you tag the issue as **sig/windows**, by commenting on the issue with `/sig windows`. This helps to bring
+the issue to a SIG Windows member's attention
+
## {{% heading "whatsnext" %}}
-We have a lot of features in our roadmap. An abbreviated high level list is
-included below, but we encourage you to view our
-[roadmap project](https://github.com/orgs/kubernetes/projects/8) and help us make
-Windows support better by
-[contributing](https://github.com/kubernetes/community/blob/master/sig-windows/).
+### Deployment tools
-### Hyper-V isolation
+The kubeadm tool helps you to deploy a Kubernetes cluster, providing the control
+plane to manage the cluster it, and nodes to run your workloads.
+[Adding Windows nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)
+explains how to deploy Windows nodes to your cluster using kubeadm.
-Hyper-V isolation is required to enable the following use cases for Windows
-containers in Kubernetes:
+The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also provides means to automate deployment of Windows nodes.
-* Hypervisor-based isolation between pods for additional security
+### Windows distribution channels
-* Backwards compatibility allowing a node to run a newer Windows Server
- version without requiring containers to be rebuilt
+For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19).
-* Specific CPU/NUMA settings for a pod
-
-* Memory isolation and reservations
-
-Hyper-V isolation support will be added in a later release and will require
-CRI-Containerd.
-
-### Deployment with kubeadm and cluster API
-
-Kubeadm is becoming the de facto standard for users to deploy a Kubernetes
-cluster. Windows node support in kubeadm is currently a work-in-progress but a
-guide is available
-[here](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/). We are
-also making investments in cluster API to ensure Windows nodes are properly
-provisioned.
+Information on the different Windows Server servicing channels
+including their support models can be found at
+[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison).
diff --git a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
index 65249e8fc8..bf5b3f9847 100644
--- a/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
+++ b/content/en/docs/tasks/access-application-cluster/ingress-minikube.md
@@ -2,6 +2,7 @@
title: Set up Ingress on Minikube with the NGINX Ingress Controller
content_type: task
weight: 100
+min-kubernetes-server-version: 1.19
---
@@ -17,23 +18,21 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+If you are using an older Kubernetes version, switch to the documentation
+for that version.
+### Create a Minikube cluster
+
+Using Katacoda
+: {{< kat-button >}}
+
+Locally
+: If you already [installed Minikube](/docs/tasks/tools/#minikube)
+ locally, run `minikube start` to create a cluster.
-## Create a Minikube cluster
-
-1. Click **Launch Terminal**
-
- {{< kat-button >}}
-
-1. (Optional) If you installed Minikube locally, run the following command:
-
- ```shell
- minikube start
- ```
-
## Enable the Ingress controller
1. To enable the NGINX Ingress controller, run the following command:
@@ -45,14 +44,14 @@ This page shows you how to set up a simple Ingress which routes requests to Serv
1. Verify that the NGINX Ingress controller is running
- {{< tabs name="tab_with_md" >}}
- {{% tab name="minikube v1.19 or later" %}}
+ {{< tabs name="tab_with_md" >}}
+ {{% tab name="minikube v1.19 or later" %}}
```shell
kubectl get pods -n ingress-nginx
```
- {{< note >}}This can take up to a minute.{{< /note >}}
+ {{< note >}}It can take up to a minute before you see these pods running OK.{{< /note >}}
-Output:
+ The output is similar to:
```
NAME READY STATUS RESTARTS AGE
@@ -60,15 +59,14 @@ ingress-nginx-admission-create-g9g49 0/1 Completed 0 11m
ingress-nginx-admission-patch-rqp78 0/1 Completed 1 11m
ingress-nginx-controller-59b45fb494-26npt 1/1 Running 0 11m
```
- {{% /tab %}}
-
- {{% tab name="minikube v1.18.1 or earlier" %}}
+ {{% /tab %}}
+ {{% tab name="minikube v1.18.1 or earlier" %}}
```shell
kubectl get pods -n kube-system
```
-{{< note >}}This can take up to a minute.{{< /note >}}
+ {{< note >}}It can take up to a minute before you see these pods running OK.{{< /note >}}
-Output:
+ The output is similar to:
```
NAME READY STATUS RESTARTS AGE
@@ -79,133 +77,121 @@ kubernetes-dashboard-5498ccf677-b8p5h 1/1 Running 0 2m
nginx-ingress-controller-5984b97644-rnkrg 1/1 Running 0 1m
storage-provisioner 1/1 Running 0 2m
```
- {{% /tab %}}
- {{< /tabs >}}
-
-
-
- ```shell
- kubectl get pods -n ingress-nginx
- ```
-
- {{< note >}}This can take up to a minute.{{< /note >}}
-
- Output:
-
- ```shell
- NAME READY STATUS RESTARTS AGE
- ingress-nginx-admission-create-2tgrf 0/1 Completed 0 3m28s
- ingress-nginx-admission-patch-68b98 0/1 Completed 0 3m28s
- ingress-nginx-controller-59b45fb494-lzmw2 1/1 Running 0 3m28s
- ```
+ Make sure that you see a Pod with a name that starts with `nginx-ingress-controller-`.
+ {{% /tab %}}
+ {{< /tabs >}}
## Deploy a hello, world app
1. Create a Deployment using the following command:
- ```shell
- kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
- ```
+ ```shell
+ kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
+ ```
- Output:
+ The output should be:
- ```shell
- deployment.apps/web created
- ```
+ ```
+ deployment.apps/web created
+ ```
1. Expose the Deployment:
- ```shell
- kubectl expose deployment web --type=NodePort --port=8080
- ```
+ ```shell
+ kubectl expose deployment web --type=NodePort --port=8080
+ ```
- Output:
+ The output should be:
- ```shell
- service/web exposed
- ```
+ ```
+ service/web exposed
+ ```
1. Verify the Service is created and is available on a node port:
```shell
- kubectl get service web
- ```
+ kubectl get service web
+ ```
- Output:
+ The output is similar to:
- ```shell
- NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
- web NodePort 10.104.133.249 8080:31637/TCP 12m
- ```
+ ```
+ NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
+ web NodePort 10.104.133.249 8080:31637/TCP 12m
+ ```
-1. Visit the service via NodePort:
+1. Visit the Service via NodePort:
- ```shell
- minikube service web --url
- ```
+ ```shell
+ minikube service web --url
+ ```
- Output:
+ The output is similar to:
- ```shell
- http://172.17.0.15:31637
- ```
+ ```
+ http://172.17.0.15:31637
+ ```
- {{< note >}}Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.{{< /note >}}
+ {{< note >}}Katacoda environment only: at the top of the terminal panel, click the plus sign, and then click **Select port to view on Host 1**. Enter the NodePort, in this case `31637`, and then click **Display Port**.{{< /note >}}
- Output:
+ The output is similar to:
- ```shell
- Hello, world!
- Version: 1.0.0
- Hostname: web-55b8c6998d-8k564
- ```
+ ```
+ Hello, world!
+ Version: 1.0.0
+ Hostname: web-55b8c6998d-8k564
+ ```
- You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
- the app using the Ingress resource.
+ You can now access the sample app via the Minikube IP address and NodePort. The next step lets you access
+ the app using the Ingress resource.
-## Create an Ingress resource
+## Create an Ingress
-The following file is an Ingress resource that sends traffic to your Service via hello-world.info.
+The following manifest defines an Ingress that sends traffic to your Service via hello-world.info.
1. Create `example-ingress.yaml` from the following file:
- {{< codenew file="service/networking/example-ingress.yaml" >}}
+ {{< codenew file="service/networking/example-ingress.yaml" >}}
-1. Create the Ingress resource by running the following command:
+1. Create the Ingress object by running the following command:
- ```shell
- kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
- ```
+ ```shell
+ kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
+ ```
- Output:
+ The output should be:
- ```shell
- ingress.networking.k8s.io/example-ingress created
- ```
+ ```
+ ingress.networking.k8s.io/example-ingress created
+ ```
1. Verify the IP address is set:
- ```shell
- kubectl get ingress
- ```
+ ```shell
+ kubectl get ingress
+ ```
- {{< note >}}This can take a couple of minutes.{{< /note >}}
+ {{< note >}}This can take a couple of minutes.{{< /note >}}
- ```shell
- NAME CLASS HOSTS ADDRESS PORTS AGE
- example-ingress hello-world.info 172.17.0.15 80 38s
- ```
+ You should see an IPv4 address in the ADDRESS column; for example:
-1. Add the following line to the bottom of the `/etc/hosts` file.
+ ```
+ NAME CLASS HOSTS ADDRESS PORTS AGE
+ example-ingress hello-world.info 172.17.0.15 80 38s
+ ```
- {{< note >}}If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.{{< /note >}}
+1. Add the following line to the bottom of the `/etc/hosts` file on
+ your computer (you will need adminstrator access):
```
172.17.0.15 hello-world.info
```
- This sends requests from hello-world.info to Minikube.
+ {{< note >}}If you are running Minikube locally, use `minikube ip` to get the external IP. The IP address displayed within the ingress list will be the internal IP.{{< /note >}}
+
+ After you make this change, your web browser sends requests for
+ hello-world.info URLs to Minikube.
1. Verify that the Ingress controller is directing traffic:
@@ -213,9 +199,9 @@ The following file is an Ingress resource that sends traffic to your Service via
curl hello-world.info
```
- Output:
+ You should see:
- ```shell
+ ```
Hello, world!
Version: 1.0.0
Hostname: web-55b8c6998d-8k564
@@ -223,34 +209,35 @@ The following file is an Ingress resource that sends traffic to your Service via
{{< note >}}If you are running Minikube locally, you can visit hello-world.info from your browser.{{< /note >}}
-## Create Second Deployment
+## Create a second Deployment
-1. Create a v2 Deployment using the following command:
+1. Create another Deployment using the following command:
- ```shell
- kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
- ```
- Output:
+ ```shell
+ kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
+ ```
+ The output should be:
- ```shell
- deployment.apps/web2 created
- ```
+ ```
+ deployment.apps/web2 created
+ ```
-1. Expose the Deployment:
+1. Expose the second Deployment:
- ```shell
- kubectl expose deployment web2 --port=8080 --type=NodePort
- ```
+ ```shell
+ kubectl expose deployment web2 --port=8080 --type=NodePort
+ ```
- Output:
+ The output should be:
- ```shell
- service/web2 exposed
- ```
+ ```
+ service/web2 exposed
+ ```
-## Edit Ingress
+## Edit the existing Ingress {#edit-ingress}
-1. Edit the existing `example-ingress.yaml` and add the following lines:
+1. Edit the existing `example-ingress.yaml` manifest, and add the
+ following lines at the end:
```yaml
- path: /v2
@@ -264,47 +251,47 @@ The following file is an Ingress resource that sends traffic to your Service via
1. Apply the changes:
- ```shell
- kubectl apply -f example-ingress.yaml
- ```
+ ```shell
+ kubectl apply -f example-ingress.yaml
+ ```
- Output:
+ You should see:
- ```shell
- ingress.networking/example-ingress configured
- ```
+ ```
+ ingress.networking/example-ingress configured
+ ```
-## Test Your Ingress
+## Test your Ingress
1. Access the 1st version of the Hello World app.
- ```shell
- curl hello-world.info
- ```
+ ```shell
+ curl hello-world.info
+ ```
- Output:
+ The output is similar to:
- ```shell
- Hello, world!
- Version: 1.0.0
- Hostname: web-55b8c6998d-8k564
- ```
+ ```
+ Hello, world!
+ Version: 1.0.0
+ Hostname: web-55b8c6998d-8k564
+ ```
1. Access the 2nd version of the Hello World app.
- ```shell
- curl hello-world.info/v2
- ```
+ ```shell
+ curl hello-world.info/v2
+ ```
- Output:
+ The output is similar to:
- ```shell
- Hello, world!
- Version: 2.0.0
- Hostname: web2-75cd47646f-t8cjk
- ```
+ ```
+ Hello, world!
+ Version: 2.0.0
+ Hostname: web2-75cd47646f-t8cjk
+ ```
- {{< note >}}If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser.{{< /note >}}
+ {{< note >}}If you are running Minikube locally, you can visit hello-world.info and hello-world.info/v2 from your browser.{{< /note >}}
@@ -315,5 +302,3 @@ The following file is an Ingress resource that sends traffic to your Service via
* Read more about [Ingress Controllers](/docs/concepts/services-networking/ingress-controllers/)
* Read more about [Services](/docs/concepts/services-networking/service/)
-
-
diff --git a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
index 6a11b4f2d3..408438e1de 100644
--- a/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
+++ b/content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
@@ -88,11 +88,11 @@ kubectl patch pv -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
* Learn more about [PersistentVolumes](/docs/concepts/storage/persistent-volumes/).
* Learn more about [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims).
-### Reference
+### References {#reference}
-* [PersistentVolume](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolume-v1-core)
-* [PersistentVolumeClaim](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core)
-* See the `persistentVolumeReclaimPolicy` field of [PersistentVolumeSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#persistentvolumeclaim-v1-core).
+* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}}
+ * Pay attention to the `.spec.persistentVolumeReclaimPolicy` [field](https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) of PersistentVolume.
+* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}}
diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
index ffa688e1b7..9e0b49480b 100644
--- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
@@ -325,6 +325,10 @@ Here is an example:
```shell
ETCDCTL_API=3 etcdctl --endpoints 10.2.0.9:2379 snapshot restore snapshotdb
```
+Another example for restoring using etcdutl options:
+```shell
+ETCDCTL_API=3 etcdctl --data-dir snapshot restore snapshotdb
+```
For more information and examples on restoring a cluster from a snapshot file, see
[etcd disaster recovery documentation](https://etcd.io/docs/current/op-guide/recovery/#restoring-a-cluster).
diff --git a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
index 6bc41d2170..e9dd545955 100644
--- a/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
+++ b/content/en/docs/tasks/administer-cluster/dns-debugging-resolution.md
@@ -67,7 +67,7 @@ If the `nslookup` command fails, check the following:
### Check the local DNS configuration first
Take a look inside the resolv.conf file.
-(See [Inheriting DNS from the node](/docs/tasks/administer-cluster/dns-custom-nameservers/#inheriting-dns-from-the-node) and
+(See [Customizing DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers) and
[Known issues](#known-issues) below for more information)
```shell
diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md
index 66427133b2..a8cc1be51c 100644
--- a/content/en/docs/tasks/administer-cluster/encrypt-data.md
+++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md
@@ -58,8 +58,7 @@ resources:
Each `resources` array item is a separate config and contains a complete configuration. The
`resources.resources` field is an array of Kubernetes resource names (`resource` or `resource.group`)
that should be encrypted. The `providers` array is an ordered list of the possible encryption
-providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided,
-but not both in the same item).
+providers. Only one provider type may be specified per entry (`identity` or `aescbc` may be provided, but not both in the same item).
The first provider in the list is used to encrypt resources going into storage. When reading
resources from storage each provider that matches the stored data attempts to decrypt the data in
@@ -78,9 +77,9 @@ read that resource will fail until it is deleted or a valid decryption key is pr
Name | Encryption | Strength | Speed | Key Length | Other Considerations
-----|------------|----------|-------|------------|---------------------
`identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written.
-`aescbc` | AES-CBC with PKCS#7 padding | Strongest | Fast | 32-byte | The recommended choice for encryption at rest but may be slightly slower than `secretbox`.
`secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review.
`aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented.
+`aescbc` | AES-CBC with PKCS#7 padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks.
`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/)
Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider
@@ -215,5 +214,3 @@ and restart all `kube-apiserver` processes. Then run:
kubectl get secrets --all-namespaces -o json | kubectl replace -f -
```
to force all secrets to be decrypted.
-
-
diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
index 8f259ddd45..0b0139151a 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
@@ -88,6 +88,7 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc
yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
+
- Verify that the download works and has the expected version:
@@ -166,11 +167,10 @@ 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:
{{< tabs name="k8s_install_kubelet" >}}
-{{< tab name="Ubuntu, Debian or HypriotOS" >}}
-
+{{% tab name="Ubuntu, Debian or HypriotOS" %}}
# replace x in {{< skew currentVersion >}}.x-00 with the latest patch version
apt-mark unhold kubelet kubectl && \
apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \
@@ -179,15 +179,13 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no
# since apt-get version 1.1 you can also use the following method
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" %}}
# replace x in {{< skew currentVersion >}}.x-0 with the latest patch version
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
-
-{{< /tab >}}
+{{% /tab %}}
{{< /tabs >}}
+
- Restart the kubelet:
@@ -268,6 +266,7 @@ without compromising the minimum required capacity for running your workloads.
yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes
{{% /tab %}}
{{< /tabs >}}
+
- Restart the kubelet:
diff --git a/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md b/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md
index bed842b6a4..d3b888fbda 100644
--- a/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md
+++ b/content/en/docs/tasks/administer-cluster/kubelet-in-userns.md
@@ -27,8 +27,7 @@ If you are just looking for how to run a pod as a non-root user, see [SecurityCo
* [Enable systemd with user session](https://rootlesscontaine.rs/getting-started/common/login/)
* [Configure several sysctl values, depending on host Linux distribution](https://rootlesscontaine.rs/getting-started/common/sysctl/)
* [Ensure that your unprivileged user is listed in `/etc/subuid` and `/etc/subgid`](https://rootlesscontaine.rs/getting-started/common/subuid/)
-
-* `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+* Enable the `KubeletInUserNamespace` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
@@ -86,9 +85,10 @@ Rootless Docker/Podman or LXC/LXD, you are all set, and you can go to the next s
Otherwise you have to create a user namespace by yourself, by calling `unshare(2)` with `CLONE_NEWUSER`.
A user namespace can be also unshared by using command line tools such as:
+
+- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
- [RootlessKit](https://github.com/rootless-containers/rootlesskit)
- [become-root](https://github.com/giuseppe/become-root)
-- [`unshare(1)`](https://man7.org/linux/man-pages/man1/unshare.1.html)
After unsharing the user namespace, you will also have to unshare other namespaces such as mount namespace.
@@ -123,29 +123,37 @@ On your node, systemd must already be configured to allow delegation; for more d
Containers documentation.
### Configuring network
+
{{% thirdparty-content %}}
The network namespace of the Node components has to have a non-loopback interface, which can be for example configured with
-slirp4netns, VPNKit, or lxc-user-nic.
+[slirp4netns](https://github.com/rootless-containers/slirp4netns),
+[VPNKit](https://github.com/moby/vpnkit), or
+[lxc-user-nic(1)](https://www.man7.org/linux/man-pages/man1/lxc-user-nic.1.html).
The network namespaces of the Pods can be configured with regular CNI plugins.
For multi-node networking, Flannel (VXLAN, 8472/UDP) is known to work.
Ports such as the kubelet port (10250/TCP) and `NodePort` service ports have to be exposed from the Node network namespace to
-the host with an external port forwarder, such as RootlessKit, slirp4netns, or socat.
+the host with an external port forwarder, such as RootlessKit, slirp4netns, or
+[socat(1)](https://linux.die.net/man/1/socat).
-You can use the port forwarder from K3s; see https://github.com/k3s-io/k3s/blob/v1.21.2+k3s1/pkg/rootlessports/controller.go
+You can use the port forwarder from K3s.
+See [Running K3s in Rootless Mode](https://rancher.com/docs/k3s/latest/en/advanced/#known-issues-with-rootless-mode)
+for more details.
### Configuring CRI
-The kubelet relies on a container runtime. You should deploy a container runtime such as containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
+The kubelet relies on a container runtime. You should deploy a container runtime such as
+containerd or CRI-O and ensure that it is running within the user namespace before the kubelet starts.
{{< tabs name="cri" >}}
{{% tab name="containerd" %}}
Running CRI plugin of containerd in a user namespace is supported since containerd 1.4.
-Running containerd within a user namespace requires the following configuration:
+Running containerd within a user namespace requires the following configurations
+in `/etc/containerd/containerd-config.toml`.
```toml
version = 2
@@ -175,7 +183,7 @@ Running CRI-O in a user namespace is supported since CRI-O 1.22.
CRI-O requires an environment variable `_CRIO_ROOTLESS=1` to be set.
-The following configuration is also recommended:
+The following configurations (in `/etc/crio/crio.conf`) are also recommended:
```toml
[crio]
@@ -197,8 +205,8 @@ The following configuration is also recommended:
Running kubelet in a user namespace requires the following configuration:
```yaml
-kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
+kind: KubeletConfiguration
featureGates:
KubeletInUserNamespace: true
# We use cgroupfs that is delegated by systemd, so we do not use "systemd" driver
@@ -206,22 +214,23 @@ featureGates:
cgroupDriver: "cgroupfs"
```
-When the `KubeletInUserNamespace` feature gate is enabled, kubelet ignores errors that may happen during setting the following sysctl values:
+When the `KubeletInUserNamespace` feature gate is enabled, the kubelet ignores errors
+that may happen during setting the following sysctl values on the node.
+
- `vm.overcommit_memory`
- `vm.panic_on_oom`
- `kernel.panic`
- `kernel.panic_on_oops`
- `kernel.keys.root_maxkeys`
- `kernel.keys.root_maxbytes`.
- (these are sysctl values for the host, not for the containers).
Within a user namespace, the kubelet also ignores any error raised from trying to open `/dev/kmsg`.
This feature gate also allows kube-proxy to ignore an error during setting `RLIMIT_NOFILE`.
The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status.
-Running kubelet in a user namespace without using this feature gate is also possible by mounting a specially crafted proc filesystem,
-but not officially supported.
+Running kubelet in a user namespace without using this feature gate is also possible
+by mounting a specially crafted proc filesystem, but not officially supported.
### Configuring kube-proxy
@@ -251,9 +260,11 @@ For more on this, see the [Caveats and Future work](https://rootlesscontaine.rs/
on the rootlesscontaine.rs website.
## {{% heading "seealso" %}}
+
- [rootlesscontaine.rs](https://rootlesscontaine.rs/)
- [Rootless Containers 2020 (KubeCon NA 2020)](https://www.slideshare.net/AkihiroSuda/kubecon-na-2020-containerd-rootless-containers-2020)
- [Running kind with Rootless Docker](https://kind.sigs.k8s.io/docs/user/rootless/)
- [Usernetes](https://github.com/rootless-containers/usernetes)
- [Running K3s with rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
- [KEP-2033: Kubelet-in-UserNS (aka Rootless mode)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless)
+
diff --git a/content/en/docs/tasks/administer-cluster/nodelocaldns.md b/content/en/docs/tasks/administer-cluster/nodelocaldns.md
index 33417b00ad..e2038a7223 100644
--- a/content/en/docs/tasks/administer-cluster/nodelocaldns.md
+++ b/content/en/docs/tasks/administer-cluster/nodelocaldns.md
@@ -46,7 +46,7 @@ Having a local cache will help improve the latency in such scenarios.
This is the path followed by DNS Queries after NodeLocal DNSCache is enabled:
-{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." >}}
+{{< figure src="/images/docs/nodelocaldns.svg" alt="NodeLocal DNSCache flow" title="Nodelocal DNSCache flow" caption="This image shows how NodeLocal DNSCache handles DNS queries." class="diagram-medium" >}}
## Configuration
{{< note >}} The local listen IP address for NodeLocal DNSCache can be any address that can be guaranteed to not collide with any existing IP in your cluster. It's recommended to use an address with a local scope, per example, from the link-local range 169.254.0.0/16 for IPv4 or from the Unique Local Address range in IPv6 fd00::/8.
diff --git a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
index 0073feea24..754da9f7b3 100644
--- a/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
+++ b/content/en/docs/tasks/configure-pod-container/configure-gmsa.md
@@ -258,7 +258,7 @@ In the example below the Pod did not get the credspec correctly:
```PowerShell
kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe
```
-nltest.exe /parentdomain` results in the following error:
+`nltest.exe /parentdomain` results in the following error:
```
Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE
```
diff --git a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
index 384b709720..17fc9e1421 100644
--- a/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
+++ b/content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
@@ -29,13 +29,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
```sh
# Linux
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-linux-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-linux-amd64 -o kompose
# macOS
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-darwin-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-darwin-amd64 -o kompose
# Windows
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.22.0/kompose-windows-amd64.exe -o kompose.exe
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.24.0/kompose-windows-amd64.exe -o kompose.exe
chmod +x kompose
sudo mv ./kompose /usr/local/bin/kompose
diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 6328d458fb..545e268a10 100644
--- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -82,8 +82,8 @@ Now that the server is running, we will create the autoscaler using
The following command will create a Horizontal Pod Autoscaler that maintains between 1 and 10 replicas of the Pods
controlled by the php-apache deployment we created in the first step of these instructions.
Roughly speaking, HPA will increase and decrease the number of replicas
-(via the deployment) to maintain an average CPU utilization across all Pods of 50%
-(since each pod requests 200 milli-cores by `kubectl run`), this means average CPU usage of 100 milli-cores).
+(via the deployment) to maintain an average CPU utilization across all Pods of 50%.
+Since each pod requests 200 milli-cores by `kubectl run`, this means an average CPU usage of 100 milli-cores.
See [here](/docs/tasks/run-application/horizontal-pod-autoscale/#algorithm-details) for more details on the algorithm.
```shell
diff --git a/content/en/docs/tutorials/hello-minikube.md b/content/en/docs/tutorials/hello-minikube.md
index 3911ff2de6..e6398d7c72 100644
--- a/content/en/docs/tutorials/hello-minikube.md
+++ b/content/en/docs/tutorials/hello-minikube.md
@@ -69,13 +69,13 @@ By default, the dashboard is only accessible from within the internal Kubernetes
The `dashboard` command creates a temporary proxy to make the dashboard accessible from outside the Kubernetes virtual network.
To stop the proxy, run `Ctrl+C` to exit the process.
-After the command exits, the dashboard remains running in Kubernetes cluster.
+After the command exits, the dashboard remains running in the Kubernetes cluster.
You can run the `dashboard` command again to create another proxy to access the dashboard.
{{< /note >}}
## Open Dashboard with URL
-If you don't want to open a web browser, run the dashboard command with the url flag to emit a URL:
+If you don't want to open a web browser, run the dashboard command with the `--url` flag to emit a URL:
```shell
minikube dashboard --url
@@ -185,7 +185,7 @@ Kubernetes [*Service*](/docs/concepts/services-networking/service/).
4. Katacoda environment only: Click the plus sign, and then click **Select port to view on Host 1**.
-5. Katacoda environment only: Note the 5 digit port number displayed opposite to `8080` in services output. This port number is randomly generated and it can be different for you. Type your number in the port number text box, then click Display Port. Using the example from earlier, you would type `30369`.
+5. Katacoda environment only: Note the 5-digit port number displayed opposite to `8080` in services output. This port number is randomly generated and it can be different for you. Type your number in the port number text box, then click Display Port. Using the example from earlier, you would type `30369`.
This opens up a browser window that serves your app and shows the app's response.
diff --git a/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml b/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml
index dff87cf851..b4bf65834a 100644
--- a/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml
+++ b/content/en/examples/admin/dns/dns-horizontal-autoscaler.yaml
@@ -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"]
+# Remove the configmaps rule once below issue is fixed:
+# 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=
- # 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
+ # Should keep target in sync with cluster/addons/dns/kube-dns.yaml.base
+ - --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,"preventSinglePointFailure":true,"includeUnschedulableNodes":true}}
+ - --logtostderr=true
+ - --v=2
+ tolerations:
+ - key: "CriticalAddonsOnly"
+ operator: "Exists"
+ serviceAccountName: kube-dns-autoscaler
diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md
index c7597e332f..88725d5b92 100644
--- a/content/en/releases/patch-releases.md
+++ b/content/en/releases/patch-releases.md
@@ -78,10 +78,10 @@ releases may also occur in between these.
| Monthly Patch Release | Cherry Pick Deadline | Target date |
| --------------------- | -------------------- | ----------- |
-| September 2021 | 2021-09-10 | 2021-09-15 |
-| October 2021 | 2021-10-15 | 2021-10-20 |
+| October 2021 | 2021-10-22 | 2021-10-27 |
| November 2021 | 2021-11-12 | 2021-11-17 |
| December 2021 | 2021-12-10 | 2021-12-15 |
+| January 2022 | 2021-01-14 | 2021-01-19 |
## Detailed Release History for Active Branches
@@ -93,6 +93,7 @@ End of Life for **1.22** is **2022-10-28**
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
|---------------|----------------------|-------------|------|
+| 1.22.3 | 2021-10-22 | 2021-10-27 | |
| 1.22.2 | 2021-09-10 | 2021-09-15 | |
| 1.22.1 | 2021-08-16 | 2021-08-19 | |
@@ -104,6 +105,7 @@ End of Life for **1.21** is **2022-06-28**
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
| ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- |
+| 1.21.6 | 2021-10-22 | 2021-10-27 | |
| 1.21.5 | 2021-09-10 | 2021-09-15 | |
| 1.21.4 | 2021-08-07 | 2021-08-11 | |
| 1.21.3 | 2021-07-10 | 2021-07-14 | |
@@ -118,6 +120,7 @@ End of Life for **1.20** is **2022-02-28**
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
| ------------- | -------------------- | ----------- | ----------------------------------------------------------------------------------- |
+| 1.20.12 | 2021-10-22 | 2021-10-27 | |
| 1.20.11 | 2021-09-10 | 2021-09-15 | |
| 1.20.10 | 2021-08-07 | 2021-08-11 | |
| 1.20.9 | 2021-07-10 | 2021-07-14 | |
@@ -138,6 +141,7 @@ End of Life for **1.19** is **2021-10-28**
| PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE |
| ------------- | -------------------- | ----------- | ------------------------------------------------------------------------- |
+| 1.19.16 | 2021-10-22 | 2021-09-27 | |
| 1.19.15 | 2021-09-10 | 2021-09-15 | |
| 1.19.14 | 2021-08-07 | 2021-08-11 | |
| 1.19.13 | 2021-07-10 | 2021-07-14 | |
diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md
index 03910c7d4f..cf7f7b6eea 100644
--- a/content/en/releases/release-managers.md
+++ b/content/en/releases/release-managers.md
@@ -31,7 +31,7 @@ The responsibilities of each role are described below.
### Security Embargo Policy
-Some information about releases is subject to embargo and we have defined policy about how those embargos are set. Please refer [Security Embargo Policy](https://github.com/kubernetes/security/blob/master/private-distributors-list.md#embargo-policy) here for more information.
+Some information about releases is subject to embargo and we have defined policy about how those embargoes are set. Please refer to the [Security Embargo Policy](https://github.com/kubernetes/committee-security-response/blob/main/private-distributors-list.md#embargo-policy) for more information.
## Handbooks
diff --git a/content/en/training/_index.html b/content/en/training/_index.html
index 5b94d73bac..74880486a6 100644
--- a/content/en/training/_index.html
+++ b/content/en/training/_index.html
@@ -14,6 +14,9 @@ class: training
Build your cloud native career
Kubernetes is at the core of the cloud native movement. Training and certifications from the Linux Foundation and our training partners lets you invest in your career, learn Kubernetes, and make your cloud native projects successful.
+
+
+
@@ -81,6 +84,15 @@ class: training
Get Kubernetes Certified
+
+
+ Kubernetes and Cloud Native Associate (KCNA)
+
+
The Kubernetes and Cloud Native Associate (KCNA) exam demonstrates a user’s foundational knowledge and skills in Kubernetes and the wider cloud native ecosystem.
+
A certified KCNA will confirm conceptual knowledge of the entire cloud native ecosystem, particularly focusing on Kubernetes.
Certified Kubernetes Application Developer (CKAD)
diff --git a/content/es/docs/concepts/configuration/manage-resources-containers.md b/content/es/docs/concepts/configuration/manage-resources-containers.md
index f936b9107e..a74f463b7c 100644
--- a/content/es/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/es/docs/concepts/configuration/manage-resources-containers.md
@@ -329,6 +329,9 @@ spec:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
+ volumeMounts:
+ - name: ephemeral
+ mountPath: "/tmp"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
@@ -336,6 +339,12 @@ spec:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
+ volumeMounts:
+ - name: ephemeral
+ mountPath: "/tmp"
+ volumes:
+ - name: ephemeral
+ emptyDir: {}
```
### Como son programados los Pods con solicitudes de almacenamiento efímero
diff --git a/content/es/docs/reference/glossary/wg.md b/content/es/docs/reference/glossary/wg.md
new file mode 100644
index 0000000000..85c4eb7bd7
--- /dev/null
+++ b/content/es/docs/reference/glossary/wg.md
@@ -0,0 +1,19 @@
+---
+title: WG (working group)
+id: wg
+date: 2018-04-12
+full_link: https://github.com/kubernetes/community/blob/master/sig-list.md#master-working-group-list
+short_description: >
+ Facilita la discusión y/o la implementación de un proyecto que sea efímero, corto o desacoplado para un comité, {{< glossary_tooltip text="SIG" term_id="sig" >}}, o esfuerzo SIG cruzado.
+
+aka:
+tags:
+- community
+---
+ Facilita la discusión y/o la implementación de un proyecto que sea efímero, corto o desacoplado para un comité, {{< glossary_tooltip text="SIG" term_id="sig" >}}, o un esfuerzo entre varios SIGs.
+
+
+
+Los grupos de trabajo son una forma de organizar personas para completar una tarea discreta.
+
+Para más información, consulta el repositorio [kubernetes/community](https://github.com/kubernetes/community) y la lista de los [SIGs y Grupos de Trabajo (WGs).](https://github.com/kubernetes/community/blob/master/sig-list.md).
diff --git a/content/es/docs/reference/glossary/workload.md b/content/es/docs/reference/glossary/workload.md
new file mode 100644
index 0000000000..19e0ef99b8
--- /dev/null
+++ b/content/es/docs/reference/glossary/workload.md
@@ -0,0 +1,22 @@
+---
+title: Workload
+id: workloads
+date: 2019-02-13
+full_link: /docs/concepts/workloads/
+short_description: >
+ Un Workload es una aplicación que se ejecuta en Kubernetes.
+
+aka:
+tags:
+- fundamental
+---
+ Un Workload es una aplicación que se ejecuta en Kubernetes.
+
+
+
+Varios objetos clave que representan diferentes tipos o partes de un Workload
+incluyen los objetos: DaemonSet, Deployment, Job, ReplicaSet y StatefulSet.
+
+Por ejemplo, un Workload que tiene un servidor web y una base de datos podría ejecutar
+la base de datos en un {{< glossary_tooltip term_id="StatefulSet" >}} y el servidor
+web en un {{< glossary_tooltip term_id="Deployment" >}}.
diff --git a/content/es/docs/tutorials/_index.md b/content/es/docs/tutorials/_index.md
index a8748b958d..27c804973a 100644
--- a/content/es/docs/tutorials/_index.md
+++ b/content/es/docs/tutorials/_index.md
@@ -55,6 +55,8 @@ Antes de recorrer cada tutorial, recomendamos añadir un marcador a
* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
+
## Servicios
* [Using Source IP](/docs/tutorials/services/source-ip/)
diff --git a/content/fr/docs/concepts/architecture/nodes.md b/content/fr/docs/concepts/architecture/nodes.md
index b6718c6750..f493fe5b17 100644
--- a/content/fr/docs/concepts/architecture/nodes.md
+++ b/content/fr/docs/concepts/architecture/nodes.md
@@ -12,7 +12,7 @@ weight: 10
Un nœud est une machine de travail dans Kubernetes, connue auparavant sous le nom de `minion`.
Un nœud peut être une machine virtuelle ou une machine physique, selon le cluster.
Chaque nœud contient les services nécessaires à l'exécution de [pods](/docs/concepts/workloads/pods/pod/) et est géré par les composants du master.
-Les services sur un nœud incluent le [container runtime](/docs/concepts/overview/components/#node-components), kubelet and kube-proxy.
+Les services sur un nœud incluent le [container runtime](/docs/concepts/overview/components/#node-components), kubelet et kube-proxy.
Consultez la section [Le Nœud Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) dans le document de conception de l'architecture pour plus de détails.
diff --git a/content/fr/docs/concepts/services-networking/endpoint-slices.md b/content/fr/docs/concepts/services-networking/endpoint-slices.md
index f5b157bc01..7771b7fe19 100644
--- a/content/fr/docs/concepts/services-networking/endpoint-slices.md
+++ b/content/fr/docs/concepts/services-networking/endpoint-slices.md
@@ -1,5 +1,5 @@
---
-reviewers:
+reviewers:
title: EndpointSlices
feature:
title: EndpointSlices
@@ -21,14 +21,14 @@ _EndpointSlices_ offrent une méthode simple pour suivre les Endpoints d'un rés
-## Resource pour EndpointSlice {#endpointslice-resource}
+## Ressource pour EndpointSlice {#endpointslice-resource}
-Dans Kubernetes, un EndpointSlice contient des reférences à un ensemble de Endpoints.
-Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié.
-Ces EnpointSlices vont inclure des références à n'importe quels Pods qui correspondent aux selecteurs de Service.
+Dans Kubernetes, un EndpointSlice contient des références à un ensemble de Endpoints.
+Le controleur d'EndpointSlice crée automatiquement des EndpointSlices pour un Service quand un {{< glossary_tooltip text="sélecteur" term_id="selector" >}} est spécifié.
+Ces EndpointSlices vont inclure des références à n'importe quels Pods qui correspondent aux selecteurs de Service.
EndpointSlices groupent ensemble les Endpoints d'un réseau par combinaisons uniques de Services et de Ports.
-Par exemple, voici un échantillon d'une resource EndpointSlice pour le Kubernetes Service `exemple`.
+Par exemple, voici un échantillon d'une ressource EndpointSlice pour le Kubernetes Service `exemple`.
```yaml
apiVersion: discovery.k8s.io/v1beta1
@@ -53,15 +53,15 @@ endpoints:
topology.kubernetes.io/zone: us-west2-a
```
-Les EndpointSlices gérés par le contrôleur d'EndpointSlice n'auront, par défaut, pas plus de 100 Endpoints chacun.
-En dessous de cette échelle, EndpointSlices devraient mapper 1:1 les Endpoints et les Services et devraientt avoir une performance similaire.
+Les EndpointSlices gérés par le contrôleur d'EndpointSlice n'auront, par défaut, pas plus de 100 Endpoints chacun.
+En dessous de cette échelle, EndpointSlices devraient mapper 1:1 les Endpoints et les Services et devraient avoir une performance similaire.
-EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand il s'agit du routage d'un trafic interne.
+EndpointSlices peuvent agir en tant que source de vérité pour kube-proxy quand il s'agit du routage d'un trafic interne.
Lorsqu'ils sont activés, ils devraient offrir une amélioration de performance pour les services qui ont une grand quantité d'Endpoints.
### Types d'addresses
-Les EndpointSlices supportent 3 types d'addresses:
+Les EndpointSlices supportent 3 types d'addresses :
* IPv4
* IPv6
@@ -69,14 +69,14 @@ Les EndpointSlices supportent 3 types d'addresses:
### Topologie
-Chaque Endpoint dans un EnpointSlice peut contenir des informations de topologie pertinentes.
+Chaque Endpoint dans un EndpointSlice peut contenir des informations de topologie pertinentes.
Ceci est utilisé pour indiquer où se trouve un Endpoint, qui contient les informations sur le Node, zone et région correspondantes. Lorsque les valeurs sont disponibles, les labels de Topologies suivants seront définis par le contrôleur EndpointSlice:
* `kubernetes.io/hostname` - Nom du Node sur lequel l'Endpoint se situe.
* `topology.kubernetes.io/zone` - Zone dans laquelle l'Endpoint se situe.
* `topology.kubernetes.io/region` - Région dans laquelle l'Endpoint se situe.
-Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que leurs correspondances avec les EndpointSlices sont à jour.
+Le contrôleur EndpointSlice surveille les Services et les Pods pour assurer que leurs correspondances avec les EndpointSlices sont à jour.
Le contrôleur gère les EndpointSlices pour tous les Services qui ont un sélecteur - [référence: {{< glossary_tooltip text="sélecteur" term_id="selector" >}}] - specifié. Celles-ci représenteront les IPs des Pods qui correspondent au sélecteur.
### Capacité d'EndpointSlices
@@ -85,32 +85,27 @@ Les EndpointSlices sont limités à une capacité de 100 Endpoints chacun, par d
### Distribution d'EndpointSlices
-Chaque EndpointSlice a un ensemble de ports qui s'applique à tous les Endpoints dans la resource.
-Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents ports cibles pour le même port nommé, nécessitant différents EndpointSlices.
+Chaque EndpointSlice a un ensemble de ports qui s'applique à tous les Endpoints dans la ressource.
+Lorsque les ports nommés sont utilisés pour un Service, les Pods peuvent se retrouver avec différents ports cibles pour le même port nommé, nécessitant différents EndpointSlices.
Le contrôleur essaie de remplir les EndpointSlices aussi complètement que possible, mais ne les rééquilibre pas activement. La logique du contrôleur est assez simple:
-1. Itérer à travers les EnpointSlices existants, retirer les Endpoints qui ne sont plus voulus et mettre à jour les Endpoints qui ont changé.
+1. Itérer à travers les EndpointSlices existants, retirer les Endpoints qui ne sont plus voulus et mettre à jour les Endpoints qui ont changé.
2. Itérer à travers les EndpointSlices qui ont été modifiés dans la première étape et les remplir avec n'importe quel Endpoint nécéssaire.
3. S'il reste encore des Endpoints nouveaux à ajouter, essayez de les mettre dans une slice qui n'a pas été changée et/ou en créer une nouvelle.
-Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EnpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, s'il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants.
-C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlices.
+Par-dessus tout, la troisième étape priorise la limitation de mises à jour d'EndpointSlice sur une distribution complètement pleine d'EndpointSlices. Par exemple, s'il y avait 10 nouveaux Endpoints à ajouter et 2 EndpointSlices qui peuvent contenir 5 Endpoints en plus chacun; cette approche créera un nouveau EndpointSlice au lieu de remplir les EndpointSlice existants. C'est à dire, une seule création EndpointSlice est préférable à plusieurs mises à jour d'EndpointSlices.
-Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement d'un EndpointSlice devient relativement coûteux puisqu'ils seront transmis à chaque Node du cluster.
+Avec kube-proxy exécuté sur chaque Node et surveillant EndpointSlices, chaque changement d'un EndpointSlice devient relativement coûteux puisqu'ils seront transmis à chaque Node du cluster.
Cette approche vise à limiter le nombre de modifications qui doivent être envoyées à chaque Node, même si ça peut causer plusieurs EndpointSlices non remplis.
En pratique, cette distribution bien peu idéale devrait être rare. La plupart des changements traités par le contrôleur EndpointSlice seront suffisamment petits pour tenir dans un EndpointSlice existant, et sinon, un nouveau EndpointSlice aurait probablement été bientôt nécessaire de toute façon. Les mises à jour continues des déploiements fournissent également une compaction naturelle des EndpointSlices avec tous leurs pods et les Endpoints correspondants qui se feront remplacer.
## Motivation
-L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints dans Kubernetes.
-Malheureusement, comme les clusters Kubernetes et Services sont devenus plus grands, les limitations de cette API sont devenues plus visibles.
-Plus particulièrement, celles-ci comprennent des limitations liées au dimensionnement vers un plus grand nombre d'Endpoints d'un réseau.
+L'API des Endpoints fournit une méthode simple et facile à suivre pour les Endpoints dans Kubernetes. Malheureusement, comme les clusters Kubernetes et Services sont devenus plus grands, les limitations de cette API sont devenues plus visibles. Plus particulièrement, celles-ci comprennent des limitations liées au dimensionnement vers un plus grand nombre d'Endpoints d'un réseau.
-Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes.
-Cela affecte les performances des composants Kubernetes (notamment le plan de contrôle) et cause une grande quantité de trafic réseau et de traitements lorsque les Endpoints changent.
-Les EndpointSlices aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
+Puisque tous les Endpoints d'un réseau pour un Service ont été stockés dans une seule ressource Endpoints, ces ressources pourraient devenir assez lourdes. Cela affecte les performances des composants Kubernetes (notamment le plan de contrôle) et cause une grande quantité de trafic réseau et de traitements lorsque les Endpoints changent. Les EndpointSlices aident à atténuer ces problèmes ainsi qu'à fournir une plate-forme extensible pour des fonctionnalités supplémentaires telles que le routage topologique.
diff --git a/content/fr/releases/notes.md b/content/fr/releases/notes.md
new file mode 100644
index 0000000000..803925fc5c
--- /dev/null
+++ b/content/fr/releases/notes.md
@@ -0,0 +1,13 @@
+---
+linktitle: Notes de version
+title: Notes
+type: docs
+description: >
+ Notes de version de Kubernetes.
+sitemap:
+ priority: 0.5
+---
+
+Les notes de version peuvent être trouvées en lisant le [Changelog](https://github.com/kubernetes/kubernetes/tree/master/CHANGELOG) qui correspond à votre version de Kubernetes. Consultez le journal des modifications pour {{< skew lastVersion >}} sur [GitHub](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-{{< skew lastVersion >}}.md).
+
+Alternativement, les notes de version peuvent être recherchées et filtrées en ligne sur : [relnotes.k8s.io](https://relnotes.k8s.io). Consultez les notes de version filtrées pour {{< skew lastVersion >}} sur [relnotes.k8s.io](https://relnotes.k8s.io/?releaseVersions={{< skew lastVersion >}}.0).
diff --git a/content/id/docs/concepts/security/overview.md b/content/id/docs/concepts/security/overview.md
index bc271e0645..0346314f3a 100644
--- a/content/id/docs/concepts/security/overview.md
+++ b/content/id/docs/concepts/security/overview.md
@@ -36,6 +36,7 @@ Amazon Web Services | https://aws.amazon.com/security/ |
Google Cloud Platform | https://cloud.google.com/security/ |
IBM Cloud | https://www.ibm.com/cloud/security |
Microsoft Azure | https://docs.microsoft.com/en-us/azure/security/azure-security |
+Oracle Cloud Infrastructure | https://www.oracle.com/security/ |
VMWare VSphere | https://www.vmware.com/security/hardening-guides.html |
Jika kamu mengoperasikan perangkat keras kamu sendiri, atau penyedia layanan cloud yang berbeda, kamu perlu merujuk pada dokumentasi penyedia layanan cloud yang kamu pakai untuk praktik keamanan terbaik.
diff --git a/content/id/docs/tutorials/_index.md b/content/id/docs/tutorials/_index.md
index 9f3ec5afb3..041b7b62d2 100644
--- a/content/id/docs/tutorials/_index.md
+++ b/content/id/docs/tutorials/_index.md
@@ -50,6 +50,8 @@ Sebelum melangkah lebih lanjut ke tutorial, sebaiknya tandai dulu halaman [Kamus
* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
+
## Servis
* [Menggunakan Source IP](/docs/tutorials/services/source-ip/)
diff --git a/content/it/docs/tutorials/_index.md b/content/it/docs/tutorials/_index.md
index 04069ff5eb..240fce078c 100644
--- a/content/it/docs/tutorials/_index.md
+++ b/content/it/docs/tutorials/_index.md
@@ -50,6 +50,8 @@ Prima di procedere con vari tutorial, raccomandiamo di aggiungere il
* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
+
## Servizi
* [Utilizzare Source IP](/docs/tutorials/services/source-ip/)
diff --git a/content/ja/docs/concepts/configuration/manage-resources-containers.md b/content/ja/docs/concepts/configuration/manage-resources-containers.md
index 0d59ecd319..f775f14b11 100644
--- a/content/ja/docs/concepts/configuration/manage-resources-containers.md
+++ b/content/ja/docs/concepts/configuration/manage-resources-containers.md
@@ -270,6 +270,9 @@ spec:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
+ volumeMounts:
+ - name: ephemeral
+ mountPath: "/tmp"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
@@ -277,6 +280,12 @@ spec:
ephemeral-storage: "2Gi"
limits:
ephemeral-storage: "4Gi"
+ volumeMounts:
+ - name: ephemeral
+ mountPath: "/tmp"
+ volumes:
+ - name: ephemeral
+ emptyDir: {}
```
### エフェメラルストレージを要求するPodのスケジュール方法
diff --git a/content/ja/docs/concepts/containers/runtime-class.md b/content/ja/docs/concepts/containers/runtime-class.md
index bc4e285c66..15cf7446f0 100644
--- a/content/ja/docs/concepts/containers/runtime-class.md
+++ b/content/ja/docs/concepts/containers/runtime-class.md
@@ -100,7 +100,7 @@ Kubernetesのビルトインのdockershim CRIは、ランタイムハンドラ
正しいハンドラーは、その`runtime`セクションで設定されます。
```
-[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
containerdの設定に関する詳細なドキュメントは下記を参照してください。
diff --git a/content/ja/docs/concepts/extend-kubernetes/operator.md b/content/ja/docs/concepts/extend-kubernetes/operator.md
index 116ebbb434..62e38d6ddb 100644
--- a/content/ja/docs/concepts/extend-kubernetes/operator.md
+++ b/content/ja/docs/concepts/extend-kubernetes/operator.md
@@ -90,6 +90,7 @@ kubectl edit SampleDB/example-database # 手動でいくつかの設定を変更
* [Charmed Operator Framework](https://juju.is/)
* [KUDO](https://kudo.dev/)（Kubernetes Universal Declarative Operator）を使います
* [kubebuilder](https://book.kubebuilder.io/)を使います
+ * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (dotnet operator SDK)
* [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)を自分で実装したWebHooksと一緒に使います
* [Operator Framework](https://operatorframework.io)を使います
* [shell-operator](https://github.com/flant/shell-operator)
diff --git a/content/ja/docs/concepts/services-networking/ingress.md b/content/ja/docs/concepts/services-networking/ingress.md
index 97d18640b8..be1b51ad84 100644
--- a/content/ja/docs/concepts/services-networking/ingress.md
+++ b/content/ja/docs/concepts/services-networking/ingress.md
@@ -18,7 +18,7 @@ weight: 40
* ノード: Kubernetes内のワーカーマシンで、クラスターの一部です。
* クラスター: Kubernetesによって管理されているコンテナ化されたアプリケーションを実行させるノードの集合です。この例や、多くのKubernetesによるデプロイでは、クラスター内のノードはインターネットに公開されていません。
* エッジルーター: クラスターでファイアウォールのポリシーを強制するルーターです。クラウドプロバイダーが管理するゲートウェイや、物理的なハードウェアの一部である場合もあります。
-* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
+* クラスターネットワーク: 物理的または論理的な繋がりの集合で、Kubernetesの[ネットワークモデル](/ja/docs/concepts/cluster-administration/networking/)によって、クラスター内でのコミュニケーションを司るものです。
* Service: {{< glossary_tooltip text="ラベル" term_id="label" >}}セレクターを使ったPodの集合を特定するKubernetes {{< glossary_tooltip term_id="service" >}}です。特に指定がない限り、Serviceはクラスターネットワーク内でのみ疎通可能な仮想IPを持つものとして扱われます。
## Ingressとは何か
@@ -66,7 +66,7 @@ Ingressリソースの最小構成の例は以下のとおりです。
{{< codenew file="service/networking/minimal-ingress.yaml" >}}
-他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
+他の全てのKubernetesリソースと同様に、Ingressには`apiVersion`、`kind`や`metadata`フィールドが必要です。Ingressオブジェクトの名前は、有効な[DNSサブドメイン名](/ja/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)である必要があります。設定ファイルに関する一般的な情報は、[アプリケーションのデプロイ](/ja/docs/tasks/run-application/run-stateless-application-deployment/)、[コンテナの設定](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/)、[リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/)を参照してください。Ingressでは、Ingressコントローラーに依存しているいくつかのオプションの設定をするためにアノテーションを一般的に使用します。例としては、[rewrite-targetアノテーション](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)などがあります。[Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers)の種類が異なれば、サポートするアノテーションも異なります。サポートされているアノテーションについて学ぶためには、使用するIngressコントローラーのドキュメントを確認してください。
Ingress [Spec](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)は、ロードバランサーやプロキシーサーバーを設定するために必要な全ての情報を持っています。最も重要なものとして、外部からくる全てのリクエストに対して一致したルールのリストを含みます。IngressリソースはHTTP(S)トラフィックに対してのルールのみサポートしています。
@@ -346,7 +346,7 @@ IngressでこのSecretを参照すると、クライアントとロードバラ
Ingressコントローラーは、負荷分散アルゴリズムやバックエンドの重みスキームなど、すべてのIngressに適用されるいくつかの負荷分散ポリシーの設定とともにブートストラップされます。発展した負荷分散のコンセプト(例: セッションの永続化、動的重み付けなど)はIngressによってサポートされていません。代わりに、それらの機能はService用のロードバランサーを介して利用できます。
-Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
+Ingressによってヘルスチェックの機能が直接に公開されていない場合でも、Kubernetesにおいて、同等の機能を提供する[Readiness Probe](/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)のようなコンセプトが存在することは注目に値します。コントローラーがどのようにヘルスチェックを行うかについては、コントローラーのドキュメントを参照してください(例えば[nginx](https://git.k8s.io/ingress-nginx/README.md)、または[GCE](https://git.k8s.io/ingress-gce/README.md#health-checks))。
## Ingressの更新
@@ -451,4 +451,4 @@ Ingressリソースを直接含まない複数の方法でサービスを公開
## {{% heading "whatsnext" %}}
* [Ingress API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io)について学ぶ
* [Ingressコントローラー](/ja/docs/concepts/services-networking/ingress-controllers/)について学ぶ
-* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/docs/tasks/access-application-cluster/ingress-minikube/)
+* [MinikubeとNGINXコントローラーでIngressのセットアップを行う](/ja/docs/tasks/access-application-cluster/ingress-minikube/)
diff --git a/content/ja/docs/reference/access-authn-authz/authentication.md b/content/ja/docs/reference/access-authn-authz/authentication.md
index 14875c8229..0aee169573 100644
--- a/content/ja/docs/reference/access-authn-authz/authentication.md
+++ b/content/ja/docs/reference/access-authn-authz/authentication.md
@@ -63,7 +63,7 @@ openssl req -new -key jbeda.pem -out jbeda-csr.pem -subj "/CN=jbeda/O=app1/O=app
これにより、"app1"と"app2"の2つのグループに属するユーザー名"jbeda"の証明書署名要求が作成されます。
-クライアント証明書の生成方法については、[証明書の管理](/docs/concepts/cluster-administration/certificates/)を参照してください。
+クライアント証明書の生成方法については、[証明書の管理](/ja/docs/concepts/cluster-administration/certificates/)を参照してください。
### 静的なトークンファイル
@@ -314,7 +314,7 @@ Webhook認証は、Bearerトークンを検証するためのフックです。
* `--authentication-token-webhook-config-file`: リモートのWebhookサービスへのアクセス方法を記述した設定ファイルです
* `--authentication-token-webhook-cache-ttl`: 認証をキャッシュする時間を決定します。デフォルトは2分です
-設定ファイルは、[kubeconfig](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。
+設定ファイルは、[kubeconfig](/ja/docs/concepts/configuration/organize-cluster-access-kubeconfig/)のファイル形式を使用します。
ファイル内で、`clusters`はリモートサービスを、`users`はAPIサーバーのWebhookを指します。例えば、以下のようになります。
```yaml
@@ -347,7 +347,7 @@ contexts:
クライアントが[上記](#putting-a-bearer-token-in-a-request)のようにBearerトークンを使用してAPIサーバーとの認証を試みた場合、認証Webhookはトークンを含むJSONでシリアライズされた`authentication.k8s.io/v1beta1` `TokenReview`オブジェクトをリモートサービスにPOSTします。Kubernetesはそのようなヘッダーが不足しているリクエストを作成しようとはしません。
-Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。
+Webhook APIオブジェクトは、他のKubernetes APIオブジェクトと同じように、[Versioning Compatibility Rule](/ja/docs/concepts/overview/kubernetes-api/)に従うことに注意してください。実装者は、ベータオブジェクトで保証される互換性が緩いことに注意し、正しいデシリアライゼーションが使用されるようにリクエストの"apiVersion"フィールドを確認する必要があります。さらにAPIサーバーは、API拡張グループ`authentication.k8s.io/v1beta1`を有効にしなければなりません(`--runtime config=authentication.k8s.io/v1beta1=true`)。
POSTボディは、以下の形式になります。
@@ -600,7 +600,7 @@ rules:
### 設定
-クレデンシャルプラグインの設定は、userフィールドの一部として[kubectlの設定ファイル](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)で行います。
+クレデンシャルプラグインの設定は、userフィールドの一部として[kubectlの設定ファイル](/ja/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)で行います。
```yaml
apiVersion: v1
diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index 62e610b277..e332cfda7c 100644
--- a/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/ja/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -146,7 +146,7 @@ Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実
1. wins、kubelet、kubeadmをインストールします。
```PowerShell
- curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+ curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
```
diff --git a/content/ja/docs/tasks/administer-cluster/nodelocaldns.md b/content/ja/docs/tasks/administer-cluster/nodelocaldns.md
index 5b7b9e58e8..4a5e59a2ca 100644
--- a/content/ja/docs/tasks/administer-cluster/nodelocaldns.md
+++ b/content/ja/docs/tasks/administer-cluster/nodelocaldns.md
@@ -73,7 +73,7 @@ NodeLocal DNSキャッシュは、クラスターノード上でDNSキャッシ
* kube-proxyがIPVSモードで稼働中のとき:
``` bash
- sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
+ sed -i "s/__PILLAR__LOCAL__DNS__/$localdns/g; s/__PILLAR__DNS__DOMAIN__/$domain/g; s/,__PILLAR__DNS__SERVER__//g; s/__PILLAR__CLUSTER__DNS__/$kubedns/g" nodelocaldns.yaml
```
このモードでは、node-local-dns Podは``上のみで待ち受けます。node-local-dnsのインターフェースはkube-dnsのクラスターIPをバインドしません。なぜならばIPVSロードバランシング用に使われているインターフェースは既にこのアドレスを使用しているためです。
`__PILLAR__UPSTREAM__SERVERS__` はnode-local-dns Podにより生成されます。
diff --git a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
index 04dfd62f8b..def1401165 100644
--- a/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
+++ b/content/ja/docs/tasks/administer-cluster/running-cloud-controller.md
@@ -79,4 +79,4 @@ cloud-controller-managerは、クラウドプロバイダーのAPIにクエリ
## {{% heading "whatsnext" %}}
-独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/docs/tasks/administer-cluster/developing-cloud-controller-manager.md)を参照してください。
+独自のクラウドコントローラーマネージャーを構築および開発するには[クラウドコントローラーマネージャーの開発](/ja/docs/tasks/administer-cluster/developing-cloud-controller-manager/)を参照してください。
diff --git a/content/ja/docs/tutorials/_index.md b/content/ja/docs/tutorials/_index.md
index 1c1d55300a..0cf5ed7f2f 100644
--- a/content/ja/docs/tutorials/_index.md
+++ b/content/ja/docs/tutorials/_index.md
@@ -46,6 +46,8 @@ content_type: concept
* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
+
## サービス
* [Source IPを使う](/docs/tutorials/services/source-ip/)
diff --git a/content/ja/docs/tutorials/stateless-application/guestbook.md b/content/ja/docs/tutorials/stateless-application/guestbook.md
index 82e38a56d2..b9aefecfa9 100644
--- a/content/ja/docs/tutorials/stateless-application/guestbook.md
+++ b/content/ja/docs/tutorials/stateless-application/guestbook.md
@@ -79,7 +79,7 @@ POD-NAMEの部分を実際のPodの名前に書き換えてください。
### RedisのマスターのServiceを作成する
-ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
+ゲストブックアプリケーションは、データを書き込むためにRedisのマスターと通信する必要があります。そのためには、[Service](/ja/docs/concepts/services-networking/service/)を適用して、トラフィックをRedisのマスターのPodへプロキシーしなければなりません。Serviceは、Podにアクセスするためのポリシーを指定します。
{{< codenew file="application/guestbook/redis-master-service.yaml" >}}
@@ -199,7 +199,7 @@ Deploymentはマニフェストファイル内に書かれた設定に基づい
### フロントエンドのServiceを作成する
-適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
+適用した`redis-slave`および`redis-master` Serviceは、コンテナクラスター内部からのみアクセス可能です。これは、デフォルトのServiceのtypeが[ClusterIP](/ja/docs/concepts/services-networking/service/#publishing-services-service-types)であるためです。`ClusterIP`は、Serviceが指している一連のPodに対して1つのIPアドレスを提供します。このIPアドレスはクラスター内部からのみアクセスできます。
もしゲストの人にゲストブックにアクセスしてほしいのなら、フロントエンドServiceを外部から見えるように設定しなければなりません。そうすれば、クライアントはコンテナクラスターの外部からServiceにリクエストを送れるようになります。Minikubeでは、Serviceを`NodePort`でのみ公開できます。
@@ -363,8 +363,8 @@ DeploymentとServiceを削除すると、実行中のPodも削除されます。
## {{% heading "whatsnext" %}}
-* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
+* ゲストブックアプリケーションに対する[ELKによるロギングとモニタリング](/ja/docs/tutorials/stateless-application/guestbook-logs-metrics-with-elk/)
* [Kubernetesの基本](/ja/docs/tutorials/kubernetes-basics/)のインタラクティブチュートリアルを終わらせる
-* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
+* Kubernetesを使って、[MySQLとWordpressのためにPersistent Volume](/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/#visit-your-new-wordpress-blog)を使用したブログを作成する
* [サービスとアプリケーションの接続](/ja/docs/concepts/services-networking/connect-applications-service/)についてもっと読む
-* [リソースの管理](/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
+* [リソースの管理](/ja/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)についてもっと読む
diff --git a/content/ko/community/_index.html b/content/ko/community/_index.html
index 0fa8d8658a..9666cd4a14 100644
--- a/content/ko/community/_index.html
+++ b/content/ko/community/_index.html
@@ -12,8 +12,8 @@ cid: community
-
사용자, 기여자, 그리고 우리가 함께 구축한 문화로 구성된 쿠버네티스 커뮤니티는 이 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장 하고 변화함에 따라 우리의 문화와 가치관이 계속 성장하고 변화하고 있습니다. 우리 모두는 프로젝트의 지속적인 개선과 작업 방식을 위해 함께 노력합니다.
-
우리는 이슈를 제기하고 풀 리퀘스트하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고 채택과 혁신을 옹호하며, kubectl get pods 을 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 여러분이 어떻게 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.
+
사용자, 기여자, 그리고 우리가 함께 구축한 문화를 통해 구성된 쿠버네티스 커뮤니티는 본 오픈소스 프로젝트가 급부상하는 가장 큰 이유 중 하나입니다. 프로젝트 자체가 성장하고 변화함에 따라 우리의 문화와 가치관 또한 지속적으로 성장하고 변화하고 있습니다. 우리 모두는 프로젝트와 작업 방식을 지속적으로 개선하기 위해 함께 노력합니다.
+
우리는 이슈(issue)와 풀 리퀘스트(pull request)를 제출하고, SIG 미팅과 쿠버네티스 모임 그리고 KubeCon에 참석하고, 도입(adoption)과 혁신(innovation)을 지지하며, kubectl get pods 를 실행하고, 다른 수천가지 중요한 방법으로 기여하는 사람들 입니다. 어떻게 하면 이 놀라운 공동체의 일부가 될 수 있는지 계속 읽어보세요.
diff --git a/content/ko/docs/concepts/architecture/nodes.md b/content/ko/docs/concepts/architecture/nodes.md
index 3ab89472d8..5daed12077 100644
--- a/content/ko/docs/concepts/architecture/nodes.md
+++ b/content/ko/docs/concepts/architecture/nodes.md
@@ -392,6 +392,49 @@ Message: Node is shutting, evicting pods
이는 갑작스러운 노드 종료의 경우와 비교했을 때 동작에 차이가 있다.
{{< /note >}}
+## 스왑(swap) 메모리 관리 {#swap-memory}
+
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
+
+쿠버네티스 1.22 이전에는 노드가 스왑 메모리를 지원하지 않았다. 그리고
+kubelet은 노드에서 스왑을 발견하지 못한 경우 시작과 동시에 실패하도록 되어 있었다.
+1.22부터는 스왑 메모리 지원을 노드 단위로 활성화할 수 있다.
+
+노드에서 스왑을 활성화하려면, `NodeSwap` 기능 게이트가 kubelet에서
+활성화되어야 하며, 명령줄 플래그 `--fail-swap-on` 또는
+[구성 설정](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)에서 `failSwapOn`가
+false로 지정되어야 한다.
+
+사용자는 또한 선택적으로 `memorySwap.swapBehavior`를 구성할 수 있으며,
+이를 통해 노드가 스왑 메모리를 사용하는 방식을 명시한다. 예를 들면,
+
+```yaml
+memorySwap:
+ swapBehavior: LimitedSwap
+```
+
+`swapBehavior`에 가용한 구성 옵션은 다음과 같다.
+
+- `LimitedSwap`: 쿠버네티스 워크로드는 스왑을 사용할 수 있는 만큼으로
+ 제한된다. 쿠버네티스에 의해 관리되지 않는 노드의 워크로드는 여전히 스왑될 수 있다.
+- `UnlimitedSwap`: 쿠버네티스 워크로드는 요청한 만큼 스왑 메모리를 사용할 수 있으며,
+ 시스템의 최대치까지 사용 가능하다.
+
+만약 `memorySwap` 구성이 명시되지 않았고 기능 게이트가 활성화되어 있다면,
+kubelet은 `LimitedSwap` 설정과 같은 행동을
+기본적으로 적용한다.
+
+`LimitedSwap` 설정에 대한 행동은 노드가 ("cgroups"으로 알려진)
+제어 그룹이 v1 또는 v2 중에서 무엇으로 동작하는가에 따라서 결정된다.
+
+- **cgroupsv1:** 쿠버네티스 워크로드는 메모리와 스왑의 조합을 사용할 수 있다.
+ 파드의 메모리 제한이 설정되어 있다면 가용 상한이 된다.
+- **cgroupsv2:** 쿠버네티스 워크로드는 스왑 메모리를 사용할 수 없다.
+
+테스트를 지원하고 피드벡을 제공하기 위한 정보는
+[KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) 및
+[디자인 제안](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/2400-node-swap/README.md)에서 찾을 수 있다.
+
## {{% heading "whatsnext" %}}
* 노드를 구성하는 [컴포넌트](/ko/docs/concepts/overview/components/#노드-컴포넌트)에 대해 알아본다.
diff --git a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
index c64dd127b3..6db0871e48 100644
--- a/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
+++ b/content/ko/docs/concepts/cluster-administration/kubelet-garbage-collection.md
@@ -6,6 +6,18 @@ weight: 70
+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
가비지 수집은 사용되지 않는
[이미지](/ko/docs/concepts/containers/#컨테이너-이미지)들과
[컨테이너](/ko/docs/concepts/containers/)들을 정리하는 kubelet의 유용한 기능이다. Kubelet은
diff --git a/content/ko/docs/concepts/cluster-administration/logging.md b/content/ko/docs/concepts/cluster-administration/logging.md
index d4e0119c41..5ae2aafffd 100644
--- a/content/ko/docs/concepts/cluster-administration/logging.md
+++ b/content/ko/docs/concepts/cluster-administration/logging.md
@@ -80,7 +80,7 @@ kubectl logs counter
로테이션하도록 컨테이너 런타임을 설정할 수도 있다.
예를 들어, `kube-up.sh` 가 GCP의 COS 이미지 로깅을 설정하는 방법은
-[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)를 통해
+[`configure-helper` 스크립트](https://github.com/kubernetes/kubernetes/blob/master/cluster/gce/gci/configure-helper.sh)를 통해
자세히 알 수 있다.
**CRI 컨테이너 런타임** 을 사용할 때, kubelet은 로그를 로테이션하고 로깅 디렉터리 구조를 관리한다.
diff --git a/content/ko/docs/concepts/cluster-administration/manage-deployment.md b/content/ko/docs/concepts/cluster-administration/manage-deployment.md
index 7e3093d51e..553ce005a9 100644
--- a/content/ko/docs/concepts/cluster-administration/manage-deployment.md
+++ b/content/ko/docs/concepts/cluster-administration/manage-deployment.md
@@ -160,7 +160,7 @@ persistentvolumeclaim/my-pvc created
지금까지 사용한 예는 모든 리소스에 최대 한 개의 레이블만 적용하는 것이었다. 세트를 서로 구별하기 위해 여러 레이블을 사용해야 하는 많은 시나리오가 있다.
-예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
+예를 들어, 애플리케이션마다 `app` 레이블에 다른 값을 사용하지만, [방명록 예제](https://github.com/kubernetes/examples/tree/master/guestbook/)와 같은 멀티-티어 애플리케이션은 각 티어를 추가로 구별해야 한다. 프론트엔드는 다음의 레이블을 가질 수 있다.
```yaml
labels:
diff --git a/content/ko/docs/concepts/configuration/overview.md b/content/ko/docs/concepts/configuration/overview.md
index 17fd61c6a6..f89d873a37 100644
--- a/content/ko/docs/concepts/configuration/overview.md
+++ b/content/ko/docs/concepts/configuration/overview.md
@@ -21,7 +21,7 @@ weight: 10
- JSON보다는 YAML을 사용해 구성 파일을 작성한다. 비록 이러한 포맷들은 대부분의 모든 상황에서 통용되어 사용될 수 있지만, YAML이 좀 더 사용자 친화적인 성향을 가진다.
-- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
+- 의미상 맞다면 가능한 연관된 오브젝트들을 하나의 파일에 모아 놓는다. 때로는 여러 개의 파일보다 하나의 파일이 더 관리하기 쉽다. 이 문법의 예시로서 [guestbook-all-in-one.yaml](https://github.com/kubernetes/examples/tree/master/guestbook/all-in-one/guestbook-all-in-one.yaml) 파일을 참고한다.
- 많은 `kubectl` 커맨드들은 디렉터리에 대해 호출될 수 있다. 예를 들어, 구성 파일들의 디렉터리에 대해 `kubectl apply`를 호출할 수 있다.
@@ -63,7 +63,7 @@ DNS 서버는 새로운 `서비스`를 위한 쿠버네티스 API를 Watch하며
## 레이블 사용하기
-- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/guestbook/) 앱을 참고한다.
+- `{ app: myapp, tier: frontend, phase: test, deployment: v3 }`처럼 애플리케이션이나 디플로이먼트의 __속성에 대한 의미__ 를 식별하는 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 정의해 사용한다. 다른 리소스를 위해 적절한 파드를 선택하는 용도로 이러한 레이블을 이용할 수 있다. 예를 들어, 모든 `tier: frontend` 파드를 선택하거나, `app: myapp`의 모든 `phase: test` 컴포넌트를 선택하는 서비스를 생각해 볼 수 있다. 이 접근 방법의 예시는 [방명록](https://github.com/kubernetes/examples/tree/master/guestbook/) 앱을 참고한다.
릴리스에 특정되는 레이블을 서비스의 셀렉터에서 생략함으로써 여러 개의 디플로이먼트에 걸치는 서비스를 생성할 수 있다. 동작 중인 서비스를 다운타임 없이 갱신하려면, [디플로이먼트](/ko/docs/concepts/workloads/controllers/deployment/)를 사용한다.
diff --git a/content/ko/docs/concepts/configuration/secret.md b/content/ko/docs/concepts/configuration/secret.md
index 06be7d5a54..330e89edac 100644
--- a/content/ko/docs/concepts/configuration/secret.md
+++ b/content/ko/docs/concepts/configuration/secret.md
@@ -12,26 +12,33 @@ weight: 30
-쿠버네티스 시크릿을 사용하면 비밀번호, OAuth 토큰, ssh 키와 같은
-민감한 정보를 저장하고 관리할 수 있다. 기밀 정보를 시크릿에 저장하는 것이
-{{< glossary_tooltip term_id="pod" >}} 정의나
-{{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}
-내에 그대로 두는 것보다 안전하고 유연하다.
-자세한 내용은 [시크릿 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md)를 참고한다.
-
시크릿은 암호, 토큰 또는 키와 같은 소량의 중요한 데이터를
-포함하는 오브젝트이다. 그렇지 않으면 이러한 정보가 파드
-명세나 이미지에 포함될 수 있다. 사용자는 시크릿을 만들 수 있고 시스템도
-일부 시크릿을 만들 수 있다.
+포함하는 오브젝트이다. 이를 사용하지 않으면 중요한 정보가 {{< glossary_tooltip text="파드" term_id="pod" >}}
+명세나 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
+포함될 수 있다. 시크릿을 사용한다는 것은 사용자의 기밀 데이터를
+애플리케이션 코드에 넣을 필요가
+없음을 뜻한다.
+
+시크릿은 시크릿을 사용하는 파드와 독립적으로 생성될 수 있기 때문에,
+파드를 생성하고, 확인하고, 수정하는 워크플로우 동안 시크릿(그리고 데이터)이
+노출되는 것에 대한 위험을 경감시킬 수 있다. 쿠버네티스
+및 클러스터에서 실행되는 애플리케이션은 기밀 데이터를 비휘발성
+저장소에 쓰는 것을 피하는 것과 같이, 시크릿에 대해 추가 예방 조치를 취할 수도 있다.
+
+시크릿은 {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}과 유사하지만
+특별히 기밀 데이터를 보관하기 위한 것이다.
{{< caution >}}
-쿠버네티스 시크릿은 기본적으로 암호화되지 않은 base64 인코딩 문자열로 저장된다.
-기본적으로 API 액세스 권한이 있는 모든 사용자 또는 쿠버네티스의 기본 데이터 저장소 etcd에
-액세스할 수 있는 모든 사용자가 일반 텍스트로 검색할 수 있다.
-시크릿을 안전하게 사용하려면 (최소한) 다음과 같이 하는 것이 좋다.
+쿠버네티스 시크릿은 기본적으로 API 서버의 기본 데이터 저장소(etcd)에 암호화되지 않은 상태로 저장된다. API 접근(access) 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다.
+또한 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 접근을 사용하여 해당 네임스페이스의 모든 시크릿을 읽을 수 있다. 여기에는 디플로이먼트 생성 기능과 같은 간접 접근이 포함된다.
+
+시크릿을 안전하게 사용하려면 최소한 다음의 단계를 따르는 것이 좋다.
1. 시크릿에 대한 [암호화 활성화](/docs/tasks/administer-cluster/encrypt-data/).
-2. 시크릿 읽기 및 쓰기를 제한하는 [RBAC 규칙 활성화 또는 구성](/ko/docs/reference/access-authn-authz/authorization/). 파드를 만들 권한이 있는 모든 사용자는 시크릿을 암묵적으로 얻을 수 있다.
+2. 시크릿의 데이터 읽기 및 쓰기(간접적인 방식 포함)를 제한하는 [RBAC 규칙](/ko/docs/reference/access-authn-authz/authorization/)
+ 활성화 또는 구성.
+3. 적절한 경우, RBAC와 같은 메커니즘을 사용하여 새로운 시크릿을 생성하거나 기존 시크릿을 대체할 수 있는 주체(principal)들을 제한한다.
+
{{< /caution >}}
@@ -47,6 +54,10 @@ weight: 30
- [컨테이너 환경 변수](#시크릿을-환경-변수로-사용하기)로써 사용.
- 파드의 [이미지를 가져올 때 kubelet](#imagepullsecrets-사용하기)에 의해 사용.
+쿠버네티스 컨트롤 플레인 또한 시크릿을 사용한다. 예를 들어,
+[부트스트랩 토큰 시크릿](#부트스트랩-토큰-시크릿)은
+노드 등록을 자동화하는 데 도움을 주는 메커니즘이다.
+
시크릿 오브젝트의 이름은 유효한
[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
사용자는 시크릿을 위한 파일을 구성할 때 `data` 및 (또는) `stringData` 필드를
@@ -1236,7 +1247,6 @@ API 서버에서 kubelet으로의 통신은 SSL/TLS로 보호된다.
API 서버 정책이 해당 사용자가 시크릿을 읽을 수 있도록 허용하지 않더라도, 사용자는
시크릿을 노출하는 파드를 실행할 수 있다.
-
## {{% heading "whatsnext" %}}
- [`kubectl` 을 사용한 시크릿 관리](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)하는 방법 배우기
diff --git a/content/ko/docs/concepts/containers/container-environment.md b/content/ko/docs/concepts/containers/container-environment.md
index 58c106fdce..749eb6fbb8 100644
--- a/content/ko/docs/concepts/containers/container-environment.md
+++ b/content/ko/docs/concepts/containers/container-environment.md
@@ -52,7 +52,7 @@ FOO_SERVICE_HOST=<서비스가 동작 중인 호스트>
FOO_SERVICE_PORT=<서비스가 동작 중인 포트>
```
-서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
+서비스에 지정된 IP 주소가 있고 [DNS 애드온](https://releases.k8s.io/master/cluster/addons/dns/)이 활성화된 경우, DNS를 통해서 컨테이너가 서비스를 사용할 수 있다.
diff --git a/content/ko/docs/concepts/containers/images.md b/content/ko/docs/concepts/containers/images.md
index 886f8247a3..9a22f2f3e5 100644
--- a/content/ko/docs/concepts/containers/images.md
+++ b/content/ko/docs/concepts/containers/images.md
@@ -1,4 +1,7 @@
---
+
+
+
title: 이미지
content_type: concept
weight: 10
@@ -16,9 +19,6 @@ weight: 10
이 페이지는 컨테이너 이미지 개념의 개요를 제공한다.
-
-
-
## 이미지 이름
@@ -210,10 +210,6 @@ kubectl describe pods/private-image-test-1 | grep 'Failed'
### 미리 내려받은 이미지
-{{< note >}}
-Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Google 컨테이너 레지스트리에 대한 자격 증명과 함께 `.dockercfg`가 있을 것이다. 그렇다면 이 방법은 쓸 수 없다.
-{{< /note >}}
-
{{< note >}}
이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
@@ -334,4 +330,5 @@ Kubelet은 모든 `imagePullSecrets` 파일을 하나의 가상 `.docker/config.
## {{% heading "whatsnext" %}}
-* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기
+* [OCI 이미지 매니페스트 명세](https://github.com/opencontainers/image-spec/blob/master/manifest.md) 읽어보기.
+* [컨테이너 이미지 가비지 수집(garbage collection)](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)에 대해 배우기.
diff --git a/content/ko/docs/concepts/containers/runtime-class.md b/content/ko/docs/concepts/containers/runtime-class.md
index 953571ec62..a2142521cd 100644
--- a/content/ko/docs/concepts/containers/runtime-class.md
+++ b/content/ko/docs/concepts/containers/runtime-class.md
@@ -1,4 +1,7 @@
---
+
+
+
title: 런타임클래스(RuntimeClass)
content_type: concept
weight: 20
@@ -115,7 +118,7 @@ dockershim은 사용자 정의 런타임 핸들러를 지원하지 않는다.
유효한 핸들러는 runtimes 단락 아래에서 설정한다.
```
-[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
+[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
```
더 자세한 containerd의 구성 문서를 살펴본다.
diff --git a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index 13313adf58..9d4ad5525c 100644
--- a/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -197,31 +197,39 @@ service PodResourcesLister {
}
```
-`List` 엔드포인트는 독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
-이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보와 함께
-실행 중인 파드의 리소스에 대한 정보를 제공한다.
+`List` 엔드포인트는 실행 중인 파드의 리소스에 대한 정보를 제공하며,
+독점적으로 할당된 CPU의 ID, 장치 플러그인에 의해 보고된 장치 ID,
+이러한 장치가 할당된 NUMA 노드의 ID와 같은 세부 정보를 함께 제공한다. 또한, NUMA 기반 머신의 경우, 컨테이너를 위해 예약된 메모리와 hugepage에 대한 정보를 포함한다.
```gRPC
-// ListPodResourcesResponse는 List 함수가 반환하는 응답이다
+// ListPodResourcesResponse는 List 함수가 반환하는 응답이다.
message ListPodResourcesResponse {
repeated PodResources pod_resources = 1;
}
-// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다
+// PodResources에는 파드에 할당된 노드 리소스에 대한 정보가 포함된다.
message PodResources {
string name = 1;
string namespace = 2;
repeated ContainerResources containers = 3;
}
-// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다
+// ContainerResources는 컨테이너에 할당된 리소스에 대한 정보를 포함한다.
message ContainerResources {
string name = 1;
repeated ContainerDevices devices = 2;
repeated int64 cpu_ids = 3;
+ repeated ContainerMemory memory = 4;
}
-// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다
+// ContainerMemory는 컨테이너에 할당된 메모리와 hugepage에 대한 정보를 포함한다.
+message ContainerMemory {
+ string memory_type = 1;
+ uint64 size = 2;
+ TopologyInfo topology = 3;
+}
+
+// 토폴로지는 리소스의 하드웨어 토폴로지를 설명한다.
message TopologyInfo {
repeated NUMANode nodes = 1;
}
@@ -231,7 +239,7 @@ message NUMANode {
int64 ID = 1;
}
-// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다
+// ContainerDevices는 컨테이너에 할당된 장치에 대한 정보를 포함한다.
message ContainerDevices {
string resource_name = 1;
repeated string device_ids = 2;
@@ -247,6 +255,7 @@ kubelet이 APIServer로 내보내는 것보다 더 많은 정보를 제공한다
message AllocatableResourcesResponse {
repeated ContainerDevices devices = 1;
repeated int64 cpu_ids = 2;
+ repeated ContainerMemory memory = 3;
}
```
diff --git a/content/ko/docs/concepts/overview/what-is-kubernetes.md b/content/ko/docs/concepts/overview/what-is-kubernetes.md
index 5d2ef83d76..2b6809782d 100644
--- a/content/ko/docs/concepts/overview/what-is-kubernetes.md
+++ b/content/ko/docs/concepts/overview/what-is-kubernetes.md
@@ -45,7 +45,7 @@ sitemap:
* 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
* 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
* 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
-* 가시성은 OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
+* 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
* 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
* 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
* 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
diff --git a/content/ko/docs/concepts/overview/working-with-objects/annotations.md b/content/ko/docs/concepts/overview/working-with-objects/annotations.md
index 245da33db3..89334978c0 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/annotations.md
@@ -30,6 +30,11 @@ weight: 50
}
```
+{{}}
+맵의 키와 값은 문자열이어야 한다. 다르게 말해서, 숫자,
+불리언(boolean), 리스트 등의 다른 형식을 키나 값에 사용할 수 없다.
+{{}}
+
다음은 어노테이션에 기록할 수 있는 정보의 예제이다.
* 필드는 선언적 구성 계층에 의해 관리된다. 이러한 필드를 어노테이션으로 첨부하는 것은
diff --git a/content/ko/docs/concepts/overview/working-with-objects/labels.md b/content/ko/docs/concepts/overview/working-with-objects/labels.md
index 0583ae0fe3..571c62b7db 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/labels.md
@@ -42,7 +42,7 @@ _레이블_ 은 파드와 같은 오브젝트에 첨부된 키와 값의 쌍이
* `"partition" : "customerA"`, `"partition" : "customerB"`
* `"track" : "daily"`, `"track" : "weekly"`
-이 예시는 일반적으로 사용하는 레이블이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
+이 예시는 [일반적으로 사용하는 레이블](/ko/docs/concepts/overview/working-with-objects/common-labels/)이며, 사용자는 자신만의 규칙(convention)에 따라 자유롭게 개발할 수 있다. 오브젝트에 붙여진 레이블 키는 고유해야 한다는 것을 기억해야 한다.
## 구문과 캐릭터 셋
@@ -50,15 +50,13 @@ _레이블_ 은 키와 값의 쌍이다. 유효한 레이블 키에는 슬래시
접두사를 생략하면 키 레이블은 개인용으로 간주한다. 최종 사용자의 오브젝트에 자동화된 시스템 컴포넌트(예: `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl` 또는 다른 타사의 자동화 구성 요소)의 접두사를 지정해야 한다.
-`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 예약되어있다.
+`kubernetes.io/`와 `k8s.io/` 접두사는 쿠버네티스의 핵심 컴포넌트로 [예약](/ko/docs/reference/labels-annotations-taints/)되어있다.
유효한 레이블 값은 다음과 같다.
* 63 자 이하여야 하고 (공백일 수도 있음),
* (공백이 아니라면) 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며,
* 알파벳과 숫자, 대시(`-`), 밑줄(`_`), 점(`.`)을 중간에 포함할 수 있다.
-유효한 레이블 값은 63자 미만 또는 공백이며 시작과 끝은 알파벳과 숫자(`[a-z0-9A-Z]`)이며, 대시(`-`), 밑줄(`_`), 점(`.`)과 함께 사용할 수 있다.
-
다음의 예시는 파드에 `environment: production` 과 `app: nginx` 2개의 레이블이 있는 구성 파일이다.
```yaml
diff --git a/content/ko/docs/concepts/overview/working-with-objects/names.md b/content/ko/docs/concepts/overview/working-with-objects/names.md
index 78b7addd43..69afaa0069 100644
--- a/content/ko/docs/concepts/overview/working-with-objects/names.md
+++ b/content/ko/docs/concepts/overview/working-with-objects/names.md
@@ -1,4 +1,7 @@
---
+
+
+
title: 오브젝트 이름과 ID
content_type: concept
weight: 20
@@ -25,7 +28,7 @@ weight: 20
물리적 호스트를 나타내는 노드와 같이 오브젝트가 물리적 엔티티를 나타내는 경우, 노드를 삭제한 후 다시 생성하지 않은 채 동일한 이름으로 호스트를 다시 생성하면, 쿠버네티스는 새 호스트를 불일치로 이어질 수 있는 이전 호스트로 취급한다.
{{< /note >}}
-다음은 리소스에 일반적으로 사용되는 세 가지 유형의 이름 제한 조건이다.
+다음은 리소스에 일반적으로 사용되는 네 가지 유형의 이름 제한 조건이다.
### DNS 서브도메인 이름
@@ -38,7 +41,7 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
-### DNS 레이블 이름
+### RFC 1123 레이블 이름 {#dns-label-names}
일부 리소스 유형은 [RFC 1123](https://tools.ietf.org/html/rfc1123)에
정의된 대로 DNS 레이블 표준을 따라야 한다.
@@ -49,6 +52,17 @@ DNS 서브도메인 이름으로 사용할 수 있는 이름이 필요하다.
- 영숫자로 시작한다.
- 영숫자로 끝난다.
+### RFC 1035 레이블 이름
+
+몇몇 리소스 타입은 자신의 이름을 [RFC 1035](https://tools.ietf.org/html/rfc1035)에
+정의된 DNS 레이블 표준을 따르도록 요구한다.
+이것은 이름이 다음을 만족해야 한다는 의미이다.
+
+- 최대 63개 문자를 포함
+- 소문자 영숫자 또는 '-'만 포함
+- 알파벳 문자로 시작
+- 영숫자로 끝남
+
### 경로 세그먼트 이름
일부 리소스 유형에서는 이름을 경로 세그먼트로 안전하게 인코딩 할 수
diff --git a/content/ko/docs/concepts/policy/resource-quotas.md b/content/ko/docs/concepts/policy/resource-quotas.md
index b5254e4300..b7cb48b23e 100644
--- a/content/ko/docs/concepts/policy/resource-quotas.md
+++ b/content/ko/docs/concepts/policy/resource-quotas.md
@@ -442,7 +442,7 @@ pods 0 10
### 네임스페이스 간 파드 어피니티 쿼터
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
오퍼레이터는 네임스페이스를 교차하는 어피니티가 있는 파드를 가질 수 있는 네임스페이스를
제한하기 위해 `CrossNamespacePodAffinity` 쿼터 범위를 사용할 수 있다. 특히, 파드 어피니티 용어의
@@ -493,9 +493,9 @@ plugins:
해당 필드를 사용하는 파드 수보다 크거나 같은 하드 제한이 있는 경우에만
파드 어피니티에서 `namespaces` 및 `namespaceSelector` 를 사용할 수 있다.
-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
## 요청과 제한의 비교 {#requests-vs-limits}
diff --git a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
index f46e075b57..1e6a007cdf 100644
--- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
+++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md
@@ -271,16 +271,16 @@ PodSpec에 지정된 NodeAffinity도 적용된다.
연관된 `matchExpressions` 가 모두 충족되어야 한다.
#### 네임스페이스 셀렉터
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다.
어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다.
빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과
null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다.
-이 기능은 알파이며 기본적으로 비활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
+이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서
[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)
-`PodAffinityNamespaceSelector` 를 설정하여 활성화할 수 있다.
+`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다.
#### 더 실용적인 유스케이스
diff --git a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
index 8c17269a64..5b0a1648c3 100644
--- a/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
+++ b/content/ko/docs/concepts/scheduling-eviction/kube-scheduler.md
@@ -85,7 +85,7 @@ _스코어링_ 단계에서 스케줄러는 목록에 남아있는 노드의 순
* [스케줄러 성능 튜닝](/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning/)에 대해 읽기
* [파드 토폴로지 분배 제약 조건](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)에 대해 읽기
* kube-scheduler의 [레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽기
-* [kube-scheduler 구성(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽기
+* [kube-scheduler 구성(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽기
* [멀티 스케줄러 구성하기](/docs/tasks/extend-kubernetes/configure-multiple-schedulers/)에 대해 배우기
* [토폴로지 관리 정책](/docs/tasks/administer-cluster/topology-manager/)에 대해 배우기
* [파드 오버헤드](/ko/docs/concepts/scheduling-eviction/pod-overhead/)에 대해 배우기
diff --git a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
index f149290882..6df4ec16b4 100644
--- a/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+++ b/content/ko/docs/concepts/scheduling-eviction/pod-priority-preemption.md
@@ -1,4 +1,7 @@
---
+
+
+
title: 파드 우선순위(priority)와 선점(preemption)
content_type: concept
weight: 70
@@ -350,21 +353,25 @@ spec:
`PodDisruptionBudget` 으로 보호되는 경우에만, 우선순위가 가장 낮은 파드를
축출 대상으로 고려한다.
-QoS와 파드 우선순위를 모두 고려하는 유일한 컴포넌트는
-[kubelet 리소스 부족 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/)이다.
-kubelet은 부족한 리소스의 사용이 요청을 초과하는지 여부에 따라, 그런 다음 우선순위에 따라,
-파드의 스케줄링 요청에 대한 부족한 컴퓨팅 리소스의 소비에 의해
-먼저 축출 대상 파드의 순위를 매긴다.
-더 자세한 내용은
-[엔드유저 파드 축출](/docs/concepts/scheduling-eviction/node-pressure-eviction/#evicting-end-user-pods)을
+kubelet은 우선순위를 사용하여 파드의 [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/) 순서를 결정한다.
+사용자는 QoS 클래스를 사용하여 어떤 파드가 축출될 것인지
+예상할 수 있다. kubelet은 다음의 요소들을 통해서 파드의 축출 순위를 매긴다.
+
+ 1. 부족한 리소스 사용량이 요청을 초과하는지 여부
+ 1. 파드 우선순위
+ 1. 요청 대비 리소스 사용량
+
+더 자세한 내용은 [kubelet 축출에서 파드 선택](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#kubelet-축출을-위한-파드-선택)을
참조한다.
-kubelet 리소스 부족 축출은 사용량이 요청을 초과하지 않는 경우
+kubelet 노드-압박 축출은 사용량이 요청을 초과하지 않는 경우
파드를 축출하지 않는다. 우선순위가 낮은 파드가 요청을
초과하지 않으면, 축출되지 않는다. 요청을 초과하는 우선순위가
더 높은 다른 파드가 축출될 수 있다.
-
## {{% heading "whatsnext" %}}
-* 프라이어리티클래스와 관련하여 리소스쿼터 사용에 대해 [기본적으로 프라이어리티클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)을 읽어보자.
+* 프라이어리티클래스와 함께 리소스쿼터 사용에 대해 읽기: [기본으로 프라이어리티 클래스 소비 제한](/ko/docs/concepts/policy/resource-quotas/#기본적으로-우선-순위-클래스-소비-제한)
+* [파드 중단(disruption)](/ko/docs/concepts/workloads/pods/disruptions/)에 대해 학습한다.
+* [API를 이용한 축출](/ko/docs/concepts/scheduling-eviction/api-eviction/)에 대해 학습한다.
+* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대해 학습한다.
diff --git a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
index 6be3e204c8..e2fb1cdcf9 100644
--- a/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
+++ b/content/ko/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md
@@ -43,7 +43,7 @@ kube-scheduler 의 `percentageOfNodesToScore` 설정을 통해
마치 100을 설정한 것처럼 작동한다.
값을 변경하려면,
-[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta1/)을
+[kube-scheduler 구성 파일](/docs/reference/config-api/kube-scheduler-config.v1beta2/)을
편집한 다음 스케줄러를 재시작한다.
대부분의 경우, 구성 파일은 `/etc/kubernetes/config/kube-scheduler.yaml` 에서 찾을 수 있다.
@@ -161,4 +161,4 @@ percentageOfNodesToScore: 50
## {{% heading "whatsnext" %}}
-* [kube-scheduler 구성 레퍼런스(v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 확인
+* [kube-scheduler 구성 레퍼런스(v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 확인
diff --git a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
index c47f5f995b..f6d8c13a19 100644
--- a/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
+++ b/content/ko/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -264,10 +264,10 @@ tolerations:
이렇게 하면 이러한 문제로 인해 데몬셋 파드가 축출되지 않는다.
-## 컨디션을 기준으로 노드 테인트하기
+## 조건(condition)을 기준으로 노드 테인트하기
컨트롤 플레인은 노드 {{}}를 이용하여
-[노드 조건](/docs/concepts/scheduling-eviction/node-pressure-eviction/)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
+[노드 조건](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)에 대한 `NoSchedule` 효과를 사용하여 자동으로 테인트를 생성한다.
스케줄러는 스케줄링 결정을 내릴 때 노드 조건을 확인하는 것이 아니라 테인트를 확인한다.
이렇게 하면 노드 조건이 스케줄링에 직접적인 영향을 주지 않는다.
@@ -298,5 +298,5 @@ tolerations:
## {{% heading "whatsnext" %}}
-* [리소스 부족 다루기](/docs/concepts/scheduling-eviction/node-pressure-eviction/)와 어떻게 구성하는지에 대해 알아보기
+* [노드-압박(node-pressure) 축출](/ko/docs/concepts/scheduling-eviction/node-pressure-eviction/)과 어떻게 구성하는지에 대해 알아보기
* [파드 우선순위](/ko/docs/concepts/scheduling-eviction/pod-priority-preemption/)에 대해 알아보기
diff --git a/content/ko/docs/concepts/security/overview.md b/content/ko/docs/concepts/security/overview.md
index 64ed2675b2..47d0548a7e 100644
--- a/content/ko/docs/concepts/security/overview.md
+++ b/content/ko/docs/concepts/security/overview.md
@@ -1,17 +1,21 @@
---
+
+
title: 클라우드 네이티브 보안 개요
+description: >
+ 클라우드 네이티브 보안 관점에서 쿠버네티스 보안을 생각해보기 위한 모델
content_type: concept
-weight: 10
+weight: 1
---
+
이 개요는 클라우드 네이티브 보안의 맥락에서 쿠버네티스 보안에 대한 생각의 모델을 정의한다.
{{< warning >}}
이 컨테이너 보안 모델은 입증된 정보 보안 정책이 아닌 제안 사항을 제공한다.
{{< /warning >}}
-
## 클라우드 네이티브 보안의 4C
@@ -83,7 +87,6 @@ etcd 암호화 | 가능한 한 모든 드라이브를 암호화하는 것이 좋
* 설정 가능한 클러스터 컴포넌트의 보안
* 클러스터에서 실행되는 애플리케이션의 보안
-
### 클러스터의 컴포넌트 {#cluster-components}
우발적이거나 악의적인 접근으로부터 클러스터를 보호하고,
diff --git a/content/ko/docs/concepts/services-networking/connect-applications-service.md b/content/ko/docs/concepts/services-networking/connect-applications-service.md
index 0848c35772..2f5a9064da 100644
--- a/content/ko/docs/concepts/services-networking/connect-applications-service.md
+++ b/content/ko/docs/concepts/services-networking/connect-applications-service.md
@@ -129,7 +129,7 @@ curl을 할 수 있을 것이다. 서비스 IP는 완전히 가상이므로 외
쿠버네티스는 서비스를 찾는 두 가지 기본 모드인 환경 변수와 DNS를
지원한다. 전자는 기본적으로 작동하지만 후자는
-[CoreDNS 클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/coredns)이 필요하다.
+[CoreDNS 클러스터 애드온](https://releases.k8s.io/master/cluster/addons/dns/coredns)이 필요하다.
{{< note >}}
만약 서비스 환경 변수가 필요하지 않은 경우(소유한 프로그램과의 예상되는 충돌 가능성,
처리할 변수가 너무 많은 경우, DNS만 사용하는 경우 등) [파드 사양](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)에서
@@ -227,7 +227,7 @@ Address 1: 10.0.162.149
* 인증서를 사용하도록 구성된 nginx 서버
* 파드에 접근할 수 있는 인증서를 만드는 [시크릿](/ko/docs/concepts/configuration/secret/)
-[nginx https 예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
+[nginx https 예제](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/)에서 이 모든 것을 얻을 수 있다. 이를 위해서는 도구를 설치해야 한다. 만약 설치하지 않으려면 나중에 수동으로 단계를 수행한다. 한마디로:
```shell
make keys KEY=/tmp/nginx.key CERT=/tmp/nginx.crt
@@ -299,7 +299,7 @@ nginxsecret kubernetes.io/tls 2 1m
nginx-secure-app의 매니페스트에 대한 주목할만한 점:
- 이것은 동일한 파일에 디플로이먼트와 서비스의 사양을 모두 포함하고 있다.
-- [nginx 서버](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/https-nginx/default.conf)
+- [nginx 서버](https://github.com/kubernetes/examples/tree/master/staging/https-nginx/default.conf)
는 포트 80에서 HTTP 트래픽을 443에서 HTTPS 트래픽 서비스를 제공하고, nginx 서비스는
두 포트를 모두 노출한다.
- 각 컨테이너는 `/etc/nginx/ssl` 에 마운트된 볼륨을 통해 키에 접근할 수 있다.
diff --git a/content/ko/docs/concepts/services-networking/dns-pod-service.md b/content/ko/docs/concepts/services-networking/dns-pod-service.md
index b405617118..dea7c35965 100644
--- a/content/ko/docs/concepts/services-networking/dns-pod-service.md
+++ b/content/ko/docs/concepts/services-networking/dns-pod-service.md
@@ -197,7 +197,7 @@ A 또는 AAAA 레코드만 생성할 수 있다. (`default-subdomain.my-namespac
### 파드의 setHostnameAsFQDN 필드 {#pod-sethostnameasfqdn-field}
-{{< feature-state for_k8s_version="v1.20" state="beta" >}}
+{{< feature-state for_k8s_version="v1.22" state="stable" >}}
파드가 전체 주소 도메인 이름(FQDN)을 갖도록 구성된 경우, 해당 호스트네임은 짧은 호스트네임이다. 예를 들어, 전체 주소 도메인 이름이 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 인 파드가 있는 경우, 기본적으로 해당 파드 내부의 `hostname` 명령어는 `busybox-1` 을 반환하고 `hostname --fqdn` 명령은 FQDN을 반환한다.
@@ -313,6 +313,28 @@ search default.svc.cluster-domain.example svc.cluster-domain.example cluster-dom
options ndots:5
```
+#### 확장된 DNS 환경 설정
+
+{{< feature-state for_k8s_version="1.22" state="alpha" >}}
+
+쿠버네티스는 파드의 DNS 환경 설정을 위해 기본적으로 최대 6개의 탐색 도메인과
+최대 256자의 탐색 도메인 목록을 허용한다.
+
+kube-apiserver와 kubelet에 `ExpandedDNSConfig` 기능 게이트가 활성화되어 있으면,
+쿠버네티스는 최대 32개의 탐색 도메인과
+최대 2048자의 탐색 도메인 목록을 허용한다.
+
+### 기능 가용성
+
+파드 DNS 환경 설정 기능과 DNS 정책 "`None`" 기능의 쿠버네티스 버전별 가용성은 다음과 같다.
+
+| 쿠버네티스 버전 | 기능 지원 |
+| :---------: |:-----------:|
+| 1.14 | 안정 |
+| 1.10 | 베타 (기본값으로 켜져 있음)|
+| 1.9 | 알파 |
+
+
## {{% heading "whatsnext" %}}
diff --git a/content/ko/docs/concepts/services-networking/ingress-controllers.md b/content/ko/docs/concepts/services-networking/ingress-controllers.md
index 41524039f0..b43467d936 100644
--- a/content/ko/docs/concepts/services-networking/ingress-controllers.md
+++ b/content/ko/docs/concepts/services-networking/ingress-controllers.md
@@ -32,6 +32,7 @@ weight: 40
Citrix 애플리케이션 딜리버리 컨트롤러에서 작동한다.
* [Contour](https://projectcontour.io/)는 [Envoy](https://www.envoyproxy.io/) 기반 인그레스 컨트롤러다.
* [EnRoute](https://getenroute.io/)는 인그레스 컨트롤러로 실행할 수 있는 [Envoy](https://www.envoyproxy.io) 기반 API 게이트웨이다.
+* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md)는 인그레스 컨트롤러로 실행할 수 있는 [Easegress](https://megaease.com/easegress/) 기반 API 게이트웨이다.
* F5 BIG-IP [쿠버네티스 용 컨테이너 인그레스 서비스](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)를
이용하면 인그레스를 사용하여 F5 BIG-IP 가상 서버를 구성할 수 있다.
* [Gloo](https://gloo.solo.io)는 API 게이트웨이 기능을 제공하는 [Envoy](https://www.envoyproxy.io) 기반의
diff --git a/content/ko/docs/concepts/services-networking/ingress.md b/content/ko/docs/concepts/services-networking/ingress.md
index 802cc486bf..805260d159 100644
--- a/content/ko/docs/concepts/services-networking/ingress.md
+++ b/content/ko/docs/concepts/services-networking/ingress.md
@@ -1,4 +1,6 @@
---
+
+
title: 인그레스(Ingress)
content_type: concept
weight: 40
@@ -222,7 +224,7 @@ IngressClass 리소스에는 선택적인 파라미터 필드가 있다. 이 클
#### 네임스페이스 범위의 파라미터
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
`Parameters` 필드에는 인그레스 클래스 구성을 위해 네임스페이스 별 리소스를 참조하는 데
사용할 수 있는 `scope` 및 `namespace` 필드가 있다.
diff --git a/content/ko/docs/concepts/services-networking/network-policies.md b/content/ko/docs/concepts/services-networking/network-policies.md
index 5a9b16a309..d8926be00c 100644
--- a/content/ko/docs/concepts/services-networking/network-policies.md
+++ b/content/ko/docs/concepts/services-networking/network-policies.md
@@ -223,7 +223,7 @@ SCTP 프로토콜 네트워크폴리시를 지원하는 {{< glossary_tooltip tex
## 포트 범위 지정
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
네트워크폴리시를 작성할 때, 단일 포트 대신 포트 범위를 대상으로 지정할 수 있다.
@@ -251,17 +251,25 @@ spec:
endPort: 32768
```
-위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우, 네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가 TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
+위 규칙은 대상 포트가 32000에서 32768 사이에 있는 경우,
+네임스페이스 `default` 에 레이블이 `db` 인 모든 파드가
+TCP를 통해 `10.0.0.0/24` 범위 내의 모든 IP와 통신하도록 허용한다.
이 필드를 사용할 때 다음의 제한 사항이 적용된다.
-* 알파 기능으로, 기본적으로 비활성화되어 있다. 클러스터 수준에서 `endPort` 필드를 활성화하려면, 사용자(또는 클러스터 관리자)가 `--feature-gates=NetworkPolicyEndPort=true,…` 가 있는 API 서버에 대해 `NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+* 베타 기능으로, 기본적으로 활성화되어 있다.
+클러스터 수준에서 `endPort` 필드를 비활성화하려면, 사용자(또는 클러스터 관리자)가
+API 서버에 대해 `--feature-gates=NetworkPolicyEndPort=false,…` 명령을 이용하여
+`NetworkPolicyEndPort` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 비활성화해야 한다.
* `endPort` 필드는 `port` 필드보다 크거나 같아야 한다.
* `endPort` 는 `port` 도 정의된 경우에만 정의할 수 있다.
* 두 포트 모두 숫자여야 한다.
{{< note >}}
-클러스터는 {{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
-네트워크폴리시 명세에서 `endPort` 필드를 지원한다.
+클러스터가 네트워크폴리시 명세의 `endPort` 필드를 지원하는
+{{< glossary_tooltip text="CNI" term_id="cni" >}} 플러그인을 사용해야 한다.
+만약 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)이
+`endPort` 필드를 지원하지 않는데 네트워크폴리시의 해당 필드에 명시를 하면,
+그 정책은 `port` 필드에만 적용될 것이다.
{{< /note >}}
## 이름으로 네임스페이스 지정
diff --git a/content/ko/docs/concepts/services-networking/service.md b/content/ko/docs/concepts/services-networking/service.md
index 5c4b9edeee..230b716c78 100644
--- a/content/ko/docs/concepts/services-networking/service.md
+++ b/content/ko/docs/concepts/services-networking/service.md
@@ -72,7 +72,7 @@ _서비스_ 로 들어가보자.
마찬가지로, 서비스 정의를 API 서버에 `POST`하여
새 인스턴스를 생성할 수 있다.
서비스 오브젝트의 이름은 유효한
-[DNS 서브도메인 이름](/ko/docs/concepts/overview/working-with-objects/names/#dns-서브도메인-이름)이어야 한다.
+[RFC 1035 레이블 이름](/ko/docs/concepts/overview/working-with-objects/names/#rfc-1035-label-names)이어야 한다.
예를 들어, 각각 TCP 포트 9376에서 수신하고
`app=MyApp` 레이블을 가지고 있는 파드 세트가 있다고 가정해 보자.
@@ -188,9 +188,10 @@ DNS명을 대신 사용하는 특수한 상황의 서비스이다. 자세한 내
이 문서 뒷부분의 [ExternalName](#externalname) 섹션을 참조한다.
### 초과 용량 엔드포인트
-엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.21(또는 그 이상)
-클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: warning` 어노테이션을 추가한다.
-이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했음을 나타낸다.
+엔드포인트 리소스에 1,000개가 넘는 엔드포인트가 있는 경우 쿠버네티스 v1.22(또는 그 이상)
+클러스터는 해당 엔드포인트에 `endpoints.kubernetes.io/over-capacity: truncated` 어노테이션을 추가한다.
+이 어노테이션은 영향을 받는 엔드포인트 오브젝트가 용량을 초과했으며
+엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
### 엔드포인트슬라이스
@@ -384,6 +385,40 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
유효하지 않은 clusterIP 주소 값으로 서비스를 생성하려고 하면, API 서버는
422 HTTP 상태 코드를 리턴하여 문제점이 있음을 알린다.
+## 트래픽 정책
+
+### 외부 트래픽 정책
+
+`spec.externalTrafficPolicy` 필드를 설정하여 외부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
+이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 외부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
+`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬
+엔드포인트가 하나도 없는 경우, kube-proxy는 연관된 서비스로의 트래픽을 포워드하지 않는다.
+
+{{< note >}}
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+kube-proxy에 대해 `ProxyTerminatingEndpoints`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
+활성화하면, kube-proxy는 노드에 로컬 엔드포인트가 있는지,
+그리고 모든 로컬 엔드포인트가 "종료 중(terminating)"으로 표시되어 있는지 여부를 확인한다.
+만약 로컬 엔드포인트가 존재하는데 **모두**가 종료 중이면, kube-proxy는 `Local`로 설정된 모든 외부 트래픽 정책을 무시한다.
+대신, 모든 노드-로컬 엔드포인트가 "종료 중" 상태를 유지하는 동안,
+kube-proxy는 마치 외부 트래픽 정책이 `Cluster`로 설정되어 있는 것처럼
+그 서비스에 대한 트래픽을 정상 상태의 다른 엔드포인트로 포워드한다.
+이러한 종료 중인 엔드포인트에 대한 포워딩 정책은 `NodePort` 서비스로 트래픽을 로드밸런싱하던 외부 로드밸런서가
+헬스 체크 노드 포트가 작동하지 않을 때에도 연결들을 비돌발적으로(gracefully) 종료시킬 수 있도록 하기 위해 존재한다.
+이러한 정책이 없다면, 노드가 여전히 로드밸런서 노드 풀에 있지만
+파드 종료 과정에서 트래픽이 제거(drop)되는 상황에서 트래픽이 유실될 수 있다.
+{{< /note >}}
+
+### 내부 트래픽 정책
+
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+
+`spec.internalTrafficPolicy` 필드를 설정하여 내부 소스에서 오는 트래픽이 어떻게 라우트될지를 제어할 수 있다.
+이 필드는 `Cluster` 또는 `Local`로 설정할 수 있다. 필드를 `Cluster`로 설정하면 내부 트래픽을 준비 상태의 모든 엔드포인트로 라우트하며,
+`Local`로 설정하면 준비 상태의 노드-로컬 엔드포인트로만 라우트한다. 만약 트래픽 정책이 `Local`로 설정되어 있는데 노드-로컬
+엔드포인트가 하나도 없는 경우, kube-proxy는 트래픽을 포워드하지 않는다.
+
## 서비스 디스커버리하기
쿠버네티스는 서비스를 찾는 두 가지 기본 모드를 지원한다. - 환경
@@ -394,7 +429,7 @@ CIDR 범위 내의 유효한 IPv4 또는 IPv6 주소여야 한다.
파드가 노드에서 실행될 때, kubelet은 각 활성화된 서비스에 대해
환경 변수 세트를 추가한다. [도커 링크
호환](https://docs.docker.com/userguide/dockerlinks/) 변수
-([makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49) 참조)와
+([makeLinkVariables](https://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49) 참조)와
보다 간단한 `{SVCNAME}_SERVICE_HOST` 및 `{SVCNAME}_SERVICE_PORT` 변수를 지원하고,
이때 서비스 이름은 대문자이고 대시는 밑줄로 변환된다.
@@ -523,6 +558,7 @@ API에서 `엔드포인트` 레코드를 생성하고, DNS 구성을 수정하
[kube-proxy 구성 파일](/docs/reference/config-api/kube-proxy-config.v1alpha1/)의
동등한 `nodePortAddresses` 필드를
특정 IP 블록으로 설정할 수 있다.
+
이 플래그는 쉼표로 구분된 IP 블록 목록(예: `10.0.0.0/8`, `192.0.2.0/25`)을 사용하여 kube-proxy가 로컬 노드로 고려해야 하는 IP 주소 범위를 지정한다.
예를 들어, `--nodeport-addresses=127.0.0.0/8` 플래그로 kube-proxy를 시작하면, kube-proxy는 NodePort 서비스에 대하여 루프백(loopback) 인터페이스만 선택한다. `--nodeport-addresses`의 기본 값은 비어있는 목록이다. 이것은 kube-proxy가 NodePort에 대해 사용 가능한 모든 네트워크 인터페이스를 고려해야 한다는 것을 의미한다. (이는 이전 쿠버네티스 릴리스와도 호환된다).
@@ -641,12 +677,12 @@ v1.20부터는 `spec.allocateLoadBalancerNodePorts` 필드를 `false`로 설정
#### 로드 밸런서 구현 클래스 지정 {#load-balancer-class}
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
-v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer` 서비스 유형에
-대한 로드 밸런서 구현 클래스를 선택적으로 지정할 수 있다.
-기본적으로, `spec.loadBalancerClass` 는 `nil` 이고 `LoadBalancer` 유형의 서비스는
-클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
+`spec.loadBalancerClass` 필드를 설정하여 클라우드 제공자가 설정한 기본값 이외의 로드 밸런서 구현을 사용할 수 있다. 이 기능은 v1.21부터 사용할 수 있으며, v1.21에서는 이 필드를 사용하기 위해 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 하지만, v1.22부터는 해당 기능 게이트가 기본적으로 활성화되어 있다.
+기본적으로, `spec.loadBalancerClass` 는 `nil` 이고,
+클러스터가 클라우드 제공자의 로드밸런서를 이용하도록 `--cloud-provider` 컴포넌트 플래그를 이용하여 설정되어 있으면
+`LoadBalancer` 유형의 서비스는 클라우드 공급자의 기본 로드 밸런서 구현을 사용한다.
`spec.loadBalancerClass` 가 지정되면, 지정된 클래스와 일치하는 로드 밸런서
구현이 서비스를 감시하고 있다고 가정한다.
모든 기본 로드 밸런서 구현(예: 클라우드 공급자가 제공하는
@@ -656,7 +692,6 @@ v1.21부터는, `spec.loadBalancerClass` 필드를 설정하여 `LoadBalancer`
`spec.loadBalancerClass` 의 값은 "`internal-vip`" 또는
"`example.com/internal-vip`" 와 같은 선택적 접두사가 있는 레이블 스타일 식별자여야 한다.
접두사가 없는 이름은 최종 사용자를 위해 예약되어 있다.
-이 필드를 사용하려면 `ServiceLoadBalancerClass` 기능 게이트를 활성화해야 한다.
#### 내부 로드 밸런서
diff --git a/content/ko/docs/concepts/storage/persistent-volumes.md b/content/ko/docs/concepts/storage/persistent-volumes.md
index c70b7413ad..87d43ae09e 100644
--- a/content/ko/docs/concepts/storage/persistent-volumes.md
+++ b/content/ko/docs/concepts/storage/persistent-volumes.md
@@ -314,12 +314,9 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
* [`azureDisk`](/ko/docs/concepts/storage/volumes/#azuredisk) - Azure Disk
* [`azureFile`](/ko/docs/concepts/storage/volumes/#azurefile) - Azure File
* [`cephfs`](/ko/docs/concepts/storage/volumes/#cephfs) - CephFS 볼륨
-* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
- (**사용 중단**)
* [`csi`](/ko/docs/concepts/storage/volumes/#csi) - 컨테이너 스토리지 인터페이스 (CSI)
* [`fc`](/ko/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 스토리지
* [`flexVolume`](/ko/docs/concepts/storage/volumes/#flexVolume) - FlexVolume
-* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
* [`gcePersistentDisk`](/ko/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE Persistent Disk
* [`glusterfs`](/ko/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 볼륨
* [`hostPath`](/ko/docs/concepts/storage/volumes/#hostpath) - HostPath 볼륨
@@ -329,17 +326,28 @@ EBS 볼륨 확장은 시간이 많이 걸리는 작업이다. 또한 6시간마
* [`local`](/ko/docs/concepts/storage/volumes/#local) - 노드에 마운트된
로컬 스토리지 디바이스
* [`nfs`](/ko/docs/concepts/storage/volumes/#nfs) - 네트워크 파일 시스템 (NFS) 스토리지
-* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
- (이 볼륨 유형은 해당 클라우드 공급자가 없어진 이후 더 이상
- 작동하지 않는다.)
* [`portworxVolume`](/ko/docs/concepts/storage/volumes/#portworxvolume) - Portworx 볼륨
-* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
* [`rbd`](/ko/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) 볼륨
-* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
- (**사용 중단**)
-* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
* [`vsphereVolume`](/ko/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 볼륨
+아래의 PersistentVolume 타입은 사용 중단되었다. 이 말인 즉슨, 지원은 여전히 제공되지만 추후 쿠버네티스 릴리스에서는 삭제될 예정이라는 것이다.
+
+* [`cinder`](/ko/docs/concepts/storage/volumes/#cinder) - Cinder (오픈스택 블록 스토리지)
+ (v1.18에서 **사용 중단**)
+* [`flocker`](/ko/docs/concepts/storage/volumes/#flocker) - Flocker 스토리지
+ (v1.22에서 **사용 중단**)
+* [`quobyte`](/ko/docs/concepts/storage/volumes/#quobyte) - Quobyte 볼륨
+ (v1.22에서 **사용 중단**)
+* [`storageos`](/ko/docs/concepts/storage/volumes/#storageos) - StorageOS 볼륨
+ (v1.22에서 **사용 중단**)
+
+이전 쿠버네티스 버전은 아래의 인-트리 PersistentVolume 타입도 지원했었다.
+
+* `photonPersistentDisk` - Photon 컨트롤러 퍼시스턴트 디스크.
+ (v1.15 이후 **사용 불가**)
+* [`scaleIO`](/ko/docs/concepts/storage/volumes/#scaleio) - ScaleIO 볼륨
+ (v1.21 이후 **사용 불가**)
+
## 퍼시스턴트 볼륨
각 PV에는 스펙과 상태(볼륨의 명세와 상태)가 포함된다.
@@ -407,38 +415,40 @@ spec:
* ReadWriteOnce -- 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
* ReadOnlyMany -- 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있다
* ReadWriteMany -- 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있다
+* ReadWriteOncePod -- 하나의 파드에서 볼륨을 읽기-쓰기로 마운트할 수 있다.
+ 쿠버네티스 버전 1.22 이상인 경우에 CSI 볼륨에 대해서만 지원된다.
CLI에서 접근 모드는 다음과 같이 약어로 표시된다.
* RWO - ReadWriteOnce
* ROX - ReadOnlyMany
* RWX - ReadWriteMany
+* RWOP - ReadWriteOncePod
> __중요!__ 볼륨이 여러 접근 모드를 지원하더라도 한 번에 하나의 접근 모드를 사용하여 마운트할 수 있다. 예를 들어 GCEPersistentDisk는 하나의 노드가 ReadWriteOnce로 마운트하거나 여러 노드가 ReadOnlyMany로 마운트할 수 있지만 동시에는 불가능하다.
-| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany|
-| :--- | :---: | :---: | :---: |
-| AWSElasticBlockStore | ✓ | - | - |
-| AzureFile | ✓ | ✓ | ✓ |
-| AzureDisk | ✓ | - | - |
-| CephFS | ✓ | ✓ | ✓ |
-| Cinder | ✓ | - | - |
-| CSI | 드라이버에 따라 다름 | 드라이버에 따라 다름 | 드라이버에 따라 다름 |
-| FC | ✓ | ✓ | - |
-| FlexVolume | ✓ | ✓ | 드라이버에 따라 다름 |
-| Flocker | ✓ | - | - |
-| GCEPersistentDisk | ✓ | ✓ | - |
-| Glusterfs | ✓ | ✓ | ✓ |
-| HostPath | ✓ | - | - |
-| iSCSI | ✓ | ✓ | - |
-| Quobyte | ✓ | ✓ | ✓ |
-| NFS | ✓ | ✓ | ✓ |
-| RBD | ✓ | ✓ | - |
-| VsphereVolume | ✓ | - | - (파드가 병치될(collocated) 때 작동) |
-| PortworxVolume | ✓ | - | ✓ |
-| ScaleIO | ✓ | ✓ | - |
-| StorageOS | ✓ | - | - |
+| Volume Plugin | ReadWriteOnce | ReadOnlyMany | ReadWriteMany | ReadWriteOncePod |
+| :--- | :---: | :---: | :---: | - |
+| AWSElasticBlockStore | ✓ | - | - | - |
+| AzureFile | ✓ | ✓ | ✓ | - |
+| AzureDisk | ✓ | - | - | - |
+| CephFS | ✓ | ✓ | ✓ | - |
+| Cinder | ✓ | - | - | - |
+| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver |
+| FC | ✓ | ✓ | - | - |
+| FlexVolume | ✓ | ✓ | depends on the driver | - |
+| Flocker | ✓ | - | - | - |
+| GCEPersistentDisk | ✓ | ✓ | - | - |
+| Glusterfs | ✓ | ✓ | ✓ | - |
+| HostPath | ✓ | - | - | - |
+| iSCSI | ✓ | ✓ | - | - |
+| Quobyte | ✓ | ✓ | ✓ | - |
+| NFS | ✓ | ✓ | ✓ | - |
+| RBD | ✓ | ✓ | - | - |
+| VsphereVolume | ✓ | - | - (works when Pods are collocated) | - |
+| PortworxVolume | ✓ | - | ✓ | - | - |
+| StorageOS | ✓ | - | - | - |
### 클래스
@@ -785,6 +795,82 @@ spec:
storage: 10Gi
```
+## 볼륨 파퓰레이터(Volume populator)와 데이터 소스
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+쿠버네티스는 커스텀 볼륨 파퓰레이터를 지원한다.
+이 알파 기능은 쿠버네티스 1.18에서 도입되었으며
+1.22에서는 새로운 메카니즘과 리디자인된 API로 새롭게 구현되었다.
+현재 사용 중인 클러스터의 버전에 맞는 쿠버네티스 문서를 읽고 있는지 다시 한번
+확인한다. {{% version-check %}}
+커스텀 볼륨 파퓰레이터를 사용하려면, kube-apiserver와 kube-controller-manager에 대해
+`AnyVolumeDataSource` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+{{< /note >}}
+
+볼륨 파퓰레이터는 `dataSourceRef`라는 PVC 스펙 필드를 활용한다.
+다른 PersistentVolumeClaim 또는 VolumeSnapshot을 가리키는 참조만 명시할 수 있는
+`dataSource` 필드와는 다르게, `dataSourceRef` 필드는 동일 네임스페이스에 있는
+어떠한 오브젝트에 대한 참조도 명시할 수 있다(단, PVC 외의 다른 코어 오브젝트는 제외).
+기능 게이트가 활성화된 클러스터에서는 `dataSource`보다 `dataSourceRef`를 사용하는 것을 권장한다.
+
+## 데이터 소스 참조
+
+`dataSourceRef` 필드는 `dataSource` 필드와 거의 동일하게 동작한다.
+둘 중 하나만 명시되어 있으면, API 서버는 두 필드에 같은 값을 할당할 것이다.
+두 필드 모두 생성 이후에는 변경될 수 없으며,
+두 필드에 다른 값을 넣으려고 시도하면 검증 에러가 발생할 것이다.
+따라서 두 필드는 항상 같은 값을 갖게 된다.
+
+`dataSourceRef` 필드와 `dataSource` 필드 사이에는
+사용자가 알고 있어야 할 두 가지 차이점이 있다.
+* `dataSource` 필드는 유효하지 않은 값(예를 들면, 빈 값)을 무시하지만,
+ `dataSourceRef` 필드는 어떠한 값도 무시하지 않으며 유효하지 않은 값이 들어오면 에러를 발생할 것이다.
+ 유효하지 않은 값은 PVC를 제외한 모든 코어 오브젝트(apiGroup이 없는 오브젝트)이다.
+* `dataSourceRef` 필드는 여러 타입의 오브젝트를 포함할 수 있지만, `dataSource` 필드는
+ PVC와 VolumeSnapshot만 포함할 수 있다.
+
+기능 게이트가 활성화된 클러스터에서는 `dataSourceRef`를 사용해야 하고, 그렇지 않은
+클러스터에서는 `dataSource`를 사용해야 한다. 어떤 경우에서든 두 필드 모두를 확인해야
+할 필요는 없다. 이렇게 약간의 차이만 있는 중복된 값은 이전 버전 호환성을 위해서만
+존재하는 것이다. 상세히 설명하면, 이전 버전과 새로운 버전의 컨트롤러가 함께 동작할
+수 있는데, 이는 두 필드가 동일하기 때문이다.
+
+### 볼륨 파퓰레이터 사용하기
+
+볼륨 파퓰레이터는 비어 있지 않은 볼륨(non-empty volume)을 생성할 수 있는 {{< glossary_tooltip text="컨트롤러" term_id="controller" >}}이며,
+이 볼륨의 내용물은 커스텀 리소스(Custom Resource)에 의해 결정된다.
+파퓰레이티드 볼륨(populated volume)을 생성하려면 `dataSourceRef` 필드에 커스텀 리소스를 기재한다.
+
+```yaml
+apiVersion: v1
+kind: PersistentVolumeClaim
+metadata:
+ name: populated-pvc
+spec:
+ dataSourceRef:
+ name: example-name
+ kind: ExampleDataSource
+ apiGroup: example.storage.k8s.io
+ accessModes:
+ - ReadWriteOnce
+ resources:
+ requests:
+ storage: 10Gi
+```
+
+볼륨 파퓰레이터는 외부 컴포넌트이기 때문에,
+만약 적합한 컴포넌트가 설치되어 있지 않다면 볼륨 파퓰레이터를 사용하는 PVC에 대한 생성 요청이 실패할 수 있다.
+외부 컨트롤러는 '컴포넌트가 없어서 PVC를 생성할 수 없음' 경고와 같은
+PVC 생성 상태에 대한 피드백을 제공하기 위해, PVC에 대한 이벤트를 생성해야 한다.
+
+알파 버전의 [볼륨 데이터 소스 검증기](https://github.com/kubernetes-csi/volume-data-source-validator)를
+클러스터에 설치할 수 있다.
+해당 데이터 소스를 다루는 파퓰레이터가 등록되어 있지 않다면 이 컨트롤러가 PVC에 경고 이벤트를 생성한다.
+PVC를 위한 적절한 파퓰레이터가 설치되어 있다면,
+볼륨 생성과 그 과정에서 발생하는 이슈에 대한 이벤트를 생성하는 것은 파퓰레이터 컨트롤러의 몫이다.
+
## 포터블 구성 작성
광범위한 클러스터에서 실행되고 퍼시스턴트 스토리지가 필요한
diff --git a/content/ko/docs/concepts/storage/storage-capacity.md b/content/ko/docs/concepts/storage/storage-capacity.md
new file mode 100644
index 0000000000..4aeb1ba8c1
--- /dev/null
+++ b/content/ko/docs/concepts/storage/storage-capacity.md
@@ -0,0 +1,117 @@
+---
+
+
+
+
+
+
+title: 스토리지 용량
+content_type: concept
+weight: 45
+---
+
+
+
+스토리지 용량은 제한이 있으며, 파드가 실행되는 노드의 상황에 따라 달라질 수 있다.
+예를 들어, 일부 노드에서 NAS(Network Attached Storage)에 접근할 수 없는 경우가 있을 수 있으며,
+또는 각 노드에 종속적인 로컬 스토리지를 사용하는 경우일 수도 있다.
+
+{{< feature-state for_k8s_version="v1.19" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+
+이 페이지에서는 쿠버네티스가 어떻게 스토리지 용량을 추적하고
+스케줄러가 남아 있는 볼륨을 제공하기 위해 스토리지 용량이 충분한 노드에
+파드를 스케줄링하기 위해 이 정보를 어떻게 사용하는지 설명한다.
+스토리지 용량을 추적하지 않으면, 스케줄러는
+볼륨을 제공할 충분한 용량이 없는 노드를 선정할 수 있으며,
+스케줄링을 여러 번 다시 시도해야 한다.
+
+스토리지 용량 추적은 {{< glossary_tooltip
+text="컨테이너 스토리지 인터페이스(CSI)" term_id="csi" >}} 드라이버에서 지원하며,
+CSI 드라이버를 설치할 때 [사용하도록 설정](#스토리지-용량-추적-활성화)해야 한다.
+
+
+
+## API
+
+ 이 기능에는 다음 두 가지 API 확장이 있다.
+- CSIStorageCapacity 오브젝트:
+ CSI 드라이버가 설치된 네임스페이스에
+ CSI 드라이버가 이 오브젝트를 생성한다. 각 오브젝트는
+ 하나의 스토리지 클래스에 대한 용량 정보를 담고 있으며,
+ 어떤 노드가 해당 스토리지에 접근할 수 있는지를 정의한다.
+- [ `CSIDriverSpec.StorageCapacity` 필드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#csidriverspec-v1-storage-k8s-io):
+ `true`로 설정하면, 쿠버네티스 스케줄러가
+ CSI 드라이버를 사용하는 볼륨의 스토리지 용량을 고려하게 된다.
+
+## 스케줄링
+
+다음과 같은 경우 쿠버네티스 스케줄러에서 스토리지 용량 정보를 사용한다.
+- `CSIStorageCapacity` 기능 게이트(feature gate)가 true이고,
+- 파드가 아직 생성되지 않은 볼륨을 사용하고,
+- 해당 볼륨은 CSI 드라이버를 참조하고
+ `WaitForFirstConsumer`
+ [볼륨 바인딩 모드](/ko/docs/concepts/storage/storage-classes/#볼륨-바인딩-모드)를 사용하는
+ {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 사용하고,
+- 드라이버의 `CSIDriver` 오브젝트에 `StorageCapacity` 속성이
+ true로 설정되어 있다.
+
+이 경우 스케줄러는 파드에 제공할
+충분한 스토리지가 있는 노드만 고려한다.
+이 검사는 아주 간단한데,
+볼륨의 크기를 노드를 포함하는 토폴로지를 가진 `CSIStorageCapacity` 오브젝트에
+나열된 용량과 비교한다.
+
+볼륨 바인딩 모드가 `Immediate` 인 볼륨의 경우에는 스토리지 드라이버는
+볼륨을 사용하는 파드와 관계없이 볼륨을 생성할 위치를 정한다.
+볼륨을 생성한 후에, 스케줄러는
+볼륨을 사용할 수 있는 노드에 파드를 스케줄링한다.
+
+[CSI 임시 볼륨](/ko/docs/concepts/storage/volumes/#csi)의 경우에는
+볼륨 유형이 로컬 볼륨이고
+큰 자원이 필요하지 않은 특정 CSI 드라이버에서만 사용된다는 가정하에,
+항상 스토리지 용량을 고려하지 않고
+스케줄링한다.
+
+## 리스케줄링
+
+`WaitForFirstConsumer` 볼륨을 가진 파드에 대해
+노드가 선정되었더라도 아직은 잠정적인 결정이다. 다음 단계에서
+선정한 노드에서 볼륨을 사용할 수 있어야 한다는 힌트를 주고
+CSI 스토리지 드라이버에 볼륨 생성을 요청한다
+
+쿠버네티스는 시간이 지난 스토리지 용량 정보를 기반으로
+노드를 선정할 수도 있으므로, 볼륨을 실제로 생성하지 않을 수도 있다.
+그런 다음 노드 선정이 재설정되고 쿠버네티스 스케줄러가
+파드를 위한 노드를 찾는 것을 재시도한다.
+
+## 제한사항
+
+스토리지 용량 추적은 첫 시도에 스케줄링이 성공할 가능성을 높이지만,
+스케줄러가 시간이 지난 정보를 기반으로
+결정해야 할 수도 있기 때문에 이를 보장하지는 않는다.
+일반적으로 스토리지 용량 정보가 없는 스케줄링과
+동일한 재시도 메커니즘으로 스케줄링 실패를 처리한다.
+
+스케줄링이 영구적으로 실패할 수 있는 한 가지 상황은
+파드가 여러 볼륨을 사용하는 경우이다.
+토폴로지 세그먼트에 하나의 볼륨이 이미 생성되어
+다른 볼륨에 충분한 용량이 남아 있지 않을 수 있다.
+이러한 상황을 복구하려면
+용량을 늘리거나 이미 생성된 볼륨을 삭제하는 등의 수작업이 필요하며,
+자동으로 처리하려면
+[추가 작업](https://github.com/kubernetes/enhancements/pull/1703)이 필요하다.
+
+## 스토리지 용량 추적 활성화
+
+스토리지 용량 추적은 베타 기능이며,
+쿠버네티스 1.21 이후 버전부터 쿠버네티스 클러스터에 기본적으로 활성화되어 있다.
+클러스터에서 스토리지 용량 추적 기능을 활성화하는 것뿐만 아니라, CSI 드라이버에서도 이 기능을 지원해야 한다.
+자세한 내용은 드라이버 문서를 참조한다.
+
+## {{% heading "whatsnext" %}}
+
+- 설계에 대한 자세한 내용은
+ [파드 스케줄링 스토리지 용량 제약 조건](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md)을 참조한다.
+- 이 기능의 추가 개발에 대한 자세한 내용은 [개선 추적 이슈 #1472](https://github.com/kubernetes/enhancements/issues/1472)를 참조한다.
+- [쿠버네티스 스케줄러](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 살펴본다.
diff --git a/content/ko/docs/concepts/storage/storage-classes.md b/content/ko/docs/concepts/storage/storage-classes.md
index f4385419f1..c915b65fad 100644
--- a/content/ko/docs/concepts/storage/storage-classes.md
+++ b/content/ko/docs/concepts/storage/storage-classes.md
@@ -76,7 +76,7 @@ volumeBindingMode: Immediate
| Glusterfs | ✓ | [Glusterfs](#glusterfs) |
| iSCSI | - | - |
| Quobyte | ✓ | [Quobyte](#quobyte) |
-| NFS | - | - |
+| NFS | - | [NFS](#nfs) |
| RBD | ✓ | [Ceph RBD](#ceph-rbd) |
| VsphereVolume | ✓ | [vSphere](#vsphere) |
| PortworxVolume | ✓ | [Portworx 볼륨](#portworx-볼륨) |
@@ -423,6 +423,29 @@ parameters:
헤드리스 서비스를 자동으로 생성한다. 퍼시스턴트 볼륨 클레임을
삭제하면 동적 엔드포인트와 서비스가 자동으로 삭제된다.
+### NFS
+
+```yaml
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+ name: example-nfs
+provisioner: example.com/external-nfs
+parameters:
+ server: nfs-server.example.com
+ path: /share
+ readOnly: false
+```
+
+* `server`: NFS 서버의 호스트네임 또는 IP 주소.
+* `path`: NFS 서버가 익스포트(export)한 경로.
+* `readOnly`: 스토리지를 읽기 전용으로 마운트할지 나타내는 플래그(기본값: false).
+
+쿠버네티스에는 내장 NFS 프로비저너가 없다. NFS를 위한 스토리지클래스를 생성하려면 외부 프로비저너를 사용해야 한다.
+예시는 다음과 같다.
+* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
+* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
+
### OpenStack Cinder
```yaml
@@ -578,6 +601,12 @@ parameters:
### Quobyte
+{{< feature-state for_k8s_version="v1.22" state="deprecated" >}}
+
+Quobyte 인-트리 스토리지 플러그인은 사용 중단되었으며,
+아웃-오브-트리 Quobyte 플러그인에 대한 [예제](https://github.com/quobyte/quobyte-csi/blob/master/example/StorageClass.yaml)
+`StorageClass`는 Quobyte CSI 저장소에서 찾을 수 있다.
+
```yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
diff --git a/content/ko/docs/concepts/storage/volumes.md b/content/ko/docs/concepts/storage/volumes.md
index 29f4755172..349f47a55c 100644
--- a/content/ko/docs/concepts/storage/volumes.md
+++ b/content/ko/docs/concepts/storage/volumes.md
@@ -124,13 +124,13 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}}
컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 `awsElasticBlockStore` 스토리지
-플러그인을 끄려면, `CSIMigrationAWSComplete` 플래그를 `true` 로 설정한다. 이 기능은 모든 워커 노드에서 `ebs.csi.aws.com` 컨테이너 스토리지 인터페이스(CSI) 드라이버 설치를 필요로 한다.
+플러그인을 끄려면, `InTreePluginAWSUnregister` 플래그를 `true` 로 설정한다.
### azureDisk {#azuredisk}
`azureDisk` 볼륨 유형은 Microsoft Azure [데이터 디스크](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers)를 파드에 마운트한다.
-더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md)을 참고한다.
+더 자세한 내용은 [`azureDisk` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md)을 참고한다.
#### azureDisk CSI 마이그레이션
@@ -148,7 +148,7 @@ EBS 볼륨이 파티션된 경우, 선택적 필드인 `partition: "}}/staging/volumes/azure_file/README.md)을 참고한다.
+더 자세한 내용은 [`azureFile` 볼륨 플러그인](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md)을 참고한다.
#### azureFile CSI 마이그레이션
@@ -176,7 +176,7 @@ Azure File CSI 드라이버는 동일한 볼륨을 다른 fsgroup에서 사용
CephFS를 사용하기 위해선 먼저 Ceph 서버를 실행하고 공유를 내보내야 한다.
{{< /note >}}
-더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/)를 참조한다.
+더 자세한 내용은 [CephFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)를 참조한다.
### cinder
@@ -347,7 +347,7 @@ targetWWN은 해당 WWN이 다중 경로 연결에서 온 것으로 예상한다
쿠버네티스 호스트가 해당 LUN에 접근할 수 있다.
{{< /note >}}
-더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel)를 참고한다.
+더 자세한 내용은 [파이버 채널 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel)를 참고한다.
### flocker (사용 중단됨(deprecated)){#flocker}
@@ -365,7 +365,7 @@ Flocker는 파드가 스케줄 되어있는 노드에 다시 연결한다. 이
`flocker` 볼륨을 사용하기 위해서는 먼저 Flocker를 설치하고 실행한다.
{{< /note >}}
-더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker)를 참조한다.
+더 자세한 내용은 [Flocker 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker)를 참조한다.
### gcePersistentDisk
@@ -462,7 +462,8 @@ spec:
required:
nodeSelectorTerms:
- matchExpressions:
- - key: failure-domain.beta.kubernetes.io/zone
+ # 1.21 이전 버전에서는 failure-domain.beta.kubernetes.io/zone 키를 사용해야 한다.
+ - key: topology.kubernetes.io/zone
operator: In
values:
- us-central1-a
@@ -480,6 +481,13 @@ GCE PD의 `CSIMigration` 기능이 활성화된 경우 기존 인-트리 플러
를 설치하고 `CSIMigration` 과 `CSIMigrationGCE`
베타 기능을 활성화해야 한다.
+#### GCE CSI 마이그레이션 완료
+
+{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+
+컨트롤러 매니저와 kubelet이 `gcePersistentDisk` 스토리지 플러그인을 로드하는 것을 방지하려면,
+`InTreePluginGCEUnregister` 플래그를 `true`로 설정한다.
+
### gitRepo (사용 중단됨) {#gitrepo}
{{< warning >}}
@@ -525,7 +533,7 @@ glusterfs 볼륨에 데이터를 미리 채울 수 있으며, 파드 간에 데
사용하려면 먼저 GlusterFS를 설치하고 실행해야 한다.
{{< /note >}}
-더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs)를 본다.
+더 자세한 내용은 [GlusterFS 예시](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs)를 본다.
### hostPath {#hostpath}
@@ -653,7 +661,7 @@ iSCSI 특징은 여러 고객이 읽기 전용으로 마운트할 수
iSCSI 볼륨은 읽기-쓰기 모드에서는 단일 고객만 마운트할 수 있다.
동시 쓰기는 허용되지 않는다.
-더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi)를 본다.
+더 자세한 내용은 [iSCSI 예시](https://github.com/kubernetes/examples/tree/master/volumes/iscsi)를 본다.
### local
@@ -741,7 +749,7 @@ local [스토리지클래스(StorageClas)](/ko/docs/concepts/storage/storage-cla
사용하려면 먼저 NFS 서버를 실행하고 공유를 내보내야 한다.
{{< /note >}}
-더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs)를 본다.
+더 자세한 내용은 [NFS 예시](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs)를 본다.
### persistentVolumeClaim {#persistentvolumeclaim}
@@ -789,7 +797,7 @@ spec:
있는지 확인한다.
{{< /note >}}
-자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md) 예제를 참고한다.
+자세한 내용은 [Portworx 볼륨](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) 예제를 참고한다.
### projected
@@ -803,7 +811,7 @@ spec:
* `serviceAccountToken`
모든 소스는 파드와 동일한 네임스페이스에 있어야 한다. 더 자세한 내용은
-[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
+[올인원 볼륨 디자인 문서](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md)를 본다.
#### 시크릿, 다운워드 API 그리고 컨피그맵이 있는 구성 예시 {#example-configuration-secret-downwardapi-configmap}
@@ -931,7 +939,7 @@ projected 볼륨 소스를 [`subPath`](#subpath-사용하기) 볼륨으로 마
해당 볼륨 소스의 업데이트를 수신하지 않는다.
{{< /note >}}
-### quobyte
+### quobyte (사용 중단됨) {#quobyte}
`quobyte` 볼륨을 사용하면 기존 [Quobyte](https://www.quobyte.com) 볼륨을
파드에 마운트할 수 있다.
@@ -964,52 +972,9 @@ RBD의 특징은 여러 고객이 동시에 읽기 전용으로 마운트할 수
RBD는 읽기-쓰기 모드에서 단일 고객만 마운트할 수 있다.
동시 쓰기는 허용되지 않는다.
-더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd)를
+더 자세한 내용은 [RBD 예시](https://github.com/kubernetes/examples/tree/master/volumes/rbd)를
참고한다.
-### scaleIO (사용 중단됨) {#scaleio}
-
-ScaleIO는 기존 하드웨어를 사용해서 확장 가능한 공유 블럭 네트워크 스토리지 클러스터를
-생성하는 소프트웨어 기반 스토리지 플랫폼이다. `scaleIO` 볼륨
-플러그인을 사용하면 배포된 파드가 기존 ScaleIO에 접근할 수
-있다. 퍼시스턴트 볼륨 클레임을 위해 새로운 볼륨을 동적으로 프로비저닝하는
-방법에 대한 자세한 내용은
-[ScaleIO 퍼시스턴트 볼륨](/ko/docs/concepts/storage/persistent-volumes/#scaleio)을 참고한다.
-
-{{< note >}}
-사용하기 위해선 먼저 기존에 ScaleIO 클러스터를 먼저 설정하고
-생성한 볼륨과 함께 실행해야 한다.
-{{< /note >}}
-
-다음의 예시는 ScaleIO를 사용하는 파드 구성이다.
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
- name: pod-0
-spec:
- containers:
- - image: k8s.gcr.io/test-webserver
- name: pod-0
- volumeMounts:
- - mountPath: /test-pd
- name: vol-0
- volumes:
- - name: vol-0
- scaleIO:
- gateway: https://localhost:443/api
- system: scaleio
- protectionDomain: sd0
- storagePool: sp1
- volumeName: vol-0
- secretRef:
- name: sio-secret
- fsType: xfs
-```
-
-더 자세한 내용은 [ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio) 예제를 참고한다.
-
### secret
`secret` 볼륨은 암호와 같은 민감한 정보를 파드에 전달하는데
@@ -1029,7 +994,7 @@ tmpfs(RAM 기반 파일시스템)로 지원되기 때문에 비 휘발성 스토
더 자세한 내용은 [시크릿 구성하기](/ko/docs/concepts/configuration/secret/)를 참고한다.
-### storageOS {#storageos}
+### storageOS (사용 중단됨) {#storageos}
`storageos` 볼륨을 사용하면 기존 [StorageOS](https://www.storageos.com)
볼륨을 파드에 마운트할 수 있다.
@@ -1177,7 +1142,7 @@ vSphere CSI 드라이버에서 생성된 새 볼륨은 이러한 파라미터를
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, 이 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버가 설치해야 한다.
+`vsphereVolume` 플러그인이 컨트롤러 관리자와 kubelet에 의해 로드되지 않도록 기능을 비활성화하려면, `InTreePluginvSphereUnregister` 기능 플래그를 `true` 로 설정해야 한다. 이를 위해서는 모든 워커 노드에 `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} 드라이버를 설치해야 한다.
## subPath 사용하기 {#using-subpath}
diff --git a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
index 6935cf8fb4..740929b05c 100644
--- a/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
+++ b/content/ko/docs/concepts/workloads/controllers/cron-jobs.md
@@ -36,9 +36,10 @@ kube-controller-manager 컨테이너에 설정된 시간대는
## 크론잡
-크론잡은 백업 실행 또는 이메일 전송과 같은 정기적이고 반복적인
-작업을 만드는데 유용하다. 또한 크론잡은 클러스터가 유휴 상태일 때 잡을
-스케줄링하는 것과 같이 특정 시간 동안의 개별 작업을 스케줄할 수 있다.
+크론잡은 백업, 리포트 생성 등의 정기적 작업을 수행하기 위해 사용된다.
+각 작업은 무기한 반복되도록 구성해야 한다(예:
+1일/1주/1달마다 1회).
+작업을 시작해야 하는 해당 간격 내 특정 시점을 정의할 수 있다.
### 예시
diff --git a/content/ko/docs/concepts/workloads/controllers/daemonset.md b/content/ko/docs/concepts/workloads/controllers/daemonset.md
index 1496b25ec3..dc8f543048 100644
--- a/content/ko/docs/concepts/workloads/controllers/daemonset.md
+++ b/content/ko/docs/concepts/workloads/controllers/daemonset.md
@@ -229,5 +229,7 @@ Kubelet이 감시하는 특정 디렉터리에 파일을 작성하는 파드를
파드가 실행되는 호스트를 정확하게 제어하는 것보다 레플리카의 수를 스케일링 업 및 다운 하고,
업데이트 롤아웃이 더 중요한 프런트 엔드와 같은 것은 스테이트리스 서비스의
-디플로이먼트를 사용한다. 파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요하고,
-다른 파드의 실행 이전에 필요한 경우에는 데몬셋을 사용한다.
+디플로이먼트를 사용한다. 데몬셋이 특정 노드에서 다른 파드가 올바르게 실행되도록 하는 노드 수준 기능을 제공한다면,
+파드 사본이 항상 모든 호스트 또는 특정 호스트에서 실행되는 것이 중요한 경우에 데몬셋을 사용한다.
+
+예를 들어, [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)은 데몬셋으로 실행되는 컴포넌트를 포함할 수 있다. 데몬셋 컴포넌트는 작동 중인 노드가 정상적인 클러스터 네트워킹을 할 수 있도록 한다.
diff --git a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
index a3ed4ea68d..225ff28948 100644
--- a/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
+++ b/content/ko/docs/concepts/workloads/controllers/garbage-collection.md
@@ -6,6 +6,18 @@ weight: 60
+
+{{< note >}}
+이 한글 문서는 더 이상 관리되지 않습니다.
+
+이 문서의 기반이 된 영어 원문은 삭제되었으며,
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)에 병합되었습니다.
+
+[Garbage Collection](/docs/concepts/architecture/garbage-collection/)의 한글화가 완료되면,
+이 문서는 삭제될 수 있습니다.
+{{< /note >}}
+
+
쿠버네티스의 가비지 수집기는 한때 소유자가 있었지만, 더 이상
소유자가 없는 오브젝트들을 삭제하는 역할을 한다.
diff --git a/content/ko/docs/concepts/workloads/controllers/job.md b/content/ko/docs/concepts/workloads/controllers/job.md
index c24beb0fca..21da00ff5a 100644
--- a/content/ko/docs/concepts/workloads/controllers/job.md
+++ b/content/ko/docs/concepts/workloads/controllers/job.md
@@ -187,14 +187,7 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
### 완료 모드
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
-
-{{< note >}}
-인덱싱된 잡을 생성하려면, [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
-`IndexedJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
-{{< /note >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
완료 횟수가 _고정적인 완료 횟수_ 즉, null이 아닌 `.spec.completions` 가 있는 잡은
`.spec.completionMode` 에 지정된 완료 모드를 가질 수 있다.
@@ -203,8 +196,14 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
완료된 파드가 있는 경우 작업이 완료된 것으로 간주된다. 즉, 각 파드
완료는 서로 상동하다(homologous). null `.spec.completions` 가 있는
잡은 암시적으로 `NonIndexed` 이다.
-- `Indexed`: 잡의 파드는 `batch.kubernetes.io/job-completion-index`
- 어노테이션에서 사용할 수 있는 0에서 `.spec.completions-1` 까지 연결된 완료 인덱스를 가져온다.
+- `Indexed`: 잡의 파드는 연결된 완료 인덱스를 0에서 `.spec.completions-1` 까지
+ 가져온다. 이 인덱스는 다음의 세 가지 메카니즘으로 얻을 수 있다.
+ - 파드 어노테이션 `batch.kubernetes.io/job-completion-index`.
+ - 파드 호스트네임 중 일부(`$(job-name)-$(index)` 형태). 인덱스된(Indexed) 잡과
+ {{< glossary_tooltip text="서비스" term_id="Service" >}}를 결합하여 사용하고
+ 있다면, 잡에 속한 파드는 DNS를 이용하여 서로를 디스커버 하기 위해 사전에 결정된
+ 호스트네임을 사용할 수 있다.
+ - 컨테이너화된 태스크의 경우, `JOB_COMPLETION_INDEX` 환경 변수.
각 인덱스에 대해 성공적으로 완료된 파드가 하나 있으면 작업이 완료된 것으로
간주된다. 이 모드를 사용하는 방법에 대한 자세한 내용은
[정적 작업 할당을 사용한 병렬 처리를 위해 인덱싱된 잡](/docs/tasks/job/indexed-parallel-processing-static/)을 참고한다.
@@ -255,7 +254,8 @@ _작업 큐_ 잡은 `.spec.completions` 를 설정하지 않은 상태로 두고
## 잡의 종료와 정리
-잡이 완료되면 파드가 더 이상 생성되지도 않지만, 삭제되지도 않는다. 이를 유지하면
+잡이 완료되면 파드가 더 이상 생성되지도 않지만, [일반적으로는](#pod-backoff-failure-policy) 삭제되지도 않는다.
+이를 유지하면
완료된 파드의 로그를 계속 보며 에러, 경고 또는 다른 기타 진단 출력을 확인할 수 있다.
잡 오브젝트는 완료된 후에도 상태를 볼 수 있도록 남아 있다. 상태를 확인한 후 이전 잡을 삭제하는 것은 사용자의 몫이다.
`kubectl` 로 잡을 삭제할 수 있다 (예: `kubectl delete jobs/pi` 또는 `kubectl delete -f ./job.yaml`). `kubectl` 을 사용해서 잡을 삭제하면 생성된 모든 파드도 함께 삭제된다.
@@ -402,14 +402,12 @@ spec:
### 잡 일시 중지
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
{{< note >}}
-잡 일시 중지는 쿠버네티스 버전 1.21 이상에서 사용할 수 있다. 이 기능을
-사용하려면 [API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)
-및 [컨트롤러 관리자](/docs/reference/command-line-tools-reference/kube-controller-manager/)에서
-`SuspendJob` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
-활성화해야 한다.
+이 기능은 쿠버네티스 버전 1.21에서는 알파 상태였으며,
+이 때문에 이 기능을 활성화하기 위해서는 추가적인 단계를 진행해야 한다.
+[현재 사용 중인 쿠버네티스 버전과 맞는 문서](/ko/docs/home/supported-doc-versions/)를 읽고 있는 것이 맞는지 다시 한번 확인한다.
{{< /note >}}
잡이 생성되면, 잡 컨트롤러는 잡의 요구 사항을 충족하기 위해
@@ -568,6 +566,46 @@ spec:
`manualSelector: true` 를 설정하면 시스템에게 사용자가 무엇을 하는지 알고 있음을 알리고, 이런
불일치를 허용한다.
+### 종료자(finalizers)를 이용한 잡 추적
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+{{< note >}}
+이 기능을 이용하기 위해서는
+[API 서버](/docs/reference/command-line-tools-reference/kube-apiserver/)와
+[컨트롤러 매니저](/docs/reference/command-line-tools-reference/kube-controller-manager/)에 대해
+`JobTrackingWithFinalizers` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 활성화해야 한다.
+기본적으로는 비활성화되어 있다.
+
+이 기능이 활성화되면, 컨트롤 플레인은 아래에 설명할 동작을 이용하여 새로운 잡이 생성되는지 추적한다.
+기존에 존재하던 잡은 영향을 받지 않는다.
+사용자가 느낄 수 있는 유일한 차이점은 컨트롤 플레인이 잡 종료를 좀 더 정확하게 추적할 수 있다는 것이다.
+{{< /note >}}
+
+이 기능이 활성화되지 않으면, 잡
+{{< glossary_tooltip text="컨트롤러" term_id="controller" >}}는
+`succeeded`와 `failed` 파드의 수를 세어 잡 상태를 추적한다.
+그런데, 파드는 다음과 같은 이유로 제거될 수 있다.
+- 노드가 다운되었을 때 가비지 콜렉터가 버려진(orphan) 파드를 제거
+- 가비지 콜렉터가 (`Succeeded` 또는 `Failed` 단계에 있는) 완료된 파드를
+ 일정 임계값 이후에 제거
+- 잡에 속한 파드를 사용자가 임의로 제거
+- (쿠버네티스에 속하지 않는) 외부 컨트롤러가 파드를 제거하거나
+ 교체
+
+클러스터에서 `JobTrackingWithFinalizers` 기능을 활성화하면,
+컨트롤 플레인은 잡에 속하는 파드의 상태를 추적하고
+API 서버에서 파드가 제거되면 이를 알아챈다.
+이를 위해, 잡 컨트롤러는 `batch.kubernetes.io/job-tracking` 종료자를 갖는 파드를 생성한다.
+컨트롤러는 파드의 상태 변화가 잡 상태에 반영된 후에만 종료자를 제거하므로,
+이후 다른 컨트롤러나 사용자가 파드를 제거할 수 있다.
+
+잡 컨트롤러는 새로운 잡에 대해서만 새로운 알고리즘을 적용한다.
+이 기능이 활성화되기 전에 생성된 잡은 영향을 받지 않는다.
+잡에 `batch.kubernetes.io/job-tracking` 어노테이션이 있는지 확인하여,
+잡 컨트롤러가 파드 종료자를 이용하여 잡을 추적하고 있는지 여부를 확인할 수 있다.
+이 어노테이션을 잡에 수동으로 추가하거나 제거해서는 **안 된다**.
+
## 대안
### 베어(Bare) 파드
@@ -594,7 +632,7 @@ spec:
시작하기에는 다소 복잡할 수 있으며 쿠버네티스와의 통합성이 낮아진다.
이 패턴의 한 예시는 파드를 시작하는 잡이다. 파드는 스크립트를 실행해서
-스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/spark/README.md)를 본다)를 시작하고,
+스파크(Spark) 마스터 컨트롤러 ([스파크 예시](https://github.com/kubernetes/examples/tree/master/staging/spark/README.md)를 본다)를 시작하고,
스파크 드라이버를 실행한 다음, 정리한다.
이 접근 방식의 장점은 전체 프로세스가 잡 오브젝트의 완료를 보장하면서도,
diff --git a/content/ko/docs/concepts/workloads/controllers/replicaset.md b/content/ko/docs/concepts/workloads/controllers/replicaset.md
index 7cf399d242..c795332625 100644
--- a/content/ko/docs/concepts/workloads/controllers/replicaset.md
+++ b/content/ko/docs/concepts/workloads/controllers/replicaset.md
@@ -323,9 +323,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
모든 기준에 대해 동등하다면, 스케일 다운할 파드가 임의로 선택된다.
### 파드 삭제 비용
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
-[`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여,
+[`controller.kubernetes.io/pod-deletion-cost`](/ko/docs/reference/labels-annotations-taints/#pod-deletion-cost) 어노테이션을 이용하여,
레플리카셋을 스케일 다운할 때 어떤 파드부터 먼저 삭제할지에 대한 우선순위를 설정할 수 있다.
이 어노테이션은 파드에 설정되어야 하며, [-2147483647, 2147483647] 범위를 갖는다.
@@ -335,9 +335,9 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron
파드에 대해 이 값을 명시하지 않으면 기본값은 0이다. 음수로도 설정할 수 있다.
유효하지 않은 값은 API 서버가 거부한다.
-이 기능은 알파 상태이며 기본적으로는 비활성화되어 있다.
-kube-apiserver와 kube-controller-manager에서 `PodDeletionCost`
-[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 켜서 활성화할 수 있다.
+이 기능은 베타 상태이며 기본적으로 활성화되어 있다.
+kube-apiserver와 kube-controller-manager에 대해 `PodDeletionCost`
+[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 이용하여 비활성화할 수 있다.
{{< note >}}
- 이 기능은 best-effort 방식으로 동작하므로, 파드 삭제 순서를 보장하지는 않는다.
diff --git a/content/ko/docs/concepts/workloads/controllers/statefulset.md b/content/ko/docs/concepts/workloads/controllers/statefulset.md
index e231770cc5..5b926e1b14 100644
--- a/content/ko/docs/concepts/workloads/controllers/statefulset.md
+++ b/content/ko/docs/concepts/workloads/controllers/statefulset.md
@@ -32,7 +32,7 @@ weight: 30
## 제한사항
-* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
+* 파드에 지정된 스토리지는 관리자에 의해 [퍼시스턴트 볼륨 프로비저너](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md)를 기반으로 하는 `storage class` 를 요청해서 프로비전하거나 사전에 프로비전이 되어야 한다.
* 스테이트풀셋을 삭제 또는 스케일 다운해도 스테이트풀셋과 연관된 볼륨이 *삭제되지 않는다*. 이는 일반적으로 스테이트풀셋과 연관된 모든 리소스를 자동으로 제거하는 것보다 더 중요한 데이터의 안전을 보장하기 위함이다.
* 스테이트풀셋은 현재 파드의 네트워크 신원을 책임지고 있는 [헤드리스 서비스](/ko/docs/concepts/services-networking/service/#헤드리스-headless-서비스)가 필요하다. 사용자가 이 서비스를 생성할 책임이 있다.
* 스테이트풀셋은 스테이트풀셋의 삭제 시 파드의 종료에 대해 어떠한 보증을 제공하지 않는다. 스테이트풀셋에서는 파드가 순차적이고 정상적으로 종료(graceful termination)되도록 하려면, 삭제 전 스테이트풀셋의 스케일을 0으로 축소할 수 있다.
@@ -223,27 +223,31 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
## 업데이트 전략
-쿠버네티스 1.7 및 이후에는 스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
+스테이트풀셋의 `.spec.updateStrategy` 필드는 스테이트풀셋의
파드에 대한 컨테이너, 레이블, 리소스의 요청/제한 그리고 주석에 대한 자동화된 롤링 업데이트를
-구성하거나 비활성화 할 수 있다.
+구성하거나 비활성화할 수 있다. 두 가지 가능한 전략이 있다.
-### 삭제 시(On Delete)
-
-`OnDelete` 업데이트 전략은 레거시(1.6과 이전)의 행위를 구현한다. 이때 스테이트풀셋의
-`.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며, 스테이트풀셋 컨트롤러는
-스테이트풀셋의 파드를 자동으로 업데이트하지 않는다. 사용자는 컨트롤러가 스테이트풀셋의
+`OnDelete`(삭제시)
+: 스테이트풀셋의 `.spec.updateStrategy.type` 은 `OnDelete` 를 설정하며,
+스테이트풀셋 컨트롤러는 스테이트풀셋의 파드를 자동으로 업데이트하지 않는다.
+사용자는 컨트롤러가 스테이트풀셋의
`.spec.template`를 반영하는 수정된 새로운 파드를 생성하도록 수동으로 파드를 삭제해야 한다.
-### 롤링 업데이트
+`RollingUpdate`(롤링 업데이트)
+: `롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
+구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다.
-`롤링 업데이트` 의 업데이트 전략은 스테이트풀셋의 파드에 대한 롤링 업데이트를
-구현한다. 롤링 업데이트는 `.spec.updateStrategy` 가 지정되지 않으면 기본 전략이 된다. 스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
-스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성을 한다. 이 과정에서 똑같이
-순차적으로 파드가 종료되고(가장 큰 수에서 작은 수까지),
-각 파드의 업데이트는 한 번에 하나씩 한다. 이전 버전을 업데이트하기 전까지 업데이트된 파드가 실행 및 준비될
-때까지 기다린다.
+## 롤링 업데이트
-#### 파티션(Partition)
+스테이트풀셋에 `롤링 업데이트` 가 `.spec.updateStrategy.type` 에 설정되면
+스테이트풀셋 컨트롤러는 스테이트풀셋의 각 파드를 삭제 및 재생성한다. 이 과정에서 똑같이
+순차적으로 파드가 종료되고(가장 큰 순서 색인에서부터에서 작은 순서 색인쪽으로),
+각 파드의 업데이트는 한 번에 하나씩 한다.
+
+쿠버네티스 컨트롤 플레인은 이전 버전을 업데이트 하기 전에, 업데이트된 파드가 실행 및 준비될 때까지 기다린다.
+`.spec.minReadySeconds`([최소 준비 시간 초](#minimum-ready-seconds) 참조)를 설정한 경우, 컨트롤 플레인은 파드가 준비 상태로 전환된 후 해당 시간을 추가로 기다린 후 이동한다.
+
+### 파티션 롤링 업데이트 {#partitions}
`롤링 업데이트` 의 업데이트 전략은 `.spec.updateStrategy.rollingUpdate.partition`
를 명시해서 파티션 할 수 있다. 만약 파티션을 명시하면 스테이트풀셋의 `.spec.template` 가
@@ -255,7 +259,7 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
대부분의 케이스는 파티션을 사용할 필요가 없지만 업데이트를 준비하거나,
카나리의 롤 아웃 또는 단계적인 롤 아웃을 행하려는 경우에는 유용하다.
-#### 강제 롤백
+### 강제 롤백
기본 [파드 관리 정책](#파드-관리-정책) (`OrderedReady`)과
함께 [롤링 업데이트](#롤링-업데이트)를 사용할 경우
@@ -273,8 +277,19 @@ web-0이 실패할 경우 web-1은 web-0이 Running 및 Ready 상태가
템플릿을 되돌린 이후에는 스테이트풀셋이 이미 잘못된 구성으로
실행하려고 시도한 모든 파드를 삭제해야 한다.
-그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작 한다.
+그러면 스테이트풀셋은 되돌린 템플릿을 사용해서 파드를 다시 생성하기 시작한다.
+### 최소 준비 시간 초 {#minimum-ready-seconds}
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+`.spec.minReadySeconds`는 새로 생성된 파드가 사용가능하다고 간주되도록
+컨테이너가 충돌되지 않고 준비되는 최소 시간 초를 지정하는 선택적 필드이다.
+기본값은 0이다(파드는 준비되는 대로 사용 가능한 것으로 간주된다).
+파드가 준비가 되는 시기에 대해 더 자세히 알아보고 싶다면,
+[컨테이너 프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)를 참고한다.
+
+이 필드는 `StatefulSetMinReadySeconds` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를 사용하도록 설정한 경우에만 작동한다.
## {{% heading "whatsnext" %}}
diff --git a/content/ko/docs/concepts/workloads/pods/_index.md b/content/ko/docs/concepts/workloads/pods/_index.md
index 22b98b705c..54fdf4a9a2 100644
--- a/content/ko/docs/concepts/workloads/pods/_index.md
+++ b/content/ko/docs/concepts/workloads/pods/_index.md
@@ -257,8 +257,12 @@ POSIX 공유 메모리와 같은 표준 프로세스 간 통신을 사용하여
## 컨테이너에 대한 특권 모드
-파드의 모든 컨테이너는 컨테이너 명세의 [보안 콘텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
-특권이 있는 컨테이너 내의 프로세스는 컨테이너 외부의 프로세스가 가지는 거의 동일한 권한을 가진다.
+리눅스에서, 파드의 모든 컨테이너는 컨테이너 명세의 [보안 컨텍스트](/docs/tasks/configure-pod-container/security-context/)에 있는 `privileged` (리눅스) 플래그를 사용하여 특권 모드를 활성화할 수 있다. 이는 네트워크 스택 조작이나 하드웨어 장치 접근과 같은 운영 체제 관리 기능을 사용하려는 컨테이너에 유용하다.
+클러스터가 `WindowsHostProcessContainers` 기능을 활성화하였다면, 파드 스펙의 보안 컨텍스트의 `windowsOptions.hostProcess` 에 의해 [윈도우 HostProcess 파드](/docs/tasks/configure-pod-container/create-hostprocess-pod)를 생성할 수 있다. 이러한 모든 컨테이너는 윈도우 HostProcess 컨테이너로 실행해야 한다. HostProcess 파드는 직접적으로 호스트에서 실행하는 것으로, 리눅스 특권있는 컨테이너에서 수행되는 관리 태스크 수행에도 사용할 수 있다.
+
+파드의 모든 컨테이너는 윈도우 HostProcess 컨테이너로 반드시 실행해야 한다.
+
+HostProcess 파드는 호스트에서 직접 실행되며 리눅스 특권있는 컨테이너에서 수행되는 것과 같은 관리 작업을 수행하는데도 사용할 수 있다.
{{< note >}}
이 설정을 사용하려면 사용자의 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}이 특권이 있는 컨테이너의 개념을 지원해야 한다.
@@ -282,6 +286,17 @@ kubelet은 자동으로 각 정적 파드에 대한 쿠버네티스 API 서버
즉, 노드에서 실행되는 파드는 API 서버에서 보이지만,
여기에서 제어할 수는 없다는 의미이다.
+## 컨테이너 프로브
+
+_프로브_는 컨테이너의 kubelet에 의해 주기적으로 실행되는 진단이다. 진단을 수행하기 위하여 kubelet은 다음과 같은 작업을 호출할 수 있다.
+
+- `ExecAction` (컨테이너 런타임의 도움을 받아 수행)
+- `TCPSocketAction` (kubelet에 의해 직접 검사)
+- `HTTPGetAction` (kubelet에 의해 직접 검사)
+
+[프로브](/ko/docs/concepts/workloads/pods/pod-lifecycle/#컨테이너-프로브-probe)에 대한 자세한 내용은
+파드 라이프사이클 문서를 참고한다.
+
## {{% heading "whatsnext" %}}
* [파드의 라이프사이클](/ko/docs/concepts/workloads/pods/pod-lifecycle/)에 대해 알아본다.
diff --git a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
index 9aa9e9bf51..136413b88f 100644
--- a/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
+++ b/content/ko/docs/concepts/workloads/pods/ephemeral-containers.md
@@ -6,15 +6,15 @@ weight: 80
-{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
+{{< feature-state state="alpha" for_k8s_version="v1.22" >}}
-이 페이지는 임시 컨테이너에 대한 개요를 제공한다: 이 특별한 유형의 컨테이너는
-트러블 슈팅과 같은 사용자가 시작한 작업을 완료하기위해 기존 {{< glossary_tooltip text="파드" term_id="pod" >}} 에서
-임시적으로 실행된다. 사용자는 애플리케이션 빌드보다는 서비스를 점검할 때 임시
-컨테이너를 사용한다.
+이 페이지는 임시 컨테이너에 대한 개요를 제공한다.
+이 특별한 유형의 컨테이너는 트러블슈팅과 같은 사용자가 시작한 작업을 완료하기 위해
+기존 {{< glossary_tooltip text="파드" term_id="pod" >}}에서 임시적으로 실행된다.
+임시 컨테이너는 애플리케이션을 빌드하는 경우보다는 서비스 점검과 같은 경우에 더 적합하다.
{{< warning >}}
-임시 컨테이너는 초기 알파 상태이며,
+임시 컨테이너 기능은 알파 상태이며,
프로덕션 클러스터에는 적합하지 않다.
[쿠버네티스 사용 중단(deprecation) 정책](/docs/reference/using-api/deprecation-policy/)에 따라
이 알파 기능은 향후 크게 변경되거나, 완전히 제거될 수 있다.
@@ -72,119 +72,8 @@ API에서 특별한 `ephemeralcontainers` 핸들러를 사용해서 만들어지
임시 컨테이너 사용 시 [프로세스 네임스페이스
공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
-활성화하면 다른 컨테이너 안의 프로세스를 보는데 도움이 된다.
+활성화하면 다른 컨테이너 안의 프로세스를 보는 데 도움이 된다.
-임시 컨테이너를 사용해서 문제를 해결하는 예시는
-[임시 디버깅 컨테이너로 디버깅하기]
-(/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)를 참조한다.
+## {{% heading "whatsnext" %}}
-## 임시 컨테이너 API
-
-{{< note >}}
-이 섹션의 예시는 `EphemeralContainers` [기능
-게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)의
-활성화를 필요로 하고, 쿠버네티스 클라이언트와 서버는 v1.16 또는 이후의 버전이어야 한다.
-{{< /note >}}
-
-이 섹션의 예시는 임시 컨테이너가 어떻게 API에 나타나는지
-보여준다. 일반적으로 `kubectl debug` 또는
-다른 `kubectl` [플러그인](/ko/docs/tasks/extend-kubectl/kubectl-plugins/)을
-사용해서 API를 직접 호출하지 않고 이런 단계들을 자동화 한다.
-
-임시 컨테이너는 파드의 `ephemeralcontainers` 하위 리소스를
-사용해서 생성되며, `kubectl --raw` 를 사용해서 보여준다. 먼저
-`EphemeralContainers` 목록으로 추가하는 임시 컨테이너를 명시한다.
-
-```json
-{
- "apiVersion": "v1",
- "kind": "EphemeralContainers",
- "metadata": {
- "name": "example-pod"
- },
- "ephemeralContainers": [{
- "command": [
- "sh"
- ],
- "image": "busybox",
- "imagePullPolicy": "IfNotPresent",
- "name": "debugger",
- "stdin": true,
- "tty": true,
- "terminationMessagePolicy": "File"
- }]
-}
-```
-
-이미 실행중인 `example-pod` 에 임시 컨테이너를 업데이트 한다.
-
-```shell
-kubectl replace --raw /api/v1/namespaces/default/pods/example-pod/ephemeralcontainers -f ec.json
-```
-
-그러면 새로운 임시 컨테이너 목록이 반환된다.
-
-```json
-{
- "kind":"EphemeralContainers",
- "apiVersion":"v1",
- "metadata":{
- "name":"example-pod",
- "namespace":"default",
- "selfLink":"/api/v1/namespaces/default/pods/example-pod/ephemeralcontainers",
- "uid":"a14a6d9b-62f2-4119-9d8e-e2ed6bc3a47c",
- "resourceVersion":"15886",
- "creationTimestamp":"2019-08-29T06:41:42Z"
- },
- "ephemeralContainers":[
- {
- "name":"debugger",
- "image":"busybox",
- "command":[
- "sh"
- ],
- "resources":{
-
- },
- "terminationMessagePolicy":"File",
- "imagePullPolicy":"IfNotPresent",
- "stdin":true,
- "tty":true
- }
- ]
-}
-```
-
-사용자는 `kubectl describe` 를 사용해서 새로 만든 임시 컨테이너의 상태를 볼 수 있다.
-
-```shell
-kubectl describe pod example-pod
-```
-
-```
-...
-Ephemeral Containers:
- debugger:
- Container ID: docker://cf81908f149e7e9213d3c3644eda55c72efaff67652a2685c1146f0ce151e80f
- Image: busybox
- Image ID: docker-pullable://busybox@sha256:9f1003c480699be56815db0f8146ad2e22efea85129b5b5983d0e0fb52d9ab70
- Port:
- Host Port:
- Command:
- sh
- State: Running
- Started: Thu, 29 Aug 2019 06:42:21 +0000
- Ready: False
- Restart Count: 0
- Environment:
- Mounts:
-...
-```
-
-예시와 같이 `kubectl attach`, `kubectl exec`, 그리고 `kubectl logs` 를 사용해서
-다른 컨테이너와 같은 방식으로 새로운 임시 컨테이너와
-상호작용할 수 있다.
-
-```shell
-kubectl attach -it example-pod -c debugger
-```
+* [임시 컨테이너 디버깅하기](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)에 대해 알아보기.
diff --git a/content/ko/docs/concepts/workloads/pods/init-containers.md b/content/ko/docs/concepts/workloads/pods/init-containers.md
index c8c7055408..a1c01b17ab 100644
--- a/content/ko/docs/concepts/workloads/pods/init-containers.md
+++ b/content/ko/docs/concepts/workloads/pods/init-containers.md
@@ -290,8 +290,9 @@ myapp-pod 1/1 Running 0 9m
초기화 컨테이너에게 명령과 실행이 주어진 경우, 리소스 사용에 대한
다음의 규칙이 적용된다.
-* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중 가장
- 높은 것은 *유효한 초기화 요청량/상한* 이다.
+* 모든 컨테이너에 정의된 특정 리소스 요청량 또는 상한 중
+ 가장 높은 것은 *유효 초기화 요청량/상한* 이다. 리소스 제한이 지정되지 않은 리소스는
+ 이 *유효 초기화 요청량/상한*을 가장 높은 요청량/상한으로 간주한다.
* 리소스를 위한 파드의 *유효한 초기화 요청량/상한* 은 다음 보다 더 높다.
* 모든 앱 컨테이너의 리소스에 대한 요청량/상한의 합계
* 리소스에 대한 유효한 초기화 요청량/상한
diff --git a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
index 010694409e..48a918715e 100644
--- a/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/ko/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -379,7 +379,7 @@ TERM 대신 이 값을 보낸다.
확인하는 즉시(정상적인 종료 기간이 설정됨), kubelet은 로컬 파드의 종료
프로세스를 시작한다.
1. 파드의 컨테이너 중 하나가 `preStop`
- [훅](/ko/docs/concepts/containers/container-lifecycle-hooks/#hook-details)을 정의한 경우, kubelet은
+ [훅](/ko/docs/concepts/containers/container-lifecycle-hooks)을 정의한 경우, kubelet은
컨테이너 내부에서 해당 훅을 실행한다. 유예 기간이 만료된 후 `preStop` 훅이
계속 실행되면, kubelet은 2초의 작은 일회성 유예 기간 연장을
요청한다.
diff --git a/content/ko/docs/contribute/generate-ref-docs/quickstart.md b/content/ko/docs/contribute/generate-ref-docs/quickstart.md
index 6855696b9d..531b1ad50b 100644
--- a/content/ko/docs/contribute/generate-ref-docs/quickstart.md
+++ b/content/ko/docs/contribute/generate-ref-docs/quickstart.md
@@ -6,7 +6,7 @@ weight: 40
-이 문서에서는 `update-imported-docs` 스크립트를 사용하여
+이 문서에서는 `update-imported-docs.py` 스크립트를 사용하여
쿠버네티스 레퍼런스 문서를 생성하는 방법에 대해 설명한다.
이 스크립트는 특정 쿠버네티스 릴리스 버전에 대해 빌드 설정을 자동으로 수행하고 레퍼런스 문서를 생성한다.
@@ -39,7 +39,7 @@ git clone git@github.com:/website.git
## `update-imported-docs` 스크립트 개요 {#Overview-of-update-imported-docs}
-`update-imported-docs` 스크립트는 `/update-imported-docs/`
+`update-imported-docs.py` 스크립트는 `/update-imported-docs/`
디렉터리에 존재한다.
이 스크립트는 다음 레퍼런스를 생성한다.
@@ -48,7 +48,7 @@ git clone git@github.com:/website.git
* `kubectl` 명령어 레퍼런스
* 쿠버네티스 API 레퍼런스
-`update-imported-docs` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
+`update-imported-docs.py` 스크립트는 쿠버네티스 소스코드로부터 레퍼런스 문서를
생성한다. 스크립트가 실행되면 개발 머신의 `/tmp` 디렉터리 아래에 임시 디렉터리를
생성하고, 이 임시 디렉터리 아래에 레퍼런스 문서 생성에 필요한 `kubernetes/kubernetes` 저장소와
`kubernetes-sigs/reference-docs` 저장소를 클론하며,
@@ -69,7 +69,7 @@ git clone git@github.com:/website.git
`kubernetes-sigs/reference-docs/Makefile` 에 있는 Make 타겟들을 활용하여 빌드하는 일련의 과정이 명시되어 있다.
`K8S_RELEASE` 환경 변수는 릴리스 버전을 결정한다.
-`update-imported-docs` 스크립트는 다음의 과정을 수행한다.
+`update-imported-docs.py` 스크립트는 다음의 과정을 수행한다.
1. 환경설정 파일에 있는 관련 저장소를 클론한다.
레퍼런스 문서 생성을 위해
@@ -152,11 +152,11 @@ repos:
## `update-imported-docs` 도구 실행하기 {#Running-the-update-imported-docs-tool}
-다음과 같이 `update-imported-docs` 도구를 실행할 수 있다.
+다음과 같이 `update-imported-docs.py` 도구를 실행할 수 있다.
```shell
cd /update-imported-docs
-./update-imported-docs
+./update-imported-docs.py
```
예를 들면 다음과 같다.
@@ -254,4 +254,3 @@ static/docs/reference/generated/kubernetes-api/{{< param "version" >}}/fonts/fon
* [kubectl 명령어에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubectl/)
* [쿠버네티스 API에 대한 레퍼런스 문서 생성하기](/docs/contribute/generate-ref-docs/kubernetes-api/)
-
diff --git a/content/ko/docs/reference/_index.md b/content/ko/docs/reference/_index.md
index 55401988b4..8bfa706ea4 100644
--- a/content/ko/docs/reference/_index.md
+++ b/content/ko/docs/reference/_index.md
@@ -71,8 +71,10 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
사용/관리하는 데에 중요하지만, 이들 API의 대부분은 아직 API 서버가
제공하지 않는다.
+* [kube-apiserver 환경설정 (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/)
* [kubelet 환경설정 (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/)
* [kube-scheduler 환경설정 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+* [kube-scheduler 환경설정 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/)
* [kube-scheduler 정책 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/)
* [kube-proxy 환경설정 (v1alpha1)](/docs/reference/config-api/kube-proxy-config.v1alpha1/)
* [`audit.k8s.io/v1` API](/docs/reference/config-api/apiserver-audit.v1/)
@@ -82,6 +84,7 @@ TCP/UDP 스트림 포워딩이나 백-엔드 집합에 걸쳐서 라운드-로
## kubeadm을 위한 API 설정
* [v1beta2](/docs/reference/config-api/kubeadm-config.v1beta2/)
+* [v1beta3](/docs/reference/config-api/kubeadm-config.v1beta3/)
## 설계 문서
diff --git a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
index ca06783465..55615e55de 100644
--- a/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
+++ b/content/ko/docs/reference/access-authn-authz/service-accounts-admin.md
@@ -57,10 +57,9 @@ weight: 50
#### 바인딩된 서비스 어카운트 토큰 볼륨
-{{< feature-state for_k8s_version="v1.21" state="beta" >}}
+{{< feature-state for_k8s_version="v1.22" state="stable" >}}
-`BoundServiceAccountTokenVolume` [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)가 활성화되면,
-토큰 컨트롤러에 의해 생성된 무기한 서비스 어카운트 토큰을 위해, 서비스 어카운트 어드미션 컨트롤러가 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
+서비스 어카운트 어드미션 컨트롤러는 토큰 컨트롤러에서 생성한 만료되지 않은 서비스 계정 토큰에 시크릿 기반 볼륨 대신 다음과 같은 프로젝티드 볼륨을 추가한다.
```yaml
- name: kube-api-access-
@@ -91,10 +90,6 @@ weight: 50
상세 사항은 [프로젝티드 볼륨](/docs/tasks/configure-pod-container/configure-projected-volume-storage/)을 참고한다.
-`BoundServiceAccountTokenVolume` 기능 게이트가 활성화되어 있지 않은 경우,
-위의 프로젝티드 볼륨을 파드 스펙에 추가하여
-시크릿 기반 서비스 어카운트 볼륨을 프로젝티드 볼륨으로 수동으로 옮길 수 있다.
-
### 토큰 컨트롤러
토큰컨트롤러는 `kube-controller-manager` 의 일부로 실행된다. 이것은 비동기적으로 동작한다. 토큰 컨트롤러는,
diff --git a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
index 97262073a1..7b1bdb7c42 100644
--- a/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
+++ b/content/ko/docs/reference/command-line-tools-reference/feature-gates.md
@@ -2,6 +2,9 @@
weight: 10
title: 기능 게이트
content_type: concept
+card:
+ name: reference
+ weight: 60
---
@@ -25,7 +28,7 @@ content_type: concept
kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능 쌍 목록에 지정된 `--feature-gates` 플래그를 사용한다.
```shell
---feature-gates="...,DynamicKubeletConfig=true"
+--feature-gates="...,GracefulNodeShutdown=true"
```
다음 표는 다른 쿠버네티스 컴포넌트에서 설정할 수 있는 기능 게이트를
@@ -55,65 +58,60 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `APIResponseCompression` | `false` | 알파 | 1.7 | 1.15 |
| `APIResponseCompression` | `true` | 베타 | 1.16 | |
| `APIServerIdentity` | `false` | 알파 | 1.20 | |
+| `APIServerTracing` | `false` | 알파 | 1.22 | |
| `AllowInsecureBackendProxy` | `true` | 베타 | 1.17 | |
| `AnyVolumeDataSource` | `false` | 알파 | 1.18 | |
| `AppArmor` | `true` | 베타 | 1.4 | |
-| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | |
-| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
-| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | |
| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | |
| `CPUManager` | `false` | 알파 | 1.8 | 1.9 |
| `CPUManager` | `true` | 베타 | 1.10 | |
+| `CPUManagerPolicyOptions` | `false` | 알파 | 1.22 | |
| `CSIInlineVolume` | `false` | 알파 | 1.15 | 1.15 |
| `CSIInlineVolume` | `true` | 베타 | 1.16 | - |
| `CSIMigration` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigration` | `true` | 베타 | 1.17 | |
| `CSIMigrationAWS` | `false` | 알파 | 1.14 | |
| `CSIMigrationAWS` | `false` | 베타 | 1.17 | |
-| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationAzureDisk` | `false` | 알파 | 1.15 | 1.18 |
| `CSIMigrationAzureDisk` | `false` | 베타 | 1.19 | |
-| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationAzureFile` | `false` | 알파 | 1.15 | 1.19 |
| `CSIMigrationAzureFile` | `false` | 베타 | 1.21 | |
-| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationGCE` | `false` | 알파 | 1.14 | 1.16 |
| `CSIMigrationGCE` | `false` | 베타 | 1.17 | |
-| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationOpenStack` | `false` | 알파 | 1.14 | 1.17 |
| `CSIMigrationOpenStack` | `true` | 베타 | 1.18 | |
-| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | |
| `CSIMigrationvSphere` | `false` | 베타 | 1.19 | |
-| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | |
-| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 |
-| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | |
| `CSIStorageCapacity` | `false` | 알파 | 1.19 | 1.20 |
| `CSIStorageCapacity` | `true` | 베타 | 1.21 | |
| `CSIVolumeFSGroupPolicy` | `false` | 알파 | 1.19 | 1.19 |
| `CSIVolumeFSGroupPolicy` | `true` | 베타 | 1.20 | |
| `CSIVolumeHealth` | `false` | 알파 | 1.21 | |
+| `CSRDuration` | `true` | 베타 | 1.22 | |
| `ConfigurableFSGroupPolicy` | `false` | 알파 | 1.18 | 1.19 |
| `ConfigurableFSGroupPolicy` | `true` | 베타 | 1.20 | |
-| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
-| `CronJobControllerV2` | `true` | 베타 | 1.21 | |
+| `ControllerManagerLeaderMigration` | `false` | 알파 | 1.21 | 1.21 |
+| `ControllerManagerLeaderMigration` | `true` | 베타 | 1.22 | |
| `CustomCPUCFSQuotaPeriod` | `false` | 알파 | 1.12 | |
+| `DaemonSetUpdateSurge` | `false` | 알파 | 1.21 | 1.21 |
+| `DaemonSetUpdateSurge` | `true` | 베타 | 1.22 | |
| `DefaultPodTopologySpread` | `false` | 알파 | 1.19 | 1.19 |
| `DefaultPodTopologySpread` | `true` | 베타 | 1.20 | |
+| `DelegateFSGroupToCSIDriver` | `false` | 알파 | 1.22 | |
| `DevicePlugins` | `false` | 알파 | 1.8 | 1.9 |
| `DevicePlugins` | `true` | 베타 | 1.10 | |
| `DisableAcceleratorUsageMetrics` | `false` | 알파 | 1.19 | 1.19 |
| `DisableAcceleratorUsageMetrics` | `true` | 베타 | 1.20 | |
+| `DisableCloudProviders` | `false` | 알파 | 1.22 | |
| `DownwardAPIHugePages` | `false` | 알파 | 1.20 | 1.20 |
| `DownwardAPIHugePages` | `false` | 베타 | 1.21 | |
-| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
-| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | |
-| `EfficientWatchResumption` | `false` | 알파 | 1.20 | |
-| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
-| `EndpointSliceProxying` | `true` | 베타 | 1.19 | |
-| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | |
+| `EfficientWatchResumption` | `false` | 알파 | 1.20 | 1.20 |
+| `EfficientWatchResumption` | `true` | 베타 | 1.21 | |
+| `EndpointSliceTerminatingCondition` | `false` | 알파 | 1.20 | 1.21 |
+| `EndpointSliceTerminatingCondition` | `true` | 베타 | 1.22 | |
| `EphemeralContainers` | `false` | 알파 | 1.16 | |
| `ExpandCSIVolumes` | `false` | 알파 | 1.14 | 1.15 |
| `ExpandCSIVolumes` | `true` | 베타 | 1.16 | |
+| `ExpandedDNSConfig` | `false` | 알파 | 1.22 | |
| `ExpandInUsePersistentVolumes` | `false` | 알파 | 1.11 | 1.14 |
| `ExpandInUsePersistentVolumes` | `true` | 베타 | 1.15 | |
| `ExpandPersistentVolumes` | `false` | 알파 | 1.8 | 1.10 |
@@ -125,70 +123,83 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `GracefulNodeShutdown` | `true` | 베타 | 1.21 | |
| `HPAContainerMetrics` | `false` | 알파 | 1.20 | |
| `HPAScaleToZero` | `false` | 알파 | 1.16 | |
-| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
-| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | |
-| `IndexedJob` | `false` | 알파 | 1.21 | |
-| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | |
+| `IndexedJob` | `false` | 알파 | 1.21 | 1.21 |
+| `IndexedJob` | `true` | 베타 | 1.22 | |
+| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
+| `IngressClassNamespacedParams` | `false` | 알파 | 1.21 | 1.21 |
+| `IngressClassNamespacedParams` | `true` | 베타 | 1.22 | |
+| `InTreePluginAWSUnregister` | `false` | 알파 | 1.21 | |
+| `InTreePluginAzureDiskUnregister` | `false` | 알파 | 1.21 | |
+| `InTreePluginAzureFileUnregister` | `false` | 알파 | 1.21 | |
+| `InTreePluginGCEUnregister` | `false` | 알파 | 1.21 | |
+| `InTreePluginOpenStackUnregister` | `false` | 알파 | 1.21 | |
+| `InTreePluginvSphereUnregister` | `false` | 알파 | 1.21 | |
| `IPv6DualStack` | `false` | 알파 | 1.15 | 1.20 |
| `IPv6DualStack` | `true` | 베타 | 1.21 | |
+| `JobTrackingWithFinalizers` | `false` | 알파 | 1.22 | |
| `KubeletCredentialProviders` | `false` | 알파 | 1.20 | |
-| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
-| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
| `LocalStorageCapacityIsolation` | `false` | 알파 | 1.7 | 1.9 |
| `LocalStorageCapacityIsolation` | `true` | 베타 | 1.10 | |
| `LocalStorageCapacityIsolationFSQuotaMonitoring` | `false` | 알파 | 1.15 | |
-| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | |
+| `LogarithmicScaleDown` | `false` | 알파 | 1.21 | 1.21 |
+| `LogarithmicScaleDown` | `true` | 베타 | 1.22 | |
+| `KubeletInUserNamespace` | `false` | 알파 | 1.22 | |
| `KubeletPodResourcesGetAllocatable` | `false` | 알파 | 1.21 | |
+| `MemoryManager` | `false` | 알파 | 1.21 | 1.21 |
+| `MemoryManager` | `true` | 베타 | 1.22 | |
+| `MemoryQoS` | `false` | 알파 | 1.22 | |
| `MixedProtocolLBService` | `false` | 알파 | 1.20 | |
-| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | |
-| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | |
-| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
-| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 |
+| `NetworkPolicyEndPort` | `false` | 알파 | 1.21 | 1.21 |
+| `NetworkPolicyEndPort` | `true` | 베타 | 1.22 | |
+| `NodeSwap` | `false` | 알파 | 1.22 | |
| `NonPreemptingPriority` | `false` | 알파 | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | 베타 | 1.19 | |
-| `PodDeletionCost` | `false` | 알파 | 1.21 | |
-| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | |
+| `PodDeletionCost` | `false` | 알파 | 1.21 | 1.21 |
+| `PodDeletionCost` | `true` | 베타 | 1.22 | |
+| `PodAffinityNamespaceSelector` | `false` | 알파 | 1.21 | 1.21 |
+| `PodAffinityNamespaceSelector` | `true` | 베타 | 1.22 | |
| `PodOverhead` | `false` | 알파 | 1.16 | 1.17 |
-| `PodOverhead` | `true` | 베타 | 1.18 | |
-| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | |
+| `PodOverhead` | `true` | 베타 | 1.18 | |
+| `PodSecurity` | `false` | 알파 | 1.22 | |
+| `PreferNominatedNode` | `false` | 알파 | 1.21 | 1.21 |
+| `PreferNominatedNode` | `true` | 베타 | 1.22 | |
+| `ProbeTerminationGracePeriod` | `false` | 알파 | 1.21 | 1.21 |
+| `ProbeTerminationGracePeriod` | `false` | 베타 | 1.22 | |
+| `ProxyTerminatingEndpoints` | `false` | 알파 | 1.22 | |
| `ProcMountType` | `false` | 알파 | 1.12 | |
| `QOSReserved` | `false` | 알파 | 1.11 | |
+| `ReadWriteOncePod` | `false` | 알파 | 1.22 | |
| `RemainingItemCount` | `false` | 알파 | 1.15 | 1.15 |
| `RemainingItemCount` | `true` | 베타 | 1.16 | |
| `RemoveSelfLink` | `false` | 알파 | 1.16 | 1.19 |
| `RemoveSelfLink` | `true` | 베타 | 1.20 | |
| `RotateKubeletServerCertificate` | `false` | 알파 | 1.7 | 1.11 |
| `RotateKubeletServerCertificate` | `true` | 베타 | 1.12 | |
-| `RunAsGroup` | `true` | 베타 | 1.14 | |
-| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
-| `ServerSideApply` | `true` | 베타 | 1.16 | |
-| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | |
-| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | |
-| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | |
-| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
-| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 |
-| `ServiceTopology` | `false` | 알파 | 1.17 | |
-| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
-| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | |
-| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | |
+| `SeccompDefault` | `false` | 알파 | 1.22 | |
+| `ServiceInternalTrafficPolicy` | `false` | 알파 | 1.21 | 1.21 |
+| `ServiceInternalTrafficPolicy` | `true` | 베타 | 1.22 | |
+| `ServiceLBNodePortControl` | `false` | 알파 | 1.20 | 1.21 |
+| `ServiceLBNodePortControl` | `true` | 베타 | 1.22 | |
+| `ServiceLoadBalancerClass` | `false` | 알파 | 1.21 | 1.21 |
+| `ServiceLoadBalancerClass` | `true` | 베타 | 1.22 | |
+| `SizeMemoryBackedVolumes` | `false` | 알파 | 1.20 | 1.21 |
+| `SizeMemoryBackedVolumes` | `true` | 베타 | 1.22 | |
+| `StatefulSetMinReadySeconds` | `false` | 알파 | 1.22 | |
| `StorageVersionAPI` | `false` | 알파 | 1.20 | |
| `StorageVersionHash` | `false` | 알파 | 1.14 | 1.14 |
| `StorageVersionHash` | `true` | 베타 | 1.15 | |
-| `SuspendJob` | `false` | 알파 | 1.21 | |
+| `SuspendJob` | `false` | 알파 | 1.21 | 1.21 |
+| `SuspendJob` | `true` | 베타 | 1.22 | |
| `TTLAfterFinished` | `false` | 알파 | 1.12 | 1.20 |
| `TTLAfterFinished` | `true` | 베타 | 1.21 | |
| `TopologyAwareHints` | `false` | 알파 | 1.21 | |
| `TopologyManager` | `false` | 알파 | 1.16 | 1.17 |
| `TopologyManager` | `true` | 베타 | 1.18 | |
-| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
-| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | |
| `VolumeCapacityPriority` | `false` | 알파 | 1.21 | - |
-| `WarningHeaders` | `true` | 베타 | 1.19 | |
| `WinDSR` | `false` | 알파 | 1.14 | |
| `WinOverlay` | `false` | 알파 | 1.14 | 1.19 |
| `WinOverlay` | `true` | 베타 | 1.20 | |
-| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 |
-| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | |
+| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 | |
{{< /table >}}
### GA 또는 사용 중단된 기능을 위한 기능 게이트
@@ -206,9 +217,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `AffinityInAnnotations` | - | 사용중단 | 1.8 | - |
| `AllowExtTrafficLocalEndpoints` | `false` | 베타 | 1.4 | 1.6 |
| `AllowExtTrafficLocalEndpoints` | `true` | GA | 1.7 | - |
+| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 |
+| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 |
+| `AttachVolumeLimit` | `true` | GA | 1.17 | - |
+| `BalanceAttachedNodeVolumes` | `false` | 알파 | 1.11 | 1.21 |
+| `BalanceAttachedNodeVolumes` | `false` | 사용중단 | 1.22 | |
| `BlockVolume` | `false` | 알파 | 1.9 | 1.12 |
| `BlockVolume` | `true` | 베타 | 1.13 | 1.17 |
| `BlockVolume` | `true` | GA | 1.18 | - |
+| `BoundServiceAccountTokenVolume` | `false` | 알파 | 1.13 | 1.20 |
+| `BoundServiceAccountTokenVolume` | `true` | 베타 | 1.21 | 1.21 |
+| `BoundServiceAccountTokenVolume` | `true` | GA | 1.22 | - |
| `CRIContainerLogRotation` | `false` | 알파 | 1.10 | 1.10 |
| `CRIContainerLogRotation` | `true` | 베타 | 1.11 | 1.20 |
| `CRIContainerLogRotation` | `true` | GA | 1.21 | - |
@@ -218,15 +237,30 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `CSIDriverRegistry` | `false` | 알파 | 1.12 | 1.13 |
| `CSIDriverRegistry` | `true` | 베타 | 1.14 | 1.17 |
| `CSIDriverRegistry` | `true` | GA | 1.18 | |
+| `CSIMigrationAWSComplete` | `false` | 알파 | 1.17 | 1.20 |
+| `CSIMigrationAWSComplete` | - | 사용중단 | 1.21 | - |
+| `CSIMigrationAzureDiskComplete` | `false` | 알파 | 1.17 | 1.20 |
+| `CSIMigrationAzureDiskComplete` | - | 사용중단 | 1.21 | - |
+| `CSIMigrationAzureFileComplete` | `false` | 알파 | 1.17 | 1.20 |
+| `CSIMigrationAzureFileComplete` | - | 사용중단 | 1.21 | - |
+| `CSIMigrationGCEComplete` | `false` | 알파 | 1.17 | 1.20 |
+| `CSIMigrationGCEComplete` | - | 사용중단 | 1.21 | - |
+| `CSIMigrationOpenStackComplete` | `false` | 알파 | 1.17 | 1.20 |
+| `CSIMigrationOpenStackComplete` | - | 사용중단 | 1.21 | - |
+| `CSIMigrationvSphereComplete` | `false` | 베타 | 1.19 | 1.21 |
+| `CSIMigrationvSphereComplete` | - | 사용중단 | 1.22 | - |
| `CSINodeInfo` | `false` | 알파 | 1.12 | 1.13 |
| `CSINodeInfo` | `true` | 베타 | 1.14 | 1.16 |
| `CSINodeInfo` | `true` | GA | 1.17 | |
-| `AttachVolumeLimit` | `false` | 알파 | 1.11 | 1.11 |
-| `AttachVolumeLimit` | `true` | 베타 | 1.12 | 1.16 |
-| `AttachVolumeLimit` | `true` | GA | 1.17 | - |
| `CSIPersistentVolume` | `false` | 알파 | 1.9 | 1.9 |
| `CSIPersistentVolume` | `true` | 베타 | 1.10 | 1.12 |
| `CSIPersistentVolume` | `true` | GA | 1.13 | - |
+| `CSIServiceAccountToken` | `false` | 알파 | 1.20 | 1.20 |
+| `CSIServiceAccountToken` | `true` | 베타 | 1.21 | 1.21 |
+| `CSIServiceAccountToken` | `true` | GA | 1.22 | |
+| `CronJobControllerV2` | `false` | 알파 | 1.20 | 1.20 |
+| `CronJobControllerV2` | `true` | 베타 | 1.21 | 1.21 |
+| `CronJobControllerV2` | `true` | GA | 1.22 | - |
| `CustomPodDNS` | `false` | 알파 | 1.9 | 1.9 |
| `CustomPodDNS` | `true` | 베타| 1.10 | 1.13 |
| `CustomPodDNS` | `true` | GA | 1.14 | - |
@@ -250,8 +284,14 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `DryRun` | `true` | GA | 1.19 | - |
| `DynamicAuditing` | `false` | 알파 | 1.13 | 1.18 |
| `DynamicAuditing` | - | 사용중단 | 1.19 | - |
+| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
+| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 |
+| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
| `DynamicProvisioningScheduling` | `false` | 알파 | 1.11 | 1.11 |
| `DynamicProvisioningScheduling` | - | 사용중단| 1.12 | - |
+| `DynamicKubeletConfig` | `false` | 알파 | 1.4 | 1.10 |
+| `DynamicKubeletConfig` | `true` | 베타 | 1.11 | 1.21 |
+| `DynamicKubeletConfig` | `false` | 사용중단 | 1.22 | - |
| `DynamicVolumeProvisioning` | `true` | 알파 | 1.3 | 1.7 |
| `DynamicVolumeProvisioning` | `true` | GA | 1.8 | - |
| `EnableAggregatedDiscoveryTimeout` | `true` | 사용중단 | 1.16 | - |
@@ -263,6 +303,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `EndpointSlice` | `true` | GA | 1.21 | - |
| `EndpointSliceNodeName` | `false` | 알파 | 1.20 | 1.20 |
| `EndpointSliceNodeName` | `true` | GA | 1.21 | - |
+| `EndpointSliceProxying` | `false` | 알파 | 1.18 | 1.18 |
+| `EndpointSliceProxying` | `true` | 베타 | 1.19 | 1.21 |
+| `EndpointSliceProxying` | `true` | GA | 1.22 | - |
| `ExperimentalCriticalPodAnnotation` | `false` | 알파 | 1.5 | 1.12 |
| `ExperimentalCriticalPodAnnotation` | `false` | 사용중단 | 1.13 | - |
| `EvenPodsSpread` | `false` | 알파 | 1.16 | 1.17 |
@@ -272,9 +315,15 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ExternalPolicyForExternalIP` | `true` | GA | 1.18 | - |
| `GCERegionalPersistentDisk` | `true` | 베타 | 1.10 | 1.12 |
| `GCERegionalPersistentDisk` | `true` | GA | 1.13 | - |
+| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
+| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 |
+| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
| `HugePages` | `false` | 알파 | 1.8 | 1.9 |
| `HugePages` | `true` | 베타| 1.10 | 1.13 |
| `HugePages` | `true` | GA | 1.14 | - |
+| `HugePageStorageMediumSize` | `false` | 알파 | 1.18 | 1.18 |
+| `HugePageStorageMediumSize` | `true` | 베타 | 1.19 | 1.21 |
+| `HugePageStorageMediumSize` | `true` | GA | 1.22 | - |
| `HyperVContainer` | `false` | 알파 | 1.10 | 1.19 |
| `HyperVContainer` | `false` | 사용중단 | 1.20 | - |
| `ImmutableEphemeralVolumes` | `false` | 알파 | 1.18 | 1.18 |
@@ -290,16 +339,22 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `KubeletPodResources` | `false` | 알파 | 1.13 | 1.14 |
| `KubeletPodResources` | `true` | 베타 | 1.15 | |
| `KubeletPodResources` | `true` | GA | 1.20 | |
+| `LegacyNodeRoleBehavior` | `false` | 알파 | 1.16 | 1.18 |
+| `LegacyNodeRoleBehavior` | `true` | 베타 | 1.19 | 1.20 |
| `LegacyNodeRoleBehavior` | `false` | GA | 1.21 | - |
| `MountContainers` | `false` | 알파 | 1.9 | 1.16 |
| `MountContainers` | `false` | 사용중단 | 1.17 | - |
| `MountPropagation` | `false` | 알파 | 1.8 | 1.9 |
| `MountPropagation` | `true` | 베타 | 1.10 | 1.11 |
| `MountPropagation` | `true` | GA | 1.12 | - |
+| `NodeDisruptionExclusion` | `false` | 알파 | 1.16 | 1.18 |
+| `NodeDisruptionExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `NodeDisruptionExclusion` | `true` | GA | 1.21 | - |
| `NodeLease` | `false` | 알파 | 1.12 | 1.13 |
| `NodeLease` | `true` | 베타 | 1.14 | 1.16 |
| `NodeLease` | `true` | GA | 1.17 | - |
+| `NamespaceDefaultLabelName` | `true` | 베타 | 1.21 | 1.21 |
+| `NamespaceDefaultLabelName` | `true` | GA | 1.22 | - |
| `PVCProtection` | `false` | 알파 | 1.9 | 1.9 |
| `PVCProtection` | - | 사용중단 | 1.10 | - |
| `PersistentLocalVolumes` | `false` | 알파 | 1.7 | 1.9 |
@@ -329,15 +384,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `RootCAConfigMap` | `true` | GA | 1.21 | - |
| `RotateKubeletClientCertificate` | `true` | 베타 | 1.8 | 1.18 |
| `RotateKubeletClientCertificate` | `true` | GA | 1.19 | - |
+| `RunAsGroup` | `true` | 베타 | 1.14 | 1.20 |
+| `RunAsGroup` | `true` | GA | 1.21 | - |
| `RuntimeClass` | `false` | 알파 | 1.12 | 1.13 |
| `RuntimeClass` | `true` | 베타 | 1.14 | 1.19 |
| `RuntimeClass` | `true` | GA | 1.20 | - |
-| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 |
-| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 |
-| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
| `SCTPSupport` | `false` | 알파 | 1.12 | 1.18 |
| `SCTPSupport` | `true` | 베타 | 1.19 | 1.19 |
| `SCTPSupport` | `true` | GA | 1.20 | - |
+| `ScheduleDaemonSetPods` | `false` | 알파 | 1.11 | 1.11 |
+| `ScheduleDaemonSetPods` | `true` | 베타 | 1.12 | 1.16 |
+| `ScheduleDaemonSetPods` | `true` | GA | 1.17 | - |
+| `SelectorIndex` | `false` | 알파 | 1.18 | 1.18 |
+| `SelectorIndex` | `true` | 베타 | 1.19 | 1.19 |
+| `SelectorIndex` | `true` | GA | 1.20 | - |
+| `ServerSideApply` | `false` | 알파 | 1.14 | 1.15 |
+| `ServerSideApply` | `true` | 베타 | 1.16 | 1.21 |
+| `ServerSideApply` | `true` | GA | 1.22 | - |
| `ServiceAccountIssuerDiscovery` | `false` | 알파 | 1.18 | 1.19 |
| `ServiceAccountIssuerDiscovery` | `true` | 베타 | 1.20 | 1.20 |
| `ServiceAccountIssuerDiscovery` | `true` | GA | 1.21 | - |
@@ -347,15 +410,23 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `ServiceLoadBalancerFinalizer` | `false` | 알파 | 1.15 | 1.15 |
| `ServiceLoadBalancerFinalizer` | `true` | 베타 | 1.16 | 1.16 |
| `ServiceLoadBalancerFinalizer` | `true` | GA | 1.17 | - |
+| `ServiceNodeExclusion` | `false` | 알파 | 1.8 | 1.18 |
+| `ServiceNodeExclusion` | `true` | 베타 | 1.19 | 1.20 |
| `ServiceNodeExclusion` | `true` | GA | 1.21 | - |
+| `ServiceTopology` | `false` | 알파 | 1.17 | 1.19 |
+| `ServiceTopology` | `false` | 사용중단 | 1.20 | - |
+| `SetHostnameAsFQDN` | `false` | 알파 | 1.19 | 1.19 |
+| `SetHostnameAsFQDN` | `true` | 베타 | 1.20 | 1.21 |
+| `SetHostnameAsFQDN` | `true` | GA | 1.22 | - |
| `StartupProbe` | `false` | 알파 | 1.16 | 1.17 |
| `StartupProbe` | `true` | 베타 | 1.18 | 1.19 |
| `StartupProbe` | `true` | GA | 1.20 | - |
| `StorageObjectInUseProtection` | `true` | 베타 | 1.10 | 1.10 |
| `StorageObjectInUseProtection` | `true` | GA | 1.11 | - |
| `StreamingProxyRedirects` | `false` | 베타 | 1.5 | 1.5 |
-| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.18 |
-| `StreamingProxyRedirects` | - | GA | 1.19 | - |
+| `StreamingProxyRedirects` | `true` | 베타 | 1.6 | 1.17 |
+| `StreamingProxyRedirects` | `true` | 사용중단 | 1.18 | 1.21 |
+| `StreamingProxyRedirects` | `false` | 사용중단 | 1.22 | - |
| `SupportIPVSProxyMode` | `false` | 알파 | 1.8 | 1.8 |
| `SupportIPVSProxyMode` | `false` | 베타 | 1.9 | 1.9 |
| `SupportIPVSProxyMode` | `true` | 베타 | 1.10 | 1.10 |
@@ -380,6 +451,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `TokenRequestProjection` | `false` | 알파 | 1.11 | 1.11 |
| `TokenRequestProjection` | `true` | 베타 | 1.12 | 1.19 |
| `TokenRequestProjection` | `true` | GA | 1.20 | - |
+| `ValidateProxyRedirects` | `false` | 알파 | 1.12 | 1.13 |
+| `ValidateProxyRedirects` | `true` | 베타 | 1.14 | 1.21 |
+| `ValidateProxyRedirects` | `true` | 사용중단 | 1.22 | - |
| `VolumePVCDataSource` | `false` | 알파 | 1.15 | 1.15 |
| `VolumePVCDataSource` | `true` | 베타 | 1.16 | 1.17 |
| `VolumePVCDataSource` | `true` | GA | 1.18 | - |
@@ -393,12 +467,18 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
| `VolumeSubpathEnvExpansion` | `false` | 알파 | 1.14 | 1.14 |
| `VolumeSubpathEnvExpansion` | `true` | 베타 | 1.15 | 1.16 |
| `VolumeSubpathEnvExpansion` | `true` | GA | 1.17 | - |
+| `WarningHeaders` | `true` | 베타 | 1.19 | 1.21 |
+| `WarningHeaders` | `true` | GA | 1.22 | - |
| `WatchBookmark` | `false` | 알파 | 1.15 | 1.15 |
| `WatchBookmark` | `true` | 베타 | 1.16 | 1.16 |
| `WatchBookmark` | `true` | GA | 1.17 | - |
+| `WindowsEndpointSliceProxying` | `false` | 알파 | 1.19 | 1.20 |
+| `WindowsEndpointSliceProxying` | `true` | 베타 | 1.21 | 1.21 |
+| `WindowsEndpointSliceProxying` | `true` | GA | 1.22| - |
| `WindowsGMSA` | `false` | 알파 | 1.14 | 1.15 |
| `WindowsGMSA` | `true` | 베타 | 1.16 | 1.17 |
| `WindowsGMSA` | `true` | GA | 1.18 | - |
+| `WindowsHostProcessContainers` | `false` | 알파 | 1.22 |
| `WindowsRunAsUserName` | `false` | 알파 | 1.16 | 1.16 |
| `WindowsRunAsUserName` | `true` | 베타 | 1.17 | 1.17 |
| `WindowsRunAsUserName` | `true` | GA | 1.18 | - |
@@ -453,6 +533,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
관리할 수 있다. (`RequestManagement` 에서 이름이 변경됨)
- `APIResponseCompression`: `LIST` 또는 `GET` 요청에 대한 API 응답을 압축한다.
- `APIServerIdentity`: 클러스터의 각 API 서버에 ID를 할당한다.
+- `APIServerTracing`: API 서버에서 분산 추적(tracing)에 대한 지원을 추가한다.
- `Accelerators`: 도커 사용 시 Nvidia GPU 지원 활성화한다.
- `AdvancedAuditing`: [고급 감사](/docs/tasks/debug-application-cluster/audit/#advanced-audit) 기능을 활성화한다.
- `AffinityInAnnotations`: [파드 어피니티 또는 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#어피니티-affinity-와-안티-어피니티-anti-affinity)
@@ -486,6 +567,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
리더 마이그레이션(Leader Migration)을 활성화한다.
- `CPUManager`: 컨테이너 수준의 CPU 어피니티 지원을 활성화한다.
[CPU 관리 정책](/docs/tasks/administer-cluster/cpu-management-policies/)을 참고한다.
+- `CPUManagerPolicyOptions`: CPUManager 정책의 미세 조정을 허용한다.
- `CRIContainerLogRotation`: cri 컨테이너 런타임에 컨테이너 로그 로테이션을 활성화한다. 로그 파일 사이즈 기본값은 10MB이며,
컨테이너 당 최대 로그 파일 수 기본값은 5이다. 이 값은 kubelet 환경설정으로 변경할 수 있다.
더 자세한 내용은 [노드 레벨에서의 로깅](/ko/docs/concepts/cluster-administration/logging/#노드-레벨에서의-로깅)을 참고한다.
@@ -506,6 +588,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
인-트리 플러그인에서 EBS CSI 플러그인으로 라우팅할 수 있다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationAWS 기능 플래그가 활성화되고
EBS CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+ 이 플래그는 인-트리 EBS 플러그인의 등록을 막는 `InTreePluginAWSUnregister` 기능 플래그로 인해
+ 더 이상 사용되지 않는다.
- `CSIMigrationAzureDisk`: shim 및 변환 로직을 통해 볼륨 작업을
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureDisk CSI 플러그인이 설치와 구성이 되어 있지 않은 경우 인-트리
@@ -516,7 +600,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
Azure-Disk 인-트리 플러그인에서 AzureDisk CSI 플러그인으로
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureDisk 기능
플래그가 활성화되고 AzureDisk CSI 플러그인이 설치 및 구성이 되어
- 있어야 한다.
+ 있어야 한다. 이 플래그는 인-트리 AzureDisk 플러그인의 등록을 막는 `InTreePluginAzureDiskUnregister` 기능 플래그로 인해
+ 더 이상 사용되지 않는다.
- `CSIMigrationAzureFile`: shim 및 변환 로직을 통해 볼륨 작업을
Azure-File 인-트리 플러그인에서 AzureFile CSI 플러그인으로 라우팅할 수 있다.
노드에 AzureFile CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
@@ -527,7 +612,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
Azure 파일 인-트리 플러그인에서 AzureFile CSI 플러그인으로
라우팅할 수 있다. 클러스터의 모든 노드에 CSIMigration과 CSIMigrationAzureFile 기능
플래그가 활성화되고 AzureFile CSI 플러그인이 설치 및 구성이 되어
- 있어야 한다.
+ 있어야 한다. 이 플래그는 인-트리 AzureFile 플러그인의 등록을 막는
+ `InTreePluginAzureFileUnregister` 기능 플래그로 인해
+ 더 이상 사용되지 않는다.
- `CSIMigrationGCE`: shim 및 변환 로직을 통해 볼륨 작업을
GCE-PD 인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다. 노드에
PD CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리 GCE 플러그인으로 폴백을
@@ -536,7 +623,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
인-트리 플러그인 등록을 중지하고 shim 및 변환 로직을 통해 볼륨 작업을 GCE-PD
인-트리 플러그인에서 PD CSI 플러그인으로 라우팅할 수 있다.
CSIMigration과 CSIMigrationGCE 기능 플래그가 활성화되고 PD CSI
- 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
+ 플러그인이 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 GCE PD 플러그인의 등록을 막는 `InTreePluginGCEUnregister` 기능 플래그로 인해
+ 더 이상 사용되지 않는다.
- `CSIMigrationOpenStack`: shim 및 변환 로직을 통해 볼륨 작업을
Cinder 인-트리 플러그인에서 Cinder CSI 플러그인으로 라우팅할 수 있다. 노드에
Cinder CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우 인-트리
@@ -545,7 +633,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
Cinder 인-트리 플러그인 등록을 중지하고 shim 및 변환 로직이 Cinder 인-트리
플러그인에서 Cinder CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다.
클러스터의 모든 노드에 CSIMigration과 CSIMigrationOpenStack 기능 플래그가 활성화되고
- Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다.
+ Cinder CSI 플러그인이 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 openstack cinder 플러그인의 등록을 막는 `InTreePluginOpenStackUnregister` 기능 플래그로 인해
+ 더 이상 사용되지 않는다.
- `CSIMigrationvSphere`: vSphere 인-트리 플러그인에서 vSphere CSI 플러그인으로 볼륨 작업을
라우팅하는 shim 및 변환 로직을 사용한다.
노드에 vSphere CSI 플러그인이 설치 및 구성이 되어 있지 않은 경우
@@ -554,7 +643,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
플러그인 등록을 중지하고 shim 및 변환 로직을 활성화하여 vSphere 인-트리 플러그인에서
vSphere CSI 플러그인으로 볼륨 작업을 라우팅할 수 있도록 한다. CSIMigration 및
CSIMigrationvSphere 기능 플래그가 활성화되고 vSphere CSI 플러그인이
- 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다.
+ 클러스터의 모든 노드에 설치 및 구성이 되어 있어야 한다. 이 플래그는 인-트리 vsphere 플러그인의 등록을 막는 `InTreePluginvSphereUnregister` 기능 플래그로 인해
+ 더 이상 사용되지 않는다.
- `CSINodeInfo`: csi.storage.k8s.io에서 CSINodeInfo API 오브젝트와 관련된 모든 로직을 활성화한다.
- `CSIPersistentVolume`: [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
호환 볼륨 플러그인을 통해 프로비저닝된 볼륨을 감지하고
@@ -570,14 +660,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
이 필드는 CSI드라이버에서 생성된 볼륨이 마운트될 때 볼륨 소유권과
권한 수정을 지원하는지 여부를 제어한다.
- `CSIVolumeHealth`: 노드에서의 CSI 볼륨 상태 모니터링 기능을 활성화한다.
+- `CSRDuration`: 클라이언트가 쿠버네티스 CSR API를 통해 발급된 인증서의 기간을
+ 요청할 수 있다.
- `ConfigurableFSGroupPolicy`: 사용자가 파드에 볼륨을 마운트할 때 fsGroups에 대한
볼륨 권한 변경 정책을 구성할 수 있다. 자세한 내용은
[파드의 볼륨 권한 및 소유권 변경 정책 구성](/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)을
참고한다.
+- `ControllerManagerLeaderMigration`: `kube-controller-manager` 및 `cloud-controller-manager`에
+ 대한 리더 마이그레이션을 지원한다.
- `CronJobControllerV2`: {{< glossary_tooltip text="크론잡(CronJob)" term_id="cronjob" >}}
컨트롤러의 대체 구현을 사용한다. 그렇지 않으면,
동일한 컨트롤러의 버전 1이 선택된다.
- 버전 2 컨트롤러는 실험적인 성능 향상을 제공한다.
- `CustomCPUCFSQuotaPeriod`: [kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/)에서
`cpuCFSQuotaPeriod` 를 노드가 변경할 수 있도록 한다.
- `CustomPodDNS`: `dnsConfig` 속성을 사용하여 파드의 DNS 설정을 사용자 정의할 수 있다.
@@ -591,12 +684,20 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
생성된 리소스에서 스키마 기반 유효성 검사를 활성화한다.
- `CustomResourceWebhookConversion`: [커스텀리소스데피니션](/ko/docs/concepts/extend-kubernetes/api-extension/custom-resources/)에서
생성된 리소스에 대해 웹 훅 기반의 변환을 활성화한다.
+- `DaemonSetUpdateSurge`: 노드당 업데이트 중 가용성을 유지하도록
+ 데몬셋 워크로드를 사용하도록 설정한다.
- `DefaultPodTopologySpread`: `PodTopologySpread` 스케줄링 플러그인을 사용하여
[기본 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/#내부-기본-제약)를 수행한다.
+- `DelegateFSGroupToCSIDriver`: CSI 드라이버가 지원할 경우, NodeStageVolume 및 NodePublishVolume CSI 호출을 통해
+ `fsGroup`를 전달하여 파드의 `securityContext`에서
+ `fsGroup`를 드라이브에 적용하는 역할을 위임한다.
- `DevicePlugins`: 노드에서 [장치 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)
기반 리소스 프로비저닝을 활성화한다.
- `DisableAcceleratorUsageMetrics`:
[kubelet이 수집한 액셀러레이터 지표 비활성화](/ko/docs/concepts/cluster-administration/system-metrics/#액셀러레이터-메트릭-비활성화).
+- `DisableCloudProviders`: `kube-apiserver`, `kube-controller-manager`,
+ `--cloud-provider` 컴포넌트 플래그와 관련된 `kubelet`의
+ 모든 기능을 비활성화한다.
- `DownwardAPIHugePages`: [다운워드 API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information)에서
hugepages 사용을 활성화한다.
- `DryRun`: 서버 측의 [dry run](/docs/reference/using-api/api-concepts/#dry-run) 요청을
@@ -635,6 +736,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
현재 수정된 결함에 의존하는 경우 존재한다.
[준비성 프로브](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)를 참조한다.
- `ExpandCSIVolumes`: CSI 볼륨 확장을 활성화한다.
+- `ExpandedDNSConfig`: 더 많은 DNS 검색 경로와 더 긴 DNS 검색 경로 목록을 허용하려면
+ kubelet과 kube-apiserver를 사용하도록 설정한다.
+ [확장된 DNS 구성](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration)을 참고한다.
- `ExpandInUsePersistentVolumes`: 사용 중인 PVC를 확장할 수 있다.
[사용 중인 퍼시스턴트볼륨클레임 크기 조정](/ko/docs/concepts/storage/persistent-volumes/#사용-중인-퍼시스턴트볼륨클레임-크기-조정)을 참고한다.
- `ExpandPersistentVolumes`: 퍼시스턴트 볼륨 확장을 활성화한다.
@@ -671,8 +775,24 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
기능을 활성화한다.
- `ImmutableEphemeralVolumes`: 안정성과 성능 향상을 위해 개별 시크릿(Secret)과 컨피그맵(ConfigMap)을
변경할 수 없는(immutable) 것으로 표시할 수 있다.
+- `InTreePluginAWSUnregister`: kubelet 및 볼륨 컨트롤러에 aws-ebs 인-트리
+ 플러그인의 등록을 중지한다.
+- `InTreePluginAzureDiskUnregister`: kubelet 및 볼륨 컨트롤러에 azuredisk 인-트리
+ 플러그인의 등록을 중지한다.
+- `InTreePluginAzureFileUnregister`: kubelet 및 볼륨 컨트롤러에 azurefile 인-트리
+ 플러그인의 등록을 중지한다.
+- `InTreePluginGCEUnregister`: kubelet 및 볼륨 컨트롤러에 gce-pd 인-트리
+ 플러그인의 등록을 중지한다.
+- `InTreePluginOpenStackUnregister`: kubelet 및 볼륨 컨트롤러에 오픈스택 cinder 인-트리
+ 플러그인의 등록을 중지한다.
+- `InTreePluginvSphereUnregister`: kubelet 및 볼륨 컨트롤러에 vSphere 인-트리
+ 플러그인의 등록을 중지한다.
- `IndexedJob`: [잡](/ko/docs/concepts/workloads/controllers/job/) 컨트롤러가
완료 횟수를 기반으로 파드 완료를 관리할 수 있도록 한다.
+- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아 있는 파드에 의존하지 않고
+ [잡](/ko/docs/concepts/workloads/controllers/job)의 완료를 추적할 수 있다.
+ 잡 컨트롤러는 완료된 파드를 추적하기 위해
+ 완료된 파드의 잡 상태 필드를 사용한다.
- `IngressClassNamespacedParams`: `IngressClass` 리소스가 네임스페이스 범위로
한정된 파라미터를 이용할 수 있도록 한다. 이 기능은 `IngressClass.spec.parameters` 에
`Scope` 와 `Namespace` 2개의 필드를 추가한다.
@@ -680,11 +800,17 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
비동기 조정을 허용한다.
- `IPv6DualStack`: IPv6을 위한 [이중 스택](/ko/docs/concepts/services-networking/dual-stack/)
기능을 활성화한다.
+- `JobTrackingWithFinalizers`: 클러스터에 무제한으로 남아있는 파드에
+ 의존하지 않고 잡 완료를 추적할 수 있다.
+ 파드 finalizers는 잡 상태 필드와
+ 아직 구성되지 않은 파드를 추적할 수 있다.
- `KubeletConfigFile`: 구성 파일을 사용하여 지정된 파일에서
kubelet 구성을 로드할 수 있다.
자세한 내용은 [구성 파일을 통해 kubelet 파라미터 설정](/docs/tasks/administer-cluster/kubelet-config-file/)을
참고한다.
- `KubeletCredentialProviders`: 이미지 풀 자격 증명에 대해 kubelet exec 자격 증명 공급자를 활성화한다.
+- `KubeletInUserNamespace`: {{}}에서 kubelet 실행을 활성화한다.
+ [루트가 아닌 유저로 쿠버네티스 노드 컴포넌트 실행](/docs/tasks/administer-cluster/kubelet-in-userns/)을 참고한다.
- `KubeletPluginsWatcher`: kubelet이 [CSI 볼륨 드라이버](/ko/docs/concepts/storage/volumes/#csi)와 같은
플러그인을 검색할 수 있도록 프로브 기반 플러그인 감시자(watcher) 유틸리티를 사용한다.
- `KubeletPodResources`: kubelet의 파드 리소스 gPRC 엔드포인트를 활성화한다. 자세한 내용은
@@ -709,6 +835,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
향상시킨다.
- `LogarithmicScaleDown`: 컨트롤러 스케일 다운 시에 파드 타임스탬프를 로그 스케일로 버켓화하여
축출할 파드를 반-랜덤하게 선택하는 기법을 활성화한다.
+- `MemoryManager`: NUMA 토폴로지를 기반으로 컨테이너에 대한
+ 메모리 어피니티를 설정할 수 있다.
+- `MemoryQoS`: cgroup v2 메모리 컨트롤러를 사용하여 파드/컨테이너에서 메모리 보호 및 사용 제한을 사용하도록 설정한다.
- `MixedProtocolLBService`: 동일한 로드밸런서 유형 서비스 인스턴스에서 다른 프로토콜
사용을 활성화한다.
- `MountContainers`: 호스트의 유틸리티 컨테이너를 볼륨 마운터로 사용할 수 있다.
@@ -720,6 +849,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `NodeDisruptionExclusion`: 영역(zone) 장애 시 노드가 제외되지 않도록 노드 레이블 `node.kubernetes.io/exclude-disruption`
사용을 활성화한다.
- `NodeLease`: 새로운 리스(Lease) API가 노드 상태 신호로 사용될 수 있는 노드 하트비트(heartbeats)를 보고할 수 있게 한다.
+- `NodeSwap`: 노드의 쿠버네티스 워크로드용 스왑 메모리를 할당하려면 kubelet을 활성화한다.
+ 반드시 `KubeletConfiguration.failSwapOn`를 false로 설정한 후 사용해야 한다.
+ 더 자세한 정보는 [스왑 메모리](/docs/concepts/architecture/nodes/#swap-memory)를 참고한다.
- `NonPreemptingPriority`: 프라이어리티클래스(PriorityClass)와 파드에 `preemptionPolicy` 필드를 활성화한다.
- `PVCProtection`: 파드에서 사용 중일 때 퍼시스턴트볼륨클레임(PVC)이
삭제되지 않도록 한다.
@@ -737,17 +869,25 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `PodReadinessGates`: 파드 준비성 평가를 확장하기 위해
`PodReadinessGate` 필드 설정을 활성화한다. 자세한 내용은 [파드의 준비성 게이트](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)를
참고한다.
+- `PodSecurity`: `PodSecurity` 어드미션 플러그인을 사용하도록 설정한다.
- `PodShareProcessNamespace`: 파드에서 실행되는 컨테이너 간에 단일 프로세스 네임스페이스를
공유하기 위해 파드에서 `shareProcessNamespace` 설정을 활성화한다. 자세한 내용은
[파드의 컨테이너 간 프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)에서 확인할 수 있다.
+- `PreferNominatedNode`: 이 플래그는 클러스터에 존재하는 다른 노드를 반복해서 검사하기 전에
+ 지정된 노드를 먼저 검사할지 여부를
+ 스케줄러에 알려준다.
- `ProbeTerminationGracePeriod`: 파드의 [프로브-수준
`terminationGracePeriodSeconds` 설정하기](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds) 기능을 활성화한다.
더 자세한 사항은 [기능개선 제안](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)을 참고한다.
- `ProcMountType`: SecurityContext의 `procMount` 필드를 설정하여
컨테이너의 proc 타입의 마운트를 제어할 수 있다.
+- `ProxyTerminatingEndpoints`: `ExternalTrafficPolicy=Local`일 때 종료 엔드포인트를 처리하도록
+ kube-proxy를 활성화한다.
- `QOSReserved`: QoS 수준에서 리소스 예약을 허용하여 낮은 QoS 수준의 파드가
더 높은 QoS 수준에서 요청된 리소스로 파열되는 것을 방지한다
(현재 메모리만 해당).
+- `ReadWriteOncePod`: `ReadWriteOncePod` 퍼시스턴트 볼륨 엑세스 모드를
+ 사용한다.
- `RemainingItemCount`: API 서버가
[청크(chunking) 목록 요청](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks)에 대한
응답에서 남은 항목 수를 표시하도록 허용한다.
@@ -779,6 +919,10 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
스케줄링할 수 있다.
- `SCTPSupport`: 파드, 서비스, 엔드포인트, 엔드포인트슬라이스 및 네트워크폴리시 정의에서
_SCTP_ `protocol` 값을 활성화한다.
+- `SeccompDefault`: 모든 워크로드의 기본 구분 프로파일로 `RuntimeDefault`을 사용한다.
+ seccomp 프로파일은 파드 및 컨테이너 `securityContext`에 지정되어 있다.
+- `SelectorIndex`: API 서버 감시(watch) 캐시의 레이블 및 필드 기반 인덱스를 사용하여
+ 목록 작업을 가속화할 수 있다.
- `ServerSideApply`: API 서버에서 [SSA(Sever Side Apply)](/docs/reference/using-api/server-side-apply/)
경로를 활성화한다.
- `ServiceAccountIssuerDiscovery`: API 서버에서 서비스 어카운트 발행자에 대해 OIDC 디스커버리 엔드포인트(발급자 및
@@ -806,6 +950,8 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `StartupProbe`: kubelet에서
[스타트업](/ko/docs/concepts/workloads/pods/pod-lifecycle/#언제-스타트업-프로브를-사용해야-하는가)
프로브를 활성화한다.
+- `StatefulSetMinReadySeconds`: 스테이트풀셋 컨트롤러가 `minReadySeconds`를
+ 반영할 수 있다.
- `StorageObjectInUseProtection`: 퍼시스턴트볼륨 또는 퍼시스턴트볼륨클레임 오브젝트가 여전히
사용 중인 경우 삭제를 연기한다.
- `StorageVersionAPI`: [스토리지 버전 API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageversion-v1alpha1-internal-apiserver-k8s-io)를
@@ -867,6 +1013,7 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
- `WinDSR`: kube-proxy가 윈도우용 DSR 로드 밸런서를 생성할 수 있다.
- `WinOverlay`: kube-proxy가 윈도우용 오버레이 모드에서 실행될 수 있도록 한다.
- `WindowsGMSA`: 파드에서 컨테이너 런타임으로 GMSA 자격 증명 스펙을 전달할 수 있다.
+- `WindowsHostProcessContainers`: 윈도우 HostProcess 컨테이너에 대한 지원을 사용하도록 설정한다.
- `WindowsRunAsUserName` : 기본 사용자가 아닌(non-default) 사용자로 윈도우 컨테이너에서
애플리케이션을 실행할 수 있도록 지원한다. 자세한 내용은
[RunAsUserName 구성](/ko/docs/tasks/configure-pod-container/configure-runasusername/)을
@@ -875,7 +1022,9 @@ kubelet과 같은 컴포넌트의 기능 게이트를 설정하려면, 기능
엔드포인트 대신 엔드포인트슬라이스를 기본 데이터 소스로 사용하여
확장성과 성능을 향상시킨다.
[엔드포인트슬라이스 활성화하기](/ko/docs/concepts/services-networking/endpoint-slices/)를 참고한다.
-
+- `WindowsHostProcessContainers`: 윈도우 노드에서 `HostProcess`
+ 컨테이너 지원을 활성화한다.
+
## {{% heading "whatsnext" %}}
diff --git a/content/ko/docs/reference/glossary/api-eviction.md b/content/ko/docs/reference/glossary/api-eviction.md
index f8a65c606e..7d5ee60667 100644
--- a/content/ko/docs/reference/glossary/api-eviction.md
+++ b/content/ko/docs/reference/glossary/api-eviction.md
@@ -2,7 +2,7 @@
title: API를 이용한 축출(Eviction)
id: api-eviction
date: 2021-04-27
-full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
+full_link: /ko/docs/concepts/scheduling-eviction/api-eviction/
short_description: >
API를 이용한 축출은 축출 API를 사용하여 파드의 정상 종료를 트리거하는
축출 오브젝트를 만드는 프로세스이다
diff --git a/content/ko/docs/reference/glossary/csi.md b/content/ko/docs/reference/glossary/csi.md
new file mode 100644
index 0000000000..64053db20b
--- /dev/null
+++ b/content/ko/docs/reference/glossary/csi.md
@@ -0,0 +1,21 @@
+---
+title: 컨테이너 스토리지 인터페이스(CSI)
+id: csi
+date: 2018-06-25
+full_link: /ko/docs/concepts/storage/volumes/#csi
+short_description: >
+ 컨테이너 스토리지 인터페이스(CSI)는 컨테이너에 스토리지 시스템을 노출하는 표준 인터페이스를 정의한다.
+
+
+aka:
+tags:
+- storage
+---
+ 컨테이너 스토리지 인터페이스(CSI)는 컨테이너에 스토리지 시스템을 노출하는 표준 인터페이스를 정의한다.
+
+
+
+CSI를 통해 공급업체는 쿠버네티스 저장소(트리 외 플러그인)를 추가하지 않고도 쿠버네티스용 사용자 스토리지 플러그인을 생성할 수 있다. 스토리지 제공자가 CSI 드라이버를 사용하려면, 먼저 [클러스터에 배포](https://kubernetes-csi.github.io/docs/deploying.html)해야 한다. 그런 다음 해당 CSI 드라이버를 사용하는 {{< glossary_tooltip text="스토리지클래스(StorageClass)" term_id="storage-class" >}}를 생성할 수 있다.
+
+* [쿠버네티스 문서에서 CSI](/ko/docs/concepts/storage/volumes/#csi)
+* [사용 가능한 CSI 드라이버 목록](https://kubernetes-csi.github.io/docs/drivers.html)
diff --git a/content/ko/docs/reference/kubectl/kubectl.md b/content/ko/docs/reference/kubectl/kubectl.md
index 81e4d3fa74..b2a16bf452 100644
--- a/content/ko/docs/reference/kubectl/kubectl.md
+++ b/content/ko/docs/reference/kubectl/kubectl.md
@@ -328,7 +328,31 @@ kubectl [flags]
+## {{% heading "envvars" %}}
+
+
+
+
+
+
+
+
+
KUBECONFIG
+
+
+
kubectl 구성 ("kubeconfig") 파일 경로. 기본: "$HOME/.kube/config"
+
+
+
+
KUBECTL_COMMAND_HEADERS
+
+
+
false로 설정하면, 호출된 kubectl 명령(쿠버네티스 버전 v1.22 이상)을 자세히 설명하는 추가 HTTP 헤더를 해제
+
+
+
+
## {{% heading "seealso" %}}
diff --git a/content/ko/docs/reference/kubectl/overview.md b/content/ko/docs/reference/kubectl/overview.md
index 3d8179a08a..247489a6ee 100644
--- a/content/ko/docs/reference/kubectl/overview.md
+++ b/content/ko/docs/reference/kubectl/overview.md
@@ -87,7 +87,7 @@ kubectl [command] [TYPE] [NAME] [flags]
`cluster-info` | `kubectl cluster-info [flags]` | 클러스터의 마스터와 서비스에 대한 엔드포인트 정보를 표시한다.
`completion` | `kubectl completion SHELL [options]` | 지정된 셸(bash 또는 zsh)에 대한 셸 완성 코드를 출력한다.
`config` | `kubectl config SUBCOMMAND [flags]` | kubeconfig 파일을 수정한다. 세부 사항은 개별 하위 명령을 참고한다.
-`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다.
+`convert` | `kubectl convert -f FILENAME [options]` | 다른 API 버전 간에 구성 파일을 변환한다. YAML 및 JSON 형식이 모두 허용된다. 참고 - `kubectl-convert` 플러그인을 설치해야 한다.
`cordon` | `kubectl cordon NODE [options]` | 노드를 스케줄 불가능(unschedulable)으로 표시한다.
`cp` | `kubectl cp [options]` | 컨테이너에서 그리고 컨테이너로 파일 및 디렉터리를 복사한다.
`create` | `kubectl create -f FILENAME [flags]` | 파일이나 표준입력에서 하나 이상의 리소스를 생성한다.
diff --git a/content/ko/docs/reference/labels-annotations-taints.md b/content/ko/docs/reference/labels-annotations-taints.md
index 0854c1b5cf..2577531042 100644
--- a/content/ko/docs/reference/labels-annotations-taints.md
+++ b/content/ko/docs/reference/labels-annotations-taints.md
@@ -200,7 +200,7 @@ kubelet이 Microsoft 윈도우에서 실행되고 있다면, 사용 중인 Windo
kube-proxy 에는 커스텀 프록시를 위한 이와 같은 레이블이 있으며, 이 레이블은 서비스 컨트롤을 커스텀 프록시에 위임한다.
-## experimental.windows.kubernetes.io/isolation-type
+## experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type}
예시: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
@@ -210,6 +210,7 @@ Hyper-V 격리(isolation)를 사용하여 윈도우 컨테이너를 실행하려
{{< note >}}
이 어노테이션은 하나의 컨테이너로 구성된 파드에만 설정할 수 있다.
+v1.20부터 이 어노테이션은 더이상 사용되지 않는다. 실험적인 Hyper-V 지원은 1.21버전에서 제거되었다.
{{< /note >}}
## ingressclass.kubernetes.io/is-default-class
@@ -262,11 +263,29 @@ kube-controller-manager의 잡(Job) 컨트롤러는
## endpoints.kubernetes.io/over-capacity
-예시: `endpoints.kubernetes.io/over-capacity:warning`
+예시: `endpoints.kubernetes.io/over-capacity:truncated`
적용 대상: 엔드포인트(Endpoints)
-v1.21 이상의 쿠버네티스 클러스터에서, 엔드포인트(Endpoints) 컨트롤러가 1000개 이상의 엔드포인트를 관리하고 있다면 각 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 엔드포인트 리소스가 용량 초과 되었음을 나타낸다.
+v1.22 이상의 쿠버네티스 클러스터에서, 한 엔드포인트(Endpoints) 리소스가 관리하고 있는 엔드포인트의 수가 1000개 이상이면 엔드포인트 컨트롤러가 해당 엔드포인트 리소스에 이 어노테이션을 추가한다. 이 어노테이션은 해당 엔드포인트 리소스가 용량 초과 되었으며 엔드포인트 컨트롤러가 엔드포인트의 수를 1000으로 줄였음을 나타낸다.
+
+## batch.kubernetes.io/job-tracking
+
+예시: `batch.kubernetes.io/job-tracking: ""`
+
+적용 대상: 잡
+
+잡에 어노테이션이 있으면 컨트롤 플레인은 [finalizers를 사용하여 잡 상태 추적](/ko/docs/concepts/workloads/controllers/job/#job-tracking-with-finalizers)
+중임을 나타낸다.
+어노테이션을 수동으로 추가하거나 제거하지 **않는다**.
+
+## scheduler.alpha.kubernetes.io/preferAvoidPods (deprecated) {#scheduleralphakubernetesio-preferavoidpods}
+
+적용 대상: 노드
+
+이 어노테이션을 사용하려면 [NodePreferAvoidPods 스케줄링 플러그인](/ko/docs/reference/scheduling/config/#scheduling-plugins)이 활성화되어 있어야 한다.
+해당 플러그인은 쿠버네티스 1.22에서 사용 중단되었다.
+대신 [테인트와 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을 사용한다.
**이 이후로 나오는 테인트는 모두 '적용 대상: 노드' 이다.**
@@ -323,3 +342,87 @@ kubelet이 "외부" 클라우드 공급자에 의해 실행되었다면 노드
예시: `node.cloudprovider.kubernetes.io/shutdown:NoSchedule`
노드의 상태가 클라우드 공급자가 정의한 'shutdown' 상태이면, 이에 따라 노드에 `node.cloudprovider.kubernetes.io/shutdown` 테인트가 `NoSchedule` 값으로 설정된다.
+
+## pod-security.kubernetes.io/enforce
+
+예시: `pod-security.kubernetes.io/enforce: baseline`
+
+적용 대상: 네임스페이스
+
+값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
+`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
+특히 `enforce` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는
+레이블 네임스페이스에 모든 파드의 생성을 금지한다.
+
+더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
+참고한다.
+
+## pod-security.kubernetes.io/enforce-version
+
+예시: `pod-security.kubernetes.io/enforce-version: {{< skew latestVersion >}}`
+
+적용 대상: 네임스페이스
+
+값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다.
+설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
+정책의 버전이 결정된다.
+
+더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
+참고한다.
+
+## pod-security.kubernetes.io/audit
+
+예시: `pod-security.kubernetes.io/audit: baseline`
+
+적용 대상: 네임스페이스
+
+값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
+`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
+특히 `audit` 레이블은 표시된 수준에 정의된 요구 사항을 충족하지 않는 레이블 네임스페이스에 파드를 생성하는 것을
+방지하지 않지만, 해당 파드에 audit 어노테이션을 추가한다.
+
+더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
+참고한다.
+
+## pod-security.kubernetes.io/audit-version
+
+예시: `pod-security.kubernetes.io/audit-version: {{< skew latestVersion >}}`
+
+적용 대상: 네임스페이스
+
+값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다.
+설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
+정책의 버전이 결정된다.
+
+더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
+참고한다.
+
+## pod-security.kubernetes.io/warn
+
+예시: `pod-security.kubernetes.io/warn: baseline`
+
+적용 대상: 네임스페이스
+
+값은 **반드시** [파드 보안 표준](/docs/concepts/security/pod-security-standards) 레벨과 상응하는
+`privileged`, `baseline`, 또는 `restricted` 중 하나여야 한다.
+특히 `warn` 레이블은 해당 레이블이 달린 네임스페이스에, 표시된 레벨에 명시된 요구 사항을 충족하지 않는 파드를 생성하는 것을
+방지하지는 않지만, 그러한 파드가 생성되면 사용자에게 경고를 반환한다.
+디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
+객체를 만들거나 업데이트할 때에도 경고가 표시된다.
+
+더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
+참고한다.
+
+## pod-security.kubernetes.io/warn-version
+
+예시: `pod-security.kubernetes.io/warn-version: {{< skew latestVersion >}}`
+
+적용 대상: 네임스페이스
+
+값은 **반드시** `latest`이거나 `v.` 형식의 유효한 쿠버네티스 버전이어야 한다.
+설정된 파드의 유효성을 검사할 때 적용할 [파드 보안 표준](/docs/concepts/security/pod-security-standards)
+정책의 버전이 결정된다. 디플로이먼트, 잡, 스테이트풀셋 등과 같은 파드 템플릿을 포함하는
+객체를 만들거나 업데이트할 때에도 경고가 표시된다.
+
+더 많은 정보는 [네임스페이스에서 파드 보안 적용](/docs/concepts/security/pod-security-admission)을
+참고한다.
\ No newline at end of file
diff --git a/content/ko/docs/reference/scheduling/config.md b/content/ko/docs/reference/scheduling/config.md
index 2f46c78d8b..07f06863d4 100644
--- a/content/ko/docs/reference/scheduling/config.md
+++ b/content/ko/docs/reference/scheduling/config.md
@@ -18,7 +18,8 @@ weight: 20
각 단계는 익스텐션 포인트(extension point)를 통해 노출된다. 플러그인은 이러한
익스텐션 포인트 중 하나 이상을 구현하여 스케줄링 동작을 제공한다.
-[KubeSchedulerConfiguration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+KubeSchedulerConfiguration ([v1beta1](/docs/reference/config-api/kube-scheduler-config.v1beta1/)
+또는 [v1beta2](/docs/reference/config-api/kube-scheduler-config.v1beta2/))
구조에 맞게 파일을 작성하고,
`kube-scheduler --config `을 실행하여
스케줄링 프로파일을 지정할 수 있다.
@@ -26,7 +27,7 @@ weight: 20
최소 구성은 다음과 같다.
```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
clientConnection:
kubeconfig: /etc/srv/kubernetes/kube-scheduler/kubeconfig
@@ -48,38 +49,41 @@ clientConnection:
스케줄링은 다음 익스텐션 포인트를 통해 노출되는 일련의 단계에서
발생한다.
-1. `QueueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를
+1. `queueSort`: 이 플러그인은 스케줄링 대기열에서 보류 중인 파드를
정렬하는 데 사용되는 정렬 기능을 제공한다. 대기열 정렬 플러그인은 한 번에 단 하나만 활성화될 수 있다.
사용할 수 있다.
-1. `PreFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를
+1. `preFilter`: 이 플러그인은 필터링하기 전에 파드 또는 클러스터에 대한 정보를
사전 처리하거나 확인하는 데 사용된다. 이 플러그인은 파드를 unschedulable로
표시할 수 있다.
-1. `Filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며
+1. `filter`: 이 플러그인은 스케줄링 정책의 단정(Predicates)과 동일하며
파드를 실행할 수 없는 노드를 필터링하는 데 사용된다. 필터는
구성된 순서대로 호출된다. 노드가 모든 필터를 통과하지 않으면 파드는 unschedulable로
표시된다.
-1. `PreScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는
+1. `postFilter`: 이 플러그인은 파드의 실행 가능한 노드를 찾을 수 없을 때,
+ 구성된 순서대로 호출된다. `postFilter` 플러그인이 파드 _schedulable_ 을 표시하는 경우,
+ 나머지 플러그인은 호출 되지 않는다.
+1. `preScore`: 이것은 사전 스코어링 작업을 수행하는 데 사용할 수 있는
정보성 익스텐션 포인트이다.
-1. `Score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를
+1. `score`: 이 플러그인은 필터링 단계를 통과한 각 노드에 점수를
제공한다. 그런 다음 스케줄러는 가중치 합계가 가장 높은
노드를 선택한다.
-1. `Reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에
+1. `reserve`: 지정된 파드에 리소스가 예약된 경우 플러그인에
알리는 정보성 익스텐션 포인트이다. 플러그인은 또한
`Reserve` 도중 또는 이후에 실패한 경우 호출 되는 `Unreserve` 호출을
구현한다.
-1. `Permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다.
-1. `PreBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다.
-1. `Bind`: 플러그인은 파드를 노드에 바인딩한다. Bind 플러그인은 순서대로 호출되며
- 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. Bind
+1. `permit`: 이 플러그인은 파드 바인딩을 방지하거나 지연시킬 수 있다.
+1. `preBind`: 이 플러그인은 파드가 바인딩되기 전에 필요한 모든 작업을 수행한다.
+1. `bind`: 플러그인은 파드를 노드에 바인딩한다. `bind` 플러그인은 순서대로 호출되며
+ 일단 바인딩이 완료되면 나머지 플러그인은 건너뛴다. bind
플러그인은 적어도 하나 이상 필요하다.
-1. `PostBind`: 파드가 바인드된 후 호출되는
+1. `postBind`: 파드가 바인드된 후 호출되는
정보성 익스텐션 포인트이다.
각 익스텐션 포인트에 대해 특정 [기본 플러그인](#스케줄링-플러그인)을 비활성화하거나
자체 플러그인을 활성화할 수 있다. 예를 들면, 다음과 같다.
```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- plugins:
@@ -99,98 +103,100 @@ profiles:
### 스케줄링 플러그인
-1. `UnReserve`: 파드가 예약된 후 거부되고 `Permit` 플러그인에 의해 보류된 경우
- 호출되는 정보성 익스텐션 포인트이다.
-
-## 스케줄링 플러그인
-
기본적으로 활성화된 다음의 플러그인은 이들 익스텐션 포인트 중
하나 이상을 구현한다.
-- `SelectorSpread`: {{< glossary_tooltip text="서비스" term_id="service" >}},
- {{< glossary_tooltip text="레플리카셋(ReplicaSets)" term_id="replica-set" >}} 및
- {{< glossary_tooltip text="스테이트풀셋(StatefulSets)" term_id="statefulset" >}}에
- 속하는 파드에 대해 노드 간 분산을 선호한다.
- 익스텐션 포인트: `PreScore`, `Score`.
- `ImageLocality`: 파드가 실행하는 컨테이너 이미지가 이미 있는 노드를
선호한다.
- 익스텐션 포인트: `Score`.
+ 익스텐션 포인트: `score`.
- `TaintToleration`: [테인트(taint)와 톨러레이션(toleration)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)을
구현한다.
- 익스텐션 포인트 구현: `Filter`, `Prescore`, `Score`.
+ 익스텐션 포인트 구현: `filter`, `preScore`, `score`.
- `NodeName`: 파드 명세 노드 이름이 현재 노드와 일치하는지 확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `NodePorts`: 노드에 요청된 파드 포트에 대해 사용 가능한 포트가 있는지 확인한다.
- 익스텐션 포인트: `PreFilter`, `Filter`.
+ 익스텐션 포인트: `preFilter`, `filter`.
- `NodePreferAvoidPods`: 노드 {{< glossary_tooltip text="어노테이션" term_id="annotation" >}}
`scheduler.alpha.kubernetes.io/preferAvoidPods` 에 따라
노드 점수를 매긴다.
- 익스텐션 포인트: `Score`.
+ 익스텐션 포인트: `score`.
- `NodeAffinity`: [노드 셀렉터](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-셀렉터-nodeselector)와
[노드 어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#노드-어피니티)를
구현한다.
- 익스텐션 포인트: `Filter`, `Score`.
+ 익스텐션 포인트: `filter`, `score`.
- `PodTopologySpread`: [파드 토폴로지 분배](/ko/docs/concepts/workloads/pods/pod-topology-spread-constraints/)를
구현한다.
- 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`.
+ 익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`.
- `NodeUnschedulable`: `.spec.unschedulable` 이 true로 설정된 노드를
필터링한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `NodeResourcesFit`: 노드에 파드가 요청하는 모든 리소스가 있는지
- 확인한다.
- 익스텐션 포인트: `PreFilter`, `Filter`.
+ 확인한다. 점수는 `LeastAllocated`(기본값), `MostAllocated`, `RequestedToCapacityRatio` 등 3가지 전략 중 하나를 사용할 수 있다.
+ 익스텐션 포인트: `preFilter`, `filter`, `score`.
- `NodeResourcesBalancedAllocation`: 파드가 스케줄된 경우, 보다 균형잡힌 리소스 사용량을
얻을 수 있는 노드를 선호한다.
- 익스텐션 포인트: `Score`.
+ 익스텐션 포인트: `score`.
- `NodeResourcesLeastAllocated`: 리소스 할당이 적은 노드를
선호한다.
익스텐션 포인트: `Score`.
- `VolumeBinding`: 노드에 요청된 {{< glossary_tooltip text="볼륨" term_id="volume" >}}이 있는지
또는 바인딩할 수 있는지 확인한다.
- 익스텐션 포인트: `PreFilter`, `Filter`, `Reserve`, `PreBind`, `Score`.
+ 익스텐션 포인트: `preFilter`, `filter`, `reserve`, `preBind`, `score`.
{{< note >}}
- `Score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이
+ `score` 익스텐션 포인트는 `VolumeCapacityPriority` 기능이
활성화되어 있어야 활성화되며,
요청된 볼륨 사이즈를 만족하는 가장 작은 PV들을 우선순위 매긴다.
{{< /note >}}
- `VolumeRestrictions`: 노드에 마운트된 볼륨이 볼륨 제공자에 특정한
제한 사항을 충족하는지 확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `VolumeZone`: 요청된 볼륨이 가질 수 있는 영역 요구 사항을 충족하는지
확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `NodeVolumeLimits`: 노드에 대해 CSI 볼륨 제한을 충족할 수 있는지
확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `EBSLimits`: 노드에 대해 AWS EBS 볼륨 제한을 충족할 수 있는지 확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `GCEPDLimits`: 노드에 대해 GCP-PD 볼륨 제한을 충족할 수 있는지 확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `AzureDiskLimits`: 노드에 대해 Azure 디스크 볼륨 제한을 충족할 수 있는지
확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `filter`.
- `InterPodAffinity`: [파드 간 어피니티 및 안티-어피니티](/ko/docs/concepts/scheduling-eviction/assign-pod-node/#파드간-어피니티와-안티-어피니티)를
구현한다.
- 익스텐션 포인트: `PreFilter`, `Filter`, `PreScore`, `Score`.
+ 익스텐션 포인트: `preFilter`, `filter`, `preScore`, `score`.
- `PrioritySort`: 기본 우선 순위 기반 정렬을 제공한다.
- 익스텐션 포인트: `QueueSort`.
+ 익스텐션 포인트: `queueSort`.
- `DefaultBinder`: 기본 바인딩 메커니즘을 제공한다.
- 익스텐션 포인트: `Bind`.
+ 익스텐션 포인트: `bind`.
- `DefaultPreemption`: 기본 선점 메커니즘을 제공한다.
- 익스텐션 포인트: `PostFilter`.
+ 익스텐션 포인트: `postFilter`.
기본으로 활성화되지 않는 다음의 플러그인을
컴포넌트 구성 API를 통해 활성화할 수도 있다.
+- `SelectorSpread`: {{< glossary_tooltip text="Services" term_id="service" >}},
+ {{< glossary_tooltip text="ReplicaSets" term_id="replica-set" >}}와
+ {{< glossary_tooltip text="StatefulSets" term_id="statefulset" >}}에 속하는 파드의 경우,
+ 노드간에 퍼지는 것을 선호한다.
+ 익스텐션 포인트: `preScore`, `score`.
+- `CinderLimits`: 노드에 대해 [OpenStack Cinder](https://docs.openstack.org/cinder/)
+ 볼륨 제한이 충족될 수 있는지 확인한다.
+ 익스텐션 포인트: `filter`.
+
+다음 플러그인은 더 이상 사용되지 않으며 `v1beta1`에서만
+사용할 수 있다.
+
+- `NodeResourcesLeastAllocated`: 리소스 할당이 낮은 노드를
+ 선호한다.
+ Extension points: `score`.
- `NodeResourcesMostAllocated`: 리소스 할당이 많은 노드를
선호한다.
- 익스텐션 포인트: `Score`.
+ 익스텐션 포인트: `score`.
- `RequestedToCapacityRatio`: 할당된 리소스의 구성된 기능에 따라 노드를
선호한다.
- 익스텐션 포인트: `Score`.
-- `CinderVolume`: 노드에 대해 OpenStack Cinder 볼륨 제한을 충족할 수 있는지
- 확인한다.
- 익스텐션 포인트: `Filter`.
+ 익스텐션 포인트: `score`.
- `NodeLabel`: Filters and / or scores a node according to configured
{{< glossary_tooltip text="label(s)" term_id="label" >}}.
익스텐션 포인트: `Filter`, `Score`.
@@ -198,7 +204,10 @@ profiles:
속한 파드가 구성된 레이블로 정의된 노드 집합에 맞는지
확인한다. 이 플러그인은 또한 서비스에 속한 파드를 노드 간에
분산하는 것을 선호한다.
- 익스텐션 포인트: `PreFilter`, `Filter`, `Score`.
+ 익스텐션 포인트: `preFilter`, `filter`, `score`.
+- `NodePreferAvoidPods`: 노드 주석 `scheduler.alpha.kubernetes.io/preferAvoidPods`에 따라
+ 노드의 우선 순위를 지정한다.
+ 익스텐션 포인트: `score`.
### 여러 프로파일
@@ -211,7 +220,7 @@ profiles:
실행된다.
```yaml
-apiVersion: kubescheduler.config.k8s.io/v1beta1
+apiVersion: kubescheduler.config.k8s.io/v1beta2
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
@@ -243,7 +252,7 @@ profiles:
{{< /note >}}
{{< note >}}
-모든 프로파일은 QueueSort 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며
+모든 프로파일은 `queueSort` 익스텐션 포인트에서 동일한 플러그인을 사용해야 하며
동일한 구성 파라미터(해당하는 경우)를 가져야 한다. 그 이유는 스케줄러가 보류 중 상태인 파드 대기열을
단 하나만 가질 수 있기 때문이다.
{{< /note >}}
@@ -253,3 +262,4 @@ profiles:
* [kube-scheduler 레퍼런스](/docs/reference/command-line-tools-reference/kube-scheduler/) 읽어보기
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 알아보기
* [kube-scheduler configuration (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1/) 레퍼런스 읽어보기
+* [kube-scheduler configuration (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2/) 레퍼런스 읽어보기
\ No newline at end of file
diff --git a/content/ko/docs/reference/scheduling/policies.md b/content/ko/docs/reference/scheduling/policies.md
index c2b9cbbdff..1146ba033a 100644
--- a/content/ko/docs/reference/scheduling/policies.md
+++ b/content/ko/docs/reference/scheduling/policies.md
@@ -98,5 +98,5 @@ weight: 10
* [스케줄링](/ko/docs/concepts/scheduling-eviction/kube-scheduler/)에 대해 배우기
* [kube-scheduler 프로파일](/docs/reference/scheduling/profiles/)에 대해 배우기
-* [kube-scheduler configuration 레퍼런스 (v1beta1)](/docs/reference/config-api/kube-scheduler-config.v1beta1) 읽어보기
+* [kube-scheduler configuration 레퍼런스 (v1beta2)](/docs/reference/config-api/kube-scheduler-config.v1beta2) 읽어보기
* [kube-scheduler Policy 레퍼런스 (v1)](/docs/reference/config-api/kube-scheduler-policy-config.v1/) 읽어보기
diff --git a/content/ko/docs/reference/tools/_index.md b/content/ko/docs/reference/tools/_index.md
index 6ac3b1dc82..b854bc3bd5 100644
--- a/content/ko/docs/reference/tools/_index.md
+++ b/content/ko/docs/reference/tools/_index.md
@@ -8,8 +8,7 @@ no_list: true
---
-쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 도움이되는 몇 가지 기본 제공 도구를 포함한다.
-
+쿠버네티스는 쿠버네티스 시스템으로 작업하는 데 필요한 공통적으로 사용되거나 관련성 있는 여러 내장 도구와 외부 도구를 포함한다.
diff --git a/content/ko/docs/reference/using-api/health-checks.md b/content/ko/docs/reference/using-api/health-checks.md
index 07857ea5d2..2e00d338a7 100644
--- a/content/ko/docs/reference/using-api/health-checks.md
+++ b/content/ko/docs/reference/using-api/health-checks.md
@@ -91,7 +91,7 @@ curl -k 'https://localhost:6443/readyz?verbose&exclude=etcd'
{{< feature-state state="alpha" >}}
-각 개별 헬스 체크는 http 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
+각 개별 헬스 체크는 HTTP 엔드포인트를 노출하고 개별적으로 체크가 가능하다.
개별 체크를 위한 스키마는 `/livez/` 이고, 여기서 `livez` 와 `readyz` 는 API 서버의 활성 상태 또는 준비 상태인지를 확인할 때 사용한다.
`` 경로 위에서 설명한 `verbose` 플래그를 사용해서 찾을 수 있고, `[+]` 와 `ok` 사이의 경로를 사용한다.
이러한 개별 헬스 체크는 머신에서 사용되서는 안되며, 운영자가 시스템의 현재 상태를 디버깅하는데 유용하다.
diff --git a/content/ko/docs/setup/best-practices/cluster-large.md b/content/ko/docs/setup/best-practices/cluster-large.md
index 899c63f6b7..5cf90e840e 100644
--- a/content/ko/docs/setup/best-practices/cluster-large.md
+++ b/content/ko/docs/setup/best-practices/cluster-large.md
@@ -121,3 +121,6 @@ _A_ 영역에 있는 컨트롤 플레인 호스트로만 전달한다. 단일
[클러스터 오토스케일러](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme)는
여러 클라우드 프로바이더와 통합되어 클러스터의 리소스 요구 수준에 맞는
노드 수를 실행할 수 있도록 도와준다.
+
+[addon resizer](https://github.com/kubernetes/autoscaler/tree/master/addon-resizer#readme)는
+클러스터 스케일이 변경될 때 자동으로 애드온 크기를 조정할 수 있도록 도와준다.
\ No newline at end of file
diff --git a/content/ko/docs/setup/production-environment/container-runtimes.md b/content/ko/docs/setup/production-environment/container-runtimes.md
index fb749a2346..18c8a9cbb1 100644
--- a/content/ko/docs/setup/production-environment/container-runtimes.md
+++ b/content/ko/docs/setup/production-environment/container-runtimes.md
@@ -26,7 +26,7 @@ weight: 20
다른 운영 체제의 경우, 해당 플랫폼과 관련된 문서를 찾아보자.
{{< /note >}}
-## Cgroup 드라이버
+## cgroup 드라이버
Control group은 프로세스에 할당된 리소스를 제한하는데 사용된다.
@@ -57,6 +57,38 @@ kubelet을 재시작하는 것은 에러를 해결할 수 없을 것이다.
교체하거나, 자동화를 사용하여 다시 설치한다.
{{< /caution >}}
+## cgroup v2
+
+cgroup v2는 cgroup Linux API의 다음 버전이다.
+cgroup v1과는 다르게 각 컨트롤러마다 다른 계층 대신 단일 계층이 있다.
+
+새 버전은 cgroup v1에 비해 몇 가지 향상된 기능을 제공하며, 개선 사항 중 일부는 다음과 같다.
+
+- API를 더 쉽고 깔끔하게 사용할 수 있음
+- 컨테이너로의 안전한 하위 트리 위임
+- 압력 중지 정보와 같은 새로운 기능
+
+일부 컨트롤러는 cgroup v1에 의해 관리되고 다른 컨트롤러는 cgroup v2에 의해 관리되는 하이브리드 구성을 지원하더라도,
+쿠버네티스는 모든 컨트롤러를 관리하기 위해
+동일한 cgroup 버전만 지원한다.
+
+systemd가 기본적으로 cgroup v2를 사용하지 않는 경우, 커널 명령줄에 `systemd.unified_cgroup_hierarchy=1`을
+추가하여 cgroup v2를 사용하도록 시스템을 구성할 수 있다.
+
+```shell
+# dnf install -y grubby && \
+ sudo grubby \
+ --update-kernel=ALL \
+ --args=”systemd.unified_cgroup_hierarchy=1"
+```
+
+구성을 적용하려면 노드를 재부팅해야 한다.
+
+cgroup v2로 전환할 때 사용자가 노드 또는 컨테이너 내에서
+cgroup 파일 시스템에 직접 접근하지 않는 한 사용자 경험에 현저한 차이가 없어야 한다.
+
+cgroup v2를 사용하려면 CRI 런타임에서도 cgroup v2를 지원해야 한다.
+
### kubeadm으로 생성한 클러스터의 드라이버를 `systemd`로 변경하기
kubeadm으로 생성한 클러스터의 cgroup 드라이버를 `systemd`로 변경하려면
diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
index cae9a85b0a..f1c905c982 100644
--- a/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
+++ b/content/ko/docs/setup/production-environment/tools/kubeadm/control-plane-flags.md
@@ -1,78 +1,108 @@
---
-reviewers:
-title: kubeadm으로 컨트롤 플레인 사용자 정의하기
+
+
+title: kubeadm API로 컴포넌트 사용자 정의하기
content_type: concept
weight: 40
---
+이 페이지는 kubeadm이 배포하는 컴포넌트(component)들을 사용자 정의하는 방법을 다룬다. 컨트롤 플레인 컴포넌트에
+대해서는 `ClusterConfiguration` 구조에서 플래그를 사용하거나 노드당 패치를 사용할 수 있다. kubelet과
+kube-proxy의 경우, `KubeletConfiguration`과 `KubeProxyConfiguration`을 각각 사용할 수 있다.
+
+이 모든 옵션이 kubeadm 구성 API를 통해 가용하다.
+구성의 각 필드 상세 사항은
+[API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 찾아볼 수 있다.
+
+{{< note >}}
+kubeadm의 CoreDNS 디플로이먼트 사용자 정의는 현재 제공되지 않는다.
+`kube-system/coredns` {{< glossary_tooltip text="컨피그맵" term_id="configmap" >}}을 수동으로
+패치하고, 그 이후에 CoreDNS {{< glossary_tooltip text="파드" term_id="pod" >}}를 다시 생성해야 한다. 또는,
+기본 CoreDNS 디플로이먼트를 생략하고 자체 변형(variant)을 배포할 수 있다.
+더 자세한 사항은 [kubeadm에서 초기화 단계 사용하기](/docs/reference/setup-tools/kubeadm/kubeadm-init/#init-phases)을 참고한다.
+{{< /note >}}
+
+
+
{{< feature-state for_k8s_version="v1.12" state="stable" >}}
-kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러와 같은 컨트롤 플레인 구성요소에 전달되는
-기본 플래그 `extraArgs` 필드를 노출한다. 이 구성요소는 다음 필드를 사용하도록 정의되어 있다.
+## `ClusterConfiguration`의 플래그로 컨트롤 플레인 사용자 정의하기
+
+kubeadm의 `ClusterConfiguration` 오브젝트는 API 서버, 컨트롤러매니저, 스케줄러, Etcd와 같은 컨트롤 플레인 컴포넌트에 전달되는
+기본 플래그를 사용자가 덮어쓸 수 있도록 노출한다.
+이 컴포넌트는 다음 구조체를 사용하여 정의된다.
- `apiServer`
- `controllerManager`
- `scheduler`
+- `etcd`
-`extraArgs` 필드는 `key: value` 쌍으로 구성되어 있다. 컨트롤 플레인 구성요소를 위한 플래그를 대체하려면 다음을 수행한다.
+이 구조체들은 공통 필드인 `extraArgs`를 포함하며, 이 필드는 `키: 값` 쌍으로 구성된다.
+컨트롤 플레인 컴포넌트를 위한 플래그를 덮어쓰려면 다음을 수행한다.
-1. 사용자 구성에서 적절한 필드를 추가한다.
-2. 필드에 대체할 플래그를 추가한다.
+1. 사용자 구성에 적절한 `extraArgs` 필드를 추가한다.
+2. `extraArgs` 필드에 플래그를 추가한다.
3. `kubeadm init`에 `--config ` 파라미터를 추가해서 실행한다.
-각 필드의 구성에서 자세한 정보를 보려면,
-[API 참고 문서](/docs/reference/config-api/kubeadm-config.v1beta2/)에서 확인해 볼 수 있다.
-
{{< note >}}
-`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을 저장하여 기본값인 `ClusterConfiguration` 오브젝트를 생성할 수 있다.
+`kubeadm config print init-defaults`를 실행하고 원하는 파일에 출력을
+저장하여 기본값들로 구성된 `ClusterConfiguration` 오브젝트를 생성할 수 있다.
{{< /note >}}
+{{< note >}}
+`ClusterConfiguration` 오브젝트는 현재 kubeadm 클러스터에서 전역(global)으로 사용된다. 즉, 사용자가 추가하는 모든 플래그는
+다른 노드에 있는 동일한 컴포넌트에도 모두 적용될 것이다. 다른 노드에서
+컴포넌트별로 개별 구성을 적용하려면 [패치](#patches)를 사용하면 된다.
+{{< /note >}}
+{{< note >}}
+플래그(키)를 복제하거나 동일한 플래그 `--foo`를 여러 번 전달하는 것은 현재 지원하지 않는다.
+이 문제를 해결하려면 [패치](#patches)를 사용해야 한다.
+{{< /note >}}
-
-
-## APIServer 플래그
+### APIServer 플래그
자세한 내용은 [kube-apiserver 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-apiserver/)를 확인한다.
-예시:
+사용 예시:
+
```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
apiServer:
extraArgs:
- advertise-address: 192.168.0.103
anonymous-auth: "false"
enable-admission-plugins: AlwaysPullImages,DefaultStorageClass
audit-log-path: /home/johndoe/audit.log
```
-## 컨트롤러매니저 플래그
+### 컨트롤러매니저 플래그
자세한 내용은 [kube-controller-manager 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-controller-manager/)를 확인한다.
-예시:
+사용 예시:
+
```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
controllerManager:
extraArgs:
cluster-signing-key-file: /home/johndoe/keys/ca.key
- bind-address: 0.0.0.0
deployment-controller-sync-period: "50"
```
-## 스케줄러 플래그
+### 스케줄러 플래그
자세한 내용은 [kube-scheduler 레퍼런스 문서](/docs/reference/command-line-tools-reference/kube-scheduler/)를 확인한다.
-예시:
+사용 예시:
+
```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: v1.16.0
scheduler:
@@ -85,3 +115,96 @@ scheduler:
readOnly: true
pathType: "File"
```
+
+### Etcd 플래그
+
+자세한 사항은 [etcd 서버 문서](https://etcd.io/docs/)를 확인한다.
+
+사용 예시:
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: ClusterConfiguration
+etcd:
+ local:
+ extraArgs:
+ election-timeout: 1000
+```
+
+## 패치를 통해 컨트롤 플레인 사용자 정의하기 {#patches}
+
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
+
+Kubeadm을 사용하면 패치 파일이 있는 디렉토리를 개별 노드에 대한 `InitConfiguration`과 `JoinConfiguration`에
+전달할 수 있다. 이 패치는 컨트롤 플레인 컴포넌트 메니패스트가 디스크에 기록되기 전에
+최종 사용자 정의 단계로 사용될 수 있다.
+
+`--config `을 사용하여 이 파일을 `kubeadm init`에 전달할 수 있다.
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: InitConfiguration
+nodeRegistration:
+ patches:
+ directory: /home/user/somedir
+```
+
+{{< note >}}
+`kubeadm init`의 경우, `---`로 구분된 `ClusterConfiguration`과 `InitConfiguration`을 모두
+포함하는 파일을 전달할 수 있다.
+{{< /note >}}
+
+`--config `을 사용하여 이 파일을 `kubeadm join`에 전달할 수 있다.
+
+```yaml
+apiVersion: kubeadm.k8s.io/v1beta3
+kind: JoinConfiguration
+nodeRegistration:
+ patches:
+ directory: /home/user/somedir
+```
+
+디렉토리는 `target[suffix][+patchtype].extension` 형태의 파일을 포함해야 한다.
+예를 들면, `kube-apiserver0+merge.yaml` 또는 단순히 `etcd.json`의 형태이다.
+
+- `target`은 `kube-apiserver`, `kube-controller-manager`, `kube-scheduler` 그리고 `etcd` 중 하나가 될 수 있다.
+- `patchtype`은 `strategic`, `merge` 그리고 `json` 중 하나가 될 수 있으며
+[kubectl에서 지원하는](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch) 패치 형식을 준수해야 한다.
+`patchtype`의 기본값은 `strategic`이다.
+- `extension`은 `json` 또는 `yaml` 중 하나여야 한다.
+- `suffix`는 어떤 패치가 먼저 적용되는지를 결정하는 데 사용할 수 있는 영숫자 형태의
+선택적 문자열이다.
+
+{{< note >}}
+`kubeadm upgrade`를 사용하여 kubeadm 노드를 업그레이드하는 경우, 업그레이드 이후에도
+사용자 정의를 유지하려면 동일한 패치를 다시 제공해야 한다. 이는 동일한 디렉토리로 지정된 `--patches`
+플래그를 사용하여 처리할 수 있다. `kubeadm upgrade`는 동일 목적으로 재사용할 수 있는 구성
+API 구조를 현재는 지원하지 않는다.
+{{< /note >}}
+
+## kubelet 사용자 정의하기
+
+kubelet을 사용자 정의하려면, `KubeletConfiguration`을 동일한 구성 파일 내에서 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration` 다음에 추가하면
+된다. 그런 다음 `kubeadm init`에 해당 파일을 전달한다.
+
+{{< note >}}
+kubeadm은 클러스터의 모든 노드에 동일한 `KubeletConfiguration`을 적용한다. 노드별 설정을
+적용하려면 kubelet 플래그를 덮어쓰기(overrides)로 사용하여, `InitConfiguration` 및
+`JoinConfiguration` 모두에서 지원되는 `nodeRegistration.kubeletExtraArgs`에 전달할 수 있다.
+일부 kubelet 플래그는 더 이상 사용되지 않는다(deprecated). 따라서 사용하기 전에 [kubelet 참조 문서](/docs/reference/command-line-tools-reference/kubelet)를 통해
+상태를 확인해야 한다.
+{{< /note >}}
+
+자세한 사항은 [kubeadm을 통해 클러스터의 각 kubelet 구성하기](/docs/setup/production-environment/tools/kubeadm/kubelet-integration)에서 살펴본다.
+
+## kube-proxy 사용자 정의하기
+
+kube-proxy를 사용자 정의하려면, `KubeProxyConfiguration`을 `---`로 구분된 `ClusterConfiguration`이나 `InitConfiguration`
+다음에 두고 `kubeadm init`에 전달하면 된다.
+
+자세한 사항은 [API 참조 페이지](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)에서 살펴볼 수 있다.
+
+{{< note >}}
+kubeadm은 kube-proxy를 {{< glossary_tooltip text="데몬셋" term_id="daemonset" >}}으로 배포한다. 이것은
+`KubeProxyConfiguration`이 클러스터의 모든 kube-proxy 인스턴스에 적용된다는 것을 의미한다.
+{{< /note >}}
diff --git a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
index d102f5f587..f5a960609f 100644
--- a/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
+++ b/content/ko/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md
@@ -239,8 +239,9 @@ CNI 플러그인 설치(대부분의 파드 네트워크에 필요)
```bash
CNI_VERSION="v0.8.2"
+ARCH="amd64"
sudo mkdir -p /opt/cni/bin
-curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
+curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
```
명령어 파일을 다운로드할 디렉터리 정의
@@ -259,15 +260,17 @@ crictl 설치(kubeadm / Kubelet 컨테이너 런타임 인터페이스(CRI)에
```bash
CRICTL_VERSION="v1.17.0"
-curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
+ARCH="amd64"
+curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
```
`kubeadm`, `kubelet`, `kubectl` 설치 및 `kubelet` systemd 서비스 추가
```bash
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
+ARCH="amd64"
cd $DOWNLOAD_DIR
-sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
+sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
sudo chmod +x {kubeadm,kubelet,kubectl}
RELEASE_VERSION="v0.4.0"
diff --git a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
index 67db901778..c4cc773ad9 100644
--- a/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
+++ b/content/ko/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md
@@ -67,10 +67,9 @@ weight: 65
| 쿠버네티스 버전 | 윈도우 서버 LTSC 릴리스 | 윈도우 서버 SAC 릴리스 |
| --- | --- | --- | --- |
-| *Kubernetes v1.19* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
| *Kubernetes v1.20* | Windows Server 2019 | Windows Server ver 1909, Windows Server ver 2004 |
| *Kubernetes v1.21* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |
-
+| *Kubernetes v1.22* | Windows Server 2019 | Windows Server ver 2004, Windows Server ver 20H2 |
지원 모델을 포함한 다양한 윈도우 서버
서비스 채널에 대한 정보는
@@ -98,12 +97,16 @@ weight: 65
일단 쿠버네티스에서 Hyper-V 격리가 포함된 윈도우 컨테이너를 지원하면,
제한 및 호환성 규칙이 변경될 것이다.
-#### 퍼즈(Pause) 이미지
+#### 퍼즈(Pause) 이미지 {#pause-image}
-Microsoft는 `mcr.microsoft.com/oss/kubernetes/pause:3.4.1`에서
-윈도우 퍼즈 인프라 컨테이너를 유지한다.
-이외에도 `k8s.gcr.io/pause:3.5`를 통해 쿠버네티스에서 관리하는 다중 아키텍처 이미지를
-사용할 수도 있는데, 이 이미지는 리눅스와 윈도우를 모두 지원한다.
+쿠버네티스는 윈도우 지원을 포함하는 다중 아키텍처 이미지를 유지보수한다.
+쿠버네티스 v1.22의 경우 권장 퍼즈 이미지는 `k8s.gcr.io/pause:3.5`이다.
+[소스 코드](https://github.com/kubernetes/kubernetes/tree/master/build/pause)는
+GitHub에서 찾을 수 있다.
+
+Microsoft는 리눅스, 윈도우 amd64를 지원하는 다중 아키텍처 이미지를 `mcr.microsoft.com/oss/kubernetes/pause:3.5`에서 유지보수하고 있다.
+이 이미지는 쿠버네티스가 유지 관리하는 이미지와 동일한 소스코드에서 생성되었지만, 모든 윈도우 바이너리는 Microsoft에 의해 서명된 [인증 코드](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode)이다.
+프로덕션 환경에서 서명된 바이너리가 필요한 경우, Microsoft가 유지 관리하는 이미지를 사용하는 것을 권장한다.
#### 컴퓨트
@@ -237,7 +240,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume
##### CSI 플러그인
-{{< feature-state for_k8s_version="v1.19" state="beta" >}}
+{{< feature-state for_k8s_version="v1.22" state="stable" >}}
{{< glossary_tooltip text="CSI" term_id="csi" >}} 플러그인과
관련된 코드는 일반적으로 컨테이너 이미지로 배포되고 데몬셋(DaemonSets)
@@ -246,9 +249,7 @@ powershell 스크립트로 배포된 다음의 FlexVolume
바이너리로 제공된다. CSI 플러그인은 쿠버네티스에서 볼륨 프로비저닝/디-프로비저닝, 볼륨
크기 조정, 쿠버네티스 노드에 볼륨 연결/분리, 파드의 개별 컨테이너에 볼륨
마운트/분리, 스냅샷 및 복제를 사용하여 퍼시스턴트 데이터 백업/복원과 같은
-다양한 볼륨 관리 작업을 처리한다. CSI 플러그인은
-일반적으로 (각 노드에서 데몬셋으로 실행되는) 노드 플러그인과 컨트롤러
-플러그인으로 구성된다.
+다양한 볼륨 관리 작업을 처리한다.
CSI 노드 플러그인(특히 블록 디바이스 또는 공유 파일시스템으로 노출된
퍼시스턴트 볼륨과 관련된 플러그인)은 디스크 장치 스캔, 파일 시스템 마운트 등과 같은
@@ -262,6 +263,13 @@ CSI 노드 플러그인에 대한 특권이 필요한 작업은 커뮤니티에
내용은 배포하려는 CSI 플러그인의 배포 가이드를
참조한다.
+윈도우 노드에서 CSI 노드 플러그인은 일반적으로 로컬 스토리지 작업을 처리하는
+커뮤니티에서 관리하는 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy)에 의해 노출된 API를 호출한다.
+
+설치에 대한 자세한 내용은 윈도우 CSI 플러그인을
+배포할 환경의 배포 가이드를 참고한다.
+또한 다음 [설치 단계](https://github.com/kubernetes-csi/csi-proxy#installation)를 참고할 수도 있다.
+
#### 네트워킹
윈도우 컨테이너용 네트워킹은
@@ -1068,9 +1076,8 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
kubelet.exe를 등록한다.
```powershell
- # Microsoft는 mcr.microsoft.com/oss/kubernetes/pause:1.4.1에서 pause 인프라 컨테이너를 릴리스했다.
nssm install kubelet C:\k\kubelet.exe
- nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:1.4.1 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
+ nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=k8s.gcr.io/pause:3.5 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config
nssm set kubelet AppDirectory C:\k
nssm start kubelet
```
@@ -1224,13 +1231,13 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
* 내 파드가 "Container Creating"에서 멈췄거나 계속해서 다시 시작된다.
- pause 이미지가 OS 버전과 호환되는지 확인한다.
+ 퍼즈 이미지가 OS 버전과 호환되는지 확인한다.
[지침](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources)에서는
OS와 컨테이너가 모두 버전 1803이라고 가정한다. 이후 버전의
윈도우가 있는 경우, Insider 빌드와 같이 그에 따라 이미지를
조정해야 한다. 이미지는 Microsoft의
[도커 리포지터리](https://hub.docker.com/u/microsoft/)를 참조한다.
- 그럼에도 불구하고, pause 이미지 Dockerfile과 샘플 서비스는 이미지가
+ 그럼에도 불구하고, 퍼즈 이미지 Dockerfile과 샘플 서비스는 이미지가
:latest로 태그될 것으로 예상한다.
* DNS 확인(resolution)이 제대로 작동하지 않는다.
@@ -1239,12 +1246,18 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
* `kubectl port-forward`가 "unable to do port forwarding: wincat not found"로 실패한다.
- 이는 쿠버네티스 1.15 및 pause 인프라 컨테이너
+ 이는 쿠버네티스 1.15 및 퍼즈 인프라 컨테이너
`mcr.microsoft.com/oss/kubernetes/pause:1.4.1`에서 구현되었다.
- 해당 버전 또는 최신 버전을 사용해야 한다. 자체 pause
+ 해당 버전 또는 최신 버전을 사용해야 한다. 자체 퍼즈
인프라 컨테이너를 빌드하려면
[wincat](https://github.com/kubernetes-sigs/sig-windows-tools/tree/master/cmd/wincat)을 포함해야 한다.
+ 윈도우에서 포트 포워딩을 지원하려면 [퍼즈 인프라 컨테이너](#pause-image)를 이용하기 위해서
+ wincat.exe가 필요하다.
+ 윈도우 OS 버전과 호환되는 지원되는 이미지를 사용하고 있는지 확인해야 한다.
+ 자신만의 퍼즈 인프라 컨테이너를 구축하려면
+ [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat)을 포함해야 한다.
+
* 내 윈도우 서버 노드가 프록시 뒤에 있기 때문에 내 쿠버네티스
설치가 실패한다.
@@ -1256,20 +1269,18 @@ PodSecurityContext 필드는 윈도우에서 작동하지 않는다. 참조를
[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine)
```
-* `pause` 컨테이너란 무엇인가?
+* 퍼즈(`pause`) 컨테이너란 무엇인가?
쿠버네티스 파드에서는 컨테이너 엔드포인트를 호스팅하기 위해
- 먼저 인프라 또는 "pause" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여
+ 먼저 인프라 또는 "퍼즈" 컨테이너가 생성된다. 인프라 및 워커 컨테이너를 포함하여
동일한 파드에 속하는 컨테이너는 공통 네트워크 네임스페이스 및
엔드포인트(동일한 IP 및 포트 공간)를 공유한다. 네트워크 구성을 잃지 않고
- 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 pause 컨테이너가
+ 워커 컨테이너가 충돌하거나 다시 시작되도록 하려면 퍼즈 컨테이너가
필요하다.
- "pause" (인프라) 이미지는 Microsoft Container Registry(MCR)에서
- 호스팅된다. `mcr.microsoft.com/oss/kubernetes/pause:1.4.1`을 사용하여 접근할 수 있다.
- 자세한 내용은
- [DOCKERFILE](https://github.com/kubernetes-sigs/windows-testing/blob/master/images/pause/Dockerfile)을 참고한다.
-
+ 퍼즈 이미지 추천 버전을 찾기 위해서는
+ [퍼즈 이미지](#pause-image)를 참고한다.
+
### 추가 조사
이러한 단계로 문제가 해결되지 않으면, 다음을 통해 쿠버네티스의 윈도우 노드에서
diff --git a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
index 5c3d52e475..2e1694834e 100644
--- a/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
+++ b/content/ko/docs/setup/production-environment/windows/user-guide-windows-containers.md
@@ -20,8 +20,8 @@ weight: 75
## 시작하기 전에
-* [윈도우 서버에서 운영하는 마스터와 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes)를
-포함한 쿠버네티스 클러스터를 생성한다.
+* 컨트롤 플레인과 [윈도우 서버로 운영되는 워커 노드](/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)를
+포함하는 쿠버네티스 클러스터를 생성한다.
* 쿠버네티스에서 서비스와 워크로드를 생성하고 배포하는 것은 리눅스나 윈도우 컨테이너
모두 비슷한 방식이라는 것이 중요하다.
[Kubectl 커맨드](/ko/docs/reference/kubectl/overview/)로 클러스터에 접속하는 것은 동일하다.
@@ -100,15 +100,15 @@ spec:
1. 이 디플로이먼트가 성공적인지 확인한다. 다음을 검토하자.
* 윈도우 노드에 파드당 두 컨테이너가 존재하는지 확인하려면, `docker ps`를 사용한다.
- * 리눅스 마스터에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
- * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터에서 `curl`을
+ * 리눅스 컨트롤 플레인 노드에서 나열된 두 파드가 존재하는지 확인하려면, `kubectl get pods`를 사용한다.
+ * 네트워크를 통한 노드에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드에서 `curl`을
파드 IP 주소의 80 포트로 실행하여 웹 서버 응답을 확인한다.
* 파드 간 통신이 되는지 확인하려면, `docker exec` 나 `kubectl exec`를 이용해 파드 간에
핑(ping)한다(윈도우 노드가 2대 이상이라면, 서로 다른 노드에 있는 파드 간 통신도 확인할 수 있다).
- * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 마스터와 독립 파드에서 `curl`을 가상 서비스
+ * 서비스에서 파드로의 통신이 되는지 확인하려면, 리눅스 컨트롤 플레인 노드와 독립 파드에서 `curl`을 가상 서비스
IP 주소(`kubectl get services`로 볼 수 있는)로 실행한다.
* 서비스 검색(discovery)이 되는지 확인하려면, 쿠버네티스 [기본 DNS 접미사](/ko/docs/concepts/services-networking/dns-pod-service/#서비스)와 서비스 이름으로 `curl`을 실행한다.
- * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 마스터에서 NodePort로 `curl`을 실행한다.
+ * 인바운드 연결이 되는지 확인하려면, 클러스터 외부 장비나 리눅스 컨트롤 플레인 노드에서 NodePort로 `curl`을 실행한다.
* 아웃바운드 연결이 되는지 확인하려면, `kubectl exec`를 이용해서 파드에서 외부 IP 주소로 `curl`을 실행한다.
{{< note >}}
@@ -178,8 +178,8 @@ GMSA로 구성한 컨테이너는 GMSA로 구성된 신원을 들고 있는 동
예를 들면, `--register-with-taints='os=windows:NoSchedule'`
모든 윈도우 노드에 테인트를 추가하여 아무 것도 거기에 스케줄링하지 않게 될 것이다(존재하는 리눅스 파드를 포함하여).
-윈도우 파드가 윈도우 노드에 스케줄링되려면,
-윈도우를 선택하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
+윈도우 파드가 윈도우 노드에 스케줄링되도록 하려면,
+윈도우 노드가 선택되도록 하기 위한 노드 셀렉터 및 적합하게 일치하는 톨러레이션이 모두 필요하다.
```yaml
nodeSelector:
diff --git a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
index 333001af81..6aa257dca4 100644
--- a/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
+++ b/content/ko/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md
@@ -31,7 +31,7 @@ min-kubernetes-server-version: v1.10
1. MongoDB를 실행하기 위해 디플로이먼트를 생성한다.
```shell
- kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
+ kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
```
성공적인 명령어의 출력은 디플로이먼트가 생성됐다는 것을 확인해준다.
@@ -84,7 +84,7 @@ min-kubernetes-server-version: v1.10
2. MongoDB를 네트워크에 노출시키기 위해 서비스를 생성한다.
```shell
- kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
+ kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
```
성공적인 커맨드의 출력은 서비스가 생성되었다는 것을 확인해준다.
diff --git a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md
index 2d44a51b0e..41b2225549 100644
--- a/content/ko/docs/tasks/administer-cluster/access-cluster-api.md
+++ b/content/ko/docs/tasks/administer-cluster/access-cluster-api.md
@@ -30,7 +30,7 @@ content_type: task
kubectl config view
```
-많은 [예제](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/)는 kubectl 사용에 대한 소개를
+많은 [예제](https://github.com/kubernetes/examples/tree/master/)는 kubectl 사용에 대한 소개를
제공한다. 전체 문서는 [kubectl 매뉴얼](/ko/docs/reference/kubectl/overview/)에 있다.
### REST API에 직접 접근
diff --git a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
index f681bc8778..8d67bea2db 100644
--- a/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
+++ b/content/ko/docs/tasks/administer-cluster/dns-custom-nameservers.md
@@ -23,7 +23,7 @@ DNS 변환(DNS resolution) 절차를 사용자 정의하는 방법을 설명한
## 소개
-DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/README.md)을
+DNS는 _애드온 관리자_ 인 [클러스터 애드온](https://releases.k8s.io/master/cluster/addons/README.md)을
사용하여 자동으로 시작되는 쿠버네티스
내장 서비스이다.
diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
index e67a08a74e..e7a1b8fb79 100644
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
@@ -153,14 +153,14 @@ Install-WindowsFeature -Name containers
```
도커 설치
-자세한 내용은 [도커 엔진 설치 - 윈도우 서버 엔터프라이즈](https://hub.docker.com/editions/enterprise/docker-ee-server-windows)에서 확인할 수 있다.
+자세한 내용은 [도커 엔진 설치 - 윈도우 서버 엔터프라이즈](https://docs.microsoft.com/ko-kr/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker)에서 확인할 수 있다.
#### wins, kubelet 및 kubeadm 설치
- ```PowerShell
- curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
- .\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
- ```
+```PowerShell
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
+.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}}
+```
#### `kubeadm` 실행하여 노드에 조인
@@ -201,7 +201,7 @@ curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/lates
#### wins, kubelet 및 kubeadm 설치
```PowerShell
-curl.exe -LO https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/PrepareNode.ps1
+curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1
.\PrepareNode.ps1 -KubernetesVersion {{< param "fullversion" >}} -ContainerRuntime containerD
```
diff --git a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
index de6feb480d..fe34d7a7f7 100644
--- a/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
+++ b/content/ko/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md
@@ -126,7 +126,17 @@ kubeadm 1.17 이전 버전에는 `kubeadm upgrade node` 명령에서
`kubeadm certs renew` 명령을 사용하여 언제든지 인증서를 수동으로 갱신할 수 있다.
-이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
+이 명령은 `/etc/kubernetes/pki` 에 저장된 CA(또는 프론트 프록시 CA) 인증서와 키를 사용하여 갱신을 수행한다.
+
+명령을 실행한 후에는 컨트롤 플레인 파드를 재시작해야 한다.
+이는 현재 일부 구성 요소 및 인증서에 대해 인증서를 동적으로 다시 로드하는 것이 지원되지 않기 때문이다.
+[스태틱(static) 파드](/ko/docs/tasks/configure-pod-container/static-pod/)는 API 서버가 아닌 로컬 kubelet에서 관리되므로
+kubectl을 사용하여 삭제 및 재시작할 수 없다.
+스태틱 파드를 다시 시작하려면 `/etc/kubernetes/manifests/`에서 매니페스트 파일을 일시적으로 제거하고
+20초를 기다리면 된다 ([KubeletConfiguration struct](/docs/reference/config-api/kubelet-config.v1beta1/)의 `fileCheckFrequency` 값을 참고한다).
+파드가 매니페스트 디렉터리에 더 이상 없는 경우 kubelet은 파드를 종료한다.
+그런 다음 파일을 다시 이동할 수 있으며 또 다른 `fileCheckFrequency` 기간이 지나면,
+kubelet은 파드를 생성하고 구성 요소에 대한 인증서 갱신을 완료할 수 있다.
{{< warning >}}
HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서 이 명령을 실행해야 한다.
@@ -161,10 +171,10 @@ HA 클러스터를 실행 중인 경우, 모든 컨트롤 플레인 노드에서
빌트인 서명자를 활성화하려면, `--cluster-signing-cert-file` 와 `--cluster-signing-key-file` 플래그를 전달해야 한다.
-새 클러스터를 생성하는 경우, kubeadm [구성 파일](/docs/reference/config-api/kubeadm-config.v1beta2/)을 사용할 수 있다.
+새 클러스터를 생성하는 경우, kubeadm [구성 파일](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3)을 사용할 수 있다.
```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
controllerManager:
extraArgs:
@@ -223,7 +233,7 @@ TLS로 보안되지 않음을 의미한다.
다음의 최소 구성을 `kubeadm init` 에 전달해야 한다.
```yaml
-apiVersion: kubeadm.k8s.io/v1beta2
+apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
---
apiVersion: kubelet.config.k8s.io/v1beta1
diff --git a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
index eb953143be..4a6a769556 100644
--- a/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
+++ b/content/ko/docs/tasks/administer-cluster/network-policy-provider/cilium-network-policy.md
@@ -22,44 +22,59 @@ weight: 20
실리움에 쉽게 친숙해지기 위해
Minikube에 실리움을 기본적인 데몬셋으로 설치를 수행하는
-[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/minikube/)를 따라 해볼 수 있다.
+[실리움 쿠버네티스 시작하기 안내](https://docs.cilium.io/en/stable/gettingstarted/k8s-install-default/)를 따라 해볼 수 있다.
-Minikube를 시작하려면 최소 버전으로 >= v1.3.1 이 필요하고,
+Minikube를 시작하려면 최소 버전으로 >= v1.5.2 이 필요하고,
다음의 실행 파라미터로 실행한다.
```shell
minikube version
```
```
-minikube version: v1.3.1
+minikube version: v1.5.2
```
```shell
-minikube start --network-plugin=cni --memory=4096
+minikube start --network-plugin=cni
```
-BPF 파일시스템을 마운트한다
+minikube의 경우 CLI 도구를 사용하여 실리움을 설치할 수 있다.
+실리움은 클러스터 구성을 자동으로 감지하고
+성공적인 설치를 위해 적절한 구성 요소를 설치한다.
```shell
-minikube ssh -- sudo mount bpffs -t bpf /sys/fs/bpf
+curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz
+sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
+rm cilium-linux-amd64.tar.gz
+cilium install
```
-Minikube에서 실리움의 데몬셋 구성과 적절한 RBAC 설정을 포함하는 필요한 구성을
-간단한 ``올인원`` YAML 파일로 배포할 수 있다.
-
```shell
-kubectl create -f https://raw.githubusercontent.com/cilium/cilium/v1.8/install/kubernetes/quick-install.yaml
-```
-```
-configmap/cilium-config created
-serviceaccount/cilium created
-serviceaccount/cilium-operator created
-clusterrole.rbac.authorization.k8s.io/cilium created
-clusterrole.rbac.authorization.k8s.io/cilium-operator created
-clusterrolebinding.rbac.authorization.k8s.io/cilium created
-clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
-daemonset.apps/cilium create
-deployment.apps/cilium-operator created
+🔮 Auto-detected Kubernetes kind: minikube
+✨ Running "minikube" validation checks
+✅ Detected minikube version "1.20.0"
+ℹ️ Cilium version not set, using default version "v1.10.0"
+🔮 Auto-detected cluster name: minikube
+🔮 Auto-detected IPAM mode: cluster-pool
+🔮 Auto-detected datapath mode: tunnel
+🔑 Generating CA...
+2021/05/27 02:54:44 [INFO] generate received request
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 48713764918856674401136471229482703021230538642
+🔑 Generating certificates for Hubble...
+2021/05/27 02:54:44 [INFO] generate received request
+2021/05/27 02:54:44 [INFO] received CSR
+2021/05/27 02:54:44 [INFO] generating key: ecdsa-256
+2021/05/27 02:54:44 [INFO] encoded CSR
+2021/05/27 02:54:44 [INFO] signed certificate with serial number 3514109734025784310086389188421560613333279574
+🚀 Creating Service accounts...
+🚀 Creating Cluster roles...
+🚀 Creating ConfigMap...
+🚀 Creating Agent DaemonSet...
+🚀 Creating Operator Deployment...
+⌛ Waiting for Cilium to be installed...
```
시작하기 안내서의 나머지 부분은 예제 애플리케이션을 이용하여
@@ -82,14 +97,14 @@ L3/L4(예, IP 주소 + 포트) 모두의 보안 정책뿐만 아니라 L7(예, H
파드의 목록을 보려면 다음을 실행한다.
```shell
-kubectl get pods --namespace=kube-system
+kubectl get pods --namespace=kube-system -l k8s-app=cilium
```
다음과 유사한 파드의 목록을 볼 것이다.
```console
-NAME READY STATUS RESTARTS AGE
-cilium-6rxbd 1/1 Running 0 1m
+NAME READY STATUS RESTARTS AGE
+cilium-kkdhz 1/1 Running 0 3m23s
...
```
diff --git a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
index 8b3f62217e..7a5e502c47 100644
--- a/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
+++ b/content/ko/docs/tasks/configmap-secret/managing-secret-using-kubectl.md
@@ -67,7 +67,7 @@ kubectl create secret generic db-user-pass \
다음 커맨드를 실행한다.
```shell
-kubectl create secret generic dev-db-secret \
+kubectl create secret generic db-user-pass \
--from-literal=username=devuser \
--from-literal=password='S!B\*d$zDsb='
```
diff --git a/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md
new file mode 100644
index 0000000000..0145967dd8
--- /dev/null
+++ b/content/ko/docs/tasks/debug-application-cluster/debug-running-pod.md
@@ -0,0 +1,340 @@
+---
+
+
+
+title: 동작 중인 파드 디버그
+content_type: task
+---
+
+
+
+이 페이지는 노드에서 동작 중인(혹은 크래시된) 파드를 디버그하는 방법에 대해 설명한다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+* 여러분의 {{< glossary_tooltip text="파드" term_id="pod" >}}는 이미 스케줄링 되어
+ 동작하고 있을 것이다. 만약 파드가 아직 동작중이지 않다면, [애플리케이션
+ 트러블슈팅](/docs/tasks/debug-application-cluster/debug-application/)을 참고한다.
+* 일부 고급 디버깅 과정에서는 해당 파드가 어떤 노드에서 동작하고 있는지
+ 알아야 하고, 해당 노드에서 쉘 명령어를 실행시킬 수 있어야 한다.
+ `kubectl`을 사용하는 일반적인 디버깅 과정에서는 이러한 접근 권한이 필요하지 않다.
+
+
+
+
+
+## 파드의 로그 확인하기 {#examine-pod-logs}
+
+먼저, 확인하고자 하는 컨테이너의 로그를 확인한다.
+
+```shell
+kubectl logs ${POD_NAME} ${CONTAINER_NAME}
+```
+
+만약 컨테이너가 이전에 크래시 되었다면, 다음의 명령을 통해 컨테이너의 크래시 로그를 살펴볼 수 있다.
+
+```shell
+kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
+```
+
+## exec를 통해 컨테이너 디버깅하기 {#container-exec}
+
+만약 {{< glossary_tooltip text="컨테이너 이미지" term_id="image" >}}에
+디버깅 도구가 포함되어 있다면, `kubectl exec`을 통해 특정 컨테이너에서 해당 명령들을
+실행할 수 있다. (리눅스나 윈도우 OS를 기반으로 만들어진 이미지에는 대부분 디버깅 도구를 포함하고
+있다.)
+
+```shell
+kubectl exec ${POD_NAME} -c ${CONTAINER_NAME} -- ${CMD} ${ARG1} ${ARG2} ... ${ARGN}
+```
+
+{{< note >}}
+`-c ${CONTAINER_NAME}` 인자는 선택적이다. 만약 하나의 컨테이너만 포함된 파드라면 해당 옵션을 생략할 수 있다.
+{{< /note >}}
+
+예를 들어, 동작 중인 카산드라 파드의 로그를 살펴보기 위해서는 다음과 같은 명령을 실행할 수 있다.
+
+```shell
+kubectl exec cassandra -- cat /var/log/cassandra/system.log
+```
+
+`kubectl exec`에 `-i`와 `-t` 옵션을 사용해서 터미널에서 접근할 수 있는 쉘을 실행시킬 수도 있다.
+예를 들면 다음과 같다.
+
+```shell
+kubectl exec -it cassandra -- sh
+```
+
+더욱 상세한 내용은 다음 [동작중인 컨테이너의 쉘에 접근하기](
+/docs/tasks/debug-application-cluster/get-shell-running-container/)를 참고하라.
+
+## 임시(ephemeral) 디버그 컨테이너를 사용해서 디버깅하기 {#ephemeral-container}
+
+{{< feature-state state="alpha" for_k8s_version="v1.18" >}}
+
+컨테이너가 크래시 됐거나 [distroless 이미지](https://github.com/GoogleContainerTools/distroless)처럼
+컨테이너 이미지에 디버깅 도구를 포함하고 있지 않아
+`kubectl exec`가 충분하지 않을 경우에는
+{{< glossary_tooltip text="임시(Ephemeral) 컨테이너" term_id="ephemeral-container" >}}를 사용하는 것이
+인터랙티브한 트러블슈팅에 유용하다. `kubectl` `v1.18`
+버전부터는 임시 컨테이너를 생성할 수 있는 알파 단계의
+명령어가 있다.
+
+### 임시 컨테이너를 사용한 디버깅 예시 {#ephemeral-container-example}
+
+{{< note >}}
+이 섹션에서 소개하는 예시를 사용하기 위해서는
+여러분의 클러스터에 `EphemeralContainers` [기능 게이트](/docs/reference/command-line-tools-reference/feature-gates/)가
+활성화되어 있어야 하고 `kubectl`의 버전이 v1.18 이상이어야 한다.
+{{< /note >}}
+
+`kubectl debug` 명령어를 사용해서 동작 중인 파드에 임시 컨테이너를 추가할 수 있다.
+먼저, 다음과 같이 파드를 추가한다.
+
+```shell
+kubectl run ephemeral-demo --image=k8s.gcr.io/pause:3.1 --restart=Never
+```
+
+이 섹션의 예시에서는 디버깅 도구가 포함되지 않은 이미지의 사례를 보여드리기 위해
+`pause` 컨테이너 이미지를 사용했는데, 이 대신 어떠한 이미지를 사용해도
+될 것이다.
+
+만약 `kubectl exec`을 통해 쉘을 생성하려 한다면 다음과 같은 에러를
+확인할 수 있을 텐데, 그 이유는 이 이미지에 쉘이 존재하지 않기 때문이다.
+
+```shell
+kubectl exec -it ephemeral-demo -- sh
+```
+
+```
+OCI runtime exec failed: exec failed: container_linux.go:346: starting container process caused "exec: \"sh\": executable file not found in $PATH": unknown
+```
+
+이 명령어 대신 `kubectl debug`을 사용해서 디버깅 컨테이너를 생성할 수 있다.
+만약 `-i`/`--interactive` 인자를 사용한다면, `kubectl`은 임시
+컨테이너의 콘솔에 자동으로 연결할 것이다.
+
+```shell
+kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
+```
+
+```
+Defaulting debug container name to debugger-8xzrl.
+If you don't see a command prompt, try pressing enter.
+/ #
+```
+
+이 명령어는 새로운 busybox 컨테이너를 추가하고 해당 컨테이너로 연결한다. `--target`
+파라미터를 사용하면 다른 컨테이너의 프로세스 네임스페이스를 대상으로 하게 된다. 여기서는
+이 옵션이 꼭 필요한데, `kubectl run`이 생성하는 파드에 대해
+[프로세스 네임스페이스 공유](/docs/tasks/configure-pod-container/share-process-namespace/)를
+활성화하지 않기 때문이다.
+
+{{< note >}}
+`--target` 파라미터는 사용 중인 {{< glossary_tooltip text="컨테이너 런타임" term_id="container-runtime" >}}에서
+지원해야지만 사용할 수 있다. 만일 지원되지 않는다면,
+임시 컨테이너가 시작되지 않을 수 있거나 독립적인 프로세스
+네임스페이스를 가지고 시작될 수 있다.
+{{< /note >}}
+
+`kubectl describe` 명령을 사용하면 새롭게 생성된 임시 컨테이너의 상태를 확인할 수 있다.
+
+```shell
+kubectl describe pod ephemeral-demo
+```
+
+```
+...
+Ephemeral Containers:
+ debugger-8xzrl:
+ Container ID: docker://b888f9adfd15bd5739fefaa39e1df4dd3c617b9902082b1cfdc29c4028ffb2eb
+ Image: busybox
+ Image ID: docker-pullable://busybox@sha256:1828edd60c5efd34b2bf5dd3282ec0cc04d47b2ff9caa0b6d4f07a21d1c08084
+ Port:
+ Host Port:
+ State: Running
+ Started: Wed, 12 Feb 2020 14:25:42 +0100
+ Ready: False
+ Restart Count: 0
+ Environment:
+ Mounts:
+...
+```
+
+디버깅이 다 끝나면 `kubectl delete`을 통해 파드를 제거할 수 있다.
+
+```shell
+kubectl delete pod ephemeral-demo
+```
+
+## 파드의 복제본을 이용해서 디버깅하기
+
+때때로 파드의 설정 옵션에 따라 특정 상황에서 트러블슈팅을 하기가 어려울 수 있다.
+예를 들어, 만일 여러분의 컨테이너 이미지가 쉘을 포함하고 있지 않거나, 여러분의
+애플리케이션이 컨테이너 시작에서 크래시가 발생한다면 `kubectl exec`을 이용해서
+컨테이너를 트러블슈팅할 수 없을 수 있다. 이러한 상황에서는 `kubectl debug`을 사용해서
+파드의 복제본을 디버깅을 위한 추가적인 설정 옵션과 함께 생성할 수 있다.
+
+### 새 컨테이너와 함께 파드의 복제본 생성하기
+
+만일 여러분의 애플리케이션이 동작은 하고 있지만 예상과는 다르게 동작하는 경우,
+파드의 복제본에 새로운 컨테이너를 추가함으로써 추가적인 트러블슈팅 도구들을
+파드에 함께 추가할 수 있다.
+
+가령, 여러분의 애플리케이션 컨테이너 이미지는 `busybox`를 기반으로 하고 있는데
+여러분은 `busybox`에는 없는 디버깅 도구를 필요로 한다고 가정해 보자. 이러한
+시나리오는 `kubectl run` 명령을 통해 시뮬레이션 해볼 수 있다.
+
+```shell
+kubectl run myapp --image=busybox --restart=Never -- sleep 1d
+```
+
+다음의 명령을 실행시켜 디버깅을 위한 새로운 우분투 컨테이너와 함께 `myapp-debug`이란
+이름의 `myapp` 컨테이너 복제본을 생성할 수 있다.
+
+```shell
+kubectl debug myapp -it --image=ubuntu --share-processes --copy-to=myapp-debug
+```
+
+```
+Defaulting debug container name to debugger-w7xmf.
+If you don't see a command prompt, try pressing enter.
+root@myapp-debug:/#
+```
+
+{{< note >}}
+* 만일 여러분이 새로 생성되는 컨테이너의 이름을 `--container` 플래그와 함께 지정하지 않는다면,
+ `kubectl debug`는 자동으로 새로운 컨테이너 이름을 생성한다.
+* `-i` 플래그를 사용하면 `kubectl debug` 명령이 새로운 컨테이너에 기본적으로 연결되게 된다.
+ 이러한 동작은 `--attach=false`을 지정하여 방지할 수 있다. 만일 여러분의 세션이
+ 연결이 끊어진다면 `kubectl attach`를 사용해서 다시 연결할 수 있다.
+* `--share-processes` 옵션은 이 파드에 있는 컨테이너가 해당 파드에 속한 다른 컨테이너의
+ 프로세스를 볼 수 있도록 한다. 이 옵션이 어떻게 동작하는지에 대해 더 알아보기 위해서는
+ 다음의 [파드의 컨테이너 간 프로세스 네임스페이스 공유](
+ /docs/tasks/configure-pod-container/share-process-namespace/)를 참고하라.
+{{< /note >}}
+
+사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
+
+```shell
+kubectl delete pod myapp myapp-debug
+```
+
+### 명령어를 변경하며 파드의 복제본 생성하기
+
+때때로 컨테이너의 명령어를 변경하는 것이 유용한 경우가 있는데, 예를 들면 디버그 플래그를 추가하기
+위해서나 애플리케이션이 크래시 되는 경우이다.
+
+다음의 `kubectl run` 명령을 통해 즉각적으로 크래시가 발생하는 애플리케이션의
+사례를 시뮬레이션해 볼 수 있다.
+
+```
+kubectl run --image=busybox myapp -- false
+```
+
+`kubectl describe pod myapp` 명령을 통해 이 컨테이너에 크래시가 발생하고 있음을 확인할 수 있다.
+
+```
+Containers:
+ myapp:
+ Image: busybox
+ ...
+ Args:
+ false
+ State: Waiting
+ Reason: CrashLoopBackOff
+ Last State: Terminated
+ Reason: Error
+ Exit Code: 1
+```
+
+이러한 경우에 `kubectl debug`을 통해 명령어를 지정함으로써 해당 파드의
+복제본을 인터랙티브 쉘로 생성할 수 있다.
+
+```
+kubectl debug myapp -it --copy-to=myapp-debug --container=myapp -- sh
+```
+
+```
+If you don't see a command prompt, try pressing enter.
+/ #
+```
+
+이제 인터랙티브 쉘에 접근할 수 있으니 파일 시스템 경로를 확인하거나
+동작 중인 컨테이너의 명령어를 직접 확인하는 등의 작업이 가능하다.
+
+{{< note >}}
+* 특정 컨테이너의 명령어를 변경하기 위해서는 `--container` 옵션을 통해 해당 컨테이너의
+ 이름을 지정해야만 한다. 이름을 지정하지 않는다면 `kubectl debug`은 이전에 지정한 명령어를
+ 그대로 사용해서 컨테이너를 생성할 것이다.
+* 기본적으로 `-i` 플래그는 `kubectl debug` 명령이 컨테이너에 바로 연결되도록 한다.
+ 이러한 동작을 방지하기 위해서는 `--attach=false` 옵션을 지정할 수 있다. 만약 여러분이 세션이
+ 종료된다면 `kubectl attach` 명령을 통해 다시 연결할 수 있다.
+{{< /note >}}
+
+사용이 모두 끝나면, 디버깅에 사용된 파드들을 잊지 말고 정리한다.
+
+```shell
+kubectl delete pod myapp myapp-debug
+```
+
+### 컨테이너 이미지를 변경하며 파드의 복제본 생성하기
+
+특정한 경우에 여러분은 제대로 동작하지 않는 파드의 이미지를
+기존 프로덕션 컨테이너 이미지에서 디버깅 빌드나 추가적인 도구를 포함한
+이미지로 변경하고 싶을 수 있다.
+
+이 사례를 보여주기 위해 `kubectl run` 명령을 통해 파드를 생성하였다.
+
+```
+kubectl run myapp --image=busybox --restart=Never -- sleep 1d
+```
+
+여기서는 `kubectl debug` 명령을 통해 해당 컨테이너 이미지를 `ubuntu`로 변경하며
+복제본을 생성하였다.
+
+```
+kubectl debug myapp --copy-to=myapp-debug --set-image=*=ubuntu
+```
+
+`--set-image`의 문법은 `kubectl set image`와 동일하게 `container_name=image`
+형식의 문법을 사용한다. `*=ubuntu`라는 의미는 모든 컨테이너의 이미지를 `ubuntu`로
+변경하겠다는 의미이다.
+
+사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
+
+```shell
+kubectl delete pod myapp myapp-debug
+```
+
+## 노드의 쉘을 사용해서 디버깅하기 {#node-shell-session}
+
+만약 위의 어떠한 방법도 사용할 수 없다면, 파드가 현재 동작 중인 노드를 찾아
+호스트의 네임스페이스로 동작하는 특권 파드를 생성할 수 있다.
+다음 `kubectl debug` 명령을 통해 해당 노드에서 인터랙티브한 쉘을 생성할 수 있다.
+
+```shell
+kubectl debug node/mynode -it --image=ubuntu
+```
+
+```
+Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode.
+If you don't see a command prompt, try pressing enter.
+root@ek8s:/#
+```
+
+노드에서 디버깅 세션을 생성할 때 유의해야 할 점은 다음과 같다.
+
+* `kubectl debug`는 노드의 이름에 기반해 새로운 파드의 이름을
+ 자동으로 생성한다.
+* 컨테이너는 호스트 네임스페이스(IPC, 네트워크, PID 네임스페이스)에서 동작한다.
+* 노드의 루트 파일시스템은 `/host`에 마운트된다.
+
+사용이 모두 끝나면, 디버깅에 사용된 파드를 잊지 말고 정리한다.
+
+```shell
+kubectl delete pod node-debugger-mynode-pdx84
+```
diff --git a/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
new file mode 100644
index 0000000000..34a91a600c
--- /dev/null
+++ b/content/ko/docs/tasks/inject-data-application/define-interdependent-environment-variables.md
@@ -0,0 +1,77 @@
+---
+title: 종속 환경 변수 정의하기
+content_type: task
+weight: 20
+---
+
+
+
+본 페이지는 쿠버네티스 파드의 컨테이너를 위한 종속 환경 변수를
+정의하는 방법에 대해 설명한다.
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+
+
+
+## 컨테이너를 위한 종속 환경 변수 정의하기
+
+파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 종속 환경 변수를 설정할 수 있다.
+종속 환경 변수를 설정하려면, 구성 파일에서 `env`의 `value`에 $(VAR_NAME)을 사용한다.
+
+이 예제에서, 한 개의 컨테이너를 실행하는 파드를 생성한다. 파드를 위한 구성 파일은 일반적인 방식으로 정의된 종속 환경 변수를 정의한다. 다음은 파드를 위한 구성 매니페스트 예시이다.
+
+{{< codenew file="pods/inject/dependent-envars.yaml" >}}
+
+1. YAML 구성 파일을 활용해 파드를 생성한다.
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/dependent-envars.yaml
+ ```
+ ```
+ pod/dependent-envars-demo created
+ ```
+
+2. 실행 중인 파드의 목록을 조회한다.
+
+ ```shell
+ kubectl get pods dependent-envars-demo
+ ```
+ ```
+ NAME READY STATUS RESTARTS AGE
+ dependent-envars-demo 1/1 Running 0 9s
+ ```
+
+3. 파드 안에서 동작 중인 컨테이너의 로그를 확인한다.
+
+ ```shell
+ kubectl logs pod/dependent-envars-demo
+ ```
+ ```
+
+ UNCHANGED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+ SERVICE_ADDRESS=https://172.17.0.1:80
+ ESCAPED_REFERENCE=$(PROTOCOL)://172.17.0.1:80
+ ```
+
+위에서 보듯이, `SERVICE_ADDRESS`는 올바른 종속성 참조, `UNCHANGED_REFERENCE`는 잘못된 종속성 참조를 정의했으며 `ESCAPED_REFERENCE`는 종속성 참조를 건너뛴다.
+
+환경 변수가 참조될 때 해당 환경 변수가 미리 정의되어 있으면 `SERVICE_ADDRESS`의 경우와 같이 참조를 올바르게 해석할 수 있다.
+
+환경 변수가 정의되지 않았거나 일부 변수만 포함된 경우, 정의되지 않은 환경 변수는 `UNCHANGED_REFERENCE`의 경우와 같이 일반 문자열로 처리된다.
+일반적으로 환경 변수 해석에 실패하더라도 컨테이너의 시작을 막지는 않는다.
+
+`$(VAR_NAME)` 구문은 이중 $로 이스케이프될 수 있다. (예: `$$(VAR_NAME)`)
+이스케이프된 참조는 참조된 변수가 정의되었는지 여부에 관계없이 해석을 수행하지 않는다.
+이는 위의 `ESCAPED_REFERENCE`를 통해 확인할 수 있다.
+
+## {{% heading "whatsnext" %}}
+
+
+* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/)에 대해 알아본다.
+* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)를 확인한다.
+
diff --git a/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md
new file mode 100644
index 0000000000..0ff081f99a
--- /dev/null
+++ b/content/ko/docs/tasks/inject-data-application/distribute-credentials-secure.md
@@ -0,0 +1,256 @@
+---
+title: 시크릿(Secret)을 사용하여 안전하게 자격증명 배포하기
+content_type: task
+weight: 50
+min-kubernetes-server-version: v1.6
+---
+
+
+본 페이지는 암호 및 암호화 키와 같은 민감한 데이터를 파드에 안전하게
+주입하는 방법을 설명한다.
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}}
+
+### 시크릿 데이터를 base-64 표현으로 변환하기
+
+사용자 이름 `my-app`과 비밀번호 `39528$vdg7Jb`의 두 가지 시크릿 데이터가 필요하다고 가정한다.
+먼저 base64 인코딩 도구를 사용하여 사용자 이름과 암호를 base64 표현으로 변환한다. 다음은 일반적으로 사용 가능한 base64 프로그램을 사용하는 예제이다.
+
+```shell
+echo -n 'my-app' | base64
+echo -n '39528$vdg7Jb' | base64
+```
+
+사용자 이름의 base-64 표현이 `bXktYXBw`이고 암호의 base-64 표현이 `Mzk1MjgkdmRnN0pi`임을
+출력을 통해 확인할 수 있다.
+
+{{< caution >}}
+사용자의 OS가 신뢰하는 로컬 툴을 사용하여 외부 툴의 보안 위험을 줄이자.
+{{< /caution >}}
+
+
+
+## 시크릿 생성하기
+
+다음은 사용자 이름과 암호가 들어 있는 시크릿을 생성하는 데 사용할 수 있는
+구성 파일이다.
+
+{{< codenew file="pods/inject/secret.yaml" >}}
+
+1. 시크릿을 생성한다.
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/secret.yaml
+ ```
+
+2. 시크릿에 대한 정보를 확인한다.
+
+ ```shell
+ kubectl get secret test-secret
+ ```
+
+ Output:
+
+ ```
+ NAME TYPE DATA AGE
+ test-secret Opaque 2 1m
+ ```
+
+3. 시크릿에 대한 자세한 정보를 확인한다.
+
+ ```shell
+ kubectl describe secret test-secret
+ ```
+
+ Output:
+
+ ```
+ Name: test-secret
+ Namespace: default
+ Labels:
+ Annotations:
+
+ Type: Opaque
+
+ Data
+ ====
+ password: 13 bytes
+ username: 7 bytes
+ ```
+
+### kubectl로 직접 시크릿 생성하기
+
+Base64 인코딩 단계를 건너뛰려면 `kubectl create secret` 명령을 사용하여
+동일한 Secret을 생성할 수 있다. 다음은 예시이다.
+
+```shell
+kubectl create secret generic test-secret --from-literal='username=my-app' --from-literal='password=39528$vdg7Jb'
+```
+
+이와 같이 더 편리하게 사용할 수 있다. 앞에서 설명한 자세한 접근 방식은 각 단계를
+명시적으로 실행하여 현재 상황을 확인할 수 있다.
+
+
+## 볼륨을 통해 시크릿 데이터에 접근할 수 있는 파드 생성하기
+
+다음은 파드를 생성하는 데 사용할 수 있는 구성 파일이다.
+
+{{< codenew file="pods/inject/secret-pod.yaml" >}}
+
+1. 파드를 생성한다.
+
+ ```shell
+ kubectl apply -f https://k8s.io/examples/pods/inject/secret-pod.yaml
+ ```
+
+2. 파드가 실행중인지 확인한다.
+
+ ```shell
+ kubectl get pod secret-test-pod
+ ```
+
+ Output:
+ ```
+ NAME READY STATUS RESTARTS AGE
+ secret-test-pod 1/1 Running 0 42m
+ ```
+
+3. 파드에서 실행 중인 컨테이너의 셸을 가져오자.
+ ```shell
+ kubectl exec -i -t secret-test-pod -- /bin/bash
+ ```
+
+4. 시크릿 데이터는 `/etc/secret-volume`에 마운트된 볼륨을 통해
+컨테이너에 노출된다.
+
+ 셸에서 `/etc/secret-volume` 디렉터리의 파일을 나열한다.
+ ```shell
+ # 컨테이너 내부의 셸에서 실행하자
+ ls /etc/secret-volume
+ ```
+ 두 개의 파일과 각 파일의 시크릿 데이터 조각을 확인할 수 있다.
+ ```
+ password username
+ ```
+
+5. 셸에서 `username` 및 `password` 파일의 내용을 출력한다.
+ ```shell
+ # 컨테이너 내부의 셸에서 실행하자
+ echo "$( cat /etc/secret-volume/username )"
+ echo "$( cat /etc/secret-volume/password )"
+ ```
+ 사용자 이름과 비밀번호가 출력된다.
+ ```
+ my-app
+ 39528$vdg7Jb
+ ```
+
+## 시크릿 데이터를 사용하여 컨테이너 환경 변수 정의하기
+
+### 단일 시크릿 데이터로 컨테이너 환경 변수 정의하기
+
+* 환경 변수를 시크릿의 키-값 쌍으로 정의한다.
+
+ ```shell
+ kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
+ ```
+
+* 시크릿에 정의된 `backend-username` 값을 파드 명세의 `SECRET_USERNAME` 환경 변수에 할당한다.
+
+ {{< codenew file="pods/inject/pod-single-secret-env-variable.yaml" >}}
+
+* 파드를 생성한다.
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-single-secret-env-variable.yaml
+ ```
+
+* 셸에서 `SECRET_USERNAME` 컨테이너 환경 변수의 내용을 출력한다.
+
+ ```shell
+ kubectl exec -i -t env-single-secret -- /bin/sh -c 'echo $SECRET_USERNAME'
+ ```
+
+ 출력은 다음과 같다.
+ ```
+ backend-admin
+ ```
+
+### 여러 시크릿 데이터로 컨테이너 환경 변수 정의하기
+
+* 이전 예제와 마찬가지로 시크릿을 먼저 생성한다.
+
+ ```shell
+ kubectl create secret generic backend-user --from-literal=backend-username='backend-admin'
+ kubectl create secret generic db-user --from-literal=db-username='db-admin'
+ ```
+
+* 파드 명세에 환경 변수를 정의한다.
+
+ {{< codenew file="pods/inject/pod-multiple-secret-env-variable.yaml" >}}
+
+* 파드를 생성한다.
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-multiple-secret-env-variable.yaml
+ ```
+
+* 셸에서 컨테이너 환경 변수를 출력한다.
+
+ ```shell
+ kubectl exec -i -t envvars-multiple-secrets -- /bin/sh -c 'env | grep _USERNAME'
+ ```
+ 출력은 다음과 같다.
+ ```
+ DB_USERNAME=db-admin
+ BACKEND_USERNAME=backend-admin
+ ```
+
+
+## 시크릿의 모든 키-값 쌍을 컨테이너 환경 변수로 구성하기
+
+{{< note >}}
+이 기능은 쿠버네티스 v1.6 이상에서 사용할 수 있다.
+{{< /note >}}
+
+* 여러 키-값 쌍을 포함하는 시크릿을 생성한다.
+
+ ```shell
+ kubectl create secret generic test-secret --from-literal=username='my-app' --from-literal=password='39528$vdg7Jb'
+ ```
+
+* envFrom을 사용하여 시크릿의 모든 데이터를 컨테이너 환경 변수로 정의한다. 시크릿의 키는 파드에서 환경 변수의 이름이 된다.
+
+ {{< codenew file="pods/inject/pod-secret-envFrom.yaml" >}}
+
+* 파드를 생성한다.
+
+ ```shell
+ kubectl create -f https://k8s.io/examples/pods/inject/pod-secret-envFrom.yaml
+ ```
+
+* `username` 및 `password` 컨테이너 환경 변수를 셸에서 출력한다.
+
+ ```shell
+ kubectl exec -i -t envfrom-secret -- /bin/sh -c 'echo "username: $username\npassword: $password\n"'
+ ```
+
+ 출력은 다음과 같다.
+ ```
+ username: my-app
+ password: 39528$vdg7Jb
+ ```
+
+### 참고
+
+* [시크릿](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
+* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
+* [파드](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core)
+
+## {{% heading "whatsnext" %}}
+
+* [시크릿](/ko/docs/concepts/configuration/secret/)에 대해 더 배워 보기.
+* [볼륨](/ko/docs/concepts/storage/volumes/)에 대해 더 배워 보기.
diff --git a/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
new file mode 100644
index 0000000000..2a8a206d6d
--- /dev/null
+++ b/content/ko/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md
@@ -0,0 +1,259 @@
+---
+title: 파일로 컨테이너에 파드 정보 노출하기
+content_type: task
+weight: 40
+---
+
+
+
+본 페이지는 파드가 DownwardAPIVolumeFile을 사용하여 파드에서 실행되는 컨테이너에
+자신에 대한 정보를 노출하는 방법에 대해 설명한다. DownwardAPIVolumeFile은 파드 필드와
+컨테이너 필드를 노출할 수 있다.
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+## 다운워드(Downward) API
+
+실행 중인 컨테이너에 파드 및 컨테이너 필드를 노출하는 방법에는 두 가지가 있다.
+
+* [환경 변수](/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#the-downward-api)
+* 볼륨 파일
+
+파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
+
+## 파드 필드 저장
+
+이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다.
+다음은 파드에 대한 구성 파일이다.
+
+{{< codenew file="pods/inject/dapi-volume.yaml" >}}
+
+구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너가 `/etc/podinfo`에 볼륨을 마운트하는
+것을 확인할 수 있다.
+
+`downwardAPI` 아래의 배열을 살펴보자. 배열의 각 요소는
+[DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)이다.
+첫 번째 요소는 파드의 `metadata.labels` 필드 값이 `labels`라는 파일에 저장되어야 함을 지정한다.
+두 번째 요소는 파드의 `annotations` 필드 값이 `annotations`라는 파일에 저장되어야 함을 지정한다.
+
+{{< note >}}
+이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
+{{< /note >}}
+
+파드를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume.yaml
+```
+
+파드의 컨테이너가 실행 중인지 확인한다.
+
+```shell
+kubectl get pods
+```
+
+컨테이너의 로그를 본다.
+
+```shell
+kubectl logs kubernetes-downwardapi-volume-example
+```
+
+출력은 `labels` 파일과 `annotations` 파일의 내용을 보여준다.
+
+```shell
+cluster="test-cluster1"
+rack="rack-22"
+zone="us-est-coast"
+
+build="two"
+builder="john-doe"
+```
+
+파드에서 실행 중인 컨테이너의 셸을 가져오자.
+
+```shell
+kubectl exec -it kubernetes-downwardapi-volume-example -- sh
+```
+
+셸에서 `labels` 파일을 보자.
+
+```shell
+/# cat /etc/podinfo/labels
+```
+
+출력을 통해 모든 파드의 레이블이 `labels` 파일에 기록되었음을 확인할 수 있다.
+
+```shell
+cluster="test-cluster1"
+rack="rack-22"
+zone="us-est-coast"
+```
+
+마찬가지로 `annotations` 파일을 확인하자.
+
+```shell
+/# cat /etc/podinfo/annotations
+```
+
+`etc/podinfo` 디렉터리에 파일을 확인하자.
+
+```shell
+/# ls -laR /etc/podinfo
+```
+
+출력에서 `labels` 및 `annotations` 파일이
+임시 하위 디렉터리에 있음을 알 수 있다. 이 예제에서는
+`..2982_06_02_21_47_53.299460680`이다. `/etc/podinfo` 디렉터리에서 `..data`는
+임시 하위 디렉토리에 대한 심볼릭 링크이다. `/etc/podinfo` 디렉토리에서
+`labels`와 `annotations` 또한 심볼릭 링크이다.
+
+```
+drwxr-xr-x ... Feb 6 21:47 ..2982_06_02_21_47_53.299460680
+lrwxrwxrwx ... Feb 6 21:47 ..data -> ..2982_06_02_21_47_53.299460680
+lrwxrwxrwx ... Feb 6 21:47 annotations -> ..data/annotations
+lrwxrwxrwx ... Feb 6 21:47 labels -> ..data/labels
+
+/etc/..2982_06_02_21_47_53.299460680:
+total 8
+-rw-r--r-- ... Feb 6 21:47 annotations
+-rw-r--r-- ... Feb 6 21:47 labels
+```
+
+심볼릭 링크를 사용하면 메타데이터의 동적(dynamic) 원자적(atomic) 갱신이 가능하다.
+업데이트는 새 임시 디렉터리에 기록되고, `..data` 심볼릭 링크는
+[rename(2)](http://man7.org/linux/man-pages/man2/rename.2.html)을 사용하여
+원자적(atomic)으로 갱신한다.
+
+{{< note >}}
+다운워드 API를 [subPath](/docs/concepts/storage/volumes/#using-subpath)
+볼륨 마운트로 사용하는 컨테이너는 다운워드 API 업데이트를 수신하지 않는다.
+{{< /note >}}
+
+셸을 종료한다.
+
+```shell
+/# exit
+```
+
+## 컨테이너 필드 저장
+
+이전 연습에서는 파드 필드를 DownwardAPIVolumeFile에 저장하였다.
+이 다음 연습에서는 컨테이너 필드를 저장한다. 다음은 하나의 컨테이너를 가진 파드의 구성 파일이다.
+
+{{< codenew file="pods/inject/dapi-volume-resources.yaml" >}}
+
+구성 파일에서 파드에 `downwardAPI` 볼륨이 있고 컨테이너는 `/etc/podinfo`에 볼륨을
+마운트하는 것을 확인할 수 있다.
+
+`downwardAPI` 아래의 `items` 배열을 살펴보자. 배열의 각 요소는 DownwardAPIVolumeFile이다.
+
+첫 번째 요소는 `client-container`라는 컨테이너에서
+`1m`으로 지정된 형식의 `limits.cpu` 필드 값이
+`cpu_limit`이라는 파일에 저장되어야 함을 지정한다. `divisor` 필드는 선택 사항이며
+기본값인 `1`은 CPU에 대한 코어 및 메모리에 대한 바이트를 의미한다.
+
+파드를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-volume-resources.yaml
+```
+
+파드에서 실행 중인 컨테이너의 셸을 가져온다.
+
+```shell
+kubectl exec -it kubernetes-downwardapi-volume-example-2 -- sh
+```
+
+셸에서 `cpu_limit` 파일을 확인한다.
+
+```shell
+/# cat /etc/podinfo/cpu_limit
+```
+비슷한 명령을 통해 `cpu_request`, `mem_limit` 및
+`mem_request` 파일을 확인할 수 있다.
+
+
+
+
+
+## 다운워드 API의 기능
+
+다음 정보는 환경 변수 및 `downwardAPI` 볼륨을 통해 컨테이너에서 사용할 수 있다.
+
+* `fieldRef`를 통해 다음 정보를 사용할 수 있다.
+ * `metadata.name` - 파드의 이름
+ * `metadata.namespace` - 파드의 네임스페이스(Namespace)
+ * `metadata.uid` - 파드의 UID
+ * `metadata.labels['']` - 파드의 레이블 `` 값 (예를 들어, `metadata.labels['mylabel']`)
+ * `metadata.annotations['']` - 파드의 어노테이션 `` 값 (예를 들어, `metadata.annotations['myannotation']`)
+* `resourceFieldRef`를 통해 다음 정보를 사용할 수 있다.
+ * 컨테이너의 CPU 한도(limit)
+ * 컨테이너의 CPU 요청(request)
+ * 컨테이너의 메모리 한도(limit)
+ * 컨테이너의 메모리 요청(request)
+ * 컨테이너의 hugepages 한도(limit) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
+ * 컨테이너의 hugepages 요청(request) (`DownwardAPIHugePages` [기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)가 활성화된 경우)
+ * 컨테이너의 임시-스토리지 한도(limit)
+ * 컨테이너의 임시-스토리지 요청(request)
+
+`downwardAPI` 볼륨 `fieldRef`를 통해 다음 정보를 사용할 수 있다.
+
+* `metadata.labels` - 한 줄에 하나의 레이블이 있는
+`label-key="escaped-label-value"` 형식의 모든 파드 레이블
+* `metadata.annotations` - 한 줄에 하나의 어노테이션이 있는 `annotation-key="escaped-annotation-value"` 형식의 모든 파드 어노테이션
+
+환경 변수를 통해 다음 정보를 사용할 수 있다.
+
+* `status.podIP` - 파드의 IP 주소
+* `spec.serviceAccountName` - 파드의 서비스 계정 이름, v1.4.0-alpha.3부터 사용 가능
+* `spec.nodeName` - 노드의 이름, v1.4.0-alpha.3부터 사용 가능
+* `status.hostIP` - 노드의 IP, v1.7.0-alpha.1 이후 사용 가능
+
+{{< note >}}
+컨테이너에 대해 CPU 및 메모리 한도(limit)가 지정되지 않은 경우 다운워드 API는 기본적으로
+CPU 및 메모리에 대해 할당 가능한 노드 값으로 설정한다.
+{{< /note >}}
+
+## 특정 경로 및 파일 권한에 대한 프로젝트 키
+
+키(key)를 파드 안의 특정 경로에, 특정 권한으로, 파일 단위로 투영(project)할 수 있다.
+자세한 내용은
+[시크릿(Secrets)](/ko/docs/concepts/configuration/secret/)을 참조한다.
+
+## 다운워드 API에 대한 동기
+
+컨테이너가 쿠버네티스에 과도하게 결합되지 않고 자체에 대한 정보를 갖는 것이 때때로 유용하다.
+다운워드 API를 사용하면 컨테이너가 쿠버네티스 클라이언트 또는 API 서버를 사용하지 않고
+자체 또는 클러스터에 대한 정보를 사용할 수 있다.
+
+예를 들어 잘 알려진 특정 환경 변수에 고유 식별자가 있다고 가정하는
+기존 애플리케이션이 있다. 한 가지 가능성은 애플리케이션을 래핑하는 것이지만
+이는 지루하고 오류가 발생하기 쉬우며 낮은 결합 목표를 위반한다.
+더 나은 옵션은 파드의 이름을 식별자로 사용하고
+파드의 이름을 잘 알려진 환경 변수에 삽입하는 것이다.
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+* [볼륨](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#volume-v1-core)
+* [DownwardAPIVolumeSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumesource-v1-core)
+* [DownwardAPIVolumeFile](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#downwardapivolumefile-v1-core)
+* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
+
+
+
+
+
diff --git a/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md b/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
new file mode 100644
index 0000000000..033e0afa79
--- /dev/null
+++ b/content/ko/docs/tasks/inject-data-application/environment-variable-expose-pod-information.md
@@ -0,0 +1,157 @@
+---
+title: 환경 변수로 컨테이너에 파드 정보 노출하기
+content_type: task
+weight: 30
+---
+
+
+
+본 페이지는 파드에서 실행 중인 컨테이너에게 파드가 환경 변수를 사용해서 자신의 정보를 노출하는 방법에
+대해 설명한다. 환경 변수는 파드 필드와 컨테이너 필드를 노출할 수 있다.
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+
+## 다운워드(Downward) API
+
+파드 및 컨테이너 필드를 실행 중인 컨테이너에 노출하는 두 가지 방법이 있다.
+
+* 환경 변수
+* [볼륨 파일](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api)
+
+파드 및 컨테이너 필드를 노출하는 이 두 가지 방법을 *다운워드 API*라고 한다.
+
+
+## 파드 필드를 환경 변수의 값으로 사용하자
+
+이 연습에서는 하나의 컨테이너를 가진 파드를 생성한다. 다음은 파드에 대한 구성 파일이다.
+
+{{< codenew file="pods/inject/dapi-envars-pod.yaml" >}}
+
+구성 파일에서 5개의 환경 변수를 확인할 수 있다. `env` 필드는
+[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_NODE_NAME` 환경 변수가 파드의 `spec.nodeName` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 파드 필드에서 이름을 가져온다.
+
+{{< note >}}
+이 예제의 필드는 파드에 있는 컨테이너의 필드가 아니라 파드 필드이다.
+{{< /note >}}
+
+파드를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-pod.yaml
+```
+
+파드의 컨테이너가 실행중인지 확인한다.
+
+```shell
+kubectl get pods
+```
+
+컨테이너의 로그를 본다.
+
+```shell
+kubectl logs dapi-envars-fieldref
+```
+
+출력은 선택된 환경 변수의 값을 보여준다.
+
+```
+minikube
+dapi-envars-fieldref
+default
+172.17.0.4
+default
+```
+
+이러한 값이 로그에 출력된 이유를 보려면 구성 파일의 `command` 및 `args` 필드를 확인하자.
+컨테이너가 시작되면 5개의 환경 변수 값을 stdout에 쓰며 10초마다 이를 반복한다.
+
+다음으로 파드에서 실행 중인 컨테이너의 셸을 가져오자.
+
+```shell
+kubectl exec -it dapi-envars-fieldref -- sh
+```
+
+셸에서 환경 변수를 보자.
+
+```shell
+/# printenv
+```
+
+출력은 특정 환경 변수에 파드 필드 값이 할당되었음을 보여준다.
+
+```
+MY_POD_SERVICE_ACCOUNT=default
+...
+MY_POD_NAMESPACE=default
+MY_POD_IP=172.17.0.4
+...
+MY_NODE_NAME=minikube
+...
+MY_POD_NAME=dapi-envars-fieldref
+```
+
+## 컨테이너 필드를 환경 변수의 값으로 사용하기
+
+이전 연습에서는 파드 필드를 환경 변수의 값으로 사용했다. 이 다음 연습에서는 컨테이너 필드를
+환경 변수의 값으로 사용한다. 다음은 하나의 컨테이너가 있는 파드의 구성 파일이다.
+
+{{< codenew file="pods/inject/dapi-envars-container.yaml" >}}
+
+구성 파일에서 4개의 환경 변수를 확인할 수 있다. `env` 필드는
+[EnvVars](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)의 배열이다. 배열의 첫 번째 요소는 `MY_CPU_REQUEST` 환경 변수가 `test-container`라는 컨테이너의
+`requests.cpu` 필드에서 값을 가져오도록 지정한다. 마찬가지로 다른 환경 변수도 컨테이너 필드에서
+값을 가져온다.
+
+파드를 생성한다.
+
+```shell
+kubectl apply -f https://k8s.io/examples/pods/inject/dapi-envars-container.yaml
+```
+
+파드의 컨테이너가 실행중인지 확인한다.
+
+```shell
+kubectl get pods
+```
+
+컨테이너의 로그를 본다.
+
+```shell
+kubectl logs dapi-envars-resourcefieldref
+```
+
+출력은 선택된 환경 변수의 값을 보여준다.
+
+```
+1
+1
+33554432
+67108864
+```
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [컨테이너를 위한 환경 변수 정의하기](/docs/tasks/inject-data-application/define-environment-variable-container/)
+* [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
+* [컨테이너](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
+* [EnvVar](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvar-v1-core)
+* [EnvVarSource](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#envvarsource-v1-core)
+* [ObjectFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#objectfieldselector-v1-core)
+* [ResourceFieldSelector](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#resourcefieldselector-v1-core)
+
+
+
diff --git a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md
index 50a3a6ad2b..a3575704ae 100644
--- a/content/ko/docs/tasks/manage-daemon/update-daemon-set.md
+++ b/content/ko/docs/tasks/manage-daemon/update-daemon-set.md
@@ -11,6 +11,8 @@ weight: 10
## {{% heading "prerequisites" %}}
+{{< include "task-tutorial-prereqs.md" >}}
+
## 데몬셋 업데이트 전략
@@ -33,9 +35,11 @@ weight: 10
`.spec.updateStrategy.type` 에 `RollingUpdate` 를 설정해야 한다.
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/ko/docs/concepts/workloads/controllers/deployment/#최대-불가max-unavailable)
-(기본값은 1)과
+(기본값은 1),
[`.spec.minReadySeconds`](/ko/docs/concepts/workloads/controllers/deployment/#최소-대기-시간초)
-(기본값은 0)으로
+(기본값은 0),
+[`.spec.maxSurge`](/ko/docs/concepts/workloads/controllers/deployment/#최대-서지-max-surge)
+(베타 기능, 기본값은 25%)를
설정할 수도 있다.
### `RollingUpdate` 업데이트 전략으로 데몬셋 생성
diff --git a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
index 981efb6719..40ca1a8726 100644
--- a/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
+++ b/content/ko/docs/tasks/manage-hugepages/scheduling-hugepages.md
@@ -113,9 +113,3 @@ spec:
- 네임스페이스에서의 huge page 사용은 `hugepages-` 토큰을 사용하는 `cpu` 또는 `memory` 와 같은
다른 컴퓨트 리소스와 비슷한 리소스쿼터(ResourceQuota)를 통해 제어할 수
있다.
-- 다양한 크기의 huge page 지원이 기능 게이트로 제공된다.
- {{}} 및
- {{}}
- (`--feature-gates=HugePageStorageMediumSize=true`)의 `HugePageStorageMediumSize`
- [기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/)를
- 사용하여 비활성화할 수 있다.
diff --git a/content/ko/docs/tasks/network/validate-dual-stack.md b/content/ko/docs/tasks/network/validate-dual-stack.md
index 5a3fdc477e..97753165f1 100644
--- a/content/ko/docs/tasks/network/validate-dual-stack.md
+++ b/content/ko/docs/tasks/network/validate-dual-stack.md
@@ -16,7 +16,7 @@ content_type: task
* 이중 스택 네트워킹을 위한 제공자 지원 (클라우드 제공자 또는 기타 제공자들은 라우팅 가능한 IPv4/IPv6 네트워크 인터페이스를 제공하는 쿠버네티스 노드들을 제공해야 한다.)
-* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예. Kubenet 또는 Calico)
+* 이중 스택을 지원하는 [네트워크 플러그인](/ko/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (예: Calico, Cilium 또는 Kubenet)
* [이중 스택 활성화](/ko/docs/concepts/services-networking/dual-stack/) 클러스터
{{< version-check >}}
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
index 61f1dbc758..a3c6285aac 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
@@ -183,7 +183,7 @@ CPU 사용량은 0으로 떨어졌고, HPA는 레플리카의 개수를 1로 낮
첫 번째로, `autoscaling/v2beta2` 형식으로 HorizontalPodAutoscaler YAML 파일을 생성한다.
```shell
-kubectl get hpa.v2beta2.autoscaling -o yaml > /tmp/hpa-v2.yaml
+kubectl get hpa php-apache -o yaml > /tmp/hpa-v2.yaml
```
에디터로 `/tmp/hpa-v2.yaml` 파일을 열면, 다음과 같은 YAML을 확인할 수 있다.
diff --git a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
index 90d151e768..0700f3cb8d 100644
--- a/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
+++ b/content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
@@ -1,4 +1,8 @@
---
+
+
+
+
title: Horizontal Pod Autoscaler
feature:
title: Horizontal 스케일링
@@ -9,10 +13,6 @@ content_type: concept
weight: 90
---
-
-
-
-
Horizontal Pod Autoscaler는 CPU 사용량
@@ -181,6 +181,7 @@ HorizontalPodAutoscaler API 오브젝트 생성시 지정된 이름이 유효한
API 오브젝트에 대한 자세한 내용은
[HorizontalPodAutoscaler 오브젝트](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#horizontalpodautoscaler-v1-autoscaling)에서 찾을 수 있다.
+
## kubectl에서 Horizontal Pod Autoscaler 지원
Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`에 의해 표준 방식으로 지원된다.
@@ -197,14 +198,17 @@ Horizontal Pod Autoscaler는 모든 API 리소스와 마찬가지로 `kubectl`
## 롤링 업데이트 중 오토스케일링
-현재 쿠버네티스에서는 기본 레플리카셋를 관리하는 디플로이먼트 오브젝트를 사용하여 롤링 업데이트를 수행할 수 있다.
-Horizontal Pod Autoscaler는 후자의 방법을 지원한다. Horizontal Pod Autoscaler는 디플로이먼트 오브젝트에 바인딩되고,
-디플로이먼트 오브젝트를 위한 크기를 설정하며, 디플로이먼트는 기본 레플리카셋의 크기를 결정한다.
+쿠버네티스는 디플로이먼트에 대한 롤링 업데이트를 지원한다.
+이 경우, 디플로이먼트가 기저 레플리카셋을 알아서 관리한다.
+디플로이먼트에 오토스케일링을 설정하려면,
+각 디플로이먼트에 대한 HorizontalPodAutoscaler를 생성한다.
+HorizontalPodAutoscaler는 디플로이먼트의 `replicas` 필드를 관리한다.
+디플로이먼트 컨트롤러는 기저 레플리카셋에 `replicas` 값을 적용하여
+롤아웃 과정 중/이후에 적절한 숫자까지 늘어나도록 한다.
-Horizontal Pod Autoscaler는 레플리케이션 컨트롤러를 직접 조작하는 롤링 업데이트에서 작동하지 않는다.
-즉, Horizontal Pod Autoscaler를 레플리케이션 컨트롤러에 바인딩하고 롤링 업데이트를 수행할 수 없다. (예 : `kubectl rolling-update`)
-작동하지 않는 이유는 롤링 업데이트에서 새 레플리케이션 컨트롤러를 만들 때,
-Horizontal Pod Autoscaler가 새 레플리케이션 컨트롤러에 바인딩되지 않기 때문이다.
+오토스케일된 레플리카가 있는 스테이트풀셋의 롤링 업데이트를 수행하면,
+스테이트풀셋이 직접 파드의 숫자를 관리한다(즉,
+레플리카셋과 같은 중간 리소스가 없다).
## 쿨-다운 / 지연에 대한 지원
diff --git a/content/ko/docs/tasks/run-application/run-stateless-application-deployment.md b/content/ko/docs/tasks/run-application/run-stateless-application-deployment.md
new file mode 100644
index 0000000000..ea5bfd76af
--- /dev/null
+++ b/content/ko/docs/tasks/run-application/run-stateless-application-deployment.md
@@ -0,0 +1,160 @@
+---
+title: 디플로이먼트(Deployment)로 스테이트리스 애플리케이션 실행하기
+min-kubernetes-server-version: v1.9
+content_type: tutorial
+weight: 10
+---
+
+
+
+이 페이지에서는 쿠버네티스 디플로이먼트 오브젝트를 사용하여 애플리케이션을 실행하는 방법을 설명한다.
+
+
+
+
+## {{% heading "objectives" %}}
+
+
+* nginx 디플로이먼트 생성하기
+* kubectl을 사용하여 디플로이먼트 정보 나열하기
+* 디플로이먼트 업데이트하기
+
+
+
+
+## {{% heading "prerequisites" %}}
+
+
+{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
+
+
+
+
+
+
+## nginx 디플로이먼트 생성하고 탐색하기
+
+쿠버네티스 디플로이먼트 오브젝트를 생성하여 애플리케이션을 실행할 수 있으며,
+디플로이먼트에 대한 명세를 YAML 파일에 기술할 수 있다. 예를 들어 이 YAML 파일은
+nginx:1.14.2 도커 이미지를 실행하는 디플로이먼트에 대한 명세를 담고 있다.
+
+{{< codenew file="application/deployment.yaml" >}}
+
+
+1. YAML 파일을 기반으로 디플로이먼트를 생성한다.
+
+ kubectl apply -f https://k8s.io/examples/application/deployment.yaml
+
+1. 디플로이먼트에 대한 정보를 살펴본다.
+
+ kubectl describe deployment nginx-deployment
+
+ 출력은 다음과 유사하다.
+
+ Name: nginx-deployment
+ Namespace: default
+ CreationTimestamp: Tue, 30 Aug 2016 18:11:37 -0700
+ Labels: app=nginx
+ Annotations: deployment.kubernetes.io/revision=1
+ Selector: app=nginx
+ Replicas: 2 desired | 2 updated | 2 total | 2 available | 0 unavailable
+ StrategyType: RollingUpdate
+ MinReadySeconds: 0
+ RollingUpdateStrategy: 1 max unavailable, 1 max surge
+ Pod Template:
+ Labels: app=nginx
+ Containers:
+ nginx:
+ Image: nginx:1.14.2
+ Port: 80/TCP
+ Environment:
+ Mounts:
+ Volumes:
+ Conditions:
+ Type Status Reason
+ ---- ------ ------
+ Available True MinimumReplicasAvailable
+ Progressing True NewReplicaSetAvailable
+ OldReplicaSets:
+ NewReplicaSet: nginx-deployment-1771418926 (2/2 replicas created)
+ No events.
+
+1. 디플로이먼트에 의해 생성된 파드를 나열한다.
+
+ kubectl get pods -l app=nginx
+
+ 출력은 다음과 유사하다.
+
+ NAME READY STATUS RESTARTS AGE
+ nginx-deployment-1771418926-7o5ns 1/1 Running 0 16h
+ nginx-deployment-1771418926-r18az 1/1 Running 0 16h
+
+1. 파드에 대한 정보를 살펴본다.
+
+ kubectl describe pod
+
+ ``은 파드 중 하나의 이름이다.
+
+## 디플로이먼트 업데이트하기
+
+새 YAML 파일을 적용하여 디플로이먼트를 업데이트할 수 있다. 이 YAML 파일은
+nginx 1.16.1을 사용하도록 디플로이먼트를 업데이트해야 함을 명시하고 있다.
+
+{{< codenew file="application/deployment-update.yaml" >}}
+
+1. 새 YAML 파일을 적용한다.
+
+ kubectl apply -f https://k8s.io/examples/application/deployment-update.yaml
+
+1. 디플로이먼트가 새 이름으로 파드를 생성하고 이전 파드를 삭제하는 것을 확인한다.
+
+ kubectl get pods -l app=nginx
+
+## 레플리카 수를 늘려 애플리케이션 확장하기
+
+새 YAML 파일을 적용하여 디플로이먼트의 파드 수를 늘릴 수 있다.
+이 YAML 파일은 `replicas`를 4로 설정하여 디플로이먼트에
+4개의 파드가 있어야 함을 명시하고 있다.
+
+{{< codenew file="application/deployment-scale.yaml" >}}
+
+1. 새 YAML 파일을 적용한다.
+
+ kubectl apply -f https://k8s.io/examples/application/deployment-scale.yaml
+
+1. 디플로이먼트에 4개의 파드가 있는지 확인한다.
+
+ kubectl get pods -l app=nginx
+
+ 출력은 다음과 유사하다.
+
+ NAME READY STATUS RESTARTS AGE
+ nginx-deployment-148880595-4zdqq 1/1 Running 0 25s
+ nginx-deployment-148880595-6zgi1 1/1 Running 0 25s
+ nginx-deployment-148880595-fxcez 1/1 Running 0 2m
+ nginx-deployment-148880595-rwovn 1/1 Running 0 2m
+
+## 디플로이먼트 삭제하기
+
+이름으로 디플로이먼트를 삭제한다.
+
+ kubectl delete deployment nginx-deployment
+
+## ReplicationControllers -- 예전 방식
+
+애플리케이션을 복제하여 생성하는 기본적인 방법은 내부적으로 레플리카셋(ReplicaSet)을 활용하는 디플로이먼트를
+사용하는 것이다. 쿠버네티스에 디플로이먼트 및 레플리카셋이 도입되기 전에는
+[레플리케이션컨트롤러(ReplicationController)](/ko/docs/concepts/workloads/controllers/replicationcontroller/)를 사용하여 복제 애플리케이션을
+구성했었다.
+
+
+
+
+## {{% heading "whatsnext" %}}
+
+
+* [디플로이먼트 오브젝트](/ko/docs/concepts/workloads/controllers/deployment/)에 대해 더 배워보기
+
+
+
+
diff --git a/content/ko/docs/tasks/tools/install-kubectl-macos.md b/content/ko/docs/tasks/tools/install-kubectl-macos.md
index 90fefb0c3a..cd03eb91b7 100644
--- a/content/ko/docs/tasks/tools/install-kubectl-macos.md
+++ b/content/ko/docs/tasks/tools/install-kubectl-macos.md
@@ -228,7 +228,7 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
1. kubectl-convert 바이너리를 시스템 `PATH` 의 파일 위치로 옮긴다.
```bash
- sudo mv ./kubectl /usr/local/bin/kubectl-convert
+ sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
sudo chown root: /usr/local/bin/kubectl-convert
```
diff --git a/content/ko/docs/tasks/tools/install-kubectl-windows.md b/content/ko/docs/tasks/tools/install-kubectl-windows.md
index ab5e7ca05d..21fe1a9afb 100644
--- a/content/ko/docs/tasks/tools/install-kubectl-windows.md
+++ b/content/ko/docs/tasks/tools/install-kubectl-windows.md
@@ -47,20 +47,20 @@ card:
kubectl 바이너리를 체크섬 파일을 통해 검증한다.
- - 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
+ - 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
```cmd
CertUtil -hashfile kubectl.exe SHA256
type kubectl.exe.sha256
```
- - `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
+ - PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다.
```powershell
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
```
-1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
+1. `PATH`로 설정된 디렉터리 중 하나에 kubectl 바이너리를 추가한다.
1. `kubectl` 의 버전이 다운로드한 버전과 같은지 확인한다.
@@ -160,20 +160,20 @@ kubectl은 Bash 및 Zsh에 대한 자동 완성 지원을 제공하므로 입력
kubectl-convert 바이너리를 체크섬 파일을 통해 검증한다.
- - 수동으로 `CertUtil` 의 출력과 다운로드한 체크섬 파일을 비교하기 위해서 커맨드 프롬프트를 사용한다.
+ - 커맨드 프롬프트를 사용하는 경우, `CertUtil` 의 출력과 다운로드한 체크섬 파일을 수동으로 비교한다.
```cmd
CertUtil -hashfile kubectl-convert.exe SHA256
type kubectl-convert.exe.sha256
```
- - `-eq` 연산자를 통해 `True` 또는 `False` 결과를 얻는 자동 검증을 위해서 PowerShell을 사용한다.
+ - PowerShell을 사용하는 경우, `-eq` 연산자를 통해 `True` 또는 `False` 결과가 출력되는 자동 검증을 수행한다.
```powershell
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
```
-1. 바이너리를 `PATH` 가 설정된 디렉터리에 추가한다.
+1. `PATH`로 설정된 디렉터리 중 하나에 kubectl-convert 바이너리를 추가한다.
1. 플러그인이 정상적으로 설치되었는지 확인한다.
diff --git a/content/ko/docs/tutorials/clusters/apparmor.md b/content/ko/docs/tutorials/clusters/apparmor.md
index 43b07e293b..7b11ea7722 100644
--- a/content/ko/docs/tutorials/clusters/apparmor.md
+++ b/content/ko/docs/tutorials/clusters/apparmor.md
@@ -348,6 +348,11 @@ Events:
### PodSecurityPolicy로 프로파일 제한하기 {#restricting-profiles-with-the-podsecuritypolicy}
+{{< note >}}
+PodSecurityPolicy는 쿠버네티스 v1.21에서 사용 중지되었으며, v1.25에서 제거될 예정이다.
+더 자세한 내용은 [PodSecurityPolicy 문서](/ko/docs/concepts/policy/pod-security-policy/)를 참고한다.
+{{< /note >}}
+
만약 PodSecurityPolicy 확장을 사용하면, 클러스터 단위로 AppArmor 제한을 적용할 수 있다.
PodSecurityPolicy를 사용하려면 위해 다음의 플래그를 반드시 `apiserver`에 설정해야 한다.
diff --git a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
index fcad9b42b3..7c66225037 100644
--- a/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
+++ b/content/ko/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html
@@ -26,7 +26,7 @@ weight: 20
ClusterIP (기본값) - 클러스터 내에서 내부 IP 에 대해 서비스를 노출해준다. 이 방식은 오직 클러스터 내에서만 서비스가 접근될 수 있도록 해준다.
NodePort - NAT가 이용되는 클러스터 내에서 각각 선택된 노드들의 동일한 포트에 서비스를 노출시켜준다. <NodeIP>:<NodePort>를 이용하여 클러스터 외부로부터 서비스가 접근할 수 있도록 해준다. ClusterIP의 상위 집합이다.
LoadBalancer - (지원 가능한 경우) 기존 클라우드에서 외부용 로드밸런서를 생성하고 서비스에 고정된 공인 IP를 할당해준다. NodePort의 상위 집합이다.
-
ExternalName - CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, `foo.bar.example.com`)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.
+
ExternalName - CNAME 레코드 및 값을 반환함으로써 서비스를 externalName 필드의 내용(예를 들면, foo.bar.example.com)에 매핑한다. 어떠한 종류의 프록시도 설정되지 않는다. 이 방식은 kube-dns v1.7 이상 또는 CoreDNS 버전 0.0.8 이상을 필요로 한다.
부가적으로, spec에 selector를 정의하지 않고 말아넣은 서비스들의 몇 가지 유즈케이스들이 있음을 주의하자. selector 없이 생성된 서비스는 상응하는 엔드포인트 오브젝트들 또한 생성하지 않는다. 이로써 사용자들로 하여금 하나의 서비스를 특정한 엔드포인트에 매핑 시킬수 있도록 해준다. selector를 생략하게 되는 또 다른 가능성은 여러분이 type: ExternalName을 이용하겠다고 확고하게 의도하는 경우이다.
diff --git a/content/pt-br/docs/concepts/configuration/configmap.md b/content/pt-br/docs/concepts/configuration/configmap.md
new file mode 100644
index 0000000000..e3666a8542
--- /dev/null
+++ b/content/pt-br/docs/concepts/configuration/configmap.md
@@ -0,0 +1,280 @@
+---
+title: ConfigMaps
+content_type: concept
+weight: 20
+---
+
+
+
+{{< glossary_definition term_id="configmap" prepend="Um ConfigMap é" length="all" >}}
+
+{{< caution >}}
+O ConfigMap não oferece confidencialidade ou encriptação.
+Se os dados que você deseja armazenar são confidenciais, utilize
+{{< glossary_tooltip term_id="secret" >}} ao invés de um ConfigMap,
+ou utilize ferramentas adicionais (de terceiros) para manter seus dados privados.
+{{< /caution >}}
+
+
+
+## Motivação
+
+Utilize um ConfigMap para manter a configuração separada do código da aplicação.
+
+Por exemplo, imagine que você esteja desenvolvendo uma aplicação que pode ser executada
+no seu computador local (para desenvolvimento) e na nuvem (para manipular tráfego real).
+Você escreve código para ler a variável de ambiente chamada `DATABASE_HOST`.
+No seu ambiente local, você configura essa variável com o valor `localhost`. Na nuvem, você
+configura essa variável para referenciar um {{< glossary_tooltip text="serviço" term_id="service" >}}
+do Kubernetes que expõe o componente do banco de dados ao seu cluster.
+Isto permite que você baixe uma imagem de contêiner que roda na nuvem e depure exatamente
+o mesmo código localmente se necessário.
+
+Um ConfigMap não foi planejado para conter grandes quantidades de dados. Os dados armazenados
+em um ConfigMap não podem exceder 1 MiB. Se você precisa armazenar configurações que são maiores
+que este limite, considere montar um volume ou utilizar um serviço separado de banco de dados
+ou de arquivamento de dados.
+
+## Objeto ConfigMap
+
+Um ConfigMap é um [objeto](/docs/concepts/overview/working-with-objects/kubernetes-objects/)
+da API que permite o armazenamento de configurações para consumo por outros objetos. Diferentemente
+de outros objetos do Kubernetes que contém um campo `spec`, o ConfigMap contém os campos `data` e
+`binaryData`. Estes campos aceitam pares chave-valor como valores. Ambos os campos `data` e `binaryData`
+são opcionais. O campo `data` foi pensado para conter sequências de bytes UTF-8, enquanto o campo `binaryData`
+foi planejado para conter dados binários em forma de strings codificadas em base64.
+
+É obrigatório que o nome de um ConfigMap seja um
+[subdomínio DNS válido](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names).
+
+Cada chave sob as seções `data` ou `binaryData` pode conter quaisquer caracteres alfanuméricos,
+`-`, `_` e `.`. As chaves armazenadas na seção `data` não podem colidir com as chaves armazenadas
+na seção `binaryData`.
+
+A partir da versão v1.19 do Kubernetes, é possível adicionar o campo `immutable` a uma definição de ConfigMap
+para criar um [ConfigMap imutável](#configmap-immutable).
+
+## ConfigMaps e Pods
+
+Você pode escrever uma `spec` para um Pod que se refere a um ConfigMap e configurar o(s) contêiner(es)
+neste Pod baseados em dados do ConfigMap. O Pod e o ConfigMap devem estar no mesmo
+{{< glossary_tooltip text="namespace" term_id="namespace" >}}.
+
+{{< note >}}
+A `spec` de um {{< glossary_tooltip text="Pod estático" term_id="static-pod" >}} não pode se referir a um
+ConfigMap ou a quaisquer outros objetos da API.
+{{< /note >}}
+
+Exemplo de um ConfigMap que contém algumas chaves com valores avulsos e outras chaves com valores semelhantes
+a fragmentos de arquivos de configuração:
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ name: game-demo
+data:
+ # chaves com valores de propriedades; cada chave mapeia para um valor avulso
+ player_initial_lives: "3"
+ ui_properties_file_name: "user-interface.properties"
+
+ # chaves semelhantes a fragmentos de arquivos
+ game.properties: |
+ enemy.types=aliens,monsters
+ player.maximum-lives=5
+ user-interface.properties: |
+ color.good=purple
+ color.bad=yellow
+ allow.textmode=true
+```
+
+Existem quatro formas diferentes para consumo de um ConfigMap na configuração de um
+contêiner dentro de um Pod:
+
+1. Dentro de um comando de contêiner e seus argumentos.
+1. Variáveis de ambiente para um contêiner.
+1. Criando um arquivo em um volume somente leitura, para consumo pela aplicação.
+1. Escrevendo código para execução dentro do Pod que utilize a API do Kubernetes para ler um ConfigMap.
+
+Os diferentes métodos de consumo oferecem diferentes formas de modelar os dados sendo consumidos.
+Para os três primeiros métodos, o {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} utiliza
+os dados de um ConfigMap quando o(s) contêiner(es) do Pod são inicializados.
+
+O quarto método envolve escrita de código para leitura do ConfigMap e dos seus dados. No entanto,
+como a API do Kubernetes está sendo utilizada diretamente, a aplicação pode solicitar atualizações
+sempre que o ConfigMap for alterado e reagir quando isso ocorre. Acessar a API do Kubernetes
+diretamente também permite ler ConfigMaps em outros namespaces.
+
+Exemplo de um Pod que utiliza valores do ConfigMap `game-demo` para configurar um Pod:
+
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: configmap-demo-pod
+spec:
+ containers:
+ - name: demo
+ image: alpine
+ command: ["sleep", "3600"]
+ env:
+ # Define as variáveis de ambiente
+ - name: PLAYER_INITIAL_LIVES # Note que aqui a variável está definida em caixa alta,
+ # diferente da chave no ConfigMap.
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo # O ConfigMap de onde esse valor vem.
+ key: player_initial_lives # A chave que deve ser buscada.
+ - name: UI_PROPERTIES_FILE_NAME
+ valueFrom:
+ configMapKeyRef:
+ name: game-demo
+ key: ui_properties_file_name
+ volumeMounts:
+ - name: config
+ mountPath: "/config"
+ readOnly: true
+ volumes:
+ # Volumes são definidos no escopo do Pod, e os pontos de montagem são definidos
+ # nos contêineres dentro dos pods.
+ - name: config
+ configMap:
+ # Informe o nome do ConfigMap que deseja montar.
+ name: game-demo
+ # Uma lista de chaves do ConfigMap para serem criadas como arquivos.
+ items:
+ - key: "game.properties"
+ path: "game.properties"
+ - key: "user-interface.properties"
+ path: "user-interface.properties"
+```
+
+ConfigMaps não diferenciam entre propriedades com valores simples ou valores complexos,
+que ocupam várias linhas. O importante é a forma que Pods e outros objetos consomem tais valores.
+
+Neste exemplo, definir um volume e montar ele dentro do contêiner `demo` no caminho `/config`
+cria dois arquivos: `/config/game.properties` e `/config/user-interface.properties`, embora existam
+quatro chaves distintas no ConfigMap. Isso se deve ao fato de que a definição do Pod contém uma lista
+`items` na seção `volumes`.
+Se a lista `items` for omitida, cada chave do ConfigMap torna-se um arquivo cujo nome é a sua chave
+correspondente, e quatro arquivos serão criados.
+
+## Usando ConfigMaps
+
+ConfigMaps podem ser montados como volumes de dados. ConfigMaps também podem ser utilizados
+por outras partes do sistema sem serem diretamente expostos ao Pod. Por exemplo, ConfigMaps
+podem conter dados que outras partes do sistema devem usar para configuração.
+
+A forma mais comum de utilização de ConfigMaps é a configuração de contêineres executando em
+Pods no mesmo namespace. Você também pode utilizar um ConfigMap separadamente.
+
+Por exemplo, existem {{< glossary_tooltip text="complementos" term_id="addons" >}} ou
+{{< glossary_tooltip text="operadores" term_id="operator-pattern" >}} que adaptam seus comportamentos
+de acordo com dados de um ConfigMap.
+
+### Utilizando ConfigMaps como arquivos em um Pod
+
+Para consumir um ConfigMap em um volume em um Pod:
+1. Crie um ConfigMap ou utilize um ConfigMap existente. Múltiplos Pods
+ podem referenciar o mesmo ConfigMap.
+1. Modifique sua definição de Pod para adicionar um volume em
+ `.spec.volumes[]`. Escolha um nome qualquer para o seu volume, e
+ referencie o seu objeto ConfigMap no campo
+ `.spec.volumes[].configMap.name`.
+1. Adicione um campo `.spec.containers[].volumeMounts[]` a cada um dos
+ contêineres que precisam do ConfigMap. Especifique
+ `.spec.containers[].volumeMounts[].readOnly = true` e informe no campo
+ `.spec.containers[].volumeMounts[].mountPath` um caminho de um diretório
+ não utilizado onde você deseja que este ConfigMap apareça.
+1. Modifique sua imagem ou linha de comando de modo que o programa procure
+ por arquivos no diretório especificado no passo anterior. Cada chave no
+ campo `data` do ConfigMap será transformado em um nome de arquivo no
+ diretório especificado por `mountPath`.
+
+Exemplo de um Pod que monta um ConfigMap em um volume:
+```yaml
+apiVersion: v1
+kind: Pod
+metadata:
+ name: mypod
+spec:
+ containers:
+ - name: mypod
+ image: redis
+ volumeMounts:
+ - name: foo
+ mountPath: "/etc/foo"
+ readOnly: true
+ volumes:
+ - name: foo
+ configMap:
+ name: myconfigmap
+```
+
+Cada ConfigMap que você deseja utilizar precisa ser referenciado em
+`.spec.volumes`.
+
+Se houver múltiplos contêineres no Pod, cada contêiner deve ter seu
+próprio bloco `volumeMounts`, mas somente uma instância de `.spec.volumes`
+é necessária por ConfigMap.
+
+### ConfigMaps montados são atualizados automaticamente
+
+Quando um ConfigMap que está sendo consumido em um volume é atualizado, as chaves projetadas são
+eventualmente atualizadas também. O Kubelet checa se o ConfigMap montado está atualizado em cada
+sincronização periódica.
+No entanto, o kubelet utiliza o cache local para buscar o valor atual do ConfigMap.
+O tipo de cache é configurável utilizando o campo `ConfigMapAndSecretChangeDetectionStrategy` na
+[configuração do Kubelet (KubeletConfiguration)](/docs/reference/config-api/kubelet-config.v1beta1/).
+Um ConfigMap pode ter sua propagação baseada em um _watch_ (comportamento padrão), que é o sistema
+de propagação de mudanças incrementais em objetos do Kubernetes; baseado em TTL (_time to live_,
+ou tempo de expiração); ou redirecionando todas as requisições diretamente para o servidor da API.
+Como resultado, o tempo decorrido total entre o momento em que o ConfigMap foi atualizado até o momento
+quando as novas chaves são projetadas nos Pods pode ser tão longo quanto o tempo de sincronização
+do kubelet somado ao tempo de propagação do cache, onde o tempo de propagação do cache depende do
+tipo de cache escolhido: o tempo de propagação pode ser igual ao tempo de propagação do _watch_,
+TTL do cache, ou zero, de acordo com cada um dos tipos de cache.
+
+ConfigMaps que são consumidos como variáveis de ambiente não atualizam automaticamente e requerem uma
+reinicialização do pod.
+
+## ConfigMaps imutáveis {#configmap-immutable}
+
+{{< feature-state for_k8s_version="v1.21" state="stable">}}
+
+A funcionalidade _Secrets e ConfigMaps imutáveis_ do Kubernetes fornece uma opção
+para marcar Secrets e ConfigMaps individuais como imutáveis. Para clusters que utilizam
+ConfigMaps extensivamente (ao menos centenas de milhares de mapeamentos únicos de
+ConfigMaps para Pods), prevenir alterações dos seus dados traz as seguintes vantagens:
+
+- protege de atualizações acidentais ou indesejadas que podem causar disrupção na execução
+ de aplicações
+- melhora o desempenho do cluster através do fechamento de _watches_ de ConfigMaps marcados
+ como imutáveis, diminuindo significativamente a carga no kube-apiserver
+
+Essa funcionalidade é controlada pelo [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
+`ImmutableEphemeralVolumes`. É possível criar um ConfigMap imutável adicionando o campo
+`immutable` e marcando seu valor com `true`.
+Por exemplo:
+
+```yaml
+apiVersion: v1
+kind: ConfigMap
+metadata:
+ ...
+data:
+ ...
+immutable: true
+```
+
+Após um ConfigMap ser marcado como imutável, _não_ é possível reverter a alteração, nem
+alterar o conteúdo dos campos `data` ou `binaryData`. É possível apenas apagar e recriar
+o ConfigMap. Como Pods existentes que consomem o ConfigMap em questão mantém um ponto de
+montagem que continuará referenciando este objeto após a remoção, é recomendado recriar
+estes pods.
+
+## {{% heading "whatsnext" %}}
+
+* Leia sobre [Secrets](/docs/concepts/configuration/secret/) (em inglês).
+* Leia [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) (em inglês).
+* Leia [The Twelve-Factor App](https://12factor.net/) (em inglês) para entender a motivação da separação de código
+e configuração.
diff --git a/content/pt-br/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/pt-br/docs/concepts/scheduling-eviction/taint-and-toleration.md
new file mode 100644
index 0000000000..dc4e362f7d
--- /dev/null
+++ b/content/pt-br/docs/concepts/scheduling-eviction/taint-and-toleration.md
@@ -0,0 +1,210 @@
+---
+title: Taints e Tolerâncias
+content_type: concept
+weight: 40
+---
+
+
+
+[_Afinidade de nó_](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)
+é uma propriedade dos {{< glossary_tooltip text="Pods" term_id="pod" >}} que os *associa* a um conjunto de {{< glossary_tooltip text="nós" term_id="node" >}} (seja como uma preferência ou uma exigência). _Taints_ são o oposto -- eles permitem que um nó repudie um conjunto de pods.
+
+_Tolerâncias_ são aplicadas em pods e permitem, mas não exigem, que os pods sejam alocados em nós com _taints_ correspondentes.
+
+Taints e tolerâncias trabalham juntos para garantir que pods não sejam alocados em nós inapropriados. Um ou mais taints são aplicados em um nó; isso define que o nó não deve aceitar nenhum pod que não tolera essas taints.
+
+
+
+
+## Conceitos
+
+Você adiciona um taint a um nó utilizando [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint).
+Por exemplo,
+
+```shell
+kubectl taint nodes node1 key1=value1:NoSchedule
+```
+
+define um taint no nó `node1`. O taint tem a chave `key1`, valor `value1` e o efeito `NoSchedule`.
+Isso significa que nenhum pod conseguirá ser executado no nó `node1` a menos que possua uma tolerância correspondente.
+
+Para remover o taint adicionado pelo comando acima, você pode executar:
+```shell
+kubectl taint nodes node1 key1=value1:NoSchedule-
+```
+
+Você especifica uma tolerância para um pod na [especificação do Pod](/docs/reference/kubernetes-api/workload-resources/pod-v1#PodSpec). Ambas as seguintes tolerâncias "correspondem" ao taint criado pelo `kubectl taint` acima, e assim um pod com qualquer uma delas poderia ser executado no `node1`:
+
+```yaml
+tolerations:
+- key: "key1"
+ operator: "Equal"
+ value: "value1"
+ effect: "NoSchedule"
+```
+
+```yaml
+tolerations:
+- key: "key1"
+ operator: "Exists"
+ effect: "NoSchedule"
+```
+
+Aqui está um exemplo de um pod que utiliza tolerâncias:
+
+{{< codenew file="pods/pod-with-toleration.yaml" >}}
+
+O valor padrão de `operator` é `Equal`.
+
+Uma tolerância "casa" um taint se as chaves e efeitos são os mesmos, e:
+
+* o valor de `operator` é `Exists` (no caso nenhum `value` deve ser especificado), ou
+* o valor de `operator` é `Equal` e os valores de `value` são iguais.
+
+{{< note >}}
+
+Existem dois casos especiais:
+
+Uma `key` vazia com o operador `Exists` "casa" todas as chaves, valores e efeitos, o que significa que o pod irá tolerar tudo.
+
+Um `effect` vazio "casa" todos os efeitos com a chave `key1`.
+
+{{< /note >}}
+
+O exemplo acima usou `effect` de `NoSchedule`. De forma alternativa, você pode usar `effect` de `PreferNoSchedule`.
+Nesse efeito, o sistema *tentará* evitar que o pod seja alocado ao nó caso ele não tolere os taints definidos, contudo a alocação não será evitada de forma obrigatória. Pode-se dizer que o `PreferNoSchedule` é uma versão permissiva do `NoSchedule`. O terceiro tipo de `effect` é o `NoExecute` que será descrito posteriormente.
+
+Você pode colocar múltiplos taints no mesmo nó e múltiplas tolerâncias no mesmo pod.
+O jeito que o Kubernetes processa múltiplos taints e tolerâncias é como um filtro: começa com todos os taints de um nó, em seguida ignora aqueles para os quais o pod tem uma tolerância relacionada; os taints restantes que não foram ignorados indicam o efeito no pod. Mais especificamente,
+
+* se existe pelo menos um taint não tolerado com o efeito `NoSchedule`, o Kubernetes não alocará o pod naquele nó
+* se existe um taint não tolerado com o efeito `NoSchedule`, mas existe pelo menos um taint não tolerado com o efeito `PreferNoSchedule`, o Kubernetes *tentará* não alocar o pod no nó
+* se existe pelo menos um taint não tolerado com o efeito `NoExecute`, o pod será expulso do nó (caso já esteja em execução) e não será alocado ao nó (caso ainda não esteja em execução).
+
+Por exemplo, imagine que você tem um nó com os seguintes taints
+
+```shell
+kubectl taint nodes node1 key1=value1:NoSchedule
+kubectl taint nodes node1 key1=value1:NoExecute
+kubectl taint nodes node1 key2=value2:NoSchedule
+```
+
+E um pod com duas tolerâncias:
+
+```yaml
+tolerations:
+- key: "key1"
+ operator: "Equal"
+ value: "value1"
+ effect: "NoSchedule"
+- key: "key1"
+ operator: "Equal"
+ value: "value1"
+ effect: "NoExecute"
+```
+
+Nesse caso, o pod não será alocado ao nó porque não possui uma tolerância para o terceiro taint. Porém, se ele já estiver rodando no nó quando o taint foi adicionado, não será afetado e continuará rodando, tendo em vista que o terceiro taint é o único não tolerado pelo pod.
+
+Normalmente, se um taint com o efeito `NoExecute` é adicionado a um nó, qualquer pod que não o tolere será expulso imediatamente e pods que o toleram nunca serão expulsos. Contudo, uma tolerância com efeito `NoExecute` pode especificar de forma opcional o campo `tolerationSeconds`, que determina quanto tempo o pod continuará alocado ao nó depois que o taint é adicionado. Por exemplo,
+
+```yaml
+tolerations:
+- key: "key1"
+ operator: "Equal"
+ value: "value1"
+ effect: "NoExecute"
+ tolerationSeconds: 3600
+```
+
+significa que se esse pod está sendo executado e um taint correspondente é adicionado ao nó, o pod irá continuar rodando neste nó por 3600 segundos e depois será expulso. Se o taint for removido antes desse tempo acabar, o pod não será expulso.
+
+## Exemplos de Casos de Uso
+
+Taints e tolerâncias são um modo flexível de conduzir pods para *fora* dos nós ou expulsar pods que não deveriam estar sendo executados. Alguns casos de uso são
+
+* **Nós Dedicados**: Se você quiser dedicar um conjunto de nós para uso exclusivo de um conjunto específico de usuários, poderá adicionar um taint nesses nós. (digamos, `kubectl taint nodes nodename dedicated=groupName:NoSchedule`) e em seguida adicionar uma tolerância correspondente para seus pods (isso seria feito mais facilmente com a escrita de um [controlador de admissão](/docs/reference/access-authn-authz/admission-controllers/) customizado).
+Os pods com tolerância terão sua execução permitida nos nós com taints (dedicados), assim como em qualquer outro nó no cluster. Se você quiser dedicar nós a esses pods *e garantir* que eles usem *apenas* os nós dedicados, precisará adicionar uma label similar ao taint para o mesmo conjunto de nós (por exemplo, `dedicated=groupName`), e o controle de admissão deverá adicionar uma afinidade de nó para exigir que os pods podem ser executados apenas nos nós definidos com a label `dedicated=groupName`.
+
+* **Nós com hardware especial**: Em um cluster no qual um pequeno grupo de nós possui hardware especializado (por exemplo, GPUs), é desejável manter pods que não necessitem desse tipo de hardware fora desses nós, dessa forma o recurso estará disponível para pods que precisem do hardware especializado. Isso pode ser feito aplicando taints nos nós com o hardware especializado (por exemplo, `kubectl taint nodes nodename special=true:NoSchedule` or `kubectl taint nodes nodename special=true:PreferNoSchedule`) e aplicando uma tolerância correspondente nos pods que usam o hardware especial. Assim como no caso de uso de nós dedicados, é provavelmente mais fácil aplicar as tolerâncias utilizando um [controlador de admissão](/docs/reference/access-authn-authz/admission-controllers/).
+Por exemplo, é recomendado usar [Extended Resources](/docs/concepts/configuration/manage-resources-containers/#extended-resources) para representar hardware especial, adicione um taint ao seus nós de hardware especializado com o nome do recurso estendido e execute o controle de admissão [ExtendedResourceToleration](/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration). Agora, tendo em vista que os nós estão marcados com um taint, nenhum pod sem a tolerância será executado neles. Porém, quando você submete um pod que requisita o recurso estendido, o controlador de admissão `ExtendedResourceToleration` irá adicionar automaticamente as tolerâncias necessárias ao pod que irá, por sua vez, ser alocado no nó com hardware especial. Isso garantirá que esses nós de hardware especial serão dedicados para os pods que requisitarem tal recurso e você não precisará adicionar manualmente as tolerâncias aos seus pods.
+
+* **Expulsões baseadas em Taint**: Um comportamento de expulsão configurada por pod quando problemas existem em um nó, o qual será descrito na próxima seção.
+
+## Expulsões baseadas em Taint
+
+{{< feature-state for_k8s_version="v1.18" state="stable" >}}
+
+O efeito de taint `NoExecute`, mencionado acima, afeta pods que já estão rodando no nó da seguinte forma
+
+ * pods que não toleram o taint são expulsos imediatamente
+ * pods que toleram o taint sem especificar `tolerationSeconds` em sua especificação de tolerância, ficam alocados para sempre
+ * pods que toleram o taint com um `tolerationSeconds` especificado, permanecem alocados pela quantidade de tempo definida
+
+O controlador de nó automaticamente adiciona um taint ao Nó quando certas condições se tornam verdadeiras. Os seguintes taints são embutidos:
+
+ * `node.kubernetes.io/not-ready`: Nó não está pronto. Isso corresponde ao NodeCondition `Ready` com o valor "`False`".
+ * `node.kubernetes.io/unreachable`: Nó é inalcançável a partir do controlador de nó. Isso corresponde ao NodeCondition `Ready` com o valor "`Unknown`".
+ * `node.kubernetes.io/memory-pressure`: Nó possui pressão de memória.
+ * `node.kubernetes.io/disk-pressure`: Nó possui pressão de disco.
+ * `node.kubernetes.io/pid-pressure`: Nó possui pressão de PID.
+ * `node.kubernetes.io/network-unavailable`: A rede do nó está indisponível.
+ * `node.kubernetes.io/unschedulable`: Nó não é alocável.
+ * `node.cloudprovider.kubernetes.io/uninitialized`: Quando o kubelet é iniciado com um provedor de nuvem "externo", esse taint é adicionado ao nó para que ele seja marcado como não utilizável. Após o controlador do cloud-controller-manager inicializar o nó, o kubelet remove esse taint.
+
+No caso de um nó estar prestes a ser expulso, o controlador de nó ou kubelet adicionam os taints relevantes com o efeito `NoExecute`. Se a condição de falha retorna ao normal, o kubelet ou controlador de nó podem remover esses taints.
+
+{{< note >}}
+A camada de gerenciamento limita a taxa de adição de novos taints aos nós. Esse limite gerencia o número de expulsões que são disparadas quando muitos nós se tornam inalcançáveis ao mesmo tempo (por exemplo: se ocorre uma falha na rede).
+{{< /note >}}
+
+Você pode especificar `tolerationSeconds` em um Pod para definir quanto tempo ele ficará alocado em um nó que está falhando ou está sem resposta.
+
+Por exemplo, você talvez queira manter uma aplicação com vários estados salvos localmente alocado em um nó por um longo período na ocorrência de uma divisão na rede, esperando que essa divisão se recuperará e assim a expulsão do pod pode ser evitada.
+A tolerância que você define para esse Pod poderia ficar assim:
+
+```yaml
+tolerations:
+- key: "node.kubernetes.io/unreachable"
+ operator: "Exists"
+ effect: "NoExecute"
+ tolerationSeconds: 6000
+```
+
+{{< note >}}
+O Kubernetes automaticamente adiciona uma tolerância para `node.kubernetes.io/not-ready` e `node.kubernetes.io/unreachable` com `tolerationSeconds=300`, a menos que você, ou um controlador, defina essas tolerâncias explicitamente.
+
+Essas tolerâncias adicionadas automaticamente significam que Pods podem continuar alocados aos Nós por 5 minutos após um desses problemas ser detectado.
+{{< /note >}}
+
+Pods do tipo [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) são criados com tolerâncias `NoExecute` sem a propriedade `tolerationSeconds` para os seguintes taints:
+
+ * `node.kubernetes.io/unreachable`
+ * `node.kubernetes.io/not-ready`
+
+Isso garante que esses pods do DaemonSet nunca sejam expulsos por conta desses problemas.
+
+## Taints por condições de nó
+
+A camada de gerenciamento, usando o {{}} do nó, cria taints automaticamente com o efeito `NoSchedule` para [condições de nó](/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions).
+
+O agendador verifica taints, não condições de nó, quando realiza suas decisões de agendamento. Isso garante que as condições de nó não afetem diretamente o agendamento.
+Por exemplo, se a condição de nó `DiskPressure` está ativa, a camada de gerenciamento adiciona o taint `node.kubernetes.io/disk-pressure` e não aloca novos pods no nó afetado. Se a condição `MemoryPressure` está ativa, a camada de gerenciamento adiciona o taint `node.kubernetes.io/memory-pressure`.
+
+Você pode ignorar condições de nó para pods recém-criados adicionando tolerâncias correspondentes. A camada de controle também adiciona a tolerância `node.kubernetes.io/memory-pressure` em pods que possuem uma {{< glossary_tooltip text="classe de QoS" term_id="qos-class" >}} diferente de `BestEffort`. Isso ocorre porque o Kubernetes trata pods nas classes de QoS `Guaranteed` ou `Burstable` (até mesmo pods sem requisitos de memória definidos) como se fossem capazes de lidar com pressão de memória, enquanto novos pods com `BestEffort` não são alocados no nó afetado.
+
+O controlador DaemonSet adiciona automaticamente as seguintes tolerâncias de `NoSchedule` para todos os daemons, prevenindo que DaemonSets quebrem.
+
+ * `node.kubernetes.io/memory-pressure`
+ * `node.kubernetes.io/disk-pressure`
+ * `node.kubernetes.io/pid-pressure` (1.14 ou superior)
+ * `node.kubernetes.io/unschedulable` (1.10 ou superior)
+ * `node.kubernetes.io/network-unavailable` (*somente rede do host*)
+
+Adicionando essas tolerâncias garante retro compatibilidade. Você também pode adicionar tolerâncias de forma arbitrária aos DaemonSets.
+
+## {{% heading "whatsnext" %}}
+
+* Leia sobre [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) e como você pode configurá-la
+* Leia sobre [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
+
+
diff --git a/content/pt-br/docs/reference/glossary/addons.md b/content/pt-br/docs/reference/glossary/addons.md
new file mode 100644
index 0000000000..c3659ed738
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/addons.md
@@ -0,0 +1,17 @@
+---
+title: Complementos
+id: addons
+date: 2019-12-15
+full_link: /pt-br/docs/concepts/cluster-administration/addons/
+short_description: >
+ Recursos que estendem a funcionalidade do Kubernetes.
+
+aka:
+tags:
+- tool
+---
+ Recursos que estendem a funcionalidade do Kubernetes.
+
+
+[Instalando Complementos](/pt-br/docs/concepts/cluster-administration/addons/) explica mais sobre a utilização de complementos em seu cluster e lista
+alguns complementos populares.
diff --git a/content/pt-br/docs/reference/glossary/configmap.md b/content/pt-br/docs/reference/glossary/configmap.md
new file mode 100644
index 0000000000..a1ccdea668
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/configmap.md
@@ -0,0 +1,18 @@
+---
+title: ConfigMap
+id: configmap
+date: 2021-08-24
+full_link: /docs/concepts/configuration/configmap
+short_description: >
+ Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor. Pode ser consumido como variáveis de ambiente, argumentos de linha de comando, ou arquivos de configuração em um volume.
+
+aka:
+tags:
+- core-object
+---
+Um objeto da API usado para armazenar dados não-confidenciais em pares chave-valor.
+{{< glossary_tooltip text="Pods" term_id="pod" >}} podem consumir ConfigMaps como variáveis de ambiente, argumentos de linha de comando ou como arquivos de configuração em um {{< glossary_tooltip text="volume" term_id="volume" >}}.
+
+
+
+Um ConfigMap ajuda a desacoplar configurações vinculadas ao ambiente das {{< glossary_tooltip text="imagens de contêiner" term_id="image" >}}, de modo a tornar aplicações mais facilmente portáveis.
\ No newline at end of file
diff --git a/content/pt-br/docs/reference/glossary/image.md b/content/pt-br/docs/reference/glossary/image.md
new file mode 100644
index 0000000000..d521557500
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/image.md
@@ -0,0 +1,17 @@
+---
+title: Imagem
+id: image
+date: 2021-08-24
+full_link:
+short_description: >
+ Instância armazenada de um contêiner que contém o conjunto de softwares necessários para rodar uma aplicação.
+
+aka:
+tags:
+- fundamental
+---
+ Instância armazenada de um {{< glossary_tooltip text="contêiner" term_id="container" >}} que contém o conjunto de softwares necessários para rodar uma aplicação.
+
+
+
+É uma forma de empacotamento de software que permite que este seja armazenado em um _container registry_, copiado para um sistema local e executado como uma aplicação. Metadados são incluídos na imagem para indicar qual programa deve ser executado, quem produziu a imagem, além de outras informações.
diff --git a/content/pt-br/docs/reference/glossary/index.md b/content/pt-br/docs/reference/glossary/index.md
new file mode 100644
index 0000000000..89cea39e44
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/index.md
@@ -0,0 +1,11 @@
+---
+title: Glossário
+layout: glossary
+noedit: true
+default_active_tag: fundamental
+weight: 5
+card:
+ name: reference
+ weight: 10
+ title: Glossário
+---
diff --git a/content/pt-br/docs/reference/glossary/kubelet.md b/content/pt-br/docs/reference/glossary/kubelet.md
index 16b55527fb..6a0d0ac415 100644
--- a/content/pt-br/docs/reference/glossary/kubelet.md
+++ b/content/pt-br/docs/reference/glossary/kubelet.md
@@ -2,7 +2,7 @@
title: Kubelet
id: kubelet
date: 2020-04-19
-full_link: /docs/reference/generated/kubelet
+full_link: /docs/reference/command-line-tools-reference/kubelet
short_description: >
Um agente que é executado em cada node no cluster. Ele garante que os contêineres estejam sendo executados em um pod.
diff --git a/content/pt-br/docs/reference/glossary/namespace.md b/content/pt-br/docs/reference/glossary/namespace.md
new file mode 100644
index 0000000000..e20031277d
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/namespace.md
@@ -0,0 +1,18 @@
+---
+title: Namespace
+id: namespace
+date: 2021-09-17
+full_link: /docs/concepts/overview/working-with-objects/namespaces
+short_description: >
+ Uma abstração utilizada pelo Kubernetes para suportar múltiplos clusters virtuais no mesmo cluster físico.
+
+aka:
+tags:
+- fundamental
+---
+ Uma abstração utilizada pelo Kubernetes para suportar múltiplos clusters virtuais no mesmo {{< glossary_tooltip text="cluster" term_id="cluster" >}} físico.
+
+
+
+Namespaces são utilizados para organizar objetos em um cluster e oferecer uma forma de separar os recursos do cluster. Os nomes dos recursos precisam ser únicos dentro de um namespace,
+mas não entre todos os namespaces existentes.
diff --git a/content/pt-br/docs/reference/glossary/operator-pattern.md b/content/pt-br/docs/reference/glossary/operator-pattern.md
new file mode 100644
index 0000000000..001207f5cf
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/operator-pattern.md
@@ -0,0 +1,24 @@
+---
+title: Padrão Operador
+id: operator-pattern
+date: 2021-09-17
+full_link: /pt-br/docs/concepts/extend-kubernetes/operator/
+short_description: >
+ Um controlador especializado que gerencia um recurso personalizado.
+
+aka:
+tags:
+- architecture
+---
+ O [padrão Operador](/docs/concepts/extend-kubernetes/operator/) é um design de
+sistema que vincula um {{< glossary_tooltip text="controlador" term_id="controller" >}}
+a um ou mais recursos personalizados.
+
+
+
+Você pode estender a funcionalidade do Kubernetes adicionando controladores ao seu cluster,
+além dos controladores que são distribuídos como parte do Kubernetes.
+
+Se uma aplicação em execução age como um controlador e tem acesso à API para desempenhar
+tarefas em um recurso personalizado que está definido na camada de gerenciamento, este é
+um exemplo do padrão Operador.
diff --git a/content/pt-br/docs/reference/glossary/pod.md b/content/pt-br/docs/reference/glossary/pod.md
index 9f6e21d6b3..2414223e43 100644
--- a/content/pt-br/docs/reference/glossary/pod.md
+++ b/content/pt-br/docs/reference/glossary/pod.md
@@ -2,7 +2,7 @@
title: Pod
id: pod
date: 2020-04-19
-full_link: /docs/concepts/workloads/pods/pod-overview/
+full_link: /docs/concepts/workloads/pods/
short_description: >
O menor e mais simples objeto Kubernetes. Um Pod representa um conjunto de contêineres em execução no seu cluster.
aka:
diff --git a/content/pt-br/docs/reference/glossary/secret.md b/content/pt-br/docs/reference/glossary/secret.md
new file mode 100644
index 0000000000..abcd1bb421
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/secret.md
@@ -0,0 +1,18 @@
+---
+title: Secret
+id: secret
+date: 2021-08-24
+full_link: /docs/concepts/configuration/secret/
+short_description: >
+ Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH.
+
+aka:
+tags:
+- core-object
+- security
+---
+ Armazena dados sensíveis, como senhas, tokens OAuth e chaves SSH.
+
+
+
+Permite mais controle com relação a como as informações sensíveis são armazenadas e reduz o risco de exposição acidental. Os valores dos Secrets são codificados como strings no formato base64, mas não encriptados por padrão. É possível configurar o cluster para realizar a [encriptação em disco](/docs/tasks/administer-cluster/encrypt-data/#ensure-all-secrets-are-encrypted) de Secrets. Um {{< glossary_tooltip text="Pod" term_id="pod" >}} pode referenciar o Secret como um arquivo em um volume montado, ou o kubelet pode usar este dado quando baixa imagens para um pod. Secrets são úteis para dados confidenciais, enquanto [ConfigMaps](/docs/tasks/configure-pod-container/configure-pod-configmap/) são úteis para dados não-confidenciais.
diff --git a/content/pt-br/docs/reference/glossary/selector.md b/content/pt-br/docs/reference/glossary/selector.md
new file mode 100644
index 0000000000..4fd72b58a0
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/selector.md
@@ -0,0 +1,17 @@
+---
+title: Seletor
+id: selector
+date: 2021-09-17
+full_link: /docs/concepts/overview/working-with-objects/labels/
+short_description: >
+ Permite ao usuário filtrar uma lista de recursos com base em rótulos (labels).
+
+aka:
+tags:
+- fundamental
+---
+ Permite ao usuário filtrar uma lista de recursos com base em {{< glossary_tooltip text="labels" term_id="label" >}} (rótulos).
+
+
+
+Seletores são aplicados quando um usuário faz uma pesquisa por listas de recursos para filtrá-los por labels (rótulos).
diff --git a/content/pt-br/docs/reference/glossary/service.md b/content/pt-br/docs/reference/glossary/service.md
new file mode 100644
index 0000000000..cc6d976dc4
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/service.md
@@ -0,0 +1,20 @@
+---
+title: Service
+id: service
+date: 2021-09-17
+full_link: /docs/concepts/services-networking/service/
+short_description: >
+ Uma forma abstrata de expor uma aplicação que está executando em um conjunto de Pods como um serviço de rede.
+
+aka:
+tags:
+- fundamental
+- core-object
+---
+Uma forma abstrata de expor uma aplicação que está executando em um conjunto de {{< glossary_tooltip text="Pods" term_id="pod" >}} como um serviço de rede.
+
+
+
+ O conjunto de Pods referenciado por um Service é (geralmente) determinado por um {{< glossary_tooltip text="seletor" term_id="selector" >}}. Se mais Pods são
+ adicionados ou removidos, o conjunto de Pods que atende ao critério do seletor será alterado. O Service garante que o tráfego de rede pode ser direcionado ao
+ conjunto atual de Pods para a carga de trabalho.
diff --git a/content/pt-br/docs/reference/glossary/static-pod.md b/content/pt-br/docs/reference/glossary/static-pod.md
new file mode 100644
index 0000000000..55ba56bb53
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/static-pod.md
@@ -0,0 +1,19 @@
+---
+title: Pod estático
+id: static-pod
+date: 2021-09-17
+full_link: /docs/tasks/configure-pod-container/static-pod/
+short_description: >
+ Um pod gerenciado diretamente pelo daemon do kubelet em um nó específico.
+
+aka:
+tags:
+- fundamental
+---
+
+Um {{< glossary_tooltip text="pod" term_id="pod" >}} gerenciado diretamente pelo
+ daemon do kubelet em um nó específico,
+
+
+
+que não é observado pelo servidor de API.
\ No newline at end of file
diff --git a/content/pt-br/docs/reference/glossary/volume.md b/content/pt-br/docs/reference/glossary/volume.md
new file mode 100644
index 0000000000..502d2db6f1
--- /dev/null
+++ b/content/pt-br/docs/reference/glossary/volume.md
@@ -0,0 +1,20 @@
+---
+title: Volume
+id: volume
+date: 2021-08-24
+full_link: /docs/concepts/storage/volumes/
+short_description: >
+ Um diretório contendo dados, accessível aos contêineres em um pod.
+
+aka:
+tags:
+- core-object
+- fundamental
+---
+ Um diretório contendo dados, accessível aos {{< glossary_tooltip text="contêineres" term_id="container" >}} em um {{< glossary_tooltip term_id="pod" >}}.
+
+
+
+Um volume do Kubernetes existe enquanto o Pod que utiliza ele existir também. Consequentemente, um volume dura mais tempo que qualquer contêiner que rodar em um Pod, e os dados no volume são preservados entre reinicializações do contêiner.
+
+Veja [armazenamento](/docs/concepts/storage/) para mais detalhes.
diff --git a/content/pt-br/docs/tutorials/_index.md b/content/pt-br/docs/tutorials/_index.md
index bc39fd817a..637ed4e6e8 100644
--- a/content/pt-br/docs/tutorials/_index.md
+++ b/content/pt-br/docs/tutorials/_index.md
@@ -47,6 +47,8 @@ Antes de iniciar um tutorial, é interessante que vocẽ salve a página de [Glo
* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
+
## Serviços / "Services"
* [Usando IP de origem](/docs/tutorials/services/source-ip/)
diff --git a/content/pt-br/examples/pods/pod-with-toleration.yaml b/content/pt-br/examples/pods/pod-with-toleration.yaml
new file mode 100644
index 0000000000..79f2756a8c
--- /dev/null
+++ b/content/pt-br/examples/pods/pod-with-toleration.yaml
@@ -0,0 +1,15 @@
+apiVersion: v1
+kind: Pod
+metadata:
+ name: nginx
+ labels:
+ env: test
+spec:
+ containers:
+ - name: nginx
+ image: nginx
+ imagePullPolicy: IfNotPresent
+ tolerations:
+ - key: "example-key"
+ operator: "Exists"
+ effect: "NoSchedule"
diff --git a/content/ru/docs/concepts/architecture/_index.md b/content/ru/docs/concepts/architecture/_index.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/concepts/architecture/controller.md b/content/ru/docs/concepts/architecture/controller.md
index c47fcaed95..4f28a51836 100644
--- a/content/ru/docs/concepts/architecture/controller.md
+++ b/content/ru/docs/concepts/architecture/controller.md
@@ -44,11 +44,11 @@ weight: 30
(После [планирования](/docs/concepts/scheduling-eviction/), Pod объекты становятся частью желаемого состояния для kubelet).
-Когда контроллер задания видить новую задачу, он убеждается что где-то в вашем кластере kubelet-ы на множестве узлов запускают нужное количество Pod-ов для выполнения работы.
-Контроллер задания сам по себе не запускает никакие Pod-ы или контейнеры. Вместо этого контроллер задания Iсообщает серверу API о создании или удалении Pod-ов.
+Когда контроллер задания видит новую задачу, он убеждается что где-то в вашем кластере kubelet-ы на множестве узлов запускают нужное количество Pod-ов для выполнения работы.
+Контроллер задания сам по себе не запускает никакие Pod-ы или контейнеры. Вместо этого контроллер задания сообщает серверу API о создании или удалении Pod-ов.
Другие компоненты в
{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}
-действуют на основе информации (имеются ли новые заплонированные Pod-ы для запуска), и в итоге работка заверщается.
+действуют на основе информации (имеются ли новые запланированные Pod-ы для запуска), и в итоге работа завершается.
После того, как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этого задания к желаемому состоянию: создает Pod-ы, которые выполняют работу, которую вы хотели для этого задания, чтобы задание было ближе к завершению.
@@ -62,12 +62,11 @@ weight: 30
В отличие от Задания, некоторым контроллерам нужно вносить изменения в вещи за пределами вашего кластера.
Например, если вы используете контур управления, чтобы убедиться, что в вашем кластере достаточно {{< glossary_tooltip text="Узлов" term_id="node" >}},
-тогда этому контроллеру нужно что-то вне текущего кластера, чтобы при необъодимости установить новые узлы.
+тогда этому контроллеру нужно что-то вне текущего кластера, чтобы при необходимости запустить новые узлы.
Контроллеры, которые взаимодействуют с внешним состоянием, находят свое желаемое состояние с сервера API, а затем напрямую взаимодействуют с внешней системой, чтобы приблизить текущее состояние.
-(На самом деле существует [контроллер](https://github.com/kubernetes/autoscaler/)
-, который горизонтально маштабирует узла в вашем кластере.)
+(На самом деле существует [контроллер](https://github.com/kubernetes/autoscaler/), который горизонтально маштабирует узлы в вашем кластере.)
Важным моментом здесь является то, что контроллер вносит некоторые изменения, чтобы вызвать желаемое состояние, а затем сообщает текущее состояние обратно на сервер API вашего кластера. Другие контуры управления могут наблюдать за этими отчетными данными и предпринимать собственные действия.
diff --git a/content/ru/docs/concepts/overview/working-with-objects/_index.md b/content/ru/docs/concepts/overview/working-with-objects/_index.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/cloud-provider.md b/content/ru/docs/reference/glossary/cloud-provider.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/container.md b/content/ru/docs/reference/glossary/container.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/controller.md b/content/ru/docs/reference/glossary/controller.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/daemonset.md b/content/ru/docs/reference/glossary/daemonset.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/deployment.md b/content/ru/docs/reference/glossary/deployment.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/docker.md b/content/ru/docs/reference/glossary/docker.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/etcd.md b/content/ru/docs/reference/glossary/etcd.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/kube-apiserver.md b/content/ru/docs/reference/glossary/kube-apiserver.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/kube-controller-manager.md b/content/ru/docs/reference/glossary/kube-controller-manager.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/kube-proxy.md b/content/ru/docs/reference/glossary/kube-proxy.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/kube-scheduler.md b/content/ru/docs/reference/glossary/kube-scheduler.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/kubelet.md b/content/ru/docs/reference/glossary/kubelet.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/label.md b/content/ru/docs/reference/glossary/label.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/name.md b/content/ru/docs/reference/glossary/name.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/node.md b/content/ru/docs/reference/glossary/node.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/pod.md b/content/ru/docs/reference/glossary/pod.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/selector.md b/content/ru/docs/reference/glossary/selector.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/service.md b/content/ru/docs/reference/glossary/service.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/glossary/uid.md b/content/ru/docs/reference/glossary/uid.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/reference/kubectl/_index.md b/content/ru/docs/reference/kubectl/_index.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/tasks/configure-pod-container/_index.md b/content/ru/docs/tasks/configure-pod-container/_index.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/tasks/tools/_index.md b/content/ru/docs/tasks/tools/_index.md
old mode 100755
new mode 100644
diff --git a/content/ru/docs/tutorials/_index.md b/content/ru/docs/tutorials/_index.md
index e251975329..6cbe48cbe4 100644
--- a/content/ru/docs/tutorials/_index.md
+++ b/content/ru/docs/tutorials/_index.md
@@ -47,6 +47,8 @@ content_type: concept
* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
+
## Сервисы
* [Использование IP](/docs/tutorials/services/source-ip/)
diff --git a/content/ru/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/ru/docs/tutorials/kubernetes-basics/expose/expose-intro.html
index 3ef66070ff..07cb3cd2df 100644
--- a/content/ru/docs/tutorials/kubernetes-basics/expose/expose-intro.html
+++ b/content/ru/docs/tutorials/kubernetes-basics/expose/expose-intro.html
@@ -31,7 +31,7 @@ weight: 10
Сервис в Kubernetes — это абстрактный объект, который определяет логический набор подов и политику доступа к ним. Сервисы создают слабую связь между подами, которые от них зависят. Сервис создаётся в формате YAML (рекомендуемый формат) или JSON, как и все остальные объекты в Kubernetes. Как правило, набор подов для сервиса определяется LabelSelector (ниже описано, в каких случаях понадобиться сервис без указания selector в спецификации).
-
Хотя у каждого пода есть уникальный IP-адрес, эти IP-адреса не доступны за пределами кластера без использования сервиса. Сервисы позволяют приложениям принимать трафик. Сервисы могут по-разному открыты, в зависимости от указанного поля type в ServiceSpec:
+
Хотя у каждого пода есть уникальный IP-адрес, эти IP-адреса не доступны за пределами кластера без использования сервиса. Сервисы позволяют приложениям принимать трафик. Сервисы могут быть по-разному открыты, в зависимости от указанного поля type в ServiceSpec:
ClusterIP (по умолчанию) - открывает доступ к сервису по внутреннему IP-адресу в кластере. Этот тип делает сервис доступным только внутри кластера.
NodePort - открывает сервис на одном и том же порту каждого выбранного узла в кластере с помощью NAT. Делает сервис доступным вне кластера, используя <NodeIP>:<NodePort>. Является надмножеством ClusterIP.
diff --git a/content/uk/docs/tutorials/_index.md b/content/uk/docs/tutorials/_index.md
index c87a5155a0..a249e4814c 100644
--- a/content/uk/docs/tutorials/_index.md
+++ b/content/uk/docs/tutorials/_index.md
@@ -63,6 +63,8 @@ Before walking through each tutorial, you may want to bookmark the
* [AppArmor](/docs/tutorials/clusters/apparmor/)
+* [seccomp](/docs/tutorials/clusters/seccomp/)
+
## Сервіси
* [Використання Source IP](/docs/tutorials/services/source-ip/)
diff --git a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md
index 65292d90ac..d873fab049 100644
--- a/content/zh/blog/_posts/2020-12-02-dockershim-faq.md
+++ b/content/zh/blog/_posts/2020-12-02-dockershim-faq.md
@@ -45,7 +45,7 @@ You can read more about the community discussion and planning in the
-->
Dockershim 向来都是一个临时解决方案（因此得名：shim）。
你可以进一步阅读
-[移除 Kubernetes 增强方案 Dockershim](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1985-remove-dockershim)
+[移除 Kubernetes 增强方案 Dockershim][drkep]
以了解相关的社区讨论和计划。
@@ -78,12 +79,16 @@ startup if using Docker as the runtime.
考虑到此改变带来的影响，我们使用了一个加长的废弃时间表。
在 Kubernetes 1.22 版之前，它不会被彻底移除；换句话说，dockershim 被移除的最早版本会是 2021 年底发布的 1.23 版。
+_更新_：dockershim 计划在 Kubernetes 1.24 版被移除，
+请参阅[移除 Kubernetes 增强方案 Dockershim][drkep]。
我们将与供应商以及其他生态团队紧密合作，确保顺利过渡，并将依据事态的发展评估后续事项。
### 优先级 {#Priority-Levels}
@@ -219,8 +219,9 @@ server.
The Priority and Fairness feature ships with a suggested configuration that
should suffice for experimentation; if your cluster is likely to
-experience heavy load then you should consider what configuration will work best.
-The suggested configuration groups requests into five priority classes:
+experience heavy load then you should consider what configuration will work
+best. The suggested configuration groups requests into five priority
+classes:
-->
## 默认值 {#defaults}
@@ -418,8 +419,8 @@ to balance progress between request flows.
公平排队算法支持通过排队配置对优先级微调。 可以在[增强建议](#whats-next)中阅读算法的详细信息，但总之：
@@ -450,7 +451,7 @@ proposal](#whats-next), but in short:
a small number of flows can dominate the apiserver. A larger `handSize` also
potentially increases the amount of latency that a single high-traffic flow
can cause. The maximum number of queued requests possible from a
- single flow is `handSize *queueLengthLimit`.
+ single flow is `handSize * queueLengthLimit`.
{{< /note >}}
-->
* 修改 `handSize` 允许你调整过载情况下不同流之间的冲突概率以及单个流可用的整体并发性。
@@ -459,7 +460,7 @@ proposal](#whats-next), but in short:
较大的 `handSize` 使两个单独的流程发生碰撞的可能性较小（因此，一个流可以饿死另一个流），
但是更有可能的是少数流可以控制 apiserver。
较大的 `handSize` 还可能增加单个高并发流的延迟量。
- 单个流中可能排队的请求的最大数量为 `handSize *queueLengthLimit` 。
+ 单个流中可能排队的请求的最大数量为 `handSize * queueLengthLimit` 。
{{< /note >}}
* `apiserver_flowcontrol_rejected_requests_total` 是一个计数器向量，
记录被拒绝的请求数量（自服务器启动以来累计值），
@@ -725,6 +727,14 @@ poorly-behaved workloads that may be harming system health.
记录包含执行中（不在队列中等待）请求的瞬时数量，
由标签 `priority_level` 和 `flow_schema` 进一步区分。
+
+* `apiserver_flowcontrol_request_concurrency_in_use` 是一个规范向量，
+ 包含占用座位的瞬时数量，由标签 `priority_level` 和 `flow_schema` 进一步区分。
+
### 调试端点 {#Debug-endpoints}
启用 APF 特性后， kube-apiserver 会在其 HTTP/HTTPS 端口提供以下路径：
- `/debug/api_priority_and_fairness/dump_priority_levels` ——
所有优先级及其当前状态的列表。你可以这样获取：
@@ -856,7 +866,7 @@ You can fetch like this:
输出类似于：
- ```
+ ```none
PriorityLevelName, ActiveQueues, IsIdle, IsQuiescing, WaitingRequests, ExecutingRequests,
workload-low, 0, true, false, 0, 0,
global-default, 0, true, false, 0, 0,
@@ -868,8 +878,8 @@ You can fetch like this:
```
- `/debug/api_priority_and_fairness/dump_queues` —— 所有队列及其当前状态的列表。
你可以这样获取：
@@ -881,7 +891,7 @@ You can fetch like this:
输出类似于：
- ```
+ ```none
PriorityLevelName, Index, PendingRequests, ExecutingRequests, VirtualStart,
workload-high, 0, 0, 0, 0.0000,
workload-high, 1, 0, 0, 0.0000,
@@ -892,8 +902,8 @@ You can fetch like this:
```
- `/debug/api_priority_and_fairness/dump_requests` ——当前正在队列中等待的所有请求的列表。
你可以这样获取：
@@ -905,15 +915,15 @@ You can fetch like this:
输出类似于：
- ```
+ ```none
PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime,
exempt, , , , , ,
system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:26:57.179170694Z,
```
针对每个优先级别，输出中还包含一条虚拟记录，对应豁免限制。
@@ -925,8 +935,9 @@ You can fetch like this:
```
+
输出类似于：
- ```
+ ```none
PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource,
system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
system, system-nodes, 12, 1, system:node:127.0.0.1, 2020-07-23T15:31:03.594555947Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps,
@@ -935,14 +946,13 @@ You can fetch like this:
## {{% heading "whatsnext" %}}
有关API优先级和公平性的设计细节的背景信息，
-请参阅[增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190228-priority-and-fairness.md)。
+请参阅[增强建议](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness)。
你可以通过 [SIG APIMachinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery/)
或特性的 [Slack 频道](https://kubernetes.slack.com/messages/api-priority-and-fairness/)
提出建议和特性请求。
diff --git a/content/zh/docs/concepts/cluster-administration/system-traces.md b/content/zh/docs/concepts/cluster-administration/system-traces.md
new file mode 100644
index 0000000000..c829341afd
--- /dev/null
+++ b/content/zh/docs/concepts/cluster-administration/system-traces.md
@@ -0,0 +1,156 @@
+---
+title: 追踪 Kubernetes 系统组件
+content_type: concept
+weight: 60
+---
+
+
+
+
+{{< feature-state for_k8s_version="v1.22" state="alpha" >}}
+
+
+系统组件追踪功能记录各个集群操作的时延信息和这些操作之间的关系。
+
+
+Kubernetes 组件基于 gRPC 导出器的
+[OpenTelemetry 协议](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#opentelemetry-protocol-specification)
+发送追踪信息，并用
+[OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector#-opentelemetry-collector)
+收集追踪信息，再将其转交给追踪系统的后台。
+
+
+
+
+## 追踪信息的收集 {#trace-collection}
+
+
+关于收集追踪信息、以及使用收集器的完整指南，可参见
+[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)。
+不过，还有一些特定于 Kubernetes 组件的事项值得注意。
+
+
+默认情况下，Kubernetes 组件使用 gRPC 的 OTLP 导出器来导出追踪信息，将信息写到
+[IANA OpenTelemetry 端口](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=opentelemetry)。
+举例来说，如果收集器以 Kubernetes 组件的边车模式运行，以下接收器配置会收集 spans 信息，并将它们写入到标准输出。
+
+
+```yaml
+receivers:
+ otlp:
+ protocols:
+ grpc:
+exporters:
+ # 用适合你后端环境的导出器替换此处的导出器
+ logging:
+ logLevel: debug
+service:
+ pipelines:
+ traces:
+ receivers: [otlp]
+ exporters: [logging]
+```
+
+
+## 组件追踪 {#component-traces}
+
+### kube-apiserver 追踪 {#kube-apiserver-traces}
+
+
+kube-apiserver 为传入的 HTTP 请求、传出到 webhook 和 etcd 的请求以及重入的请求生成 spans。
+由于 kube-apiserver 通常是一个公开的端点，所以它通过出站的请求传播
+[W3C 追踪上下文](https://www.w3.org/TR/trace-context/)，
+但不使用入站请求的追踪上下文。
+
+
+#### 在 kube-apiserver 中启用追踪 {#enabling-tracing-in-the-kube-apiserver}
+
+
+要启用追踪特性，需要启用 kube-apiserver 上的 `APIServerTracing`
+[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。
+然后，使用 `--tracing-config-file=<<配置文件路径>` 为 kube-apiserver 提供追踪配置文件。
+下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。
+
+```yaml
+apiVersion: apiserver.config.k8s.io/v1alpha1
+kind: TracingConfiguration
+# default value
+#endpoint: localhost:4317
+samplingRatePerMillion: 100
+```
+
+
+有关 TracingConfiguration 结构体的更多信息，请参阅
+[API 服务器配置 API (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。
+
+
+## 稳定性 {#stability}
+
+
+追踪工具仍在积极开发中，未来它会以多种方式发生变化。
+这些变化包括：span 名称、附加属性、检测端点等等。
+此类特性在达到稳定版本之前，不能保证追踪工具的向后兼容性。
+
+## {{% heading "whatsnext" %}}
+
+
+* 阅读[Getting Started with the OpenTelemetry Collector](https://opentelemetry.io/docs/collector/getting-started/)
\ No newline at end of file
diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md
index 53a301f03e..0d018141a7 100644
--- a/content/zh/docs/concepts/configuration/secret.md
+++ b/content/zh/docs/concepts/configuration/secret.md
@@ -22,47 +22,58 @@ weight: 30
-
-
-`Secret` 对象类型用来保存敏感信息，例如密码、OAuth 令牌和 SSH 密钥。
-将这些信息放在 `secret` 中比放在 {{< glossary_tooltip term_id="pod" >}} 的定义或者 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 中来说更加安全和灵活。
-参阅 [Secret 设计文档](https://git.k8s.io/community/contributors/design-proposals/auth/secrets.md) 获取更多详细信息。
-
Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。
-这样的信息可能会被放在 Pod 规约中或者镜像中。
-用户可以创建 Secret，同时系统也创建了一些 Secret。
+这样的信息可能会被放在 {{< glossary_tooltip term_id="pod" >}} 规约中或者镜像中。
+使用 Secret 意味着你不需要在应用程序代码中包含机密数据。
+
+
+由于创建 Secret 可以独立于使用它们的 Pod，
+因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret（及其数据）的风险较小。
+Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施，
+例如避免将机密数据写入非易失性存储。
+
+Secret 类似于 {{}}
+但专门用于保存机密数据。
{{< caution >}}
-Kubernetes Secret 默认情况下存储为 base64-编码的、非加密的字符串。
-默认情况下，能够访问 API 的任何人，或者能够访问 Kubernetes 下层数据存储（etcd）
-的任何人都可以以明文形式读取这些数据。
-为了能够安全地使用 Secret，我们建议你（至少）：
+默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。
+任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。
+此外，任何有权限在命名空间中创建 Pod 的人都可以使用该访问权限读取该命名空间中的任何 Secret；
+这包括间接访问，例如创建 Deployment 的能力。
+
+为了安全地使用 Secret，请至少执行以下步骤：
1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)；
-2. [启用 或配置 RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制对 Secret 的读写操作。
- 要注意，任何被允许创建 Pod 的人都默认地具有读取 Secret 的权限。
+2. 启用或配置 [RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取 Secret 的数据（包括通过间接方式）。
+3. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。
{{< /caution >}}
@@ -89,6 +100,15 @@ Pod 可以用三种方式之一来使用 Secret：
- 作为[容器的环境变量](#using-secrets-as-environment-variables)
- 由 [kubelet 在为 Pod 拉取镜像时使用](#using-imagepullsecrets)
+
+Kubernetes 控制平面也使用 Secret；
+例如，[引导令牌 Secret](#bootstrap-token-secrets)
+是一种帮助自动化节点注册的机制。
+
## Secret 的类型 {#secret-types}
-在创建 Secret 对象时，你可以使用
-[`Secret`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#secret-v1-core)
-资源的 `type` 字段，或者与其等价的 `kubectl` 命令行参数（如果有的话）为其设置类型。
-Secret 的类型用来帮助编写程序处理 Secret 数据。
+创建 Secret 时，你可以使用 Secret 资源的 `type` 字段，
+或者与其等价的 `kubectl` 命令行参数（如果有的话）为其设置类型。
+Secret 的 `type` 有助于对不同类型机密数据的编程处理。
Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。
针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。
@@ -553,13 +572,13 @@ kubectl create secret tls my-tls-secret \
```
这里的公钥/私钥对都必须事先已存在。用于 `--cert` 的公钥证书必须是 .PEM 编码的
（Base64 编码的 DER 格式），且与 `--key` 所给定的私钥匹配。
@@ -1334,6 +1353,8 @@ This includes any pods created using kubectl, or indirectly via a replication
controller. It does not include pods created via the kubelets
`--manifest-url` flag, its `--config` flag, or its REST API (these are
not common ways to create pods.)
+The `spec` of a {{< glossary_tooltip text="static Pod" term_id="static-pod" >}} cannot refer to a Secret
+or any other API objects.
-->
每个 Secret 的大小限制为 1MB。这是为了防止创建非常大的 Secret 导致 API 服务器
和 kubelet 的内存耗尽。然而，创建过多较小的 Secret 也可能耗尽内存。
@@ -1343,6 +1364,8 @@ kubelet 仅支持从 API 服务器获得的 Pod 使用 Secret。
这包括使用 `kubectl` 创建的所有 Pod，以及间接通过副本控制器创建的 Pod。
它不包括通过 kubelet `--manifest-url` 标志，`--config` 标志或其 REST API
创建的 Pod（这些不是创建 Pod 的常用方法）。
+{{}}
+的 `spec` 不能引用 Secret 或任何其他 API 对象。
### 风险
@@ -1968,9 +1987,6 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa
- 如果您将 Secret 数据编码为 base64 的清单（JSON 或 YAML）文件，共享该文件或将其检入代码库，该密码将会被泄露。 Base64 编码不是一种加密方式，应该视同纯文本。
- 应用程序在从卷中读取 Secret 后仍然需要保护 Secret 的值，例如不会意外将其写入日志或发送给不信任方。
- 可以创建使用 Secret 的 Pod 的用户也可以看到该 Secret 的值。即使 API 服务器策略不允许用户读取 Secret 对象，用户也可以运行 Pod 导致 Secret 暴露。
-- 目前，任何节点的 root 用户都可以通过模拟 kubelet 来读取 API 服务器中的任何 Secret。
- 仅向实际需要 Secret 的节点发送 Secret 数据才能限制节点的 root 账号漏洞的影响，
- 该功能还在计划中。
## {{% heading "whatsnext" %}}
@@ -1978,8 +1994,10 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa
- Learn how to [manage Secret using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- Read the [API reference](/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/) for `Secret`
-->
- 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
- 学习如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/)
- 学习如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
+- 阅读 [API 参考](/zh/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret`
diff --git a/content/zh/docs/concepts/containers/container-environment.md b/content/zh/docs/concepts/containers/container-environment.md
index 79170508e6..7e9a12be1b 100644
--- a/content/zh/docs/concepts/containers/container-environment.md
+++ b/content/zh/docs/concepts/containers/container-environment.md
@@ -89,10 +89,10 @@ FOO_SERVICE_PORT=
服务具有专用的 IP 地址。如果启用了
-[DNS插件](https://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/)，
+[DNS 插件](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addons/dns/)，
可以在容器中通过 DNS 来访问服务。
## {{% heading "whatsnext" %}}
diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh/docs/concepts/containers/images.md
index 0a629be864..1360faab32 100644
--- a/content/zh/docs/concepts/containers/images.md
+++ b/content/zh/docs/concepts/containers/images.md
@@ -29,7 +29,7 @@ This page provides an outline of the container image concept.
容器镜像是可执行的软件包，可以单独运行；该软件包对所处的运行时环境具有
良定（Well Defined）的假定。
-你通常会创建应用的容器镜像并将其推送到某仓库，然后在
+你通常会创建应用的容器镜像并将其推送到某仓库（Registry），然后在
{{< glossary_tooltip text="Pod" term_id="pod" >}} 中引用它。
本页概要介绍容器镜像的概念。
@@ -41,7 +41,7 @@ This page provides an outline of the container image concept.
Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`.
Images can also include a registry hostname; for example: `fictional.registry.example/imagename`,
-and possible a port number as well; for example: `fictional.registry.example:10443/imagename`.
+and possibly a port number as well; for example: `fictional.registry.example:10443/imagename`.
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
@@ -72,20 +72,6 @@ If you don't specify a tag, Kubernetes assumes you mean the tag `latest`.
关于在镜像标签中何处可以使用分隔字符（`_`、`-` 和 `.`）还有一些额外的规则。
如果你不指定标签，Kubernetes 认为你想使用标签 `latest`。
-
-{{< caution >}}
-你要避免在生产环境中使用 `latest` 标签，因为这会使得跟踪所运行的镜像版本变得
-非常困难，同时也很难回滚到之前运行良好的版本。
-
-正确的做法恰恰相反，你应该指定一个有意义的标签，如 `v1.42.0`。
-{{< /caution >}}
-
-如果你希望强制总是拉取镜像，你可以执行以下操作之一：
+### 镜像拉取策略 {#image-pull-policy}
-- 设置容器的 `imagePullPolicy` 为 `Always`。
-- 省略 `imagePullPolicy`，并使用 `:latest` 作为要使用的镜像的标签；
- Kubernetes 会将策略设置为 `Always`。
-- 省略 `imagePullPolicy` 和要使用的镜像标签。
-- 启用 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)
- 准入控制器（Admission Controller）。
+容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。
+
+以下列表包含了 `imagePullPolicy` 可以设置的值，以及这些值的效果：
+
+
+`IfNotPresent`
+: 只有当镜像在本地不存在时才会拉取。
+
+`Always`
+: 每当 kubelet 启动一个容器时，kubelet 会查询容器的镜像仓库，
+ 将名称解析为一个镜像[摘要](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier)。
+ 如果 kubelet 有一个容器镜像，并且对应的摘要已在本地缓存，kubelet 就会使用其缓存的镜像；
+ 否则，kubelet 就会使用解析后的摘要拉取镜像，并使用该镜像来启动容器。
+
+`Never`
+: Kubelet 不会尝试获取镜像。如果镜像已经以某种方式存在本地，
+ kubelet 会尝试启动容器；否则，会启动失败。
+ 更多细节见[提前拉取镜像](#pre-pulled-images)。
+
+
+只要能够可靠地访问镜像仓库，底层镜像提供者的缓存语义甚至可以使 `imagePullPolicy: Always` 高效。
+你的容器运行时可以注意到节点上已经存在的镜像层，这样就不需要再次下载。
+
+
+{{< note >}}
+在生产环境中部署容器时，你应该避免使用 `:latest` 标签，因为这使得正在运行的镜像的版本难以追踪，并且难以正确地回滚。
+
+相反，应指定一个有意义的标签，如 `v1.42.0`。
+{{< /note >}}
+
+为了确保 Pod 总是使用相同版本的容器镜像，你可以指定镜像的摘要；
+将 `:` 替换为 `@`，例如 `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`。
+
+
+当使用镜像标签时，如果镜像仓库修改了代码所对应的镜像标签，可能会出现新旧代码混杂在 Pod 中运行的情况。
+镜像摘要唯一标识了镜像的特定版本，因此 Kubernetes 每次启动具有指定镜像名称和摘要的容器时，都会运行相同的代码。
+指定一个镜像可以固定你所运行的代码，这样镜像仓库的变化就不会导致版本的混杂。
+
+有一些第三方的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)
+在创建 Pod（和 Pod 模板）时产生变更，这样运行的工作负载就是根据镜像摘要，而不是标签来定义的。
+无论镜像仓库上的标签发生什么变化，你都想确保你所有的工作负载都运行相同的代码，那么指定镜像摘要会很有用。
+
+
+#### 默认镜像拉取策略 {#imagepullpolicy-defaulting}
+
+当你（或控制器）向 API 服务器提交一个新的 Pod 时，你的集群会在满足特定条件时设置 `imagePullPolicy `字段：
+
+
+- 如果你省略了 `imagePullPolicy` 字段，并且容器镜像的标签是 `:latest`，
+ `imagePullPolicy` 会自动设置为 `Always`。
+- 如果你省略了 `imagePullPolicy` 字段，并且没有指定容器镜像的标签，
+ `imagePullPolicy` 会自动设置为 `Always`。
+- 如果你省略了 `imagePullPolicy` 字段，并且为容器镜像指定了非 `:latest` 的标签，
+ `imagePullPolicy` 就会自动设置为 `IfNotPresent`。
{{< note >}}
-对象被 *创建* 时，容器的 `imagePullPolicy` 总是被设置为某值，如果镜像的标签
-后来发生改变，镜像拉取策略也不会被改变。
+容器的 `imagePullPolicy` 的值总是在对象初次 _创建_ 时设置的，如果后来镜像的标签发生变化，则不会更新。
-例如，如果你创建了一个 Deployment 对象，其中的镜像标签不是 `:latest`，
-后来 Deployment 的镜像被改为 `:latest`，则 `imagePullPolicy` 不会被改变为
-`Always`。你必须在对象被初始创建之后手动改变拉取策略。
+例如，如果你用一个 _非_ `:latest` 的镜像标签创建一个 Deployment，
+并在随后更新该 Deployment 的镜像标签为 `:latest`，则 `imagePullPolicy` 字段 _不会_ 变成 `Always`。
+你必须手动更改已经创建的资源的拉取策略。
{{< /note >}}
-如果 `imagePullPolicy` 未被定义为特定的值，也会被设置为 `Always`。
+#### 必要的镜像拉取 {#required-image-pull}
+
+如果你想总是强制执行拉取，你可以使用下述的一中方式：
+
+- 设置容器的 `imagePullPolicy` 为 `Always`。
+- 省略 `imagePullPolicy`，并使用 `:latest` 作为镜像标签；
+ 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。
+- 省略 `imagePullPolicy` 和镜像的标签；
+ 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。
+- 启用准入控制器 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。
+
+
+
+### ImagePullBackOff
+
+当 kubelet 使用容器运行时创建 Pod 时，容器可能因为 `ImagePullBackOff` 导致状态为
+[Waiting](/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-state-waiting)。
+
+
+`ImagePullBackOff` 状态意味着容器无法启动，
+因为 Kubernetes 无法拉取容器镜像（原因包括无效的镜像名称，或从私有仓库拉取而没有 `imagePullSecret`）。
+ `BackOff` 部分表示 Kubernetes 将继续尝试拉取镜像，并增加回退延迟。
+
+Kubernetes 会增加每次尝试之间的延迟，直到达到编译限制，即 300 秒（5 分钟）。
-* 阅读 [OCI Image Manifest 规范](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
-
+* 阅读 [OCI Image Manifest 规范](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。
+* 了解[容器镜像垃圾收集](/zh/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。
diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh/docs/concepts/containers/runtime-class.md
index d1ed733804..a2cee358c1 100644
--- a/content/zh/docs/concepts/containers/runtime-class.md
+++ b/content/zh/docs/concepts/containers/runtime-class.md
@@ -89,10 +89,10 @@ RuntimeClass 假设集群中的节点配置是同构的（换言之，所有的
所有这些配置都具有相应的 `handler` 名，并被 RuntimeClass 引用。
-handler 必须符合 DNS-1123 命名规范（字母、数字、或 `-`）。
+handler 必须是有效的 [DNS 标签名](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。
-更详细信息，请查阅 CRI-O [配置文档](https://raw.githubusercontent.com/cri-o/cri-o/9f11d1d/docs/crio.conf.5.md)。
+更详细信息，请查阅 CRI-O [配置文档](https://github.com/cri-o/cri-o/blob/master/docs/crio.conf.5.md)。
- [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md)
- [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling)
diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
index 738ba23e06..d2a0c6c188 100644
--- a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
+++ b/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md
@@ -23,12 +23,13 @@ The aggregation layer allows Kubernetes to be extended with additional APIs, bey
而不局限于 Kubernetes 核心 API 提供的功能。
-这里的附加 API 可以是[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/)
-这类已经成熟的解决方案，也可以是你自己开发的 API。
+这里的附加 API 可以是现成的解决方案比如
+[metrics server](https://github.com/kubernetes-sigs/metrics-server),
+或者你自己开发的 API。
聚合层不同于
[定制资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。
diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index a25019b3a0..6fdc0a371f 100644
--- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -334,10 +334,12 @@ service PodResourcesLister {
这一 `List` 端点提供运行中 Pods 的资源信息，包括类似独占式分配的
CPU ID、设备插件所报告的设备 ID 以及这些设备分配所处的 NUMA 节点 ID。
+此外，对于基于 NUMA 的机器，它还会包含为容器保留的内存和大页的信息。
```gRPC
// ListPodResourcesResponse 是 List 函数的响应
@@ -357,6 +359,14 @@ message ContainerResources {
string name = 1;
repeated ContainerDevices devices = 2;
repeated int64 cpu_ids = 3;
+ repeated ContainerMemory memory = 4;
+}
+
+// ContainerMemory 包含分配给容器的内存和大页信息
+message ContainerMemory {
+ string memory_type = 1;
+ uint64 size = 2;
+ TopologyInfo topology = 3;
}
// Topology 描述资源的硬件拓扑结构
@@ -390,6 +400,7 @@ It provides more information than kubelet exports to APIServer.
message AllocatableResourcesResponse {
repeated ContainerDevices devices = 1;
repeated int64 cpu_ids = 2;
+ repeated ContainerMemory memory = 3;
}
```
@@ -397,7 +408,7 @@ message AllocatableResourcesResponse {
`ContainerDevices` 会向外提供各个设备所隶属的 NUMA 单元这类拓扑信息。
NUMA 单元通过一个整数 ID 来标识，其取值与设备插件所报告的一致。
diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh/docs/concepts/extend-kubernetes/operator.md
index 97326b31cd..4001e14f17 100644
--- a/content/zh/docs/concepts/extend-kubernetes/operator.md
+++ b/content/zh/docs/concepts/extend-kubernetes/operator.md
@@ -98,8 +98,7 @@ Some of the things that you can use an operator to automate include:
* 在没有内部成员选举程序的情况下，为分布式应用选择首领角色
-想要更详细的了解 Operator？这儿有一个详细的示例：
+想要更详细的了解 Operator？下面是一个示例：
1. 有一个名为 SampleDB 的自定义资源，你可以将其配置到集群中。
2. 一个包含 Operator 控制器部分的 Deployment，用来确保 Pod 处于运行状态。
@@ -215,9 +214,10 @@ Operator.
* [Charmed Operator Framework](https://juju.is/)
* [kubebuilder](https://book.kubebuilder.io/)
+* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (dotnet operator SDK)
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
-* [Metacontroller](https://metacontroller.app/) along with WebHooks that
- you implement yourself
+* [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html) along with WebHooks that
+you implement yourself
* [Operator Framework](https://operatorframework.io)
* [shell-operator](https://github.com/flant/shell-operator)
-->
@@ -227,14 +227,16 @@ Operator.
* [Charmed Operator Framework](https://juju.is/)
* [kubebuilder](https://book.kubebuilder.io/)
+* [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (dotnet operator SDK)
* [KUDO](https://kudo.dev/) (Kubernetes 通用声明式 Operator)
-* [Metacontroller](https://metacontroller.app/)，可与 Webhooks 结合使用，以实现自己的功能。
+* [Metacontroller](https://metacontroller.github.io/metacontroller/intro.html)，可与 Webhooks 结合使用，以实现自己的功能。
* [Operator Framework](https://operatorframework.io)
* [shell-operator](https://github.com/flant/shell-operator)
## {{% heading "whatsnext" %}}
+* 阅读 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator 白皮书](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md)。
* 详细了解 [定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
* 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator
* [发布](https://operatorhub.io/)你的 Operator，让别人也可以使用
diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh/docs/concepts/overview/components.md
index 8e76e91fd7..26535842ab 100644
--- a/content/zh/docs/concepts/overview/components.md
+++ b/content/zh/docs/concepts/overview/components.md
@@ -26,7 +26,7 @@ card:
When you deploy Kubernetes, you get a cluster.
{{}}
-This document outlines the various components you need to have
+This document outlines the various components you need to have for
a complete and working Kubernetes cluster.
Here's the diagram of a Kubernetes cluster with all the components tied together.
diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh/docs/concepts/overview/working-with-objects/annotations.md
index 5239861124..053fbbc341 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/annotations.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/annotations.md
@@ -48,6 +48,15 @@ Annotations, like labels, are key/value maps:
}
```
+{{}}
+
+Map 中的键和值必须是字符串。
+换句话说，你不能使用数字、布尔值、列表或其他类型的键或值。
+{{}}
+
diff --git a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md
index 5184fb0b38..58a4b65163 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md
@@ -93,7 +93,7 @@ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Alway
## 多种资源类型 {#multiple-resource-types}
diff --git a/content/zh/docs/concepts/overview/working-with-objects/finalizers.md b/content/zh/docs/concepts/overview/working-with-objects/finalizers.md
new file mode 100644
index 0000000000..9fba543d9b
--- /dev/null
+++ b/content/zh/docs/concepts/overview/working-with-objects/finalizers.md
@@ -0,0 +1,146 @@
+---
+title: Finalizers
+content_type: concept
+weight: 60
+---
+
+
+
+{{}}
+
+
+你可以通过使用 Finalizers 提醒{{}}
+在删除目标资源前执行特定的清理任务，
+来控制资源的{{}}。
+
+
+Finalizers 通常不指定要执行的代码。
+相反，它们通常是特定资源上的键的列表，类似于注解。
+Kubernetes 自动指定了一些 Finalizers，但你也可以指定你自己的。
+
+
+## Finalizers 如何工作 {#how-finalizers-work}
+
+当你使用清单文件创建资源时，你可以在 `metadata.finalizers` 字段指定 Finalizers。
+当你试图删除该资源时，管理该资源的控制器会注意到 `finalizers` 字段中的值，
+并进行以下操作：
+
+ * 修改对象，将你开始执行删除的时间添加到 `metadata.deletionTimestamp` 字段。
+ * 将该对象标记为只读，直到其 `metadata.finalizers` 字段为空。
+
+
+然后，控制器试图满足资源的 Finalizers 的条件。
+每当一个 Finalizer 的条件被满足时，控制器就会从资源的 `finalizers` 字段中删除该键。
+当该字段为空时，垃圾收集继续进行。
+你也可以使用 Finalizers 来阻止删除未被管理的资源。
+
+
+一个常见的 Finalizer 的例子是 `kubernetes.io/pv-protection`，
+它用来防止意外删除 `PersistentVolume` 对象。
+当一个 `PersistentVolume` 对象被 Pod 使用时，
+Kubernetes 会添加 `pv-protection` Finalizer。
+如果你试图删除 `PersistentVolume`，它将进入 `Terminating` 状态，
+但是控制器因为该 Finalizer 存在而无法删除该资源。
+当 Pod 停止使用 `PersistentVolume` 时，
+Kubernetes 清除 `pv-protection` Finalizer，控制器就会删除该卷。
+
+
+## 属主引用、标签和 Finalizers {#owners-labels-finalizers}
+
+与{{}}类似，
+[属主引用](/zh/concepts/overview/working-with-objects/owners-dependents/)
+描述了 Kubernetes 中对象之间的关系，但它们作用不同。
+当一个{{}}
+管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。
+例如，当 {{}} 创建一个或多个 Pod 时，
+Job 控制器会给这些 Pod 应用上标签，并跟踪集群中的具有相同标签的 Pod 的变化。
+
+
+Job 控制器还为这些 Pod 添加了*属主引用*，指向创建 Pod 的 Job。
+如果你在这些 Pod 运行的时候删除了 Job，
+Kubernetes 会使用属主引用（而不是标签）来确定集群中哪些 Pod 需要清理。
+
+当 Kubernetes 识别到要删除的资源上的属主引用时，它也会处理 Finalizers。
+
+在某些情况下，Finalizers 会阻止依赖对象的删除，
+这可能导致目标属主对象，保持在只读状态的时间比预期的长，且没有被完全删除。
+在这些情况下，你应该检查目标属主和附属对象上的 Finalizers 和属主引用，来排查原因。
+
+{{}}
+
+在对象卡在删除状态的情况下，尽量避免手动移除 Finalizers，以允许继续删除操作。
+Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它们会导致集群出现问题。
+{{}}
+
+
+## {{% heading "whatsnext" %}}
+
+
+* 阅读 Kubernetes 博客的[使用 Finalizers 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。
diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
index 96a863cfa0..6c8ce5873e 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md
@@ -160,6 +160,7 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
* `apiVersion` - Which version of the Kubernetes API you're using to create this object
* `kind` - What kind of object you want to create
* `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace`
+* `spec` - What state you desire for the object
-->
### 必需字段 {#required-fields}
@@ -168,25 +169,23 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to
* `apiVersion` - 创建该对象所使用的 Kubernetes API 的版本
* `kind` - 想要创建的对象的类别
* `metadata` - 帮助唯一性标识对象的一些数据，包括一个 `name` 字符串、UID 和可选的 `namespace`
+* `spec` - 你所期望的该对象的状态
-你也需要提供对象的 `spec` 字段。
-对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。
-[Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
-能够帮助我们找到任何我们想创建的对象的 spec 格式。
-例如，可以从
-[core/v1 PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core)
-查看 `Pod` 的 `spec` 格式，
-并且可以从
-[apps/v1 DeploymentSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#deploymentspec-v1-apps)
-查看 `Deployment` 的 `spec` 格式。
+The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes.
+For example, the reference for Pod details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)
+for a Pod in the API, and the reference for Deployment details the [`spec` field](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec) for Deployments.
+In those API reference pages you'll see mention of PodSpec and DeploymentSpec. These names are implementation details of the Golang code that Kubernetes uses to implement its API.
+-->
+对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。
+[Kubernetes API 参考](https://kubernetes.io/docs/reference/kubernetes-api/)
+能够帮助我们找到任何我们想创建的对象的规约格式。
+
+例如，Pod 参考文档详细说明了 API 中 Pod 的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec)，
+Deployment 的参考文档则详细说明了 Deployment 的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/deployment-v1/#DeploymentSpec)。
+在这些 API 参考页面中，你将看到提到的 PodSpec 和 DeploymentSpec。
+这些名字是 Kubernetes 用来实现其 API 的 Golang 代码的实现细节。
## {{% heading "whatsnext" %}}
diff --git a/content/zh/docs/concepts/overview/working-with-objects/labels.md b/content/zh/docs/concepts/overview/working-with-objects/labels.md
index 2714cb3f7b..34b9fe0f6b 100644
--- a/content/zh/docs/concepts/overview/working-with-objects/labels.md
+++ b/content/zh/docs/concepts/overview/working-with-objects/labels.md
@@ -70,11 +70,10 @@ Example labels:
* `"track" : "daily"`, `"track" : "weekly"`
-这些只是常用标签的例子; 你可以任意制定自己的约定。请记住，对于给定对象标签的键必须是唯一的。
+有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子; 你可以任意制定自己的约定。
+请记住，标签的 Key 对于给定对象必须是唯一的。
## 语法和字符集
@@ -97,7 +96,7 @@ _标签_ 是键值对。有效的标签键有两个段：可选的前缀和名
向最终用户对象添加标签的自动系统组件（例如 `kube-scheduler`、`kube-controller-manager`、
`kube-apiserver`、`kubectl` 或其他第三方自动化工具）必须指定前缀。
-`kubernetes.io/` 前缀是为 Kubernetes 核心组件保留的。
+`kubernetes.io/` 和 `k8s.io/` 前缀是为 Kubernetes 核心组件[保留的](/zh/docs/reference/labels-annotations-taints/)。
-以下是比较常见的三种资源命名约束。
+以下是比较常见的四种资源命名约束。
-### DNS 标签名 {#dns-label-names}
+### RFC 1123 标签名 {#dns-label-names}
某些资源类型需要其名称遵循 [RFC 1123](https://tools.ietf.org/html/rfc1123)
所定义的 DNS 标签标准。也就是命名必须满足如下规则：
-- 最多63个字符
-- 只能包含小写字母、数字，以及'-'
+- 最多 63 个字符
+- 只能包含小写字母、数字，以及 '-'
- 须以字母数字开头
- 须以字母数字结尾
+
+
+### RFC 1035 标签名 {#rfc-1035-label-names}
+
+某些资源类型需要其名称遵循 [RFC 1035](https://tools.ietf.org/html/rfc1035)
+所定义的 DNS 标签标准。也就是命名必须满足如下规则：
+
+- 最多 63 个字符
+- 只能包含小写字母、数字，以及 '-'
+- 须以字母开头
+- 须以字母数字结尾
+
Kubernetes 会创建四个初始名字空间：
-* `default` 没有指明使用其它名字空间的对象所使用的默认名字空间
-* `kube-system` Kubernetes 系统创建对象所使用的名字空间
-* `kube-public` 这个名字空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。
- 这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。
- 这个名字空间的公共方面只是一种约定，而不是要求。
-* `kube-node-lease` 此名字空间用于与各个节点相关的租期（Lease）对象；
- 此对象的设计使得集群规模很大时节点心跳检测性能得到提升。
+ * `default` 没有指明使用其它名字空间的对象所使用的默认名字空间
+ * `kube-system` Kubernetes 系统创建对象所使用的名字空间
+ * `kube-public` 这个名字空间是自动创建的，所有用户（包括未经过身份验证的用户）都可以读取它。
+ 这个名字空间主要用于集群使用，以防某些资源在整个集群中应该是可见和可读的。
+ 这个名字空间的公共方面只是一种约定，而不是要求。
+ * `kube-node-lease` 此名字空间用于与各个节点相关的
+ [租约（Lease）](/docs/reference/kubernetes-api/cluster-resources/lease-v1/)对象。
+ 节点租期允许 kubelet 发送[心跳](/zh/docs/concepts/architecture/nodes/#heartbeats)，由此控制面能够检测到节点故障。
@@ -155,8 +156,8 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/)
Kubernetes allows you to limit the number of processes running in a Pod. You
specify this limit at the node level, rather than configuring it as a resource
limit for a particular Pod. Each Node can have a different PID limit.
-To configure the limit, you can specify the command line parameter
-`--pod-max-pids` to the kubelet, or set `PodPidsLimit` in the kubelet
+To configure the limit, you can specify the command line parameter `--pod-max-pids`
+to the kubelet, or set `PodPidsLimit` in the kubelet
[configuration file](/docs/tasks/administer-cluster/kubelet-config-file/).
-->
## Pod 级别 PID 限制 {#pod-pid-limits}
@@ -183,9 +184,12 @@ the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
## PID based eviction
You can configure kubelet to start terminating a Pod when it is misbehaving and consuming abnormal amount of resources.
-This feature is called eviction. You can [Configure Out of Resource Handling](/docs/tasks/administer-cluster/out-of-resource) for various eviction signals.
+This feature is called eviction. You can
+[Configure Out of Resource Handling](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
+for various eviction signals.
Use `pid.available` eviction signal to configure the threshold for number of PIDs used by Pod.
-You can set soft and hard eviction policies. However, even with the hard eviction policy, if the number of PIDs growing very fast,
+You can set soft and hard eviction policies.
+However, even with the hard eviction policy, if the number of PIDs growing very fast,
node can still get into unstable state by hitting the node PIDs limit.
Eviction signal value is calculated periodically and does NOT enforce the limit.
-->
@@ -219,9 +223,10 @@ Pod 行为不正常而没有 PID 可用。
- 参阅 [PID 约束改进文档](https://github.com/kubernetes/enhancements/blob/097b4d8276bc9564e56adf72505d43ce9bc5e9e8/keps/sig-node/20190129-pid-limiting.md)
以了解更多信息。
@@ -229,5 +234,5 @@ Pod 行为不正常而没有 PID 可用。
[Kubernetes 1.14 中限制进程 ID 以提升稳定性](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/)
的博文。
- 请阅读[为容器管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。
-- 学习如何[配置资源不足情况的处理](/zh/docs/tasks/administer-cluster/out-of-resource)。
+- 学习如何[配置资源不足情况的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。
diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md
index 46db85215e..813bfce688 100644
--- a/content/zh/docs/concepts/policy/pod-security-policy.md
+++ b/content/zh/docs/concepts/policy/pod-security-policy.md
@@ -15,9 +15,11 @@ weight: 30
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，将在 v1.25 中删除。
+关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
## 启用 Pod 安全策略
-Pod 安全策略实现为一种可选（但是建议启用）的
+Pod 安全策略实现为一种可选的
[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。
[启用了准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)
即可强制实施 Pod 安全策略，不过如果没有授权认可策略之前即启用
@@ -206,7 +207,11 @@ roleRef:
name:
apiGroup: rbac.authorization.k8s.io
subjects:
-# Authorize specific service accounts:
+# Authorize all service accounts in a namespace (recommended):
+- kind: Group
+ apiGroup: rbac.authorization.k8s.io
+ name: system:serviceaccounts:
+# Authorize specific service accounts (not recommended):
- kind: ServiceAccount
name:
namespace:
@@ -222,20 +227,24 @@ subjects:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
- name: <绑定名称>
+ name:
roleRef:
kind: ClusterRole
- name: <角色名称>
+ name:
apiGroup: rbac.authorization.k8s.io
subjects:
-# 授权特定的服务账号
+# 授权命名空间下的所有服务账号（推荐）：
+- kind: Group
+ apiGroup: rbac.authorization.k8s.io
+ name: system:serviceaccounts:
+# 授权特定的服务账号（不建议这样操作）：
- kind: ServiceAccount
- name: <要授权的服务账号名称>
+ name:
namespace:
-# 授权特定的用户（不建议这样操作）
+# 授权特定的用户（不建议这样操作）：
- kind: User
apiGroup: rbac.authorization.k8s.io
- name: <要授权的用户名>
+ name:
```
+## 推荐实践 {#recommended-practice}
+
+PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` {{< glossary_tooltip
+text="准入控制器" term_id="admission-controller" >}}替代。
+有关此变更的更多详细信息，请参阅 [PodSecurityPolicy Deprecation: Past, Present, and
+Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。
+参照下述指导，简化从 PodSecurityPolicy 迁移到新的准入控制器步骤：
+
+
+1. 将 PodSecurityPolicies 限制为 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)所定义的策略：
+ - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
+ - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
+ - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}}
+2. 通过配置 `system:serviceaccounts:` 组（`` 是目标命名空间），仅将 PSP 绑定到整个命名空间。示例：
+
+ ```yaml
+ apiVersion: rbac.authorization.k8s.io/v1
+ # This cluster role binding allows all pods in the "development" namespace to use the baseline PSP.
+ kind: ClusterRoleBinding
+ metadata:
+ name: psp-baseline-namespaces
+ roleRef:
+ kind: ClusterRole
+ name: psp-baseline
+ apiGroup: rbac.authorization.k8s.io
+ subjects:
+ - kind: Group
+ name: system:serviceaccounts:development
+ apiGroup: rbac.authorization.k8s.io
+ - kind: Group
+ name: system:serviceaccounts:canary
+ apiGroup: rbac.authorization.k8s.io
+ ```
+
+- 参阅 [PodSecurityPolicy Deprecation: Past, Present, and
+ Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)，了解 Pod 安全策略的未来。
+
- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)
了解策略建议。
- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。
diff --git a/content/zh/docs/concepts/policy/resource-quotas.md b/content/zh/docs/concepts/policy/resource-quotas.md
index 23cc9a2308..8d7cba6884 100644
--- a/content/zh/docs/concepts/policy/resource-quotas.md
+++ b/content/zh/docs/concepts/policy/resource-quotas.md
@@ -102,8 +102,9 @@ Neither contention nor changes to quota will affect already created resources.
## 启用资源配额
@@ -122,7 +123,9 @@ ResourceQuota in that namespace.
## 计算资源配额
@@ -249,7 +252,9 @@ In release 1.8, quota support for local ephemeral storage is added as an alpha f
{{< note >}}
如果所使用的是 CRI 容器运行时，容器日志会被计入临时存储配额。
这可能会导致存储配额耗尽的 Pods 被意外地驱逐出节点。
@@ -382,7 +387,7 @@ Resources specified on the quota outside of the allowed set results in a validat
| `NotTerminating` | Match pods where `.spec.activeDeadlineSeconds is nil` |
| `BestEffort` | Match pods that have best effort quality of service. |
| `NotBestEffort` | Match pods that do not have best effort quality of service. |
-| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/configuration/pod-priority-preemption). |
+| `PriorityClass` | Match pods that references the specified [priority class](/docs/concepts/scheduling-eviction/pod-priority-preemption). |
| `CrossNamespacePodAffinity` | Match pods that have cross-namespace pod [(anti)affinity terms](/docs/concepts/scheduling-eviction/assign-pod-node). |
-->
| 作用域 | 描述 |
@@ -391,7 +396,7 @@ Resources specified on the quota outside of the allowed set results in a validat
| `NotTerminating` | 匹配所有 `spec.activeDeadlineSeconds` 是 nil 的 Pod。 |
| `BestEffort` | 匹配所有 Qos 是 BestEffort 的 Pod。 |
| `NotBestEffort` | 匹配所有 Qos 不是 BestEffort 的 Pod。 |
-| `PriorityClass` | 匹配所有引用了所指定的[优先级类](/zh/docs/concepts/configuration/pod-priority-preemption)的 Pods。 |
+| `PriorityClass` | 匹配所有引用了所指定的[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption)的 Pods。 |
| `CrossNamespacePodAffinity` | 匹配那些设置了跨名字空间 [（反）亲和性条件](/zh/docs/concepts/scheduling-eviction/assign-pod-node)的 Pod。 |
-Pod 可以创建为特定的[优先级](/zh/docs/concepts/configuration/pod-priority-preemption/#pod-priority)。
+Pod 可以创建为特定的[优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)。
通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。
如果配额对象通过 `scopeSelector` 字段设置其作用域为优先级类，则配额对象只能
跟踪以下资源：
@@ -702,7 +708,7 @@ pods 0 10
-->
### 跨名字空间的 Pod 亲和性配额 {#cross-namespace-pod-affinity-quota}
-{{< feature-state for_k8s_version="v1.21" state="alpha" >}}
+{{< feature-state for_k8s_version="v1.22" state="beta" >}}
-此功能特性处于 Alpha 阶段，默认被禁用。你可以通过为 kube-apiserver 和
+此功能特性处于 Beta 阶段，默认被禁用。你可以通过为 kube-apiserver 和
kube-scheduler 设置
[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)
`PodAffinityNamespaceSelector` 来启用此特性。
@@ -868,7 +874,7 @@ kubectl create -f ./object-counts.yaml --namespace=myspace
kubectl get quota --namespace=myspace
```
-```
+```none
NAME AGE
compute-resources 30s
object-counts 32s
@@ -878,7 +884,7 @@ object-counts 32s
kubectl describe quota compute-resources --namespace=myspace
```
-```
+```none
Name: compute-resources
Namespace: myspace
Resource Used Hard
@@ -894,7 +900,7 @@ requests.nvidia.com/gpu 0 4
kubectl describe quota object-counts --namespace=myspace
```
-```
+```none
Name: object-counts
Namespace: myspace
Resource Used Hard
@@ -1034,7 +1040,7 @@ Then, create a resource quota object in the `kube-system` namespace:
kubectl apply -f https://k8s.io/examples/policy/priority-class-resourcequota.yaml -n kube-system
```
-```
+```none
resourcequota/pods-cluster-services created
```
diff --git a/content/zh/docs/concepts/security/controlling-access.md b/content/zh/docs/concepts/security/controlling-access.md
index b45dee64dd..b6799171ae 100644
--- a/content/zh/docs/concepts/security/controlling-access.md
+++ b/content/zh/docs/concepts/security/controlling-access.md
@@ -246,7 +246,7 @@ By default, the Kubernetes API server serves HTTP on 2 ports:
- is intended for testing and bootstrap, and for other components of the master node
(scheduler, controller-manager) to talk to the API
- no TLS
- - default is port 8080, change with `--insecure-port` flag.
+ - default is port 8080
- default IP is localhost, change with `--insecure-bind-address` flag.
- request **bypasses** authentication and authorization modules.
- request handled by admission control module(s).
@@ -266,7 +266,7 @@ By default, the Kubernetes API server serves HTTP on 2 ports:
- 用于测试和引导，以及主控节点上的其他组件（调度器，控制器管理器）与 API 通信
- 没有 TLS
- - 默认为端口 8080，使用 `--insecure-port` 进行更改
+ - 默认为端口 8080
- 默认 IP 为 localhost，使用 `--insecure-bind-address` 进行更改
- 请求 **绕过** 身份认证和鉴权模块
- 由准入控制模块处理的请求
diff --git a/content/zh/docs/concepts/security/pod-security-standards.md b/content/zh/docs/concepts/security/pod-security-standards.md
index 47a3c5e0da..7a78e66b4c 100644
--- a/content/zh/docs/concepts/security/pod-security-standards.md
+++ b/content/zh/docs/concepts/security/pod-security-standards.md
@@ -14,67 +14,39 @@ weight: 10
-Pod 的安全性配置一般通过使用
-[安全性上下文（Security Context）](/zh/docs/tasks/configure-pod-container/security-context/)
-来保证。安全性上下文允许用户逐个 Pod 地定义特权级及访问控制。
+Pod 安全性标准定义了三种不同的 _策略（Policy）_，以广泛覆盖安全应用场景。
+这些策略是 _渐进式的（Cumulative）_，安全级别从高度宽松至高度受限。
+本指南概述了每个策略的要求。
-以前，对集群的安全性上下文的需求的实施及其基于策略的定义都通过使用
-[Pod 安全性策略](/zh/docs/concepts/policy/pod-security-policy/)来实现。
-_Pod 安全性策略（Pod Security Policy）_ 是一种集群层面的资源，控制 Pod 规约中
-安全性敏感的部分。
-
-不过，新的策略实施方式不断涌现，或增强或替换 PodSecurityPolicy 的使用。
-本页的目的是详细介绍建议实施的 Pod 安全框架；这些内容与具体的实现无关。
+| Profile | 描述 |
+| ------ | ----------- |
+| Privileged | 不受限制的策略，提供最大可能范围的权限许可。此策略允许已知的特权提升。 |
+| Baseline | 限制性最弱的策略，禁止已知的策略提升。允许使用默认的（规定最少）Pod 配置。 |
+| Restricted | 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。 |
-## 策略类型 {#policy-types}
-
-在进一步讨论整个策略谱系之前，有必要对基本的策略下个定义。
-策略可以是很严格的也可以是很宽松的：
-
-- **_Privileged_** - 不受限制的策略，提供最大可能范围的权限许可。这些策略
- 允许已知的特权提升。
-- **_Baseline_** - 限制性最弱的策略，禁止已知的策略提升。
- 允许使用默认的（规定最少）Pod 配置。
-- **_Restricted_** - 限制性非常强的策略，遵循当前的保护 Pod 的最佳实践。
-
-
-## 策略 {#policies}
+## Profile 细节 {#profile-details}
### Privileged
-Privileged 策略是有目的地开放且完全无限制的策略。此类策略通常针对由
-特权较高、受信任的用户所管理的系统级或基础设施级负载。
+**_Privileged_ 策略是有目的地开放且完全无限制的策略。**
+此类策略通常针对由特权较高、受信任的用户所管理的系统级或基础设施级负载。
Privileged 策略定义中限制较少。对于默认允许（Allow-by-default）实施机制（例如 gatekeeper），
Privileged 框架可能意味着不应用任何约束而不是实施某策略实例。
@@ -93,15 +65,26 @@ Privileged 策略应该默认允许所有控制（即，禁止所有限制）。
### Baseline
-Baseline 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。
+**_Baseline_ 策略的目标是便于常见的容器化应用采用，同时禁止已知的特权提升。**
此策略针对的是应用运维人员和非关键性应用的开发人员。
下面列举的控制应该被实施（禁止）：
+{{< note >}}
+在下述表格中，通配符（`*`）意味着一个列表中的所有元素。
+例如 `spec.containers[*].securityContext` 表示 _所定义的所有容器_ 的安全性上下文对象。
+如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。
+{{< /note >}}
+
+ 
+
+ 
+ 
+ 
+
+
+
+
+
+ 