Waiting for Readiness
In some scenarios, simply creating objects during initialization is not enough. You may need to wait for
certain resources to become ready before the init-agent marks the workspace as initialized. For example,
a CRD must be Established before custom resources using it can be created by other initializers
further down the chain.
The initialization.kcp.io/wait-for-ready annotation allows you to express this requirement on
individual manifests.
How It Works
When the init-agent encounters a manifest (from any of its init sources) with
the initialization.kcp.io/wait-for-ready annotation, it will:
- Create (or confirm the existence of) the object as usual.
- Re-fetch the object's current state from the API server.
- Check whether the condition type specified in the annotation's value has
status: "True"in the object'sstatus.conditionslist. - If the condition is not yet
True, the agent requeues reconciliation and tries again after a few seconds. - Only once all annotated objects across all sources have their required conditions met will the agent remove the initializer from the workspace, completing initialization.
The annotation value must be the name of a condition type (e.g. Established, Ready,
Available). This condition must appear in the standard Kubernetes status.conditions array of
the resource.
Important
Waiting for a condition to become True inherently means that some process must set that
condition. In some cases this happens automatically (e.g. the Kubernetes API server sets
Established on CRDs), but in other cases you may need a dedicated controller or operator to
act on the resource and update its status.
Due to the nature of kcp's workspace initialization, the workspace is not accessible through
the regular API while it still has initializers. Only processes that work through the same
initializingworkspaces virtual workspace – i.e. processes that are registered for the same
initializer as the init-agent – can see and modify objects in the workspace during
initialization.
This means that if you need an external controller to make a resource "ready", that controller
must also operate on the same initializer's initializingworkspaces view. Without this, the
controller will not be able to access the workspace and therefore cannot set the condition the
init-agent is waiting for. The initialization would be stuck indefinitely.
In practice, this is most relevant for custom operators that need to reconcile resources created by the init-agent. Make sure these operators have the appropriate kcp permissions and are configured to watch the same initializing workspaces.
Usage
Add the annotation to any manifest inside an InitTemplate's spec.template. The following example
creates a CRD and waits for it to become Established before initialization is considered complete:
apiVersion: initialization.kcp.io/v1alpha1
kind: InitTemplate
metadata:
name: widgets-crd
spec:
template: |
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: widgets.example.com
annotations:
initialization.kcp.io/wait-for-ready: "Established"
spec:
group: example.com
names:
kind: Widget
listKind: WidgetList
plural: widgets
singular: widget
scope: Cluster
versions:
- name: v1alpha1
served: true
storage: true
schema:
openAPIV3Schema:
type: object
In this example the init-agent will create the CRD and then wait until its Established condition
is True before considering this source complete. CRDs are just a nice example of a Kube-native
resource that on its own becomes ready.
The agent will keep retrying indefinitely. If a condition is never set, the workspace will remain in the initializing state. Use kcp's workspace lifecycle management to handle stuck workspaces if necessary.
The annotation works with any Kubernetes resource that follows the standard conditions pattern in its status. Common examples include:
| Resource | Typical Condition |
|---|---|
CustomResourceDefinition |
Established |
Deployment |
Available |
APIBinding (kcp) |
Ready |