Release notes

v0.0.3

Summary

Structured documentation and release information. Split operator controller and webhooks into separate deployments.

Highlights

• Release notes/changelog flow is now bilingual and CI-automated.
• Split operator controller and webhooks into separate deployments.

v0.0.2

Fixes

CRDs are now also stored in the module repository at managed-clickhouse-d8/crds

Added annotations for webhooks:

• werf.io/deploy-dependency-deployment
• werf.io/deploy-dependency-service

v0.0.1

Basic capabilities for deploying and managing Clickhouse nodes in a DKP cluster have been implemented.

Creating standalone Clickhouse servers

Added a new Clickhouse CRD that allows deploying independent Clickhouse nodes. When creating the resource, the user specifies compute resources (CPU, memory) and storage parameters.

Configuration templates via ClickhouseClass

Added the ClickhouseClass CRD, which allows administrators to create named templates for nodes. A class defines the allowed resource policy (CPU and memory ranges).

Validation via webhooks

All create and update operations on Clickhouse and ClickhouseClass resources go through admission webhooks. The webhooks validate parameter correctness: allowed CPU and memory ranges, as well as custom rules defined by the administrator.

Custom CEL validation rules

Administrators can define arbitrary validation rules for Clickhouse resources in a ClickhouseClass using CEL (Common Expression Language) expressions. The rules are checked by the webhook on every creation or modification of a Clickhouse instance, allowing organization-specific constraints to be implemented without changing the operator’s code.

Distroless image support

Clickhouse images are based on a distroless architecture, which improves security by minimizing the number of components in the container.

Server TLS certificate support

TLS certificate support has been implemented for:

• Clickhouse server TLS

Two certificate management modes are supported:

• CertManager — issuing and managing certificates via cert-manager
• CustomCertificate — using a user-provided Kubernetes Secret with certificates

Example configuration:

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: Clickhouse
metadata:
  name: clickhouse-sample
spec:
  tls:
    mode: CertManager
    certManager:
      clusterIssuerName: selfsigned
  clickhouseClassName: default
  instance:
    memory:
      size: "4Gi"
    cpu:
      cores: 1
      coreFraction: "75%"
    persistentVolumeClaim:
      size: "4Gi"
      storageClassName: local