diff --git a/docs/getting-started/README.md b/docs/getting-started/README.md index 695ef98f0..64efda14c 100644 --- a/docs/getting-started/README.md +++ b/docs/getting-started/README.md @@ -1,7 +1,10 @@ # Before you begin -Before you can get started with a Knative Quickstart deployment you must set up a development environment. +!!! warning + Knative Quickstart Environments are for experimentation use only. For production installation, see our [Administrator's Guide](../admin) -## Set up a development cluster +Before you can get started with a Knative Quickstart deployment you must install kind and the Kubernetes CLI. + +## Install Kind (Kubernetes in Docker) You can use [`kind`](https://kind.sigs.k8s.io/docs/user/quick-start){target=_blank} (Kubernetes in Docker) to run a local Kubernetes cluster with Docker container nodes. diff --git a/docs/getting-started/clean-up.md b/docs/getting-started/clean-up.md new file mode 100644 index 000000000..6ea0b97ae --- /dev/null +++ b/docs/getting-started/clean-up.md @@ -0,0 +1,38 @@ +## Clean Up + +=== "kn" + Delete the Service by running the command: + + ```bash + kn service delete cloudevents-player + ``` + + Delete the Trigger by running the command: + + ```bash + kn trigger delete cloudevents-trigger + ``` + +=== "kubectl" + Delete the Service by running the command + + ```bash + kubectl delete -f cloudevents.yaml + ``` + + Delete the Trigger by running the command: + + ```bash + kubectl delete -f ce-trigger.yaml + ``` + +Delete the Cluster + +Delete your `konk` Cluster" by running the command: + ```bash + kind delete clusters knative + ``` +!!! success "Verify Output" + ```{ .bash .no-copy } + Deleted clusters: ["knative"] + ``` diff --git a/docs/getting-started/first-autoscale.md b/docs/getting-started/first-autoscale.md index edba9a773..3c2ca9ad7 100644 --- a/docs/getting-started/first-autoscale.md +++ b/docs/getting-started/first-autoscale.md @@ -1,5 +1,5 @@ # Scaling to Zero -**Remember those super powers :rocket: we talked about?** One of Knative Serving's powers is automatic scaling or simply "autoscaling" out-of-the-box! This means your Knative Service will only "spin 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. +**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 "concurrency limits and other options," but that's beyond the scope of this tutorial. @@ -12,11 +12,15 @@ Let's run our "Hello world!" Service just one more time. This time, try the Knat curl http://hello.default.127.0.0.1.nip.io ``` -You can watch the pods and see how they ==scale to zero== after traffic stops going to the URL. +You can watch the pods and see how they scale to zero after traffic stops going to the URL. ```bash kubectl get pod -l serving.knative.dev/service=hello -w ``` +!!! warning + It may take up to 2 minutes for your Pods to scale down. Pinging your service again will reset this timer. + + ==**Expected output:**== ```{ .bash .no-copy } NAME READY STATUS @@ -27,7 +31,7 @@ hello-world 0/2 Terminating ``` ### Scale up your Knative Service -Try to rerun the Knative Service in your browser [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank}, and you will see a new pod running again. +Rerun the Knative Service in your browser [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank}, and you will see a new pod running again. ==**Expected output:**== ```{ .bash .no-copy } @@ -39,7 +43,7 @@ hello-world 2/2 Running ``` Exit the watch command with `Ctrl+c`. -Some people call this **Serverless** :tada: :taco: :fire: +Some people call this **Serverless** :tada: :taco: :fire: Up next, traffic splitting! ??? question "Want to go deeper on Autoscaling?" Interested in getting in the weeds with Knative Autoscaling? Check out the autoscaling page for concepts, samples, and more! diff --git a/docs/getting-started/first-broker.md b/docs/getting-started/first-broker.md index 05b971c64..ee4464c4b 100644 --- a/docs/getting-started/first-broker.md +++ b/docs/getting-started/first-broker.md @@ -1,5 +1,5 @@ ## Sources, Brokers, Triggers, Sinks, oh my! -For the purposes of this tutorial, let's keep it simple. You will focus on four powerful Eventing components: `Source`, `Trigger`, `Broker`, and `Sink`. +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:
@@ -9,29 +9,31 @@ Let's take a look at how these components interact: | Component | Basic Definition | | :---------: | :----------------------------------: | -| `Source` | :information_source: A Kubernetes Custom Resource which emits events to the Broker. | -| `Broker` | :material-relation-many-to-many: A "hub" for events in your infrastructure; a central location to send events for delivery. | -| `Trigger` | :material-magnet-on: Acts as a filter for events entering the broker, can be configured with desired event attributes. | -| `Sink` | :material-download: A destination for events. | +|:material-information: **Source** |A Kubernetes Custom Resource which emits events to the Broker. | +|:material-relation-many-to-many: **Broker** | A "hub" for events in your infrastructure; a central location to send events for delivery. | +|:material-magnet: **Trigger** |Acts as a filter for events entering the broker, can be configured with desired event attributes. | +|:material-download: **Sink** | A destination for events. | -!!! note "A note on `Sources` and `Sinks`" - 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. +!!! note "A note on Sources and Sinks" + 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 CloudEvents send information back and forth between your Services and these components. +Knative Eventing uses CloudEvents 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 CloudEvents 1.0 Specification, with required and optional attributes. - 1. CloudEvents can be "emitted" by almost anything and can be transported to anywhere in your deployment. - 1. CloudEvents can carry some attributes (things like `id`, `source`, `type`, etc) as well as data payloads (JSON, plaintext, reference to data that lives elsewhere, etc). + To find out more about CloudEvents, check out the [CloudEvents website](https://cloudevents.io/)! ## Examining the Broker -As part of the `KonK` install, you should have an in-memory `Broker` already installed. +As part of the `KonK` install, an In-Memory Broker should have already be installed in your Cluster. Check to see that it is installed by running the command: + ```bash kn broker list ``` @@ -45,5 +47,9 @@ example-broker http://broker-ingress.knative-eventing.svc.cluster.local/defaul In-Memory Brokers are for development use only and must not be used in a production deployment. -??? question "What other components exist in Knative Eventing?" +??? question "Are there any other components of Knative Eventing?" + Though it is out of scope for this tutorial, Knative Eventing has many components which can be used in many ways to suit your needs. + If you want to find out more about the different components of Knative Eventing, like Channels, Sequences, Parallels, etc. check out "Eventing Components." + +**Next, you'll take a look at a simple implementation** of Sources, Brokers, Triggers and Sinks using an app called the Cloud Events Player. diff --git a/docs/getting-started/first-service.md b/docs/getting-started/first-service.md index da97099b0..a6d5d6e09 100644 --- a/docs/getting-started/first-service.md +++ b/docs/getting-started/first-service.md @@ -2,10 +2,11 @@ !!! tip Hit ++"."++ on your keyboard to move forward in the tutorial. Use ++","++ to go back at any time. -==**In this tutorial, you will deploy a "Hello world" service.**== +**In this tutorial, you will deploy a "Hello world" service.** + This service will accept an environment variable, `TARGET`, and print "`Hello ${TARGET}!`." -For those of you familiar with other **source-to-url** tools, this may seem familiar. However, since our "Hello world" Service is being deployed as a Knative Service, it gets some **super powers (scale-to-zero, traffic-splitting) out of the box** :rocket:. +Since our "Hello world" Service is being deployed as a Knative Service, not a Kubernetes Service, it gets some **super powers out of the box** :rocket:. ## Knative Service: "Hello world!" === "kn" @@ -21,6 +22,12 @@ For those of you familiar with other **source-to-url** tools, this may seem fami ??? question "Why did I pass in `revision-name`?" Note the name "world" which you passed in as "revision-name," naming your `Revisions` will help you to more easily identify them, but don't worry, you'll learn more about `Revisions` later. + ==**Expected output:**== + ```{ .bash .no-copy } + Service hello created to latest revision 'hello-world' is available at URL: + http://hello.default.127.0.0.1.nip.io + ``` + === "YAML" ``` bash @@ -49,22 +56,26 @@ For those of you familiar with other **source-to-url** tools, this may seem fami ??? question "Why did I pass in the second name, `hello-world`?" Note the name "hello-world" which you passed in under "metadata" in your YAML file. Naming your `Revisions` will help you to more easily identify them, but don't worry if this if a bit confusing now, you'll learn more about `Revisions` later. + ==**Expected output:**== + ```{ .bash .no-copy } + service.serving.knative.dev/hello created + ``` + To see the URL where your Knative Service is hosted, leverage the `kn` CLI: + ```bash + kn service list + ``` +## Ping your Knative Service +Ping your Knative Service by opening [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank} in your browser of choice or by running the command: -==**Expected output:**== -```{ .bash .no-copy } -Service hello created to latest revision 'hello-world' is available at URL: -http://hello.default.127.0.0.1.nip.io -``` - -## Run your Knative Service ``` curl http://hello.default.127.0.0.1.nip.io ``` + ==**Expected output:**== ```{ .bash .no-copy } Hello World! ``` -Congratulations :tada:, you've just created your first Knative Service! +Congratulations :tada:, you've just created your first Knative Service. Up next, Autoscaling! diff --git a/docs/getting-started/first-source.md b/docs/getting-started/first-source.md index 5da4bf87f..4580f45c1 100644 --- a/docs/getting-started/first-source.md +++ b/docs/getting-started/first-source.md @@ -1,14 +1,14 @@ -In this tutorial, you will be using the [CloudEvents Player](https://github.com/ruromero/cloudevents-player) to showcase the core concepts of Knative Eventing. By the end of this tutorial, you should have something that looks like this: +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 6.6 from Knative in Action
Here, the CloudEvents Player is acting as both a Source and a Sink for CloudEvents.
## Creating your first Source -The CloudEvents Player acts as a `Source` for CloudEvents by intaking the URL of our `Broker` as an environment variable (`BROKER_URL`) and sending CloudEvents via the UI. +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. Create the CloudEvents Player Service: === "kn" @@ -18,26 +18,50 @@ Create the CloudEvents Player Service: --image ruromero/cloudevents-player:latest \ --env BROKER_URL=http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker ``` + ==**Expected Output**== + ```{ .bash .no-copy } + Service 'cloudevents-player' created to latest revision 'cloudevents-player-vwybw-1' is available at URL: + http://cloudevents-player.default.127.0.0.1.nip.io + ``` + + ??? question "Why is my Revision named something different!" + Because we didn't assign a `revision-name`, Knative Serving automatically created one for us. It's okay if your Revision is named something different. === "YAML" ```bash - //TODO + apiVersion: serving.knative.dev/v1 + kind: Service + metadata: + name: cloudevents-player + spec: + template: + metadata: + annotations: + autoscaling.knative.dev/minScale: "1" + spec: + containers: + - image: ruromero/cloudevents-player:latest + env: + - name: BROKER_URL + value: http://broker-ingress.knative-eventing.svc.cluster.local/default/example-broker ``` -==**Expected Output**== -```{ .bash .no-copy } -Service 'cloudevents-player' created to latest revision 'cloudevents-player-vwybw-1' is available at URL: -http://cloudevents-player.default.127.0.0.1.nip.io -``` -??? question "Wait, my `Revision` is named something different!" - Since we didn't assign a `revision-name`, Knative Serving automatically created one for us, it's ok if your `Revision` is named something different. + Once you've created your YAML file, named something like `cloudevents-player.yaml`, apply it by running the command: + ``` bash + kubectl apply -f cloudevents-player.yaml + ``` + + ==**Expected Output**== + ```{ .bash .no-copy } + service.serving.knative.dev/cloudevents-player created + ``` ## Examining the CloudEvents Player -We 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, you should be greeted by a form titled "Create event." +**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.
- +
The user interface for the CloudEvents Player
@@ -52,14 +76,16 @@ We can use the CloudEvents Player to send and receive CloudEvents. If you open t For more information on the CloudEvents Specification, check out the [CloudEvents Spec](https://github.com/cloudevents/spec/blob/v1.0.1/spec.md){target=_blank}. -Fill out the form with whatever you data you would like to (make sure your Event Source does not contain any spaces) and hit the "SEND EVENT" button. + 1. Fill in the form with whatever you data you want. + 1. Ensure your Event Source does not contain any spaces. + 1. Click **SEND EVENT**. + +![CloudEvents Player Send](../images/event_sent.png) -![CloudEvents Player Send](https://user-images.githubusercontent.com/16281246/116407683-04448d80-a800-11eb-9283-ba86fb259053.png) +??? tip "Clicking the :fontawesome-solid-envelope: shows you the CloudEvent as the Broker sees it." + ![Event_Details](../images/event_details.png) +The :material-send: icon in the "Status" column implies that the event has been sent to our Broker... but where has the event gone? **Well, right now, nowhere!** -!!! tip "Tip: Clicking the :fontawesome-solid-envelope: will show you the CloudEvent as the `Broker` sees it." - -The :material-send: icon in the "Status" column implies that the event has been sent to our `Broker`, but where has the event gone? Well, right now, nowhere! - -A `Broker` is simply a receptacle for events. In order for your events to be sent somewhere, you must create a `Trigger` which listens for your events and places them somewhere. Let's do that next! +A Broker is simply a receptacle for events. In order for your events to be sent anywhere, you must create a Trigger which listens for your events and places them somewhere. And, you're in luck: you'll create your first Trigger on the next page! diff --git a/docs/getting-started/first-traffic-split.md b/docs/getting-started/first-traffic-split.md index c75154679..1ac425814 100644 --- a/docs/getting-started/first-traffic-split.md +++ b/docs/getting-started/first-traffic-split.md @@ -6,14 +6,14 @@ The last super power :rocket: of Knative Serving we'll go over in this tutorial ## Creating a new Revision -You may have noticed that when you created your Knative Service you assigned it a `revision-name`, "world". When your Service was created, Knative returned both a URL and a 'latest revision' name for your Knative Service. **But what happens if you make a change to your Service?** +You may have noticed that when you created your Knative Service you assigned it a `revision-name`, "world". If you used `kn`, when your Service was created Knative returned both a URL and a "latest revision" for your Knative Service. **But what happens if you make a change to your Service?** -??? question "What exactly is a `Revision`?"" - You can think of a `Revision` as a stateless, autoscaling snapshot-in-time of application code and configuration. +??? question "What exactly is a Revision?"" + You can think of a Revision as a stateless, autoscaling, snapshot-in-time of application code and configuration. - A new `Revision` will get created each and every time you make changes to your Knative Service, whether you assign it a name or not. When splitting traffic, Knative splits traffic between different `Revisions` of your Knative Service. + A new Revision will get created each and every time you make changes to your Knative Service, whether you assign it a name or not. When splitting traffic, Knative splits traffic between different Revisions of your Knative Service. -Instead of `TARGET`="World," let's update the environment variable `TARGET` on our Knative Service `hello` to greet "Knative". Lets name this new revision `hello-knative` +Instead of `TARGET`="World" update the environment variable `TARGET` on your Knative Service `hello` to greet "Knative" instead. Name this new revision `hello-knative` === "kn" ``` bash @@ -22,6 +22,14 @@ Instead of `TARGET`="World," let's update the environment variable `TARGET` on o --revision-name=knative ``` + As before, `kn` prints out some helpful information to the CLI. + + ==**Expected output:**== + ```{ .bash .no-copy } + Service hello created to latest revision 'hello-knative' is available at URL: + http://hello.default.127.0.0.1.nip.io + ``` + === "YAML" ``` bash --- @@ -47,17 +55,15 @@ Instead of `TARGET`="World," let's update the environment variable `TARGET` on o kubectl apply -f hello.yaml ``` -As before, Knative prints. out some helpful information to the CLI. + ==**Expected output:**== + ```{ .bash .no-copy } + service.serving.knative.dev/hello created + ``` -==**Expected output:**== -```{ .bash .no-copy } -Service hello created to latest revision 'hello-knative' is available at URL: -http://hello.default.127.0.0.1.nip.io -``` -Note, since we are updating an existing Knative Service `hello`, the URL doesn't change, but our new `Revision` should have the new name "hello-knative" +Note, since we are updating an existing Knative Service `hello`, the URL doesn't change, but our new Revision should have the new name `hello-knative` -Let's access our Knative Service again on the browser [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank} to see the change, or use `curl` in your terminal: +Let's access our Knative Service again on your browser [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank} to see the change, or use `curl` in your terminal: ```bash curl http://hello.default.127.0.0.1.nip.io ``` @@ -68,7 +74,7 @@ Hello Knative! ``` ## Splitting Traffic -You may at this point be wondering, "where did 'Hello World!' go?" `Revisions` are a stateless snapshot-in-time of application code and configuration so your "hello-world" `Revision` is still available to you. +You may at this point be wondering, "where did 'Hello World!' go?" Remember, Revisions are a stateless snapshot-in-time of application code and configuration, so your "hello-world" `Revision` is still available to you. We can easily see a list of our existing revisions with the `kn` CLI: @@ -92,9 +98,11 @@ hello-knative hello 100% 2 30s 3 OK / 4 True hello-world hello 1 5m 3 OK / 4 True ``` -The column most relevant for our purposes is "TRAFFIC". It looks like 100% of traffic is going to our latest `Revision` ("hello-knative") and 0% of traffic is going to the `Revision` we configured earlier ("hello-world") +The column most relevant for our purposes is `TRAFFIC`. It looks like 100% of traffic is going to our latest `Revision` ("hello-knative") and 0% of traffic is going to the Revision we configured earlier ("hello-world"). -By default, when Knative creates a brand new `Revision` it directs 100% of traffic to the latest `Revision` of your service. **We can change this default behavior by specifying how much traffic we want each of our `Revisions` to receive.** Lets split traffic in half, using a percentage of 50%. +When you create a new Revision of a Knative Service, Knative defaults to directing 100% of traffic to this latest Revision. **We can change this default behavior by specifying how much traffic we want each of our Revisions to receive.** + +Lets split traffic between our two Revisions: !!! info inline end `@latest` will always point to our "latest" `Revision` which, at the moment, is `hello-knative`. @@ -156,14 +164,13 @@ hello-knative hello 50% 2 10m 3 OK / 4 True hello-world hello 50% 1 36m 3 OK / 4 True ``` -Access the Knative service on the browser again [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank}, and refresh multiple times to see the different output being served by each revision. -You can use curl to access multiple times. +Access your Knative service on the browser again [http://hello.default.127.0.0.1.nip.io](http://hello.default.127.0.0.1.nip.io){target=_blank}, and refresh multiple times to see the different output being served by each Revision. + +Similarly, you can `curl` the Service URL multiple times to see the traffic being split between the Revisions. ```bash curl http://hello.default.127.0.0.1.nip.io ``` -On the terminal you will see the output from the both revisions. - ==**Expected output:**== ```{ .bash .no-copy } curl http://hello.default.127.0.0.1.nip.io @@ -173,4 +180,17 @@ curl http://hello.default.127.0.0.1.nip.io Hello World! ``` -Congratulations, :tada: you've successfully split traffic between 2 different `Revisions`. Up next, Knative Eventing! +Congratulations, :tada: you've successfully split traffic between 2 different Revisions of a Knative Service. Up next, Knative Eventing! + +## Clean Up +You won't need the `hello` Service in the Knative Eventing tutorial, so it's best to clean up before you move forward: + +=== "kn" + ```bash + kn service delete hello + ``` + +=== "kubectl" + ```bash + kubectl delete -f hello.yaml + ``` diff --git a/docs/getting-started/first-trigger.md b/docs/getting-started/first-trigger.md index a7c4215de..1625df487 100644 --- a/docs/getting-started/first-trigger.md +++ b/docs/getting-started/first-trigger.md @@ -1,16 +1,19 @@ -## Creating your first `Trigger` +## Creating your first Trigger === "kn" ```bash - kn trigger create cloudevents-player --sink cloudevents-player --broker example-broker + kn trigger create cloudevents-trigger --sink cloudevents-player --broker example-broker ``` + ```{ .bash .no-copy } + Trigger 'cloudevents-trigger' successfully created in namespace 'default'. + ``` === "YAML" ```bash apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: - name: cloudevents-player + name: cloudevents-trigger annotations: knative-eventing-injection: enabled spec: @@ -21,18 +24,28 @@ kind: Service name: cloudevents-player ``` -==**Expected Output**== -```{ .bash .no-copy } -Trigger 'cloudevents-player' successfully created in namespace 'default'. -``` -??? question "What CloudEvents is my `Trigger` listening for?" - Since we didn't specify a `--filter` in our `kn` command, our Trigger is listening for any CloudEvents coming into the `Broker`. + After you've created your YAML file, named something like `ce-trigger.yaml`, apply it by running the command: + ``` bash + kubectl apply -f ce-trigger.yaml + ``` + + ==**Expected Output**== + ```{ .bash .no-copy } + 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. + + An example on how to use Filters is provided below. 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:
- +
You may need to refresh the page to see your changes
@@ -48,7 +61,7 @@ Now, when we go back to the CloudEvents Player and send an Event, we see that Cl kn trigger create cloudevents-player-filter --sink cloudevents-player --broker example-broker --filter type=some-type ``` - If you send a CloudEvent with type "some-type," it will be reflected in the CloudEvents Player UI. Any other types will be ignored by the `Trigger`. + If you send a CloudEvent with type "some-type," it is reflected in the CloudEvents Player UI. The Trigger ignores any other types. You can filter on any aspect of the CloudEvent you would like to. diff --git a/docs/getting-started/getting-started-eventing.md b/docs/getting-started/getting-started-eventing.md index 3faa64112..83c0a77f8 100644 --- a/docs/getting-started/getting-started-eventing.md +++ b/docs/getting-started/getting-started-eventing.md @@ -1,15 +1,21 @@ # Introducing the Knative Eventing ## Background -With Knative Serving, we have a powerful tool which can take our containerized code and deploy it with relative ease. **With Knative Eventing, you gain a few new super powers :rocket: that allow you to build Event-Driven Applications.** +With Knative Serving, we have a powerful tool which can take our containerized code and deploy it with relative ease. **With Knative Eventing, you gain a few new super powers :rocket:** that allow you to build Event-Driven Applications. ??? question "What are Event Driven Applications?" - Event-driven applications are designed to detect events as they occur, and then deal with them using some event-handling procedure. Producing "events" to detect and consuming events with an "event-handling procedure" is precisely what Knative Eventing enables. + Event-driven applications are designed to detect events as they occur, and then deal with them using some event-handling procedure. Producing and consuming events with an "event-handling procedure" is precisely what Knative Eventing enables. + + Want to find out more about Event-Driven Architecture and Knative Eventing? Check out this CNCF Session aptly named ["Event-driven architecture with Knative events"](https://www.cncf.io/online-programs/event-driven-architecture-with-knative-events/){target=blank} ==**Knative Eventing acts as the "glue" between the disparate parts of your architecture**== and allows you to easily communicate between those parts in a fault-tolerant way. Some examples include: -1. [Creating and responding to Kubernetes API events](../../eventing/sources/apiserversource/) -1. [Creating an image processing pipeline](https://www.youtube.com/watch?v=DrmOpjAunlQ) -1. [Facilitating AI workloads at the edge in large-scale, drone-powered sustainable agriculture projects](https://www.youtube.com/watch?v=lVfJ5WEQ5_s). +:material-file-document: [Creating and responding to Kubernetes API events](../../eventing/sources/apiserversource/){target=blank} -As you can see by the examples above, **Knative Eventing implementations can range from the dead simple to extremely complex**, the concepts you'll learn will be a great starting point to accomplish either. +--8<-- "YouTube_icon.svg" +[Creating an image processing pipeline](https://www.youtube.com/watch?v=DrmOpjAunlQ){target=blank} + +--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. diff --git a/docs/getting-started/images/event_details.png b/docs/getting-started/images/event_details.png new file mode 100644 index 000000000..680d8daf9 Binary files /dev/null and b/docs/getting-started/images/event_details.png differ diff --git a/docs/getting-started/images/event_diagram.png b/docs/getting-started/images/event_diagram.png new file mode 100644 index 000000000..933fdba9f Binary files /dev/null and b/docs/getting-started/images/event_diagram.png differ diff --git a/docs/getting-started/images/event_form.png b/docs/getting-started/images/event_form.png new file mode 100644 index 000000000..a7629da99 Binary files /dev/null and b/docs/getting-started/images/event_form.png differ diff --git a/docs/getting-started/images/event_received.png b/docs/getting-started/images/event_received.png new file mode 100644 index 000000000..c9b1c4261 Binary files /dev/null and b/docs/getting-started/images/event_received.png differ diff --git a/docs/getting-started/images/event_sent.png b/docs/getting-started/images/event_sent.png new file mode 100644 index 000000000..b2c33eccd Binary files /dev/null and b/docs/getting-started/images/event_sent.png differ diff --git a/docs/getting-started/install-knative-quickstart.md b/docs/getting-started/install-knative-quickstart.md index 8ee807ea4..afc84df4a 100644 --- a/docs/getting-started/install-knative-quickstart.md +++ b/docs/getting-started/install-knative-quickstart.md @@ -1,25 +1,15 @@ # Getting Started with the Knative "Quickstart" Environment -!!! warning - Knative Quickstart Environments are for experimentation only. For production installation, see our [Administrator's Guide](../admin) - ## Install Knative using the konk script You can get started with a local deployment of Knative by using _Knative on Kind_ (`konk`): -`konk` is a shell script that completes the following functions: - -1. Checks if you have `kind` installed, and creates a cluster called `knative`. -1. Installs Knative Serving with Kourier as the default networking layer, and nip.io as the DNS. -1. Installs Knative Eventing and creates a default broker and channel implementation. - -!!! todo "Install Knative and Kubernetes on a local Docker Daemon using `konk`" - ``` - curl -sL install.konk.dev | bash - ``` +--8<-- "quickstart-install.md" ## Install the Knative CLI -The Knative CLI (`kn`) provides a quick and easy interface for creating Knative resources such as Knative services and event sources, without the need to create or modify YAML files directly. `kn` also simplifies completion of otherwise complex procedures such as autoscaling and traffic splitting. +The Knative CLI (`kn`) provides a quick and easy interface for creating Knative resources, such as Knative Services and Event Sources, without the need to create or modify YAML files directly. + +`kn` also simplifies completion of otherwise complex procedures such as autoscaling and traffic splitting. --8<-- "install-kn.md" diff --git a/docs/help/contributor/README.md b/docs/help/contributor/README.md index fba9a5451..14cfe4564 100644 --- a/docs/help/contributor/README.md +++ b/docs/help/contributor/README.md @@ -4,5 +4,5 @@ - [Knative MkDocs Contributor Guide](./mkdocs-contributor-guide.md) - [Knative Style Guide](./style-guide/README.md) -- [Content Re-Use](../snippets/README.md) -- [Using Shortcodes (Coming Soon!)]() +- [Content Re-Use](../../snippets/README.md) +- [Using Shortcodes (TBD)]() diff --git a/docs/images/Google.png b/docs/images/Google.png deleted file mode 100644 index f1f64e3a6..000000000 Binary files a/docs/images/Google.png and /dev/null differ diff --git a/docs/images/Redhat.png b/docs/images/Redhat.png deleted file mode 100644 index ad9bc9ceb..000000000 Binary files a/docs/images/Redhat.png and /dev/null differ diff --git a/docs/images/Tanzu.png b/docs/images/Tanzu.png deleted file mode 100644 index fc6870337..000000000 Binary files a/docs/images/Tanzu.png and /dev/null differ diff --git a/docs/images/Triggermesh.png b/docs/images/Triggermesh.png deleted file mode 100644 index 3f1756fcc..000000000 Binary files a/docs/images/Triggermesh.png and /dev/null differ diff --git a/docs/images/corporate-logos/Google.svg b/docs/images/corporate-logos/Google.svg new file mode 100644 index 000000000..3790851de --- /dev/null +++ b/docs/images/corporate-logos/Google.svg @@ -0,0 +1,2 @@ + + diff --git a/docs/images/IBM.png b/docs/images/corporate-logos/IBM.png similarity index 100% rename from docs/images/IBM.png rename to docs/images/corporate-logos/IBM.png diff --git a/docs/images/corporate-logos/Redhat.svg b/docs/images/corporate-logos/Redhat.svg new file mode 100644 index 000000000..3da4fd9c5 --- /dev/null +++ b/docs/images/corporate-logos/Redhat.svg @@ -0,0 +1 @@ +RedHat-Logo-A-Color diff --git a/docs/images/corporate-logos/Triggermesh.svg b/docs/images/corporate-logos/Triggermesh.svg new file mode 100644 index 000000000..f465ed018 --- /dev/null +++ b/docs/images/corporate-logos/Triggermesh.svg @@ -0,0 +1,43 @@ + + + + + + + + + + + + + + + + + + + + + + diff --git a/docs/images/corporate-logos/vmware.svg b/docs/images/corporate-logos/vmware.svg new file mode 100644 index 000000000..854530624 --- /dev/null +++ b/docs/images/corporate-logos/vmware.svg @@ -0,0 +1,37 @@ + + + + + + + + + + + + + + diff --git a/docs/snippets/YouTube_icon.svg b/docs/snippets/YouTube_icon.svg new file mode 100644 index 000000000..d873776d0 --- /dev/null +++ b/docs/snippets/YouTube_icon.svg @@ -0,0 +1,65 @@ + + + +image/svg+xml diff --git a/docs/snippets/quickstart-install.md b/docs/snippets/quickstart-install.md new file mode 100644 index 000000000..5d7211be6 --- /dev/null +++ b/docs/snippets/quickstart-install.md @@ -0,0 +1,23 @@ + + +`konk` is a shell script that completes the following functions: + +1. **Checks if you have [`kind`](https://kind.sigs.k8s.io/docs/user/quick-start){target=_blank} installed,** and creates a cluster called `knative`. +1. **Installs Knative Serving with Kourier** as the default networking layer, and nip.io as the DNS. +1. **Installs Knative Eventing** and creates an in-memory Broker and Channel implementation. + +!!! todo "Install Knative and Kubernetes on a local Docker Daemon using `konk`" + ```bash + curl -sL install.konk.dev | bash + ``` + +??? bug "Having issues with Kind?" + We've found that some users (specifically Linux) may have trouble with Docker and, subsequently, Kind. Though this tutorial assumes you have KonK installed, you can easily follow along with a different installation. + + We have provide an alternative Quickstart on `minikube` here: [https://github.com/csantanapr/knative-minikube](https://github.com/csantanapr/knative-minikube){_target="_blank"} + +Installing `konk` may take a few minutes. After the script is finished, check to make sure you have a Cluster called `knative` +!!! success "Verify Installation" + ```bash + kind get clusters + ``` diff --git a/mkdocs.yml b/mkdocs.yml index 0691faa0e..ff88d4250 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -12,15 +12,16 @@ nav: - Getting Started: - Before you begin: getting-started/README.md - Knative Quickstart: getting-started/install-knative-quickstart.md - - Serverless: + - Using Knative Serving: - First Knative Service: getting-started/first-service.md - Scaling to Zero: getting-started/first-autoscale.md - Traffic Splitting: getting-started/first-traffic-split.md - - Event-Driven Applications: + - Using Knative Eventing: - Introducing Knative Eventing: getting-started/getting-started-eventing.md - Sources, Brokers, Triggers, Sinks: getting-started/first-broker.md - Introducing the CloudEvents Player: getting-started/first-source.md - Creating your first Trigger: getting-started/first-trigger.md + - Clean Up: getting-started/clean-up.md - What's Next?: getting-started/next-steps.md # Administration guide - Administration guide: diff --git a/overrides/home.html b/overrides/home.html index fd3dbf346..126a34e6b 100644 --- a/overrides/home.html +++ b/overrides/home.html @@ -89,19 +89,19 @@