whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request #28408 from tengqm/fix-links-1

Browse Source 
Fix some links in the tasks section
This commit is contained in:
Kubernetes Prow Robot
2021-06-14 16:24:01 -07:00
committed by GitHub
parent 3d35f770d0 8282ae39a9
commit e5b5f45e7c
4 changed files with 63 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md
+21 -22
View File
@@ -7,7 +7,6 @@ card:
weight: 40 weight: 40
--- ---
<!-- overview --> <!-- overview -->
This page shows how to configure access to multiple clusters by using This page shows how to configure access to multiple clusters by using
@@ -21,20 +20,15 @@ a *kubeconfig file*. This is a generic way of referring to configuration files.
It does not mean that there is a file named `kubeconfig`. It does not mean that there is a file named `kubeconfig`.
{{< /note >}} {{< /note >}}
## {{% heading "prerequisites" %}} ## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< include "task-tutorial-prereqs.md" >}}
To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed, To check that {{< glossary_tooltip text="kubectl" term_id="kubectl" >}} is installed,
run `kubectl version --client`. The kubectl version should be 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. cluster's API server.
<!-- steps --> <!-- steps -->
## Define clusters, users, and contexts ## Define clusters, users, and contexts
@@ -186,7 +180,7 @@ kubectl config --kubeconfig=config-demo view --minify
The output shows configuration information associated with the `dev-frontend` context: The output shows configuration information associated with the `dev-frontend` context:
```shell ```yaml
apiVersion: v1 apiVersion: v1
clusters: clusters:
- cluster: - cluster:
@@ -238,7 +232,6 @@ kubectl config --kubeconfig=config-demo use-context dev-storage
View configuration associated with the new current context, `dev-storage`. View configuration associated with the new current context, `dev-storage`.
```shell ```shell
kubectl config --kubeconfig=config-demo view --minify kubectl config --kubeconfig=config-demo view --minify
``` ```
@@ -247,7 +240,7 @@ kubectl config --kubeconfig=config-demo view --minify
In your `config-exercise` directory, create a file named `config-demo-2` with this content: In your `config-exercise` directory, create a file named `config-demo-2` with this content:
```shell ```yaml
apiVersion: v1 apiVersion: v1
kind: Config kind: Config
preferences: {} preferences: {}
@@ -269,13 +262,17 @@ current value of your `KUBECONFIG` environment variable, so you can restore it l
For example: For example:
### Linux ### Linux
```shell ```shell
export KUBECONFIG_SAVED=$KUBECONFIG export KUBECONFIG_SAVED=$KUBECONFIG
``` ```
### Windows PowerShell ### Windows PowerShell
```shell
```powershell
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG $Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
``` ```
The `KUBECONFIG` environment variable is a list of paths to configuration files. The list is 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 colon-delimited for Linux and Mac, and semicolon-delimited for Windows. If you have
a `KUBECONFIG` environment variable, familiarize yourself with the configuration files a `KUBECONFIG` environment variable, familiarize yourself with the configuration files
@@ -284,11 +281,14 @@ in the list.
Temporarily append two paths to your `KUBECONFIG` environment variable. For example: Temporarily append two paths to your `KUBECONFIG` environment variable. For example:
### Linux ### Linux
```shell ```shell
export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2
``` ```
### Windows PowerShell ### Windows PowerShell
```shell
```powershell
$Env:KUBECONFIG=("config-demo;config-demo-2") $Env:KUBECONFIG=("config-demo;config-demo-2")
``` ```
@@ -303,7 +303,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 `dev-ramp-up` context from the `config-demo-2` file and the three contexts from
the `config-demo` file: the `config-demo` file:
```shell ```yaml
contexts: contexts:
- context: - context:
cluster: development cluster: development
@@ -347,11 +347,14 @@ If you have a `$HOME/.kube/config` file, and it's not already listed in your
For example: For example:
### Linux ### Linux
```shell ```shell
export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
``` ```
### Windows Powershell ### Windows Powershell
```shell
```powershell
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config" $Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"
``` ```
@@ -367,23 +370,19 @@ kubectl config view
Return your `KUBECONFIG` environment variable to its original value. For example:<br> Return your `KUBECONFIG` environment variable to its original value. For example:<br>
### Linux ### Linux
```shell ```shell
export KUBECONFIG=$KUBECONFIG_SAVED export KUBECONFIG=$KUBECONFIG_SAVED
``` ```
### Windows PowerShell ### Windows PowerShell
```shell
```powershell
$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED $Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED
``` ```
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) * [Organizing Cluster Access Using kubeconfig Files](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
* [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config) * [kubectl config](/docs/reference/generated/kubectl/kubectl-commands#config)
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md
+1
View File
@@ -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 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#). 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. Please contact the vendor to get up to date instructions for migrating from dockershim.
content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+29 -37
View File
@@ -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 daemons compete for resources and lead to resource starvation issues on the
node. 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 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. on each node.
## {{% heading "prerequisites" %}} ## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
Your Kubernetes server must be at or later than version 1.17 to use Your Kubernetes server must be at or later than version 1.17 to use
the kubelet command line option `--reserved-cpus` to set an the kubelet command line option `--reserved-cpus` to set an
[explicitly reserved CPU list](#explicitly-reserved-cpu-list). [explicitly reserved CPU list](#explicitly-reserved-cpu-list).
<!-- steps --> <!-- steps -->
## Node Allocatable ## Node Allocatable
![node capacity](/images/docs/node-capacity.svg) ![node capacity](/images/docs/node-capacity.svg)
`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 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 Node Allocatable is exposed as part of `v1.Node` object in the API and as part
of `kubectl describe node` in the CLI. 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 It is recommended that the kubernetes system daemons are placed under a top
level control group (`runtime.slice` on systemd machines for example). Each level control group (`runtime.slice` on systemd machines for example). Each
system daemon should ideally run within its own child control group. Refer to system daemon should ideally run within its own child control group. Refer to
[this [the design proposal](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
doc](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
for more details on recommended control group hierarchy. for more details on recommended control group hierarchy.
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't 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=[cpu=100m][,][memory=100Mi][,][ephemeral-storage=1Gi][,][pid=1000]`
- **Kubelet Flag**: `--system-reserved-cgroup=` - **Kubelet Flag**: `--system-reserved-cgroup=`
`system-reserved` is meant to capture resource reservation for OS system daemons `system-reserved` is meant to capture resource reservation for OS system daemons
like `sshd`, `udev`, etc. `system-reserved` should reserve `memory` for the 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. `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 It is recommended that the OS system daemons are placed under a top level
control group (`system.slice` on systemd machines for example). control group (`system.slice` on systemd machines for example).
Note that Kubelet **does not** create `--system-reserved-cgroup` if it doesn't Note that `kubelet` **does not** create `--system-reserved-cgroup` if it doesn't
exist. Kubelet will fail if an invalid cgroup is specified. exist. `kubelet` will fail if an invalid cgroup is specified.
### Explicitly Reserved CPU List ### Explicitly Reserved CPU List
{{< feature-state for_k8s_version="v1.17" state="stable" >}} {{< 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 `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 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 ### 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 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 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 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 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 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 - 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 eviction-hard`. For this reason, resources reserved for evictions are not
@@ -169,17 +163,17 @@ available for pods.
### Enforcing Node Allocatable ### 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 by evicting pods whenever the overall usage across all pods exceeds
`Allocatable`. More details on eviction policy can be found 'Allocatable'. More details on eviction policy can be found
[here](/docs/tasks/administer-cluster/out-of-resource/#eviction-policy). This enforcement is controlled by 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`. specifying `pods` value to the kubelet flag `--enforce-node-allocatable`.
Optionally, `kubelet` can be made to enforce `kube-reserved` and Optionally, `kubelet` can be made to enforce `kube-reserved` and
`system-reserved` by specifying `kube-reserved` & `system-reserved` values in `system-reserved` by specifying `kube-reserved` & `system-reserved` values in
the same flag. Note that to enforce `kube-reserved` or `system-reserved`, the same flag. Note that to enforce `kube-reserved` or `system-reserved`,
@@ -188,10 +182,10 @@ respectively.
## General Guidelines ## 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 daemons can burst within their bounding control groups and this behavior needs
to be managed as part of kubernetes deployments. For example, `kubelet` should 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 container runtime. However, Kubelet cannot burst and use up all available Node
resources if `kube-reserved` is enforced. 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 to fork on the node. The
recommendation is to enforce `system-reserved` only if a user has profiled their 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 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 * Once adequate monitoring and alerting is in place to track kube system
daemons, attempt to enforce `kube-reserved` based on usage heuristics. daemons, attempt to enforce `kube-reserved` based on usage heuristics.
* If absolutely necessary, enforce `system-reserved` over time. * 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. 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. So expect a drop in `Allocatable` capacity in future releases.
<!-- discussion --> <!-- discussion -->
## Example Scenario ## 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` * `--system-reserved` is set to `cpu=500m,memory=1Gi,ephemeral-storage=1Gi`
* `--eviction-hard` is set to `memory.available<500Mi,nodefs.available<10%` * `--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. `88Gi` of local storage.
Scheduler ensures that the total memory `requests` across all pods on this node does Scheduler ensures that the total memory `requests` across all pods on this node does
not exceed `28.5Gi` and storage doesn't exceed `88Gi`. not exceed 28.5Gi and storage doesn't exceed 88Gi.
Kubelet evicts pods whenever the overall memory usage across pods exceeds `28.5Gi`, 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 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`. 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 If `kube-reserved` and/or `system-reserved` is not enforced and system daemons
exceed their reservation, `kubelet` evicts pods whenever the overall node memory 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.
content/en/docs/tasks/manage-daemon/update-daemon-set.md
+12 -17
View File
@@ -7,35 +7,36 @@ weight: 10
--- ---
<!-- overview --> <!-- overview -->
This page shows how to perform a rolling update on a DaemonSet. This page shows how to perform a rolling update on a DaemonSet.
## {{% heading "prerequisites" %}} ## {{% heading "prerequisites" %}}
* The DaemonSet rolling update feature is only supported in Kubernetes version 1.6 or later.
<!-- steps --> <!-- steps -->
## DaemonSet Update Strategy ## DaemonSet Update Strategy
DaemonSet has two update strategy types: 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 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 pods. This is the same behavior of DaemonSet in Kubernetes version 1.5 or
before. before.
* RollingUpdate: This is the default update strategy. * `RollingUpdate`: This is the default update strategy.
With `RollingUpdate` update strategy, after you update a With `RollingUpdate` update strategy, after you update a
DaemonSet template, old DaemonSet pods will be killed, and new DaemonSet pods 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 ## Performing a Rolling Update
To enable the rolling update feature of a DaemonSet, you must set its To enable the rolling update feature of a DaemonSet, you must set its
`.spec.updateStrategy.type` to `RollingUpdate`. `.spec.updateStrategy.type` to `RollingUpdate`.
You may want to set [`.spec.updateStrategy.rollingUpdate.maxUnavailable`](/docs/concepts/workloads/controllers/deployment/#max-unavailable) (default You may want to set
to 1) and [`.spec.minReadySeconds`](/docs/concepts/workloads/controllers/deployment/#min-ready-seconds) (default to 0) as well. [`.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 ### 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 The rollout is stuck because new DaemonSet pods can't be scheduled on at least one
node. This is possible when the node is 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 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: 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 kubectl delete ds fluentd-elasticsearch -n kube-system
``` ```
## {{% heading "whatsnext" %}} ## {{% heading "whatsnext" %}}
* See [Performing a rollback on a DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
* See [Task: Performing a rollback on a * See [Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)
DaemonSet](/docs/tasks/manage-daemon/rollback-daemon-set/)
* See [Concepts: Creating a DaemonSet to adopt existing DaemonSet pods](/docs/concepts/workloads/controllers/daemonset/)