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

This commit is contained in:
Seth McCombs
2022-07-21 13:48:12 -07:00
135 changed files with 14957 additions and 2026 deletions
@@ -332,7 +332,7 @@ container of a Pod can specify either or both of the following:
Limits and requests for `ephemeral-storage` are measured in byte quantities.
You can express storage as a plain integer or as a fixed-point number using one of these suffixes:
E, P, T, G, M, K. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
E, P, T, G, M, k. You can also use the power-of-two equivalents: Ei, Pi, Ti, Gi,
Mi, Ki. For example, the following quantities all represent roughly the same value:
- `128974848`
@@ -340,6 +340,10 @@ Mi, Ki. For example, the following quantities all represent roughly the same val
- `129M`
- `123Mi`
Pay attention to the case of the suffixes. If you request `400m` of ephemeral-storage, this is a request
for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
or 400 megabytes (`400M`).
In the following example, the Pod has two containers. Each container has a request of
2GiB of local ephemeral storage. Each container has a limit of 4GiB of local ephemeral
storage. Therefore, the Pod has a request of 4GiB of local ephemeral storage, and
@@ -85,11 +85,15 @@ The kubelet supports the following filesystem partitions:
Kubelet auto-discovers these filesystems and ignores other filesystems. Kubelet
does not support other configurations.
{{<note>}}
Some kubelet garbage collection features are deprecated in favor of eviction.
For a list of the deprecated features, see
[kubelet garbage collection deprecation](/docs/concepts/architecture/garbage-collection/#deprecation).
{{</note>}}
Some kubelet garbage collection features are deprecated in favor of eviction:
| Existing Flag | New Flag | Rationale |
| ------------- | -------- | --------- |
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
### Eviction thresholds
@@ -558,7 +558,7 @@ If the access modes are specified as ReadWriteOncePod, the volume is constrained
| AzureFile | &#x2713; | &#x2713; | &#x2713; | - |
| AzureDisk | &#x2713; | - | - | - |
| CephFS | &#x2713; | &#x2713; | &#x2713; | - |
| Cinder | &#x2713; | - | - | - |
| Cinder | &#x2713; | - | ([if multi-attach volumes are available](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/features.md#multi-attach-volumes)) | - |
| CSI | depends on the driver | depends on the driver | depends on the driver | depends on the driver |
| FC | &#x2713; | &#x2713; | - | - |
| FlexVolume | &#x2713; | &#x2713; | depends on the driver | - |
@@ -73,7 +73,7 @@ volume mount will not receive updates for those volume sources.
## SecurityContext interactions
The [proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the the correct owner permissions set.
The [proposal](https://git.k8s.io/enhancements/keps/sig-storage/2451-service-account-token-volumes#proposal) for file permission handling in projected service account volume enhancement introduced the projected files having the correct owner permissions set.
### Linux
@@ -99,6 +99,7 @@ into their own volume mount outside of `C:\`.
By default, the projected files will have the following ownership as shown for
an example projected volume file:
```powershell
PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List
@@ -111,6 +112,7 @@ Access : NT AUTHORITY\SYSTEM Allow FullControl
Audit :
Sddl : O:BAG:SYD:AI(A;ID;FA;;;SY)(A;ID;FA;;;BA)(A;ID;0x1200a9;;;BU)
```
This implies all administrator users like `ContainerAdministrator` will have
read, write and execute access while, non-administrator users will have read and
execute access.
+1 -1
View File
@@ -132,7 +132,7 @@ section refers to several key workload abstractions and how they map to Windows.
* CronJob
* ReplicationController
* {{< glossary_tooltip text="Services" term_id="service" >}}
See [Load balancing and Services](#load-balancing-and-services) for more details.
See [Load balancing and Services](/docs/concepts/services-networking/windows-networking/#load-balancing-and-services) for more details.
Pods, workload resources, and Services are critical elements to managing Windows
workloads on Kubernetes. However, on their own they are not enough to enable
@@ -71,7 +71,7 @@ Pod Template:
job-name=pi
Containers:
pi:
Image: perl
Image: perl:5.34.0
Port: <none>
Host Port: <none>
Command:
@@ -125,7 +125,7 @@ spec:
- -Mbignum=bpi
- -wle
- print bpi(2000)
image: perl
image: perl:5.34.0
imagePullPolicy: Always
name: pi
resources: {}
@@ -356,7 +356,7 @@ spec:
spec:
containers:
- name: pi
image: perl
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
@@ -402,7 +402,7 @@ spec:
spec:
containers:
- name: pi
image: perl
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
```
@@ -216,16 +216,16 @@ Figure 2. Working from a local fork to make your changes.
1. Decide which branch base to your work on:
- For improvements to existing content, use `upstream/main`.
- For new content about existing features, use `upstream/main`.
- For localized content, use the localization's conventions. For more information, see
[localizing Kubernetes documentation](/docs/contribute/localization/).
- For new features in an upcoming Kubernetes release, use the feature branch. For more
information, see [documenting for a release](/docs/contribute/new-content/new-features/).
- For long-running efforts that multiple SIG Docs contributors collaborate on,
like content reorganization, use a specific feature branch created for that effort.
- For improvements to existing content, use `upstream/main`.
- For new content about existing features, use `upstream/main`.
- For localized content, use the localization's conventions. For more information, see
[localizing Kubernetes documentation](/docs/contribute/localization/).
- For new features in an upcoming Kubernetes release, use the feature branch. For more
information, see [documenting for a release](/docs/contribute/new-content/new-features/).
- For long-running efforts that multiple SIG Docs contributors collaborate on,
like content reorganization, use a specific feature branch created for that effort.
If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
If you need help choosing a branch, ask in the `#sig-docs` Slack channel.
1. Create a new branch based on the branch identified in step 1. This example assumes the base
branch is `upstream/main`:
@@ -234,7 +234,7 @@ Figure 2. Working from a local fork to make your changes.
git checkout -b <my_new_branch> upstream/main
```
3. Make your changes using a text editor.
1. Make your changes using a text editor.
At any time, use the `git status` command to see what files you've changed.
@@ -396,7 +396,7 @@ Figure 3. Steps to open a PR from your fork to the K8s/website.
1. From the **head repository** drop-down menu, select your fork.
1. From the **compare** drop-down menu, select your branch.
1. Select **Create Pull Request**.
`. Add a description for your pull request:
1. Add a description for your pull request:
- **Title** (50 characters or less): Summarize the intent of the change.
- **Description**: Describe the change in more detail.
@@ -484,10 +484,10 @@ conflict. You must resolve all merge conflicts in your PR.
1. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch:
```shell
git fetch upstream
git rebase upstream/main
```
```shell
git fetch upstream
git rebase upstream/main
```
1. Inspect the results of the rebase:
@@ -512,7 +512,7 @@ conflict. You must resolve all merge conflicts in your PR.
1. Continue the rebase:
``
```shell
git rebase --continue
```
@@ -10,9 +10,8 @@ weight: 10
Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls)
section in the Kubernetes website repository to see open pull requests.
Reviewing documentation pull requests is a
great way to introduce yourself to the Kubernetes community.
It helps you learn the code base and build trust with other contributors.
Reviewing documentation pull requests is a great way to introduce yourself to the Kubernetes
community. It helps you learn the code base and build trust with other contributors.
Before reviewing, it's a good idea to:
@@ -28,7 +27,6 @@ Before reviewing, it's a good idea to:
Before you start a review:
- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)
and ensure that you abide by it at all times.
- Be polite, considerate, and helpful.
@@ -73,6 +71,7 @@ class third,fourth white
Figure 1. Review process steps.
1. Go to [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls).
You see a list of every open pull request against the Kubernetes website and docs.
@@ -103,12 +102,20 @@ Figure 1. Review process steps.
4. Go to the **Files changed** tab to start your review.
1. Click on the `+` symbol beside the line you want to comment on.
1. Fill in any comments you have about the line and click either **Add single comment** (if you
have only one comment to make) or **Start a review** (if you have multiple comments to make).
1. Fill in any comments you have about the line and click either **Add single comment**
(if you have only one comment to make) or **Start a review** (if you have multiple comments to make).
1. When finished, click **Review changes** at the top of the page. Here, you can add
a summary of your review (and leave some positive comments for the contributor!),
approve the PR, comment or request changes as needed. New contributors should always
choose **Comment**.
a summary of your review (and leave some positive comments for the contributor!).
Please always use the "Comment"
- Avoid clicking the "Request changes" button when finishing your review.
If you want to block a PR from being merged before some further changes are made,
you can leave a "/hold" comment.
Mention why you are setting a hold, and optionally specify the conditions under
which the hold can be removed by you or other reviewers.
- Avoid clicking the "Approve" button when finishing your review.
Leaving a "/approve" comment is recommended most of the time.
## Reviewing checklist
@@ -361,7 +361,7 @@ Beware.
### Katacoda Embedded Live Environment
This button lets users run Minikube in their browser using the [Katacoda Terminal](https://www.katacoda.com/embed/panel).
This button lets users run Minikube in their browser using the Katacoda Terminal.
It lowers the barrier of entry by allowing users to use Minikube with one click instead of going through the complete
Minikube and Kubectl installation process locally.
@@ -9,7 +9,7 @@ weight: 95
<!-- overview -->
The tables below enumerate the configuration parameters on
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/) objects, whether the field mutates
[PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) objects, whether the field mutates
and/or validates pods, and how the configuration values map to the
[Pod Security Standards](/docs/concepts/security/pod-security-standards/).
@@ -31,9 +31,9 @@ The fields enumerated in this table are part of the `PodSecurityPolicySpec`, whi
under the `.spec` field path.
<table class="no-word-break">
<caption style="display:none">Mapping PodSecurityPolicySpec fields to Pod Security Standards</caption>
<tbody>
<tr>
<caption style="display:none">Mapping PodSecurityPolicySpec fields to Pod Security Standards</caption>
<tbody>
<tr>
<th><code>PodSecurityPolicySpec</code></th>
<th>Type</th>
<th>Pod Security Standards Equivalent</th>
@@ -54,19 +54,19 @@ under the `.spec` field path.
<td>
<p><b>Baseline</b>: subset of</p>
<ul>
<li><code>AUDIT_WRITE</code></li>
<li><code>CHOWN</code></li>
<li><code>DAC_OVERRIDE</code></li>
<li><code>FOWNER</code></li>
<li><code>FSETID</code></li>
<li><code>KILL</code></li>
<li><code>MKNOD</code></li>
<li><code>NET_BIND_SERVICE</code></li>
<li><code>SETFCAP</code></li>
<li><code>SETGID</code></li>
<li><code>SETPCAP</code></li>
<li><code>SETUID</code></li>
<li><code>SYS_CHROOT</code></li>
<li><code>AUDIT_WRITE</code></li>
<li><code>CHOWN</code></li>
<li><code>DAC_OVERRIDE</code></li>
<li><code>FOWNER</code></li>
<li><code>FSETID</code></li>
<li><code>KILL</code></li>
<li><code>MKNOD</code></li>
<li><code>NET_BIND_SERVICE</code></li>
<li><code>SETFCAP</code></li>
<li><code>SETGID</code></li>
<li><code>SETPCAP</code></li>
<li><code>SETUID</code></li>
<li><code>SYS_CHROOT</code></li>
</ul>
<p><b>Restricted</b>: empty / undefined / nil OR a list containing <i>only</i> <code>NET_BIND_SERVICE</code>
</td>
@@ -236,9 +236,9 @@ The [annotations](/docs/concepts/overview/working-with-objects/annotations/) enu
table can be specified under `.metadata.annotations` on the PodSecurityPolicy object.
<table class="no-word-break">
<caption style="display:none">Mapping PodSecurityPolicy annotations to Pod Security Standards</caption>
<tbody>
<tr>
<caption style="display:none">Mapping PodSecurityPolicy annotations to Pod Security Standards</caption>
<tbody>
<tr>
<th><code>PSP Annotation</code></th>
<th>Type</th>
<th>Pod Security Standards Equivalent</th>
@@ -54,8 +54,8 @@ it can't be both.
ClusterRoles have several uses. You can use a ClusterRole to:
1. define permissions on namespaced resources and be granted within individual namespace(s)
1. define permissions on namespaced resources and be granted across all namespaces
1. define permissions on namespaced resources and be granted access within individual namespace(s)
1. define permissions on namespaced resources and be granted access across all namespaces
1. define permissions on cluster-scoped resources
If you want to define a role within a namespace, use a Role; if you want to define
@@ -90,7 +90,7 @@ kubelet [flags]
</tr>
<tr>
<td colspan="2">--authorization-mode string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>AlwaysAllow</code></td></td>
<td colspan="2">--authorization-mode string&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Default: <code>AlwaysAllow</code></td>
</tr>
<tr>
<td></td><td style="line-height: 130%; word-wrap: break-word;">Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See <a href="https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/">kubelet-config-file</a> for more information.)</td>
@@ -2,9 +2,10 @@
title: Extensions
id: Extensions
date: 2019-02-01
full_link: /docs/concepts/extend-kubernetes/extend-cluster/#extensions
full_link: /docs/concepts/extend-kubernetes/#extensions
short_description: >
Extensions are software components that extend and deeply integrate with Kubernetes to support new types of hardware.
Extensions are software components that extend and deeply integrate with Kubernetes to support
new types of hardware.
aka:
tags:
@@ -15,4 +16,6 @@ tags:
<!--more-->
Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters come with extensions pre-installed. As a result, most Kubernetes users will not need to install [extensions](/docs/concepts/extend-kubernetes/extend-cluster/#extensions) and even fewer users will need to author new ones.
Many cluster administrators use a hosted or distribution instance of Kubernetes. These clusters
come with extensions pre-installed. As a result, most Kubernetes users will not need to install
[extensions](/docs/concepts/extend-kubernetes/) and even fewer users will need to author new ones.
@@ -2,7 +2,7 @@
title: Garbage Collection
id: garbage-collection
date: 2021-07-07
full_link: /docs/concepts/workloads/controllers/garbage-collection/
full_link: /docs/concepts/architecture/garbage-collection/
short_description: >
A collective term for the various mechanisms Kubernetes uses to clean up cluster
resources.
@@ -12,13 +12,16 @@ tags:
- fundamental
- operation
---
Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
cluster resources.
Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
cluster resources.
<!--more-->
Kubernetes uses garbage collection to clean up resources like [unused containers and images](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
Kubernetes uses garbage collection to clean up resources like
[unused containers and images](/docs/concepts/architecture/garbage-collection/#containers-images),
[failed Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
[objects owned by the targeted resource](/docs/concepts/overview/working-with-objects/owners-dependents/),
[completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
that have expired or failed.
that have expired or failed.
@@ -39,7 +39,7 @@ The JSON and Protobuf serialization schemas follow the same guidelines for
schema changes. The following descriptions cover both formats.
The API versioning and software versioning are indirectly related.
The [API and release versioning proposal](https://git.k8s.io/design-proposals-archive/release/versioning.md)
The [API and release versioning proposal](https://git.k8s.io/sig-release/release-engineering/versioning.md)
describes the relationship between API versioning and software versioning.
Different API versions indicate different levels of stability and support. You
@@ -13,10 +13,10 @@ Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [i
* a highly available cluster
* composable attributes
* support for most popular Linux distributions
* Ubuntu 16.04, 18.04, 20.04
* Ubuntu 16.04, 18.04, 20.04, 22.04
* CentOS/RHEL/Oracle Linux 7, 8
* Debian Buster, Jessie, Stretch, Wheezy
* Fedora 31, 32
* Fedora 34, 35
* Fedora CoreOS
* openSUSE Leap 15
* Flatcar Container Linux by Kinvolk
@@ -33,7 +33,7 @@ To choose a tool which best fits your use case, read [this comparison](https://g
Provision servers with the following [requirements](https://github.com/kubernetes-sigs/kubespray#requirements):
* **Ansible v2.9 and python-netaddr are installed on the machine that will run Ansible commands**
* **Ansible v2.11 and python-netaddr are installed on the machine that will run Ansible commands**
* **Jinja 2.11 (or newer) is required to run the Ansible Playbooks**
* The target servers must have access to the Internet in order to pull docker images. Otherwise, additional configuration is required ([See Offline Environment](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/offline-environment.md))
* The target servers are configured to allow **IPv4 forwarding**
@@ -69,4 +69,4 @@ admission controller. To get started with `cosigned` here are a few helpful
resources:
* [Installation](https://github.com/sigstore/cosign#installation)
* [Configuration Options](https://github.com/sigstore/cosign/tree/main/config)
* [Configuration Options](https://github.com/sigstore/cosign/blob/main/USAGE.md#detailed-usage)
@@ -362,9 +362,9 @@ and create it:
kubectl create --validate=false -f my-crontab.yaml -o yaml
```
your output is similar to:
Your output is similar to:
```console
```yaml
apiVersion: stable.example.com/v1
kind: CronTab
metadata:
@@ -836,7 +836,7 @@ Validation Rules Examples:
| `has(self.expired) && self.created + self.ttl < self.expired` | Validate that 'expired' date is after a 'create' date plus a 'ttl' duration |
| `self.health.startsWith('ok')` | Validate a 'health' string field has the prefix 'ok' |
| `self.widgets.exists(w, w.key == 'x' && w.foo < 10)` | Validate that the 'foo' property of a listMap item with a key 'x' is less than 10 |
| `type(self) == string ? self == '100%' : self == 1000` | Validate an int-or-string field for both the the int and string cases |
| `type(self) == string ? self == '100%' : self == 1000` | Validate an int-or-string field for both the int and string cases |
| `self.metadata.name.startsWith(self.prefix)` | Validate that an object's name has the prefix of another field value |
| `self.set1.all(e, !(e in self.set2))` | Validate that two listSets are disjoint |
| `size(self.names) == size(self.details) && self.names.all(n, n in self.details)` | Validate the 'details' map is keyed by the items in the 'names' listSet |
@@ -844,7 +844,6 @@ Validation Rules Examples:
Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#evaluation)
- If the Rule is scoped to the root of a resource, it may make field selection into any fields
declared in the OpenAPIv3 schema of the CRD as well as `apiVersion`, `kind`, `metadata.name` and
`metadata.generateName`. This includes selection of fields in both the `spec` and `status` in the
@@ -7,7 +7,7 @@ description: Configure the kubelet's image credential provider plugin
content_type: task
---
{{< feature-state for_k8s_version="v1.20" state="alpha" >}}
{{< feature-state for_k8s_version="v1.24" state="beta" >}}
<!-- overview -->