Kubernetes · Developer Preview

Kubernetes Operator

Declarative cluster reconciliation, node pool orchestration, rolling upgrades, and automated partition rebalancing via krabka-operator.

Developer Preview Notice: krabka-operator is under active development. Core Kafka cluster reconciliation, custom resource definitions, and Helm deployment charts are published.

The krabka Operator reconciles standard Kubernetes Custom Resource Definitions (CRDs) into running StatefulSets, headless Services, ConfigMaps, TLS Secrets, and broker configurations. Cluster topology is decoupled across Kafka (cluster-wide version, listeners, CA) and KafkaNodePool (roles, replicas, storage claims).

Sample Kafka & NodePool Manifest

A minimal krabka.io/v1alpha1 configuration declaring a three-broker combined Controller/Broker quorum with persistent volume storage:

Kafka & KafkaNodePool CRDs:

apiVersion: krabka.io/v1alpha1
kind: Kafka
metadata:
  name: demo
  namespace: default
spec:
  kafkaVersion: "4.0.0"
  listeners:
    - name: plain
      port: 9092
      type: internal
      tls: false
    - name: tls
      port: 9094
      type: internal
      tls: true
  interBrokerListenerName: plain
  authorization:
    type: simple
    superUsers: ["ANONYMOUS"]
---
apiVersion: krabka.io/v1alpha1
kind: KafkaNodePool
metadata:
  name: brokers
  namespace: default
  labels:
    krabka.io/cluster: demo
spec:
  roles: [Controller, Broker]
  replicas: 3
  nodeIdStart: 0
  storage:
    type: PersistentClaim
    size: 50Gi
    deleteClaim: true

Custom Resource Definitions (CRDs)

All custom resource definitions managed by the operator in API group krabka.io/v1alpha1:

Open the CRD explorer → Find fields in all eight resources. Check nested types, required fields, defaults, allowed values, and validation rules.

Kind	Declared Responsibility
Kafka	A cluster: version label, listeners, cluster and clients CA, authorization, metrics, tiered storage
KafkaNodePool	A pool of nodes with its own roles (Controller, Broker), replicas, image, resources, and storage
KafkaTopic	A topic, its partition count, replication factor, and configuration
KafkaUser	A principal, its authentication (SCRAM-SHA-256/512, TLS, externally managed TLS, delegation token), ACLs, and quotas
KafkaConnector	A PostgreSQL CDC source connector (postgresSource)
KafkaRebalance	A partition rebalance request (full, addBrokers or removeBrokers), served by the krabka-rebalancer
SchemaRegistry	A Confluent-compatible schema registry deployment
KafkaGrpcGateway	A gRPC gateway deployment

Approve a rebalance

Create a KafkaRebalance with the krabka.io/cluster label. The operator asks the rebalancer for a proposal and reports ProposalReady in status.conditions. Read status.optimizationResult before approval.

kubectl get kafkarebalance demo-rebalance -n default -o yaml
kubectl annotate kafkarebalance demo-rebalance -n default krabka.io/rebalance=approve --overwrite
# Recompute a proposal or stop an execution:
kubectl annotate kafkarebalance demo-rebalance -n default krabka.io/rebalance=refresh --overwrite
kubectl annotate kafkarebalance demo-rebalance -n default krabka.io/rebalance=stop --overwrite

The state moves through PendingProposal, ProposalReady, and Rebalancing to Ready or NotReady. A stopped execution reports Stopped. The removeBrokers mode needs a bearer token in a Secret in the resource's namespace. Set spec.authorizationSecretRef, or use the derived Secret <cluster>-rebalancer-auth with key token.

Use gateway documentation with the KafkaGrpcGateway reference to configure gRPC access and webhook ingestion.

Component images: With the operator chart and no spec.image, a KafkaConnector runs ghcr.io/krabka-io/krabka-connect-worker:v0.4.1 and a KafkaGrpcGateway runs ghcr.io/krabka-io/krabka-gateway:v0.5.0. Both tags are published on ghcr.io. Set spec.image on the resource, or connectorImage and gatewayImage in the chart values, to use another tag, a digest, or a mirror. The SchemaRegistry default, krabka-schema-registry:0.4.1, is published.

Scope & Architectural Boundaries

krabka-operator is scoped strictly to Kafka broker and cluster components. The Postgres-compatible compute substrate (gres) is managed separately from the CRDs listed above.

Installing via Helm

Deploy the operator using the official Helm chart. The chart installs the CRDs from its own crds/ directory on first install; Helm does not update them on upgrade, so apply them again from the chart you upgrade to (see the chart's install notes). The quickstart runs the same install end to end with pinned images:

Helm Installation:

# Add Helm chart repository and install the operator
helm repo add krabka https://krabka.io/charts
helm repo update
helm install krabka-operator krabka/krabka-operator --version 1.0.1 \
  --namespace krabka-system --create-namespace

Helm Chart Repository →

GPG signing key, chart index, and verification instructions for krabka charts.

Operator Feature Tour →

Overview of rolling upgrades, CRD reconciliation, and automated partition rebalancing.