More Related Content Similar to DevOpsCon Berlin: Helm vs Operators – Do I Need to Decide? (20) More from Nico Meisenzahl (12) DevOpsCon Berlin: Helm vs Operators – Do I Need to Decide?2. Nico Meisenzahl
• Senior Cloud & DevOps Consultant at white duck
• Microsoft MVP, Docker Community Leader &
GitLab Hero
• Container, Kubernetes, Cloud-Native & DevOps
© white duck GmbH 2021
Phone: +49 8031 230159 0
Email: nico.meisenzahl@whiteduck.de
Twitter: @nmeisenzahl
LinkedIn: https://www.linkedin.com/in/nicomeisenzahl
Blog: https://meisenzahl.org
3. Agenda
• Do I need to decide?
• How do Helm and Operators differ?
• Real-world examples
• How to build an Operator
© white duck GmbH 2021
4. Do I need to decide?
© white duck GmbH 2021
5. Do I need to decide?
No!
We need different tools and methods to tackle different use
cases. They can also complement each other.
These use cases range from installing a small app to
operating a complex stateful application.
© white duck GmbH 2021
6. What is Helm?
• “The package manager for Kubernetes”
• simplifies our application deployments by focusing on
templatization, reusability
• we can use it for our own apps or benefit from a big
ecosystem
Note: Helm is just one (the most common) example of a
variety of similar tools.
© white duck GmbH 2021
7. What Helm helps with
• allows us to define, package, customize our applications
• supports us installing, upgrading and deleting stateless
applications
• enables us to start quickly
• provides us with support for Day-1 operations
Helm does not focus on managing/operating an application.
© white duck GmbH 2021
9. What we still need help with
• maintaining our applications
• housekeeping tasks
• optimizing our exiting applications
• upgrading
• stateful applications
• complex applications with dependencies
• implementing backups, failure recovery
Basically, everything that concerns Day-2 operation.
© white duck GmbH 2021
10. The Operator pattern
… is an application-specific controller that extends the
Kubernetes API to create, configure, and manage instances
of complex stateful applications on behalf of a Kubernetes
user.
The Operator pattern aims to capture the main goal of a
human operator managing a service or set of services.
© white duck GmbH 2021
11. Where an Operator can help
• package human operational knowledge into code
• DRY (don’t repeat yourself)
• automate maintenance & complex operational tasks
• deployments & scaling
• configuration changes, rollouts, upgrades & testing
• backups & restores
• tasks can be translated into declarative input
• diff, act, observe (declarative / desired state)
Offers Kubernetes-native way to automate Day-2 operations.
© white duck GmbH 2021
12. What exactly is an Operators?
• Custom Resource
• a Custom Resource (CR) is an extension of the Kubernetes API
defined by a Custom Resource Definition (CRD)
• Controller
• a Controller monitors the CR type and initiates application-
specific actions to adjust the current state of the resource to the
desired state.
• the Controller runs as a containerized workload within the
Kubernetes cluster
© white duck GmbH 2021
14. Operator vs. Custom Controller
• identical concepts with different domains
• Custom Controller
• understands only Kubernetes’s native abstractions such as
Pod, Deployment, Service, …
• Operator
• Controllers that are part of an Operator also understand
Custom Resource abstractions that the Operator has
introduced
© white duck GmbH 2021
15. When to use Operators
• operate stateful third-party applications
• manage your own complex or stateful applications
• introduce abstraction
• “something” as a service as part of a developer platform
• external resources
© white duck GmbH 2021
16. Some examples (third party)
• Prometheus Operator
• manage Prometheus, Alertmanager, and related components
• Strimzi Kafka Operator
• run and operate Apache Kafka clusters on Kubernetes in various
deployment configurations
• Elastic Cloud on Kubernetes (ECK)
• orchestrate Elastic applications (Elasticsearch, Kibana, APM Server,
…) on Kubernetes
• Crossplane
• provision and manage cloud infrastructure and services
© white duck GmbH 2021
17. Build your own Operator
• using a Kubernetes Client library
• https://github.com/kubernetes/sample-controller
• choose from a variety of tools and frameworks
• kubebuilder
• Operator Framework
• Shell-operator
• KUDO
© white duck GmbH 2021
https://hazelcast.com/blog/build-your-kubernetes-operator-with-the-right-tool/
18. kubebuilder
• provides powerful libraries and tools to simplify building
and publishing Kubernetes APIs from scratch
• focuses on Golang
• fully flexible
• is maintained by Kubernetes SIG API Machinery
© white duck GmbH 2021
19. Operator Framework
• Operator SDK
• software development kit for building Operators
• scaffolding and more higher-level framework with large feature set
• supporting Helm, Ansible and Golang
• Operation Lifecycle Manager (OLM)
• helps install, update, and manage the lifecycle of Operators
• OperatorHub.io
• catalog hosting existing Operators
• by RedHat
© white duck GmbH 2021
20. Shell-operator
• running event-driven scripts in a Kubernetes cluster
• bash, python, kubectl, …
• easy to start with
• ops-focused
• triggered by Kubernetes events, scheduled, or start up
• webhook machinery for AdmissionReview requests & others
• is based on an “universal” controller
• by Flant
© white duck GmbH 2021
21. KUDO
• Kubernetes Universal Declarative Operator
• no coding required
• define Operators as templated YAML manifests
• based on kubebuilder and other community projects
• Operator Repository
• https://github.com/kudobuilder/operators
• also based on an “universal” controller
© white duck GmbH 2021
22. You have to decide
• are you running…
• stateless or stateful/complex applications?
• stateful third-party applications? Do they provide an Operator?
• Operators…
• can help but also introduce complexity
• you need to commit to maintain the Operator code
• have a different focus than Helm; each has strengths and
weaknesses
• Operators & Helm can also complement each other
© white duck GmbH 2021