Your Crossplane may be sleeping

TL;DR I came up with a two-cluster Crossplane lab to test experiment that hopes to show what the communication crossplane has it resources it manages both in a native and remote cluster. Summary of the findings. Native composition cannot reach another cluster. This is not an error, there is just a silent absence. I saw that there is no field for it. You need provider-kubernetes Objects for this mechanism. Readiness reports green for a workload that cannot start. The default policy means "applied successfully" and not that it "works". There are 4 policy options and nothing tells you which one is active. Drift goes uncorrected for ten minutes. The watch field that sounds like it fixes this is alpha, gated, and silently does nothing unless you also pass a flag to the provider pod. Both of those are fixable , with a CEL readiness query and a DeploymentRuntimeConfig . Once configured, drift is caught in about a second and reported honestly. The credential one is not fixable. I rotated a Postgres password directly on the target. Eight green rows across two traces, and FATAL: password authentication failed from inside the application container. Understandable behaviour because a control plane isnt supposed to touch the data plan. But this is worth knowing and understanding The pattern I realised is that the capability exists, but the defaults dont work as you would assume. The status output for good or bad is identical which makes it hard to tell whether you control plane is watching or asleep. Repo: github.com/Joojo7/crossplane-lab Intro Hello my people its me again. A while back I wrote about BYOC in platform engineering , and the argument I kept coming back to was the difference between a control plane that reconciles infrastructure in your account and one that merely references it. I ended that piece with a hands-on path for anyone who wanted to go further, and Crossplane was on it, mostly because it is the most legible open implementation of the reconciling side of th