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

Merge master into dev-1.21 to keep in sync, plus latest API reference

Browse Source 
This sync merge includes API reference updates.
This commit is contained in:
Tim Bannister
2021-04-06 20:53:30 +01:00
parent 8dbf6671db d2bf43be4d 41f8e9da78
commit 965aa51daf
266 changed files with 72690 additions and 4933 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md
+2 -2
View File
@@ -283,14 +283,14 @@ volume.
We can also take the snapshot using various options given by etcdctl. For example
```shell
ETCDCTL_API=3 etcdctl --h
ETCDCTL_API=3 etcdctl -h
```
will list various options available from etcdctl. For example, you can take a snapshot by specifying
the endpoint, certificates etc as shown below:
```shell
ETCDCTL_API=3 etcdctl --endpoints=[127.0.0.1:2379] \
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 \
--cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> \
snapshot save <backup-file-location>
```
content/en/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes.md
+4 -2
View File
@@ -1,7 +1,9 @@
---
reviewers:
- michmike
- patricklang
- jayunit100
- jsturtevant
- marosset
- perithompson
title: Adding Windows nodes
min-kubernetes-server-version: 1.17
content_type: tutorial
content/en/docs/tasks/administer-cluster/kubelet-config-file.md
+12 -16
View File
@@ -7,31 +7,21 @@ content_type: task
---
<!-- overview -->
{{< feature-state for_k8s_version="v1.10" state="beta" >}}
A subset of the Kubelet's configuration parameters may be
set via an on-disk config file, as a substitute for command-line flags.
This functionality is considered beta in v1.10.
Providing parameters via a config file is the recommended approach because
it simplifies node deployment and configuration management.
## {{% heading "prerequisites" %}}
- A v1.10 or higher Kubelet binary must be installed for beta functionality.
<!-- steps -->
## Create the config file
The subset of the Kubelet's configuration that can be configured via a file
is defined by the `KubeletConfiguration` struct
[here (v1beta1)](https://github.com/kubernetes/kubernetes/blob/{{< param "docsbranch" >}}/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
is defined by the
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
struct.
The configuration file must be a JSON or YAML representation of the parameters
in this struct. Make sure the Kubelet has read permissions on the file.
@@ -53,6 +43,11 @@ For a trick to generate a configuration file from a live node, see
## Start a Kubelet process configured via the config file
{{< note >}}
If you use kubeadm to initialize your cluster, use the kubelet-config while creating your cluster with `kubeadmin init`.
See [configuring kubelet using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/) for details.
{{< /note >}}
Start the Kubelet with the `--config` flag set to the path of the Kubelet's config file.
The Kubelet will then load its config from this file.
@@ -68,8 +63,6 @@ If `--config` is provided and the values are not specified via the command line,
defaults for the `KubeletConfiguration` version apply.
In the above example, this version is `kubelet.config.k8s.io/v1beta1`.
<!-- discussion -->
## Relationship to Dynamic Kubelet Config
@@ -78,6 +71,9 @@ If you are using the [Dynamic Kubelet Configuration](/docs/tasks/administer-clus
feature, the combination of configuration provided via `--config` and any flags which override these values
is considered the default "last known good" configuration by the automatic rollback mechanism.
## {{% heading "whatsnext" %}}
- Learn more about kubelet configuration by checking the
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
reference.
content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md
+24 -22
View File
@@ -22,8 +22,8 @@ but this is unsafe for some parameters. Before deciding to change a parameter
dynamically, you need a strong understanding of how that change will affect your
cluster's behavior. Always carefully test configuration changes on a small set
of nodes before rolling them out cluster-wide. Advice on configuring specific
fields is available in the inline `KubeletConfiguration`
[type documentation (for v1.20)](https://github.com/kubernetes/kubernetes/blob/release-1.20/staging/src/k8s.io/kubelet/config/v1beta1/types.go).
fields is available in the inline
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/).
{{< /warning >}}
@@ -55,7 +55,7 @@ For each node that you're reconfiguring, you must set the kubelet
The basic workflow for configuring a kubelet in a live cluster is as follows:
1. Write a YAML or JSON configuration file containing the
kubelet's configuration.
kubelet's configuration.
2. Wrap this file in a ConfigMap and save it to the Kubernetes control plane.
3. Update the kubelet's corresponding Node object to use this ConfigMap.
@@ -135,24 +135,24 @@ To follow the tasks as written, you need to have `jq` installed. You can
adapt the steps if you prefer to extract the `kubeletconfig` subobject manually.
{{< /note >}}
1. Choose a Node to reconfigure. In this example, the name of this Node is
referred to as `NODE_NAME`.
2. Start the kubectl proxy in the background using the following command:
1. Choose a Node to reconfigure. In this example, the name of this Node is
referred to as `NODE_NAME`.
2. Start the kubectl proxy in the background using the following command:
```bash
kubectl proxy --port=8001 &
```
3. Run the following command to download and unpack the configuration from the
`configz` endpoint. The command is long, so be careful when copying and
pasting. **If you use zsh**, note that common zsh configurations add backslashes
to escape the opening and closing curly braces around the variable name in the URL.
For example: `${NODE_NAME}` will be rewritten as `$\{NODE_NAME\}` during the paste.
You must remove the backslashes before running the command, or the command will fail.
```shell
kubectl proxy --port=8001 &
```
3. Run the following command to download and unpack the configuration from the
`configz` endpoint. The command is long, so be careful when copying and
pasting. **If you use zsh**, note that common zsh configurations add backslashes
to escape the opening and closing curly braces around the variable name in the URL.
For example: `${NODE_NAME}` will be rewritten as `$\{NODE_NAME\}` during the paste.
You must remove the backslashes before running the command, or the command will fail.
```bash
NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
```
```bash
NODE_NAME="the-name-of-the-node-you-are-reconfiguring"; curl -sSL "http://localhost:8001/api/v1/nodes/${NODE_NAME}/proxy/configz" | jq '.kubeletconfig|.kind="KubeletConfiguration"|.apiVersion="kubelet.config.k8s.io/v1beta1"' > kubelet_configz_${NODE_NAME}
```
{{< note >}}
You need to manually add the `kind` and `apiVersion` to the downloaded
@@ -312,8 +312,6 @@ empty, since all config sources have been reset to `nil`, which indicates that
the local default config is `assigned`, `active`, and `lastKnownGood`, and no
error is reported.
<!-- discussion -->
## `kubectl patch` example
@@ -356,7 +354,7 @@ metadata and checkpoints. The structure of the kubelet's checkpointing directory
| - ...
```
## Understanding Node.Status.Config.Error messages {#understanding-node-config-status-errors}
## Understanding `Node.Status.Config.Error` messages {#understanding-node-config-status-errors}
The following table describes error messages that can occur
when using Dynamic Kubelet Config. You can search for the identical text
@@ -378,6 +376,10 @@ internal failure, see Kubelet log for details | The kubelet encountered some int
## {{% heading "whatsnext" %}}
- For more information on configuring the kubelet via a configuration file, see
- For more information on configuring the kubelet via a configuration file, see
[Set kubelet parameters via a config file](/docs/tasks/administer-cluster/kubelet-config-file).
- See the reference documentation for [`NodeConfigSource`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#nodeconfigsource-v1-core)
- Learn more about kubelet configuration by checking the
[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/)
reference.
content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+1 -1
View File
@@ -90,7 +90,7 @@ In addition to `cpu`, `memory`, and `ephemeral-storage`, `pid` may be
specified to reserve the specified number of process IDs for
kubernetes system daemons.
To optionally enforce `kube-reserved` on system daemons, specify the parent
To optionally enforce `kube-reserved` on kubernetes system daemons, specify the parent
control group for kube daemons as the value for `--kube-reserved-cgroup` kubelet
flag.
content/en/docs/tasks/configure-pod-container/static-pod.md
+12 -16
View File
@@ -31,21 +31,14 @@ Pods to run a Pod on every node, you should probably be using a
instead.
{{< /note >}}
## {{% heading "prerequisites" %}}
{{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
This page assumes you're using {{< glossary_tooltip term_id="docker" >}} to run Pods,
and that your nodes are running the Fedora operating system.
Instructions for other distributions or Kubernetes installations may vary.
<!-- steps -->
## Create a static pod {#static-pod-creation}
@@ -54,7 +47,9 @@ You can configure a static Pod with either a [file system hosted configuration f
### Filesystem-hosted static Pod manifest {#configuration-files}
Manifests are standard Pod definitions in JSON or YAML format in a specific directory. Use the `staticPodPath: <the directory>` field in the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file), which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there.
Manifests are standard Pod definitions in JSON or YAML format in a specific directory. Use the `staticPodPath: <the directory>` field in the
[kubelet configuration file](/docs/reference/config-api/kubelet-config.v1beta1/),
which periodically scans the directory and creates/deletes static Pods as YAML/JSON files appear/disappear there.
Note that the kubelet will ignore files starting with dots when scanning the specified directory.
For example, this is how to start a simple web server as a static Pod:
@@ -90,17 +85,18 @@ For example, this is how to start a simple web server as a static Pod:
3. Configure your kubelet on the node to use this directory by running it with `--pod-manifest-path=/etc/kubelet.d/` argument. On Fedora edit `/etc/kubernetes/kubelet` to include this line:
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
or add the `staticPodPath: <the directory>` field in the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file).
```
KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/"
```
or add the `staticPodPath: <the directory>` field in the
[kubelet configuration file](/docs/reference/config-api/kubelet-config.v1beta1/).
4. Restart the kubelet. On Fedora, you would run:
```shell
# Run this command on the node where the kubelet is running
systemctl restart kubelet
```
```shell
# Run this command on the node where the kubelet is running
systemctl restart kubelet
```
### Web-hosted static pod manifest {#pods-created-via-http}
content/en/docs/tasks/debug-application-cluster/audit.md
+10 -7
View File
@@ -46,7 +46,9 @@ Each request can be recorded with an associated _stage_. The defined stages are:
- `Panic` - Events generated when a panic occurred.
{{< note >}}
Audit events are different from the
The configuration of an
[Audit Event configuration](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event)
is different from the
[Event](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#event-v1-core)
API object.
{{< /note >}}
@@ -59,7 +61,7 @@ Memory consumption depends on the audit logging configuration.
Audit policy defines rules about what events should be recorded and what data
they should include. The audit policy object structure is defined in the
[`audit.k8s.io` API group](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy).
When an event is processed, it's
compared against the list of rules in order. The first matching rule sets the
_audit level_ of the event. The defined audit levels are:
@@ -95,6 +97,9 @@ If you're crafting your own audit profile, you can use the audit profile for Goo
[configure-helper.sh](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/cluster/gce/gci/configure-helper.sh)
script, which generates an audit policy file. You can see most of the audit policy file by looking directly at the script.
You can also refer to the [`Policy` configuration reference](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Policy)
for details about the fields defined.
## Audit backends
Audit backends persist audit events to an external storage.
@@ -104,9 +109,7 @@ Out of the box, the kube-apiserver provides two backends:
- Webhook backend, which sends events to an external HTTP API
In all cases, audit events follow a structure defined by the Kubernetes API in the
`audit.k8s.io` API group. For Kubernetes {{< param "fullversion" >}}, that
API is at version
[`v1`](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/pkg/apis/audit/v1/types.go).
[`audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/#audit-k8s-io-v1-Event).
{{< note >}}
In case of patches, request body is a JSON array with patch operations, not a JSON object
@@ -174,8 +177,6 @@ and finally configure the `hostPath`:
```
### Webhook backend
The webhook audit backend sends audit events to a remote web API, which is assumed to
@@ -250,3 +251,5 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr
## {{% heading "whatsnext" %}}
* Learn about [Mutating webhook auditing annotations](/docs/reference/access-authn-authz/extensible-admission-controllers/#mutating-webhook-auditing-annotations).
* Read the [reference for `audit.k8s.io` API group](/docs/reference/config-api/apiserver-audit.v1/).
content/en/docs/tasks/run-application/horizontal-pod-autoscale.md
+1 -1
View File
@@ -354,7 +354,7 @@ and [the walkthrough for using external metrics](/docs/tasks/run-application/hor
## Support for configurable scaling behavior
Starting from
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/20190307-configurable-scale-velocity-for-hpa.md)
[v1.18](https://github.com/kubernetes/enhancements/blob/master/keps/sig-autoscaling/853-configurable-hpa-scale-velocity/README.md)
the `v2beta2` API allows scaling behavior to be configured through the HPA
`behavior` field. Behaviors are specified separately for scaling up and down in
`scaleUp` or `scaleDown` section under the `behavior` field. A stabilization
content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md
+1 -1
View File
@@ -33,7 +33,7 @@ Up to date information on this process can be found at the
Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command:
```shell
helm repo add svc-cat https://svc-catalog-charts.storage.googleapis.com
helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog
```
Check to make sure that it installed successfully by executing the following command: