diff --git a/docs/assets/svls-architecture.svg b/docs/assets/svls-architecture.svg index aba23badb..78fd37f85 100644 --- a/docs/assets/svls-architecture.svg +++ b/docs/assets/svls-architecture.svg @@ -1,4 +1,3 @@ - -
Function Controller
Function Controller
Function CR
(Function)
Function CR...
Docker image
Docker image
K8s Job
K8s Job
Deployment
Deployment
Service
Service
HorizontalPodAutoscaler
HorizontalPodAutoscaler
ConfigMap
ConfigMap
creates
creates
watches
watches
creates
creates
references
refer...
pushes
pushes
creates
creates
creates and watches
creates and watches
creates
creates
creates
creates
scales
scales
exposes
expos...
references
refer...
Kyma cluster
Kyma cluster
User
User
Docker registry
Docker registry
1
1
2
2
3
3
4
4
5
5
7
7
8
8
9
9
6
6
Reference key:
Reference key:

Dashed connectors and borders represent background processes
Dashed connectors and borders re...Text is not SVG - cannot display \ No newline at end of file +
%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22%26lt%3Bfont%20style%3D%26quot%3Bfont-size%3A%2014px%3B%26quot%3B%26gt%3BUser%26lt%3B%2Ffont%26gt%3B%22%20style%3D%22text%3Bhtml%3D1%3Balign%3Dcenter%3BverticalAlign%3Dmiddle%3Bresizable%3D0%3Bpoints%3D%5B%5D%3Bautosize%3D1%3BstrokeColor%3Dnone%3BfillColor%3Dnone%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22-130%22%20y%3D%22280%22%20width%3D%2250%22%20height%3D%2230%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E
Function CR
(Function)
Function Controller
Deployment
Service
User
Reference key:
Dashed connectors and borders
represent background processes
1
2
3
4
creates
watches
creates and watches
creates
5
Kyma cluster
 \ No newline at end of file diff --git a/docs/assets/svls-running.svg b/docs/assets/svls-running.svg index 33f886314..d93400f96 100644 --- a/docs/assets/svls-running.svg +++ b/docs/assets/svls-running.svg @@ -1,4 +1,3 @@ - -
User
User
Create/Update
Deployment, Service, and/or HorizontalPodAutoscaler
Create/Update...
Set Running 
condition to True
Set Running...
creates Function
creates Function
updates Function
updates Function
Don't change condition status
Don't change condition statu...
Is Deployment, Service, or HorizontalPodAutoscaler update required?
Is Deployment...
yes
yes
no
no
Set Running 
condition to False
Set Running...
Set Running 
condition to Unknown
Set Running...
success
success
failure
failure
processing
processing
Kyma cluster
Kyma cluster
Reference key:
Reference key:

Dashed connectors and borders point to Function status conditions
Dashed connectors and borders po...
Set Running 
condition to Unknown with reason MinimumReplcasUnavailable
Set Running...
unhealthy deployment
unhealthy d...Text is not SVG - cannot display \ No newline at end of file +
User
Create/Update
Deployment and/or Service
Set Running 
condition to True
creates Function
updates Function
Don't change condition status
Is Deployment, or Service update required?
yes
no
Set Running 
condition to False
Set Running 
condition to Unknown
success
failure
processing
Kyma cluster
Reference key:

Dashed connectors and borders point to Function status conditions
Set Running 
condition to Unknown with reason MinimumReplcasUnavailable
unhealthy deployment
 \ No newline at end of file diff --git a/docs/user/00-20-configure-serverless.md b/docs/user/00-20-configure-serverless.md index ed9fac3ba..c663a51bb 100644 --- a/docs/user/00-20-configure-serverless.md +++ b/docs/user/00-20-configure-serverless.md @@ -14,23 +14,17 @@ The Serverless module has its own operator (Serverless Operator). It watches the The Serverless CR is an API to configure the Serverless module. You can use it to perform the following actions: -- Enable or disable the internal Docker registry. -- Configure the external Docker registry. - Override endpoint for traces collected by the Serverless Functions. - Override endpoint for Eventing. -- Override the target CPU utilization percentage. - Override the Function requeue duration. -- Override the Function build executor arguments. -- Override the Function build max simultaneous jobs. - Override the healthz liveness timeout. - Override the Function request body limit. - Override the Function timeout. -- Override the default build Job preset. - Override the default runtime Pod preset. - Override the default log level. - Override the default log format. - Enable network policies. -- Enable buildless mode of Serverless. +- Disable buildless mode of Serverless. The default configuration of the Serverless Module is following: @@ -44,91 +38,6 @@ The default configuration of the Serverless Module is following: enableInternal: true ``` -> [!WARNING] -> The `spec.dockerRegistry` field is deprecated and will be removed in a future version of Serverless where Functions won't require building images. - -## Procedure - -1. Go to Kyma dashboard. The URL is in the Overview section of your subaccount. -2. Choose **Modify Modules**, and in the **View** tab, choose `serverless`. -4. Go to **Edit**, and provide your configuration changes. You can use the **Form** or **YAML** tab. - -### Configuring Docker Registry - -By default, Serverless uses PersistentVolume (PV) as the internal registry to store Docker images for Functions. The default storage size of a single volume is 20 GB. This internal registry is suitable for local development. - -> [!WARNING] -> If you use Serverless for production purposes, it is recommended that you use an external registry, such as Docker Hub, Artifact Registry, or Azure Container Registry (ACR). - -Follow these steps to use the external Docker registry in Serverless: - -1. Create a Secret in the `kyma-system` namespace with the required data (`username`, `password`, `serverAddress`, and `registryAddress`): - - ```bash - kubectl create secret generic my-registry-config \ - --namespace kyma-system \ - --from-literal=username={USERNAME} \ - --from-literal=password={PASSWORD} \ - --from-literal=serverAddress={SERVER_URL} \ - --from-literal=registryAddress={REGISTRY_URL} - ``` - - > [!TIP] - > In case of DockerHub, usually the Docker registry address is the same as the account name. - - Examples: - - - - #### **Docker Hub** - - ```bash - kubectl create secret generic my-registry-config \ - --namespace kyma-system \ - --from-literal=username={USERNAME} \ - --from-literal=password={PASSWORD} \ - --from-literal=serverAddress=https://index.docker.io/v1/ \ - --from-literal=registryAddress={USERNAME} - ``` - - #### **Artifact Registry** - - ```bash - kubectl create secret generic my-registry-config \ - --namespace kyma-system \ - --from-literal=username=_json_key \ - --from-literal=password={GCR_KEY_JSON} \ - --from-literal=serverAddress=gcr.io \ - --from-literal=registryAddress=gcr.io/{YOUR_GCR_PROJECT} - ``` - - For more information on how to set up authentication for Docker with Artifact Registry, see the [Artifact Registry documentation](https://cloud.google.com/artifact-registry/docs/docker/authentication#json-key). - - #### **ACR** - - ```bash - kubectl create secret generic my-registry-config \ - --namespace kyma-system \ - --from-literal=username=00000000-0000-0000-0000-000000000000 \ - --from-literal=password={ACR_TOKEN} \ - --from-literal=serverAddress={AZ_REGISTRY_NAME}.azurecr.io \ - --from-literal=registryAddress={AZ_REGISTRY_NAME}.azurecr.io - ``` - - For more information on how to authenticate with ACR, see the [ACR documentation](https://learn.microsoft.com/en-us/azure/container-registry/container-registry-authentication?tabs=azure-cli#az-acr-login-with---expose-token). - - - -2. Reference the Secret in the Serverless CR: - - ```yaml - spec: - dockerRegistry: - secretName: my-registry-config - ``` - -The URL of the currently used Docker registry is visible in the Serverless CR status. - ### Configuring Trace Endpoint By default, the Serverless operator checks if there is a trace endpoint available. If available, the detected trace endpoint is used as the trace collector URL in Functions. @@ -154,18 +63,6 @@ By default `http://eventing-publisher-proxy.kyma-system.svc.cluster.local/publis endpoint: http://eventing-publisher-proxy.kyma-system.svc.cluster.local/publish ``` -### Configuring Target CPU Utilization Percentage - -You can set a custom target threshold for CPU utilization. The default value is set to `50%`. - -```yaml - spec: - targetCPUUtilizationPercentage: 50 -``` - -> [!WARNING] -> The `spec.targetCPUUtilizationPercentage` field is deprecated and will be removed in a future version of Serverless, where automatic HPA creation will be disabled. - ### Configuring the Function Requeue Duration By default, the Function associated with the default configuration will be requeued every 5 minutes. @@ -175,38 +72,6 @@ By default, the Function associated with the default configuration will be reque functionRequeueDuration: 5m ``` -### Configuring the Function Build Executor Arguments - -Use this label to choose the [arguments](https://github.com/GoogleContainerTools/kaniko?tab=readme-ov-file#additional-flags) passed to the Function build executor, for example: - -- `--insecure` - executor operates in an insecure mode -- `--skip-tls-verify` - executor skips the TLS certificate verification -- `--skip-unused-stages` - executor skips any stages that aren't used for the current execution -- `--log-format=text` - executor uses logs in a given format -- `--cache=true` - enables caching for the executor -- `--compressed-caching=false` - prevents tar compression for cached layers. This increases the runtime of the build, but decrease the memory usage especially for large builds. -- `--use-new-run` - improves performance by avoiding the full filesystem snapshots. - -```yaml - spec: - functionBuildExecutorArgs: "--insecure,--skip-tls-verify,--skip-unused-stages,--log-format=text,--cache=true,--use-new-run,--compressed-caching=false" -``` - -> [!WARNING] -> The `spec.functionBuildExecutorArgs` field is deprecated and will be removed in a future version of Serverless where Functions won't require building images. - -### Configuring the Function Build Max Simultaneous Jobs - -You can set a custom maximum number of simultaneous jobs which can run at the same time. The default value is set to `5`. - -```yaml - spec: - functionBuildMaxSimultaneousJobs: 5 -``` - -> [!WARNING] -> The `spec.functionBuildMaxSimultaneousJobs` field is deprecated and will be removed in a future version of Serverless where Functions won't require building images. - ### Configuring the healthz Liveness Timeout By default, Function is considered unhealthy if the liveness health check endpoint does not respond within 10 seconds. @@ -216,18 +81,6 @@ By default, Function is considered unhealthy if the liveness health check endpoi healthzLivenessTimeout: "10s" ``` -### Configuring the Default Build Job Preset - -You can configure the default build Job preset to be used. - -```yaml - spec: - defaultBuildJobPreset: "normal" -``` - -> [!WARNING] -> The `spec.defaultBuildJobPreset` field is deprecated and will be removed in a future version of Serverless where Functions won't require building images. - ### Configuring the Default Runtime Pod Preset You can configure the default runtime Pod preset to be used. diff --git a/docs/user/00-40-security-considerations.md b/docs/user/00-40-security-considerations.md index ece6cfac3..03b90f430 100644 --- a/docs/user/00-40-security-considerations.md +++ b/docs/user/00-40-security-considerations.md @@ -11,13 +11,8 @@ To eliminate potential security risks when using Functions, bear in mind these f - Kyma does not define any authorization policies that would restrict Functions' access to other resources within the namespace. If you deploy a Function in a given namespace, it can freely access all events and APIs of services within this namespace. -- Since Kubernetes is [moving from PodSecurityPolicies to PodSecurity Admission Controller](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/), Kyma Functions require running in namespaces with the `baseline` Pod security level. The `restricted` level is not currently supported due to the requirements of the Function building process. - -- The Kyma Serverless components can run with the PodSecurity Admission Controller support in the `restricted` Pod security level when using an external registry. When the Internal Docker Registry is enabled, the Internal Registry DaemonSet requires elevated privileges to function correctly, exceeding the limitations of both the `restricted` and `baseline` levels. +- Since Kubernetes is [moving from PodSecurityPolicies to PodSecurity Admission Controller](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/), traditional Kyma Functions with build jobs require running in namespaces with the `baseline` Pod security level. However, buildless mode eliminates build jobs, allowing Functions to run in namespaces with more restrictive Pod security levels such as `restricted`. - All administrators and regular users who have access to a specific namespace in a cluster can also access: - Source code of all Functions within this namespace - - Internal Docker registry that contains Function images - - Secrets allowing the build Job to pull and push images from and to the Docker registry (in non-system namespaces) - \ No newline at end of file diff --git a/docs/user/00-50-limitations.md b/docs/user/00-50-limitations.md index 75917b7aa..16e9d130c 100644 --- a/docs/user/00-50-limitations.md +++ b/docs/user/00-50-limitations.md @@ -5,7 +5,7 @@ Function Ccontroller does not serve time-critical requests from users. It reconciles Function custom resources (CR), stored at the Kubernetes API Server, and has no persistent state on its own. -Function Controller doesn't build or serve Functions using its allocated runtime resources. It delegates this work to the dedicated Kubernetes workloads. It schedules (build-time) jobs to build the Function Docker image and (runtime) Pods to serve them once they are built. +Function Controller doesn't serve Functions using its allocated runtime resources. It delegates this work to the dedicated Kubernetes workloads. Refer to the [architecture](technical-reference/04-10-architecture.md) diagram for more details. Having this in mind, also remember that Function Controller does not require horizontal scaling. @@ -13,44 +13,11 @@ It scales vertically up to `160Mi` of memory and `500m` of CPU time. ## Namespace Setup Limitations -Be aware that if you apply [LimitRanges](https://kubernetes.io/docs/concepts/policy/limit-range/) in the target namespace where you create Functions, the limits also apply to the Function workloads and may prevent Functions from being built and run. In such cases, ensure that resources requested in the Function configuration are lower than the limits applied in the namespace. +Be aware that if you apply [LimitRanges](https://kubernetes.io/docs/concepts/policy/limit-range/) in the target namespace where you create Functions, the limits also apply to the Function workloads and may prevent Functions from being run. In such cases, ensure that resources requested in the Function configuration are lower than the limits applied in the namespace. ## Limitation for the Number of Functions -There is no upper limit of Functions that you can run on Kyma. Once you define a Function, its build jobs and runtime Pods are always requested by Function Controller. It's up to Kubernetes to schedule them based on the available memory and CPU time on the Kubernetes worker nodes. This is determined mainly by the number of the Kubernetes worker nodes (and the node auto-scaling capabilities) and their computational capacity. - -## Build Phase Limitation - -> [!NOTE] -> All measurements were taken on Kubernetes with five AWS worker nodes of type m5.xlarge (four CPU 3.1 GHz x86_64 cores, 16 GiB memory). - -The time necessary to build a Function depends on the following elements: - -- Selected [build profile](technical-reference/07-80-available-presets.md#build-jobs-resources) that determines the requested resources (and their limits) for the build phase -- Number and size of dependencies that must be downloaded and bundled into the Function image -- Cluster nodes specification - - - -#### **Node.js** - -| | local-dev | no profile (no limits for resource) | -|-----------------|-----------|-------------------------------------| -| no dependencies | 24 sec | 15 sec | -| 2 dependencies | 26 sec | 16 sec | - -#### **Python** - -| | local-dev | no profile (no limits for resource) | -|-----------------|-----------|-------------------------------------| -| no dependencies | 30 sec | 16 sec | -| 2 dependencies | 32 sec | 20 sec | - - - -The shortest build time (the limit) is approximately 15 seconds and requires no limitation of the build job resources and a minimum number of dependencies that are pulled in during the build phase. - -Running multiple Function build jobs at once (especially with no limits) may drain the cluster resources. To mitigate such risk, there is an additional limit of 5 simultaneous Function builds. If a sixth one is scheduled, it is built once there is a vacancy in the build queue. +There is no upper limit of Functions that you can run on Kyma. Once you define a Function and runtime Pods are always requested by Function Controller. It's up to Kubernetes to schedule them based on the available memory and CPU time on the Kubernetes worker nodes. This is determined mainly by the number of the Kubernetes worker nodes (and the node auto-scaling capabilities) and their computational capacity. ## Runtime Phase Limitations @@ -88,6 +55,3 @@ The bigger the runtime profile, the more resources are available to serve the re Function runtime Pods can be scaled horizontally from zero up to the limits of the available resources at the Kubernetes worker nodes. See the [Use External Scalers](tutorials/01-130-use-external-scalers.md) tutorial for more information. -## In-Cluster Docker Registry - -Serverless comes with an in-cluster Docker registry for the Function images. For more information on the Docker registry configuration, see [Configuring Docker Registry](00-20-configure-serverless.md#configuring-docker-registry). diff --git a/docs/user/README.md b/docs/user/README.md index 4ee38a113..d502fc61a 100644 --- a/docs/user/README.md +++ b/docs/user/README.md @@ -19,7 +19,6 @@ The Serverless module provides the following features: - Event-driven programming model - Reduced implementation and operation effort - Function management with Kubernetes resources like [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [Services](https://kubernetes.io/docs/concepts/services-networking/service/), and [HorizontalPodAutoscalers](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) -- Docker image creation with [Kubernetes Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/job/) ## Architecture diff --git a/docs/user/_sidebar.md b/docs/user/_sidebar.md index cce82e2b8..f46f5c2db 100644 --- a/docs/user/_sidebar.md +++ b/docs/user/_sidebar.md @@ -22,20 +22,15 @@ * [Function CR](/serverless-manager/user/resources/06-10-function-cr.md) * [Serverless CR](/serverless-manager/user/resources/06-20-serverless-cr.md) * [Technical Reference](/serverless-manager/user/technical-reference/README.md) - * [Buildless Serverless](/serverless-manager/user/technical-reference/03-10-buildless-serverless.md) + * [Serverless Architecture Updates](/serverless-manager/user/technical-reference/serverless-architecture-updates.md) * [Serverless Architecture](/serverless-manager/user/technical-reference/04-10-architecture.md) - * [Internal Docker Registry](/serverless-manager/user/technical-reference/04-20-internal-registry.md) * [Environment Variables in Functions](/serverless-manager/user/technical-reference/05-20-env-variables.md) * [Sample Functions](/serverless-manager/user/technical-reference/07-10-sample-functions.md) - * [Function Processing](/serverless-manager/user/technical-reference/07-20-function-processing-stages.md) * [Git Source Type](/serverless-manager/user/technical-reference/07-40-git-source-type.md) * [Function's Specification](/serverless-manager/user/technical-reference/07-70-function-specification.md) * [Available Presets](/serverless-manager/user/technical-reference/07-80-available-presets.md) - * [Serverless Buildless Mode](/serverless-manager/user/technical-reference/03-10-buildless-serverless.md) * [Troubleshooting Guides](/serverless-manager/user/troubleshooting-guides/README.md) - * [Functions Won't Build](/serverless-manager/user/troubleshooting-guides/03-10-cannot-build-functions.md) * [Container Fails](/serverless-manager/user/troubleshooting-guides/03-20-failing-function-container.md) - * [Functions Failing To Build on k3d](/serverless-manager/user/troubleshooting-guides/03-40-function-build-failing-k3d.md) * [Serverless Periodically Restarting](/serverless-manager/user/troubleshooting-guides/03-50-serverless-periodically-restaring.md) * [Best Practices](/serverless-manager/user/08-10-best-practices.md) \ No newline at end of file diff --git a/docs/user/resources/06-10-function-cr.md b/docs/user/resources/06-10-function-cr.md index 2d9075c9c..b1c1d3637 100644 --- a/docs/user/resources/06-10-function-cr.md +++ b/docs/user/resources/06-10-function-cr.md @@ -39,9 +39,6 @@ spec: return 'Hello ' + name; } } - scaleConfig: - minReplicas: 3 - maxReplicas: 3 resourceConfiguration: function: resources: @@ -51,14 +48,6 @@ spec: requests: cpu: 500m memory: 500Mi - build: - resources: - limits: - cpu: 2 - memory: 2Gi - requests: - cpu: 1 - memory: 1Gi env: - name: PERSON_NAME value: "John" @@ -109,38 +98,32 @@ spec: **Spec:** -| Parameter | Type | Description | -| ---- | ----------- |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **annotations** | map\[string\]string | Defines annotations used in Deployment's PodTemplate and applied on the Function's runtime Pod. | +| Parameter | Type | Description | +| ---- | ----------- |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **annotations** | map\[string\]string | Defines annotations used in Deployment's PodTemplate and applied on the Function's runtime Pod. | | **env** | \[\]object | Specifies an array of key-value pairs to be used as environment variables for the Function. You can define values as static strings or reference values from ConfigMaps or Secrets. For configuration details, see the [official Kubernetes documentation](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/). | -| **labels** | map\[string\]string | Defines labels used in Deployment's PodTemplate and applied on the Function's runtime Pod. | -| **replicas** | integer | Defines the exact number of Function's Pods to run at a time. If **ScaleConfig** is configured, or if the Function is targeted by an external scaler, then the **Replicas** field is used by the relevant HorizontalPodAutoscaler to control the number of active replicas. | -| **resourceConfiguration** | object | Specifies resources requested by the Function and the build Job. | -| **resourceConfiguration.​build** | object | **Deprecated: Serverless won't build images a future version** Specifies resources requested by the build Job's Pod. | -| **resourceConfiguration.​build.​profile** | string | Defines the name of the predefined set of values of the resource. Can't be used together with **Resources**. | -| **resourceConfiguration.​build.​resources** | object | Defines the amount of resources available for the Pod. Can't be used together with **Profile**. For configuration details, see the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). | -| **resourceConfiguration.​function** | object | Specifies resources requested by the Function's Pod. | -| **resourceConfiguration.​function.​profile** | string | Defines the name of the predefined set of values of the resource. Can't be used together with **Resources**. | -| **resourceConfiguration.​function.​resources** | object | Defines the amount of resources available for the Pod. Can't be used together with **Profile**. For configuration details, see the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). | -| **runtime** (required) | string | Specifies the runtime of the Function. The available values are `nodejs20` and `python312`. | -| **runtimeImageOverride** | string | Specifies the runtime image used instead of the default one. | -| **scaleConfig** | object | **Deprecated: Serverless won't create HPA in a future version** Defines the minimum and maximum number of Function's Pods to run at a time. When it is configured, a HorizontalPodAutoscaler will be deployed and will control the **Replicas** field to scale the Function based on the CPU utilization. | -| **scaleConfig.​maxReplicas** (required) | integer | Defines the maximum number of Function's Pods to run at a time. | -| **scaleConfig.​minReplicas** (required) | integer | Defines the minimum number of Function's Pods to run at a time. | -| **secretMounts** | \[\]object | Specifies Secrets to mount into the Function's container filesystem. | -| **secretMounts.​mountPath** (required) | string | Specifies the path within the container where the Secret should be mounted. | -| **secretMounts.​secretName** (required) | string | Specifies the name of the Secret in the Function's namespace. | -| **source** (required) | object | Contains the Function's source code configuration. | -| **source.​gitRepository** | object | Defines the Function as Git-sourced. Can't be used together with **Inline**. | -| **source.​gitRepository.​auth** | object | Specifies the authentication method. Required for SSH. | -| **source.​gitRepository.​auth.​secretName** (required) | string | Specifies the name of the Secret with credentials used by the Function Controller to authenticate to the Git repository in order to fetch the Function's source code and dependencies. This Secret must be stored in the same namespace as the Function CR. | -| **source.​gitRepository.​auth.​type** (required) | string | Defines the repository authentication method. The value is either `basic` if you use a password or token, or `key` if you use an SSH key. | -| **source.​gitRepository.​baseDir** | string | Specifies the relative path to the Git directory that contains the source code from which the Function is built. | -| **source.​gitRepository.​reference** | string | Specifies either the branch name, tag or commit revision from which the Function Controller automatically fetches the changes in the Function's code and dependencies. | -| **source.​gitRepository.​url** (required) | string | Specifies the URL of the Git repository with the Function's code and dependencies. Depending on whether the repository is public or private and what authentication method is used to access it, the URL must start with the `http(s)`, `git`, or `ssh` prefix. | -| **source.​inline** | object | Defines the Function as the inline Function. Can't be used together with **GitRepository**. | -| **source.​inline.​dependencies** | string | Specifies the Function's dependencies. | -| **source.​inline.​source** (required) | string | Specifies the Function's full source code. | +| **labels** | map\[string\]string | Defines labels used in Deployment's PodTemplate and applied on the Function's runtime Pod. | +| **replicas** | integer | Defines the exact number of Function's Pods to run at a time. If **ScaleConfig** is configured, or if the Function is targeted by an external scaler, then the **Replicas** field is used by the relevant HorizontalPodAutoscaler to control the number of active replicas. | +| **resourceConfiguration** | object | Specifies resources requested by the Function. | +| **resourceConfiguration.​function** | object | Specifies resources requested by the Function's Pod. | +| **resourceConfiguration.​function.​profile** | string | Defines the name of the predefined set of values of the resource. Can't be used together with **Resources**. | +| **resourceConfiguration.​function.​resources** | object | Defines the amount of resources available for the Pod. Can't be used together with **Profile**. For configuration details, see the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/). | +| **runtime** (required) | string | Specifies the runtime of the Function. The available values are `nodejs20` and `python312`. | +| **runtimeImageOverride** | string | Specifies the runtime image used instead of the default one. | +| **secretMounts** | \[\]object | Specifies Secrets to mount into the Function's container filesystem. | +| **secretMounts.​mountPath** (required) | string | Specifies the path within the container where the Secret should be mounted. | +| **secretMounts.​secretName** (required) | string | Specifies the name of the Secret in the Function's namespace. | +| **source** (required) | object | Contains the Function's source code configuration. | +| **source.​gitRepository** | object | Defines the Function as Git-sourced. Can't be used together with **Inline**. | +| **source.​gitRepository.​auth** | object | Specifies the authentication method. Required for SSH. | +| **source.​gitRepository.​auth.​secretName** (required) | string | Specifies the name of the Secret with credentials used by the Function Controller to authenticate to the Git repository in order to fetch the Function's source code and dependencies. This Secret must be stored in the same namespace as the Function CR. | +| **source.​gitRepository.​auth.​type** (required) | string | Defines the repository authentication method. The value is either `basic` if you use a password or token, or `key` if you use an SSH key. | +| **source.​gitRepository.​baseDir** | string | Specifies the relative path to the Git directory that contains the source code from which the Function is built. | +| **source.​gitRepository.​reference** | string | Specifies either the branch name, tag or commit revision from which the Function Controller automatically fetches the changes in the Function's code and dependencies. | +| **source.​gitRepository.​url** (required) | string | Specifies the URL of the Git repository with the Function's code and dependencies. Depending on whether the repository is public or private and what authentication method is used to access it, the URL must start with the `http(s)`, `git`, or `ssh` prefix. | +| **source.​inline** | object | Defines the Function as the inline Function. Can't be used together with **GitRepository**. | +| **source.​inline.​dependencies** | string | Specifies the Function's dependencies. | +| **source.​inline.​source** (required) | string | Specifies the Function's full source code. | **Status:** @@ -159,7 +142,7 @@ spec: | **replicas** | integer | Specifies the total number of non-terminated Pods targeted by this Function. | | **runtime** | string | Specifies the **Runtime** type of the Function. | | **runtimeImage** | string | Specifies the image version used to build and run the Function's Pods. | -| **runtimeImageOverride** | string | Deprecated: Specifies the runtime image version which overrides the **RuntimeImage** status parameter. **RuntimeImageOverride** exists for historical compatibility and should be removed with v1alpha3 version. | +| **runtimeImageOverride** | string | Specifies the runtime image version which overrides the **RuntimeImage** status parameter. **RuntimeImageOverride** exists for historical compatibility and should be removed with v1alpha3 version. | @@ -169,16 +152,8 @@ Processing of a Function CR can succeed, continue, or fail for one of these reas | Reason | Type | Description | | -------------------------------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `ConfigMapCreated` | `ConfigurationReady` | A new ConfigMap was created based on the Function CR definition. | -| `ConfigMapUpdated` | `ConfigurationReady` | The existing ConfigMap was updated after changes in the Function CR name, its source code or dependencies. | | `SourceUpdated` | `ConfigurationReady` | The Function Controller managed to fetch changes in the Functions's source code and configuration from the Git repository. | | `SourceUpdateFailed` | `ConfigurationReady` | The Function Controller failed to fetch changes in the Functions's source code and configuration from the Git repository. | -| `JobFailed` | `BuildReady` | The image with the Function's configuration could not be created due to an error. | -| `JobCreated` | `BuildReady` | The Kubernetes Job resource that builds the Function image was created. | -| `JobUpdated` | `BuildReady` | The existing Job was updated after changing the Function's metadata or spec fields that do not affect the way of building the Function image, such as labels. | -| `JobRunning` | `BuildReady` | The Job is in progress. | -| `JobsDeleted` | `BuildReady` | Previous Jobs responsible for building Function images were deleted. | -| `JobFinished` | `BuildReady` | The Job was finished and the Function's image was uploaded to the Docker Registry. | | `DeploymentCreated` | `Running` | A new Deployment referencing the Function's image was created. | | `DeploymentUpdated` | `Running` | The existing Deployment was updated after changing the Function's image, scaling parameters, variables, or labels. | | `DeploymentFailed` | `Running` | The Function's Pod crashed or could not start due to an error. | @@ -197,11 +172,8 @@ These are the resources related to this CR: | Custom resource | Description | | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- | -| [ConfigMap](https://kubernetes.io/docs/concepts/configuration/configmap/) | Stores the Function's source code and dependencies. | -| [Job](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) | Builds an image with the Function's code in a runtime. | | [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) | Serves the Function's image as a microservice. | | [Service](https://kubernetes.io/docs/concepts/services-networking/service/) | Exposes the Function's Deployment as a network service inside the Kubernetes cluster. | -| [HorizontalPodAutoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) | Automatically scales the number of Function's Pods. | These components use this CR: diff --git a/docs/user/resources/06-20-serverless-cr.md b/docs/user/resources/06-20-serverless-cr.md index 8962e94d4..551e35f45 100644 --- a/docs/user/resources/06-20-serverless-cr.md +++ b/docs/user/resources/06-20-serverless-cr.md @@ -8,7 +8,7 @@ The `serverlesses.operator.kyma-project.io` CustomResourceDefinition (CRD) is a ## Sample Custom Resource -The following Serverless custom resource (CR) shows configuration of Serverless with the external registry, custom endpoints for eventing and tracing and custom additional configuration. +The following Serverless custom resource (CR) shows configuration of Serverless with custom endpoints for eventing and tracing and custom additional configuration. ```yaml apiVersion: operator.kyma-project.io/v1alpha1 @@ -19,19 +19,12 @@ The following Serverless custom resource (CR) shows configuration of Serverless name: default namespace: kyma-system spec: - dockerRegistry: - enableInternal: false - secretName: my-secret eventing: endpoint: http://eventing-publisher-proxy.kyma-system.svc.cluster.local/publish tracing: endpoint: http://telemetry-otlp-traces.kyma-system.svc.cluster.local:4318/v1/traces - targetCPUUtilizationPercentage: 50 functionRequeueDuration: 5m - functionBuildExecutorArgs: "--insecure,--skip-tls-verify,--skip-unused-stages,--log-format=text,--cache=true,--use-new-run,--compressed-caching=false" - functionBuildMaxSimultaneousJobs: 5 healthzLivenessTimeout: "10s" - defaultBuildJobPreset: "normal" defaultRuntimePodPreset: "M" logLevel: "info" logFormat: "json" @@ -63,19 +56,12 @@ For details, see the [Serverless specification file](https://github.com/kyma-pro | Parameter | Type | Description | |-------------------------------------------|---------|------------------------------------------------------------------------------------------------------------------------------------------------------| -| **dockerRegistry** | object | **Deprecated: a future Serverless version won't build images** | -| **dockerRegistry.​enableInternal** | boolean | When set to `true`, the internal Docker registry is enabled | -| **dockerRegistry.​secretName** | string | Secret used for configuration of the Docker registry | | **eventing** | object | | | **eventing.​endpoint** (required) | string | Used Eventing endpoint | | **tracing** | object | | | **tracing.​endpoint** (required) | string | Used Tracing endpoint | -| **targetCPUUtilizationPercentage** | string | **Deprecated: a future Serverless version won't create HPAs** Sets a custom CPU utilization threshold for scaling Function Pods | | **functionRequeueDuration** | string | Sets the requeue duration for Function. By default, the Function associated with the default configuration is requeued every 5 minutes | -| **functionBuildExecutorArgs** | string | **Deprecated: a future Serverless version won't build images** Specifies the arguments passed to the Function build executor | -| **functionBuildMaxSimultaneousJobs** | string | **Deprecated: a future Serverless version won't build images** A number of simultaneous jobs that can run at the same time. The default value is `5` | | **healthzLivenessTimeout** | string | Sets the timeout for the Function health check. The default value in seconds is `10` | -| **defaultBuildJobPreset** | string | **Deprecated: a future Serverless version won't build images** Configures the default build Job preset to be used | | **defaultRuntimePodPreset** | string | Configures the default runtime Pod preset to be used | | **logLevel** | string | Sets desired log level to be used. The default value is "info" | | **logFormat** | string | Sets desired log format to be used. The default value is "json" | @@ -90,18 +76,13 @@ For details, see the [Serverless specification file](https://github.com/kyma-pro | **conditions.​observedGeneration** | integer | Represents the **.metadata.generation** that the condition was set based upon. For instance, if **.metadata.generation** is currently `12`, but the **.status.conditions[x].observedGeneration** is `9`, the condition is out of date with respect to the current state of the instance. | | **conditions.​reason** (required) | string | Contains a programmatic identifier indicating the reason for the condition's last transition. Producers of specific condition types may define expected values and meanings for this field and whether the values are considered a guaranteed API. The value should be a camelCase string. This field may not be empty. | | **conditions.​status** (required) | string | Specifies the status of the condition. The value is either `True`, `False`, or `Unknown`. | -| **conditions.​type** (required) | string | Specifies the condition type in camelCase or in `foo.example.com/CamelCase`. Many **.conditions.type** values are consistent across resources like `Available`, but because arbitrary conditions can be useful (see **.node.status.conditions**), the ability to deconflict is important. The regex it matches is `(dns1123SubdomainFmt/)?(qualifiedNameFmt)`. | -| **dockerRegistry** | string | Used registry configuration. Contains registry URL or "internal". | +| **conditions.​type** (required) | string | Specifies the condition type in camelCase or in `foo.example.com/CamelCase`. Many **.conditions.type** values are consistent across resources like `Available`, but because arbitrary conditions can be useful (see **.node.status.conditions**), the ability to deconflict is important. The regex it matches is `(dns1123SubdomainFmt/)?(qualifiedNameFmt)`. | | | **eventingEndpoint** | string | Used Eventing endpoint. | | **served** (required) | string | Served signifies that current Serverless is managed. Value can be one of `True`, or `False`. | | **state** | string | Signifies the current state of Serverless. Value can be one of `Ready`, `Processing`, `Error`, or `Deleting`. | -| **tracingEndpoint** | string | Used Tracing endpoint. | -| **targetCPUUtilizationPercentage** | string | Used target CPU utilization percentage. | -| **functionRequeueDuration** | string | Used the Function requeue duration. | -| **functionBuildExecutorArgs** | string | Used the Function build executor arguments. | -| **functionBuildMaxSimultaneousJobs** | string | Used the Function build max number of simultaneous jobs. | -| **healthzLivenessTimeout** | string | Used the healthz liveness timeout. | -| **defaultBuildJobPreset** | string | Used the default build Job preset. | +| **tracingEndpoint** | string | Used Tracing endpoint. | | +| **functionRequeueDuration** | string | Used the Function requeue duration. | | +| **healthzLivenessTimeout** | string | Used the healthz liveness timeout. | | | **defaultRuntimePodPreset** | string | Used the default runtime Pod preset. | | **logLevel** | string | Used the log level. | | **logFormat** | string | Used the log format. | diff --git a/docs/user/technical-reference/03-10-architecture-updates.md b/docs/user/technical-reference/03-10-architecture-updates.md new file mode 100644 index 000000000..979d12c53 --- /dev/null +++ b/docs/user/technical-reference/03-10-architecture-updates.md @@ -0,0 +1,22 @@ +# Build-less mode of Serverless + +## Benefits + +- **Simplified architecture**: By separating the Docker Registry into its own module, the Serverless module is now more lightweight and easier to manage. +- **Faster deployment**: The removal of the build job reduces the time required to deploy Functions. +- **Dynamic dependency resolution**: Dependencies are resolved at runtime, allowing for more flexibility in managing library versions. +- **Improved flexibility**: Injecting Function code into the runtime Pod simplifies the deployment process and reduces image management overhead. +- **Reduced resource consumption**: Eliminating build jobs means Serverless no longer requires computational resources from worker nodes for image building. +- **Enhanced security**: By removing build jobs, Functions can run in namespaces with more restrictive Pod security levels enabled. + +## What Changes with Buildless Mode + +- Your Serverless module no longer includes an internal Docker Registry. +- Function builds are eliminated. Your Functions use a base image that mounts dependencies dynamically at runtime. +- Function dependencies are downloaded each time a Function Pod starts. This means different replicas of the same Function may use different dependency versions if you don't pin exact versions. +- Your Function code is injected directly into runtime Pods without requiring pre-built container images. + +## Use Fixed Dependency Versions + +- **Avoid using `latest` versions of Function dependencies**: Since dependencies are resolved at the Function's Pod start time in buildless mode, using `latest` versions can lead to inconsistencies between replicas of the same Function. This may be the case when the dependency provider releases a new version after one replica is already running and before another replica is created due to auto-scaling. Always specify exact versions of dependencies to ensure stability and predictability. +- **Dependency resolution behavior**: Be aware that each replica of a Function may resolve and use a different version of a dependency if the version is not explicitly pinned. \ No newline at end of file diff --git a/docs/user/technical-reference/03-10-buildless-serverless.md b/docs/user/technical-reference/03-10-buildless-serverless.md deleted file mode 100644 index 066f6b305..000000000 --- a/docs/user/technical-reference/03-10-buildless-serverless.md +++ /dev/null @@ -1,36 +0,0 @@ -# Serverless Buildless Mode - -Learn how to accelerate your development with Serverless buildless mode. - -From the beginning, Kyma Serverless has aimed to accelerate the development of fast prototypes by allowing users to focus on business logic rather than containerization and Kubernetes deployment. Our goal is to remove operational barriers so developers can iterate quickly and efficiently. - -With the introduction of buildless mode, we significantly shortened the feedback loop during prototype development by eliminating the image build step in Kyma runtime. In buildless mode, instead of building and pushing custom Function images into the in-cluster registry, your code and dependencies are mounted into Kyma-provided runtime images. This approach positions Kyma Serverless as a more efficient development tool, enabling even faster iteration. Additionally, it eliminates the architectural complexities and limitations of deploying Serverless Functions on Kubernetes. - -## Features - -- **Faster deployment**: Even though Function dependencies are resolved and downloaded at the start time of each Function, the overall time required for the Function to become ready is significantly shorter, as there is no need to wait for a build Job to complete before the Function Pod is scheduled. -- **Resource efficiency**: Eliminates the need for Serverless to acquire computational resources from worker nodes to build the image. -- **Enhanced security**: By eliminating build jobs, Functions can run in namespaces with more restrictive Pod security levels enabled. -- **No additional storage required**: No additional storage resources are used to store the Function image. -- **Simplified Architecture**: The Serverless module no longer requires Docker Registry, making it more lightweight and easier to manage. - -## Outcomes of Switching to Buildless Mode - -- The internal resources used for storing custom Function images (Docker Registry) are uninstalled from the Serverless module -- Your existing Functions are redeployed without downtime and started as Pods based on Kyma-provided images with your handler code and dependencies mounted. -- Build Jobs associated with your Function are deleted. -- All fields that were deprecated in the Serverless [1.6.0 release](https://github.com/kyma-project/serverless/releases/tag/1.6.0) are no longer functional in buildless mode: - - [Function CRD](https://kyma-project.io/#/serverless-manager/user/resources/06-10-function-cr) - - `spec.scaleConfig` - for existing Functions with `scaleConfig` defined, the `HorizontalPodAutoscaler` objects are not deleted upon switching to buildless mode, but are no longer managed by the Serverless module. To learn how to scale Functions, see [Use External Scalers](https://kyma-project.io/#/serverless-manager/user/tutorials/01-130-use-external-scalers). - - `spec.resourceConfiguration.​build` - - [Serverless CRD](https://kyma-project.io/#/serverless-manager/user/resources/06-20-serverless-cr) - - `spec.dockerRegistry` - - `spec.targetCPUUtilizationPercentage` - - `spec.functionBuildExecutorArgs` - - `spec.functionBuildMaxSimultaneousJobs` - - `spec.defaultBuildJobPreset` - -## Using Fixed Dependency Versions - -- **Avoid using `latest` versions of Function dependencies**: Since dependencies are resolved at Function's Pod start time in buildless mode, using `latest` versions can lead to inconsistencies between replicas of the same Function. This may be the case when the dependency provider releases a new version after one replica is already running and before another replica is created due to auto-scaling. Always specify exact versions of dependencies to ensure stability and predictability. -- **Dependency resolution behavior**: Be aware that each replica of a Function may resolve and use a different dependency version if the version is not explicitly pinned. diff --git a/docs/user/technical-reference/04-10-architecture.md b/docs/user/technical-reference/04-10-architecture.md index d13ae3669..08f9f0ade 100644 --- a/docs/user/technical-reference/04-10-architecture.md +++ b/docs/user/technical-reference/04-10-architecture.md @@ -1,6 +1,6 @@ # Serverless Architecture -Serverless relies heavily on Kubernetes resources. It uses [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [Services](https://kubernetes.io/docs/concepts/services-networking/service/) and [HorizontalPodAutoscalers](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) to deploy and manage Functions, and [Kubernetes Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) to create Docker images. See how these and other resources process a Function within a Kyma cluster: +Serverless relies heavily on Kubernetes resources. It uses [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) and [Services](https://kubernetes.io/docs/concepts/services-networking/service/) to deploy and manage Functions. See how these and other resources process a Function within a Kyma cluster: ![Serverless architecture](../../assets/svls-architecture.svg) @@ -9,20 +9,10 @@ Serverless relies heavily on Kubernetes resources. It uses [Deployments](https:/ 1. Create a Function either through the UI or by applying a Function custom resource (CR). This CR contains the Function definition (business logic that you want to execute) and information on the environment on which it should run. -2. Before the Function can be saved or modified, it is first updated and then verified by the defaulting and validation webhooks respectively. +2. The Function CR is processed by the Function Controller (FC), which validates and updates the resource. -3. Function Controller (FC) detects the new, validated Function CR. +3. FC creates a Deployment to manage the Function's Pods. -4. FC creates a ConfigMap with the Function definition. +4. FC creates a Service to expose the Function. -5. Based on the ConfigMap, FC creates a Kubernetes Job that triggers the creation of a Function image. - -6. The Job creates a Pod which builds the production Docker image based on the Function's definition. The Job then pushes this image to a Docker registry. - -7. FC monitors the Job status. When the image creation finishes successfully, FC creates a Deployment that uses the newly built image. - -8. FC creates a Service that points to the Deployment. - -9. FC creates a HorizontalPodAutoscaler that automatically scales the number of Pods in the Deployment based on the observed CPU utilization. - -10. FC waits for the Deployment to become ready. +5. FC waits for the Deployment to become ready. diff --git a/docs/user/technical-reference/04-20-internal-registry.md b/docs/user/technical-reference/04-20-internal-registry.md deleted file mode 100644 index 3257f2aa0..000000000 --- a/docs/user/technical-reference/04-20-internal-registry.md +++ /dev/null @@ -1,22 +0,0 @@ -# Internal Docker Registry - -By default, the Kyma Serverless module comes with the internal Docker registry, which stores the Function container images without using the third-party registry. - -The internal Docker registry is not recommended for production, as it's not deployed in the High Availability (HA) setup and has limited storage space and no garbage collection of the orphaned images. - -Still, it is very convenient for development and getting first-time experience with Kyma Serverless. - -See the following diagram to learn how it works: - -![Serverless architecture](../../assets/svls-internal-registry.svg) - -1. Build job pushes the Function image to the Docker registry using the in-cluster URL. -2. The Kubernetes DNS resolves the internal Docker registry URL to the actual IP address. -3. [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/) fetches the image using the URL: `localhost:{node_port}/{image}`. -4. NodePort allows kubelet to get into the cluster network, translate `localhost` to `internal-registry.kyma-system.svc.cluster.local`, and ask the Kubernetes DNS to resolve the name. -5. The Kubernetes DNS service resolves the name and provides the IP of the internal Docker registry. - -> [!NOTE] -> kubelet cannot resolve the in-cluster URL. That's why Serverless uses the NodePort service. - -The NodePort service routing assures that the pull request reaches the internal Docker registry regardless of whether it is from a different node. diff --git a/docs/user/technical-reference/07-20-function-processing-stages.md b/docs/user/technical-reference/07-20-function-processing-stages.md index 8d2f5b396..9f4a58b9d 100644 --- a/docs/user/technical-reference/07-20-function-processing-stages.md +++ b/docs/user/technical-reference/07-20-function-processing-stages.md @@ -3,14 +3,13 @@ From the moment you [create a Function](../tutorials/01-10-create-inline-function.md) (Function CR) until the time it is ready, it goes through three processing stages that are defined as these condition types: 1. `ConfigurationReady` (PrinterColumn `CONFIGURED`) -2. `BuildReady` (PrinterColumn `BUILT`) 3. `Running` (PrinterColumn `RUNNING`) For a Function to be considered ready, the status of all three conditions must be `True`: ```bash -NAME CONFIGURED BUILT RUNNING RUNTIME VERSION AGE -test-function True True True nodejs20 1 96s +NAME CONFIGURED RUNNING RUNTIME VERSION AGE +test-function True True nodejs20 1 96s ``` When you update an existing Function, conditions change asynchronously depending on the change type. @@ -22,26 +21,15 @@ The diagrams illustrate all three core status changes in the Function processing ## Configured -This initial phase starts when you create a Function CR with configuration specifying the Function's setup. It ends with creating a ConfigMap that is used as a building block for a Function image. +This initial phase starts when you create a Function CR with configuration specifying the Function's setup. ![Function configured](../../assets/svls-configured.svg) -## Built - -This phase involves creating and processing the Job CR. It ends successfully when the Function image is built and sent to the Docker registry. If the image already exists and only an update is required, the Docker image receives a new tag. - -Updating an existing Function requires an image rebuild only if you change the Function's body (**source**) or dependencies (**deps**). An update of a Function's other configuration details, such as environment variables, replicas, resources, or labels, does not require image rebuild because it only affects the Deployment. - -> [!NOTE] -> Each time you update a Function's configuration, the Function Controller deletes all previous Job CRs for the given Function's **UID**. - -![Function built](../../assets/svls-built.svg) - ## Running -This stage revolves around creating a Deployment, Service and HorizontalPodAutoscaler or updating them when configuration changes were made in the Function CR or the Function image was rebuilt. +This stage revolves around creating a Deployment and Service or updating them when configuration changes were made in the Function CR. -In general, the Deployment is considered updated when both configuration and the image tag in the Deployment are up to date. Service and HorizontalPodAutoscaler are considered updated when there are proper labels set and configuration is up to date. +In general, the Deployment is considered updated when its configuration is up to date. Service is considered updated when proper labels are set and the configuration is up to date. Thanks to the implemented reconciliation loop, the Function Controller constantly observes all newly created or updated resources. If it detects changes, it fetches the appropriate resource's status and only then updates the Function's status. diff --git a/docs/user/technical-reference/07-80-available-presets.md b/docs/user/technical-reference/07-80-available-presets.md index a76f9cc08..91f73fd4e 100644 --- a/docs/user/technical-reference/07-80-available-presets.md +++ b/docs/user/technical-reference/07-80-available-presets.md @@ -1,9 +1,6 @@ # Available Presets -Function's resources and replicas as well as resources for image-building Jobs are based on presets. A preset is a predefined group of values. There are two groups of presets defined for a Function CR and include the presents for: - -- Function's resources -- Image-building Job's resources +Function's resources and replicas are based on presets. A preset is a predefined group of values. ## Usage @@ -21,15 +18,4 @@ For example, to modify the default values for **buildResources**, remove all its | `L` | `400m` | `512Mi` | `800m` | `1024Mi` | | `XL` | `800m` | `1024Mi` | `1600m` | `2048Mi` | -To apply values ​​from a given preset, use the **serverless.kyma-project.io/function-resources-preset: {PRESET}** label in the Function CR. - -### Build Job's Resources - -| Preset | Request CPU | Request memory | Limit CPU | Limit memory | -| - | - | - | - | - | -| `local-dev` | `200m` | `200Mi` | `400m` | `400Mi` | -| `slow` | `200m` | `200Mi` | `700m` | `700Mi` | -| `normal` | `500m` | `700Mi` | `1100m` | `1100Mi`| -| `fast` | `900m` | `1100Mi` | `1700m` | `1100Mi`| - -To apply values ​​from a given preset, use the **serverless.kyma-project.io/build-resources-preset: {PRESET}** label in the Function CR. \ No newline at end of file +To apply values ​​from a given preset, use the **serverless.kyma-project.io/function-resources-preset: {PRESET}** label in the Function CR. \ No newline at end of file diff --git a/docs/user/troubleshooting-guides/03-10-cannot-build-functions.md b/docs/user/troubleshooting-guides/03-10-cannot-build-functions.md deleted file mode 100644 index 077b02817..000000000 --- a/docs/user/troubleshooting-guides/03-10-cannot-build-functions.md +++ /dev/null @@ -1,67 +0,0 @@ -# Failure to Build Functions - -## Symptom - -You have issues when building your Function. - -## Cause - -In its default configuration, Serverless uses persistent volumes as the internal registry to store Docker images for Functions. The default storage size of such a volume is 20 GB. When this storage becomes full, you will have issues with building your Functions. - -## Remedy - -As a workaround, increase the default capacity up to a maximum of 100 GB by editing the `serverless-docker-registry` PersistentVolumeClaim (PVC) object on your cluster. - -1. Edit the `serverless-docker-registry` PVC: - - ```bash - kubectl edit pvc -n kyma-system serverless-docker-registry - ``` - -2. Change the value of **spec.resources.requests.storage** to higher, such as 30 GB, to increase the PVC capacity: - - ```yaml - ... - spec: - resources: - requests: - storage: 30Gi - ``` - -3. Save the changes and wait for a few minutes. Use this command to check if the **CAPACITY** of the `serverless-docker-registry` PVC has changed as expected: - - ```bash - kubectl get pvc serverless-docker-registry -n kyma-system - ``` - - You should get the following result: - - ```bash - NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE - serverless-docker-registry Bound pvc-a69b96hc-ahbc-k85d-0gh6-19gkcr4yns4k 30Gi RWO standard 23d - ``` - -If the value of the storage does not change, restart the Pod to which this PVC is bound to finish the volume resize. - -To do this, follow these steps: - -1. List all available Pods in the `kyma-system` namespace: - - ```bash - kubectl get pods -n kyma-system - ``` - -2. Search for the Pod with the `serverless-docker-registry-{UNIQUE_ID}` name and delete it. See the example below: - - ```bash - kubectl delete pod serverless-docker-registry-6869bd57dc-9tqxp -n kyma-system - ``` - - > [!WARNING] - > Do not remove Pods named `serverless-docker-registry-self-signed-cert-{UNIQUE_ID}`. - -3. Search for the `serverless-docker-registry` PVC again to check that the capacity was resized: - - ```bash - kubectl get pvc serverless-docker-registry -n kyma-system - ``` diff --git a/docs/user/troubleshooting-guides/03-40-function-build-failing-k3d.md b/docs/user/troubleshooting-guides/03-40-function-build-failing-k3d.md deleted file mode 100644 index aee50fe99..000000000 --- a/docs/user/troubleshooting-guides/03-40-function-build-failing-k3d.md +++ /dev/null @@ -1,52 +0,0 @@ -# Functions Failing to Build on k3d - -## Symptom - -There are rare cases, for some k3d versions and configurations, where users experience Functions failing to be built. - -Your Function cannot be built and you get the following output: - - ```bash - $ kubectl get functions.serverless.kyma-project.io nyfun - NAME CONFIGURED BUILT RUNNING RUNTIME VERSION AGE - myfun True False nodejs20 1 3h15m - ``` - -Additionally, the Function build job shows the following error, meaning that your host k3d environment is likely to experience the problem: - - ```bash - $ kubectl logs myfun-build-zqhk8-7xl6h - kaniko should only be run inside of a container, run with the --force flag if you are sure you want to continue - ``` - -## Cause - -This problem originates in [kaniko](https://github.com/GoogleContainerTools/kaniko) - the container image build tool used in Kyma. kaniko is designed to be run in a container and this is how it is executed in Kyma (as build jobs). -kaniko has a detection mechanism to verify whether the build is actually executed in a container and fails in case it is not. -This detection mechanism has issues and in some circumstances (that is, hosts with cgroups in version 2 or other, not yet clearly identified) it shows a false positive result. - -Related issues: - -- https://github.com/kyma-project/kyma/issues/13051 -- https://github.com/GoogleContainerTools/kaniko/issues/1592 - -## Remedy - -You can force kaniko to skip the verification by overriding the kaniko execution arguments with the `--force` flag. - -Introduce a file with overrides, for example `my-overrides.yaml`. - - ```yaml - serverless: - containers: - manager: - envs: - functionBuildExecutorArgs: - value: --insecure,--skip-tls-verify,--skip-unused-stages,--log-format=text,--cache=true,--use-new-run,--compressed-caching=false,--force - ``` - -Use the file to override the default configuration while deploying Kyma on your k3d instance: - - ```bash - kyma deploy --values-file my-overrides.yaml - ``` diff --git a/docs/user/tutorials/01-60-set-external-registry.md b/docs/user/tutorials/01-60-set-external-registry.md deleted file mode 100644 index e257e6861..000000000 --- a/docs/user/tutorials/01-60-set-external-registry.md +++ /dev/null @@ -1,244 +0,0 @@ -# Set an External Docker Registry - -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) -- [Azure Container Registry (ACR)](https://azure.microsoft.com/en-us/services/container-registry/) - -> [!WARNING] -> Function images are not cached in the Docker Hub. The reason is that this registry is not compatible with the caching logic defined in [Kaniko](https://cloud.google.com/cloud-build/docs/kaniko-cache) that Serverless uses for building images. - -## Prerequisites - - - -#### **Docker Hub** - -- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) - -#### **GAR** - -- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) -- [gcloud](https://cloud.google.com/sdk/gcloud/) -- [Google Cloud Platform (GCP)](https://cloud.google.com) project - -#### **ACR** - -- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) -- [Azure CLI](https://docs.microsoft.com/en-us/cli/azure) -- [Microsoft Azure](http://azure.com) subscription - - - -## Steps - -### Create Required Cloud Resources - - - -#### **Docker Hub** - -1. Run the `export {VARIABLE}={value}` command to set up these environment variables, where: - - - **USER_NAME** is the name of the account in the Docker Hub. - - **PASSWORD** is the password for the account in the Docker Hub. - - **SERVER_ADDRESS** is the server address of the Docker Hub. At the moment, Kyma only supports the `https://index.docker.io/v1/` server address. - - **REGISTRY_ADDRESS** is the registry address in the Docker Hub. - - > [!TIP] - > Usually, the Docker registry address is the same as the account name. - - Example: - - ```bash - export USER_NAME=kyma-rocks - export PASSWORD=admin123 - export SERVER_ADDRESS=https://index.docker.io/v1/ - export REGISTRY_ADDRESS=kyma-rocks - ``` - -#### **GAR** - -To use GAR, create a Google service account that has a private key and the **Storage Admin** role permissions. Follow these steps: - -1. Run the `export {VARIABLE}={value}` command to set up these environment variables, where: - - - **SA_NAME** is the name of the service account. - - **SA_DISPLAY_NAME** is the display name of the service account. - - **PROJECT** is the GCP project ID. - - **SECRET_FILE** is the path to the private key. - - **ROLE** is the **Storage Admin** role bound to the service account. - - **SERVER_ADDRESS** is the server address of the Docker registry. - - Example: - - ```bash - export SA_NAME=my-service-account - export SA_DISPLAY_NAME=service-account - export PROJECT=test-project-012345 - export SECRET_FILE=my-private-key-path - export ROLE=roles/storage.admin - export SERVER_ADDRESS=gar.io - ``` - -2. When you communicate with Google Cloud for the first time, set the context for your Google Cloud project. Run this command: - - ```bash - gcloud config set project ${PROJECT} - ``` - -3. Create a service account. Run: - - ```bash - gcloud iam service-accounts create ${SA_NAME} --display-name ${SA_DISPLAY_NAME} - ``` - -4. Add a policy binding for the **Storage Admin** role to the service account. Run: - - ```bash - gcloud projects add-iam-policy-binding ${PROJECT} --member=serviceAccount:${SA_NAME}@${PROJECT}.iam.gserviceaccount.com --role=${ROLE} - ``` - -5. Create a private key for the service account: - - ```bash - gcloud iam service-accounts keys create ${SECRET_FILE} --iam-account=${SA_NAME}@${PROJECT}.iam.gserviceaccount.com - ``` - -6. Export the private key as an environment variable: - - ```bash - export GCS_KEY_JSON=$(< "$SECRET_FILE" base64 | tr -d '\n') - ``` - -#### **ACR** - -Create an ACR and a service principal. Follow these steps: - -1. Run the `export {VARIABLE}={value}` command to set up these environment variables, where: - - - **AZ_REGISTRY_NAME** is the name of the ACR. - - **AZ_RESOURCE_GROUP** is the name of the resource group. - - **AZ_RESOURCE_GROUP_LOCATION** is the location of the resource group. - - **AZ_SUBSCRIPTION_ID** is the ID of the Azure subscription. - - **AZ_SERVICE_PRINCIPAL_NAME** is the name of the Azure service principal. - - **ROLE** is the **acrpush** role bound to the service principal. - - **SERVER_ADDRESS** is the server address of the Docker registry. - - Example: - - ```bash - export AZ_REGISTRY_NAME=registry - export AZ_RESOURCE_GROUP=my-resource-group - export AZ_RESOURCE_GROUP_LOCATION=westeurope - export AZ_SUBSCRIPTION_ID=123456-123456-123456-1234567 - export AZ_SERVICE_PRINCIPAL_NAME=acr-service-principal - export ROLE=acrpush - export SERVER_ADDRESS=azurecr.io - ``` - -2. When you communicate with Microsoft Azure for the first time, log into your Azure account. Run this command: - - ```bash - az login - ``` - -3. Create a resource group. Run: - - ```bash - az group create --name ${AZ_RESOURCE_GROUP} --location ${AZ_RESOURCE_GROUP_LOCATION} --subscription ${AZ_SUBSCRIPTION_ID} - ``` - -4. Create an ACR. Run: - - ```bash - az acr create --name ${AZ_REGISTRY_NAME} --resource-group ${AZ_RESOURCE_GROUP} --subscription ${AZ_SUBSCRIPTION_ID} --sku {Basic, Classic, Premium, Standard} - ``` - -5. Obtain the full ACR ID. Run: - - ```bash - export AZ_REGISTRY_ID=$(az acr show --name ${AZ_REGISTRY_NAME} --query id --output tsv) - ``` - -6. Create a service principal with rights scoped to the ACR. Run: - - ```bash - export SP_PASSWORD=$(az ad sp create-for-rbac --name http://${AZ_SERVICE_PRINCIPAL_NAME} --scopes ${AZ_REGISTRY_ID} --role ${ROLE} --query password --output tsv) - export SP_APP_ID=$(az ad sp show --id http://${AZ_SERVICE_PRINCIPAL_NAME} --query appId --output tsv) - ``` - - Alternatively, assign the desired role to the existing service principal. Run: - - ```bash - export SP_APP_ID=$(az ad sp show --id http://${AZ_SERVICE_PRINCIPAL_NAME} --query appId --output tsv) - export SP_PASSWORD=$(az ad sp show --id http://${AZ_SERVICE_PRINCIPAL_NAME} --query password --output tsv) - az role assignment create --assignee ${SP_APP_ID} --scope ${AZ_REGISTRY_ID} --role ${ROLE} - ``` - - - -### Override Serverless Configuration - -Prepare yaml file with overrides that match your Docker registry provider: - - - -#### **Docker Hub** - -```bash -cat > docker-registry-overrides.yaml < docker-registry-overrides.yaml < docker-registry-overrides.yaml < - -> [!WARNING] -> If you want to set an external Docker registry before you install Kyma, manually apply the Secret to the cluster before you run the installation script. - -### Apply Configuration - -Deploy Kyma with different configuration for Docker registry . Run: - -```bash -kyma deploy --values-file docker-registry-overrides.yaml -``` - -> [!NOTE] -> To learn more, read about [changing Kyma configuration](https://kyma-project.io/docs/kyma/latest/04-operation-guides/operations/03-change-kyma-config-values). diff --git a/docs/user/tutorials/01-90-set-asynchronous-connection.md b/docs/user/tutorials/01-90-set-asynchronous-connection.md index cf568ab4d..2cc693252 100644 --- a/docs/user/tutorials/01-90-set-asynchronous-connection.md +++ b/docs/user/tutorials/01-90-set-asynchronous-connection.md @@ -111,7 +111,7 @@ This tutorial shows only one possible use case. There are many more use cases on kyma function create nodejs emitter --source handler.js --dependencies package.json ``` - Your Function is now built and deployed in Kyma runtime. Kyma exposes it through the APIRule. The incoming payloads are processed by your emitter Function. It then sends the sanitized content to the workload that subscribes to the selected event type. In our case, it's the receiver Function. + Your Function is now deployed in Kyma runtime. Kyma exposes it through the APIRule. The incoming payloads are processed by your emitter Function. It then sends the sanitized content to the workload that subscribes to the selected event type. In our case, it's the receiver Function. 4. Expose Function by creating the APIRule CR: @@ -187,7 +187,7 @@ This tutorial shows only one possible use case. There are many more use cases on kyma function create nodejs receiver --source handler.js --dependencies package.json ``` - The Function is configured, built, and deployed in Kyma runtime. The Subscription becomes active and all events with the selected type are processed by the Function. + The Function is configured and deployed in Kyma runtime. The Subscription becomes active and all events with the selected type are processed by the Function. 2. Subscribe the `receiver` Function to the event: