Merge master into dev-1.22 to keep in sync.
This commit is contained in:
Victor Palade
Executable → Regular
+26
-20
@@ -7,7 +7,6 @@ card:
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to configure access to multiple clusters by using
|
||||
@@ -22,19 +21,21 @@ It does not mean that there is a file named `kubeconfig`.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
{{< warning >}}
|
||||
Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure.
|
||||
If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script.
|
||||
{{< /warning>}}
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed,
|
||||
run `kubectl version --client`. The kubectl version should be
|
||||
[within one minor version](/docs/setup/release/version-skew-policy/#kubectl) of your
|
||||
[within one minor version](/releases/version-skew-policy/#kubectl) of your
|
||||
cluster's API server.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Define clusters, users, and contexts
|
||||
@@ -186,7 +187,7 @@ kubectl config --kubeconfig=config-demo view --minify
|
||||
|
||||
The output shows configuration information associated with the `dev-frontend` context:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
clusters:
|
||||
- cluster:
|
||||
@@ -238,7 +239,6 @@ kubectl config --kubeconfig=config-demo use-context dev-storage
|
||||
|
||||
View configuration associated with the new current context, `dev-storage`.
|
||||
|
||||
|
||||
```shell
|
||||
kubectl config --kubeconfig=config-demo view --minify
|
||||
```
|
||||
@@ -247,7 +247,7 @@ kubectl config --kubeconfig=config-demo view --minify
|
||||
|
||||
In your `config-exercise` directory, create a file named `config-demo-2` with this content:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: Config
|
||||
preferences: {}
|
||||
@@ -269,13 +269,17 @@ current value of your `KUBECONFIG` environment variable, so you can restore it l
|
||||
For example:
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG_SAVED=$KUBECONFIG
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
|
||||
```
|
||||
|
||||
The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is
|
||||
colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have
|
||||
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
|
||||
@@ -284,11 +288,14 @@ in the list.
|
||||
Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG=("config-demo;config-demo-2")
|
||||
```
|
||||
|
||||
@@ -303,7 +310,7 @@ environment variable. In particular, notice that the merged information has the
|
||||
`dev-ramp-up` context from the `config-demo-2` file and the three contexts from
|
||||
the `config-demo` file:
|
||||
|
||||
```shell
|
||||
```yaml
|
||||
contexts:
|
||||
- context:
|
||||
cluster: development
|
||||
@@ -347,11 +354,14 @@ If you have a `$HOME/.kube/config` file, and it's not already listed in your
|
||||
For example:
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
|
||||
```
|
||||
|
||||
### Windows Powershell
|
||||
```shell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
|
||||
```
|
||||
|
||||
@@ -367,23 +377,19 @@ kubectl config view
|
||||
Return your `KUBECONFIG` environment variable to its original value. For example:<br>
|
||||
|
||||
### Linux
|
||||
|
||||
```shell
|
||||
export KUBECONFIG=$KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
### Windows PowerShell
|
||||
```shell
|
||||
|
||||
```powershell
|
||||
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
|
||||
```
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Executable → Regular
Executable → Regular
@@ -85,7 +85,11 @@ Additionally, kubeadm informs the user if the certificate is externally managed;
|
||||
{{< /warning >}}
|
||||
|
||||
{{< note >}}
|
||||
`kubelet.conf` is not included in the list above because kubeadm configures kubelet for automatic certificate renewal.
|
||||
`kubelet.conf` is not included in the list above because kubeadm configures kubelet
|
||||
for [automatic certificate renewal](/docs/tasks/tls/certificate-rotation/)
|
||||
with rotatable certificates under `/var/lib/kubelet/pki`.
|
||||
To repair an expired kubelet client certificate see
|
||||
[Kubelet client certificate rotation fails](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/#kubelet-client-cert).
|
||||
{{< /note >}}
|
||||
|
||||
{{< warning >}}
|
||||
@@ -142,7 +146,7 @@ The Kubernetes certificates normally reach their expiration date after one year.
|
||||
|
||||
## Renew certificates with the Kubernetes certificates API
|
||||
|
||||
This section provide more details about how to execute manual certificate renewal using the Kubernetes certificates API.
|
||||
This section provides more details about how to execute manual certificate renewal using the Kubernetes certificates API.
|
||||
|
||||
{{< caution >}}
|
||||
These are advanced topics for users who need to integrate their organization's certificate infrastructure into a kubeadm-built cluster. If the default kubeadm configuration satisfies your needs, you should let kubeadm manage certificates instead.
|
||||
|
||||
@@ -51,7 +51,7 @@ The Memory Manager updates the Node Map during the startup and runtime as follow
|
||||
|
||||
This occurs once a node administrator employs `--reserved-memory` (section [Reserved memory flag](#reserved-memory-flag)). In this case, the Node Map becomes updated to reflect this reservation as illustrated in [Memory Manager KEP: Memory Maps at start-up (with examples)][5].
|
||||
|
||||
The administrator must provide `--reserved-memory` flag when `static` policy is configured.
|
||||
The administrator must provide `--reserved-memory` flag when `Static` policy is configured.
|
||||
|
||||
### Runtime
|
||||
|
||||
@@ -61,7 +61,7 @@ Important topic in the context of Memory Manager operation is the management of
|
||||
|
||||
## Memory Manager configuration
|
||||
|
||||
Other Managers should be first pre-configured (section [Pre-configuration](#pre-configuration)). Next, the Memory Manger feature should be enabled (section [Enable the Memory Manager feature](#enable-the-memory-manager-feature)) and be run with `static` policy (section [static policy](#static-policy)). Optionally, some amount of memory can be reserved for system or kubelet processes to increase node stability (section [Reserved memory flag](#reserved-memory-flag)).
|
||||
Other Managers should be first pre-configured (section [Pre-configuration](#pre-configuration)). Next, the Memory Manger feature should be enabled (section [Enable the Memory Manager feature](#enable-the-memory-manager-feature)) and be run with `Static` policy (section [Static policy](#static-policy)). Optionally, some amount of memory can be reserved for system or kubelet processes to increase node stability (section [Reserved memory flag](#reserved-memory-flag)).
|
||||
|
||||
### Policies
|
||||
|
||||
@@ -69,21 +69,21 @@ Memory Manager supports two policies. You can select a policy via a `kubelet` fl
|
||||
|
||||
Two policies can be selected:
|
||||
|
||||
* `none` (default)
|
||||
* `static`
|
||||
* `None` (default)
|
||||
* `Static`
|
||||
|
||||
#### none policy {#policy-none}
|
||||
#### None policy {#policy-none}
|
||||
|
||||
This is the default policy and does not affect the memory allocation in any way.
|
||||
It acts the same as if the Memory Manager is not present at all.
|
||||
|
||||
The `none` policy returns default topology hint. This special hint denotes that Hint Provider (Memory Manger in this case) has no preference for NUMA affinity with any resource.
|
||||
The `None` policy returns default topology hint. This special hint denotes that Hint Provider (Memory Manger in this case) has no preference for NUMA affinity with any resource.
|
||||
|
||||
#### static policy {#policy-static}
|
||||
#### Static policy {#policy-static}
|
||||
|
||||
In the case of the `Guaranteed` pod, the `static` Memory Manger policy returns topology hints relating to the set of NUMA nodes where the memory can be guaranteed, and reserves the memory through updating the internal [NodeMap][2] object.
|
||||
In the case of the `Guaranteed` pod, the `Static` Memory Manger policy returns topology hints relating to the set of NUMA nodes where the memory can be guaranteed, and reserves the memory through updating the internal [NodeMap][2] object.
|
||||
|
||||
In the case of the `BestEffort` or `Burstable` pod, the `static` Memory Manager policy sends back the default topology hint as there is no request for the guaranteed memory, and does not reserve the memory in the internal [NodeMap][2] object.
|
||||
In the case of the `BestEffort` or `Burstable` pod, the `Static` Memory Manager policy sends back the default topology hint as there is no request for the guaranteed memory, and does not reserve the memory in the internal [NodeMap][2] object.
|
||||
|
||||
### Reserved memory flag
|
||||
|
||||
@@ -100,7 +100,7 @@ The Memory Manager will not use this reserved memory for the allocation of conta
|
||||
|
||||
For example, if you have a NUMA node "NUMA0" with `10Gi` of memory available, and the `--reserved-memory` was specified to reserve `1Gi` of memory at "NUMA0", the Memory Manager assumes that only `9Gi` is available for containers.
|
||||
|
||||
You can omit this parameter, however, you should be aware that the quantity of reserved memory from all NUMA nodes should be equal to the quantity of memory specified by the [Node Allocatable feature](/docs/tasks/administer-cluster/reserve-compute-resources/). If at least one node allocatable parameter is non-zero, you will need to specify `--reserved-memory` for at least one NUMA node. In fact, `eviction-hard` threshold value is equal to `100Mi` by default, so if `static` policy is used, `--reserved-memory` is obligatory.
|
||||
You can omit this parameter, however, you should be aware that the quantity of reserved memory from all NUMA nodes should be equal to the quantity of memory specified by the [Node Allocatable feature](/docs/tasks/administer-cluster/reserve-compute-resources/). If at least one node allocatable parameter is non-zero, you will need to specify `--reserved-memory` for at least one NUMA node. In fact, `eviction-hard` threshold value is equal to `100Mi` by default, so if `Static` policy is used, `--reserved-memory` is obligatory.
|
||||
|
||||
Also, avoid the following configurations:
|
||||
1. duplicates, i.e. the same NUMA node or memory type, but with a different value;
|
||||
@@ -152,7 +152,7 @@ Here is an example of a correct configuration:
|
||||
--feature-gates=MemoryManager=true
|
||||
--kube-reserved=cpu=4,memory=4Gi
|
||||
--system-reserved=cpu=1,memory=1Gi
|
||||
--memory-manager-policy=static
|
||||
--memory-manager-policy=Static
|
||||
--reserved-memory 0:memory=3Gi --reserved-memory 1:memory=2148Mi
|
||||
```
|
||||
Let us validate the configuration above:
|
||||
@@ -163,7 +163,7 @@ Let us validate the configuration above:
|
||||
|
||||
## Placing a Pod in the Guaranteed QoS class
|
||||
|
||||
If the selected policy is anything other than `none`, the Memory Manager identifies pods that are in the `Guaranteed` QoS class. The Memory Manager provides specific topology hints to the Topology Manager for each `Guaranteed` pod. For pods in a QoS class other than `Guaranteed`, the Memory Manager provides default topology hints to the Topology Manager.
|
||||
If the selected policy is anything other than `None`, the Memory Manager identifies pods that are in the `Guaranteed` QoS class. The Memory Manager provides specific topology hints to the Topology Manager for each `Guaranteed` pod. For pods in a QoS class other than `Guaranteed`, the Memory Manager provides default topology hints to the Topology Manager.
|
||||
|
||||
The following excerpts from pod manifests assign a pod to the `Guaranteed` QoS class.
|
||||
|
||||
@@ -270,7 +270,7 @@ spec:
|
||||
Next, let us log into the node where it was deployed and examine the state file in `/var/lib/kubelet/memory_manager_state`:
|
||||
```json
|
||||
{
|
||||
"policyName":"static",
|
||||
"policyName":"Static",
|
||||
"machineState":{
|
||||
"0":{
|
||||
"numberOfAssignments":1,
|
||||
|
||||
Executable → Regular
+1
@@ -78,3 +78,4 @@ telemetry agents on the node, make sure to check with the vendor of the agent wh
|
||||
We keep the work in progress version of migration instructions for various telemetry and security agent vendors
|
||||
in [Google doc](https://docs.google.com/document/d/1ZFi4uKit63ga5sxEiZblfb-c23lFhvy6RXVPikS8wf0/edit#).
|
||||
Please contact the vendor to get up to date instructions for migrating from dockershim.
|
||||
|
||||
|
||||
@@ -17,33 +17,27 @@ itself. Unless resources are set aside for these system daemons, pods and system
|
||||
daemons compete for resources and lead to resource starvation issues on the
|
||||
node.
|
||||
|
||||
The `kubelet` exposes a feature named `Node Allocatable` that helps to reserve
|
||||
The `kubelet` exposes a feature named 'Node Allocatable' that helps to reserve
|
||||
compute resources for system daemons. Kubernetes recommends cluster
|
||||
administrators to configure `Node Allocatable` based on their workload density
|
||||
administrators to configure 'Node Allocatable' based on their workload density
|
||||
on each node.
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
|
||||
Your Kubernetes server must be at or later than version 1.17 to use
|
||||
the kubelet command line option `--reserved-cpus` to set an
|
||||
[explicitly reserved CPU list](#explicitly-reserved-cpu-list).
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## Node Allocatable
|
||||
|
||||
|
||||
|
||||
`Allocatable` on a Kubernetes node is defined as the amount of compute resources
|
||||
'Allocatable' on a Kubernetes node is defined as the amount of compute resources
|
||||
that are available for pods. The scheduler does not over-subscribe
|
||||
`Allocatable`. `CPU`, `memory` and `ephemeral-storage` are supported as of now.
|
||||
'Allocatable'. 'CPU', 'memory' and 'ephemeral-storage' are supported as of now.
|
||||
|
||||
Node Allocatable is exposed as part of `v1.Node` object in the API and as part
|
||||
of `kubectl describe node` in the CLI.
|
||||
@@ -97,8 +91,7 @@ flag.
|
||||
It is recommended that the kubernetes system daemons are placed under a top
|
||||
level control group (`runtime.slice` on systemd machines for example). Each
|
||||
system daemon should ideally run within its own child control group. Refer to
|
||||
[this
|
||||
doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
|
||||
[the design proposal](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
|
||||
for more details on recommended control group hierarchy.
|
||||
|
||||
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
|
||||
@@ -109,7 +102,6 @@ exist. Kubelet will fail if an invalid cgroup is specified.
|
||||
- **Kubelet Flag**: `--system-reserved=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
|
||||
- **Kubelet Flag**: `--system-reserved-cgroup=`
|
||||
|
||||
|
||||
`system-reserved` is meant to capture resource reservation for OS system daemons
|
||||
like `sshd`, `udev`, etc. `system-reserved` should reserve `memory` for the
|
||||
`kernel` too since `kernel` memory is not accounted to pods in Kubernetes at this time.
|
||||
@@ -127,13 +119,14 @@ kubelet flag.
|
||||
It is recommended that the OS system daemons are placed under a top level
|
||||
control group (`system.slice` on systemd machines for example).
|
||||
|
||||
Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't
|
||||
exist. Kubelet will fail if an invalid cgroup is specified.
|
||||
Note that `kubelet` **does not** create `--system-reserved-cgroup` if it doesn't
|
||||
exist. `kubelet` will fail if an invalid cgroup is specified.
|
||||
|
||||
### Explicitly Reserved CPU List
|
||||
|
||||
{{< feature-state for_k8s_version="v1.17" state="stable" >}}
|
||||
|
||||
- **Kubelet Flag**: `--reserved-cpus=0-3`
|
||||
**Kubelet Flag**: `--reserved-cpus=0-3`
|
||||
|
||||
`reserved-cpus` is meant to define an explicit CPU set for OS system daemons and
|
||||
kubernetes system daemons. `reserved-cpus` is for systems that do not intend to
|
||||
@@ -154,14 +147,15 @@ For example: in Centos, you can do this using the tuned toolset.
|
||||
|
||||
### Eviction Thresholds
|
||||
|
||||
- **Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]`
|
||||
**Kubelet Flag**: `--eviction-hard=[memory.available<500Mi]`
|
||||
|
||||
Memory pressure at the node level leads to System OOMs which affects the entire
|
||||
node and all pods running on it. Nodes can go offline temporarily until memory
|
||||
has been reclaimed. To avoid (or reduce the probability of) system OOMs kubelet
|
||||
provides [`Out of Resource`](/docs/tasks/administer-cluster/out-of-resource/) management. Evictions are
|
||||
provides [out of resource](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
|
||||
management. Evictions are
|
||||
supported for `memory` and `ephemeral-storage` only. By reserving some memory via
|
||||
`--eviction-hard` flag, the `kubelet` attempts to `evict` pods whenever memory
|
||||
`--eviction-hard` flag, the `kubelet` attempts to evict pods whenever memory
|
||||
availability on the node drops below the reserved value. Hypothetically, if
|
||||
system daemons did not exist on a node, pods cannot use more than `capacity -
|
||||
eviction-hard`. For this reason, resources reserved for evictions are not
|
||||
@@ -169,17 +163,17 @@ available for pods.
|
||||
|
||||
### Enforcing Node Allocatable
|
||||
|
||||
- **Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
|
||||
**Kubelet Flag**: `--enforce-node-allocatable=pods[,][system-reserved][,][kube-reserved]`
|
||||
|
||||
The scheduler treats `Allocatable` as the available `capacity` for pods.
|
||||
The scheduler treats 'Allocatable' as the available `capacity` for pods.
|
||||
|
||||
`kubelet` enforce `Allocatable` across pods by default. Enforcement is performed
|
||||
`kubelet` enforce 'Allocatable' across pods by default. Enforcement is performed
|
||||
by evicting pods whenever the overall usage across all pods exceeds
|
||||
`Allocatable`. More details on eviction policy can be found
|
||||
[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by
|
||||
'Allocatable'. More details on eviction policy can be found
|
||||
on the [node pressure eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/)
|
||||
page. This enforcement is controlled by
|
||||
specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
|
||||
|
||||
|
||||
Optionally, `kubelet` can be made to enforce `kube-reserved` and
|
||||
`system-reserved` by specifying `kube-reserved` & `system-reserved` values in
|
||||
the same flag. Note that to enforce `kube-reserved` or `system-reserved`,
|
||||
@@ -188,10 +182,10 @@ respectively.
|
||||
|
||||
## General Guidelines
|
||||
|
||||
System daemons are expected to be treated similar to `Guaranteed` pods. System
|
||||
System daemons are expected to be treated similar to 'Guaranteed' pods. System
|
||||
daemons can burst within their bounding control groups and this behavior needs
|
||||
to be managed as part of kubernetes deployments. For example, `kubelet` should
|
||||
have its own control group and share `Kube-reserved` resources with the
|
||||
have its own control group and share `kube-reserved` resources with the
|
||||
container runtime. However, Kubelet cannot burst and use up all available Node
|
||||
resources if `kube-reserved` is enforced.
|
||||
|
||||
@@ -200,9 +194,9 @@ to critical system services being CPU starved, OOM killed, or unable
|
||||
to fork on the node. The
|
||||
recommendation is to enforce `system-reserved` only if a user has profiled their
|
||||
nodes exhaustively to come up with precise estimates and is confident in their
|
||||
ability to recover if any process in that group is oom_killed.
|
||||
ability to recover if any process in that group is oom-killed.
|
||||
|
||||
* To begin with enforce `Allocatable` on `pods`.
|
||||
* To begin with enforce 'Allocatable' on `pods`.
|
||||
* Once adequate monitoring and alerting is in place to track kube system
|
||||
daemons, attempt to enforce `kube-reserved` based on usage heuristics.
|
||||
* If absolutely necessary, enforce `system-reserved` over time.
|
||||
@@ -212,8 +206,6 @@ more features are added. Over time, kubernetes project will attempt to bring
|
||||
down utilization of node system daemons, but that is not a priority as of now.
|
||||
So expect a drop in `Allocatable` capacity in future releases.
|
||||
|
||||
|
||||
|
||||
<!-- discussion -->
|
||||
|
||||
## Example Scenario
|
||||
@@ -225,15 +217,15 @@ Here is an example to illustrate Node Allocatable computation:
|
||||
* `--system-reserved` is set to `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
|
||||
* `--eviction-hard` is set to `memory.available<500Mi,nodefs.available<10%`
|
||||
|
||||
Under this scenario, `Allocatable` will be `14.5 CPUs`, `28.5Gi` of memory and
|
||||
Under this scenario, 'Allocatable' will be 14.5 CPUs, 28.5Gi of memory and
|
||||
`88Gi` of local storage.
|
||||
Scheduler ensures that the total memory `requests` across all pods on this node does
|
||||
not exceed `28.5Gi` and storage doesn't exceed `88Gi`.
|
||||
Kubelet evicts pods whenever the overall memory usage across pods exceeds `28.5Gi`,
|
||||
or if overall disk usage exceeds `88Gi` If all processes on the node consume as
|
||||
much CPU as they can, pods together cannot consume more than `14.5 CPUs`.
|
||||
not exceed 28.5Gi and storage doesn't exceed 88Gi.
|
||||
Kubelet evicts pods whenever the overall memory usage across pods exceeds 28.5Gi,
|
||||
or if overall disk usage exceeds 88Gi If all processes on the node consume as
|
||||
much CPU as they can, pods together cannot consume more than 14.5 CPUs.
|
||||
|
||||
If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
|
||||
exceed their reservation, `kubelet` evicts pods whenever the overall node memory
|
||||
usage is higher than `31.5Gi` or `storage` is greater than `90Gi`
|
||||
usage is higher than 31.5Gi or `storage` is greater than 90Gi.
|
||||
|
||||
|
||||
Executable → Regular
Executable → Regular
Executable → Regular
@@ -41,7 +41,7 @@ the container starts.
|
||||
|
||||
kubectl apply -f https://k8s.io/examples/debug/termination.yaml
|
||||
|
||||
In the YAML file, in the `cmd` and `args` fields, you can see that the
|
||||
In the YAML file, in the `command` and `args` fields, you can see that the
|
||||
container sleeps for 10 seconds and then writes "Sleep expired" to
|
||||
the `/dev/termination-log` file. After the container writes
|
||||
the "Sleep expired" message, it terminates.
|
||||
|
||||
Executable → Regular
Executable → Regular
Executable → Regular
@@ -7,35 +7,36 @@ weight: 10
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
||||
This page shows how to perform a rolling update on a DaemonSet.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
* The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## DaemonSet Update Strategy
|
||||
|
||||
DaemonSet has two update strategy types:
|
||||
|
||||
* OnDelete: With `OnDelete` update strategy, after you update a DaemonSet template, new
|
||||
* `OnDelete`: With `OnDelete` update strategy, after you update a DaemonSet template, new
|
||||
DaemonSet pods will *only* be created when you manually delete old DaemonSet
|
||||
pods. This is the same behavior of DaemonSet in Kubernetes version 1.5 or
|
||||
before.
|
||||
* RollingUpdate: This is the default update strategy.
|
||||
* `RollingUpdate`: This is the default update strategy.
|
||||
With `RollingUpdate` update strategy, after you update a
|
||||
DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods
|
||||
will be created automatically, in a controlled fashion. At most one pod of the DaemonSet will be running on each node during the whole update process.
|
||||
will be created automatically, in a controlled fashion. At most one pod of
|
||||
the DaemonSet will be running on each node during the whole update process.
|
||||
|
||||
## Performing a Rolling Update
|
||||
|
||||
To enable the rolling update feature of a DaemonSet, you must set its
|
||||
`.spec.updateStrategy.type` to `RollingUpdate`.
|
||||
|
||||
You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default
|
||||
to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well.
|
||||
You may want to set
|
||||
[`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable)
|
||||
(default to 1) and
|
||||
[`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds)
|
||||
(default to 0) as well.
|
||||
|
||||
### Creating a DaemonSet with `RollingUpdate` update strategy
|
||||
|
||||
@@ -143,7 +144,7 @@ causes:
|
||||
|
||||
The rollout is stuck because new DaemonSet pods can't be scheduled on at least one
|
||||
node. This is possible when the node is
|
||||
[running out of resources](/docs/tasks/administer-cluster/out-of-resource/).
|
||||
[running out of resources](/docs/concepts/scheduling-eviction/node-pressure-eviction/).
|
||||
|
||||
When this happens, find the nodes that don't have the DaemonSet pods scheduled on
|
||||
by comparing the output of `kubectl get nodes` and the output of:
|
||||
@@ -184,14 +185,8 @@ Delete DaemonSet from a namespace :
|
||||
kubectl delete ds fluentd-elasticsearch -n kube-system
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* See [Task: Performing a rollback on a
|
||||
DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
|
||||
* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
|
||||
|
||||
* 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/)
|
||||
|
||||
|
||||
Executable → Regular
Executable → Regular
Executable → Regular
Executable → Regular
@@ -27,8 +27,8 @@ The kubelet uses certificates for authenticating to the Kubernetes API. By
|
||||
default, these certificates are issued with one year expiration so that they do
|
||||
not need to be renewed too frequently.
|
||||
|
||||
Kubernetes 1.8 contains [kubelet certificate
|
||||
rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/), a beta feature
|
||||
Kubernetes contains [kubelet certificate
|
||||
rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/),
|
||||
that will automatically generate a new key and request a new certificate from
|
||||
the Kubernetes API as the current certificate approaches expiration. Once the
|
||||
new certificate is available, it will be used for authenticating connections to
|
||||
@@ -62,7 +62,7 @@ criteria, it will be auto approved by the controller manager, then it will have
|
||||
a status of `Approved`. Next, the controller manager will sign a certificate,
|
||||
issued for the duration specified by the
|
||||
`--cluster-signing-duration` parameter, and the signed certificate
|
||||
will be attached to the certificate signing requests.
|
||||
will be attached to the certificate signing request.
|
||||
|
||||
The kubelet will retrieve the signed certificate from the Kubernetes API and
|
||||
write that to disk, in the location specified by `--cert-dir`. Then the kubelet
|
||||
|
||||
Executable → Regular
@@ -1,21 +0,0 @@
|
||||
---
|
||||
title: "gcloud kubectl install"
|
||||
description: "How to install kubectl with gcloud snippet for inclusion in each OS-specific tab."
|
||||
headless: true
|
||||
---
|
||||
|
||||
You can install kubectl as part of the Google Cloud SDK.
|
||||
|
||||
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/).
|
||||
|
||||
1. Run the `kubectl` installation command:
|
||||
|
||||
```shell
|
||||
gcloud components install kubectl
|
||||
```
|
||||
|
||||
1. Test to ensure the version you installed is up-to-date:
|
||||
|
||||
```shell
|
||||
kubectl version --client
|
||||
```
|
||||
@@ -22,7 +22,6 @@ The following methods exist for installing kubectl on Linux:
|
||||
- [Install kubectl binary with curl on Linux](#install-kubectl-binary-with-curl-on-linux)
|
||||
- [Install using native package management](#install-using-native-package-management)
|
||||
- [Install using other package management](#install-using-other-package-management)
|
||||
- [Install on Linux as part of the Google Cloud SDK](#install-on-linux-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
### Install kubectl binary with curl on Linux
|
||||
|
||||
@@ -168,10 +167,6 @@ kubectl version --client
|
||||
|
||||
{{< /tabs >}}
|
||||
|
||||
### Install on Linux as part of the Google Cloud SDK
|
||||
|
||||
{{< include "included/install-kubectl-gcloud.md" >}}
|
||||
|
||||
## Verify kubectl configuration
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
@@ -22,7 +22,6 @@ The following methods exist for installing kubectl on macOS:
|
||||
- [Install kubectl binary with curl on macOS](#install-kubectl-binary-with-curl-on-macos)
|
||||
- [Install with Homebrew on macOS](#install-with-homebrew-on-macos)
|
||||
- [Install with Macports on macOS](#install-with-macports-on-macos)
|
||||
- [Install on macOS as part of the Google Cloud SDK](#install-on-macos-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
### Install kubectl binary with curl on macOS
|
||||
|
||||
@@ -31,7 +30,6 @@ The following methods exist for installing kubectl on macOS:
|
||||
{{< tabs name="download_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"
|
||||
chmod +x kubectl
|
||||
{{< /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"
|
||||
@@ -104,6 +102,10 @@ The following methods exist for installing kubectl on macOS:
|
||||
sudo chown root: /usr/local/bin/kubectl
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
Make sure `/usr/local/bin` is in your PATH environment variable.
|
||||
{{< /note >}}
|
||||
|
||||
1. Test to ensure the version you installed is up-to-date:
|
||||
|
||||
```bash
|
||||
@@ -149,11 +151,6 @@ If you are on macOS and using [Macports](https://macports.org/) package manager,
|
||||
kubectl version --client
|
||||
```
|
||||
|
||||
|
||||
### Install on macOS as part of the Google Cloud SDK
|
||||
|
||||
{{< include "included/install-kubectl-gcloud.md" >}}
|
||||
|
||||
## Verify kubectl configuration
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
|
||||
@@ -21,7 +21,6 @@ The following methods exist for installing kubectl on Windows:
|
||||
|
||||
- [Install kubectl binary with curl on Windows](#install-kubectl-binary-with-curl-on-windows)
|
||||
- [Install on Windows using Chocolatey or Scoop](#install-on-windows-using-chocolatey-or-scoop)
|
||||
- [Install on Windows as part of the Google Cloud SDK](#install-on-windows-as-part-of-the-google-cloud-sdk)
|
||||
|
||||
|
||||
### Install kubectl binary with curl on Windows
|
||||
@@ -127,10 +126,6 @@ If you have installed Docker Desktop before, you may need to place your `PATH` e
|
||||
Edit the config file with a text editor of your choice, such as Notepad.
|
||||
{{< /note >}}
|
||||
|
||||
### Install on Windows as part of the Google Cloud SDK
|
||||
|
||||
{{< include "included/install-kubectl-gcloud.md" >}}
|
||||
|
||||
## Verify kubectl configuration
|
||||
|
||||
{{< include "included/verify-kubectl.md" >}}
|
||||
@@ -147,4 +142,4 @@ Below are the procedures to set up autocompletion for Zsh, if you are running th
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
{{< include "included/kubectl-whats-next.md" >}}
|
||||
|
||||
Reference in New Issue
Block a user