Merge pull request #52521 from soltysh/kyaml_feature

Add missing env var (KUBECTL_KYAML) for kubectl, used for enabling kyaml output format

Author: k8s-ci-robot

content/en/docs/reference/kubectl/kubectl.md

@@ -362,7 +362,7 @@ kubectl [flags]
 <td colspan="2">KUBECTL_ENABLE_CMD_SHADOW</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to true, external plugins can be used as subcommands for builtin commands if subcommand does not exist. In alpha stage, this feature can only be used for create command(e.g. kubectl create networkpolicy). 
+<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to true, external plugins can be used as subcommands for builtin commands if subcommand does not exist. In alpha stage, this feature can only be used for create command(e.g. kubectl create networkpolicy).
 </td>
 </tr>
 
@@ -386,7 +386,15 @@ kubectl [flags]
 <td colspan="2">KUBECTL_KUBERC</td>
 </tr>
 <tr>
-<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to true, kuberc file is taken into account to define user specific preferences.  
+<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to true, kuberc file is taken into account to define user specific preferences.
+</td>
+</tr>
+
+<tr>
+<td colspan="2">KUBECTL_KYAML</td>
+</tr>
+<tr>
+<td></td><td style="line-height: 130%; word-wrap: break-word;">When set to true, kubectl is capable of producing Kubernetes-specific dialect of YAML output format.
 </td>
 </tr>
 

content/en/docs/reference/node/node-status.md

@@ -3,6 +3,7 @@ content_type: reference
 title: Node Status
 weight: 80
 ---
+
 <!-- overview -->
 
 The status of a [node](/docs/concepts/architecture/nodes/) in Kubernetes is a critical
@@ -20,9 +21,9 @@ A Node's status contains the following information:
 
 You can use `kubectl` to view a Node's status and other details:
 
-```shell
 kubectl describe node <insert-node-name-here>
-```
+
+text
 
 Each section of the output is described below.
 
@@ -40,43 +41,43 @@ The usage of these fields varies depending on your cloud provider or bare metal
 
 The `conditions` field describes the status of all `Running` nodes. Examples of conditions include:
 
-{{< table caption = "Node conditions, and a description of when each condition applies." >}}
+{{< table caption="Node conditions, and a description of when each condition applies." >}}
 | Node Condition       | Description |
 |----------------------|-------------|
-| `Ready`              | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 50 seconds) |
-| `DiskPressure`       | `True` if pressure exists on the disk size—that is, if the disk capacity is low; otherwise `False` |
-| `MemoryPressure`     | `True` if pressure exists on the node memory—that is, if the node memory is low; otherwise `False` |
-| `PIDPressure`        | `True` if pressure exists on the processes—that is, if there are too many processes on the node; otherwise `False` |
-| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False` |
+| `Ready`              | `True` if the node is healthy and ready to accept pods, `False` if the node is not healthy and is not accepting pods, and `Unknown` if the node controller has not heard from the node in the last `node-monitor-grace-period` (default is 40 seconds). |
+| `DiskPressure`       | `True` if pressure exists on the disk size—that is, if the disk capacity is low; otherwise `False`. |
+| `MemoryPressure`     | `True` if pressure exists on the node memory—that is, if the node memory is low; otherwise `False`. |
+| `PIDPressure`        | `True` if pressure exists on the processes—that is, if there are too many processes on the node; otherwise `False`. |
+| `NetworkUnavailable` | `True` if the network for the node is not correctly configured, otherwise `False`. |
 {{< /table >}}
 
 {{< note >}}
 If you use command-line tools to print details of a cordoned Node, the Condition includes
 `SchedulingDisabled`. `SchedulingDisabled` is not a Condition in the Kubernetes API; instead,
-cordoned nodes are marked Unschedulable in their spec.
+cordoned nodes are marked `Unschedulable` in their spec.
 {{< /note >}}
 
 In the Kubernetes API, a node's condition is represented as part of the `.status`
 of the Node resource. For example, the following JSON structure describes a healthy node:
 
-```json
 "conditions": [
-  {
-    "type": "Ready",
-    "status": "True",
-    "reason": "KubeletReady",
-    "message": "kubelet is posting ready status",
-    "lastHeartbeatTime": "2019-06-05T18:38:35Z",
-    "lastTransitionTime": "2019-06-05T11:41:27Z"
-  }
+{
+"type": "Ready",
+"status": "True",
+"reason": "KubeletReady",
+"message": "kubelet is posting ready status",
+"lastHeartbeatTime": "2019-06-05T18:38:35Z",
+"lastTransitionTime": "2019-06-05T11:41:27Z"
+}
 ]
-```
+
+text
 
 When problems occur on nodes, the Kubernetes control plane automatically creates
 [taints](/docs/concepts/scheduling-eviction/taint-and-toleration/) that match the conditions
 affecting the node. An example of this is when the `status` of the Ready condition
 remains `Unknown` or `False` for longer than the kube-controller-manager's `NodeMonitorGracePeriod`,
-which defaults to 50 seconds. This will cause either an `node.kubernetes.io/unreachable` taint, for an `Unknown` status,
+which defaults to 40 seconds. This will cause either an `node.kubernetes.io/unreachable` taint, for an `Unknown` status,
 or a `node.kubernetes.io/not-ready` taint, for a `False` status, to be added to the Node.
 
 These taints affect pending pods as the scheduler takes the Node's taints into consideration when
@@ -116,7 +117,7 @@ availability of each node, and to take action when failures are detected.
 
 For nodes there are two forms of heartbeats:
 
-* updates to the `.status` of a Node
+* updates to the `.status` of a Node.
 * [Lease](/docs/concepts/architecture/leases/) objects
   within the `kube-node-lease`
   {{< glossary_tooltip term_id="namespace" text="namespace">}}.
@@ -132,8 +133,11 @@ and for updating their related Leases.
 - The kubelet updates the node's `.status` either when there is change in status
   or if there has been no update for a configured interval. The default interval
   for `.status` updates to Nodes is 5 minutes, which is much longer than the 40
-  second default timeout for unreachable nodes.
+  second default timeout for unreachable nodes. The update interval is controlled by the
+  `nodeStatusUpdateFrequency` field in the [Kubelet configuration file](/docs/tasks/administer-cluster/reconfigure-kubelet/),
+  and the timeout is controlled by the
+  `--node-monitor-grace-period` flag on the [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/).
 - The kubelet creates and then updates its Lease object every 10 seconds
   (the default update interval). Lease updates occur independently from
   updates to the Node's `.status`. If the Lease update fails, the kubelet retries,
-  using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.
+  using exponential backoff that starts at 200 milliseconds and capped at 7 seconds.