Skip to main content
Back to features overview

Kubernetes native operator

Deploy, scale, and rebalance krabka clusters natively on Kubernetes. The operator watches custom resource definitions (CRDs in group krabka.io/v1alpha1) to automate node pool provisioning, rolling updates, user auth, and partition balancing.

Declarative custom resources (krabka.io/v1alpha1)

The operator watches these custom resources. Their manifests can be applied directly or through GitOps tools such as ArgoCD or Flux:

Kafka

Declares the cluster version label, listeners, authorization, metrics, and tiered storage.

KafkaNodePool

Dedicated pools of broker or controller nodes with distinct CPU/RAM and disk sizing.

KafkaTopic

Declares partitions, replication factor, and topic configuration such as retention.

KafkaUser

Automates SCRAM credential generation, TLS identities, ACLs, and quotas.

KafkaRebalance

Asks krabka-rebalancer for a partition movement plan in full, addBrokers or removeBrokers mode, and executes it once the proposal is approved.

KafkaConnector

Provisions PostgreSQL CDC source connectors.

Sample Kafka and KafkaNodePool CRDs

apiVersion: krabka.io/v1alpha1
kind: Kafka
metadata:
  name: streaming-production
  namespace: streaming
spec:
  kafkaVersion: "4.0.0"
  listeners:
    - name: plain
      port: 9092
      type: internal
      tls: false
    - name: external
      port: 9094
      type: loadbalancer
      tls: true
  interBrokerListenerName: plain
  metricsConfig: {}
---
apiVersion: krabka.io/v1alpha1
kind: KafkaNodePool
metadata:
  name: brokers
  namespace: streaming
  labels:
    krabka.io/cluster: streaming-production
spec:
  roles: [Controller, Broker]
  replicas: 5
  nodeIdStart: 0
  resources:
    requests:
      cpu: "1"
      memory: 512Mi
    limits:
      cpu: "4"
      memory: 2Gi
  storage:
    type: PersistentClaim
    size: 100Gi
    deleteClaim: false

Rolling upgrades and automated rebalancing

Each node pool renders as a StatefulSet with the RollingUpdate strategy, so pods restart one at a time and each must become Ready before the next one cycles. A PodDisruptionBudget with maxUnavailable 1 guards each pool against voluntary disruption.