Change:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: Url selector #kubelet-config-k8s-io-v1beta1-KubeletConfiguration doesn't make a difference between: and Proposed Solution: Removing the selector from the URLs Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--<!--Additional Information:--
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/language en
/assign
/retitle Problems with (generated) reference for kubelet configuration

Discussion:
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 <del> [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) </del> <ins> [`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) </ins> resource type. ### Container image lifecycle

|`custom-class-c`         | 1000                   | |`regular/unset`          | 0                      | <del> Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) </del> <ins> Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) </ins> the settings for `shutdownGracePeriodByPodPriority` could look like: |Pod priority class value|Shutdown period|

To enable swap on a node, the `NodeSwap` feature gate must be enabled on the kubelet, and the `--fail-swap-on` command line flag or `failSwapOn` <del> [configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) </del> <ins> [configuration setting](/docs/reference/config-api/kubelet-config.v1beta1/) </ins> must be set to false. {{< warning >}}

![Node level logging](/images/docs/user-guide/logging/logging-node-level.png) <del> A container runtime handles and redirects any output generated to a containerized application's `stdout` and `stderr` streams. Different container runtimes implement this in different ways; however, the integration with the kubelet is standardized as the _CRI logging format_. </del> <ins> A container runtime handles and redirects any output generated to a containerized application's `stdout` and `stderr` streams. Different container runtimes implement this in different ways; however, the integration with the kubelet is standardized as the _CRI logging format_. </ins> <del> By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs. </del> <ins> By default, if a container restarts, the kubelet keeps one terminated container with its logs. If a pod is evicted from the node, all corresponding containers are also evicted, along with their logs. </ins> <del> The kubelet makes logs available to clients via a special feature of the Kubernetes API. The usual way to access this is by running `kubectl logs`. </del> <ins> The kubelet makes logs available to clients via a special feature of the Kubernetes API. The usual way to access this is by running `kubectl logs`. </ins> ### Log rotation

The kubelet sends this information to the container runtime (using CRI), and the runtime writes the container logs to the given location. <del> You can configure two kubelet [configuration settings](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration), </del> <ins> You can configure two kubelet [configuration settings](/docs/reference/config-api/kubelet-config.v1beta1/), </ins> `containerLogMaxSize` and `containerLogMaxFiles`, using the [kubelet configuration file](/docs/tasks/administer-cluster/kubelet-config-file/). These settings let you configure the maximum size for each log file and the maximum number of files allowed for each container respectively.

## Cluster-level logging architectures <del> While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options: </del> <ins> While Kubernetes does not provide a native solution for cluster-level logging, there are several common approaches you can consider. Here are some options: </ins> * Use a node-level logging agent that runs on every node. * Include a dedicated sidecar container for logging in an application pod.

![Using a node level logging agent](/images/docs/user-guide/logging/logging-with-node-agent.png) <del> You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node. </del> <ins> You can implement cluster-level logging by including a _node-level logging agent_ on each node. The logging agent is a dedicated tool that exposes logs or pushes logs to a backend. Commonly, the logging agent is a container that has access to a directory with log files from all of the application containers on that node. </ins> Because the logging agent must run on every node, it is recommended to run the agent as a `DaemonSet`. Node-level logging creates only one agent per node and doesn't require any changes to the applications running on the node. <del> Containers write to stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation. </del> <ins> Containers write to stdout and stderr, but with no agreed format. A node-level agent collects these logs and forwards them for aggregation. </ins> ### Using a sidecar container with the logging agent {#sidecar-container-with-logging-agent}

You can use the `check-expiration` subcommand to check when certificates expire: <del> ``` </del> <ins> ```shell </ins> kubeadm certs check-expiration ``` The output is similar to this: <del> ``` </del> <ins> ```console </ins> CERTIFICATE                EXPIRES                  RESIDUAL TIME   CERTIFICATE AUTHORITY   EXTERNALLY MANAGED admin.conf                 Dec 30, 2020 23:36 UTC   364d                                    no apiserver                  Dec 30, 2020 23:36 UTC   364d            ca                      no

If you have already created the cluster you must adapt it by doing the following: - Find and edit the `kubelet-config-{{< skew currentVersion >}}` ConfigMap in the `kube-system` namespace. In that ConfigMap, the `kubelet` key has a <del> [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) </del> <ins> [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/) </ins> document as its value. Edit the KubeletConfiguration document to set `serverTLSBootstrap: true`. - On each node, add the `serverTLSBootstrap: true` field in `/var/lib/kubelet/config.yaml` and restart the kubelet with `systemctl restart kubelet`

```shell kubectl get csr <ins> ``` ```console </ins> NAME        AGE     SIGNERNAME                        REQUESTOR                      CONDITION csr-9wvgt   112s    kubernetes.io/kubelet-serving     system:node:worker-1           Pending csr-lz97v   1m58s   kubernetes.io/kubelet-serving     system:node:control-plane-1    Pending