ADR008: Allow Reuse of Existing Kubernetes Operators

  • Status: approved

  • Deciders:

    • Florian Waibel

    • Lars Francke

    • Oliver Hessel

    • Sönke Liebau

  • Date: 15.01.2021

Context and Problem Statement

For some of the tools we plan to integrate there are existing operators that deploy these tools on Kubernetes. Most notably these tools are:

  • Spark

  • Kafka

Some implementation effort may be avoided by reusing these operators instead of recreating the tool-specific functionality that is already implemented. Since these operators are designed to work with Kubernetes and thus exclusively focused on containers some translation of data structures and processes would be necessary.

Decision Drivers

  • Keeping the implementation effort as low as realistically possible

  • Keeping compatibility with Kubernetes as far as possible to ease a later move towards Kubernetes deployments

  • Avoid hard dependencies on external projects that may force us to fork in case they break compatibility with us

Considered Options

  • Allow reuse of Kubernetes operators (would need to be decided individually for every tool)

  • Don’t reuse operators

Decision Outcome

Chosen option: "Don’t reuse operators", because the core value proposition of Stackable is that customers can get all tools from one place. This sort of implies that everything looks, feels and behaves the same, which would be very tough to ensure when depending on external projects that all behave differently.

Even just looking at the two potential Kafka operators: Strimzi and Banzai, they choose substantially different approaches and adapting either one to our needs would have created substantial effort.

Positive Consequences

  • All components deployed by us will adhere to a common standard, behavior and config set

  • We can reuse core components for all operators

    • Operator framework

    • Config management framework

Negative Consequences

  • A lot of effort and functionality has been implemented in existing operators, which we will effectively need to duplicate

Pros and Cons of the Options

Allow reuse of Kubernetes operators

  • Good, because it saves implementation effort

  • Good, because this forces us to consider Kubernetes compatibility repeatedly

  • Bad, because we create a dependency on another project that may at some point break compatibility

  • Bad, because we need to adapt to interfaces that have been designed specifically with containers in mind

Don’t reuse operators

  • Good, because it allows us to build our operators the way that works best for us

  • Good, because we do not depend on the quality of external projects that may have implemented partial functionality (i.e. security)

  • Bad, because we repeat work that has already been done

Links