diff --git a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
index b372e7e7b4..a896d0f8c9 100644
--- a/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
+++ b/content/en/blog/_posts/2021-11-12-are-you-ready-for-dockershim-removal/index.md
@@ -7,11 +7,16 @@ slug: are-you-ready-for-dockershim-removal
**Author:** Sergey Kanzhelev, Google. With reviews from Davanum Srinivas, Elana Hashman, Noah Kantrowitz, Rey Lejano.
+{{% alert color="info" title="Poll closed" %}}
+This poll closed on January 7, 2022.
+{{% /alert %}}
+
Last year we announced that Dockershim is being deprecated: [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/).
Our current plan is to remove dockershim from the Kubernetes codebase soon.
We are looking for feedback from you whether you are ready for dockershim
removal and to ensure that you are ready when the time comes.
-**Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8**.
+
+Please fill out this survey: https://forms.gle/svCJmhvTv78jGdSx8
The dockershim component that enables Docker as a Kubernetes container runtime is
being deprecated in favor of runtimes that directly use the [Container Runtime Interface](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)
@@ -25,7 +30,7 @@ are still not ready: [migrating telemetry and security agents](/docs/tasks/admin
At this point, we believe that there is feature parity between Docker and the
other runtimes. Many end-users have used our [migration guide](/docs/tasks/administer-cluster/migrating-from-dockershim/)
and are running production workload using these different runtimes. The plan of
-record today is that dockershim will be removed in version 1.24, slated for
+record today is that dockershim will be removed in version 1.24, slated for
release around April of next year. For those developing or running alpha and
beta versions, dockershim will be removed in December at the beginning of the
1.24 release development cycle.
@@ -33,7 +38,7 @@ beta versions, dockershim will be removed in December at the beginning of the
There is only one month left to give us feedback. We want you to tell us how
ready you are.
-**We are collecting opinions through this survey: [https://forms.gle/svCJmhvTv78jGdSx8](https://forms.gle/svCJmhvTv78jGdSx8)**
+We are collecting opinions through this survey: https://forms.gle/svCJmhvTv78jGdSx8
To better understand preparedness for the dockershim removal, our survey is
asking the version of Kubernetes you are currently using, and an estimate of
when you think you will adopt Kubernetes 1.24. All the aggregated information
diff --git a/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md
new file mode 100644
index 0000000000..07f33b8b80
--- /dev/null
+++ b/content/en/blog/_posts/2022-01-07-kubernetes-is-moving-on-from-dockershim.md
@@ -0,0 +1,103 @@
+---
+layout: blog
+title: "Kubernetes is Moving on From Dockershim: Commitments and Next Steps"
+date: 2022-01-07
+slug: kubernetes-is-moving-on-from-dockershim
+---
+
+**Authors:** Sergey Kanzhelev (Google), Jim Angel (Google), Davanum Srinivas (VMware), Shannon Kularathna (Google), Chris Short (AWS), Dawn Chen (Google)
+
+Kubernetes is removing dockershim in the upcoming v1.24 release. We're excited
+to reaffirm our community values by supporting open source container runtimes,
+enabling a smaller kubelet, and increasing engineering velocity for teams using
+Kubernetes. If you [use Docker Engine as a container runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)
+for your Kubernetes cluster, get ready to migrate in 1.24! To check if you're
+affected, refer to [Check whether dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/).
+
+## Why we’re moving away from dockershim
+
+Docker was the first container runtime used by Kubernetes. This is one of the
+reasons why Docker is so familiar to many Kubernetes users and enthusiasts.
+Docker support was hardcoded into Kubernetes – a component the project refers to
+as dockershim.
+As containerization became an industry standard, the Kubernetes project added support
+for additional runtimes. This culminated in the implementation of the
+container runtime interface (CRI), letting system components (like the kubelet)
+talk to container runtimes in a standardized way. As a result, dockershim became
+an anomaly in the Kubernetes project.
+Dependencies on Docker and dockershim have crept into various tools
+and projects in the CNCF ecosystem ecosystem, resulting in fragile code.
+
+By removing the
+dockershim CRI, we're embracing the first value of CNCF: "[Fast is better than
+slow](https://github.com/cncf/foundation/blob/master/charter.md#3-values)".
+Stay tuned for future communications on the topic!
+
+## Deprecation timeline
+
+We [formally announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/) the dockershim deprecation in December 2020. Full removal is targeted
+in Kubernetes 1.24, in April 2022. This timeline
+aligns with our [deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior),
+which states that deprecated behaviors must function for at least 1 year
+after their announced deprecation.
+
+We'll support Kubernetes version 1.23, which includes
+dockershim, for another year in the Kubernetes project. For managed
+Kubernetes providers, vendor support is likely to last even longer, but this is
+dependent on the companies themselves. Regardless, we're confident all cluster operations will have
+time to migrate. If you have more questions about the dockershim removal, refer
+to the [Dockershim Deprecation FAQ](/dockershim).
+
+We asked you whether you feel prepared for the migration from dockershim in this
+survey: [Are you ready for Dockershim removal](/blog/2021/11/12/are-you-ready-for-dockershim-removal/).
+We had over 600 responses. To everybody who took time filling out the survey,
+thank you.
+
+The results show that we still have a lot of ground to cover to help you to
+migrate smoothly. Other container runtimes exist, and have been promoted
+extensively. However, many users told us they still rely on dockershim,
+and sometimes have dependencies that need to be re-worked. Some of these
+dependencies are outside of your control. Based on your feedback, here are some
+of the steps we are taking to help.
+
+## Our next steps
+
+Based on the feedback you provided:
+
+- CNCF and the 1.24 release team are committed to delivering documentation in
+ time for the 1.24 release. This includes more informative blog posts like this
+ one, updating existing code samples, tutorials, and tasks, and producing a
+ migration guide for cluster operators.
+- We are reaching out to the rest of the CNCF community to help prepare them for
+ this change.
+
+If you're part of a project with dependencies on dockershim, or if you're
+interested in helping with the migration effort, please join us! There's always
+room for more contributors, whether to our transition tools or to our
+documentation. To get started, say hello in the
+[#sig-node](https://kubernetes.slack.com/archives/C0BP8PW9G)
+channel on [Kubernetes Slack](https://slack.kubernetes.io/)!
+
+## Final thoughts
+
+As a project, we've already seen cluster operators increasingly adopt other
+container runtimes through 2021.
+We believe there are no major blockers to migration. The steps we're taking to
+improve the migration experience will light the path more clearly for you.
+
+We understand that migration from dockershim is yet another action you may need to
+do to keep your Kubernetes infrastructure up to date. For most of you, this step
+will be straightforward and transparent. In some cases, you will encounter
+hiccups or issues. The community has discussed at length whether postponing the
+dockershim removal would be helpful. For example, we recently talked about it in
+the [SIG Node discussion on November 11th](https://docs.google.com/document/d/1Ne57gvidMEWXR70OxxnRkYquAoMpt56o75oZtg-OeBg/edit#bookmark=id.r77y11bgzid)
+and in the [Kubernetes Steering committee meeting held on December 6th](https://docs.google.com/document/d/1qazwMIHGeF3iUh5xMJIJ6PDr-S3bNkT8tNLRkSiOkOU/edit#bookmark=id.m0ir406av7jx).
+We already [postponed](https://github.com/kubernetes/enhancements/pull/2481/) it
+once in 2021 because the adoption rate of other
+runtimes was lower than we wanted, which also gave us more time to identify
+potential blocking issues.
+
+At this point, we believe that the value that you (and Kubernetes) gain from
+dockershim removal makes up for the migration effort you'll have. Start planning
+now to avoid surprises. We'll have more updates and guides before Kubernetes
+1.24 is released.
diff --git a/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md
new file mode 100644
index 0000000000..4c969ff50c
--- /dev/null
+++ b/content/en/blog/_posts/2022-01-10-meet-our-contributors-APAC-India-region-01.md
@@ -0,0 +1,106 @@
+---
+layout: blog
+title: "Meet Our Contributors - APAC (India region)"
+date: 2022-01-10T12:00:00+0000
+slug: meet-our-contributors-india-ep-01
+canonicalUrl: https://kubernetes.dev/blog/2022/01/10/meet-our-contributors-india-ep-01/
+---
+
+**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Pritish Samal](https://github.com/CIPHERTron), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
+
+**Editor:** [Priyanka Saggu](https://psaggu.com)
+
+---
+
+Good day, everyone 👋
+
+Welcome to the first episode of the APAC edition of the "Meet Our Contributors" blog post series.
+
+
+In this post, we'll introduce you to five amazing folks from the India region who have been actively contributing to the upstream Kubernetes projects in a variety of ways, as well as being the leaders or maintainers of numerous community initiatives.
+
+💫 *Let's get started, so without further ado…*
+
+
+## [Arsh Sharma](https://github.com/RinkiyaKeDad)
+
+Arsh is currently employed with Okteto as a Developer Experience engineer. As a new contributor, he realised that 1:1 mentorship opportunities were quite beneficial in getting him started with the upstream project.
+
+He is presently a CI Signal shadow on the Kubernetes 1.23 release team. He is also contributing to the SIG Testing and SIG Docs projects, as well as to the [cert-manager](https://github.com/cert-manager/infrastructure) tools development work that is being done under the aegis of SIG Architecture.
+
+To the newcomers, Arsh helps plan their early contributions sustainably.
+
+> _I would encourage folks to contribute in a way that's sustainable. What I mean by that
+> is that it's easy to be very enthusiastic early on and take up more stuff than one can
+> actually handle. This can often lead to burnout in later stages. It's much more sustainable
+> to work on things iteratively._
+
+## [Kunal Kushwaha](https://github.com/kunal-kushwaha)
+
+Kunal Kushwaha is a core member of the Kubernetes marketing council. He is also a CNCF ambassador and one of the founders of the [CNCF Students Program](https://community.cncf.io/cloud-native-students/).. He also served as a Communications role shadow during the 1.22 release cycle.
+
+At the end of his first year, Kunal began contributing to the [fabric8io kubernetes-client](https://github.com/fabric8io/kubernetes-client) project. He was then selected to work on the same project as part of Google Summer of Code. Kunal mentored people on the same project, first through Google Summer of Code then through Google Code-in.
+
+As an open-source enthusiast, he believes that diverse participation in the community is beneficial since it introduces new perspectives and opinions and respect for one's peers. He has worked on various open-source projects, and his participation in communities has considerably assisted his development as a developer.
+
+
+> _I believe if you find yourself in a place where you do not know much about the
+> project, that's a good thing because now you can learn while contributing and the
+> community is there to help you. It has helped me a lot in gaining skills, meeting
+> people from around the world and also helping them. You can learn on the go,
+> you don't have to be an expert. Make sure to also check out no code contributions
+> because being a beginner is a skill and you can bring new perspectives to the
+> organisation._
+
+## [Madhav Jivarajani](https://github.com/MadhavJivrajani)
+
+
+Madhav Jivarajani works on the VMware Upstream Kubernetes stability team. He began contributing to the Kubernetes project in January 2021 and has since made significant contributions to several areas of work under SIG Architecture, SIG API Machinery, and SIG ContribEx (contributor experience).
+
+Among several significant contributions are his recent efforts toward the Archival of [design proposals](https://github.com/kubernetes/community/issues/6055), refactoring the ["groups" codebase](https://github.com/kubernetes/k8s.io/pull/2713) under k8s-infra repository to make it mockable and testable, and improving the functionality of the [GitHub k8s bot](https://github.com/kubernetes/test-infra/issues/23129).
+
+In addition to his technical efforts, Madhav oversees many projects aimed at assisting new contributors. He organises bi-weekly "KEP reading club" sessions to help newcomers understand the process of adding new features, deprecating old ones, and making other key changes to the upstream project. He has also worked on developing [Katacoda scenarios](https://github.com/kubernetes-sigs/contributor-katacoda) to assist new contributors to become acquainted with the process of contributing to k/k. In addition to his current efforts to meet with community members every week, he has organised several [new contributors workshops (NCW)](https://www.youtube.com/watch?v=FgsXbHBRYIc).
+
+> _I initially did not know much about Kubernetes. I joined because the community was
+> super friendly. But what made me stay was not just the people, but the project itself.
+> My solution to not feeling overwhelmed in the community was to gain as much context
+> and knowledge into the topics that I was interested in and were being discussed. And
+> as a result I continued to dig deeper into Kubernetes and the design of it.
+> I am a systems nut & thus Kubernetes was an absolute goldmine for me._
+
+
+## [Rajas Kakodkar](https://github.com/rajaskakodkar)
+
+Rajas Kakodkar currently works at VMware as a Member of Technical Staff. He has been engaged in many aspects of the upstream Kubernetes project since 2019.
+
+He is now a key contributor to the Testing special interest group. He is also active in the SIG Network community. Lately, Rajas has contributed significantly to the [NetworkPolicy++](https://docs.google.com/document/d/1AtWQy2fNa4qXRag9cCp5_HsefD7bxKe3ea2RPn8jnSs/) and [`kpng`](https://github.com/kubernetes-sigs/kpng) sub-projects.
+
+One of the first challenges he ran across was that he was in a different time zone than the upstream project's regular meeting hours. However, async interactions on community forums progressively corrected that problem.
+
+> _I enjoy contributing to Kubernetes not just because I get to work on
+> cutting edge tech but more importantly because I get to work with
+> awesome people and help in solving real world problems._
+
+## [Rajula Vineet Reddy](https://github.com/rajula96reddy)
+
+Rajula Vineet Reddy, a Junior Engineer at CERN, is a member of the Marketing Council team under SIG ContribEx . He also served as a release shadow for SIG Release during the 1.22 and 1.23 Kubernetes release cycles.
+
+He started looking at the Kubernetes project as part of a university project with the help of one of his professors. Over time, he spent a significant amount of time reading the project's documentation, Slack discussions, GitHub issues, and blogs, which helped him better grasp the Kubernetes project and piqued his interest in contributing upstream. One of his key contributions was his assistance with automation in the SIG ContribEx Upstream Marketing subproject.
+
+According to Rajula, attending project meetings and shadowing various project roles are vital for learning about the community.
+
+> _I find the community very helpful and it's always_
+> “you get back as much as you contribute”.
+> _The more involved you are, the more you will understand, get to learn and
+> contribute new things._
+>
+> _The first step to_ “come forward and start” _is hard. But it's all gonna be
+> smooth after that. Just take that jump._
+
+---
+
+If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. We're thrilled to have other folks assisting us in reaching out to even more wonderful individuals of the community. Your suggestions would be much appreciated.
+
+
+We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
+
diff --git a/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md b/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md
new file mode 100644
index 0000000000..002b2bd531
--- /dev/null
+++ b/content/en/blog/_posts/2022-01-19-Securing-Admission-Controllers.md
@@ -0,0 +1,44 @@
+---
+layout: blog
+title: "Securing Admission Controllers"
+date: 2022-01-19
+slug: secure-your-admission-controllers-and-webhooks
+---
+
+**Author:** Rory McCune (Aqua Security)
+
+[Admission control](/docs/reference/access-authn-authz/admission-controllers/) is a key part of Kubernetes security, alongside authentication and authorization. Webhook admission controllers are extensively used to help improve the security of Kubernetes clusters in a variety of ways including restricting the privileges of workloads and ensuring that images deployed to the cluster meet organization’s security requirements.
+
+However, as with any additional component added to a cluster, security risks can present themselves. A security risk example is if the deployment and management of the admission controller are not handled correctly. To help admission controller users and designers manage these risks appropriately, the [security documentation](https://github.com/kubernetes/community/tree/master/sig-security#security-docs) subgroup of SIG Security has spent some time developing a [threat model for admission controllers](https://github.com/kubernetes/sig-security/tree/main/sig-security-docs/papers/admission-control). This threat model looks at likely risks which may arise from the incorrect use of admission controllers, which could allow security policies to be bypassed, or even allow an attacker to get unauthorised access to the cluster.
+
+From the threat model, we developed a set of security best practices that should be adopted to ensure that cluster operators can get the security benefits of admission controllers whilst avoiding any risks from using them.
+
+## Admission controllers and good practices for security
+
+From the threat model, a couple of themes emerged around how to ensure the security of admission controllers.
+
+### Secure webhook configuration
+
+It’s important to ensure that any security component in a cluster is well configured and admission controllers are no different here. There are a couple of security best practices to consider when using admission controllers
+
+* **Correctly configured TLS for all webhook traffic**. Communications between the API server and the admission controller webhook should be authenticated and encrypted to ensure that attackers who may be in a network position to view or modify this traffic cannot do so. To achieve this access the API server and webhook must be using certificates from a trusted certificate authority so that they can validate their mutual identities
+* **Only authenticated access allowed**. If an attacker can send an admission controller large numbers of requests, they may be able to overwhelm the service causing it to fail. Ensuring all access requires strong authentication should mitigate that risk.
+* **Admission controller fails closed**. This is a security practice that has a tradeoff, so whether a cluster operator wants to configure it will depend on the cluster’s threat model. If an admission controller fails closed, when the API server can’t get a response from it, all deployments will fail. This stops attackers bypassing the admission controller by disabling it, but, can disrupt the cluster’s operation. As clusters can have multiple webhooks, one approach to hit a middle ground might be to have critical controls on a fail closed setups and less critical controls allowed to fail open.
+* **Regular reviews of webhook configuration**. Configuration mistakes can lead to security issues, so it’s important that the admission controller webhook configuration is checked to make sure the settings are correct. This kind of review could be done automatically by an Infrastructure As Code scanner or manually by an administrator.
+
+
+### Secure cluster configuration for admission control
+
+In most cases, the admission controller webhook used by a cluster will be installed as a workload in the cluster. As a result, it’s important to ensure that Kubernetes' security features that could impact its operation are well configured.
+
+* **Restrict [RBAC](/docs/reference/access-authn-authz/rbac/) rights**. Any user who has rights which would allow them to modify the configuration of the webhook objects or the workload that the admission controller uses could disrupt its operation. So it’s important to make sure that only cluster administrators have those rights.
+* **Prevent privileged workloads**. One of the realities of container systems is that if a workload is given certain privileges, it will be possible to break out to the underlying cluster node and impact other containers on that node. Where admission controller services run in the cluster they’re protecting, it’s important to ensure that any requirement for privileged workloads is carefully reviewed and restricted as much as possible.
+* **Strictly control external system access**. As a security service in a cluster admission controller systems will have access to sensitive information like credentials. To reduce the risk of this information being sent outside the cluster, [network policies](/docs/concepts/services-networking/network-policies/) should be used to restrict the admission controller services access to external networks.
+* **Each cluster has a dedicated webhook**. Whilst it may be possible to have admission controller webhooks that serve multiple clusters, there is a risk when using that model that an attack on the webhook service would have a larger impact where it’s shared. Also where multiple clusters use an admission controller there will be increased complexity and access requirements, making it harder to secure.
+
+
+### Admission controller rules
+
+A key element of any admission controller used for Kubernetes security is the rulebase it uses. The rules need to be able to accurately meet their goals avoiding false positive and false negative results.
+
+* **Regularly test and review rules**. Admission controller rules need to be tested to ensure their accuracy. They also need to be regularly reviewed as the Kubernetes API will change with each new version, and rules need to be assessed with each Kubernetes release to understand any changes that may be required to keep them up to date.
diff --git a/content/en/docs/concepts/architecture/cri.md b/content/en/docs/concepts/architecture/cri.md
index e8391ca34b..02f6d8a199 100644
--- a/content/en/docs/concepts/architecture/cri.md
+++ b/content/en/docs/concepts/architecture/cri.md
@@ -15,7 +15,7 @@ each Node in your cluster, so that the
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} can launch
{{< glossary_tooltip text="Pods" term_id="pod" >}} and their containers.
-{{< glossary_definition term_id="container-runtime-interface" length="all" >}}
+{{< glossary_definition prepend="The Container Runtime Interface (CRI) is" term_id="container-runtime-interface" length="all" >}}
diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md
index 0974089f8d..74e81092ae 100644
--- a/content/en/docs/concepts/architecture/nodes.md
+++ b/content/en/docs/concepts/architecture/nodes.md
@@ -33,7 +33,7 @@ There are two main ways to have Nodes added to the {{< glossary_tooltip text="AP
1. The kubelet on a node self-registers to the control plane
2. You (or another human user) manually add a Node object
-After you create a Node object, or the kubelet on a node self-registers, the
+After you create a Node {{< glossary_tooltip text="object" term_id="object" >}}, or the kubelet on a node self-registers, the
control plane checks whether the new Node object is valid. For example, if you
try to create a Node from the following JSON manifest:
diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md
index ee7793d004..ca026b204f 100644
--- a/content/en/docs/concepts/cluster-administration/networking.md
+++ b/content/en/docs/concepts/cluster-administration/networking.md
@@ -79,7 +79,7 @@ addressing, and it can be used in combination with other CNI plugins.
### CNI-Genie from Huawei
-[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Romana](https://romana.io), [Weave-net](https://www.weave.works/products/weave-net/).
+[CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) is a CNI plugin that enables Kubernetes to [simultaneously have access to different implementations](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables) of the [Kubernetes network model](/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model) in runtime. This includes any implementation that runs as a [CNI plugin](https://github.com/containernetworking/cni#3rd-party-plugins), such as [Flannel](https://github.com/coreos/flannel#flannel), [Calico](https://docs.projectcalico.org/), [Weave-net](https://www.weave.works/products/weave-net/).
CNI-Genie also supports [assigning multiple IP addresses to a pod](https://github.com/Huawei-PaaS/CNI-Genie/blob/master/docs/multiple-ips/README.md#feature-2-extension-cni-genie-multiple-ip-addresses-per-pod), each from a different CNI plugin.
@@ -104,10 +104,6 @@ network complexity required to deploy Kubernetes at scale within AWS.
[Coil](https://github.com/cybozu-go/coil) is a CNI plugin designed for ease of integration, providing flexible egress networking.
Coil operates with a low overhead compared to bare metal, and allows you to define arbitrary egress NAT gateways for external networks.
-### 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.
-
### Contrail / Tungsten Fabric
[Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is a truly open, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with various orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide different isolation modes for virtual machines, containers/pods and bare metal workloads.
@@ -130,6 +126,10 @@ With this toolset DANM is able to provide multiple separated network interfaces,
network that satisfies the Kubernetes requirements. Many
people have reported success with Flannel and Kubernetes.
+### Hybridnet
+
+[Hybridnet](https://github.com/alibaba/hybridnet) is an open source CNI plugin designed for hybrid clouds which provides both overlay and underlay networking for containers in one or more clusters. Overlay and underlay containers can run on the same node and have cluster-wide bidirectional network connectivity.
+
### Jaguar
[Jaguar](https://gitlab.com/sdnlab/jaguar) is an open source solution for Kubernetes's network based on OpenDaylight. Jaguar provides overlay network using vxlan and Jaguar CNIPlugin provides one IP address per pod.
diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
index f14f78b13b..8b201e70e6 100644
--- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
+++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md
@@ -1,7 +1,6 @@
---
-reviewers:
title: Device Plugins
-description: Use the Kubernetes device plugin framework to implement plugins for GPUs, NICs, FPGAs, InfiniBand, and similar resources that require vendor-specific setup.
+description: Device plugins let you configure your cluster with support for devices or resources that require vendor-specific setup, such as GPUs, NICs, FPGAs, or non-volatile main memory.
content_type: concept
weight: 20
---
@@ -48,12 +47,14 @@ For example, after a device plugin registers `hardware-vendor.example/foo` with
and reports two healthy devices on a node, the node status is updated
to advertise that the node has 2 "Foo" devices installed and available.
-Then, users can request devices in a
-[Container](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#container-v1-core)
-specification as they request other types of resources, with the following limitations:
-
+Then, users can request devices as part of a Pod specification
+(see [`container`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)).
+Requesting extended resources is similar to how you manage requests and limits for
+other resources, with the following differences:
* Extended resources are only supported as integer resources and cannot be overcommitted.
-* Devices cannot be shared among Containers.
+* Devices cannot be shared between containers.
+
+### Example {#example-pod}
Suppose a Kubernetes cluster is running a device plugin that advertises resource `hardware-vendor.example/foo`
on certain nodes. Here is an example of a pod requesting this resource to run a demo workload:
@@ -174,7 +175,7 @@ a Kubernetes release with a newer device plugin API version, upgrade your device
to support both versions before upgrading these nodes. Taking that approach will
ensure the continuous functioning of the device allocations during the upgrade.
-## Monitoring Device Plugin Resources
+## Monitoring device plugin resources
{{< feature-state for_k8s_version="v1.15" state="beta" >}}
@@ -310,7 +311,7 @@ DaemonSet, `/var/lib/kubelet/pod-resources` must be mounted as a
Support for the `PodResourcesLister service` requires `KubeletPodResources` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) to be enabled.
It is enabled by default starting with Kubernetes 1.15 and is v1 since Kubernetes 1.20.
-## Device Plugin integration with the Topology Manager
+## Device plugin integration with the Topology Manager
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
@@ -319,7 +320,7 @@ The Topology Manager is a Kubelet component that allows resources to be co-ordin
```gRPC
message TopologyInfo {
- repeated NUMANode nodes = 1;
+ repeated NUMANode nodes = 1;
}
message NUMANode {
@@ -338,6 +339,8 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
## Device plugin examples {#examples}
+{{% thirdparty-content %}}
+
Here are some examples of device plugin implementations:
* The [AMD GPU device plugin](https://github.com/RadeonOpenCompute/k8s-device-plugin)
@@ -357,5 +360,5 @@ Here are some examples of device plugin implementations:
* Learn about [scheduling GPU resources](/docs/tasks/manage-gpus/scheduling-gpus/) using device plugins
* Learn about [advertising extended resources](/docs/tasks/administer-cluster/extended-resource-node/) on a node
-* Read about using [hardware acceleration for TLS ingress](https://kubernetes.io/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
* Learn about the [Topology Manager](/docs/tasks/administer-cluster/topology-manager/)
+* Read about using [hardware acceleration for TLS ingress](/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) with Kubernetes
diff --git a/content/en/docs/concepts/overview/working-with-objects/common-labels.md b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
index 3053544cd2..210d33dcd4 100644
--- a/content/en/docs/concepts/overview/working-with-objects/common-labels.md
+++ b/content/en/docs/concepts/overview/working-with-objects/common-labels.md
@@ -42,9 +42,10 @@ on every resource object.
| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string |
| `app.kubernetes.io/created-by` | The controller/user who created this resource | `controller-manager` | string |
-To illustrate these labels in action, consider the following StatefulSet object:
+To illustrate these labels in action, consider the following {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} object:
```yaml
+# This is an excerpt
apiVersion: apps/v1
kind: StatefulSet
metadata:
diff --git a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md
index fff925b6c5..63776520a9 100644
--- a/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md
+++ b/content/en/docs/concepts/scheduling-eviction/pod-priority-preemption.md
@@ -106,7 +106,7 @@ description: "This priority class should be used for XYZ service pods only."
{{< feature-state for_k8s_version="v1.19" state="beta" >}}
-Pods with `PreemptionPolicy: Never` will be placed in the scheduling queue
+Pods with `preemptionPolicy: Never` will be placed in the scheduling queue
ahead of lower-priority pods,
but they cannot preempt other pods.
A non-preempting pod waiting to be scheduled will stay in the scheduling queue,
@@ -122,16 +122,16 @@ allowing other pods with lower priority to be scheduled before them.
Non-preempting pods may still be preempted by other,
high-priority pods.
-`PreemptionPolicy` defaults to `PreemptLowerPriority`,
+`preemptionPolicy` defaults to `PreemptLowerPriority`,
which will allow pods of that PriorityClass to preempt lower-priority pods
(as is existing default behavior).
-If `PreemptionPolicy` is set to `Never`,
+If `preemptionPolicy` is set to `Never`,
pods in that PriorityClass will be non-preempting.
An example use case is for data science workloads.
A user may submit a job that they want to be prioritized above other workloads,
but do not wish to discard existing work by preempting running pods.
-The high priority job with `PreemptionPolicy: Never` will be scheduled
+The high priority job with `preemptionPolicy: Never` will be scheduled
ahead of other queued pods,
as soon as sufficient cluster resources "naturally" become free.
diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md
index f51e10e558..cd9124b6a7 100644
--- a/content/en/docs/concepts/storage/storage-classes.md
+++ b/content/en/docs/concepts/storage/storage-classes.md
@@ -434,7 +434,7 @@ provisioner: example.com/external-nfs
parameters:
server: nfs-server.example.com
path: /share
- readOnly: false
+ readOnly: "false"
```
* `server`: Server is the hostname or IP address of the NFS server.
@@ -797,7 +797,7 @@ parameters:
storagePool: sp1
storageMode: ThinProvisioned
secretRef: sio-secret
- readOnly: false
+ readOnly: "false"
fsType: xfs
```
diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md
index d2284d9dbb..8ff46d4f50 100644
--- a/content/en/docs/concepts/workloads/controllers/job.md
+++ b/content/en/docs/concepts/workloads/controllers/job.md
@@ -615,7 +615,7 @@ spec:
```
The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010af00002`. Setting
-`manualSelector: true` tells the system to that you know what you are doing and to allow this
+`manualSelector: true` tells the system that you know what you are doing and to allow this
mismatch.
### Job tracking with finalizers
diff --git a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
index 9656a816e7..07cf3c77a6 100644
--- a/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
+++ b/content/en/docs/concepts/workloads/pods/pod-lifecycle.md
@@ -229,7 +229,7 @@ when both the following statements apply:
* All conditions specified in `readinessGates` are `True`.
When a Pod's containers are Ready but at least one custom condition is missing or
-`False`, the kubelet sets the Pod's [condition](#pod-condition) to `ContainersReady`.
+`False`, the kubelet sets the Pod's [condition](#pod-conditions) to `ContainersReady`.
## Container probes
diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md
index 592b59ded9..bd11ae6cb5 100644
--- a/content/en/docs/contribute/localization.md
+++ b/content/en/docs/contribute/localization.md
@@ -249,6 +249,7 @@ Home | [All heading and subheading URLs](/docs/home/)
Setup | [All heading and subheading URLs](/docs/setup/)
Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/)
Site strings | [All site strings](#Site-strings-in-i18n) in a new localized TOML file
+Releases | [All heading and subheading URLs](/releases)
Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source:
diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md
index e59ffe4fe3..c577c3f8be 100644
--- a/content/en/docs/contribute/participate/roles-and-responsibilities.md
+++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md
@@ -147,7 +147,7 @@ separately for reviewer status in SIG Docs.
To apply:
1. Open a pull request that adds your GitHub user name to a section of the
- [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS) file
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) file
in the `kubernetes/website` repository.
{{< note >}}
@@ -219,7 +219,7 @@ separately for approver status in SIG Docs.
To apply:
1. Open a pull request adding yourself to a section of the
- [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS)
+ [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES)
file in the `kubernetes/website` repository.
{{< note >}}
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 6eb9e1d40e..f9d2336f07 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
@@ -53,7 +53,7 @@ different Kubernetes components.
|---------|---------|-------|-------|-------|
| `APIListChunking` | `false` | Alpha | 1.8 | 1.8 |
| `APIListChunking` | `true` | Beta | 1.9 | |
-| `APIPriorityAndFairness` | `false` | Alpha | 1.17 | 1.19 |
+| `APIPriorityAndFairness` | `false` | Alpha | 1.18 | 1.19 |
| `APIPriorityAndFairness` | `true` | Beta | 1.20 | |
| `APIResponseCompression` | `false` | Alpha | 1.7 | 1.15 |
| `APIResponseCompression` | `true` | Beta | 1.16 | |
@@ -167,8 +167,8 @@ different Kubernetes components.
| `NodeSwap` | `false` | Alpha | 1.22 | |
| `NonPreemptingPriority` | `false` | Alpha | 1.15 | 1.18 |
| `NonPreemptingPriority` | `true` | Beta | 1.19 | |
-| `OpenAPIEnum` | `false` | Alpha | 1.23 | |
-| `OpenAPIv3` | `false` | Alpha | 1.23 | |
+| `OpenAPIEnums` | `false` | Alpha | 1.23 | |
+| `OpenAPIV3` | `false` | Alpha | 1.23 | |
| `PodAndContainerStatsFromCRI` | `false` | Alpha | 1.23 | |
| `PodAffinityNamespaceSelector` | `false` | Alpha | 1.21 | 1.21 |
| `PodAffinityNamespaceSelector` | `true` | Beta | 1.22 | |
@@ -784,7 +784,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
[readiness probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes).
- `ExpandCSIVolumes`: Enable the expanding of CSI volumes.
- `ExpandedDNSConfig`: Enable kubelet and kube-apiserver to allow more DNS
- search paths and longer list of DNS search paths. See
+ search paths and longer list of DNS search paths. This feature requires container
+ runtime support(Containerd: v1.5.6 or higher, CRI-O: v1.22 or higher). See
[Expanded DNS Configuration](/docs/concepts/services-networking/dns-pod-service/#expanded-dns-configuration).
- `ExpandInUsePersistentVolumes`: Enable expanding in-use PVCs. See
[Resizing an in-use PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#resizing-an-in-use-persistentvolumeclaim).
@@ -913,9 +914,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
Must be used with `KubeletConfiguration.failSwapOn` set to false.
For more details, please see [swap memory](/docs/concepts/architecture/nodes/#swap-memory)
- `NonPreemptingPriority`: Enable `preemptionPolicy` field for PriorityClass and Pod.
-- `OpenAPIEnum`: Enables populating "enum" fields of OpenAPI schemas in the
+- `OpenAPIEnums`: Enables populating "enum" fields of OpenAPI schemas in the
spec returned from the API server.
-- `OpenAPIv3`: Enables the API server to publish OpenAPI v3.
+- `OpenAPIV3`: Enables the API server to publish OpenAPI v3.
- `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
being deleted when it is still used by any Pod.
- `PodDeletionCost`: Enable the [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)
diff --git a/content/en/docs/reference/glossary/container-runtime-interface.md b/content/en/docs/reference/glossary/container-runtime-interface.md
index 11f7bc50f4..28a67cbbb4 100644
--- a/content/en/docs/reference/glossary/container-runtime-interface.md
+++ b/content/en/docs/reference/glossary/container-runtime-interface.md
@@ -19,4 +19,4 @@ The Kubernetes Container Runtime Interface (CRI) defines the main
[gRPC](https://grpc.io) protocol for the communication between the
[cluster components](/docs/concepts/overview/components/#node-components)
{{< glossary_tooltip text="kubelet" term_id="kubelet" >}} and
-{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
+{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}.
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 b5756e5cc2..5693274a59 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-join.md
@@ -41,8 +41,6 @@ For control-plane nodes additional steps are performed:
1. Adding new local etcd member.
-1. Adding this node to the ClusterStatus of the kubeadm cluster.
-
### Using join phases with kubeadm {#join-phases}
Kubeadm allows you join a node to the cluster in phases using `kubeadm join phase`.
diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
index 93d5ce0cbb..9a5f9b29fd 100644
--- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
+++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-reset.md
@@ -16,8 +16,7 @@ Performs a best effort revert of changes made by `kubeadm init` or `kubeadm join
`kubeadm reset` is responsible for cleaning up a node local file system from files that were created using
the `kubeadm init` or `kubeadm join` commands. For control-plane nodes `reset` also removes the local stacked
-etcd member of this node from the etcd cluster and also removes this node's information from the kubeadm
-`ClusterStatus` object. `ClusterStatus` is a kubeadm managed Kubernetes API object that holds a list of kube-apiserver endpoints.
+etcd member of this node from the etcd cluster.
`kubeadm reset phase` can be used to execute the separate phases of the above workflow.
To skip a list of phases you can use the `--skip-phases` flag, which works in a similar way to
diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
index 0319ee17fc..b14cd79613 100644
--- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
+++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md
@@ -16,19 +16,20 @@ or upgrades for such nodes. The long term plan is to empower the tool
aspects.
{{< /note >}}
-Kubeadm defaults to running a single member etcd cluster in a static pod managed
-by the kubelet on the control plane node. This is not a high availability setup
-as the etcd cluster contains only one member and cannot sustain any members
-becoming unavailable. This task walks through the process of creating a high
-availability etcd cluster of three members that can be used as an external etcd
-when using kubeadm to set up a kubernetes cluster.
+By default, kubeadm runs a local etcd instance on each control plane node.
+It is also possible to treat the etcd cluster as external and provision
+etcd instances on separate hosts. The differences between the two approaches are covered in the
+[Options for Highly Available topology][/docs/setup/production-environment/tools/kubeadm/ha-topology] page.
+This task walks through the process of creating a high availability external
+etcd cluster of three members that can be used by kubeadm during cluster creation.
## {{% heading "prerequisites" %}}
-* Three hosts that can talk to each other over ports 2379 and 2380. This
+* Three hosts that can talk to each other over TCP ports 2379 and 2380. This
document assumes these default ports. However, they are configurable through
the kubeadm config file.
-* Each host must [have docker, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
+* Each host must have systemd and a bash compatible shell installed.
+* Each host must [have a container runtime, kubelet, and kubeadm installed](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/).
* Each host should have access to the Kubernetes container image registry (`k8s.gcr.io`) or list/pull the required etcd image using
`kubeadm config images list/pull`. This guide will setup etcd instances as
[static pods](/docs/tasks/configure-pod-container/static-pod/) managed by a kubelet.
@@ -48,6 +49,11 @@ the certificates described below; no other cryptographic tooling is required for
this example.
{{< /note >}}
+{{< note >}}
+The examples below use IPv4 addresses but you can also configure kubeadm, the kubelet and etcd
+to use IPv6 addresses. Dual-stack is supported by some Kubernetes options, but not by etcd. For more details
+on Kubernetes dual-stack support see [Dual-stack support with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/).
+{{< /note >}}
1. Configure the kubelet to be a service manager for etcd.
@@ -59,8 +65,9 @@ this example.
cat << EOF > /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
[Service]
ExecStart=
- # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
- ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd
+ # Replace "systemd" with the cgroup driver of your container runtime. The default value in the kubelet is "cgroupfs".
+ # Replace the value of "--container-runtime-endpoint" for a different container runtime if needed.
+ ExecStart=/usr/bin/kubelet --address=127.0.0.1 --pod-manifest-path=/etc/kubernetes/manifests --cgroup-driver=systemd --container-runtime=remote --container-runtime-endpoint=unix:///var/run/containerd/containerd.sock
Restart=always
EOF
@@ -80,21 +87,34 @@ this example.
member running on it using the following script.
```sh
- # Update HOST0, HOST1, and HOST2 with the IPs or resolvable names of your hosts
+ # Update HOST0, HOST1 and HOST2 with the IPs of your hosts
export HOST0=10.0.0.6
export HOST1=10.0.0.7
export HOST2=10.0.0.8
+ # Update NAME0, NAME1 and NAME2 with the hostnames of your hosts
+ export NAME0="infra0"
+ export NAME1="infra1"
+ export NAME2="infra2"
+
# Create temp directories to store files that will end up on other hosts.
mkdir -p /tmp/${HOST0}/ /tmp/${HOST1}/ /tmp/${HOST2}/
- ETCDHOSTS=(${HOST0} ${HOST1} ${HOST2})
- NAMES=("infra0" "infra1" "infra2")
+ HOSTS=(${HOST0} ${HOST1} ${HOST2})
+ NAMES=(${NAME0} ${NAME1} ${NAME2})
- for i in "${!ETCDHOSTS[@]}"; do
- HOST=${ETCDHOSTS[$i]}
+ for i in "${!HOSTS[@]}"; do
+ HOST=${HOSTS[$i]}
NAME=${NAMES[$i]}
cat << EOF > /tmp/${HOST}/kubeadmcfg.yaml
+ ---
+ apiVersion: "kubeadm.k8s.io/v1beta3"
+ kind: InitConfiguration
+ nodeRegistration:
+ name: ${NAME}
+ localAPIEndpoint:
+ advertiseAddress: ${HOST}
+ ---
apiVersion: "kubeadm.k8s.io/v1beta3"
kind: ClusterConfiguration
etcd:
@@ -104,7 +124,7 @@ this example.
peerCertSANs:
- "${HOST}"
extraArgs:
- initial-cluster: ${NAMES[0]}=https://${ETCDHOSTS[0]}:2380,${NAMES[1]}=https://${ETCDHOSTS[1]}:2380,${NAMES[2]}=https://${ETCDHOSTS[2]}:2380
+ initial-cluster: ${NAMES[0]}=https://${HOSTS[0]}:2380,${NAMES[1]}=https://${HOSTS[1]}:2380,${NAMES[2]}=https://${HOSTS[2]}:2380
initial-cluster-state: new
name: ${NAME}
listen-peer-urls: https://${HOST}:2380
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 153243ffef..aa7a623c42 100644
--- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
@@ -37,8 +37,11 @@ The upgrade workflow at high level is the following:
### Additional information
-- [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/) before kubelet MINOR version
- upgrades is required. In the case of control plane nodes, they could be running CoreDNS Pods or other critical workloads.
+- The instructions below outline when to drain each node during the upgrade process.
+If you are performing a **minor** version upgrade for any kubelet, you **must**
+first drain the node (or nodes) that you are upgrading. In the case of control plane nodes,
+they could be running CoreDNS Pods or other critical workloads. For more information see
+[Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/).
- All containers are restarted after upgrade, because the container spec hash value is changed.
diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md
index ddfefb6f49..da3bdc1148 100644
--- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md
+++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md
@@ -52,7 +52,7 @@ For example: on COS images, Docker exposes its Unix domain socket at
Here's a sample shell script to find Pods that have a mount directly mapping the
Docker socket. This script outputs the namespace and name of the pod. You can
-remove the grep `/var/run/docker.sock` to review other mounts.
+remove the `grep '/var/run/docker.sock'` to review other mounts.
```bash
kubectl get pods --all-namespaces \
diff --git a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
index 949f1922c4..0024ff8bbc 100644
--- a/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
+++ b/content/en/docs/tasks/tools/included/optional-kubectl-configs-bash-linux.md
@@ -26,19 +26,18 @@ Reload your shell and verify that bash-completion is correctly installed by typi
### Enable kubectl autocompletion
+#### Bash
+
You now need to ensure that the kubectl completion script gets sourced in all your shell sessions. There are two ways in which you can do this:
-- Source the completion script in your `~/.bashrc` file:
-
- ```bash
- echo 'source <(kubectl completion bash)' >>~/.bashrc
- ```
-
-- Add the completion script to the `/etc/bash_completion.d` directory:
-
- ```bash
- kubectl completion bash >/etc/bash_completion.d/kubectl
- ```
+{{< tabs name="kubectl_bash_autocompletion" >}}
+{{{< tab name="User" codelang="bash" >}}
+echo 'source <(kubectl completion bash)' >>~/.bashrc
+{{< /tab >}}
+{{< tab name="System" codelang="bash" >}}
+kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
+{{< /tab >}}}
+{{< /tabs >}}
If you have an alias for kubectl, you can extend shell completion to work with that alias:
diff --git a/content/en/docs/tutorials/_index.md b/content/en/docs/tutorials/_index.md
index 0f1181e2cf..01bb9a6552 100644
--- a/content/en/docs/tutorials/_index.md
+++ b/content/en/docs/tutorials/_index.md
@@ -47,12 +47,6 @@ Before walking through each tutorial, you may want to bookmark the
* [Running ZooKeeper, A CP Distributed System](/docs/tutorials/stateful-application/zookeeper/)
-## Clusters
-
-* [AppArmor](/docs/tutorials/clusters/apparmor/)
-
-* [seccomp](/docs/tutorials/clusters/seccomp/)
-
## Services
* [Using Source IP](/docs/tutorials/services/source-ip/)
@@ -61,7 +55,8 @@ Before walking through each tutorial, you may want to bookmark the
* [Apply Pod Security Standards at Cluster level](/docs/tutorials/security/cluster-level-pss/)
* [Apply Pod Security Standards at Namespace level](/docs/tutorials/security/ns-level-pss/)
-
+* [AppArmor](/docs/tutorials/security/apparmor/)
+* [seccomp](/docs/tutorials/security/seccomp/)
## {{% heading "whatsnext" %}}
If you would like to write a tutorial, see
diff --git a/content/en/docs/tutorials/clusters/_index.md b/content/en/docs/tutorials/clusters/_index.md
deleted file mode 100644
index 2db6156b6f..0000000000
--- a/content/en/docs/tutorials/clusters/_index.md
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: "Clusters"
-weight: 60
----
-
diff --git a/content/en/docs/tutorials/clusters/apparmor.md b/content/en/docs/tutorials/security/apparmor.md
similarity index 100%
rename from content/en/docs/tutorials/clusters/apparmor.md
rename to content/en/docs/tutorials/security/apparmor.md
diff --git a/content/en/docs/tutorials/clusters/seccomp.md b/content/en/docs/tutorials/security/seccomp.md
similarity index 100%
rename from content/en/docs/tutorials/clusters/seccomp.md
rename to content/en/docs/tutorials/security/seccomp.md
diff --git a/content/fr/_index.html b/content/fr/_index.html
index 836e5b7504..0b7db944f9 100644
--- a/content/fr/_index.html
+++ b/content/fr/_index.html
@@ -43,12 +43,12 @@ Kubernetes est une solution open-source qui vous permet de tirer parti de vos in
- Venez au KubeCon NA Los Angeles, USA du 11 au 15 Octobre 2021
+ Venez au KubeCon Detroit, Michigan, USA du 24 au 28 Octobre 2022
- Venez au KubeCon EU Valence, Espagne du 15 au 20 Mai 2022
+ Venez au KubeCon EU Valence, Espagne + Virtuel du 16 au 20 Mai 2022
| --add-dir-header | +|
If true, adds the file directory to the header of the log messages |
+|
| --admission-control-config-file string | +|
File with admission control configuration. |
+|
| --advertise-address string | +|
The IP address on which to advertise the apiserver to members of the cluster. This address must be reachable by the rest of the cluster. If blank, the --bind-address will be used. If --bind-address is unspecified, the host's default interface will be used. |
+|
| --allow-metric-labels stringToString Default: [] | +|
The map from metric-label to value allow-list of this label. The key's format is <MetricName>,<LabelName>. The value's format is <allowed_value>,<allowed_value>...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'. |
+|
| --allow-privileged | +|
If true, allow privileged containers. [default=false] |
+|
| --alsologtostderr | +|
log to standard error as well as files |
+|
| --anonymous-auth Default: true | +|
Enables anonymous requests to the secure port of the API server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. |
+|
| --api-audiences strings | +|
Identifiers of the API. The service account token authenticator will validate that tokens used against the API are bound to at least one of these audiences. If the --service-account-issuer flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL. |
+|
| --apiserver-count int Default: 1 | +|
The number of apiservers running in the cluster, must be a positive number. (In use when --endpoint-reconciler-type=master-count is enabled.) |
+|
| --audit-log-batch-buffer-size int Default: 10000 | +|
The size of the buffer to store events before batching and writing. Only used in batch mode. |
+|
| --audit-log-batch-max-size int Default: 1 | +|
The maximum size of a batch. Only used in batch mode. |
+|
| --audit-log-batch-max-wait duration | +|
The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode. |
+|
| --audit-log-batch-throttle-burst int | +|
Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode. |
+|
| --audit-log-batch-throttle-enable | +|
Whether batching throttling is enabled. Only used in batch mode. |
+|
| --audit-log-batch-throttle-qps float | +|
Maximum average number of batches per second. Only used in batch mode. |
+|
| --audit-log-compress | +|
If set, the rotated log files will be compressed using gzip. |
+|
| --audit-log-format string Default: "json" | +|
Format of saved audits. "legacy" indicates 1-line text format for each event. "json" indicates structured json format. Known formats are legacy,json. |
+|
| --audit-log-maxage int | +|
The maximum number of days to retain old audit log files based on the timestamp encoded in their filename. |
+|
| --audit-log-maxbackup int | +|
The maximum number of old audit log files to retain. |
+|
| --audit-log-maxsize int | +|
The maximum size in megabytes of the audit log file before it gets rotated. |
+|
| --audit-log-mode string Default: "blocking" | +|
Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict. |
+|
| --audit-log-path string | +|
If set, all requests coming to the apiserver will be logged to this file. '-' means standard out. |
+|
| --audit-log-truncate-enabled | +|
Whether event and batch truncating is enabled. |
+|
| --audit-log-truncate-max-batch-size int Default: 10485760 | +|
Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size. |
+|
| --audit-log-truncate-max-event-size int Default: 102400 | +|
Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded. |
+|
| --audit-log-version string Default: "audit.k8s.io/v1" | +|
API group and version used for serializing audit events written to log. |
+|
| --audit-policy-file string | +|
Path to the file that defines the audit policy configuration. |
+|
| --audit-webhook-batch-buffer-size int Default: 10000 | +|
The size of the buffer to store events before batching and writing. Only used in batch mode. |
+|
| --audit-webhook-batch-max-size int Default: 400 | +|
The maximum size of a batch. Only used in batch mode. |
+|
| --audit-webhook-batch-max-wait duration Default: 30s | +|
The amount of time to wait before force writing the batch that hadn't reached the max size. Only used in batch mode. |
+|
| --audit-webhook-batch-throttle-burst int Default: 15 | +|
Maximum number of requests sent at the same moment if ThrottleQPS was not utilized before. Only used in batch mode. |
+|
| --audit-webhook-batch-throttle-enable Default: true | +|
Whether batching throttling is enabled. Only used in batch mode. |
+|
| --audit-webhook-batch-throttle-qps float Default: 10 | +|
Maximum average number of batches per second. Only used in batch mode. |
+|
| --audit-webhook-config-file string | +|
Path to a kubeconfig formatted file that defines the audit webhook configuration. |
+|
| --audit-webhook-initial-backoff duration Default: 10s | +|
The amount of time to wait before retrying the first failed request. |
+|
| --audit-webhook-mode string Default: "batch" | +|
Strategy for sending audit events. Blocking indicates sending events should block server responses. Batch causes the backend to buffer and write events asynchronously. Known modes are batch,blocking,blocking-strict. |
+|
| --audit-webhook-truncate-enabled | +|
Whether event and batch truncating is enabled. |
+|
| --audit-webhook-truncate-max-batch-size int Default: 10485760 | +|
Maximum size of the batch sent to the underlying backend. Actual serialized size can be several hundreds of bytes greater. If a batch exceeds this limit, it is split into several batches of smaller size. |
+|
| --audit-webhook-truncate-max-event-size int Default: 102400 | +|
Maximum size of the audit event sent to the underlying backend. If the size of an event is greater than this number, first request and response are removed, and if this doesn't reduce the size enough, event is discarded. |
+|
| --audit-webhook-version string Default: "audit.k8s.io/v1" | +|
API group and version used for serializing audit events written to webhook. |
+|
| --authentication-token-webhook-cache-ttl duration Default: 2m0s | +|
The duration to cache responses from the webhook token authenticator. |
+|
| --authentication-token-webhook-config-file string | +|
File with webhook configuration for token authentication in kubeconfig format. The API server will query the remote service to determine authentication for bearer tokens. |
+|
| --authentication-token-webhook-version string Default: "v1beta1" | +|
The API version of the authentication.k8s.io TokenReview to send to and expect from the webhook. |
+|
| --authorization-mode strings Default: "AlwaysAllow" | +|
Ordered list of plug-ins to do authorization on secure port. Comma-delimited list of: AlwaysAllow,AlwaysDeny,ABAC,Webhook,RBAC,Node. |
+|
| --authorization-policy-file string | +|
File with authorization policy in json line by line format, used with --authorization-mode=ABAC, on the secure port. |
+|
| --authorization-webhook-cache-authorized-ttl duration Default: 5m0s | +|
The duration to cache 'authorized' responses from the webhook authorizer. |
+|
| --authorization-webhook-cache-unauthorized-ttl duration Default: 30s | +|
The duration to cache 'unauthorized' responses from the webhook authorizer. |
+|
| --authorization-webhook-config-file string | +|
File with webhook configuration in kubeconfig format, used with --authorization-mode=Webhook. The API server will query the remote service to determine access on the API server's secure port. |
+|
| --authorization-webhook-version string Default: "v1beta1" | +|
The API version of the authorization.k8s.io SubjectAccessReview to send to and expect from the webhook. |
+|
| --azure-container-registry-config string | +|
Path to the file containing Azure container registry configuration information. |
+|
| --bind-address string Default: 0.0.0.0 | +|
The IP address on which to listen for the --secure-port port. The associated interface(s) must be reachable by the rest of the cluster, and by CLI/web clients. If blank or an unspecified address (0.0.0.0 or ::), all interfaces will be used. |
+|
| --cert-dir string Default: "/var/run/kubernetes" | +|
The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. |
+|
| --client-ca-file string | +|
If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. |
+|
| --cloud-config string | +|
The path to the cloud provider configuration file. Empty string for no configuration file. |
+|
| --cloud-provider string | +|
The provider for cloud services. Empty string for no provider. |
+|
| --cloud-provider-gce-l7lb-src-cidrs cidrs Default: 130.211.0.0/22,35.191.0.0/16 | +|
CIDRs opened in GCE firewall for L7 LB traffic proxy & health checks |
+|
| --contention-profiling | +|
Enable lock contention profiling, if profiling is enabled |
+|
| --cors-allowed-origins strings | +|
List of allowed origins for CORS, comma separated. An allowed origin can be a regular expression to support subdomain matching. If this list is empty CORS will not be enabled. |
+|
| --default-not-ready-toleration-seconds int Default: 300 | +|
Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration. |
+|
| --default-unreachable-toleration-seconds int Default: 300 | +|
Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration. |
+|
| --default-watch-cache-size int Default: 100 | +|
Default watch cache size. If zero, watch cache will be disabled for resources that do not have a default watch size set. |
+|
| --delete-collection-workers int Default: 1 | +|
Number of workers spawned for DeleteCollection call. These are used to speed up namespace cleanup. |
+|
| --disable-admission-plugins strings | +|
admission plugins that should be disabled although they are in the default enabled plugins list (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter. |
+|
| --disabled-metrics strings | +|
This flag provides an escape hatch for misbehaving metrics. You must provide the fully qualified metric name in order to disable it. Disclaimer: disabling metrics is higher in precedence than showing hidden metrics. |
+|
| --egress-selector-config-file string | +|
File with apiserver egress selector configuration. |
+|
| --enable-admission-plugins strings | +|
admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodSecurityPolicy, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter. |
+|
| --enable-aggregator-routing | +|
Turns on aggregator routing requests to endpoints IP rather than cluster IP. |
+|
| --enable-bootstrap-token-auth | +|
Enable to allow secrets of type 'bootstrap.kubernetes.io/token' in the 'kube-system' namespace to be used for TLS bootstrapping authentication. |
+|
| --enable-garbage-collector Default: true | +|
Enables the generic garbage collector. MUST be synced with the corresponding flag of the kube-controller-manager. |
+|
| --enable-priority-and-fairness Default: true | +|
If true and the APIPriorityAndFairness feature gate is enabled, replace the max-in-flight handler with an enhanced one that queues and dispatches with priority and fairness |
+|
| --encryption-provider-config string | +|
The file containing configuration for encryption providers to be used for storing secrets in etcd |
+|
| --endpoint-reconciler-type string Default: "lease" | +|
Use an endpoint reconciler (master-count, lease, none) |
+|
| --etcd-cafile string | +|
SSL Certificate Authority file used to secure etcd communication. |
+|
| --etcd-certfile string | +|
SSL certification file used to secure etcd communication. |
+|
| --etcd-compaction-interval duration Default: 5m0s | +|
The interval of compaction requests. If 0, the compaction request from apiserver is disabled. |
+|
| --etcd-count-metric-poll-period duration Default: 1m0s | +|
Frequency of polling etcd for number of resources per type. 0 disables the metric collection. |
+|
| --etcd-db-metric-poll-interval duration Default: 30s | +|
The interval of requests to poll etcd and update metric. 0 disables the metric collection |
+|
| --etcd-healthcheck-timeout duration Default: 2s | +|
The timeout to use when checking etcd health. |
+|
| --etcd-keyfile string | +|
SSL key file used to secure etcd communication. |
+|
| --etcd-prefix string Default: "/registry" | +|
The prefix to prepend to all resource paths in etcd. |
+|
| --etcd-servers strings | +|
List of etcd servers to connect with (scheme://ip:port), comma separated. |
+|
| --etcd-servers-overrides strings | +|
Per-resource etcd servers overrides, comma separated. The individual override format: group/resource#servers, where servers are URLs, semicolon separated. Note that this applies only to resources compiled into this server binary. |
+|
| --event-ttl duration Default: 1h0m0s | +|
Amount of time to retain events. |
+|
| --experimental-logging-sanitization | +|
[Experimental] When enabled prevents logging of fields tagged as sensitive (passwords, keys, tokens). |
+|
| --external-hostname string | +|
The hostname to use when generating externalized URLs for this master (e.g. Swagger API Docs or OpenID Discovery). |
+|
| --feature-gates <comma-separated 'key=True|False' pairs> | +|
A set of key=value pairs that describe feature gates for alpha/experimental features. Options are: |
+|
| --goaway-chance float | +|
To prevent HTTP/2 clients from getting stuck on a single apiserver, randomly close a connection (GOAWAY). The client's other in-flight requests won't be affected, and the client will reconnect, likely landing on a different apiserver after going through the load balancer again. This argument sets the fraction of requests that will be sent a GOAWAY. Clusters with single apiservers, or which don't use a load balancer, should NOT enable this. Min is 0 (off), Max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. |
+|
| -h, --help | +|
help for kube-apiserver |
+|
| --http2-max-streams-per-connection int | +|
The limit that the server gives to clients for the maximum number of streams in an HTTP/2 connection. Zero means to use golang's default. |
+|
| --identity-lease-duration-seconds int Default: 3600 | +|
The duration of kube-apiserver lease in seconds, must be a positive number. (In use when the APIServerIdentity feature gate is enabled.) |
+|
| --identity-lease-renew-interval-seconds int Default: 10 | +|
The interval of kube-apiserver renewing its lease in seconds, must be a positive number. (In use when the APIServerIdentity feature gate is enabled.) |
+|
| --kubelet-certificate-authority string | +|
Path to a cert file for the certificate authority. |
+|
| --kubelet-client-certificate string | +|
Path to a client cert file for TLS. |
+|
| --kubelet-client-key string | +|
Path to a client key file for TLS. |
+|
| --kubelet-preferred-address-types strings Default: "Hostname,InternalDNS,InternalIP,ExternalDNS,ExternalIP" | +|
List of the preferred NodeAddressTypes to use for kubelet connections. |
+|
| --kubelet-timeout duration Default: 5s | +|
Timeout for kubelet operations. |
+|
| --kubernetes-service-node-port int | +|
If non-zero, the Kubernetes master service (which apiserver creates/maintains) will be of type NodePort, using this as the value of the port. If zero, the Kubernetes master service will be of type ClusterIP. |
+|
| --lease-reuse-duration-seconds int Default: 60 | +|
The time in seconds that each lease is reused. A lower value could avoid large number of objects reusing the same lease. Notice that a too small value may cause performance problems at storage layer. |
+|
| --livez-grace-period duration | +|
This option represents the maximum amount of time it should take for apiserver to complete its startup sequence and become live. From apiserver's start time to when this amount of time has elapsed, /livez will assume that unfinished post-start hooks will complete successfully and therefore return true. |
+|
| --log-backtrace-at <a string in the form 'file:N'> Default: :0 | +|
when logging hits line file:N, emit a stack trace |
+|
| --log-dir string | +|
If non-empty, write log files in this directory |
+|
| --log-file string | +|
If non-empty, use this log file |
+|
| --log-file-max-size uint Default: 1800 | +|
Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. |
+|
| --log-flush-frequency duration Default: 5s | +|
Maximum number of seconds between log flushes |
+|
| --logging-format string Default: "text" | +|
Sets the log format. Permitted formats: "text". |
+|
| --logtostderr Default: true | +|
log to standard error instead of files |
+|
| --master-service-namespace string Default: "default" | +|
DEPRECATED: the namespace from which the Kubernetes master services should be injected into pods. |
+|
| --max-connection-bytes-per-sec int | +|
If non-zero, throttle each user connection to this number of bytes/sec. Currently only applies to long-running requests. |
+|
| --max-mutating-requests-inflight int Default: 200 | +|
This and --max-requests-inflight are summed to determine the server's total concurrency limit (which must be positive) if --enable-priority-and-fairness is true. Otherwise, this flag limits the maximum number of mutating requests in flight, or a zero value disables the limit completely. |
+|
| --max-requests-inflight int Default: 400 | +|
This and --max-mutating-requests-inflight are summed to determine the server's total concurrency limit (which must be positive) if --enable-priority-and-fairness is true. Otherwise, this flag limits the maximum number of non-mutating requests in flight, or a zero value disables the limit completely. |
+|
| --min-request-timeout int Default: 1800 | +|
An optional field indicating the minimum number of seconds a handler must keep a request open before timing it out. Currently only honored by the watch request handler, which picks a randomized value above this number as the connection timeout, to spread out load. |
+|
| --oidc-ca-file string | +|
If set, the OpenID server's certificate will be verified by one of the authorities in the oidc-ca-file, otherwise the host's root CA set will be used. |
+|
| --oidc-client-id string | +|
The client ID for the OpenID Connect client, must be set if oidc-issuer-url is set. |
+|
| --oidc-groups-claim string | +|
If provided, the name of a custom OpenID Connect claim for specifying user groups. The claim value is expected to be a string or array of strings. This flag is experimental, please see the authentication documentation for further details. |
+|
| --oidc-groups-prefix string | +|
If provided, all groups will be prefixed with this value to prevent conflicts with other authentication strategies. |
+|
| --oidc-issuer-url string | +|
The URL of the OpenID issuer, only HTTPS scheme will be accepted. If set, it will be used to verify the OIDC JSON Web Token (JWT). |
+|
| --oidc-required-claim <comma-separated 'key=value' pairs> | +|
A key=value pair that describes a required claim in the ID Token. If set, the claim is verified to be present in the ID Token with a matching value. Repeat this flag to specify multiple claims. |
+|
| --oidc-signing-algs strings Default: "RS256" | +|
Comma-separated list of allowed JOSE asymmetric signing algorithms. JWTs with a 'alg' header value not in this list will be rejected. Values are defined by RFC 7518 https://tools.ietf.org/html/rfc7518#section-3.1. |
+|
| --oidc-username-claim string Default: "sub" | +|
The OpenID claim to use as the user name. Note that claims other than the default ('sub') is not guaranteed to be unique and immutable. This flag is experimental, please see the authentication documentation for further details. |
+|
| --oidc-username-prefix string | +|
If provided, all usernames will be prefixed with this value. If not provided, username claims other than 'email' are prefixed by the issuer URL to avoid clashes. To skip any prefixing, provide the value '-'. |
+|
| --one-output | +|
If true, only write logs to their native severity level (vs also writing to each lower severity level) |
+|
| --permit-address-sharing | +|
If true, SO_REUSEADDR will be used when binding the port. This allows binding to wildcard IPs like 0.0.0.0 and specific IPs in parallel, and it avoids waiting for the kernel to release sockets in TIME_WAIT state. [default=false] |
+|
| --permit-port-sharing | +|
If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false] |
+|
| --profiling Default: true | +|
Enable profiling via web interface host:port/debug/pprof/ |
+|
| --proxy-client-cert-file string | +|
Client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. It is expected that this cert includes a signature from the CA in the --requestheader-client-ca-file flag. That CA is published in the 'extension-apiserver-authentication' configmap in the kube-system namespace. Components receiving calls from kube-aggregator should use that CA to perform their half of the mutual TLS verification. |
+|
| --proxy-client-key-file string | +|
Private key for the client certificate used to prove the identity of the aggregator or kube-apiserver when it must call out during a request. This includes proxying requests to a user api-server and calling out to webhook admission plugins. |
+|
| --request-timeout duration Default: 1m0s | +|
An optional field indicating the duration a handler must keep a request open before timing it out. This is the default request timeout for requests but may be overridden by flags such as --min-request-timeout for specific types of requests. |
+|
| --requestheader-allowed-names strings | +|
List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed. |
+|
| --requestheader-client-ca-file string | +|
Root certificate bundle to use to verify client certificates on incoming requests before trusting usernames in headers specified by --requestheader-username-headers. WARNING: generally do not depend on authorization being already done for incoming requests. |
+|
| --requestheader-extra-headers-prefix strings | +|
List of request header prefixes to inspect. X-Remote-Extra- is suggested. |
+|
| --requestheader-group-headers strings | +|
List of request headers to inspect for groups. X-Remote-Group is suggested. |
+|
| --requestheader-username-headers strings | +|
List of request headers to inspect for usernames. X-Remote-User is common. |
+|
| --runtime-config <comma-separated 'key=value' pairs> | +|
A set of key=value pairs that enable or disable built-in APIs. Supported options are: |
+|
| --secure-port int Default: 6443 | +|
The port on which to serve HTTPS with authentication and authorization. It cannot be switched off with 0. |
+|
| --service-account-extend-token-expiration Default: true | +|
Turns on projected service account expiration extension during token generation, which helps safe transition from legacy token to bound service account token feature. If this flag is enabled, admission injected tokens would be extended up to 1 year to prevent unexpected failure during transition, ignoring value of service-account-max-token-expiration. |
+|
| --service-account-issuer strings | +|
Identifier of the service account token issuer. The issuer will assert this identifier in "iss" claim of issued tokens. This value is a string or URI. If this option is not a valid URI per the OpenID Discovery 1.0 spec, the ServiceAccountIssuerDiscovery feature will remain disabled, even if the feature gate is set to true. It is highly recommended that this value comply with the OpenID spec: https://openid.net/specs/openid-connect-discovery-1_0.html. In practice, this means that service-account-issuer must be an https URL. It is also highly recommended that this URL be capable of serving OpenID discovery documents at {service-account-issuer}/.well-known/openid-configuration. When this flag is specified multiple times, the first is used to generate tokens and all are used to determine which issuers are accepted. |
+|
| --service-account-jwks-uri string | +|
Overrides the URI for the JSON Web Key Set in the discovery doc served at /.well-known/openid-configuration. This flag is useful if the discovery docand key set are served to relying parties from a URL other than the API server's external (as auto-detected or overridden with external-hostname). Only valid if the ServiceAccountIssuerDiscovery feature gate is enabled. |
+|
| --service-account-key-file strings | +|
File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key is provided |
+|
| --service-account-lookup Default: true | +|
If true, validate ServiceAccount tokens exist in etcd as part of authentication. |
+|
| --service-account-max-token-expiration duration | +|
The maximum validity duration of a token created by the service account token issuer. If an otherwise valid TokenRequest with a validity duration larger than this value is requested, a token will be issued with a validity duration of this value. |
+|
| --service-account-signing-key-file string | +|
Path to the file that contains the current private key of the service account token issuer. The issuer will sign issued ID tokens with this private key. |
+|
| --service-cluster-ip-range string | +|
A CIDR notation IP range from which to assign service cluster IPs. This must not overlap with any IP ranges assigned to nodes or pods. Max of two dual-stack CIDRs is allowed. |
+|
| --service-node-port-range <a string in the form 'N1-N2'> Default: 30000-32767 | +|
A port range to reserve for services with NodePort visibility. Example: '30000-32767'. Inclusive at both ends of the range. |
+|
| --show-hidden-metrics-for-version string | +|
The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that. |
+|
| --shutdown-delay-duration duration | +|
Time to delay the termination. During that time the server keeps serving requests normally. The endpoints /healthz and /livez will return success, but /readyz immediately returns failure. Graceful termination starts after this delay has elapsed. This can be used to allow load balancer to stop sending traffic to this server. |
+|
| --skip-headers | +|
If true, avoid header prefixes in the log messages |
+|
| --skip-log-headers | +|
If true, avoid headers when opening log files |
+|
| --stderrthreshold int Default: 2 | +|
logs at or above this threshold go to stderr |
+|
| --storage-backend string | +|
The storage backend for persistence. Options: 'etcd3' (default). |
+|
| --storage-media-type string Default: "application/vnd.kubernetes.protobuf" | +|
The media type to use to store objects in storage. Some resources or storage backends may only support a specific media type and will ignore this setting. |
+|
| --strict-transport-security-directives strings | +|
List of directives for HSTS, comma separated. If this list is empty, then HSTS directives will not be added. Example: 'max-age=31536000,includeSubDomains,preload' |
+|
| --tls-cert-file string | +|
File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir. |
+|
| --tls-cipher-suites strings | +|
Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. |
+|
| --tls-min-version string | +|
Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 |
+|
| --tls-private-key-file string | +|
File containing the default x509 private key matching --tls-cert-file. |
+|
| --tls-sni-cert-key string | +|
A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". |
+|
| --token-auth-file string | +|
If set, the file that will be used to secure the secure port of the API server via token authentication. |
+|
| --tracing-config-file string | +|
File with apiserver tracing configuration. |
+|
| -v, --v int | +|
number for the log level verbosity |
+|
| --version version[=true] | +|
Print version information and quit |
+|
| --vmodule <comma-separated 'pattern=N' settings> | +|
comma-separated list of pattern=N settings for file-filtered logging |
+|
| --watch-cache Default: true | +|
Enable watch caching in the apiserver |
+|
| --watch-cache-sizes strings | +|
Watch cache size settings for some resources (pods, nodes, etc.), comma separated. The individual setting format: resource[.group]#size, where resource is lowercase plural (no version), group is omitted for resources of apiVersion v1 (the legacy core API) and included for others, and size is a number. It takes effect when watch-cache is enabled. Some resources (replicationcontrollers, endpoints, nodes, pods, services, apiservices.apiregistration.k8s.io) have system defaults set by heuristics, others default to default-watch-cache-size |
+|
| Field | Description |
|---|---|
apiVersionstring | audit.k8s.io/v1 |
kindstring | Event |
level [Required]+ Level
+ |
++ AuditLevel at which event was generated | +
auditID [Required]+ k8s.io/apimachinery/pkg/types.UID
+ |
++ Unique audit ID, generated for each request. | +
stage [Required]+ Stage
+ |
++ Stage of the request handling when this event instance was generated. | +
requestURI [Required]+ string
+ |
++ RequestURI is the request URI as sent by the client to a server. | +
verb [Required]+ string
+ |
++ Verb is the kubernetes verb associated with the request. +For non-resource requests, this is the lower-cased HTTP method. | +
user [Required]+ authentication/v1.UserInfo
+ |
++ Authenticated user information. | +
impersonatedUser+ authentication/v1.UserInfo
+ |
++ Impersonated user information. | +
sourceIPs+ []string
+ |
++ Source IPs, from where the request originated and intermediate proxies. | +
userAgent+ string
+ |
++ UserAgent records the user agent string reported by the client. +Note that the UserAgent is provided by the client, and must not be trusted. | +
objectRef+ ObjectReference
+ |
++ Object reference this request is targeted at. +Does not apply for List-type requests, or non-resource requests. | +
responseStatus+ meta/v1.Status
+ |
++ The response status, populated even when the ResponseObject is not a Status type. +For successful responses, this will only include the Code and StatusSuccess. +For non-status type error responses, this will be auto-populated with the error Message. | +
requestObject+ k8s.io/apimachinery/pkg/runtime.Unknown
+ |
++ API object from the request, in JSON format. The RequestObject is recorded as-is in the request +(possibly re-encoded as JSON), prior to version conversion, defaulting, admission or +merging. It is an external versioned object type, and may not be a valid object on its own. +Omitted for non-resource requests. Only logged at Request Level and higher. | +
responseObject+ k8s.io/apimachinery/pkg/runtime.Unknown
+ |
++ API object returned in the response, in JSON. The ResponseObject is recorded after conversion +to the external type, and serialized as JSON. Omitted for non-resource requests. Only logged +at Response Level. | +
requestReceivedTimestamp+ meta/v1.MicroTime
+ |
++ Time the request reached the apiserver. | +
stageTimestamp+ meta/v1.MicroTime
+ |
++ Time the request reached current audit stage. | +
annotations+ map[string]string
+ |
++ Annotations is an unstructured key value map stored with an audit event that may be set by +plugins invoked in the request serving chain, including authentication, authorization and +admission plugins. Note that these annotations are for the audit event, and do not correspond +to the metadata.annotations of the submitted object. Keys should uniquely identify the informing +component to avoid name collisions (e.g. podsecuritypolicy.admission.k8s.io/policy). Values +should be short. Annotations are included in the Metadata level. | +
| Field | Description |
|---|---|
apiVersionstring | audit.k8s.io/v1 |
kindstring | EventList |
metadata+ meta/v1.ListMeta
+ |
++ No description provided. + | +
items [Required]+ []Event
+ |
++ No description provided. + | +
| Field | Description |
|---|---|
apiVersionstring | audit.k8s.io/v1 |
kindstring | Policy |
metadata+ meta/v1.ObjectMeta
+ |
+
+ ObjectMeta is included for interoperability with API infrastructure.Refer to the Kubernetes API documentation for the fields of the metadata field. |
+
rules [Required]+ []PolicyRule
+ |
++ Rules specify the audit Level a request should be recorded at. +A request may match multiple rules, in which case the FIRST matching rule is used. +The default audit level is None, but can be overridden by a catch-all rule at the end of the list. +PolicyRules are strictly ordered. | +
omitStages+ []Stage
+ |
++ OmitStages is a list of stages for which no events are created. Note that this can also +be specified per rule in which case the union of both are omitted. | +
| Field | Description |
|---|---|
apiVersionstring | audit.k8s.io/v1 |
kindstring | PolicyList |
metadata+ meta/v1.ListMeta
+ |
++ No description provided. + | +
items [Required]+ []Policy
+ |
++ No description provided. + | +
| Field | Description |
|---|---|
group+ string
+ |
++ Group is the name of the API group that contains the resources. +The empty string represents the core API group. | +
resources+ []string
+ |
++ Resources is a list of resources this rule applies to. + +For example: +'pods' matches pods. +'pods/log' matches the log subresource of pods. +'∗' matches all resources and their subresources. +'pods/∗' matches all subresources of pods. +'∗/scale' matches all scale subresources. + +If wildcard is present, the validation rule will ensure resources do not +overlap with each other. + +An empty list implies all resources and subresources in this API groups apply. | +
resourceNames+ []string
+ |
++ ResourceNames is a list of resource instance names that the policy matches. +Using this field requires Resources to be specified. +An empty list implies that every instance of the resource is matched. | +
| Field | Description |
|---|---|
resource+ string
+ |
++ No description provided. + | +
namespace+ string
+ |
++ No description provided. + | +
name+ string
+ |
++ No description provided. + | +
uid+ k8s.io/apimachinery/pkg/types.UID
+ |
++ No description provided. + | +
apiGroup+ string
+ |
++ APIGroup is the name of the API group that contains the referred object. +The empty string represents the core API group. | +
apiVersion+ string
+ |
++ APIVersion is the version of the API group that contains the referred object. | +
resourceVersion+ string
+ |
++ No description provided. + | +
subresource+ string
+ |
++ No description provided. + | +
| Field | Description |
|---|---|
level [Required]+ Level
+ |
++ The Level that requests matching this rule are recorded at. | +
users+ []string
+ |
++ The users (by authenticated user name) this rule applies to. +An empty list implies every user. | +
userGroups+ []string
+ |
++ The user groups this rule applies to. A user is considered matching +if it is a member of any of the UserGroups. +An empty list implies every user group. | +
verbs+ []string
+ |
++ The verbs that match this rule. +An empty list implies every verb. | +
resources+ []GroupResources
+ |
++ Resources that this rule matches. An empty list implies all kinds in all API groups. | +
namespaces+ []string
+ |
++ Namespaces that this rule matches. +The empty string "" matches non-namespaced resources. +An empty list implies every namespace. | +
nonResourceURLs+ []string
+ |
++ NonResourceURLs is a set of URL paths that should be audited. +∗s are allowed, but only as the full, final step in the path. +Examples: + "/metrics" - Log requests for apiserver metrics + "/healthz∗" - Log all health checks | +
omitStages+ []Stage
+ |
++ OmitStages is a list of stages for which no events are created. Note that this can also +be specified policy wide in which case the union of both are omitted. +An empty list means no restrictions will apply. | +
By Sarah Wells, Technical Director for Operations and Reliability, Financial Times
- +Sarah Wells, Financial Times 운영 및 안정성 기술 담당 이사
+このページの項目は、Kubernetesが必要とする機能を提供するサードパーティー製品またはプロジェクトです。Kubernetesプロジェクトの作者は、それらのサードパーティー製品またはプロジェクトに責任を負いません。詳しくは、CNCFウェブサイトのガイドラインをご覧ください。第三者のリンクを追加するような変更を提案する前に、コンテンツガイドを読むべきです。
""" + [version_check_mustbe] other = "作業するKubernetesサーバーは次のバージョンである必要があります: " diff --git a/static/_redirects b/static/_redirects index 780597c901..10e81668ee 100644 --- a/static/_redirects +++ b/static/_redirects @@ -335,6 +335,8 @@ /docs/tutorials/kubernetes-basics/expose-intro/ /docs/tutorials/kubernetes-basics/expose/expose-intro/ 301 /docs/tutorials/kubernetes-basics/scale-interactive/ /docs/tutorials/kubernetes-basics/scale/scale-interactive/ 301 /docs/tutorials/kubernetes-basics/scale-intro/ /docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 +/docs/tutorials/clusters/apparmor/ /docs/tutorials/security/apparmor/ 301 +/docs/tutorials/clusters/seccomp/ /docs/tutorials/security/seccomp/ 301 /ja/docs/tutorials/kubernetes-basics/scale-intro/ /ja/docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 /ko/docs/tutorials/kubernetes-basics/scale-intro/ /ko/docs/tutorials/kubernetes-basics/scale/scale-intro/ 301 /docs/tutorials/kubernetes-basics/update-interactive/ /docs/tutorials/kubernetes-basics/update/update-interactive/ 301