fix: Use attributes for Kubernetes occurences

modules/administration-guide/pages/viewing-kubernetes-events.adoc

@@ -1,6 +1,6 @@
 [id="viewing-kubernetes-events"]
-// = Accessing Kubernetes events on OpenShift
-:navtitle: Accessing Kubernetes events on OpenShift
+// = Accessing {kubernetes} events on OpenShift
+:navtitle: Accessing {kubernetes} events on OpenShift
 :keywords: administration-guide, viewing-kubernetes-events
 :page-aliases: .:viewing-kubernetes-events
 

modules/administration-guide/partials/con_authorization-and-user-management.adoc

@@ -12,7 +12,7 @@ The default {identity-provider} credentials are `admin:admin`. You can use the `
 .Identifying the {identity-provider} URL
 
 ifeval::["{project-context}" == "che"]
-{prod-short} running on Kubernetes::
+{prod-short} running on {kubernetes}::
 Go to `+$CHE_HOST:5050/auth+`.
 
 {prod-short} is running on OpenShift::

modules/administration-guide/partials/con_che-workspaces-architecture.adoc

@@ -10,7 +10,7 @@ A {prod-short} deployment on the cluster consists of the {prod-short} server com
 * secrets
 * PVs
 
-The {prod-short} workspace is a web application. It is composed of microservices running in containers that provide all the services of a modern IDE such as an editor, language auto-completion, and debugging tools. The IDE services are deployed with the development tools, packaged in containers and user runtime applications, which are defined as {platforms-name} resources.
+The {prod-short} workspace is a web application. It is composed of microservices running in containers that provide all the services of a modern IDE such as an editor, language auto-completion, and debugging tools. The IDE services are deployed with the development tools, packaged in containers and user runtime applications, which are defined as {orch-name} resources.
 
 The source code of the projects of a {prod-short} workspace is persisted in a {platforms-name} `PersistentVolume`. Microservices run in containers that have read-write access to the source code (IDE services, development tools), and runtime applications have read-write access to this shared directory.
 

modules/end-user-guide/pages/importing-kubernetes-applications-into-a-workspace.adoc

@@ -1,6 +1,6 @@
 [id="importing-kubernetes-applications-into-a-workspace"]
-// = Importing a Kubernetes application into a workspace
-:navtitle: Importing Kubernetes applications into a workspace
+// = Importing a {orch-name} application into a workspace
+:navtitle: Importing {orch-name} applications into a workspace
 :keywords: end-user-guide, importing-kubernetes-applications-into-a-workspace
 :page-aliases: .:importing-kubernetes-applications-into-a-workspace
 

modules/end-user-guide/partials/proc_che-including-kubernetes-applications-in-a-workspace-devfile-definition.adoc

@@ -30,7 +30,7 @@ metadata:
 +
 <1> Only the name `minimal-workspace` is specified. After the {prod-short} server processes this devfile, the devfile is converted to a minimal {prod-short} workspace that only has the default editor (Che-Theia) and the default editor plug-ins, including, for example, the terminal.
 
-. To add {orch-name} applications to a workspace, modify the devfile and add the `Kubernetes` component type.
+. To add {orch-name} applications to a workspace, modify the devfile and add the `{kubernetes}` component type.
 +
 For example, to embed the NodeJS-Mongo application in the `minimal-workspace`:
 +

modules/end-user-guide/partials/proc_mounting-a-secret-as-an-environment-variable-into-a-workspace-container.adoc

@@ -13,7 +13,7 @@ The following section describes how to mount a {platforms-name} secret from the
 
 .Procedure
 
-. In the Kubernetes {orch-namespace} where a {prod-short} workspace will be created, generate a new {platforms-name} secret .
+. In the {platforms-namespace} where a {prod-short} workspace will be created, generate a new {platforms-name} secret.
 
 * The labels of the secret that is about to be generated must match the set of labels configured in `che.workspace.provision.secret.labels` property of {prod-short}. By default, it is a set of two labels: 
 +

modules/installation-guide/examples/checluster-properties.adoc

@@ -127,7 +127,7 @@ workspacePVCStorageClassName: Storage class for the Persistent Volume Claims ded
 :===
  Property: Description
 ingressClass: Ingress class that will define the which controller will manage ingresses. Defaults to `nginx`. NB\: This drives the `kubernetes.io/ingress.class` annotation on Che-related ingresses.
-ingressDomain: Global ingress domain for a Kubernetes cluster. This MUST be explicitly specified\: there are no defaults.
+ingressDomain: Global ingress domain for a {kubernetes} cluster. This MUST be explicitly specified\: there are no defaults.
 ingressStrategy: Strategy for ingress creation. Options are\: `multi-host` (host is explicitly provided in ingress), `single-host` (host is provided, path-based rules) and `default-host` (no host is provided, path-based rules). Defaults to `multi-host` Deprecated in favor of `serverExposureStrategy` in the `server` section, which defines this regardless of the cluster type. When both are defined, the `serverExposureStrategy` option takes precedence.
 securityContextFsGroup: The FSGroup in which the {prod-short} Pod and workspace Pods containers runs in. Default value is `1724`.
 securityContextRunAsUser: ID of the user the {prod-short} Pod and workspace Pods containers run as. Default value is `1724`.
@@ -166,3 +166,4 @@ reason: A brief CamelCase message indicating details about why the Pod is in thi
 :===
 
 
+