Add admonition type to shortcode (#9482)
* Change existing admon blocks * Fix includes issue
This commit is contained in:
committed by
k8s-ci-robot
parent
e839031292
commit
d65e1790ff
@@ -51,7 +51,7 @@ In version 1.9, the CCM runs the following controllers from the preceding list:
|
||||
Additionally, it runs another controller called the PersistentVolumeLabels controller. This controller is responsible for setting the zone and region labels on PersistentVolumes created in GCP and AWS clouds.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
|
||||
Volume controller was deliberately chosen to not be a part of CCM. Due to the complexity involved and due to the existing efforts to abstract away vendor specific volume logic, it was decided that volume controller will not be moved to CCM.
|
||||
{{< /note >}}
|
||||
|
||||
The original plan to support volumes using CCM was to use Flex volumes to support pluggable volumes. However, a competing effort known as CSI is being planned to replace Flex.
|
||||
|
||||
@@ -84,7 +84,7 @@ A Pod that does not have any tolerations gets scheduled according to the old mod
|
||||
tolerates the taints of a particular Node can be scheduled on that Node.
|
||||
|
||||
{{< caution >}}
|
||||
**Caution:** Enabling this feature creates a small delay between the
|
||||
Enabling this feature creates a small delay between the
|
||||
time when a condition is observed and when a taint is created. This delay is usually less than one second, but it can increase the number of Pods that are successfully scheduled but rejected by the kubelet.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -128,7 +128,7 @@ services are running -- it is eligible to run a pod. Otherwise, it is
|
||||
ignored for any cluster activity until it becomes valid.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.
|
||||
Kubernetes keeps the object for the invalid node and keeps checking to see whether it becomes valid.
|
||||
You must explicitly delete the Node object to stop this process.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -241,7 +241,7 @@ kubectl cordon $NODENAME
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Pods created by a DaemonSet controller bypass the Kubernetes scheduler
|
||||
Pods created by a DaemonSet controller bypass the Kubernetes scheduler
|
||||
and do not respect the unschedulable attribute on a node. This assumes that daemons belong on
|
||||
the machine even if it is being drained of applications while it prepares for a reboot.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -57,7 +57,9 @@ You can use `kubectl logs` to retrieve logs from a previous instantiation of a c
|
||||
|
||||
Everything a containerized application writes to `stdout` and `stderr` is handled and redirected somewhere by a container engine. For example, the Docker container engine redirects those two streams to [a logging driver](https://docs.docker.com/engine/admin/logging/overview), which is configured in Kubernetes to write to a file in json format.
|
||||
|
||||
**Note:** The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
|
||||
{{< note >}}
|
||||
The Docker json logging driver treats each line as a separate message. When using the Docker logging driver, there is no direct support for multi-line messages. You need to handle multi-line messages at the logging agent level or higher.
|
||||
{{< /note >}}
|
||||
|
||||
By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs.
|
||||
|
||||
@@ -81,13 +83,15 @@ When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands
|
||||
the basic logging example, the kubelet on the node handles the request and
|
||||
reads directly from the log file, returning the contents in the response.
|
||||
|
||||
**Note:** Currently, if some external system has performed the rotation,
|
||||
{{< note >}}
|
||||
Currently, if some external system has performed the rotation,
|
||||
only the contents of the latest log file will be available through
|
||||
`kubectl logs`. E.g. if there's a 10MB file, `logrotate` performs
|
||||
the rotation and there are two files, one 10MB in size and one empty,
|
||||
`kubectl logs` will return an empty response.
|
||||
|
||||
[cosConfigureHelper]: https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh
|
||||
{{< /note >}}
|
||||
|
||||
### System component logs
|
||||
|
||||
@@ -215,10 +219,12 @@ If the node-level logging agent is not flexible enough for your situation, you
|
||||
can create a sidecar container with a separate logging agent that you have
|
||||
configured specifically to run with your application.
|
||||
|
||||
**Note**: Using a logging agent in a sidecar container can lead
|
||||
{{< note >}}
|
||||
Using a logging agent in a sidecar container can lead
|
||||
to significant resource consumption. Moreover, you won't be able to access
|
||||
those logs using `kubectl logs` command, because they are not controlled
|
||||
by the kubelet.
|
||||
{{< /note >}}
|
||||
|
||||
As an example, you could use [Stackdriver](/docs/tasks/debug-application-cluster/logging-stackdriver/),
|
||||
which uses fluentd as a logging agent. Here are two configuration files that
|
||||
@@ -227,9 +233,11 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c
|
||||
|
||||
{{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}}
|
||||
|
||||
**Note**: The configuration of fluentd is beyond the scope of this article. For
|
||||
{{< note >}}
|
||||
The configuration of fluentd is beyond the scope of this article. For
|
||||
information about configuring fluentd, see the
|
||||
[official fluentd documentation](http://docs.fluentd.org/).
|
||||
{{< /note >}}
|
||||
|
||||
The second file describes a pod that has a sidecar container running fluentd.
|
||||
The pod mounts a volume where fluentd can pick up its configuration data.
|
||||
|
||||
@@ -331,7 +331,7 @@ Currently, resources are created without this annotation, so the first invocatio
|
||||
All subsequent calls to `kubectl apply`, and other commands that modify the configuration, such as `kubectl replace` and `kubectl edit`, will update the annotation, allowing subsequent calls to `kubectl apply` to detect and perform deletions using a three-way diff.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
||||
To use apply, always create resource initially with either `kubectl apply` or `kubectl create --save-config`.
|
||||
{{< /note >}}
|
||||
|
||||
### kubectl edit
|
||||
|
||||
@@ -87,7 +87,7 @@ with a standard set of labels. As of Kubernetes v1.4 these labels are
|
||||
* `beta.kubernetes.io/arch`
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The value of these labels is cloud provider specific and is not guaranteed to be reliable.
|
||||
The value of these labels is cloud provider specific and is not guaranteed to be reliable.
|
||||
For example, the value of `kubernetes.io/hostname` may be the same as the Node name in some environments
|
||||
and a different value in other environments.
|
||||
{{< /note >}}
|
||||
@@ -173,11 +173,15 @@ like node, rack, cloud provider zone, cloud provider region, etc. You express it
|
||||
key for the node label that the system uses to denote such a topology domain, e.g. see the label keys listed above
|
||||
in the section [Interlude: built-in node labels](#interlude-built-in-node-labels).
|
||||
|
||||
**Note:** Inter-pod affinity and anti-affinity require substantial amount of
|
||||
{{< note >}}
|
||||
Inter-pod affinity and anti-affinity require substantial amount of
|
||||
processing which can slow down scheduling in large clusters significantly. We do
|
||||
not recommend using them in clusters larger than several hundred nodes.
|
||||
{{< /note >}}
|
||||
|
||||
**Note:** Pod anti-affinity requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior.
|
||||
{{< note >}}
|
||||
Pod anti-affinity requires nodes to be consistently labelled, i.e. every node in the cluster must have an appropriate label matching `topologyKey`. If some or all nodes are missing the specified `topologyKey` label, it can lead to unintended behavior.
|
||||
{{< /note >}}
|
||||
|
||||
As with node affinity, there are currently two types of pod affinity and anti-affinity, called `requiredDuringSchedulingIgnoredDuringExecution` and
|
||||
`preferredDuringSchedulingIgnoredDuringExecution` which denote "hard" vs. "soft" requirements.
|
||||
|
||||
@@ -149,7 +149,9 @@ When using Docker:
|
||||
multiplied by 100. The resulting value is the total amount of CPU time that a container can use
|
||||
every 100ms. A container cannot use more than its share of CPU time during this interval.
|
||||
|
||||
{{< note >}}**Note**: The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.{{</ note >}}
|
||||
{{< note >}}
|
||||
The default quota period is 100ms. The minimum resolution of CPU quota is 1ms.
|
||||
{{</ note >}}
|
||||
|
||||
- The `spec.containers[].resources.limits.memory` is converted to an integer, and
|
||||
used as the value of the
|
||||
@@ -317,7 +319,7 @@ Kubernetes version 1.8 introduces a new resource, _ephemeral-storage_ for managi
|
||||
This partition is “ephemeral” and applications cannot expect any performance SLAs (Disk IOPS for example) from this partition. Local ephemeral storage management only applies for the root partition; the optional partition for image layer and writable layer is out of scope.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
|
||||
If an optional runtime partition is used, root partition will not hold any image layer or writable layers.
|
||||
{{< /note >}}
|
||||
|
||||
### Requests and limits setting for local ephemeral storage
|
||||
@@ -420,7 +422,7 @@ http://k8s-master:8080/api/v1/nodes/k8s-node-1/status
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note**: In the preceding request, `~1` is the encoding for the character `/`
|
||||
In the preceding request, `~1` is the encoding for the character `/`
|
||||
in the patch path. The operation path value in JSON-Patch is interpreted as a
|
||||
JSON-Pointer. For more details, see
|
||||
[IETF RFC 6901, section 3](https://tools.ietf.org/html/rfc6901#section-3).
|
||||
@@ -476,7 +478,7 @@ Examples of _valid_ quantities are `3`, `3000m` and `3Ki`. Examples of
|
||||
_invalid_ quantities are `0.5` and `1500m`.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Extended resources replace Opaque Integer Resources.
|
||||
Extended resources replace Opaque Integer Resources.
|
||||
Users can use any domain name prefix other than `kubernetes.io` which is reserved.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -484,7 +486,7 @@ To consume an extended resource in a Pod, include the resource name as a key
|
||||
in the `spec.containers[].resources.limits` map in the container spec.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Extended resources cannot be overcommitted, so request and limit
|
||||
Extended resources cannot be overcommitted, so request and limit
|
||||
must be equal if both are present in a container spec.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ find the information it needs to choose a cluster and communicate with the API s
|
||||
of a cluster.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A file that is used to configure access to clusters is called
|
||||
A file that is used to configure access to clusters is called
|
||||
a *kubeconfig file*. This is a generic way of referring to configuration files.
|
||||
It does not mean that there is a file named `kubeconfig`.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -84,15 +84,15 @@ The [imagePullPolicy](/docs/concepts/containers/images/#updating-images) and the
|
||||
- `imagePullPolicy: Never`: the image is assumed to exist locally. No attempt is made to pull the image.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
|
||||
To make sure the container always uses the same version of the image, you can specify its [digest](https://docs.docker.com/engine/reference/commandline/pull/#pull-an-image-by-digest-immutable-identifier), for example `sha256:45b23dee08af5e43a7fea6c4cf9c25ccf269ee113168c19722f87876677c5cb2`. The digest uniquely identifies a specific version of the image, so it is never updated by Kubernetes unless you change the digest value.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
|
||||
You should avoid using the `:latest` tag when deploying containers in production as it is harder to track which version of the image is running and more difficult to roll back properly.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
|
||||
The caching semantics of the underlying image provider make even `imagePullPolicy: Always` efficient. With Docker, for example, if the image already exists, the pull attempt is fast because all image layers are cached and no image download is needed.
|
||||
{{< /note >}}
|
||||
|
||||
## Using kubectl
|
||||
|
||||
@@ -36,7 +36,7 @@ Kubernetes Version | Priority and Preemption State | Enabled by default
|
||||
1.10 | alpha | no
|
||||
1.11 | beta | yes
|
||||
|
||||
{{< warning >}} **Warning**: In a cluster where not all users are trusted, a
|
||||
{{< warning >}}In a cluster where not all users are trusted, a
|
||||
malicious user could create pods at the highest possible priorities, causing
|
||||
other pods to be evicted/not get scheduled. To resolve this issue,
|
||||
[ResourceQuota](https://kubernetes.io/docs/concepts/policy/resource-quotas/) is
|
||||
@@ -71,24 +71,13 @@ Pods.
|
||||
|
||||
## How to disable preemption
|
||||
|
||||
{{< note >}} **Note**: In Kubernetes 1.11, critical pods (except DaemonSet pods,
|
||||
which are still scheduled by the DaemonSet controller) rely on scheduler
|
||||
preemption to be scheduled when a cluster is under resource pressure. For this
|
||||
reason, you will need to run an older version of Rescheduler if you decide to
|
||||
disable preemption. More on this is provided below. {{< /note >}}
|
||||
|
||||
#### Option 1: Disable both Pod priority and preemption
|
||||
|
||||
Disabling Pod priority disables preemption as well. In order to disable Pod
|
||||
Priority, set the feature to false for API server, Scheduler, and Kubelet.
|
||||
Disabling the feature on Kubelets is not vital. You can leave the feature on for
|
||||
Kubelets if rolling out is hard.
|
||||
|
||||
```
|
||||
--feature-gates=PodPriority=false
|
||||
```
|
||||
|
||||
#### Option 2: Disable Preemption only
|
||||
{{< note >}}
|
||||
In Kubernetes 1.11, critical pods (except DaemonSet pods, which are
|
||||
still scheduled by the DaemonSet controller) rely on scheduler preemption to be
|
||||
scheduled when a cluster is under resource pressure. For this reason, you will
|
||||
need to run an older version of Rescheduler if you decide to disable preemption.
|
||||
More on this is provided below.
|
||||
{{< /note >}}
|
||||
|
||||
In Kubernetes 1.11 and later, preemption is controlled by a kube-scheduler flag
|
||||
`disablePreemption`, which is set to `false` by default.
|
||||
@@ -266,11 +255,13 @@ A Node is considered for preemption only when the answer to this question is
|
||||
yes: "If all the Pods with lower priority than the pending Pod are removed from
|
||||
the Node, can the pending Pod be scheduled on the Node?"
|
||||
|
||||
{{< note >}} **Note:** Preemption does not necessarily remove all lower-priority
|
||||
{{< note >}}
|
||||
Preemption does not necessarily remove all lower-priority
|
||||
Pods. If the pending Pod can be scheduled by removing fewer than all
|
||||
lower-priority Pods, then only a portion of the lower-priority Pods are removed.
|
||||
Even so, the answer to the preceding question must be yes. If the answer is no,
|
||||
the Node is not considered for preemption. {{< /note >}}
|
||||
the Node is not considered for preemption.
|
||||
{{< /note >}}
|
||||
|
||||
If a pending Pod has inter-pod affinity to one or more of the lower-priority
|
||||
Pods on the Node, the inter-Pod affinity rule cannot be satisfied in the absence
|
||||
|
||||
@@ -45,9 +45,11 @@ algorithmSource:
|
||||
percentageOfNodesToScore: 50
|
||||
```
|
||||
|
||||
{{< note >}} **Note**: In clusters with zero or less than 50 feasible nodes, the
|
||||
{{< note >}}
|
||||
In clusters with zero or less than 50 feasible nodes, the
|
||||
scheduler still checks all the nodes, simply because there are not enough
|
||||
feasible nodes to stop the scheduler's search early. {{< /note >}}
|
||||
feasible nodes to stop the scheduler's search early.
|
||||
{{< /note >}}
|
||||
|
||||
**To disable this feature**, you can set `percentageOfNodesToScore` to 100.
|
||||
|
||||
|
||||
@@ -353,7 +353,7 @@ propagation delay, where cache propagation delay depends on the chosen cache typ
|
||||
(it equals to watch propagation delay, ttl of cache, or zero corespondingly).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A container using a Secret as a
|
||||
A container using a Secret as a
|
||||
[subPath](/docs/concepts/storage/volumes#using-subpath) volume mount will not receive
|
||||
Secret updates.
|
||||
{{< /note >}}
|
||||
@@ -492,7 +492,7 @@ $ kubectl create secret generic ssh-key-secret --from-file=ssh-privatekey=/path/
|
||||
```
|
||||
|
||||
{{< caution >}}
|
||||
**Caution:** Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
|
||||
Think carefully before sending your own ssh keys: other users of the cluster may have access to the secret. Use a service account which you want to be accessible to all the users with whom you share the Kubernetes cluster, and can revoke if they are compromised.
|
||||
{{< /caution >}}
|
||||
|
||||
|
||||
@@ -544,7 +544,7 @@ $ kubectl create secret generic test-db-secret --from-literal=username=testuser
|
||||
secret "test-db-secret" created
|
||||
```
|
||||
{{< note >}}
|
||||
**Note:** Special characters such as `$`, `\*`, and `!` require escaping.
|
||||
Special characters such as `$`, `\*`, and `!` require escaping.
|
||||
If the password you are using has special characters, you need to escape them using the `\\` character. For example, if your actual password is `S!B\*d$zDsb`, you should execute the command this way:
|
||||
|
||||
kubectl create secret generic dev-db-secret --from-literal=username=devuser --from-literal=password=S\\!B\\\*d\\$zDsb
|
||||
@@ -665,7 +665,7 @@ the `dotfile-test-container` will have this file present at the path
|
||||
`/etc/secret-volume/.secret-file`.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: Files beginning with dot characters are hidden from the output of `ls -l`;
|
||||
Files beginning with dot characters are hidden from the output of `ls -l`;
|
||||
you must use `ls -la` to see them when listing directory contents.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -774,7 +774,7 @@ Pod level](#use-case-secret-visible-to-one-container-in-a-pod).
|
||||
single node.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** As of 1.7 [encryption of secret data at rest is supported](/docs/tasks/administer-cluster/encrypt-data/).
|
||||
As of 1.7 [encryption of secret data at rest is supported](/docs/tasks/administer-cluster/encrypt-data/).
|
||||
{{< /note >}}
|
||||
|
||||
{{% capture whatsnext %}}
|
||||
|
||||
@@ -69,7 +69,7 @@ A toleration "matches" a taint if the keys are the same and the effects are the
|
||||
`Operator` defaults to `Equal` if not specified.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** There are two special cases:
|
||||
There are two special cases:
|
||||
|
||||
* An empty `key` with operator `Exists` matches all keys, values and effects which means this
|
||||
will tolerate everything.
|
||||
@@ -230,7 +230,7 @@ added by the NodeController (or kubelet) and the normal logic for evicting pods
|
||||
based on the Ready NodeCondition is disabled.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
|
||||
To maintain the existing [rate limiting](/docs/concepts/architecture/nodes/)
|
||||
behavior of pod evictions due to node problems, the system actually adds the taints
|
||||
in a rate-limited way. This prevents massive pod evictions in scenarios such
|
||||
as the master becoming partitioned from the nodes.
|
||||
|
||||
@@ -44,7 +44,7 @@ https://cs.k8s.io/?q=docker%20manifest%20(create%7Cpush%7Cannotate)&i=nope&files
|
||||
These commands rely on and are implemented purely on the Docker CLI. You will need to either edit the `$HOME/.docker/config.json` and set `experimental` key to `enabled` or you can just set `DOCKER_CLI_EXPERIMENTAL` environment variable to `enabled` when you call the CLI commands.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
|
||||
Please use Docker *18.06 or above*, versions below that either have bugs or do not support the experimental command line option. Example https://github.com/docker/cli/issues/1135 causes problems under containerd.
|
||||
{{< /note >}}
|
||||
|
||||
If you run into trouble with uploading stale manifests, just clean up the older manifests in `$HOME/.docker/manifests` to start fresh.
|
||||
@@ -156,16 +156,16 @@ You can use the IBM Cloud Container Registry to deploy containers from [IBM Clou
|
||||
### Configuring Nodes to Authenticate to a Private Registry
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
|
||||
If you are running on AWS EC2 and are using the EC2 Container Registry (ECR), the kubelet on each node will
|
||||
manage and update the ECR login credentials. You cannot use this approach.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This approach is suitable if you can control node configuration. It
|
||||
This approach is suitable if you can control node configuration. It
|
||||
will not work reliably on GCE, and any other cloud provider that does automatic
|
||||
node replacement.
|
||||
{{< /note >}}
|
||||
@@ -183,7 +183,7 @@ in the search paths list below, kubelet uses it as the credential provider when
|
||||
* `/.dockercfg`
|
||||
|
||||
{{< note >}}
|
||||
**Note**: You may have to set `HOME=/root` explicitly in your environment file for kubelet.
|
||||
You may have to set `HOME=/root` explicitly in your environment file for kubelet.
|
||||
{{< /note >}}
|
||||
|
||||
Here are the recommended steps to configuring your nodes to use a private registry. In this
|
||||
@@ -240,11 +240,11 @@ registry keys are added to the `.docker/config.json`.
|
||||
### Pre-pulling Images
|
||||
|
||||
{{< note >}}
|
||||
**Note:** If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
If you are running on Google Kubernetes Engine, there will already be a `.dockercfg` on each node with credentials for Google Container Registry. You cannot use this approach.
|
||||
{{< /note >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This approach is suitable if you can control node configuration. It
|
||||
This approach is suitable if you can control node configuration. It
|
||||
will not work reliably on GCE, and any other cloud provider that does automatic
|
||||
node replacement.
|
||||
{{< /note >}}
|
||||
@@ -263,7 +263,7 @@ All pods will have read access to any pre-pulled images.
|
||||
### Specifying ImagePullSecrets on a Pod
|
||||
|
||||
{{< note >}}
|
||||
**Note:** This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
|
||||
This approach is currently the recommended approach for Google Kubernetes Engine, GCE, and any cloud-providers
|
||||
where node creation is automated.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ corresponding documentation for your CRI implementation for how to configure. As
|
||||
feature, not all CRIs support multiple RuntimeClasses yet.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** RuntimeClass currently assumes a homogeneous node configuration across the cluster
|
||||
RuntimeClass currently assumes a homogeneous node configuration across the cluster
|
||||
(which means that all nodes are configured the same way with respect to container runtimes). Any heterogeneity (varying configurations) must be
|
||||
managed independently of RuntimeClass through scheduling features (see [Assigning Pods to
|
||||
Nodes](/docs/concepts/configuration/assign-pod-node/)).
|
||||
@@ -87,11 +87,9 @@ spec:
|
||||
|
||||
|
||||
{{< note >}}
|
||||
|
||||
**Note:** It is recommended that RuntimeClass write operations (create/update/patch/delete) be
|
||||
It is recommended that RuntimeClass write operations (create/update/patch/delete) be
|
||||
restricted to the cluster administrator. This is typically the default. See [Authorization
|
||||
Overview](https://kubernetes.io/docs/reference/access-authn-authz/authorization/) for more details.
|
||||
|
||||
{{< /note >}}
|
||||
|
||||
### Usage
|
||||
|
||||
@@ -8,7 +8,9 @@ toc_hide: true
|
||||
|
||||
{{% capture overview %}}
|
||||
|
||||
**NOTE:** Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
|
||||
{{< note >}}
|
||||
Be sure to also [create an entry in the table of contents](/docs/home/contribute/write-new-topic/#creating-an-entry-in-the-table-of-contents) for your new document.
|
||||
{{< /note >}}
|
||||
|
||||
This page explains ...
|
||||
|
||||
|
||||
@@ -91,7 +91,7 @@ Use a ConfigMap if any of the following apply:
|
||||
* You want to perform rolling updates via Deployment, etc, when the file is updated.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
|
||||
Use a [secret](/docs/concepts/configuration/secret/) for sensitive data, which is similar to a configMap but more secure.
|
||||
{{< /note >}}
|
||||
|
||||
Use a custom resource (CRD or Aggregated API) if most of the following apply:
|
||||
@@ -131,7 +131,7 @@ for a demonstration of how to register a new custom resource, work with instance
|
||||
and setup a controller to handle events.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** CRD is the successor to the deprecated *ThirdPartyResource* (TPR) API, and is available as of Kubernetes 1.7.
|
||||
CRD is the successor to the deprecated *ThirdPartyResource* (TPR) API, and is available as of Kubernetes 1.7.
|
||||
{{< /note >}}
|
||||
|
||||
## API server aggregation
|
||||
|
||||
@@ -60,7 +60,7 @@ annotation on each object. The annotation contains the contents of the object
|
||||
configuration file that was used to create the object.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Add the `-R` flag to recursively process directories.
|
||||
Add the `-R` flag to recursively process directories.
|
||||
{{< /note >}}
|
||||
|
||||
Here's an example of an object configuration file:
|
||||
@@ -134,7 +134,7 @@ kubectl apply -f <directory>/
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Add the `-R` flag to recursively process directories.
|
||||
Add the `-R` flag to recursively process directories.
|
||||
{{< /note >}}
|
||||
|
||||
Here's an example configuration file:
|
||||
@@ -148,7 +148,7 @@ kubectl apply -f https://k8s.io/examples/application/simple_deployment.yaml
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** For purposes of illustration, the preceding command refers to a single
|
||||
For purposes of illustration, the preceding command refers to a single
|
||||
configuration file instead of a directory.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -322,7 +322,7 @@ spec:
|
||||
```
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** Mixing `kubectl apply` with the imperative object configuration commands
|
||||
Mixing `kubectl apply` with the imperative object configuration commands
|
||||
`create` and `replace` is not supported. This is because `create`
|
||||
and `replace` do not retain the `kubectl.kubernetes.io/last-applied-configuration`
|
||||
that `kubectl apply` uses to compute updates.
|
||||
@@ -347,12 +347,12 @@ kubectl delete -f <filename>
|
||||
Only use this if you know what you are doing.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** `kubectl apply --prune` is in alpha, and backwards incompatible
|
||||
`kubectl apply --prune` is in alpha, and backwards incompatible
|
||||
changes might be introduced in subsequent releases.
|
||||
{{< /warning >}}
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** You must be careful when using this command, so that you
|
||||
You must be careful when using this command, so that you
|
||||
do not delete objects unintentionally.
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -373,7 +373,7 @@ kubectl apply -f <directory/> --prune -l <labels>
|
||||
```
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** Apply with prune should only be run against the root directory
|
||||
Apply with prune should only be run against the root directory
|
||||
containing the object configuration files. Running against sub-directories
|
||||
can cause objects to be unintentionally deleted if they are returned
|
||||
by the label selector query specified with `-l <labels>` and
|
||||
@@ -391,10 +391,9 @@ kubectl get -f <filename|url> -o yaml
|
||||
## How apply calculates differences and merges changes
|
||||
|
||||
{{< caution >}}
|
||||
**Caution:** A *patch* is an update operation that is scoped to specific
|
||||
fields of an object instead of the entire object.
|
||||
This enables updating only a specific set of fields on an object without
|
||||
reading the object first.
|
||||
A *patch* is an update operation that is scoped to specific fields of an object
|
||||
instead of the entire object. This enables updating only a specific set of fields
|
||||
on an object without reading the object first.
|
||||
{{< /caution >}}
|
||||
|
||||
When `kubectl apply` updates the live configuration for an object,
|
||||
@@ -546,7 +545,7 @@ and merged.
|
||||
Primitive fields are replaced or cleared.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** '-' is used for "not applicable" because the value is not used.
|
||||
`-` is used for "not applicable" because the value is not used.
|
||||
{{< /note >}}
|
||||
|
||||
| Field in object configuration file | Field in live object configuration | Field in last-applied-configuration | Action |
|
||||
@@ -561,7 +560,7 @@ Primitive fields are replaced or cleared.
|
||||
Fields that represent maps are merged by comparing each of the subfields or elements of the map:
|
||||
|
||||
{{< note >}}
|
||||
**Note:** '-' is used for "not applicable" because the value is not used.
|
||||
`-` is used for "not applicable" because the value is not used.
|
||||
{{< /note >}}
|
||||
|
||||
| Key in object configuration file | Key in live object configuration | Field in last-applied-configuration | Action |
|
||||
@@ -689,7 +688,7 @@ by `name`.
|
||||
As of Kubernetes 1.5, merging lists of primitive elements is not supported.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Which of the above strategies is chosen for a given field is controlled by
|
||||
Which of the above strategies is chosen for a given field is controlled by
|
||||
the `patchStrategy` tag in [types.go](https://git.k8s.io/api/core/v1/types.go#L2565)
|
||||
If no `patchStrategy` is specified for a field of type list, then
|
||||
the list is replaced.
|
||||
@@ -900,7 +899,7 @@ Kubernetes objects should be managed using only one method at a time.
|
||||
Switching from one method to another is possible, but is a manual process.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** It is OK to use imperative deletion with declarative management.
|
||||
It is OK to use imperative deletion with declarative management.
|
||||
{{< /note >}}
|
||||
|
||||
{{< comment >}}
|
||||
@@ -924,8 +923,10 @@ configuration involves several manual steps:
|
||||
|
||||
1. Manually remove the `status` field from the configuration file.
|
||||
|
||||
{{< note >}}**Note:** This step is optional, as `kubectl apply` does not update the status field
|
||||
even if it is present in the configuration file.{{< /note >}}
|
||||
{{< note >}}
|
||||
This step is optional, as `kubectl apply` does not update the status field
|
||||
even if it is present in the configuration file.
|
||||
{{< /note >}}
|
||||
|
||||
1. Set the `kubectl.kubernetes.io/last-applied-configuration` annotation on the object:
|
||||
|
||||
@@ -952,7 +953,7 @@ TODO(pwittrock): Why doesn't export remove the status field? Seems like it shou
|
||||
## Defining controller selectors and PodTemplate labels
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** Updating selectors on controllers is strongly discouraged.
|
||||
Updating selectors on controllers is strongly discouraged.
|
||||
{{< /warning >}}
|
||||
|
||||
The recommended approach is to define a single, immutable PodTemplate label
|
||||
|
||||
@@ -76,8 +76,7 @@ Setting this aspect may set different fields for different object types:
|
||||
- `set` <field>: Set an aspect of an object.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: In Kubernetes version 1.5, not every verb-driven command has an
|
||||
associated aspect-driven command.
|
||||
In Kubernetes version 1.5, not every verb-driven command has an associated aspect-driven command.
|
||||
{{< /note >}}
|
||||
|
||||
The `kubectl` tool supports these additional ways to update a live object directly,
|
||||
@@ -95,7 +94,7 @@ You can use the `delete` command to delete an object from a cluster:
|
||||
- `delete <type>/<name>`
|
||||
|
||||
{{< note >}}
|
||||
**Note**: You can use `kubectl delete` for both imperative commands and imperative object
|
||||
You can use `kubectl delete` for both imperative commands and imperative object
|
||||
configuration. The difference is in the arguments passed to the command. To use
|
||||
`kubectl delete` as an imperative command, pass the object to be deleted as
|
||||
an argument. Here's an example that passes a Deployment object named nginx:
|
||||
|
||||
@@ -34,7 +34,7 @@ for details.
|
||||
## How to update objects
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** Updating objects with the `replace` command drops all
|
||||
Updating objects with the `replace` command drops all
|
||||
parts of the spec not specified in the configuration file. This
|
||||
should not be used with objects whose specs are partially managed
|
||||
by the cluster, such as Services of type `LoadBalancer`, where
|
||||
@@ -115,7 +115,7 @@ kubectl replace -f <kind>_<name>.yaml
|
||||
## Defining controller selectors and PodTemplate labels
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** Updating selectors on controllers is strongly discouraged.
|
||||
Updating selectors on controllers is strongly discouraged.
|
||||
{{< /warning >}}
|
||||
|
||||
The recommended approach is to define a single, immutable PodTemplate label
|
||||
|
||||
@@ -15,7 +15,7 @@ approaches.
|
||||
## Management techniques
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** A Kubernetes object should be managed using only one technique. Mixing
|
||||
A Kubernetes object should be managed using only one technique. Mixing
|
||||
and matching techniques for the same object results in undefined behavior.
|
||||
{{< /warning >}}
|
||||
|
||||
@@ -74,7 +74,7 @@ See the [API reference](/docs/reference/generated/kubernetes-api/{{< param "vers
|
||||
for more details on object definitions.
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** The imperative `replace` command replaces the existing
|
||||
The imperative `replace` command replaces the existing
|
||||
spec with the newly provided one, dropping all changes to the object missing from
|
||||
the configuration file. This approach should not be used with resource
|
||||
types whose specs are updated independently of the configuration file.
|
||||
@@ -135,7 +135,7 @@ are automatically detected per-object by `kubectl`. This enables working on
|
||||
directories, where different operations might be needed for different objects.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Declarative object configuration retains changes made by other
|
||||
Declarative object configuration retains changes made by other
|
||||
writers, even if the changes are not merged back to the object configuration file.
|
||||
This is possible by using the `patch` API operation to write only
|
||||
observed differences, instead of using the `replace`
|
||||
|
||||
@@ -19,7 +19,7 @@ Instead, applications are informal and described with metadata. The definition o
|
||||
what an application contains is loose.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** These are recommended labels. They make it easier to manage applications
|
||||
These are recommended labels. They make it easier to manage applications
|
||||
but aren't required for any core tooling.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ An empty label selector (that is, one with zero requirements) selects every obje
|
||||
A null label selector (which is only possible for optional selector fields) selects no objects.
|
||||
|
||||
{{< note >}}
|
||||
**Note**: the label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
|
||||
The label selectors of two controllers must not overlap within a namespace, otherwise they will fight with each other.
|
||||
{{< /note >}}
|
||||
|
||||
### _Equality-based_ requirement
|
||||
|
||||
@@ -230,8 +230,8 @@ Create the rolebinding to grant `fake-user` the `use` verb on the example
|
||||
policy:
|
||||
|
||||
{{< note >}}
|
||||
**Note:** _This is not the recommended way! See the [next section](#run-another-pod)
|
||||
for the preferred approach._
|
||||
This is not the recommended way! See the [next section](#run-another-pod)
|
||||
for the preferred approach.
|
||||
{{< /note >}}
|
||||
|
||||
```shell
|
||||
@@ -442,7 +442,7 @@ allowedHostPaths:
|
||||
readOnly: true # only allow read-only mounts
|
||||
```
|
||||
|
||||
{{< warning >}}**Warning:** There are many ways a container with unrestricted access to the host
|
||||
{{< warning >}}There are many ways a container with unrestricted access to the host
|
||||
filesystem can escalate privileges, including reading data from other
|
||||
containers, and abusing the credentials of system services, such as Kubelet.
|
||||
|
||||
|
||||
@@ -202,7 +202,7 @@ field in the quota spec.
|
||||
A quota is matched and consumed only if `scopeSelector` in the quota spec selects the pod.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You need to enable the feature gate `ResourceQuotaScopeSelectors`before using resource quotas
|
||||
You need to enable the feature gate `ResourceQuotaScopeSelectors`before using resource quotas
|
||||
per PriorityClass.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -149,7 +149,7 @@ The Endpoints object can specify the `hostname` for any endpoint addresses,
|
||||
along with its IP.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Because A records are not created for Pod names, `hostname` is required for the Pod's A record to be created. A Pod with no `hostname` but with `subdomain` only will only create the A record for the headless service (`default-subdomain.my-namespace.svc.cluster.local`), pointing to the Pod's IP address.
|
||||
Because A records are not created for Pod names, `hostname` is required for the Pod's A record to be created. A Pod with no `hostname` but with `subdomain` only will only create the A record for the headless service (`default-subdomain.my-namespace.svc.cluster.local`), pointing to the Pod's IP address.
|
||||
{{< /note >}}
|
||||
|
||||
### Pod's DNS Policy
|
||||
@@ -176,7 +176,7 @@ following pod-specific DNS policies. These policies are specified in the
|
||||
See [DNS config](#dns-config) subsection below.
|
||||
|
||||
{{< note >}}
|
||||
**NOTE:** "Default" is not the default DNS policy. If `dnsPolicy` is not
|
||||
"Default" is not the default DNS policy. If `dnsPolicy` is not
|
||||
explicitly specified, then “ClusterFirst” is used.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -99,7 +99,7 @@ In order for the Ingress resource to work, the cluster must have an Ingress cont
|
||||
* [Istio](https://istio.io/) based ingress controller [Control Ingress Traffic](https://istio.io/docs/tasks/traffic-management/ingress/)
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Review the documentation for your controller to find its specific support policy.
|
||||
Review the documentation for your controller to find its specific support policy.
|
||||
{{< /note >}}
|
||||
|
||||
## Before you begin
|
||||
@@ -107,7 +107,7 @@ In order for the Ingress resource to work, the cluster must have an Ingress cont
|
||||
The following document describes a set of cross-platform features exposed through the Ingress resource. Ideally, all Ingress controllers should fulfill this specification, but we're not there yet. We currently support and maintain [GCE](https://git.k8s.io/ingress-gce/README.md) and [nginx](https://git.k8s.io/ingress-nginx/README.md) controllers. If you use the F5 BIG-IP Controller, see [Use the BIG-IP Controller as a Kubernetes Ingress Controller](http://clouddocs.f5.com/containers/latest/kubernetes/kctlr-k8s-ingress-ctlr.html).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Make sure you review your controller's specific docs so you understand the caveats.
|
||||
Make sure you review your controller's specific docs so you understand the caveats.
|
||||
{{< /note >}}
|
||||
|
||||
## Types of Ingress
|
||||
@@ -202,7 +202,7 @@ When it has done so, you will see the address of the loadbalancer at the
|
||||
Address field.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** You need to create a default-http-backend [Service](/docs/concepts/services-networking/service/) if necessary.
|
||||
You need to create a default-http-backend [Service](/docs/concepts/services-networking/service/) if necessary.
|
||||
{{< /note >}}
|
||||
|
||||
### Name based virtual hosting
|
||||
|
||||
@@ -87,7 +87,7 @@ Kubernetes `Services` support `TCP`, `UDP` and `SCTP` for protocols. The defaul
|
||||
is `TCP`.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** SCTP support is an alpha feature since Kubernetes 1.12
|
||||
SCTP support is an alpha feature since Kubernetes 1.12
|
||||
{{< /note >}}
|
||||
|
||||
### Services without selectors
|
||||
@@ -132,7 +132,7 @@ subsets:
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The endpoint IPs may not be loopback (127.0.0.0/8), link-local
|
||||
The endpoint IPs may not be loopback (127.0.0.0/8), link-local
|
||||
(169.254.0.0/16), or link-local multicast (224.0.0.0/24). They cannot be the
|
||||
cluster IPs of other Kubernetes services either because the `kube-proxy`
|
||||
component doesn't support virtual IPs as destination yet.
|
||||
@@ -212,10 +212,12 @@ options for load balancing algorithm, such as:
|
||||
- `sed`: shortest expected delay
|
||||
- `nq`: never queue
|
||||
|
||||
**Note:** ipvs mode assumes IPVS kernel modules are installed on the node
|
||||
{{< note >}}
|
||||
ipvs mode assumes IPVS kernel modules are installed on the node
|
||||
before running kube-proxy. When kube-proxy starts with ipvs proxy mode,
|
||||
kube-proxy would validate if IPVS modules are installed on the node, if
|
||||
it's not installed kube-proxy will fall back to iptables proxy mode.
|
||||
{{< /note >}}
|
||||
|
||||

|
||||
|
||||
@@ -459,7 +461,7 @@ public IP address resource needs to be created first, and it should be in the sa
|
||||
group of the other automatically created resources of the cluster. For example, `MC_myResourceGroup_myAKSCluster_eastus`. Specify the assigned IP address as loadBalancerIP. Ensure that you have updated the securityGroupName in the cloud provider configuration file. For information about troubleshooting `CreatingLoadBalancerFailed` permission issues see, [Use a static IP address with the Azure Kubernetes Service (AKS) load balancer](https://docs.microsoft.com/en-us/azure/aks/static-ip) or [CreatingLoadBalancerFailed on AKS cluster with advanced networking](https://github.com/Azure/AKS/issues/357).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The support of SCTP in the cloud provider's load balancer is up to the cloud provider's
|
||||
he support of SCTP in the cloud provider's load balancer is up to the cloud provider's
|
||||
load balancer implementation. If SCTP is not supported by the cloud provider's load balancer the
|
||||
Service creation request is accepted but the creation of the load balancer fails.
|
||||
{{< /note >}}
|
||||
@@ -693,7 +695,9 @@ There are other annotations to manage Classic Elastic Load Balancers that are de
|
||||
|
||||
#### Network Load Balancer support on AWS [alpha]
|
||||
|
||||
**Warning:** This is an alpha feature and not recommended for production clusters yet.
|
||||
{{< warning >}}
|
||||
This is an alpha feature and not recommended for production clusters yet.
|
||||
{{< /warning >}}
|
||||
|
||||
Starting in version 1.9.0, Kubernetes supports Network Load Balancer (NLB). To
|
||||
use a Network Load Balancer on AWS, use the annotation `service.beta.kubernetes.io/aws-load-balancer-type`
|
||||
@@ -747,13 +751,15 @@ spec:
|
||||
- "143.231.0.0/16"
|
||||
```
|
||||
|
||||
**Note:** NLB only works with certain instance classes, see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
|
||||
{{< note >}}
|
||||
NLB only works with certain instance classes, see the [AWS documentation](http://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#register-deregister-targets)
|
||||
for supported instance types.
|
||||
{{< /note >}}
|
||||
|
||||
### Type ExternalName {#externalname}
|
||||
|
||||
{{< note >}}
|
||||
**NOTE:** ExternalName Services are available only with `kube-dns` version 1.7 and later.
|
||||
ExternalName Services are available only with `kube-dns` version 1.7 and later.
|
||||
{{< /note >}}
|
||||
|
||||
Services of type ExternalName map a service to a DNS name (specified using
|
||||
|
||||
@@ -85,7 +85,7 @@ Once a user has a claim and that claim is bound, the bound PV belongs to the use
|
||||
The purpose of the Storage Object in Use Protection feature is to ensure that Persistent Volume Claims (PVCs) in active use by a pod and Persistent Volume (PVs) that are bound to PVCs are not removed from the system as this may result in data loss.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** PVC is in active use by a pod when the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`.
|
||||
PVC is in active use by a pod when the pod status is `Pending` and the pod is assigned to a node or the pod status is `Running`.
|
||||
{{< /note >}}
|
||||
|
||||
When the [Storage Object in Use Protection feature](/docs/tasks/administer-cluster/storage-object-in-use-protection/) is enabled, if a user deletes a PVC in active use by a pod, the PVC is not removed immediately. PVC removal is postponed until the PVC is no longer actively used by any pods, and also if admin deletes a PV that is bound to a PVC, the PV is not removed immediately. PV removal is postponed until the PV is not bound to a PVC any more.
|
||||
@@ -147,7 +147,7 @@ For volume plugins that support the `Delete` reclaim policy, deletion removes bo
|
||||
#### Recycle
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
|
||||
The `Recycle` reclaim policy is deprecated. Instead, the recommended approach is to use dynamic provisioning.
|
||||
{{< /warning >}}
|
||||
|
||||
If supported by the underlying volume plugin, the `Recycle` reclaim policy performs a basic scrub (`rm -rf /thevolume/*`) on the volume and makes it available again for a new claim.
|
||||
@@ -238,7 +238,7 @@ This feature has no effect on PVCs that are not in use by a Pod or deployment. Y
|
||||
uses the PVC before the expansion can complete.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Expanding EBS volumes is a time consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
|
||||
Expanding EBS volumes is a time consuming operation. Also, there is a per-volume quota of one modification every 6 hours.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -377,7 +377,7 @@ Currently, only NFS and HostPath support recycling. AWS EBS, GCE PD, Azure Disk,
|
||||
A Kubernetes administrator can specify additional mount options for when a Persistent Volume is mounted on a node.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Not all Persistent volume types support mount options.
|
||||
Not all Persistent volume types support mount options.
|
||||
{{< /note >}}
|
||||
|
||||
The following volume types support mount options:
|
||||
@@ -495,7 +495,7 @@ the requirements are ANDed together: only a PV of the requested class and with
|
||||
the requested labels may be bound to the PVC.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it.
|
||||
Currently, a PVC with a non-empty `selector` can't have a PV dynamically provisioned for it.
|
||||
{{< /note >}}
|
||||
|
||||
In the past, the annotation `volume.beta.kubernetes.io/storage-class` was used instead
|
||||
@@ -547,7 +547,7 @@ applicable.
|
||||
* RBD (Ceph Block Device)
|
||||
|
||||
{{< note >}}
|
||||
**Note**: Only FC and iSCSI volumes supported raw block volumes in Kubernetes 1.9.
|
||||
Only FC and iSCSI volumes supported raw block volumes in Kubernetes 1.9.
|
||||
Support for the additional plugins was added in 1.10.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -605,7 +605,7 @@ spec:
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
**Note:** When adding a raw block device for a Pod, we specify the device path in the container instead of a mount path.
|
||||
When adding a raw block device for a Pod, we specify the device path in the container instead of a mount path.
|
||||
{{< /note >}}
|
||||
|
||||
### Binding Block Volumes
|
||||
@@ -627,7 +627,7 @@ Volume binding matrix for statically provisioned volumes:
|
||||
| Filesystem | unspecified | BIND |
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Only statically provisioned volumes are supported for alpha release. Administrators should take care to consider these values when working with raw block devices.
|
||||
Only statically provisioned volumes are supported for alpha release. Administrators should take care to consider these values when working with raw block devices.
|
||||
{{< /note >}}
|
||||
|
||||
## Volume Snapshot and Restore Volume from Snapshot Support
|
||||
|
||||
@@ -123,8 +123,10 @@ the class or PV, so mount of the PV will simply fail if one is invalid.
|
||||
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
**Note:** This feature requires the `VolumeScheduling` feature gate to be
|
||||
{{< note >}}
|
||||
This feature requires the `VolumeScheduling` feature gate to be
|
||||
enabled.
|
||||
{{< /note >}}
|
||||
|
||||
The `volumeBindingMode` field controls when [volume binding and dynamic
|
||||
provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur.
|
||||
@@ -159,8 +161,10 @@ The following plugins support `WaitForFirstConsumer` with pre-created Persistent
|
||||
### Allowed Topologies
|
||||
{{< feature-state for_k8s_version="v1.12" state="beta" >}}
|
||||
|
||||
**Note:** This feature requires the `VolumeScheduling` feature gate to be
|
||||
{{< note >}}
|
||||
This feature requires the `VolumeScheduling` feature gate to be
|
||||
enabled.
|
||||
{{< /note >}}
|
||||
|
||||
When a cluster operactor specifies the `WaitForFirstConsumer` volume binding mode, it is no longer necessary
|
||||
to restrict provisioning to specific topologies in most situations. However,
|
||||
@@ -232,8 +236,10 @@ parameters:
|
||||
encrypting the volume. If none is supplied but `encrypted` is true, a key is
|
||||
generated by AWS. See AWS docs for valid ARN value.
|
||||
|
||||
**Note:** `zone` and `zones` parameters are deprecated and replaced with
|
||||
{{< note >}}
|
||||
`zone` and `zones` parameters are deprecated and replaced with
|
||||
[allowedTopologies](#allowed-topologies)
|
||||
{{< /note >}}
|
||||
|
||||
### GCE PD
|
||||
|
||||
@@ -269,8 +275,10 @@ specified, Kubernetes will arbitrarily choose among the specified zones. If the
|
||||
`zones` parameter is omitted, Kubernetes will arbitrarily choose among zones
|
||||
managed by the cluster.
|
||||
|
||||
**Note:** `zone` and `zones` parameters are deprecated and replaced with
|
||||
{{< note >}}
|
||||
`zone` and `zones` parameters are deprecated and replaced with
|
||||
[allowedTopologies](#allowed-topologies)
|
||||
{{< /note >}}
|
||||
|
||||
### Glusterfs
|
||||
|
||||
|
||||
@@ -105,7 +105,7 @@ EBS volume can be pre-populated with data, and that data can be "handed off"
|
||||
between Pods.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it.
|
||||
You must create an EBS volume using `aws ec2 create-volume` or the AWS API before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
There are some restrictions when using an `awsElasticBlockStore` volume:
|
||||
@@ -170,7 +170,7 @@ that data can be "handed off" between Pods. CephFS can be mounted by multiple
|
||||
writers simultaneously.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have your own Ceph server running with the share exported before you can use it.
|
||||
You must have your own Ceph server running with the share exported before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
See the [CephFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/cephfs/) for more details.
|
||||
@@ -215,11 +215,11 @@ Note that this path is derived from the volume's `mountPath` and the `path`
|
||||
keyed with `log_level`.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it.
|
||||
You must create a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
|
||||
A Container using a ConfigMap as a [subPath](#using-subpath) volume mount will not
|
||||
receive ConfigMap updates.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -229,7 +229,7 @@ A `downwardAPI` volume is used to make downward API data available to applicatio
|
||||
It mounts a directory and writes the requested data in plain text files.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Container using Downward API as a [subPath](#using-subpath) volume mount will not
|
||||
A Container using Downward API as a [subPath](#using-subpath) volume mount will not
|
||||
receive Downward API updates.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -245,7 +245,7 @@ or different paths in each Container. When a Pod is removed from a node for
|
||||
any reason, the data in the `emptyDir` is deleted forever.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
|
||||
A Container crashing does *NOT* remove a Pod from a node, so the data in an `emptyDir` volume is safe across Container crashes.
|
||||
{{< /note >}}
|
||||
|
||||
Some uses for an `emptyDir` are:
|
||||
@@ -290,7 +290,7 @@ You can specify single or multiple target World Wide Names using the parameter
|
||||
targetWWNs expect that those WWNs are from multi-path connections.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
|
||||
You must configure FC SAN Zoning to allocate and mask those LUNs (volumes) to the target WWNs beforehand so that Kubernetes hosts can access them.
|
||||
{{< /caution >}}
|
||||
|
||||
See the [FC example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) for more details.
|
||||
@@ -307,7 +307,7 @@ reattached by Flocker to the node that the Pod is scheduled. This means data
|
||||
can be "handed off" between Pods as required.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have your own Flocker installation running before you can use it.
|
||||
You must have your own Flocker installation running before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
See the [Flocker example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) for more details.
|
||||
@@ -321,7 +321,7 @@ preserved and the volume is merely unmounted. This means that a PD can be
|
||||
pre-populated with data, and that data can be "handed off" between Pods.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must create a PD using `gcloud` or the GCE API or UI before you can use it.
|
||||
You must create a PD using `gcloud` or the GCE API or UI before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
There are some restrictions when using a `gcePersistentDisk`:
|
||||
@@ -403,7 +403,7 @@ spec:
|
||||
### gitRepo (deprecated) {#gitrepo}
|
||||
|
||||
{{< warning >}}
|
||||
**Warning:** The gitRepo volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
|
||||
The gitRepo volume type is deprecated. To provision a container with a git repo, mount an [EmptyDir](#emptydir) into an InitContainer that clones the repo using git, then mount the [EmptyDir](#emptydir) into the Pod's container.
|
||||
{{< /warning >}}
|
||||
|
||||
A `gitRepo` volume is an example of what can be done as a volume plugin. It
|
||||
@@ -443,7 +443,7 @@ be "handed off" between Pods. GlusterFS can be mounted by multiple writers
|
||||
simultaneously.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have your own GlusterFS installation running before you can use it.
|
||||
You must have your own GlusterFS installation running before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
See the [GlusterFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/glusterfs) for more details.
|
||||
@@ -521,7 +521,7 @@ unmounted. This means that an iscsi volume can be pre-populated with data, and
|
||||
that data can be "handed off" between Pods.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have your own iSCSI server running with the volume created before you can use it.
|
||||
You must have your own iSCSI server running with the volume created before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
A feature of iSCSI is that it can be mounted as read-only by multiple consumers
|
||||
@@ -537,7 +537,7 @@ See the [iSCSI example](https://github.com/kubernetes/examples/tree/{{< param "g
|
||||
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The alpha PersistentVolume NodeAffinity annotation has been deprecated
|
||||
The alpha PersistentVolume NodeAffinity annotation has been deprecated
|
||||
and will be removed in a future release. Existing PersistentVolumes using this
|
||||
annotation must be updated by the user to use the new PersistentVolume
|
||||
`NodeAffinity` field.
|
||||
@@ -610,7 +610,7 @@ provisioning yet. For an example on how to run an external local provisioner,
|
||||
see the [local volume provisioner user guide](https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume).
|
||||
|
||||
{{< note >}}
|
||||
**Note:** The local PersistentVolume requires manual cleanup and deletion by the
|
||||
The local PersistentVolume requires manual cleanup and deletion by the
|
||||
user if the external static provisioner is not used to manage the volume
|
||||
lifecycle.
|
||||
{{< /note >}}
|
||||
@@ -625,7 +625,7 @@ that data can be "handed off" between Pods. NFS can be mounted by multiple
|
||||
writers simultaneously.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have your own NFS server running with the share exported before you can use it.
|
||||
You must have your own NFS server running with the share exported before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
See the [NFS example](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) for more details.
|
||||
@@ -782,7 +782,7 @@ option for the API server. The `path` field specifies a relative path to the mou
|
||||
of the projected volume.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Container using a projected volume source as a [subPath](#using-subpath) volume mount will not
|
||||
A Container using a projected volume source as a [subPath](#using-subpath) volume mount will not
|
||||
receive updates for those volume sources.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -818,7 +818,7 @@ spec:
|
||||
```
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** Make sure you have an existing PortworxVolume with name `pxvol`
|
||||
Make sure you have an existing PortworxVolume with name `pxvol`
|
||||
before using it in the Pod.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -830,7 +830,7 @@ A `quobyte` volume allows an existing [Quobyte](http://www.quobyte.com) volume t
|
||||
be mounted into your Pod.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have your own Quobyte setup running with the volumes
|
||||
You must have your own Quobyte setup running with the volumes
|
||||
created before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -846,7 +846,7 @@ means that a RBD volume can be pre-populated with data, and that data can
|
||||
be "handed off" between Pods.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have your own Ceph installation running before you can use RBD.
|
||||
You must have your own Ceph installation running before you can use RBD.
|
||||
{{< /caution >}}
|
||||
|
||||
A feature of RBD is that it can be mounted as read-only by multiple consumers
|
||||
@@ -866,7 +866,7 @@ volumes (or it can dynamically provision new volumes for persistent volume claim
|
||||
[ScaleIO Persistent Volumes](/docs/concepts/storage/persistent-volumes/#scaleio)).
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must have an existing ScaleIO cluster already setup and
|
||||
You must have an existing ScaleIO cluster already setup and
|
||||
running with the volumes created before you can use them.
|
||||
{{< /caution >}}
|
||||
|
||||
@@ -908,11 +908,11 @@ backed by tmpfs (a RAM-backed filesystem) so they are never written to
|
||||
non-volatile storage.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must create a secret in the Kubernetes API before you can use it.
|
||||
You must create a secret in the Kubernetes API before you can use it.
|
||||
{{< /caution >}}
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Container using a Secret as a [subPath](#using-subpath) volume mount will not
|
||||
A Container using a Secret as a [subPath](#using-subpath) volume mount will not
|
||||
receive Secret updates.
|
||||
{{< /note >}}
|
||||
|
||||
@@ -934,7 +934,7 @@ The StorageOS Container requires 64-bit Linux and has no additional dependencies
|
||||
A free developer license is available.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must run the StorageOS Container on each node that wants to
|
||||
You must run the StorageOS Container on each node that wants to
|
||||
access StorageOS volumes or that will contribute storage capacity to the pool.
|
||||
For installation instructions, consult the
|
||||
[StorageOS documentation](https://docs.storageos.com).
|
||||
@@ -974,7 +974,7 @@ For more information including Dynamic Provisioning and Persistent Volume Claims
|
||||
### vsphereVolume {#vspherevolume}
|
||||
|
||||
{{< note >}}
|
||||
**Prerequisite:** Kubernetes with vSphere Cloud Provider configured. For cloudprovider
|
||||
Prerequisite: Kubernetes with vSphere Cloud Provider configured. For cloudprovider
|
||||
configuration please refer [vSphere getting started guide](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/).
|
||||
{{< /note >}}
|
||||
|
||||
@@ -982,7 +982,7 @@ A `vsphereVolume` is used to mount a vSphere VMDK Volume into your Pod. The con
|
||||
of a volume are preserved when it is unmounted. It supports both VMFS and VSAN datastore.
|
||||
|
||||
{{< caution >}}
|
||||
**Important:** You must create VMDK using one of the following method before using with Pod.
|
||||
You must create VMDK using one of the following method before using with Pod.
|
||||
{{< /caution >}}
|
||||
|
||||
#### Creating a VMDK volume
|
||||
@@ -1274,7 +1274,7 @@ Its values are:
|
||||
[Linux kernel documentation](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt)
|
||||
|
||||
{{< caution >}}
|
||||
**Caution:** `Bidirectional` mount propagation can be dangerous. It can damage
|
||||
`Bidirectional` mount propagation can be dangerous. It can damage
|
||||
the host operating system and therefore it is allowed only in privileged
|
||||
Containers. Familiarity with Linux kernel behavior is strongly recommended.
|
||||
In addition, any volume mounts created by Containers in Pods must be destroyed
|
||||
|
||||
@@ -14,8 +14,9 @@ A _Cron Job_ creates [Jobs](/docs/concepts/workloads/controllers/jobs-run-to-com
|
||||
|
||||
One CronJob object is like one line of a _crontab_ (cron table) file. It runs a job periodically
|
||||
on a given schedule, written in [Cron](https://en.wikipedia.org/wiki/Cron) format.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** All **CronJob** `schedule:` times are denoted in UTC.
|
||||
All **CronJob** `schedule:` times are denoted in UTC.
|
||||
{{< /note >}}
|
||||
|
||||
For instructions on creating and working with cron jobs, and for an example of a spec file for a cron job, see [Running automated tasks with cron jobs](/docs/tasks/job/automated-tasks-with-cron-jobs).
|
||||
|
||||
@@ -206,7 +206,7 @@ back-off count is reset if no new failed Pods appear before the Job's next
|
||||
status check.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
|
||||
Issue [#54870](https://github.com/kubernetes/kubernetes/issues/54870) still exists for versions of Kubernetes prior to version 1.12
|
||||
{{< /note >}}
|
||||
|
||||
## Job Termination and Cleanup
|
||||
|
||||
@@ -16,7 +16,7 @@ weight: 20
|
||||
{{% capture overview %}}
|
||||
|
||||
{{< note >}}
|
||||
**NOTE:** A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
|
||||
A [`Deployment`](/docs/concepts/workloads/controllers/deployment/) that configures a [`ReplicaSet`](/docs/concepts/workloads/controllers/replicaset/) is now the recommended way to set up replication.
|
||||
{{< /note >}}
|
||||
|
||||
A _ReplicationController_ ensures that a specified number of pod replicas are running at any one
|
||||
|
||||
@@ -16,7 +16,7 @@ weight: 40
|
||||
StatefulSet is the workload API object used to manage stateful applications.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** StatefulSets are stable (GA) in 1.9.
|
||||
StatefulSets are stable (GA) in 1.9.
|
||||
{{< /note >}}
|
||||
|
||||
{{< glossary_definition term_id="statefulset" length="all" >}}
|
||||
@@ -144,7 +144,7 @@ Cluster Domain | Service (ns/name) | StatefulSet (ns/name) | StatefulSet Domain
|
||||
kube.local | foo/nginx | foo/web | nginx.foo.svc.kube.local | web-{0..N-1}.nginx.foo.svc.kube.local | web-{0..N-1} |
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Cluster Domain will be set to `cluster.local` unless
|
||||
Cluster Domain will be set to `cluster.local` unless
|
||||
[otherwise configured](/docs/concepts/services-networking/dns-pod-service/#how-it-works).
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
@@ -55,7 +55,7 @@ A Pod can specify a set of shared storage *volumes*. All containers in the Pod c
|
||||
You'll rarely create individual Pods directly in Kubernetes--even singleton Pods. This is because Pods are designed as relatively ephemeral, disposable entities. When a Pod gets created (directly by you, or indirectly by a Controller), it is scheduled to run on a Node in your cluster. The Pod remains on that Node until the process is terminated, the pod object is deleted, the pod is *evicted* for lack of resources, or the Node fails.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
|
||||
Restarting a container in a Pod should not be confused with restarting the Pod. The Pod itself does not run, but is an environment the containers run in and persists until it is deleted.
|
||||
{{< /note >}}
|
||||
|
||||
Pods do not, by themselves, self-heal. If a Pod is scheduled to a Node that fails, or if the scheduling operation itself fails, the Pod is deleted; likewise, a Pod won't survive an eviction due to a lack of resources or Node maintenance. Kubernetes uses a higher-level abstraction, called a *Controller*, that handles the work of managing the relatively disposable Pod instances. Thus, while it is possible to use Pod directly, it's far more common in Kubernetes to manage your pods using a Controller. See [Pods and Controllers](#pods-and-controllers) for more information on how Kubernetes uses Controllers to implement Pod scaling and healing.
|
||||
|
||||
@@ -51,7 +51,7 @@ Pods, Kubernetes modifies the Pod Spec. For changes to `Env`, `EnvFrom`, and
|
||||
the Pod; for changes to `Volume`, Kubernetes modifies the Pod Spec.
|
||||
|
||||
{{< note >}}
|
||||
**Note:** A Pod Preset is capable of modifying the `.spec.containers` field in a
|
||||
A Pod Preset is capable of modifying the `.spec.containers` field in a
|
||||
Pod spec when appropriate. *No* resource definition from the Pod Preset will be
|
||||
applied to the `initContainers` field.
|
||||
{{< /note >}}
|
||||
|
||||
Reference in New Issue
Block a user