Merge pull request #47036 from chanieljdan/merged-main-dev-1.31

Merged main dev 1.31

Author: k8s-ci-robot

assets/scss/_custom.scss

@@ -341,6 +341,12 @@ footer {
 
 /* DOCS */
 
+table tr.cve-status-open, table tr.cve-status-unknown {
+  > td.cve-item-summary {
+    font-weight: bold;
+  }
+}
+
 .launch-cards {
   padding: 0;
   display: grid;

content/en/docs/concepts/configuration/secret.md

@@ -335,7 +335,6 @@ You can create an `Opaque` type for credentials used for basic authentication.
 However, using the defined and public Secret type (`kubernetes.io/basic-auth`) helps other
 people to understand the purpose of your Secret, and sets a convention for what key names
 to expect.
-The Kubernetes API verifies that the required keys are set for a Secret of this type.
 
 ### SSH authentication Secrets
 

content/en/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md

@@ -103,9 +103,9 @@ percentageOfNodesToScore: 50
 
 `percentageOfNodesToScore` must be a value between 1 and 100 with the default
 value being calculated based on the cluster size. There is also a hardcoded
-minimum value of 50 nodes.
+minimum value of 100 nodes.
 
-{{< note >}}In clusters with less than 50 feasible nodes, the scheduler still
+{{< note >}}In clusters with less than 100 feasible nodes, the scheduler still
 checks all the nodes because there are not enough feasible nodes to stop
 the scheduler's search early.
 

content/en/docs/concepts/services-networking/service.md

@@ -725,16 +725,16 @@ Select one of the tabs.
 metadata:
   name: my-service
   annotations:
-      networking.gke.io/load-balancer-type: "Internal"
+    networking.gke.io/load-balancer-type: "Internal"
 ```
 {{% /tab %}}
 {{% tab name="AWS" %}}
 
 ```yaml
 metadata:
-    name: my-service
-    annotations:
-        service.beta.kubernetes.io/aws-load-balancer-internal: "true"
+  name: my-service
+  annotations:
+    service.beta.kubernetes.io/aws-load-balancer-internal: "true"
 ```
 
 {{% /tab %}}
@@ -744,7 +744,7 @@ metadata:
 metadata:
   name: my-service
   annotations:
-      service.beta.kubernetes.io/azure-load-balancer-internal: "true"
+    service.beta.kubernetes.io/azure-load-balancer-internal: "true"
 ```
 
 {{% /tab %}}
@@ -754,7 +754,7 @@ metadata:
 metadata:
   name: my-service
   annotations:
-      service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
+    service.kubernetes.io/ibm-load-balancer-cloud-provider-ip-type: "private"
 ```
 
 {{% /tab %}}
@@ -802,7 +802,7 @@ metadata:
 metadata:
   name: my-service
   annotations:
-      service.beta.kubernetes.io/oci-load-balancer-internal: true
+    service.beta.kubernetes.io/oci-load-balancer-internal: true
 ```
 {{% /tab %}}
 {{< /tabs >}}

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

@@ -14,62 +14,68 @@ weight: 270
 
 ## {{% heading "prerequisites" %}}
 
-You need to have a Kubernetes cluster, and the kubectl command-line tool must
-be configured to communicate with your cluster. It is recommended to follow this
-guide on a cluster with at least two nodes that are not acting as control plane
-nodes. If you do not already have a cluster, you can create one by using
-[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/).
+Before you follow steps in this page to deploy, manage, back up or restore etcd,
+you need to understand the typical expectations for operating an etcd cluster.
+Refer to the [etcd documentation](https://etcd.io/docs/) for more context.
 
-### Understanding etcdctl and etcdutl
+Key details include:
 
-`etcdctl` and `etcdutl` are command-line tools used to interact with etcd clusters, but they serve different purposes:
-
-- `etcdctl`: This is the primary command-line client for interacting with etcd over a
-network. It is used for day-to-day operations such as managing keys and values,
-administering the cluster, checking health, and more.
-
-- `etcdutl`: This is an administration utility designed to operate directly on etcd data
-files, including migrating data between etcd versions, defragmenting the database,
-restoring snapshots, and validating data consistency. For network operations, `etcdctl`
-should be used.
-
-For more information on `etcdutl`, you can refer to the [etcd recovery documentation](https://etcd.io/docs/v3.5/op-guide/recovery/).
-
-<!-- steps -->
-
-## Prerequisites
-
-* Run etcd as a cluster of odd members.
+* The minimum recommended etcd versions to run in production are `3.4.22+` and `3.5.6+`.
 
 * etcd is a leader-based distributed system. Ensure that the leader
   periodically send heartbeats on time to all followers to keep the cluster
   stable.
 
-* Ensure that no resource starvation occurs.
+* You should run etcd as a cluster with an odd number of members.
+
+* Aim to ensure that no resource starvation occurs.
 
   Performance and stability of the cluster is sensitive to network and disk
   I/O. Any resource starvation can lead to heartbeat timeout, causing instability
   of the cluster. An unstable etcd indicates that no leader is elected. Under
   such circumstances, a cluster cannot make any changes to its current state,
   which implies no new pods can be scheduled.
 
-* Keeping etcd clusters stable is critical to the stability of Kubernetes
-  clusters. Therefore, run etcd clusters on dedicated machines or isolated
-  environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/).
-
-* The minimum recommended etcd versions to run in production are `3.4.22+` and `3.5.6+`.
-
-## Resource requirements
+### Resource requirements for etcd
 
 Operating etcd with limited resources is suitable only for testing purposes.
 For deploying in production, advanced hardware configuration is required.
 Before deploying etcd in production, see
 [resource requirement reference](https://etcd.io/docs/current/op-guide/hardware/#example-hardware-configurations).
 
+Keeping etcd clusters stable is critical to the stability of Kubernetes
+clusters. Therefore, run etcd clusters on dedicated machines or isolated
+environments for [guaranteed resource requirements](https://etcd.io/docs/current/op-guide/hardware/).
+
+### Tools
+
+Depending on which specific outcome you're working on, you will need the `etcdctl` tool or the
+`etcdutl` tool (you may need both).
+
+<!-- steps -->
+
+## Understanding etcdctl and etcdutl
+
+`etcdctl` and `etcdutl` are command-line tools used to interact with etcd clusters, but they serve different purposes:
+
+- `etcdctl`: This is the primary command-line client for interacting with etcd over a
+network. It is used for day-to-day operations such as managing keys and values,
+administering the cluster, checking health, and more.
+
+- `etcdutl`: This is an administration utility designed to operate directly on etcd data
+files, including migrating data between etcd versions, defragmenting the database,
+restoring snapshots, and validating data consistency. For network operations, `etcdctl`
+should be used.
+
+For more information on `etcdutl`, you can refer to the [etcd recovery documentation](https://etcd.io/docs/v3.5/op-guide/recovery/).
+
+
 ## Starting etcd clusters
 
 This section covers starting a single-node and multi-node etcd cluster.
 
+This guide assumes that `etcd` is already installed.
+
 ### Single-node etcd cluster
 
 Use a single-node etcd cluster only for testing purposes.
@@ -93,7 +99,14 @@ production and back it up periodically. A five-member cluster is recommended
 in production. For more information, see
 [FAQ documentation](https://etcd.io/docs/current/faq/#what-is-failure-tolerance).
 
-Configure an etcd cluster either by static member information or by dynamic
+As you're using Kubernetes, you have the option to run etcd as a container inside
+one or more Pods. The `kubeadm` tool sets up etcd
+{{< glossary_tooltip text="static pods" term_id="static-pod" >}} by default, or
+you can deploy a
+[separate cluster](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/)
+and instruct kubeadm to use that etcd cluster as the control plane's backing store.
+
+You configure an etcd cluster either by static member information or by dynamic
 discovery. For more information on clustering, see
 [etcd clustering documentation](https://etcd.io/docs/current/op-guide/clustering/).
 

content/en/docs/tasks/configure-pod-container/configure-service-account.md

@@ -263,7 +263,7 @@ token:          ...
 ```
 
 {{< note >}}
-The content of `token` is elided here.
+The content of `token` is omitted here.
 
 Take care not to display the contents of a `kubernetes.io/service-account-token`
 Secret somewhere that your terminal / computer screen could be seen by an onlooker.

content/en/docs/tasks/configure-pod-container/translate-compose-kubernetes.md

@@ -29,13 +29,13 @@ Kompose is released via GitHub on a three-week cycle, you can see all current re
 
 ```sh
 # Linux
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-linux-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-linux-amd64 -o kompose
 
 # macOS
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-darwin-amd64 -o kompose
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-darwin-amd64 -o kompose
 
 # Windows
-curl -L https://github.com/kubernetes/kompose/releases/download/v1.26.0/kompose-windows-amd64.exe -o kompose.exe
+curl -L https://github.com/kubernetes/kompose/releases/download/v1.34.0/kompose-windows-amd64.exe -o kompose.exe
 
 chmod +x kompose
 sudo mv ./kompose /usr/local/bin/kompose
@@ -93,26 +93,27 @@ you need is an existing `docker-compose.yml` file.
 1. Go to the directory containing your `docker-compose.yml` file. If you don't have one, test using this one.
 
    ```yaml
-   version: "2"
 
    services:
 
-     redis-master:
-       image: registry.k8s.io/redis:e2e
+     redis-leader:
+       container_name: redis-leader
+       image: redis
        ports:
          - "6379"
 
-     redis-slave:
-       image: gcr.io/google_samples/gb-redisslave:v3
+     redis-replica:
+       container_name: redis-replica
+       image: redis
        ports:
          - "6379"
-       environment:
-         - GET_HOSTS_FROM=dns
+       command: redis-server --replicaof redis-leader 6379 --dir /tmp
 
-     frontend:
-       image: gcr.io/google-samples/gb-frontend:v4
+     web:
+       container_name: web
+       image: quay.io/kompose/web
        ports:
-         - "80:80"
+         - "8080:8080"
        environment:
          - GET_HOSTS_FROM=dns
        labels:
@@ -129,27 +130,27 @@ you need is an existing `docker-compose.yml` file.
    The output is similar to:
 
    ```none
-   INFO Kubernetes file "frontend-tcp-service.yaml" created 
-   INFO Kubernetes file "redis-master-service.yaml" created 
-   INFO Kubernetes file "redis-slave-service.yaml" created 
-   INFO Kubernetes file "frontend-deployment.yaml" created 
-   INFO Kubernetes file "redis-master-deployment.yaml" created 
-   INFO Kubernetes file "redis-slave-deployment.yaml" created
+   INFO Kubernetes file "redis-leader-service.yaml" created
+   INFO Kubernetes file "redis-replica-service.yaml" created
+   INFO Kubernetes file "web-tcp-service.yaml" created
+   INFO Kubernetes file "redis-leader-deployment.yaml" created
+   INFO Kubernetes file "redis-replica-deployment.yaml" created
+   INFO Kubernetes file "web-deployment.yaml" created
    ```
 
    ```bash
-    kubectl apply -f frontend-tcp-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
+    kubectl apply -f web-tcp-service.yaml,redis-leader-service.yaml,redis-replica-service.yaml,web-deployment.yaml,redis-leader-deployment.yaml,redis-replica-deployment.yaml
    ```
 
    The output is similar to:
 
    ```none
-   service/frontend-tcp created
-   service/redis-master created
-   service/redis-slave created
-   deployment.apps/frontend created
-   deployment.apps/redis-master created
-   deployment.apps/redis-slave created
+   deployment.apps/redis-leader created
+   deployment.apps/redis-replica created
+   deployment.apps/web created
+   service/redis-leader created
+   service/redis-replica created
+   service/web-tcp created
    ```
 
     Your deployments are running in Kubernetes.
@@ -159,39 +160,35 @@ you need is an existing `docker-compose.yml` file.
    If you're already using `minikube` for your development process:
 
    ```bash
-   minikube service frontend
+   minikube service web-tcp
    ```
 
    Otherwise, let's look up what IP your service is using!
 
    ```sh
-   kubectl describe svc frontend
+   kubectl describe svc web-tcp
    ```
 
    ```none
-   Name:                     frontend-tcp
-   Namespace:                default
-   Labels:                   io.kompose.service=frontend-tcp
-   Annotations:              kompose.cmd: kompose convert
-                             kompose.service.type: LoadBalancer
-                             kompose.version: 1.26.0 (40646f47)
-   Selector:                 io.kompose.service=frontend
-   Type:                     LoadBalancer
-   IP Family Policy:         SingleStack
-   IP Families:              IPv4
-   IP:                       10.43.67.174
-   IPs:                      10.43.67.174
-   Port:                     80  80/TCP
-   TargetPort:               80/TCP
-   NodePort:                 80  31254/TCP
-   Endpoints:                10.42.0.25:80
-   Session Affinity:         None
-   External Traffic Policy:  Cluster
-   Events:
-     Type    Reason                Age   From                Message
-     ----    ------                ----  ----                -------
-     Normal  EnsuringLoadBalancer  62s   service-controller  Ensuring load balancer
-     Normal  AppliedDaemonSet      62s   service-controller  Applied LoadBalancer DaemonSet kube-system/svclb-frontend-tcp-9362d276
+    Name:                     web-tcp
+    Namespace:                default
+    Labels:                   io.kompose.service=web-tcp
+    Annotations:              kompose.cmd: kompose convert
+                              kompose.service.type: LoadBalancer
+                              kompose.version: 1.33.0 (3ce457399)
+    Selector:                 io.kompose.service=web
+    Type:                     LoadBalancer
+    IP Family Policy:         SingleStack
+    IP Families:              IPv4
+    IP:                       10.102.30.3
+    IPs:                      10.102.30.3
+    Port:                     8080  8080/TCP
+    TargetPort:               8080/TCP
+    NodePort:                 8080  31624/TCP
+    Endpoints:                10.244.0.5:8080
+    Session Affinity:         None
+    External Traffic Policy:  Cluster
+    Events:                   <none>
    ```
 
    If you're using a cloud provider, your IP will be listed next to `LoadBalancer Ingress`.
@@ -206,7 +203,7 @@ you need is an existing `docker-compose.yml` file.
    resources used.
 
    ```sh
-   kubectl delete -f frontend-tcp-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
+   kubectl delete -f web-tcp-service.yaml,redis-leader-service.yaml,redis-replica-service.yaml,web-deployment.yaml,redis-leader-deployment.yaml,redis-replica-deployment.yaml
    ```
 
 <!-- discussion -->

content/en/docs/tasks/manage-kubernetes-objects/storage-version-migration.md

@@ -26,6 +26,15 @@ Install [`kubectl`](/docs/tasks/tools/#kubectl).
 
 {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}}
 
+Ensure that your cluster has the `StorageVersionMigrator` and `InformerResourceVersion`
+[feature gates](/docs/reference/command-line-tools-reference/feature-gates/)
+enabled. You will need control plane administrator access to make that change.
+
+Enable storage version migration REST api by setting runtime config
+`storagemigration.k8s.io/v1alpha1` to `true` for the API server. For more information on
+how to do that,
+read [enable or disable a Kubernetes API](/docs/tasks/administer-cluster/enable-disable-api/).
+
 <!-- steps -->
 
 ## Re-encrypt Kubernetes secrets using storage version migration