云原生|Operator本质

Why are Operators different than other tools out there?
Operators are purpose-built to run a Kubernetes application, with operational knowledge baked in. They will be smarter and more tailored than generic tools.

The cloud-like capabilities that are encoded into the Operator code can provide an advanced user experience, automating such features as updates, backups and scaling. All of this is accomplished using standard Kubernetes tools, CLI and API.

What are benefits of using the Operator Framework?
If you are a community member, builder, consumer of applications, or a user of Kubernetes overall, the Operator Framework offers a number of benefits. Operators are built on top of a common set of Kubernetes APIs. They act like cloud services, make it more simple to install and update Kubernetes applications, without having to worry about the underlying platform.

Operators helps your teams to build a great automation experience. They allow teams to build in expertise of automated operations, instead of building manually each time.

How does the Operator Framework make hybrid cloud easier?
For consumers of applications across the hybrid cloud, keeping those applications up to date as new versions become available is of supreme importance, both for security reasons and for managing the applications’ lifecycles and other needs. The Operator Framework helps address these user requirements, aiding in the creation of cloud-native applications that are easier to consume, to keep updated, and to secure.

Who builds an Operator?
Operators are best built by those that are experts in the “business logic” of installing, running and upgrading an application.

Experience has shown that the creation of an Operator typically starts by automating an application’s installation and self-service provisioning capabilities, and then evolves to take on more complex automation.

Who deploys an Operator?
Operators are deployed by end-users through the Lifecycle Manager. Common patterns are for centralized infrastructure teams to grant access to a team’s Namespaces to run specific Operators. Afterwards, each team can manage, upgrade and scale their Operators in a self-service manner.

Operators can package internal applications at an enterprise, software that is deployed by commercial customers, or popular open source projects. Operators can even power a SaaS environment with a large amount of individual instances of an application.

Does an Operator require Kubernetes?
Yes, Kubernetes is required, but range of versions/distros are supported. The goal is to provide tooling to build Kubernetes applications, Operators, that are independent to a specific vendor or cloud platform.

Do I always need to write my own Operator to get value out of the Operator Framework?
You do not need to write your own Operator in order to get value out of the Operator Framework. Operators can be written such that they can be reused for applications. This means that you can, for example, create a generic Helm Operator that can be specialized for individual Charts. Even applications that do not require more than the built-in Kubernetes Workloads APIs can benefit from the lifecycle management and unified user-experience provided by the Operator Framework.

How do I join the community or help out?
All core components are part of a dedicated GitHub organization called “Operator Framework”. Please join the Operator Framework mailing list for discussion, questions and comments. Please also review and assist community operators as listed here and here.