Change on cluster to in cluster (#736)

README.md

@@ -8,7 +8,7 @@
 
 ## Overview
 
-Serverless Operator allows deploying the [Serverless](https://kyma-project.io/docs/kyma/latest/01-overview/serverless/) component on the Kyma cluster in compatibility with [Lifecycle Manager](https://github.com/kyma-project/lifecycle-manager).
+Serverless Operator allows deploying the [Serverless](https://kyma-project.io/docs/kyma/latest/01-overview/serverless/) component in the Kyma cluster in compatibility with [Lifecycle Manager](https://github.com/kyma-project/lifecycle-manager).
 
 ## Install
 
@@ -76,15 +76,15 @@ kubectl apply -f https://github.com/kyma-project/serverless-manager/releases/lat
     ```
 
 <!-- TODO: update this section - now we don't use lifecycle manager -->
-### Test Integration with Lifecycle Manager on the k3d Cluster
+### Test Integration with Lifecycle Manager in the k3d Cluster
 
 1. Clone the project.
 
     ```bash
     git clone https://github.com/kyma-project/serverless-manager.git && cd serverless-manager/
     ```
 
-2. Build Serverless Operator locally and run it on the k3d cluster.
+2. Build Serverless Operator locally and run it in the k3d cluster.
 
     ```bash
     make -C hack/local run

components/serverless/design/glossary_proposal.md

@@ -5,7 +5,7 @@
 Currently, Serverless in Kyma consists of two projects:
 
 - [function-controller](../README.md)() -
-  responsible for running a Function on a Kubernetes cluster
+  responsible for running a Function in a Kubernetes cluster
 - [serverless-manager](https://github.com/kyma-project/serverless-manager) - responsible for installation and
   configuration of Serverless
 
@@ -29,7 +29,7 @@ The proposed naming conventions refer to different architecture layers of the wh
 
 This section refers to the high-level architecture elements, namely to the main projects:
 
-- Serverless - the new naming convention for the `function-controller`. Serverless is responsible for running a Function on a Kubernetes cluster. It can contain its own
+- Serverless - the new naming convention for the `function-controller`. Serverless is responsible for running a Function in a Kubernetes cluster. It can contain its own
   CRD.
 - Serverless-operator - the new naming convention for `serverless-manager`. Serverless-operator installs and configures Serverless.
 - Kyma-Keda-operator - the operator which installs and configures [KEDA](https://keda.sh/).
@@ -38,7 +38,7 @@ This section refers to the high-level architecture elements, namely to the main
 
 This section refers to the Serverless components:
 
-- Controller - responsible for creating and configuring k8s resources to finally run a function on a cluster. It is responsible for the reconciliation of the Function CR.
+- Controller - responsible for creating and configuring k8s resources to finally run a function in a cluster. It is responsible for the reconciliation of the Function CR.
 - Webhook - responsible for defaulting, validation, and conversion of the Function CR, mutating the external registry Secret, and reconciling certificates.
 
 Proposed naming convention:

components/serverless/design/internal_registry_garbage_collection.md

@@ -23,7 +23,7 @@ This is a proposal to implement garbage collection logic to avoid these issues.
 The Docker registry already has a [garbage collection mechanism](https://docs.docker.com/registry/garbage-collection/). However, it's not very flexible. It's only possible to delete blobs that are not referenced by any manifests.
 
 To utilize this, we need to implement custom logic that will periodically run and:
-- Identify existing Functions running on the cluster.
+- Identify existing Functions running in the cluster.
 - Identify current images used by those Functions' runtimes.
 - List all tags for the used images.
 - Identify unused tags and use the Registry API to delete them.
@@ -43,7 +43,7 @@ The garbage collection process is implemented in three phases:
 For this phase, a simple command line tool will perform the following steps:
 #### Function image garbage collection
 
-- Identify existing Functions running on the cluster.
+- Identify existing Functions running in the cluster.
 - Identify current images used by those Functions' runtimes.
 - List all tags for the used images.
 - Identify unused tags and use the Registry API to delete them.

docs/contributor/04-10-testing-strategy.md

@@ -9,15 +9,15 @@ Each pull request to the repository triggers the following CI/CD jobs that verif
 - `Serverless verify / lint (pull_request)` - Is responsible for the Serverless linting and static code analysis. For the configuration, see the [serverless-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/serverless-verify.yaml#L19) file.
 - `Operator verify / unit-test (pull_request)` - Runs basic unit tests of Operator's logic. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L30) file.
 - `Serverless verify / unit-test (pull_request)` - Runs unit tests of Serverless's logic. For the configuration, see the [serverless-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/serverless-verify.yaml#L31) file.
-- `Operator verify / integration-test (pull_request)` - Runs the basic functionality integration test suite for the Operator on a k3d cluster. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L39) file.
-- `Serverless verify / contract-integration-test (pull_request)` - Runs the `tracing`, `api-gateway`, and `cloud-event` contract compatibility integration test suite for Serverless on a k3d cluster. For the configuration, see the [serverless-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/serverless-verify.yaml#L41) file.
+- `Operator verify / integration-test (pull_request)` - Runs the basic functionality integration test suite for the Operator in a k3d cluster. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L39) file.
+- `Serverless verify / contract-integration-test (pull_request)` - Runs the `tracing`, `api-gateway`, and `cloud-event` contract compatibility integration test suite for Serverless in a k3d cluster. For the configuration, see the [serverless-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/serverless-verify.yaml#L41) file.
 
 ## CI/CD Jobs Running on the Main Branch
 
-- `Operator verify / integration-test (push)` - Runs the basic functionality integration test suite for the Operator on a k3d cluster. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L39) file.
+- `Operator verify / integration-test (push)` - Runs the basic functionality integration test suite for the Operator in a k3d cluster. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L39) file.
 - `Operator verify / upgrade-test (push)` - Runs the upgrade integration test suite and verifies if the latest release can be successfully upgraded to the new (`main`) revision. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L66) file.
 - `Serverless verify / git-auth-integration-test (push)` - Runs the `GitHub` and `Azure DevOps` API and authentication integration test suite for Serverless. For the configuration, see the [serverless-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/serverless-verify.yaml#L64) file.
-- `Operator verify / gardener-integration-test (push)` - Checks the installation of the Serverless module on the Gardener shoot cluster and runs basic integration tests of Serverless. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L86) file.
+- `Operator verify / gardener-integration-test (push)` - Checks the installation of the Serverless module in the Gardener shoot cluster and runs basic integration tests of Serverless. For the configuration, see the [operator-verify.yaml](https://github.com/kyma-project/serverless/blob/main/.github/workflows/operator-verify.yaml#L86) file.
 
 ## CI/CD Jobs Running on a Schedule
 

docs/user/00-30-development-toolkit.md

@@ -7,7 +7,7 @@ To start developing your first Functions, you need:
 - [**Docker**](https://www.docker.com/) as the container runtime
 - [**kubectl**](https://kubernetes.io/docs/reference/kubectl/kubectl/), the Kubernetes command-line tool, for running commands against clusters
 - Development environment of your choice:
-   - **Kyma CLI** to easily initiate inline Functions or Git Functions locally, run, test, and later apply them on the clusters
+   - **Kyma CLI** to easily initiate inline Functions or Git Functions locally, run, test, and later apply them in the clusters
    - **Node.js** or **Python**
    - **IDE** as the source code editor
    - **Kyma dashboard** to manage Functions and related workloads through the graphical user interface

docs/user/technical-reference/05-20-env-variables.md

@@ -13,7 +13,7 @@ Every runtime provides its own unique environment configuration which can be rea
 | **FUNC_HANDLER** | `main` | The name of the exported Function inside the `MOD_NAME` file.                                                                                                         |
 | **MOD_NAME** | `handler` | The name of the main exported file. It must have an extension of `.py` for the Python runtimes and `.js` for the Node.js ones. The extension must be added on the server side. |
 | **FUNC_PORT** | `8080` | The right port a server listens to.                                                                                                                                  |
-| **SERVICE_NAMESPACE** | None | The namespace where the right Function exists on a cluster.                                                                                                           |
+| **SERVICE_NAMESPACE** | None | The namespace where the right Function exists in a cluster.                                                                                                           |
 | **KUBELESS_INSTALL_VOLUME** | `/kubeless` | Full path to volume mount with users source code.                                                                                                                     |
 | **FUNC_RUNTIME** | None | The name of the actual runtime. Possible values: `nodejs16` - deprecated, `nodejs18`, `python39`.                                                                               |
 | **TRACE_COLLECTOR_ENDPOINT** | None | Full address of OpenTelemetry Trace Collector is exported if the trace collector's endpoint is present.                                                                  |

docs/user/technical-reference/07-60-function-configuration-file.md

@@ -111,7 +111,7 @@ source:
 See all parameter descriptions.
 
 > [!NOTE]
-> The **Default value** column specifies the values that Kyma CLI sets when applying resources on a cluster, if no other values are provided.
+> The **Default value** column specifies the values that Kyma CLI sets when applying resources in a cluster, if no other values are provided.
 
 | Parameter                                                      | Required | Related custom resource | Default value  | Description                                                                                                                                                                                                                                                                                                                           |
 |----------------------------------------------------------------|:--------:| ---------| ---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|

docs/user/tutorials/01-110-override-runtime-image.md

@@ -6,7 +6,7 @@ This tutorial shows how to build a custom runtime image and override the Functio
 
 Before you start, make sure you have these tools installed:
 
-- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) on a cluster
+- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) in a cluster
 
 ## Steps
 

docs/user/tutorials/01-120-inject-envs.md

@@ -8,7 +8,7 @@ You can specify environment variables in the Function definition, or define refe
 
 Before you start, make sure you have these tools installed:
 
-- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) on a cluster
+- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) in a cluster
 
 ## Steps
 

docs/user/tutorials/01-140-use-secret-mounts.md

@@ -7,7 +7,7 @@ It's based on a simple Function in Python 3.9. The Function reads data from Secr
 
 Before you start, make sure you have these tools installed:
 
-- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) on a cluster
+- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) in a cluster
 
 ## Steps
 

docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md

@@ -9,15 +9,15 @@ This tutorial shows how to use the available CLI commands to manage Functions in
 > [!NOTE]
 > Read about [Istio sidecars in Kyma and why you want them](https://kyma-project.io/docs/kyma/latest/01-overview/service-mesh/smsh-03-istio-sidecars-in-kyma/). Then, check how to [enable automatic Istio sidecar proxy injection](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/smsh-01-istio-enable-sidecar-injection/). For more details, see [Default Istio setup in Kyma](https://kyma-project.io/docs/kyma/latest/01-overview/service-mesh/smsh-02-default-istio-setup-in-kyma/).
 
-This tutorial is based on a sample Python Function run on a lightweight [k3d](https://k3d.io/) cluster.
+This tutorial is based on a sample Python Function run in a lightweight [k3d](https://k3d.io/) cluster.
 
 ## Prerequisites
 
 Before you start, make sure you have these tools installed:
 
 - [Docker](https://www.docker.com/)
 - [Kyma CLI](https://github.com/kyma-project/cli)
-- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) locally or on a cluster
+- [Serverless module installed](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/08-install-uninstall-upgrade-kyma-module/) locally or in a cluster
 
 ## Steps
 
@@ -66,13 +66,13 @@ Follow these steps:
 
   Alternatively, use the `--dry-run` flag to list the file that will be created before you apply it. You can also preview the file's content in the format of your choice by adding the `--output {FILE_FORMAT}` flag, such as `--output yaml`.
 
-3. Once applied, view the Function's details on the cluster:
+3. Once applied, view the Function's details in the cluster:
 
   ```bash
   kubectl describe function {FUNCTION_NAME}
   ```
 
-4. Change the Function's source code on the cluster to return "Hello Serverless!":
+4. Change the Function's source code in the cluster to return "Hello Serverless!":
 
   a) Edit the Function:
 

docs/user/tutorials/01-50-sync-function-with-gitops.md

@@ -1,6 +1,6 @@
 # Synchronize Git Resources with the Cluster Using a Gitops Operator
 
-This tutorial shows how you can automate the deployment of local Kyma resources on a cluster using the GitOps logic. You will use [Kyma CLI](https://github.com/kyma-project/cli) to create an inline Python Function. You will later push the resource to a GitHub repository of your choice and set up a GitOps operator to monitor the given repository folder and synchronize any changes in it with your cluster. For the purpose of this tutorial, you will install and use the [Flux](https://fluxcd.io/flux/get-started/) GitOps operator and a lightweight [k3d](https://k3d.io/) cluster.
+This tutorial shows how you can automate the deployment of local Kyma resources in a cluster using the GitOps logic. You will use [Kyma CLI](https://github.com/kyma-project/cli) to create an inline Python Function. You will later push the resource to a GitHub repository of your choice and set up a GitOps operator to monitor the given repository folder and synchronize any changes in it with your cluster. For the purpose of this tutorial, you will install and use the [Flux](https://fluxcd.io/flux/get-started/) GitOps operator and a lightweight [k3d](https://k3d.io/) cluster.
 
 > [!TIP]
 > Although this tutorial uses Flux to synchronize Git resources with the cluster, you can use an alternative GitOps operator for this purpose, such as [Argo](https://argoproj.github.io/argo-cd/).
@@ -39,7 +39,7 @@ These sections will lead you through the whole installation, configuration, and
   kubectl cluster-info
   ```
 
-3. Apply the `functions.serverless.kyma-project.io` CRD from sources in the [`serverless`](https://github.com/kyma-project/serverless/tree/main/components/serverless/config/crd) repository. You will need it to create the Function CR on the cluster.
+3. Apply the `functions.serverless.kyma-project.io` CRD from sources in the [`serverless`](https://github.com/kyma-project/serverless/tree/main/components/serverless/config/crd) repository. You will need it to create the Function CR in the cluster.
 
   ```bash
   kubectl apply -f https://raw.githubusercontent.com/kyma-project/serverless/main/components/serverless/config/crd/bases/serverless.kyma-project.io_functions.yaml
@@ -216,4 +216,4 @@ You can see that Flux synchronized the resource and the new Function CR was adde
 
 ## Reverting Feature
 
-Once you set it up, Flux will keep monitoring the given Git repository folder for any changes. If you modify the existing resources directly on the cluster, Flux will automatically revert these changes and update the given resource back to its version on the `main` branch of the Git repository.  
+Once you set it up, Flux will keep monitoring the given Git repository folder for any changes. If you modify the existing resources directly in the cluster, Flux will automatically revert these changes and update the given resource back to its version on the `main` branch of the Git repository.  

docs/user/tutorials/01-60-set-external-registry.md

@@ -1,6 +1,6 @@
 # Set an External Docker Registry
 
-By default, you install Kyma with Serverless that uses the internal Docker registry running on a cluster. This tutorial shows how to override this default setup with an external Docker registry from one of these cloud providers:
+By default, you install Kyma with Serverless that uses the internal Docker registry running in a cluster. This tutorial shows how to override this default setup with an external Docker registry from one of these cloud providers:
 
 - [Docker Hub](https://hub.docker.com/)
 - [Google Artifact Registry (GAR)](https://cloud.google.com/artifact-registry)