Skip to content
Kannika

    Announcing the 0.12.0 Release

    This new release introduces preflight checks for restores, schema mapping support in the console, a monitoring sidecar for backups, Kubernetes RBAC support, a dark mode, and more!

    Installation

    For new installations, see the Installation guide.

    For upgrading existing installations, see the associated Upgrading to 0.12.x guide.

    Preflight checks

    To prevent common issues during restores, we’ve added preflight checks to Restores. These checks will proactively identify potential issues before you initiate the restore process, helping you avoid unexpected errors.

    Restore checks
    Restore checks
    Topic checks
    Topic checks

    Checks that have been added, include:

    • if the topic exists in the target cluster
    • if the topic is empty in the target cluster
    • if the topic exists in the Backup
    • if the topic can be written to
    • if the connection to the target cluster works

    We will continue to improve the restore experience in future releases by adding more checks (e.g. checking the maximum message size settings and if the amount of partitions in the backup and in the target cluster match).

    Schema Mapping

    A new Schema Mapping tab is available for Restores. This tab allows you to define and update a schema mapping for the restore process, supporting the already existing Schema Mapping feature, which was only available via the Kubernetes API.

    Schema mapping
    Schema mapping

    Even though this is a very basic initial version, this is the first step of a larger effort to add support for mapping schemas in the console. In future releases, you will be able to:

    • view more information about the schemas (e.g. subjects, references, etc.),
    • generate schema mappings, leveraging the existing SchemaRegistry and SchemaRegistryBackup resources.
    • restore schemas back to a schema registry

    Updated naming strategy for Kannika Armory resources

    When defining Backups or Restores, Armory would create child resources in Kubernetes to make the workload run such as ConfigMaps or Jobs. These used to be named after their parent resource, ie. a Backup called flights would generate a ConfigMap called flights to hold its configuration.

    This behavior was inconvenient as the likelihood for naming conflicts with user-defined resources is high. Therefore, we’ve updated the naming strategy for child resources to include the UUID of the parent Backup or Restore.

    Parent and child resources are now linked via a label instead of their names. For instance, all resources belonging to a Backup, as well as the Backup itself, will share a io.kannika/backup label.

    Namespace isolation (BREAKING CHANGE)

    To improve the security of the cluster where Armory runs, the new version of Armory defaults to Role and RoleBinding resources, instead of cluster-wide ClusterRole and ClusterRoleBinding resources.

    Note that these are not mutually exclusive, and you can enable both namespaced and cluster-wide RBAC resources at the same time.

    To properly support namespace isolation, the new version of Armory now allows you to specify the namespace that the whole platform will watch.

    Before this version, the operator would work across all namespaces, while the API would work in a single namespace defined by the api.config.kubernetes.namespace or global.kubernetes.namespace configuration settings.

    To streamline the behavior of the operator and the API, we have:

    • removed support for the api.config.kubernetes.namespace
    • made the operator watch the same namespace as the API specified by the global.kubernetes.namespace key.

    If the global.kubernetes.namespace key is not set, it will default to the release namespace (e.g. kannika-system).

    Support for multiple namespaces will be added in a future release.

    Kubernetes RBAC Learn how to configure Kubernetes RBAC
    Namespaces Learn how to configure namespaces

    Monitoring sidecar for backups

    A common practice with backups is to check if the backup still works. The worst time to find out that a backup is broken is when you need it the most.

    To help you keep an eye on your backups, we’ve added a monitoring sidecar to the backup pod. This sidecar will periodically check if the backup is still working as expected by running checks. If the sidecar detects an issue, it will log an error message.

    One of the checks that the sidecar will run is if the backup for a topic is progressing, compared with the EventHub. It will do this by comparing offsets in the backup with the offsets of the topic in the EventHub.

    In the future, more checks will be added to the sidecar, and

    Dark mode

    A new dark mode is available in the console.

    Dark mode
    Dark mode
    Light mode
    Light mode

    By default, the console will use the system’s theme, but you can manually switch between light and dark mode. Toggle between modes from the user menu in the bottom left corner.

    Toggle dark mode
    Toggle dark mode

    Other changes

    • The backup process’ architecture has been revised. This change was motivated by the significant amount of memory used by large backups. As of 0.12, expect a noticeable drop in memory usage at a slight performance cost under heavy load. Should you notice a Backup not being able to keep up with the amount of records produced, please try the worker group feature out.

    • The id field of a Restore has been renamed to name in the GraphQL and REST API to align with the naming of other resources. An alias has been added to maintain backward compatibility.

    • The operator will now use JSON logging by default. A new operator.config.logging.format setting has been added to allow configuring the logging format with json or text as possible values.

    • Topics recently added to a Restore will no longer be auto-selected, but a button will be shown to select them instead.

    • The console will show the amount of lag for each topic in the Topics tab of a Backup.

    • The console will show the total lag of a Backup.

    • A new /rest/restores/{name}/metrics endpoint has been added to the REST API to get the metrics of a Restore.

    Bug fixes

    • When using the payload-schema-mapping plugin, tombstone records will retain their null payload instead of being restored with an empty byte array.

    • When using the key-schema-mapping plugin, keyless records will retain their null key instead of being restored with an empty byte array.

    • Backup tasks will now be restarted on global Kafka errors (e.g. BrokerNotAvailable), as librdkafka does not recover properly from these errors.

    • The console will now honor the console.config.security.enabled setting when it is set to false and will no longer display a login screen.

    Breaking changes

    • The operator will only look for a license secret in the release namespace (e.g. kannika-system). If you have a license in a different namespace, you will need to move it to the Helm release namespace.

    • The platform will only watch for resources in the namespace defined by global.kubernetes.namespace, which defaults to the Helm release namespace.

    • The platform will default to Role and RoleBinding for Kubernetes RBAC.

    Release Notes

    For a full list of changes, see the Changelog.