Add guide section

2026-01-18 14:58:43 +00:00 · 2019-11-07 14:01:46 +01:00 · 2019-11-07 14:01:46 +01:00 · 2d341e33f1
commit 2d341e33f1
parent c2cdb8dade
12 changed files with 1187 additions and 0 deletions
--- a/docs/providers/knative/guide/credentials.md
+++ b/docs/providers/knative/guide/credentials.md
@ -0,0 +1,37 @@
+<!--
+title: Knative - Knative Guide - Credentials | Serverless Framework
+menuText: Credentials
+menuOrder: 4
+description: How to set up the Serverless Framework with your Kubernetes / Knative credentials
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/credentials/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Credentials
+
+The Serverless Framework needs access to account credentials for your Kubernetes cluster so that it can create and manage Knative resources on your behalf. Additionally the Serverless Framework also needs access to your Docker Hub account to manage the container images which are used for Knative Serving services.
+
+## Kubeconfig files
+
+The Serverless Framework automatically detects and uses a kubeconfig file to communicate with your Kubernetes cluster. The kubeconfig file should be stored at `$HOME/.kube` on your local machine.
+
+For instructions on how to setup kubeconfig files see [the official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/).
+
+## Docker Hub
+
+The Serverless Framework will leverage a Docker Daemon to build and push container images to Docker Hub if you're not using URLs to existing container images as your function handlers.
+
+Make sure that you have Docker running locally on your machine and you're setting the `provider.docker` variables in your `serverless.yml` file:
+
+```yaml
+provider:
+  name: knative
+  docker:
+    username: ${env:DOCKER_HUB_USERNAME}
+    password: ${env:DOCKER_HUB_PASSWORD}
+```
--- a/docs/providers/knative/guide/deploying.md
+++ b/docs/providers/knative/guide/deploying.md
@ -0,0 +1,53 @@
+<!--
+title: Knative - Knative Guide - Deploying | Serverless Framework
+menuText: Deploying
+menuOrder: 8
+description: How to deploy your Knative Serving services
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/deploying/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Deploying
+
+The Serverless Framework was designed to provision your Knative functions and events safely and quickly. It does this via a couple of methods designed for different types of deployments.
+
+Upon deployment the Serverless Framework creates an own namespace on your Kubernetes cluster which follows this naming convention: `sls-{service}-{stage}`
+
+Creating and managing different namespaces makes it possible to deploy multiple services with multiple stages Side-by-Side.
+
+## Deploy All
+
+This is the main method for doing deployments with the Serverless Framework:
+
+```bash
+serverless deploy
+```
+
+Use this method when you have updated your function or event configuration in `serverless.yml` and you want to deploy that change (or multiple changes at the same time) to your Kubernetes cluster.
+
+**Note:** You can always enforce a deployment using the `--force` option, or specify a different configuration file name with the the `--config` option.
+
+### Tips
+
+- Use this in your CI/CD systems, as it is the safest method of deployment.
+- This method defaults to the `dev` stage. You can change the default stage in your `serverless.yml` file by setting the `stage` properties inside a `provider` object as the following example shows:
+
+  ```yaml
+  service: service-name
+  provider:
+    name: knative
+    stage: prod
+  ```
+
+- You can also deploy to different stages by passing in flags to the command:
+
+  ```
+  serverless deploy --stage prod
+  ```
+
+Check out the [deploy command docs](../cli-reference/deploy.md) for all details and options.
--- a/docs/providers/knative/guide/events.md
+++ b/docs/providers/knative/guide/events.md
@ -0,0 +1,63 @@
+<!--
+title: Knative - Knative Guide - Events | Serverless Framework
+menuText: Events
+menuOrder: 7
+description: Configuring Knative Eventing events sources in the Serverless Framework
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/events/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Events
+
+Simply put, events are the things that trigger your functions to run.
+
+If you are using Knative as your provider, all `events` in the service are anything [Knative Eventing](https://knative.dev/docs/eventing) supports as an [event source](https://knative.dev/docs/eventing/sources/). Such event sources can be e.g. AWS SQS, Kafka, CronJob or Custom events.
+
+[View the events section for a list of supported events](../events)
+
+## Configuration
+
+Events belong to each Function and can be found in the `events` property in `serverless.yml`.
+
+```yaml
+functions:
+  createUser:
+    handler: create-user.dockerfile
+    events:
+      - cron:
+          schedule: '* * * * *'
+          data: '{ "message": "Hello world from a Cron event source!" }'
+```
+
+Events are objects, which can contain event-specific information.
+
+The `events` property is an array, because it's possible for functions to be triggered by multiple events, as shown.
+
+You can set multiple events per Function, as long as you're using the event type once and it's supported by [Knative Eventing](https://knative.dev/docs/eventing).
+
+```yaml
+functions:
+  createUser:
+    handler: create-user.dockerfile
+    events:
+      - cron:
+          schedule: '* * * * *'
+          data: '{ "message": "Hello world from a Cron event source!" }'
+      - custom:
+          filter:
+            attributes:
+              type: greeting
+```
+
+## Types
+
+The Serverless Framework supports several [Knative Evening](https://knative.dev/docs/eventing) event sources. Instead of listing them here, we've put them in a separate section, since they have a lot of configurations and functionality. [Check out the events section for more information.](../events)
+
+## Deploying
+
+To deploy or update your functions and events, run `serverless deploy`.
--- a/docs/providers/knative/guide/functions.md
+++ b/docs/providers/knative/guide/functions.md
@ -0,0 +1,64 @@
+<!--
+title: Knative - Knative Guide - Functions | Serverless Framework
+menuText: Functions
+menuOrder: 6
+description: How to configure Knative Serving services in the Serverless Framework
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/functions/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Functions
+
+If you are using Knative as a provider, all _functions_ inside the service are [Knative Serving](https://knative.dev/docs/serving) services.
+
+## Configuration
+
+All of the functions in your serverless service can be found in `serverless.yml` under the `functions` property.
+
+```yaml
+service: my-service
+
+provider:
+  name: knative
+
+# you can overwrite defaults here
+#  stage: dev
+
+plugins:
+  - serverless-knative
+
+functions:
+  functionOne:
+    handler: function-one.dockerfile
+    context: ./code
+  functionTwo:
+    handler: gcr.io/knative-releases/github.com/knative/eventing-contrib/cmd/event_display:latest
+```
+
+The `handler` property points either to the Dockerfile which describes the container image which should be used as a [Knative Serving](https://knative.dev/docs/serving) service or to a container image on a remote Container Registry.
+
+You might also want to specify the build context if you're using a Dockerfile as your `handler` configuration. You can do this with the `context` configuration. The build context will default to the current working directory if you're not specifying a `context` configuration.
+
+You can specify an array of functions, which is useful if you separate your functions in to different files:
+
+```yaml
+# serverless.yml
+functions:
+  - ${file(./foo-functions.yml)}
+  - ${file(./bar-functions.yml)}
+```
+
+```yaml
+# foo-functions.yml
+fooOne:
+  handler: fooOne.dockerfile
+fooTwo:
+  handler: fooTwo.dockerfile
+```
+
+Check out the [Serverless Variables](./variables.md) for all the details and options on how to make your configuration more dynamic.
--- a/docs/providers/knative/guide/installation.md
+++ b/docs/providers/knative/guide/installation.md
@ -0,0 +1,57 @@
+<!--
+title: Knative - Knative Guide - Installation | Serverless Framework
+menuText: Installation
+menuOrder: 2
+description: How to install the Serverless Framework and start using the Knative provider integration
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/installation/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Installation
+
+### Installing Node.js
+
+Serverless is a [Node.js](https://nodejs.org) CLI tool so the first thing you need to do is to install Node.js on your machine.
+
+Go to the official [Node.js website](https://nodejs.org), download and follow the [installation instructions](https://nodejs.org/en/download/) to install Node.js on your local machine.
+
+**Note:** You need Node v8 or higher in order to use the Knative provider integration.
+
+You can verify that Node.js is installed successfully by running `node --version` in your terminal. You should see the corresponding Node version number printed out.
+
+### Installing the Serverless Framework
+
+Next, install the Serverless Framework via [npm](https://npmjs.org) which was already installed when you installed Node.js.
+
+Open up a terminal and type `npm install -g serverless` to install Serverless.
+
+```bash
+npm install -g serverless
+```
+
+Once the installation process is done you can verify that Serverless is installed successfully by running the following command in your terminal:
+
+```bash
+serverless
+```
+
+To see which version of serverless you have installed run:
+
+```bash
+serverless --version
+```
+
+### Setting up Knative on your Kubernetes Cluster
+
+Please follow the [official Knative documentation](https://knative.dev/docs/install) to setup Knative on your Kubernetes cluster. In addition to that make sure that you setup the corresponding [Knative Eventing](https://knative.dev/docs/eventing) components for the event sources you're using (e.g. the Google Cloud PubSub component when using the `gcpPubSub` event source).
+
+### Setting up access to Knative
+
+To run serverless commands that interface with your Knative installation, you will need to setup access to such installation on your machine.
+
+[Follow these instructions on setting up access to your Knative installation](./credentials.md)
--- a/docs/providers/knative/guide/intro.md
+++ b/docs/providers/knative/guide/intro.md
@ -0,0 +1,92 @@
+<!--
+title: Knative - Knative Guide - Introduction | Serverless Framework
+menuText: Intro
+menuOrder: 1
+description: An introduction to using Knative with the Serverless Framework
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/intro/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Introduction
+
+The Serverless Framework helps you develop and deploy your [Knative Serving](https://knative.dev/docs/serving) services, along with the [Knative Eventing](https://knative.dev/docs/eventing) configurations as event sources. It's a CLI that offers structure, automation and best practices out-of-the-box, allowing you to focus on building sophisticated, event-driven, serverless architectures, comprised of [functions](#functions) and [fvents](#events).
+
+The Serverless Framework is different from other application frameworks because:
+
+- It manages your code as well as your infrastructure
+- It supports multiple languages (Node.js, Python, PHP, and more)
+
+## Core Concepts
+
+Here are the Framework's main concepts and how they pertain to Knative primitives.
+
+### Functions
+
+A Function is a [Knative Serving](https://knative.dev/docs/serving) service. It's an independent unit of deployment, like a microservice. It's merely code, deployed in the cloud, that is most often written to perform a single job such as:
+
+- _Saving a user to the database_
+- _Processing a file in a database_
+- _Performing a scheduled task_
+
+You can perform multiple jobs in your code, but we don't recommend doing that without good reason. Separation of concerns is best and the Framework is designed to help you easily develop and deploy functions, as well as manage lots of them.
+
+### Events
+
+Anything that triggers a [Knative Serving](https://knative.dev/docs/serving) service to execute is regarded by the Framework as an **Event**. Events are [Knative Eventing](https://knative.dev/docs/eventing) sources such as:
+
+- _A Kafka event_
+- _AWS SQS queue element_
+- _A scheduled task (e.g., run every 5 minutes)_
+- _And more..._
+
+When you define an event for your functions in the Serverless Framework, the Framework will automatically create any infrastructure necessary for that event (e.g., a [Knative Trigger](https://knative.dev/docs/eventing/broker-trigger)) and configure your [Knative Serving](https://knative.dev/docs/serving) functions to listen to it.
+
+### Resources
+
+**Resources** are Knative infrastructure components which your Functions use such as:
+
+- _A Kafka event source_
+- _AWS SQS event source_
+- _A scheduled task (e.g., run every 5 minutes)_
+- _And more..._
+
+### Services
+
+A **Service** is the Framework's unit of organization. You can think of it as a project file, though you can have multiple services for a single application. It's where you define your Functions, the Events that trigger them, and the Resources your Functions use, all in one file entitled `serverless.yml` (or `serverless.json` or `serverless.js`). It looks like this:
+
+```yaml
+service: users
+
+functions: # Your "Functions"
+  functionOne:
+    events: # The "Events" that trigger this function
+      - kafka:
+          consumerGroup: KAFKA_CONSUMER_GROUP_NAME
+          bootstrapServers:
+            - server1
+            - server2
+          topics:
+            - my-topic
+  functionTwo:
+    events:
+      - cron:
+          schedule: '* * * * *'
+          data: '{"message": "Hello world from a Cron event source!"}'
+```
+
+When you deploy with the Framework by running `serverless deploy`, everything in `serverless.yml` is deployed at once.
+
+### Plugins
+
+You can overwrite or extend the functionality of the Framework using **Plugins**. Every `serverless.yml` can contain a `plugins:` property, which features multiple plugins.
+
+```yaml
+plugins:
+  - serverless-knative
+  - serverless-secrets
+```
--- a/docs/providers/knative/guide/packaging.md
+++ b/docs/providers/knative/guide/packaging.md
@ -0,0 +1,25 @@
+<!--
+title: Knative - Knative Guide - Packaging | Serverless Framework
+menuText: Packaging
+menuOrder: 10
+description: How the Serverless Framework packages your Knative Serving service and other available options
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/packaging/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Packaging
+
+## Package CLI Command
+
+Using the Serverless CLI tool, you can package your project without deploying it to Knative. This is best used with CI / CD workflows to ensure consistent deployable artifacts.
+
+Running the following command will build and push the container image which is specified with a `Dockerfile` the corresponding function `handler` points to:
+
+```bash
+serverless package
+```
--- a/docs/providers/knative/guide/plugins.md
+++ b/docs/providers/knative/guide/plugins.md
@ -0,0 +1,420 @@
+<!--
+title: Knative - Knative Guide - Plugins | Serverless Framework
+menuText: Plugins
+menuOrder: 11
+description: How to install and create Plugins to extend or overwrite the functionality of the Serverless Framework
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/plugins/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Plugins
+
+A Plugin is custom Javascript code that creates new or extends existing commands within the Serverless Framework. The Serverless Framework is merely a group of Plugins that are provided in the core. If you or your organization have a specific workflow, install a pre-written Plugin or write a plugin to customize the Framework to your needs. External Plugins are written exactly the same way as the core Plugins.
+
+- [How to create serverless plugins - Part 1](https://serverless.com/blog/writing-serverless-plugins/)
+- [How to create serverless plugins - Part 2](https://serverless.com/blog/writing-serverless-plugins-2/)
+
+## Installing Plugins
+
+External Plugins are added on a per service basis and are not applied globally. Make sure you are in your Service's root directory, then install the corresponding Plugin with the help of NPM:
+
+```
+npm install --save custom-serverless-plugin
+```
+
+We need to tell Serverless that we want to use the plugin inside our service. We do this by adding the name of the Plugin to the `plugins` section in the `serverless.yml` file.
+
+```yaml
+# serverless.yml file
+
+plugins:
+  - custom-serverless-plugin
+```
+
+The `plugins` section supports two formats:
+
+Array object:
+
+```yaml
+plugins:
+  - plugin1
+  - plugin2
+```
+
+Enhanced plugins object:
+
+```yaml
+plugins:
+  localPath: './custom_serverless_plugins'
+  modules:
+    - plugin1
+    - plugin2
+```
+
+Plugins might want to add extra information which should be accessible to Serverless. The `custom` section in the `serverless.yml` file is the place where you can add necessary configurations for your plugins (the plugins author / documentation will tell you if you need to add anything there):
+
+```yaml
+plugins:
+  - custom-serverless-plugin
+
+custom:
+  customkey: customvalue
+```
+
+## Service local plugin
+
+If you are working on a plugin or have a plugin that is just designed for one project, it can be loaded from the local `.serverless_plugins` folder at the root of your service. Local plugins can be added in the `plugins` array in `serverless.yml`.
+
+```yaml
+plugins:
+  - custom-serverless-plugin
+```
+
+Local plugins folder can be changed by enhancing `plugins` object:
+
+```yaml
+plugins:
+  localPath: './custom_serverless_plugins'
+  modules:
+    - custom-serverless-plugin
+```
+
+The `custom-serverless-plugin` will be loaded from the `custom_serverless_plugins` directory at the root of your service. If the `localPath` is not provided or empty, the `.serverless_plugins` directory will be used.
+
+The plugin will be loaded based on being named `custom-serverless-plugin.js` or `custom-serverless-plugin\index.js` in the root of `localPath` folder (`.serverless_plugins` by default).
+
+If you want to load a plugin from a specific directory without affecting other plugins, you can also specify a path relative to the root of your service:
+
+```yaml
+plugins:
+  # This plugin will be loaded from the `.serverless_plugins/` or `node_modules/` directories
+  - custom-serverless-plugin
+  # This plugin will be loaded from the `sub/directory/` directory
+  - ./sub/directory/another-custom-plugin
+```
+
+### Load Order
+
+Keep in mind that the order you define your plugins matters. When Serverless loads all the core plugins and then the custom plugins in the order you've defined them.
+
+```yaml
+# serverless.yml
+
+plugins:
+  - plugin1
+  - plugin2
+```
+
+In this case `plugin1` is loaded before `plugin2`.
+
+## Writing Plugins
+
+### Concepts
+
+#### Plugin
+
+Code which defines _Commands_, any _Events_ within a _Command_, and any _Hooks_ assigned to a _Lifecycle Event_.
+
+- Command // CLI configuration, commands, subcommands, options
+  - LifecycleEvent(s) // Events that happen sequentially when the command is run
+    - Hook(s) // Code that runs when a Lifecycle Event happens during a Command
+
+#### Command
+
+A CLI _Command_ that can be called by a user, e.g. `serverless deploy`. A Command has no logic, but simply defines the CLI configuration (e.g. command, subcommands, parameters) and the _Lifecycle Events_ for the command. Every command defines its own lifecycle events.
+
+```javascript
+'use strict';
+
+class MyPlugin {
+  constructor() {
+    this.commands = {
+      deploy: {
+        lifecycleEvents: ['resources', 'functions'],
+      },
+    };
+  }
+}
+
+module.exports = MyPlugin;
+```
+
+#### Lifecycle Events
+
+Events that fire sequentially during a Command. The above example lists two Events. However, for each Event, an additional `before` and `after` event is created. Therefore, six Events exist in the above example:
+
+- `before:deploy:resources`
+- `deploy:resources`
+- `after:deploy:resources`
+- `before:deploy:functions`
+- `deploy:functions`
+- `after:deploy:functions`
+
+The name of the command in front of lifecycle events when they are used for Hooks.
+
+#### Hooks
+
+A Hook binds code to any lifecycle event from any command.
+
+```javascript
+'use strict';
+
+class Deploy {
+  constructor() {
+    this.commands = {
+      deploy: {
+        lifecycleEvents: ['resources', 'functions'],
+      },
+    };
+
+    this.hooks = {
+      'before:deploy:resources': this.beforeDeployResources,
+      'deploy:resources': this.deployResources,
+      'after:deploy:functions': this.afterDeployFunctions,
+    };
+  }
+
+  beforeDeployResources() {
+    console.log('Before Deploy Resources');
+  }
+
+  deployResources() {
+    console.log('Deploy Resources');
+  }
+
+  afterDeployFunctions() {
+    console.log('After Deploy Functions');
+  }
+}
+
+module.exports = Deploy;
+```
+
+### Custom Variable Types
+
+As of version 1.52.0 of the Serverless framework, plugins can officially implement their own
+variable types for use in serverless config files.
+
+Example:
+
+```javascript
+'use strict';
+
+class EchoTestVarPlugin {
+  constructor() {
+    getEchoTestValue(src) {
+      return src.slice(5);
+    }
+    getDependentEchoTestValue(src) {
+      return src.slice(5);
+    }
+    this.variableResolvers = {
+      echo: this.getEchoTestValue,
+      // if a variable type depends on profile/stage/credentials, to avoid infinite loops in
+      // trying to resolve variables that depend on themselves, specify as such by setting a
+      // dependendServiceName property on the variable getter
+      echoStageDependent: {
+        resolver: this.getDependentEchoTestValue,
+        serviceName: 'echo that isnt prepopulated',
+        isDisabledAtPrepopulation: true
+    };
+  }
+}
+```
+
+The above plugin will add support for variables like `${echo:foobar}` and resolve to the key. EG:
+`${echo:foobar}` will resolve to `'foobar'`.
+
+#### `this.variableResolvers` structure
+
+The data structure of `this.variableResolvers` is an `Object` with keys that are either a
+`function` or `Object`.
+
+The keys are used to generate the regex which matches the variable type. Eg, a key of `test` will
+match variables like `${test:foobar}`.
+
+If the value is a `function` it is used to resolve variables matched. It must be `async` or return
+a `Promise` and accepts the variable string(with prefix but not the wrapping variable syntax,
+eg `test:foobar`) as it's only argument.
+
+If the value is an `Object`, it can have the following keys:
+
+- `resolver` - required, a function, same requirements as described above.
+- `isDisabledAtPrepopulation` - optional, a boolean, disable this variable type when populating
+  stage and credentials. This is important for variable types that depend on Knative or other
+  service that depend on those variables
+- `serviceName` - required if `isDisabledAtPrepopulation === true`, a string to display to users
+  if they try to use the variable type in one of the fields disabled for populating
+  stage / credentials.
+
+### Nesting Commands
+
+You can also nest commands, e.g. if you want to provide a command `serverless deploy function`. Those nested commands have their own lifecycle events and do not inherit them from their parents.
+
+```javascript
+'use strict';
+
+class MyPlugin {
+  constructor() {
+    this.commands = {
+      deploy: {
+        lifecycleEvents: ['resources', 'functions'],
+        commands: {
+          function: {
+            lifecycleEvents: ['package', 'deploy'],
+          },
+        },
+      },
+    };
+  }
+}
+
+module.exports = MyPlugin;
+```
+
+### Defining Options
+
+Each (sub)command can have multiple Options.
+
+Options are passed in with a double dash (`--`) like this: `serverless function deploy --function functionName`.
+
+Option Shortcuts are passed in with a single dash (`-`) like this: `serverless function deploy -f functionName`.
+
+The `options` object will be passed in as the second parameter to the constructor of your plugin.
+
+In it, you can optionally add a `shortcut` property, as well as a `required` property. The Framework will return an error if a `required` Option is not included. You can also set a `default` property if your option is not required.
+
+**Note:** At this time, the Serverless Framework does not use parameters.
+
+```javascript
+'use strict';
+
+class Deploy {
+  constructor(serverless, options) {
+    this.serverless = serverless;
+    this.options = options;
+
+    this.commands = {
+      deploy: {
+        lifecycleEvents: ['functions'],
+        options: {
+          function: {
+            usage: 'Specify the function you want to deploy (e.g. "--function myFunction")',
+            shortcut: 'f',
+            required: true,
+          },
+          stage: {
+            usage: 'Specify the stage you want to deploy to. (e.g. "--stage prod")',
+            shortcut: 's',
+            default: 'dev',
+          },
+        },
+      },
+    };
+
+    this.hooks = {
+      'deploy:functions': this.deployFunction.bind(this),
+    };
+  }
+
+  deployFunction() {
+    console.log('Deploying function: ', this.options.function);
+  }
+}
+
+module.exports = Deploy;
+```
+
+### Provider Specific Plugins
+
+Plugins can be provider specific which means that they are bound to a provider.
+
+**Note:** Binding a plugin to a provider is optional. Serverless will always consider your plugin if you don't specify a `provider`.
+
+The provider definition should be added inside the plugins constructor:
+
+```javascript
+'use strict';
+
+class ProviderDeploy {
+  constructor(serverless, options) {
+    this.serverless = serverless;
+    this.options = options;
+
+    // set the providers name here
+    this.provider = this.serverless.getProvider('providerName');
+
+    this.commands = {
+      deploy: {
+        lifecycleEvents: ['functions'],
+        options: {
+          function: {
+            usage: 'Specify the function you want to deploy (e.g. "--function myFunction")',
+            required: true,
+          },
+        },
+      },
+    };
+
+    this.hooks = {
+      'deploy:functions': this.deployFunction.bind(this),
+    };
+  }
+
+  deployFunction() {
+    console.log('Deploying function: ', this.options.function);
+  }
+}
+
+module.exports = ProviderDeploy;
+```
+
+The Plugin's functionality will now only be executed when the Serverless Service's provider matches the provider name which is defined inside the plugins constructor.
+
+### Serverless Instance
+
+The `serverless` instance which enables access to global service config during runtime is passed in as the first parameter to the plugin constructor.
+
+```javascript
+'use strict';
+
+class MyPlugin {
+  constructor(serverless, options) {
+    this.serverless = serverless;
+    this.options = options;
+
+    this.commands = {
+      log: {
+        lifecycleEvents: ['serverless'],
+      },
+    };
+
+    this.hooks = {
+      'log:serverless': this.logServerless.bind(this),
+    };
+  }
+
+  logServerless() {
+    console.log('Serverless instance: ', this.serverless);
+  }
+}
+
+module.exports = MyPlugin;
+```
+
+**Note:** [Variable references](./variables.md#reference-properties-in-serverlessyml) in the `serverless` instance are not resolved before a Plugin's constructor is called, so if you need these, make sure to wait to access those from your [hooks](#hooks).
+
+### Command Naming
+
+Command names need to be unique. If we load two commands and both want to specify the same command (e.g. we have an integrated command `deploy` and an external command also wants to use `deploy`) the Serverless CLI will print an error and exit. If you want to have your own `deploy` command you need to name it something different like `myCompanyDeploy` so they don't clash with existing plugins.
+
+### Extending the `info` command
+
+The `info` command which is used to display information about the deployment has detailed `lifecycleEvents` you can hook into to add and display custom information.
+
+**Note:** Every provider implements its own `info` plugin so you might want to take a look into the `lifecycleEvents` the provider `info` plugin exposes.
--- a/docs/providers/knative/guide/quick-start.md
+++ b/docs/providers/knative/guide/quick-start.md
@ -0,0 +1,110 @@
+<!--
+title: Knative - Knative Guide - Quick Start | Serverless Framework
+menuText: Quick Start
+menuOrder: 3
+description: Get started with the Serverless Framework Knative provider integration in 5 minutes or less
+layout: Doc
+-->
+
+# Quick Start
+
+Complete the steps in this guide to install the Serverless Framework open-source CLI and deploy, invoke and remove a sample service on your Knative installation.
+
+## Initial Setup
+
+There are a few prerequisites you need to install and configure:
+
+- [Install Node.js 8.x or later on your local machine](#install-nodejs-and-npm)
+- [Install the Serverless Framework open-source CLI version 1.50.0 or later](#install-the-serverless-framework-open-source-cli)
+
+If you already have these prerequisites setup you can skip ahead to deploy an example Service.
+
+### Install Node.js and NPM
+
+- Follow these [installation instructions](https://nodejs.org/en/download/).
+- At the end, you should be able to run `node -v` from your command line and get a result like this...
+
+```sh
+$ node -v
+vx.x.x
+```
+
+- You should also be able to run `npm -v` from your command line and should see...
+
+```sh
+$ npm -v
+x.x.x
+```
+
+### Install the Serverless Framework open-source CLI
+
+- Run this command in your terminal
+
+```sh
+npm install -g serverless
+```
+
+- After install is complete, you should be able to run `serverless -v` from your command line and get a result like this...
+
+```sh
+$ serverless -v
+x.x.x
+```
+
+## Create and deploy a serverless Service
+
+Now that you’ve completed your setup, let’s create and deploy a serverless Service.
+
+### Create a new Service from a Template
+
+1. Use the Serverless Framework open-source CLI to create a new Service with `knative-docker`template.
+
+````sh
+# Create a new Serverless service/project
+$ serverless create --template knative-docker --path my-service
+
+2. Install the dependencies
+
+```sh
+# Change into the newly created directory
+$ cd my-service
+$ npm install
+````
+
+### Set up Knative
+
+[Install Knative](./installation.md) on your Kubernetes cluster.
+
+### Set up the credentials
+
+[Configure your Knative access](./credentials.md) to work with the Serverless Framework.
+
+### Deploy the Service
+
+Use this command to deploy your service for the first time and after you make changes to your functions or events in `serverless.yml` and want to deploy all changes within your service at the same time.
+
+```bash
+serverless deploy
+```
+
+More information in [deploy command](../cli-reference/deploy.md)
+
+### Invoke your service's function
+
+Invokes a Function and returns logs.
+
+```bash
+serverless invoke -f hello
+```
+
+More information in [invoke command](../cli-reference/invoke.md)
+
+## Cleanup
+
+### Remove your Service
+
+If at any point you no longer need your service, you can run the following command to remove the functions and events that were created. This will delete the resources you created.
+
+```sh
+serverless remove
+```
--- a/docs/providers/knative/guide/services.md
+++ b/docs/providers/knative/guide/services.md
@ -0,0 +1,159 @@
+<!--
+title: Knative - Knative - Services | Serverless Framework
+menuText: Services
+menuOrder: 5
+description: How to manage and configure Serverless services, which contain your Knative Serving services and their events
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/services/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative - Services
+
+A `service` is like a project. It's where you define your [Knative Serving](https://knative.dev/docs/serving) services and the `events` that trigger them, all in a file called `serverless.yml`.
+
+To get started building your first Serverless Framework project, create a `service`.
+
+## Organization
+
+In the beginning of an application, many people use a single service to define all of the functions and events for that project. This is what we recommend in the beginning.
+
+```bash
+myService/
+  serverless.yml  # Contains all functions and infrastructure resources
+```
+
+However, as your application grows, you can break it out into multiple services. A lot of people organize their services by workflows or data models, and group the functions related to those workflows and data models together in the service.
+
+```bash
+users/
+  serverless.yml # Contains 4 functions that do Users CRUD operations and the Users database
+posts/
+  serverless.yml # Contains 4 functions that do Posts CRUD operations and the Posts database
+comments/
+  serverless.yml # Contains 4 functions that do Comments CRUD operations and the Comments database
+```
+
+This makes sense since related functions usually use common infrastructure resources, and you want to keep those functions and resources together as a single unit of deployment, for better organization and separation of concerns.
+
+## Creation
+
+To create a service, use the `create` command. You can also pass in a path to create a directory and auto-name your service:
+
+```bash
+# Create service with Node.js template in the folder ./my-service
+serverless create --template knative-docker --path my-service
+```
+
+Here are the available runtimes for Knative:
+
+- knative-docker
+
+Check out the [create command docs](../cli-reference/create) for all the details and options.
+
+## Contents
+
+You'll see the following files in your working directory:
+
+- `serverless.yml`
+- `code/hello-world.dockerfile`
+- `code/app.py`
+
+### serverless.yml
+
+Each `service` configuration is managed in the `serverless.yml` file. The main responsibilities of this file are:
+
+- Declare a Serverless service
+- Define one or more functions in the service
+  - Define the provider the service will be deployed to
+  - Define any custom plugins to be used
+  - Define events that trigger each function to execute (e.g. custom events)
+  - Allow events listed in the `events` section to automatically create the resources required for the event upon deployment
+  - Allow flexible configuration using Serverless Variables
+
+You can see the name of the service, the provider configuration and the first function inside the `functions` definition. Any further service configuration will be done in this file.
+
+```yaml
+service: my-service # service name
+
+provider: # provider information
+  name: knative
+
+plugins:
+  - serverless-knative
+
+functions:
+  functionOne:
+    handler: function-one.dockerfile
+    events:
+      - cron:
+          schedule: '* * * * *'
+          data: '{"message": "Hello world from a Cron event source!"}'
+```
+
+### hello-world.dockerfile
+
+The `hello-world.dockerfile` contains the container image description which defines how the service is containerized.
+
+### app.py
+
+The `app.py` file contains an example Python service which exposes an HTTP server and is therefore deployable as a [Knative Serving](https://knative.dev/docs/serving) service.
+
+## Deployment
+
+When you deploy a service, all of the functions and events in your `serverless.yml` are translated into calls to the Kubernetes API to dynamically define those resources.
+
+To deploy a service, use the `deploy` command:
+
+```bash
+serverless deploy
+```
+
+Check out the [deployment guide](./deploying.md) to learn more about deployments and how they work. Or, check out the [deploy command docs](../cli-reference/deploy.md) for all the details and options.
+
+## Removal
+
+To easily remove your service from Knative, you can use the `remove` command.
+
+Run `serverless remove` to trigger the removal process.
+
+Serverless will start the removal and informs you about it's process on the console. A success message is printed once the whole service is removed.
+
+The removal process will only remove the service on your Knative installation and optionally the Docker image on your local machine. The service directory will still remain on your local machine so you can still modify and (re)deploy it to another stage later on.
+
+## Version Pinning
+
+The Serverless framework is usually installed globally via `npm install -g serverless`. This way you have the Serverless CLI available for all your services.
+
+Installing tools globally has the downside that the version can't be pinned inside `package.json`. This can lead to issues if you upgrade Serverless, but your colleagues or CI system don't. You can use a feature in your `serverless.yml` without worrying that your CI system will deploy with an old version of Serverless.
+
+### Pinning a Version
+
+To configure version pinning define a `frameworkVersion` property in your serverless.yaml. Whenever you run a Serverless command from the CLI it checks if your current Serverless version is matching the `frameworkVersion` range. The CLI uses [Semantic Versioning](http://semver.org/) so you can pin it to an exact version or provide a range. In general we recommend to pin to an exact version to ensure everybody in your team has the exact same setup and no unexpected problems happen.
+
+### Examples
+
+#### Exact Version
+
+```yaml
+frameworkVersion: '=1.0.3'
+```
+
+#### Version Range
+
+```yaml
+frameworkVersion: '>=1.0.0 <2.0.0'
+```
+
+## Installing Serverless in an existing service
+
+If you already have a Serverless service, and would prefer to lock down the framework version using `package.json`, then you can install Serverless as follows:
+
+```bash
+# from within a service
+npm install serverless --save-dev
+```
--- a/docs/providers/knative/guide/variables.md
+++ b/docs/providers/knative/guide/variables.md
@ -0,0 +1,28 @@
+<!--
+title: Knative - Knative Guide - Variables | Serverless Framework
+menuText: Variables
+menuOrder: 9
+description: How to use Serverless Variables to insert dynamic configuration info into your serverless.yml
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/variables/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative Variables
+
+Variables allow users to dynamically replace config values in `serverless.yml` config. They are especially useful when providing secrets for your service to use and when you are working with multiple stages.
+
+The Serverless Framework provides a powerful variable system which allows you to add dynamic data into your `serverless.yml`. With Serverless Variables, you'll be able to do the following:
+
+- Reference & load variables from environment variables via `${env:FOO}`
+- Reference & load variables from CLI options via `${opt:stage}`
+- Recursively reference properties of any type from the same `serverless.yml` file via `${self:provider.name}`
+- Recursively reference properties of any type from other YAML / JSON files via `${file(./some-file.json):exportedVar}`
+- Recursively nest variable references within each other for ultimate flexibility
+- Combine multiple variable references to overwrite each other
+
+**Note:** You can only use variables in `serverless.yml` property **values**, not property keys. So you can't use variables to generate dynamic logical IDs in the custom resources section for example.
--- a/docs/providers/knative/guide/workflow.md
+++ b/docs/providers/knative/guide/workflow.md
@ -0,0 +1,79 @@
+<!--
+title: Knative - knative Guide - Workflow | Serverless Framework
+menuText: Workflow
+menuOrder: 12
+description: A guide and cheatsheet containing CLI commands and workflow recommendations
+layout: Doc
+-->
+
+<!-- DOCS-SITE-LINK:START automatically generated  -->
+
+### [Read this on the main serverless docs site](https://www.serverless.com/framework/docs/providers/knative/guide/workflow/)
+
+<!-- DOCS-SITE-LINK:END -->
+
+# Knative Workflow Tips
+
+Quick recommendations and tips for various processes.
+
+### Development Workflow
+
+1. Write your functions
+1. Use `serverless deploy` when you've made changes to `serverless.yml` and in CI/CD systems.
+1. Use `serverless invoke -f myFunction` to test your functions on Knative.
+1. Write tests to run locally.
+
+### Using stages
+
+- At the very least, use a `dev` and `prod` stage.
+- In larger teams, each member should use a separate Knative installation and their own stage for development.
+
+### Larger Projects
+
+- Break your application / project into multiple Serverless services.
+- Model your Serverless services around data models or workflows.
+- Keep the functions in your Serverless services to a minimum.
+
+## Cheat Sheet
+
+A handy list of commands to use when developing with the Serverless Framework.
+
+##### Create a service:
+
+Creates a new service
+
+```
+serverless create -p [SERVICE NAME] -t knative-docker
+```
+
+##### Install a service
+
+This is a convenience method to install a pre-made Serverless service locally by downloading the GitHub repo and unzipping it.
+
+```
+serverless install -u [GITHUB URL OF SERVICE]
+```
+
+##### Deploy all
+
+Use this when you have made changes to your functions or events in `serverless.yml` or you simply want to deploy all changes within your service at the same time.
+
+```
+serverless deploy -s [STAGE NAME]
+```
+
+##### Invoke function
+
+Invokes a [Knative Serving](https://knative.dev/docs/serving) service returns it's output.
+
+```
+serverless invoke -f [FUNCTION NAME] -s [STAGE NAME] -l
+```
+
+##### Info
+
+See information about your deployed / undeployed functions by running the info command in your service directory.
+
+```
+serverless info
+```