Merge remote-tracking branch 'upstream/main' into dev-1.24

content/en/docs/tasks/administer-cluster/access-cluster-api.md

@@ -95,8 +95,25 @@ export CLUSTER_NAME="some_server_name"
 # Point to the API server referring the cluster name
 APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
 
-# Gets the token value
-TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 --decode)
+# Create a secret to hold a token for the default service account
+kubectl apply -f - <<EOF
+apiVersion: v1
+kind: Secret
+metadata:
+  name: default-token
+  annotations:
+    kubernetes.io/service-account.name: default
+type: kubernetes.io/service-account-token
+EOF
+
+# Wait for the token controller to populate the secret with a token:
+while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
+  echo "waiting for token..." >&2
+  sleep 1
+done
+
+# Get the token value
+TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
 
 # Explore the API with TOKEN
 curl -X GET $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
@@ -119,26 +136,6 @@ The output is similar to this:
 }
 ```
 
-Using `jsonpath` approach:
-
-```shell
-APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
-TOKEN=$(kubectl get secret $(kubectl get serviceaccount default -o jsonpath='{.secrets[0].name}') -o jsonpath='{.data.token}' | base64 --decode )
-curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure
-{
-  "kind": "APIVersions",
-  "versions": [
-    "v1"
-  ],
-  "serverAddressByClientCIDRs": [
-    {
-      "clientCIDR": "0.0.0.0/0",
-      "serverAddress": "10.0.1.149:443"
-    }
-  ]
-}
-```
-
 The above example uses the `--insecure` flag. This leaves it subject to MITM
 attacks. When kubectl accesses the cluster it uses a stored root certificate
 and client certificates to access the server. (These are installed in the

content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md

@@ -361,3 +361,12 @@ We also recommend restarting any components (e.g. `kube-scheduler`,
 stale data. Note that in practice, the restore takes a bit of time.  During the
 restoration, critical components will lose leader lock and restart themselves.
 {{< /note >}}
+
+## Upgrading etcd clusters
+
+
+For more details on etcd upgrade, please refer to the [etcd upgrades](https://etcd.io/docs/latest/upgrades/) documentation.
+
+{{< note >}}
+Before you start an upgrade, please back up your etcd cluster first.
+{{< /note >}}

content/en/docs/tasks/administer-cluster/cpu-management-policies.md

@@ -46,7 +46,8 @@ management policies to determine some placement preferences on the node.
 ### Configuration
 
 The CPU Manager policy is set with the `--cpu-manager-policy` kubelet
-option. There are two supported policies:
+flag or the `cpuManagerPolicy` field in [KubeletConfiguration](/docs/reference/config-api/kubelet-config.v1beta1/).
+There are two supported policies:
 
 * [`none`](#none-policy): the default policy.
 * [`static`](#static-policy): allows pods with certain resource characteristics to be
@@ -68,6 +69,27 @@ and `CPUManagerPolicyBetaOptions` feature gates. Diverging from the Kubernetes s
 feature gates guard groups of options, because it would have been too cumbersome to add a feature
 gate for each individual option.
 
+### Changing the CPU Manager Policy
+
+Since the CPU manger policy can only be applied when kubelet spawns new pods, simply changing from
+"none" to "static" won't apply to existing pods. So in order to properly change the CPU manager
+policy on a node, perform the following steps:
+
+1. [Drain](/docs/tasks/administer-cluster/safely-drain-node) the node.
+2. Stop kubelet.
+3. Remove the old CPU manager state file. The path to this file is
+`/var/lib/kubelet/cpu_manager_state` by default. This clears the state maintained by the
+CPUManager so that the cpu-sets set up by the new policy won’t conflict with it.
+4. Edit the kubelet configuration to change the CPU manager policy to the desired value.
+5. Start kubelet.
+
+Repeat this process for every node that needs its CPU manager policy changed. Skipping this
+process will result in kubelet crashlooping with the following error:
+
+```
+could not restore state from checkpoint: configured policy "static" differs from state checkpoint policy "none", please drain this node and delete the CPU manager checkpoint file "/var/lib/kubelet/cpu_manager_state" before restarting Kubelet
+```
+
 ### None policy
 
 The `none` policy explicitly enables the existing default CPU

content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md

@@ -170,7 +170,7 @@ kubectl apply -f https://k8s.io/examples/admin/resource/cpu-constraints-pod-3.ya
 ```
 
 The output shows that the Pod does not get created, because it defines an unacceptable container.
-That container is not acceptable because it specifies a CPU limit that is lower than the
+That container is not acceptable because it specifies a CPU request that is lower than the
 enforced minimum:
 
 ```

content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md

@@ -177,7 +177,7 @@ Here are two of the restrictions that a resource quota imposes on a namespace:
 * For every Pod that runs in the namespace, the Pod and each of its containers must have a memory limit.
   (If you specify a memory limit for every container in a Pod, Kubernetes can infer the Pod-level memory
   limit by adding up the limits for its containers).
-* CPU limits apply a resource reservation on the node where the Pod in question is scheduled.
+* Memory limits apply a resource reservation on the node where the Pod in question is scheduled.
   The total amount of memory reserved for all Pods in the namespace must not exceed a specified limit.
 * The total amount of memory actually used by all Pods in the namespace must also not exceed a specified limit.