Merge pull request #32694 from nate-double-u/merged-main-dev-1.24
Merged main into dev 1.24
This commit is contained in:
Kubernetes Prow Robot
@@ -13,7 +13,7 @@ allows the clean up of resources like the following:
|
||||
* [Objects without owner references](#owners-dependents)
|
||||
* [Unused containers and container images](#containers-images)
|
||||
* [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete)
|
||||
* [Stale or expired CertificateSigningRequests (CSRs)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* [Stale or expired CertificateSigningRequests (CSRs)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process)
|
||||
* {{<glossary_tooltip text="Nodes" term_id="node">}} deleted in the following scenarios:
|
||||
* On a cloud when the cluster uses a [cloud controller manager](/docs/concepts/architecture/cloud-controller/)
|
||||
* On-premises when the cluster uses an addon similar to a cloud controller
|
||||
|
||||
@@ -134,7 +134,7 @@ Mi, Ki. For example, the following represent roughly the same value:
|
||||
128974848, 129e6, 129M, 128974848000m, 123Mi
|
||||
```
|
||||
|
||||
Take care about case for suffixes. If you request `400m` of memory, this is a request
|
||||
Pay attention to the case of the suffixes. If you request `400m` of memory, this is a request
|
||||
for 0.4 bytes. Someone who types that probably meant to ask for 400 mebibytes (`400Mi`)
|
||||
or 400 megabytes (`400M`).
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ Customization approaches can be broadly divided into *configuration*, which only
|
||||
|
||||
Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options.
|
||||
|
||||
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
|
||||
*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable.
|
||||
|
||||
## Extensions
|
||||
|
||||
|
||||
@@ -348,6 +348,7 @@ Here are some examples of device plugin implementations:
|
||||
* The [KubeVirt device plugins](https://github.com/kubevirt/kubernetes-device-plugins) for hardware-assisted virtualization
|
||||
* The [NVIDIA GPU device plugin for Container-Optimized OS](https://github.com/GoogleCloudPlatform/container-engine-accelerators/tree/master/cmd/nvidia_gpu)
|
||||
* The [RDMA device plugin](https://github.com/hustcat/k8s-rdma-device-plugin)
|
||||
* The [SocketCAN device plugin](https://github.com/collabora/k8s-socketcan)
|
||||
* The [Solarflare device plugin](https://github.com/vikaschoudhary16/sfc-device-plugin)
|
||||
* The [SR-IOV Network device plugin](https://github.com/intel/sriov-network-device-plugin)
|
||||
* The [Xilinx FPGA device plugins](https://github.com/Xilinx/FPGA_as_a_Service/tree/master/k8s-fpga-device-plugin) for Xilinx FPGA devices
|
||||
|
||||
@@ -129,6 +129,12 @@ The available Admission Control modules are described in [Admission Controllers]
|
||||
Once a request passes all admission controllers, it is validated using the validation routines
|
||||
for the corresponding API object, and then written to the object store (shown as step **4**).
|
||||
|
||||
## Auditing
|
||||
|
||||
Kubernetes auditing provides a security-relevant, chronological set of records documenting the sequence of actions in a cluster.
|
||||
The cluster audits the activities generated by users, by applications that use the Kubernetes API, and by the control plane itself.
|
||||
|
||||
For more information, see [Auditing](/docs/tasks/debug-application-cluster/audit/).
|
||||
|
||||
## API server ports and IPs
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ behavior of pods in a clear, consistent fashion.
|
||||
|
||||
As a Beta feature, Kubernetes offers a built-in _Pod Security_ {{< glossary_tooltip
|
||||
text="admission controller" term_id="admission-controller" >}}, the successor
|
||||
to [PodSecurityPolicies](/docs/concepts/policy/pod-security-policy/). Pod security restrictions
|
||||
to [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/). Pod security restrictions
|
||||
are applied at the {{< glossary_tooltip text="namespace" term_id="namespace" >}} level when pods
|
||||
are created.
|
||||
|
||||
@@ -55,7 +55,7 @@ are available at [https://git.k8s.io/pod-security-admission/webhook](https://git
|
||||
|
||||
To install:
|
||||
```shell
|
||||
git clone git@github.com:kubernetes/pod-security-admission.git
|
||||
git clone https://github.com/kubernetes/pod-security-admission.git
|
||||
cd pod-security-admission/webhook
|
||||
make certs
|
||||
kubectl apply -k .
|
||||
|
||||
@@ -452,7 +452,7 @@ of individual policies are not defined here.
|
||||
- {{< example file="security/podsecurity-baseline.yaml" >}}Baseline namespace{{< /example >}}
|
||||
- {{< example file="security/podsecurity-restricted.yaml" >}}Restricted namespace{{< /example >}}
|
||||
|
||||
[**PodSecurityPolicy**](/docs/concepts/policy/pod-security-policy/) (Deprecated)
|
||||
[**PodSecurityPolicy**](/docs/concepts/security/pod-security-policy/) (Deprecated)
|
||||
|
||||
- {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}}
|
||||
- {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}}
|
||||
|
||||
@@ -281,7 +281,7 @@ the policy will be applied only for the single `port` field.
|
||||
|
||||
## Targeting a Namespace by its name
|
||||
|
||||
{{< feature-state state="beta" for_k8s_version="1.21" >}}
|
||||
{{< feature-state for_k8s_version="1.22" state="stable" >}}
|
||||
|
||||
The Kubernetes control plane sets an immutable label `kubernetes.io/metadata.name` on all
|
||||
namespaces, provided that the `NamespaceDefaultLabelName`
|
||||
|
||||
@@ -126,10 +126,10 @@ 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
|
||||
As a cluster administrator, you can use a [PodSecurityPolicy](/docs/concepts/security/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 >}}
|
||||
@@ -250,13 +250,12 @@ PVCs indirectly if they can create Pods, even if they do not have
|
||||
permission to create PVCs directly. Cluster administrators must be
|
||||
aware of this. If this does not fit their security model, they have
|
||||
two choices:
|
||||
- Use a [Pod Security
|
||||
Policy](/docs/concepts/policy/pod-security-policy/) where the
|
||||
`volumes` list does not contain the `ephemeral` volume type
|
||||
(deprecated in Kubernetes 1.21).
|
||||
- Use an [admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/)
|
||||
which rejects objects like Pods that have a generic ephemeral
|
||||
that rejects objects like Pods that have a generic ephemeral
|
||||
volume.
|
||||
- Use a [Pod Security Policy](/docs/concepts/security/pod-security-policy/)
|
||||
where the `volumes` list does not contain the `ephemeral` volume type
|
||||
(deprecated since Kubernetes 1.21).
|
||||
|
||||
The normal [namespace quota for PVCs](/docs/concepts/policy/resource-quotas/#storage-resource-quota) still applies, so
|
||||
even if users are allowed to use this new mechanism, they cannot use
|
||||
|
||||
@@ -54,8 +54,7 @@ into a Pod at a specified path. For example:
|
||||
|
||||
The example Pod has a projected volume containing the injected service account
|
||||
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/).
|
||||
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
|
||||
|
||||
@@ -261,8 +261,7 @@ Within a Pod, containers share an IP address and port space, and
|
||||
can find each other via `localhost`. The containers in a Pod can also communicate
|
||||
with each other using standard inter-process communications like SystemV semaphores
|
||||
or POSIX shared memory. Containers in different Pods have distinct IP addresses
|
||||
and can not communicate by IPC without
|
||||
[special configuration](/docs/concepts/policy/pod-security-policy/).
|
||||
and can not communicate by OS-level IPC without special configuration.
|
||||
Containers that want to interact with a container running in a different Pod can
|
||||
use IP networking to communicate.
|
||||
|
||||
|
||||
@@ -712,7 +712,7 @@ for more information.
|
||||
This admission controller acts on creation and modification of the pod and determines if it should be admitted
|
||||
based on the requested security context and the available Pod Security Policies.
|
||||
|
||||
See also [Pod Security Policy documentation](/docs/concepts/policy/pod-security-policy/)
|
||||
See also the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) documentation
|
||||
for more information.
|
||||
|
||||
### PodTolerationRestriction {#podtolerationrestriction}
|
||||
@@ -773,14 +773,17 @@ for more information.
|
||||
|
||||
### SecurityContextDeny {#securitycontextdeny}
|
||||
|
||||
This admission controller will deny any pod that attempts to set certain escalating
|
||||
This admission controller will deny any Pod that attempts to set certain escalating
|
||||
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
fields, as shown in the
|
||||
[Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/)
|
||||
task.
|
||||
This should be enabled if a cluster doesn't utilize
|
||||
[pod security policies](/docs/concepts/policy/pod-security-policy/)
|
||||
to restrict the set of values a security context can take.
|
||||
If you don't use [Pod Security admission]((/docs/concepts/security/pod-security-admission/),
|
||||
[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), nor any external enforcement mechanism,
|
||||
then you could use this admission controller to restrict the set of values a security context can take.
|
||||
|
||||
See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for more context on restricting
|
||||
pod privileges.
|
||||
|
||||
### ServiceAccount {#serviceaccount}
|
||||
|
||||
|
||||
@@ -121,7 +121,7 @@ token,user,uid,"group1,group2,group3"
|
||||
|
||||
When using bearer token authentication from an http client, the API
|
||||
server expects an `Authorization` header with a value of `Bearer
|
||||
THETOKEN`. The bearer token must be a character sequence that can be
|
||||
<token>`. The bearer token must be a character sequence that can be
|
||||
put in an HTTP header value using no more than the encoding and
|
||||
quoting facilities of HTTP. For example: if the bearer token is
|
||||
`31ada4fd-adec-460c-809a-9e56ceb75269` then it would appear in an HTTP
|
||||
|
||||
@@ -76,7 +76,7 @@ DELETE | delete (for individual resources), deletecollection (for collections
|
||||
|
||||
Kubernetes sometimes checks authorization for additional permissions using specialized verbs. For example:
|
||||
|
||||
* [PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/)
|
||||
* [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/)
|
||||
* `use` verb on `podsecuritypolicies` resources in the `policy` API group.
|
||||
* [RBAC](/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping)
|
||||
* `bind` and `escalate` verbs on `roles` and `clusterroles` resources in the `rbac.authorization.k8s.io` API group.
|
||||
|
||||
@@ -74,7 +74,7 @@ different Kubernetes components.
|
||||
| `CSIInlineVolume` | `true` | Beta | 1.16 | - |
|
||||
| `CSIMigration` | `false` | Alpha | 1.14 | 1.16 |
|
||||
| `CSIMigration` | `true` | Beta | 1.17 | |
|
||||
| `CSIMigrationAWS` | `false` | Alpha | 1.14 | |
|
||||
| `CSIMigrationAWS` | `false` | Alpha | 1.14 | 1.16 |
|
||||
| `CSIMigrationAWS` | `false` | Beta | 1.17 | 1.22 |
|
||||
| `CSIMigrationAWS` | `true` | Beta | 1.23 | |
|
||||
| `CSIMigrationAzureFile` | `false` | Alpha | 1.15 | 1.19 |
|
||||
@@ -607,39 +607,47 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
See [AppArmor Tutorial](/docs/tutorials/security/apparmor/) for more details.
|
||||
- `AttachVolumeLimit`: Enable volume plugins to report limits on number of volumes
|
||||
that can be attached to a node.
|
||||
See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits) for more details.
|
||||
- `BalanceAttachedNodeVolumes`: Include volume count on node to be considered for balanced resource allocation
|
||||
while scheduling. A node which has closer CPU, memory utilization, and volume count is favored by the scheduler
|
||||
while making decisions.
|
||||
See [dynamic volume limits](/docs/concepts/storage/storage-limits/#dynamic-volume-limits)
|
||||
for more details.
|
||||
- `BalanceAttachedNodeVolumes`: Include volume count on node to be considered for
|
||||
balanced resource allocation while scheduling. A node which has closer CPU,
|
||||
memory utilization, and volume count is favored by the scheduler while making decisions.
|
||||
- `BlockVolume`: Enable the definition and consumption of raw block devices in Pods.
|
||||
See [Raw Block Volume Support](/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)
|
||||
for more details.
|
||||
- `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume consisting of a
|
||||
ServiceAccountTokenVolumeProjection. Cluster admins can use metric `serviceaccount_stale_tokens_total` to
|
||||
monitor workloads that are depending on the extended tokens. If there are no such workloads, turn off
|
||||
extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`.
|
||||
- `BoundServiceAccountTokenVolume`: Migrate ServiceAccount volumes to use a projected volume
|
||||
consisting of a ServiceAccountTokenVolumeProjection. Cluster admins can use metric
|
||||
`serviceaccount_stale_tokens_total` to monitor workloads that are depending on the extended
|
||||
tokens. If there are no such workloads, turn off extended tokens by starting `kube-apiserver` with
|
||||
flag `--service-account-extend-token-expiration=false`.
|
||||
Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
|
||||
for more details.
|
||||
for more details.
|
||||
- `ControllerManagerLeaderMigration`: Enables Leader Migration for
|
||||
[kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration) and
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) which allows a cluster operator to live migrate
|
||||
[cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager)
|
||||
which allows a cluster operator to live migrate
|
||||
controllers from the kube-controller-manager into an external controller-manager
|
||||
(e.g. the cloud-controller-manager) in an HA cluster without downtime.
|
||||
- `CPUManager`: Enable container level CPU affinity support, see
|
||||
[CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/).
|
||||
- `CPUManagerPolicyAlphaOptions`: This allows fine-tuning of CPUManager policies, experimental, Alpha-quality options
|
||||
- `CPUManagerPolicyAlphaOptions`: This allows fine-tuning of CPUManager policies,
|
||||
experimental, Alpha-quality options
|
||||
This feature gate guards *a group* of CPUManager options whose quality level is alpha.
|
||||
This feature gate will never graduate to beta or stable.
|
||||
- `CPUManagerPolicyBetaOptions`: This allows fine-tuning of CPUManager policies, experimental, Beta-quality options
|
||||
- `CPUManagerPolicyBetaOptions`: This allows fine-tuning of CPUManager policies,
|
||||
experimental, Beta-quality options
|
||||
This feature gate guards *a group* of CPUManager options whose quality level is beta.
|
||||
This feature gate will never graduate to stable.
|
||||
- `CPUManagerPolicyOptions`: Allow fine-tuning of CPUManager policies.
|
||||
- `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. The default max size of a log file is 10MB and the
|
||||
default max number of log files allowed for a container is 5. These values can be configured in the kubelet config.
|
||||
See the [logging at node level](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level) documentation for more details.
|
||||
- `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime.
|
||||
The default max size of a log file is 10MB and the default max number of
|
||||
log files allowed for a container is 5.
|
||||
These values can be configured in the kubelet config.
|
||||
See [logging at node level](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)
|
||||
for more details.
|
||||
- `CSIBlockVolume`: Enable external CSI volume drivers to support block storage.
|
||||
See the [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)
|
||||
documentation for more details.
|
||||
See [`csi` raw block volume support](/docs/concepts/storage/volumes/#csi-raw-block-volume-support)
|
||||
for more details.
|
||||
- `CSIDriverRegistry`: Enable all logic related to the CSIDriver API object in
|
||||
csi.storage.k8s.io.
|
||||
- `CSIInlineVolume`: Enable CSI Inline volumes support for pods.
|
||||
@@ -671,7 +679,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
AzureDisk CSI plugin. Requires CSIMigration and CSIMigrationAzureDisk feature
|
||||
flags enabled and AzureDisk CSI plugin installed and configured on all nodes
|
||||
in the cluster. This flag has been deprecated in favor of the
|
||||
`InTreePluginAzureDiskUnregister` feature flag which prevents the registration of in-tree AzureDisk plugin.
|
||||
`InTreePluginAzureDiskUnregister` feature flag which prevents the registration
|
||||
of in-tree AzureDisk plugin.
|
||||
- `CSIMigrationAzureFile`: Enables shims and translation logic to route volume
|
||||
operations from the Azure-File in-tree plugin to AzureFile CSI plugin.
|
||||
Supports falling back to in-tree AzureFile plugin for mount operations to
|
||||
@@ -694,19 +703,13 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
Does not support falling back for provision operations, for those the CSI
|
||||
plugin must be installed and configured. Requires CSIMigration feature flag
|
||||
enabled.
|
||||
- `csiMigrationRBD`: Enables shims and translation logic to route volume
|
||||
operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
|
||||
CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
|
||||
installed and configured in the cluster. This flag has been deprecated in
|
||||
favor of the
|
||||
`InTreePluginRBDUnregister` feature flag which prevents the registration of
|
||||
in-tree RBD plugin.
|
||||
- `CSIMigrationGCEComplete`: Stops registering the GCE-PD in-tree plugin in
|
||||
kubelet and volume controllers and enables shims and translation logic to
|
||||
route volume operations from the GCE-PD in-tree plugin to PD CSI plugin.
|
||||
Requires CSIMigration and CSIMigrationGCE feature flags enabled and PD CSI
|
||||
plugin installed and configured on all nodes in the cluster. This flag has
|
||||
been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which prevents the registration of in-tree GCE PD plugin.
|
||||
been deprecated in favor of the `InTreePluginGCEUnregister` feature flag which
|
||||
prevents the registration of in-tree GCE PD plugin.
|
||||
- `CSIMigrationOpenStack`: Enables shims and translation logic to route volume
|
||||
operations from the Cinder in-tree plugin to Cinder CSI plugin. Supports
|
||||
falling back to in-tree Cinder plugin for mount operations to nodes that have
|
||||
@@ -719,7 +722,14 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
volume operations from the Cinder in-tree plugin to Cinder CSI plugin.
|
||||
Requires CSIMigration and CSIMigrationOpenStack feature flags enabled and Cinder
|
||||
CSI plugin installed and configured on all nodes in the cluster. This flag has
|
||||
been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag which prevents the registration of in-tree openstack cinder plugin.
|
||||
been deprecated in favor of the `InTreePluginOpenStackUnregister` feature flag
|
||||
which prevents the registration of in-tree openstack cinder plugin.
|
||||
- `csiMigrationRBD`: Enables shims and translation logic to route volume
|
||||
operations from the RBD in-tree plugin to Ceph RBD CSI plugin. Requires
|
||||
CSIMigration and csiMigrationRBD feature flags enabled and Ceph CSI plugin
|
||||
installed and configured in the cluster. This flag has been deprecated in
|
||||
favor of the `InTreePluginRBDUnregister` feature flag which prevents the registration of
|
||||
in-tree RBD plugin.
|
||||
- `CSIMigrationvSphere`: Enables shims and translation logic to route volume operations
|
||||
from the vSphere in-tree plugin to vSphere CSI plugin. Supports falling back
|
||||
to in-tree vSphere plugin for mount operations to nodes that have the feature
|
||||
@@ -732,11 +742,12 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
from the vSphere in-tree plugin to vSphere CSI plugin. Requires CSIMigration and
|
||||
CSIMigrationvSphere feature flags enabled and vSphere CSI plugin installed and
|
||||
configured on all nodes in the cluster. This flag has been deprecated in favor
|
||||
of the `InTreePluginvSphereUnregister` feature flag which prevents the registration of in-tree vsphere plugin.
|
||||
of the `InTreePluginvSphereUnregister` feature flag which prevents the
|
||||
registration of in-tree vsphere plugin.
|
||||
- `CSIMigrationPortworx`: Enables shims and translation logic to route volume operations
|
||||
from the Portworx in-tree plugin to Portworx CSI plugin.
|
||||
Requires Portworx CSI driver to be installed and configured in the cluster, and feature gate set `CSIMigrationPortworx=true` in kube-controller-manager and kubelet configs.
|
||||
- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in csi.storage.k8s.io.
|
||||
Requires Portworx CSI driver to be installed and configured in the cluster.
|
||||
- `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in `csi.storage.k8s.io`.
|
||||
- `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a
|
||||
[CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md)
|
||||
compatible volume plugin.
|
||||
@@ -765,7 +776,9 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `CronJobTimeZone`: Allow the use of the `timeZone` optional field in [CronJobs](/docs/concepts/workloads/controllers/cron-jobs/)
|
||||
- `CustomCPUCFSQuotaPeriod`: Enable nodes to change `cpuCFSQuotaPeriod` in
|
||||
[kubelet config](/docs/tasks/administer-cluster/kubelet-config-file/).
|
||||
- `CustomResourceValidationExpressions`: Enable expression language validation in CRD which will validate customer resource based on validation rules written in `x-kubernetes-validations` extension.
|
||||
- `CustomResourceValidationExpressions`: Enable expression language validation in CRD
|
||||
which will validate customer resource based on validation rules written in
|
||||
the `x-kubernetes-validations` extension.
|
||||
- `CustomPodDNS`: Enable customizing the DNS settings for a Pod using its `dnsConfig` property.
|
||||
Check [Pod's DNS Config](/docs/concepts/services-networking/dns-pod-service/#pods-dns-config)
|
||||
for more details.
|
||||
@@ -849,7 +862,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
host mounts, or containers that are privileged or using specific non-namespaced
|
||||
capabilities (e.g. `MKNODE`, `SYS_MODULE` etc.). This should only be enabled
|
||||
if user namespace remapping is enabled in the Docker daemon.
|
||||
- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not applied to Service ExternalIPs.
|
||||
- `ExternalPolicyForExternalIP`: Fix a bug where ExternalTrafficPolicy is not
|
||||
applied to Service ExternalIPs.
|
||||
- `GCERegionalPersistentDisk`: Enable the regional PD feature on GCE.
|
||||
- `GenericEphemeralVolume`: Enables ephemeral, inline volumes that support all features
|
||||
of normal volumes (can be provided by third-party storage vendors, storage capacity tracking,
|
||||
@@ -862,8 +876,10 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
for more details.
|
||||
- `GracefulNodeShutdownBasedOnPodPriority`: Enables the kubelet to check Pod priorities
|
||||
when shutting down a node gracefully.
|
||||
- `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe. See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
|
||||
- `HonorPVReclaimPolicy`: Honor persistent volume reclaim policy when it is `Delete` irrespective of PV-PVC deletion ordering.
|
||||
- `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe.
|
||||
See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe).
|
||||
- `HonorPVReclaimPolicy`: Honor persistent volume reclaim policy when it is `Delete`
|
||||
irrespective of PV-PVC deletion ordering.
|
||||
- `HPAContainerMetrics`: Enable the `HorizontalPodAutoscaler` to scale based on
|
||||
metrics from individual containers in target pods.
|
||||
- `HPAScaleToZero`: Enables setting `minReplicas` to 0 for `HorizontalPodAutoscaler`
|
||||
@@ -875,10 +891,19 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `HyperVContainer`: Enable
|
||||
[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container)
|
||||
for Windows containers.
|
||||
- `IdentifyPodOS`: Allows the Pod OS field to be specified. This helps in identifying the OS of the pod
|
||||
authoritatively during the API server admission time. In Kubernetes {{< skew currentVersion >}}, the allowed values for the `pod.spec.os.name` are `windows` and `linux`.
|
||||
- `IdentifyPodOS`: Allows the Pod OS field to be specified. This helps in identifying
|
||||
the OS of the pod authoritatively during the API server admission time.
|
||||
In Kubernetes {{< skew currentVersion >}}, the allowed values for the `pod.spec.os.name`
|
||||
are `windows` and `linux`.
|
||||
- `ImmutableEphemeralVolumes`: Allows for marking individual Secrets and ConfigMaps as
|
||||
immutable for better safety and performance.
|
||||
- `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/)
|
||||
controller to manage Pod completions per completion index.
|
||||
- `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in
|
||||
`IngressClass` resource. This feature adds two fields - `Scope` and `Namespace`
|
||||
to `IngressClass.spec.parameters`.
|
||||
- `Initializers`: Allow asynchronous coordination of object creation using the
|
||||
Initializers admission plugin.
|
||||
- `InTreePluginAWSUnregister`: Stops registering the aws-ebs in-tree plugin in kubelet
|
||||
and volume controllers.
|
||||
- `InTreePluginAzureDiskUnregister`: Stops registering the azuredisk in-tree plugin in kubelet
|
||||
@@ -895,13 +920,6 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
and volume controllers.
|
||||
- `InTreePluginvSphereUnregister`: Stops registering the vSphere in-tree plugin in kubelet
|
||||
and volume controllers.
|
||||
- `IndexedJob`: Allows the [Job](/docs/concepts/workloads/controllers/job/)
|
||||
controller to manage Pod completions per completion index.
|
||||
- `IngressClassNamespacedParams`: Allow namespace-scoped parameters reference in
|
||||
`IngressClass` resource. This feature adds two fields - `Scope` and `Namespace`
|
||||
to `IngressClass.spec.parameters`.
|
||||
- `Initializers`: Allow asynchronous coordination of object creation using the
|
||||
Initializers admission plugin.
|
||||
- `IPv6DualStack`: Enable [dual stack](/docs/concepts/services-networking/dual-stack/)
|
||||
support for IPv6.
|
||||
- `JobMutableNodeSchedulingDirectives`: Allows updating node scheduling directives in
|
||||
@@ -919,17 +937,21 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
a file specified using a config file.
|
||||
See [setting kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
for more details.
|
||||
- `KubeletCredentialProviders`: Enable kubelet exec credential providers for image pull credentials.
|
||||
- `KubeletInUserNamespace`: Enables support for running kubelet in a {{<glossary_tooltip text="user namespace" term_id="userns">}}.
|
||||
- `KubeletCredentialProviders`: Enable kubelet exec credential providers for
|
||||
image pull credentials.
|
||||
- `KubeletInUserNamespace`: Enables support for running kubelet in a
|
||||
{{<glossary_tooltip text="user namespace" term_id="userns">}}.
|
||||
See [Running Kubernetes Node Components as a Non-root User](/docs/tasks/administer-cluster/kubelet-in-userns/).
|
||||
- `KubeletPluginsWatcher`: Enable probe-based plugin watcher utility to enable kubelet
|
||||
to discover plugins such as [CSI volume drivers](/docs/concepts/storage/volumes/#csi).
|
||||
- `KubeletPodResources`: Enable the kubelet's pod resources gRPC endpoint. See
|
||||
[Support Device Monitoring](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/606-compute-device-assignment/README.md)
|
||||
for more details.
|
||||
- `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources `GetAllocatableResources` functionality.
|
||||
This API augments the [resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)
|
||||
with informations about the allocatable resources, enabling clients to properly track the free compute resources on a node.
|
||||
- `KubeletPodResourcesGetAllocatable`: Enable the kubelet's pod resources
|
||||
`GetAllocatableResources` functionality. This API augments the
|
||||
[resource allocation reporting](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#monitoring-device-plugin-resources)
|
||||
with informations about the allocatable resources, enabling clients to properly
|
||||
track the free compute resources on a node.
|
||||
- `LegacyNodeRoleBehavior`: When disabled, legacy behavior in service load balancers and
|
||||
node disruption will ignore the `node-role.kubernetes.io/master` label in favor of the
|
||||
feature-specific labels provided by `NodeDisruptionExclusion` and `ServiceNodeExclusion`.
|
||||
@@ -950,15 +972,18 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
based on logarithmic bucketing of pod timestamps.
|
||||
- `MemoryManager`: Allows setting memory affinity for a container based on
|
||||
NUMA topology.
|
||||
- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using cgroup v2 memory controller.
|
||||
- `MemoryQoS`: Enable memory protection and usage throttle on pod / container using
|
||||
cgroup v2 memory controller.
|
||||
- `MixedProtocolLBService`: Enable using different protocols in the same `LoadBalancer` type
|
||||
Service instance.
|
||||
- `MountContainers`: Enable using utility containers on host as the volume mounter.
|
||||
- `MountPropagation`: Enable sharing volume mounted by one container to other containers or pods.
|
||||
For more details, please see [mount propagation](/docs/concepts/storage/volumes/#mount-propagation).
|
||||
- `NamespaceDefaultLabelName`: Configure the API Server to set an immutable {{< glossary_tooltip text="label" term_id="label" >}}
|
||||
`kubernetes.io/metadata.name` on all namespaces, containing the namespace name.
|
||||
- `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects, allowing the selection of a port range instead of a single port.
|
||||
- `NamespaceDefaultLabelName`: Configure the API Server to set an immutable
|
||||
{{< glossary_tooltip text="label" term_id="label" >}} `kubernetes.io/metadata.name`
|
||||
on all namespaces, containing the namespace name.
|
||||
- `NetworkPolicyEndPort`: Enable use of the field `endPort` in NetworkPolicy objects,
|
||||
allowing the selection of a port range instead of a single port.
|
||||
- `NodeDisruptionExclusion`: Enable use of the Node label `node.kubernetes.io/exclude-disruption`
|
||||
which prevents nodes from being evacuated during zone failures.
|
||||
- `NodeLease`: Enable the new Lease API to report node heartbeats, which could be used as a node health signal.
|
||||
@@ -973,23 +998,23 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `OpenAPIEnums`: Enables populating "enum" fields of OpenAPI schemas in the
|
||||
spec returned from the API server.
|
||||
- `OpenAPIV3`: Enables the API server to publish OpenAPI v3.
|
||||
- `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
|
||||
being deleted when it is still used by any Pod.
|
||||
- `PodDeletionCost`: Enable the [Pod Deletion Cost](/docs/concepts/workloads/controllers/replicaset/#pod-deletion-cost)
|
||||
feature which allows users to influence ReplicaSet downscaling order.
|
||||
- `PersistentLocalVolumes`: Enable the usage of `local` volume type in Pods.
|
||||
Pod affinity has to be specified if requesting a `local` volume.
|
||||
- `PodAndContainerStatsFromCRI`: Configure the kubelet to gather container and pod stats from the CRI container runtime
|
||||
rather than gathering them from cAdvisor.
|
||||
- `PodAndContainerStatsFromCRI`: Configure the kubelet to gather container and
|
||||
pod stats from the CRI container runtime rather than gathering them from cAdvisor.
|
||||
- `PodDisruptionBudget`: Enable the [PodDisruptionBudget](/docs/tasks/run-application/configure-pdb/) feature.
|
||||
- `PodAffinityNamespaceSelector`: Enable the [Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector)
|
||||
and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota) quota scope features.
|
||||
- `PodAffinityNamespaceSelector`: Enable the
|
||||
[Pod Affinity Namespace Selector](/docs/concepts/scheduling-eviction/assign-pod-node/#namespace-selector)
|
||||
and [CrossNamespacePodAffinity](/docs/concepts/policy/resource-quotas/#cross-namespace-pod-affinity-quota)
|
||||
quota scope features.
|
||||
- `PodOverhead`: Enable the [PodOverhead](/docs/concepts/scheduling-eviction/pod-overhead/)
|
||||
feature to account for pod overheads.
|
||||
- `PodPriority`: Enable the descheduling and preemption of Pods based on their
|
||||
[priorities](/docs/concepts/scheduling-eviction/pod-priority-preemption/).
|
||||
- `PodReadinessGates`: Enable the setting of `PodReadinessGate` field for extending
|
||||
Pod readiness evaluation. See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
|
||||
Pod readiness evaluation. See [Pod readiness gate](/docs/concepts/workloads/pods/pod-lifecycle/#pod-readiness-gate)
|
||||
for more details.
|
||||
- `PodSecurity`: Enables the `PodSecurity` admission plugin.
|
||||
- `PodShareProcessNamespace`: Enable the setting of `shareProcessNamespace` in a Pod for sharing
|
||||
@@ -1000,19 +1025,22 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
the cluster.
|
||||
- `ProbeTerminationGracePeriod`: Enable [setting probe-level
|
||||
`terminationGracePeriodSeconds`](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#probe-level-terminationgraceperiodseconds)
|
||||
on pods. See the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period) for more details.
|
||||
on pods. See the [enhancement proposal](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2238-liveness-probe-grace-period)
|
||||
for more details.
|
||||
- `ProcMountType`: Enables control over the type proc mounts for containers
|
||||
by setting the `procMount` field of a SecurityContext.
|
||||
- `ProxyTerminatingEndpoints`: Enable the kube-proxy to handle terminating
|
||||
endpoints when `ExternalTrafficPolicy=Local`.
|
||||
- `PVCProtection`: Enable the prevention of a PersistentVolumeClaim (PVC) from
|
||||
being deleted when it is still used by any Pod.
|
||||
- `QOSReserved`: Allows resource reservations at the QoS level preventing pods
|
||||
at lower QoS levels from bursting into resources requested at higher QoS levels
|
||||
(memory only for now).
|
||||
- `ReadWriteOncePod`: Enables the usage of `ReadWriteOncePod` PersistentVolume
|
||||
access mode.
|
||||
- `RecoverVolumeExpansionFailure`: Enables users to edit their PVCs to smaller sizes so as they can recover from previously issued
|
||||
volume expansion failures. See
|
||||
[Recovering from Failure when Expanding Volumes](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)
|
||||
- `RecoverVolumeExpansionFailure`: Enables users to edit their PVCs to smaller
|
||||
sizes so as they can recover from previously issued volume expansion failures.
|
||||
See [Recovering from Failure when Expanding Volumes](/docs/concepts/storage/persistent-volumes/#recovering-from-failure-when-expanding-volumes)
|
||||
for more details.
|
||||
- `RemainingItemCount`: Allow the API servers to show a count of remaining
|
||||
items in the response to a
|
||||
@@ -1035,7 +1063,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
[Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md)
|
||||
for more details.
|
||||
- `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet.
|
||||
See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) for more details.
|
||||
See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)
|
||||
for more details.
|
||||
- `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet.
|
||||
See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)
|
||||
for more details.
|
||||
@@ -1047,7 +1076,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
instead of the DaemonSet controller.
|
||||
- `SCTPSupport`: Enables the _SCTP_ `protocol` value in Pod, Service,
|
||||
Endpoints, EndpointSlice, and NetworkPolicy definitions.
|
||||
- `SeccompDefault`: Enables the use of `RuntimeDefault` as the default seccomp profile for all workloads.
|
||||
- `SeccompDefault`: Enables the use of `RuntimeDefault` as the default seccomp profile
|
||||
for all workloads.
|
||||
The seccomp profile is specified in the `securityContext` of a Pod and/or a Container.
|
||||
- `SelectorIndex`: Allows label and field based indexes in API server watch
|
||||
cache to accelerate list operations.
|
||||
@@ -1061,7 +1091,8 @@ Each feature gate is designed for enabling/disabling a specific feature:
|
||||
- `ServiceInternalTrafficPolicy`: Enables the `internalTrafficPolicy` field on Services
|
||||
- `ServiceLBNodePortControl`: Enables the `allocateLoadBalancerNodePorts` field on Services.
|
||||
- `ServiceLoadBalancerClass`: Enables the `loadBalancerClass` field on Services. See
|
||||
[Specifying class of load balancer implementation](/docs/concepts/services-networking/service/#load-balancer-class) for more details.
|
||||
[Specifying class of load balancer implementation](/docs/concepts/services-networking/service/#load-balancer-class)
|
||||
for more details.
|
||||
- `ServiceLoadBalancerFinalizer`: Enable finalizer protection for Service load balancers.
|
||||
- `ServiceNodeExclusion`: Enable the exclusion of nodes from load balancers
|
||||
created by a cloud provider. A node is eligible for exclusion if labelled with
|
||||
|
||||
@@ -126,7 +126,6 @@ of provisioning.
|
||||
2. [Token authentication file](#token-authentication-file)
|
||||
|
||||
Bootstrap tokens are a simpler and more easily managed method to authenticate kubelets, and do not require any additional flags when starting kube-apiserver.
|
||||
Using bootstrap tokens is currently __beta__ as of Kubernetes version 1.12.
|
||||
|
||||
Whichever method you choose, the requirement is that the kubelet be able to authenticate as a user with the rights to:
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: Pod Security Policy
|
||||
id: pod-security-policy
|
||||
date: 2018-04-12
|
||||
full_link: /docs/concepts/policy/pod-security-policy/
|
||||
full_link: /docs/concepts/security/pod-security-policy/
|
||||
short_description: >
|
||||
Enables fine-grained authorization of pod creation and updates.
|
||||
|
||||
|
||||
+47
-6
@@ -527,15 +527,56 @@ options.
|
||||
|
||||
## Version skew policy {#version-skew-policy}
|
||||
|
||||
The `kubeadm` tool of version v{{< skew latestVersion >}} may deploy clusters with a control plane of version v{{< skew latestVersion >}} or v{{< skew prevMinorVersion >}}.
|
||||
`kubeadm` v{{< skew latestVersion >}} can also upgrade an existing kubeadm-created cluster of version v{{< skew prevMinorVersion >}}.
|
||||
While kubeadm allows version skew against some components that it manages, it is recommended that you
|
||||
match the kubeadm version with the versions of the control plane components, kube-proxy and kubelet.
|
||||
|
||||
Due to that we can't see into the future, kubeadm CLI v{{< skew latestVersion >}} may or may not be able to deploy v{{< skew nextMinorVersion >}} clusters.
|
||||
### kubeadm's skew against the Kubernetes version
|
||||
|
||||
These resources provide more information on supported version skew between kubelets and the control plane, and other Kubernetes components:
|
||||
kubeadm can be used with Kubernetes components that are the same version as kubeadm
|
||||
or one version older. The Kubernetes version can be specified to kubeadm by using the
|
||||
`--kubernetes-version` flag of `kubeadm init` or the
|
||||
[`ClusterConfiguration.kubernetesVersion`](/docs/reference/config-api/kubeadm-config.v1beta3/)
|
||||
field when using `--config`. This option will control the versions
|
||||
of kube-apiserver, kube-controller-manager, kube-scheduler and kube-proxy.
|
||||
|
||||
* Kubernetes [version and version-skew policy](/docs/setup/release/version-skew-policy/)
|
||||
* Kubeadm-specific [installation guide](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl)
|
||||
Example:
|
||||
* kubeadm is at {{< skew latestVersion >}}
|
||||
* `kubernetesVersion` must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}}
|
||||
|
||||
### kubeadm's skew against the kubelet
|
||||
|
||||
Similarly to the Kubernetes version, kubeadm can be used with a kubelet version that is the same
|
||||
version as kubeadm or one version older.
|
||||
|
||||
Example:
|
||||
* kubeadm is at {{< skew latestVersion >}}
|
||||
* kubelet on the host must be at {{< skew latestVersion >}} or {{< skew prevMinorVersion >}}
|
||||
|
||||
### kubeadm's skew against kubeadm
|
||||
|
||||
There are certain limitations on how kubeadm commands can operate on existing nodes or whole clusters
|
||||
managed by kubeadm.
|
||||
|
||||
If new nodes are joined to the cluster, the kubeadm binary used for `kubeadm join` must match
|
||||
the last version of kubeadm used to either create the cluster with `kubeadm init` or to upgrade
|
||||
the same node with `kubeadm upgrade`. Similar rules apply to the rest of the kubeadm commands
|
||||
with the exception of `kubeadm upgrade`.
|
||||
|
||||
Example for `kubeadm join`:
|
||||
* kubeadm version {{< skew latestVersion >}} was used to create a cluster with `kubeadm init`
|
||||
* Joining nodes must use a kubeadm binary that is at version {{< skew latestVersion >}}
|
||||
|
||||
Nodes that are being upgraded must use a version of kubeadm that is the same MINOR
|
||||
version or one MINOR version newer than the version of kubeadm used for managing the
|
||||
node.
|
||||
|
||||
Example for `kubeadm upgrade`:
|
||||
* kubeadm version {{< skew prevMinorVersion >}} was used to create or upgrade the node
|
||||
* The version of kubeadm used for upgrading the node must be at {{< skew prevMinorVersion >}}
|
||||
or {{< skew latestVersion >}}
|
||||
|
||||
To learn more about the version skew between the different Kubernetes component see
|
||||
the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/).
|
||||
|
||||
## Limitations {#limitations}
|
||||
|
||||
|
||||
@@ -182,8 +182,9 @@ respectively.
|
||||
|
||||
## General Guidelines
|
||||
|
||||
System daemons are expected to be treated similar to 'Guaranteed' pods. System
|
||||
daemons can burst within their bounding control groups and this behavior needs
|
||||
System daemons are expected to be treated similar to
|
||||
[Guaranteed pods](/docs/tasks/configure-pod-container/quality-service-pod/#create-a-pod-that-gets-assigned-a-qos-class-of-guaranteed).
|
||||
System daemons can burst within their bounding control groups and this behavior needs
|
||||
to be managed as part of kubernetes deployments. For example, `kubelet` should
|
||||
have its own control group and share `kube-reserved` resources with the
|
||||
container runtime. However, Kubelet cannot burst and use up all available Node
|
||||
|
||||
@@ -32,7 +32,7 @@ configure a [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/).
|
||||
|
||||
If availability is important for any applications that run or could run on the node(s)
|
||||
that you are draining, [configure a PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)
|
||||
first and the continue following this guide.
|
||||
first and then continue following this guide.
|
||||
|
||||
## Use `kubectl drain` to remove a node from service
|
||||
|
||||
|
||||
@@ -63,7 +63,7 @@ actions a client might want to perform. It is recommended that you use the
|
||||
|
||||
As with authentication, simple and broad roles may be appropriate for smaller clusters, but as
|
||||
more users interact with the cluster, it may become necessary to separate teams into separate
|
||||
namespaces with more limited roles.
|
||||
{{< glossary_tooltip text="namespaces" term_id="namespace" >}} with more limited roles.
|
||||
|
||||
With authorization, it is important to understand how updates on one object may cause actions in
|
||||
other places. For instance, a user may not be able to create pods directly, but allowing them to
|
||||
@@ -106,15 +106,18 @@ reserved resources like memory, or to provide default limits when none are speci
|
||||
A pod definition contains a [security context](/docs/tasks/configure-pod-container/security-context/)
|
||||
that allows it to request access to run as a specific Linux user on a node (like root),
|
||||
access to run privileged or access the host network, and other controls that would otherwise
|
||||
allow it to run unfettered on a hosting node. [Pod security policies](/docs/concepts/policy/pod-security-policy/)
|
||||
can limit which users or service accounts can provide dangerous security context settings. For example, pod security policies can limit volume mounts, especially `hostPath`, which are aspects of a pod that should be controlled.
|
||||
allow it to run unfettered on a hosting node.
|
||||
|
||||
You can configure [Pod security admission](/docs/concepts/security/pod-security-admission/)
|
||||
to enforce use of a particular [Pod Security Standard](/docs/concepts/security/pod-security-standards/)
|
||||
in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}, or to detect breaches.
|
||||
|
||||
Generally, most application workloads need limited access to host resources so they can
|
||||
successfully run as a root process (uid 0) without access to host information. However,
|
||||
considering the privileges associated with the root user, you should write application
|
||||
containers to run as a non-root user. Similarly, administrators who wish to prevent
|
||||
client applications from escaping their containers should use a restrictive pod security
|
||||
policy.
|
||||
client applications from escaping their containers should apply the **Baseline**
|
||||
or **Restricted** Pod Security Standard.
|
||||
|
||||
|
||||
### Preventing containers from loading unwanted kernel modules
|
||||
@@ -238,7 +241,15 @@ restrict the integration to functioning in a single namespace if possible.
|
||||
Components that create pods may also be unexpectedly powerful if they can do so inside namespaces
|
||||
like the `kube-system` namespace, because those pods can gain access to service account secrets
|
||||
or run with elevated permissions if those service accounts are granted access to permissive
|
||||
[pod security policies](/docs/concepts/policy/pod-security-policy/).
|
||||
[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/).
|
||||
|
||||
If you use [Pod Security admission]((/docs/concepts/security/pod-security-admission/) and allow
|
||||
any component to create Pods within a namespace that permits privileged Pods, those Pods may
|
||||
be able to escape their containers and use this widened access to elevate their privileges.
|
||||
|
||||
You should not allow untrusted components to create Pods in any system namespace (those with
|
||||
names that start with `kube-`) nor in any namespace where that access grant allows the possibility
|
||||
of privilege escalation.
|
||||
|
||||
### Encrypt secrets at rest
|
||||
|
||||
|
||||
@@ -218,6 +218,7 @@ Use the option `--from-env-file` to create a ConfigMap from an env-file, for exa
|
||||
|
||||
# Download the sample files into `configure-pod-container/configmap/` directory
|
||||
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
|
||||
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
|
||||
|
||||
# The env-file `game-env-file.properties` looks like below
|
||||
cat configure-pod-container/configmap/game-env-file.properties
|
||||
@@ -255,17 +256,10 @@ data:
|
||||
lives: "3"
|
||||
```
|
||||
|
||||
{{< caution >}}
|
||||
When passing `--from-env-file` multiple times to create a ConfigMap from multiple data sources, only the last env-file is used.
|
||||
{{< /caution >}}
|
||||
|
||||
The behavior of passing `--from-env-file` multiple times is demonstrated by:
|
||||
Starting with Kubernetes v1.23, `kubectl` supports the `--from-env-file` argument to be
|
||||
specified multiple times to create a ConfigMap from multiple data sources.
|
||||
|
||||
```shell
|
||||
# Download the sample files into `configure-pod-container/configmap/` directory
|
||||
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties
|
||||
|
||||
# Create the configmap
|
||||
kubectl create configmap config-multi-env-files \
|
||||
--from-env-file=configure-pod-container/configmap/game-env-file.properties \
|
||||
--from-env-file=configure-pod-container/configmap/ui-env-file.properties
|
||||
@@ -288,8 +282,11 @@ metadata:
|
||||
resourceVersion: "810136"
|
||||
uid: 252c4572-eb35-11e7-887b-42010a8002b8
|
||||
data:
|
||||
allowed: '"true"'
|
||||
color: purple
|
||||
enemies: aliens
|
||||
how: fairlyNice
|
||||
lives: "3"
|
||||
textmode: "true"
|
||||
```
|
||||
|
||||
|
||||
@@ -44,9 +44,6 @@ The above bullets are not a complete set of security context settings -- please
|
||||
[SecurityContext](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#securitycontext-v1-core)
|
||||
for a comprehensive list.
|
||||
|
||||
For more information about security mechanisms in Linux, see
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features)
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
@@ -487,6 +484,8 @@ kubectl delete pod security-context-demo-4
|
||||
* [Tuning Docker with the newest security enhancements](https://github.com/containerd/containerd/blob/main/docs/cri/config.md)
|
||||
* [Security Contexts design document](https://git.k8s.io/community/contributors/design-proposals/auth/security_context.md)
|
||||
* [Ownership Management design document](https://git.k8s.io/community/contributors/design-proposals/storage/volume-ownership-management.md)
|
||||
* [Pod Security Policies](/docs/concepts/policy/pod-security-policy/)
|
||||
* [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/)
|
||||
* [AllowPrivilegeEscalation design
|
||||
document](https://git.k8s.io/community/contributors/design-proposals/auth/no-new-privs.md)
|
||||
* For more information about security mechanisms in Linux, see
|
||||
[Overview of Linux Kernel Security Features](https://www.linux.com/learn/overview-linux-kernel-security-features) (Note: Some information is out of date)
|
||||
|
||||
@@ -182,8 +182,7 @@ static-web 1/1 Running 0 2m
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See
|
||||
[PodSecurityPolicy](/docs/concepts/policy/pod-security-policy/).
|
||||
Make sure the kubelet has permission to create the mirror Pod in the API server. If not, the creation request is rejected by the API server. See [Pod Security admission](/docs/concepts/security/pod-security-admission) and [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/).
|
||||
{{< /note >}}
|
||||
|
||||
{{< glossary_tooltip term_id="label" text="Labels" >}} from the static Pod are
|
||||
|
||||
@@ -337,9 +337,9 @@ APIs, cluster administrators must ensure that:
|
||||
* For external metrics, this is the `external.metrics.k8s.io` API. It may be provided by the custom metrics adapters provided above.
|
||||
|
||||
For more information on these different metrics paths and how they differ please see the relevant design proposals for
|
||||
[the HPA V2](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/custom-metrics-api.md)
|
||||
and [external.metrics.k8s.io](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/external-metrics-api.md).
|
||||
[the HPA V2](https://github.com/kubernetes/design-proposals-archive/blob/main/autoscaling/hpa-v2.md),
|
||||
[custom.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/custom-metrics-api.md)
|
||||
and [external.metrics.k8s.io](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/external-metrics-api.md).
|
||||
|
||||
For examples of how to use them see [the walkthrough for using custom metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-multiple-metrics-and-custom-metrics)
|
||||
and [the walkthrough for using external metrics](/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/#autoscaling-on-metrics-not-related-to-kubernetes-objects).
|
||||
|
||||
@@ -350,7 +350,7 @@ node with the required profile.
|
||||
|
||||
{{< note >}}
|
||||
PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25.
|
||||
See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information.
|
||||
See [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) documentation for more information.
|
||||
{{< /note >}}
|
||||
|
||||
If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
|
||||
|
||||
Reference in New Issue
Block a user