Merge master into dev-1.22 to keep in sync
This commit is contained in:
Victor Palade
@@ -210,7 +210,7 @@ To upgrade a HA control plane to use the cloud controller manager, see [Migrate
|
||||
|
||||
Want to know how to implement your own cloud controller manager, or extend an existing project?
|
||||
|
||||
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.17/cloud.go#L42-L62) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
|
||||
The cloud controller manager uses Go interfaces to allow implementations from any cloud to be plugged in. Specifically, it uses the `CloudProvider` interface defined in [`cloud.go`](https://github.com/kubernetes/cloud-provider/blob/release-1.21/cloud.go#L42-L69) from [kubernetes/cloud-provider](https://github.com/kubernetes/cloud-provider).
|
||||
|
||||
The implementation of the shared controllers highlighted in this document (Node, Route, and Service), and some scaffolding along with the shared cloudprovider interface, is part of the Kubernetes core. Implementations specific to cloud providers are outside the core of Kubernetes and implement the `CloudProvider` interface.
|
||||
|
||||
|
||||
@@ -0,0 +1,164 @@
|
||||
---
|
||||
title: Garbage Collection
|
||||
content_type: concept
|
||||
weight: 50
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
{{<glossary_definition term_id="garbage-collection" length="short">}} This
|
||||
allows the clean up of resources like the following:
|
||||
|
||||
* [Failed pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
* [Completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
* [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)
|
||||
* {{<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
|
||||
manager
|
||||
* [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats)
|
||||
|
||||
## Owners and dependents {#owners-dependents}
|
||||
|
||||
Many objects in Kubernetes link to each other through [*owner references*](/docs/concepts/overview/working-with-objects/owners-dependents/).
|
||||
Owner references tell the control plane which objects are dependent on others.
|
||||
Kubernetes uses owner references to give the control plane, and other API
|
||||
clients, the opportunity to clean up related resources before deleting an
|
||||
object. In most cases, Kubernetes manages owner references automatically.
|
||||
|
||||
Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
|
||||
mechanism that some resources also use. For example, consider a
|
||||
{{<glossary_tooltip text="Service" term_id="service">}} that creates
|
||||
`EndpointSlice` objects. The Service uses *labels* to allow the control plane to
|
||||
determine which `EndpointSlice` objects are used for that Service. In addition
|
||||
to the labels, each `EndpointSlice` that is managed on behalf of a Service has
|
||||
an owner reference. Owner references help different parts of Kubernetes avoid
|
||||
interfering with objects they don’t control.
|
||||
|
||||
## Cascading deletion {#cascading-deletion}
|
||||
|
||||
Kubernetes checks for and deletes objects that no longer have owner
|
||||
references, like the pods left behind when you delete a ReplicaSet. When you
|
||||
delete an object, you can control whether Kubernetes deletes the object's
|
||||
dependents automatically, in a process called *cascading deletion*. There are
|
||||
two types of cascading deletion, as follows:
|
||||
|
||||
* Foreground cascading deletion
|
||||
* Background cascading deletion
|
||||
|
||||
You can also control how and when garbage collection deletes resources that have
|
||||
owner references using Kubernetes {{<glossary_tooltip text="finalizers" term_id="finalizer">}}.
|
||||
|
||||
### Foreground cascading deletion {#foreground-deletion}
|
||||
|
||||
In foreground cascading deletion, the owner object you're deleting first enters
|
||||
a *deletion in progress* state. In this state, the following happens to the
|
||||
owner object:
|
||||
|
||||
* The Kubernetes API server sets the object's `metadata.deletionTimestamp`
|
||||
field to the time the object was marked for deletion.
|
||||
* The Kubernetes API server also sets the `metadata.finalizers` field to
|
||||
`foregroundDeletion`.
|
||||
* The object remains visible through the Kubernetes API until the deletion
|
||||
process is complete.
|
||||
|
||||
After the owner object enters the deletion in progress state, the controller
|
||||
deletes the dependents. After deleting all the dependent objects, the controller
|
||||
deletes the owner object. At this point, the object is no longer visible in the
|
||||
Kubernetes API.
|
||||
|
||||
During foreground cascading deletion, the only dependents that block owner
|
||||
deletion are those that have the `ownerReference.blockOwnerDeletion=true` field.
|
||||
See [Use foreground cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion)
|
||||
to learn more.
|
||||
|
||||
### Background cascading deletion {#background-deletion}
|
||||
|
||||
In background cascading deletion, the Kubernetes API server deletes the owner
|
||||
object immediately and the controller cleans up the dependent objects in
|
||||
the background. By default, Kubernetes uses background cascading deletion unless
|
||||
you manually use foreground deletion or choose to orphan the dependent objects.
|
||||
|
||||
See [Use background cascading deletion](/docs/tasks/administer-cluster/use-cascading-deletion/#use-background-cascading-deletion)
|
||||
to learn more.
|
||||
|
||||
### Orphaned dependents
|
||||
|
||||
When Kubernetes deletes an owner object, the dependents left behind are called
|
||||
*orphan* objects. By default, Kubernetes deletes dependent objects. To learn how
|
||||
to override this behaviour, see [Delete owner objects and orphan dependents](/docs/tasks/administer-cluster/use-cascading-deletion/#set-orphan-deletion-policy).
|
||||
|
||||
## Garbage collection of unused containers and images {#containers-images}
|
||||
|
||||
The {{<glossary_tooltip text="kubelet" term_id="kubelet">}} performs garbage
|
||||
collection on unused images every five minutes and on unused containers every
|
||||
minute. You should avoid using external garbage collection tools, as these can
|
||||
break the kubelet behavior and remove containers that should exist.
|
||||
|
||||
To configure options for unused container and image garbage collection, tune the
|
||||
kubelet using a [configuration file](/docs/tasks/administer-cluster/kubelet-config-file/)
|
||||
and change the parameters related to garbage collection using the
|
||||
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)
|
||||
resource type.
|
||||
|
||||
### Container image lifecycle
|
||||
|
||||
Kubernetes manages the lifecycle of all images through its *image manager*,
|
||||
which is part of the kubelet, with the cooperation of cadvisor. The kubelet
|
||||
considers the following disk usage limits when making garbage collection
|
||||
decisions:
|
||||
|
||||
* `HighThresholdPercent`
|
||||
* `LowThresholdPercent`
|
||||
|
||||
Disk usage above the configured `HighThresholdPercent` value triggers garbage
|
||||
collection, which deletes images in order based on the last time they were used,
|
||||
starting with the oldest first. The kubelet deletes images
|
||||
until disk usage reaches the `LowThresholdPercent` value.
|
||||
|
||||
### Container image garbage collection {#container-image-garbage-collection}
|
||||
|
||||
The kubelet garbage collects unused containers based on the following variables,
|
||||
which you can define:
|
||||
|
||||
* `MinAge`: the minimum age at which the kubelet can garbage collect a
|
||||
container. Disable by setting to `0`.
|
||||
* `MaxPerPodContainer`: the maximum number of dead containers each Pod pair
|
||||
can have. Disable by setting to less than `0`.
|
||||
* `MaxContainers`: the maximum number of dead containers the cluster can have.
|
||||
Disable by setting to less than `0`.
|
||||
|
||||
In addition to these variables, the kubelet garbage collects unidentified and
|
||||
deleted containers, typically starting with the oldest first.
|
||||
|
||||
`MaxPerPodContainer` and `MaxContainer` may potentially conflict with each other
|
||||
in situations where retaining the maximum number of containers per Pod
|
||||
(`MaxPerPodContainer`) would go outside the allowable total of global dead
|
||||
containers (`MaxContainers`). In this situation, the kubelet adjusts
|
||||
`MaxPodPerContainer` to address the conflict. A worst-case scenario would be to
|
||||
downgrade `MaxPerPodContainer` to `1` and evict the oldest containers.
|
||||
Additionally, containers owned by pods that have been deleted are removed once
|
||||
they are older than `MinAge`.
|
||||
|
||||
{{<note>}}
|
||||
The kubelet only garbage collects the containers it manages.
|
||||
{{</note>}}
|
||||
|
||||
## Configuring garbage collection {#configuring-gc}
|
||||
|
||||
You can tune garbage collection of resources by configuring options specific to
|
||||
the controllers managing those resources. The following pages show you how to
|
||||
configure garbage collection:
|
||||
|
||||
* [Configuring cascading deletion of Kubernetes objects](/docs/tasks/administer-cluster/use-cascading-deletion/)
|
||||
* [Configuring cleanup of finished Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/)
|
||||
|
||||
<!-- * [Configuring unused container and image garbage collection](/docs/tasks/administer-cluster/reconfigure-kubelet/) -->
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [ownership of Kubernetes objects](/docs/concepts/overview/working-with-objects/owners-dependents/).
|
||||
* Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
|
||||
* Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs.
|
||||
@@ -14,7 +14,7 @@ A node may be a virtual or physical machine, depending on the cluster. Each node
|
||||
is managed by the
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}}
|
||||
and contains the services necessary to run
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}
|
||||
{{< glossary_tooltip text="Pods" term_id="pod" >}}.
|
||||
|
||||
Typically you have several nodes in a cluster; in a learning or resource-limited
|
||||
environment, you might have only one node.
|
||||
|
||||
@@ -1,98 +0,0 @@
|
||||
---
|
||||
title: Garbage collection for container images
|
||||
content_type: concept
|
||||
weight: 70
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
Garbage collection is a helpful function of kubelet that will clean up unused
|
||||
[images](/docs/concepts/containers/#container-images) and unused
|
||||
[containers](/docs/concepts/containers/). Kubelet will perform garbage collection
|
||||
for containers every minute and garbage collection for images every five minutes.
|
||||
|
||||
External garbage collection tools are not recommended as these tools can potentially
|
||||
break the behavior of kubelet by removing containers expected to exist.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Image Collection
|
||||
|
||||
Kubernetes manages lifecycle of all images through imageManager, with the cooperation
|
||||
of cadvisor.
|
||||
|
||||
The policy for garbage collecting images takes two factors into consideration:
|
||||
`HighThresholdPercent` and `LowThresholdPercent`. Disk usage above the high threshold
|
||||
will trigger garbage collection. The garbage collection will delete least recently used images until the low
|
||||
threshold has been met.
|
||||
|
||||
## Container Collection
|
||||
|
||||
The policy for garbage collecting containers considers three user-defined variables.
|
||||
`MinAge` is the minimum age at which a container can be garbage collected.
|
||||
`MaxPerPodContainer` is the maximum number of dead containers every single
|
||||
pod (UID, container name) pair is allowed to have.
|
||||
`MaxContainers` is the maximum number of total dead containers.
|
||||
These variables can be individually disabled by setting `MinAge` to zero and
|
||||
setting `MaxPerPodContainer` and `MaxContainers` respectively to less than zero.
|
||||
|
||||
Kubelet will act on containers that are unidentified, deleted, or outside of
|
||||
the boundaries set by the previously mentioned flags. The oldest containers
|
||||
will generally be removed first. `MaxPerPodContainer` and `MaxContainer` may
|
||||
potentially conflict with each other in situations where retaining the maximum
|
||||
number of containers per pod (`MaxPerPodContainer`) would go outside the
|
||||
allowable range of global dead containers (`MaxContainers`).
|
||||
`MaxPerPodContainer` would be adjusted in this situation: A worst case
|
||||
scenario would be to downgrade `MaxPerPodContainer` to 1 and evict the oldest
|
||||
containers. Additionally, containers owned by pods that have been deleted are
|
||||
removed once they are older than `MinAge`.
|
||||
|
||||
Containers that are not managed by kubelet are not subject to container garbage collection.
|
||||
|
||||
## User Configuration
|
||||
|
||||
You can adjust the following thresholds to tune image garbage collection with the following kubelet flags :
|
||||
|
||||
1. `image-gc-high-threshold`, the percent of disk usage which triggers image garbage collection.
|
||||
Default is 85%.
|
||||
2. `image-gc-low-threshold`, the percent of disk usage to which image garbage collection attempts
|
||||
to free. Default is 80%.
|
||||
|
||||
You can customize the garbage collection policy through the following kubelet flags:
|
||||
|
||||
1. `minimum-container-ttl-duration`, minimum age for a finished container before it is
|
||||
garbage collected. Default is 0 minute, which means every finished container will be garbage collected.
|
||||
2. `maximum-dead-containers-per-container`, maximum number of old instances to be retained
|
||||
per container. Default is 1.
|
||||
3. `maximum-dead-containers`, maximum number of old instances of containers to retain globally.
|
||||
Default is -1, which means there is no global limit.
|
||||
|
||||
Containers can potentially be garbage collected before their usefulness has expired. These containers
|
||||
can contain logs and other data that can be useful for troubleshooting. A sufficiently large value for
|
||||
`maximum-dead-containers-per-container` is highly recommended to allow at least 1 dead container to be
|
||||
retained per expected container. A larger value for `maximum-dead-containers` is also recommended for a
|
||||
similar reason.
|
||||
See [this issue](https://github.com/kubernetes/kubernetes/issues/13287) for more details.
|
||||
|
||||
|
||||
## Deprecation
|
||||
|
||||
Some kubelet Garbage Collection features in this doc will be replaced by kubelet eviction in the future.
|
||||
|
||||
Including:
|
||||
|
||||
| Existing Flag | New Flag | Rationale |
|
||||
| ------------- | -------- | --------- |
|
||||
| `--image-gc-high-threshold` | `--eviction-hard` or `--eviction-soft` | existing eviction signals can trigger image garbage collection |
|
||||
| `--image-gc-low-threshold` | `--eviction-minimum-reclaim` | eviction reclaims achieve the same behavior |
|
||||
| `--maximum-dead-containers` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--maximum-dead-containers-per-container` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--minimum-container-ttl-duration` | | deprecated once old logs are stored outside of container's context |
|
||||
| `--low-diskspace-threshold-mb` | `--eviction-hard` or `eviction-soft` | eviction generalizes disk thresholds to other resources |
|
||||
| `--outofdisk-transition-frequency` | `--eviction-pressure-transition-period` | eviction generalizes disk pressure transition to other resources |
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
See [Configuring Out Of Resource Handling](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
|
||||
for more details.
|
||||
|
||||
@@ -407,9 +407,9 @@ stringData:
|
||||
|
||||
There are several options to create a Secret:
|
||||
|
||||
- [create Secret using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [create Secret from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [create Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- [create Secrets using `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- [create Secrets from config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- [create Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
## Editing a Secret
|
||||
|
||||
@@ -1239,7 +1239,7 @@ for secret data, so that the secrets are not stored in the clear into {{< glossa
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Learn how to [manage Secret using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- Learn how to [manage Secrets using `kubectl`](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
|
||||
@@ -330,4 +330,5 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md)
|
||||
* Read the [OCI Image Manifest Specification](https://github.com/opencontainers/image-spec/blob/master/manifest.md).
|
||||
* Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection).
|
||||
|
||||
@@ -118,7 +118,7 @@ Runtime handlers are configured through containerd's configuration at
|
||||
`/etc/containerd/config.toml`. Valid handlers are configured under the runtimes section:
|
||||
|
||||
```
|
||||
[plugins.cri.containerd.runtimes.${HANDLER_NAME}]
|
||||
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.${HANDLER_NAME}]
|
||||
```
|
||||
|
||||
See containerd's config documentation for more details:
|
||||
|
||||
@@ -45,7 +45,7 @@ Containers have become popular because they provide extra benefits, such as:
|
||||
* Agile application creation and deployment: increased ease and efficiency of container image creation compared to VM image use.
|
||||
* Continuous development, integration, and deployment: provides for reliable and frequent container image build and deployment with quick and efficient rollbacks (due to image immutability).
|
||||
* Dev and Ops separation of concerns: create application container images at build/release time rather than deployment time, thereby decoupling applications from infrastructure.
|
||||
* Observability not only surfaces OS-level information and metrics, but also application health and other signals.
|
||||
* Observability: not only surfaces OS-level information and metrics, but also application health and other signals.
|
||||
* Environmental consistency across development, testing, and production: Runs the same on a laptop as it does in the cloud.
|
||||
* Cloud and OS distribution portability: Runs on Ubuntu, RHEL, CoreOS, on-premises, on major public clouds, and anywhere else.
|
||||
* Application-centric management: Raises the level of abstraction from running an OS on virtual hardware to running an application on an OS using logical resources.
|
||||
|
||||
@@ -0,0 +1,80 @@
|
||||
---
|
||||
title: Finalizers
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{<glossary_definition term_id="finalizer" length="long">}}
|
||||
|
||||
You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
|
||||
of resources by alerting {{<glossary_tooltip text="controllers" term_id="controller">}} to perform specific cleanup tasks before
|
||||
deleting the target resource.
|
||||
|
||||
Finalizers don't usually specify the code to execute. Instead, they are
|
||||
typically lists of keys on a specific resource similar to annotations.
|
||||
Kubernetes specifies some finalizers automatically, but you can also specify
|
||||
your own.
|
||||
|
||||
## How finalizers work
|
||||
|
||||
When you create a resource using a manifest file, you can specify finalizers in
|
||||
the `metadata.finalizers` field. When you attempt to delete the resource, the
|
||||
controller that manages it notices the values in the `finalizers` field and does
|
||||
the following:
|
||||
|
||||
* Modifies the object to add a `metadata.deletionTimestamp` field with the
|
||||
time you started the deletion.
|
||||
* Marks the object as read-only until its `metadata.finalizers` field is empty.
|
||||
|
||||
The controller then attempts to satisfy the requirements of the finalizers
|
||||
specified for that resource. Each time a finalizer condition is satisfied, the
|
||||
controller removes that key from the resource's `finalizers` field. When the
|
||||
field is empty, garbage collection continues. You can also use finalizers to
|
||||
prevent deletion of unmanaged resources.
|
||||
|
||||
A common example of a finalizer is `kubernetes.io/pv-protection`, which prevents
|
||||
accidental deletion of `PersistentVolume` objects. When a `PersistentVolume`
|
||||
object is in use by a Pod, Kubernetes adds the `pv-protection` finalizer. If you
|
||||
try to delete the `PersistentVolume`, it enters a `Terminating` status, but the
|
||||
controller can't delete it because the finalizer exists. When the Pod stops
|
||||
using the `PersistentVolume`, Kubernetes clears the `pv-protection` finalizer,
|
||||
and the controller deletes the volume.
|
||||
|
||||
## Owner references, labels, and finalizers {#owners-labels-finalizers}
|
||||
|
||||
Like {{<glossary_tooltip text="labels" term_id="label">}}, [owner references](/concepts/overview/working-with-objects/owners-dependents/)
|
||||
describe the relationships between objects in Kubernetes, but are used for a
|
||||
different purpose. When a
|
||||
{{<glossary_tooltip text="controllers" term_id="controller">}} manages objects
|
||||
like Pods, it uses labels to track changes to groups of related objects. For
|
||||
example, when a {{<glossary_tooltip text="Job" term_id="job">}} creates one or
|
||||
more Pods, the Job controller applies labels to those pods and tracks changes to
|
||||
any Pods in the cluster with the same label.
|
||||
|
||||
The Job controller also adds *owner references* to those Pods, pointing at the
|
||||
Job that created the Pods. If you delete the Job while these Pods are running,
|
||||
Kubernetes uses the owner references (not labels) to determine which Pods in the
|
||||
cluster need cleanup.
|
||||
|
||||
Kubernetes also processes finalizers when it identifies owner references on a
|
||||
resource targeted for deletion.
|
||||
|
||||
In some situations, finalizers can block the deletion of dependent objects,
|
||||
which can cause the targeted owner object to remain in a read-only state for
|
||||
longer than expected without being fully deleted. In these situations, you
|
||||
should check finalizers and owner references on the target owner and dependent
|
||||
objects to troubleshoot the cause.
|
||||
|
||||
{{<note>}}
|
||||
In cases where objects are stuck in a deleting state, try to avoid manually
|
||||
removing finalizers to allow deletion to continue. Finalizers are usually added
|
||||
to resources for a reason, so forcefully removing them can lead to issues in
|
||||
your cluster.
|
||||
{{</note>}}
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read [Using Finalizers to Control Deletion](/blog/2021/05/14/using-finalizers-to-control-deletion/)
|
||||
on the Kubernetes blog.
|
||||
@@ -42,7 +42,7 @@ Example labels:
|
||||
* `"partition" : "customerA"`, `"partition" : "customerB"`
|
||||
* `"track" : "daily"`, `"track" : "weekly"`
|
||||
|
||||
These are examples of commonly used labels; you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
|
||||
These are examples of [commonly used labels](/docs/concepts/overview/working-with-objects/common-labels/); you are free to develop your own conventions. Keep in mind that label Key must be unique for a given object.
|
||||
|
||||
## Syntax and character set
|
||||
|
||||
@@ -50,7 +50,7 @@ _Labels_ are key/value pairs. Valid label keys have two segments: an optional pr
|
||||
|
||||
If the prefix is omitted, the label Key is presumed to be private to the user. Automated system components (e.g. `kube-scheduler`, `kube-controller-manager`, `kube-apiserver`, `kubectl`, or other third-party automation) which add labels to end-user objects must specify a prefix.
|
||||
|
||||
The `kubernetes.io/` and `k8s.io/` prefixes are reserved for Kubernetes core components.
|
||||
The `kubernetes.io/` and `k8s.io/` prefixes are [reserved](/docs/reference/labels-annotations-taints/) for Kubernetes core components.
|
||||
|
||||
Valid label value:
|
||||
* must be 63 characters or less (can be empty),
|
||||
|
||||
@@ -28,7 +28,7 @@ For non-unique user-provided attributes, Kubernetes provides [labels](/docs/conc
|
||||
In cases when objects represent a physical entity, like a Node representing a physical host, when the host is re-created under the same name without deleting and re-creating the Node, Kubernetes treats the new host as the old one, which may lead to inconsistencies.
|
||||
{{< /note >}}
|
||||
|
||||
Below are three types of commonly used name constraints for resources.
|
||||
Below are four types of commonly used name constraints for resources.
|
||||
|
||||
### DNS Subdomain Names
|
||||
|
||||
@@ -41,7 +41,7 @@ This means the name must:
|
||||
- start with an alphanumeric character
|
||||
- end with an alphanumeric character
|
||||
|
||||
### DNS Label Names
|
||||
### RFC 1123 Label Names {#dns-label-names}
|
||||
|
||||
Some resource types require their names to follow the DNS
|
||||
label standard as defined in [RFC 1123](https://tools.ietf.org/html/rfc1123).
|
||||
@@ -52,6 +52,17 @@ This means the name must:
|
||||
- start with an alphanumeric character
|
||||
- end with an alphanumeric character
|
||||
|
||||
### RFC 1035 Label Names
|
||||
|
||||
Some resource types require their names to follow the DNS
|
||||
label standard as defined in [RFC 1035](https://tools.ietf.org/html/rfc1035).
|
||||
This means the name must:
|
||||
|
||||
- contain at most 63 characters
|
||||
- contain only lowercase alphanumeric characters or '-'
|
||||
- start with an alphabetic character
|
||||
- end with an alphanumeric character
|
||||
|
||||
### Path Segment Names
|
||||
|
||||
Some resource types require their names to be able to be safely encoded as a
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
---
|
||||
title: Owners and Dependents
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
In Kubernetes, some objects are *owners* of other objects. For example, a
|
||||
{{<glossary_tooltip text="ReplicaSet" term_id="replica-set">}} is the owner of a set of Pods. These owned objects are *dependents*
|
||||
of their owner.
|
||||
|
||||
Ownership is different from the [labels and selectors](/docs/concepts/overview/working-with-objects/labels/)
|
||||
mechanism that some resources also use. For example, consider a Service that
|
||||
creates `EndpointSlice` objects. The Service uses labels to allow the control plane to
|
||||
determine which `EndpointSlice` objects are used for that Service. In addition
|
||||
to the labels, each `EndpointSlice` that is managed on behalf of a Service has
|
||||
an owner reference. Owner references help different parts of Kubernetes avoid
|
||||
interfering with objects they don’t control.
|
||||
|
||||
## Owner references in object specifications
|
||||
|
||||
Dependent objects have a `metadata.ownerReferences` field that references their
|
||||
owner object. A valid owner reference consists of the object name and a UID
|
||||
within the same namespace as the dependent object. Kubernetes sets the value of
|
||||
this field automatically for objects that are dependents of other objects like
|
||||
ReplicaSets, DaemonSets, Deployments, Jobs and CronJobs, and ReplicationControllers.
|
||||
You can also configure these relationships manually by changing the value of
|
||||
this field. However, you usually don't need to and can allow Kubernetes to
|
||||
automatically manage the relationships.
|
||||
|
||||
Dependent objects also have an `ownerReferences.blockOwnerDeletion` field that
|
||||
takes a boolean value and controls whether specific dependents can block garbage
|
||||
collection from deleting their owner object. Kubernetes automatically sets this
|
||||
field to `true` if a {{<glossary_tooltip text="controller" term_id="controller">}}
|
||||
(for example, the Deployment controller) sets the value of the
|
||||
`metadata.ownerReferences` field. You can also set the value of the
|
||||
`blockOwnerDeletion` field manually to control which dependents block garbage
|
||||
collection.
|
||||
|
||||
A Kubernetes admission controller controls user access to change this field for
|
||||
dependent resources, based on the delete permissions of the owner. This control
|
||||
prevents unauthorized users from delaying owner object deletion.
|
||||
|
||||
## Ownership and finalizers
|
||||
|
||||
When you tell Kubernetes to delete a resource, the API server allows the
|
||||
managing controller to process any [finalizer rules](/docs/concepts/overview/working-with-objects/finalizers/)
|
||||
for the resource. {{<glossary_tooltip text="Finalizers" term_id="finalizer">}}
|
||||
prevent accidental deletion of resources your cluster may still need to function
|
||||
correctly. For example, if you try to delete a `PersistentVolume` that is still
|
||||
in use by a Pod, the deletion does not happen immediately because the
|
||||
`PersistentVolume` has the `kubernetes.io/pv-protection` finalizer on it.
|
||||
Instead, the volume remains in the `Terminating` status until Kubernetes clears
|
||||
the finalizer, which only happens after the `PersistentVolume` is no longer
|
||||
bound to a Pod.
|
||||
|
||||
Kubernetes also adds finalizers to an owner resource when you use either
|
||||
[foreground or orphan cascading deletion](/docs/concepts/architecture/garbage-collection/#cascading-deletion).
|
||||
In foreground deletion, it adds the `foreground` finalizer so that the
|
||||
controller must delete dependent resources that also have
|
||||
`ownerReferences.blockOwnerDeletion=true` before it deletes the owner. If you
|
||||
specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so
|
||||
that the controller ignores dependent resources after it deletes the owner
|
||||
object.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn more about [Kubernetes finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
|
||||
* Learn about [garbage collection](/docs/concepts/architecture/garbage-collection).
|
||||
* Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System).
|
||||
@@ -353,7 +353,7 @@ the removal of the lowest priority Pods is not sufficient to allow the scheduler
|
||||
to schedule the preemptor Pod, or if the lowest priority Pods are protected by
|
||||
`PodDisruptionBudget`.
|
||||
|
||||
The kubelet uses Priority to determine pod order for [out-of-resource eviction](/docs/tasks/administer-cluster/out-of-resource/).
|
||||
The kubelet uses Priority to determine pod order for [node-pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
You can use the QoS class to estimate the order in which pods are most likely
|
||||
to get evicted. The kubelet ranks pods for eviction based on the following factors:
|
||||
|
||||
@@ -361,10 +361,10 @@ to get evicted. The kubelet ranks pods for eviction based on the following facto
|
||||
1. Pod Priority
|
||||
1. Amount of resource usage relative to requests
|
||||
|
||||
See [evicting end-user pods](/docs/tasks/administer-cluster/out-of-resource/#evicting-end-user-pods)
|
||||
See [Pod selection for kubelet eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)
|
||||
for more details.
|
||||
|
||||
kubelet out-of-resource eviction does not evict Pods when their
|
||||
kubelet node-pressure eviction does not evict Pods when their
|
||||
usage does not exceed their requests. If a Pod with lower priority is not
|
||||
exceeding its requests, it won't be evicted. Another Pod with higher priority
|
||||
that exceeds its requests may be evicted.
|
||||
|
||||
@@ -8,7 +8,7 @@ weight: 90
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
{{< feature-state for_k8s_version="v1.15" state="alpha" >}}
|
||||
{{< feature-state for_k8s_version="v1.19" state="stable" >}}
|
||||
|
||||
The scheduling framework is a pluggable architecture for the Kubernetes scheduler.
|
||||
It adds a new set of "plugin" APIs to the existing scheduler. Plugins are compiled into the scheduler. The APIs allow most scheduling features to be implemented as plugins, while keeping the
|
||||
|
||||
@@ -267,7 +267,7 @@ This ensures that DaemonSet pods are never evicted due to these problems.
|
||||
## Taint Nodes by Condition
|
||||
|
||||
The control plane, using the node {{<glossary_tooltip text="controller" term_id="controller">}},
|
||||
automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/pod-eviction#node-conditions).
|
||||
automatically creates taints with a `NoSchedule` effect for [node conditions](/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions).
|
||||
|
||||
The scheduler checks taints, not node conditions, when it makes scheduling
|
||||
decisions. This ensures that node conditions don't directly affect scheduling.
|
||||
@@ -298,7 +298,7 @@ arbitrary tolerations to DaemonSets.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Read about [out of resource handling](/docs/concepts/scheduling-eviction/out-of-resource/) and how you can configure it
|
||||
* Read about [pod priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
|
||||
* Read about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) and how you can configure it
|
||||
* Read about [Pod Priority](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
|
||||
|
||||
|
||||
|
||||
@@ -32,6 +32,7 @@ Kubernetes as a project supports and maintains [AWS](https://github.com/kubernet
|
||||
Citrix Application Delivery Controller.
|
||||
* [Contour](https://projectcontour.io/) is an [Envoy](https://www.envoyproxy.io/) based ingress controller.
|
||||
* [EnRoute](https://getenroute.io/) is an [Envoy](https://www.envoyproxy.io) based API gateway that can run as an ingress controller.
|
||||
* [Easegress IngressController](https://github.com/megaease/easegress/blob/main/doc/ingresscontroller.md) is an [Easegress](https://megaease.com/easegress/) based API gateway that can run as an ingress controller.
|
||||
* F5 BIG-IP [Container Ingress Services for Kubernetes](https://clouddocs.f5.com/containers/latest/userguide/kubernetes/)
|
||||
lets you use an Ingress to configure F5 BIG-IP virtual servers.
|
||||
* [Gloo](https://gloo.solo.io) is an open-source ingress controller based on [Envoy](https://www.envoyproxy.io),
|
||||
|
||||
@@ -72,7 +72,7 @@ A Service in Kubernetes is a REST object, similar to a Pod. Like all of the
|
||||
REST objects, you can `POST` a Service definition to the API server to create
|
||||
a new instance.
|
||||
The name of a Service object must be a valid
|
||||
[DNS label name](/docs/concepts/overview/working-with-objects/names#dns-label-names).
|
||||
[RFC 1035 label name](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names).
|
||||
|
||||
For example, suppose you have a set of Pods where each listens on TCP port 9376
|
||||
and contains a label `app=MyApp`:
|
||||
@@ -188,7 +188,7 @@ selectors and uses DNS names instead. For more information, see the
|
||||
[ExternalName](#externalname) section later in this document.
|
||||
|
||||
### Over Capacity Endpoints
|
||||
If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.21 (or later)
|
||||
If an Endpoints resource has more than 1000 endpoints then a Kubernetes v1.21
|
||||
cluster annotates that Endpoints with `endpoints.kubernetes.io/over-capacity: warning`.
|
||||
This annotation indicates that the affected Endpoints object is over capacity.
|
||||
|
||||
|
||||
@@ -76,7 +76,7 @@ for provisioning PVs. This field must be specified.
|
||||
| Glusterfs | ✓ | [Glusterfs](#glusterfs) |
|
||||
| iSCSI | - | - |
|
||||
| Quobyte | ✓ | [Quobyte](#quobyte) |
|
||||
| NFS | - | - |
|
||||
| NFS | - | [NFS](#nfs) |
|
||||
| RBD | ✓ | [Ceph RBD](#ceph-rbd) |
|
||||
| VsphereVolume | ✓ | [vSphere](#vsphere) |
|
||||
| PortworxVolume | ✓ | [Portworx Volume](#portworx-volume) |
|
||||
@@ -423,6 +423,29 @@ parameters:
|
||||
`gluster-dynamic-<claimname>`. The dynamic endpoint and service are automatically
|
||||
deleted when the persistent volume claim is deleted.
|
||||
|
||||
### NFS
|
||||
|
||||
```yaml
|
||||
apiVersion: storage.k8s.io/v1
|
||||
kind: StorageClass
|
||||
metadata:
|
||||
name: example-nfs
|
||||
provisioner: example.com/external-nfs
|
||||
parameters:
|
||||
server: nfs-server.example.com
|
||||
path: /share
|
||||
readOnly: false
|
||||
```
|
||||
|
||||
* `server`: Server is the hostname or IP address of the NFS server.
|
||||
* `path`: Path that is exported by the NFS server.
|
||||
* `readOnly`: A flag indicating whether the storage will be mounted as read only (default false).
|
||||
|
||||
Kubernetes doesn't include an internal NFS provisioner. You need to use an external provisioner to create a StorageClass for NFS.
|
||||
Here are some examples:
|
||||
* [NFS Ganesha server and external provisioner](https://github.com/kubernetes-sigs/nfs-ganesha-server-and-external-provisioner)
|
||||
* [NFS subdir external provisioner](https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner)
|
||||
|
||||
### OpenStack Cinder
|
||||
|
||||
```yaml
|
||||
|
||||
@@ -1,184 +0,0 @@
|
||||
---
|
||||
title: Garbage Collection
|
||||
content_type: concept
|
||||
weight: 60
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
The role of the Kubernetes garbage collector is to delete certain objects
|
||||
that once had an owner, but no longer have an owner.
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Owners and dependents
|
||||
|
||||
Some Kubernetes objects are owners of other objects. For example, a ReplicaSet
|
||||
is the owner of a set of Pods. The owned objects are called *dependents* of the
|
||||
owner object. Every dependent object has a `metadata.ownerReferences` field that
|
||||
points to the owning object.
|
||||
|
||||
Sometimes, Kubernetes sets the value of `ownerReference` automatically. For
|
||||
example, when you create a ReplicaSet, Kubernetes automatically sets the
|
||||
`ownerReference` field of each Pod in the ReplicaSet. In 1.8, Kubernetes
|
||||
automatically sets the value of `ownerReference` for objects created or adopted
|
||||
by ReplicationController, ReplicaSet, StatefulSet, DaemonSet, Deployment, Job
|
||||
and CronJob.
|
||||
|
||||
You can also specify relationships between owners and dependents by manually
|
||||
setting the `ownerReference` field.
|
||||
|
||||
Here's a configuration file for a ReplicaSet that has three Pods:
|
||||
|
||||
{{< codenew file="controllers/replicaset.yaml" >}}
|
||||
|
||||
If you create the ReplicaSet and then view the Pod metadata, you can see
|
||||
OwnerReferences field:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/controllers/replicaset.yaml
|
||||
kubectl get pods --output=yaml
|
||||
```
|
||||
|
||||
The output shows that the Pod owner is a ReplicaSet named `my-repset`:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Pod
|
||||
metadata:
|
||||
...
|
||||
ownerReferences:
|
||||
- apiVersion: apps/v1
|
||||
controller: true
|
||||
blockOwnerDeletion: true
|
||||
kind: ReplicaSet
|
||||
name: my-repset
|
||||
uid: d9607e19-f88f-11e6-a518-42010a800195
|
||||
...
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Cross-namespace owner references are disallowed by design.
|
||||
|
||||
Namespaced dependents can specify cluster-scoped or namespaced owners.
|
||||
A namespaced owner **must** exist in the same namespace as the dependent.
|
||||
If it does not, the owner reference is treated as absent, and the dependent
|
||||
is subject to deletion once all owners are verified absent.
|
||||
|
||||
Cluster-scoped dependents can only specify cluster-scoped owners.
|
||||
In v1.20+, if a cluster-scoped dependent specifies a namespaced kind as an owner,
|
||||
it is treated as having an unresolvable owner reference, and is not able to be garbage collected.
|
||||
|
||||
In v1.20+, if the garbage collector detects an invalid cross-namespace `ownerReference`,
|
||||
or a cluster-scoped dependent with an `ownerReference` referencing a namespaced kind, a warning Event
|
||||
with a reason of `OwnerRefInvalidNamespace` and an `involvedObject` of the invalid dependent is reported.
|
||||
You can check for that kind of Event by running
|
||||
`kubectl get events -A --field-selector=reason=OwnerRefInvalidNamespace`.
|
||||
{{< /note >}}
|
||||
|
||||
## Controlling how the garbage collector deletes dependents
|
||||
|
||||
When you delete an object, you can specify whether the object's dependents are
|
||||
also deleted automatically. Deleting dependents automatically is called *cascading
|
||||
deletion*. There are two modes of *cascading deletion*: *background* and *foreground*.
|
||||
|
||||
If you delete an object without deleting its dependents
|
||||
automatically, the dependents are said to be *orphaned*.
|
||||
|
||||
### Foreground cascading deletion
|
||||
|
||||
In *foreground cascading deletion*, the root object first
|
||||
enters a "deletion in progress" state. In the "deletion in progress" state,
|
||||
the following things are true:
|
||||
|
||||
* The object is still visible via the REST API
|
||||
* The object's `deletionTimestamp` is set
|
||||
* The object's `metadata.finalizers` contains the value "foregroundDeletion".
|
||||
|
||||
Once the "deletion in progress" state is set, the garbage
|
||||
collector deletes the object's dependents. Once the garbage collector has deleted all
|
||||
"blocking" dependents (objects with `ownerReference.blockOwnerDeletion=true`), it deletes
|
||||
the owner object.
|
||||
|
||||
Note that in the "foregroundDeletion", only dependents with
|
||||
`ownerReference.blockOwnerDeletion=true` block the deletion of the owner object.
|
||||
Kubernetes version 1.7 added an [admission controller](/docs/reference/access-authn-authz/admission-controllers/#ownerreferencespermissionenforcement) that controls user access to set
|
||||
`blockOwnerDeletion` to true based on delete permissions on the owner object, so that
|
||||
unauthorized dependents cannot delay deletion of an owner object.
|
||||
|
||||
If an object's `ownerReferences` field is set by a controller (such as Deployment or ReplicaSet),
|
||||
blockOwnerDeletion is set automatically and you do not need to manually modify this field.
|
||||
|
||||
### Background cascading deletion
|
||||
|
||||
In *background cascading deletion*, Kubernetes deletes the owner object
|
||||
immediately and the garbage collector then deletes the dependents in
|
||||
the background.
|
||||
|
||||
### Setting the cascading deletion policy
|
||||
|
||||
To control the cascading deletion policy, set the `propagationPolicy`
|
||||
field on the `deleteOptions` argument when deleting an Object. Possible values include "Orphan",
|
||||
"Foreground", or "Background".
|
||||
|
||||
Here's an example that deletes dependents in background:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
Here's an example that deletes dependents in foreground:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
Here's an example that orphans dependents:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/replicasets/my-repset \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
kubectl also supports cascading deletion.
|
||||
|
||||
To delete dependents in the foreground using kubectl, set `--cascade=foreground`. To
|
||||
orphan dependents, set `--cascade=orphan`.
|
||||
|
||||
The default behavior is to delete the dependents in the background which is the
|
||||
behavior when `--cascade` is omitted or explicitly set to `background`.
|
||||
|
||||
Here's an example that orphans the dependents of a ReplicaSet:
|
||||
|
||||
```shell
|
||||
kubectl delete replicaset my-repset --cascade=orphan
|
||||
```
|
||||
|
||||
### Additional note on Deployments
|
||||
|
||||
Prior to 1.7, When using cascading deletes with Deployments you *must* use `propagationPolicy: Foreground`
|
||||
to delete not only the ReplicaSets created, but also their Pods. If this type of _propagationPolicy_
|
||||
is not used, only the ReplicaSets will be deleted, and the Pods will be orphaned.
|
||||
See [kubeadm/#149](https://github.com/kubernetes/kubeadm/issues/149#issuecomment-284766613) for more information.
|
||||
|
||||
## Known issues
|
||||
|
||||
Tracked at [#26120](https://github.com/kubernetes/kubernetes/issues/26120)
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
[Design Doc 1](https://git.k8s.io/community/contributors/design-proposals/api-machinery/garbage-collection.md)
|
||||
|
||||
[Design Doc 2](https://git.k8s.io/community/contributors/design-proposals/api-machinery/synchronous-garbage-collection.md)
|
||||
@@ -283,6 +283,17 @@ on the Kubernetes API server for each static Pod.
|
||||
This means that the Pods running on a node are visible on the API server,
|
||||
but cannot be controlled from there.
|
||||
|
||||
## Container probes
|
||||
|
||||
A _probe_ is a diagnostic performed periodically by the kubelet on a container. To perform a diagnostic, the kubelet can invoke different actions:
|
||||
|
||||
- `ExecAction` (performed with the help of the container runtime)
|
||||
- `TCPSocketAction` (checked directly by the kubelet)
|
||||
- `HTTPGetAction` (checked directly by the kubelet)
|
||||
|
||||
You can read more about [probes](/docs/concepts/workloads/pods/pod-lifecycle/#container-probes)
|
||||
in the Pod Lifecycle documentation.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn about the [lifecycle of a Pod](/docs/concepts/workloads/pods/pod-lifecycle/).
|
||||
|
||||
@@ -31,7 +31,7 @@ an application. Examples are:
|
||||
- cloud provider or hypervisor failure makes VM disappear
|
||||
- a kernel panic
|
||||
- the node disappears from the cluster due to cluster network partition
|
||||
- eviction of a pod due to the node being [out-of-resources](/docs/tasks/administer-cluster/out-of-resource/).
|
||||
- eviction of a pod due to the node being [out-of-resources](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
|
||||
Except for the out-of-resources condition, all these conditions
|
||||
should be familiar to most users; they are not specific
|
||||
|
||||
@@ -304,13 +304,23 @@ specify a readiness probe. In this case, the readiness probe might be the same
|
||||
as the liveness probe, but the existence of the readiness probe in the spec means
|
||||
that the Pod will start without receiving any traffic and only start receiving
|
||||
traffic after the probe starts succeeding.
|
||||
If your container needs to work on loading large data, configuration files, or
|
||||
migrations during startup, specify a readiness probe.
|
||||
|
||||
If you want your container to be able to take itself down for maintenance, you
|
||||
can specify a readiness probe that checks an endpoint specific to readiness that
|
||||
is different from the liveness probe.
|
||||
|
||||
If your app has a strict dependency on back-end services, you can implement both
|
||||
a liveness and a readiness probe. The liveness probe passes when the app itself
|
||||
is healthy, but the readiness probe additionally checks that each required
|
||||
back-end service is available. This helps you avoid directing traffic to Pods
|
||||
that can only respond with error messages.
|
||||
|
||||
If your container needs to work on loading large data, configuration files, or
|
||||
migrations during startup, you can use a
|
||||
[startup probe](#when-should-you-use-a-startup-probe). However, if you want to
|
||||
detect the difference between an app that has failed and an app that is still
|
||||
processing its startup data, you might prefer a readiness probe.
|
||||
|
||||
{{< note >}}
|
||||
If you want to be able to drain requests when the Pod is deleted, you do not
|
||||
necessarily need a readiness probe; on deletion, the Pod automatically puts itself
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: API-initiated eviction
|
||||
id: api-eviction
|
||||
date: 2021-04-27
|
||||
full_link: /docs/concepts/scheduling-eviction/pod-eviction/#api-eviction
|
||||
full_link: /docs/concepts/scheduling-eviction/api-eviction/
|
||||
short_description: >
|
||||
API-initiated eviction is the process by which you use the Eviction API to create an
|
||||
Eviction object that triggers graceful pod termination.
|
||||
|
||||
@@ -0,0 +1,31 @@
|
||||
---
|
||||
title: Finalizer
|
||||
id: finalizer
|
||||
date: 2021-07-07
|
||||
full_link: /docs/concepts/overview/working-with-objects/finalizers/
|
||||
short_description: >
|
||||
A namespaced key that tells Kubernetes to wait until specific conditions are met
|
||||
before it fully deletes an object marked for deletion.
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Finalizers are namespaced keys that tell Kubernetes to wait until specific
|
||||
conditions are met before it fully deletes resources marked for deletion.
|
||||
Finalizers alert {{<glossary_tooltip text="controllers" term_id="controller">}}
|
||||
to clean up resources the deleted object owned.
|
||||
|
||||
<!--more-->
|
||||
|
||||
When you tell Kubernetes to delete an object that has finalizers specified for
|
||||
it, the Kubernetes API marks the object for deletion, putting it into a
|
||||
read-only state. The target object remains in a terminating state while the
|
||||
control plane, or other components, take the actions defined by the finalizers.
|
||||
After these actions are complete, the controller removes the relevant finalizers
|
||||
from the target object. When the `metadata.finalizers` field is empty,
|
||||
Kubernetes considers the deletion complete.
|
||||
|
||||
You can use finalizers to control {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}
|
||||
of resources. For example, you can define a finalizer to clean up related resources or
|
||||
infrastructure before the controller deletes the target resource.
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
title: Garbage Collection
|
||||
id: garbage-collection
|
||||
date: 2021-07-07
|
||||
full_link: /docs/concepts/workloads/controllers/garbage-collection/
|
||||
short_description: >
|
||||
A collective term for the various mechanisms Kubernetes uses to clean up cluster
|
||||
resources.
|
||||
|
||||
aka:
|
||||
tags:
|
||||
- fundamental
|
||||
- operation
|
||||
---
|
||||
Garbage collection is a collective term for the various mechanisms Kubernetes uses to clean up
|
||||
cluster resources.
|
||||
|
||||
<!--more-->
|
||||
|
||||
Kubernetes uses garbage collection to clean up resources like [unused containers and images](/docs/concepts/workloads/controllers/garbage-collection/#containers-images),
|
||||
[failed Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection),
|
||||
[objects owned by the targeted resource](/docs/concepts/overview/working-with-objects/owners-dependents/),
|
||||
[completed Jobs](/docs/concepts/workloads/controllers/ttlafterfinished/), and resources
|
||||
that have expired or failed.
|
||||
@@ -11,7 +11,7 @@ tags:
|
||||
- architecture
|
||||
- fundamental
|
||||
---
|
||||
Control Plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes.
|
||||
Control plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes.
|
||||
|
||||
<!--more-->
|
||||
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
title: kube-scheduler
|
||||
id: kube-scheduler
|
||||
date: 2018-04-12
|
||||
full_link: /docs/reference/generated/kube-scheduler/
|
||||
full_link: /docs/reference/command-line-tools-reference/kube-scheduler/
|
||||
short_description: >
|
||||
Control plane component that watches for newly created pods with no assigned node, and selects a node for them to run on.
|
||||
|
||||
|
||||
@@ -200,7 +200,7 @@ Used on: Service
|
||||
|
||||
The kube-proxy has this label for custom proxy, which delegates service control to custom proxy.
|
||||
|
||||
## experimental.windows.kubernetes.io/isolation-type
|
||||
## experimental.windows.kubernetes.io/isolation-type (deprecated) {#experimental-windows-kubernetes-io-isolation-type}
|
||||
|
||||
Example: `experimental.windows.kubernetes.io/isolation-type: "hyperv"`
|
||||
|
||||
@@ -210,6 +210,7 @@ The annotation is used to run Windows containers with Hyper-V isolation. To use
|
||||
|
||||
{{< note >}}
|
||||
You can only set this annotation on Pods that have a single container.
|
||||
Starting from v1.20, this annotation is deprecated. Experimental Hyper-V support was removed in 1.21.
|
||||
{{< /note >}}
|
||||
|
||||
## ingressclass.kubernetes.io/is-default-class
|
||||
|
||||
@@ -126,8 +126,8 @@ The default configuration can be printed out using the
|
||||
If your configuration is not using the latest version it is **recommended** that you migrate using
|
||||
the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
For more information on the fields and usage of the configuration you can navigate to our API reference
|
||||
page and pick a version from [the list](https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories).
|
||||
For more information on the fields and usage of the configuration you can navigate to our
|
||||
[API reference page](/docs/reference/config-api/kubeadm-config.v1beta2/).
|
||||
|
||||
### Adding kube-proxy parameters {#kube-proxy}
|
||||
|
||||
|
||||
@@ -286,8 +286,8 @@ The default configuration can be printed out using the
|
||||
If your configuration is not using the latest version it is **recommended** that you migrate using
|
||||
the [kubeadm config migrate](/docs/reference/setup-tools/kubeadm/kubeadm-config/) command.
|
||||
|
||||
For more information on the fields and usage of the configuration you can navigate to our API reference
|
||||
page and pick a version from [the list](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#pkg-subdirectories).
|
||||
For more information on the fields and usage of the configuration you can navigate to our
|
||||
[API reference](/docs/reference/config-api/kubeadm-config.v1beta2/).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
@@ -26,8 +26,8 @@ to a Kubernetes cluster, troubleshoot them, and manage the cluster and its resou
|
||||
|
||||
## Helm
|
||||
|
||||
[`Kubernetes Helm`](https://github.com/kubernetes/helm) is a tool for managing packages of pre-configured
|
||||
Kubernetes resources, aka Kubernetes charts.
|
||||
[Helm](https://helm.sh/) is a tool for managing packages of pre-configured
|
||||
Kubernetes resources. These packages are known as _Helm charts_.
|
||||
|
||||
Use Helm to:
|
||||
|
||||
|
||||
@@ -208,6 +208,77 @@ more remaining items and the API server does not include a `remainingItemCount`
|
||||
field in its response. The intended use of the `remainingItemCount` is estimating
|
||||
the size of a collection.
|
||||
|
||||
## Lists
|
||||
|
||||
There are dozens of list types (such as `PodList`, `ServiceList`, and `NodeList`) defined in the Kubernetes API.
|
||||
You can get more information about each list type from the [Kubernetes API](https://kubernetes.io/docs/reference/kubernetes-api/) documentation.
|
||||
|
||||
When you query the API for a particular type, all items returned by that query are of that type. For example, when you
|
||||
ask for a list of services, the list type is shown as `kind: ServiceList` and each item in that list represents a single Service. For example:
|
||||
|
||||
```console
|
||||
|
||||
GET /api/v1/services
|
||||
---
|
||||
{
|
||||
"kind": "ServiceList",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"resourceVersion": "2947301"
|
||||
},
|
||||
"items": [
|
||||
{
|
||||
"metadata": {
|
||||
"name": "kubernetes",
|
||||
"namespace": "default",
|
||||
...
|
||||
"metadata": {
|
||||
"name": "kube-dns",
|
||||
"namespace": "kube-system",
|
||||
...
|
||||
```
|
||||
|
||||
Some tools, such as `kubectl` provide another way to query the Kubernetes API. Because the output of `kubectl` might include multiple list types, the list of items is represented as `kind: List`. For example:
|
||||
|
||||
```console
|
||||
|
||||
$ kubectl get services -A -o yaml
|
||||
|
||||
apiVersion: v1
|
||||
kind: List
|
||||
metadata:
|
||||
resourceVersion: ""
|
||||
selfLink: ""
|
||||
items:
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
creationTimestamp: "2021-06-03T14:54:12Z"
|
||||
labels:
|
||||
component: apiserver
|
||||
provider: kubernetes
|
||||
name: kubernetes
|
||||
namespace: default
|
||||
...
|
||||
- apiVersion: v1
|
||||
kind: Service
|
||||
metadata:
|
||||
annotations:
|
||||
prometheus.io/port: "9153"
|
||||
prometheus.io/scrape: "true"
|
||||
creationTimestamp: "2021-06-03T14:54:14Z"
|
||||
labels:
|
||||
k8s-app: kube-dns
|
||||
kubernetes.io/cluster-service: "true"
|
||||
kubernetes.io/name: CoreDNS
|
||||
name: kube-dns
|
||||
namespace: kube-system
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Keep in mind that the Kubernetes API does not have a `kind: List` type. `kind: List` is an internal mechanism type for lists of mixed resources and should not be depended upon.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## Receiving resources as Tables
|
||||
|
||||
|
||||
@@ -53,11 +53,11 @@ The **events.k8s.io/v1beta1** API version of Event will no longer be served in v
|
||||
* Notable changes in **events.k8s.io/v1**:
|
||||
* `type` is limited to `Normal` and `Warning`
|
||||
* `involvedObject` is renamed to `regarding`
|
||||
* `action`, `reason`, `reportingComponent`, and `reportingInstance` are required when creating new **events.k8s.io/v1** Events
|
||||
* `action`, `reason`, `reportingController`, and `reportingInstance` are required when creating new **events.k8s.io/v1** Events
|
||||
* use `eventTime` instead of the deprecated `firstTimestamp` field (which is renamed to `deprecatedFirstTimestamp` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `series.lastObservedTime` instead of the deprecated `lastTimestamp` field (which is renamed to `deprecatedLastTimestamp` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `series.count` instead of the deprecated `count` field (which is renamed to `deprecatedCount` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `reportingComponent` instead of the deprecated `source.component` field (which is renamed to `deprecatedSource.component` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `reportingController` instead of the deprecated `source.component` field (which is renamed to `deprecatedSource.component` and not permitted in new **events.k8s.io/v1** Events)
|
||||
* use `reportingInstance` instead of the deprecated `source.host` field (which is renamed to `deprecatedSource.host` and not permitted in new **events.k8s.io/v1** Events)
|
||||
|
||||
#### PodDisruptionBudget {#poddisruptionbudget-v125}
|
||||
|
||||
+1
-1
@@ -415,7 +415,7 @@ and make sure that the node is empty, then deconfigure the node.
|
||||
Talking to the control-plane node with the appropriate credentials, run:
|
||||
|
||||
```bash
|
||||
kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
|
||||
kubectl drain <node name> --delete-emptydir-data --force --ignore-daemonsets
|
||||
```
|
||||
|
||||
Before removing the node, reset the state installed by `kubeadm`:
|
||||
|
||||
@@ -150,3 +150,4 @@ networking:
|
||||
|
||||
* [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking
|
||||
* Read about [Dual-stack](/docs/concepts/services-networking/dual-stack/) cluster networking
|
||||
* Learn more about the kubeadm [configuration format](/docs/reference/config-api/kubeadm-config.v1beta2/)
|
||||
|
||||
@@ -11,7 +11,7 @@ card:
|
||||
<!-- overview -->
|
||||
|
||||
<img src="https://raw.githubusercontent.com/kubernetes/kubeadm/master/logos/stacked/color/kubeadm-stacked-color.png" align="right" width="150px">This page shows how to install the `kubeadm` toolbox.
|
||||
For information how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
For information on how to create a cluster with kubeadm once you have performed this installation process, see the [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) page.
|
||||
|
||||
|
||||
|
||||
@@ -240,8 +240,9 @@ Install CNI plugins (required for most pod network):
|
||||
|
||||
```bash
|
||||
CNI_VERSION="v0.8.2"
|
||||
ARCH="amd64"
|
||||
sudo mkdir -p /opt/cni/bin
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-amd64-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
|
||||
curl -L "https://github.com/containernetworking/plugins/releases/download/${CNI_VERSION}/cni-plugins-linux-${ARCH}-${CNI_VERSION}.tgz" | sudo tar -C /opt/cni/bin -xz
|
||||
```
|
||||
|
||||
Define the directory to download command files
|
||||
@@ -260,15 +261,17 @@ Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI)
|
||||
|
||||
```bash
|
||||
CRICTL_VERSION="v1.17.0"
|
||||
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-amd64.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
|
||||
ARCH="amd64"
|
||||
curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz
|
||||
```
|
||||
|
||||
Install `kubeadm`, `kubelet`, `kubectl` and add a `kubelet` systemd service:
|
||||
|
||||
```bash
|
||||
RELEASE="$(curl -sSL https://dl.k8s.io/release/stable.txt)"
|
||||
ARCH="amd64"
|
||||
cd $DOWNLOAD_DIR
|
||||
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/amd64/{kubeadm,kubelet,kubectl}
|
||||
sudo curl -L --remote-name-all https://storage.googleapis.com/kubernetes-release/release/${RELEASE}/bin/linux/${ARCH}/{kubeadm,kubelet,kubectl}
|
||||
sudo chmod +x {kubeadm,kubelet,kubectl}
|
||||
|
||||
RELEASE_VERSION="v0.4.0"
|
||||
@@ -314,4 +317,3 @@ If you are running into difficulties with kubeadm, please consult our [troublesh
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/)
|
||||
|
||||
|
||||
+8
-3
@@ -163,7 +163,7 @@ services](/docs/concepts/services-networking/service/#nodeport) or use `HostNetw
|
||||
|
||||
## Pods are not accessible via their Service IP
|
||||
|
||||
- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-cannot-reach-itself-via-service-ip)
|
||||
- Many network add-ons do not yet enable [hairpin mode](/docs/tasks/debug-application-cluster/debug-service/#a-pod-fails-to-reach-itself-via-the-service-ip)
|
||||
which allows pods to access themselves via their Service IP. This is an issue related to
|
||||
[CNI](https://github.com/containernetworking/cni/issues/476). Please contact the network
|
||||
add-on provider to get the latest status of their support for hairpin mode.
|
||||
@@ -258,7 +258,12 @@ Error from server: Get https://10.19.0.41:10250/containerLogs/default/mysql-ddc6
|
||||
curl http://169.254.169.254/metadata/v1/interfaces/public/0/anchor_ipv4/address
|
||||
```
|
||||
|
||||
The workaround is to tell `kubelet` which IP to use using `--node-ip`. When using DigitalOcean, it can be the public one (assigned to `eth0`) or the private one (assigned to `eth1`) should you want to use the optional private network. The [`KubeletExtraArgs` section of the kubeadm `NodeRegistrationOptions` structure](https://github.com/kubernetes/kubernetes/blob/release-1.13/cmd/kubeadm/app/apis/kubeadm/v1beta1/types.go) can be used for this.
|
||||
The workaround is to tell `kubelet` which IP to use using `--node-ip`.
|
||||
When using DigitalOcean, it can be the public one (assigned to `eth0`) or
|
||||
the private one (assigned to `eth1`) should you want to use the optional
|
||||
private network. The `kubeletExtraArgs` section of the kubeadm
|
||||
[`NodeRegistrationOptions` structure](/docs/reference/config-api/kubeadm-config.v1beta2/#kubeadm-k8s-io-v1beta2-NodeRegistrationOptions)
|
||||
can be used for this.
|
||||
|
||||
Then restart `kubelet`:
|
||||
|
||||
@@ -331,7 +336,7 @@ Alternatively, you can try separating the `key=value` pairs like so:
|
||||
`--apiserver-extra-args "enable-admission-plugins=LimitRanger,enable-admission-plugins=NamespaceExists"`
|
||||
but this will result in the key `enable-admission-plugins` only having the value of `NamespaceExists`.
|
||||
|
||||
A known workaround is to use the kubeadm [configuration file](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#apiserver-flags).
|
||||
A known workaround is to use the kubeadm [configuration file](/docs/reference/config-api/kubeadm-config.v1beta2/).
|
||||
|
||||
## kube-proxy scheduled before node is initialized by cloud-controller-manager
|
||||
|
||||
|
||||
+2
-2
@@ -31,7 +31,7 @@ for database debugging.
|
||||
1. Create a Deployment that runs MongoDB:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-deployment.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
|
||||
```
|
||||
|
||||
The output of a successful command verifies that the deployment was created:
|
||||
@@ -84,7 +84,7 @@ for database debugging.
|
||||
2. Create a Service to expose MongoDB on the network:
|
||||
|
||||
```shell
|
||||
kubectl apply -f https://k8s.io/examples/application/guestbook/mongo-service.yaml
|
||||
kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
|
||||
```
|
||||
|
||||
The output of a successful command verifies that the Service was created:
|
||||
|
||||
@@ -0,0 +1,352 @@
|
||||
---
|
||||
title: Use Cascading Deletion in a Cluster
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!--overview-->
|
||||
|
||||
This page shows you how to specify the type of [cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#cascading-deletion)
|
||||
to use in your cluster during {{<glossary_tooltip text="garbage collection" term_id="garbage-collection">}}.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
You also need to [create a sample Deployment](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment)
|
||||
to experiment with the different types of cascading deletion. You will need to
|
||||
recreate the Deployment for each type.
|
||||
|
||||
## Check owner references on your pods
|
||||
|
||||
Check that the `ownerReferences` field is present on your pods:
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=nginx --output=yaml
|
||||
```
|
||||
|
||||
The output has an `ownerReferences` field similar to this:
|
||||
|
||||
```
|
||||
apiVersion: v1
|
||||
...
|
||||
ownerReferences:
|
||||
- apiVersion: apps/v1
|
||||
blockOwnerDeletion: true
|
||||
controller: true
|
||||
kind: ReplicaSet
|
||||
name: nginx-deployment-6b474476c4
|
||||
uid: 4fdcd81c-bd5d-41f7-97af-3a3b759af9a7
|
||||
...
|
||||
```
|
||||
|
||||
## Use foreground cascading deletion {#use-foreground-cascading-deletion}
|
||||
|
||||
By default, Kubernetes uses [background cascading deletion](/docs/concepts/workloads/controllers/garbage-collection/#background-deletion)
|
||||
to delete dependents of an object. You can switch to foreground cascading deletion
|
||||
using either `kubectl` or the Kubernetes API, depending on the Kubernetes
|
||||
version your cluster runs. {{<version-check>}}
|
||||
|
||||
{{<tabs name="foreground_deletion">}}
|
||||
{{% tab name="Kubernetes 1.20.x and later" %}}
|
||||
You can delete objects using foreground cascading deletion using `kubectl` or the
|
||||
Kubernetes API.
|
||||
|
||||
**Using kubectl**
|
||||
|
||||
Run the following command:
|
||||
<!--TODO: verify release after which the --cascade flag is switched to a string in https://github.com/kubernetes/kubectl/commit/fd930e3995957b0093ecc4b9fd8b0525d94d3b4e-->
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment --cascade=foreground
|
||||
```
|
||||
|
||||
**Using the Kubernetes API**
|
||||
|
||||
1. Start a local proxy session:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. Use `curl` to trigger deletion:
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
The output contains a `foregroundDeletion` {{<glossary_tooltip text="finalizer" term_id="finalizer">}}
|
||||
like this:
|
||||
|
||||
```
|
||||
"kind": "Deployment",
|
||||
"apiVersion": "apps/v1",
|
||||
"metadata": {
|
||||
"name": "nginx-deployment",
|
||||
"namespace": "default",
|
||||
"uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505",
|
||||
"resourceVersion": "1363097",
|
||||
"creationTimestamp": "2021-07-08T20:24:37Z",
|
||||
"deletionTimestamp": "2021-07-08T20:27:39Z",
|
||||
"finalizers": [
|
||||
"foregroundDeletion"
|
||||
]
|
||||
...
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Versions prior to Kubernetes 1.20.x" %}}
|
||||
You can delete objects using foreground cascading deletion by calling the
|
||||
Kubernetes API.
|
||||
|
||||
For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/).
|
||||
|
||||
1. Start a local proxy session:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. Use `curl` to trigger deletion:
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
The output contains a `foregroundDeletion` {{<glossary_tooltip text="finalizer" term_id="finalizer">}}
|
||||
like this:
|
||||
|
||||
```
|
||||
"kind": "Deployment",
|
||||
"apiVersion": "apps/v1",
|
||||
"metadata": {
|
||||
"name": "nginx-deployment",
|
||||
"namespace": "default",
|
||||
"uid": "d1ce1b02-cae8-4288-8a53-30e84d8fa505",
|
||||
"resourceVersion": "1363097",
|
||||
"creationTimestamp": "2021-07-08T20:24:37Z",
|
||||
"deletionTimestamp": "2021-07-08T20:27:39Z",
|
||||
"finalizers": [
|
||||
"foregroundDeletion"
|
||||
]
|
||||
...
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{</tabs>}}
|
||||
|
||||
## Use background cascading deletion {#use-background-cascading-deletion}
|
||||
|
||||
1. [Create a sample Deployment](/docs/tasks/run-application/run-stateless-application-deployment/#creating-and-exploring-an-nginx-deployment).
|
||||
1. Use either `kubectl` or the Kubernetes API to delete the Deployment,
|
||||
depending on the Kubernetes version your cluster runs. {{<version-check>}}
|
||||
|
||||
{{<tabs name="background_deletion">}}
|
||||
{{% tab name="Kubernetes version 1.20.x and later" %}}
|
||||
|
||||
You can delete objects using background cascading deletion using `kubectl`
|
||||
or the Kubernetes API.
|
||||
|
||||
Kubernetes uses background cascading deletion by default, and does so
|
||||
even if you run the following commands without the `--cascade` flag or the
|
||||
`propagationPolicy` argument.
|
||||
|
||||
**Using kubectl**
|
||||
|
||||
Run the following command:
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment --cascade=background
|
||||
```
|
||||
|
||||
**Using the Kubernetes API**
|
||||
|
||||
1. Start a local proxy session:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. Use `curl` to trigger deletion:
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
"kind": "Status",
|
||||
"apiVersion": "v1",
|
||||
...
|
||||
"status": "Success",
|
||||
"details": {
|
||||
"name": "nginx-deployment",
|
||||
"group": "apps",
|
||||
"kind": "deployments",
|
||||
"uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456"
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="Versions prior to Kubernetes 1.20.x" %}}
|
||||
Kubernetes uses background cascading deletion by default, and does so
|
||||
even if you run the following commands without the `--cascade` flag or the
|
||||
`propagationPolicy: Background` argument.
|
||||
|
||||
For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/).
|
||||
|
||||
**Using kubectl**
|
||||
|
||||
Run the following command:
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment --cascade=true
|
||||
```
|
||||
|
||||
**Using the Kubernetes API**
|
||||
|
||||
1. Start a local proxy session:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. Use `curl` to trigger deletion:
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Background"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
The output is similar to this:
|
||||
|
||||
```
|
||||
"kind": "Status",
|
||||
"apiVersion": "v1",
|
||||
...
|
||||
"status": "Success",
|
||||
"details": {
|
||||
"name": "nginx-deployment",
|
||||
"group": "apps",
|
||||
"kind": "deployments",
|
||||
"uid": "cc9eefb9-2d49-4445-b1c1-d261c9396456"
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{</tabs>}}
|
||||
|
||||
|
||||
## Delete owner objects and orphan dependents {#set-orphan-deletion-policy}
|
||||
|
||||
By default, when you tell Kubernetes to delete an object, the
|
||||
{{<glossary_tooltip text="controller" term_id="controller">}} also deletes
|
||||
dependent objects. You can make Kubernetes *orphan* these dependents using
|
||||
`kubectl` or the Kubernetes API, depending on the Kubernetes version your
|
||||
cluster runs. {{<version-check>}}
|
||||
|
||||
{{<tabs name="orphan_objects">}}
|
||||
{{% tab name="Kubernetes version 1.20.x and later" %}}
|
||||
|
||||
**Using kubectl**
|
||||
|
||||
Run the following command:
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment --cascade=orphan
|
||||
```
|
||||
|
||||
**Using the Kubernetes API**
|
||||
|
||||
1. Start a local proxy session:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. Use `curl` to trigger deletion:
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
The output contains `orphan` in the `finalizers` field, similar to this:
|
||||
|
||||
```
|
||||
"kind": "Deployment",
|
||||
"apiVersion": "apps/v1",
|
||||
"namespace": "default",
|
||||
"uid": "6f577034-42a0-479d-be21-78018c466f1f",
|
||||
"creationTimestamp": "2021-07-09T16:46:37Z",
|
||||
"deletionTimestamp": "2021-07-09T16:47:08Z",
|
||||
"deletionGracePeriodSeconds": 0,
|
||||
"finalizers": [
|
||||
"orphan"
|
||||
],
|
||||
...
|
||||
```
|
||||
|
||||
{{% /tab %}}
|
||||
{{% tab name="Versions prior to Kubernetes 1.20.x" %}}
|
||||
|
||||
For details, read the [documentation for your Kubernetes version](/docs/home/supported-doc-versions/).
|
||||
|
||||
**Using kubectl**
|
||||
|
||||
Run the following command:
|
||||
|
||||
```shell
|
||||
kubectl delete deployment nginx-deployment --cascade=false
|
||||
```
|
||||
|
||||
**Using the Kubernetes API**
|
||||
|
||||
1. Start a local proxy session:
|
||||
|
||||
```shell
|
||||
kubectl proxy --port=8080
|
||||
```
|
||||
|
||||
1. Use `curl` to trigger deletion:
|
||||
|
||||
```shell
|
||||
curl -X DELETE localhost:8080/apis/apps/v1/namespaces/default/deployments/nginx-deployment \
|
||||
-d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Orphan"}' \
|
||||
-H "Content-Type: application/json"
|
||||
```
|
||||
|
||||
The output contains `orphan` in the `finalizers` field, similar to this:
|
||||
|
||||
```
|
||||
"kind": "Deployment",
|
||||
"apiVersion": "apps/v1",
|
||||
"namespace": "default",
|
||||
"uid": "6f577034-42a0-479d-be21-78018c466f1f",
|
||||
"creationTimestamp": "2021-07-09T16:46:37Z",
|
||||
"deletionTimestamp": "2021-07-09T16:47:08Z",
|
||||
"deletionGracePeriodSeconds": 0,
|
||||
"finalizers": [
|
||||
"orphan"
|
||||
],
|
||||
...
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{</tabs>}}
|
||||
|
||||
You can check that the Pods managed by the Deployment are still running:
|
||||
|
||||
```shell
|
||||
kubectl get pods -l app=nginx
|
||||
```
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
* Learn about [owners and dependents](/docs/concepts/overview/working-with-objects/owners-dependents/) in Kubernetes.
|
||||
* Learn about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/).
|
||||
* Learn about [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/).
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Managing Secret using Configuration File
|
||||
title: Managing Secrets using Configuration File
|
||||
content_type: task
|
||||
weight: 20
|
||||
description: Creating Secret objects using resource configuration file.
|
||||
@@ -193,6 +193,6 @@ kubectl delete secret mysecret
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
|
||||
- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- Learn how to [manage Secret using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
- Learn how to [manage Secrets with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- Learn how to [manage Secrets using kustomize](/docs/tasks/configmap-secret/managing-secret-using-kustomize/)
|
||||
|
||||
|
||||
@@ -67,7 +67,7 @@ single quotes (`'`). For example, if your password is `S!B\*d$zDsb=`,
|
||||
run the following command:
|
||||
|
||||
```shell
|
||||
kubectl create secret generic dev-db-secret \
|
||||
kubectl create secret generic db-user-pass \
|
||||
--from-literal=username=devuser \
|
||||
--from-literal=password='S!B\*d$zDsb='
|
||||
```
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
---
|
||||
title: Managing Secret using Kustomize
|
||||
title: Managing Secrets using Kustomize
|
||||
content_type: task
|
||||
weight: 30
|
||||
description: Creating Secret objects using kustomization.yaml file.
|
||||
@@ -135,6 +135,6 @@ kubectl delete secret db-user-pass-96mffmfh4k
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
- Read more about the [Secret concept](/docs/concepts/configuration/secret/)
|
||||
- Learn how to [manage Secret with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- Learn how to [manage Secret using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
- Learn how to [manage Secrets with the `kubectl` command](/docs/tasks/configmap-secret/managing-secret-using-kubectl/)
|
||||
- Learn how to [manage Secrets using config file](/docs/tasks/configmap-secret/managing-secret-using-config-file/)
|
||||
|
||||
|
||||
@@ -349,8 +349,11 @@ JSON Web Key Set (JWKS) at `/openid/v1/jwks`. The OpenID Provider Configuration
|
||||
is sometimes referred to as the _discovery document_.
|
||||
|
||||
Clusters include a default RBAC ClusterRole called
|
||||
`system:service-account-issuer-discovery`. No role bindings are provided
|
||||
by default. Administrators may, for example, choose whether to bind the role to
|
||||
`system:service-account-issuer-discovery`. A default RBAC ClusterRoleBinding
|
||||
assigns this role to the `system:serviceaccounts` group, which all service
|
||||
accounts implicitly belong to. This allows pods running on the cluster to access
|
||||
the service account discovery document via their mounted service account token.
|
||||
Administrators may, additionally, choose to bind the role to
|
||||
`system:authenticated` or `system:unauthenticated` depending on their security
|
||||
requirements and which external systems they intend to federate with.
|
||||
|
||||
|
||||
@@ -11,6 +11,8 @@ This page shows how to perform a rolling update on a DaemonSet.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## DaemonSet Update Strategy
|
||||
@@ -191,4 +193,3 @@ kubectl delete ds fluentd-elasticsearch -n kube-system
|
||||
|
||||
* See [Performing a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
|
||||
* See [Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
|
||||
@@ -198,14 +198,17 @@ The detailed documentation of `kubectl autoscale` can be found [here](/docs/refe
|
||||
|
||||
## Autoscaling during rolling update
|
||||
|
||||
Currently in Kubernetes, it is possible to perform a rolling update by using the deployment object, which manages the underlying replica sets for you.
|
||||
Horizontal Pod Autoscaler only supports the latter approach: the Horizontal Pod Autoscaler is bound to the deployment object,
|
||||
it sets the size for the deployment object, and the deployment is responsible for setting sizes of underlying replica sets.
|
||||
Kubernetes lets you perform a rolling update on a Deployment. In that
|
||||
case, the Deployment manages the underlying ReplicaSets for you.
|
||||
When you configure autoscaling for a Deployment, you bind a
|
||||
HorizontalPodAutoscaler to a single Deployment. The HorizontalPodAutoscaler
|
||||
manages the `replicas` field of the Deployment. The deployment controller is responsible
|
||||
for setting the `replicas` of the underlying ReplicaSets so that they add up to a suitable
|
||||
number during the rollout and also afterwards.
|
||||
|
||||
Horizontal Pod Autoscaler does not work with rolling update using direct manipulation of replication controllers,
|
||||
i.e. you cannot bind a Horizontal Pod Autoscaler to a replication controller and do rolling update.
|
||||
The reason this doesn't work is that when rolling update creates a new replication controller,
|
||||
the Horizontal Pod Autoscaler will not be bound to the new replication controller.
|
||||
If you perform a rolling update of a StatefulSet that has an autoscaled number of
|
||||
replicas, the StatefulSet directly manages its set of Pods (there is no intermediate resource
|
||||
similar to ReplicaSet).
|
||||
|
||||
## Support for cooldown/delay
|
||||
|
||||
|
||||
@@ -379,7 +379,7 @@ This might impact other applications on the Node, so it's best to
|
||||
**only do this in a test cluster**.
|
||||
|
||||
```shell
|
||||
kubectl drain <node-name> --force --delete-local-data --ignore-daemonsets
|
||||
kubectl drain <node-name> --force --delete-emptydir-data --ignore-daemonsets
|
||||
```
|
||||
|
||||
Now you can watch as the Pod reschedules on a different Node:
|
||||
|
||||
@@ -0,0 +1,11 @@
|
||||
---
|
||||
title: "kubectl-convert overview"
|
||||
description: >-
|
||||
A kubectl plugin that allows you to convert manifests from one version
|
||||
of a Kubernetes API to a different version.
|
||||
headless: true
|
||||
---
|
||||
|
||||
A plugin for Kubernetes command-line tool `kubectl`, which allows you to convert manifests between different API
|
||||
versions. This can be particularly helpful to migrate manifests to a non-deprecated api version with newer Kubernetes release.
|
||||
For more info, visit [migrate to non deprecated apis](/docs/reference/using-api/deprecation-guide/#migrate-to-non-deprecated-apis)
|
||||
@@ -172,7 +172,7 @@ kubectl version --client
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
## Optional kubectl configurations
|
||||
## Optional kubectl configurations and plugins
|
||||
|
||||
### Enable shell autocompletion
|
||||
|
||||
@@ -185,6 +185,61 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
|
||||
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### Install `kubectl convert` plugin
|
||||
|
||||
{{< include "included/kubectl-convert-overview.md" >}}
|
||||
|
||||
1. Download the latest release with the command:
|
||||
|
||||
```bash
|
||||
curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert
|
||||
```
|
||||
|
||||
1. Validate the binary (optional)
|
||||
|
||||
Download the kubectl-convert checksum file:
|
||||
|
||||
```bash
|
||||
curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
|
||||
```
|
||||
|
||||
Validate the kubectl-convert binary against the checksum file:
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl-convert.sha256) kubectl-convert" | sha256sum --check
|
||||
```
|
||||
|
||||
If valid, the output is:
|
||||
|
||||
```console
|
||||
kubectl-convert: OK
|
||||
```
|
||||
|
||||
If the check fails, `sha256` exits with nonzero status and prints output similar to:
|
||||
|
||||
```bash
|
||||
kubectl-convert: FAILED
|
||||
sha256sum: WARNING: 1 computed checksum did NOT match
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Download the same version of the binary and checksum.
|
||||
{{< /note >}}
|
||||
|
||||
1. Install kubectl-convert
|
||||
|
||||
```bash
|
||||
sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
|
||||
```
|
||||
|
||||
1. Verify plugin is successfully installed
|
||||
|
||||
```shell
|
||||
kubectl convert --help
|
||||
```
|
||||
|
||||
If you do not see an error, it means the plugin is successfully installed.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
||||
@@ -155,7 +155,7 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
## Optional kubectl configurations
|
||||
## Optional kubectl configurations and plugins
|
||||
|
||||
### Enable shell autocompletion
|
||||
|
||||
@@ -168,6 +168,82 @@ Below are the procedures to set up autocompletion for Bash and Zsh.
|
||||
{{< tab name="Zsh" include="included/optional-kubectl-configs-zsh.md" />}}
|
||||
{{< /tabs >}}
|
||||
|
||||
### Install `kubectl convert` plugin
|
||||
|
||||
{{< include "included/kubectl-convert-overview.md" >}}
|
||||
|
||||
1. Download the latest release with the command:
|
||||
|
||||
{{< tabs name="download_convert_binary_macos" >}}
|
||||
{{< tab name="Intel" codelang="bash" >}}
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert"
|
||||
{{< /tab >}}
|
||||
{{< tab name="Apple Silicon" codelang="bash" >}}
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert"
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
1. Validate the binary (optional)
|
||||
|
||||
Download the kubectl checksum file:
|
||||
|
||||
{{< tabs name="download_convert_checksum_macos" >}}
|
||||
{{< tab name="Intel" codelang="bash" >}}
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/amd64/kubectl-convert.sha256"
|
||||
{{< /tab >}}
|
||||
{{< tab name="Apple Silicon" codelang="bash" >}}
|
||||
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/darwin/arm64/kubectl-convert.sha256"
|
||||
{{< /tab >}}
|
||||
{{< /tabs >}}
|
||||
|
||||
Validate the kubectl-convert binary against the checksum file:
|
||||
|
||||
```bash
|
||||
echo "$(<kubectl-convert.sha256) kubectl-convert" | shasum -a 256 --check
|
||||
```
|
||||
|
||||
If valid, the output is:
|
||||
|
||||
```console
|
||||
kubectl-convert: OK
|
||||
```
|
||||
|
||||
If the check fails, `shasum` exits with nonzero status and prints output similar to:
|
||||
|
||||
```bash
|
||||
kubectl-convert: FAILED
|
||||
shasum: WARNING: 1 computed checksum did NOT match
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Download the same version of the binary and checksum.
|
||||
{{< /note >}}
|
||||
|
||||
1. Make kubectl-convert binary executable
|
||||
|
||||
```bash
|
||||
chmod +x ./kubectl-convert
|
||||
```
|
||||
|
||||
1. Move the kubectl-convert binary to a file location on your system `PATH`.
|
||||
|
||||
```bash
|
||||
sudo mv ./kubectl-convert /usr/local/bin/kubectl-convert
|
||||
sudo chown root: /usr/local/bin/kubectl-convert
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Make sure `/usr/local/bin` is in your PATH environment variable.
|
||||
{{< /note >}}
|
||||
|
||||
1. Verify plugin is successfully installed
|
||||
|
||||
```shell
|
||||
kubectl convert --help
|
||||
```
|
||||
|
||||
If you do not see an error, it means the plugin is successfully installed.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
||||
@@ -130,7 +130,7 @@ Edit the config file with a text editor of your choice, such as Notepad.
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
## Optional kubectl configurations
|
||||
## Optional kubectl configurations and plugins
|
||||
|
||||
### Enable shell autocompletion
|
||||
|
||||
@@ -140,6 +140,49 @@ Below are the procedures to set up autocompletion for Zsh, if you are running th
|
||||
|
||||
{{< include "included/optional-kubectl-configs-zsh.md" >}}
|
||||
|
||||
### Install `kubectl convert` plugin
|
||||
|
||||
{{< include "included/kubectl-convert-overview.md" >}}
|
||||
|
||||
1. Download the latest release with the command:
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/release/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe
|
||||
```
|
||||
|
||||
1. Validate the binary (optional)
|
||||
|
||||
Download the kubectl-convert checksum file:
|
||||
|
||||
```powershell
|
||||
curl -LO https://dl.k8s.io/{{< param "fullversion" >}}/bin/windows/amd64/kubectl-convert.exe.sha256
|
||||
```
|
||||
|
||||
Validate the kubectl-convert binary against the checksum file:
|
||||
|
||||
- Using Command Prompt to manually compare `CertUtil`'s output to the checksum file downloaded:
|
||||
|
||||
```cmd
|
||||
CertUtil -hashfile kubectl-convert.exe SHA256
|
||||
type kubectl-convert.exe.sha256
|
||||
```
|
||||
|
||||
- Using PowerShell to automate the verification using the `-eq` operator to get a `True` or `False` result:
|
||||
|
||||
```powershell
|
||||
$($(CertUtil -hashfile .\kubectl-convert.exe SHA256)[1] -replace " ", "") -eq $(type .\kubectl-convert.exe.sha256)
|
||||
```
|
||||
|
||||
1. Add the binary in to your `PATH`.
|
||||
|
||||
1. Verify plugin is successfully installed
|
||||
|
||||
```shell
|
||||
kubectl convert --help
|
||||
```
|
||||
|
||||
If you do not see an error, it means the plugin is successfully installed.
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
||||
@@ -348,6 +348,11 @@ node with the required profile.
|
||||
|
||||
### Restricting profiles with the PodSecurityPolicy
|
||||
|
||||
{{< 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.
|
||||
{{< /note >}}
|
||||
|
||||
If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To
|
||||
enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:
|
||||
|
||||
|
||||
@@ -37,7 +37,7 @@ weight: 10
|
||||
<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
|
||||
<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>
|
||||
<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
|
||||
<li><i>ExternalName</i> - Maps the Service to the contents of the <code>externalName</code> field (e.g. `foo.bar.example.com`), by returning a <code>CNAME</code> record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of <code>kube-dns</code>, or CoreDNS version 0.0.8 or higher.</li>
|
||||
<li><i>ExternalName</i> - Maps the Service to the contents of the <code>externalName</code> field (e.g. <code>foo.bar.example.com</code>), by returning a <code>CNAME</code> record with its value. No proxying of any kind is set up. This type requires v1.7 or higher of <code>kube-dns</code>, or CoreDNS version 0.0.8 or higher.</li>
|
||||
</ul>
|
||||
<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
|
||||
<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
|
||||
|
||||
@@ -266,7 +266,7 @@ to also be deleted. Never assume you'll be able to access data if its volume cla
|
||||
|
||||
The Pods in this tutorial use the [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile)
|
||||
image from Google's [container registry](https://cloud.google.com/container-registry/docs/).
|
||||
The Docker image above is based on [debian-base](https://github.com/kubernetes/kubernetes/tree/master/build/debian-base)
|
||||
The Docker image above is based on [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)
|
||||
and includes OpenJDK 8.
|
||||
|
||||
This image includes a standard Cassandra installation from the Apache Debian repo.
|
||||
|
||||
@@ -937,7 +937,7 @@ Use [`kubectl drain`](/docs/reference/generated/kubectl/kubectl-commands/#drain)
|
||||
drain the node on which the `zk-0` Pod is scheduled.
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
|
||||
kubectl drain $(kubectl get pod zk-0 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
```
|
||||
@@ -972,7 +972,7 @@ Keep watching the `StatefulSet`'s Pods in the first terminal and drain the node
|
||||
`zk-1` is scheduled.
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data "kubernetes-node-ixsl" cordoned
|
||||
kubectl drain $(kubectl get pod zk-1 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data "kubernetes-node-ixsl" cordoned
|
||||
```
|
||||
|
||||
```
|
||||
@@ -1015,7 +1015,7 @@ Continue to watch the Pods of the stateful set, and drain the node on which
|
||||
`zk-2` is scheduled.
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
|
||||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
```
|
||||
@@ -1101,7 +1101,7 @@ zk-1 1/1 Running 0 13m
|
||||
Attempt to drain the node on which `zk-2` is scheduled.
|
||||
|
||||
```shell
|
||||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-local-data
|
||||
kubectl drain $(kubectl get pod zk-2 --template {{.spec.nodeName}}) --ignore-daemonsets --force --delete-emptydir-data
|
||||
```
|
||||
|
||||
The output:
|
||||
|
||||
Reference in New Issue
Block a user