diff --git a/README.md b/README.md index 98e4c234a..2ed98680b 100644 --- a/README.md +++ b/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,7 +76,7 @@ kubectl apply -f https://github.com/kyma-project/serverless-manager/releases/lat ``` -### Test Integration with Lifecycle Manager on the k3d Cluster +### Test Integration with Lifecycle Manager in the k3d Cluster 1. Clone the project. @@ -84,7 +84,7 @@ kubectl apply -f https://github.com/kyma-project/serverless-manager/releases/lat 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 diff --git a/components/serverless/design/glossary_proposal.md b/components/serverless/design/glossary_proposal.md index e1a1971ba..b422ecbec 100644 --- a/components/serverless/design/glossary_proposal.md +++ b/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: diff --git a/components/serverless/design/internal_registry_garbage_collection.md b/components/serverless/design/internal_registry_garbage_collection.md index 1b30be2b0..4fcb21306 100644 --- a/components/serverless/design/internal_registry_garbage_collection.md +++ b/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. diff --git a/docs/contributor/04-10-testing-strategy.md b/docs/contributor/04-10-testing-strategy.md index 2b874d3a3..cb33c0177 100644 --- a/docs/contributor/04-10-testing-strategy.md +++ b/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 diff --git a/docs/user/00-30-development-toolkit.md b/docs/user/00-30-development-toolkit.md index 8b9153353..85c391501 100644 --- a/docs/user/00-30-development-toolkit.md +++ b/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 \ No newline at end of file diff --git a/docs/user/technical-reference/05-20-env-variables.md b/docs/user/technical-reference/05-20-env-variables.md index b404c1d7b..177908dcd 100644 --- a/docs/user/technical-reference/05-20-env-variables.md +++ b/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. | diff --git a/docs/user/technical-reference/07-60-function-configuration-file.md b/docs/user/technical-reference/07-60-function-configuration-file.md index 19c0ad5d5..e35c65eef 100644 --- a/docs/user/technical-reference/07-60-function-configuration-file.md +++ b/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 | |----------------------------------------------------------------|:--------:| ---------| ---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| diff --git a/docs/user/tutorials/01-110-override-runtime-image.md b/docs/user/tutorials/01-110-override-runtime-image.md index 63cb212fa..dabc86742 100644 --- a/docs/user/tutorials/01-110-override-runtime-image.md +++ b/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 diff --git a/docs/user/tutorials/01-120-inject-envs.md b/docs/user/tutorials/01-120-inject-envs.md index c93da9049..498c508f2 100644 --- a/docs/user/tutorials/01-120-inject-envs.md +++ b/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 diff --git a/docs/user/tutorials/01-140-use-secret-mounts.md b/docs/user/tutorials/01-140-use-secret-mounts.md index d341c8b07..7d44c5c08 100644 --- a/docs/user/tutorials/01-140-use-secret-mounts.md +++ b/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 diff --git a/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md b/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md index 02673eb78..f646aeb1e 100644 --- a/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md +++ b/docs/user/tutorials/01-30-manage-functions-with-kyma-cli.md @@ -9,7 +9,7 @@ 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 @@ -17,7 +17,7 @@ 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: diff --git a/docs/user/tutorials/01-50-sync-function-with-gitops.md b/docs/user/tutorials/01-50-sync-function-with-gitops.md index fb63deecc..56e98a117 100644 --- a/docs/user/tutorials/01-50-sync-function-with-gitops.md +++ b/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. \ No newline at end of file +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. \ No newline at end of file diff --git a/docs/user/tutorials/01-60-set-external-registry.md b/docs/user/tutorials/01-60-set-external-registry.md index ae5a67288..0abc182b5 100644 --- a/docs/user/tutorials/01-60-set-external-registry.md +++ b/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)