[a11y] Fix "see" occurrences (#5315)

* Fix see occurrences

* Update docs/operating-eck/troubleshooting/troubleshooting-methods.asciidoc

Co-authored-by: Michael Morello <[email protected]>

Co-authored-by: Michael Morello <[email protected]>

docs/advanced-topics/custom-images.asciidoc

@@ -26,7 +26,7 @@ RUN bin/elasticsearch-plugin install --batch repository-gcs
 docker build --tag elasticsearch-gcs:{version}
 ----
 
-There are various hosting options for your images. If you use Google Kubernetes Engine, it is automatically configured to use the Google Container Registry. See https://cloud.google.com/container-registry/docs/using-with-google-cloud-platform#google-kubernetes-engine[Using Container Registry with Google Cloud] for more information. To use the image, you can then https://cloud.google.com/container-registry/docs/pushing-and-pulling#pushing_an_image_to_a_registry[push to the registry] with:
+There are various hosting options for your images. If you use Google Kubernetes Engine, it is automatically configured to use the Google Container Registry. Check https://cloud.google.com/container-registry/docs/using-with-google-cloud-platform#google-kubernetes-engine[Using Container Registry with Google Cloud] for more information. To use the image, you can then https://cloud.google.com/container-registry/docs/pushing-and-pulling#pushing_an_image_to_a_registry[push to the registry] with:
 
 [subs="attributes"]
 ----
@@ -61,7 +61,7 @@ For more information, check the following references:
 [id="{p}-container-registry-override"]
 == Override the default container registry
 
-When creating custom resources ({eck_resources_list}), the operator defaults to using container images pulled from the `docker.elastic.co` registry. If you are in an environment where external network access is restricted, you could configure the operator to use a different default container registry by starting the operator with the `--container-registry` command-line flag. See <<{p}-operator-config>> for more information on how to configure the operator using command-line flags and environment variables.
+When creating custom resources ({eck_resources_list}), the operator defaults to using container images pulled from the `docker.elastic.co` registry. If you are in an environment where external network access is restricted, you could configure the operator to use a different default container registry by starting the operator with the `--container-registry` command-line flag. Check <<{p}-operator-config>> for more information on how to configure the operator using command-line flags and environment variables.
 
 The operator expects container images to be located at specific paths in the default container registry. Make sure that your container images are stored at the right path and are tagged correctly with the stack version number. For example, if your private registry is `my.registry` and you wish to deploy components from stack version {version}, the following image paths should exist:
 

docs/advanced-topics/openshift.asciidoc

@@ -31,7 +31,7 @@ Before deploying an Elasticsearch cluster with ECK, make sure that the Kubernete
 +
 Alternatively, you can opt for setting `node.store.allow_mmap: false` at the <<{p}-node-configuration,Elasticsearch node configuration>> level. This has performance implications and is not recommended for production workloads.
 +
-For more information, see <<{p}-virtual-memory>>.
+For more information, check <<{p}-virtual-memory>>.
 
 [id="{p}-openshift-deploy-the-operator"]
 == Deploy the operator
@@ -325,7 +325,7 @@ spec:
             path: /var/lib/docker/containers
 ----
 
-See the complete examples in the link:{eck_github}/tree/{eck_release_branch}/config/recipes/beats[recipes directory].
+Check the complete examples in the link:{eck_github}/tree/{eck_release_branch}/config/recipes/beats[recipes directory].
 
 
 [id="{p}-openshift-agent"]

docs/advanced-topics/service-meshes.asciidoc

@@ -19,7 +19,7 @@ You can connect ECK and managed Elastic Stack applications to some of the most p
 [id="{p}-service-mesh-istio"]
 == Istio
 
-The instructions in this section describe how to connect the operator and managed resources to the Istio service mesh and assume that Istio is already installed and configured on your Kubernetes cluster. To know more about Istio and how to install it, see the link:https://istio.io[product documentation].
+The instructions in this section describe how to connect the operator and managed resources to the Istio service mesh and assume that Istio is already installed and configured on your Kubernetes cluster. To know more about Istio and how to install it, check the link:https://istio.io[product documentation].
 
 These instructions have been tested with Istio {istio_version}. Older or newer versions of Istio might require additional configuration steps not documented here.
 
@@ -117,7 +117,7 @@ spec:
 
 <3> Optional. Only set `automountServiceAccountToken` to `true` if your Kubernetes cluster does not have support for issuing third-party security tokens.
 
-If you do not have https://istio.io/latest/docs/tasks/security/authentication/mtls-migration/[automatic mutual TLS] enabled, you may need to create a link:https://istio.io/docs/reference/config/networking/destination-rule/[Destination Rule] to allow the operator to communicate with the Elasticsearch cluster. A communication issue between the operator and the managed Elasticsearch cluster can be detected by looking at the operator logs to see if there are any errors reported with the text `503 Service Unavailable`.
+If you do not have https://istio.io/latest/docs/tasks/security/authentication/mtls-migration/[automatic mutual TLS] enabled, you may need to create a link:https://istio.io/docs/reference/config/networking/destination-rule/[Destination Rule] to allow the operator to communicate with the Elasticsearch cluster. A communication issue between the operator and the managed Elasticsearch cluster can be detected by looking at the operator logs to check if there are any errors reported with the text `503 Service Unavailable`.
 
 [source,sh]
 ----
@@ -281,7 +281,7 @@ kubectl annotate namespace elastic-stack linkerd.io/inject=enabled
 
 Any Elasticsearch, Kibana, or APM Server resources deployed to a namespace with the above annotation will automatically join the mesh.
 
-Alternatively, if you only want specific resources to join the mesh, add the `linkerd.io/inject: enabled` annotation to the `podTemplate` (see <<{p}-api-reference, API documentation>>) of the resource as follows:
+Alternatively, if you only want specific resources to join the mesh, add the `linkerd.io/inject: enabled` annotation to the `podTemplate` (check <<{p}-api-reference, API documentation>>) of the resource as follows:
 
 [source,yaml]
 ----

docs/advanced-topics/stack-monitoring.asciidoc

@@ -68,7 +68,7 @@ IMPORTANT: The monitoring cluster must be managed by ECK in the same Kubernetes
 
 You can send metrics and logs to two different Elasticsearch monitoring clusters.
 
-You can also enable Stack Monitoring on Elasticsearch only or on Kibana only. In the latter case, Kibana will not be available on the Stack Monitoring Kibana page (see link:https://www.elastic.co/guide/en/kibana/current/monitoring-data.html#monitoring-data[View monitoring data in Kibana]).
+You can also enable Stack Monitoring on Elasticsearch only or on Kibana only. In the latter case, Kibana will not be available on the Stack Monitoring Kibana page (check link:https://www.elastic.co/guide/en/kibana/current/monitoring-data.html#monitoring-data[View monitoring data in Kibana]).
 
 == When to use it
 
@@ -77,7 +77,7 @@ This feature is a good solution if you need to monitor your Elastic applications
 - to Metricbeat to allow queriying the k8s API
 - to Filebeat to deploy a privileged DaemonSet
 
-However, for maximum efficiency and minimising resource consumption, or advanced use cases that require specific Beats configurations, you can deploy a standalone Metricbeat Deployment and a Filebeat Daemonset. See the <<{p}-beat-configuration-examples,Beats configuration Examples>> for more information.
+However, for maximum efficiency and minimising resource consumption, or advanced use cases that require specific Beats configurations, you can deploy a standalone Metricbeat Deployment and a Filebeat Daemonset. Check the <<{p}-beat-configuration-examples,Beats configuration Examples>> for more information.
 
 == How it works
 

docs/advanced-topics/webhook-namespace-selectors.asciidoc

@@ -16,4 +16,4 @@ Webhook resources are cluster-scoped, therefore `createClusterScopedResources` m
 
 WARNING: It is not recommended to deploy webhook resources in environments where operators are run by untrusted users and need to be locked down tightly.
 
-For more information, see <<{p}-webhook,Configure the validating webhook>> and link:https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/[Dynamic Admission Control].
+For more information, check <<{p}-webhook,Configure the validating webhook>> and link:https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/[Dynamic Admission Control].

docs/design/0001-no-stateful-sets.md

@@ -1,6 +1,6 @@
 # 1. Stateful set or custom controller
 
-**Update (2019-07-30):** we decided to refactor the code towards using StatefulSets in order to manage Elasticsearch pods. Mostly in order to get closer to Kubernetes standards, simplify PersistentVolumes management, and stay open to future improvements in the ecosystem. For more details, see [the StatefulSets discussion issue](https://github.com/elastic/cloud-on-k8s/issues/1173).
+**Update (2019-07-30):** we decided to refactor the code towards using StatefulSets in order to manage Elasticsearch pods. Mostly in order to get closer to Kubernetes standards, simplify PersistentVolumes management, and stay open to future improvements in the ecosystem. For more details, check [the StatefulSets discussion issue](https://github.com/elastic/cloud-on-k8s/issues/1173).
 
 * Status: ~~accepted~~ rejected, superseded by https://github.com/elastic/cloud-on-k8s/issues/1173
 * Deciders: @nkvoll
@@ -89,7 +89,7 @@ We decided to implement our own controller that manages pods directly.
 
 - [StatefulSets documentation](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)
 
-- [etcd-operator](https://github.com/coreos/etcd-operator): one of the first and most popular operator out there. Does not rely on StatefulSets. See [this comment](https://github.com/coreos/etcd-operator/issues/1323#issuecomment-317875165) from _xiang90_:
+- [etcd-operator](https://github.com/coreos/etcd-operator): one of the first and most popular operator out there. Does not rely on StatefulSets. Check [this comment](https://github.com/coreos/etcd-operator/issues/1323#issuecomment-317875165) from _xiang90_:
 > Statefulset is not flexible enough to achieve quite a few things easily, and the benefits it bring in right now are not significant.
 
 - [Best practices for building Kubernetes Operators and stateful apps (Google)](https://cloud.google.com/blog/products/containers-kubernetes/best-practices-for-building-kubernetes-operators-and-stateful-apps)

docs/design/0002-global-operator/0002-global-operator.md

@@ -70,5 +70,5 @@ Superseded by [005](https://github.com/elastic/cloud-on-k8s/blob/main/docs/desig
 
 ### Negative Consequences <!-- optional -->
 
-- Introduces more than one operator, complicating deployment and debugging. (See section for future improvements)
+- Introduces more than one operator, complicating deployment and debugging. 
 - Controllers in the global operator, such as the CCR controller still need to be scaled on a number-of-clusters / associations basis (but it does not need to connect to individual ES clusters).

docs/design/0004-licensing.md

@@ -108,9 +108,9 @@ Option 1 and 2 are both valid as two separate implementation phases. Without a r
 * What kind of license will we support? gold, platinum, standard license?
     * assume all license types for now  
 * What do we do when the license expires. How do we recover from that?
-    * The cluster does not disintegrate when the license expires. The operator will see the cluster as unhealthy as our current health checks start failing only if the cluster never had a license. But we might continue starting out with a trial license until the cluster forms and is issued a proper license.  The license API stays responsive even without any license attached to the cluster and cluster bounces back as soon as a valid license is put into place. 
+    * The cluster does not disintegrate when the license expires. The operator will detect the cluster as unhealthy as our current health checks start failing only if the cluster never had a license. But we might continue starting out with a trial license until the cluster forms and is issued a proper license.  The license API stays responsive even without any license attached to the cluster and cluster bounces back as soon as a valid license is put into place. 
 * How do we handle license downgrades to basic? 
-    * As basic does not support internal TLS I don't see a way at the moment to downgrade to basic. Should we prevent/validate this with a CRD and validation?
+    * As basic does not support internal TLS, there is no way at the moment to downgrade to basic. Should we prevent/validate this with a CRD and validation?
 * Do we have have way of testing licensing. Can we generate test licenses?
     * Not really. The only option is to unit/integration test the code around license management. We can think about two options in the future: dev licenses similar to what Elasticsearch does (would require us to use dev Docker images) or loading a valid license in vault for CI to run a set of integration and e2e tests on it
 * Do we need to support enterprise licenses that contain individual cluster licenses?

docs/design/0006-certificate-management.md

@@ -79,7 +79,7 @@ Several options considered involving an init container in the ES pod:
 * *Option B*: the init container requests the operator through an API in the operator to send the CSR. Disadvantage: similar to Option A, we implicitly authorize the ES pod to reach the operator. Even though this can be restricted to a single endpoint, it's an additional possible flow that could lead to security issues.
 * *Option C*: the init container runs an HTTP server to serve the generated CSR. The operator requests the CSR through this API. Advantage: the pod does not need to reach any other service. Disadvantage: some additional complexity in the design and the implementation.
 
-Option C is the chosen one here. For more details on the actual workflow, see the [cert-initializer README](https://github.com/elastic/cloud-on-k8s/blob/main/operators/cmd/cert-initializer/README.md).
+Option C is the chosen one here. For more details on the actual workflow, check the [cert-initializer README](https://github.com/elastic/cloud-on-k8s/blob/main/operators/cmd/cert-initializer/README.md).
 
 #### Pods certificate rotation
 

docs/design/0010-license-checks.md

@@ -15,7 +15,7 @@ behaviour are any commercial features available to licensed operators only.
 
 * we currently suppport multiple deployment options for the operator: single namespace and multi-namespace.
 * for the activation of commerical features we need a minimal amount of protection against tampering.
-* we see admission controllers as optional means of verification and don't want to rely on them for functionality that does not exist in other places as well.
+* we consider admission controllers as optional means of verification and don't want to rely on them for functionality that does not exist in other places as well.
 * we regard licenses as somewhat sensitive data that should not be shared freely across all namespaces and controllers.
 
 

docs/design/adr-template.md

@@ -25,7 +25,7 @@ Technical Story: [description | ticket/issue URL] <!-- optional -->
 
 ## Decision Outcome
 
-Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (see below)].
+Chosen option: "[option 1]", because [justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force force | … | comes out best (check below)].
 
 ### Positive Consequences <!-- optional -->
 

docs/operating-eck/licensing.asciidoc

@@ -7,9 +7,9 @@ endif::[]
 [id="{p}-{page_id}"]
 = Manage licenses in ECK
 
-When you install the default distribution of ECK, you receive a Basic license. Any Elastic stack application you manage through ECK will also be Basic licensed. Go to https://www.elastic.co/subscriptions to see which features are included in the Basic license for free.
+When you install the default distribution of ECK, you receive a Basic license. Any Elastic stack application you manage through ECK will also be Basic licensed. Go to https://www.elastic.co/subscriptions to check which features are included in the Basic license for free.
 
-IMPORTANT: ECK is only offered in two licensing tiers: Basic and Enterprise. Similar to the Elastic Stack, customers can download and use ECK with a Basic license for free. Basic license users can obtain support from GitHub or through our link:https://discuss.elastic.co[community]. A paid Enterprise subscription is required to engage the Elastic support team. For more details, see the link:https://www.elastic.co/subscriptions[Elastic subscriptions].
+IMPORTANT: ECK is only offered in two licensing tiers: Basic and Enterprise. Similar to the Elastic Stack, customers can download and use ECK with a Basic license for free. Basic license users can obtain support from GitHub or through our link:https://discuss.elastic.co[community]. A paid Enterprise subscription is required to engage the Elastic support team. For more details, check the link:https://www.elastic.co/subscriptions[Elastic subscriptions].
 
 In this section, you are going to learn how to:
 
@@ -83,7 +83,7 @@ kubectl label secret eck-license "license.k8s.elastic.co/scope"=operator -n elas
 == Update your license
 Before your current Enterprise license expires, you will receive a new Enterprise license from Elastic (provided that your subscription is valid).
 
-NOTE: You can see the expiry date of your license in the license file that you received from Elastic. Enterprise licenses are container licenses that include multiple licenses for individual Elasticsearch clusters with shorter expiry. Therefore, you will see a different expiry in Kibana or via the Elasticsearch link:https://www.elastic.co/guide/en/elasticsearch/reference/current/get-license.html[`_license`] API. ECK will automatically update the Elasticsearch cluster licenses until the expiry date of the ECK Enterprise license is reached.
+NOTE: You can check the expiry date of your license in the license file that you received from Elastic. Enterprise licenses are container licenses that include multiple licenses for individual Elasticsearch clusters with shorter expiry. Therefore, you will get a different expiry in Kibana or via the Elasticsearch link:https://www.elastic.co/guide/en/elasticsearch/reference/current/get-license.html[`_license`] API. ECK will automatically update the Elasticsearch cluster licenses until the expiry date of the ECK Enterprise license is reached.
 
 To avoid any unintended downgrade of individual Elasticsearch clusters to a Basic license while installing the new license, we recommend to install the new Enterprise license as a new Kubernetes secret next to your existing Enterprise license. Just replace `eck-license` with a different name from the examples above. ECK will use the correct license automatically.
 
@@ -107,7 +107,7 @@ The operator periodically writes the total amount of Elastic resources under man
 }
 ----
 
-If the operator metrics endpoint is enabled via the `--metrics-port` flag (see <<{p}-operator-config>>), license usage data will be included in the reported metrics. 
+If the operator metrics endpoint is enabled via the `--metrics-port` flag (check <<{p}-operator-config>>), license usage data will be included in the reported metrics. 
 
 [source,shell]
 ----