mirror of https://github.com/knative/docs.git
Changed HTML links to Markdown (#4173)
* Changed HTML links to Markdown * Change HTML image links to Markdown * Fix image links
This commit is contained in:
parent
6e784253cb
commit
001cd9bd29
|
@ -6,7 +6,7 @@ The following CLI tools are supported for use with Knative.
|
|||
|
||||
You can use `kubectl` to apply the YAML files required to install Knative components, and also to create Knative resources, such as services and event sources using YAML.
|
||||
|
||||
See <a href="https://kubernetes.io/docs/tasks/tools/install-kubectl/" target="_blank">Install and Set Up `kubectl`</a>.
|
||||
See [Install and Set Up `kubectl`](https://kubernetes.io/docs/tasks/tools/install-kubectl/){target=_blank}.
|
||||
|
||||
## kn
|
||||
|
||||
|
@ -34,14 +34,16 @@ You can also specify a config file in the following ways:
|
|||
|
||||
- Using the `kn` CLI `--config` option, for example, `kn service list --config path/to/config.yaml`. The default config is at `~/.config/kn/config.yaml`.
|
||||
|
||||
For more information about `kubeconfig` files, see <a href="https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/" target="_blank">Organizing Cluster Access Using kubeconfig Files</a>.
|
||||
For more information about `kubeconfig` files, see
|
||||
[Organizing Cluster Access Using kubeconfig Files](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/){target=_blank}.
|
||||
|
||||
### Using kubeconfig files with your platform
|
||||
|
||||
Instructions for using `kubeconfig` files are available for the following platforms:
|
||||
|
||||
- <a href="https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html" target="_blank">Amazon EKS</a>
|
||||
- <a href="https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl" target="_blank">Google GKE</a>
|
||||
- <a href="https://cloud.ibm.com/docs/containers?topic=containers-getting-started" target="_blank">IBM IKS</a>
|
||||
- <a href="https://docs.openshift.com/container-platform/4.6/cli_reference/openshift_cli/administrator-cli-commands.html#create-kubeconfig" target="_blank">Red Hat OpenShift Cloud Platform</a>
|
||||
- Starting <a href="https://minikube.sigs.k8s.io/docs/start/" target="_blank">minikube</a> writes this file automatically, or provides an appropriate context in an existing configuration file.
|
||||
- [Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/create-kubeconfig.html){target=_blank}
|
||||
- [Google GKE](https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl){target=_blank}
|
||||
- [IBM IKS](https://cloud.ibm.com/docs/containers?topic=containers-getting-started){target=_blank}
|
||||
- [Red Hat OpenShift Cloud Platform](https://docs.openshift.com/container-platform/4.6/cli_reference/openshift_cli/administrator-cli-commands.html#create-kubeconfig){target=_blank}
|
||||
- Starting [minikube](https://minikube.sigs.k8s.io/docs/start/){target=_blank} writes this file
|
||||
automatically, or provides an appropriate context in an existing configuration file.
|
||||
|
|
|
@ -13,10 +13,10 @@ Nightly-built executable binaries are available for users who want to install th
|
|||
|
||||
Links to the latest nightly-built executable binaries are available here:
|
||||
|
||||
- <a href="https://storage.googleapis.com/knative-nightly/client/latest/kn-darwin-amd64" target="_blank">macOS</a>
|
||||
- <a href="https://storage.googleapis.com/knative-nightly/client/latest/kn-linux-amd64" target="_blank">Linux</a>
|
||||
- <a href="https://storage.googleapis.com/knative-nightly/client/latest/kn-windows-amd64.exe" target="_blank">Windows</a>
|
||||
- [macOS](https://storage.googleapis.com/knative-nightly/client/latest/kn-darwin-amd64){target=_blank}
|
||||
- [Linux](https://storage.googleapis.com/knative-nightly/client/latest/kn-linux-amd64){target=_blank}
|
||||
- [Windows](https://storage.googleapis.com/knative-nightly/client/latest/kn-windows-amd64.exe){target=_blank}
|
||||
|
||||
## Using kn with Tekton
|
||||
|
||||
See the <a href="http://hub.tekton.dev/tekton/task/kn" target="_blank">Tekton documentation</a>.
|
||||
See the [Tekton documentation](http://hub.tekton.dev/tekton/task/kn){target=_blank}.
|
||||
|
|
|
@ -6,7 +6,7 @@ Event delivery mechanics are an implementation detail that depend on the configu
|
|||
[broker class](../../admin/eventing/broker-configuration.md#broker-class-options).
|
||||
Using brokers and triggers abstracts the details of event routing from the event producer and event consumer.
|
||||
|
||||
<img src="images/broker-workflow.svg" width="70%">
|
||||

|
||||
|
||||
After an event has entered a broker, it can be forwarded to subscribers by using triggers. Triggers allow events to be filtered by attributes, so that events with particular attributes can be sent to subscribers that have registered interest in events with those attributes.
|
||||
|
||||
|
|
|
@ -4,7 +4,7 @@ Channels are Kubernetes [custom resources](https://kubernetes.io/docs/concepts/e
|
|||
|
||||
A channel provides an event delivery mechanism that can fan-out received events, through subscriptions, to multiple destinations, or sinks. Examples of sinks include brokers and Knative services.
|
||||
|
||||
<img src="images/channel-workflow.png" width="80%">
|
||||

|
||||
|
||||
## Next steps
|
||||
|
||||
|
|
|
@ -2,12 +2,21 @@
|
|||
**Remember those super powers :rocket: we talked about?** One of Knative Serving's powers is built-in automatic scaling (autoscaling). This means your Knative Service only spins up your application to perform its job -- in this case, saying "Hello world!" -- if it is needed; otherwise, it will "scale to zero" by spinning down and waiting for a new request to come in.
|
||||
|
||||
??? question "What about scaling up to meet increased demand?"
|
||||
Knative Autoscaling also allows you to easily configure your service to scale up (horizontal autoscaling) to meet increased demand as well as control the number of instances that spin up using <a href= "../../serving/autoscaling/concurrency/" target="_blank"> "concurrency limits and other options,"</a> but that's beyond the scope of this tutorial.
|
||||
Knative Autoscaling also allows you to easily configure your service to scale up
|
||||
(horizontal autoscaling) to meet increased demand as well as control the number of instances that
|
||||
spin up using
|
||||
[concurrency limits and other options](../../serving/autoscaling/concurrency/){target=_blank},
|
||||
but that's beyond the scope of this tutorial.
|
||||
|
||||
**Let's see this in action!** We're going to peek under the hood at the <a href= "https://kubernetes.io/docs/concepts/workloads/pods/" target="blank_">Pod</a> in Kubernetes where our Knative Service is running to watch our "Hello world!" Service scale up and down.
|
||||
**Let's see this in action!** We're going to peek under the hood at the
|
||||
[Pod](https://kubernetes.io/docs/concepts/workloads/pods/){target=blank_} in Kubernetes where our
|
||||
Knative Service is running to watch our "Hello world!" Service scale up and down.
|
||||
|
||||
### Run your Knative Service
|
||||
Let's run our "Hello world!" Service just one more time. This time, try the Knative Service `URL` in your browser [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank}, or you can use your terminal with `curl`.
|
||||
Let's run our "Hello world!" Service just one more time. This time, try the Knative Service `URL` in
|
||||
your browser
|
||||
[http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank}, or you
|
||||
can use your terminal with `curl`.
|
||||
```bash
|
||||
curl http://hello.default.127.0.0.1.nip.io
|
||||
```
|
||||
|
|
|
@ -2,10 +2,8 @@
|
|||
For the purposes of this tutorial, let's keep it simple. You will focus on four powerful Eventing components: Source, Trigger, Broker, and Sink.
|
||||
|
||||
Let's take a look at how these components interact:
|
||||
<figure>
|
||||
<img src="https://user-images.githubusercontent.com/16281246/116248768-1fe56080-a73a-11eb-9a85-8bdccb82d16c.png" draggable="false">
|
||||
<figcaption> Source 1 and Source 2 are transmitting some data (1's and 2's) to the Broker, which then gets filtered by Triggers to the desired Sink.</figcaption>
|
||||
</figure>
|
||||
|
||||
{draggable=false}
|
||||
|
||||
| Component | Basic Definition |
|
||||
| :---------: | :----------------------------------: |
|
||||
|
@ -18,14 +16,16 @@ Let's take a look at how these components interact:
|
|||
A Knative Service can act as both a Source and a Sink for events, and for good reason. You may want to consume events from the Broker and send modified events back to the Broker, as you would in any pipeline use-case.
|
||||
|
||||
### CloudEvents
|
||||
Knative Eventing uses <a href="https://github.com/cloudevents/spec/blob/master/primer.md" target="blank_">CloudEvents</a> to send information back and forth between your Services and these components.
|
||||
Knative Eventing uses
|
||||
[CloudEvents](https://github.com/cloudevents/spec/blob/master/primer.md){target=blank_} to send
|
||||
information back and forth between your Services and these components.
|
||||
|
||||
??? question "What are CloudEvents?"
|
||||
For our purposes, the only thing you need to know about CloudEvents are:
|
||||
|
||||
1. CloudEvents can carry some attributes (like id, Source, type, etc) as well as data payloads (JSON, plaintext, reference to data that lives elsewhere, etc).
|
||||
1. CloudEvents can be "emitted" by almost anything and can be transported to anywhere in your deployment.
|
||||
1. CloudEvents follow the <a href = "https://github.com/cloudevents/spec" target="_blank">CloudEvents 1.0 Specification</a>, with required and optional attributes.
|
||||
1. CloudEvents follow the [CloudEvents 1.0 Specification](https://github.com/cloudevents/spec){target=_blank}, with required and optional attributes.
|
||||
|
||||
|
||||
To find out more about CloudEvents, check out the [CloudEvents website](https://cloudevents.io/)!
|
||||
|
|
|
@ -1,11 +1,8 @@
|
|||
In this tutorial, you use the [CloudEvents Player](https://github.com/ruromero/cloudevents-player){target=blank} to showcase the core concepts of Knative Eventing. By the end of this tutorial, you should have an architecture that looks like this:
|
||||
|
||||
<figure>
|
||||
<img src="../images/event_diagram.png" draggable="false">
|
||||
<figcaption>Figure 6.6 from <a href = "https://www.manning.com/books/knative-in-action" target="_blank">Knative in Action</a> <br>
|
||||
Here, the CloudEvents Player is acting as both a <code>Source</code> and a <code>Sink</code> for CloudEvents.
|
||||
</figcaption>
|
||||
</figure>
|
||||

|
||||
|
||||
The above image is Figure 6.6 from [Knative in Action](https://www.manning.com/books/knative-in-action){target=_blank}.
|
||||
|
||||
## Creating your first Source
|
||||
The CloudEvents Player acts as a Source for CloudEvents by intaking the URL of the Broker as an environment variable, `BROKER_URL`. You will send CloudEvents to the Broker through the CloudEvents Player application.
|
||||
|
@ -58,12 +55,9 @@ Create the CloudEvents Player Service:
|
|||
```
|
||||
|
||||
## Examining the CloudEvents Player
|
||||
**You can use the CloudEvents Player to send and receive CloudEvents.** If you open the [Service URL](http://cloudevents-player.default.127.0.0.1.nip.io){target=_blank} in your browser, the **Create Event** form appears.
|
||||
**You can use the CloudEvents Player to send and receive CloudEvents.** If you open the [Service URL](http://cloudevents-player.default.127.0.0.1.nip.io){target=_blank} in your browser, the **Create Event** form appears:
|
||||
|
||||
<figure>
|
||||
<img src="../images/event_form.png" draggable="false">
|
||||
<figcaption>The user interface for the CloudEvents Player</figcaption>
|
||||
</figure>
|
||||

|
||||
|
||||
??? question "What do these fields mean?"
|
||||
| Field | Description |
|
||||
|
|
|
@ -2,7 +2,11 @@
|
|||
The last super power :rocket: of Knative Serving we'll go over in this tutorial is traffic splitting.
|
||||
|
||||
??? question "What are some common traffic splitting use-cases?"
|
||||
Splitting traffic is useful for a number of very common modern infrastructure needs, such as **<a href= "https://martinfowler.com/bliki/BlueGreenDeployment.html" target="blank_">blue/green deployments</a> and <a href="https://martinfowler.com/bliki/CanaryRelease.html" target="blank_">canary deployments</a>.** Bringing these industry standards to bear on Kubernetes is **as simple as a single CLI command on Knative** or YAML tweak, let's see how!
|
||||
Splitting traffic is useful for a number of very common modern infrastructure needs, such as
|
||||
**[blue/green deployments](https://martinfowler.com/bliki/BlueGreenDeployment.html){target=blank_}
|
||||
and
|
||||
[canary deployments](https://martinfowler.com/bliki/CanaryRelease.html){target=blank_}.**
|
||||
Bringing these industry standards to bear on Kubernetes is **as simple as a single CLI command on Knative** or YAML tweak, let's see how!
|
||||
|
||||
|
||||
## Creating a new Revision
|
||||
|
|
|
@ -35,7 +35,6 @@
|
|||
trigger.eventing.knative.dev/cloudevents-trigger created
|
||||
```
|
||||
|
||||
|
||||
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.
|
||||
|
@ -44,12 +43,9 @@ trigger.eventing.knative.dev/cloudevents-player created
|
|||
|
||||
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:
|
||||
|
||||
<figure>
|
||||
<img src="../images/event_received.png" draggable="false">
|
||||
<figcaption>You may need to refresh the page to see your changes</figcaption>
|
||||
</figure>
|
||||
|
||||
{draggable=false}
|
||||
|
||||
You may need to refresh the page to see your changes.
|
||||
|
||||
??? question "What if I want to filter on CloudEvent attributes?"
|
||||
First, delete your existing Trigger:
|
||||
|
|
|
@ -7,7 +7,7 @@ Follow the procedure for the DNS of your choice:
|
|||
|
||||
=== "Magic DNS (sslip.io)"
|
||||
|
||||
Knative provides a Kubernetes Job called `default-domain` that configures Knative Serving to use <a href="http://sslip.io">sslip.io</a> as the default DNS suffix.
|
||||
Knative provides a Kubernetes Job called `default-domain` that configures Knative Serving to use [sslip.io](http://sslip.io) as the default DNS suffix.
|
||||
|
||||
```bash
|
||||
kubectl apply -f {{artifact(repo="serving",file="serving-default-domain.yaml")}}
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
!!! todo "Installing the `kn` CLI"
|
||||
|
||||
=== "Using Homebrew"
|
||||
For macOS, you can install `kn` by using <a href="https://github.com/knative/homebrew-client" target="_blank">Homebrew</a>.
|
||||
For macOS, you can install `kn` by using [Homebrew](https://github.com/knative/homebrew-client){target=_blank}.
|
||||
|
||||
```
|
||||
brew install knative/client/kn
|
||||
|
@ -11,7 +11,7 @@
|
|||
|
||||
You can install `kn` by downloading the executable binary for your system and placing it in the system path.
|
||||
|
||||
1. Download the binary for your system from the <a href="https://github.com/knative/client/releases" target="_blank">`kn` release page</a>.
|
||||
1. Download the binary for your system from the [`kn` release page](https://github.com/knative/client/releases){target=_blank}.
|
||||
|
||||
1. Rename the binary to `kn` and make it executable by running the commands:
|
||||
|
||||
|
@ -59,7 +59,7 @@
|
|||
|
||||
Links to images are available here:
|
||||
|
||||
- <a href="https://gcr.io/knative-releases/knative.dev/client/cmd/kn" target="_blank">Latest release</a>
|
||||
- [Latest release](https://gcr.io/knative-releases/knative.dev/client/cmd/kn){target=_blank}
|
||||
|
||||
You can run `kn` from a container image. For example:
|
||||
|
||||
|
|
Loading…
Reference in New Issue