This is an introduction to installing and using Knative to deploy apps as cloud functions on a Kubernetes cluster. As of July 2019, Knative depends on Istio, so this guide includes details about working with both frameworks. Scripts and notes are found in linked GitLab repos.
The document covers a variety of topics through the following guides: 1. Install 2. Deploy App as Knative Service 3. Create Revisions and Route Traffic 4. Develop Pub-Sub Patterns with Knative Eventing - Direct Delivery (Cron Job Source) - Queued Events (Container Source)
- OpenStack account with configured SSH key
- OpenStack CLIs: the general OpenStack CLI and Magnum CLI
- Kubectl >=v1.10
As stated in the Knative docs:
Knative requires a Kubernetes cluster v1.11 or newer with the MutatingAdmissionWebhook admission controller enabled. kubectl v1.10 is also required.
If you create a cluster with OpenStack Magnum (i.e. using the
openstack coe command),
MutatingAdmissionWebhook is enabled by default. If you are curious, you can verify this by SSH-ing in to the master node and inspecting the
All instructions and scripts are available in this repo.
Deploy App as Knative Service
Once you have installed Knative and Istio on your Kubernetes cluster, you can easily deploy a sample app. Again, see this repo for instructions.
Create Revisions and Route Traffic
Knative automatically creates a new revision each time that changes are made to an existing service. A revision is an immutable snapshot of your code and configuration at a certain point in time. Revisions are essential for rolling back to previous releases and distributing traffic across multiple revisions.
Scripts and config files are found in this repo.
Develop Pub-Sub Patterns with Knative Eventing
Knative supports event emission and consumption. A consumer is a regular Knative
Service. The producer either exists within the cluster or it has a proxy within the cluster that communicate with the original producer outside the cluster to forward messages to consumers.