Posts on Java Operator SDK

Welcome read-cache-after-write consistency!

Fri, 13 Mar 2026 00:00:00 +0000

TL;DR: In version 5.3.0 we introduced strong consistency guarantees for updates with a new API. You can now update resources (both your custom resource and managed resources) and the framework will guarantee that these updates will be instantly visible when accessing resources from caches, and naturally also for subsequent reconciliations.

I briefly talked about this topic at KubeCon last year.

public UpdateControl<WebPage> reconcile(WebPage webPage, Context<WebPage> context) {
 
 ConfigMap managedConfigMap = prepareConfigMap(webPage);
 // apply the resource with new API
 context.resourceOperations().serverSideApply(managedConfigMap);
 
 // fresh resource instantly available from our update in the caches
 var upToDateResource = context.getSecondaryResource(ConfigMap.class);
 
 // from now on built-in update methods by default use this feature;
 // it is guaranteed that resource changes will be visible for next reconciliation
 return UpdateControl.patchStatus(alterStatusObject(webPage));
}

In addition to that, the framework will automatically filter events for your own updates, so they don’t trigger the reconciliation again.

How to guarantee allocated values for next reconciliation

Thu, 22 May 2025 00:00:00 +0000

Deprecated

Read-cache-after-write consistency feature replaces this functionality. (since version 5.3.0)

It provides this functionality also for secondary resources and optimistic locking is not required anymore. See the docs and related blog post for details.

We recently released v5.1 of Java Operator SDK (JOSDK). One of the highlights of this release is related to a topic of so-called allocated values.

To describe the problem, let’s say that our controller needs to create a resource that has a generated identifier, i.e. a resource which identifier cannot be directly derived from the custom resource’s desired state as specified in its spec field. To record the fact that the resource was successfully created, and to avoid attempting to recreate the resource again in subsequent reconciliations, it is typical for this type of controller to store the generated identifier in the custom resource’s status field.

From legacy approach to server-side apply

Tue, 25 Feb 2025 00:00:00 +0000

From version 5 of Java Operator SDK server side apply is a first-class feature and is used by default to update resources. As we will see, unfortunately (or fortunately), using it requires changes for your reconciler implementation.

For this reason, we prepared a feature flag, which you can flip if you are not prepared to migrate yet: ConfigurationService.useSSAToPatchPrimaryResource

Setting this flag to false will make the operations done by UpdateControl using the former approach (not SSA). Similarly, the finalizer handling won’t utilize SSA handling. The plan is to keep this flag and allow the use of the former approach (non-SSA) also in future releases.

Using k8s' ETCD as your application DB

Thu, 16 Jan 2025 00:00:00 +0000

FAQ: Is Kubernetes’ ETCD the Right Database for My Application?

Answer

While the idea of moving your application data to Custom Resources (CRs) aligns with the “Cloud Native” philosophy, it often introduces more challenges than benefits. Let’s break it down:

Top Reasons Why Storing Data in ETCD Through CRs Looks Appealing

Storing application data as CRs enables treating your application’s data like infrastructure:
- GitOps compatibility: Declarative content can be stored in Git repositories, ensuring reproducibility.
- Infrastructure alignment: Application data can follow the same workflow as other infrastructure components.

Challenges of Using Kubernetes’ ETCD as Your Application’s Database

Technical Limitations:

Data Size Limitations 🔴: