Blog
29 October 2021
Ivan Mikheykin, software engineer

The v1.0 release of addon-operator for Kubernetes brings stable Go hooks and more

We are happy to announce addon-operator v1.0 – the long-awaited major release of our Open Source tool for creating and dealing with add-ons in Kubernetes! addon-operator manages K8s modules based on Helm and capabilities provided by our another tool, shell-operator. The latter is designed to create Kubernetes operators quickly and effortlessly.

Please, refer to the corresponding addon-operator and shell-operator announcements to learn more about these tools.

The first major release of addon-operator introduces a lot of new features. Let’s focus on the most prominent ones.

New features in addon-operator v1.0

General:

  • The HELM_IGNORE_RELEASE variable has been added to enable installing addon-operator using Helm in the same namespace where the modules will be installed (see #176 and the documentation for more info).
  • The executionMinPeriod and executionBurst parameters have been introduced in the hook configuration (inherited from shell-operator, see #257 for more information). They set the maximum execution rate of the hook, enabling it to handle event bursts.
  • The individual Kubernetes client instances have been implemented for hooks, patchers, and Helm resource monitoring. Each client now has its own throttling settings (learn more in the documentation and code). As a result, reducing the frequency of requests from Helm-resource monitors does not slow down events to launch hooks.
  • Helm releases are now deployed faster thanks to changes in the auto-healing mechanism (#234):
    • Helm 3 became a part of addon-operator. The built-in Helm is used if there is no Helm binary in the image. This speeds up the processing of module templates before running them.
    • The Helm resource monitor collects information about resources in the background and terminates when it detects a non-existent resource.
  • Fixed a heisenbug with initializing hook subscriptions: a waiting period for an informer cache to become synced has been implemented. (This one was inherited from shell-operator, #326.)
  • Migrated the codebase to Go 1.16.

About a year ago, addon-operator got support for hooks written in Go. We took advantage of this feature in our Deckhouse Kubernetes platform by rewriting modules in Go. Support for Go hooks has been refined and improved over time, making it no longer experimental (although it is still poorly documented).

As for the Go hooks, the following improvements were implemented for v1.0.0:

  • MetricsCollector has been added to simplify working with metrics (#223, #211).
  • Kubernetes object patches are now collected using PatchCollector and applied after the hook completes (just like regular hooks, #229).
  • Dynamic bindings for Go hooks have been implemented (experimental). The hook can now re-subscribe to other objects while running by changing apiVersion and kind for particular binding or disable the subscription (see #216 for details).
  • Multiple improvements have been made to the inner workings of Go hooks (#212, #210, #206, #200, #196, and others).

Finally, changes in version 1.0.1 released a week later:

  • Messages from Kubernetes clients and helm3lib are redirected to logrus to generate a valid JSON log (#253).
  • Fixed rollback of Pending releases in helm3lib (#254).

The minor shell-operator update (1.0.4) was released together with addon-operator 1.0. The main change was migrating the codebase to Go 1.16 (similar to that of addon-operator).

Looking forward

Currently, both tools are developing in tandem with the Deckhouse Kubernetes platform, being its essential parts. New features are added as the need for them arises in the context of platform development. Despite this, both tools are popular as standalone projects: shell-operator boasts over 1400 stars on GitHub, while addon-operator has 300+. For instance, we are aware that well-known companies such as KubeSphere, Confluent, and Adobe are also using these tools.