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:
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
--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.