toggle quoted messageShow quoted text
Easy and simple/simply are words to be avoided in definitions, especially in the K8s space. :-)
Thank you so much to Matt for driving this discussion. Is there a working definition at this point that incorporates this discussion into Matt's original definition? I feel that recap will help drive this towards done.
On Sat, Nov 9, 2019 at 10:28 PM Li, Xiang <x.li@...
“Easy” is relative. At least Kubernetes makes it easier than some other environments to achieve the defined model.
But yes, managing the complex app is the hard part. No one says k8s can make that part very easy. Managing app is different than achieving the management model.
日 期：2019年11月10日 11:03:49
抄 送：cncf-sig-app-delivery<cncf-sig-app-delivery@...>; Tobias Knaup<tobi@...>; Zhang, Lei<lei.zhang@...>
主 题：Re: [cncf-sig-app-delivery] Operator Definition
I disagree with the last paragraph of this reply - or the characterization in how it applies to existing operators. Strimzi is a CNCF example where these points are made true — and Kubernetes offers a model but doesn’t necessarily make it easy.
That said, the definitions are in line with my understanding of an operator. I want to contribute perspective indirectly with the intent to help this conversation...
The concept of providing state in a declaratively, irregardless of implementation is a key tenet to how we model systems and implement it in Kubernetes. So far this community has defined APIs in terms of Kubernetes-style object models or resources, which we have collectively and silently termed as “declarative” for our use across projects. Maybe there’s something to be said in that, and taking a cue from Cloud Events, determining what we expect an operator to be from the resource model and applying it to implementations?
That’s not to say we should suddenly start writing a CRD, but we should start creating a well-specified model and extract the definition from that.
Reading through it, this sounds still very generic. I’d like to start talking with existing operators and end users to understand their views of how this model could advance the state of services they feel “need” operators and expand it to our pending definition.
I’m happy to own this data collection with the SIGs blessing and push it into the outstanding issue/PR.
On Nov 9, 2019, at 9:27 PM, Li, Xiang <x.li@...> wrote:
While we could extend Operator concept developed at CoreOS to non Kubernetes platforms, but there are a few implicit key points that we must preserve. Or we are defining something else.
1. Operator keeps the desired state of the managed workload. The API of an operator is declarative not imperative.
2. Operator is reactive and mostly automatic. It follows the observe, diff, act pattern from Kubernetes generic controllers.
3. Operator embeds the domain knowledge for a specific workload operation into code. This makes an operator different from a controller.
Kubernetes environment just makes all three easy. Yes, there are so called x-operator in Kube-world but they do not try to achieve the 3 key points. Most of them should be called installer or deployer instead I guess...
日 期：2019年11月09日 21:30:08
抄 送：Zhang, Lei<lei.zhang@...>; <cncf-sig-app-delivery@...>
主 题：Re: [cncf-sig-app-delivery] Operator Definition
"An operator is software that manages routine procedures and lifecycle
operations of workloads."
Isn't also the case that an operator *delegates some of this
responsibility* to the orchestrator? Or, "leverages the
On Fri, Nov 8, 2019 at 10:42 PM Tobias Knaup <tobi@...> wrote:
> +1 for workload and for a concise definition like Devdatta proposed.
> I found that most people get it when I explain operators as "runbooks as code". Especially when I talk to folks that don't know advanced concept like CRDs yet.
> So based on what was said here earlier and the Wikipedia article on runbooks an operator could be defined as:
> "An operator is software that manages routine procedures and lifecycle operations of workloads."
> A Kubernetes operator could be defined with a bit more detail:
> "A Kubernetes operator is a controller that manages routine procedures and lifecycle operations of workloads."
> - Tobi
> On Fri, Nov 8, 2019 at 12:09 PM alexis richardson <alexis@...> wrote:
>> +1 for workload. I think application will eventually have a definition we can all get behind, and it will be different.
>> On Fri, 8 Nov 2019, 19:20 Zhang, Lei, <lei.zhang@...> wrote:
>>> After reading thru the thread, I tend to agree "workload" reads more accurate than "application" in Operator Framework's case.
>>> The difference here seems to be: "how to run" vs "what to run".
>>> Lei Zhang (Harry)
>>> Alibaba Group
>>> ------------------Original Mail ------------------
>>> Sender: <cncf-sig-app-delivery@...>
>>> Send Date:Fri Nov 8 10:41:00 2019
>>> Recipients: <cncf-sig-app-delivery@...>
>>> CC: <cncf-sig-app-delivery@...>
>>> Subject:Re: [cncf-sig-app-delivery] Operator Definition
>>>> I agree with Matt and Doug that the scope of the definition need not be specific to Kubernetes. Given this SIG is at the CNCF level, aren't we responsible for defining these things broadly across the industry for cloud native in general? We could create a general definition to state what an operator is, and then offer definitions specific to platforms that define how it works on said platform, or leave that up to those projects to define for themselves.
>>>> For example, the general definition of operator could be something along the lines of Devdatta's proposal or the first sentence of Matt's proposal without mentioning Kubernetes specifics:
>>>> "An operator is a platform extension that creates, configures, and manages the lifecycle of workloads."
>>>> The Kubernetes operator definition defines how the pattern works specifically on Kubernetes:
>>>> "A Kubernetes operator is an extension to the Kubernetes API that builds upon the basic Kubernetes resource and controller concepts but includes domain-specific knowledge to automate common tasks for a given workload."
>>>> This has a few benefits:
>>>> The general definition can be applied to systems where the pattern already exists using that system's specific constructs and terminology.
>>>> It should be easy enough to understand the general concept without getting into platform-specific details. "I have a Redis operator for platform X" gets the point across without getting into the details of platform X.
>>>> Platform-specific definitions can follow the general pattern in a way that is familiar and easy to understand for the platform's users. "I have a Redis operator for Kubernetes" denotes how the operator works specifically in Kubernetes, so you know exactly what this means in the context of Kubernetes, but even if you're not familiar with Kubernetes, you at least have an idea of what it means from the general definition.
>>>> Side note: Quinton mentioned earlier that the use of "application" here may be somewhat misleading. I tend to agree with that and so I used "workload" as a more general term.