K8S Operator Pattern

Why We Need the Operator Pattern

Kubernetes provides strong support for general-purpose automation such as deployment, scaling, and health checks. However, it does not natively offer domain-specific logic for specialized applications.

For example, if you need to create OpenSearch indices according to specific rules and configure RBAC at the same time, a simple combination of Deployment and ConfigMap will not be sufficient.

This is exactly the type of gap where the Operator Pattern comes into play.

The operator combines Custom Resources (CRs) defined by the user, and Controllers that continuously manage them, to enable application management in a fully Kubernetes-native way.

Desired State vs. Actual State

At the core of Kubernetes lies the philosophy of continuously reconciling the gap between the desired state and the actual state.

For example, if spec.replicas = 3 is set for a Deployment, the controller ensures that the number of running pods remains three at all times.

The operator extends this principle by implementing a specialized controller that manages custom resources.

Get Bohyun Lee’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

In other words,

• It reads the desired state defined in the .spec,
• Compares it with the actual state recorded in .status, and
• Continuously reconciles until both states are aligned.

A more detailed view of the controller workflow looks like this:

1. The user’s request for the desired state is recorded in the .spec of the Custom Resource.
2. The controller attempts to reflect the .spec values into the actual domain resource (e.g., RedisService, OpenSearch).
3. Once the operation succeeds, the controller updates the .status.
4. When .spec == .status, the controller stops further actions.

Core Benefits of the K8S Operator

1. State-oriented Automation
   - Extends Kubernetes’ core philosophy of desired state vs. actual state.
   - Operators continuously reconcile the .spec defined by the user with the .status of the resource, ensuring that even complex operational procedures can be managed declaratively.
2. Application-specific Operational Logic
   - Goes beyond the built-in Kubernetes resources (Pods, Services, Deployments) to address domain-specific requirements.
   - By implementing custom controllers, operators embed application-level operational knowledge, enabling them to manage workloads such as OpenSearch, Kafka, or Redis with Kubernetes-native automation.
3. Kubernetes-native Integration
   - Through Custom Resource Definitions (CRDs), applications can be managed as first-class Kubernetes objects.
   - This allows teams to rely on the familiar Kubernetes API and kubectl commands, ensuring consistency and lowering the learning curve for managing complex applications.

How Operators Work: Controllers and Informers

Operators operate through controllers and informers:

• Informer: Watches the API server for changes and stores them in a local cache.
• Controller: Pulls objects from the cache, performs reconcile logic, and updates the API server.

With this mechanism, cluster resources (Pods, Services, CRs, etc.) can be detected, reconciled, and updated in real time.

Internal Flow of the Controller

The LY Tech Blog provided a detailed explanation of the controller’s internal workings, which clarified the full picture:

1. API Server ↔ etcd: The etcd watcher detects changes and notifies the API server.
2. Reflector → DeltaFIFO → Cache: The Reflector receives events, pushes them into the DeltaFIFO queue, and updates the cache.
3. Event Handler → WorkQueue: When the Reflector sends an event notification, the handler pushes the resource’s namespacedName into the WorkQueue.
4. Reconcile Function: The WorkQueue dequeues the namespacedName, fetches the object from the cache, compares .spec and .status, and performs necessary actions.
5. State Update → API Server: After applying changes, the controller updates .status by sending POST/PUT requests to the API server.

This event-driven, reconcile-based workflow is what makes operators robust and reliable in managing domain-specific resources on Kubernetes.

Reference

• https://www.cncf.io/blog/2022/06/15/kubernetes-operators-what-are-they-some-examples/
• https://kubernetes.io/ko/docs/concepts/extend-kubernetes/operator/
• https://techblog.lycorp.co.jp/ko/define-and-manage-kubernetes-custom-resources-with-controller