kubernetes
/
website
mirror of https://github.com/kubernetes/website.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge pull request #32579 from nate-double-u/merged-main-dev-1.24 

Merged main into dev 1.24
pull/32595/head
Kubernetes Prow Robot 2022-03-28 10:23:31 -07:00 committed by GitHub
parent 6da9c34b2e 7c67921f3f
commit 69312dde46
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
189 changed files with 7876 additions and 5343 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
OWNERS_ALIASES
View File

@ -24,6 +24,7 @@ aliases:
- jimangel
- jlbutler
- kbhawkey
- natalisucks
- nate-double-u # RT 1.24 Docs Lead
- onlydole
- pi-victor
@ -40,6 +41,7 @@ aliases:
- jimangel
- kbhawkey
- mehabhalodiya
- natalisucks
- onlydole
- rajeshdeshpande02
- sftim
@ -147,8 +149,11 @@ aliases:
- divya-mohan0209
- jimangel
- kbhawkey
- natalisucks
- onlydole
- reylejano
- sftim
- tengqm
sig-docs-zh-owners: # Admins for Chinese content
# chenopis
- chenrui333
@ -241,7 +246,6 @@ aliases:
# authoritative source: https://git.k8s.io/sig-release/OWNERS_ALIASES
sig-release-leads:
- cpanato # SIG Technical Lead
- hasheddan # SIG Technical Lead
- jeremyrickard # SIG Technical Lead
- justaugustus # SIG Chair
- LappleApple # SIG Program Manager

3
assets/scss/_custom.scss
View File

@ -566,7 +566,8 @@ main.content {
}
}
/* COMMUNITY */
/* COMMUNITY legacy styles */
/* Leave these in place until localizations are caught up */
.newcommunitywrapper {
.news {

34
content/en/blog/_posts/2022-03-31-ready-for-dockershim-removal.md Normal file
View File

@ -0,0 +1,34 @@
---
layout: blog
title: "Is Your Cluster Ready for v1.24?"
date: 2022-03-31
slug: ready-for-dockershim-removal
---
**Author:** Kat Cosgrove
Way back in December of 2020, Kubernetes announced the [deprecation of Dockershim](/blog/2020/12/02/dont-panic-kubernetes-and-docker/). In Kubernetes, dockershim is a software shim that allows you to use the entire Docker engine as your container runtime within Kubernetes. In the upcoming v1.24 release, we are removing Dockershim - the delay between deprecation and removal in line with the [project’s policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/) of supporting features for at least one year after deprecation. If you are a cluster operator, this guide includes the practical realities of what you need to know going into this release. Also, what do you need to do to ensure your cluster doesn’t fall over!
## First, does this even affect you?
If you are rolling your own cluster or are otherwise unsure whether or not this removal affects you, stay on the safe side and [check to see if you have any dependencies on Docker Engine](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/). Please note that using Docker Desktop to build your application containers is not a Docker dependency for your cluster. Container images created by Docker are compliant with the [Open Container Initiative (OCI)](https://opencontainers.org/), a Linux Foundation governance structure that defines industry standards around container formats and runtimes. They will work just fine on any container runtime supported by Kubernetes.
If you are using a managed Kubernetes service from a cloud provider, and you haven’t explicitly changed the container runtime, there may be nothing else for you to do. Amazon EKS, Azure AKS, and Google GKE all default to containerd now, though you should make sure they do not need updating if you have any node customizations. To check the runtime of your nodes, follow [Find Out What Container Runtime is Used on a Node](​​/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/).
Regardless of whether you are rolling your own cluster or using a managed Kubernetes service from a cloud provider, you may need to [migrate telemetry or security agents that rely on Docker Engine](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/).
## I have a Docker dependency. What now?
If your Kubernetes cluster depends on Docker Engine and you intend to upgrade to Kubernetes v1.24 (which you should eventually do for security and similar reasons), you will need to change your container runtime from Docker Engine to something else or use [cri-dockerd](https://github.com/Mirantis/cri-dockerd). Since [containerd](https://containerd.io/) is a graduated CNCF project and the runtime within Docker itself, it’s a safe bet as an alternative container runtime. Fortunately, the Kubernetes project has already documented the process of [changing a node’s container runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/), using containerd as an example. Instructions are similar for switching to one of the other supported runtimes.
## I want to upgrade Kubernetes, and I need to maintain compatibility with Docker as a runtime. What are my options?
Fear not, you aren’t being left out in the cold and you don’t have to take the security risk of staying on an old version of Kubernetes. Mirantis and Docker have jointly released, and are maintaining, a replacement for dockershim. That replacement is called [cri-dockerd](https://github.com/Mirantis/cri-dockerd). If you do need to maintain compatibility with Docker as a runtime, install cri-dockerd following the instructions in the project’s documentation.
## Is that it?
Yes. As long as you go into this release aware of the changes being made and the details of your own clusters, and you make sure to communicate clearly with your development teams, it will be minimally dramatic. You may have some changes to make to your cluster, application code, or scripts, but all of these requirements are documented. Switching from using Docker Engine as your runtime to using [one of the other supported container runtimes](/docs/setup/production-environment/container-runtimes/) effectively means removing the middleman, since the purpose of dockershim is to access the container runtime used by Docker itself. From a practical perspective, this removal is better both for you and for Kubernetes maintainers in the long-run.
If you still have questions, please first check the [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/).

440
content/en/community/_index.html
View File

@ -1,257 +1,183 @@
---
title: Community
layout: basic
cid: community
---
<div class="newcommunitywrapper">
<div class="banner1">
<img src="/images/community/kubernetes-community-final-02.jpg" alt="Kubernetes Conference Gallery" style="width:100%;padding-left:0px" class="desktop">
<img src="/images/community/kubernetes-community-02-mobile.jpg" alt="Kubernetes Conference Gallery" style="width:100%;padding-left:0px" class="mobile">
</div>
<div class="intro">
<br class="mobile">
<p>The Kubernetes community -- users, contributors, and the culture we've built together -- is one of the biggest reasons for the meteoric rise of this open source project. Our culture and values continue to grow and change as the project itself grows and changes. We all work together toward constant improvement of the project and the ways we work on it.
<br><br>We are the people who file issues and pull requests, attend SIG meetings, Kubernetes meetups, and KubeCon, advocate for its adoption and innovation, run <code>kubectl get pods</code>, and contribute in a thousand other vital ways. Read on to learn how you can get involved and become part of this amazing community.</p>
<br class="mobile">
</div>
<div class="community__navbar">
<a href="https://www.kubernetes.dev/">Contributor Community</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#values">Community Values</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#conduct">Code of conduct </a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#videos">Videos</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#discuss">Discussions</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#events">Events and meetups</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="#news">News</a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<a href="/releases">Releases</a>
</div>
<br class="mobile"><br class="mobile">
<div class="imagecols">
<br class="mobile">
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-03.jpg" alt="Kubernetes Conference Gallery" style="width:100%" class="desktop">
</div>
<div class="imagecol">
<img src="/images/community/kubernetes-community-final-04.jpg" alt="Kubernetes Conference Gallery" style="width:100%" class="desktop">
</div>
<div class="imagecol" style="margin-right:0% important">
<img src="/images/community/kubernetes-community-final-05.jpg" alt="Kubernetes Conference Gallery" style="width:100%;margin-right:0% important" class="desktop">
</div>
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="Kubernetes Conference Gallery" style="width:100%;margin-bottom:3%" class="mobile">
<a name="values"></a>
</div>
<div><a name="values"></a></div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Community Values</h1>
The Kubernetes Community values are the keystone to the ongoing success of the project.<br>
These principles guide every aspect of the Kubernetes project.
<br>
<a href="/community/values/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
READ MORE
</span>
</a>
</div><a name="conduct"></a>
</div>
</div>
<div class="conduct">
<div class="conducttext">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="conducttextnobutton" style="margin-bottom:2%"><h1>Code of Conduct</h1>
The Kubernetes community values respect and inclusiveness, and enforces a Code of Conduct in all interactions. If you notice a violation of the Code of Conduct at an event or meeting, in Slack, or in another communication mechanism, reach out to the Kubernetes Code of Conduct Committee at <a href="mailto:conduct@kubernetes.io" style="color:#0662EE;font-weight:300">conduct@kubernetes.io</a>. All reports are kept confidential. You can read about the committee&nbsp;<a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct" style="color:#0662EE;font-weight:300">here</a>.
<br>
<a href="https://kubernetes.io/community/code-of-conduct/">
<br class="mobile"><br class="mobile">
<span class="fullbutton">
READ MORE
</span>
</a>
</div><a name="videos"></a>
</div>
</div>
<div class="videos">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-top:0px">Videos</h1>
<div style="margin-bottom:4%;font-weight:300;text-align:center;padding-left:10%;padding-right:10%">We're on YouTube, a lot. Subscribe for a wide range of&nbsp;topics.</div>
<div class="videocontainer">
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="Monthly office hours" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
<div class="videocta">
Watch monthly office hours&nbsp;&#9654;</div>
</a>
</div>
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="Weekly community meetings" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
<div class="videocta">
Watch weekly community meetings&nbsp;&#9654;
</div>
</a>
</div>
<div class="video">
<iframe width="100%" height="250" src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="Talk from a community member" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
<div class="videocta">
Watch a talk from a community member&nbsp;&#9654;
</div>
</a>
<a name="discuss"></a>
</div>
</div>
</div>
<div class="resources">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="padding-top:1%">Discussions</h1>
<div style="font-weight:300;text-align:center">We talk a lot. Find us and join the conversation on any of these&nbsp;platforms.</div>
<div class="resourcecontainer">
<div class="resourcebox">
<img src="/images/community/discuss.png" alt=Forum" style="width:80%;padding-bottom:2%">
<a href="https://discuss.kubernetes.io/" style="color:#0662EE;display:block;margin-top:1%">
forum&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
Topic-based technical discussions that bridge docs, StackOverflow, and so much&nbsp;more
</div>
</div>
<div class="resourcebox">
<img src="/images/community/twitter.png" alt="Twitter" style="width:80%;padding-bottom:2%">
<a href="https://twitter.com/kubernetesio" style="color:#0662EE;display:block;margin-top:1%">
twitter&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">Real-time announcements of blog posts, events, news, ideas
</div>
</div>
<div class="resourcebox">
<img src="/images/community/github.png" alt="GitHub" style="width:80%;padding-bottom:2%">
<a href="https://github.com/kubernetes/kubernetes" style="color:#0662EE;display:block;margin-top:1%">
github&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
All the project and issue tracking, plus of course code
</div>
</div>
<div class="resourcebox">
<img src="/images/community/stack.png" alt="Stack Overflow" style="width:80%;padding-bottom:2%">
<a href="https://stackoverflow.com/search?q=kubernetes" style="color:#0662EE;display:block;margin-top:1%">
stack overflow&nbsp;&#9654;
</a>
<div class="resourceboxtext" style="font-size:12px;text-transform:none !important;font-weight:300;line-height:1.4em;color:#333333;margin-top:4%">
Technical troubleshooting for any use&nbsp;case
<a name="events"></a>
</div>
</div>
<!--
<div class="resourcebox">
<img src="/images/community/slack.png" style="width:80%">
slack&nbsp;&#9654;
<div class="resourceboxtext" style="font-size:11px;text-transform:none !important;font-weight:200;line-height:1.4em;color:#333333;margin-top:4%">
With 170+ channels, you'll find one that fits your needs.
</div>
</div>-->
</div>
</div>
<div class="events">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<div class="eventcontainer">
<h1 style="color:white !important">Upcoming Events</h1>
{{< upcoming-events >}}
</div>
</div>
<div class="meetups">
<div class="meetupcol">
<div class="meetuptext">
<h1 style="text-align:left">Global Community</h1>
With over 150 meetups in the world and growing, go find your local kube people. If one isn't near, take charge and create your own.
</div>
<a href="https://www.meetup.com/topics/kubernetes/">
<div class="button">
FIND A MEETUP
</div>
</a>
<a name="news"></a>
</div>
</div>
<!--
<div class="contributor">
<div class="contributortext">
<br>
<h1 style="text-align:left">
New Contributors Site
</h1>
Text about new contributors site.
<br><br>
<div class="button">
VISIT SITE
</div>
</div>
</div>
-->
<div class="news">
<br class="mobile"><br class="mobile">
<br class="tablet"><br class="tablet">
<h1 style="margin-bottom:2%">Recent News</h1>
<br>
<div class="twittercol1">
<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw">Tweets by kubernetesio</a> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>
</div>
<br>
<br><br><br><br>
</div>
</div>
---
title: Community
layout: basic
cid: community
community_styles_migrated: true
---
<img
id="banner"
srcset="/images/community/kubernetes-community-final-02.jpg 1500w, /images/community/kubernetes-community-02-mobile.jpg 900w"
sizes="(max-width: 900px) 900px, (max-width: 1920px) 1500px"
src="/images/community/kubernetes-community-final-02.jpg"
alt="Kubernetes conference photo">
<div class="community-section" id="introduction">
<p>The Kubernetes community — users, contributors, and the culture we've
built together — is one of the biggest reasons for the meteoric rise of
this open source project. Our culture and values continue to grow and change
as the project itself grows and changes. We all work together toward constant
improvement of the project and the ways we work on it.</p>
<p> We are the people who file issues and pull requests, attend SIG meetings,
Kubernetes meetups, and KubeCon, advocate for its adoption and innovation,
run <code>kubectl get pods</code>, and contribute in a thousand other vital
ways. Read on to learn how you can get involved and become part of this amazing
community.</p>
</div>
<div id="navigation-items">
<div class="community-nav-item external-link">
<a href="https://www.kubernetes.dev/">Contributor community</a>
</div>
<div class="community-nav-item">
<a href="#values">Community values</a>
</div>
<div class="community-nav-item">
<a href="#conduct">Code of conduct</a>
</div>
<div class="community-nav-item">
<a href="#videos">Videos</a>
</div>
<div class="community-nav-item">
<a href="#discuss">Discussions</a>
</div>
<div class="community-nav-item">
<a href="#meetups">Meetups</a>
</div>
<div class="community-nav-item">
<a href="#news">News</a>
</div>
<div class="community-nav-item">
<a href="/releases">Releases</a>
</div>
</div>
<div class="community-section" id="gallery">
<img src="/images/community/kubernetes-community-final-03.jpg" alt="Kubernetes conference gallery photo" class="community-gallery-desktop">
<img src="/images/community/kubernetes-community-final-04.jpg" alt="Kubernetes conference gallery photo" class="community-gallery-desktop">
<img src="/images/community/kubernetes-community-final-05.jpg" alt="Kubernetes conference gallery photo" class="community-gallery-desktop">
<img src="/images/community/kubernetes-community-04-mobile.jpg" alt="Kubernetes conference gallery photo" class="community-gallery-mobile">
</div>
<div class="community-section" id="values">
<h2>Community Values</h2>
<p>The Kubernetes Community values are the keystone to the ongoing success of the project.<br class="optional"/>
These principles guide every aspect of the Kubernetes project.</p>
<a href="https://www.kubernetes.dev/community/values/" class="community-cta-button">
<span class="community-cta">Read more</span>
</a>
</div>
<div class="community-section" id="conduct">
<h2>Code of Conduct</h2>
<p>The Kubernetes community values respect and inclusiveness, and enforces a Code of Conduct in all interactions.</p>
<p>If you notice a violation of the Code of Conduct at an event or meeting, in <a href="#slack">Slack</a>, or in another communication mechanism, reach out to the Kubernetes Code of Conduct Committee at <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>. All reports are kept confidential. You can read <a href="https://github.com/kubernetes/community/tree/master/committee-code-of-conduct">about the committee</a> in the Kubernetes community repository on GitHub.</p>
<a href="/community/code-of-conduct/" class="community-cta-button">
<span class="community-cta">Read more</span>
</a>
</div>
<div id="videos" class="community-section">
<h2>Videos</h2>
<p class="community-simple">Kubernetes is on YouTube, a lot. Subscribe for a wide range of&nbsp;topics.</p>
<div class="container">
<div class="video youtube">
<iframe src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg" title="Monthly office hours" allow="camera 'none'; microphone 'none'; geolocation 'none'; fullscreen https://www.youtube.com/" ></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3azFUvYJjGn45YbF6C-uIg">
<span class="videocta">Watch monthly office hours&nbsp;&#9654;</span>
</a>
</div>
<div class="video youtube">
<iframe src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" title="Weekly community meetings" allow="camera 'none'; microphone 'none'; geolocation 'none'; fullscreen https://www.youtube.com/"></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ">
<span class="videocta">Watch weekly community meetings&nbsp;&#9654;</span>
</a>
</div>
<div class="video youtube" id="discuss">
<iframe src="https://www.youtube.com/embed/videoseries?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F" title="Talk from a community member" allow="camera 'none'; microphone 'none'; geolocation 'none'; fullscreen https://www.youtube.com/"></iframe>
<a href="https://www.youtube.com/playlist?list=PL69nYSiGNLP3QpQrhZq_sLYo77BVKv09F">
<span class="videocta">Watch a talk from a community member&nbsp;&#9654;</span>
</a>
</div>
</div>
</div>
<div id="resources" class="community-section">
<h2>Discussions</h2>
<p class="community-simple">We talk a lot. Find us and join the conversation on any of these&nbsp;platforms.</p>
<div class="container">
<div class="community-resource">
<a href="https://discuss.kubernetes.io/">
<img src="/images/community/discuss.png" alt="Forum">
</a>
<a href="https://discuss.kubernetes.io/">Community forums&nbsp;&#9654;</a>
<p>Topic-based technical discussions that bridge docs,
troubleshooting, and so much&nbsp;more.</p>
</div>
<div id="twitter" class="community-resource">
<a href="https://twitter.com/kubernetesio">
<img src="/images/community/twitter.png" alt="Twitter">
</a>
<a href="https://twitter.com/kubernetesio">Twitter&nbsp;&#9654;</a>
<p><em>#kubernetesio</em></p>
<p>Real-time announcements of blog posts, events, news, ideas.</p>
</div>
<div id="github" class="community-resource">
<a href="https://github.com/kubernetes/kubernetes">
<img src="/images/community/github.png" alt="GitHub">
</a>
<a href="https://github.com/kubernetes/kubernetes">GitHub&nbsp;&#9654;</a>
<p>All the project and issue tracking, plus of course code.</p>
</div>
<div id="server-fault" class="community-resource">
<a href="https://serverfault.com/questions/tagged/kubernetes">
<img src="/images/community/serverfault.png" alt="Server Fault">
</a>
<a href="https://serverfault.com/questions/tagged/kubernetes">Server Fault&nbsp;&#9654;</a>
<p>Kubernetes-related discussion on Server Fault. Ask a question, or answer one.</p>
</div>
<div id="slack" class="community-resource">
<a href="https://kubernetes.slack.com/">
<img src="/images/community/slack.png" alt="Slack">
</a>
<a href="https://kubernetes.slack.com/">Slack&nbsp;&#9654;</a>
<p>With 170+ channels, you'll find one that fits your needs.</p>
<details><summary><em>Need an invitation?</em></summary>
Visit <a href="https://slack.k8s.io/">https://slack.k8s.io/</a>
for an invitation.</details>
</div>
</div>
</div>
<div class="community-section" id="events">
<div class="container">
<h2>Upcoming Events</h2>
{{< upcoming-events >}}
</div>
</div>
<div class="community-section" id="meetups">
<h2>Global community</h2>
<p>
With over 150 meetups in the world and growing, go find your local kube people. If one isn't near, take charge and create your own.
</p>
<a href="https://www.meetup.com/topics/kubernetes/" class="community-cta-button">
<span class="community-cta">Find a meetup</span>
</a>
</div>
<div class="community-section community-frame" id="news">
<h2>Recent News</h2>
<div class="twittercol1">
<a class="twitter-timeline" data-tweet-limit="1" href="https://twitter.com/kubernetesio?ref_src=twsrc%5Etfw">Tweets by kubernetesio</a>
</div>
</div>

16
content/en/community/code-of-conduct.md
View File

@ -1,27 +1,29 @@
---
title: Community
title: Kubernetes Community Code of Conduct
layout: basic
cid: community
css: /css/community.css
community_styles_migrated: true
---
<div class="community_main">
<h1>Kubernetes Community Code of Conduct</h1>
<div class="community-section" id="cncf-code-of-conduct-intro">
<p>
Kubernetes follows the
<a href="https://github.com/cncf/foundation/blob/master/code-of-conduct.md">CNCF Code of Conduct</a>.
The text of the CNCF CoC is replicated below, as of
<a href="https://github.com/cncf/foundation/blob/214585e24aab747fb85c2ea44fbf4a2442e30de6/code-of-conduct.md">commit 214585e</a>.
If you notice that this is out of date, please
<a href="https://github.com/kubernetes/website/issues/new">file an issue</a>.
</p>
<p>
If you notice a violation of the Code of Conduct at an event or meeting, in
Slack, or in another communication mechanism, reach out to
the <a href="https://git.k8s.io/community/committee-code-of-conduct">Kubernetes Code of Conduct Committee</a>.
You can reach us by email at <a href="mailto:conduct@kubernetes.io">conduct@kubernetes.io</a>.
Your anonymity will be protected.
</p>
</div>
<div class="cncf_coc_container">
<div id="cncf-code-of-conduct">
{{< include "/static/cncf-code-of-conduct.md" >}}
</div>
</div>

7
content/en/community/static/OWNERS Normal file
View File

@ -0,0 +1,7 @@
# See the OWNERS docs at https://go.k8s.io/owners
# Disable inheritance to encourage careful review of any changes here.
options:
no_parent_owners: true
approvers:
- sig-docs-leads

5
content/en/community/static/README.md
View File

@ -1,2 +1,5 @@
The files in this directory have been imported from other sources. Do not
edit them directly, except by replacing them with new versions.
edit them directly, except by replacing them with new versions.
Localization note: you do not need to create localized versions of any of
the files in this directory.

19
content/en/community/values.md
View File

@ -1,13 +1,18 @@
---
title: Community
title: Kubernetes Community Values
layout: basic
cid: community
css: /css/community.css
community_styles_migrated: true
# this page is deprecated
# canonical page is https://www.kubernetes.dev/community/values/
sitemap:
priority: 0.1
---
<div class="community_main">
<div class="cncf_coc_container">
<div class="community-section" id="values-legacy">
{{< include "/static/community-values.md" >}}
</div>
</div>
<!-- no need to localize this file, nor the contents of the static directory -->
<!-- if localizing, find the appropriate localized version of the CNCF code of
conduct, and link directly to that -->

21
content/en/docs/concepts/configuration/organize-cluster-access-kubeconfig.md
View File

@ -148,7 +148,28 @@ File references on the command line are relative to the current working director
In `$HOME/.kube/config`, relative paths are stored relatively, and absolute paths
are stored absolutely.
## Proxy
You can configure `kubectl` to use proxy by setting `proxy-url` in the kubeconfig file, like:
```yaml
apiVersion: v1
kind: Config
proxy-url: https://proxy.host:3128
clusters:
- cluster:
name: development
users:
- name: developer
contexts:
- context:
name: development
```
## {{% heading "whatsnext" %}}

109
content/en/docs/concepts/containers/images.md
View File

@ -29,8 +29,7 @@ and possibly a port number as well; for example: `fictional.registry.example:104
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
After the image name part you can add a _tag_ (as also using with commands such
as `docker` and `podman`).
After the image name part you can add a _tag_ (in the same way you would when using with commands like `docker` or `podman`).
Tags let you identify different versions of the same series of images.
Image tags consist of lowercase and uppercase letters, digits, underscores (`_`),
@ -91,7 +90,7 @@ the image's digest;
replace `<image-name>:<tag>` with `<image-name>@<digest>`
(for example, `image@sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`).
When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image fixes the code that you run so that a change at the registry cannot lead to that mix of versions.
When using image tags, if the image registry were to change the code that the tag on that image represents, you might end up with a mix of Pods running the old and new code. An image digest uniquely identifies a specific version of the image, so Kubernetes runs the same code every time it starts a container with that image name and digest specified. Specifying an image by digest fixes the code that you run so that a change at the registry cannot lead to that mix of versions.
There are third-party [admission controllers](/docs/reference/access-authn-authz/admission-controllers/)
that mutate Pods (and pod templates) when they are created, so that the
@ -175,95 +174,11 @@ These options are explained in more detail below.
### Configuring nodes to authenticate to a private registry
If you run Docker on your nodes, you can configure the Docker container
runtime to authenticate to a private container registry.
Specific instructions for setting credentials depends on the container runtime and registry you chose to use. You should refer to your solution's documentation for the most accurate information.
This approach is suitable if you can control node configuration.
{{< note >}}
Default Kubernetes only supports the `auths` and `HttpHeaders` section in Docker configuration.
Docker credential helpers (`credHelpers` or `credsStore`) are not supported.
{{< /note >}}
Docker stores keys for private registries in the `$HOME/.dockercfg` or `$HOME/.docker/config.json` file. If you put the same file
in the search paths list below, kubelet uses it as the credential provider when pulling images.
* `{--root-dir:-/var/lib/kubelet}/config.json`
* `{cwd of kubelet}/config.json`
* `${HOME}/.docker/config.json`
* `/.docker/config.json`
* `{--root-dir:-/var/lib/kubelet}/.dockercfg`
* `{cwd of kubelet}/.dockercfg`
* `${HOME}/.dockercfg`
* `/.dockercfg`
{{< note >}}
You may have to set `HOME=/root` explicitly in the environment of the kubelet process.
{{< /note >}}
Here are the recommended steps to configuring your nodes to use a private registry. In this
example, run these on your desktop/laptop:
1. Run `docker login [server]` for each set of credentials you want to use. This updates `$HOME/.docker/config.json` on your PC.
1. View `$HOME/.docker/config.json` in an editor to ensure it contains only the credentials you want to use.
1. Get a list of your nodes; for example:
- if you want the names: `nodes=$( kubectl get nodes -o jsonpath='{range.items[*].metadata}{.name} {end}' )`
- if you want to get the IP addresses: `nodes=$( kubectl get nodes -o jsonpath='{range .items[*].status.addresses[?(@.type=="ExternalIP")]}{.address} {end}' )`
1. Copy your local `.docker/config.json` to one of the search paths list above.
- for example, to test this out: `for n in $nodes; do scp ~/.docker/config.json root@"$n":/var/lib/kubelet/config.json; done`
{{< note >}}
For production clusters, use a configuration management tool so that you can apply this
setting to all the nodes where you need it.
{{< /note >}}
Verify by creating a Pod that uses a private image; for example:
```shell
kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: private-image-test-1
spec:
containers:
- name: uses-private-image
image: $PRIVATE_IMAGE_NAME
imagePullPolicy: Always
command: [ "echo", "SUCCESS" ]
EOF
```
```
pod/private-image-test-1 created
```
If everything is working, then, after a few moments, you can run:
```shell
kubectl logs private-image-test-1
```
and see that the command outputs:
```
SUCCESS
```
If you suspect that the command failed, you can run:
```shell
kubectl describe pods/private-image-test-1 | grep 'Failed'
```
In case of failure, the output is similar to:
```
Fri, 26 Jun 2015 15:36:13 -0700 Fri, 26 Jun 2015 15:39:13 -0700 19 {kubelet node-i2hq} spec.containers{uses-private-image} failed Failed to pull image "user/privaterepo:v1": Error: image user/privaterepo:v1 not found
```
You must ensure all nodes in the cluster have the same `.docker/config.json`. Otherwise, pods will run on
some nodes and fail to run on others. For example, if you use node autoscaling, then each instance
template needs to include the `.docker/config.json` or mount a drive that contains it.
All pods will have read access to images in any private registry once private
registry keys are added to the `.docker/config.json`.
For an example of configuring a private container image registry, see the
[Pull an Image from a Private Registry](/docs/tasks/configure-pod-container/pull-image-private-registry)
task. That example uses a private registry in Docker Hub.
### Interpretation of config.json {#config-json}
@ -332,6 +247,7 @@ If now a container specifies an image `my-registry.io/images/subpath/my-image`
to be pulled, then the kubelet will try to download them from both
authentication sources if one of them fails.
### Pre-pulled images
{{< note >}}
@ -362,6 +278,8 @@ Kubernetes supports specifying container image registry keys on a Pod.
#### Creating a Secret with a Docker config
You need to know the username, registry password and client email address for authenticating
to the registry, as well as its hostname.
Run the following command, substituting the appropriate uppercase values:
```shell
@ -426,14 +344,13 @@ There are a number of solutions for configuring private registries. Here are so
common use cases and suggested solutions.
1. Cluster running only non-proprietary (e.g. open-source) images. No need to hide images.
- Use public images on the Docker hub.
- Use public images from a public registry
- No configuration required.
- Some cloud providers automatically cache or mirror public images, which improves availability and reduces the time to pull images.
1. Cluster running some proprietary images which should be hidden to those outside the company, but
visible to all cluster users.
- Use a hosted private [Docker registry](https://docs.docker.com/registry/).
- It may be hosted on the [Docker Hub](https://hub.docker.com/signup), or elsewhere.
- Manually configure .docker/config.json on each node as described above.
- Use a hosted private registry
- Manual configuration may be required on the nodes that need to access to private registry
- Or, run an internal private registry behind your firewall with open read access.
- No Kubernetes configuration is required.
- Use a hosted container image registry service that controls image access
@ -450,8 +367,6 @@ common use cases and suggested solutions.
If you need access to multiple registries, you can create one secret for each registry.
Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.json`
## {{% heading "whatsnext" %}}

488
content/en/docs/concepts/scheduling-eviction/assign-pod-node.md
View File

@ -12,158 +12,181 @@ weight: 20
<!-- overview -->
You can constrain a {{< glossary_tooltip text="Pod" term_id="pod" >}} so that it can only run on particular set of
{{< glossary_tooltip text="Node(s)" term_id="node" >}}.
{{< glossary_tooltip text="node(s)" term_id="node" >}}.
There are several ways to do this and the recommended approaches all use
[label selectors](/docs/concepts/overview/working-with-objects/labels/) to facilitate the selection.
Generally such constraints are unnecessary, as the scheduler will automatically do a reasonable placement
(e.g. spread your pods across nodes so as not place the pod on a node with insufficient free resources, etc.)
but there are some circumstances where you may want to control which node the pod deploys to - for example to ensure
that a pod ends up on a machine with an SSD attached to it, or to co-locate pods from two different
(for example, spreading your Pods across nodes so as not place Pods on a node with insufficient free resources).
However, there are some circumstances where you may want to control which node
the Pod deploys to, for example, to ensure that a Pod ends up on a node with an SSD attached to it, or to co-locate Pods from two different
services that communicate a lot into the same availability zone.
<!-- body -->
You can use any of the following methods to choose where Kubernetes schedules
specific Pods:
* [nodeSelector](#nodeselector) field matching against [node labels](#built-in-node-labels)
* [Affinity and anti-affinity](#affinity-and-anti-affinity)
* [nodeName](#nodename) field
## Node labels {#built-in-node-labels}
Like many other Kubernetes objects, nodes have
[labels](/docs/concepts/overview/working-with-objects/labels/). You can [attach labels manually](/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node).
Kubernetes also populates a standard set of labels on all nodes in a cluster. See [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/)
for a list of common node labels.
{{<note>}}
The value of these labels is cloud provider specific and is not guaranteed to be reliable.
For example, the value of `kubernetes.io/hostname` may be the same as the node name in some environments
and a different value in other environments.
{{</note>}}
### Node isolation/restriction
Adding labels to nodes allows you to target Pods for scheduling on specific
nodes or groups of nodes. You can use this functionality to ensure that specific
Pods only run on nodes with certain isolation, security, or regulatory
properties.
If you use labels for node isolation, choose label keys that the {{<glossary_tooltip text="kubelet" term_id="kubelet">}}
cannot modify. This prevents a compromised node from setting those labels on
itself so that the scheduler schedules workloads onto the compromised node.
The [`NodeRestriction` admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)
prevents the kubelet from setting or modifying labels with a
`node-restriction.kubernetes.io/` prefix.
To make use of that label prefix for node isolation:
1. Ensure you are using the [Node authorizer](/docs/reference/access-authn-authz/node/) and have _enabled_ the `NodeRestriction` admission plugin.
2. Add labels with the `node-restriction.kubernetes.io/` prefix to your nodes, and use those labels in your [node selectors](#nodeselector).
For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
## nodeSelector
`nodeSelector` is the simplest recommended form of node selection constraint.
`nodeSelector` is a field of PodSpec. It specifies a map of key-value pairs. For the pod to be eligible
to run on a node, the node must have each of the indicated key-value pairs as labels (it can have
additional labels as well). The most common usage is one key-value pair.
You can add the `nodeSelector` field to your Pod specification and specify the
[node labels](#built-in-node-labels) you want the target node to have.
Kubernetes only schedules the Pod onto nodes that have each of the labels you
specify.
Let's walk through an example of how to use `nodeSelector`.
### Step Zero: Prerequisites
This example assumes that you have a basic understanding of Kubernetes pods and that you have [set up a Kubernetes cluster](/docs/setup/).
### Step One: Attach label to the node
Run `kubectl get nodes` to get the names of your cluster's nodes. Pick out the one that you want to add a label to, and then run `kubectl label nodes <node-name> <label-key>=<label-value>` to add a label to the node you've chosen. For example, if my node name is 'kubernetes-foo-node-1.c.a-robinson.internal' and my desired label is 'disktype=ssd', then I can run `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd`.
You can verify that it worked by re-running `kubectl get nodes --show-labels` and checking that the node now has a label. You can also use `kubectl describe node "nodename"` to see the full list of labels of the given node.
### Step Two: Add a nodeSelector field to your pod configuration
Take whatever pod config file you want to run, and add a nodeSelector section to it, like this. For example, if this is my pod config:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
```
Then add a nodeSelector like so:
{{< codenew file="pods/pod-nginx.yaml" >}}
When you then run `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml`,
the Pod will get scheduled on the node that you attached the label to. You can
verify that it worked by running `kubectl get pods -o wide` and looking at the
"NODE" that the Pod was assigned to.
## Interlude: built-in node labels {#built-in-node-labels}
In addition to labels you [attach](#step-one-attach-label-to-the-node), nodes come pre-populated
with a standard set of labels. See [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/) for a list of these.
{{< note >}}
The value of these labels is cloud provider specific and is not guaranteed to be reliable.
For example, the value of `kubernetes.io/hostname` may be the same as the Node name in some environments
and a different value in other environments.
{{< /note >}}
## Node isolation/restriction
Adding labels to Node objects allows targeting pods to specific nodes or groups of nodes.
This can be used to ensure specific pods only run on nodes with certain isolation, security, or regulatory properties.
When using labels for this purpose, choosing label keys that cannot be modified by the kubelet process on the node is strongly recommended.
This prevents a compromised node from using its kubelet credential to set those labels on its own Node object,
and influencing the scheduler to schedule workloads to the compromised node.
The `NodeRestriction` admission plugin prevents kubelets from setting or modifying labels with a `node-restriction.kubernetes.io/` prefix.
To make use of that label prefix for node isolation:
1. Ensure you are using the [Node authorizer](/docs/reference/access-authn-authz/node/) and have _enabled_ the [NodeRestriction admission plugin](/docs/reference/access-authn-authz/admission-controllers/#noderestriction).
2. Add labels under the `node-restriction.kubernetes.io/` prefix to your Node objects, and use those labels in your node selectors.
For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`.
See [Assign Pods to Nodes](/docs/tasks/configure-pod-container/assign-pods-nodes) for more
information.
## Affinity and anti-affinity
`nodeSelector` provides a very simple way to constrain pods to nodes with particular labels. The affinity/anti-affinity
feature, greatly expands the types of constraints you can express. The key enhancements are
`nodeSelector` is the simplest way to constrain Pods to nodes with specific
labels. Affinity and anti-affinity expands the types of constraints you can
define. Some of the benefits of affinity and anti-affinity include:
1. The affinity/anti-affinity language is more expressive. The language offers more matching rules
besides exact matches created with a logical AND operation;
2. you can indicate that the rule is "soft"/"preference" rather than a hard requirement, so if the scheduler
can't satisfy it, the pod will still be scheduled;
3. you can constrain against labels on other pods running on the node (or other topological domain),
rather than against labels on the node itself, which allows rules about which pods can and cannot be co-located
* The affinity/anti-affinity language is more expressive. `nodeSelector` only
selects nodes with all the specified labels. Affinity/anti-affinity gives you
more control over the selection logic.
* You can indicate that a rule is *soft* or *preferred*, so that the scheduler
still schedules the Pod even if it can't find a matching node.
* You can constrain a Pod using labels on other Pods running on the node (or other topological domain),
instead of just node labels, which allows you to define rules for which Pods
can be co-located on a node.
The affinity feature consists of two types of affinity, "node affinity" and "inter-pod affinity/anti-affinity".
Node affinity is like the existing `nodeSelector` (but with the first two benefits listed above),
while inter-pod affinity/anti-affinity constrains against pod labels rather than node labels, as
described in the third item listed above, in addition to having the first and second properties listed above.
The affinity feature consists of two types of affinity:
* *Node affinity* functions like the `nodeSelector` field but is more expressive and
allows you to specify soft rules.
* *Inter-pod affinity/anti-affinity* allows you to constrain Pods against labels
on other Pods.
### Node affinity
Node affinity is conceptually similar to `nodeSelector` -- it allows you to constrain which nodes your
pod is eligible to be scheduled on, based on labels on the node.
Node affinity is conceptually similar to `nodeSelector`, allowing you to constrain which nodes your
Pod can be scheduled on based on node labels. There are two types of node
affinity:
There are currently two types of node affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
`preferredDuringSchedulingIgnoredDuringExecution`. You can think of them as "hard" and "soft" respectively,
in the sense that the former specifies rules that *must* be met for a pod to be scheduled onto a node (similar to
`nodeSelector` but using a more expressive syntax), while the latter specifies *preferences* that the scheduler
will try to enforce but will not guarantee. The "IgnoredDuringExecution" part of the names means that, similar
to how `nodeSelector` works, if labels on a node change at runtime such that the affinity rules on a pod are no longer
met, the pod continues to run on the node. In the future we plan to offer
`requiredDuringSchedulingRequiredDuringExecution` which will be identical to `requiredDuringSchedulingIgnoredDuringExecution`
except that it will evict pods from nodes that cease to satisfy the pods' node affinity requirements.
* `requiredDuringSchedulingIgnoredDuringExecution`: The scheduler can't
schedule the Pod unless the rule is met. This functions like `nodeSelector`,
but with a more expressive syntax.
* `preferredDuringSchedulingIgnoredDuringExecution`: The scheduler tries to
find a node that meets the rule. If a matching node is not available, the
scheduler still schedules the Pod.
Thus an example of `requiredDuringSchedulingIgnoredDuringExecution` would be "only run the pod on nodes with Intel CPUs"
and an example `preferredDuringSchedulingIgnoredDuringExecution` would be "try to run this set of pods in failure
zone XYZ, but if it's not possible, then allow some to run elsewhere".
{{<note>}}
In the preceding types, `IgnoredDuringExecution` means that if the node labels
change after Kubernetes schedules the Pod, the Pod continues to run.
{{</note>}}
Node affinity is specified as field `nodeAffinity` of field `affinity` in the PodSpec.
You can specify node affinities using the `.spec.affinity.nodeAffinity` field in
your Pod spec.
Here's an example of a pod that uses node affinity:
For example, consider the following Pod spec:
{{< codenew file="pods/pod-with-node-affinity.yaml" >}}
{{<codenew file="pods/pod-with-node-affinity.yaml">}}
This node affinity rule says the pod can only be placed on a node with a label whose key is
`kubernetes.io/e2e-az-name` and whose value is either `e2e-az1` or `e2e-az2`. In addition,
among nodes that meet that criteria, nodes with a label whose key is `another-node-label-key` and whose
value is `another-node-label-value` should be preferred.
In this example, the following rules apply:
You can see the operator `In` being used in the example. The new node affinity syntax supports the following operators: `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`.
You can use `NotIn` and `DoesNotExist` to achieve node anti-affinity behavior, or use
[node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) to repel pods from specific nodes.
* The node *must* have a label with the key `kubernetes.io/e2e-az-name` and
the value is either `e2e-az1` or `e2e-az2`.
* The node *preferably* has a label with the key `another-node-label-key` and
the value `another-node-label-value`.
If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied for the pod
to be scheduled onto a candidate node.
You can use the `operator` field to specify a logical operator for Kubernetes to use when
interpreting the rules. You can use `In`, `NotIn`, `Exists`, `DoesNotExist`,
`Gt` and `Lt`.
If you specify multiple `nodeSelectorTerms` associated with `nodeAffinity` types, then the pod can be scheduled onto a node **if one of the** `nodeSelectorTerms` can be satisfied.
`NotIn` and `DoesNotExist` allow you to define node anti-affinity behavior.
Alternatively, you can use [node taints](/docs/concepts/scheduling-eviction/taint-and-toleration/)
to repel Pods from specific nodes.
If you specify multiple `matchExpressions` associated with `nodeSelectorTerms`, then the pod can be scheduled onto a node **only if all** `matchExpressions` is satisfied.
{{<note>}}
If you specify both `nodeSelector` and `nodeAffinity`, *both* must be satisfied
for the Pod to be scheduled onto a node.
If you remove or change the label of the node where the pod is scheduled, the pod won't be removed. In other words, the affinity selection works only at the time of scheduling the pod.
If you specify multiple `nodeSelectorTerms` associated with `nodeAffinity`
types, then the Pod can be scheduled onto a node if one of the specified `nodeSelectorTerms` can be
satisfied.
The `weight` field in `preferredDuringSchedulingIgnoredDuringExecution` is in the range 1-100. For each node that meets all of the scheduling requirements (resource request, RequiredDuringScheduling affinity expressions, etc.), the scheduler will compute a sum by iterating through the elements of this field and adding "weight" to the sum if the node matches the corresponding MatchExpressions. This score is then combined with the scores of other priority functions for the node. The node(s) with the highest total score are the most preferred.
If you specify multiple `matchExpressions` associated with a single `nodeSelectorTerms`,
then the Pod can be scheduled onto a node only if all the `matchExpressions` are
satisfied.
{{</note>}}
See [Assign Pods to Nodes using Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)
for more information.
#### Node affinity weight
You can specify a `weight` between 1 and 100 for each instance of the
`preferredDuringSchedulingIgnoredDuringExecution` affinity type. When the
scheduler finds nodes that meet all the other scheduling requirements of the Pod, the
scheduler iterates through every preferred rule that the node satisfies and adds the
value of the `weight` for that expression to a sum.
The final sum is added to the score of other priority functions for the node.
Nodes with the highest total score are prioritized when the scheduler makes a
scheduling decision for the Pod.
For example, consider the following Pod spec:
{{<codenew file="pods/pod-with-affinity-anti-affinity.yaml">}}
If there are two possible nodes that match the
`requiredDuringSchedulingIgnoredDuringExecution` rule, one with the
`label-1:key-1` label and another with the `label-2:key-2` label, the scheduler
considers the `weight` of each node and adds the weight to the other scores for
that node, and schedules the Pod onto the node with the highest final score.
{{<note>}}
If you want Kubernetes to successfully schedule the Pods in this example, you
must have existing nodes with the `kubernetes.io/os=linux` label.
{{</note>}}
#### Node affinity per scheduling profile
{{< feature-state for_k8s_version="v1.20" state="beta" >}}
When configuring multiple [scheduling profiles](/docs/reference/scheduling/config/#multiple-profiles), you can associate
a profile with a Node affinity, which is useful if a profile only applies to a specific set of Nodes.
To do so, add an `addedAffinity` to the args of the [`NodeAffinity` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
a profile with a node affinity, which is useful if a profile only applies to a specific set of nodes.
To do so, add an `addedAffinity` to the `args` field of the [`NodeAffinity` plugin](/docs/reference/scheduling/config/#scheduling-plugins)
in the [scheduler configuration](/docs/reference/scheduling/config/). For example:
```yaml
@ -188,29 +211,41 @@ profiles:
The `addedAffinity` is applied to all Pods that set `.spec.schedulerName` to `foo-scheduler`, in addition to the
NodeAffinity specified in the PodSpec.
That is, in order to match the Pod, Nodes need to satisfy `addedAffinity` and the Pod's `.spec.NodeAffinity`.
That is, in order to match the Pod, nodes need to satisfy `addedAffinity` and
the Pod's `.spec.NodeAffinity`.
Since the `addedAffinity` is not visible to end users, its behavior might be unexpected to them. We
recommend to use node labels that have clear correlation with the profile's scheduler name.
Since the `addedAffinity` is not visible to end users, its behavior might be
unexpected to them. Use node labels that have a clear correlation to the
scheduler profile name.
{{< note >}}
The DaemonSet controller, which [creates Pods for DaemonSets](/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)
is not aware of scheduling profiles. For this reason, it is recommended that you keep a scheduler profile, such as the
`default-scheduler`, without any `addedAffinity`. Then, the Daemonset's Pod template should use this scheduler name.
Otherwise, some Pods created by the Daemonset controller might remain unschedulable.
The DaemonSet controller, which [creates Pods for DaemonSets](/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler),
does not support scheduling profiles. When the DaemonSet controller creates
Pods, the default Kubernetes scheduler places those Pods and honors any
`nodeAffinity` rules in the DaemonSet controller.
{{< /note >}}
### Inter-pod affinity and anti-affinity
Inter-pod affinity and anti-affinity allow you to constrain which nodes your pod is eligible to be scheduled *based on
labels on pods that are already running on the node* rather than based on labels on nodes. The rules are of the form
"this pod should (or, in the case of anti-affinity, should not) run in an X if that X is already running one or more pods that meet rule Y".
Y is expressed as a LabelSelector with an optional associated list of namespaces; unlike nodes, because pods are namespaced
(and therefore the labels on pods are implicitly namespaced),
a label selector over pod labels must specify which namespaces the selector should apply to. Conceptually X is a topology domain
like node, rack, cloud provider zone, cloud provider region, etc. You express it using a `topologyKey` which is the
key for the node label that the system uses to denote such a topology domain; for example, see the label keys listed above
in the section [Interlude: built-in node labels](#built-in-node-labels).
Inter-pod affinity and anti-affinity allow you to constrain which nodes your
Pods can be scheduled on based on the labels of **Pods** already running on that
node, instead of the node labels.
Inter-pod affinity and anti-affinity rules take the form "this
Pod should (or, in the case of anti-affinity, should not) run in an X if that X
is already running one or more Pods that meet rule Y", where X is a topology
domain like node, rack, cloud provider zone or region, or similar and Y is the
rule Kubernetes tries to satisfy.
You express these rules (Y) as [label selectors](/docs/concepts/overview/working-with-objects/labels/#label-selectors)
with an optional associated list of namespaces. Pods are namespaced objects in
Kubernetes, so Pod labels also implicitly have namespaces. Any label selectors
for Pod labels should specify the namespaces in which Kubernetes should look for those
labels.
You express the topology domain (X) using a `topologyKey`, which is the key for
the node label that the system uses to denote the domain. For examples, see
[Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/).
{{< note >}}
Inter-pod affinity and anti-affinity require substantial amount of
@ -219,76 +254,100 @@ not recommend using them in clusters larger than several hundred nodes.
{{< /note >}}
{{< note >}}
Pod anti-affinity requires nodes to be consistently labelled, in other words every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior.
Pod anti-affinity requires nodes to be consistently labelled, in other words,
every node in the cluster must have an appropriate label matching `topologyKey`.
If some or all nodes are missing the specified `topologyKey` label, it can lead
to unintended behavior.
{{< /note >}}
As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
`preferredDuringSchedulingIgnoredDuringExecution` which denote "hard" vs. "soft" requirements.
See the description in the node affinity section earlier.
An example of `requiredDuringSchedulingIgnoredDuringExecution` affinity would be "co-locate the pods of service A and service B
in the same zone, since they communicate a lot with each other"
and an example `preferredDuringSchedulingIgnoredDuringExecution` anti-affinity would be "spread the pods from this service across zones"
(a hard requirement wouldn't make sense, since you probably have more pods than zones).
#### Types of inter-pod affinity and anti-affinity
Inter-pod affinity is specified as field `podAffinity` of field `affinity` in the PodSpec.
And inter-pod anti-affinity is specified as field `podAntiAffinity` of field `affinity` in the PodSpec.
Similar to [node affinity](#node-affinity) are two types of Pod affinity and
anti-affinity as follows:
#### An example of a pod that uses pod affinity:
* `requiredDuringSchedulingIgnoredDuringExecution`
* `preferredDuringSchedulingIgnoredDuringExecution`
For example, you could use
`requiredDuringSchedulingIgnoredDuringExecution` affinity to tell the scheduler to
co-locate Pods of two services in the same cloud provider zone because they
communicate with each other a lot. Similarly, you could use
`preferredDuringSchedulingIgnoredDuringExecution` anti-affinity to spread Pods
from a service across multiple cloud provider zones.
To use inter-pod affinity, use the `affinity.podAffinity` field in the Pod spec.
For inter-pod anti-affinity, use the `affinity.podAntiAffinity` field in the Pod
spec.
#### Pod affinity example {#an-example-of-a-pod-that-uses-pod-affinity}
Consider the following Pod spec:
{{< codenew file="pods/pod-with-pod-affinity.yaml" >}}
The affinity on this pod defines one pod affinity rule and one pod anti-affinity rule. In this example, the
`podAffinity` is `requiredDuringSchedulingIgnoredDuringExecution`
while the `podAntiAffinity` is `preferredDuringSchedulingIgnoredDuringExecution`. The
pod affinity rule says that the pod can be scheduled onto a node only if that node is in the same zone
as at least one already-running pod that has a label with key "security" and value "S1". (More precisely, the pod is eligible to run
on node N if node N has a label with key `topology.kubernetes.io/zone` and some value V
such that there is at least one node in the cluster with key `topology.kubernetes.io/zone` and
value V that is running a pod that has a label with key "security" and value "S1".) The pod anti-affinity
rule says that the pod should not be scheduled onto a node if that node is in the same zone as a pod with
label having key "security" and value "S2". See the
This example defines one Pod affinity rule and one Pod anti-affinity rule. The
Pod affinity rule uses the "hard"
`requiredDuringSchedulingIgnoredDuringExecution`, while the anti-affinity rule
uses the "soft" `preferredDuringSchedulingIgnoredDuringExecution`.
The affinity rule says that the scheduler can only schedule a Pod onto a node if
the node is in the same zone as one or more existing Pods with the label
`security=S1`. More precisely, the scheduler must place the Pod on a node that has the
`topology.kubernetes.io/zone=V` label, as long as there is at least one node in
that zone that currently has one or more Pods with the Pod label `security=S1`.
The anti-affinity rule says that the scheduler should try to avoid scheduling
the Pod onto a node that is in the same zone as one or more Pods with the label
`security=S2`. More precisely, the scheduler should try to avoid placing the Pod on a node that has the
`topology.kubernetes.io/zone=R` label if there are other nodes in the
same zone currently running Pods with the `Security=S2` Pod label.
See the
[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)
for many more examples of pod affinity and anti-affinity, both the `requiredDuringSchedulingIgnoredDuringExecution`
flavor and the `preferredDuringSchedulingIgnoredDuringExecution` flavor.
for many more examples of Pod affinity and anti-affinity.
The legal operators for pod affinity and anti-affinity are `In`, `NotIn`, `Exists`, `DoesNotExist`.
You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the
`operator` field for Pod affinity and anti-affinity.
In principle, the `topologyKey` can be any legal label-key. However,
for performance and security reasons, there are some constraints on topologyKey:
In principle, the `topologyKey` can be any allowed label key with the following
exceptions for performance and security reasons:
1. For pod affinity, empty `topologyKey` is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
and `preferredDuringSchedulingIgnoredDuringExecution`.
2. For pod anti-affinity, empty `topologyKey` is also not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
and `preferredDuringSchedulingIgnoredDuringExecution`.
3. For `requiredDuringSchedulingIgnoredDuringExecution` pod anti-affinity, the admission controller `LimitPodHardAntiAffinityTopology` was introduced to limit `topologyKey` to `kubernetes.io/hostname`. If you want to make it available for custom topologies, you may modify the admission controller, or disable it.
4. Except for the above cases, the `topologyKey` can be any legal label-key.
* For Pod affinity and anti-affinity, an empty `topologyKey` field is not allowed in both `requiredDuringSchedulingIgnoredDuringExecution`
and `preferredDuringSchedulingIgnoredDuringExecution`.
* For `requiredDuringSchedulingIgnoredDuringExecution` Pod anti-affinity rules,
the admission controller `LimitPodHardAntiAffinityTopology` limits
`topologyKey` to `kubernetes.io/hostname`. You can modify or disable the
admission controller if you want to allow custom topologies.
In addition to `labelSelector` and `topologyKey`, you can optionally specify a list `namespaces`
of namespaces which the `labelSelector` should match against (this goes at the same level of the definition as `labelSelector` and `topologyKey`).
If omitted or empty, it defaults to the namespace of the pod where the affinity/anti-affinity definition appears.
All `matchExpressions` associated with `requiredDuringSchedulingIgnoredDuringExecution` affinity and anti-affinity
must be satisfied for the pod to be scheduled onto a node.
In addition to `labelSelector` and `topologyKey`, you can optionally specify a list
of namespaces which the `labelSelector` should match against using the
`namespaces` field at the same level as `labelSelector` and `topologyKey`.
If omitted or empty, `namespaces` defaults to the namespace of the Pod where the
affinity/anti-affinity definition appears.
#### Namespace selector
{{< feature-state for_k8s_version="v1.24" state="stable" >}}
Users can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
The affinity term is applied to the union of the namespaces selected by `namespaceSelector` and the ones listed in the `namespaces` field.
You can also select matching namespaces using `namespaceSelector`, which is a label query over the set of namespaces.
The affinity term is applied to namespaces selected by both `namespaceSelector` and the `namespaces` field.
Note that an empty `namespaceSelector` ({}) matches all namespaces, while a null or empty `namespaces` list and
null `namespaceSelector` means "this pod's namespace".
null `namespaceSelector` matches the namespace of the Pod where the rule is defined.
#### More Practical Use-cases
#### More practical use-cases
Interpod Affinity and AntiAffinity can be even more useful when they are used with higher
level collections such as ReplicaSets, StatefulSets, Deployments, etc. One can easily configure that a set of workloads should
Inter-pod affinity and anti-affinity can be even more useful when they are used with higher
level collections such as ReplicaSets, StatefulSets, Deployments, etc. These
rules allow you to configure that a set of workloads should
be co-located in the same defined topology, eg., the same node.
##### Always co-located in the same node
Take, for example, a three-node cluster running a web application with an
in-memory cache like redis. You could use inter-pod affinity and anti-affinity
to co-locate the web servers with the cache as much as possible.
In a three node cluster, a web application has in-memory cache such as redis. We want the web-servers to be co-located with the cache as much as possible.
Here is the yaml snippet of a simple redis deployment with three replicas and selector label `app=store`. The deployment has `PodAntiAffinity` configured to ensure the scheduler does not co-locate replicas on a single node.
In the following example Deployment for the redis cache, the replicas get the label `app=store`. The
`podAntiAffinity` rule tells the scheduler to avoid placing multiple replicas
with the `app=store` label on a single node. This creates each cache in a
separate node.
```yaml
apiVersion: apps/v1
@ -320,7 +379,10 @@ spec:
image: redis:3.2-alpine
```
The below yaml snippet of the webserver deployment has `podAntiAffinity` and `podAffinity` configured. This informs the scheduler that all its replicas are to be co-located with pods that have selector label `app=store`. This will also ensure that each web-server replica does not co-locate on a single node.
The following Deployment for the web servers creates replicas with the label `app=web-store`. The
Pod affinity rule tells the scheduler to place each replica on a node that has a
Pod with the label `app=store`. The Pod anti-affinity rule tells the scheduler
to avoid placing multiple `app=web-store` servers on a single node.
```yaml
apiVersion: apps/v1
@ -361,56 +423,37 @@ spec:
image: nginx:1.16-alpine
```
If we create the above two deployments, our three node cluster should look like below.
Creating the two preceding Deployments results in the following cluster layout,
where each web server is co-located with a cache, on three separate nodes.
| node-1 | node-2 | node-3 |
|:--------------------:|:-------------------:|:------------------:|
| *webserver-1* | *webserver-2* | *webserver-3* |
| *cache-1* | *cache-2* | *cache-3* |
As you can see, all the 3 replicas of the `web-server` are automatically co-located with the cache as expected.
```
kubectl get pods -o wide
```
The output is similar to this:
```
NAME READY STATUS RESTARTS AGE IP NODE
redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3
redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1
redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2
web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1
web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3
web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2
```
##### Never co-located in the same node
The above example uses `PodAntiAffinity` rule with `topologyKey: "kubernetes.io/hostname"` to deploy the redis cluster so that
no two instances are located on the same host.
See [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
for an example of a StatefulSet configured with anti-affinity for high availability, using the same technique.
See the [ZooKeeper tutorial](/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure)
for an example of a StatefulSet configured with anti-affinity for high
availability, using the same technique as this example.
## nodeName
`nodeName` is the simplest form of node selection constraint, but due
to its limitations it is typically not used. `nodeName` is a field of
PodSpec. If it is non-empty, the scheduler ignores the pod and the
kubelet running on the named node tries to run the pod. Thus, if
`nodeName` is provided in the PodSpec, it takes precedence over the
above methods for node selection.
`nodeName` is a more direct form of node selection than affinity or
`nodeSelector`. `nodeName` is a field in the Pod spec. If the `nodeName` field
is not empty, the scheduler ignores the Pod and the kubelet on the named node
tries to place the Pod on that node. Using `nodeName` overrules using
`nodeSelector` or affinity and anti-affinity rules.
Some of the limitations of using `nodeName` to select nodes are:
- If the named node does not exist, the pod will not be run, and in
- If the named node does not exist, the Pod will not run, and in
some cases may be automatically deleted.
- If the named node does not have the resources to accommodate the
pod, the pod will fail and its reason will indicate why,
Pod, the Pod will fail and its reason will indicate why,
for example OutOfmemory or OutOfcpu.
- Node names in cloud environments are not always predictable or
stable.
Here is an example of a pod config file using the `nodeName` field:
Here is an example of a Pod spec using the `nodeName` field:
```yaml
apiVersion: v1
@ -424,21 +467,16 @@ spec:
nodeName: kube-01
```
The above pod will run on the node kube-01.
The above Pod will only run on the node `kube-01`.
## {{% heading "whatsnext" %}}
[Taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) allow a Node to *repel* a set of Pods.
The design documents for
[node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) contain extra background information about these features.
Once a Pod is assigned to a Node, the kubelet runs the Pod and allocates node-local resources.
The [topology manager](/docs/tasks/administer-cluster/topology-manager/) can take part in node-level
resource allocation decisions.
* Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) .
* Read the design docs for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)
and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md).
* Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level
resource allocation decisions.
* Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/).
* Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/).

2
content/en/docs/concepts/scheduling-eviction/pod-overhead.md
View File

@ -72,7 +72,7 @@ spec:
runtimeClassName: kata-fc
containers:
- name: busybox-ctr
image: busybox
image: busybox:1.28
stdin: true
tty: true
resources:

2
content/en/docs/concepts/services-networking/ingress-controllers.md
View File

@ -23,7 +23,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
{{% thirdparty-content %}}
* [AKS Application Gateway Ingress Controller](https://azure.github.io/application-gateway-kubernetes-ingress/) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [AKS Application Gateway Ingress Controller](https://docs.microsoft.com/azure/application-gateway/tutorial-ingress-controller-add-on-existing?toc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Faks%2Ftoc.json&bc=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fazure%2Fbread%2Ftoc.json) is an ingress controller that configures the [Azure Application Gateway](https://docs.microsoft.com/azure/application-gateway/overview).
* [Ambassador](https://www.getambassador.io/) API Gateway is an [Envoy](https://www.envoyproxy.io)-based ingress
controller.
* [Apache APISIX ingress controller](https://github.com/apache/apisix-ingress-controller) is an [Apache APISIX](https://github.com/apache/apisix)-based ingress controller.

45
content/en/docs/concepts/services-networking/service.md
View File

@ -109,12 +109,45 @@ field.
{{< /note >}}
Port definitions in Pods have names, and you can reference these names in the
`targetPort` attribute of a Service. This works even if there is a mixture
of Pods in the Service using a single configured name, with the same network
protocol available via different port numbers.
This offers a lot of flexibility for deploying and evolving your Services.
For example, you can change the port numbers that Pods expose in the next
version of your backend software, without breaking clients.
`targetPort` attribute of a Service. For example, we can bind the `targetPort`
of the Service to the Pod port in the following way:
```yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: nginx:11.14.2
ports:
- containerPort: 80
name: http-web-svc
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
```
This works even if there is a mixture of Pods in the Service using a single
configured name, with the same network protocol available via different
port numbers. This offers a lot of flexibility for deploying and evolving
your Services. For example, you can change the port numbers that Pods expose
in the next version of your backend software, without breaking clients.
The default protocol for Services is TCP; you can also use any other
[supported protocol](#protocol-support).

6
content/en/docs/concepts/services-networking/topology-aware-hints.md
View File

@ -19,6 +19,12 @@ those network endpoints can be routed closer to where it originated.
For example, you can route traffic within a locality to reduce
costs, or to improve network performance.
{{< note >}}
The "topology-aware hints" feature is at Beta stage and it is **NOT** enabled
by default. To try out this feature, you have to enable the `TopologyAwareHints`
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/).
{{< /note >}}
<!-- body -->
## Motivation

12
content/en/docs/concepts/storage/ephemeral-volumes.md
View File

@ -107,7 +107,7 @@ metadata:
spec:
containers:
- name: my-frontend
image: busybox
image: busybox:1.28
volumeMounts:
- mountPath: "/data"
name: my-csi-inline-vol
@ -125,9 +125,17 @@ driver. These attributes are specific to each driver and not
standardized. See the documentation of each CSI driver for further
instructions.
### CSI driver restrictions
{{< feature-state for_k8s_version="v1.21" state="deprecated" >}}
As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) to control which CSI drivers can be used in a Pod, specified with the
[`allowedCSIDrivers` field](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy).
{{< note >}}
PodSecurityPolicy is deprecated and will be removed in the Kubernetes v1.25 release.
{{< /note >}}
### Generic ephemeral volumes
{{< feature-state for_k8s_version="v1.23" state="stable" >}}
@ -158,7 +166,7 @@ metadata:
spec:
containers:
- name: my-frontend
image: busybox
image: busybox:1.28
volumeMounts:
- mountPath: "/scratch"
name: scratch-volume

9
content/en/docs/concepts/storage/projected-volumes.md
View File

@ -23,7 +23,7 @@ Currently, the following types of volume sources can be projected:
* [`secret`](/docs/concepts/storage/volumes/#secret)
* [`downwardAPI`](/docs/concepts/storage/volumes/#downwardapi)
* [`configMap`](/docs/concepts/storage/volumes/#configmap)
* `serviceAccountToken`
* [`serviceAccountToken`](#serviceaccounttoken)
All sources are required to be in the same namespace as the Pod. For more details,
see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md) design document.
@ -45,6 +45,7 @@ parameters are nearly the same with two exceptions:
volume source. However, as illustrated above, you can explicitly set the `mode`
for each individual projection.
## serviceAccountToken projected volumes {#serviceaccounttoken}
When the `TokenRequestProjection` feature is enabled, you can inject the token
for the current [service account](/docs/reference/access-authn-authz/authentication/#service-account-tokens)
into a Pod at a specified path. For example:
@ -52,8 +53,10 @@ into a Pod at a specified path. For example:
{{< codenew file="pods/storage/projected-service-account-token.yaml" >}}
The example Pod has a projected volume containing the injected service account
token. This token can be used by a Pod's containers to access the Kubernetes API
server. The `audience` field contains the intended audience of the
token. Containers in this Pod can use that token to access the Kubernetes API
server, authenticating with the identity of [the pod's ServiceAccount]
(/docs/tasks/configure-pod-container/configure-service-account/).
The `audience` field contains the intended audience of the
token. A recipient of the token must identify itself with an identifier specified
in the audience of the token, and otherwise should reject the token. This field
is optional and it defaults to the identifier of the API server.

6
content/en/docs/concepts/storage/storage-classes.md
View File

@ -87,7 +87,7 @@ for provisioning PVs. This field must be specified.
You are not restricted to specifying the "internal" provisioners
listed here (whose names are prefixed with "kubernetes.io" and shipped
alongside Kubernetes). You can also run and specify external provisioners,
which are independent programs that follow a [specification](https://git.k8s.io/community/contributors/design-proposals/storage/volume-provisioning.md)
which are independent programs that follow a [specification](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md)
defined by Kubernetes. Authors of external provisioners have full discretion
over where their code lives, how the provisioner is shipped, how it needs to be
run, what volume plugin it uses (including Flex), etc. The repository
@ -241,8 +241,8 @@ allowedTopologies:
- matchLabelExpressions:
- key: failure-domain.beta.kubernetes.io/zone
values:
- us-central1-a
- us-central1-b
- us-central-1a
- us-central-1b
```
## Parameters

4
content/en/docs/concepts/storage/volumes.md
View File

@ -251,7 +251,7 @@ metadata:
spec:
containers:
- name: test
image: busybox
image: busybox:1.28
volumeMounts:
- name: config-vol
mountPath: /etc/config
@ -1128,7 +1128,7 @@ spec:
fieldRef:
apiVersion: v1
fieldPath: metadata.name
image: busybox
image: busybox:1.28
command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
volumeMounts:
- name: workdir1

2
content/en/docs/concepts/workloads/controllers/cron-jobs.md
View File

@ -69,7 +69,7 @@ takes you through this example in more detail).
# │ │ │ ┌───────────── month (1 - 12)
# │ │ │ │ ┌───────────── day of the week (0 - 6) (Sunday to Saturday;
# │ │ │ │ │ 7 is also Sunday on some systems)
# │ │ │ │ │
# │ │ │ │ │ OR sun, mon, tue, wed, thu, fri, sat
# │ │ │ │ │
# * * * * *
```

2
content/en/docs/concepts/workloads/controllers/daemonset.md
View File

@ -107,7 +107,7 @@ If you do not specify either, then the DaemonSet controller will create Pods on
### Scheduled by default scheduler
{{< feature-state state="stable" for-kubernetes-version="1.17" >}}
{{< feature-state for_kubernetes_version="1.17" state="stable" >}}
A DaemonSet ensures that all eligible nodes run a copy of a Pod. Normally, the
node that a Pod runs on is selected by the Kubernetes scheduler. However,

2
content/en/docs/concepts/workloads/pods/_index.md
View File

@ -180,7 +180,7 @@ spec:
spec:
containers:
- name: hello
image: busybox
image: busybox:1.28
command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
restartPolicy: OnFailure
# The pod template ends here

3
content/en/docs/reference/command-line-tools-reference/feature-gates.md
View File

@ -63,7 +63,8 @@ different Kubernetes components.
| `AllowInsecureBackendProxy` | `true` | Beta | 1.17 | |
| `AnyVolumeDataSource` | `false` | Alpha | 1.18 | |
| `AppArmor` | `true` | Beta | 1.4 | |
| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | |
| `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | 1.21 |
| `ControllerManagerLeaderMigration` | `true` | Beta | 1.22 | |
| `CPUManager` | `false` | Alpha | 1.8 | 1.9 |
| `CPUManager` | `true` | Beta | 1.10 | |
| `CPUManagerPolicyAlphaOptions` | `false` | Alpha | 1.23 | |

216
content/en/docs/reference/config-api/kubeadm-config.v1beta3.md
View File

@ -156,15 +156,15 @@ configuration types to be used during a <code>kubeadm init</code> run.</p>
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">effect</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;NoSchedule&#34;</span><span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">kubeletExtraArgs</span>:<span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">v</span>:<span style="color:#bbb"> </span><span style="color:#099">4</span><span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">ignorePreflightErrors</span>:<span style="color:#bbb">
</span><span style="color:#bbb"></span>- IsPrivilegedUser<span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">imagePullPolicy</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;IfNotPresent&#34;</span><span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">ignorePreflightErrors</span>:<span style="color:#bbb">
</span><span style="color:#bbb"> </span>- IsPrivilegedUser<span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">imagePullPolicy</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;IfNotPresent&#34;</span><span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">localAPIEndpoint</span>:<span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">advertiseAddress</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;10.100.0.1&#34;</span><span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">bindPort</span>:<span style="color:#bbb"> </span><span style="color:#099">6443</span><span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">certificateKey</span>:<span style="color:#bbb"> </span><span style="color:#d14">&#34;e6a2eb8581237ab72a4f494f30285ec12a9694d750b9785706a83bfcbbbd2204&#34;</span><span style="color:#bbb">
</span><span style="color:#bbb"> </span><span style="color:#000;font-weight:bold">skipPhases</span>:<span style="color:#bbb">
</span><span style="color:#bbb"> </span>- addon/kube-proxy<span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">skipPhases</span>:<span style="color:#bbb">
</span><span style="color:#bbb"> </span>- addon/kube-proxy<span style="color:#bbb">
</span><span style="color:#bbb"></span>---<span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">apiVersion</span>:<span style="color:#bbb"> </span>kubeadm.k8s.io/v1beta3<span style="color:#bbb">
</span><span style="color:#bbb"></span><span style="color:#000;font-weight:bold">kind</span>:<span style="color:#bbb"> </span>ClusterConfiguration<span style="color:#bbb">
@ -264,6 +264,109 @@ node only (e.g. the node ip).</p>
## `BootstrapToken` {#BootstrapToken}
**Appears in:**
- [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration)
<p>BootstrapToken describes one bootstrap token, stored as a Secret in the cluster</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>token</code> <B>[Required]</B><br/>
<a href="#BootstrapTokenString"><code>BootstrapTokenString</code></a>
</td>
<td>
<p><code>token</code> is used for establishing bidirectional trust between nodes and control-planes.
Used for joining nodes in the cluster.</p>
</td>
</tr>
<tr><td><code>description</code><br/>
<code>string</code>
</td>
<td>
<p><code>description</code> sets a human-friendly message why this token exists and what it's used
for, so other administrators can know its purpose.</p>
</td>
</tr>
<tr><td><code>ttl</code><br/>
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
</td>
<td>
<p><code>ttl</code> defines the time to live for this token. Defaults to <code>24h</code>.
<code>expires</code> and <code>ttl</code> are mutually exclusive.</p>
</td>
</tr>
<tr><td><code>expires</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#time-v1-meta"><code>meta/v1.Time</code></a>
</td>
<td>
<p><code>expires</code> specifies the timestamp when this token expires. Defaults to being set
dynamically at runtime based on the <code>ttl</code>. <code>expires</code> and <code>ttl</code> are mutually exclusive.</p>
</td>
</tr>
<tr><td><code>usages</code><br/>
<code>[]string</code>
</td>
<td>
<p><code>usages</code> describes the ways in which this token can be used. Can by default be used
for establishing bidirectional trust, but that can be changed here.</p>
</td>
</tr>
<tr><td><code>groups</code><br/>
<code>[]string</code>
</td>
<td>
<p><code>groups</code> specifies the extra groups that this token will authenticate as when/if
used for authentication</p>
</td>
</tr>
</tbody>
</table>
## `BootstrapTokenString` {#BootstrapTokenString}
**Appears in:**
- [BootstrapToken](#BootstrapToken)
<p>BootstrapTokenString is a token of the format <code>abcdef.abcdef0123456789</code> that is used
for both validation of the practically of the API server from a joining node's point
of view and as an authentication method for the node in the bootstrap phase of
&quot;kubeadm join&quot;. This token is and should be short-lived.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>-</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<span class="text-muted">No description provided.</span></td>
</tr>
<tr><td><code>-</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<span class="text-muted">No description provided.</span></td>
</tr>
</tbody>
</table>
## `ClusterConfiguration` {#kubeadm-k8s-io-v1beta3-ClusterConfiguration}
@ -1237,106 +1340,3 @@ first alpha-numerically.</p>
</tbody>
</table>
## `BootstrapToken` {#BootstrapToken}
**Appears in:**
- [InitConfiguration](#kubeadm-k8s-io-v1beta3-InitConfiguration)
<p>BootstrapToken describes one bootstrap token, stored as a Secret in the cluster</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>token</code> <B>[Required]</B><br/>
<a href="#BootstrapTokenString"><code>BootstrapTokenString</code></a>
</td>
<td>
<p><code>token</code> is used for establishing bidirectional trust between nodes and control-planes.
Used for joining nodes in the cluster.</p>
</td>
</tr>
<tr><td><code>description</code><br/>
<code>string</code>
</td>
<td>
<p><code>description</code> sets a human-friendly message why this token exists and what it's used
for, so other administrators can know its purpose.</p>
</td>
</tr>
<tr><td><code>ttl</code><br/>
<a href="https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1#Duration"><code>meta/v1.Duration</code></a>
</td>
<td>
<p><code>ttl</code> defines the time to live for this token. Defaults to <code>24h</code>.
<code>expires</code> and <code>ttl</code> are mutually exclusive.</p>
</td>
</tr>
<tr><td><code>expires</code><br/>
<a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.23/#time-v1-meta"><code>meta/v1.Time</code></a>
</td>
<td>
<p><code>expires</code> specifies the timestamp when this token expires. Defaults to being set
dynamically at runtime based on the <code>ttl</code>. <code>expires</code> and <code>ttl</code> are mutually exclusive.</p>
</td>
</tr>
<tr><td><code>usages</code><br/>
<code>[]string</code>
</td>
<td>
<p><code>usages</code> describes the ways in which this token can be used. Can by default be used
for establishing bidirectional trust, but that can be changed here.</p>
</td>
</tr>
<tr><td><code>groups</code><br/>
<code>[]string</code>
</td>
<td>
<p><code>groups</code> specifies the extra groups that this token will authenticate as when/if
used for authentication</p>
</td>
</tr>
</tbody>
</table>
## `BootstrapTokenString` {#BootstrapTokenString}
**Appears in:**
- [BootstrapToken](#BootstrapToken)
<p>BootstrapTokenString is a token of the format <code>abcdef.abcdef0123456789</code> that is used
for both validation of the practically of the API server from a joining node's point
of view and as an authentication method for the node in the bootstrap phase of
&quot;kubeadm join&quot;. This token is and should be short-lived.</p>
<table class="table">
<thead><tr><th width="30%">Field</th><th>Description</th></tr></thead>
<tbody>
<tr><td><code>-</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<span class="text-muted">No description provided.</span></td>
</tr>
<tr><td><code>-</code> <B>[Required]</B><br/>
<code>string</code>
</td>
<td>
<span class="text-muted">No description provided.</span></td>
</tr>
</tbody>
</table>

2
content/en/docs/reference/glossary/namespace.md
View File

@ -4,7 +4,7 @@ id: namespace
date: 2018-04-12
full_link: /docs/concepts/overview/working-with-objects/namespaces
short_description: >
An abstraction used by Kubernetes to support multiple virtual clusters on the same physical cluster.
An abstraction used by Kubernetes to support isolation of groups of resources within a single cluster.
aka:
tags:

15
content/en/docs/reference/kubectl/cheatsheet.md
View File

@ -39,6 +39,11 @@ complete -F __start_kubectl k
source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell
echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # add autocomplete permanently to your zsh shell
```
### A Note on --all-namespaces
Appending `--all-namespaces` happens frequently enough where you should be aware of the shorthand for `--all-namespaces`:
```kubectl -A```
## Kubectl context and configuration
@ -97,10 +102,10 @@ kubectl apply -f https://git.io/vPieo # create resource(s) from url
kubectl create deployment nginx --image=nginx # start a single instance of nginx
# create a Job which prints "Hello World"
kubectl create job hello --image=busybox -- echo "Hello World"
kubectl create job hello --image=busybox:1.28 -- echo "Hello World"
# create a CronJob that prints "Hello World" every minute
kubectl create cronjob hello --image=busybox --schedule="*/1 * * * *" -- echo "Hello World"
kubectl create cronjob hello --image=busybox:1.28 --schedule="*/1 * * * *" -- echo "Hello World"
kubectl explain pods # get the documentation for pod manifests
@ -113,7 +118,7 @@ metadata:
spec:
containers:
- name: busybox
image: busybox
image: busybox:1.28
args:
- sleep
- "1000000"
@ -125,7 +130,7 @@ metadata:
spec:
containers:
- name: busybox
image: busybox
image: busybox:1.28
args:
- sleep
- "1000"
@ -315,7 +320,7 @@ kubectl logs my-pod -c my-container --previous # dump pod container logs (s
kubectl logs -f my-pod # stream pod logs (stdout)
kubectl logs -f my-pod -c my-container # stream pod container logs (stdout, multi-container case)
kubectl logs -f -l name=myLabel --all-containers # stream all pods logs with label name=myLabel (stdout)
kubectl run -i --tty busybox --image=busybox -- sh # Run pod as interactive shell
kubectl run -i --tty busybox --image=busybox:1.28 -- sh # Run pod as interactive shell
kubectl run nginx --image=nginx -n mynamespace # Start a single instance of nginx pod in the namespace of mynamespace
kubectl run nginx --image=nginx # Run pod nginx and write its spec into a file called pod.yaml
--dry-run=client -o yaml > pod.yaml

6
content/en/docs/reference/labels-annotations-taints/_index.md
View File

@ -495,9 +495,11 @@ based on setting `securityContext` within the Pod's `.spec`.
## Annotations used for audit
- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
- [`authorization.k8s.io/decision`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-decision)
- [`authorization.k8s.io/reason`](/docs/reference/labels-annotations-taints/audit-annotations/#authorization-k8s-io-reason)
- [`pod-security.kubernetes.io/audit-violations`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-audit-violations)
- [`pod-security.kubernetes.io/enforce-policy`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-enforce-policy)
- [`pod-security.kubernetes.io/exempt`](/docs/reference/labels-annotations-taints/audit-annotations/#pod-security-kubernetes-io-exempt)
See more details on the [Audit Annotations](/docs/reference/labels-annotations-taints/audit-annotations/) page.

18
content/en/docs/reference/labels-annotations-taints/audit-annotations.md
View File

@ -56,4 +56,20 @@ that was transgressed as well as the specific policies on the fields that were
violated from the PodSecurity enforcement.
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/)
for more information.
for more information.
## authorization.k8s.io/decision
Example: `authorization.k8s.io/decision: "forbid"`
This annotation indicates whether or not a request was authorized in Kubernetes audit logs.
See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.
## authorization.k8s.io/reason
Example: `authorization.k8s.io/decision: "Human-readable reason for the decision"`
This annotation gives reason for the [decision](#authorization-k8s-io-decision) in Kubernetes audit logs.
See [Auditing](/docs/tasks/debug-application-cluster/audit/) for more information.

2
content/en/docs/setup/best-practices/certificates.md
View File

@ -22,6 +22,8 @@ This page explains the certificates that your cluster requires.
Kubernetes requires PKI for the following operations:
* Client certificates for the kubelet to authenticate to the API server
* Kubelet [server certificates](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates)
for the the API server to talk to the kubelets
* Server certificate for the API server endpoint
* Client certificates for administrators of the cluster to authenticate to the API server
* Client certificates for the API server to talk to the kubelets

3
content/en/docs/setup/production-environment/tools/kubeadm/kubelet-integration.md
View File

@ -203,6 +203,7 @@ The DEB and RPM packages shipped with the Kubernetes releases are:
| Package name | Description |
|--------------|-------------|
| `kubeadm` | Installs the `/usr/bin/kubeadm` CLI tool and the [kubelet drop-in file](#the-kubelet-drop-in-file-for-systemd) for the kubelet. |
| `kubelet` | Installs the kubelet binary in `/usr/bin` and CNI binaries in `/opt/cni/bin`. |
| `kubelet` | Installs the `/usr/bin/kubelet` binary. |
| `kubectl` | Installs the `/usr/bin/kubectl` binary. |
| `cri-tools` | Installs the `/usr/bin/crictl` binary from the [cri-tools git repository](https://github.com/kubernetes-sigs/cri-tools). |
| `kubernetes-cni` | Installs the `/opt/cni/bin` binaries from the [plugins git repository](https://github.com/containernetworking/plugins). |

31
content/en/docs/tasks/access-application-cluster/access-cluster.md
View File

@ -205,35 +205,10 @@ See documentation for other libraries for how they authenticate.
## Accessing the API from a Pod
When accessing the API from a pod, locating and authenticating
to the apiserver are somewhat different.
to the API server are somewhat different.
The recommended way to locate the apiserver within the pod is with
the `kubernetes.default.svc` DNS name, which resolves to a Service IP which in turn
will be routed to an apiserver.
The recommended way to authenticate to the apiserver is with a
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By kube-system, a pod
is associated with a service account, and a credential (token) for that
service account is placed into the filesystem tree of each container in that pod,
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.
If available, a certificate bundle is placed into the filesystem tree of each
container at `/var/run/secrets/kubernetes.io/serviceaccount/ca.crt`, and should be
used to verify the serving certificate of the apiserver.
Finally, the default namespace to be used for namespaced API operations is placed in a file
at `/var/run/secrets/kubernetes.io/serviceaccount/namespace` in each container.
From within a pod the recommended ways to connect to API are:
- Run `kubectl proxy` in a sidecar container in the pod, or as a background
process within the container. This proxies the
Kubernetes API to the localhost interface of the pod, so that other processes
in any container of the pod can access it.
- Use the Go client library, and create a client using the `rest.InClusterConfig()` and `kubernetes.NewForConfig()` functions.
They handle locating and authenticating to the apiserver. [example](https://git.k8s.io/client-go/examples/in-cluster-client-configuration/main.go)
In each case, the credentials of the pod are used to communicate securely with the apiserver.
Please check [Accessing the API from within a Pod](/docs/tasks/run-application/access-api-from-pod/)
for more details.
## Accessing services running on the cluster

14
content/en/docs/tasks/access-application-cluster/ingress-minikube.md
View File

@ -240,13 +240,13 @@ The following manifest defines an Ingress that sends traffic to your Service via
following lines at the end:
```yaml
- path: /v2
pathType: Prefix
backend:
service:
name: web2
port:
number: 8080
- path: /v2
pathType: Prefix
backend:
service:
name: web2
port:
number: 8080
```
1. Apply the changes:

79
content/en/docs/tasks/administer-cluster/change-pv-reclaim-policy.md
View File

@ -7,14 +7,10 @@ content_type: task
This page shows how to change the reclaim policy of a Kubernetes
PersistentVolume.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- steps -->
## Why change reclaim policy of a PersistentVolume
@ -33,55 +29,58 @@ Released phase, where all of its data can be manually recovered.
1. List the PersistentVolumes in your cluster:
```shell
kubectl get pv
```
```shell
kubectl get pv
```
The output is similar to this:
The output is similar to this:
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
```none
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
```
This list also includes the name of the claims that are bound to each volume
This list also includes the name of the claims that are bound to each volume
for easier identification of dynamically provisioned volumes.
1. Choose one of your PersistentVolumes and change its reclaim policy:
```shell
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
```
```shell
kubectl patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
```
where `<your-pv-name>` is the name of your chosen PersistentVolume.
where `<your-pv-name>` is the name of your chosen PersistentVolume.
{{< note >}}
On Windows, you must _double_ quote any JSONPath template that contains spaces (not single quote as shown above for bash). This in turn means that you must use a single quote or escaped double quote around any literals in the template. For example:
{{< note >}}
On Windows, you must _double_ quote any JSONPath template that contains spaces (not single
quote as shown above for bash). This in turn means that you must use a single quote or escaped
double quote around any literals in the template. For example:
```cmd
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
```
{{< /note >}}
```cmd
kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\":\"Retain\"}}"
```
{{< /note >}}
1. Verify that your chosen PersistentVolume has the right policy:
```shell
kubectl get pv
```
```shell
kubectl get pv
```
The output is similar to this:
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
In the preceding output, you can see that the volume bound to claim
`default/claim3` has reclaim policy `Retain`. It will not be automatically
deleted when a user deletes claim `default/claim3`.
The output is similar to this:
```none
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 40s
pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 36s
pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 33s
```
In the preceding output, you can see that the volume bound to claim
`default/claim3` has reclaim policy `Retain`. It will not be automatically
deleted when a user deletes claim `default/claim3`.
## {{% heading "whatsnext" %}}
@ -91,8 +90,8 @@ kubectl patch pv <your-pv-name> -p "{\"spec\":{\"persistentVolumeReclaimPolicy\"
### References {#reference}
* {{< api-reference page="config-and-storage-resources/persistent-volume-v1" >}}
* Pay attention to the `.spec.persistentVolumeReclaimPolicy` [field](https://kubernetes.io/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec) of PersistentVolume.
* Pay attention to the `.spec.persistentVolumeReclaimPolicy`
[field](/docs/reference/kubernetes-api/config-and-storage-resources/persistent-volume-v1/#PersistentVolumeSpec)
of PersistentVolume.
* {{< api-reference page="config-and-storage-resources/persistent-volume-claim-v1" >}}

6
content/en/docs/tasks/administer-cluster/declare-network-policy.md
View File

@ -68,7 +68,7 @@ pod/nginx-701339712-e0qfq 1/1 Running 0 35s
You should be able to access the new `nginx` service from other Pods. To access the `nginx` Service from another Pod in the `default` namespace, start a busybox container:
```console
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh
```
In your shell, run the following command:
@ -111,7 +111,7 @@ networkpolicy.networking.k8s.io/access-nginx created
When you attempt to access the `nginx` Service from a Pod without the correct labels, the request times out:
```console
kubectl run busybox --rm -ti --image=busybox -- /bin/sh
kubectl run busybox --rm -ti --image=busybox:1.28 -- /bin/sh
```
In your shell, run the command:
@ -130,7 +130,7 @@ wget: download timed out
You can create a Pod with the correct labels to see that the request is allowed:
```console
kubectl run busybox --rm -ti --labels="access=true" --image=busybox -- /bin/sh
kubectl run busybox --rm -ti --labels="access=true" --image=busybox:1.28 -- /bin/sh
```
In your shell, run the command:

73
content/en/docs/tasks/administer-cluster/ip-masq-agent.md
View File

@ -4,31 +4,27 @@ content_type: task
---
<!-- overview -->
This page shows how to configure and enable the ip-masq-agent.
This page shows how to configure and enable the `ip-masq-agent`.
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
<!-- discussion -->
## IP Masquerade Agent User Guide
The ip-masq-agent configures iptables rules to hide a pod's IP address behind the cluster node's IP address. This is typically done when sending traffic to destinations outside the cluster's pod [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) range.
The `ip-masq-agent` configures iptables rules to hide a pod's IP address behind the cluster node's IP address. This is typically done when sending traffic to destinations outside the cluster's pod [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) range.
### **Key Terms**
* **NAT (Network Address Translation)**
Is a method of remapping one IP address to another by modifying either the source and/or destination address information in the IP header. Typically performed by a device doing IP routing.
* **Masquerading**
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
* **CIDR (Classless Inter-Domain Routing)**
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
* **Link Local**
A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
* **NAT (Network Address Translation)**
Is a method of remapping one IP address to another by modifying either the source and/or destination address information in the IP header. Typically performed by a device doing IP routing.
* **Masquerading**
A form of NAT that is typically used to perform a many to one address translation, where multiple source IP addresses are masked behind a single address, which is typically the device doing the IP routing. In Kubernetes this is the Node's IP address.
* **CIDR (Classless Inter-Domain Routing)**
Based on the variable-length subnet masking, allows specifying arbitrary-length prefixes. CIDR introduced a new method of representation for IP addresses, now commonly known as **CIDR notation**, in which an address or routing prefix is written with a suffix indicating the number of bits of the prefix, such as 192.168.2.0/24.
* **Link Local**
A link-local address is a network address that is valid only for communications within the network segment or the broadcast domain that the host is connected to. Link-local addresses for IPv4 are defined in the address block 169.254.0.0/16 in CIDR notation.
The ip-masq-agent configures iptables rules to handle masquerading node/pod IP addresses when sending traffic to destinations outside the cluster node's IP and the Cluster IP range. This essentially hides pod IP addresses behind the cluster node's IP address. In some environments, traffic to "external" addresses must come from a known machine address. For example, in Google Cloud, any traffic to the internet must come from a VM's IP. When containers are used, as in Google Kubernetes Engine, the Pod IP will be rejected for egress. To avoid this, we must hide the Pod IP behind the VM's own IP address - generally known as "masquerade". By default, the agent is configured to treat the three private IP ranges specified by [RFC 1918](https://tools.ietf.org/html/rfc1918) as non-masquerade [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing). These ranges are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. The agent will also treat link-local (169.254.0.0/16) as a non-masquerade CIDR by default. The agent is configured to reload its configuration from the location */etc/config/ip-masq-agent* every 60 seconds, which is also configurable.
@ -36,14 +32,20 @@ The ip-masq-agent configures iptables rules to handle masquerading node/pod IP a
The agent configuration file must be written in YAML or JSON syntax, and may contain three optional keys:
* **nonMasqueradeCIDRs:** A list of strings in [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
* **masqLinkLocal:** A Boolean (true / false) which indicates whether to masquerade traffic to the link local prefix 169.254.0.0/16. False by default.
* **resyncInterval:** A time interval at which the agent attempts to reload config from disk. For example: '30s', where 's' means seconds, 'ms' means milliseconds, etc...
* `nonMasqueradeCIDRs`: A list of strings in
[CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) notation that specify the non-masquerade ranges.
* `masqLinkLocal`: A Boolean (true/false) which indicates whether to masquerade traffic to the
link local prefix `169.254.0.0/16`. False by default.
* `resyncInterval`: A time interval at which the agent attempts to reload config from disk.
For example: '30s', where 's' means seconds, 'ms' means milliseconds.
Traffic to 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) ranges will NOT be masqueraded. Any other traffic (assumed to be internet) will be masqueraded. An example of a local destination from a pod could be its Node's IP address as well as another node's address or one of the IP addresses in Cluster's IP range. Any other traffic will be masqueraded by default. The below entries show the default set of rules that are applied by the ip-masq-agent:
```
```shell
iptables -t nat -L IP-MASQ-AGENT
```
```none
RETURN all -- anywhere 169.254.0.0/16 /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
RETURN all -- anywhere 10.0.0.0/8 /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
RETURN all -- anywhere 172.16.0.0/12 /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
@ -52,33 +54,35 @@ MASQUERADE all -- anywhere anywhere /* ip-masq-agent:
```
By default, in GCE/Google Kubernetes Engine starting with Kubernetes version 1.7.0, if network policy is enabled or you are using a cluster CIDR not in the 10.0.0.0/8 range, the ip-masq-agent will run in your cluster. If you are running in another environment, you can add the ip-masq-agent [DaemonSet](/docs/concepts/workloads/controllers/daemonset/) to your cluster:
By default, in GCE/Google Kubernetes Engine, if network policy is enabled or
you are using a cluster CIDR not in the 10.0.0.0/8 range, the `ip-masq-agent`
will run in your cluster. If you are running in another environment,
you can add the `ip-masq-agent` [DaemonSet](/docs/concepts/workloads/controllers/daemonset/)
to your cluster.
<!-- steps -->
## Create an ip-masq-agent
To create an ip-masq-agent, run the following kubectl command:
`
```shell
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/ip-masq-agent/master/ip-masq-agent.yaml
`
```
You must also apply the appropriate node label to any nodes in your cluster that you want the agent to run on.
`
kubectl label nodes my-node beta.kubernetes.io/masq-agent-ds-ready=true
`
```shell
kubectl label nodes my-node node.kubernetes.io/masq-agent-ds-ready=true
```
More information can be found in the ip-masq-agent documentation [here](https://github.com/kubernetes-sigs/ip-masq-agent)
In most cases, the default set of rules should be sufficient; however, if this is not the case for your cluster, you can create and apply a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to customize the IP ranges that are affected. For example, to allow only 10.0.0.0/8 to be considered by the ip-masq-agent, you can create the following [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) in a file called "config".
{{< note >}}
It is important that the file is called config since, by default, that will be used as the key for lookup by the ip-masq-agent:
It is important that the file is called config since, by default, that will be used as the key for lookup by the `ip-masq-agent`:
```
```yaml
nonMasqueradeCIDRs:
- 10.0.0.0/8
resyncInterval: 60s
@ -87,15 +91,18 @@ resyncInterval: 60s
Run the following command to add the config map to your cluster:
```
```shell
kubectl create configmap ip-masq-agent --from-file=config --namespace=kube-system
```
This will update a file located at */etc/config/ip-masq-agent* which is periodically checked every *resyncInterval* and applied to the cluster node.
This will update a file located at `/etc/config/ip-masq-agent` which is periodically checked every `resyncInterval` and applied to the cluster node.
After the resync interval has expired, you should see the iptables rules reflect your changes:
```
```shell
iptables -t nat -L IP-MASQ-AGENT
```
```none
Chain IP-MASQ-AGENT (1 references)
target prot opt source destination
RETURN all -- anywhere 169.254.0.0/16 /* ip-masq-agent: cluster-local traffic should not be subject to MASQUERADE */ ADDRTYPE match dst-type !LOCAL
@ -103,9 +110,9 @@ RETURN all -- anywhere 10.0.0.0/8 /* ip-masq-agent:
MASQUERADE all -- anywhere anywhere /* ip-masq-agent: outbound traffic should be subject to MASQUERADE (this match must come after cluster-local CIDR matches) */ ADDRTYPE match dst-type !LOCAL
```
By default, the link local range (169.254.0.0/16) is also handled by the ip-masq agent, which sets up the appropriate iptables rules. To have the ip-masq-agent ignore link local, you can set *masqLinkLocal* to true in the config map.
By default, the link local range (169.254.0.0/16) is also handled by the ip-masq agent, which sets up the appropriate iptables rules. To have the ip-masq-agent ignore link local, you can set `masqLinkLocal` to true in the ConfigMap.
```
```yaml
nonMasqueradeCIDRs:
- 10.0.0.0/8
resyncInterval: 60s

31
content/en/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md
View File

@ -81,13 +81,13 @@ kubectl describe pod liveness-exec
The output indicates that no liveness probes have failed yet:
```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 11s default-scheduler Successfully assigned default/liveness-exec to node01
Normal Pulling 9s kubelet, node01 Pulling image "k8s.gcr.io/busybox"
Normal Pulled 7s kubelet, node01 Successfully pulled image "k8s.gcr.io/busybox"
Normal Created 7s kubelet, node01 Created container liveness
Normal Started 7s kubelet, node01 Started container liveness
```
After 35 seconds, view the Pod events again:
@ -100,14 +100,15 @@ At the bottom of the output, there are messages indicating that the liveness
probes have failed, and the containers have been killed and recreated.
```
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
--------- -------- ----- ---- ------------- -------- ------ -------
37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]
36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e
2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 57s default-scheduler Successfully assigned default/liveness-exec to node01
Normal Pulling 55s kubelet, node01 Pulling image "k8s.gcr.io/busybox"
Normal Pulled 53s kubelet, node01 Successfully pulled image "k8s.gcr.io/busybox"
Normal Created 53s kubelet, node01 Created container liveness
Normal Started 53s kubelet, node01 Started container liveness
Warning Unhealthy 10s (x3 over 20s) kubelet, node01 Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
Normal Killing 10s kubelet, node01 Container liveness failed liveness probe, will be restarted
```
Wait another 30 seconds, and verify that the container has been restarted:

50
content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
View File

@ -208,7 +208,6 @@ you need is an existing `docker-compose.yml` file.
- CLI
- [`kompose convert`](#kompose-convert)
- Documentation
- [Build and Push Docker Images](#build-and-push-docker-images)
- [Alternative Conversions](#alternative-conversions)
- [Labels](#labels)
- [Restart](#restart)
@ -326,55 +325,6 @@ INFO OpenShift file "foo-buildconfig.yaml" created
If you are manually pushing the OpenShift artifacts using ``oc create -f``, you need to ensure that you push the imagestream artifact before the buildconfig artifact, to workaround this OpenShift issue: https://github.com/openshift/origin/issues/4518 .
{{< /note >}}
## Build and Push Docker Images
Kompose supports both building and pushing Docker images. When using the `build` key within your Docker Compose file, your image will:
- Automatically be built with Docker using the `image` key specified within your file
- Be pushed to the correct Docker repository using local credentials (located at `.docker/config`)
Using an [example Docker Compose file](https://raw.githubusercontent.com/kubernetes/kompose/master/examples/buildconfig/docker-compose.yml):
```yaml
version: "2"
services:
foo:
build: "./build"
image: docker.io/foo/bar
```
Using `kompose up` with a `build` key:
```none
kompose up
INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar'
INFO Building image 'docker.io/foo/bar' from directory 'build'
INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
INFO Pushing image 'foo/bar:latest' to registry 'docker.io'
INFO Attempting authentication credentials 'https://index.docker.io/v1/
INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io'
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Deploying application in "default" namespace
INFO Successfully created Service: foo
INFO Successfully created Deployment: foo
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details.
```
In order to disable the functionality, or choose to use BuildConfig generation (with OpenShift) `--build (local|build-config|none)` can be passed.
```sh
# Disable building/pushing Docker images
kompose up --build none
# Generate Build Config artifacts for OpenShift
kompose up --provider openshift --build build-config
```
## Alternative Conversions
The default `kompose` transformation will generate Kubernetes [Deployments](/docs/concepts/workloads/controllers/deployment/) and [Services](/docs/concepts/services-networking/service/), in yaml format. You have alternative option to generate json with `-j`. Also, you can alternatively generate [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/) objects, [Daemon Sets](/docs/concepts/workloads/controllers/daemonset/), or [Helm](https://github.com/helm/helm) charts.

8
content/en/docs/tasks/debug-application-cluster/debug-running-pod.md
View File

@ -110,7 +110,7 @@ specify the `-i`/`--interactive` argument, `kubectl` will automatically attach
to the console of the Ephemeral Container.
```shell
kubectl debug -it ephemeral-demo --image=busybox --target=ephemeral-demo
kubectl debug -it ephemeral-demo --image=busybox:1.28 --target=ephemeral-demo
```
```
@ -182,7 +182,7 @@ but you need debugging utilities not included in `busybox`. You can simulate
this scenario using `kubectl run`:
```shell
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
Run this command to create a copy of `myapp` named `myapp-debug` that adds a
@ -225,7 +225,7 @@ To simulate a crashing application, use `kubectl run` to create a container
that immediately exits:
```
kubectl run --image=busybox myapp -- false
kubectl run --image=busybox:1.28 myapp -- false
```
You can see using `kubectl describe pod myapp` that this container is crashing:
@ -283,7 +283,7 @@ additional utilities.
As an example, create a Pod using `kubectl run`:
```
kubectl run myapp --image=busybox --restart=Never -- sleep 1d
kubectl run myapp --image=busybox:1.28 --restart=Never -- sleep 1d
```
Now use `kubectl debug` to make a copy and change its container image

132
content/en/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md
View File

@ -8,14 +8,19 @@ content_type: concept
<!-- overview -->
For Kubernetes, the _Metrics API_ offers a basic set of metrics to support automatic scaling and similar use cases.
This API makes information available about resource usage for node and pod, including metrics for CPU and memory.
If you deploy the Metrics API into your cluster, clients of the Kubernetes API can then query for this information, and
you can use Kubernetes' access control mechanisms to manage permissions to do so.
For Kubernetes, the _Metrics API_ offers a basic set of metrics to support automatic scaling and
similar use cases. This API makes information available about resource usage for node and pod,
including metrics for CPU and memory. If you deploy the Metrics API into your cluster, clients of
the Kubernetes API can then query for this information, and you can use Kubernetes' access control
mechanisms to manage permissions to do so.
The [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) and [VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA) use data from the metrics API to adjust workload replicas and resources to meet customer demand.
The [HorizontalPodAutoscaler](/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) and
[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA)
use data from the metrics API to adjust workload replicas and resources to meet customer demand.
You can also view the resource metrics using the [`kubectl top`](https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#top) command.
You can also view the resource metrics using the
[`kubectl top`](/docs/reference/generated/kubectl/kubectl-commands#top)
command.
{{< note >}}
The Metrics API, and the metrics pipeline that it enables, only offers the minimum
@ -59,34 +64,51 @@ Figure 1. Resource Metrics Pipeline
The architecture components, from right to left in the figure, consist of the following:
* [cAdvisor](https://github.com/google/cadvisor): Daemon for collecting, aggregating and exposing container metrics included in Kubelet.
* [kubelet](/docs/concepts/overview/components/#kubelet): Node agent for managing container resources. Resource metrics are accessible using the `/metrics/resource` and `/stats` kubelet API endpoints.
* [Summary API](#summary-api-source): API provided by the kubelet for discovering and retrieving per-node summarized stats available through the `/stats` endpoint.
* [metrics-server](#metrics-server): Cluster addon component that collects and aggregates resource metrics pulled from each kubelet. The API server serves Metrics API for use by HPA, VPA, and by the `kubectl top` command. Metrics Server is a reference implementation of the Metrics API.
* [Metrics API](#metrics-api): Kubernetes API supporting access to CPU and memory used for workload autoscaling. To make this work in your cluster, you need an API extension server that provides the Metrics API.
* [cAdvisor](https://github.com/google/cadvisor): Daemon for collecting, aggregating and exposing
container metrics included in Kubelet.
* [kubelet](/docs/concepts/overview/components/#kubelet): Node agent for managing container
resources. Resource metrics are accessible using the `/metrics/resource` and `/stats` kubelet
API endpoints.
* [Summary API](#summary-api-source): API provided by the kubelet for discovering and retrieving
per-node summarized stats available through the `/stats` endpoint.
* [metrics-server](#metrics-server): Cluster addon component that collects and aggregates resource
metrics pulled from each kubelet. The API server serves Metrics API for use by HPA, VPA, and by
the `kubectl top` command. Metrics Server is a reference implementation of the Metrics API.
* [Metrics API](#metrics-api): Kubernetes API supporting access to CPU and memory used for
workload autoscaling. To make this work in your cluster, you need an API extension server that
provides the Metrics API.
{{< note >}}
cAdvisor supports reading metrics from cgroups, which works with typical container runtimes on Linux.
If you use a container runtime that uses another resource isolation mechanism, for example virtualization, then that container runtime must support [CRI Container Metrics](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-container-stats.md) in order for metrics to be available to the kubelet.
If you use a container runtime that uses another resource isolation mechanism, for example
virtualization, then that container runtime must support
[CRI Container Metrics](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-container-stats.md)
in order for metrics to be available to the kubelet.
{{< /note >}}
<!-- body -->
## Metrics API
The metrics-server implements the Metrics API. This API allows you to access CPU and memory usage for the nodes and pods in your cluster. Its primary role is to feed resource usage metrics to K8s autoscaler components.
The metrics-server implements the Metrics API. This API allows you to access CPU and memory usage
for the nodes and pods in your cluster. Its primary role is to feed resource usage metrics to K8s
autoscaler components.
Here is an example of the Metrics API request for a `minikube` node piped through `jq` for easier
reading:
Here is an example of the Metrics API request for a `minikube` node piped through `jq` for easier reading:
```shell
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/minikube" | jq '.'
```
Here is the same API call using `curl`:
```shell
curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes/minikube
```
Sample reply:
Sample response:
```json
{
"kind": "NodeMetrics",
@ -104,16 +126,22 @@ Sample reply:
}
}
```
Here is an example of the Metrics API request for a `kube-scheduler-minikube` pod contained in the `kube-system` namespace and piped through `jq` for easier reading:
Here is an example of the Metrics API request for a `kube-scheduler-minikube` pod contained in the
`kube-system` namespace and piped through `jq` for easier reading:
```shell
kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube" | jq '.'
```
Here is the same API call using `curl`:
```shell
curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube
```
Sample reply:
Sample response:
```json
{
"kind": "PodMetrics",
@ -138,47 +166,72 @@ Sample reply:
}
```
The Metrics API is defined in the [k8s.io/metrics](https://github.com/kubernetes/metrics) repository. You must enable the [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) and register an [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) for the `metrics.k8s.io` API.
The Metrics API is defined in the [k8s.io/metrics](https://github.com/kubernetes/metrics)
repository. You must enable the [API aggregation layer](/docs/tasks/extend-kubernetes/configure-aggregation-layer/)
and register an [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)
for the `metrics.k8s.io` API.
To learn more about the Metrics API, see [resource metrics API design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md), the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server) and the [resource metrics API](https://github.com/kubernetes/metrics#resource-metrics-api).
To learn more about the Metrics API, see [resource metrics API design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md),
the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server) and the
[resource metrics API](https://github.com/kubernetes/metrics#resource-metrics-api).
{{< note >}} You must deploy the metrics-server or alternative adapter that serves the Metrics API to be able to access it. {{< /note >}}
{{< note >}}
You must deploy the metrics-server or alternative adapter that serves the Metrics API to be able
to access it.
{{< /note >}}
## Measuring resource usage
### CPU
CPU is reported as the average core usage measured in cpu units. One cpu, in Kubernetes, is equivalent to 1 vCPU/Core for cloud providers, and 1 hyper-thread on bare-metal Intel processors.
CPU is reported as the average core usage measured in cpu units. One cpu, in Kubernetes, is
equivalent to 1 vCPU/Core for cloud providers, and 1 hyper-thread on bare-metal Intel processors.
This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in both Linux and Windows kernels). The time window used to calculate CPU is shown under window field in Metrics API.
This value is derived by taking a rate over a cumulative CPU counter provided by the kernel (in
both Linux and Windows kernels). The time window used to calculate CPU is shown under window field
in Metrics API.
To learn more about how Kubernetes allocates and measures CPU resources, see [meaning of CPU](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu).
To learn more about how Kubernetes allocates and measures CPU resources, see
[meaning of CPU](/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu).
### Memory
Memory is reported as the working set, measured in bytes, at the instant the metric was collected.
In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under memory pressure. However, calculation of the working set varies by host OS, and generally makes heavy use of heuristics to produce an estimate.
In an ideal world, the "working set" is the amount of memory in-use that cannot be freed under
memory pressure. However, calculation of the working set varies by host OS, and generally makes
heavy use of heuristics to produce an estimate.
The Kubernetes model for a container's working set expects that the container runtime counts anonymous memory associated with the container in question. The working set metric typically also includes some cached (file-backed) memory, because the host OS cannot always reclaim pages.
The Kubernetes model for a container's working set expects that the container runtime counts
anonymous memory associated with the container in question. The working set metric typically also
includes some cached (file-backed) memory, because the host OS cannot always reclaim pages.
To learn more about how Kubernetes allocates and measures memory resources, see [meaning of memory](/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-memory).
To learn more about how Kubernetes allocates and measures memory resources, see
[meaning of memory](/docs/concepts/configuration/manage-resources-container/#meaning-of-memory).
## Metrics Server
The metrics-server fetches resource metrics from the kubelets and exposes them in the Kubernetes API server through the Metrics API for use by the HPA and VPA. You can also view these metrics using the `kubectl top` command.
The metrics-server fetches resource metrics from the kubelets and exposes them in the Kubernetes
API server through the Metrics API for use by the HPA and VPA. You can also view these metrics
using the `kubectl top` command.
The metrics-server uses the Kubernetes API to track nodes and pods in your cluster. The metrics-server queries each node over HTTP to fetch metrics. The metrics-server also builds an internal view of pod metadata, and keeps a cache of pod health. That cached pod health information is available via the extension API that the metrics-server makes available.
The metrics-server uses the Kubernetes API to track nodes and pods in your cluster. The
metrics-server queries each node over HTTP to fetch metrics. The metrics-server also builds an
internal view of pod metadata, and keeps a cache of pod health. That cached pod health information
is available via the extension API that the metrics-server makes available.
For example with an HPA query, the metrics-server needs to identify which pods fulfill the label selectors in the deployment.
For example with an HPA query, the metrics-server needs to identify which pods fulfill the label
selectors in the deployment.
The metrics-server calls the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) API
to collect metrics from each node. Depending on the metrics-server version it uses:
The metrics-server calls the [kubelet](/docs/reference/command-line-tools-reference/kubelet/) API to collect metrics from each node. Depending on the metrics-server version it uses:
* Metrics resource endpoint `/metrics/resource` in version v0.6.0+ or
* Summary API endpoint `/stats/summary` in older versions
To learn more about the metrics-server, see the [metrics-server repository](https://github.com/kubernetes-sigs/metrics-server).
To learn more about the metrics-server, see the
[metrics-server repository](https://github.com/kubernetes-sigs/metrics-server).
You can also check out the following:
@ -190,20 +243,25 @@ You can also check out the following:
### Summary API source
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at the node, volume, pod and container level, and emits this information in
The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) gathers stats at the node,
volume, pod and container level, and emits this information in
the [Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go)
for consumers to read.
Here is an example of a Summary API request for a `minikube` node:
```shell
kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary"
```
Here is the same API call using `curl`:
```shell
curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary
```
{{< note >}}
The summary API `/stats/summary` endpoint will be replaced by the `/metrics/resource` endpoint beginning with metrics-server 0.6.x.
{{< /note >}}
The summary API `/stats/summary` endpoint will be replaced by the `/metrics/resource` endpoint
beginning with metrics-server 0.6.x.
{{< /note >}}

2
content/en/docs/tasks/job/parallel-processing-expansion.md
View File

@ -201,7 +201,7 @@ spec:
spec:
containers:
- name: c
image: busybox
image: busybox:1.28
command: ["sh", "-c", "echo Processing URL {{ url }} && sleep 5"]
restartPolicy: Never
{% endfor %}

8
content/en/docs/tasks/manage-daemon/update-daemon-set.md
View File

@ -34,11 +34,11 @@ DaemonSet has two update strategy types:
To enable the rolling update feature of a DaemonSet, you must set its
`.spec.updateStrategy.type` to `RollingUpdate`.
You may want to set
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable)
You may want to set
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(default to 1),
[`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds)
(default to 0) and
[`.spec.minReadySeconds`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(default to 0) and
[`.spec.updateStrategy.rollingUpdate.maxSurge`](/docs/reference/kubernetes-api/workload-resources/daemon-set-v1/#DaemonSetSpec)
(a beta feature and defaults to 0) as well.

8
content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md
View File

@ -189,11 +189,11 @@ kubectl get deployment patch-demo --output yaml
The output shows that the PodSpec in the Deployment has only one Toleration:
```shell
```yaml
tolerations:
- effect: NoSchedule
key: disktype
value: ssd
- effect: NoSchedule
key: disktype
value: ssd
```
Notice that the `tolerations` list in the PodSpec was replaced, not merged. This is because

3
content/en/docs/tasks/run-application/access-api-from-pod.md
View File

@ -48,7 +48,8 @@ While running in a Pod, the Kubernetes apiserver is accessible via a Service nam
do this automatically.
The recommended way to authenticate to the API server is with a
[service account](/docs/tasks/configure-pod-container/configure-service-account/) credential. By default, a Pod
[service account](/docs/tasks/configure-pod-container/configure-service-account/)
credential. By default, a Pod
is associated with a service account, and a credential (token) for that
service account is placed into the filesystem tree of each container in that Pod,
at `/var/run/secrets/kubernetes.io/serviceaccount/token`.

2
content/en/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough.md
View File

@ -152,7 +152,7 @@ runs in an infinite loop, sending queries to the php-apache service.
```shell
# Run this in a separate terminal
# so that the load generation continues and you can carry on with the rest of the steps
kubectl run -i --tty load-generator --rm --image=busybox --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
```
Now run:

4
content/en/docs/tasks/tools/install-kubectl-linux.md
View File

@ -52,7 +52,7 @@ For example, to download version {{< param "fullversion" >}} on Linux, type:
Validate the kubectl binary against the checksum file:
```bash
echo "$(<kubectl.sha256) kubectl" | sha256sum --check
echo "$(cat kubectl.sha256) kubectl" | sha256sum --check
```
If valid, the output is:
@ -212,7 +212,7 @@ Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
Validate the kubectl-convert binary against the checksum file:
```bash
echo "$(<kubectl-convert.sha256) kubectl-convert" | sha256sum --check
echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
```
If valid, the output is:

8
content/en/docs/tasks/tools/install-kubectl-macos.md
View File

@ -69,7 +69,7 @@ The following methods exist for installing kubectl on macOS:
Validate the kubectl binary against the checksum file:
```bash
echo "$(<kubectl.sha256) kubectl" | shasum -a 256 --check
echo "$(cat kubectl.sha256) kubectl" | shasum -a 256 --check
```
If valid, the output is:
@ -114,7 +114,7 @@ The following methods exist for installing kubectl on macOS:
Or use this for detailed view of version:
```cmd
kubectl version --client --output=yaml
kubectl version --client --output=yaml
```
### Install with Homebrew on macOS
@ -124,7 +124,7 @@ If you are on macOS and using [Homebrew](https://brew.sh/) package manager, you
1. Run the installation command:
```bash
brew install kubectl
brew install kubectl
```
or
@ -205,7 +205,7 @@ Below are the procedures to set up autocompletion for Bash, Fish, and Zsh.
Validate the kubectl-convert binary against the checksum file:
```bash
echo "$(<kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
echo "$(cat kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
```
If valid, the output is:

12
content/en/docs/tasks/tools/install-kubectl-windows.md
View File

@ -38,13 +38,13 @@ The following methods exist for installing kubectl on Windows:
1. Validate the binary (optional)
Download the kubectl checksum file:
Download the `kubectl` checksum file:
```powershell
curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl.exe.sha256"
```
Validate the kubectl binary against the checksum file:
Validate the `kubectl` binary against the checksum file:
- Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
@ -59,7 +59,7 @@ The following methods exist for installing kubectl on Windows:
$($(CertUtil -hashfile .\kubectl.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl.exe.sha256)
```
1. Append or prepend the kubectl binary folder to your `PATH` environment variable.
1. Append or prepend the `kubectl` binary folder to your `PATH` environment variable.
1. Test to ensure the version of `kubectl` is the same as downloaded:
@ -156,13 +156,13 @@ Below are the procedures to set up autocompletion for PowerShell.
1. Validate the binary (optional)
Download the kubectl-convert checksum file:
Download the `kubectl-convert` checksum file:
```powershell
curl -LO "https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256"
```
Validate the kubectl-convert binary against the checksum file:
Validate the `kubectl-convert` binary against the checksum file:
- Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
@ -177,7 +177,7 @@ Below are the procedures to set up autocompletion for PowerShell.
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
```
1. Append or prepend the kubectl binary folder to your `PATH` environment variable.
1. Append or prepend the `kubectl-convert` binary folder to your `PATH` environment variable.
1. Verify plugin is successfully installed

2
content/en/docs/tutorials/security/apparmor.md
View File

@ -264,7 +264,7 @@ metadata:
spec:
containers:
- name: hello
image: busybox
image: busybox:1.28
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]
EOF
pod/hello-apparmor-2 created

2
content/en/docs/tutorials/services/source-ip.md
View File

@ -119,7 +119,7 @@ clusterip ClusterIP 10.0.170.92 <none> 80/TCP 51s
And hitting the `ClusterIP` from a pod in the same cluster:
```shell
kubectl run busybox -it --image=busybox --restart=Never --rm
kubectl run busybox -it --image=busybox:1.28 --restart=Never --rm
```
The output is similar to this:
```

2
content/en/examples/admin/logging/two-files-counter-pod-agent-sidecar.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: count
image: busybox
image: busybox:1.28
args:
- /bin/sh
- -c

6
content/en/examples/admin/logging/two-files-counter-pod-streaming-sidecar.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: count
image: busybox
image: busybox:1.28
args:
- /bin/sh
- -c
@ -22,13 +22,13 @@ spec:
- name: varlog
mountPath: /var/log
- name: count-log-1
image: busybox
image: busybox:1.28
args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
volumeMounts:
- name: varlog
mountPath: /var/log
- name: count-log-2
image: busybox
image: busybox:1.28
args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
volumeMounts:
- name: varlog

2
content/en/examples/admin/logging/two-files-counter-pod.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: count
image: busybox
image: busybox:1.28
args:
- /bin/sh
- -c

8
content/en/examples/admin/resource/limit-range-pod-1.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: busybox-cnt01
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"]
resources:
@ -16,7 +16,7 @@ spec:
memory: "200Mi"
cpu: "500m"
- name: busybox-cnt02
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"]
resources:
@ -24,7 +24,7 @@ spec:
memory: "100Mi"
cpu: "100m"
- name: busybox-cnt03
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"]
resources:
@ -32,6 +32,6 @@ spec:
memory: "200Mi"
cpu: "500m"
- name: busybox-cnt04
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"]

8
content/en/examples/admin/resource/limit-range-pod-2.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: busybox-cnt01
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"]
resources:
@ -16,7 +16,7 @@ spec:
memory: "200Mi"
cpu: "500m"
- name: busybox-cnt02
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"]
resources:
@ -24,7 +24,7 @@ spec:
memory: "100Mi"
cpu: "100m"
- name: busybox-cnt03
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"]
resources:
@ -32,6 +32,6 @@ spec:
memory: "200Mi"
cpu: "500m"
- name: busybox-cnt04
image: busybox
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"]

2
content/en/examples/admin/resource/limit-range-pod-3.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: busybox-cnt01
image: busybox
image: busybox:1.28
resources:
limits:
memory: "300Mi"

2
content/en/examples/application/job/cronjob.yaml
View File

@ -10,7 +10,7 @@ spec:
spec:
containers:
- name: hello
image: busybox
image: busybox:1.28
imagePullPolicy: IfNotPresent
command:
- /bin/sh

2
content/en/examples/application/job/job-tmpl.yaml
View File

@ -13,6 +13,6 @@ spec:
spec:
containers:
- name: c
image: busybox
image: busybox:1.28
command: ["sh", "-c", "echo Processing item $ITEM && sleep 5"]
restartPolicy: Never

2
content/en/examples/debug/counter-pod.yaml
View File

@ -5,6 +5,6 @@ metadata:
spec:
containers:
- name: count
image: busybox
image: busybox:1.28
args: [/bin/sh, -c,
'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

1
content/en/examples/examples_test.go
View File

@ -556,6 +556,7 @@ func TestExampleObjectSchemas(t *testing.T) {
"pod-projected-svc-token": {&api.Pod{}},
"pod-rs": {&api.Pod{}, &api.Pod{}},
"pod-single-configmap-env-variable": {&api.Pod{}},
"pod-with-affinity-anti-affinity": {&api.Pod{}},
"pod-with-node-affinity": {&api.Pod{}},
"pod-with-pod-affinity": {&api.Pod{}},
"pod-with-toleration": {&api.Pod{}},

2
content/en/examples/pods/init-containers.yaml
View File

@ -14,7 +14,7 @@ spec:
# These containers are run during pod initialization
initContainers:
- name: install
image: busybox
image: busybox:1.28
command:
- wget
- "-O"

2
content/en/examples/pods/inject/dependent-envars.yaml
View File

@ -10,7 +10,7 @@ spec:
command:
- sh
- -c
image: busybox
image: busybox:1.28
env:
- name: SERVICE_PORT
value: "80"

32
content/en/examples/pods/pod-with-affinity-anti-affinity.yaml Normal file
View File

@ -0,0 +1,32 @@
apiVersion: v1
kind: Pod
metadata:
name: with-affinity-anti-affinity
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: In
values:
- linux
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: label-1
operator: In
values:
- key-1
- weight: 50
preference:
matchExpressions:
- key: label-2
operator: In
values:
- key-2
containers:
- name: with-node-affinity
image: k8s.gcr.io/pause:2.0

5
content/en/examples/pods/pod-with-node-affinity.yaml
View File

@ -8,11 +8,10 @@ spec:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/e2e-az-name
- key: kubernetes.io/os
operator: In
values:
- e2e-az1
- e2e-az2
- linux
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:

2
content/en/examples/pods/security/hello-apparmor.yaml
View File

@ -9,5 +9,5 @@ metadata:
spec:
containers:
- name: hello
image: busybox
image: busybox:1.28
command: [ "sh", "-c", "echo 'Hello AppArmor!' && sleep 1h" ]

2
content/en/examples/pods/security/security-context.yaml
View File

@ -12,7 +12,7 @@ spec:
emptyDir: {}
containers:
- name: sec-ctx-demo
image: busybox
image: busybox:1.28
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol

2
content/en/examples/pods/share-process-namespace.yaml
View File

@ -8,7 +8,7 @@ spec:
- name: nginx
image: nginx
- name: shell
image: busybox
image: busybox:1.28
securityContext:
capabilities:
add:

2
content/en/examples/pods/storage/projected-secret-downwardapi-configmap.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: container-test
image: busybox
image: busybox:1.28
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"

2
content/en/examples/pods/storage/projected-secrets-nondefault-permission-mode.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: container-test
image: busybox
image: busybox:1.28
volumeMounts:
- name: all-in-one
mountPath: "/projected-volume"

2
content/en/examples/pods/storage/projected-service-account-token.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: container-test
image: busybox
image: busybox:1.28
volumeMounts:
- name: token-vol
mountPath: "/service-account"

2
content/en/examples/pods/storage/projected.yaml
View File

@ -5,7 +5,7 @@ metadata:
spec:
containers:
- name: test-projected-volume
image: busybox
image: busybox:1.28
args:
- sleep
- "86400"

2
content/en/examples/service/networking/hostaliases-pod.yaml
View File

@ -15,7 +15,7 @@ spec:
- "bar.remote"
containers:
- name: cat-hosts
image: busybox
image: busybox:1.28
command:
- cat
args:

5
content/en/releases/patch-releases.md
View File

@ -78,10 +78,10 @@ releases may also occur in between these.
| Monthly Patch Release | Cherry Pick Deadline | Target date |
| --------------------- | -------------------- | ----------- |
| March 2022 | 2022-03-11 | 2022-03-16 |
| April 2022 | 2022-04-08 | 2022-04-13 |
| May 2022 | 2022-05-13 | 2022-05-18 |
| June 2022 | 2022-06-10 | 2022-06-15 |
| July 2022 | 2022-07-08 | 2022-07-13 |
## Detailed Release History for Active Branches
@ -93,6 +93,7 @@ End of Life for **1.23** is **2023-02-28**.
| Patch Release | Cherry Pick Deadline | Target Date | Note |
|---------------|----------------------|-------------|------|
| 1.23.6 | 2022-04-08 | 2022-04-13 | |
| 1.23.5 | 2022-03-11 | 2022-03-16 | |
| 1.23.4 | 2022-02-11 | 2022-02-16 | |
| 1.23.3 | 2022-01-24 | 2022-01-25 | [Out-of-Band Release](https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) |
@ -107,6 +108,7 @@ End of Life for **1.22** is **2022-10-28**
| Patch Release | Cherry Pick Deadline | Target Date | Note |
|---------------|----------------------|-------------|------|
| 1.22.9 | 2022-04-08 | 2022-04-13 | |
| 1.22.8 | 2022-03-11 | 2022-03-16 | |
| 1.22.7 | 2022-02-11 | 2022-02-16 | |
| 1.22.6 | 2022-01-14 | 2022-01-19 | |
@ -124,6 +126,7 @@ End of Life for **1.21** is **2022-06-28**
| Patch Release | Cherry Pick Deadline | Target Date | Note |
| ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- |
| 1.21.12 | 2022-04-08 | 2022-04-13 | |
| 1.21.11 | 2022-03-11 | 2022-03-16 | |
| 1.21.10 | 2022-02-11 | 2022-02-16 | |
| 1.21.9 | 2022-01-14 | 2022-01-19 | |

168
content/fr/docs/tasks/configure-pod-container/translate-compose-kubernetes.md
View File

@ -121,22 +121,7 @@ En quelques étapes, nous vous emmenons de Docker Compose à Kubernetes. Tous do
kompose.service.type: LoadBalancer
```
2. Lancez la commande `kompose up` pour déployer directement sur Kubernetes, ou passez plutôt à l'étape suivante pour générer un fichier à utiliser avec `kubectl`.
```bash
$ kompose up
We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Successfully created Service: redis
INFO Successfully created Service: web
INFO Successfully created Deployment: redis
INFO Successfully created Deployment: web
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details.
```
3. Pour convertir le fichier `docker-compose.yml` en fichiers que vous pouvez utiliser avec `kubectl`, lancez `kompose convert` et ensuite `kubectl apply -f <output file>`.
2. Pour convertir le fichier `docker-compose.yml` en fichiers que vous pouvez utiliser avec `kubectl`, lancez `kompose convert` et ensuite `kubectl apply -f <output file>`.
```bash
$ kompose convert
@ -160,7 +145,7 @@ En quelques étapes, nous vous emmenons de Docker Compose à Kubernetes. Tous do
Vos déploiements fonctionnent sur Kubernetes.
4. Accédez à votre application.
3. Accédez à votre application.
Si vous utilisez déjà `minikube` pour votre processus de développement :
@ -201,10 +186,7 @@ En quelques étapes, nous vous emmenons de Docker Compose à Kubernetes. Tous do
- CLI
- [`kompose convert`](#kompose-convert)
- [`kompose up`](#kompose-up)
- [`kompose down`](#kompose-down)
- Documentation
- [Construire et pousser des images de docker](#build-and-push-docker-images)
- [Conversions alternatives](#alternative-conversions)
- [Etiquettes](#labels)
- [Redémarrage](#restart)
@ -301,152 +283,6 @@ INFO OpenShift file "foo-buildconfig.yaml" created
Si vous poussez manuellement les artefacts OpenShift en utilisant ``oc create -f``, vous devez vous assurer que vous poussez l'artefact imagestream avant l'artefact buildconfig, pour contourner ce problème OpenShift : https://github.com/openshift/origin/issues/4518 .
{{< /note >}}
## `kompose up`
Kompose propose un moyen simple de déployer votre application "composée" sur Kubernetes ou OpenShift via `kompose up`.
### Kubernetes
```sh
$ kompose --file ./examples/docker-guestbook.yml up
We are going to create Kubernetes deployments and services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Successfully created service: redis-master
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created deployment: redis-master
INFO Successfully created deployment: redis-slave
INFO Successfully created deployment: frontend
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods' for details.
$ kubectl get deployment,svc,pods
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
deployment.extensions/frontend 1 1 1 1 4m
deployment.extensions/redis-master 1 1 1 1 4m
deployment.extensions/redis-slave 1 1 1 1 4m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/frontend ClusterIP 10.0.174.12 <none> 80/TCP 4m
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 13d
service/redis-master ClusterIP 10.0.202.43 <none> 6379/TCP 4m
service/redis-slave ClusterIP 10.0.1.85 <none> 6379/TCP 4m
NAME READY STATUS RESTARTS AGE
pod/frontend-2768218532-cs5t5 1/1 Running 0 4m
pod/redis-master-1432129712-63jn8 1/1 Running 0 4m
pod/redis-slave-2504961300-nve7b 1/1 Running 0 4m
```
**Note**:
- Vous devez avoir un cluster Kubernetes en cours d'exécution avec kubectl pré-configuré.
- Seuls les déploiements et les services sont générés et déployés dans Kubernetes. Si vous avez besoin d'autres types de ressources, utilisez les commandes `kompose convert` et `kubectl apply -f` à la place.
### OpenShift
```sh
$ kompose --file ./examples/docker-guestbook.yml --provider openshift up
We are going to create OpenShift DeploymentConfigs and Services for your Dockerized application.
If you need different kind of resources, use the 'kompose convert' and 'oc create -f' commands instead.
INFO Successfully created service: redis-slave
INFO Successfully created service: frontend
INFO Successfully created service: redis-master
INFO Successfully created deployment: redis-slave
INFO Successfully created ImageStream: redis-slave
INFO Successfully created deployment: frontend
INFO Successfully created ImageStream: frontend
INFO Successfully created deployment: redis-master
INFO Successfully created ImageStream: redis-master
Your application has been deployed to OpenShift. You can run 'oc get dc,svc,is' for details.
$ oc get dc,svc,is
NAME REVISION DESIRED CURRENT TRIGGERED BY
dc/frontend 0 1 0 config,image(frontend:v4)
dc/redis-master 0 1 0 config,image(redis-master:e2e)
dc/redis-slave 0 1 0 config,image(redis-slave:v1)
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/frontend 172.30.46.64 <none> 80/TCP 8s
svc/redis-master 172.30.144.56 <none> 6379/TCP 8s
svc/redis-slave 172.30.75.245 <none> 6379/TCP 8s
NAME DOCKER REPO TAGS UPDATED
is/frontend 172.30.12.200:5000/fff/frontend
is/redis-master 172.30.12.200:5000/fff/redis-master
is/redis-slave 172.30.12.200:5000/fff/redis-slave v1
```
**Note**:
- Vous devez avoir un cluster OpenShift en cours d'exécution avec `oc` pré-configuré (`oc login`)
## `kompose down`
Une fois que vous avez déployé l'application "composée" sur Kubernetes, `$ kompose down` vous
facilitera la suppression de l'application en supprimant ses déploiements et services. Si vous avez besoin de supprimer d'autres ressources, utilisez la commande 'kubectl'.
```sh
$ kompose --file docker-guestbook.yml down
INFO Successfully deleted service: redis-master
INFO Successfully deleted deployment: redis-master
INFO Successfully deleted service: redis-slave
INFO Successfully deleted deployment: redis-slave
INFO Successfully deleted service: frontend
INFO Successfully deleted deployment: frontend
```
**Note**:
- Vous devez avoir un cluster Kubernetes en cours d'exécution avec kubectl pré-configuré.
## Construire et pousser des images de docker
Kompose permet de construire et de pousser des images Docker. Lorsque vous utilisez la clé `build` dans votre fichier Docker Compose, votre image sera :
- Automatiquement construite avec le Docker en utilisant la clé "image" spécifiée dans votre fichier
- Être poussé vers le bon dépôt Docker en utilisant les identifiants locaux (situés dans `.docker/config`)
Utilisation d'un [exemple de fichier Docker Compose](https://raw.githubusercontent.com/kubernetes/kompose/master/examples/buildconfig/docker-compose.yml):
```yaml
version: "2"
services:
foo:
build: "./build"
image: docker.io/foo/bar
```
En utilisant `kompose up` avec une clé `build` :
```none
$ kompose up
INFO Build key detected. Attempting to build and push image 'docker.io/foo/bar'
INFO Building image 'docker.io/foo/bar' from directory 'build'
INFO Image 'docker.io/foo/bar' from directory 'build' built successfully
INFO Pushing image 'foo/bar:latest' to registry 'docker.io'
INFO Attempting authentication credentials 'https://index.docker.io/v1/
INFO Successfully pushed image 'foo/bar:latest' to registry 'docker.io'
INFO We are going to create Kubernetes Deployments, Services and PersistentVolumeClaims for your Dockerized application. If you need different kind of resources, use the 'kompose convert' and 'kubectl apply -f' commands instead.
INFO Deploying application in "default" namespace
INFO Successfully created Service: foo
INFO Successfully created Deployment: foo
Your application has been deployed to Kubernetes. You can run 'kubectl get deployment,svc,pods,pvc' for details.
```
Afin de désactiver cette fonctionnalité, ou de choisir d'utiliser la génération de BuildConfig (avec OpenShift) `--build (local|build-config|none)` peut être passé.
```sh
# Désactiver la construction/poussée d'images Docker
$ kompose up --build none
# Générer des artefacts de Build Config pour OpenShift
$ kompose up --provider openshift --build build-config
```
## Autres conversions
La transformation par défaut `komposer` va générer des [Déploiements](/docs/concepts/workloads/controllers/deployment/) et [Services](/docs/concepts/services-networking/service/) de Kubernetes, au format yaml. Vous avez une autre option pour générer json avec `-j`. Vous pouvez aussi générer des objets de [Replication Controllers](/docs/concepts/workloads/controllers/replicationcontroller/), [Daemon Sets](/docs/concepts/workloads/controllers/daemonset/), ou [Helm](https://github.com/helm/helm) charts.

2
content/ja/docs/home/_index.md
View File

@ -59,7 +59,7 @@ cards:
title: "K8sリリースノート"
description: "もしKubernetesをインストールする、また最新バージョンにアップグレードする場合、最新のリリースノートを参照してください。"
button: "Kubernetesをダウンロードする"
button_path: "/docs/setup/release/notes"
button_path: "/releases/download"
- name: about
title: ドキュメントについて
description: このWebサイトには、Kubernetesの最新バージョンと過去4世代のドキュメントが含まれています。

2
content/ja/docs/tasks/debug-application-cluster/audit.md
View File

@ -149,6 +149,7 @@ volumeMounts:
最後に`hostPath`を設定します:
```yaml
...
volumes:
- name: audit
hostPath:
path: /etc/kubernetes/audit-policy.yaml
@ -158,7 +159,6 @@ volumeMounts:
hostPath:
path: /var/log/audit.log
type: FileOrCreate
```
### Webhookバックエンド

2
content/ko/docs/tasks/run-application/horizontal-pod-autoscale.md
View File

@ -51,7 +51,7 @@ Horizontal Pod Autoscaling을 활용하는
쿠버네티스는 Horizontal Pod Autoscaling을
간헐적으로(intermittently) 실행되는
컨트롤 루프 형태로 구현했다(지숙적인 프로세스가 아니다).
컨트롤 루프 형태로 구현했다(지속적인 프로세스가 아니다).
실행 주기는 [`kube-controller-manager`](/docs/reference/command-line-tools-reference/kube-controller-manager/)의
`--horizontal-pod-autoscaler-sync-period` 파라미터에 의해 설정된다(기본 주기는 15초이다).

208
content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md Normal file
View File

@ -0,0 +1,208 @@
---
layout: blog
title: "Atualizado: Perguntas frequentes (FAQ) sobre a remoção do Dockershim"
date: 2022-02-17
slug: dockershim-faq
aliases: [ '/dockershim' ]
---
**Esta é uma atualização do artigo original [FAQ sobre a depreciação do Dockershim](/blog/2020/12/02/dockershim-faq/),
publicado no final de 2020.**
Este documento aborda algumas perguntas frequentes sobre a
descontinuação e remoção do _dockershim_, que foi
[anunciado](/blog/2020/12/08/kubernetes-1-20-release-announcement/)
como parte do lançamento do Kubernetes v1.20. Para obter mais detalhes sobre
o que isso significa, confira a postagem do blog
[Não entre em pânico: Kubernetes e Docker](/pt-br/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
Além disso, você pode ler [verifique se a remoção do dockershim afeta você](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
para determinar qual impacto a remoção do _dockershim_ teria para você
ou para sua organização.
Como o lançamento do Kubernetes 1.24 se tornou iminente, estamos trabalhando bastante para tentar fazer uma transição suave.
- Escrevemos uma postagem no blog detalhando nosso [compromisso e os próximos passos](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
- Acreditamos que não há grandes obstáculos para a migração para [outros agentes de execução de contêiner](/docs/setup/production-environment/container-runtimes/#container-runtimes).
- Há também um guia [Migrando do dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) disponível.
- Também criamos uma página para listar
[artigos sobre a remoção do dockershim e sobre o uso de agentes de execução compatíveis com CRI](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/). Essa lista inclui alguns dos documentos já mencionados e também
abrange fontes externas selecionadas (incluindo guias de fornecedores).
### Por que o _dockershim_ está sendo removido do Kubernetes?
As primeiras versões do Kubernetes funcionavam apenas com um ambiente de execução de contêiner específico:
Docker Engine. Mais tarde, o Kubernetes adicionou suporte para trabalhar com outros agentes de execução de contêiner.
O padrão CRI (_Container Runtime Interface_ ou Interface de Agente de Execução de Containers) foi [criado](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) para
habilitar a interoperabilidade entre orquestradores (como Kubernetes) e diferentes agentes
de execução de contêiner.
O Docker Engine não implementa essa interface (CRI), então o projeto Kubernetes criou um
código especial para ajudar na transição, e tornou esse código _dockershim_ parte do projeto
Kubernetes.
O código _dockershim_ sempre foi destinado a ser uma solução temporária (daí o nome: _shim_).
Você pode ler mais sobre a discussão e o planejamento da comunidade na
[Proposta de remoção do Dockershim para aprimoramento do Kubernetes][drkep].
Na verdade, manter o _dockershim_ se tornou um fardo pesado para os mantenedores do Kubernetes.
Além disso, recursos que são amplamente incompatíveis com o _dockershim_, como
_cgroups v2_ e _namespaces_ de usuário estão sendo implementados nos agentes de execução de CRI
mais recentes. A remoção do suporte para o _dockershim_ permitirá um maior
desenvolvimento nessas áreas.
[drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim
### Ainda posso usar o Docker Engine no Kubernetes 1.23?
Sim, a única coisa que mudou na versão 1.20 é a presença de um aviso no log de inicialização
do [kubelet] se estiver usando o Docker Engine como agente de execução de contêiner.
Você verá este aviso em todas as versões até 1.23. A remoção do _dockershim_ ocorre no Kubernetes 1.24.
[kubelet]: /docs/reference/command-line-tools-reference/kubelet/
### Quando o _dockershim_ será removido?
Dado o impacto dessa mudança, estamos definindo um cronograma de depreciação mais longo.
A remoção do _dockershim_ está agendada para o Kubernetes v1.24, consulte a
[Proposta de remoção do Dockershim para aprimoramento do Kubernetes][drkep].
O projeto Kubernetes trabalhará em estreita colaboração com fornecedores e outros ecossistemas para garantir
uma transição suave e avaliará os acontecimentos à medida que a situação for evoluindo.
### Ainda posso usar o Docker Engine como meu agente de execução do contêiner?
Primeiro, se você usa o Docker em seu próprio PC para desenvolver ou testar contêineres: nada muda.
Você ainda pode usar o Docker localmente, independentemente dos agentes de execução de contêiner que
você usa em seus Clusters Kubernetes. Os contêineres tornam esse tipo de interoperabilidade possível.
Mirantis e Docker [comprometeram-se][mirantis] a manter um adaptador substituto para o
Docker Engine, e a manter este adaptador mesmo após o _dockershim_ ser removido
do Kubernetes. O adaptador substituto é chamado [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/
### Minhas imagens de contêiner existentes ainda funcionarão?
Sim, as imagens produzidas a partir do `docker build` funcionarão com todas as implementações do CRI.
Todas as suas imagens existentes ainda funcionarão exatamente da mesma forma.
#### E as imagens privadas?
Sim. Todos os agentes de execução de CRI são compatíveis com as mesmas configurações de segredos usadas no
Kubernetes, seja por meio do PodSpec ou ServiceAccount.
### Docker e contêineres são a mesma coisa?
Docker popularizou o padrão de contêineres Linux e tem sido fundamental no
desenvolvimento desta tecnologia. No entanto, os contêineres já existiam
no Linux há muito tempo. O ecossistema de contêineres cresceu para ser muito
mais abrangente do que apenas Docker. Padrões como o OCI e o CRI ajudaram muitas
ferramentas a crescer e prosperar no nosso ecossistema, alguns substituindo
aspectos do Docker, enquanto outros aprimoram funcionalidades já existentes.
### Existem exemplos de pessoas que usam outros agentes de execução de contêineres em produção hoje?
Todos os artefatos produzidos pelo projeto Kubernetes (binários Kubernetes) são validados
a cada lançamento de versão.
Além disso, o projeto [kind] vem usando containerd há algum tempo e tem
visto uma melhoria na estabilidade para seu caso de uso. Kind e containerd são executados
várias vezes todos os dias para validar quaisquer alterações na base de código do Kubernetes.
Outros projetos relacionados seguem um padrão semelhante, demonstrando a estabilidade e
usabilidade de outros agentes de execução de contêiner. Como exemplo, o OpenShift 4.x utiliza
o agente de execução [CRI-O] em produção desde junho de 2019.
Para outros exemplos e referências, dê uma olhada em projetos adeptos do containerd e
CRI-O, dois agentes de execução de contêineres sob o controle da _Cloud Native Computing Foundation_
([CNCF]).
- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md)
- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md)
[CRI-O]: https://cri-o.io/
[kind]: https://kind.sigs.k8s.io/
[CNCF]: https://cncf.io
### As pessoas continuam referenciando OCI, o que é isso?
OCI significa _[Open Container Initiative]_ (ou Iniciativa Open Source de Contêineres), que padronizou muitas das
interfaces entre ferramentas e tecnologias de contêiner. Eles mantêm uma
especificação padrão para imagens de contêiner (OCI image-spec) e para
contêineres em execução (OCI runtime-spec). Eles também mantêm uma implementação real
da especificação do agente de execução na forma de [runc], que é o agente de execução padrão
para ambos [containerd] e [CRI-O]. O CRI baseia-se nessas especificações de baixo nível para
fornecer um padrão de ponta a ponta para gerenciar contêineres.
[Open Container Initiative]: https://opencontainers.org/about/overview/
[runc]: https://github.com/opencontainers/runc
[containerd]: https://containerd.io/
### Qual implementação de CRI devo usar?
Essa é uma pergunta complexa e depende de muitos fatores. Se você estiver
trabalhando com Docker, mudar para containerd deve ser uma troca relativamente fácil e
terá um desempenho estritamente melhor e menos sobrecarga. No entanto, nós encorajamos você a
explorar todas as opções do [cenário CNCF], pois outro agente de execução de contêiner
pode funcionar ainda melhor para o seu ambiente.
[cenário CNCF]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category
### O que devo ficar atento ao mudar a minha implementação de CRI utilizada?
Embora o código de conteinerização base seja o mesmo entre o Docker e a maioria dos
CRIs (incluindo containerd), existem algumas poucas diferenças. Alguns
pontos a se considerar ao migrar são:
- Configuração de _log_
- Limitações de recursos de agentes de execução
- Scripts de provisionamento que chamam o docker ou usam o docker por meio de seu soquete de controle
- Plugins kubectl que exigem CLI do docker ou o soquete de controle
- Ferramentas do projeto Kubernetes que requerem acesso direto ao Docker Engine
(por exemplo: a ferramenta depreciada `kube-imagepuller`)
- Configuração de funcionalidades como `registry-mirrors` e _registries_ inseguros
- Outros scripts de suporte ou _daemons_ que esperam que o Docker Engine esteja disponível e seja executado
fora do Kubernetes (por exemplo, agentes de monitoramento ou segurança)
- GPUs ou hardware especial e como eles se integram ao seu agente de execução e ao Kubernetes
Se você usa solicitações ou limites de recursos do Kubernetes ou usa DaemonSets para coleta de logs
em arquivos, eles continuarão a funcionar da mesma forma. Mas se você personalizou
sua configuração `dockerd`, você precisará adaptá-la para seu novo agente de execução de
contêiner assim que possível.
Outro aspecto a ser observado é que ferramentas para manutenção do sistema ou execuções dentro de um
contêiner no momento da criação de imagens podem não funcionar mais. Para o primeiro, a ferramenta
[`crictl`][cr] pode ser utilizada como um substituto natural (veja
[migrando do docker cli para o crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))
e para o último, você pode usar novas opções de construções de contêiner, como [img], [buildah],
[kaniko], ou [buildkit-cli-for-kubectl] que não requerem Docker.
[cr]: https://github.com/kubernetes-sigs/cri-tools
[img]: https://github.com/genuinetools/img
[buildah]: https://github.com/containers/buildah
[kaniko]: https://github.com/GoogleContainerTools/kaniko
[buildkit-cli-for-kubectl]: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl
Para containerd, você pode começar com sua [documentação] para ver quais opções de configuração
estão disponíveis à medida que você vá realizando a migração.
[documentação]: https://github.com/containerd/cri/blob/master/docs/registry.md
Para obter instruções sobre como usar containerd e CRI-O com Kubernetes, consulte o
documentação do Kubernetes em [Agentes de execução de contêineres]
[Agentes de execução de contêineres]: /docs/setup/production-environment/container-runtimes/
### E se eu tiver mais perguntas?
Se você usa uma distribuição do Kubernetes com suporte do fornecedor, pode perguntar a eles sobre
planos de atualização para seus produtos. Para perguntas de usuário final, poste-as
no nosso fórum da comunidade de usuários: https://discuss.kubernetes.io/.
Você também pode conferir a excelente postagem do blog
[Espere, o Docker está depreciado no Kubernetes agora?][dep], uma discussão técnica mais aprofundada
sobre as mudanças.
[dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
### Posso ganhar um abraço?
Sim, ainda estamos dando abraços se solicitado. 🤗🤗🤗

4
content/ru/community/static/README.md
View File

@ -1,2 +1,2 @@
Файлы в этой диркетории были импортированы из других источников.
Не редактируйте их напрямую, вместо этого заменяйте их более новыми версиями.
Файлы в этой директории были импортированы из других источников.
Не редактируйте их напрямую, вместо этого заменяйте их более новыми версиями.

2
content/ru/community/static/community-values.md
View File

@ -25,4 +25,4 @@
Открытость новым идеям и изученная технологическая эволюция делают Kubernetes более сильным проектом. Постоянное совершенствование, лидерство слуг, наставничество и уважение-вот основы культуры проекта Kubernetes. Лидеры сообщества Kubernetes обязаны находить, спонсировать и продвигать новых членов сообщества. Лидеры должны ожидать, что они отойдут в сторону. Члены сообщества должны ожидать, что они сделают шаг вперед.
**"Culture eats strategy for breakfast." --Peter Drucker**
**"Культура съедает стратегию на завтрак" — Питер Друкер**

5
content/ru/docs/concepts/architecture/_index.md
View File

@ -2,6 +2,5 @@
title: "Кластерная Архитектура"
weight: 30
description: >
The architectural concepts behind Kubernetes.
---
Архитектурные концепции, лежащие в основе Kubernetes.
---

22
content/ru/docs/concepts/architecture/cloud-controller.md
View File

@ -8,7 +8,7 @@ weight: 40
{{< feature-state state="beta" for_k8s_version="v1.11" >}}
Технологии облачной инфраструктуры позволяет запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами.
Технологии облачной инфраструктуры позволяют запускать Kubernetes в общедоступных, частных и гибридных облаках. Kubernetes верит в автоматизированную, управляемую API инфраструктуру без жесткой связи между компонентами.
{{< glossary_definition term_id="cloud-controller-manager" length="all" prepend="Диспетчер облачных контроллеров">}}
@ -33,7 +33,7 @@ weight: 40
Контроллеры внутри диспетчера облачных контроллеров включают в себя:
### Контролер узла
### Контроллер узла
Контроллер узла отвечает за создание объектов {{< glossary_tooltip text="узла" term_id="node" >}} при создании новых серверов в вашей облачной инфраструктуре. Контроллер узла получает информацию о работающих хостах внутри вашей арендуемой инфраструктуры облачного провайдера.
Контроллер узла выполняет следующие функции:
@ -41,13 +41,13 @@ weight: 40
1. Инициализация объектов узла для каждого сервера, которые контроллер получает через API облачного провайдера.
2. Аннотирование и маркировка объектов узла специфичной для облака информацией, такой как регион узла и доступные ему ресурсы (процессор, память и т.д.).
3. Получение имени хоста и сетевых адресов.
4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удлаяет объект узла из вашего Kubernetes кластера.
4. Проверка работоспособности узла. В случае, если узел перестает отвечать на запросы, этот контроллер проверяет с помощью API вашего облачного провайдера, был ли сервер деактивирован / удален / прекращен. Если узел был удален из облака, контроллер удаляет объект узла из вашего Kubernetes кластера.
Некоторые облачные провайдеры реализуют его разделение на контроллер узла и отдельный контроллер жизненного цикла узла.
### Контролер маршрута
### Контроллер маршрута
Контролер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом.
Контроллер маршрута отвечает за соответствующую настройку маршрутов в облаке, чтобы контейнеры на разных узлах кластера Kubernetes могли взаимодействовать друг с другом.
В зависимости от облачного провайдера, контроллер маршрута способен также выделять блоки IP-адресов для сети Pod-ов.
@ -61,7 +61,7 @@ weight: 40
### Контроллер узла {#authorization-node-controller}
Контроллер узла работает только с объектом узла. Он требует полного доступа для и изменения объектов узла.
Контроллер узла работает только с объектом узла. Он требует полного доступа на чтение и изменение объектов узла.
`v1/Node`:
@ -73,9 +73,9 @@ weight: 40
- Watch
- Delete
### Контролер маршрута {#authorization-route-controller}
### Контроллер маршрута {#authorization-route-controller}
Контролер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла.
Контроллер маршрута прослушивает создание объектов узла и соответствующим образом настраивает маршруты. Для этого требуется получить доступ к объектам узла.
`v1/Node`:
@ -99,7 +99,7 @@ weight: 40
### Другие {#authorization-miscellaneous}
Реализация ядра диспетчера облачных контроллеров требует доступ для создания создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts).
Реализация ядра диспетчера облачных контроллеров требует доступ для создания объектов событий, а для обеспечения безопасной работы требуется доступ к созданию сервисных учетных записей (ServiceAccounts).
`v1/Event`:
@ -111,7 +111,7 @@ weight: 40
- Create
The {{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так:
{{< glossary_tooltip term_id="rbac" text="RBAC" >}} ClusterRole для диспетчера облачных контроллеров выглядит так:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
@ -179,7 +179,7 @@ rules:
## {{% heading "whatsnext" %}}
[Администрирование диспетчера облачных контроллеров](/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager)
содержит инструкции по запуску и управлению диспетером облачных контроллеров.
содержит инструкции по запуску и управлению диспетчером облачных контроллеров.
Хотите знать, как реализовать свой собственный диспетчер облачных контроллеров или расширить проект?

32
content/ru/docs/concepts/architecture/control-plane-node-communication.md
View File

@ -11,21 +11,21 @@ aliases:
<!-- overview -->
Этот документ каталог связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).
Этот документ описывает связь между плоскостью управления (apiserver) и кластером Kubernetes. Цель состоит в том, чтобы позволить пользователям настраивать свою установку для усиления сетевой конфигурации, чтобы кластер мог работать в ненадежной сети (или на полностью общедоступных IP-адресах облачного провайдера).
<!-- body -->
## Связь между плоскостью управления и узлом
В Kubernetes имеется API шаблон "hub-and-spoke". Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов плоскости управления не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS. (обычно 443) с одной или несколькими включенными формами [идентификации](/docs/reference/access-authn-authz/authentication/) клиена.
В Kubernetes имеется API шаблон «ступица и спица» (hub-and-spoke). Все используемые API из узлов (или которые запускают pod-ы) завершает apiserver. Ни один из других компонентов плоскости управления не предназначен для предоставления удаленных сервисов. Apiserver настроен на прослушивание удаленных подключений через безопасный порт HTTPS (обычно 443) с одной или несколькими включенными формами [аутентификации](/docs/reference/access-authn-authz/authentication/) клиента.
Должна быть включена одна или несколько форм [идентификации](/docs/reference/access-authn-authz/authorization/), особенно если разрешены [анонимные запросы](/docs/reference/access-authn-authz/authentication/#anonymous-requests) или [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
Должна быть включена одна или несколько форм [авторизации](/docs/reference/access-authn-authz/authorization/), особенно, если разрешены [анонимные запросы](/docs/reference/access-authn-authz/authentication/#anonymous-requests) или [ServiceAccount токены](/docs/reference/access-authn-authz/authentication/#service-account-tokens).
Узлы должны быть снабжены общедоступным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver-у вместе с действительными учетными данными клиента. Хороший подход заключается в том, что учетные данные клиента, предоставляемые kubelet, имеют форму клиентского сертификата. См. Информацию о загрузке Kubelet TLS [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) для автоматической подготовки клиентских сертификатов kubelet.
Узлы должны быть снабжены публичным корневым сертификатом для кластера, чтобы они могли безопасно подключаться к apiserver-у вместе с действительными учетными данными клиента. Хороший подход заключается в том, чтобы учетные данные клиента, предоставляемые kubelet-у, имели форму клиентского сертификата. См. Информацию о загрузке kubelet TLS [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) для автоматической подготовки клиентских сертификатов kubelet.
pod-ы, которые хотят подключиться к apiserver, могут сделать это безопасно, используя учетную запись службы, чтобы Kubernetes автоматически вводил общедоступный корневой сертификат и действительный токен-носитель в pod при его создании.
Служба `kubernetes` (в пространстве имен `default`) is настроен с виртуальным IP-адресом, который перенаправляет (через kube-proxy) к endpoint HTTPS apiserver-а.
Pod-ы, которые хотят подключиться к apiserver, могут сделать это безопасно, используя ServiceAccount, чтобы Kubernetes автоматически вводил общедоступный корневой сертификат и действительный токен-носитель в pod при его создании.
Служба `kubernetes` (в пространстве имен `default`) настроена с виртуальным IP-адресом, который перенаправляет (через kube-proxy) на HTTPS эндпоинт apiserver-а.
Компоненты уровня управления также взаимодействуют с кластером apiserver-а через защищенный порт.
@ -33,7 +33,7 @@ pod-ы, которые хотят подключиться к apiserver, мог
## Узел к плоскости управления
Существуют две пути взаимодействия от плоскости управления (apiserver) к узлам. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а.
Существуют два пути связи плоскости управления (apiserver) с узлами. Первый - от apiserver-а до kubelet процесса, который выполняется на каждом узле кластера. Второй - от apiserver к любому узлу, pod-у или службе через промежуточную функциональность apiserver-а.
### apiserver в kubelet
@ -43,21 +43,21 @@ pod-ы, которые хотят подключиться к apiserver, мог
* Прикрепление (через kubectl) к запущенным pod-ам.
* Обеспечение функциональности переадресации портов kubelet.
Эти соединения заверщаются в kubelet в endpoint HTTPS. По умолчанию apiserver не проверяет сертификат обслуживания kubelet-ов, что делает соединение подверженным к атаке человек по середине (man-in-the-middle) и **unsafe** запущенных в ненадежных или общедоступных сетях.
Эти соединения завершаются на HTTPS эндпоинте kubelet-a. По умолчанию apiserver не проверяет сертификат обслуживания kubelet-ов, что делает соединение подверженным к атаке «человек посередине» (man-in-the-middle) и **небезопасным** к запуску в ненадежных и/или общедоступных сетях.
Для проверки этого соединения, используется флаг `--kubelet-certificate-authority` чтобы предоставить apiserver-у набор корневых (root) сертификатов для проверки сертификата обслуживания kubelet-ов.
Для проверки этого соединения используется флаг `--kubelet-certificate-authority` чтобы предоставить apiserver-у набор корневых (root) сертификатов для проверки сертификата обслуживания kubelet-ов.
Если это не возможно, используйте [SSH-тунелирование](#ssh-tunnels) между apiserver-ом и kubelet, если это необходимо во избежании подключения по ненадежной или общедоступной сети.
Если это не возможно, используйте [SSH-тунелирование](#ssh-tunnels) между apiserver-ом и kubelet, если это необходимо, чтобы избежать подключения по ненадежной или общедоступной сети.
Наконец, Должны быть включены [пудентификация или авторизация Kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) для защиты kubelet API.
Наконец, должны быть включены [аутентификация или авторизация kubelet](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) для защиты kubelet API.
### apiserver для узлов, pod-ов, и служб
Соединение с apiserver-ом к узлу, pod-у или службе по умолчанию осушествяляется по обычному HTTP-соединению и поэтому не проходят проверку подлиности и не шифрование. Они могут быть запущены по защищенному HTTPS-соединению, добавив префикс `https:` к имени узла, pod-а или службы в URL-адресе API, но они не будут проверять сертификат предоставленный HTTPS endpoint, также не будут предоставлять учетные данные клиента. Таким образом, хотя соединение будет зашифровано, оно не обеспечит никаких гарантий целостности. Эти соединения **are not currently safe** запущенных в ненадежных или общедоступных сетях.
Соединения с apiserver к узлу, поду или сервису по умолчанию осуществляются по-обычному HTTP-соединению и поэтому не аутентифицируются, и не шифруются. Они могут быть запущены по защищенному HTTPS-соединению, после добавления префикса `https:` к имени узла, пода или сервиса в URL-адресе API, но они не будут проверять сертификат предоставленный HTTPS эндпоинтом, как и не будут предоставлять учетные данные клиента. Таким образом, хотя соединение будет зашифровано, оно не обеспечит никаких гарантий целостности. Эти соединения **в настоящее время небезопасны** для запуска в ненадежных или общедоступных сетях.
### SSH-тунели
### SSH-туннели
Kubernetes поддерживает SSH-туннели для защиты плоскости управления узлов от путей связи. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафикпредназначенный для kubelet, узлу, pod-у или службе через тунель. Этот тунель гарантирует, что трафик не выводиться за пределы сети, в которой работает узел.
Kubernetes поддерживает SSH-туннели для защиты плоскости управления узлов от путей связи. В этой конфигурации apiserver инициирует SSH-туннель для каждого узла в кластере (подключается к ssh-серверу, прослушивая порт 22) и передает весь трафик предназначенный для kubelet, узлу, pod-у или службе через туннель. Этот туннель гарантирует, что трафик не выводится за пределы сети, в которой работает узел.
SSH-туннели в настоящее время устарели, поэтому вы не должны использовать их, если не знаете, что делаете. Служба подключения является заменой этого канала связи.
@ -65,6 +65,6 @@ SSH-туннели в настоящее время устарели, поэто
{{< feature-state for_k8s_version="v1.18" state="beta" >}}
В качестве замены SSH-туннелям, служба подключения обеспечивает уровень полномочие TCP для плоскости управления кластерной связи. Служба подключения состоит из двух частей: сервер подключения в сети плоскости управления и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с плоскости управления на узлы проходит через эти соединения.
В качестве замены SSH-туннелям, служба подключения обеспечивает уровень полномочия TCP для плоскости управления кластерной связи. Служба подключения состоит из двух частей: сервер подключения к сети плоскости управления и агентов подключения в сети узлов. Агенты службы подключения инициируют подключения к серверу подключения и поддерживают сетевое подключение. После включения службы подключения, весь трафик с плоскости управления на узлы проходит через эти соединения.
Следуйте инструкциям [Задача службы подключения](/docs/tasks/extend-kubernetes/setup-konnectivity/) чтобы настроить службу подключения в кластере.
Следуйте инструкциям [Задача службы подключения,](/docs/tasks/extend-kubernetes/setup-konnectivity/) чтобы настроить службу подключения в кластере.

26
content/ru/docs/concepts/architecture/controller.md
View File

@ -10,8 +10,8 @@ weight: 30
Вот один из примеров контура управления: термостат в помещении.
Когда вы устанавливаете температуру, это говорит термостату о вашем *желаемом состоянии*. Фактическая температура в помещении - это
*текущее состояние*. Термостат действует так, чтобы приблизить текущее состояние к елаемому состоянию, путем включения или выключения оборудования.
Когда вы устанавливаете температуру, это говорит термостату о вашем *желаемом состоянии*. Фактическая температура в помещении - это
*текущее состояние*. Термостат действует так, чтобы приблизить текущее состояние к желаемому состоянию, путем включения или выключения оборудования.
{{< glossary_definition term_id="controller" length="short">}}
@ -27,7 +27,7 @@ weight: 30
имеют поле спецификации, которое представляет желаемое состояние. Контроллер (ы) для этого ресурса несут ответственность за приближение текущего состояния к желаемому состоянию
Контроллер может выполнить это действие сам; чаще всего в Kubernetes,
контроллер будет отправляет сообщения на
контроллер отправляет сообщения на
{{< glossary_tooltip text="сервер API" term_id="kube-apiserver" >}} которые имеют
полезные побочные эффекты. Пример этого вы можете увидеть ниже.
@ -40,7 +40,7 @@ weight: 30
Контроллер {{< glossary_tooltip term_id="job" >}} является примером встроенного контроллера Kubernetes. Встроенные контроллеры управляют состоянием, взаимодействуя с кластером сервера API.
Задание - это ресурс Kubernetes, который запускает
{{< glossary_tooltip term_id="pod" >}}, или возможно несколько Pod-ов, которые выполняют задание и затем останавливаются.
{{< glossary_tooltip term_id="pod" >}}, или возможно несколько Pod-ов, выполняющих задачу и затем останавливающихся.
(После [планирования](/docs/concepts/scheduling-eviction/), Pod объекты становятся частью желаемого состояния для kubelet).
@ -50,9 +50,9 @@ weight: 30
{{< glossary_tooltip text="плоскости управления" term_id="control-plane" >}}
действуют на основе информации (имеются ли новые запланированные Pod-ы для запуска), и в итоге работа завершается.
После того, как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этого задания к желаемому состоянию: создает Pod-ы, которые выполняют работу, которую вы хотели для этого задания, чтобы задание было ближе к завершению.
После того как вы создадите новое задание, желаемое состояние для этого задания будет завершено. Контроллер задания приближает текущее состояние этой задачи к желаемому состоянию: создает Pod-ы, выполняющие работу, которую вы хотели для этой задачи, чтобы задание было ближе к завершению.
Контроллеры также обровляют объекты которые их настраивают.
Контроллеры также обновляют объекты которые их настраивают.
Например: как только работа выполнена для задания, контроллер задания обновляет этот объект задание, чтобы пометить его как `Завершенный`.
(Это немного похоже на то, как некоторые термостаты выключают свет, чтобы указать, что теперь ваша комната имеет установленную вами температуру).
@ -66,20 +66,20 @@ weight: 30
Контроллеры, которые взаимодействуют с внешним состоянием, находят свое желаемое состояние с сервера API, а затем напрямую взаимодействуют с внешней системой, чтобы приблизить текущее состояние.
(На самом деле существует [контроллер](https://github.com/kubernetes/autoscaler/), который горизонтально маштабирует узлы в вашем кластере.)
(На самом деле существует [контроллер](https://github.com/kubernetes/autoscaler/), который горизонтально масштабирует узлы в вашем кластере.)
Важным моментом здесь является то, что контроллер вносит некоторые изменения, чтобы вызвать желаемое состояние, а затем сообщает текущее состояние обратно на сервер API вашего кластера. Другие контуры управления могут наблюдать за этими отчетными данными и предпринимать собственные действия.
В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes, плоскость управления косвенно работает с инструментами управления IP-адресами,службами хранения данных, API облочных провайдеров и другими службами для релизации
В примере с термостатом, если в помещении очень холодно, тогда другой контроллер может также включить обогреватель для защиты от замерзания. В кластерах Kubernetes, плоскость управления косвенно работает с инструментами управления IP-адресами, службами хранения данных, API облачных провайдеров и другими службами для реализации
[расширения Kubernetes](/docs/concepts/extend-kubernetes/).
## Желаемое против текущего состояния {#desired-vs-current}
Kubernetes использует систему вида cloud-native и способен справлятся с постоянными изменениями.
Kubernetes использует систему вида cloud-native и способен справляться с постоянными изменениями.
Ваш кластер может изменяться в любой по мере выполнения работы и контуры управления автоматически устранают сбой. Это означает, что потенциально Ваш кластер никогда не достигнет стабильного состояния.
Ваш кластер может изменяться в любой по мере выполнения работы и контуры управления автоматически устраняют сбой. Это означает, что потенциально Ваш кластер никогда не достигнет стабильного состояния.
Пока контроллеры вашего кластера работают и могут вносить полезные изменения, не имеет значения, является ли общее состояние стабильным или нет.
Пока контроллеры вашего кластера работают и могут вносить полезные изменения, не имеет значения, является ли общее состояние стабильным или нет.
## Дизайн
@ -90,7 +90,7 @@ Kubernetes использует систему вида cloud-native и спос
{{< note >}}
Существует несколько контроллеров, которые создают или обновляют один и тот же тип объекта. За кулисами контроллеры Kubernetes следят за тем, чтобы обращать внимание только на ресурсы, связанные с их контролирующим ресурсом.
Например, у вас могут быть развертывания и задания; они оба создают Pod-ы. Контроллер заданий не удаляет Pod-ы созданные вашим развертиыванием, потому что имеется информационные ({{< glossary_tooltip term_id="label" text="метки" >}})
Например, у вас могут быть развертывания и задания; они оба создают Pod-ы. Контроллер заданий не удаляет Pod-ы созданные вашим развертыванием, потому что имеется информационные ({{< glossary_tooltip term_id="label" text="метки" >}})
которые могут быть использованы контроллерами тем самым показывая отличие Pod-ов.
{{< /note >}}
@ -102,7 +102,7 @@ Kubernetes поставляется с набором встроенных ко
Kubernetes позволяет вам запускать устойчивую плоскость управления, так что в случае отказа одного из встроенных контроллеров работу берет на себя другая часть плоскости управления.
Вы можете найти контроллеры, которые работают вне плоскости управления, чтобы расширить Kubernetes.
Или, если вы хотите, можете написать новый контроллер самостоятельно. Вы можете запустить свой собственный контроллер виде наборов Pod-ов,
Или, если вы хотите, можете написать новый контроллер самостоятельно. Вы можете запустить свой собственный контроллер в виде наборов Pod-ов,
или внешнее в Kubernetes. Что подойдет лучше всего, будет зависеть от того, что делает этот конкретный контроллер.

36
content/ru/docs/concepts/architecture/garbage-collection.md
View File

@ -23,7 +23,7 @@ weight: 50
Многие объекты в Kubernetes ссылаются друг на друга через [*ссылки владельцев*](/docs/concepts/overview/working-with-objects/owners-dependents/).
Ссылки владельцев сообщают плоскости управления какие объекты зависят от других.
Kubernetes использует ссылки владельцев, чтобы предоставить плоскости управления и другим API
клиентам, возможность очистить связанные ресурсы передудалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев.
клиентам, возможность очистить связанные ресурсы перед удалением объекта. В большинстве случаев, Kubernetes автоматический управляет ссылками владельцев.
Владелец отличается от [меток и селекторов](/docs/concepts/overview/working-with-objects/labels/)
которые также используют некоторые ресурсы. Например, рассмотрим
@ -36,15 +36,15 @@ Kubernetes использует ссылки владельцев, чтобы п
{{< note >}}
Ссылки на владельцев перекрестных пространств имен запрещены по дизайну.
Зависимости пространства имен могут указывать на область действия кластера или владельцев пространства имен.
Владелец пространства имен **должен** быть в том же пространстве имен что и зависимости.
Если это не возможно, cсылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
Владелец пространства имен **должен** быть в том же пространстве имен, что и зависимости.
Если это не возможно, ссылка владельца считается отсутствующей и зависимый объект подлежит удалению, как только будет проверено отсутствие всех владельцев.
Зависимости области действия кластер может указывать только владельцев области действия кластера.
В версии v1.20+, если зависимость с областью действия кластера указывает на пространство имен как владелец,
тогда он рассматривается как имеющий неразрешимую ссылку на владельца и не может быть обработан сборщиком мусора.
В версии v1.20+, если сборщик мусора обнаружит недопустимое перекрестное пространство имен `ownerReference`,
или зависящие от облости действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающеся о не действительной зависимости.
или зависящие от области действия кластера `ownerReference` ссылка на тип пространства имен, предупреждающее событие с причиной `OwnerRefInvalidNamespace` и `involvedObject` сообщающее о недействительной зависимости.
Вы можете проверить наличие такого рода событий, выполнив `kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
{{< /note >}}
@ -52,22 +52,22 @@ Kubernetes использует ссылки владельцев, чтобы п
Kubernetes проверяет и удаляет объекты, на которые больше нет ссылок владельцев, так же как и pod-ов, оставленных после удаления ReplicaSet. Когда Вы удаляете объект, вы можете контролировать автоматический ли Kubernetes удаляет зависимые объекты автоматически в процессе вызова *каскадного удаления*. Существует два типа каскадного удаления, а именно:
* Каскадное удалени Foreground
* Каскадное удаление Foreground
* Каскадное удаление Background
Вы так же можете управлять как и когда сборщик мусора удаляет ресурсы, на которые ссылаются владельцы с помощью Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}.
### Каскадное удалени Foreground {#foreground-deletion}
### Каскадное удаление Foreground {#foreground-deletion}
В Каскадном удалени Foreground, объект владельца, который вы удаляете, сначало переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее:
В Каскадном удалении Foreground, объект владельца, который вы удаляете, сначала переходить в состояние *в процессе удаления*. В этом состоянии с объектом-владельцем происходить следующее:
* Сервер Kubernetes API устанавливает полю объекта `metadata.deletionTimestamp`
время, когда объект был помечен для удаления.
* Сервер Kubernetes API так же устанавливает метку `metadata.finalizers`для поля
`foregroundDeletion`.
* Объект остается видимым блогодоря Kubernetes API пока процесс удаления не завершиться
* Объект остается видимым благодаря Kubernetes API пока процесс удаления не завершиться
После того, как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API.
После того как владелец объекта переходит в состояние прогресса удаления, контроллер удаляет зависимые объекты. После удаления всех зависимых объектов, контроллер удаляет объект владельца. На этом этапе, объект больше не отображается в Kubernetes API.
Во время каскадного удаления foreground, единственным зависимым, которые блокируют удаления владельца, являются те, у кого имеется поле `ownerReference.blockOwnerDeletion=true`.
Чтобы узнать больше. Смотрите [Использование каскадного удаления foreground](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion).
@ -80,16 +80,16 @@ Kubernetes проверяет и удаляет объекты, на котор
### Осиротевшие зависимости
Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшыми* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это повидение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
Когда Kubernetes удаляет владельца объекта, оставшиеся зависимости называются *осиротевшими* объектами. По умолчанию, Kubernetes удаляет зависимые объекты. Чтобы узнать, как переопределить это поведение смотрите [Удаление объектов владельца и осиротевших зависимостей](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
## Сбор мусора из неиспользуемых контейнеров и изобробразов {#containers-images}
## Сбор мусора из неиспользуемых контейнеров и изображений {#containers-images}
{{<glossary_tooltip text="kubelet" term_id="kubelet">}} выполняет сбор мусора для неиспользуемых образов каждые пять минут и для неиспользуемых контейнеров каждую минуту. Вам следует избегать использования внешних инструментов для сборки мусора, так как они могут
нарушить поведение kubelet и удалить контейнеры, которые должны существовать.
Чтобы настроить параметры для сборшика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте
Чтобы настроить параметры для сборщика мусора для неиспользуемого контейнера и сборки мусора образа, подстройте
kubelet использую [конфигурационный файл](/docs/tasks/administer-cluster/kubelet-config-file/)
и измените параметры, связанные со сборшиком мусора используя тип ресурса
и измените параметры, связанные со сборщиком мусора используя тип ресурса
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration).
### Жизненный цикл контейнерных образов Container image lifecycle
@ -99,19 +99,19 @@ Kubernetes управляет жизненным циклом всех обра
* `HighThresholdPercent`
* `LowThresholdPercent`
Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. kubelet удлаяет образы до тех пор, пока использование диска не достигнет значения `LowThresholdPercent`.
Использование диска выше настроенного значения `HighThresholdPercent` запускает сборку мусора, которая удаляет образы в порядке основанном на последнем использовании, начиная с самого старого. Kubelet удаляет образы до тех пор, пока использование диска не достигнет значения `LowThresholdPercent`.
### Сборщик мусора контейнерных образов {#container-image-garbage-collection}
kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить:
Kubelet собирает не используемые контейнеры на основе следующих переменных, которые вы можете определить:
* `MinAge`: минимальный возраст, при котором kubelet может начать собирать мусор контейнеров. Отключить, установив значение `0`.
* `MaxPerPodContainer`: максимальное количество некативныз контейнеров, которое может быть у каджой пары Pod-ов. Отключить, установив значение меньше чем `0`.
* `MaxPerPodContainer`: максимальное количество неактивных контейнеров, которое может быть у каждой пары Pod-ов. Отключить, установив значение меньше чем `0`.
* `MaxContainers`: максимальное количество не используемых контейнеров, которые могут быть в кластере. Отключить, установив значение меньше чем `0`.
В дополнение к этим переменным, kubelet собирает неопознанные и удаленные контейнеры, обычно начиная с самого старого.
`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры.
`MaxPerPodContainer` и `MaxContainer` могут потенциально конфликтовать друг с другом в ситуациях, когда требуется максимальное количество контейнеров в Pod-е (`MaxPerPodContainer`) выйдет за пределы допустимого общего количества глобальных не используемых контейнеров (`MaxContainers`). В этой ситуации kubelet регулирует `MaxPodPerContainer` для устранения конфликта. Наихудшим сценарием было бы понизить `MaxPerPodContainer` да `1` и изгнать самые старые контейнеры.
Кроме того, владельцы контейнеров в pod-е могут быть удалены, как только они становятся старше чем `MinAge`.
{{<note>}}
@ -120,7 +120,7 @@ Kubelet собирает мусор только у контейнеров, ко
## Настройка сборщик мусора {#configuring-gc}
Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показанно, как настроить сборку мусора:
Вы можете настроить сборку мусора ресурсов, настроив параметры, специфичные для контроллеров, управляющих этими ресурсами. В последующих страницах показано, как настроить сборку мусора:
* [Настройка каскадного удаления объектов Kubernetes](/docs/tasks/administer-cluster/use-cascading-deletion/)
* [Настройка очистки завершенных заданий](/docs/concepts/workloads/controllers/ttlafterfinished/)

54
content/ru/docs/concepts/architecture/nodes.md
View File

@ -32,7 +32,7 @@ Kubernetes запускает ваши приложения, помещая ко
1. Kubelet на узле саморегистрируется в плоскости управления
2. Вы или другой пользователь вручную добавляете объект Узла
После того, как вы создадите объект Узла или kubelet на узле самозарегистируется,
После того как вы создадите объект Узла или kubelet на узле самозарегистируется,
плоскость управления проверяет, является ли новый объект Узла валидным (правильным). Например, если вы
попробуете создать Узел при помощи следующего JSON манифеста:
@ -50,9 +50,9 @@ Kubernetes запускает ваши приложения, помещая ко
```
Kubernetes создает внутри себя объект Узла (представление). Kubernetes проверяет,
что kubelet зарегистрировался на API сервере, который совпадает с значением поля `metadata.name` Узла.
что kubelet зарегистрировался на API сервере, который совпадает со значением поля `metadata.name` Узла.
Если узел здоров (если все необходимые сервисы запущены),
он имеет право на запуск Пода. В противном случае, этот узел игнорируется для любой активности кластера
он имеет право на запуск Пода. В противном случае этот узел игнорируется для любой активности кластера
до тех пор, пока он не станет здоровым.
{{< note >}}
@ -62,13 +62,13 @@ Kubernetes сохраняет объект для невалидного Узл
остановить проверку доступности узла.
{{< /note >}}
Имя объекта Узла дожно быть валидным
Имя объекта Узла должно быть валидным
[именем поддомена DNS](/ru/docs/concepts/overview/working-with-objects/names#имена-поддоменов-dns).
### Саморегистрация Узлов
Когда kubelet флаг `--register-node` имеет значение _true_ (по умолчанию), то kubelet будет пытаться
зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большиством дистрибутивов.
зарегистрировать себя на API сервере. Это наиболее предпочтительная модель, используемая большинством дистрибутивов.
Для саморегистрации kubelet запускается со следующими опциями:
@ -94,16 +94,16 @@ kubelet'ы имеют право только создавать/изменят
Когда вы хотите создать объекты Узла вручную, установите kubelet флаг `--register-node=false`.
Вы можете изменять объекты Узла независимо от настройки `--register-node`.
Например, вы можете установить метки на существующем Узле или пометить его неназначаемым.
Например, вы можете установить метки на существующем Узле или пометить его не назначаемым.
Вы можете использовать метки на Узлах в сочетании с селекторами узла на Подах для управления планированием.
Например, вы можете ограничить Под иметь право на запуск только на группе доступных узлов.
Например, вы можете ограничить Под, иметь право на запуск только на группе доступных узлов.
Маркировка узла как неназначаемого предотвращает размещение планировщиком новых подов на этом Узле,
Маркировка узла как не назначаемого предотвращает размещение планировщиком новых подов на этом Узле,
но не влияет на существующие Поды на Узле. Это полезно в качестве
подготовительного шага перед перезагрузкой узла или другим обслуживанием.
Чтобы отметить Узел неназначемым, выполните:
Чтобы отметить Узел не назначаемым, выполните:
```shell
kubectl cordon $NODENAME
@ -111,7 +111,7 @@ kubectl cordon $NODENAME
{{< note >}}
Поды, являющиеся частью {{< glossary_tooltip term_id="daemonset" >}} допускают
запуск на неназначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла,
запуск на не назначаемом Узле. DaemonSets обычно обеспечивает локальные сервисы узла,
которые должны запускаться на Узле, даже если узел вытесняется для запуска приложений.
{{< /note >}}
@ -157,7 +157,7 @@ kubectl describe node <insert-node-name-here>
{{< note >}}
Если вы используете инструменты командной строки для вывода сведений об блокированном узле,
то Условие включает `SchedulingDisabled`. `SchedulingDisabled` не является Условием в Kubernetes API;
вместо этого блокированные узлы помечены как Неназначемые в их спецификации.
вместо этого блокированные узлы помечены как Не назначаемые в их спецификации.
{{< /note >}}
Состояние узла представлено в виде JSON объекта. Например, следующая структура описывает здоровый узел:
@ -203,8 +203,8 @@ kubectl describe node <insert-node-name-here>
Описывает ресурсы, доступные на узле: CPU, память и максимальное количество подов,
которые могут быть запланированы на узле.
Поля в блоке capasity указывают общее количество ресурсов, которые есть на Узле.
Блок allocatable указывает количество ресурсовна Узле,
Поля в блоке capacity указывают общее количество ресурсов, которые есть на Узле.
Блок allocatable указывает количество ресурсов на Узле,
которые доступны для использования обычными Подами.
Вы можете прочитать больше о емкости и выделяемых ресурсах, изучая, как [зарезервировать вычислительные ресурсы](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) на Узле.
@ -212,7 +212,7 @@ kubectl describe node <insert-node-name-here>
### Информация (Info)
Описывает общую информацию об узле, такую как версия ядра, версия Kubernetes (версии kubelet и kube-proxy), версия Docker (если используется) и название ОС.
Эта информация соберается Kubelet'ом на узле.
Эта информация собирается Kubelet'ом на узле.
### Контроллер узла
@ -247,16 +247,16 @@ ConditionUnknown, когда узел становится недоступны
[Lease объект](/docs/reference/generated/kubernetes-api/{{< latest-version >}}/#lease-v1-coordination-k8s-io).
Каждый узел имеет связанный с ним Lease объект в `kube-node-lease`
{{< glossary_tooltip term_id="namespace" text="namespace">}}.
Lease - это легковестный ресурс, который улучшает производительность
Lease - это легковесный ресурс, который улучшает производительность
сердцебиений узла при масштабировании кластера.
Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта.
Kubelet отвечает за создание и обновление `NodeStatus` и Lease объекта.
- Kubelet обновляет `NodeStatus` либо когда происходит изменение статуса,
либо если в течение настронного интервала обновления не было. По умолчанию
либо если в течение настроенного интервала обновления не было. По умолчанию
интервал для обновлений `NodeStatus` составляет 5 минут (намного больше,
чем 40-секундный стандартный таймаут для недоступных узлов).
- Kubelet созадет и затем обновляет свой Lease объект каждый 10 секунд
- Kubelet создает и затем обновляет свой Lease объект каждый 10 секунд
(интервал обновления по умолчанию). Lease обновления происходят независимо от
`NodeStatus` обновлений. Если обновление Lease завершается неудачно,
kubelet повторяет попытку с экспоненциальным откатом, начинающимся с 200 миллисекунд и ограниченным 7 секундами.
@ -265,7 +265,7 @@ Kubelet отвечает за создание и обновление `NodeStat
В большинстве случаев контроллер узла ограничивает скорость выселения
до `--node-eviction-rate` (по умолчанию 0,1) в секунду, что означает,
что он не выселяет поды с узлов быстрее чем c 1 узела в 10 секунд.
что он не выселяет поды с узлов быстрее чем с одного узла в 10 секунд.
Поведение выселения узла изменяется, когда узел в текущей зоне доступности
становится нездоровым. Контроллер узла проверяет, какой процент узлов в зоне
@ -288,26 +288,26 @@ Kubelet отвечает за создание и обновление `NodeStat
выселяет поды с нормальной скоростью `--node-eviction-rate`. Крайний случай - когда все зоны
полностью нездоровы (т.е. в кластере нет здоровых узлов). В таком случае
контроллер узла предполагает, что существует некоторая проблема с подключением к мастеру,
и останавеливает все выселения, пока какое-нибудь подключение не будет восстановлено.
и останавливает все выселения, пока какое-нибудь подключение не будет восстановлено.
Контроллер узла также отвечает за выселение подов, запущенных на узлах с
`NoExecute` ограничениями, за исключением тех подов, которые сопротивляются этим ограничениям.
Контроллер узла так же добавляет {{< glossary_tooltip text="ограничения" term_id="taint" >}}
соотвествующие проблемам узла, таким как узел недоступен или не готов. Это означает,
соответствующие проблемам узла, таким как узел недоступен или не готов. Это означает,
что планировщик не будет размещать поды на нездоровых узлах.
{{< caution >}}
`kubectl cordon` помечает узел как 'неназначемый', что имеет побочный эфект от контроллера сервисов,
`kubectl cordon` помечает узел как 'не назначаемый', что имеет побочный эффект от контроллера сервисов,
удаляющего узел из любых списков целей LoadBalancer узла, на которые он ранее имел право,
эффектино убирая входящий трафик балансировщика нагрузки с блокированного узла(ов).
эффективно убирая входящий трафик балансировщика нагрузки с блокированного узла(ов).
{{< /caution >}}
### Емкость узла
Объекты узла отслеживают информацию о емкости ресурсов узла (например,
объем доступной памяти и количество CPU).
Узлы, которые [самостоятельно зарегистировались](#саморегистрация-узлов) сообщают
о свое емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла)
Узлы, которые [самостоятельно зарегистрировались](#саморегистрация-узлов), сообщают
о своей емкости во время регистрации. Если вы [вручную](#ручное-администрирование-узла)
добавляете узел, то вам нужно задать информацию о емкости узла при его добавлении.
{{< glossary_tooltip text="Планировщик" term_id="kube-scheduler" >}} Kubernetes гарантирует,
@ -318,7 +318,7 @@ Kubelet отвечает за создание и обновление `NodeStat
а также исключает любые процессы, запущенные вне контроля kubelet.
{{< note >}}
Если вы явно хотите зарезервировать ресурсы для процессов, не связанныз с Подами, смотрите раздел
Если вы явно хотите зарезервировать ресурсы для процессов, не связанных с Подами, смотрите раздел
[зарезервировать ресурсы для системных демонов](/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved).
{{< /note >}}
@ -339,4 +339,4 @@ Kubelet отвечает за создание и обновление `NodeStat
* Подробнее про [Узлы](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node)
of the architecture design document.
* Подробнее про [ограничения и допуски](/docs/concepts/configuration/taint-and-toleration/).
* Подробнее про [автомаштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).
* Подробнее про [авто масштабирование кластера](/docs/tasks/administer-cluster/cluster-management/#cluster-autoscaling).

20
content/ru/docs/concepts/cluster-administration/_index.md
View File

@ -11,7 +11,7 @@ no_list: true
---
<!-- overview -->
Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями] (/docs/concepts/) Kubernetes.
Обзор администрирования кластера предназначен для всех, кто создает или администрирует кластер Kubernetes. Это предполагает некоторое знакомство с основными [концепциями](/docs/concepts/) Kubernetes.
<!-- body -->
@ -19,19 +19,19 @@ no_list: true
См. Руководства в разделе [настройка](/docs/setup/) для получения примеров того, как планировать, устанавливать и настраивать кластеры Kubernetes. Решения, перечисленные в этой статье, называются *distros*.
{{< note >}}
{{< note >}}
не все дистрибутивы активно поддерживаются. Выбирайте дистрибутивы, протестированные с последней версией Kubernetes.
{{< /note >}}
Прежде чем выбрать руководство, вот некоторые соображения:
- Вы хотите опробовать Kubernetes на вашем компьюторе или собрать многоузловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд.
- будете ли вы использовать **размещенный кластер Kubernetes**, такой как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**?
- Будет ли ваш кластер **в помещений** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров.
- **Если вы будете настроаивать Kubernetes в помещений (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего.
- Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **вирутальных машинах (VMs)**?
- Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают болле широкий выбор.
- Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходивые для запуска кластера.
- Вы хотите опробовать Kubernetes на вашем компьютере или собрать много узловой кластер высокой доступности? Выбирайте дистрибутивы, наиболее подходящие для ваших нужд.
- Будете ли вы использовать **размещенный кластер Kubernetes**, такой, как [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/) или **разместите собственный кластер**?
- Будет ли ваш кластер **в помещении** или **в облаке (IaaS)**? Kubernetes не поддерживает напрямую гибридные кластеры. Вместо этого вы можете настроить несколько кластеров.
- **Если вы будете настраивать Kubernetes в помещении (локально)**, подумайте, какая [сетевая модель](/docs/concepts/cluster-administration/networking/) подходит лучше всего.
- Будете ли вы запускать Kubernetes на **оборудований "bare metal"** или на **виртуальных машинах (VMs)**?
- Вы хотите **запустить кластер** или планируете **активно разворачивать код проекта Kubernetes**? В последнем случае выберите активно разрабатываемый дистрибутив. Некоторые дистрибутивы используют только двоичные выпуски, но предлагают более широкий выбор.
- Ознакомьтесь с [компонентами](/docs/concepts/overview/components/) необходимые для запуска кластера.
## Управление кластером
@ -54,7 +54,7 @@ no_list: true
* [Использование контроллеров допуска](/docs/reference/access-authn-authz/admission-controllers/) explains plug-ins which intercepts requests to the Kubernetes API server after authentication and authorization.
* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctlинструмент командной строки для установки параметров ядра.
* [Использование Sysctls в кластере Kubernetes](/docs/tasks/administer-cluster/sysctl-cluster/) описывает администратору, как использовать sysctl инструмент командной строки для установки параметров ядра.
* [Аудит](/docs/tasks/debug-application-cluster/audit/) описывает, как взаимодействовать с журналами аудита Kubernetes.

26
content/ru/docs/concepts/cluster-administration/addons.md
View File

@ -13,33 +13,33 @@ content_type: concept
<!-- body -->
## Сеть и сетевыя политика
## Сеть и сетевая политика
* [ACI](https://www.github.com/noironetworks/aci-containers) обеспечивает интегрированную сеть контейнеров и сетевую безопасность с помощью Cisco ACI.
* [Antrea](https://antrea.io/) работает на уровне 3, обеспечивая сетевые службы и службы безопасности для Kubernetes, используя Open vSwitch в качестве уровня сетевых данных.
* [Calico](https://docs.projectcalico.org/latest/introduction/) Calico поддерживает гибкий набор сетевых опций, поэтому вы можете выбрать наиболее эффективный вариант для вашей ситуации, включая сети без оверлея и оверлейные сети, с или без BGP. Calico использует тот же механизм для обеспечения соблюдения сетевой политики для хостов, модулей и (при использовании Istio и Envoy) приложений на уровне сервисной сети (mesh layer).
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политик.
* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) объединяет Flannel и Calico, обеспечивая сеть и сетевую политику.
* [Cilium](https://github.com/cilium/cilium) - это плагин сети L3 и сетевой политики, который может прозрачно применять политики HTTP/API/L7. Поддерживаются как режим маршрутизации, так и режим наложения/инкапсуляции, и он может работать поверх других подключаемых модулей CNI.
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) позволяет Kubernetes легко подключаться к выбору плагинов CNI, таких как Calico, Canal, Flannel, Romana или Weave.
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric are интегрированы с системами оркестровки, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/pod-ов и рабочих нагрузок без операционной системы.
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), основан на [Tungsten Fabric](https://tungsten.io), представляет собой платформу для виртуализации мультиоблачных сетей с открытым исходным кодом и управления политиками. Contrail и Tungsten Fabric интегрированы с системами оркестрации, такими как Kubernetes, OpenShift, OpenStack и Mesos, и обеспечивают режимы изоляции для виртуальных машин, контейнеров/подов и рабочих нагрузок без операционной системы.
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) - это поставщик оверлейной сети, который можно использовать с Kubernetes.
* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes pod-ов.
* Multus - это плагин Multi для поддержки нексольких сетейв Kubernetes для поддержки всех CNI плагинов (наприме: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes.
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуалной сети a появившейся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS.
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложеных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами.
* [Knitter](https://github.com/ZTE/Knitter/) - это плагин для поддержки нескольких сетевых интерфейсов Kubernetes подов.
* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) - это плагин Multi для работы с несколькими сетями в Kubernetes, который поддерживает большинство самых популярных [CNI](https://github.com/containernetworking/cni) (например: Calico, Cilium, Contiv, Flannel), в дополнение к рабочим нагрузкам основанных на SRIOV, DPDK, OVS-DPDK и VPP в Kubernetes.
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) - это сетевой провайдер для Kubernetes основанный на [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), реализация виртуальной сети, появившийся в результате проекта Open vSwitch (OVS). OVN-Kubernetes обеспечивает сетевую реализацию на основе наложения для Kubernetes, включая реализацию балансировки нагрузки и сетевой политики на основе OVS.
* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) - это подключаемый модуль контроллера CNI на основе OVN для обеспечения облачной цепочки сервисных функций (SFC), несколько наложенных сетей OVN, динамического создания подсети, динамического создания виртуальных сетей, сети поставщика VLAN, сети прямого поставщика и подключаемого к другим Multi Сетевые плагины, идеально подходящие для облачных рабочих нагрузок на периферии в сети с несколькими кластерами.
* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) плагин для контейнера (NCP) обеспечивающий интеграцию между VMware NSX-T и контейнерами оркестраторов, таких как Kubernetes, а так же интеграцию между NSX-T и контейнеров на основе платформы CaaS/PaaS, таких как Pivotal Container Service (PKS) и OpenShift.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes Pod-ами и не Kubernetes окружением с отображением и мониторингом безопасности.
* [Romana](https://romana.io) - это сетевое решение уровня 3 для pod сетей, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) обеспечивает сетевуюи политику сетей, будет работать в сетевого раздела и не требует внешней базы данных.
* [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) - эта платформа SDN, которая обеспечивает сетевое взаимодействие на основе политик между Kubernetes подами и не Kubernetes окружением, с отображением и мониторингом безопасности.
* [Romana](https://romana.io) - это сетевое решение уровня 3 для сетей подов, которое также поддерживает [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Подробности установки Kubeadm доступны [здесь](https://github.com/romana/romana/tree/master/containerize).
* [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) предоставляет сеть и обеспечивает сетевую политику, будет работать на обеих сторонах сетевого раздела и не требует внешней базы данных.
## Обнаружение служб
* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для pod-ов.
* [CoreDNS](https://coredns.io) - это гибкий, расширяемый DNS-сервер, который может быть [установлен](https://github.com/coredns/deployment/tree/master/kubernetes) в качестве внутрикластерного DNS для подов.
## Визуализация и контроль
* [Dashboard](https://github.com/kubernetes/dashboard#kubernetes-dashboard) - это веб-интерфейс панели инструментов для Kubernetes.
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, pod-ов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно.
* [Weave Scope](https://www.weave.works/documentation/scope-latest-installing/#k8s) - это инструмент для графической визуализации ваших контейнеров, подов, сервисов и т.д. Используйте его вместе с [учетной записью Weave Cloud](https://cloud.weave.works/) или разместите пользовательский интерфейс самостоятельно.
## Инфраструктура
@ -49,4 +49,4 @@ content_type: concept
В устаревшем каталоге [cluster/addons](https://git.k8s.io/kubernetes/cluster/addons) задокументировано несколько других дополнений.
Ссылки на те, в хорошем состоянии, должны быть здесь. PR приветствуются!
Ссылки на те, в хорошем состоянии, должны быть здесь. Пул реквесты приветствуются!

12
content/ru/docs/concepts/overview/kubernetes-api.md
View File

@ -36,7 +36,7 @@ Kubernetes как таковой состоит из множества комп
Все детали API документируется с использованием [OpenAPI](https://www.openapis.org/).
Начиная с Kubernetes 1.10, API-сервер Kubernetes основывается на спецификации OpenAPI через конечную точку `/openapi/v2`.
Нужный формат устанавливается через HTTP-заголовоки:
Нужный формат устанавливается через HTTP-заголовки:
Заголовок | Возможные значения
------ | ---------------
@ -61,11 +61,11 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
Чтобы упростить удаления полей или изменение ресурсов, Kubernetes поддерживает несколько версий API, каждая из которых доступна по собственному пути, например, `/api/v1` или `/apis/extensions/v1beta1`.
Мы выбрали версионирование API, а не конкретных ресурсов или полей, чтобы API отражал четкое и согласованное представление о системных ресурсах и их поведении, а также, чтобы разграничивать API, которые уже не поддерживаются и/или находятся в экспериментальной стадии. Схемы сериализации JSON и Protobuf следуют одним и тем же правилам по внесению изменений в схему, поэтому описание ниже охватывают оба эти формата.
Мы выбрали версионирование API, а не конкретных ресурсов или полей, чтобы API отражал четкое и согласованное представление о системных ресурсах и их поведении, а также, чтобы разграничивать API, которые уже не поддерживаются и/или находятся в экспериментальной стадии. Схемы сериализации JSON и Protobuf следуют одним и тем же правилам по внесению изменений в схему, поэтому описание ниже охватывают оба эти формата.
Обратите внимание, что версиоирование API и программное обеспечение косвенно связаны друг с другом. [Предложение по версионированию API и новых выпусков](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) описывает, как связаны между собой версии API с версиями программного обеспечения.
Обратите внимание, что версионирование API и программное обеспечение косвенно связаны друг с другом. [Предложение по версионированию API и новых выпусков](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) описывает, как связаны между собой версии API с версиями программного обеспечения.
Разные версии API имеют характеризуются разной уровнем стабильностью и поддержкой. Критерии каждого уровня более подробно описаны в [документации изменений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Ниже приводится краткое изложение:
Разные версии API характеризуются разными уровнями стабильности и поддержки. Критерии каждого уровня более подробно описаны в [документации изменений API](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). Ниже приводится краткое изложение:
- Альфа-версии:
- Названия версий включают надпись `alpha` (например, `v1alpha1`).
@ -79,7 +79,7 @@ GET /swagger-2.0.0.pb-v1.gz | GET /openapi/v2 **Accept**: application/com.github
- Поддержка функциональности в целом не будет прекращена, хотя кое-что может измениться.
- Схема и/или семантика объектов может стать несовместимой с более поздними бета-версиями или стабильными выпусками. Когда это случится, мы даем инструкции по миграции на следующую версию. Это обновление может включать удаление, редактирование и повторного создание API-объектов. Этот процесс может потребовать тщательного анализа. Кроме этого, это может привести к простою приложений, которые используют данную функциональность.
- Рекомендуется только для неосновного производственного использования из-за риска возникновения возможных несовместимых изменений с будущими версиями. Если у вас есть несколько кластеров, которые возможно обновить независимо, вы можете снять это ограничение.
- **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того, как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.**
- **Пожалуйста, попробуйте в действии бета-версии функциональности и поделитесь своими впечатлениями! После того как функциональность выйдет из бета-версии, нам может быть нецелесообразно что-то дальше изменять.**
- Стабильные версии:
- Имя версии `vX`, где `vX` — целое число.
- Стабильные версии функциональностей появятся в новых версиях.
@ -113,5 +113,3 @@ DaemonSets, Deployments, StatefulSet, NetworkPolicies, PodSecurityPolicies и Re
Например: чтобы включить deployments и daemonsets, используйте флаг `--runtime-config=extensions/v1beta1/deployments=true,extensions/v1beta1/daemonsets=true`.
{{< note >}}Включение/отключение отдельных ресурсов поддерживается только в API-группе `extensions/v1beta1` по историческим причинам.{{< /note >}}

76
content/ru/docs/contribute/advanced.md
View File

@ -1,5 +1,5 @@
---
title: Участие для опытных
title: Существенный вклад
slug: advanced
content_type: concept
weight: 30
@ -22,20 +22,20 @@ weight: 30
- Ежедневно проверять [открытые пулреквесты](https://github.com/kubernetes/website/pulls) для контроля качества и соблюдения рекомендаций по [оформлению](/docs/contribute/style/style-guide/) и [содержимому](/docs/contribute/style/content-guide/).
- В первую очередь просматривайте самые маленькие пулреквесты (`size/XS`), и только потом беритесь за самые большие (`size/XXL`).
- Проверяйте столько пулреквестов, сколько сможете.
- Проследить, что CLA подписан каждым участником.
- Проследите, что CLA подписан каждым участником.
- Помогайте новым участникам подписать [CLA](https://github.com/kubernetes/community/blob/master/CLA.md).
- Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, чтобы они подписали CLA.
- Используйте [этот](https://github.com/zparnold/k8s-docs-pr-botherer) скрипт, чтобы автоматически напомнить участникам, не подписавшим CLA, подписать его.
- Оставить свое мнение о предложенных изменениях и поспособствовать в проведении технического обзора от членов других SIG-групп.
- Предложить исправления для измененного контента в PR.
- Если вы хотите убедиться в правильности контента, прокомментируйте PR и задайте уточняющие вопросы.
- Добавьте нужны метки с `sig/`.
- Если нужно, то назначьте рецензентов из секции `reviewers:` в фронтальной части файла.
- Добавьте нужные метки с `sig/`.
- Если нужно, то назначьте рецензентов из секции `reviewers:` в верхней части файла.
- Добавьте метки `Docs Review` и `Tech Review` для установки статуса проверки PR.
- Добавьте метку `Needs Doc Review` или `Needs Tech Review` для пулреквестов, которые ещё не были проверены.
- Добавьте метку `Doc Review: Open Issues` или `Tech Review: Open Issues` для пулреквестов, которые были проверены и требуют дополнительную информацию и выполнение действия перед слиянием.
- Добавьте метки `/lgtm` и `/approve` для пулреквестов, которые могут быть приняты.
- Объедините пулреквесты, если они готовы, либо закройте те, которые не могут быть приняты.
- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использование метаданных SIG Docs.
- Ежедневно отсортируйте и пометьте новые заявки. Обратитесь к странице [Участие для опытных](/ru/docs/contribute/intermediate/) для получения информации по использованию метаданных SIG Docs.
### Полезные ссылки на GitHub для дежурных
@ -43,9 +43,9 @@ weight: 30
- [Нет CLA, нет права на слияние](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+label%3A%22cncf-cla%3A+no%22+-label%3Ado-not-merge+label%3Alanguage%2Fen): напомните участнику подписать CLA. Если об этом уже напомнил и бот, и человек, то закройте PR и напишите автору, что он может открыть свой PR после подписания CLA.
**Не проверяйте PR, если их авторы не подписали CLA!**
- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужен проверка с технической точки зрения, попросите её провести одного из рецензентов, который предложил бот. Если требуется просмотр пулреквест со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста.
- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слияния, оставьте комментарий с текстом `/approve`.
- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения. (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]).
- [Требуется LGTM](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-label%3Algtm+): если нужна проверка с технической точки зрения, попросите её провести одного из рецензентов, которого предложил бот. Если требуется просмотр пулреквеста со стороны группы документации или вычитка, то предложите изменения, либо сами измените PR, чтобы ускорить процесс принятия пулреквеста.
- [Имеет LGTM, нужно одобрение со стороны группы документации](https://github.com/kubernetes/website/pulls?q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+label%3Algtm): выясните, нужно ли внести какие-либо дополнительные изменения или обновления, чтобы принять PR. Если по вашему мнению PR готов к слиянию, оставьте комментарий с текстом `/approve`.
- [Быстрые результаты](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+base%3Amaster+-label%3A%22do-not-merge%2Fwork-in-progress%22+-label%3A%22do-not-merge%2Fhold%22+label%3A%22cncf-cla%3A+yes%22+label%3A%22size%2FXS%22+label%3A%22language%2Fen%22+): если маленький PR направлен в основную ветку и не имеет условий для объединения (поменяйте "XS" в метке с размером при работе с другими пулреквестами [XS, S, M, L, XL, XXL]).
- [Вне основной ветки](https://github.com/kubernetes/website/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+label%3Alanguage%2Fen+-base%3Amaster): если PR отправлен в ветку `dev-`, значит он предназначается для будущего выпуска. Убедитесь, что [release meister](https://github.com/kubernetes/sig-release/tree/master/release-team) знает об этом, добавив комментарий с `/assign @<meister's_github-username>`. Если он направлен в старую ветку, помогите автору PR изменить на более подходящую ветку.
### Когда закрывать пулреквесты
@ -57,7 +57,7 @@ weight: 30
- Закройте любой PR, если автор не отреагировал на комментарии или проверки в течение 2 или более недель.
Не бойтесь закрывать пулреквесты. Участники с лёгкостью открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулировать автора возобновить и закончить свой вклад.
Не бойтесь закрывать пулреквесты. Участники с лёгкостью могут открыть и возобновить незаконченную работу. Зачастую уведомление о закрытии стимулирует автора возобновить и завершить свою работу до конца.
Чтобы закрыть пулреквест, оставьте комментарий `/close` в PR.
@ -71,8 +71,8 @@ weight: 30
[Члены](/ru/docs/contribute/participating/#члены) SIG Docs могут предлагать улучшения.
После того, как вы давно начали работать над документацией Kubernetes, у наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по оформлению](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их на канале `#sig-docs` Slack на [kubernetes.slack.com](https://kubernetes.slack.com).
Если вы давно начали работать над документацией Kubernetes, у вас наверняка появились какие-нибудь идеи по улучшению [руководства по оформлению](/docs/contribute/style/style-guide/), [руководства по содержанию](/docs/contribute/style/content-guide/), набору инструментов, который используется для создания документации, стилизации сайта, процессов проверки и объединения пулреквестов. Для максимальной открытости подобные типы предложений по улучшению должны обсуждаться на встречи SIG Docs или в [списке рассылки kubernetes-sig-docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs).
Помимо этого, это поможет разъяснить, как всё устроено в данный момент, и объяснить, почему так было принято, прежде чем предлагать радикальные изменения. Самый быстрый способ узнать ответы на вопросы о том, как в настоящее время работает документация, это задать их в канале `#sig-docs` в [официальном Slack](https://kubernetes.slack.com).
Когда обсуждение состоялось, а SIG-группа согласилась с желаемым результатом, вы можете работать над предлагаемыми изменениями наиболее приемлемым способом. Например, обновление руководства по оформлению или функциональности сайта может включать открытие пулреквеста, а изменение, связанное с тестированием документации, может предполагать взаимодействие с sig-testing.
@ -84,11 +84,11 @@ weight: 30
Представитель SIG Docs для данного выпуска координирует следующие задачи:
- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивают документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск.
- Регулярное посещение встречи sig-release и обновлять информацию о статусе документации в выпуске.
- Мониторинг электронной таблицы с отслеживанием функциональности на наличие новых или измененных возможностей, затрагивающих документацию. Если документация для определенной функциональности не будет готова к выпуску, возможно, она не попадет в выпуск.
- Регулярное посещение встречи sig-release и обновление информации о статусе документации к выпуску.
- Проверка и вычитка документации по функциональности, подготовленной SIG-группой, ответственной за реализацию этой функциональности.
- Объединение связанных с выпуском пулреквестов и поддержка Git-ветки выпуска.
- Консультируйте других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing).
- Консультирование других участников SIG Docs, которые хотят научиться выполнять эту роль в будущем. Это называется сопровождение (shadowing).
- Публикация изменений в документации, связанные с выпуском при размещении артефактов.
Координация выпуска обычно занимает 3-4 месяца, а обязанности распределяются между утверждающими SIG Docs.
@ -101,10 +101,10 @@ weight: 30
Обязанности амбассадоров новых участников включают в себя:
- Отвечать на вопросы новых участников на [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com).
- Отвечать на вопросы новых участников в [Slack-канале Kubernetes #sig-docs](https://kubernetes.slack.com).
- Совместно работать с дежурным по PR, чтобы определять заявки, которые подойдут для решения новыми участниками.
- Консультировать новых участников в их PR.
- Помогать новых участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes.
- Помогать новым участникам в создании более сложных PR, чтобы они могли стать членами Kubernetes.
- [Оказывать содействие участникам](/ru/docs/contribute/advanced/#поддержка-нового-участника) на их пути становления членом в Kubernetes.
Текущие амбассадоры новых участников объявляются на каждом собрании SIG Docs и на канале [#sig-docs в Kubernetes](https://kubernetes.slack.com).
@ -115,7 +115,7 @@ weight: 30
Если участник сделал 5 значительных пулреквестов в один или несколько репозиториев Kubernetes, он имеет право на [членство](/ru/docs/contribute/participating#члены) в организации Kubernetes. Членство участника должно быть поддержано двумя спонсорами, которые уже являются рецензентами.
Новые участники документации могут найти спонсоров в канале #sig-docs в [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes.
Новые участники документации могут найти спонсоров в канале #sig-docs [в Slack Kubernetes](https://kubernetes.slack.com) или в [списке рассылки SIG Docs](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). Если вы осознали полезность работы автора заявки на членство, вы добровольно можете поддержать (спонсировать) его. Когда они подадут заявку на членство, отреагируйте на заявку "+1" и напишите подробный комментарий о том, почему вы считаете, что кандидат отлично вписывается в члены организации Kubernetes.
## Сопредседатель SIG
@ -125,9 +125,9 @@ weight: 30
Сопредседатели должны соответствовать следующим требованиям:
- Быть утверждающим SIG Docs не меньше 6 месяцев
- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопровождать два выпуска
- Понимание рабочих процессов и инструментов SIG Docs: git, Hugo, локализация, блог
- Быть утверждающими SIG Docs не меньше 6 месяцев.
- [Руководить выпуском документации Kubernetes](/docs/contribute/advanced/#coordinate-docs-for-a-kubernetes-release) или сопроводить два выпуска.
- Понимать рабочие процессы и инструменты SIG Docs: git, Hugo, локализация, блог.
- Понимать, как другие SIG-группы и репозитории Kubernetes влияют на рабочий процесс SIG Docs, включая: [команды в k/org](https://github.com/kubernetes/org/blob/master/config/kubernetes/sig-docs/teams.yaml), [процессы в k/community](https://github.com/kubernetes/community/tree/master/sig-docs), плагины в [k/test-infra](https://github.com/kubernetes/test-infra/) и роль [SIG Architecture](https://github.com/kubernetes/community/tree/master/sig-architecture).
- Уделять не менее 5 часов в неделю (но зачастую больше) в течение как минимум 6 месяцев для выполнения обязанностей.
@ -137,13 +137,13 @@ weight: 30
Обязанности включают в себя:
- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию
- Быть примером соблюдения [норм поведения сообщества]https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG
- Изучение и внедрение передовых практик для SIG-группы, обновляя рекомендации по участию
- Планирование и проведение встреч SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое
- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях
- Сосредоточить группу SIG Docs на достижении максимального счастья для разработчиков через отличную документацию.
- Быть примером соблюдения [норм поведения сообщества](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) и контролировать их выполнение членами SIG.
- Изучать и внедрять передовые практики для SIG-группы, обновляя рекомендации по участию.
- Планировать и проверять встречи SIG: еженедельные обновления информации, ежеквартальные ретроспективные/плановые совещания и многое другое.
- Планирование и проведение спринтов по документации на мероприятиях KubeCon и других конференциях.
- Набирать персонал и выступать в поддержку {{< glossary_tooltip text="CNCF" term_id="cncf" >}} и его платиновых партнеров, включая Google, Oracle, Azure, IBM и Huawei.
- Поддерживать нормальную работу SIG
- Поддерживать нормальную работу SIG.
### Проведение продуктивных встреч
@ -155,33 +155,33 @@ weight: 30
**Сформулируйте четкую повестку дня**:
- Определите конкретную цель встречи
- Опубликуйте программу дня заранее
- Определите конкретную цель встречи.
- Опубликуйте программу дня заранее.
Для еженедельных встреч скопируйте примечания из предыдущей недели в раздел "Past meetings".
**Работайте вместе для создания точных примечания**:
- Запишите обсуждение встречи
- Подумайте над тем, чтобы делегировать роль стенографист кому-нибудь другому
- Запишите обсуждение встречи.
- Подумайте над тем, чтобы делегировать роль стенографиста кому-нибудь другому.
**Определяйте решения по пунктам повестки четко и точно**:
- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения
- Записывайте решения по пунктам, кто будет ими заниматься и ожидаемую дату завершения.
**Руководите обсуждением, когда это необходимо**:
- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему
- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей
- Если обсуждение выходит за пределы повестки дня, снова обратите внимание участников на обсуждаемую тему.
- Найдите место для различных стилей ведения обсуждения, не отвлекаясь от темы обсуждения и уважая время людей.
**Уважайте время людей**:
- Начинайте и заканчивайте встречи своевременно
- Начинайте и заканчивайте встречи своевременно.
**Используйте Zoom эффективно**:
- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md)
- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего
- Ознакомьтесь с [рекомендациями Zoom для Kubernetes](https://github.com/kubernetes/community/blob/master/communication/zoom-guidelines.md).
- Попробуйте попроситься быть ведущим в самом начале встречи, введя ключ ведущего.
<img src="/images/docs/contribute/claim-host.png" width="75%" alt="Исполнение роли ведущего в Zoom" />
@ -192,5 +192,3 @@ weight: 30
Если нужно остановить запись, нажмите на кнопку Stop.
Запись автоматически загрузится на YouTube.

80
content/ru/docs/contribute/style/content-guide.md
View File

@ -25,72 +25,72 @@ card:
### Контент, полученный из двух источников
Документация Kubernetes не содержит дублированный контент, полученный из разных мест (так называемый **контент из двумя источниками**). Контент из двух источников требует дублирования работы со стороны мейнтейнеров проекта и к тому же быстро теряет актуальность.
Документация Kubernetes не содержит дублированный контент, полученный из разных мест (так называемый **контент из двух источников**). Контент из двух источников требует дублирования работы со стороны мейнтейнеров проекта и к тому же быстро теряет актуальность.
Перед добавлением контента, задайте себе вопрос:
- Новая информация относится к действующему проекту CNCF ИЛИ проекту в организациях на GitHub kubernetes или kubernetes-sigs?
- Новая информация относится к действующему проекту CNCF или проекту в организациях на GitHub kubernetes или kubernetes-sigs?
- Если да, то:
- У этого проекта есть собственная документация?
- если да, то укажите ссылку на документацию проекта в документации Kubernetes
- если нет, добавьте информацию в репозиторий проекта (если это возможно), а затем укажите ссылку на неё в документации Kubernetes
- если да, то укажите ссылку на документацию проекта в документации Kubernetes.
- если нет, добавьте информацию в репозиторий проекта (если это возможно), а затем укажите ссылку на неё в документации Kubernetes.
- Если нет, то:
- Остановитесь!
- Добавление информации по продуктам от других разработчиков не допускается
- Добавление информации о продуктах от других разработчиков не допускается.
- Не разрешено ссылаться на документацию и сайты сторонних разработчиков.
### Разрешенная и запрещённая информация
Есть несколько условий, когда в документации Kubernetes может быть информация, относящиеся не к проектам Kubernetes.
Ниже перечислены основные категории по содержанию проектов, не касающихся к Kubernetes, а также приведены рекомендации о том, что разрешено, а что нет:
Ниже перечислены основные категории по содержанию проектов, не касающихся Kubernetes, а также приведены рекомендации о том, что разрешено, а что нет:
1. Инструкции по установке или эксплуатации Kubernetes, которые не связаны с проектами Kubernetes
1. Инструкции по установке или эксплуатации Kubernetes, которые не связаны с проектами Kubernetes.
- Разрешено:
- Ссылаться на документацию на CNCF-проекта или на проект в GitHub-организациях kubernetes или kubernetes-sigs
- Пример: для установки Kubernetes в процессе обучения нужно обязательно установить и настроить minikube, а также сослаться на соответствующую документацию minikube
- Добавление инструкций для проектов в организации kubernetes или kubernetes-sigs, если по ним нет инструкций
- Пример: добавление инструкций по установке и решению неполадок [kubadm](https://github.com/kubernetes/kubeadm)
- Ссылаться на документацию CNCF-проекта или на проект в GitHub-организациях kubernetes или kubernetes-sigs.
- Пример: для установки Kubernetes в процессе обучения нужно обязательно установить и настроить minikube, а также сослаться на соответствующую документацию minikube.
- Добавление инструкций для проектов в организации kubernetes или kubernetes-sigs, если по ним нет инструкций.
- Пример: добавление инструкций по установке и решению неполадок [kubeadm](https://github.com/kubernetes/kubeadm).
- Запрещено:
- Добавление информацию, которая повторяет документацию в другом репозитории
- Добавление информации, которая дублирует документацию в другом репозитории.
- Примеры:
- Добавление инструкций по установке и настройке minikube; Minikube имеет собственную [документацию](https://minikube.sigs.k8s.io/docs/), которая включают эти инструкции
- Добавление инструкций по установке Docker, CRI-O, containerd и других окружений для выполнения контейнеров в разных операционных системах
- Добавление инструкций по установке и настройке minikube; Minikube имеет собственную [документацию](https://minikube.sigs.k8s.io/docs/), которая включают эти инструкции.
- Добавление инструкций по установке Docker, CRI-O, containerd и других окружений для выполнения контейнеров в разных операционных системах.
- Добавление инструкций по установке Kubernetes в промышленных окружениях, используя разные проекты:
-Kubernetes Rebar Integrated Bootstrap (KRIB) — это проект стороннего разработчика, поэтому все содержимое находится репозитории разработчика.
- Kubernetes Rebar Integrated Bootstrap (KRIB) — это проект стороннего разработчика, поэтому всё содержимое находится в репозитории разработчика.
- У проекта [Kubernetes Operations (kops)](https://github.com/kubernetes/kops) есть инструкции по установке и руководства в GitHub-репозитории.
- У проекта [Kubespray](https://kubespray.io) есть собственная документация
- Добавление руководства, в котором объясняется, как выполнить задачу с использованием продукта определенного разработчика или проекта с открытым исходным кодом, не являющиеся CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs.
- Добавление руководства по использованию CNCF-проекта или проекта в GitHub-организациях kubernetes или kubnetes-sigs, если у проекта есть собственная документация
1. Подробное описание технических аспектов по использованию стороннего проекта (не Kubernetes) или как этот проект разработан
- У проекта [Kubespray](https://kubespray.io) есть собственная документация.
- Добавление руководства, в котором объясняется, как выполнить задачу с использованием продукта определенного разработчика или проекта с открытым исходным кодом, не являющиеся CNCF-проектами или проектом в GitHub-организациях kubernetes, или kubernetes-sigs.
- Добавление руководства по использованию CNCF-проекта или проекта в GitHub-организациях kubernetes или kubernetes-sigs, если у проекта есть собственная документация.
1. Подробное описание технических аспектов по использованию стороннего проекта (не Kubernetes) или как этот проект разработан.
Добавление такого типа информации в документацию Kubernetes не допускается.
1. Информация стороннему проекту
1. Информация стороннему проекту.
- Разрешено:
- Добавление краткого введения о CNCF-проекте или проекте в GitHub-организациях kubernetes или kubernetes-sigs; этот абзац может содержать ссылки на проект
- Добавление краткого введения о CNCF-проекте или проекте в GitHub-организациях kubernetes или kubernetes-sigs; этот абзац может содержать ссылки на проект.
- Запрещено:
- Добавление информации по продукту определённого разработчика
- Добавление информации по проекту с открытым исходным кодом, который не является CNCF-проектом или проектом в GitHub-организациях kubernetes или kubnetes-sigs
- Добавление информации, дублирующего документацию из другого проекта, независимо от оригинального репозитория
- Пример: добавление документации для проекта [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) в документацию Kubernetes
1. Только ссылки на сторонний проект
- Добавление информации по продукту определённого разработчика.
- Добавление информации по проекту с открытым исходным кодом, который не является CNCF-проектом или проектом в GitHub-организациях kubernetes или kubernetes-sigs.
- Добавление информации, дублирующего документацию из другого проекта, независимо от оригинального репозитория.
- Пример: добавление документации для проекта [Kubernetes in Docker (KinD)](https://kind.sigs.k8s.io) в документацию Kubernetes.
1. Только ссылки на сторонний проект.
- Разрешено:
- Ссылаться на проекты в GitHub-организациях kubernetes и kubernetes-sigs
- Пример: добавление ссылок на [документацию](https://kind.sigs.k8s.io/docs/user/quick-start) проекта Kubernetes in Docker (KinD), который находится в GitHub-организации kubernetes-sigs
- Добавление ссылок на действующие CNCF-проекты
- Пример: добавление ссылок на [документацию](https://prometheus.io/docs/introduction/overview/) проекта Prometheus; Prometheus — это действующий проект CNCF
- Ссылаться на проекты в GitHub-организациях kubernetes и kubernetes-sigs.
- Пример: добавление ссылок на [документацию](https://kind.sigs.k8s.io/docs/user/quick-start) проекта Kubernetes in Docker (KinD), который находится в GitHub-организации kubernetes-sigs.
- Добавление ссылок на действующие CNCF-проекты.
- Пример: добавление ссылок на [документацию](https://prometheus.io/docs/introduction/overview/) проекта Prometheus; Prometheus — это действующий проект CNCF.
- Запрещено:
- Ссылаться на продукты стороннего разработчика
- Ссылаться на архивированные проекты CNCF
- Ссылаться на недействующие проекты в организациях GitHub в kubernetes и kubernetes-sigs
- Ссылаться на проекты с открытым исходным кодом, которые не являются проектами CNCF или не находятся в организациях GitHub kubernetes или kubernetes-sigs.
1. Содержание учебных курсов
- Ссылаться на продукты стороннего разработчика.
- Ссылаться на прекращенные проекты CNCF.
- Ссылаться на недействующие проекты в организациях GitHub в kubernetes и kubernetes-sigs.
- Ссылаться на проекты с открытым исходным кодом, которые не являются проектами CNCF или не находятся в организациях GitHub kubernetes, или kubernetes-sigs.
1. Содержание учебных курсов.
- Разрешено:
- Ссылаться на независимые от разработчиков учебные курсы Kubernetes, предлагаемыми [CNCF](https://www.cncf.io/), [Linux Foundation](https://www.linuxfoundation.org/) и [Linux Academy](https://linuxacademy.com/) (партнер Linux Foundation)
- Пример: добавление ссылок на курсы Linux Academy, такие как [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) в [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/)
- Ссылаться на независимые от разработчиков учебные курсы Kubernetes, предлагаемыми [CNCF](https://www.cncf.io/), [Linux Foundation](https://www.linuxfoundation.org/) и [Linux Academy](https://linuxacademy.com/) (партнер Linux Foundation).
- Пример: добавление ссылок на курсы Linux Academy, такие как [Kubernetes Quick Start](https://linuxacademy.com/course/kubernetes-quick-start/) и [Kubernetes Security](https://linuxacademy.com/course/kubernetes-security/).
- Запрещено:
- Ссылаться на учебныЕе онлайн-курсы, вне CNCF, Linux Foundation или Linux Academy; документация Kubernetes не содержит ссылок на сторонний контент
- Ссылаться на учебные онлайн-курсы, не относящиеся к CNCF, Linux Foundation или Linux Academy; документация Kubernetes не содержит ссылок на сторонний контент.
- Пример: добавление ссылок на учебные руководства или курсы Kubernetes на Medium, KodeKloud, Udacity, Coursera, learnk8s и т.д.
- Ссылаться на руководства определённых разработчиков вне зависимости от обучающей организации
- Пример: добавление ссылок на такие курсы Linux Academy, как [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) and [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/)
- Ссылаться на руководства определённых разработчиков вне зависимости от обучающей организации.
- Пример: добавление ссылок на такие курсы Linux Academy, как [Google Kubernetes Engine Deep Dive](https://linuxacademy.com/google-cloud-platform/training/course/name/google-kubernetes-engine-deep-dive) и [Amazon EKS Deep Dive](https://linuxacademy.com/course/amazon-eks-deep-dive/)
Если у вас есть вопросы по поводу допустимого контента, присоединяйтесь к каналу #sig-docs в [Slack Kubernetes](http://slack.k8s.io/)!

12
content/ru/docs/reference/kubectl/cheatsheet.md
View File

@ -235,7 +235,7 @@ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl
kubectl label pods my-pod new-label=awesome # Добавить метку
kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # Добавить аннотацию
kubectl autoscale deployment foo --min=2 --max=10 # Автоматически промасштабировать развёртывание "foo"
kubectl autoscale deployment foo --min=2 --max=10 # Автоматически масштабировать развёртывание "foo" в диапазоне от 2 до 10 подов
```
## Обновление ресурсов
@ -269,10 +269,10 @@ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # Использовать
## Масштабирование ресурсов
```bash
kubectl scale --replicas=3 rs/foo # Промасштабировать набор реплик (replicaset) 'foo' до 3
kubectl scale --replicas=3 -f foo.yaml # Промасштабировать ресурс в "foo.yaml" до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Если количество реплик в развёртывании mysql равен 2, промасштабировать его до 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Промасштабировать несколько контроллеров репликации
kubectl scale --replicas=3 rs/foo # Масштабирование набора реплик (replicaset) 'foo' до 3
kubectl scale --replicas=3 -f foo.yaml # Масштабирование ресурса в "foo.yaml" до 3
kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # Если количество реплик в развёртывании mysql равен 2, масштабировать его до 3
kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Масштабирование нескольких контроллеров репликации до 5
```
## Удаление ресурсов
@ -362,7 +362,7 @@ kubectl api-resources --api-group=extensions # Все ресурсы в API-гр
### Уровни детальности вывода и отладки в Kubectl
Уровни детальности вывода Kubectl регулируются с помощью флагов `-v` или `--v`, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированиия Kubernetes и связанные с ними уровни описаны [здесь](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
Уровни детальности вывода Kubectl регулируются с помощью флагов `-v` или `--v`, за которыми следует целое число, представляющее уровни логирования. Общие соглашения по логированию Kubernetes и связанные с ними уровни описаны [здесь](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md).
Уровень детальности | Описание

2
content/ru/docs/reference/kubectl/docker-cli-to-kubectl.md
View File

@ -70,7 +70,7 @@ kubectl run [-i] [--tty] --attach <name> --image=<image>
```
В отличие от `docker run ...`, если вы укажете `--attach`, то присоедините `stdin`, `stdout` and `stderr`. Нельзя проконтролировать, какие потоки прикрепляются (`docker -a ...`).
Чтобы отсоединиться от контейнера воспользуетесь комбинацией клавиш Ctrl+P, а затем Ctrl+Q.
Чтобы отсоединиться от контейнера, воспользуетесь комбинацией клавиш Ctrl+P, а затем Ctrl+Q.
Так как команда kubectl run запускает развёртывание для контейнера, то оно начнет перезапускаться, если завершить прикрепленный процесс по нажатию Ctrl+C, в отличие от команды `docker run -it`.
Для удаления объекта Deployment вместе с подами, необходимо выполнить команду `kubectl delete deployment <name>`.

2
content/ru/docs/reference/kubectl/jsonpath.md
View File

@ -90,7 +90,7 @@ kubectl get pods -o=jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.st
```
{{< note >}}
В Windows нужно заключить в _двойные_ кавычки JSONPath-шаблон, который содержит пробелы (не в одинарные, как в примерах выше для bash). Таким образом, любые литералы в таких шаблонов нужно оборачивать в одинарные кавычки или экранированные двойные кавычки. Например:
В Windows нужно заключить в _двойные_ кавычки JSONPath-шаблон, который содержит пробелы (не в одинарные, как в примерах выше для bash). Таким образом, любые литералы в таких шаблонах нужно оборачивать в одинарные кавычки или экранированные двойные кавычки. Например:
```cmd
kubectl get pods -o=jsonpath="{range .items[*]}{.metadata.name}{'\t'}{.status.startTime}{'\n'}{end}"

94
content/ru/docs/reference/kubectl/kubectl.md
View File

@ -158,14 +158,14 @@ kubectl [flags]
<td colspan="2">--default-not-ready-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: 300</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения notReady:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение.</td>
</tr>
<tr>
<td colspan="2">--default-unreachable-toleration-seconds int&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: 300</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого нет установлено такое допущение.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Указывает tolerationSeconds для допущения unreachable:NoExecute, которое по умолчанию добавляется к каждому поду, у которого не установлено такое допущение.</td>
</tr>
<tr>
@ -221,7 +221,7 @@ kubectl [flags]
<td colspan="2">--docker-tls-cert string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: "cert.pem"</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">путь к клиентскому сертификату</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Путь к клиентскому сертификату</td>
</tr>
<tr>
@ -277,7 +277,7 @@ kubectl [flags]
<td colspan="2">--insecure-skip-tls-verify</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, значит сертификат сервера не будет проверятся на достоверность. Это сделает подключения через HTTPS небезопасными.</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Если true, значит сертификат сервера не будет проверяться на достоверность. Это сделает подключения через HTTPS небезопасными.</td>
</tr>
<tr>
@ -333,7 +333,7 @@ kubectl [flags]
<td colspan="2">--logtostderr&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;По умолчанию: true</td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Логировать в стандартный поток ошибок вместо сохранения логов в файлы</td>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Вывод логов в стандартный поток ошибок вместо сохранения их в файлы</td>
</tr>
<tr>
@ -521,48 +521,48 @@ kubectl [flags]
## {{% heading "seealso" %}}
* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - Обновить аннотации ресурса
* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources) - Вывести доступные API-ресурсы на сервере
* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions) - Вывести доступные API-версии на сервере в виде "group/version".
* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) - Внести изменения в конфигурацию ресурса из файла или потока stdin.
* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach) - Присоединиться к запущенному контейнеру
* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth) - Проверить разрешение на выполнение определённых действий
* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) - Автоматически промасштабировать Deployment, ReplicaSet или ReplicationController
* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate) - Изменить сертификаты ресурсов.
* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info) - Показать информацию по кластеру
* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion) - Вывод кода автодополнения указанной командной оболочки (bash или zsh)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - Изменить файлы kubeconfig
* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) - Конвертировать конфигурационные файлы в различные API-версии
* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon) - Отметить узел как неназначаемый
* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp) - Копировать файлы и директории в/из контейнеров.
* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) - Создать ресурс из файла или потока stdin.
* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete) - Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов
* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe) - Показать подробную информацию о конкретном ресурсе или группе ресурсов
* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - Сравнить действующую версию с новой (применяемой)
* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain) - Вытеснить узел для подготовки к эксплуатации
* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit) - Отредактировать ресурс на сервере
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - Выполнить команду в контейнере
* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - Получить документацию ресурсов
* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - Создать новый сервис Kubernetes из контроллера репликации, сервиса, развёртывания или пода
* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get) - Вывести один или несколько ресурсов
* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize) - Собрать ресурсы kustomization из директории или URL-адреса.
* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label) - Обновить метки ресурса
* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs) - Вывести логи контейнера в поде
* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options) - Вывести список флагов, применяемых ко всем командам
* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch) - Обновить один или несколько полей ресурса, используя стратегию слияния патча
* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin) - Команда для работы с плагинами.
* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward) - Переадресовать один или несколько локальных портов в под
* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy) - Запустить прокси на API-сервер Kubernetes
* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace) - Заменить ресурс из определения в файле или потоке stdin.
* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout) - Управление плавающим обновлением ресурса
* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run) - Запустить указанный образ в кластере
* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - Задать новый размер для Deployment, ReplicaSet или Replication Controller.
* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - Конфигурировать ресурсы в объектах
* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) - Обновить ограничения для одного или нескольких узлов
* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top) - Показать информацию по использованию системных ресурсов (процессор, память, диск)
* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - Отметить узел как назначаемый
* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Вывести информацию о версии клиента и сервера
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах.
* [kubectl annotate](/docs/reference/generated/kubectl/kubectl-commands#annotate) - Обновить аннотации ресурса.
* [kubectl api-resources](/docs/reference/generated/kubectl/kubectl-commands#api-resources) - Вывести доступные API-ресурсы на сервере.
* [kubectl api-versions](/docs/reference/generated/kubectl/kubectl-commands#api-versions) - Вывести доступные API-версии на сервере в виде "group/version".
* [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) - Внести изменения в конфигурацию ресурса из файла или потока stdin.
* [kubectl attach](/docs/reference/generated/kubectl/kubectl-commands#attach) - Присоединиться к запущенному контейнеру.
* [kubectl auth](/docs/reference/generated/kubectl/kubectl-commands#auth) - Проверить разрешение на выполнение определённых действий.
* [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands#autoscale) - Автоматически масштабировать Deployment, ReplicaSet или ReplicationController.
* [kubectl certificate](/docs/reference/generated/kubectl/kubectl-commands#certificate) - Изменить сертификаты ресурсов.
* [kubectl cluster-info](/docs/reference/generated/kubectl/kubectl-commands#cluster-info) - Показать информацию по кластеру.
* [kubectl completion](/docs/reference/generated/kubectl/kubectl-commands#completion) - Вывод кода автодополнения указанной командной оболочки (bash или zsh).
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) - Изменить файлы kubeconfig.
* [kubectl convert](/docs/reference/generated/kubectl/kubectl-commands#convert) - Конвертировать конфигурационные файлы в различные API-версии.
* [kubectl cordon](/docs/reference/generated/kubectl/kubectl-commands#cordon) - Отметить узел как неназначаемый.
* [kubectl cp](/docs/reference/generated/kubectl/kubectl-commands#cp) - Копировать файлы и директории в/из контейнеров.
* [kubectl create](/docs/reference/generated/kubectl/kubectl-commands#create) - Создать ресурс из файла или потока stdin.
* [kubectl delete](/docs/reference/generated/kubectl/kubectl-commands#delete) - Удалить ресурсы из файла, потока stdin, либо с помощью селекторов меток, имен, селекторов ресурсов или ресурсов.
* [kubectl describe](/docs/reference/generated/kubectl/kubectl-commands#describe) - Показать подробную информацию о конкретном ресурсе или группе ресурсов.
* [kubectl diff](/docs/reference/generated/kubectl/kubectl-commands#diff) - Сравнить действующую версию с новой (применяемой).
* [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands#drain) - Вытеснить узел для подготовки к эксплуатации.
* [kubectl edit](/docs/reference/generated/kubectl/kubectl-commands#edit) - Отредактировать ресурс на сервере.
* [kubectl exec](/docs/reference/generated/kubectl/kubectl-commands#exec) - Выполнить команду в контейнере.
* [kubectl explain](/docs/reference/generated/kubectl/kubectl-commands#explain) - Получить документацию ресурсов.
* [kubectl expose](/docs/reference/generated/kubectl/kubectl-commands#expose) - Создать новый сервис Kubernetes из контроллера репликации, сервиса, развёртывания или пода.
* [kubectl get](/docs/reference/generated/kubectl/kubectl-commands#get) - Вывести один или несколько ресурсов.
* [kubectl kustomize](/docs/reference/generated/kubectl/kubectl-commands#kustomize) - Собрать ресурсы kustomization из директории или URL-адреса.
* [kubectl label](/docs/reference/generated/kubectl/kubectl-commands#label) - Обновить метки ресурса.
* [kubectl logs](/docs/reference/generated/kubectl/kubectl-commands#logs) - Вывести логи контейнера в поде.
* [kubectl options](/docs/reference/generated/kubectl/kubectl-commands#options) - Вывести список флагов, применяемых ко всем командам.
* [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands#patch) - Обновить один или несколько полей ресурса, используя стратегию слияния патча.
* [kubectl plugin](/docs/reference/generated/kubectl/kubectl-commands#plugin) - Команда для работы с плагинами.
* [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands#port-forward) - Переадресовать один или несколько локальных портов в под.
* [kubectl proxy](/docs/reference/generated/kubectl/kubectl-commands#proxy) - Запустить прокси на API-сервер Kubernetes.
* [kubectl replace](/docs/reference/generated/kubectl/kubectl-commands#replace) - Заменить ресурс из определения в файле или потоке stdin.
* [kubectl rollout](/docs/reference/generated/kubectl/kubectl-commands#rollout) - Управление плавающим обновлением ресурса.
* [kubectl run](/docs/reference/generated/kubectl/kubectl-commands#run) - Запустить указанный образ в кластере.
* [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands#scale) - Задать новый размер для Deployment, ReplicaSet или Replication Controller.
* [kubectl set](/docs/reference/generated/kubectl/kubectl-commands#set) - Конфигурировать ресурсы в объектах.
* [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) - Обновить ограничения для одного или нескольких узлов.
* [kubectl top](/docs/reference/generated/kubectl/kubectl-commands#top) - Показать информацию по использованию системных ресурсов (процессор, память, диск).
* [kubectl uncordon](/docs/reference/generated/kubectl/kubectl-commands#uncordon) - Отметить узел как назначаемый.
* [kubectl version](/docs/reference/generated/kubectl/kubectl-commands#version) - Вывести информацию о версии клиента и сервера.
* [kubectl wait](/docs/reference/generated/kubectl/kubectl-commands#wait) - Экспериментально: ожидать выполнения определенного условия в одном или нескольких ресурсах.

0
content/vi/docs/concepts/architecture/_index.md Executable file → Normal file
View File

154
content/zh/blog/_posts/2021-12-08-dual-stack-networking-ga.md Normal file
View File

@ -0,0 +1,154 @@
---
layout: blog
title: 'Kubernetes 1.23：IPv4/IPv6 双协议栈网络达到 GA'
date: 2021-12-08
slug: dual-stack-networking-ga
---
<!--
layout: blog
title: 'Kubernetes 1.23: Dual-stack IPv4/IPv6 Networking Reaches GA'
date: 2021-12-08
slug: dual-stack-networking-ga
-->
<!--
**Author:** Bridget Kromhout (Microsoft)
-->
**作者:** Bridget Kromhout (微软)
<!--
"When will Kubernetes have IPv6?" This question has been asked with increasing frequency ever since alpha support for IPv6 was first added in k8s v1.9. While Kubernetes has supported IPv6-only clusters since v1.18, migration from IPv4 to IPv6 was not yet possible at that point. At long last, [dual-stack IPv4/IPv6 networking](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/) has reached general availability (GA) in Kubernetes v1.23.
What does dual-stack networking mean for you? Let’s take a look…
-->
“Kubernetes 何时支持 IPv6？” 自从 k8s v1.9 版本中首次添加对 IPv6 的 alpha 支持以来，这个问题的讨论越来越频繁。
虽然 Kubernetes 从 v1.18 版本开始就支持纯 IPv6 集群，但当时还无法支持 IPv4 迁移到 IPv6。
[IPv4/IPv6 双协议栈网络](https://github.com/kubernetes/enhancements/tree/master/keps/sig-network/563-dual-stack/)
在 Kubernetes v1.23 版本中进入正式发布（GA）阶段。
让我们来看看双协议栈网络对你来说意味着什么？
<!--
## Service API updates
-->
## 更新 Service API
<!--
[Services](/docs/concepts/services-networking/service/) were single-stack before 1.20, so using both IP families meant creating one Service per IP family. The user experience was simplified in 1.20, when Services were re-implemented to allow both IP families, meaning a single Service can handle both IPv4 and IPv6 workloads. Dual-stack load balancing is possible between services running any combination of IPv4 and IPv6.
-->
[Services](/zh/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的，
因此，使用两个 IP 协议族意味着需为每个 IP 协议族创建一个 Service。在 1.20 版本中对用户体验进行简化，
重新实现了 Service 以支持两个 IP 协议族，这意味着一个 Service 就可以处理 IPv4 和 IPv6 协议。
对于 Service 而言，任意的 IPv4 和 IPv6 协议组合都可以实现负载均衡。
<!--
The Service API now has new fields to support dual-stack, replacing the single ipFamily field.
* You can select your choice of IP family by setting `ipFamilyPolicy` to one of three options: SingleStack, PreferDualStack, or RequireDualStack. A service can be changed between single-stack and dual-stack (within some limits).
* Setting `ipFamilies` to a list of families assigned allows you to set the order of families used.
* `clusterIPs` is inclusive of the previous `clusterIP` but allows for multiple entries, so it’s no longer necessary to run duplicate services, one in each of the two IP families. Instead, you can assign cluster IP addresses in both IP families.
-->
Service API 现在有了支持双协议栈的新字段，取代了单一的 ipFamily 字段。
* 你可以通过将 `ipFamilyPolicy` 字段设置为 `SingleStack`、`PreferDualStack` 或
`RequireDualStack` 来设置 IP 协议族。Service 可以在单协议栈和双协议栈之间进行转换(在某些限制内)。
* 设置 `ipFamilies` 为指定的协议族列表，可用来设置使用协议族的顺序。
* 'clusterIPs' 的能力在涵盖了之前的 'clusterIP'的情况下，还允许设置多个 IP 地址。
所以不再需要运行重复的 Service，在两个 IP 协议族中各运行一个。你可以在两个 IP 协议族中分配集群 IP 地址。
<!--
Note that Pods are also dual-stack. For a given pod, there is no possibility of setting multiple IP addresses in the same family.
-->
请注意，Pods 也是双协议栈的。对于一个给定的 Pod，不可能在同一协议族中设置多个 IP 地址。
<!--
## Default behavior remains single-stack
-->
## 默认行为仍然是单协议栈
<!--
Starting in 1.20 with the re-implementation of dual-stack services as alpha, the underlying networking for Kubernetes has included dual-stack whether or not a cluster was configured with the feature flag to enable dual-stack.
-->
从 1.20 版本开始，重新实现的双协议栈服务处于 Alpha 阶段，无论集群是否配置了启用双协议栈的特性标志，
Kubernetes 的底层网络都已经包括了双协议栈。
<!--
Kubernetes 1.23 removed that feature flag as part of graduating the feature to stable. Dual-stack networking is always available if you want to configure it. You can set your cluster network to operate as single-stack IPv4, as single-stack IPv6, or as dual-stack IPv4/IPv6.
-->
Kubernetes 1.23 删除了这个特性标志，说明该特性已经稳定。
如果你想要配置双协议栈网络，这一能力总是存在的。
你可以将集群网络设置为 IPv4 单协议栈 、IPv6 单协议栈或 IPV4/IPV6 双协议栈 。
<!--
While Services are set according to what you configure, Pods default to whatever the CNI plugin sets. If your CNI plugin assigns single-stack IPs, you will have single-stack unless `ipFamilyPolicy` specifies PreferDualStack or RequireDualStack. If your CNI plugin assigns dual-stack IPs, `pod.status.PodIPs` defaults to dual-stack.
-->
虽然 Service 是根据你的配置设置的，但 Pod 默认是由 CNI 插件设置的。
如果你的 CNI 插件分配单协议栈 IP，那么就是单协议栈，除非 `ipFamilyPolicy` 设置为 `PreferDualStack` 或 `RequireDualStack`。
如果你的 CNI 插件分配双协议栈 IP，则 `pod.status.PodIPs` 默认为双协议栈。
<!--
Even though dual-stack is possible, it is not mandatory to use it. Examples in the documentation show the variety possible in [dual-stack service configurations](/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios).
-->
尽管双协议栈是可用的，但并不强制你使用它。
在[双协议栈服务配置](/zh/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios)
文档中的示例列出了可能出现的各种场景.
<!--
## Try dual-stack right now
-->
## 现在尝试双协议栈
<!--
While upstream Kubernetes now supports [dual-stack networking](/docs/concepts/services-networking/dual-stack/) as a GA or stable feature, each provider’s support of dual-stack Kubernetes may vary. Nodes need to be provisioned with routable IPv4/IPv6 network interfaces. Pods need to be dual-stack. The [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) is what assigns the IP addresses to the Pods, so it's the network plugin being used for the cluster that needs to support dual-stack. Some Container Network Interface (CNI) plugins support dual-stack, as does kubenet.
-->
虽然现在上游 Kubernetes 支持[双协议栈网络](/zh/docs/concepts/services-networking/dual-stack/)
作为 GA 或稳定特性，但每个提供商对双协议栈 Kubernetes 的支持可能会有所不同。节点需要提供可路由的 IPv4/IPv6 网络接口。
Pod 需要是双协议栈的。[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)
是用来为 Pod 分配 IP 地址的，所以集群需要支持双协议栈的网络插件。一些容器网络接口（CNI）插件支持双协议栈，例如 kubenet。
<!--
Ecosystem support of dual-stack is increasing; you can create [dual-stack clusters with kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), try a [dual-stack cluster locally with KIND](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family), and deploy dual-stack clusters in cloud providers (after checking docs for CNI or kubenet availability).
-->
支持双协议栈的生态系统在不断壮大；你可以使用
[kubeadm 创建双协议栈集群](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/),
在本地尝试用 [KIND 创建双协议栈集群](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family)，
还可以将双协议栈集群部署到云上（在查阅 CNI 或 kubenet 可用性的文档之后）
<!--
## Get involved with SIG Network
-->
## 加入 Network SIG
<!--
SIG-Network wants to learn from community experiences with dual-stack networking to find out more about evolving needs and your use cases. The [SIG-network update video from KubeCon NA 2021](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4) summarizes the SIG’s recent updates, including dual-stack going to stable in 1.23.
-->
SIG-Network 希望从双协议栈网络的社区体验中学习，以了解更多不断变化的需求和你的用例信息。
[SIG-network 更新了来自 KubeCon 2021 北美大会的视频](https://www.youtube.com/watch?v=uZ0WLxpmBbY&list=PLj6h78yzYM2Nd1U4RMhv7v88fdiFqeYAP&index=4)
总结了 SIG 最近的更新，包括双协议栈将在 1.23 版本中稳定。
<!--
The current SIG-Network [KEPs](https://github.com/orgs/kubernetes/projects/10) and [issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork) on GitHub illustrate the SIG’s areas of emphasis. The [dual-stack API server](https://github.com/kubernetes/enhancements/issues/2438) is one place to consider contributing.
-->
当前 SIG-Network 在 GitHub 上的 [KEPs](https://github.com/orgs/kubernetes/projects/10) 和
[issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork)
说明了该 SIG 的重点领域。[双协议栈 API 服务器](https://github.com/kubernetes/enhancements/issues/2438)
是一个考虑贡献的方向。
<!--
[SIG-Network meetings](https://github.com/kubernetes/community/tree/master/sig-network#meetings) are a friendly, welcoming venue for you to connect with the community and share your ideas. Looking forward to hearing from you!
-->
[SIG-Network 会议](https://github.com/kubernetes/community/tree/master/sig-network#meetings)
是一个友好、热情的场所，你可以与社区联系并分享你的想法。期待你的加入！
<!--
## Acknowledgments
-->
## 致谢
<!--
The dual-stack networking feature represents the work of many Kubernetes contributors. Thanks to all who contributed code, experience reports, documentation, code reviews, and everything in between. Bridget Kromhout details this community effort in [Dual-Stack Networking in Kubernetes](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/). KubeCon keynotes by Tim Hockin & Khaled (Kal) Henidak in 2019 ([The Long Road to IPv4/IPv6 Dual-stack Kubernetes](https://www.youtube.com/watch?v=o-oMegdZcg4)) and by Lachlan Evenson in 2021 ([And Here We Go: Dual-stack Networking in Kubernetes](https://www.youtube.com/watch?v=lVrt8F2B9CM)) talk about the dual-stack journey, spanning five years and a great many lines of code.
-->
许多 Kubernetes 贡献者为双协议栈网络做出了贡献。感谢所有贡献了代码、经验报告、文档、代码审查以及其他工作的人。
Bridget Kromhout 在 [Kubernetes的双协议栈网络](https://containerjournal.com/features/dual-stack-networking-in-kubernetes/)
中详细介绍了这项社区工作。Tim Hockin 和 Khaled (Kal) Henidak 在 2019 年的 KubeCon 大会演讲
（[Kubernetes 通往 IPv4/IPv6 双协议栈的漫漫长路](https://www.youtube.com/watch?v=o-oMegdZcg4)）
和 Lachlan Evenson 在 2021 年演讲（[我们来啦，Kubernetes 双协议栈网络](https://www.youtube.com/watch?v=o-oMegdZcg4)）
中讨论了双协议栈的发展旅程，耗时 5 年和海量代码。

208
content/zh/blog/_posts/2021-12-16-StatefulSet-PVC-Auto-Deletion.md Normal file
View File

@ -0,0 +1,208 @@
---
layout: blog
title: 'Kubernetes 1.23: StatefulSet PVC 自动删除 (alpha)'
date: 2021-12-16
slug: kubernetes-1-23-statefulset-pvc-auto-deletion
---
<!--
layout: blog
title: 'Kubernetes 1.23: StatefulSet PVC Auto-Deletion (alpha)'
date: 2021-12-16
slug: kubernetes-1-23-statefulset-pvc-auto-deletion
-->
<!--
**Author:** Matthew Cary (Google)
-->
**作者:** Matthew Cary (谷歌)
<!--
Kubernetes v1.23 introduced a new, alpha-level policy for
[StatefulSets](docs/concepts/workloads/controllers/statefulset/) that controls the lifetime of
[PersistentVolumeClaims](docs/concepts/storage/persistent-volumes/) (PVCs) generated from the
StatefulSet spec template for cases when they should be deleted automatically when the StatefulSet
is deleted or pods in the StatefulSet are scaled down.
-->
Kubernetes v1.23 为 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/)
引入了一个新的 alpha 级策略，用来控制由 StatefulSet 规约模板生成的
[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/) (PVCs) 的生命周期，
用于当删除 StatefulSet 或减少 StatefulSet 中的 Pods 数量时 PVCs 应该被自动删除的场景。
<!--
## What problem does this solve?
-->
## 它解决了什么问题？
<!--
A StatefulSet spec can include Pod and PVC templates. When a replica is first created, the
Kubernetes control plane creates a PVC for that replica if one does not already exist. The behavior
before Kubernetes v1.23 was that the control plane never cleaned up the PVCs created for
StatefulSets - this was left up to the cluster administrator, or to some add-on automation that
you’d have to find, check suitability, and deploy. The common pattern for managing PVCs, either
manually or through tools such as Helm, is that the PVCs are tracked by the tool that manages them,
with explicit lifecycle. Workflows that use StatefulSets must determine on their own what PVCs are
created by a StatefulSet and what their lifecycle should be.
-->
StatefulSet 规约中可以包含 Pod 和 PVC 的模板。当副本先被创建时，如果 PVC 还不存在，
Kubernetes 控制面会为该副本自动创建一个 PVC。在 Kubernetes 1.23 版本之前，
控制面不会删除 StatefulSet 创建的 PVCs——这依赖集群管理员或你需要部署一些额外的适用的自动化工具来处理。
管理 PVC 的常见模式是通过手动或使用 Helm 等工具，PVC 的具体生命周期由管理它的工具跟踪。
使用 StatefulSet 时必须自行确定 StatefulSet 创建哪些 PVC，以及它们的生命周期应该是什么。
<!--
Before this new feature, when a StatefulSet-managed replica disappears, either because the
StatefulSet is reducing its replica count, or because its StatefulSet is deleted, the PVC and its
backing volume remains and must be manually deleted. While this behavior is appropriate when the
data is critical, in many cases the persistent data in these PVCs is either temporary, or can be
reconstructed from another source. In those cases, PVCs and their backing volumes remaining after
their StatefulSet or replicas have been deleted are not necessary, incur cost, and require manual
cleanup.
-->
在这个新特性之前，当一个 StatefulSet 管理的副本消失时，无论是因为 StatefulSet 减少了它的副本数，
还是因为它的 StatefulSet 被删除了，PVC 及其下层的卷仍然存在，需要手动删除。
当存储数据比较重要时，这样做是合理的，但在许多情况下，这些 PVC 中的持久化数据要么是临时的，
要么可以从另一个源端重建。在这些情况下，删除 StatefulSet 或减少副本后留下的 PVC 及其下层的卷是不必要的，
还会产生成本，需要手动清理。
<!--
## The new StatefulSet PVC retention policy
-->
## 新的 StatefulSet PVC 保留策略
<!--
If you enable the alpha feature, a StatefulSet spec includes a PersistentVolumeClaim retention
policy. This is used to control if and when PVCs created from a StatefulSet’s `volumeClaimTemplate`
are deleted. This first iteration of the retention policy contains two situations where PVCs may be
deleted.
-->
如果你启用这个新 alpha 特性，StatefulSet 规约中就可以包含 PersistentVolumeClaim 的保留策略。
该策略用于控制是否以及何时删除基于 StatefulSet 的 `volumeClaimTemplate` 属性所创建的 PVCs。
保留策略的首次迭代包含两种可能删除 PVC 的情况。
<!--
The first situation is when the StatefulSet resource is deleted (which implies that all replicas are
also deleted). This is controlled by the `whenDeleted` policy. The second situation, controlled by
`whenScaled` is when the StatefulSet is scaled down, which removes some but not all of the replicas
in a StatefulSet. In both cases the policy can either be `Retain`, where the corresponding PVCs are
not touched, or `Delete`, which means that PVCs are deleted. The deletion is done with a normal
[object deletion](/docs/concepts/architecture/garbage-collection/), so that, for example, all
retention policies for the underlying PV are respected.
-->
第一种情况是 StatefulSet 资源被删除时（这意味着所有副本也被删除），这由 `whenDeleted` 策略控制的。
第二种情况是 StatefulSet 缩小时，即删除 StatefulSet 部分副本，这由 `whenScaled` 策略控制。
在这两种情况下，策略即可以是 `Retain` 不涉及相应 PVCs 的改变，也可以是 `Delete` 即删除对应的 PVCs。
删除是通过普通的[对象删除](/zh/docs/concepts/architecture/garbage-collection/)完成的，
因此，的所有保留策略都会被遵照执行。
<!--
This policy forms a matrix with four cases. I’ll walk through and give an example for each one.
-->
该策略形成包含四种情况的矩阵。我将逐一介绍，并为每一种情况给出一个例子。
<!--
* **`whenDeleted` and `whenScaled` are both `Retain`.** This matches the existing behavior for
StatefulSets, where no PVCs are deleted. This is also the default retention policy. It’s
appropriate to use when data on StatefulSet volumes may be irreplaceable and should only be
deleted manually.
-->
* **`whenDeleted` 和 `whenScaled` 都是 `Retain`。** 这与 StatefulSets 的现有行为一致，
即不删除 PVCs。 这也是默认的保留策略。它适用于 StatefulSet
卷上的数据是不可替代的且只能手动删除的情况。
<!--
* **`whenDeleted` is `Delete` and `whenScaled` is `Retain`.** In this case, PVCs are deleted only when
the entire StatefulSet is deleted. If the StatefulSet is scaled down, PVCs are not touched,
meaning they are available to be reattached if a scale-up occurs with any data from the previous
replica. This might be used for a temporary StatefulSet, such as in a CI instance or ETL
pipeline, where the data on the StatefulSet is needed only during the lifetime of the
StatefulSet lifetime, but while the task is running the data is not easily reconstructible. Any
retained state is needed for any replicas that scale down and then up.
-->
* **`whenDeleted` 是 `Delete` 但 `whenScaled` 是 `Retain`。** 在这种情况下，
只有当整个 StatefulSet 被删除时，PVCs 才会被删除。
如果减少 StatefulSet 副本，PVCs 不会删除，这意味着如果增加副本时，可以从前一个副本重新连接所有数据。
这可能用于临时的 StatefulSet，例如在 CI 实例或 ETL 管道中，
StatefulSet 上的数据仅在 StatefulSet 生命周期内才需要，但在任务运行时数据不易重构。
任何保留状态对于所有先缩小后扩大的副本都是必需的。
<!--
* **`whenDeleted` and `whenScaled` are both `Delete`.** PVCs are deleted immediately when their
replica is no longer needed. Note this does not include when a Pod is deleted and a new version
rescheduled, for example when a node is drained and Pods need to migrate elsewhere. The PVC is
deleted only when the replica is no longer needed as signified by a scale-down or StatefulSet
deletion. This use case is for when data does not need to live beyond the life of its
replica. Perhaps the data is easily reconstructable and the cost savings of deleting unused PVCs
is more important than quick scale-up, or perhaps that when a new replica is created, any data
from a previous replica is not usable and must be reconstructed anyway.
-->
* **`whenDeleted` 和 `whenScaled` 都是 `Delete`。** 当其副本不再被需要时，PVCs 会立即被删除。
注意，这并不包括 Pod 被删除且有新版本被调度的情况，例如当节点被腾空而 Pod 需要迁移到别处时。
只有当副本不再被需要时，如按比例缩小或删除 StatefulSet 时，才会删除 PVC。
此策略适用于数据生命周期短于副本生命周期的情况。即数据很容易重构，
且删除未使用的 PVC 所节省的成本比快速增加副本更重要，或者当创建一个新的副本时，
来自以前副本的任何数据都不可用，必须重新构建。
<!--
* **`whenDeleted` is `Retain` and `whenScaled` is `Delete`.** This is similar to the previous case,
when there is little benefit to keeping PVCs for fast reuse during scale-up. An example of a
situation where you might use this is an Elasticsearch cluster. Typically you would scale that
workload up and down to match demand, whilst ensuring a minimum number of replicas (for example:
3). When scaling down, data is migrated away from removed replicas and there is no benefit to
retaining those PVCs. However, it can be useful to bring the entire Elasticsearch cluster down
temporarily for maintenance. If you need to take the Elasticsearch system offline, you can do
this by temporarily deleting the StatefulSet, and then bringing the Elasticsearch cluster back
by recreating the StatefulSet. The PVCs holding the Elasticsearch data will still exist and the
new replicas will automatically use them.
-->
* **`whenDeleted` 是 `Retain` 但 `whenScaled` 是 `Delete`。** 这与前一种情况类似，
在增加副本时用保留的 PVCs 快速重构几乎没有什么益处。例如 Elasticsearch 集群就是使用的这种方式。
通常，你需要增大或缩小工作负载来满足业务诉求，同时确保最小数量的副本（例如：3）。
当减少副本时，数据将从已删除的副本迁移出去，保留这些 PVCs 没有任何用处。
但是，这对临时关闭整个 Elasticsearch 集群进行维护时是很有用的。
如果需要使 Elasticsearch 系统脱机，可以通过临时删除 StatefulSet 来实现，
然后通过重新创建 StatefulSet 来恢复 Elasticsearch 集群。
保存 Elasticsearch 数据的 PVCs 不会被删除，新的副本将自动使用它们。
<!--
Visit the
[documentation](docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies) to
see all the details.
-->
查阅[文档](/zh/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies)
获取更多详细信息。
<!--
## What’s next?
-->
## 下一步是什么？
<!--
Enable the feature and try it out! Enable the `StatefulSetAutoDeletePVC` feature gate on a cluster,
then create a StatefulSet using the new policy. Test it out and tell us what you think!
-->
启用该功能并尝试一下！在集群上启用 `StatefulSetAutoDeletePVC` 功能，然后使用新策略创建 StatefulSet。
测试一下，告诉我们你的体验！
<!--
I'm very curious to see if this owner reference mechanism works well in practice. For example, we
realized there is no mechanism in Kubernetes for knowing who set a reference, so it’s possible that
the StatefulSet controller may fight with custom controllers that set their own
references. Fortunately, maintaining the existing retention behavior does not involve any new owner
references, so default behavior will be compatible.
-->
我很好奇这个属主引用机制在实践中是否有效。例如，我们意识到 Kubernetes 中没有可以知道谁设置了引用的机制，
因此 StatefulSet 控制器可能会与设置自己的引用的自定义控制器发生冲突。
幸运的是，维护现有的保留行为不涉及任何新属主引用，因此默认行为是兼容的。
<!--
Please tag any issues you report with the label `sig/apps` and assign them to Matthew Cary
([@mattcary](https://github.com/mattcary) at GitHub).
-->
请用标签 `sig/apps` 标记你报告的任何问题，并将它们分配给 Matthew Cary
(在 GitHub上 [@mattcary](https://github.com/mattcary))。
<!--
Enjoy!
-->
尽情体验吧！

373
content/zh/blog/_posts/2022-02-17-updated-dockershim-faq.md Normal file
View File

@ -0,0 +1,373 @@
---
layout: blog
title: "更新：弃用 Dockershim 的常见问题"
date: 2022-02-17
slug: dockershim-faq
aliases: [ '/dockershim' ]
---
<!--
layout: blog
title: "Updated: Dockershim Removal FAQ"
date: 2022-02-17
slug: dockershim-faq
aliases: [ '/dockershim' ]
-->
<!--
**This is an update to the original [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/) article,
published in late 2020.**
-->
**本文是针对2020年末发布的[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)的博客更新。**
<!--
This document goes over some frequently asked questions regarding the
deprecation and removal of _dockershim_, that was
[announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/)
as a part of the Kubernetes v1.20 release. For more detail
on what that means, check out the blog post
[Don't Panic: Kubernetes and Docker](/blog/2020/12/02/dont-panic-kubernetes-and-docker/).
-->
本文回顾了自 Kubernetes v1.20 版本[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)弃用
Dockershim 以来所引发的一些常见问题。关于弃用细节以及这些细节背后的含义，请参考博文
[别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。
<!--
Also, you can read [check whether dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)
to determine how much impact the removal of dockershim would have for you
or for your organization.
-->
你还可以查阅：[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)这篇文章，
以确定弃用 dockershim 会对你或你的组织带来多大的影响。
<!--
As the Kubernetes 1.24 release has become imminent, we've been working hard to try to make this a smooth transition.
-->
随着 Kubernetes 1.24 版本的发布迫在眉睫，我们一直在努力尝试使其能够平稳升级顺利过渡。
<!--
- We've written a blog post detailing our [commitment and next steps](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/).
- We believe there are no major blockers to migration to [other container runtimes](/docs/setup/production-environment/container-runtimes/#container-runtimes).
- There is also a [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) guide available.
- We've also created a page to list
[articles on dockershim removal and on using CRI-compatible runtimes](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/).
That list includes some of the already mentioned docs, and also covers selected external sources
(including vendor guides).
-->
- 我们已经写了一篇博文，详细说明了我们的[承诺和后续操作](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)。
- 我们我们相信可以无障碍的迁移到其他[容器运行时](/zh/docs/setup/production-environment/container-runtimes/#container-runtimes)。
- 我们撰写了 [dockershim 迁移指南](/docs/tasks/administer-cluster/migrating-from-dockershim/)供你参考。
- 我们还创建了一个页面来列出[有关 dockershim 移除和使用 CRI 兼容运行时的文章](/zh/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。
该列表包括一些已经提到的文档，还涵盖了选定的外部资源（包括供应商指南）。
<!--
### Why is the dockershim being removed from Kubernetes?
-->
### 为什么会从 Kubernetes 中移除 dockershim ？
<!--
Early versions of Kubernetes only worked with a specific container runtime:
Docker Engine. Later, Kubernetes added support for working with other container runtimes.
The CRI standard was [created](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) to
enable interoperability between orchestrators (like Kubernetes) and many different container
runtimes.
Docker Engine doesn't implement that interface (CRI), so the Kubernetes project created
special code to help with the transition, and made that _dockershim_ code part of Kubernetes
itself.
-->
Kubernetes 的早期版本仅适用于特定的容器运行时：Docker Engine。
后来，Kubernetes 增加了对使用其他容器运行时的支持。[创建](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) CRI
标准是为了实现编排器（如 Kubernetes）和许多不同的容器运行时之间交互操作。
Docker Engine 没有实现（CRI）接口，因此 Kubernetes 项目创建了特殊代码来帮助过渡，
并使 dockershim 代码成为 Kubernetes 的一部分。
<!--
The dockershim code was always intended to be a temporary solution (hence the name: shim).
You can read more about the community discussion and planning in the
[Dockershim Removal Kubernetes Enhancement Proposal][drkep].
In fact, maintaining dockershim had become a heavy burden on the Kubernetes maintainers.
-->
dockershim 代码一直是一个临时解决方案（因此得名：shim）。
你可以阅读 [Kubernetes 移除 Dockershim 增强方案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim)
以了解相关的社区讨论和计划。
事实上，维护 dockershim 已经成为 Kubernetes 维护者的沉重负担。
<!--
Additionally, features that were largely incompatible with the dockershim, such
as cgroups v2 and user namespaces are being implemented in these newer CRI
runtimes. Removing support for the dockershim will allow further development in
those areas.
-->
此外，在较新的 CRI 运行时中实现了与 dockershim 不兼容的功能，例如 cgroups v2 和用户命名空间。
取消对 dockershim 的支持将加速这些领域的发展。
<!--
### Can I still use Docker Engine in Kubernetes 1.23?
-->
### 在 Kubernetes 1.23 版本中还可以使用 Docker Engine 吗？
<!--
Yes, the only thing changed in 1.20 is a single warning log printed at [kubelet]
startup if using Docker Engine as the runtime. You'll see this warning in all versions up to 1.23. The dockershim removal occurs in Kubernetes 1.24.
-->
可以使用，在 1.20 版本中唯一的改动是，如果使用 Docker Engine，
在 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/)
启动时会打印一个警告日志。
你将在 1.23 版本及以前版本看到此警告。dockershim 将在 Kubernetes 1.24 版本中移除 。
<!--
### When will dockershim be removed?
-->
### 什么时候移除 dockershim ？
<!--
Given the impact of this change, we are using an extended deprecation timeline.
Removal of dockershim is scheduled for Kubernetes v1.24, see [Dockershim Removal Kubernetes Enhancement Proposal][drkep].
The Kubernetes project will be working closely with vendors and other ecosystem groups to ensure
a smooth transition and will evaluate things as the situation evolves.
-->
考虑到此变更带来的影响，我们使用了一个加长的废弃时间表。
dockershim 计划在 Kubernetes v1.24 中进行移除，
参见 [Kubernetes 移除 Dockershim 增强方案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim)。
Kubernetes 项目将与供应商和其他生态系统组织密切合作，以确保平稳过渡，并将依据事态的发展评估后续事项。
<!--
### Can I still use Docker Engine as my container runtime?
-->
### 我还可以使用 Docker Engine 作为我的容器运行时吗？
<!--
First off, if you use Docker on your own PC to develop or test containers: nothing changes.
You can still use Docker locally no matter what container runtime(s) you use for your
Kubernetes clusters. Containers make this kind of interoperability possible.
-->
首先，如果你在自己的电脑上使用 Docker 用来做开发或测试容器：它将与之前没有任何变化。
无论你为 Kubernetes 集群使用什么容器运行时，你都可以在本地使用 Docker。容器使这种交互成为可能。
<!--
Mirantis and Docker have [committed][mirantis] to maintaining a replacement adapter for
Docker Engine, and to maintain that adapter even after the in-tree dockershim is removed
from Kubernetes. The replacement adapter is named [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd).
-->
Mirantis 和 Docker 已[承诺](https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/)
为 Docker Engine 维护一个替代适配器，
并在 dockershim 从 Kubernetes 移除后维护该适配器。
替代适配器名为 [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)。
<!--
### Will my existing container images still work?
-->
### 我现有的容器镜像还能正常工作吗？
<!--
Yes, the images produced from `docker build` will work with all CRI implementations.
All your existing images will still work exactly the same.
-->
当然可以，`docker build` 创建的镜像适用于任何 CRI 实现。
所有你的现有镜像将和往常一样工作。
<!--
#### What about private images?
-->
### 私有镜像呢？
<!--
Yes. All CRI runtimes support the same pull secrets configuration used in
Kubernetes, either via the PodSpec or ServiceAccount.
-->
当然可以。所有 CRI 运行时均支持在 Kubernetes 中相同的拉取（pull）Secret 配置，
无论是通过 PodSpec 还是 ServiceAccount。
<!--
### Are Docker and containers the same thing?
-->
### Docker 和容器是一回事吗？
<!--
Docker popularized the Linux containers pattern and has been instrumental in
developing the underlying technology, however containers in Linux have existed
for a long time. The container ecosystem has grown to be much broader than just
Docker. Standards like OCI and CRI have helped many tools grow and thrive in our
ecosystem, some replacing aspects of Docker while others enhance existing
functionality.
-->
Docker 普及了 Linux 容器模式，并在开发底层技术方面发挥了重要作用，
但是 Linux 中的容器已经存在了很长时间。容器的生态相比于 Docker 具有更宽广的领域。
OCI 和 CRI 等标准帮助许多工具在我们的生态系统中发展壮大，
其中一些替代了 Docker 的某些方面，而另一些则增强了现有功能。
<!--
### Are there examples of folks using other runtimes in production today?
-->
### 现在是否有在生产系统中使用其他运行时的例子？
<!--
All Kubernetes project produced artifacts (Kubernetes binaries) are validated
with each release.
-->
Kubernetes 所有项目在所有版本中出产的工件（Kubernetes 二进制文件）都经过了验证。
<!--
Additionally, the [kind] project has been using containerd for some time and has
seen an improvement in stability for its use case. Kind and containerd are leveraged
multiple times every day to validate any changes to the Kubernetes codebase. Other
related projects follow a similar pattern as well, demonstrating the stability and
usability of other container runtimes. As an example, OpenShift 4.x has been
using the [CRI-O] runtime in production since June 2019.
-->
此外，[kind](https://kind.sigs.k8s.io/) 项目使用 containerd 已经有一段时间了，并且提高了其用例的稳定性。
Kind 和 containerd 每天都会被多次使用来验证对 Kubernetes 代码库的任何更改。
其他相关项目也遵循同样的模式，从而展示了其他容器运行时的稳定性和可用性。
例如，OpenShift 4.x 从 2019 年 6 月以来，就一直在生产环境中使用 [CRI-O](https://cri-o.io/) 运行时。
<!--
For other examples and references you can look at the adopters of containerd and
CRI-O, two container runtimes under the Cloud Native Computing Foundation ([CNCF]).
-->
至于其他示例和参考资料，你可以查看 containerd 和 CRI-O 的使用者列表，
这两个容器运行时是云原生基金会（[CNCF](https://cncf.io)）下的项目。
- [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md)
- [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md)
<!--
### People keep referencing OCI, what is that?
-->
### 人们总在谈论 OCI，它是什么？
<!--
OCI stands for the [Open Container Initiative], which standardized many of the
interfaces between container tools and technologies. They maintain a standard
specification for packaging container images (OCI image-spec) and running containers
(OCI runtime-spec). They also maintain an actual implementation of the runtime-spec
in the form of [runc], which is the underlying default runtime for both
[containerd] and [CRI-O]. The CRI builds on these low-level specifications to
provide an end-to-end standard for managing containers.
-->
OCI 是 [Open Container Initiative](https://opencontainers.org/about/overview/) 的缩写，
它标准化了容器工具和底层实现之间的大量接口。
它们维护了打包容器镜像（OCI image）和运行时（OCI runtime）的标准规范。
它们还以 [runc](https://github.com/opencontainers/runc) 的形式维护了一个 runtime-spec 的真实实现，
这也是 [containerd](https://containerd.io/) 和 [CRI-O](https://cri-o.io/) 依赖的默认运行时。
CRI 建立在这些底层规范之上，为管理容器提供端到端的标准。
<!--
### Which CRI implementation should I use?
-->
### 我应该用哪个 CRI 实现？
<!--
That’s a complex question and it depends on a lot of factors. If Docker is
working for you, moving to containerd should be a relatively easy swap and
will have strictly better performance and less overhead. However, we encourage you
to explore all the options from the [CNCF landscape] in case another would be an
even better fit for your environment.
-->
这是一个复杂的问题，依赖于许多因素。
如果你正在使用 Docker，迁移到 containerd 应该是一个相对容易地转换，并将获得更好的性能和更少的开销。
然而，我们鼓励你探索 [CNCF landscape](https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category)
提供的所有选项，做出更适合你的选择。
<!--
### What should I look out for when changing CRI implementations?
-->
### 当切换 CRI 实现时，应该注意什么？
<!--
While the underlying containerization code is the same between Docker and most
CRIs (including containerd), there are a few differences around the edges. Some
common things to consider when migrating are:
-->
虽然 Docker 和大多数 CRI（包括 containerd）之间的底层容器化代码是相同的，
但其周边部分却存在差异。迁移时要考虑如下常见事项：
<!--
- Logging configuration
- Runtime resource limitations
- Node provisioning scripts that call docker or use docker via it's control socket
- Kubectl plugins that require docker CLI or the control socket
- Tools from the Kubernetes project that require direct access to Docker Engine
(for example: the deprecated `kube-imagepuller` tool)
- Configuration of functionality like `registry-mirrors` and insecure registries
- Other support scripts or daemons that expect Docker Engine to be available and are run
outside of Kubernetes (for example, monitoring or security agents)
- GPUs or special hardware and how they integrate with your runtime and Kubernetes
-->
- 日志配置
- 运行时的资源限制
- 调用 docker 或通过其控制套接字使用 docker 的节点配置脚本
- 需要访问 docker 命令或控制套接字的 kubectl 插件
- 需要直接访问 Docker Engine 的 Kubernetes 工具（例如：已弃用的 'kube-imagepuller' 工具）
- `registry-mirrors` 和不安全注册表等功能的配置
- 保障 Docker Engine 可用、且运行在 Kubernetes 之外的脚本或守护进程（例如：监视或安全代理）
- GPU 或特殊硬件，以及它们如何与你的运行时和 Kubernetes 集成
<!--
If you use Kubernetes resource requests/limits or file-based log collection
DaemonSets then they will continue to work the same, but if you’ve customized
your `dockerd` configuration, you’ll need to adapt that for your new container
runtime where possible.
-->
如果你只是用了 Kubernetes 资源请求/限制或基于文件的日志收集 DaemonSet，它们将继续稳定工作，
但是如果你用了自定义了 dockerd 配置，则可能需要为新的容器运行时做一些适配工作。
<!--
Another thing to look out for is anything expecting to run for system maintenance
or nested inside a container when building images will no longer work. For the
former, you can use the [`crictl`][cr] tool as a drop-in replacement (see [mapping from docker cli to crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) and for the
latter you can use newer container build options like [img], [buildah],
[kaniko], or [buildkit-cli-for-kubectl] that don’t require Docker.
-->
另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。
对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案
(参阅[从 docker cli 到 crictl 的映射](/zh/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl))。
对于后者，可以用新的容器创建选项，例如
[img](https://github.com/genuinetools/img)、
[buildah](https://github.com/containers/buildah)、
[kaniko](https://github.com/GoogleContainerTools/kaniko) 或
[buildkit-cli-for-kubectl](https://github.com/vmware-tanzu/buildkit-cli-for-kubectl)，
他们都不需要 Docker。
<!--
For containerd, you can start with their [documentation] to see what configuration
options are available as you migrate things over.
-->
对于 containerd，你可查阅有关它的[文档](https://github.com/containerd/cri/blob/master/docs/registry.md)，
获取迁移时可用的配置选项。
<!--
For instructions on how to use containerd and CRI-O with Kubernetes, see the
Kubernetes documentation on [Container Runtimes]
-->
有关如何在 Kubernetes 中使用 containerd 和 CRI-O 的说明，
请参阅 [Kubernetes 相关文档](/docs/setup/production-environment/container-runtimes/)
<!--
### What if I have more questions?
-->
### 我还有其他问题怎么办？
<!--
If you use a vendor-supported Kubernetes distribution, you can ask them about
upgrade plans for their products. For end-user questions, please post them
to our end user community forum: https://discuss.kubernetes.io/.
-->
如果你使用了供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。
对于最终用户的问题，请把问题发到我们的最终用户社区的论坛：https://discuss.kubernetes.io/。
<!--
You can also check out the excellent blog post
[Wait, Docker is deprecated in Kubernetes now?][dep] a more in-depth technical
discussion of the changes.
-->
你也可以看看这篇优秀的博客文章：[等等，Docker 被 Kubernetes 弃用了?](https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m)
对这些变化进行更深入的技术讨论。
<!--
### Can I have a hug?
-->
### 我可以加入吗？
<!--
Yes, we're still giving hugs as requested. 🤗🤗🤗
-->
当然，只要你愿意，随时随地欢迎。🤗🤗🤗

180
content/zh/blog/_posts/2022-03-15-meet-our-contributors-APAC-AU-NZ-region-01.md Normal file
View File

@ -0,0 +1,180 @@
---
layout: blog
title: "认识我们的贡献者 - 亚太地区（澳大利亚-新西兰地区）"
date: 2022-03-16T12:00:00+0000
slug: meet-our-contributors-au-nz-ep-02
canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
---
<!--
layout: blog
title: "Meet Our Contributors - APAC (Aus-NZ region)"
date: 2022-03-16T12:00:00+0000
slug: meet-our-contributors-au-nz-ep-02
canonicalUrl: https://www.kubernetes.dev/blog/2022/03/14/meet-our-contributors-au-nz-ep-02/
-->
<!--
**Authors & Interviewers:** [Anubhav Vardhan](https://github.com/anubha-v-ardhan), [Atharva Shinde](https://github.com/Atharva-Shinde), [Avinesh Tripathi](https://github.com/AvineshTripathi), [Brad McCoy](https://github.com/bradmccoydev), [Debabrata Panigrahi](https://github.com/Debanitrkl), [Jayesh Srivastava](https://github.com/jayesh-srivastava), [Kunal Verma](https://github.com/verma-kunal), [Pranshu Srivastava](https://github.com/PranshuSrivastava), [Priyanka Saggu](github.com/Priyankasaggu11929/), [Purneswar Prasad](https://github.com/PurneswarPrasad), [Vedant Kakde](https://github.com/vedant-kakde)
-->
**作者和采访者：**
[Anubhav Vardhan](https://github.com/anubha-v-ardhan),
[Atharva Shinde](https://github.com/Atharva-Shinde),
[Avinesh Tripathi](https://github.com/AvineshTripathi),
[Brad McCoy](https://github.com/bradmccoydev),
[Debabrata Panigrahi](https://github.com/Debanitrkl),
[Jayesh Srivastava](https://github.com/jayesh-srivastava),
[Kunal Verma](https://github.com/verma-kunal),
[Pranshu Srivastava](https://github.com/PranshuSrivastava),
[Priyanka Saggu](github.com/Priyankasaggu11929/),
[Purneswar Prasad](https://github.com/PurneswarPrasad),
[Vedant Kakde](https://github.com/vedant-kakde)
---
<!--
Good day, everyone 👋
-->
大家好👋
<!--
Welcome back to the second episode of the "Meet Our Contributors" blog post series for APAC.
-->
欢迎来到亚太地区的”认识我们的贡献者”博文系列第二期。
<!--
This post will feature four outstanding contributors from the Australia and New Zealand regions, who have played diverse leadership and community roles in the Upstream Kubernetes project.
-->
这篇文章将介绍来自澳大利亚和新西兰地区的四位杰出贡献者，
他们在上游 Kubernetes 项目中承担着不同子项目的领导者和社区贡献者的角色。
<!--
So, without further ado, let's get straight to the blog.
-->
闲话少说，让我们直接进入主题。
## [Caleb Woodbine](https://github.com/BobyMCbobs)
<!--
Caleb Woodbine is currently a member of the ii.nz organisation.
-->
Caleb Woodbine 目前是 ii.nz 组织的成员。
<!--
He began contributing to the Kubernetes project in 2018 as a member of the Kubernetes Conformance working group. His experience was positive, and he benefited from early guidance from [Hippie Hacker](https://github.com/hh), a fellow contributor from New Zealand.
-->
他于 2018 年作为 Kubernetes Conformance 工作组的成员开始为 Kubernetes 项目做贡献。
他积极向上，他从一位来自新西兰的贡献者 [Hippie Hacker](https://github.com/hh) 的早期指导中受益匪浅。
<!--
He has made major contributions to Kubernetes project since then through `SIG k8s-infra` and `k8s-conformance` working group.
-->
他在 `SIG k8s-infra` 和 `k8s-conformance` 工作组为 Kubernetes 项目做出了重大贡献。
<!--
Caleb is also a co-organizer of the [CloudNative NZ](https://www.meetup.com/cloudnative-nz/) community events, which aim to expand the reach of Kubernetes project throughout New Zealand in order to encourage technical education and improved employment opportunities.
-->
Caleb 也是 [CloudNative NZ](https://www.meetup.com/cloudnative-nz/)
社区活动的联合组织者，该活动旨在扩大 Kubernetes 项目在整个新西兰的影响力，以鼓励科技教育和改善就业机会。
<!--
> _There need to be more outreach in APAC and the educators and universities must pick up Kubernetes, as they are very slow and about 8+ years out of date. NZ tends to rather pay overseas than educate locals on the latest cloud tech Locally._
-->
> _亚太地区需要更多的外联活动，教育工作者和大学必须学习 Kubernetes，因为他们非常缓慢，
而且已经落后了8年多。新西兰倾向于在海外付费，而不是教育当地人最新的云技术。_
## [Dylan Graham](https://github.com/DylanGraham)
<!--
Dylan Graham is a cloud engineer from Adeliade, Australia. He has been contributing to the upstream Kubernetes project since 2018.
-->
Dylan Graham 是来自澳大利亚 Adeliade 的云计算工程师。自 2018 年以来，他一直在为上游 Kubernetes 项目做出贡献。
<!--
He stated that being a part of such a large-scale project was initially overwhelming, but that the community's friendliness and openness assisted him in getting through it.
-->
他表示，成为如此大项目的一份子，最初压力是比较大的，但社区的友好和开放帮助他度过了难关。
<!--
He began by contributing to the project documentation and is now mostly focused on the community support for the APAC region.
-->
开始在项目文档方面做贡献，现在主要致力于为亚太地区提供社区支持。
<!--
He believes that consistent attendance at community/project meetings, taking on project tasks, and seeking community guidance as needed can help new aspiring developers become effective contributors.
-->
他相信，持续参加社区/项目会议，承担项目任务，并在需要时寻求社区指导，可以帮助有抱负的新开发人员成为有效的贡献者。
<!--
> _The feeling of being a part of a large community is really special. I've met some amazing people, even some before the pandemic in real life :)_
-->
> _成为大社区的一份子感觉真的很特别。我遇到了一些了不起的人，甚至是在现实生活中疫情发生之前。_
## [Hippie Hacker](https://github.com/hh)
<!--
Hippie has worked for the CNCF.io as a Strategic Initiatives contractor from New Zealand for almost 5+ years. He is an active contributor to k8s-infra, API conformance testing, Cloud provider conformance submissions, and apisnoop.cncf.io domains of the upstream Kubernetes & CNCF projects.
-->
Hippie 来自新西兰，曾在 CNCF.io 作为战略计划承包商工作 5 年多。他是 k8s-infra、
API 一致性测试、云提供商一致性提交以及上游 Kubernetes 和 CNCF 项目 apisnoop.cncf.io 域的积极贡献者。
<!--
He recounts their early involvement with the Kubernetes project, which began roughly 5 years ago when their firm, ii.nz, demonstrated [network booting from a Raspberry Pi using PXE and running Gitlab in-cluster to install Kubernetes on servers](https://ii.nz/post/bringing-the-cloud-to-your-community/).
-->
他讲述了他们早期参与 Kubernetes 项目的情况，该项目始于大约 5 年前，当时他们的公司 ii.nz
演示了[使用 PXE 从 Raspberry Pi 启动网络，并在集群中运行Gitlab，以便在服务器上安装 Kubernetes ](https://ii.nz/post/bringing-the-cloud-to-your-community/)
<!--
He describes their own contributing experience as someone who, at first, tried to do all of the hard lifting on their own, but eventually saw the benefit of group contributions which reduced burnout and task division which allowed folks to keep moving forward on their own momentum.
-->
他描述了自己的贡献经历：一开始，他试图独自完成所有艰巨的任务，但最终看到了团队协作贡献的好处，
分工合作减少了过度疲劳，这让人们能够凭借自己的动力继续前进。
<!--
He recommends that new contributors use pair programming.
-->
他建议新的贡献者结对编程。
<!--
> _The cross pollination of approaches and two pairs of eyes on the same work can often yield a much more amplified effect than a PR comment / approval alone can afford._
-->
> _针对一个项目，多人关注和交叉交流往往比单独的评审、批准 PR 能产生更大的效果。_
## [Nick Young](https://github.com/youngnick)
<!--
Nick Young works at VMware as a technical lead for Contour, a CNCF ingress controller. He was active with the upstream Kubernetes project from the beginning, and eventually became the chair of the LTS working group, where he advocated user concerns. He is currently the SIG Network Gateway API subproject's maintainer.
-->
Nick Young 在 VMware 工作，是 CNCF 入口控制器 Contour 的技术负责人。
他从一开始就积极参与上游 Kubernetes 项目，最终成为 LTS 工作组的主席，
他提倡关注用户。他目前是 SIG Network Gateway API 子项目的维护者。
<!--
His contribution path was notable in that he began working on major areas of the Kubernetes project early on, skewing his trajectory.
-->
他的贡献之路是引人注目的，因为他很早就在 Kubernetes 项目的主要领域工作，这改变了他的轨迹。
<!--
He asserts the best thing a new contributor can do is to "start contributing". Naturally, if it is relevant to their employment, that is excellent; however, investing non-work time in contributing can pay off in the long run in terms of work. He believes that new contributors, particularly those who are currently Kubernetes users, should be encouraged to participate in higher-level project discussions.
-->
他断言，一个新贡献者能做的最好的事情就是“开始贡献”。当然，如果与他的工作息息相关，那好极了;
然而，把非工作时间投入到贡献中去，从长远来看可以在工作上获得回报。
他认为，应该鼓励新的贡献者，特别是那些目前是 Kubernetes 用户的人，参与到更高层次的项目讨论中来。
<!--
> _Just being active and contributing will get you a long way. Once you've been active for a while, you'll find that you're able to answer questions, which will mean you're asked questions, and before you know it you are an expert._
-->
> _只要积极主动，做出贡献，你就可以走很远。一旦你活跃了一段时间，你会发现你能够解答别人的问题，
这意味着会有人请教你或和你讨论，在你意识到这一点之前，你就已经是专家了。_
---
<!--
If you have any recommendations/suggestions for who we should interview next, please let us know in #sig-contribex. Your suggestions would be much appreciated. We're thrilled to have additional folks assisting us in reaching out to even more wonderful individuals of the community.
-->
如果你对我们接下来应该采访的人有任何意见/建议，请在 #sig-contribex 中告知我们。
非常感谢你的建议。我们很高兴有更多的人帮助我们接触到社区中更优秀的人。
<!--
We'll see you all in the next one. Everyone, till then, have a happy contributing! 👋
-->
我们下期再见。祝你有个愉快的贡献之旅!👋

6
content/zh/community/static/README.md
View File

@ -1,5 +1,9 @@
<!-- The files in this directory have been imported from other sources. Do not
edit them directly, except by replacing them with new versions. -->
edit them directly, except by replacing them with new versions.
Localization note: you do not need to create localized versions of any of
the files in this directory.
-->
本路径下的文件从其它地方导入。
除了版本更新，不要直接修改。
本地化说明：你无需为此目录中的任何文件创建本地化版本。

Some files were not shown because too many files have changed in this diff Show More