Release notes

v0.0.4

Summary

Added the ms_changelog process for generating RELEASE_NOTES.md

Highlights

RELEASE_NOTES is now formatted consistently with the other managed services.

v0.0.3

Summary

• Updated meta-operator to v0.0.19

Highlights

• Bundle: CRDs are now taken from the module’s crds/ directory (includePaths: crds). Copying directly from the operator submodule (images/.../crd) was removed.
• Bundle / release: docs/internal is excluded from the delivery.
• Release image (release-channel-version): docs, openapi and crds were added to the release image.

v0.0.2

Summary

• Added TLS support in Managed Kafka

Highlights

• Updated roles for resources in accordance with RBAC v1.
• Updated alpine libraries and fixed CVEs.
• ServiceMonitor for operator metrics (/metrics on port 8080).
• CustomPrometheusRules: operator, broker and instance unavailability; invalid configuration.
• Added the spec.observability field (Enabled / Disabled / EnabledWithoutAlerts). The operator sets the observability.deckhouse.io/servicemonitoring label on child resources to control monitoring at the module level.

v0.0.1

Summary

• First release of Managed Kafka.
• This version provides the basic capabilities for deploying and managing Kafka brokers in a DKP cluster.

Highlights

• Added the new Kafka CRD for deploying standalone Kafka brokers. Each broker runs in KRaft mode, without ZooKeeper. When creating a resource, the user specifies compute resources (CPU, memory) and storage parameters, and selects the broker class.
• All create and update operations on Kafka and KafkaClass resources go through admission webhooks. The webhooks validate parameters: allowed CPU and memory ranges, correctness of overridden configuration parameters, and custom rules defined by the administrator.
• Added the KafkaClass CRD, which lets administrators create named broker templates. A class defines the policy for allowed resources (CPU and memory ranges), default broker configuration parameters, and the list of parameters users may override themselves.
• Users can override broker parameters in Kafka.spec.configuration if the class explicitly allows it.
• Administrators can set in KafkaClass.spec.configuration all user-level parameters (as defaults), as well as advanced broker parameters that are not available to users.
• Administrators also control broker pod placement via nodeSelector, nodeAffinity and tolerations in KafkaClass.
• Administrators can define arbitrary validation rules for Kafka resources in KafkaClass using CEL (Common Expression Language) expressions. The webhook checks the rules on every broker create or update, which allows organization-specific constraints without changing the operator code.