Merge pull request #41395 from tengqm/improve-sys-logs

Improve sys logs page by clarifying options dropped

content/en/docs/concepts/cluster-administration/logging.md

@@ -71,11 +71,12 @@ You can use `kubectl logs --previous` to retrieve logs from a previous instantia
 If your pod has multiple containers, specify which container's logs you want to access by
 appending a container name to the command, with a `-c` flag, like so:
 
-```console
+```shell
 kubectl logs counter -c count
 ```
 
-See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs) for more details.
+See the [`kubectl logs` documentation](/docs/reference/generated/kubectl/kubectl-commands#logs)
+for more details.
 
 ### How nodes handle container logs
 
@@ -98,23 +99,23 @@ The usual way to access this is by running `kubectl logs`.
 
 You can configure the kubelet to rotate logs automatically.
 
-If you configure rotation, the kubelet is responsible for rotating container logs and managing the logging directory structure.
+If you configure rotation, the kubelet is responsible for rotating container logs and managing the
+logging directory structure.
 The kubelet sends this information to the container runtime (using CRI),
 and the runtime writes the container logs to the given location.
 
 You can configure two kubelet [configuration settings](/docs/reference/config-api/kubelet-config.v1beta1/),
 `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.
+These settings let you configure the maximum size for each log file and the maximum number of
+files allowed for each container respectively.
 
 When you run [`kubectl logs`](/docs/reference/generated/kubectl/kubectl-commands#logs) as in
 the basic logging example, the kubelet on the node handles the request and
 reads directly from the log file. The kubelet returns the content of the log file.
 
-
 {{< note >}}
-Only the contents of the latest log file are available through
-`kubectl logs`.
+Only the contents of the latest log file are available through `kubectl logs`.
 
 For example, if a Pod writes 40 MiB of logs and the kubelet rotates logs
 after 10 MiB, running `kubectl logs` returns at most 10MiB of data.
@@ -149,9 +150,8 @@ If systemd is not present, the kubelet and container runtime write to `.log` fil
 run the kubelet via a helper tool, `kube-log-runner`, and use that tool to redirect
 kubelet logs to a directory that you choose.
 
-You can also set a logging directory using the deprecated kubelet command line
-argument `--log-dir`. However, the kubelet always directs your container runtime to
-write logs into directories within `/var/log/pods`.
+The kubelet always directs your container runtime to write logs into directories within
+`/var/log/pods`.
 
 For more information on `kube-log-runner`, read [System Logs](/docs/concepts/cluster-administration/system-logs/#klog).
 
@@ -221,7 +221,8 @@ application containers on that node.
 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.
+Node-level logging creates only one agent per node and doesn't require any changes to the
+applications running on the node.
 
 Containers write to stdout and stderr, but with no agreed format. A node-level agent collects
 these logs and forwards them for aggregation.
@@ -231,7 +232,8 @@ these logs and forwards them for aggregation.
 You can use a sidecar container in one of the following ways:
 
 * The sidecar container streams application logs to its own `stdout`.
-* The sidecar container runs a logging agent, which is configured to pick up logs from an application container.
+* The sidecar container runs a logging agent, which is configured to pick up logs
+  from an application container.
 
 #### Streaming sidecar container
 
@@ -346,10 +348,13 @@ The pod mounts a volume where fluentd can pick up its configuration data.
 
 ![Exposing logs directly from the application](/images/docs/user-guide/logging/logging-from-application.png)
 
-Cluster-logging that exposes or pushes logs directly from every application is outside the scope of Kubernetes.
+Cluster-logging that exposes or pushes logs directly from every application is outside the scope
+of Kubernetes.
 
 ## {{% heading "whatsnext" %}}
 
 * Read about [Kubernetes system logs](/docs/concepts/cluster-administration/system-logs/)
 * Learn about [Traces For Kubernetes System Components](/docs/concepts/cluster-administration/system-traces/)
-* Learn how to [customise the termination message](/docs/tasks/debug/debug-application/determine-reason-pod-failure/#customizing-the-termination-message) that Kubernetes records when a Pod fails
+* Learn how to [customise the termination message](/docs/tasks/debug/debug-application/determine-reason-pod-failure/#customizing-the-termination-message)
+  that Kubernetes records when a Pod fails
+

content/en/docs/concepts/cluster-administration/system-logs.md

@@ -22,12 +22,10 @@ scheduler decisions).
 klog is the Kubernetes logging library. [klog](https://github.com/kubernetes/klog)
 generates log messages for the Kubernetes system components.
 
-For more information about klog configuration, see the [Command line tool reference](/docs/reference/command-line-tools-reference/).
-
 Kubernetes is in the process of simplifying logging in its components.
 The following klog command line flags
 [are deprecated](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components)
-starting with Kubernetes 1.23 and will be removed in a future release:
+starting with Kubernetes v1.23 and removed in Kubernetes v1.26:
 
 - `--add-dir-header`
 - `--alsologtostderr`
@@ -96,13 +94,13 @@ klog output or structured logging.
 The default formatting of structured log messages is as text, with a format that is backward
 compatible with traditional klog:
 
-```ini
+```
 <klog header> "<message>" <key1>="<value1>" <key2>="<value2>" ...
 ```
 
 Example:
 
-```ini
+```
 I1025 00:15:15.525108       1 controller_utils.go:116] "Pod status updated" pod="kube-system/kubedns" status="ready"
 ```
 
@@ -245,6 +243,7 @@ in the application log provider. On both operating systems, logs are also availa
 
 Provided you are authorized to interact with node objects, you can try out this alpha feature on all your nodes or
 just a subset. Here is an example to retrieve the kubelet service logs from a node:
+
 ```shell
 # Fetch kubelet logs from a node named node-1.example
 kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet"
@@ -252,6 +251,7 @@ kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet"
 
 You can also fetch files, provided that the files are in a directory that the kubelet allows for log
 fetches. For example, you can fetch a log from `/var/log` on a Linux node:
+
 ```shell
 kubectl get --raw "/api/v1/nodes/<insert-node-name-here>/proxy/logs/?query=/<insert-log-file-name-here>"
 ```
@@ -273,6 +273,7 @@ Option | Description
 `tailLines` | specify how many lines from the end of the log to retrieve; the default is to fetch the whole log
 
 Example of a more complex query:
+
 ```shell
 # Fetch kubelet logs from a node named node-1.example that have the word "error"
 kubectl get --raw "/api/v1/nodes/node-1.example/proxy/logs/?query=kubelet&pattern=error"