Installing OpenFunction and its dependencies with Helm

[tpiperatgod]

Motivation

OpenFunction implemented a framework for lifecycle management of the basic business unit "function". In this architecture we use Shipwright (and Tekton for the build pipeline), a component for OCI image building from "function" to "application"; Knative, an engine for synchronous functions; KEDA for event-driven mechanism; Dapr for application distributed responsiveness; and Ingress Nginx for "function" entry.

This shows the cloud-native character of OpenFunction, but also poses a challenge for OpenFunction deployment - we need to provide a convenient and customizable solution for users to deploy OpenFunction and its corresponding dependencies according to requirement scenarios.

We can divide the capabilities of OpenFunction from the user's perspective into:

1. build - Transform "function" to "application", generate OCI image and export
2. serving - Deploying "functions" (in the form of OCI images) to cluster to create serverless workloads with event-driven, auto-scaling capabilities

At the same time, OpenFunction decouples components and capabilities based on the two kinds of services mentioned above, which means that users who only need "build" capabilities do not need to deploy components such as KEDA, Knative, Dapr in the cluster; users who only need "serving" capabilities do not need to deploy components such as Shipwright, Tekton in the cluster.

Now, OpenFunction can implement the above requirements via CLI (ofn). In the CLI we do the following:

1. calculate the inventory of components to be installed based on the parameters passed to ofn by the user
2. locate the YAML file address of the installed component according to the component inventory
3. install the component on a different OS by running kubectl apply -f <yaml file> from the shell

This approach meets most of the current needs, but there are still many problems:

1. we currently use dapr init -k to install Dapr, which means that we cannot standardize the installation of all components
2. we use a lot of shell commands to perform tasks on different operating systems, so we need to suffer from the increased cost of differentiation
3. the OpenFunction CLI itself is not cloud-native and we need a more native solution

Goals

Therefore we want to complete the installation of the components via the Helm. We expect to achieve the following after the retrofit:

• users can use Helm install to install OpenFunction and its dependencies, and control the deployment of dependencies based on parameters
• change the deployment methods in the OpenFunction CLI from execution via shell to calling the Helm API

Actions

• Phase 1

  • [x] Create charts directory in the main repository to store Helm chart files for each component

  • [x] Complete the Dapr chart

  • [x] Complete the KEDA chart

  • [x] Complete the Shipwright chart

  • [x] Complete the Tekton Pipeline chart

  • [x] Complete the Knative Serving chart

  • [x] Complete the Ingress Nginx chart

  • [x] Complete the OpenFunction chart

• Phase 2

  • [ ] Change the way components are installed in the CLI from using shell commands to calling the Helm API

[tpiperatgod]

Additional Information

• Shipwright, no Helm chart yet
• Tekton Pipeline, no Helm chart yet
• Knative Serving, no Helm chart yet
• KEDA, with Helm chart: https://github.com/kedacore/charts
• Dapr, with Helm chart: https://github.com/dapr/helm-charts
• Ingress Nginx, with Helm chart: https://github.com/kubernetes/ingress-nginx/tree/main/charts/ingress-nginx

[wrongerror]

@benjaminhuo @tpiperatgod When we create an openfunction release through helm, should the namespace of the dependent component be set to release.Namespace or each component uses a separate namespace, such as dapr using dapr-system, and tekton-pipelines using tekton-piplines. This creates a problem if different components use different namespaces: managing a single release across multiple namespaces. Although setting the namespace manually in helm3 is not a best practice, we can still override the relevant namespace via global variables. Do you have any suggestions?

[benjaminhuo]

Each component should be installed to their own ns

[wrongerror]

That for the components that already have helm chart we need to pull the component charts to openfunction/charts and then modify them, dapr helm chart has multiple versions, we only modify the latest version to support it?

[benjaminhuo]

why we need to modify each component's chart? I think just keep it as it is is ok

[wrongerror]

https://github.com/helm/helm/issues/5358 This issue is similar with I mentioned above

[wrongerror]

Is cert-manger still required as a dependency in release 0.6.0? I don't see it in the proposal's dependency list, but I see the relevant configuration in bundle.yaml.

[tpiperatgod]

Is cert-manger still required as a dependency in release 0.6.0? I don't see it in the proposal's dependency list, but I see the relevant configuration in bundle.yaml.

Yes, cert-manager is required for v0.6.0 while for later versions it is the component that is not wanted.