docs: Ensure consistent proper case of Kubernetes

cmd/argocd/commands/project.go

@@ -106,7 +106,7 @@ func NewProjectCreateCommand(clientOpts *argocdclient.ClientOptions) *cobra.Comm
 			# Create a new project with name PROJECT
 			argocd proj create PROJECT
 
-			# Create a new project with name PROJECT from a file or URL to a kubernetes manifest
+			# Create a new project with name PROJECT from a file or URL to a Kubernetes manifest
 			argocd proj create PROJECT -f FILE|URL
 		`),
 		Run: func(c *cobra.Command, args []string) {

docs/developer-guide/extensions/ui-extensions.md

@@ -36,7 +36,7 @@ registerResourceExtension(component: ExtensionComponent, group: string, kind: st
 - `component: ExtensionComponent` is a React component that receives the following properties:
 
   - application: Application - Argo CD Application resource;
-  - resource: State - the kubernetes resource object;
+  - resource: State - the Kubernetes resource object;
   - tree: ApplicationTree - includes list of all resources that comprise the application;
 
   See properties interfaces in [models.ts](https://github.com/argoproj/argo-cd/blob/master/ui/src/app/shared/models.ts)

docs/developer-guide/site.md

@@ -2,13 +2,14 @@
 
 ## Developing And Testing
 
-The website is build using `mkdocs` and `mkdocs-material`. 
+The website is built using `mkdocs` and `mkdocs-material`. 
 
 To test:
 
 ```bash
 make serve-docs
 ```
+
 Once running, you can view your locally built documentation at [http://0.0.0.0:8000/](http://0.0.0.0:8000/). 
 
 ## Deploying

docs/index.md

@@ -53,7 +53,7 @@ meeting:
 
 ![Argo CD Architecture](assets/argocd_architecture.png)
 
-Argo CD is implemented as a kubernetes controller which continuously monitors running applications
+Argo CD is implemented as a Kubernetes controller which continuously monitors running applications
 and compares the current, live state against the desired target state (as specified in the Git repo).
 A deployed application whose live state deviates from the target state is considered `OutOfSync`.
 Argo CD reports & visualizes the differences, while providing facilities to automatically or

docs/operator-manual/applicationset/Generators-Cluster-Decision-Resource.md

@@ -1,6 +1,6 @@
 # Cluster Decision Resource Generator
 
-The cluster decision resource generates a list of Argo CD clusters. This is done using [duck-typing](https://pkg.go.dev/knative.dev/pkg/apis/duck), which does not require knowledge of the full shape of the referenced kubernetes resource. The following is an example of a cluster-decision-resource-based ApplicationSet generator:
+The cluster decision resource generates a list of Argo CD clusters. This is done using [duck-typing](https://pkg.go.dev/knative.dev/pkg/apis/duck), which does not require knowledge of the full shape of the referenced Kubernetes resource. The following is an example of a cluster-decision-resource-based ApplicationSet generator:
 ```yaml
 apiVersion: argoproj.io/v1alpha1
 kind: ApplicationSet

docs/operator-manual/applicationset/Generators-Git.md

@@ -409,15 +409,15 @@ the contents of webhook payloads are considered untrusted, and will only result
 application (a process which already occurs at three-minute intervals). If ApplicationSet is publicly
 accessible, then configuring a webhook secret is recommended to prevent a DDoS attack.
 
-In the `argocd-secret` kubernetes secret, include the Git provider's webhook secret configured in step 1.
+In the `argocd-secret` Kubernetes secret, include the Git provider's webhook secret configured in step 1.
 
-Edit the Argo CD kubernetes secret:
+Edit the Argo CD Kubernetes secret:
 
 ```bash
 kubectl edit secret argocd-secret -n argocd
 ```
 
-TIP: for ease of entering secrets, kubernetes supports inputting secrets in the `stringData` field,
+TIP: for ease of entering secrets, Kubernetes supports inputting secrets in the `stringData` field,
 which saves you the trouble of base64 encoding the values and copying it to the `data` field.
 Simply copy the shared webhook secret created in step 1, to the corresponding
 GitHub/GitLab/BitBucket key under the `stringData` field:

docs/operator-manual/applicationset/Generators-Post-Selector.md

@@ -1,6 +1,6 @@
 # Post Selector all generators
 
-The Selector allows to post-filter based on generated values using the kubernetes common labelSelector format. In the example, the list generator generates a set of two application which then filter by the key value to only select the `env` with value `staging`:
+The Selector allows to post-filter based on generated values using the Kubernetes common labelSelector format. In the example, the list generator generates a set of two application which then filter by the key value to only select the `env` with value `staging`:
 
 ## Example: List generator + Post Selector
 ```yaml

docs/operator-manual/health.md

@@ -3,7 +3,7 @@
 ## Overview
 Argo CD provides built-in health assessment for several standard Kubernetes types, which is then
 surfaced to the overall Application health status as a whole. The following checks are made for
-specific types of kubernetes resources:
+specific types of Kubernetes resources:
 
 ### Deployment, ReplicaSet, StatefulSet, DaemonSet
 * Observed generation is equal to desired generation.

docs/operator-manual/metrics.md

@@ -8,12 +8,12 @@ Metrics about applications. Scraped at the `argocd-metrics:8082/metrics` endpoin
 | Metric | Type | Description |
 |--------|:----:|-------------|
 | `argocd_app_info` | gauge | Information about Applications. It contains labels such as `sync_status` and `health_status` that reflect the application state in Argo CD. |
-| `argocd_app_k8s_request_total` | counter | Number of kubernetes requests executed during application reconciliation |
+| `argocd_app_k8s_request_total` | counter | Number of Kubernetes requests executed during application reconciliation |
 | `argocd_app_labels` | gauge | Argo Application labels converted to Prometheus labels. Disabled by default. See section below about how to enable it. |
 | `argocd_app_reconcile` | histogram | Application reconciliation performance. |
 | `argocd_app_sync_total` | counter | Counter for application sync history |
 | `argocd_cluster_api_resource_objects` | gauge | Number of k8s resource objects in the cache. |
-| `argocd_cluster_api_resources` | gauge | Number of monitored kubernetes API resources. |
+| `argocd_cluster_api_resources` | gauge | Number of monitored Kubernetes API resources. |
 | `argocd_cluster_cache_age_seconds` | gauge | Cluster cache age in seconds. |
 | `argocd_cluster_connection_status` | gauge | The k8s cluster current connection status. |
 | `argocd_cluster_events_total` | counter | Number of processes k8s resource events. |
@@ -67,7 +67,7 @@ Scraped at the `argocd-server-metrics:8083/metrics` endpoint.
 | Metric | Type | Description |
 |--------|:----:|-------------|
 | `argocd_redis_request_duration` | histogram | Redis requests duration. |
-| `argocd_redis_request_total` | counter | Number of kubernetes requests executed during application reconciliation. |
+| `argocd_redis_request_total` | counter | Number of Kubernetes requests executed during application reconciliation. |
 | `grpc_server_handled_total` | counter | Total number of RPCs completed on the server, regardless of success or failure. |
 | `grpc_server_msg_sent_total` | counter | Total number of gRPC stream messages sent by the server. |
 
@@ -80,7 +80,7 @@ Scraped at the `argocd-repo-server:8084/metrics` endpoint.
 | `argocd_git_request_duration_seconds` | histogram | Git requests duration seconds. |
 | `argocd_git_request_total` | counter | Number of git requests performed by repo server |
 | `argocd_redis_request_duration_seconds` | histogram | Redis requests duration seconds. |
-| `argocd_redis_request_total` | counter | Number of kubernetes requests executed during application reconciliation. |
+| `argocd_redis_request_total` | counter | Number of Kubernetes requests executed during application reconciliation. |
 | `argocd_repo_pending_request_total` | gauge | Number of pending requests requiring repository lock |
 
 ## Prometheus Operator

docs/operator-manual/security.md

@@ -45,7 +45,7 @@ Communication with Redis is performed over plain HTTP by default. TLS can be set
 Git and helm repositories are managed by a stand-alone service, called the repo-server. The
 repo-server does not carry any Kubernetes privileges and does not store credentials to any services
 (including git). The repo-server is responsible for cloning repositories which have been permitted
-and trusted by Argo CD operators, and generating kubernetes manifests at a given path in the
+and trusted by Argo CD operators, and generating Kubernetes manifests at a given path in the
 repository. For performance and bandwidth efficiency, the repo-server maintains local clones of
 these repositories so that subsequent commits to the repository are efficiently downloaded.
 
@@ -109,7 +109,7 @@ The information is used to reconstruct a REST config and kubeconfig to the clust
 services.
 
 To rotate the bearer token used by Argo CD, the token can be deleted (e.g. using kubectl) which
-causes kubernetes to generate a new secret with a new bearer token. The new token can be re-inputted
+causes Kubernetes to generate a new secret with a new bearer token. The new token can be re-inputted
 to Argo CD by re-running `argocd cluster add`. Run the following commands against the *_managed_*
 cluster:
 

docs/operator-manual/troubleshooting.md

@@ -25,7 +25,7 @@ argocd admin settings resource-overrides ignore-differences ./deploy.yaml --argo
 
 **Health Assessment**
 
-Argo CD provides built-in [health assessment](./health.md) for several kubernetes resources which can be further
+Argo CD provides built-in [health assessment](./health.md) for several Kubernetes resources which can be further
 customized by writing your own health checks in [Lua](https://www.lua.org/).
 The health checks are configured in the `resource.customizations` field of `argocd-cm` ConfigMap.
 

docs/operator-manual/upgrading/2.7-2.8.md

@@ -11,7 +11,7 @@ to upgrade your plugin.
 
 With the 2.8 release `entrypoint.sh` will be removed from the containers,
 because starting with 2.7, the implicit entrypoint is set to `tini` in the
-`Dockerfile` explicitly, and the kubernetes manifests has been updated to use
+`Dockerfile` explicitly, and the Kubernetes manifests has been updated to use
 it. Simply updating the containers without updating the deployment manifests
 will result in pod startup failures, as the old manifests are relying on
 `entrypoint.sh` instead of `tini`. Please make sure the manifests are updated

docs/operator-manual/user-management/index.md

@@ -442,7 +442,7 @@ Add a `rootCA` to your `oidc.config` which contains the PEM encoded root certifi
 
 #### Example
 
-SSO `clientSecret` can thus be stored as a kubernetes secret with the following manifests
+SSO `clientSecret` can thus be stored as a Kubernetes secret with the following manifests
 
 `argocd-secret`:
 ```yaml

docs/operator-manual/webhook.md

@@ -41,7 +41,7 @@ the contents of webhook payloads are considered untrusted, and will only result
 application (a process which already occurs at three-minute intervals). If Argo CD is publicly
 accessible, then configuring a webhook secret is recommended to prevent a DDoS attack.
 
-In the `argocd-secret` kubernetes secret, configure one of the following keys with the Git
+In the `argocd-secret` Kubernetes secret, configure one of the following keys with the Git
 provider's webhook secret configured in step 1.
 
 | Provider        | K8s Secret Key                   |
@@ -54,13 +54,13 @@ provider's webhook secret configured in step 1.
 | Azure DevOps    | `webhook.azuredevops.username`   |
 |                 | `webhook.azuredevops.password`   |
 
-Edit the Argo CD kubernetes secret:
+Edit the Argo CD Kubernetes secret:
 
 ```bash
 kubectl edit secret argocd-secret -n argocd
 ```
 
-TIP: for ease of entering secrets, kubernetes supports inputting secrets in the `stringData` field,
+TIP: for ease of entering secrets, Kubernetes supports inputting secrets in the `stringData` field,
 which saves you the trouble of base64 encoding the values and copying it to the `data` field.
 Simply copy the shared webhook secret created in step 1, to the corresponding
 GitHub/GitLab/BitBucket key under the `stringData` field:

docs/proposals/config-management-plugin-v2.md

@@ -291,7 +291,7 @@ There aren't any major drawbacks to this proposal. Also, the advantages supersed
 However following are few minor drawbacks,
 
 * With addition of plugin.yaml, there will be more yamls to manage
-* Operators need to be aware of the modified kubernetes manifests in the subsequent version.
+* Operators need to be aware of the modified Kubernetes manifests in the subsequent version.
 * The format of the CMP manifest is a new "contract" that would need to adhere the usual Argo CD compatibility promises in future.
 
 

docs/user-guide/best_practices.md

@@ -2,7 +2,7 @@
 
 ## Separating Config Vs. Source Code Repositories
 
-Using a separate Git repository to hold your kubernetes manifests, keeping the config separate
+Using a separate Git repository to hold your Kubernetes manifests, keeping the config separate
 from your application source code, is highly recommended for the following reasons:
 
 1. It provides a clean separation of application code vs. application config. There will be times

docs/user-guide/ci_automation.md

@@ -18,7 +18,7 @@ docker push mycompany/guestbook:v2.0
 ## Update The Local Manifests Using Your Preferred Templating Tool, And Push The Changes To Git
 
 !!! tip
-    The use of a different Git repository to hold your kubernetes manifests (separate from
+    The use of a different Git repository to hold your Kubernetes manifests (separate from
     your application source code), is highly recommended. See [best practices](best_practices.md)
     for further rationale.
 

docs/user-guide/commands/argocd_proj_create.md

@@ -14,7 +14,7 @@ argocd proj create PROJECT [flags]
   # Create a new project with name PROJECT
   argocd proj create PROJECT
   
-  # Create a new project with name PROJECT from a file or URL to a kubernetes manifest
+  # Create a new project with name PROJECT from a file or URL to a Kubernetes manifest
   argocd proj create PROJECT -f FILE|URL
 ```
 

docs/user-guide/kustomize.md

@@ -9,7 +9,7 @@ The following configuration options are available for Kustomize:
 * `commonLabels` is a string map of additional labels
 * `forceCommonLabels` is a boolean value which defines if it's allowed to override existing labels
 * `commonAnnotations` is a string map of additional annotations
-* `namespace` is a kubernetes resources namespace
+* `namespace` is a Kubernetes resources namespace
 * `forceCommonAnnotations` is a boolean value which defines if it's allowed to override existing annotations
 * `commonAnnotationsEnvsubst` is a boolean value which enables env variables substition in annotation  values
 * `patches` is a list of Kustomize patches that supports inline updates

docs/user-guide/sync-options.md

@@ -29,7 +29,7 @@ The app will be out of sync if Argo CD expects a resource to be pruned. You may
 
 ## Disable Kubectl Validation
 
-For a certain class of objects, it is necessary to `kubectl apply` them using the `--validate=false` flag. Examples of this are kubernetes types which uses `RawExtension`, such as [ServiceCatalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/pkg/apis/servicecatalog/v1beta1/types.go#L497). You can do using this annotations:
+For a certain class of objects, it is necessary to `kubectl apply` them using the `--validate=false` flag. Examples of this are Kubernetes types which uses `RawExtension`, such as [ServiceCatalog](https://github.com/kubernetes-incubator/service-catalog/blob/master/pkg/apis/servicecatalog/v1beta1/types.go#L497). You can do using this annotations:
 
 
 ```yaml