If you are using Kubernetes Config Connector to manage your Google Cloud objects, then you know these objects behave just like any Kubernetes objects. The configuration is declarative, idempotent, eventually-consistent and self-healing. It also means, that you can use standard commands to wait for Kubernetes Config Connector objects to be ready.
Why do we ever need to wait? With eventual consistency comes uncertainty. How do we know when the object is finally ready? Luckily, Kubernetes has a standard solution to this: kubectl wait.
It works well with Config Connector objects and lets you automate the scenarios, where you would like to ensure, that your script executes the next command in your script only when the object is ready. Here’s an example of waiting for SqlDatabase:
kubectl wait --for=condition=Ready sqlinstance/wp-db --timeout=15m
Default timeout is 30s. Negative timeout value means to wait for a week. In my scripts I’m using something meaningful, like 15m, when usually it takes 5m. This is to avoid having to wait longer than needed, when there’s an issue that needs to be investigate. And I would not recommend waiting for a week (negative timeout).
If all parts of your configuration are purely declarative, then you don’t need to wait. Just running kubectl apply on the folder takes care of it. In reality, however, you do often have components that still need imperative setup. For example, in my WordPress example, I have to use gcloud command due to a bug, which requires me to wait for iamserviceaccount to be ready:
kubectl wait --for=condition=Ready iamserviceaccount/sql-wp-sa --timeout=30m
Using --for=condition=Ready works consistently to wait for Kubernetes Config Connector objects to be ready. Special effort was done to ensure that this is consistent across all objects.