Functions CRD and Operator

[lkingland]

Functions CRD and Operator

This is a discussion intended to help define the validity and scope of a Functions CRD and Operator.

Overview

Developers familiar with Kubernetes are accustomed to kubectl apply -f. Providing a simple CRD which defines enough about a function for the cluster to perform a build and deploy internally would both adhere to this paradigm but also be nearly frictionless from a developer's perspective given a properly configured cluster, with no required local dependencies other than kubectl and a cluster connection.

Scope

There are no features on our roadmap which require a CRD. Everything can be accomplished (and probably should be accomplished) with the existing Serving and Eventing structures. Even auto-update is likely better mediated via CI/CD than as an internal operator. Therefore the scope of this CRD and Operator is likely quite narrow: just enough to trigger an in-cluster build and deploy using a CRD which is essentially a pointer to a repository.

Considerations

One key consideration is the necessity of a properly configured cluster, with extensive user feedback to ensure this is the case.

[khusseini]

I think it would be much easier for developers to handle one CRD over the required other 4.
Since a developer would anyway have to deal with a func.yaml file, why not turning this into a kubernetes CRD? this would be a lot easier for developers to have to maintain only that one func.yaml file. Having to manage Service, Route, Configuration and Revision CRDs in order to maintain one function is frankly too much for most developers who want to focus on the code, rather than the setup and a devops team should not have to worry about this. The func cli already handles this for us, so the solution to this seems to me very... very simple. The function build is separate from this. See it this way the developers will anyway need to implement build pipelines for their other applications, so implementing a CD pipeline to just build the function like you commented above is not the problem.

So in my head a solution could look like this:

• create an operator with the operator sdk for ansible
• handle function CRDs in order to only deploy them using the func deploy cli within ansible

that said, you are completely right, that currently a function can already be handled via CRDs, I am just throwing in the point that maintaining one CRD is easier than having to maintain 4, which could be maintained by software.

What do you think?

[lkingland]

Thanks for the comment @khusseini

Yes, I agree that we would create an operator which handles a simple Functions CRD. The operator would be the one running func deploy (though it would probably use the Go client library rather than the command). This CRD simply instructs the cluster to deploy the Function which is hosted in a given Git repository.

You are also right that it is our goal with Functions to provide a single point of management where developers can define their Function as a Service, even though when it is actually deployed to the cluster it will be comprised of several components: Service, Routes, Domain Mappings, Certificates, Event Subscriptions, etc. etc.

Of course, we know that it will never be able to handle 100% of all situations, so one can always decide to just build the container with func build and then manage the individual definitions if necessary!

[juan-riveros]

Looking into this, I see a lot of talk about remote build, but that's entirely not something our organization would need if we are deploying via GitOps since we could just build the function image within CI and then have ArgoCD pull the CRD from an env repo.

It would be wonderful if the CLI could dump the CRD which could be copied to the env repo without requiring communicating to the remote cluster at all.