mirror of https://github.com/knative/docs.git
Format markdown (#1123)
* Format markdown Produced via: `prettier --write --prose-wrap=always $(find -name '*.md' | grep -v vendor | grep -v .github)` * Revert bad diff
This commit is contained in:
mattmoor-sockpuppet
Knative Prow Robot
parent
1c2a4f5fd6
commit
cb504f078a
|
|
@ -68,14 +68,14 @@ API
|
|||
|
||||
[Build](https://github.com/knative/build), Builders, and Build templates
|
||||
|
||||
| Artifact | Link |
|
||||
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
|
||||
| Community Meeting VC | [meet.google.com/hau-nwak-tgm](https://meet.google.com/hau-nwak-tgm) <br>Or dial in:<br>(US) +1 219-778-6103 PIN: 573 000# |
|
||||
| Artifact | Link |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| Forum | [knative-dev@](https://groups.google.com/forum/#!forum/knative-dev) |
|
||||
| Community Meeting VC | [meet.google.com/hau-nwak-tgm](https://meet.google.com/hau-nwak-tgm) <br>Or dial in:<br>(US) +1 219-778-6103 PIN: 573 000# |
|
||||
| Community Meeting Calendar | Every other Wednesday 10:00a-10:30a PST <br>[Calendar](https://calendar.google.com/event?action=TEMPLATE&tmeid=MTBkb3MwYnVrbDd0djE0a2kzcmpmbjZndm9fMjAxODA5MTJUMTcwMDAwWiBqYXNvbmhhbGxAZ29vZ2xlLmNvbQ&tmsrc=jasonhall%40google.com&scp=ALL) |
|
||||
| Meeting Notes | [Notes](https://docs.google.com/document/d/1e7gMVFlJfkFdTcaWj2qETeRD9kSBG2Vh8mASPmQMYC0/edit) |
|
||||
| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1ov16HvPam-v_FXAGEaUdHok6_hUAoIoe) |
|
||||
| Slack Channel | [#build-crd](https://knative.slack.com/messages/build-crd) |
|
||||
| Meeting Notes | [Notes](https://docs.google.com/document/d/1e7gMVFlJfkFdTcaWj2qETeRD9kSBG2Vh8mASPmQMYC0/edit) |
|
||||
| Document Folder | [Folder](https://drive.google.com/corp/drive/folders/1ov16HvPam-v_FXAGEaUdHok6_hUAoIoe) |
|
||||
| Slack Channel | [#build-crd](https://knative.slack.com/messages/build-crd) |
|
||||
|
||||
| | Leads | Company | Profile |
|
||||
| -------------------------------------------------------- | ---------- | ------- | --------------------------------------- |
|
||||
|
|
|
|||
|
|
@ -209,14 +209,12 @@ credentials are then used to authenticate with the Docker registry.
|
|||
## Kubernetes's Docker registry's secret
|
||||
|
||||
Kubernetes defines two types of secrets for Docker registries :
|
||||
`kubernetes.io/dockercfg` and
|
||||
`kubernetes.io/dockerconfigjson`. Knative supports those secrets in
|
||||
addition to the one described above.
|
||||
`kubernetes.io/dockercfg` and `kubernetes.io/dockerconfigjson`. Knative supports
|
||||
those secrets in addition to the one described above.
|
||||
|
||||
1. Define a `Secret` from a Docker client configuration file, as documented in
|
||||
[Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/)
|
||||
|
||||
1. Define a `Secret` from a Docker client configuration file, as
|
||||
documented in [Pull an Image from a Private
|
||||
Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/)
|
||||
|
||||
```bash
|
||||
kubectl create secret generic regcred \
|
||||
--from-file=.dockerconfigjson=<path/to/.docker/config.json> \
|
||||
|
|
@ -225,42 +223,42 @@ addition to the one described above.
|
|||
|
||||
1. Direct a `ServiceAccount` to use this `Secret`:
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: build-bot
|
||||
secrets:
|
||||
- name: regcred
|
||||
```
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ServiceAccount
|
||||
metadata:
|
||||
name: build-bot
|
||||
secrets:
|
||||
- name: regcred
|
||||
```
|
||||
|
||||
1. Use that `ServiceAccount` in your `Build`:
|
||||
1. Use that `ServiceAccount` in your `Build`:
|
||||
|
||||
```yaml
|
||||
apiVersion: build.knative.dev/v1alpha1
|
||||
kind: Build
|
||||
metadata:
|
||||
name: build-with-basic-auth
|
||||
spec:
|
||||
serviceAccountName: build-bot
|
||||
steps:
|
||||
...
|
||||
```
|
||||
```yaml
|
||||
apiVersion: build.knative.dev/v1alpha1
|
||||
kind: Build
|
||||
metadata:
|
||||
name: build-with-basic-auth
|
||||
spec:
|
||||
serviceAccountName: build-bot
|
||||
steps:
|
||||
...
|
||||
```
|
||||
|
||||
1. Execute the build:
|
||||
1. Execute the build:
|
||||
|
||||
```shell
|
||||
kubectl apply --filename secret.yaml --filename serviceaccount.yaml --filename build.yaml
|
||||
```
|
||||
```shell
|
||||
kubectl apply --filename secret.yaml --filename serviceaccount.yaml --filename build.yaml
|
||||
```
|
||||
|
||||
When this build executes, before steps execute, a `~/.docker/config.json` will
|
||||
be generated containing the credentials configured in the `Secret`, and these
|
||||
credentials are then used to authenticate with the Docker registry.
|
||||
|
||||
If both `kubernetes.io/*` and knative flavored basic authentication
|
||||
secret are provided, knative will merge the credentials from those
|
||||
two ; knative flavored credentials taking precendence over
|
||||
`kubernetes.io/dockerconfigjson` (or `kubernetes.io/dockercfg`) ones.
|
||||
If both `kubernetes.io/*` and knative flavored basic authentication secret are
|
||||
provided, knative will merge the credentials from those two ; knative flavored
|
||||
credentials taking precendence over `kubernetes.io/dockerconfigjson` (or
|
||||
`kubernetes.io/dockercfg`) ones.
|
||||
|
||||
### Guiding credential selection
|
||||
|
||||
|
|
|
|||
|
|
@ -258,33 +258,49 @@ See the [Cronjob Source](samples/cronjob-source) example.
|
|||
|
||||
### KafkaSource
|
||||
|
||||
The KafkaSource reads events from an Apache Kafka Cluster, and passes these to a Knative Serving application so that they can be consumed.
|
||||
The KafkaSource reads events from an Apache Kafka Cluster, and passes these to a
|
||||
Knative Serving application so that they can be consumed.
|
||||
|
||||
**Spec fields**:
|
||||
|
||||
- `consumerGroup`: `string` Name of a Kafka consumer group.
|
||||
- `bootstrapServers`: `string` Comma separated list of `hostname:port` pairs for the Kafka Broker.
|
||||
- `bootstrapServers`: `string` Comma separated list of `hostname:port` pairs for
|
||||
the Kafka Broker.
|
||||
- `topics`: `string` Name of the Kafka topic to consume messages from.
|
||||
|
||||
See the [Kafka Source](https://github.com/knative/eventing-sources/tree/master/contrib/kafka/samples) example.
|
||||
See the
|
||||
[Kafka Source](https://github.com/knative/eventing-sources/tree/master/contrib/kafka/samples)
|
||||
example.
|
||||
|
||||
### CamelSource
|
||||
|
||||
A CamelSource is an event source that can represent any existing [Apache Camel component](https://github.com/apache/camel/tree/master/components) that provides a consumer side, and enables publishing events to an addressable endpoint. Each Camel endpoint has the form of a URI where the scheme is the ID of the component to use.
|
||||
A CamelSource is an event source that can represent any existing
|
||||
[Apache Camel component](https://github.com/apache/camel/tree/master/components)
|
||||
that provides a consumer side, and enables publishing events to an addressable
|
||||
endpoint. Each Camel endpoint has the form of a URI where the scheme is the ID
|
||||
of the component to use.
|
||||
|
||||
CamelSource requires [Camel-K](https://github.com/apache/camel-k#installation) to be installed into the current namespace.
|
||||
CamelSource requires [Camel-K](https://github.com/apache/camel-k#installation)
|
||||
to be installed into the current namespace.
|
||||
|
||||
**Spec fields**:
|
||||
|
||||
- source: information on the kind of Camel source that should be created.
|
||||
- component: the default kind of source, enables creating an EventSource by configuring a single Camel component.
|
||||
- uri: `string` contains the Camel URI that should be used to push events into the target sink.
|
||||
- properties: `key/value map` contains Camel global options or component specific configuration. Options are available in the documentation of each existing Apache Camel component.
|
||||
- serviceAccountName: `string` an optional service account that can be used to run the source pod.
|
||||
- image: `string` an optional base image to use for the source pod, mainly for development purposes.
|
||||
|
||||
See the [CamelSource](https://github.com/knative/eventing-sources/blob/master/contrib/camel/samples/README.md) example.
|
||||
- component: the default kind of source, enables creating an EventSource by
|
||||
configuring a single Camel component.
|
||||
- uri: `string` contains the Camel URI that should be used to push events
|
||||
into the target sink.
|
||||
- properties: `key/value map` contains Camel global options or component
|
||||
specific configuration. Options are available in the documentation of each
|
||||
existing Apache Camel component.
|
||||
- serviceAccountName: `string` an optional service account that can be used to
|
||||
run the source pod.
|
||||
- image: `string` an optional base image to use for the source pod, mainly for
|
||||
development purposes.
|
||||
|
||||
See the
|
||||
[CamelSource](https://github.com/knative/eventing-sources/blob/master/contrib/camel/samples/README.md)
|
||||
example.
|
||||
|
||||
## Getting Started
|
||||
|
||||
|
|
|
|||
|
|
@ -96,6 +96,7 @@ kail -l serving.knative.dev/service=message-dumper -c user-container --since=10m
|
|||
### Cleanup
|
||||
|
||||
You can remove the Cron Event Source via:
|
||||
|
||||
```shell
|
||||
kubectl delete --filename cronjob-source.yaml
|
||||
```
|
||||
|
|
|
|||
|
|
@ -204,6 +204,7 @@ see them in the subscriber.
|
|||
To cleanup the knative resources:
|
||||
|
||||
1. Remove the gcppubsub controller:
|
||||
|
||||
```shell
|
||||
pushd $HOME/go/src/github.com/knative/eventing-sources
|
||||
kubectl delete --filename config/default-gcppubsub.yaml
|
||||
|
|
@ -211,12 +212,14 @@ To cleanup the knative resources:
|
|||
```
|
||||
|
||||
2. Remove the channel:
|
||||
|
||||
```shell
|
||||
sed "s/CHANNEL_NAME/$CHANNEL_NAME/" channel.yaml |
|
||||
kubectl --namespace default delete --filename -
|
||||
```
|
||||
|
||||
3. Remove the gcppubsub source:
|
||||
|
||||
```shell
|
||||
sed -e "s/MY_GCP_PROJECT/$IOTCORE_PROJECT/" \
|
||||
-e "s/TOPIC_NAME/$IOTCORE_TOPIC_DATA/" \
|
||||
|
|
|
|||
|
|
@ -95,7 +95,9 @@ Ce-Source: /apis/v1/namespaces/default/pods/busybox
|
|||
|
||||
### Cleanup
|
||||
|
||||
You can remove the `Channel`, `Service Account`, `Event Sources`, and `Subscriber` via:
|
||||
You can remove the `Channel`, `Service Account`, `Event Sources`, and
|
||||
`Subscriber` via:
|
||||
|
||||
```shell
|
||||
kubectl --namespace default delete --filename channel.yaml
|
||||
kubectl --namespace default delete --filename serviceaccount.yaml
|
||||
|
|
|
|||
|
|
@ -10,63 +10,57 @@ procedure:
|
|||
```
|
||||
-->
|
||||
|
||||
Event Sources are Kubernetes Custom Resources which provide a mechanism for registering interest in
|
||||
a class of events from a particular software system. Since different event sources may be described
|
||||
by different Custom Resources, this page provides an index of the available source resource types as
|
||||
well as links to installation instructions.
|
||||
Event Sources are Kubernetes Custom Resources which provide a mechanism for
|
||||
registering interest in a class of events from a particular software system.
|
||||
Since different event sources may be described by different Custom Resources,
|
||||
this page provides an index of the available source resource types as well as
|
||||
links to installation instructions.
|
||||
|
||||
This is a non-exhaustive list of Event sources for Knative.
|
||||
|
||||
|
||||
### Inclusion in this list is not an endorsement, nor does it imply any level of support.
|
||||
|
||||
|
||||
## Sources
|
||||
|
||||
These are sources that are installed as `CRD`s.
|
||||
|
||||
Name | Status | Support | Description
|
||||
--- | --- | --- | ---
|
||||
[AWS SQS](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/aws_sqs_types.go) | Proof of Concept | None | Brings [AWS Simple Queue Service](https://aws.amazon.com/sqs/) messages into Knative.
|
||||
[Apache Camel](https://github.com/knative/eventing-sources/blob/master/contrib/camel/pkg/apis/sources/v1alpha1/camelsource_types.go) | Proof of Concept | None | Allows to use [Apache Camel](https://github.com/apache/camel) components for pushing events into Knative.
|
||||
[Apache Kafka](https://github.com/knative/eventing-sources/blob/master/contrib/kafka/pkg/apis/sources/v1alpha1/kafka_types.go) | Proof of Concept | None | Brings [Apache Kafka](https://kafka.apache.org/) messages into Knative.
|
||||
[Cron Job](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/cron_job_types.go) | Proof of Concept | None | Uses an in-memory timer to produce events on the specified Cron schedule.
|
||||
[GCP PubSub](https://github.com/knative/eventing-sources/blob/master/contrib/gcppubsub/pkg/apis/sources/v1alpha1/gcp_pubsub_types.go) | Proof of Concept | None | Brings [GCP PubSub](https://cloud.google.com/pubsub/) messages into Knative.
|
||||
[GitHub](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/githubsource_types.go) | Proof of Concept | None | Registers for events of the specified types on the specified GitHub organization/repository. Brings those events into Knative.
|
||||
[GitLab](https://gitlab.com/triggermesh/gitlabsource) | Proof of Concept | None | Registers for events of the specified types on the specified GitLab repository. Brings those events into Knative.
|
||||
[Google Cloud Scheduler](https://github.com/vaikas-google/csr) | Active Development | None | Create, update, and delete [Google Cloud Scheduler](https://cloud.google.com/scheduler/) Jobs. When those jobs are triggered, receive the event inside Knative.
|
||||
[Google Cloud Storage](https://github.com/vaikas-google/gcs) | Active Development | None | Registers for events of the specified types on the specified Google Cloud Storage bucket and optional object prefix. Brings those events into Knative.
|
||||
[Kubernetes](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/kuberneteseventsource_types.go) | Active Development | Knative | Brings Kubernetes cluster events into Knative. Uses ContainerSource for underlying infrastructure.
|
||||
|
||||
|
||||
| Name | Status | Support | Description |
|
||||
| ------------------------------------------------------------------------------------------------------------------------------------- | ------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [AWS SQS](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/aws_sqs_types.go) | Proof of Concept | None | Brings [AWS Simple Queue Service](https://aws.amazon.com/sqs/) messages into Knative. |
|
||||
| [Apache Camel](https://github.com/knative/eventing-sources/blob/master/contrib/camel/pkg/apis/sources/v1alpha1/camelsource_types.go) | Proof of Concept | None | Allows to use [Apache Camel](https://github.com/apache/camel) components for pushing events into Knative. |
|
||||
| [Apache Kafka](https://github.com/knative/eventing-sources/blob/master/contrib/kafka/pkg/apis/sources/v1alpha1/kafka_types.go) | Proof of Concept | None | Brings [Apache Kafka](https://kafka.apache.org/) messages into Knative. |
|
||||
| [Cron Job](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/cron_job_types.go) | Proof of Concept | None | Uses an in-memory timer to produce events on the specified Cron schedule. |
|
||||
| [GCP PubSub](https://github.com/knative/eventing-sources/blob/master/contrib/gcppubsub/pkg/apis/sources/v1alpha1/gcp_pubsub_types.go) | Proof of Concept | None | Brings [GCP PubSub](https://cloud.google.com/pubsub/) messages into Knative. |
|
||||
| [GitHub](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/githubsource_types.go) | Proof of Concept | None | Registers for events of the specified types on the specified GitHub organization/repository. Brings those events into Knative. |
|
||||
| [GitLab](https://gitlab.com/triggermesh/gitlabsource) | Proof of Concept | None | Registers for events of the specified types on the specified GitLab repository. Brings those events into Knative. |
|
||||
| [Google Cloud Scheduler](https://github.com/vaikas-google/csr) | Active Development | None | Create, update, and delete [Google Cloud Scheduler](https://cloud.google.com/scheduler/) Jobs. When those jobs are triggered, receive the event inside Knative. |
|
||||
| [Google Cloud Storage](https://github.com/vaikas-google/gcs) | Active Development | None | Registers for events of the specified types on the specified Google Cloud Storage bucket and optional object prefix. Brings those events into Knative. |
|
||||
| [Kubernetes](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/kuberneteseventsource_types.go) | Active Development | Knative | Brings Kubernetes cluster events into Knative. Uses ContainerSource for underlying infrastructure. |
|
||||
|
||||
## Meta Sources
|
||||
|
||||
These are not directly usable, but make writing a Source much easier.
|
||||
|
||||
Name | Status | Support | Description
|
||||
--- | --- | --- | ---
|
||||
[Auto Container Source](https://github.com/Harwayne/auto-container-source) | Proof of Concept | None | AutoContainerSource is a controller that allows the Source CRDs _without_ needing a controller. It notices CRDs with a specific label and starts controlling resources of that type. It utilizes Container Source as underlying infrastructure.
|
||||
[Container Source](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/containersource_types.go) | Active Development | Knative | Container Source is a generic controller. Given an Image URL, it will keep a single `Pod` running with the specified image, environment, and arguments. It is used by multiple other Sources as underlying infrastructure.
|
||||
[Sample Source](https://github.com/grantr/sample-source) | Proof of Concept | None | SampleSource is a reference implementation supporting the [Writing an Event Source the Hard Way tutorial](../samples/writing-a-source).
|
||||
|
||||
|
||||
| Name | Status | Support | Description |
|
||||
| ------------------------------------------------------------------------------------------------------------------------------ | ------------------ | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [Auto Container Source](https://github.com/Harwayne/auto-container-source) | Proof of Concept | None | AutoContainerSource is a controller that allows the Source CRDs _without_ needing a controller. It notices CRDs with a specific label and starts controlling resources of that type. It utilizes Container Source as underlying infrastructure. |
|
||||
| [Container Source](https://github.com/knative/eventing-sources/blob/master/pkg/apis/sources/v1alpha1/containersource_types.go) | Active Development | Knative | Container Source is a generic controller. Given an Image URL, it will keep a single `Pod` running with the specified image, environment, and arguments. It is used by multiple other Sources as underlying infrastructure. |
|
||||
| [Sample Source](https://github.com/grantr/sample-source) | Proof of Concept | None | SampleSource is a reference implementation supporting the [Writing an Event Source the Hard Way tutorial](../samples/writing-a-source). |
|
||||
|
||||
### ContainerSource Containers
|
||||
|
||||
These are containers intended to be used with `ContainerSource`.
|
||||
|
||||
Name | Status | Support | Description
|
||||
--- | --- | --- | ---
|
||||
[AWS CodeCommit](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscodecommit) | Active Development | TriggerMesh | Registers for events of the specified types on the specified AWS CodeCommit repository. Brings those events into Knative.
|
||||
[AWS Cognito](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscognito) | Active Development | TriggerMesh | Registers for AWS Cognito events. Brings those events into Knative.
|
||||
[AWS DynamoDB](https://github.com/triggermesh/knative-lambda-sources/tree/master/awsdynamodb) | Active Development | TriggerMesh | Registers for events of on the specified AWS DynamoDB table. Brings those events into Knative.
|
||||
[AWS Kinesis](https://github.com/triggermesh/knative-lambda-sources/tree/master/awskinesis) | Active Development | TriggerMesh | Registers for events on the specified AWS Kinesis stream. Brings those events into Knative.
|
||||
[AWS SNS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssns) | Active Development | TriggerMesh | Registers for events of the specified AWS SNS endpoint. Brings those events into Knative.
|
||||
[AWS SQS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssqs) | Active Development | TriggerMesh | Registers for events of the specified AWS SQS queue. Brings those events into Knative.
|
||||
[FTP / SFTP](https://github.com/vaikas-google/ftp) | Proof of concept | None | Watches for files being uploaded into a FTP/SFTP and generates events for those.
|
||||
[Heartbeat](https://github.com/knative/eventing-sources/tree/master/cmd/heartbeats) | Proof of Concept | None | Uses an in-memory timer to produce events at the specified interval.
|
||||
[Heartbeat](https://github.com/Harwayne/auto-container-source/tree/master/heartbeat-source) | Proof of Concept | None | Uses an in-memory timer to produce events as the specified interval. Uses AutoContainerSource for underlying infrastructure.
|
||||
[K8s](https://github.com/Harwayne/auto-container-source/tree/master/k8s-event-source) | Proof of Concept | None | Brings Kubernetes cluster events into Knative. Uses AutoContainerSource for underlying infrastructure.
|
||||
[WebSocket](https://github.com/knative/eventing-sources/tree/master/cmd/websocketsource) | Active Development | None | Opens a WebSocket to the specified source and packages each received message as a Knative event.
|
||||
|
||||
| Name | Status | Support | Description |
|
||||
| ------------------------------------------------------------------------------------------------- | ------------------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [AWS CodeCommit](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscodecommit) | Active Development | TriggerMesh | Registers for events of the specified types on the specified AWS CodeCommit repository. Brings those events into Knative. |
|
||||
| [AWS Cognito](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscognito) | Active Development | TriggerMesh | Registers for AWS Cognito events. Brings those events into Knative. |
|
||||
| [AWS DynamoDB](https://github.com/triggermesh/knative-lambda-sources/tree/master/awsdynamodb) | Active Development | TriggerMesh | Registers for events of on the specified AWS DynamoDB table. Brings those events into Knative. |
|
||||
| [AWS Kinesis](https://github.com/triggermesh/knative-lambda-sources/tree/master/awskinesis) | Active Development | TriggerMesh | Registers for events on the specified AWS Kinesis stream. Brings those events into Knative. |
|
||||
| [AWS SNS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssns) | Active Development | TriggerMesh | Registers for events of the specified AWS SNS endpoint. Brings those events into Knative. |
|
||||
| [AWS SQS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssqs) | Active Development | TriggerMesh | Registers for events of the specified AWS SQS queue. Brings those events into Knative. |
|
||||
| [FTP / SFTP](https://github.com/vaikas-google/ftp) | Proof of concept | None | Watches for files being uploaded into a FTP/SFTP and generates events for those. |
|
||||
| [Heartbeat](https://github.com/knative/eventing-sources/tree/master/cmd/heartbeats) | Proof of Concept | None | Uses an in-memory timer to produce events at the specified interval. |
|
||||
| [Heartbeat](https://github.com/Harwayne/auto-container-source/tree/master/heartbeat-source) | Proof of Concept | None | Uses an in-memory timer to produce events as the specified interval. Uses AutoContainerSource for underlying infrastructure. |
|
||||
| [K8s](https://github.com/Harwayne/auto-container-source/tree/master/k8s-event-source) | Proof of Concept | None | Brings Kubernetes cluster events into Knative. Uses AutoContainerSource for underlying infrastructure. |
|
||||
| [WebSocket](https://github.com/knative/eventing-sources/tree/master/cmd/websocketsource) | Active Development | None | Opens a WebSocket to the specified source and packages each received message as a Knative event. |
|
||||
|
|
|
|||
|
|
@ -68,11 +68,11 @@ Engine cluster.
|
|||
1. Set `PROJECT` environment variable, you can replace `my-knative-project` with
|
||||
the desired name of your GCP project. If you don't have one, we'll create one
|
||||
in the next step.
|
||||
|
||||
|
||||
```bash
|
||||
export PROJECT=my-knative-project
|
||||
```
|
||||
|
||||
|
||||
1. If you don't have a GCP project, create and set it as your `gcloud` default:
|
||||
|
||||
```bash
|
||||
|
|
@ -125,9 +125,9 @@ components, the recommended configuration for a cluster is:
|
|||
--scopes=service-control,service-management,compute-rw,storage-ro,cloud-platform,logging-write,monitoring-write,pubsub,datastore \
|
||||
--num-nodes=3
|
||||
```
|
||||
|
||||
|
||||
1. Grant cluster-admin permissions to the current user:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl create clusterrolebinding cluster-admin-binding \
|
||||
--clusterrole=cluster-admin \
|
||||
|
|
@ -158,14 +158,14 @@ Knative depends on Istio.
|
|||
about an unknown type, run the second `kubectl apply` command again.
|
||||
|
||||
1. Label the default namespace with `istio-injection=enabled`:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl label namespace default istio-injection=enabled
|
||||
```
|
||||
|
||||
|
||||
1. Monitor the Istio components until all of the components show a `STATUS` of
|
||||
`Running` or `Completed`:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl get pods --namespace istio-system
|
||||
```
|
||||
|
|
@ -205,7 +205,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
completed until the upgrade process finishes.
|
||||
|
||||
1. Run the `kubectl apply` command to install Knative and its dependencies:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \
|
||||
--filename https://github.com/knative/build/releases/download/v0.4.0/build.yaml \
|
||||
|
|
@ -214,7 +214,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
|
||||
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
|
||||
```
|
||||
|
||||
|
||||
> **Note**: If your install fails on the first attempt, try rerunning the
|
||||
> commands. They will likely succeed on the second attempt. For background
|
||||
> info and to track the upcoming solution to this problem, see issues
|
||||
|
|
@ -224,9 +224,10 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
|
||||
> required to enable the Build and Serving components to interact with each
|
||||
> other.
|
||||
|
||||
1. Monitor the Knative components until all of the components show a `STATUS` of
|
||||
`Running`:
|
||||
|
||||
|
||||
```bash
|
||||
kubectl get pods --namespace knative-serving
|
||||
kubectl get pods --namespace knative-build
|
||||
|
|
|
|||
|
|
@ -192,6 +192,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
completed until the upgrade process finishes.
|
||||
|
||||
1. Run the `kubectl apply` command to install Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \
|
||||
--filename https://github.com/knative/build/releases/download/v0.4.0/build.yaml \
|
||||
|
|
@ -200,6 +201,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
|
||||
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
|
||||
```
|
||||
|
||||
> **Note**: If your install fails on the first attempt, try rerunning the
|
||||
> commands. They will likely succeed on the second attempt. For background
|
||||
> info and to track the upcoming solution to this problem, see issues
|
||||
|
|
@ -209,6 +211,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
|
||||
> required to enable the Build and Serving components to interact with each
|
||||
> other.
|
||||
|
||||
1. Monitor the Knative components until all of the components show a `STATUS` of
|
||||
`Running`:
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -105,6 +105,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
completed until the upgrade process finishes.
|
||||
|
||||
1. Run the `kubectl apply` command to install Knative and its dependencies:
|
||||
|
||||
```bash
|
||||
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \
|
||||
--filename https://github.com/knative/build/releases/download/v0.4.0/build.yaml \
|
||||
|
|
@ -113,6 +114,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
|
||||
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
|
||||
```
|
||||
|
||||
> **Note**: If your install fails on the first attempt, try rerunning the
|
||||
> commands. They will likely succeed on the second attempt. For background
|
||||
> info and to track the upcoming solution to this problem, see issues
|
||||
|
|
@ -122,6 +124,7 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
|
|||
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
|
||||
> required to enable the Build and Serving components to interact with each
|
||||
> other.
|
||||
|
||||
1. Monitor the Knative components until all of the components show a `STATUS` of
|
||||
`Running`:
|
||||
```bash
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ Serving resources and how they can be applied across common use cases.
|
|||
| Github Webhook | A simple webhook handler that demonstrates interacting with Github. | [Go](./gitwebhook-go/README.md) |
|
||||
| gRPC | A simple gRPC server. | [Go](./grpc-ping-go/README.md) |
|
||||
| Knative Routing | An example of mapping multiple Knative services to different paths under a single domain name using the Istio VirtualService concept. | [Go](./knative-routing-go/README.md) |
|
||||
| Knative Secrets | A simple app that demonstrates how to use a Kubernetes secret as a Volume in Knative. | [Go](./secrets-go/README.md) |
|
||||
| Knative Secrets | A simple app that demonstrates how to use a Kubernetes secret as a Volume in Knative. | [Go](./secrets-go/README.md) |
|
||||
| REST API | A simple Restful service that exposes an endpoint defined by an environment variable described in the Knative Configuration. | [Go](./rest-api-go/README.md) |
|
||||
| Source to URL | A sample that shows how to use Knative to go from source code in a git repository to a running application with a URL. | [Go](./source-to-url-go/README.md) |
|
||||
| Telemetry | This sample runs a simple web server that makes calls to other in-cluster services and responds to requests with "Hello World!". The purpose of this sample is to show generating metrics, logs, and distributed traces. | [Go](./telemetry-go/README.md) |
|
||||
|
|
|
|||
|
|
@ -175,8 +175,8 @@ echo $INGRESS_IP
|
|||
|
||||
1. If your cluster is running outside a cloud provider (for example on
|
||||
Minikube), your services will never get an external IP address, and
|
||||
`INGRESS_IP` won't contain a value. In that case, use the Istio `hostIP`
|
||||
and `nodePort` as the ingress IP:
|
||||
`INGRESS_IP` won't contain a value. In that case, use the Istio `hostIP` and
|
||||
`nodePort` as the ingress IP:
|
||||
|
||||
```shell
|
||||
export INGRESS_IP=$(kubectl get po --selector $INGRESSGATEWAY_LABEL=ingressgateway --namespace istio-system \
|
||||
|
|
|
|||
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
A simple web app written in Go that you can use for testing. It demonstrates how
|
||||
to use a Kubernetes secret as a Volume with Knative. We will create a new Google
|
||||
Service Account and place it into a Kubernetes secret, then we will mount it
|
||||
|
|
|
|||
|
|
@ -1,10 +1,11 @@
|
|||
This samples builds off of the [Creating a RESTful Service](../rest-api-go) sample
|
||||
to illustrate updating a Service to create a new Revision as well as splitting traffic
|
||||
between the two created Revisions.
|
||||
This samples builds off of the [Creating a RESTful Service](../rest-api-go)
|
||||
sample to illustrate updating a Service to create a new Revision as well as
|
||||
splitting traffic between the two created Revisions.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Complete the Service creation steps in [Creating a RESTful Service](../rest-api-go).
|
||||
1. Complete the Service creation steps in
|
||||
[Creating a RESTful Service](../rest-api-go).
|
||||
1. Move into the docs directory:
|
||||
|
||||
```shell
|
||||
|
|
@ -16,17 +17,17 @@ cd $GOPATH/src/github.com/knative/docs
|
|||
The service was originally created with a mode of `runLatest`. In `runLatest`
|
||||
mode, the service serves the latest Revision that is ready to handle incoming
|
||||
traffic. To split traffic between multiple Revisions, the Service mode will need
|
||||
to be changed to `release` mode. The `release` mode differs from `runLatest` in that
|
||||
it requires a `revisions` list. The `revisions` list accepts 1 or 2 Revisions
|
||||
that will be served by the base domain of the service. When 2 Revisions are
|
||||
present in the list a `rolloutPercent` parameter specifies the percentage of
|
||||
traffic to send to each Revision.
|
||||
to be changed to `release` mode. The `release` mode differs from `runLatest` in
|
||||
that it requires a `revisions` list. The `revisions` list accepts 1 or 2
|
||||
Revisions that will be served by the base domain of the service. When 2
|
||||
Revisions are present in the list a `rolloutPercent` parameter specifies the
|
||||
percentage of traffic to send to each Revision.
|
||||
|
||||
This first step will update the Service to release mode with a single Revision.
|
||||
|
||||
1. To populate the `revisions` list the name of the created Revision is required.
|
||||
The command below captures the names of all created Revisions as an array so it
|
||||
can be substituted it into the YAML.
|
||||
1. To populate the `revisions` list the name of the created Revision is
|
||||
required. The command below captures the names of all created Revisions as an
|
||||
array so it can be substituted it into the YAML.
|
||||
|
||||
```shell
|
||||
REVISIONS=($(kubectl get revision -l "serving.knative.dev/service=stock-service-example" -o \
|
||||
|
|
@ -34,12 +35,14 @@ jsonpath="{.items[*].metadata.name}"))
|
|||
echo ${REVISIONS[*]}
|
||||
```
|
||||
|
||||
2. The `release_sample.yaml` is setup in this directory to allow enable substituting the
|
||||
Revision name into the file with the `envsubst` utility. Executing the
|
||||
command below will update the Service to release mode with the queried Revision name.
|
||||
2. The `release_sample.yaml` is setup in this directory to allow enable
|
||||
substituting the Revision name into the file with the `envsubst` utility.
|
||||
Executing the command below will update the Service to release mode with the
|
||||
queried Revision name.
|
||||
|
||||
- Note: The command below expects `$REPO` to still be exported. See
|
||||
[RESTful Service Setup](https://github.com/knative/docs/tree/master/serving/samples/rest-api-go#setup) to set it.
|
||||
[RESTful Service Setup](https://github.com/knative/docs/tree/master/serving/samples/rest-api-go#setup)
|
||||
to set it.
|
||||
|
||||
```shell
|
||||
CURRENT=${REVISIONS[0]} \
|
||||
|
|
@ -48,7 +51,7 @@ envsubst < serving/samples/traffic-splitting/release_sample.yaml \
|
|||
```
|
||||
|
||||
3. The `spec` of the Service should now show `release` with the Revision name
|
||||
retrieved above.
|
||||
retrieved above.
|
||||
|
||||
```shell
|
||||
kubectl get ksvc stock-service-example --output yaml
|
||||
|
|
@ -58,12 +61,13 @@ kubectl get ksvc stock-service-example --output yaml
|
|||
|
||||
This section describes how to create a new Revision by updating your Service.
|
||||
|
||||
A new Revision is created every time a value in the `revisionTemplate` section of
|
||||
the Service `spec` is updated. The `updated_sample.yaml` in this folder changes
|
||||
the environment variable `RESOURCE` from `stock` to `share`. Applying this
|
||||
change will result in a new Revision.
|
||||
A new Revision is created every time a value in the `revisionTemplate` section
|
||||
of the Service `spec` is updated. The `updated_sample.yaml` in this folder
|
||||
changes the environment variable `RESOURCE` from `stock` to `share`. Applying
|
||||
this change will result in a new Revision.
|
||||
|
||||
For comparison, you can diff the `release_sample.yaml` with the `updated_sample.yaml`.
|
||||
For comparison, you can diff the `release_sample.yaml` with the
|
||||
`updated_sample.yaml`.
|
||||
|
||||
```shell
|
||||
diff serving/samples/traffic-splitting/release_sample.yaml \
|
||||
|
|
@ -89,8 +93,9 @@ kubectl get ksvc stock-service-example --output yaml
|
|||
|
||||
3. The readiness of the Service can be verified through the Service Conditions.
|
||||
When the Service conditions report it is ready again, you can access the new
|
||||
Revision using the same method as found in the [previous sample](../rest-api-go/README.md#access-the-service)
|
||||
by prefixing the Service hostname with `latest.`.
|
||||
Revision using the same method as found in the
|
||||
[previous sample](../rest-api-go/README.md#access-the-service) by prefixing
|
||||
the Service hostname with `latest.`.
|
||||
|
||||
```shell
|
||||
curl --header "Host:latest.${SERVICE_HOSTNAME}" http://${INGRESS_IP}
|
||||
|
|
@ -107,11 +112,11 @@ curl --header "Host:current.${SERVICE_HOSTNAME}" http://${INGRESS_IP}
|
|||
## Traffic Splitting
|
||||
|
||||
Updating the service to split traffic between the two revisions is done by
|
||||
placing a second revision in of the `revisions` list and specifying a `rolloutPercent`.
|
||||
The `rolloutPercent` is the percentage of traffic to send to the second element in
|
||||
the list. When the Service is Ready the traffic will be split as desired for the
|
||||
base domain, and a subdomain of `candidate` will be available pointing to the
|
||||
second Revision.
|
||||
placing a second revision in of the `revisions` list and specifying a
|
||||
`rolloutPercent`. The `rolloutPercent` is the percentage of traffic to send to
|
||||
the second element in the list. When the Service is Ready the traffic will be
|
||||
split as desired for the base domain, and a subdomain of `candidate` will be
|
||||
available pointing to the second Revision.
|
||||
|
||||
1. Get the latest list of revisions by executing the command below:
|
||||
|
||||
|
|
@ -138,16 +143,17 @@ envsubst < serving/samples/traffic-splitting/split_sample.yaml \
|
|||
kubectl get ksvc --output yaml
|
||||
```
|
||||
|
||||
4. Once updated, `curl` requests to the base domain should result in responses split evenly between `Welcome to the share app!` and
|
||||
`Welcome to the stock app!`.
|
||||
4. Once updated, `curl` requests to the base domain should result in responses
|
||||
split evenly between `Welcome to the share app!` and
|
||||
`Welcome to the stock app!`.
|
||||
|
||||
```shell
|
||||
curl --header "Host:${SERVICE_HOSTNAME}" http://${INGRESS_IP}
|
||||
```
|
||||
|
||||
5. Much like the `current` and `latest` subdomains there should now be a
|
||||
`candidate` subdomain that should return `Welcome to the share app!` as it hits
|
||||
the second index of the `revisions` list.
|
||||
`candidate` subdomain that should return `Welcome to the share app!` as it
|
||||
hits the second index of the `revisions` list.
|
||||
|
||||
```shell
|
||||
curl --header "Host:candidate.${SERVICE_HOSTNAME}" http://${INGRESS_IP}
|
||||
|
|
|
|||
Loading…
Reference in New Issue