knative
/
docs
mirror of https://github.com/knative/docs.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Replace erroneous instances of above and below (#4106) 

* Remove accidental changes to archived file

* Update docs/developer/eventing/sources/creating-event-sources/writing-event-source/04-reconciler.md

Co-authored-by: Samia Nneji <snneji@vmware.com>

* Update docs/developer/eventing/sources/creating-event-sources/writing-event-source/04-reconciler.md

Co-authored-by: Samia Nneji <snneji@vmware.com>

* Apply suggestions from code review

Co-authored-by: Samia Nneji <snneji@vmware.com>

* Update docs/eventing/flows/sequence/sequence-reply-to-sequence/README.md

Co-authored-by: Samia Nneji <snneji@vmware.com>

* Deleted redundant lines per Samia's suggestion

* Update docs/serving/samples/hello-world/helloworld-php/README.md

Co-authored-by: Samia Nneji <snneji@vmware.com>

Co-authored-by: Samia Nneji <snneji@vmware.com>
This commit is contained in:
RichardJJG 2021-08-12 19:51:35 +01:00 committed by GitHub
parent d1dff0aefb
commit 7ee18955f1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
93 changed files with 305 additions and 310 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
docs/admin/eventing/broker-configuration.md
View File

@ -112,7 +112,7 @@ When a Broker is created without a specified `BrokerClass` annotation, the defau
The following example creates a Broker called `default` in the default namespace, and uses `MTChannelBasedBroker` as the implementation:
1. Create a YAML file for your Broker using the example below:
1. Create a YAML file for your Broker using the following example:
```yaml
apiVersion: eventing.knative.dev/v1

4
docs/admin/eventing/kafka-channel-configuration.md
View File

@ -10,7 +10,7 @@ To use Kafka Channels, you must:
## Create a `kafka-channel` ConfigMap
1. Create a YAML file for the `kafka-channel` ConfigMap using the template below:
1. Create a YAML file for the `kafka-channel` ConfigMap using the following template:
```yaml
apiVersion: v1
@ -38,7 +38,7 @@ To use Kafka Channels, you must:
Where `<filename>` is the name of the file you created in the previous step.
1. Optional. To create a Broker that uses Kafka Channels, specify the `kafka-channel` ConfigMap in the Broker spec. You can do this by creating a YAML file using the template below:
1. Optional. To create a Broker that uses Kafka Channels, specify the `kafka-channel` ConfigMap in the Broker spec. You can do this by creating a YAML file using the following template:
```yaml
apiVersion: eventing.knative.dev/v1

2
docs/admin/install/eventing/eventing-installation-files.md
View File

@ -7,7 +7,7 @@ This guide provides reference information about the core Knative Eventing YAML f
For information about installing these files, see [Installing Knative Eventing using YAML files](../install-eventing-with-yaml).
The table below describes the installation files included in Knative Eventing:
The following table describes the installation files included in Knative Eventing:
| File name | Description | Dependencies|
| --- | --- | --- |

6
docs/admin/install/eventing/install-eventing-with-yaml.md
View File

@ -43,7 +43,7 @@ To install Knative Eventing:
## Optional: Install a default Channel (messaging) layer
The tabs below expand to show instructions for installing a default Channel layer.
The following tabs expand to show instructions for installing a default Channel layer.
Follow the procedure for the Channel of your choice:
<!-- This indentation is important for things to render properly. -->
@ -92,7 +92,7 @@ Follow the procedure for the Channel of your choice:
## Optional: Install a Broker layer:
The tabs below expand to show instructions for installing the Broker layer.
The following tabs expand to show instructions for installing the Broker layer.
Follow the procedure for the Broker of your choice:
<!-- This indentation is important for things to render properly. -->
@ -196,7 +196,7 @@ Follow the procedure for the Broker of your choice:
## Install optional Eventing extensions
The tabs below expand to show instructions for installing each Eventing extension.
The following tabs expand to show instructions for installing each Eventing extension.
<!-- This indentation is important for things to render properly. -->
=== "Apache Kafka Sink"

12
docs/admin/install/installing-istio.md
View File

@ -34,7 +34,7 @@ instructions. If you're familiar with Istio and know what kind of installation
you want, read through the options and choose the installation that suits your
needs.
You can easily customize your Istio installation with `istioctl`. The below sections
You can easily customize your Istio installation with `istioctl`. The following sections
cover a few useful Istio configurations and their benefits.
### Choosing an Istio installation
@ -57,7 +57,7 @@ Enter the following command to install Istio:
To install Istio without sidecar injection:
1. Create a `istio-minimal-operator.yaml` file using the template below:
1. Create a `istio-minimal-operator.yaml` file using the following template:
```yaml
apiVersion: install.istio.io/v1alpha1
@ -99,7 +99,7 @@ injection][2]. The Istio service mesh provides a few benefits:
- Allows you to use the [Istio authorization policy][4], controlling the access
to each Knative service based on Istio service roles.
To automatic sidecar injection, set `autoInject: enabled` in addition to above
For automatic sidecar injection, set `autoInject: enabled` in addition to the earlier
operator configuration.
```
@ -121,7 +121,7 @@ preparations for mTLS enabled environment.
```
1. Set `PeerAuthentication` to `PERMISSIVE` on knative-serving system namespace
by creating a YAML file using the template below:
by creating a YAML file using the following template:
```bash
apiVersion: "security.istio.io/v1beta1"
@ -174,7 +174,7 @@ Replace the label selector with the label of your service:
istio: knative-local-gateway
```
For the service above, it should be updated to:
For the service mentioned earlier, it should be updated to:
```
custom: custom-local-gateway
@ -218,7 +218,7 @@ You can edit this by using the following command:
kubectl edit cm config-domain --namespace knative-serving
```
Given the external IP above, change the content to:
Given this external IP, change the content to:
```
apiVersion: v1

44
docs/admin/install/knative-with-operators.md
View File

@ -97,7 +97,7 @@ kubectl logs -f deploy/knative-operator
The field `spec.manifests` is used to specify one or multiple URL links of Knative Serving component. Do not forget to
add the valid URL of the Knative network ingress plugin. Knative Serving component is still tightly-coupled with a network
ingress plugin in the operator. As in the above example, you can use `net-istio`. The ordering of the URLs is critical.
ingress plugin in the operator. As in the example mentioned earlier, you can use `net-istio`. The ordering of the URLs is critical.
Put the manifest you want to apply first on the top.
=== "Install Customized Knative Serving"
@ -114,7 +114,7 @@ kubectl logs -f deploy/knative-operator
1. You can use the overwrite mode to customize all the Knative Serving manifests. For example, the version of the customized
Knative Serving is `$spec_version`, and it is available at `https://my-serving/serving.yaml`. You choose `net-istio`
as the ingress plugin, which is available at `https://my-net-istio/net-istio.yaml`. You can create the content of Serving
CR as below to install your Knative Serving and the istio ingress:
CR as in the following example to install your Knative Serving and the istio ingress:
```
apiVersion: v1
kind: Namespace
@ -140,7 +140,7 @@ kubectl logs -f deploy/knative-operator
1. You can use the append mode to add your customized manifests into the default manifests. For example, you only customize
a few resources, and make them available at `https://my-serving/serving-custom.yaml`. You still need to install the default
Knative Serving. In this case, you can create the content of Serving CR as below:
Knative Serving. In this case, you can create the content of Serving CR as follows:
```
apiVersion: v1
kind: Namespace
@ -195,7 +195,7 @@ knative-serving <version number> True
??? "Installing the Knative Serving component with different network layers"
Knative Operator can configure Knative Serving component with different network layer options. Istio is the default network
layer, if the ingress is not specified in the Knative Serving CR. Click on each tab below to see how you can configure
layer, if the ingress is not specified in the Knative Serving CR. Click on each of the following tabs to see how you can configure
Knative Serving with different ingresses:
=== "Ambassador"
@ -225,7 +225,7 @@ knative-serving <version number> True
kubectl set env --namespace ambassador deployments/ambassador AMBASSADOR_KNATIVE_SUPPORT=true
```
1. To configure Knative Serving to use Ambassador, copy the YAML below into a file:
1. To configure Knative Serving to use Ambassador, copy the following YAML into a file:
```yaml
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
@ -250,7 +250,7 @@ knative-serving <version number> True
kubectl --namespace ambassador get service ambassador
```
Save this for configuring DNS below.
Save this for configuring DNS later.
=== "Contour"
@ -261,7 +261,7 @@ knative-serving <version number> True
kubectl apply --filename {{artifact(repo="net-contour",file="contour.yaml")}}
```
1. To configure Knative Serving to use Contour, copy the YAML below into a file:
1. To configure Knative Serving to use Contour, copy the following YAML into a file:
```yaml
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
@ -288,13 +288,13 @@ knative-serving <version number> True
kubectl --namespace contour-external get service envoy
```
Save this for configuring DNS below.
Save this for configuring DNS later.
=== "Kourier"
The following commands install Kourier and enable its Knative integration.
1. To configure Knative Serving to use Kourier, copy the YAML below into a file:
1. To configure Knative Serving to use Kourier, copy the following YAML into a file:
```yaml
apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
@ -322,7 +322,7 @@ knative-serving <version number> True
kubectl --namespace knative-serving get service kourier
```
Save this for configuring DNS below.
Save this for configuring DNS later.
<!-- These are snippets from the docs/snippets directory -->
{% include "dns.md" %}
@ -397,7 +397,7 @@ knative-serving <version number> True
1. You can use the overwrite mode to customize all the Knative Eventing manifests. For example, the version of the customized
Knative Eventing is `$spec_version`, and it is available at `https://my-eventing/eventing.yaml`. You can create the
content of Eventing CR as below to install your Knative Eventing:
content of Eventing CR to install your Knative Eventing as follows:
```
apiVersion: v1
@ -423,7 +423,7 @@ knative-serving <version number> True
1. You can use the append mode to add your customized manifests into the default manifests. For example, you only customize
a few resources, and make them available at `https://my-eventing/eventing-custom.yaml`. You still need to install the default
Knative eventing. In this case, you can create the content of Eventing CR as below:
Knative eventing. In this case, you can create the content of Eventing CR as follows:
```
apiVersion: v1
@ -483,12 +483,12 @@ knative-eventing <version number> True
??? "Installing the Knative Eventing component with different eventing sources"
Knative Operator can configure Knative Eventing component with different eventing sources. Click on each tab below to
Knative Operator can configure Knative Eventing component with different eventing sources. Click on each of the following tabs to
see how you can configure Knative Eventing with different eventing sources:
=== "Ceph"
To configure Knative Eventing to install Ceph as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install Ceph as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -505,7 +505,7 @@ knative-eventing <version number> True
=== "Apache CouchDB"
To configure Knative Eventing to install Apache CouchDB as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install Apache CouchDB as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -522,7 +522,7 @@ knative-eventing <version number> True
=== "GitHub"
To configure Knative Eventing to install GitHub as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install GitHub as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -539,7 +539,7 @@ knative-eventing <version number> True
=== "GitLab"
To configure Knative Eventing to install GitLab as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install GitLab as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -556,7 +556,7 @@ knative-eventing <version number> True
=== "Apache Kafka"
To configure Knative Eventing to install Kafka as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install Kafka as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -573,7 +573,7 @@ knative-eventing <version number> True
=== "NATS Streaming"
To configure Knative Eventing to install NATS Streaming as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install NATS Streaming as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -590,7 +590,7 @@ knative-eventing <version number> True
=== "Prometheus"
To configure Knative Eventing to install Prometheus as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install Prometheus as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -607,7 +607,7 @@ knative-eventing <version number> True
=== "RabbitMQ"
To configure Knative Eventing to install RabbitMQ as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install RabbitMQ as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1
@ -624,7 +624,7 @@ knative-eventing <version number> True
=== "Redis"
To configure Knative Eventing to install Redis as the eventing source, apply the content of the Eventing CR as below:
To configure Knative Eventing to install Redis as the eventing source, apply the content of the Eventing CR as follows:
```bash
cat <<-EOF | kubectl apply -f -
apiVersion: operator.knative.dev/v1alpha1

2
docs/admin/install/operator/configuring-eventing-cr.md
View File

@ -137,7 +137,7 @@ Some images are defined by using the environment variable in Knative Eventing. T
This example shows how you can define custom image links that can be defined in the KnativeEventing CR using the simplified format
`docker.io/knative-images/${NAME}:{CUSTOM-TAG}`.
In the example below:
In the following example:
- The custom tag `latest` is used for all images.
- All image links are accessible without using secrets.

8
docs/admin/install/operator/configuring-serving-cr.md
View File

@ -120,7 +120,7 @@ from a private container registry](../../../serving/deploying-from-private-regis
This example shows how you can define custom image links that can be defined in the CR using the simplified format
`docker.io/knative-images/${NAME}:{CUSTOM-TAG}`.
In the example below:
In the following example:
- the custom tag `v0.13.0` is used for all images
- all image links are accessible without using secrets
@ -204,7 +204,7 @@ This example uses a secret named `regcred`. You must create your own private sec
- [From command line for docker credentials](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/#create-a-secret-by-providing-credentials-on-the-command-line)
- [Create your own secret](https://kubernetes.io/docs/concepts/configuration/secret/#creating-your-own-secrets)
After you create this secret, edit the Operator CR by appending the content below:
After you create this secret, edit the Operator CR by appending the following content:
```yaml
apiVersion: operator.knative.dev/v1alpha1
@ -219,7 +219,7 @@ spec:
- name: regcred
```
The field `imagePullSecrets` expects a list of secrets. You can add multiple secrets to access the images as below:
The field `imagePullSecrets` expects a list of secrets. You can add multiple secrets to access the images as follows:
```yaml
apiVersion: operator.knative.dev/v1alpha1
@ -387,7 +387,7 @@ spec:
ephemeral-storage: 4Gi
```
If you would like to add another container `autoscaler` with the same configuration, you need to change your CR as below:
If you would like to add another container `autoscaler` with the same configuration, you need to change your CR as follows:
```yaml
apiVersion: operator.knative.dev/v1alpha1

12
docs/admin/install/serving/install-serving-with-yaml.md
View File

@ -25,7 +25,7 @@ To install the Knative Serving component:
## Install a networking layer
The tabs below expand to show instructions for installing a networking layer.
The following tabs expand to show instructions for installing a networking layer.
Follow the procedure for the networking layer of your choice:
<!-- TODO: Link to document/diagram describing what is a networking layer. -->
@ -55,7 +55,7 @@ Follow the procedure for the networking layer of your choice:
```
!!! tip
Save this to use in the [Configure DNS](#configure-dns) section below.
Save this to use in the following [Configure DNS](#configure-dns) section.
=== "Ambassador"
@ -105,7 +105,7 @@ Follow the procedure for the networking layer of your choice:
```
!!! tip
Save this to use in the [Configure DNS](#configure-dns) section below.
Save this to use in the following [Configure DNS](#configure-dns) section.
=== "Contour"
@ -139,7 +139,7 @@ Follow the procedure for the networking layer of your choice:
```
!!! tip
Save this to use in the [Configure DNS](#configure-dns) section below.
Save this to use in the following [Configure DNS](#configure-dns) section.
=== "Istio"
@ -166,7 +166,7 @@ Follow the procedure for the networking layer of your choice:
```
!!! tip
Save this to use in the [Configure DNS](#configure-dns) section below.
Save this to use in the following [Configure DNS](#configure-dns) section.
## Verify the installation
@ -198,7 +198,7 @@ Follow the procedure for the networking layer of your choice:
## Install optional Serving extensions
The tabs below expand to show instructions for installing each Serving extension.
The following tabs expand to show instructions for installing each Serving extension.
=== "HPA autoscaling"

2
docs/admin/install/serving/serving-installation-files.md
View File

@ -7,7 +7,7 @@ This guide provides reference information about the core Knative Serving YAML fi
For information about installing these files, see [Installing Knative Serving using YAML files](../install-serving-with-yaml).
The table below describes the installation files included in Knative Serving:
The following table describes the installation files included in Knative Serving:
| File name | Description | Dependencies|
| --- | --- | --- |

14
docs/admin/install/uninstall.md
View File

@ -6,8 +6,8 @@ type: "docs"
# Uninstalling Knative
To uninstall an Operator-based Knative installation, follow the [Uninstall an Operator-based Knative Installation](#uninstall-an-operator-based-knative-installation) procedure below.
To uninstall a YAML-based Knative installation, follow the [Uninstall a YAML-based Knative Installation](#uninstall-a-yaml-based-knative-installation) procedure below.
To uninstall an Operator-based Knative installation, see the following [Uninstall an Operator-based Knative Installation](#uninstall-an-operator-based-knative-installation) procedure.
To uninstall a YAML-based Knative installation, see the following [Uninstall a YAML-based Knative Installation](#uninstall-a-yaml-based-knative-installation) procedure.
## Uninstalling a YAML-based Knative installation
@ -17,7 +17,7 @@ To uninstall a YAML-based Knative installation:
### Uninstalling optional Serving extensions
Uninstall any Serving extensions you have installed by following the relevant steps below:
Uninstall any Serving extensions you have installed by performing the steps in the following relevant tab:
@ -73,7 +73,7 @@ Follow the relevant procedure to uninstall the networking layer you installed:
<!-- TODO: Link to document/diagram describing what is a networking layer. -->
<!-- This indentation is important for things to render properly. -->
=== "Ambassador"
The following commands uninstall Ambassador and enable its Knative integration.
@ -162,7 +162,7 @@ Follow the relevant procedure to uninstall the networking layer you installed:
### Uninstalling optional Eventing extensions
Uninstall any Eventing extensions you have installed by following the relevant procedure below:
Uninstall any Eventing extensions you have installed by following the relevant procedure:
@ -294,7 +294,7 @@ Uninstall each channel layer you have installed:
<!-- This indentation is important for things to render properly. -->
=== "Apache Kafka Channel"
Uninstall the Apache Kafka Channel by running:
@ -364,7 +364,7 @@ Uninstall each channel layer you have installed:
## Uninstall an Operator-based Knative installation
To uninstall an Operator-based Knative installation, follow the procedures below.
To uninstall an Operator-based Knative installation, follow these procedures:
### Removing the Knative Serving component

6
docs/admin/upgrade/upgrade-installation-with-operator.md
View File

@ -12,7 +12,7 @@ The Knative Operator supports up to the last three major releases. For example,
To upgrade, apply the Operator custom resources, adding the `spec.version` for the Knative version that you want to upgrade to:
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: operator.knative.dev/v1alpha1
@ -119,7 +119,7 @@ If the upgrade fails, you can rollback to restore your Knative to the previous v
=== "Knative Serving"
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: operator.knative.dev/v1alpha1
@ -140,7 +140,7 @@ If the upgrade fails, you can rollback to restore your Knative to the previous v
=== "Knative Eventing"
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: operator.knative.dev/v1alpha1

2
docs/client/configure-kn.md
View File

@ -29,7 +29,7 @@ eventing:
Where
- `path-lookup` specifies whether `kn` should look for [plugins](kn-plugins) in the `PATH` environment variable. This is a boolean configuration option. The default value is `false`.
- `directory` specifies the directory where `kn` will look for plugins. The default path depends on the operating system, as described above. This can be any directory that is visible to the user.
- `directory` specifies the directory where `kn` will look for plugins. The default path depends on the operating system, as described earlier. This can be any directory that is visible to the user.
- `sink-mappings` defines the Kubernetes Addressable resource that is used when you use the `--sink` flag with a `kn` CLI command.
- `prefix`: The prefix you want to use to describe your sink. Service, `svc`, `channel`, and `broker` are predefined prefixes in `kn`.
<!--can be a prefix be anything? Otherwise let's provide a full list of what's allowed, limitations, etc.-->

2
docs/developer/eventing/event-delivery.md
View File

@ -105,7 +105,7 @@ These extension attributes are as follows:
### Channel support
The table below summarizes what delivery parameters are supported for each Channel implementation.
The following table summarizes which delivery parameters are supported for each Channel implementation.
| Channel Type | Supported Delivery Parameters |
| - | - |

34
docs/developer/eventing/sources/apiserversource/getting-started/README.md
View File

@ -32,7 +32,7 @@ command:
1. Create a ServiceAccount:
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: v1
@ -44,7 +44,7 @@ command:
Where:
- `<service-account>` is the name of the ServiceAccount that you want to create.
- `<namespace>` is the namespace that you created in step 1 above.
- `<namespace>` is the namespace that you created in step 1 earlier.
1. Apply the YAML file by running the command:
@ -55,7 +55,7 @@ command:
1. Create a ClusterRole:
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
@ -83,7 +83,7 @@ command:
1. Create a ClusterRoleBinding:
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: rbac.authorization.k8s.io/v1
@ -102,9 +102,9 @@ command:
Where:
- `<cluster-role-binding>` is the name of the ClusterRoleBinding that you want to create.
- `<cluster-role>` is the name of the ClusterRole that you created in step 3 above.
- `<service-account>` is the name of the ServiceAccount that you created in step 2 above.
- `<namespace>` is the name of the namespace that you created in step 1 above.
- `<cluster-role>` is the name of the ClusterRole that you created in step 3 earlier.
- `<service-account>` is the name of the ServiceAccount that you created in step 2 earlier.
- `<namespace>` is the name of the namespace that you created in step 1 earlier.
1. Apply the YAML file by running the command:
@ -129,13 +129,13 @@ command:
Where:
- `<apiserversource>` is the name of the source that you want to create.
- `<namespace>` is the name of the namespace that you created in step 1 above.
- `<service-account>` is the name of the ServiceAccount that you created in step 2 above.
- `<namespace>` is the name of the namespace that you created in step 1 earlier.
- `<service-account>` is the name of the ServiceAccount that you created in step 2 earlier.
- `<sink>` is the name of the PodSpecable object that you want to use as a sink.
A PodSpecable is an object that describes a PodSpec.
=== "YAML"
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: sources.knative.dev/v1
@ -158,8 +158,8 @@ command:
Where:
- `<apiserversource>` is the name of the source that you want to create.
- `<namespace>` is the name of the namespace that you created in step 1 above.
- `<service-account>` is the name of the ServiceAccount that you created in step 2 above.
- `<namespace>` is the name of the namespace that you created in step 1 earlier.
- `<service-account>` is the name of the ServiceAccount that you created in step 2 earlier.
- `<event-mode>` is either `Resource` or `Reference`. If set to `Resource`, the event payload contains the entire resource that the event is for. If set to `Reference`, the event payload only contains a reference to the resource that the event is for. The default is `Reference`.
- `<sink-kind>` is any supported PodSpecable object that you want to use as a sink, for example, `Service` or `Deployment`. A PodSpecable is an object that describes a PodSpec.
- `<sink-name>` is the name of your sink.
@ -178,14 +178,14 @@ command:
```bash
kubectl run busybox --image=busybox --namespace=<namespace> --restart=Never -- ls
```
Where `<namespace>` is the name of the namespace that you created in step 1 above.
Where `<namespace>` is the name of the namespace that you created in step 1 earlier.
1. Delete the test pod by running the command:
```bash
kubectl --namespace=<namespace> delete pod busybox
```
Where `<namespace>` is the name of the namespace that you created in step 1 above.
Where `<namespace>` is the name of the namespace that you created in step 1 earlier.
1. View the logs to verify that Kubernetes events were sent to the sink by the Knative Eventing system by running the command:
@ -194,8 +194,8 @@ command:
```
Where:
- `<namespace>` is the name of the namespace that you created in step 1 above.
- `<sink>` is the name of the PodSpecable object that you used as a sink in step 5 above.
- `<namespace>` is the name of the namespace that you created in step 1 earlier.
- `<sink>` is the name of the PodSpecable object that you used as a sink in step 5 earlier.
Example log output:
@ -260,4 +260,4 @@ To remove the ApiServerSource object and all of the related resources:
```bash
kubectl delete namespace <namespace>
```
Where `<namespace>` is the name of the namespace that you created in step 1 above.
Where `<namespace>` is the name of the namespace that you created in step 1 earlier.

12
docs/developer/eventing/sources/containersource/README.md
View File

@ -9,7 +9,7 @@ The ContainerSource object starts a container image that generates events and
sends messages to a sink URI. You can also use ContainerSource to support your
own event sources in Knative.
In the examples below, the event source is a heartbeats container and the sink
In the following examples, the event source is a heartbeats container and the sink
is a Knative Service.
If you have an existing event source and sink, you can replace the examples with
your own values.
@ -20,7 +20,7 @@ Before you can create a ContainerSource object:
- You must have [Knative Eventing](../../../admin/install/install-eventing-with-yaml)
installed on your cluster.
- If you want to use the example heartbeats event source below, you must also:
- If you want to use the following example heartbeats event source, you must also:
- Install [ko](https://github.com/google/ko)
- Set `KO_DOCKER_REPO`. For example, `gcr.io/[gcloud-project]` or `docker.io/<username>`
- Authenticate with your `KO_DOCKER_REPO`
@ -30,7 +30,7 @@ installed on your cluster.
1. Build an image of your event source and publish it to your image repository.
Your image must read the environment variable `K_SINK` and post messages to the
URL specified in `K_SINK`. If you do not already have an image, you can use
URL specified in `K_SINK`. If you do not already have an image, you can use
the following example heartbeats event source by running the commands:
```bash
@ -64,7 +64,7 @@ Service, which dumps incoming messages into its log:
```
=== "YAML"
1. Create a YAML file using the example below:
1. Create a YAML file using the following example:
```yaml
apiVersion: apps/v1
@ -126,7 +126,7 @@ Service, which dumps incoming messages into its log:
For a list of available options, see the [Knative client documentation](https://github.com/knative/client/blob/main/docs/cmd/kn_source_container_create.md#kn-source-container-create).
=== "YAML"
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: sources.knative.dev/v1
@ -196,7 +196,7 @@ Service, which dumps incoming messages into its log:
1. Verify that the output returns the properties of the events that your
ContainerSource sent to your sink.
In the example below, the command has returned the `Attributes` and `Data` properties
In the following example, the command has returned the `Attributes` and `Data` properties
of the events that the ContainerSource sent to the `event-display` Service:
```

2
docs/developer/eventing/sources/creating-event-sources/writing-event-source/01-theory.md
View File

@ -87,7 +87,7 @@ func NewController(ctx context.Context, cmw configmap.Watcher) *controller.Impl
```
Sample source's [`update-codegen.sh`](https://github.com/knative-sandbox/sample-source/blob/main/hack/update-codegen.sh) have the configuration
to have the required things above generated and injected:
to have the required things mentioned earlier generated and injected:
```bash
# Generation
${CODEGEN_PKG}/generate-groups.sh "deepcopy,client,informer,lister" \

42
docs/developer/eventing/sources/creating-event-sources/writing-event-source/04-reconciler.md
View File

@ -10,26 +10,28 @@ aliases:
# Reconciler Implementation and Design
## Reconciler Functionality
General steps the reconciliation process needs to cover:
1. Update the `ObservedGeneration` and initialize the `Status` conditions (as defined in `samplesource_lifecycle.go` and `samplesource_types.go`)
```go
src.Status.InitializeConditions()
src.Status.ObservedGeneration = src.Generation
```
2. Create/reconcile the Receive Adapter (detailed below)
3. If successful, update the `Status` and `MarkDeployed`
```go
src.Status.PropagateDeploymentAvailability(ra)
```
4. Create/reconcile the `SinkBinding` for the Receive Adapter targeting the `Sink` (detailed below)
5. MarkSink with the result
```go
src.Status.MarkSink(sb.Status.SinkURI)
```
6. Return a new reconciler event stating that the process is done
```go
return pkgreconciler.NewEvent(corev1.EventTypeNormal, "SampleSourceReconciled", "SampleSource reconciled: \"%s/%s\"", namespace, name)
```
1. Update the `ObservedGeneration` and initialize the `Status` conditions as defined in `samplesource_lifecycle.go` and `samplesource_types.go`:
```go
src.Status.InitializeConditions()
src.Status.ObservedGeneration = src.Generation
```
1. Follow the later [Reconcile/Create the Receive Adapter](#reconcilecreate-the-receive-adapter) procedure.
1. If successful, update the `Status` and `MarkDeployed`:
```go
src.Status.PropagateDeploymentAvailability(ra)
```
1. Follow the later [Reconcile/Create the SinkBinding](#reconcilecreate-the-sinkbinding) procedure for the receive adapter targeting the sink.
1. `MarkSink` with the result:
```go
src.Status.MarkSink(sb.Status.SinkURI)
```
1. Return a new reconciler event stating that the process is done:
```go
return pkgreconciler.NewEvent(corev1.EventTypeNormal, "SampleSourceReconciled", "SampleSource reconciled: \"%s/%s\"", namespace, name)
```
## Reconcile/Create The Receive Adapter
As part of the source reconciliation, we have to create and deploy
@ -76,7 +78,7 @@ return pkgreconciler.NewEvent(corev1.EventTypeNormal, "DeploymentUpdated", "upda
## Reconcile/Create The SinkBinding
Instead of directly giving the details of the sink to the receive adapter, use a `SinkBinding` to bind the receive adapter with the sink.
Steps here are almost the same with the `Deployment` reconciliation above, but it is for another resource, `SinkBinding`.
Steps here are almost the same with the `Deployment` reconciliation mentioned earlier, but it is for another resource, `SinkBinding`.
1. Create a `Reference` for the receive adapter deployment. This deployment will be `SinkBinding`'s source:
```go

7
docs/developer/eventing/sources/kafka-source/README.md
View File

@ -69,7 +69,7 @@ The `KafkaSource` reads all the messages, from all partitions, and sends those m
cd knative-docs/docs/eventing/samples/kafka/source
```
2. Build the Event Display Service by copying the YAML below into a file:
2. Build the Event Display Service by copying the following YAML into a file:
```yaml
apiVersion: serving.knative.dev/v1
@ -152,8 +152,7 @@ The `KafkaSource` reads all the messages, from all partitions, and sends those m
### Verify
1. Produce a message (`{"msg": "This is a test!"}`) to the Apache Kafka topic,
like shown below:
1. Produce a message (`{"msg": "This is a test!"}`) to the Apache Kafka topic as in the following example:
```
kubectl -n kafka run kafka-producer -ti --image=strimzi/kafka:0.14.0-kafka-2.3.0 --rm=true --restart=Never -- bin/kafka-console-producer.sh --broker-list my-cluster-kafka-bootstrap:9092 --topic knative-demo-topic
If you don't see a command prompt, try pressing enter.
@ -293,7 +292,7 @@ To specify it, add the label `kafkasources.sources.knative.dev/key-type` to the
## Connecting to a TLS enabled Kafka broker
The KafkaSource supports TLS and SASL authentication methods. For enabling TLS authentication, please have the below files
The KafkaSource supports TLS and SASL authentication methods. To enable TLS authentication, you must have the following files:
* CA Certificate
* Client Certificate and Key

4
docs/developer/eventing/sources/ping-source/README.md
View File

@ -79,7 +79,7 @@ The following example shows how you can configure a PingSource as an event sourc
=== "YAML"
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: sources.knative.dev/v1
@ -122,7 +122,7 @@ The following example shows how you can configure a PingSource as an event sourc
To create a PingSource that uses base64 encoded data:
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: sources.knative.dev/v1

8
docs/developer/eventing/sources/sinkbinding/getting-started.md
View File

@ -7,7 +7,7 @@ SinkBinding resolves a sink as a URI, sets the URI in the environment
variable `K_SINK`, and adds the URI to a subject using `K_SINK`.
If the URI changes, SinkBinding updates the value of `K_SINK`.
In the examples below, the sink is a Knative Service and the subject is a CronJob.
In the following examples, the sink is a Knative Service and the subject is a CronJob.
If you have an existing subject and sink, you can replace the examples with your
own values.
@ -92,7 +92,7 @@ create a Knative service.
```
=== "YAML"
1. Create a YAML file for the Knative service using the template below:
1. Create a YAML file for the Knative service using the following template:
```yaml
apiVersion: serving.knative.dev/v1
@ -134,7 +134,7 @@ use the following sample to create a CronJob object as the subject.
The following CronJob makes a single cloud event that targets `K_SINK` and adds
any extra overrides given by `CE_OVERRIDES`.
1. Create a YAML file for the CronJob using the example below:
1. Create a YAML file for the CronJob using the following example:
```yaml
apiVersion: batch/v1beta1
@ -217,7 +217,7 @@ Create a `SinkBinding` object that directs events from your subject to the sink.
```
=== "YAML"
1. Create a YAML file for the `SinkBinding` object using the template below:
1. Create a YAML file for the `SinkBinding` object using the following template:
```yaml
apiVersion: sources.knative.dev/v1

2
docs/developer/serving/services/README.md
View File

@ -8,7 +8,7 @@ Each time the configuration is updated, a new Revision is created. Revisions are
## Modifying Knative services
Any changes to specifications, metadata labels, or metadata annotations for a Service must be copied to the Route and Configuration owned by that Service. The `serving.knative.dev/service` label on the Route and Configuration must also be set to the name of the Service. Any additional labels or annotations on the Route and Configuration not specified above must be removed.
Any changes to specifications, metadata labels, or metadata annotations for a Service must be copied to the Route and Configuration owned by that Service. The `serving.knative.dev/service` label on the Route and Configuration must also be set to the name of the Service. Any additional labels or annotations on the Route and Configuration not specified earlier must be removed.
The Service updates its `status` fields based on the corresponding `status` value for the owned Route and Configuration.
The Service must include conditions of`RoutesReady` and `ConfigurationsReady` in addition to the generic `Ready` condition. Other conditions can also be present.

2
docs/developer/serving/services/creating-services.md
View File

@ -19,7 +19,7 @@ Create a sample service:
=== "Apply YAML"
1. Create a YAML file using the example below:
1. Create a YAML file using the following example:
```yaml
apiVersion: serving.knative.dev/v1

4
docs/developer/serving/services/custom-domains.md
View File

@ -37,7 +37,7 @@ DomainMappings in that namespace can use the domain name.
map any domain name, even ones in other namespaces or for domain names
that they do not own.
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: networking.internal.knative.dev/v1alpha1
@ -57,7 +57,7 @@ DomainMappings in that namespace can use the domain name.
1. Create a DomainMapping object:
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: serving.knative.dev/v1alpha1

2
docs/developer/serving/traffic-management.md
View File

@ -28,7 +28,7 @@ spec:
When a `tag` attribute is applied to a Route, an address for the specific traffic target is created.
In the above example, you can access the staging target by accessing `staging-<route name>.<namespace>.<domain>`. The targets for `example-service-2` and `example-service-3` can only be accessed using the main route, `<route name>.<namespace>.<domain>`.
In this example, you can access the staging target by accessing `staging-<route name>.<namespace>.<domain>`. The targets for `example-service-2` and `example-service-3` can only be accessed using the main route, `<route name>.<namespace>.<domain>`.
When a traffic target is tagged, a new Kubernetes Service is created for that Service, so that other Services can access it within the cluster. From the previous example, a new Kubernetes Service called `staging-<route name>` will be created in the same namespace. This Service has the ability to override the visibility of this specific Route by applying the label `networking.knative.dev/visibility` with value `cluster-local`. See the documentation on [private services](../../developer/serving/services/private-services) for more information about how to restrict visibility on specific Routes.

2
docs/eventing/accessing-traces.md
View File

@ -109,7 +109,7 @@ For this example, assume the following details:
the Kubernetes Service `logger`.
- An event is sent to the Broker with the type `transformer`, by the Pod named `sender`.
Given the above, the expected path and behavior of an event is as follows:
Given this scenario, the expected path and behavior of an event is as follows:
1. `sender` Pod sends the request to the Broker.
1. Go to the Broker's ingress Pod.

2
docs/eventing/broker/create-mtbroker.md
View File

@ -40,7 +40,7 @@ You can create a broker by using the `kn` CLI or by applying YAML files using `k
The YAML in the following example creates a broker named `default` in the current namespace. For more information about configuring broker options using YAML, see the full [broker configuration example](../example-mtbroker).
1. Create a broker in the current namespace by creating a YAML file using the
template below:
following template:
```yaml
apiVersion: eventing.knative.dev/v1

2
docs/eventing/broker/kafka-broker/README.md
View File

@ -105,7 +105,7 @@ data:
bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"
```
The above `ConfigMap` is installed in the cluster. You can edit
This `ConfigMap` is installed in the cluster. You can edit
the configuration or create a new one with the same values
depending on your needs.

6
docs/eventing/broker/triggers/README.md
View File

@ -18,7 +18,7 @@ The `subscriber` value must be a [Destination](https://pkg.go.dev/knative.dev/pk
The following trigger receives all the events from the `default` broker and
delivers them to the Knative Serving service `my-service`:
1. Create a YAML file using the example below:
1. Create a YAML file using the following example:
```yaml
apiVersion: eventing.knative.dev/v1
@ -45,7 +45,7 @@ delivers them to the Knative Serving service `my-service`:
The following trigger receives all the events from the `default` broker and
delivers them to the custom path `/my-custom-path` for the Kubernetes service `my-service`:
1. Create a YAML file using the example below:
1. Create a YAML file using the following example:
```yaml
apiVersion: eventing.knative.dev/v1
@ -82,7 +82,7 @@ This example filters events from the `default` broker that are of type
`dev.knative.foo.bar` and have the extension `myextension` with the value
`my-extension-value`.
1. Create a YAML file using the example below:
1. Create a YAML file using the following example:
```yaml
apiVersion: eventing.knative.dev/v1

2
docs/eventing/channels/create-default-channel.md
View File

@ -6,7 +6,7 @@ Channel object.
To create a Channel:
1. Create a YAML file for the [Channel object](https://knative.dev/docs/reference/api/eventing/#messaging.knative.dev/v1.Channel)
using the template below:
using the following template:
```yaml
apiVersion: messaging.knative.dev/v1

2
docs/eventing/channels/subscriptions.md
View File

@ -62,7 +62,7 @@ For more information about Subscription objects, see
=== "YAML"
1. Create a YAML file for the Subscription object using the example below:
1. Create a YAML file for the Subscription object using the following example:
```yaml
apiVersion: messaging.knative.dev/v1

2
docs/eventing/debugging/example.yaml
View File

@ -59,7 +59,7 @@ spec:
---
# K8s Service which points at the Deployment below.
# K8s Service which points at the following deployment.
apiVersion: v1
kind: Service

12
docs/eventing/event-registry.md
View File

@ -33,7 +33,7 @@ To see event types in the registry that are available to subscribe to, enter the
kubectl get eventtypes -n <namespace>
```
Below, we show an example output of executing the above command using the
The following example shows the output of executing the `kubectl get eventtypes` command using the
`default` namespace in a testing cluster. We will address the question of how
this registry was populated in a later section.
@ -123,7 +123,7 @@ Now that you know what events can be consumed from the Brokers' event meshes,
you can create Triggers to subscribe to particular events.
Here are a few example Triggers that subscribe to events using exact matching on
`type` and/or `source`, based on the above registry output:
`type` and/or `source`, based on the registry output mentioned earlier:
1. Subscribes to GitHub _pushes_ from any source.
@ -145,7 +145,7 @@ Here are a few example Triggers that subscribe to events using exact matching on
name: push-service
```
As per the registry output above, only two sources exist for that particular
As per the registry output mentioned, only two sources exist for that particular
type of event (_knative's eventing and serving_ repositories). If later on
new sources are registered for GitHub pushes, this trigger will be able to
consume them.
@ -245,8 +245,8 @@ the next topic: How do we actually populate the registry in the first place?
- AwsSqsSource
Let's look at an example, in particular, the KafkaSource sample we used to
populate the registry in our testing cluster. Below is what the yaml looks
like.
populate the registry in our testing cluster. This is what the YAML looks
like:
```yaml
apiVersion: sources.knative.dev/v1beta1
@ -270,7 +270,7 @@ the next topic: How do we actually populate the registry in the first place?
KafkaSource, please refer to the
[KafKaSource sample](../samples/kafka/).
For this discussion, the relevant information from the yaml above are the
For this discussion, the relevant information from the YAML mentioned are the
`sink` and the `topics`. We observe that the `sink` is of kind `Broker`. We
currently only support automatic creation of EventTypes for Sources instances
that point to Brokers. Regarding `topics`, this is what we use to generate the

2
docs/eventing/flows/parallel.md
View File

@ -26,7 +26,7 @@ Parallel has three parts for the Spec:
executed. Both `filter` and `subscriber` must be `Addressable`.
1. the event returned by the `subscriber` is sent to the branch `reply`
object. When the `reply` is empty, the event is sent to the `spec.reply`
object (see below).
object.
1. (optional) `channelTemplate` defines the Template which will be used to
create `Channel`s.
1. (optional) `reply` defines where the result of each branch is sent to when

2
docs/eventing/flows/sequence/README.md
View File

@ -49,7 +49,7 @@ Sequence has four parts for the Status:
## Examples
For each of these examples below, You will use a [`PingSource`](../../sources/ping-source/) as the source of events.
For each of the following examples, you use a [`PingSource`](../../sources/ping-source/) as the source of events.
We also use a very simple [transformer](https://github.com/knative/eventing/blob/main/cmd/appender/main.go) which performs very trivial transformation of the incoming events to demonstrate they have passed through each stage.

12
docs/eventing/flows/sequence/sequence-reply-to-event-display/README.md
View File

@ -32,8 +32,8 @@ If you want to use different type of `Channel`, you will have to modify the
### Create the Knative Services
Change `default` below to create the steps in the Namespace where you want
resources created.
Change `default` in the following command to create the steps in the namespace where you want
resources created:
```yaml
apiVersion: serving.knative.dev/v1
@ -118,8 +118,8 @@ spec:
name: event-display
```
Change `default` below to create the `Sequence` in the Namespace where you want
the resources to be created.
Change `default` in the following command to create the `Sequence` in the namespace where you want
the resources to be created:
```bash
kubectl -n default create -f ./sequence.yaml
@ -139,8 +139,8 @@ spec:
- image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
```
Change `default` below to create the `Sequence` in the Namespace where you want
your resources to be created.
Change `default` in the following command to create the `Sequence` in the namespace where you want
your resources to be created:
```bash
kubectl -n default create -f ./event-display.yaml

12
docs/eventing/flows/sequence/sequence-reply-to-sequence/README.md
View File

@ -33,8 +33,8 @@ If you want to use different type of `Channel`, you will have to modify the
### Create the Knative Services
Change `default` below to create the steps in the Namespace where you want
resources created.
Change `default` in the following command to create the steps in the namespace where you want
resources created:
```yaml
apiVersion: serving.knative.dev/v1
@ -159,8 +159,8 @@ spec:
name: second-sequence
```
Change `default` below to create the `Sequence` in the Namespace where you want
your resources created.
Change `default` in the following command to create the `Sequence` in the namespace where you want
your resources created:
```bash
kubectl -n default create -f ./sequence1.yaml
@ -219,8 +219,8 @@ spec:
- image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
```
Change `default` below to create the `Sequence` in the Namespace where you want
your resources created.
Change `default` in the following command to create the `Sequence` in the namespace where you want
your resources created:
```bash
kubectl -n default create -f ./event-display.yaml

7
docs/eventing/flows/sequence/sequence-terminal/README.md
View File

@ -113,11 +113,8 @@ spec:
name: third
```
Change `default` below to create the `Sequence` in the Namespace where you want
the resources to be created.
Here, if you are using different type of Channel, you need to change the
spec.channelTemplate to point to your desired Channel.
Change `default` in the following command to create the `Sequence` in the namespace where you want
the resources to be created:
```bash
kubectl -n default create -f ./sequence.yaml

22
docs/eventing/flows/sequence/sequence-with-broker-trigger/README.md
View File

@ -34,7 +34,7 @@ The functions used in these examples live in
### Creating the Broker
1. To create the cluster default Broker type, copy the YAML below into a file:
1. To create the cluster default Broker type, copy the following YAML into a file:
```yaml
apiVersion: eventing.knative.dev/v1
@ -98,8 +98,8 @@ spec:
```
Change the `default` namespace below to create the services in the namespace where you have
configured your broker.
Change `default` in the following command to create the services in the namespace where you have
configured your broker:
```bash
kubectl -n default create -f ./steps.yaml
@ -142,8 +142,8 @@ spec:
name: default
```
Change the `default` namespace below to create the sequence in the namespace where you have
configured your broker.
Change `default` in the following command to create the sequence in the namespace where you have
configured your broker:
```bash
kubectl -n default create -f ./sequence.yaml
@ -170,8 +170,8 @@ spec:
name: default
```
Change the `default` namespace below to create the PingSource in the namespace where you have
configured your broker and sequence.
Change `default` in the following command to create the PingSource in the namespace where you have
configured your broker and sequence:
```bash
kubectl -n default create -f ./ping-source.yaml
@ -196,8 +196,8 @@ spec:
name: sequence
```
Change the `default` namespace below to create the trigger in the namespace where you have
configured your broker and sequence.
Change `default` in the following command to create the trigger in the namespace where you have
configured your broker and sequence:
```bash
kubectl -n default create -f ./trigger.yaml
@ -235,8 +235,8 @@ spec:
```
Change `default` namespace below to create the service and trigger in the namespace
where you have configured your broker.
Change `default` in the following command to create the service and trigger in the namespace
where you have configured your broker:
```bash
kubectl -n default create -f ./display-trigger.yaml

18
docs/eventing/getting-started.md
View File

@ -22,7 +22,7 @@ kubectl create namespace event-example
The [broker](../broker) allows you to route events to different event sinks or consumers.
1. Add a broker named `default` to your namespace by creating a YAML file using
the template below:
the following template:
```yaml
apiVersion: eventing.knative.dev/v1
@ -62,7 +62,7 @@ the template below:
In this step, you create two event consumers, `hello-display` and `goodbye-display`, to
demonstrate how you can configure your event producers to target a specific consumer.
1. To deploy the `hello-display` consumer to your cluster, copy the YAML below into a file:
1. To deploy the `hello-display` consumer to your cluster, copy the following YAML into a file:
```yaml
apiVersion: apps/v1
@ -104,7 +104,7 @@ demonstrate how you can configure your event producers to target a specific cons
```
Where `<filename>` is the name of the file you created in the previous step.
1. To deploy the `goodbye-display` consumer to your cluster, copy the YAML below
1. To deploy the `goodbye-display` consumer to your cluster, copy the following YAML
into a file:
```yaml
@ -167,7 +167,7 @@ A [trigger](../broker/triggers) defines the events that each event consumer rece
Brokers use triggers to forward events to the correct consumers.
Each trigger can specify a filter that enables selection of relevant events based on the Cloud Event context attributes.
1. Create a trigger by copying the YAML below into a file:
1. Create a trigger by copying the following YAML into a file:
```yaml
apiVersion: eventing.knative.dev/v1
kind: Trigger
@ -194,7 +194,7 @@ Each trigger can specify a filter that enables selection of relevant events base
```
Where `<filename>` is the name of the file you created in the previous step.
1. To add a second trigger, copy the YAML below into a file:
1. To add a second trigger, copy the following YAML into a file:
```yaml
apiVersion: eventing.knative.dev/v1
kind: Trigger
@ -245,7 +245,7 @@ This guide uses `curl` commands to manually send individual events as HTTP reque
The broker can only be accessed from within the cluster where Knative Eventing is installed. You must create a pod within that cluster to act as an event producer that will execute the `curl` commands.
1. To create a pod, copy the YAML below into a file:
1. To create a pod, copy the following YAML into a file:
```yaml
apiVersion: v1
kind: Pod
@ -304,7 +304,7 @@ The broker can only be accessed from within the cluster where Knative Eventing i
When the broker receives your event, `hello-display` will activate and send
it to the event consumer of the same name.
If the event has been received, you will receive a `202 Accepted` response
similar to the one below:
similar to the following example:
```{ .bash .no-copy }
< HTTP/1.1 202 Accepted
@ -327,7 +327,7 @@ The broker can only be accessed from within the cluster where Knative Eventing i
When the broker receives your event, `goodbye-display` will activate and
send the event to the event consumer of the same name.
If the event has been received, you will receive a `202 Accepted` response
similar to the one below:
similar to the following example:
```
< HTTP/1.1 202 Accepted
< Content-Length: 0
@ -348,7 +348,7 @@ The broker can only be accessed from within the cluster where Knative Eventing i
When the broker receives your event, `hello-display` and `goodbye-display`
will activate and send the event to the event consumers of the same name.
If the event has been received, you will receive a `202 Accepted` response
similar to the one below:
similar to the following example:
```{ .bash .no-copy }
< HTTP/1.1 202 Accepted
< Content-Length: 0

2
docs/eventing/samples/github-source/README.md
View File

@ -127,7 +127,7 @@ kubectl --namespace default apply --filename github-source.yaml
Verify the GitHub webhook was created by looking at the list of
webhooks under the Settings tab in your GitHub repository. A hook
should be listed that points to your Knative cluster with a green
check mark to the left of the hook URL, as shown below.
check mark to the left of the hook URL, as shown in the following image:
![GitHub Webhook](webhook_created.png "GitHub webhook screenshot")

2
docs/eventing/samples/github-source/github-source.yaml
View File

@ -19,5 +19,5 @@ spec:
apiVersion: serving.knative.dev/v1
kind: Service
name: github-message-dumper
# To use GitHub Enterprise you would need to add an entry for your githubAPIURL similar to the example below
# To use GitHub Enterprise you would need to add an entry for your githubAPIURL similar to the following example
# githubAPIURL: "https://github.mycompany.com/api/v3/"

8
docs/eventing/samples/gitlab-source/README.md
View File

@ -53,8 +53,8 @@ We will:
### Create a Knative Service
The `event-display.yaml` file shown below defines the basic service which will
receive events from the GitLab source.
The `event-display.yaml` file defines the basic service which will
receive events from the GitLab source:
```yaml
apiVersion: serving.knative.dev/v1
@ -83,12 +83,12 @@ kubectl -n default apply -f event-display.yaml
webhooks. Also decide on a secret token that your source will use to
authenticate the incoming webhooks from GitLab.
1. Update a secret values in `secret.yaml` defined below:
1. Update the secret values in `secret.yaml` as follows:
`accessToken` is the personal access token created in step 1 and
`secretToken` is any token of your choosing.
Hint: you can generate a random _secretToken_ with:
Tip: you can generate a random _secretToken_ by running the command:
```bash
head -c 8 /dev/urandom | base64

20
docs/eventing/samples/helloworld/helloworld-go/README.md
View File

@ -20,7 +20,7 @@ along with a
However, you can also deploy the app as a
[Knative Serving Service](../../../../serving/).
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -103,8 +103,8 @@ cd knative-docs/docs/eventing/samples/helloworld/helloworld-go
}
```
1. In your project directory, create a file named `Dockerfile` and copy the code
block below into it. For detailed instructions on dockerizing a Go app, see
1. In your project directory, create a file named `Dockerfile` and copy the following code
block into it. For detailed instructions on dockerizing a Go app, see
[Deploying Go servers with Docker](https://blog.golang.org/docker).
```docker
@ -244,13 +244,13 @@ folder) you're ready to build and deploy the sample app.
1. After the build has completed and the container is pushed to docker hub, you
can deploy the sample application into your cluster. Ensure that the
container image value in `sample-app.yaml` matches the container you built in
the previous step. Apply the configuration using `kubectl`:
the previous step. Apply the configuration by running the following command:
```bash
kubectl apply --filename sample-app.yaml
```
1. Above command created a namespace `knative-samples` and create a default Broker it. Verify using the following command:
1. Verify that the command created the namespace `knative-samples` and a default Broker by running the command:
```bash
kubectl get broker --namespace knative-samples
@ -316,8 +316,8 @@ with correct CloudEvent headers set.
### Verify that event is received by helloworld-go app
Helloworld-go app logs the context and the msg of the above event, and replies
back with another event.
The Helloworld-go app logs the context and the msg of the event you created earlier, and replies
with another event.
1. Display helloworld-go app logs
@ -367,7 +367,7 @@ Play around with the CloudEvent attributes in the curl command and the trigger s
`source=knative/eventing/samples/hello-world`. This event enters the eventing
mesh via the Broker and can be delivered to other services using a Trigger
1. Using the example below, create a YAML file for a Pod that receives any
1. Using the following example, create a YAML file for a Pod that receives any
CloudEvent and logs the event to its output:
```yaml
@ -414,8 +414,8 @@ CloudEvent and logs the event to its output:
```
Where `<filename>` is the name of the file you created in the previous step.
1. Using the example below, create a YAML file for a trigger to deliver the event
to the above service:
1. Using the following example, create a YAML file for a trigger to deliver the event
to the `event-display` Service:
```yaml
apiVersion: eventing.knative.dev/v1

2
docs/eventing/samples/helloworld/helloworld-go/helloworld.go
View File

@ -24,7 +24,7 @@ func receive(ctx context.Context, event cloudevents.Event) (*cloudevents.Event,
// The response will go back into the knative eventing system just like any other event
newEvent := cloudevents.NewEvent()
// Setting the ID here is not necessary. When using NewDefaultClient the ID is set
// automatically. We set the ID anyway so it appears in the log below.
// automatically. We set the ID anyway so it appears in the log.
newEvent.SetID(uuid.New().String())
newEvent.SetSource("knative/eventing/samples/hello-world")
newEvent.SetType("dev.knative.samples.hifromknative")

12
docs/eventing/samples/helloworld/helloworld-python/README.md
View File

@ -5,7 +5,7 @@ A simple web app written in Python that you can use to test knative eventing. It
We will deploy the app as a [Kubernetes Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) along with a [Kubernetes Service](https://kubernetes.io/docs/concepts/services-networking/service/).
However, you can also deploy the app as a [Knative Serving Service](../../../../serving/).
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -55,8 +55,8 @@ cd knative-docs/docs/eventing/samples/helloworld/helloworld-python
Flask==1.1.1
```
1. In your project directory, create a file named `Dockerfile` and copy the code
block below into it. For detailed instructions on dockerizing a Go app, see
1. In your project directory, create a file named `Dockerfile` and copy the following code
block into it. For detailed instructions on dockerizing a Go app, see
[Deploying Go servers with Docker](https://blog.golang.org/docker).
```docker
@ -223,7 +223,7 @@ You can send an HTTP request directly to the Knative [broker](../../../broker) i
### Verify that event is received by helloworld-python app
Helloworld-python app logs the context and the msg of the above event, and replies back with another event.
The Helloworld-python app logs the context and the msg of the event you created earlier, and replies with another event.
1. Display helloworld-python app logs
```bash
@ -261,7 +261,7 @@ The `helloworld-python` app replies with an event type `type= dev.knative.sample
1. Deploy a Pod that receives any CloudEvent and logs the event to its output.
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
# event-display app deploment
@ -308,7 +308,7 @@ The `helloworld-python` app replies with an event type `type= dev.knative.sample
1. Create a trigger to deliver the event to the previously created service.
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: eventing.knative.dev/v1

2
docs/eventing/samples/iot-core/README.md
View File

@ -98,7 +98,7 @@ export IOTCORE_TOPIC_DEVICE="iot-demo-device-pubsub-topic"
To install the default Broker:
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: eventing.knative.dev/v1

7
docs/eventing/samples/kafka/binding/README.md
View File

@ -13,7 +13,7 @@ enables easy bootstrapping of a Kafka client.
## Create a Job that uses KafkaBinding
In the below example a Kubernetes Job will be using the KafkaBinding to produce
In the following example a Kubernetes Job will be using the KafkaBinding to produce
messages on a Kafka Topic, which will be received by the Event Display service
via Kafka Source
@ -68,8 +68,7 @@ via Kafka Source
1. (Optional) Deploy the Event Display Service via kn cli:
Alternatively, you can create the knative service using the `kn` cli like
below
Alternatively, you can create the knative service by running the following command in the `kn` CLI.
```
kn service create event-display --image=gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
@ -224,7 +223,7 @@ In this case, we will bind any `Job` with the labels `kafka.topic: "logs"`.
## Connecting to a TLS enabled Kafka broker
The KafkaBinding supports TLS and SASL authentication methods. For injecting TLS
authentication, please have the below files
authentication, you must have the following files:
- CA Certificate
- Client Certificate and Key

2
docs/eventing/samples/parallel/README.md
View File

@ -16,7 +16,7 @@ All examples are using the
## Examples
For each of these examples below, we'll use
Each of the following examples use
[`PingSource`](../../sources/ping-source/) as the source of events.
We also use simple

4
docs/eventing/samples/parallel/multiple-branches/README.md
View File

@ -101,8 +101,8 @@ spec:
- image: gcr.io/knative-releases/knative.dev/eventing/cmd/event_display
```
Change `default` below to create the `Sequence` in the Namespace where you want
your resources to be created.
Change `default` in the following command to create the `Sequence` in the namespace where you want
your resources to be created:
```bash
kubectl -n default create -f ./event-display.yaml

6
docs/eventing/sugar/README.md
View File

@ -27,7 +27,7 @@ kubectl apply --filename {{ artifact( repo="eventing", file="eventing-sugar-cont
One way to create a Broker is to manually apply a resource to a cluster using
the default settings:
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: eventing.knative.dev/v1
@ -55,14 +55,14 @@ use-cases:
controller will create a Broker named by that Trigger in the Trigger's
Namespace.
When a Broker is deleted and the above labels or annotations are in-use, the
When a Broker is deleted and the mentioned labels or annotations are in use, the
Sugar Controller will automatically recreate a default Broker.
### Namespace Examples
Creating a "default" Broker when creating a Namespace:
1. Copy the YAML below into a file:
1. Copy the following YAML into a file:
```yaml
apiVersion: v1

2
docs/getting-started/first-trigger.md
View File

@ -40,7 +40,7 @@ trigger.eventing.knative.dev/cloudevents-player created
??? question "What CloudEvents is my Trigger listening for?"
Because we didn't specify a `--filter` in our `kn` command, the Trigger is listening for any CloudEvents coming into the Broker.
An example on how to use Filters is provided below.
The following example shows how to use Filters.
Now, when we go back to the CloudEvents Player and send an Event, we see that CloudEvents are both sent and received by the CloudEvents Player:

2
docs/getting-started/getting-started-eventing.md
View File

@ -18,4 +18,4 @@ With Knative Serving, we have a powerful tool which can take our containerized c
--8<-- "YouTube_icon.svg"
[Facilitating AI workloads at the edge in large-scale, drone-powered sustainable agriculture projects](https://www.youtube.com/watch?v=lVfJ5WEQ5_s){target=blank}
As you can see by the examples above, Knative Eventing implementations can range from simplistic to extremely complex. For now, you'll start with simplistic and learn about the most basic components of Knative Eventing: Sources, Brokers, Triggers and Sinks.
As you can see by the mentioned examples, Knative Eventing implementations can range from simplistic to extremely complex. For now, you'll start with simplistic and learn about the most basic components of Knative Eventing: Sources, Brokers, Triggers and Sinks.

4
docs/getting-started/next-steps.md
View File

@ -9,7 +9,7 @@ This topic provides a list of resources to help you continue your Knative journe
## :test_tube: Knative samples
Try out some of the Knative samples below:
Try out some of the following Knative samples:
- [Converting a Kubernetes Service to a Knative Service](../../serving/convert-deployment-to-knative-service/)
- [Knative Serving code samples](../../serving/samples/)
@ -17,7 +17,7 @@ Try out some of the Knative samples below:
## :page_with_curl: Explore the Knative docs
Explore the guides below for documentation specific to your role:
See the following guides for documentation specific to your role:
- [Developer Guide](../developer/README.md)
- [Admin Guide](../admin/README.md)

2
docs/help/contributor/code-samples.md
View File

@ -51,7 +51,7 @@ either internal contributor content, or external-facing user content.
[`e2e` tests](https://github.com/knative/docs/tree/main/test).
- **Community owned and maintained samples**: For sample code which doesn't
meet the above criteria, put the code in a separate repository and link to
meet the mentioned criteria, put the code in a separate repository and link to
it [from this page](https://github.com/knative/docs/tree/main/community/samples/README.md).
These samples might not receive regular maintenance. It is possible that a
sample is no longer current and is not actively maintained by its original

2
docs/help/contributor/creating-blog-posts.md
View File

@ -18,7 +18,7 @@ This section covers documentation, processes, and roles for the [Knative blog](h
Anyone can write a blog post and submit it for review. Commercial content is not allowed. Please refer to the [blog guidelines](#blog-guidelines) for more guidance.
To submit a blog post, follow the steps below.
To submit a blog post:
1. [Sign the Contributor License Agreements](https://github.com/knative/community/blob/main/CONTRIBUTING.md#contributor-license-agreements) if you have not yet done so.
1. Familiarize yourself with the Markdown format for existing blog posts in the [docs repository](https://github.com/knative/docs/tree/main/blog). Blog posts are categorized into different directories. You can explore the directories to find examples.

4
docs/help/contributor/mkdocs-contributor-guide.md
View File

@ -115,7 +115,7 @@ and
[https://squidfunk.github.io/mkdocs-material/setup/setting-up-navigation/](https://squidfunk.github.io/mkdocs-material/setup/setting-up-navigation/)
### Content Tabs
Content tabs are handy way to organize lots of information in a visually pleasing way. Some documentation from [https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#usage](https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#usage) is reproduced below.
Content tabs are handy way to organize lots of information in a visually pleasing way. Some documentation from [https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#usage](https://squidfunk.github.io/mkdocs-material/reference/content-tabs/#usage) is reproduced here:
=== "Grouping Code blocks"
Code blocks are one of the primary targets to be grouped, and can be considered a special case of content tabs, as tabs with a single code block are always rendered without horizontal spacing.
Example:
@ -234,7 +234,7 @@ To search a database of Icons and Emojis (all of which can be used on Knative.de
The Knative site uses [mkdocs-redirects](https://github.com/datarobot/mkdocs-redirects) to "redirect" users from a page that may no longer exist (or has been moved) to their desired location.
Adding re-directs to the Knative site is done in one centralized place, `docs/config/redirects.yml`. The format is shown below:
Adding re-directs to the Knative site is done in one centralized place, `docs/config/redirects.yml`. The format is shown here:
```
plugins:

7
docs/help/contributor/style-guide/documenting-code.md
View File

@ -17,7 +17,7 @@ Apply code formatting only to special-purpose text:
> Specify the language your code is in as part of the code block
> Specify non-language specific code, like CLI commands, with ```bash (see below for formatting).
> Specify non-language specific code, like CLI commands, with ```bash. See the following examples for formatting.
=== ":white_check_mark: Correct"
```go
@ -77,7 +77,7 @@ Apply code formatting only to special-purpose text:
* It describes what the command does before stating the command.
* It's as short as possible
> If you must deviate from the standard line, ensure you still meet the above criteria.
> If you must deviate from the standard line, ensure you still meet these criteria.
=== ":white_check_mark: Correct"
Create the service by running the command:
@ -105,7 +105,7 @@ Apply code formatting only to special-purpose text:
**Example 3:**
Run the command below to create a service:
Run the following command to create a service:
```bash
kn create service <service-name>
@ -171,7 +171,6 @@ Apply code formatting only to special-purpose text:
- Hyphens between words
- Explanation for each variable below code block
- Explanation format is “Where... `<service-name>` is…"
- If there are multiple variables, see below.
### Single variable
=== ":white_check_mark: Correct"

4
docs/help/contributor/templates/template-concept.md
View File

@ -6,7 +6,7 @@ They provide helpful context to readers. They do not include procedures.
## Template
The template below includes the standard sections that should appear in conceptual topics, including a topic introduction sentence, an overview, and placeholders for additional sections and subsections.
The following template includes the standard sections that should appear in conceptual topics, including a topic introduction sentence, an overview, and placeholders for additional sections and subsections.
Copy and paste the markdown from the template to use it in your topic.
```
@ -41,7 +41,7 @@ Copy and paste the markdown to use it in your topic.
### Table
Introduce the table with a sentence. For example, “The table below details which operations must be made available to a developer accessing a Knative Route using a minimal profile.”
Introduce the table with a sentence. For example, “The following table lists which operations must be made available to a developer accessing a Knative Route using a minimal profile.”
#### Markdown Table Template

13
docs/help/contributor/templates/template-procedure.md
View File

@ -6,7 +6,7 @@ to perform a task as well as some context about the task.
## Template
The template below includes the standard sections that should appear in procedural topics, including
The following template includes the standard sections that should appear in procedural topics, including
a topic sentence, an overview section, and sections for each task within the procedure.
Copy and paste the markdown from the template to use it in your topic.
@ -39,7 +39,7 @@ To [task]:
## Prerequisites
Use one of the formats described below for the Prerequisites section.
Use one of the following formats for the Prerequisites section.
### Formatting for two or more prerequisites
@ -110,8 +110,9 @@ Copy and paste the markdown to use it in your topic.
### “Fill-in-the-Fields” Table
Where the reader must enter many values in, say, a YAML file, use a table within the procedure as
below:
Where the reader must enter many values in, for example, a YAML file, use a table within the
procedure as follows:
Open the YAML file.
```yaml
@ -129,7 +130,7 @@ spec:
Key6: Value6
```
Change the relevant values to your needs, using the table below as a guide.
Change the relevant values to your needs, using the following table as a guide.
| Key | Value Type | Description |
|-------|----------------|--------------|
@ -143,7 +144,7 @@ Change the relevant values to your needs, using the table below as a guide.
### Table
Introduce the table with a sentence. For example, “The table below details which operations must be
Introduce the table with a sentence. For example, “The following table lists which operations must be
made available to a developer accessing a Knative Route using a minimal profile.”

2
docs/serving/autoscaling/autoscale-go/README.md
View File

@ -156,7 +156,7 @@ The autoscaler supports customization through annotations. There are two
autoscaler classes built into Knative:
1. `kpa.autoscaling.knative.dev` which is the concurrency-based autoscaler
described above (the default), and
described earlier (the default), and
2. `hpa.autoscaling.knative.dev` which delegates to the Kubernetes HPA which
autoscales on CPU usage.

2
docs/serving/autoscaling/autoscaler-types.md
View File

@ -1,6 +1,6 @@
# Supported Autoscaler types
Knative Serving supports the implementation of Knative Pod Autoscaler (KPA) and Kubernetes' Horizontal Pod Autoscaler (HPA). The features and limitations of each of these Autoscalers are listed below.
Knative Serving supports the implementation of Knative Pod Autoscaler (KPA) and Kubernetes' Horizontal Pod Autoscaler (HPA). This topic lists the features and limitations of each of these Autoscalers, as well as how to configure them.
!!! important
If you want to use Kubernetes Horizontal Pod Autoscaler (HPA), you must install it after you install Knative Serving.

2
docs/serving/getting-started-knative-app.md
View File

@ -168,7 +168,7 @@ To see if your app has been deployed successfully, you need the URL created by K
> configuring DNS (e.g. with `sslip.io`), or [using a Custom Domain](../serving/using-a-custom-domain).
If you changed the name from `helloworld-go` to something else when creating
the `.yaml` file, replace `helloworld-go` in the above commands with the name you entered.
the `.yaml` file, replace `helloworld-go` in these commands with the name you entered.
1. Now you can make a request to your app and see the results. Replace
the URL with the one returned by the command in the previous step.

4
docs/serving/istio-authorization.md
View File

@ -72,7 +72,7 @@ spec:
Requests here will fail when forwarded by the activator, because the Istio proxy at the destination service will see the source namespace of the requests as `knative-serving`, which is the namespace of the activator.
Currently, the easiest way around this is to explicitly allow requests from the `knative-serving` namespace, for example by adding it to the list in the above policy:
Currently, the easiest way around this is to explicitly allow requests from the `knative-serving` namespace, for example by adding it to the list in the policy mentioned earlier:
```yaml
apiVersion: security.istio.io/v1beta1
@ -104,7 +104,7 @@ The `/healthz` path allows system pods to probe the service.
To add the `/metrics` and `/healthz` paths to the AuthorizationPolicy:
1. Create a YAML file for your AuthorizationPolicy using the example below:
1. Create a YAML file for your AuthorizationPolicy using the following example:
```yaml
apiVersion: security.istio.io/v1beta1

8
docs/serving/samples/cloudevents/cloudevents-dotnet/README.md
View File

@ -22,7 +22,7 @@ can use for testing. It supports running in two modes:
The application will use `$K_SINK`-mode whenever the environment variable is
specified.
Follow the steps below to create the sample code and then deploy the app to your
Do the following the steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -65,7 +65,7 @@ cd knative-docs/docs/serving/samples/cloudevents/cloudevents-dotnet
docker push <image>
```
1. If you look in `service.yaml`, take the `<image>` name above and insert it
1. If you look in `service.yaml`, take the `<image>` name and insert it
into the `image:` field.
```bash
@ -92,9 +92,11 @@ $ curl -X POST \
-H "ce-type: curl.demo" \
-H "ce-id: 123-abc" \
-d '{"name":"Dave"}' \
<URL from kubectl command above>
<service-URL>
```
Where `<service-URL>` is the URL from the `kubectl get ksvc` command.
You will get back:
```json

8
docs/serving/samples/cloudevents/cloudevents-go/README.md
View File

@ -22,7 +22,7 @@ can use for testing. It supports running in two modes:
The application will use `$K_SINK`-mode whenever the environment variable is
specified.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -58,7 +58,7 @@ cd knative-docs/docs/serving/samples/cloudevents/cloudevents-go
1. Choose how you would like to build the application:
=== "Dockerfile"
If you look in `Dockerfile`, you will see a method for pulling in the
@ -87,10 +87,10 @@ cd knative-docs/docs/serving/samples/cloudevents/cloudevents-go
1. Choose how you would like to deploy the application:
=== "yaml (with Dockerfile)"
If you look in `service.yaml`, take the `<image>` name above and insert it
If you look in `service.yaml`, take the `<image>` name you used earlier and insert it
into the `image:` field, then run:
```bash

2
docs/serving/samples/cloudevents/cloudevents-nodejs/README.md
View File

@ -22,7 +22,7 @@ can use for testing. It supports running in two modes:
The application will use `$K_SINK`-mode whenever the environment variable is
specified.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:

2
docs/serving/samples/cloudevents/cloudevents-rust/README.md
View File

@ -24,7 +24,7 @@ that can receive CloudEvents. It supports running in two modes:
The application will use `$K_SINK`-mode whenever the environment variable is
specified.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample by running the
following commands:

2
docs/serving/samples/cloudevents/cloudevents-spring/README.md
View File

@ -24,7 +24,7 @@ supports running in two modes:
The application will use `$K_SINK`-mode whenever the environment variable is
specified.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:

2
docs/serving/samples/cloudevents/cloudevents-vertx/README.md
View File

@ -24,7 +24,7 @@ supports running in two modes:
The application will use `$K_SINK`-mode whenever the environment variable is
specified.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:

8
docs/serving/samples/hello-world/helloworld-csharp/README.md
View File

@ -11,7 +11,7 @@ A simple web app written in C# using .NET Core 3.1 that you can use for testing.
It reads in an env variable `TARGET` and prints "Hello \${TARGET}!". If TARGET
is not specified, it will use "World" as the TARGET.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -76,8 +76,8 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-csharp
});
```
1. In your project directory, create a file named `Dockerfile` and copy the code
block below into it. For detailed instructions on dockerizing an ASP.NET Core
1. In your project directory, create a file named `Dockerfile` and copy the following code
block into it. For detailed instructions on dockerizing an ASP.NET Core
app, see
[Docker images for ASP.NET Core](https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/docker/building-net-docker-images).
@ -179,7 +179,7 @@ folder) you're ready to build and deploy the sample app.
```
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
```bash
curl http://helloworld-csharp.default.1.2.3.4.sslip.io

2
docs/serving/samples/hello-world/helloworld-go/README.md
View File

@ -211,7 +211,7 @@ You will need:
## Verifying
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
```bash
curl http://helloworld-go.default.1.2.3.4.sslip.io

6
docs/serving/samples/hello-world/helloworld-java-spark/README.md
View File

@ -39,8 +39,8 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-java
Go to `http://localhost:8080/` to see your `Hello World!` message.
1. In your project directory, create a file named `Dockerfile` and copy the code
block below into it. For detailed instructions on dockerizing a Spark Java
1. In your project directory, create a file named `Dockerfile` and copy the following code
block into it. For detailed instructions on dockerizing a Spark Java
app, see [Spark with Docker](http://sparkjava.com/tutorials/docker). For
additional information on multi-stage docker builds for Java see
[Creating Smaller Java Image using Docker Multi-stage Build](https://github.com/arun-gupta/docker-java-multistage). Navigate to your project directory and copy the following code into a new file named `Dockerfile`:
@ -165,7 +165,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-java
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
Example:

4
docs/serving/samples/hello-world/helloworld-java-spring/README.md
View File

@ -79,7 +79,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-java-spring
Go to `http://localhost:8080/` to see your `Hello World!` message.
1. In your project directory, create a file named `Dockerfile` and copy the code block below into it:
1. In your project directory, create a file named `Dockerfile` and copy the following code block into it:
```docker
# Use the official maven/Java 8 image to create a build artifact: https://hub.docker.com/_/maven
@ -213,7 +213,7 @@ After the build has completed and the container is pushed to Docker Hub, you can
1. Make a request to your app and observe the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
Example:

8
docs/serving/samples/hello-world/helloworld-kotlin/README.md
View File

@ -11,7 +11,7 @@ A simple web app written in Kotlin using [Ktor](https://ktor.io/) that you can
use for testing. It reads in an env variable `TARGET` and prints "Hello
\${TARGET}". If TARGET is not specified, it will use "World" as the TARGET.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -38,7 +38,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-kotlin
```
2. Create a file named `Main.kt` at `src/main/kotlin/com/example/hello` and copy
the code block below into it:
the following code block into it:
```bash
mkdir -p src/main/kotlin/com/example/hello
@ -95,7 +95,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-kotlin
}
```
5. Create a file named `Dockerfile` and copy the code block below into it.
5. Create a file named `Dockerfile` and copy the following code block into it.
```docker
# Use the official gradle image to create a build artifact.
@ -184,7 +184,7 @@ folder) you're ready to build and deploy the sample app.
```
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
```bash
curl http://helloworld-kotlin.default.1.2.3.4.sslip.io

8
docs/serving/samples/hello-world/helloworld-nodejs/README.md
View File

@ -11,7 +11,7 @@ A simple web app written in Node.js that you can use for testing. It reads in an
env variable `TARGET` and prints "Hello \${TARGET}!". If TARGET is not
specified, it will use "World" as the TARGET.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -91,8 +91,8 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-nodejs
}
```
1. In your project directory, create a file named `Dockerfile` and copy the code
block below into it. For detailed instructions on dockerizing a Node.js app,
1. In your project directory, create a file named `Dockerfile` and copy the following code
block into it. For detailed instructions on dockerizing a Node.js app,
see
[Dockerizing a Node.js web app](https://nodejs.org/en/docs/guides/nodejs-docker-webapp/).
@ -191,7 +191,7 @@ folder) you're ready to build and deploy the sample app.
```
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
```bash
curl http://helloworld-nodejs.default.1.2.3.4.sslip.io

8
docs/serving/samples/hello-world/helloworld-php/README.md
View File

@ -11,7 +11,7 @@ A simple web app written in PHP that you can use for testing. It reads in an env
variable `TARGET` and prints `Hello ${TARGET}!`. If `TARGET` is not specified,
it will use `World` as the `TARGET`.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -37,7 +37,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-php
cd app
```
1. Create a file named `index.php` and copy the code block below into it:
1. Create a file named `index.php` and copy the following code block into it:
```php
<?php
@ -46,7 +46,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-php
?>
```
1. Create a file named `Dockerfile` and copy the code block below into it. See
1. Create a file named `Dockerfile` and copy the following code block into it. See
[official PHP docker image](https://hub.docker.com/_/php/) for more details.
```docker
@ -190,7 +190,7 @@ folder) you're ready to build and deploy the sample app.
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
```bash
curl http://helloworld-php.default.1.2.3.4.sslip.io

10
docs/serving/samples/hello-world/helloworld-python/README.md
View File

@ -42,7 +42,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-python
cd app
```
1. Create a file named `app.py` and copy the code block below into it:
1. Create a file named `app.py` and copy the following code block into it:
```python
import os
@ -61,8 +61,8 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-python
```
1. In your project directory, create a file named `Dockerfile` and copy the code
block below into it. See
1. In your project directory, create a file named `Dockerfile` and copy the following code
block into it. See
[official Python docker image](https://hub.docker.com/_/python/) for more
details.
@ -205,8 +205,8 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-python
1. Now you can make a request to your app and see the result. Replace the URL
below with the URL returned in the previous command.
1. Now you can make a request to your app and see the result. Replace the following URL
with the URL returned in the previous command.
Example:

8
docs/serving/samples/hello-world/helloworld-ruby/README.md
View File

@ -37,7 +37,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-ruby
cd app
```
1. Create a file named `app.rb` and copy the code block below into it:
1. Create a file named `app.rb` and copy the following code block into it:
```ruby
require 'sinatra'
@ -50,7 +50,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-ruby
end
```
1. Create a file named `Dockerfile` and copy the code block below into it. See
1. Create a file named `Dockerfile` and copy the following code block into it. See
[official Ruby docker image](https://hub.docker.com/_/ruby/) for more
details.
@ -72,7 +72,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-ruby
CMD ["ruby", "./app.rb"]
```
1. Create a file named `Gemfile` and copy the text block below into it.
1. Create a file named `Gemfile` and copy the following text block into it.
```gem
source 'https://rubygems.org'
@ -217,7 +217,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-ruby
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
Example:

2
docs/serving/samples/hello-world/helloworld-scala/README.md
View File

@ -13,7 +13,7 @@ Serving when using [Scala](https://scala-lang.org/) and [Akka](https://akka.io/)
request with a text specified as an `ENV` variable named `MESSAGE`, defaulting
to `"Hello World!"`.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:

6
docs/serving/samples/hello-world/helloworld-shell/README.md
View File

@ -31,7 +31,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-shell
## Building
1. Create a new file named `script.sh` and paste the script below. This will run BusyBox' `http` returning a friendly welcome message as `plain/text` plus some extra information:
1. Create a new file named `script.sh` and paste the following script. This will run BusyBox' `http` returning a friendly welcome message as `plain/text` plus some extra information:
```bash
#!/bin/sh
@ -48,7 +48,7 @@ cd knative-docs/docs/serving/samples/hello-world/helloworld-shell
# Like printing the date, checking CGI environment variables, ...
```
1. Create a new file named `Dockerfile` and copy the code block below into it.
1. Create a new file named `Dockerfile` and copy the following code block into it.
```docker
# Busybox image that contains the simple 'httpd'
@ -194,7 +194,7 @@ folder) you're ready to build and deploy the sample app.
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
Example:

3
docs/serving/samples/knative-routing-go/README.md
View File

@ -268,7 +268,7 @@ The Gateway proxy checks the updated host, and forwards it to `Search` or
## Using internal services and `"httpProtocol": "Redirected"`
Using the above approach, services will be available using two entrypoints into the cluster:
Using the approach explained in the previous section, services will be available using two entrypoints into the cluster:
The original ones provided by Knative Serving (`search-service.default.example.com` and `login-service.default.example.com`),
as well as the additional entrypoints `example.com/search` and `example.com/login`
provided by the manually added VirtualService (`entry-route`).
@ -309,4 +309,3 @@ To clean up the sample resources:
kubectl delete --filename docs/serving/samples/knative-routing-go/sample.yaml
kubectl delete --filename docs/serving/samples/knative-routing-go/routing.yaml
```

8
docs/serving/samples/multi-container/README.md
View File

@ -103,7 +103,7 @@ You can do this by copying the following code into the `servingcontainer.go` fil
```text
cd -
cd knative-docs/docs/serving/samples/multi-container/sidecarcontainer
```
```
1. Create a basic web server which listens on port 8882.
You can do this by copying the following code into the `sidecarcontainer.go` file:
@ -183,12 +183,12 @@ You can do this by copying the following code into the `sidecarcontainer.go` fil
1. Use Go tool to create a
[`go.mod`](https://github.com/golang/go/wiki/Modules#gomod) manifest:
servingcontainer
```bash
cd -
cd knative-docs/docs/serving/samples/multi-container/servingcontainer
go mod init github.com/knative/docs/docs/serving/samples/multi-container/servingcontainer
go mod init github.com/knative/docs/docs/serving/samples/multi-container/servingcontainer
```
sidecarcontainer
```bash
@ -250,7 +250,7 @@ After you have modified the sample code files you can build and deploy the sampl
```
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
```bash
curl http://multi-container.default.1.2.3.4.sslip.io

4
docs/serving/samples/rest-api-go/README.md
View File

@ -77,7 +77,7 @@ To build and push to a container registry using Docker:
```
1. Substitute the image reference path in the template with our published image
path. The command below substitutes using the \${REPO} variable into a new
path. The following command substitutes using the \${REPO} variable into a new
file called `docs/serving/samples/rest-api-go/sample.yaml`.
```bash
@ -94,7 +94,7 @@ Knative Serving sample:
kubectl apply --filename docs/serving/samples/rest-api-go/sample.yaml
```
The above command creates a Knative Service within your Kubernetes cluster in
This command creates a Knative Service within your Kubernetes cluster in
the default namespace.
## Explore the Service

8
docs/serving/samples/secrets-go/README.md
View File

@ -12,7 +12,7 @@ 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
into a container as a Volume.
Follow the steps below to create the sample code and then deploy the app to your
Do the following steps to create the sample code and then deploy the app to your
cluster. You can also download a working copy of the sample, by running the
following commands:
@ -93,8 +93,8 @@ cd knative-docs/docs/serving/samples/secrets-go
}
```
1. In your project directory, create a file named `Dockerfile` and copy the code
block below into it. For detailed instructions on dockerizing a Go app, see
1. In your project directory, create a file named `Dockerfile` and copy the following code
block into it. For detailed instructions on dockerizing a Go app, see
[Deploying Go servers with Docker](https://blog.golang.org/docker).
```docker
@ -243,7 +243,7 @@ folder) you're ready to build and deploy the sample app.
```
1. Now you can make a request to your app and see the result. Replace
the URL below with the URL returned in the previous command.
the following URL with the URL returned in the previous command.
```bash
curl http://secrets-go.default.1.2.3.4.sslip.io

2
docs/serving/samples/tag-header-based-routing/README.md
View File

@ -19,7 +19,7 @@ Currently Istio, Contour and Kourier ingress support this feature.
## Prerequestie
1. A Knative cluster that has an ingress controller installed
with Knative version 0.16 and above.
with Knative v0.16 and later.
1. Move into the docs directory:

6
docs/serving/setting-up-custom-ingress-gateway.md
View File

@ -49,7 +49,7 @@ Replace the label selector with the label of your service:
istio: ingressgateway
```
For the service above, it should be updated to:
For the example `custom-ingressgateway` service mentioned earlier, it should be updated to:
```
istio: custom-gateway
@ -84,7 +84,7 @@ namespace:
1. Edit the file to add the `gateway.knative-serving.knative-ingress-gateway: <ingress_name>.<ingress_namespace>.svc.cluster.local` field with
the fully qualified url of your service.
For the service above, it should be updated to:
For the example `custom-ingressgateway` service mentioned earlier, it should be updated to:
```yaml
apiVersion: v1
@ -154,7 +154,7 @@ namespace:
1. Edit the file to add the `gateway.<gateway-namespace>.<gateway-name>: istio-ingressgateway.istio-system.svc.cluster.local` field with
the customized gateway.
For the gateway above, it should be updated to:
For the example `knative-custom-gateway` mentioned earlier, it should be updated to:
```yaml
apiVersion: v1

2
docs/serving/using-a-custom-domain.md
View File

@ -45,7 +45,7 @@ To change the {default-domain} value there are a few steps involved:
You can also apply an updated domain configuration:
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: v1

16
docs/serving/using-a-tls-cert.md
View File

@ -25,7 +25,7 @@ cert-manager tool:
- **Manually obtain and renew certificates**: Both the Certbot and cert-manager
tools can be used to manually obtain TLS certificates. In general, after you
obtain a certificate, you must create a Kubernetes secret to use that
certificate in your cluster. See the complete set of steps below for details
certificate in your cluster. See the procedures later in this topic for details
about manually obtaining and configuring certificates.
- **Enable Knative to automatically obtain and renew TLS certificates**: You can
@ -80,7 +80,7 @@ tools to obtain a certificate from Let's Encrypt:
- Setup cert-manager to either manually obtain a certificate, or to
automatically provision certificates
This page covers details for both of the above options.
This page covers details for both options.
For details about using other CA's, see the tool's reference documentation:
@ -133,7 +133,7 @@ provisioning:
1. [Install and configure cert-manager](installing-cert-manager.md).
1. Continue to the steps below about
1. Continue to the steps about
[manually adding a TLS certificate](#manually-adding-a-tls-certificate) by
creating and using a Kubernetes secret.
@ -150,7 +150,7 @@ following steps to add that certificate to your Knative cluster.
For instructions about enabling Knative for automatic certificate provisioning,
see [Enabling automatic TLS cert provisioning](using-auto-tls.md). Otherwise,
continue below for instructions about manually adding a certificate.
follow the steps in the relevant tab to manually add a certificate:
=== "Contour"
@ -171,7 +171,7 @@ continue below for instructions about manually adding a certificate.
Take note of the namespace and secret name. You will need these in future steps.
1. To use this certificate and private key in different namespaces, you must
create a delegation. To do so, create a YAML file using the template below:
create a delegation. To do so, create a YAML file using the following template:
```yaml
apiVersion: projectcontour.io/v1
@ -238,8 +238,8 @@ continue below for instructions about manually adding a certificate.
Example:
```yaml
# Please edit the object below. Lines beginning with a '#' will be ignored.
# and an empty file will abort the edit. If an error occurs while saving this
# Edit the following object. Lines beginning with a '#' will be ignored.
# An empty file will abort the edit. If an error occurs while saving this
# file will be reopened with the relevant failures.
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
@ -265,7 +265,7 @@ continue below for instructions about manually adding a certificate.
mode: SIMPLE
credentialName: tls-cert
```
In the example above, `TLS_HOSTS` represents the hosts of your TLS certificate. It can be a single host, multiple hosts, or a wildcard host.
In this example, `TLS_HOSTS` represents the hosts of your TLS certificate. It can be a single host, multiple hosts, or a wildcard host.
For detailed instructions, please refer [Istio documentation](https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/)

2
docs/serving/using-auto-tls.md
View File

@ -90,7 +90,7 @@ and which DNS provider validates those requests.
To apply the ClusterIssuer for HTTP01 challenge:
1. Create a YAML file using the template below:
1. Create a YAML file using the following template:
```yaml
apiVersion: cert-manager.io/v1

5
docs/smoketest.md
View File

@ -3,7 +3,7 @@
Use this page to test your changes and ensure that there are not any issues,
unwanted behaviors, or regression that are caused by your changes.
Below are a set of site elements that have causes issues in the past.
This is a set of site elements that have causes issues in the past:
## Lists
@ -84,6 +84,3 @@ How to include tabbed content in your page. Note that you can set a default tab.
{{< tab name="Include example" >}}
{{% readfile file="./serving/samples/multi-container/service.yaml" code="true" lang="yaml" %}}

2
docs/snippets/dns.md
View File

@ -2,7 +2,7 @@
You can configure DNS to prevent the need to run curl commands with a host header.
The tabs below expand to show instructions for configuring DNS.
The following tabs expand to show instructions for configuring DNS.
Follow the procedure for the DNS of your choice:
=== "Magic DNS (sslip.io)"

4
docs/snippets/temporary-dns.md
View File

@ -16,9 +16,9 @@
```
1. Instruct `curl` to connect to the External IP or CNAME defined by the
networking layer in section 3 above, and use the `-H "Host:"` command-line
networking layer mentioned in section 3, and use the `-H "Host:"` command-line
option to specify the Knative application's host name.
For example, if the networking layer defines your External IP and port to be `http://192.168.39.228:32198` and you wish to access the above `helloworld-go` application, use:
For example, if the networking layer defines your External IP and port to be `http://192.168.39.228:32198` and you wish to access the `helloworld-go` application mentioned earlier, use:
```bash
curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
```