whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Seth McCombs
2022-07-21 13:48:12 -07:00
parent b61dfcd181 79afafeb76
commit 88784d31b8
135 changed files with 14957 additions and 2026 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md
+20 -20
View File
@@ -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>
content/en/docs/reference/access-authn-authz/rbac.md
+2 -2
View File
@@ -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
content/en/docs/reference/command-line-tools-reference/kubelet.md
+1 -1
View File
@@ -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>
content/en/docs/reference/glossary/extensions.md
+6 -3
View File
@@ -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.
content/en/docs/reference/glossary/garbage-collection.md
+8 -5
View File
@@ -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.
content/en/docs/reference/using-api/_index.md
+1 -1
View File
@@ -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