knativeknative-serving

How to extend knative serving features and add new features to it?


I'm currently evaluating Knative Serving as an alternative to deploy my applications to Kubernetes. I'm wondering if it is possible is to extend Knative features to offer more capabilities to my application developers, for example, I would like them to define other custom infrastructure, like cloud databases, or to let them to configure Istio features, like Authorization policies, using only the Service yaml manifest without the necessity to deploy other Kubernetes yamls. At the end of the day, I would like to have only the Knative Service as my application contract and nothing else.

Is it possible to do this? Is there any documentation on how to do it?


Solution

  • I'm glad to hear that you're finding Knative useful! Knative is intended to complement, rather than replace Kubernetes, so I'm going to point you to a few useful Kubernetes patterns which will work with Knative (rather than suggesting that you fork or extend the Knative controllers to add capabilities like database deployment).

    For features like Cloud Databases, I'd look into the "operator" pattern. If you're working with cloud providers, Crossplane provides a set of custom resources to allow developers to manage cloud resources using custom kubernetes objects. For example, here is the AWS RDSInstance type for provisioning RDS databases.

    For Istio authorization policy in particular, you might simply pre-configure a set of canned authentication policies and then use workload labels to select which ones should apply to a particular workload. (Note, I'm not an Istio user, so this is based on reading their docs, rather than practical experience.) If you need something more dynamic (for example, an annotation to indicate which principals can invoke the service), you'll probably want to write a controller to watch the Knative Services and/or Deployments in the cluster and create the appropriate Istio AuthorizationPolicies on the fly.

    It sounds like you're already using OAM, so it might make more sense to build this into your application definition there; Knative Serving might best be thought of as "a better version of Deployment" than "a full application model".