I've asked the same question in the kubernetes capz channel, and they asked to create a github issue to track this. https://github.com/kubernetes-sigs/cluster-api-provider-azure/issues/5511 Still, if anybody has any information I'd appreciate it!

the initial provisioning should work if you use the provided ClusterClass, the nodes will just be tainted until the ccm is installed

@limited-football-68766 I finally got around to revisiting this and Im having good success. Thanks for getting that PR into the cluster-api-provider-azure github project! They have not released a version with your fixes in yet, so I did have to build the provider components and images locally for now. I have a cluster running in azure now with the rke2 controlplane/bootstrap providers, which is a huge success! The only thing I had to do was to change the health check probe on the control plane loadbalancer from an HTTPS probe to a TCP probe. I had to do that manually. The HTTPS probe was trying to hit a /readyz endpoint on the node, which is not served up by RKE2 (as far as I am aware). Is that something you ran into in your testing?

I could not find anything in the updated CRD spec(s) to override the health check probe.

FYI I also tried building the Azure provider with the latest changes and I managed to succeed. I already prepared a PR: https://github.com/rancher/turtles/compare/fix_azure_rke2_registration_method Mainly by not defining the RKE2 registrationMethod (will default to control-plane-endpoint) and adding the additional rule to AzureCluster:

apiVersion: <http://infrastructure.cluster.x-k8s.io/v1beta1|infrastructure.cluster.x-k8s.io/v1beta1>
kind: AzureClusterTemplate
metadata:
  name: azure-cluster
spec:
  template:
    spec:
      identityRef:
        apiVersion: <http://infrastructure.cluster.x-k8s.io/v1beta1|infrastructure.cluster.x-k8s.io/v1beta1>
        kind: AzureClusterIdentity
        name: cluster-identity
      networkSpec:
        subnets:
        - name: control-plane-subnet
          role: control-plane
          securityGroup:
            securityRules:
            - action: Allow
              description: Allow port 9345 for RKE2
              destination: '*'
              destinationPorts: "9345"
              direction: Inbound
              name: allow_port_9345
              priority: 2203
              protocol: Tcp
              source: '*'
              sourcePorts: '*'
        - name: node-subnet
          natGateway:
            name: node-natgateway
          role: node
        additionalAPIServerLBPorts:
        - name: rke2
          port: 9345

apiVersion: <http://controlplane.cluster.x-k8s.io/v1beta1|controlplane.cluster.x-k8s.io/v1beta1>
kind: RKE2ControlPlaneTemplate
metadata:
  name: rke2-control-plane
spec:
  template:
    spec:
      rolloutStrategy:
        type: "RollingUpdate"
        rollingUpdate:
          maxSurge: 1
      agentConfig: {}
      serverConfig:
        cni: none
        cloudProviderName: external
        disableComponents:
          kubernetesComponents:
          - cloudController
        kubeAPIServer:
          extraArgs:
          - --anonymous-auth=true
      files:
        - owner: root:root
          path: /etc/kubernetes/azure.json
          permissions: "0644"

But if you find current changes insufficient, feel free to open a PR/issue upstream to look further into that.

Best example of also tested configuration in full is in https://github.com/kubernetes-sigs/cluster-api-provider-azure/blob/main/templates/cluster-template-clusterclass-rke2.yaml, tested in upstream e2e tests. If it misses something, we should look into that too.