Merge master into dev-1.22 to keep in sync
This commit is contained in:
Victor Palade
@@ -23,7 +23,7 @@ This page lists some of the available add-ons and links to their respective inst
|
||||
* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave.
|
||||
* [Contiv](https://contiv.github.io) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options.
|
||||
* [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads.
|
||||
* [Flannel](https://github.com/coreos/flannel/blob/master/Documentation/kubernetes.md) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes.
|
||||
* [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod.
|
||||
* [Multus](https://github.com/Intel-Corp/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes.
|
||||
* [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy.
|
||||
|
||||
@@ -328,13 +328,13 @@ kubectl create secret tls my-tls-secret \
|
||||
--key=path/to/key/file
|
||||
```
|
||||
|
||||
The public/private key pair must exist before hand. The public key certificate
|
||||
The public/private key pair must exist beforehand. The public key certificate
|
||||
for `--cert` must be .PEM encoded (Base64-encoded DER format), and match the
|
||||
given private key for `--key`.
|
||||
The private key must be in what is commonly called PEM private key format,
|
||||
unencrypted. In both cases, the initial and the last lines from PEM (for
|
||||
example, `--------BEGIN CERTIFICATE-----` and `-------END CERTIFICATE----` for
|
||||
a cetificate) are *not* included.
|
||||
a certificate) are *not* included.
|
||||
|
||||
### Bootstrap token Secrets
|
||||
|
||||
|
||||
@@ -25,7 +25,7 @@ This page provides an outline of the container image concept.
|
||||
|
||||
Container images are usually given a name such as `pause`, `example/mycontainer`, or `kube-apiserver`.
|
||||
Images can also include a registry hostname; for example: `fictional.registry.example/imagename`,
|
||||
and possible a port number as well; for example: `fictional.registry.example:10443/imagename`.
|
||||
and possibly a port number as well; for example: `fictional.registry.example:10443/imagename`.
|
||||
|
||||
If you don't specify a registry hostname, Kubernetes assumes that you mean the Docker public registry.
|
||||
|
||||
|
||||
@@ -113,11 +113,13 @@ Operator.
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
* [Charmed Operator Framework](https://juju.is/)
|
||||
* [kubebuilder](https://book.kubebuilder.io/)
|
||||
* [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator)
|
||||
* [Metacontroller](https://metacontroller.app/) along with WebHooks that
|
||||
you implement yourself
|
||||
* [Operator Framework](https://operatorframework.io)
|
||||
* [shell-operator](https://github.com/flant/shell-operator)
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -21,7 +21,7 @@ This page is an overview of Kubernetes.
|
||||
<!-- body -->
|
||||
Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
|
||||
|
||||
The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community.
|
||||
The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the "K" and the "s". Google open-sourced the Kubernetes project in 2014. Kubernetes combines [over 15 years of Google's experience](/blog/2015/04/borg-predecessor-to-kubernetes/) running production workloads at scale with best-of-breed ideas and practices from the community.
|
||||
|
||||
## Going back in time
|
||||
|
||||
|
||||
@@ -39,7 +39,8 @@ on every resource object.
|
||||
| `app.kubernetes.io/version` | The current version of the application (e.g., a semantic version, revision hash, etc.) | `5.7.21` | string |
|
||||
| `app.kubernetes.io/component` | The component within the architecture | `database` | string |
|
||||
| `app.kubernetes.io/part-of` | The name of a higher level application this one is part of | `wordpress` | string |
|
||||
| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string |
|
||||
| `app.kubernetes.io/managed-by` | The tool being used to manage the operation of an application | `helm` | string |
|
||||
| `app.kubernetes.io/created-by` | The controller/user who created this resource | `controller-manager` | string |
|
||||
|
||||
To illustrate these labels in action, consider the following StatefulSet object:
|
||||
|
||||
@@ -54,6 +55,7 @@ metadata:
|
||||
app.kubernetes.io/component: database
|
||||
app.kubernetes.io/part-of: wordpress
|
||||
app.kubernetes.io/managed-by: helm
|
||||
app.kubernetes.io/created-by: controller-manager
|
||||
```
|
||||
|
||||
## Applications And Instances Of Applications
|
||||
@@ -170,4 +172,3 @@ metadata:
|
||||
|
||||
With the MySQL `StatefulSet` and `Service` you'll notice information about both MySQL and WordPress, the broader application, are included.
|
||||
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ Creation and deletion of namespaces are described in the
|
||||
[Admin Guide documentation for namespaces](/docs/tasks/administer-cluster/namespaces).
|
||||
|
||||
{{< note >}}
|
||||
Avoid creating namespace with prefix `kube-`, since it is reserved for Kubernetes system namespaces.
|
||||
Avoid creating namespaces with the prefix `kube-`, since it is reserved for Kubernetes system namespaces.
|
||||
{{< /note >}}
|
||||
|
||||
### Viewing namespaces
|
||||
|
||||
@@ -1,8 +1,11 @@
|
||||
---
|
||||
title: "Scheduling and Eviction"
|
||||
title: "Scheduling, Preemption and Eviction"
|
||||
weight: 90
|
||||
description: >
|
||||
In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes so that the kubelet can run them.
|
||||
Eviction is the process of proactively failing one or more Pods on resource-starved Nodes.
|
||||
In Kubernetes, scheduling refers to making sure that Pods are matched to Nodes
|
||||
so that the kubelet can run them. Preemption is the process of terminating
|
||||
Pods with lower Priority so that Pods with higher Priority can schedule on
|
||||
Nodes. Eviction is the process of proactively terminating one or more Pods on
|
||||
resource-starved Nodes.
|
||||
---
|
||||
|
||||
|
||||
@@ -113,7 +113,7 @@ enforced/disallowed:
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>AppArmor <em>(optional)</em></td>
|
||||
<td>AppArmor</td>
|
||||
<td>
|
||||
On supported hosts, the 'runtime/default' AppArmor profile is applied by default.
|
||||
The baseline policy should prevent overriding or disabling the default AppArmor
|
||||
@@ -124,14 +124,26 @@ enforced/disallowed:
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>SELinux <em>(optional)</em></td>
|
||||
<td>SELinux</td>
|
||||
<td>
|
||||
Setting custom SELinux options should be disallowed.<br>
|
||||
Setting the SELinux type is restricted, and setting a custom SELinux user or role option is forbidden.<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.securityContext.seLinuxOptions<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions<br>
|
||||
<br><b>Allowed Values:</b> undefined/nil<br>
|
||||
spec.securityContext.seLinuxOptions.type<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions.type<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions.type<br>
|
||||
<br><b>Allowed Values:</b><br>
|
||||
undefined/empty<br>
|
||||
container_t<br>
|
||||
container_init_t<br>
|
||||
container_kvm_t<br>
|
||||
<br><b>Restricted Fields:</b><br>
|
||||
spec.securityContext.seLinuxOptions.user<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions.user<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions.user<br>
|
||||
spec.securityContext.seLinuxOptions.role<br>
|
||||
spec.containers[*].securityContext.seLinuxOptions.role<br>
|
||||
spec.initContainers[*].securityContext.seLinuxOptions.role<br>
|
||||
<br><b>Allowed Values:</b> undefined/empty<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
|
||||
@@ -540,11 +540,11 @@ spec:
|
||||
|
||||
### Access Modes
|
||||
|
||||
Claims use the same conventions as volumes when requesting storage with specific access modes.
|
||||
Claims use [the same conventions as volumes](#access-modes) when requesting storage with specific access modes.
|
||||
|
||||
### Volume Modes
|
||||
|
||||
Claims use the same convention as volumes to indicate the consumption of the volume as either a filesystem or block device.
|
||||
Claims use [the same convention as volumes](#volume-mode) to indicate the consumption of the volume as either a filesystem or block device.
|
||||
|
||||
### Resources
|
||||
|
||||
|
||||
@@ -154,9 +154,9 @@ the class or PV. If a mount option is invalid, the PV mount fails.
|
||||
### Volume Binding Mode
|
||||
|
||||
The `volumeBindingMode` field controls when [volume binding and dynamic
|
||||
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
|
||||
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur. When unset, "Immediate" mode is used by default.
|
||||
|
||||
By default, the `Immediate` mode indicates that volume binding and dynamic
|
||||
The `Immediate` mode indicates that volume binding and dynamic
|
||||
provisioning occurs once the PersistentVolumeClaim is created. For storage
|
||||
backends that are topology-constrained and not globally accessible from all Nodes
|
||||
in the cluster, PersistentVolumes will be bound or provisioned without knowledge of the Pod's scheduling
|
||||
@@ -188,6 +188,36 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
|
||||
and pre-created PVs, but you'll need to look at the documentation for a specific CSI driver
|
||||
to see its supported topology keys and examples.
|
||||
|
||||
{{< note >}}
|
||||
If you choose to use `waitForFirstConsumer`, do not use `nodeName` in the Pod spec
|
||||
to specify node affinity. If `nodeName` is used in this case, the scheduler will be bypassed and PVC will remain in `pending` state.
|
||||
|
||||
Instead, you can use node selector for hostname in this case as shown below.
|
||||
{{< /note >}}
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
name: task-pv-pod
|
||||
spec:
|
||||
nodeSelector:
|
||||
kubernetes.io/hostname: kube-01
|
||||
volumes:
|
||||
- name: task-pv-storage
|
||||
persistentVolumeClaim:
|
||||
claimName: task-pv-claim
|
||||
containers:
|
||||
- name: task-pv-container
|
||||
image: nginx
|
||||
ports:
|
||||
- containerPort: 80
|
||||
name: "http-server"
|
||||
volumeMounts:
|
||||
- mountPath: "/usr/share/nginx/html"
|
||||
name: task-pv-storage
|
||||
```
|
||||
|
||||
### Allowed Topologies
|
||||
|
||||
When a cluster operator specifies the `WaitForFirstConsumer` volume binding mode, it is no longer necessary
|
||||
|
||||
@@ -80,12 +80,14 @@ Here are some ways to mitigate involuntary disruptions:
|
||||
[multi-zone cluster](/docs/setup/multiple-zones).)
|
||||
|
||||
The frequency of voluntary disruptions varies. On a basic Kubernetes cluster, there are
|
||||
no voluntary disruptions at all. However, your cluster administrator or hosting provider
|
||||
no automated voluntary disruptions (only user-triggered ones). However, your cluster administrator or hosting provider
|
||||
may run some additional services which cause voluntary disruptions. For example,
|
||||
rolling out node software updates can cause voluntary disruptions. Also, some implementations
|
||||
of cluster (node) autoscaling may cause voluntary disruptions to defragment and compact nodes.
|
||||
Your cluster administrator or hosting provider should have documented what level of voluntary
|
||||
disruptions, if any, to expect.
|
||||
disruptions, if any, to expect. Certain configuration options, such as
|
||||
[using PriorityClasses](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/)
|
||||
in your pod spec can also cause voluntary (and involuntary) disruptions.
|
||||
|
||||
|
||||
## Pod disruption budgets
|
||||
|
||||
@@ -246,7 +246,7 @@ myapp-pod 1/1 Running 0 9m
|
||||
```
|
||||
|
||||
This simple example should provide some inspiration for you to create your own
|
||||
init containers. [What's next](#whats-next) contains a link to a more detailed example.
|
||||
init containers. [What's next](#what-s-next) contains a link to a more detailed example.
|
||||
|
||||
## Detailed behavior
|
||||
|
||||
@@ -326,7 +326,6 @@ Kubernetes, consult the documentation for the version you are using.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container)
|
||||
* Learn how to [debug init containers](/docs/tasks/debug-application-cluster/debug-init-containers/)
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ obsolete -->
|
||||
You can use _topology spread constraints_ to control how {{< glossary_tooltip text="Pods" term_id="Pod" >}} are spread across your cluster among failure-domains such as regions, zones, nodes, and other user-defined topology domains. This can help to achieve high availability as well as efficient resource utilization.
|
||||
|
||||
{{< note >}}
|
||||
In versions of Kubernetes before v1.19, you must enable the `EvenPodsSpread`
|
||||
In versions of Kubernetes before v1.18, you must enable the `EvenPodsSpread`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) on
|
||||
the [API server](/docs/concepts/overview/components/#kube-apiserver) and the
|
||||
[scheduler](/docs/reference/generated/kube-scheduler/) in order to use Pod
|
||||
|
||||
Reference in New Issue
Block a user