diff --git a/hack/lib/kind-config/single-node.yaml b/hack/lib/kind-config/single-node.yaml
index 71202f09c..56b05f666 100644
--- a/hack/lib/kind-config/single-node.yaml
+++ b/hack/lib/kind-config/single-node.yaml
@@ -19,58 +19,46 @@ nodes:
       containerPort: 31235
       hostPort: 12346
       listenAddress: 127.0.0.1
-
-
-    #! Kind v0.12.0 ignores kubeadm.k8s.io/v1beta2 for Kube v1.23+ but uses it for older versions of Kube.
-    #! Previous versions of Kind would use kubeadm.k8s.io/v1beta2 for all versions of Kube including 1.23.
-    #! To try to maximize compatibility with various versions of Kind and Kube, define this
-    #! ClusterConfiguration twice and hope that Kind will use the one that it likes for the given version
-    #! of Kube, and ignore the one that it doesn't like. This seems to work, at least for Kind v0.12.0.
-    kubeadmConfigPatches:
-    - |
-      apiVersion: kubeadm.k8s.io/v1beta2
-      kind: ClusterConfiguration
-      apiServer:
-        extraArgs:
-          #! To make sure the endpoints on our service are correct (this mostly matters for kubectl based
-          #! installs where kapp is not doing magic changes to the deployment and service selectors).
-          #! Setting this field to true makes it so that the API service will do the service cluster IP
-          #! to endpoint IP translations internally instead of relying on the network stack (i.e. kube-proxy).
-          #! The logic inside the API server is very straightforward - randomly pick an IP from the list
-          #! of available endpoints.  This means that over time, all endpoints associated with the service
-          #! are exercised.  For whatever reason, leaving this as false (i.e. use kube-proxy) appears to
-          #! hide some network misconfigurations when used internally by the API server aggregation layer.
-          enable-aggregator-routing: "true"
-    - |
-      apiVersion: kubeadm.k8s.io/v1beta3
-      kind: ClusterConfiguration
-      apiServer:
-        extraArgs:
-          # See comment above.
-          enable-aggregator-routing: "true"
     #@ if data.values.enable_audit_logs:
-    - |
-      kind: ClusterConfiguration
-      apiServer:
-          #! enable auditing flags on the API server
-          extraArgs:
-            audit-log-path: /var/log/kubernetes/kube-apiserver-audit.log
-            audit-policy-file: /etc/kubernetes/policies/audit-policy.yaml
-          #! mount new files / directories on the control plane
-          extraVolumes:
-            - name: audit-policies
-              hostPath: /etc/kubernetes/policies
-              mountPath: /etc/kubernetes/policies
-              readOnly: true
-              pathType: "DirectoryOrCreate"
-            - name: "audit-logs"
-              hostPath: "/var/log/kubernetes"
-              mountPath: "/var/log/kubernetes"
-              readOnly: false
-              pathType: DirectoryOrCreate
     #! mount the local file on the control plane
     extraMounts:
-    - hostPath: /tmp/metadata-audit-policy.yaml
-      containerPath: /etc/kubernetes/policies/audit-policy.yaml
-      readOnly: true
+      - hostPath: /tmp/metadata-audit-policy.yaml
+        containerPath: /etc/kubernetes/policies/audit-policy.yaml
+        readOnly: true
     #@ end
+#! Apply these patches to all nodes.
+kubeadmConfigPatches:
+- |
+  kind: ClusterConfiguration
+  apiServer:
+    extraArgs:
+      #! To make sure the endpoints on our service are correct (this mostly matters for kubectl based
+      #! installs where kapp is not doing magic changes to the deployment and service selectors).
+      #! Setting this field to true makes it so that the API service will do the service cluster IP
+      #! to endpoint IP translations internally instead of relying on the network stack (i.e. kube-proxy).
+      #! The logic inside the API server is very straightforward - randomly pick an IP from the list
+      #! of available endpoints. This means that over time, all endpoints associated with the service
+      #! are exercised. For whatever reason, leaving this as false (i.e. use kube-proxy) appears to
+      #! hide some network misconfigurations when used internally by the API server aggregation layer.
+      enable-aggregator-routing: "true"
+#@ if data.values.enable_audit_logs:
+- |
+  kind: ClusterConfiguration
+  apiServer:
+      #! enable auditing flags on the API server
+      extraArgs:
+        audit-log-path: /var/log/kubernetes/kube-apiserver-audit.log
+        audit-policy-file: /etc/kubernetes/policies/audit-policy.yaml
+      #! mount new files / directories on the control plane
+      extraVolumes:
+        - name: audit-policies
+          hostPath: /etc/kubernetes/policies
+          mountPath: /etc/kubernetes/policies
+          readOnly: true
+          pathType: "DirectoryOrCreate"
+        - name: "audit-logs"
+          hostPath: "/var/log/kubernetes"
+          mountPath: "/var/log/kubernetes"
+          readOnly: false
+          pathType: DirectoryOrCreate
+#@ end