Add concept page for Operators (#14458)

* Add concept page for Operator pattern

* Link to article about Operator best practices

content/en/docs/reference/glossary/operator-pattern.md

@@ -0,0 +1,24 @@
+---
+title: Operator pattern
+id: operator-pattern
+date: 2019-05-21
+full_link: /docs/concepts/extend-kubernetes/operator/
+short_description: >
+  A specialized controller used to manage a custom resource
+
+aka:
+tags:
+- architecture
+---
+ The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system
+design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom
+resources.
+
+<!--more-->
+
+You can extend Kubernetes by adding controllers to your cluster, beyond the built-in
+controllers that come as part of Kubernetes itself.
+
+If a running application acts as a controller and has API access to carry out tasks
+against a custom resource that's defined in the control plane, that's an example of
+the Operator pattern.

content/en/docs/reference/kubectl/cheatsheet.md

@@ -348,7 +348,7 @@ Kubectl verbosity is controlled with the `-v` or `--v` flags followed by an inte
 
 Verbosity | Description
 --------------| -----------
-`--v=0` | Generally useful for this to ALWAYS be visible to an operator.
+`--v=0` | Generally useful for this to *always* be visible to a cluster operator.
 `--v=1` | A reasonable default log level if you don't want verbosity.
 `--v=2` | Useful steady state information about the service and important log messages that may correlate to significant changes in the system. This is the recommended default log level for most systems.
 `--v=3` | Extended information about changes.