[BUG] AKS real mode stays Creating after k3s API becomes healthy

[thomhurst]

Summary

With floci/floci-az 0.12.0 running in Docker and AKS real mode enabled, the k3s child becomes healthy but the ARM cluster remains in Creating indefinitely. Consequently listClusterAdminCredential never receives the finalized real kubeconfig.

Reproduction

1. Run floci-az as a container with /var/run/docker.sock mounted read-write.

2. Set FLOCI_AZ_SERVICES_AKS_MOCKED=false.

3. Set FLOCI_AZ_SERVICES_AKS_DEFAULT_IMAGE=rancher/k3s:v1.29.15-k3s1.

4. PUT a managed cluster to:

   /subscriptions/subscription/resourceGroups/sidecars/providers/Microsoft.ContainerService/managedClusters/aks-test?api-version=2024-04-01

5. Poll the same resource for at least two minutes.

Request body:

{
  "location": "eastus",
  "properties": {
    "kubernetesVersion": "1.29",
    "dnsPrefix": "aks-test",
    "agentPoolProfiles": [
      {
        "name": "nodepool1",
        "count": 1,
        "vmSize": "Standard_DS2_v2",
        "osType": "Linux",
        "mode": "System"
      }
    ]
  }
}

Actual behavior

The child starts successfully. Floci logs:

Detected current Docker network for spawned containers: bridge (172.17.0.4)
Started container e38e3c1e...
k3s container e38e3c1e... started for cluster aks-test on port 6,443 (internal: https://172.17.0.5:6443)

The k3s logs show the API server and system pods started. A direct request to the published endpoint proves the API server answers:

GET https://localhost:6443/livez
HTTP/1.1 401 Unauthorized

AksClusterManager.isReady explicitly treats 401 as ready, but every ARM GET continues to return:

{"properties":{"provisioningState":"Creating"}}

No "AKS cluster is now ready" or "Finalized AKS cluster" entry appears.

Expected behavior

The readiness poller recognizes the 200/401/403 response, calls finalizeCluster, persists Succeeded, and listClusterAdminCredential returns the real k3s kubeconfig.

Environment

• floci-az: 0.12.0, image digest sha256:0c673d49bb75b502ea0750f1c1347777483ffc33945539e1d9254438cb441a03
• k3s: rancher/k3s:v1.29.15-k3s1
• Docker Desktop with Linux containers on Windows
• Parent and child network: bridge
• Reproduced by the Testcontainers for .NET FlociAz compatibility suite

Suspected area

AksClusterManager.isReady or native-image HTTPS handling. TCP from the parent to 172.17.0.5:6443 succeeds, and the host-side HTTPS probe returns the response code that isReady accepts, so the failure appears between HttpsURLConnection and the native readiness poller.

[TheXenocide]

Confirmed root cause: AksClusterManager.isReady() polls the k3s /livez endpoint via java.net.URL/HttpsURLConnection, which throws MalformedURLException under GraalVM native-image because the https URL protocol isn't registered for native compilation (Quarkus/GraalVM requires --enable-url-protocols=https explicitly — it's not included by default). The exception is caught by isReady()'s blanket catch (Exception e) { return false; }, so every poll silently reports not-ready regardless of the actual response code — matches exactly what you're seeing (a real 401 from the API server, isReady coded to accept it, but provisioningState never advancing).

This lines up with your own suspicion: the JVM-mode build has no such registration requirement, so this is native-image-specific, not a logic bug in isReady() itself.

Fix: add --enable-url-protocols=https to quarkus.native.additional-build-args in src/main/resources/application.yml, alongside the existing --initialize-at-run-time=... entries. Verified locally — this one line resolves it and lets native-image AKS readiness polling succeed against a real k3s control plane. Happy to open a PR with this plus a regression test if that's useful.