consistency for capitalization of term operator in documentation (#35753)
* Because operators are not kubernetes objects, the word operators should only be capitlized at the start of sentences, URLs where the external source has done so, abbreviations, or start of headers. * only changing en initially for the pr process * text styling on line 18 for operator pattern
This commit is contained in:
parent
9084afad3c
commit
7c89f5675a
|
|
@ -15,13 +15,13 @@ Kubernetes principles, notably the [control loop](/docs/concepts/architecture/co
|
|||
|
||||
## Motivation
|
||||
|
||||
The Operator pattern aims to capture the key aim of a human operator who
|
||||
The _operator pattern_ aims to capture the key aim of a human operator who
|
||||
is managing a service or set of services. Human operators who look after
|
||||
specific applications and services have deep knowledge of how the system
|
||||
ought to behave, how to deploy it, and how to react if there are problems.
|
||||
|
||||
People who run workloads on Kubernetes often like to use automation to take
|
||||
care of repeatable tasks. The Operator pattern captures how you can write
|
||||
care of repeatable tasks. The operator pattern captures how you can write
|
||||
code to automate a task beyond what Kubernetes itself provides.
|
||||
|
||||
## Operators in Kubernetes
|
||||
|
|
@ -35,7 +35,7 @@ Kubernetes' {{< glossary_tooltip text="operator pattern" term_id="operator-patte
|
|||
Operators are clients of the Kubernetes API that act as controllers for
|
||||
a [Custom Resource](/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
|
||||
|
||||
## An example Operator {#example}
|
||||
## An example operator {#example}
|
||||
|
||||
Some of the things that you can use an operator to automate include:
|
||||
|
||||
|
|
@ -49,7 +49,7 @@ Some of the things that you can use an operator to automate include:
|
|||
* choosing a leader for a distributed application without an internal
|
||||
member election process
|
||||
|
||||
What might an Operator look like in more detail? Here's an example:
|
||||
What might an operator look like in more detail? Here's an example:
|
||||
|
||||
1. A custom resource named SampleDB, that you can configure into the cluster.
|
||||
2. A Deployment that makes sure a Pod is running that contains the
|
||||
|
|
@ -57,36 +57,36 @@ What might an Operator look like in more detail? Here's an example:
|
|||
3. A container image of the operator code.
|
||||
4. Controller code that queries the control plane to find out what SampleDB
|
||||
resources are configured.
|
||||
5. The core of the Operator is code to tell the API server how to make
|
||||
5. The core of the operator is code to tell the API server how to make
|
||||
reality match the configured resources.
|
||||
* If you add a new SampleDB, the operator sets up PersistentVolumeClaims
|
||||
to provide durable database storage, a StatefulSet to run SampleDB and
|
||||
a Job to handle initial configuration.
|
||||
* If you delete it, the Operator takes a snapshot, then makes sure that
|
||||
* If you delete it, the operator takes a snapshot, then makes sure that
|
||||
the StatefulSet and Volumes are also removed.
|
||||
6. The operator also manages regular database backups. For each SampleDB
|
||||
resource, the operator determines when to create a Pod that can connect
|
||||
to the database and take backups. These Pods would rely on a ConfigMap
|
||||
and / or a Secret that has database connection details and credentials.
|
||||
7. Because the Operator aims to provide robust automation for the resource
|
||||
7. Because the operator aims to provide robust automation for the resource
|
||||
it manages, there would be additional supporting code. For this example,
|
||||
code checks to see if the database is running an old version and, if so,
|
||||
creates Job objects that upgrade it for you.
|
||||
|
||||
## Deploying Operators
|
||||
## Deploying operators
|
||||
|
||||
The most common way to deploy an Operator is to add the
|
||||
The most common way to deploy an operator is to add the
|
||||
Custom Resource Definition and its associated Controller to your cluster.
|
||||
The Controller will normally run outside of the
|
||||
{{< glossary_tooltip text="control plane" term_id="control-plane" >}},
|
||||
much as you would run any containerized application.
|
||||
For example, you can run the controller in your cluster as a Deployment.
|
||||
|
||||
## Using an Operator {#using-operators}
|
||||
## Using an operator {#using-operators}
|
||||
|
||||
Once you have an Operator deployed, you'd use it by adding, modifying or
|
||||
deleting the kind of resource that the Operator uses. Following the above
|
||||
example, you would set up a Deployment for the Operator itself, and then:
|
||||
Once you have an operator deployed, you'd use it by adding, modifying or
|
||||
deleting the kind of resource that the operator uses. Following the above
|
||||
example, you would set up a Deployment for the operator itself, and then:
|
||||
|
||||
```shell
|
||||
kubectl get SampleDB # find configured databases
|
||||
|
|
@ -94,19 +94,19 @@ kubectl get SampleDB # find configured databases
|
|||
kubectl edit SampleDB/example-database # manually change some settings
|
||||
```
|
||||
|
||||
…and that's it! The Operator will take care of applying the changes
|
||||
…and that's it! The operator will take care of applying the changes
|
||||
as well as keeping the existing service in good shape.
|
||||
|
||||
## Writing your own Operator {#writing-operator}
|
||||
## Writing your own operator {#writing-operator}
|
||||
|
||||
If there isn't an Operator in the ecosystem that implements the behavior you
|
||||
If there isn't an operator in the ecosystem that implements the behavior you
|
||||
want, you can code your own.
|
||||
|
||||
You also implement an Operator (that is, a Controller) using any language / runtime
|
||||
You also implement an operator (that is, a Controller) using any language / runtime
|
||||
that can act as a [client for the Kubernetes API](/docs/reference/using-api/client-libraries/).
|
||||
|
||||
Following are a few libraries and tools you can use to write your own cloud native
|
||||
Operator.
|
||||
operator.
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
|
|
@ -129,6 +129,6 @@ Operator.
|
|||
* Learn more about [Custom Resources](/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
|
||||
* Find ready-made operators on [OperatorHub.io](https://operatorhub.io/) to suit your use case
|
||||
* [Publish](https://operatorhub.io/) your operator for other people to use
|
||||
* Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the Operator pattern (this is an archived version of the original article).
|
||||
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building Operators
|
||||
* Read [CoreOS' original article](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html) that introduced the operator pattern (this is an archived version of the original article).
|
||||
* Read an [article](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps) from Google Cloud about best practices for building operators
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue