The document discusses Kubernetes operators, which are automated software managers that oversee the lifecycle of applications within Kubernetes, enhancing efficiency in deployment and management. It describes how operators work through custom controllers, the use of the Operator SDK for development, and the Operator Lifecycle Manager for managing operator deployments. Best practices for building operators are outlined, emphasizing security, migration, and proper status reporting.

2. installed
configured managed
upgraded

3. Running apps in Kubernetes is
easy

4. Kubernetes is a declarative
platform

5. $ oc scale deploy/web --replicas=3

7. Running them over time is
harder

8. ⏣ Resize/Upgrade
⏣ Reconfigure
⏣ Backup
⏣ Healing

9. “Anything that isn’t automated
is slowing you down”

10. If only Kubernetes knew...

11. WHAT IS AN OPERATOR?
Grant Drop Database

12. WHAT IS AN OPERATOR?

13. WHAT IS AN OPERATOR?

14. Operators are automated
software managers that
manage the entire lifecycle of
Kubernetes applications
WHAT IS AN OPERATOR?

15. Value of Operators
Improve the “time to
first value” for your
customers
Minimize software upgrade
risk and associated
operational costs
Embed best practices
from the experts – you –
into the Operator
Provide a cloud-like "As
a Service" experience

16. HOW DOES AN OPERATOR WORK?
Custom Kubernetes Controller
Watch Events
Reconciliation
+
Custom Resource Definition
Kubernetes Operator

17. Custom Resource
Developer /
OpenShift User
HOW DOES AN OPERATOR WORK?
K8s API
kind: ProductionReadyDatabase
apiVersion:
database.example.com/v1alpha1
metadata:
name: my-important-database
spec:
connectionPoolSize: 300
readReplicas: 2
version: v4.0.1
Custom Kubernetes Controller
Watch Events
Reconciliation
+
Custom Resource Definition
Kubernetes Operator

19. ● Operator SDK - Allows developers to build, package and test an Operator based on
your expertise without requiring all the knowledge of Kubernetes API complexities
● Operator Lifecycle Manager - Helps you to install, and update, and generally manage
the lifecycle of all of the Operators (and their associated services) running across
your clusters
● Operator Metering - Enable usage reporting for Operators and resources within
Kubernetes

20. CATEGORIES OF OPERATORS

21. Ansible SDKHelm SDK Go SDK
Helm Chart
Ansible Playbooks
APBs
Build operators from
Helm chart, without any
coding
Build operators from
Ansible playbooks and
APBs
Build advanced operators
for full lifecycle
management
TYPES OF OPERATORS

22. CAPABILITY LEVELS FOR OPERATORS

23. How does it all work?

24. OPERATOR PROJECT SCAFFOLD AND IMPLEMENTATION
OPERATOR
SDK
KUBERNETES
OPERATOR
+ =
AUTHOR
“create new
operator”
scaffolding custom logic

25. OPERATOR
SDK
KUBERNETES
OPERATOR
+ = +
OPERATOR
LIFECYCLE
MANAGER
“create new
operator”
scaffolding custom logic metadata
package
“make available to”
“list packages”
OPERATOR PUBLISHING
PUBLISHER
ADMINISTRATOR
AUTHOR

26. YourOperator v1.1.2
Bundle
OPERATOR
LIFECYCLE MANAGER
Deployment
Role
ClusterRole
RoleBinding
ClusterRoleBinding
ServiceAccount
CustomResourceDefinition
OPERATOR LIFECYCLE MANAGER: The Operator Operator

27. OPERATOR
LIFECYCLE MANAGER
YourOperator v1.1.2
YourOperator v1.1.3
YourOperator v1.2.0
YourOperator v1.2.2
Subscription for
YourOperator
Time
VersionOperator Catalog
OPERATOR LIFECYCLE MANAGEMENT

28. Red Hat Products
ISV Partners
Community
OPERATOR HUB
Operator Hub - Allows
administrators to
selectively make
operators available from
curated sources to users
in the cluster.

29. ...and many more
OPERATORS ACROSS THE INDUSTRY

30. OPERATOR
SDK
KUBERNETES
OPERATOR
+ = +
OPERATOR
LIFECYCLE
MANAGER
+
USER
“create new
operator”
scaffolding custom logic metadata
package
“make available to”
“list packages”
“subscribe to
channel”
subscriptionnamespaceoperator
instance
managed
application
“Create
application”
SERVICE INSTANTIATION
PUBLISHER
ADMINISTRATOR
+
AUTHOR

31. of Operator-backed Services
Reduce friction for deploying operator
backed applications
●

33. BASIC OPERATOR BEST PRACTICES
● Follow best practices on Container images for running on OpenShift
● Don’t use root
● Use a supported base image (RHEL, UBI) as security in the base images is critical
● Provide meaningful status information when querying the CR’s state
● Support an update/upgrade path for your operator’s resources:
● Your Operator must understand past and future versions of your application in order to
seamlessly transition from one to another.
● Migrations always needs to be done for long lived application installs, eg. if you change
the format of a ConfigMap, the Operator needs to migrate that and keep it up to date.
● What next? After install, upgrade, basic management, monitor Golden Signals: Operator is an
SRE in software

34. Resources
● https://github.com/operator-framework/getting-started
● https://github.com/operator-framework/community-operators
● https://commons.openshift.org/sig/operators.html
● https://groups.google.com/forum/#!forum/operator-framework
● https://operatorhub.io
● https://learn.openshift.com/operatorframework
● Kubernetes Operators, Dobies and Wood, O’Reilly, 2020
○ Compliments of Red Hat here