Format markdown (#1070)

* Format markdown

Produced via: `prettier --write --prose-wrap=always $(find -name '*.md' | grep -v vendor | grep -v .github)`

* Apply suggestions from code review

Co-Authored-By: mattmoor-sockpuppet <mattmoor+sockpuppet@google.com>

* Undo parts of auto-correction that result in diff.
This commit is contained in:
mattmoor-sockpuppet 2019-03-24 21:12:49 -07:00 committed by Knative Prow Robot
parent 9910b8a9ac
commit 01d4ba31ec
85 changed files with 837 additions and 792 deletions

View File

@ -7,8 +7,8 @@ docs and learn about Knative.
## Source files
View the source files if you want to contribute a fix or add new content.
Each release of the Knative docs are
View the source files if you want to contribute a fix or add new content. Each
release of the Knative docs are
[branched](https://github.com/knative/docs/branches). If you are looking for an
archived doc set, see the list of available versions in
[Knative doc releases](./doc-releases.md).

View File

@ -7,7 +7,6 @@ menu:
type: "blog"
---
Welcome to the Knative **blog** section. Keep up-to-date with product and
release announcements, read articles, hear about recent social events, and
find out where the Knative team will be talking next.
release announcements, read articles, hear about recent social events, and find
out where the Knative team will be talking next.

View File

@ -4,4 +4,3 @@ linkTitle: "Articles"
weight: 30
type: "blog"
---

View File

@ -1,5 +1,5 @@
## Sample apps
| Sample Name | Knative Component | Description | Language(s) |
| --------------| ----------------- | -------------------------- | ----------------- |
| Hello World | Serving | A quick introduction that highlights how to deploy an app. | [Clojure](./serving/helloworld-clojure/README.md), [Dart](./serving/helloworld-dart/README.md), [Elixir](./serving/helloworld-elixir/README.md), [Haskell](./serving/helloworld-haskell/README.md), [Rust](./serving/helloworld-rust/README.md), [Shell](./serving/helloworld-shell/README.md), [Swift](./serving/helloworld-swift/README.md), [Vertx](./serving/helloworld-vertx/README.md) |
| Sample Name | Knative Component | Description | Language(s) |
| ----------- | ----------------- | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Hello World | Serving | A quick introduction that highlights how to deploy an app. | [Clojure](./serving/helloworld-clojure/README.md), [Dart](./serving/helloworld-dart/README.md), [Elixir](./serving/helloworld-elixir/README.md), [Haskell](./serving/helloworld-haskell/README.md), [Rust](./serving/helloworld-rust/README.md), [Shell](./serving/helloworld-shell/README.md), [Swift](./serving/helloworld-swift/README.md), [Vertx](./serving/helloworld-vertx/README.md) |

View File

@ -8,6 +8,7 @@ type: "docs"
Get up and running in a language of your choice using one of the community
contributed and maintained sample apps.
Use the following table to view the instructions and sample code in the knative/docs repo.
Use the following table to view the instructions and sample code in the
knative/docs repo.
{{% readfile file="README.md" relative="true" markdown="true" %}}

View File

@ -7,8 +7,8 @@ specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -8,8 +8,8 @@ that you can use for testing. It reads in the env variable `TARGET` and prints
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).
- [dart-sdk](https://www.dartlang.org/tools/sdk#install) installed and

View File

@ -7,8 +7,8 @@ specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -8,8 +8,8 @@ TARGET is not specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -7,8 +7,8 @@ variable is not specified, the script uses `World`.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -15,8 +15,8 @@ You must meet the following requirements to complete this sample:
- A version of the Knative Serving component installed and running on your
Kubernetes cluster. Follow the
[Knative installation instructions](../../../install/README.md)
if you need to create a Knative cluster.
[Knative installation instructions](../../../install/README.md) if you need to
create a Knative cluster.
- The following software downloaded and install on your loacal machine:
- [Java SE 8 or later JDK](http://www.oracle.com/technetwork/java/javase/downloads/index.html).
- [Eclipse Vert.x v3.5.4](https://vertx.io/).

View File

@ -86,8 +86,8 @@ page still applies, but you'll find the specifics about the docs process there.
In order to contribute a feature to Knative you'll need to go through the
following steps:
- Discuss your idea with the appropriate [working groups](./WORKING-GROUPS.md) on
the working group's mailing list.
- Discuss your idea with the appropriate [working groups](./WORKING-GROUPS.md)
on the working group's mailing list.
- Once there is general agreement that the feature is useful,
[create a GitHub issue](https://github.com/knative/docs/issues/new) to track

View File

@ -53,7 +53,6 @@ Note that code issues should be filed against the
[individual Knative repositories](http://github.com/knative), while
documentation issues should go in the `docs` repository.
### Working group
The [Knative Documentation Working Group](./WORKING-GROUPS.md#documentation)
@ -112,8 +111,8 @@ that are only expected to be used by contributors, those samples are put in the
## Docs contributor roles
Because contributing to the documentation requires a different skill set than
contributing to the Knative code base, we've defined the roles of
documentation contributors seperately from the roles of code contributors.
contributing to the Knative code base, we've defined the roles of documentation
contributors seperately from the roles of code contributors.
If you're looking for code contributor roles, see [ROLES](./ROLES.md).
@ -122,21 +121,21 @@ If you're looking for code contributor roles, see [ROLES](./ROLES.md).
Established contributor to the Knative docs.
Members are continuously active contributors in the community. They can have
issues and PRs assigned to them, might participate in working group meetings, and
pre-submit tests are automatically run for their PRs. Members are expected to
remain active contributors to the Knative documentation.
issues and PRs assigned to them, might participate in working group meetings,
and pre-submit tests are automatically run for their PRs. Members are expected
to remain active contributors to the Knative documentation.
All members are encouraged to help with PR reviews, although each PR
must be reviewed by an official [Approver](#approver). In their review,
members should be looking for technical correctness of the documentation,
adherence to the [style guide](https://developers.google.com/style/), good spelling and grammar (writing quality),
intuitive organization, and strong documentation usability. Members should be
proficient in at least one of these review areas.
All members are encouraged to help with PR reviews, although each PR must be
reviewed by an official [Approver](#approver). In their review, members should
be looking for technical correctness of the documentation, adherence to the
[style guide](https://developers.google.com/style/), good spelling and grammar
(writing quality), intuitive organization, and strong documentation usability.
Members should be proficient in at least one of these review areas.
### Requirements
- Has made multiple contributions to the project or community. Contributions might
include, but are not limited to:
- Has made multiple contributions to the project or community. Contributions
might include, but are not limited to:
- Authoring and reviewing PRs on GitHub in the Docs or Website repos.
@ -157,42 +156,45 @@ proficient in at least one of these review areas.
- Responsive to issues and PRs assigned to them.
- Active owner of documents they have contributed (unless ownership is explicitly
transferred).
- Active owner of documents they have contributed (unless ownership is
explicitly transferred).
- Addresses bugs or issues in their documentation in a timely manner.
### Becoming a member
First, reach out to an approver and ask them to sponsor you so that you can become a member.
The easiest way to do this is using Slack.
First, reach out to an approver and ask them to sponsor you so that you can
become a member. The easiest way to do this is using Slack.
If they are supportive of your membership, your sponsor will reach out to the Knative Steering
committee to ask that you be added as a member of the Knative org.
If they are supportive of your membership, your sponsor will reach out to the
Knative Steering committee to ask that you be added as a member of the Knative
org.
Once your sponsor notifies you that you've been added to the Knative org, open a
PR to add yourself as a docs-reviewer in the [OWNERS_ALIASES](../OWNERS_ALIASES)
file.
Once your sponsor notifies you that you've been added to the Knative org,
open a PR to add yourself as a docs-reviewer in the
[OWNERS_ALIASES](../OWNERS_ALIASES) file.
## Approver
Docs approvers are able to both review and approve documentation contributions.
While documentation review is focused on writing quality and correctness,
approval is focused on holistic acceptance of a contribution including:
long-term maintainability, adhering to style guide conventions, overall information
architecture, and usability from an engineering standpoint. Docs approvers will
enlist help from engineers for reviewing code-heavy contributions to the Docs repo.
long-term maintainability, adhering to style guide conventions, overall
information architecture, and usability from an engineering standpoint. Docs
approvers will enlist help from engineers for reviewing code-heavy contributions
to the Docs repo.
### Requirements
- Reviewer of the Docs repo for at least 3 months.
- Proficient in reviewing all aspects of writing quality, including grammar and
spelling, adherence to style guide conventions, organization, and usability.
Can coach newer writers to improve their contributions in these areas.
- Primary reviewer for at least 10 substantial PRs to the docs, showing substantial
ability to coach for writing development.
- Proficient in reviewing all aspects of writing quality, including grammar
and spelling, adherence to style guide conventions, organization, and
usability. Can coach newer writers to improve their contributions in these
areas.
- Primary reviewer for at least 10 substantial PRs to the docs, showing
substantial ability to coach for writing development.
- Reviewed or merged at least 30 PRs to the docs.
@ -204,9 +206,9 @@ enlist help from engineers for reviewing code-heavy contributions to the Docs re
- Responsible for documentation quality control via PR reviews.
- Focus on long-term maintainability, adhering to style
guide conventions, overall information architecture, and usability from
an engineering standpoint.
- Focus on long-term maintainability, adhering to style guide conventions,
overall information architecture, and usability from an engineering
standpoint.
- Expected to be responsive to review requests as per
[community expectations](REVIEWING.md).
@ -218,12 +220,11 @@ enlist help from engineers for reviewing code-heavy contributions to the Docs re
### Becoming an approver
If you want to become an approver, make your goal clear to the current
Knative Docs approvers, either by contacting them in Slack or announcing
your intention to become an approver at a meeting of the Documentation
Working Group.
If you want to become an approver, make your goal clear to the current Knative
Docs approvers, either by contacting them in Slack or announcing your intention
to become an approver at a meeting of the Documentation Working Group.
Once you feel you meet the criteria, you can ask one of the current
approvers to nominate you to become an approver. If all existing
approvers agree that you meet the criteria open a PR to add yourself
as a docs-approver in the [OWNERS_ALIASES](../OWNERS_ALIASES) file.
Once you feel you meet the criteria, you can ask one of the current approvers to
nominate you to become an approver. If all existing approvers agree that you
meet the criteria open a PR to add yourself as a docs-approver in the
[OWNERS_ALIASES](../OWNERS_ALIASES) file.

View File

@ -1,4 +1,3 @@
_Important_. Before proceeding, please review the Knative community
[Code of Conduct](./CODE-OF-CONDUCT.md).
@ -23,14 +22,15 @@ Other Documents
- [Code of Conduct](./CODE-OF-CONDUCT.md) - all contributors must abide by the
code of conduct
- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on becoming
a contributor
- [Contributing to Knative](./CONTRIBUTING.md) - guidelines and advice on
becoming a contributor
- [Working Groups](./WORKING-GROUPS.md) - describes our various working groups
- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how working
groups operate
- [Working Group Processes](./WORKING-GROUP-PROCESSES.md) - describes how
working groups operate
- [Technical Oversight Committee](./TECH-OVERSIGHT-COMMITTEE.md) - describes our
technical oversight committee
- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering committee
- [Steering Committee](./STEERING-COMMITTEE.md) - describes our steering
committee
- [Community Roles](./ROLES.md) - describes the roles individuals can assume
within the Knative community
- [Reviewing and Merging Pull Requests](./REVIEWING.md) - how we manage pull
@ -39,8 +39,8 @@ Other Documents
## Introduction
Knative is a Kubernetes-based platform to build, deploy, and manage modern
serverless workloads. See [Knative docs](../docs/README.md) for
in-depth information about using Knative.
serverless workloads. See [Knative docs](../docs/README.md) for in-depth
information about using Knative.
## Knative authors
@ -56,15 +56,15 @@ tools, platforms, languages, and products. By submitting a tutorial you can
share your experience and help others who are solving similar problems.
Community tutorials are stored in Markdown files under the `community` folder
[Community Samples](../community/samples/README.md). These documents
are contributed, reviewed, and maintained by the community.
[Community Samples](../community/samples/README.md). These documents are
contributed, reviewed, and maintained by the community.
Submit a Pull Request to the community sample directory under the Knative
component folder that aligns with your document. For example, Knative Serving
samples are under the `serving` folder. A reviewer will be assigned to review your
submission. They'll work with you to ensure that your submission is clear, correct,
and meets the [style guide](./DOCS-CONTRIBUTING.md), but it helps if you follow it
as you write your tutorial.
samples are under the `serving` folder. A reviewer will be assigned to review
your submission. They'll work with you to ensure that your submission is clear,
correct, and meets the [style guide](./DOCS-CONTRIBUTING.md), but it helps if
you follow it as you write your tutorial.
## Meetings and work groups
@ -98,7 +98,8 @@ following resources are available for you:
- [Knative Users](https://groups.google.com/forum/#!forum/knative-users)
- [Knative Developers](https://groups.google.com/forum/#!forum/knative-dev)
For contributors to Knative, we also have [Knative Slack](./SLACK-GUIDELINES.md).
For contributors to Knative, we also have
[Knative Slack](./SLACK-GUIDELINES.md).
---

View File

@ -30,8 +30,8 @@ Please do not ever hesitate to ask a question or submit a PR.
Reviewers are often the first points of contact between new members of the
community and are important in shaping the community. We encourage reviewers to
read the [code of conduct](./CODE-OF-CONDUCT.md) and to go above and
beyond the code of conduct to promote a collaborative and respectful community.
read the [code of conduct](./CODE-OF-CONDUCT.md) and to go above and beyond the
code of conduct to promote a collaborative and respectful community.
## Code reviewers

View File

@ -5,9 +5,9 @@ weight: 55
type: "docs"
---
This document describes the set of roles individuals might have within the Knative
community, the requirements of each role, and the privileges that each role
grants.
This document describes the set of roles individuals might have within the
Knative community, the requirements of each role, and the privileges that each
role grants.
- [Role Summary](#role-summary)
- [Collaborator](#collaborator)
@ -120,8 +120,8 @@ with the PR bot.
- Working on some contribution to the project that would benefit from the
ability to have PRs or Issues to be assigned to the contributor.
- Join [knative-users@](https://groups.google.com/forum/#!forum/knative-users)
, which grants read access to documents in the Team Drive.
- Join [knative-users@](https://groups.google.com/forum/#!forum/knative-users) ,
which grants read access to documents in the Team Drive.
## Member
@ -143,8 +143,8 @@ this is not a requirement.
### Requirements
- Has made multiple contributions to the project or community. Contributions might
include, but are not limited to:
- Has made multiple contributions to the project or community. Contributions
might include, but are not limited to:
- Authoring and reviewing PRs on GitHub.
@ -195,13 +195,13 @@ approver in an OWNERS file:
- Reviewer of the codebase for at least 3 months.
- Primary reviewer for at least 10 substantial PRs to the codebase.
- One path for getting the necessary reviews is to add yourself to the
`reviewers` section of the OWNERS file. Note that this does not give
you any additional privileges. By having yourself listed in this
section in OWNERS file means that you will get PRs assigned to you
for code review. Getting added to `reviewers` section is at the
discretion of an approver after enough evidence of quality
contributions.
`reviewers` section of the OWNERS file. Note that this does not give you any
additional privileges. By having yourself listed in this section in OWNERS
file means that you will get PRs assigned to you for code review. Getting
added to `reviewers` section is at the discretion of an approver after
enough evidence of quality contributions.
- Reviewed or merged at least 30 PRs to the codebase.
@ -218,18 +218,17 @@ approver in an OWNERS file:
- Demonstrate sound technical judgment.
- Responsible for project quality control via [code reviews](./REVIEWING.md).
* Responsible for project quality control via [code reviews](./REVIEWING.md).
- Focus on holistic acceptance of contribution such as dependencies with other
features, backward / forward compatibility, API and flag definitions, etc.
- Expected to be responsive to review requests as per
* Expected to be responsive to review requests as per
[community expectations](./REVIEWING.md).
- Mentor members and contributors.
* Mentor members and contributors.
- Might approve code contributions for acceptance.
* Might approve code contributions for acceptance.
## Lead

View File

@ -100,8 +100,7 @@ working group:
these meetings between 9:00AM to 2:59PM Pacific Time. Invite the public Google
group to the meeting.
- **Register the Working Group**. Go to
[WORKING-GROUPS.md](./WORKING-GROUPS.md)
- **Register the Working Group**. Go to [WORKING-GROUPS.md](./WORKING-GROUPS.md)
and add your working group name, the names of the leads, the working group
charter, and a link to the meeting you created.
@ -189,9 +188,10 @@ Leads from all affected working groups generally work together and come to an
agreeable conclusion.
In all cases, remaining blocking issues can be raised to the
[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve the
situation. To trigger an escalation, create an issue in the `knative/serving`
repo and assign it to the **@knative/tech-oversight-committee** team.
[technical oversight committee](./TECH-OVERSIGHT-COMMITTEE.md) to help resolve
the situation. To trigger an escalation, create an issue in the
`knative/serving` repo and assign it to the
**@knative/tech-oversight-committee** team.
---

View File

@ -12,8 +12,8 @@ each of these groups may operate a little differently depending on their needs
and workflow.
When the need arises, a new working group can be created. See the
[working group processes](./WORKING-GROUP-PROCESSES.md) for working group proposal
and creation procedures.
[working group processes](./WORKING-GROUP-PROCESSES.md) for working group
proposal and creation procedures.
The working groups generate design docs which are kept in a
[shared drive](https://drive.google.com/corp/drive/folders/0APnJ_hRs30R2Uk9PVA)
@ -103,8 +103,7 @@ conventions
## Documentation
Knative documentation, especially the [Docs](../docs/README.md)
repo.
Knative documentation, especially the [Docs](../docs/README.md) repo.
| Artifact | Link |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |

View File

@ -12,7 +12,7 @@ aliases:
Learn how to join the community of Knative contributors.
Also see our [Community page](../community) for links to Knative chats, discussions, or Q&A.
Also see our [Community page](../community) for links to Knative chats,
discussions, or Q&A.
{{% readfile file="README.md" relative="true" markdown="true" %}}

View File

@ -1,8 +1,8 @@
# Documentation Releases
The available versions of the Knative documentation can be found on the
[website](https://www.knative.dev).
You can also view the documentation source files in one of the branches.
[website](https://www.knative.dev). You can also view the documentation source
files in one of the branches.
## Documentation website
@ -10,23 +10,22 @@ Use the Knative Documentation website to learn about the product:
- [`https://www.knative.dev`](https://www.knative.dev)
## `knative/docs` branches
If you want to fix or add content to a past release, you can find the source files
in the following branches:
If you want to fix or add content to a past release, you can find the source
files in the following branches:
* **Released versions**
- **Released versions**
The following branches include content for released versions of Knative:
- [**`release-0.4`**](https://github.com/knative/docs/tree/release-0.4)
- [**`release-0.3`**](https://github.com/knative/docs/tree/release-0.3)
- [**`release-0.2`**](https://github.com/knative/docs/tree/release-0.2)
- [**`release-0.1`**](https://github.com/knative/docs/tree/release-0.1)
- [**`release-0.4`**](https://github.com/knative/docs/tree/release-0.4)
- [**`release-0.3`**](https://github.com/knative/docs/tree/release-0.3)
- [**`release-0.2`**](https://github.com/knative/docs/tree/release-0.2)
- [**`release-0.1`**](https://github.com/knative/docs/tree/release-0.1)
* **Development (pre-release) version**
- **Development (pre-release) version**
The `master` branch includes pre-release content for the next Knative version:
- [**`master`**](https://github.com/knative/docs/tree/master)
- [**`master`**](https://github.com/knative/docs/tree/master)

View File

@ -1,4 +1,3 @@
Knative (pronounced kay-nay-tiv) extends
[Kubernetes](https://kubernetes.io/docs/concepts/overview/what-is-kubernetes/)
to provide a set of middleware components that are essential to build modern,

View File

@ -1,4 +1,3 @@
A `Build` is a custom resource in Knative that allows you to define a process
that runs to completion and can provide status. For example, fetch, build, and
package your code by using a Knative `Build` that communicates whether the
@ -12,9 +11,8 @@ action, you can define a Knative `Build` through a single configuration file.
Also consider using a Knative `Build` to build the source code of your apps into
container images, which you can then run on
[Knative `serving`](../serving/README.md).
More information about this use case is demonstrated in
[this sample](../serving/samples/source-to-url-go).
[Knative `serving`](../serving/README.md). More information about this use case
is demonstrated in [this sample](../serving/samples/source-to-url-go).
## Key features of Knative Builds

View File

@ -35,8 +35,9 @@ Kubernetes cluster, and it must include the Knative Build component:
1. Create a configuration file named `build.yaml` that includes the following
code.
This `Build` resource definition includes a single "[step](./builds.md#steps)"
that performs the task of simply printing "_hello build_":
This `Build` resource definition includes a single
"[step](./builds.md#steps)" that performs the task of simply printing "_hello
build_":
```yaml
apiVersion: build.knative.dev/v1alpha1

View File

@ -62,9 +62,9 @@ Docker daemon, which would give the build complete access to your entire
cluster. So that's a very bad idea.
`kaniko` expects to run inside a container, so it's a natural fit for the Build
CRD [builder contract](../build/builder-contract.md). `kaniko` is available as a builder at
`gcr.io/kaniko-project/executor:latest`, and there's a `BuildTemplate` that
wraps it at
CRD [builder contract](../build/builder-contract.md). `kaniko` is available as a
builder at `gcr.io/kaniko-project/executor:latest`, and there's a
`BuildTemplate` that wraps it at
https://github.com/knative/build-templates/blob/master/kaniko/kaniko.yaml. It
exposes one required parameter, `IMAGE`, which describes the name of the image
to push to.
@ -81,8 +81,8 @@ abstracting away the container image being used, and instead referring to Go
packages by their [import paths](https://golang.org/doc/code.html#ImportPaths)
(e.g., `github.com/kaniko/serving/cmd/controller`)
The typical usage is `ko apply --filename config.yaml`, which reads in the config YAML,
and looks for Go import paths representing runnable commands (i.e.,
The typical usage is `ko apply --filename config.yaml`, which reads in the
config YAML, and looks for Go import paths representing runnable commands (i.e.,
`package main`). When it finds a matching import path, `ko` builds the package
using `go build` then pushes a container image containing that binary on top of
a base image (by default, `gcr.io/distroless/base`) to

View File

@ -1,4 +1,3 @@
Knative Eventing is a system that is designed to address a common need for cloud
native development and provides composable primitives to enable late-binding
event sources and event consumers.
@ -176,7 +175,11 @@ The GitHubSource fires a new event for selected
- `sink`:
[ObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/#objectreference-v1-core)
A reference to the object that should receive events.
- `githubAPIURL`: `string` Optional field to specify the base URL for API requests. Defaults to the public GitHub API if not specified, but can be set to a domain endpoint to use with GitHub Enterprise, for example, `https://github.mycompany.com/api/v3/`. This base URL should always be specified with a trailing slash.
- `githubAPIURL`: `string` Optional field to specify the base URL for API
requests. Defaults to the public GitHub API if not specified, but can be set
to a domain endpoint to use with GitHub Enterprise, for example,
`https://github.mycompany.com/api/v3/`. This base URL should always be
specified with a trailing slash.
See the [GitHub Source](samples/github-source) example.

View File

@ -1,12 +1,11 @@
This is an evolving document on how to debug a non-working Knative Eventing
setup.
## Audience
This document is intended for people that are familiar with the object model of
[Knative Eventing](../README.md). You don't need to be an expert,
but do need to know roughly how things fit together.
[Knative Eventing](../README.md). You don't need to be an expert, but do need to
know roughly how things fit together.
## Version
@ -111,7 +110,10 @@ Verify that the `Pod` is `Ready`:
kubectl --namespace knative-debug get pod -l app=fn -o jsonpath='{.items[*].status.conditions[?(@.type == "Ready")].status}'
```
This should return `True`. If it doesn't, then try to debug the `Deployment` using the [Kubernetes Application Debugging](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application-introspection/) guide.
This should return `True`. If it doesn't, then try to debug the `Deployment`
using the
[Kubernetes Application Debugging](https://kubernetes.io/docs/tasks/debug-application-cluster/debug-application-introspection/)
guide.
##### `svc`

View File

@ -1,4 +1,3 @@
Cron Job Source example shows how to configure Cron Job as event source for
functions.
@ -7,8 +6,7 @@ functions.
### Prerequisites
1. Setup [Knative Serving](../../../serving).
1. Setup
[Knative Eventing](../../../eventing).
1. Setup [Knative Eventing](../../../eventing).
### Create a Knative Service

View File

@ -1,4 +1,3 @@
This sample shows how to configure the GCP PubSub event source. This event
source is most useful as a bridge from other GCP services, such as
[Cloud Storage](https://cloud.google.com/storage/docs/pubsub-notifications),
@ -17,9 +16,8 @@ source is most useful as a bridge from other GCP services, such as
1. Setup [Knative Serving](../../../install)
1. Setup
[Knative Eventing](../../../eventing). In
addition, install the GCP PubSub event source from `release-gcppubsub.yaml`:
1. Setup [Knative Eventing](../../../eventing). In addition, install the GCP
PubSub event source from `release-gcppubsub.yaml`:
```shell
kubectl apply --filename https://github.com/knative/eventing-sources/releases/download/v0.3.0/release-gcppubsub.yaml

View File

@ -1,4 +1,3 @@
This sample shows how to bind a running service to an
[IoT core](https://cloud.google.com/iot-core/) using
[GCP PubSub](https://cloud.google.com/pubsub/) as the event source. With minor
@ -66,8 +65,7 @@ export IOTCORE_TOPIC_DEVICE="iot-demo-device-pubsub-topic"
gcloud pubsub topics create $IOTCORE_TOPIC_DEVICE
```
1. Setup
[Knative Eventing](../../../eventing).
1. Setup [Knative Eventing](../../../eventing).
1. Install the
[in-memory `ClusterChannelProvisioner`](https://github.com/knative/eventing/tree/master/config/provisioners/in-memory-channel).

View File

@ -1,4 +1,3 @@
Kubernetes Event Source example shows how to wire kubernetes cluster events for
consumption by a function that has been implemented as a Knative Service.
@ -7,8 +6,7 @@ consumption by a function that has been implemented as a Knative Service.
### Prerequisites
1. Setup [Knative Serving](../../../serving).
1. Setup
[Knative Eventing](../../../eventing).
1. Setup [Knative Eventing](../../../eventing).
### Channel

View File

@ -1,4 +1,3 @@
This tutorial walks you through creating an event source for Knative Eventing
"the hard way", without using helper objects like ContainerSource.
@ -38,11 +37,11 @@ You'll need these tools installed:
Kubebuilder not your thing? Prefer the easy way? Check out these alternatives.
- [ContainerSource](../../../eventing/sources/README.md#meta-sources)
is an easy way to turn any dispatcher container into an Event Source.
- [Auto ContainerSource](../../../eventing/sources/README.md#meta-sources)
is an even easier way to turn any dispatcher container into an Event Source
without writing any controller code. It requires Metacontroller.
- [ContainerSource](../../../eventing/sources/README.md#meta-sources) is an easy
way to turn any dispatcher container into an Event Source.
- [Auto ContainerSource](../../../eventing/sources/README.md#meta-sources) is an
even easier way to turn any dispatcher container into an Event Source without
writing any controller code. It requires Metacontroller.
- [Metacontroller](https://metacontroller.app) can be used to write controllers
as webhooks in any language.
- The [Cloud Scheduler source](https://github.com/vaikas-google/csr) uses the

View File

@ -49,16 +49,15 @@ These are not directly usable, but make writing a Source much easier.
These are containers intended to be used with `ContainerSource`.
Name | Status | Support | Description
--- | --- | --- | ---
[AWS CodeCommit](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscodecommit) | Active Development | TriggerMesh | Registers for events of the specified types on the specified AWS CodeCommit repository. Brings those events into Knative.
[AWS Cognito](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscognito) | Active Development | TriggerMesh | Registers for AWS Cognito events. Brings those events into Knative.
[AWS DynamoDB](https://github.com/triggermesh/knative-lambda-sources/tree/master/awsdynamodb) | Active Development | TriggerMesh | Registers for events of on the specified AWS DynamoDB table. Brings those events into Knative.
[AWS Kinesis](https://github.com/triggermesh/knative-lambda-sources/tree/master/awskinesis) | Active Development | TriggerMesh | Registers for events on the specified AWS Kinesis stream. Brings those events into Knative.
[AWS SNS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssns) | Active Development | TriggerMesh | Registers for events of the specified AWS SNS endpoint. Brings those events into Knative.
[AWS SQS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssqs) | Active Development | TriggerMesh | Registers for events of the specified AWS SQS queue. Brings those events into Knative.
[Heartbeat](https://github.com/knative/eventing-sources/tree/master/cmd/heartbeats) | Proof of Concept | None | Uses an in-memory timer to produce events at the specified interval.
[Heartbeat](https://github.com/Harwayne/auto-container-source/tree/master/heartbeat-source) | Proof of Concept | None | Uses an in-memory timer to produce events as the specified interval. Uses AutoContainerSource for underlying infrastructure.
[K8s](https://github.com/Harwayne/auto-container-source/tree/master/k8s-event-source) | Proof of Concept | None | Brings Kubernetes cluster events into Knative. Uses AutoContainerSource for underlying infrastructure.
[WebSocket](https://github.com/knative/eventing-sources/tree/master/cmd/websocketsource) | Active Development | None | Opens a WebSocket to the specified source and packages each received message as a Knative event.
| Name | Status | Support | Description |
| ------------------------------------------------------------------------------------------------- | ------------------ | ----------- | ---------------------------------------------------------------------------------------------------------------------------- |
| [AWS CodeCommit](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscodecommit) | Active Development | TriggerMesh | Registers for events of the specified types on the specified AWS CodeCommit repository. Brings those events into Knative. |
| [AWS Cognito](https://github.com/triggermesh/knative-lambda-sources/tree/master/awscognito) | Active Development | TriggerMesh | Registers for AWS Cognito events. Brings those events into Knative. |
| [AWS DynamoDB](https://github.com/triggermesh/knative-lambda-sources/tree/master/awsdynamodb) | Active Development | TriggerMesh | Registers for events of on the specified AWS DynamoDB table. Brings those events into Knative. |
| [AWS Kinesis](https://github.com/triggermesh/knative-lambda-sources/tree/master/awskinesis) | Active Development | TriggerMesh | Registers for events on the specified AWS Kinesis stream. Brings those events into Knative. |
| [AWS SNS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssns) | Active Development | TriggerMesh | Registers for events of the specified AWS SNS endpoint. Brings those events into Knative. |
| [AWS SQS](https://github.com/triggermesh/knative-lambda-sources/tree/master/awssqs) | Active Development | TriggerMesh | Registers for events of the specified AWS SQS queue. Brings those events into Knative. |
| [Heartbeat](https://github.com/knative/eventing-sources/tree/master/cmd/heartbeats) | Proof of Concept | None | Uses an in-memory timer to produce events at the specified interval. |
| [Heartbeat](https://github.com/Harwayne/auto-container-source/tree/master/heartbeat-source) | Proof of Concept | None | Uses an in-memory timer to produce events as the specified interval. Uses AutoContainerSource for underlying infrastructure. |
| [K8s](https://github.com/Harwayne/auto-container-source/tree/master/k8s-event-source) | Proof of Concept | None | Brings Kubernetes cluster events into Knative. Uses AutoContainerSource for underlying infrastructure. |
| [WebSocket](https://github.com/knative/eventing-sources/tree/master/cmd/websocketsource) | Active Development | None | Opens a WebSocket to the specified source and packages each received message as a Knative event. |

View File

@ -156,11 +156,11 @@ Each Knative component must be installed individually. You can decide which
components and observability plugins to install based on what you plan to do
with Knative.
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background info
> and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
### Choosing Knative installation files
@ -198,28 +198,28 @@ files from the Knative repositories:
- [Eventing][4]
- [Eventing Sources][5]
| Knative Install Filename | Notes | Dependencies |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **knative/serving** | | |
| [`serving.yaml`][1.1]† | Installs the Serving component. | Cluster roles enabled, if interacting with Build |
| [`monitoring.yaml`][1.2]† | Installs the [ELK stack][2], [Prometheus][2.1], [Grafana][2.2], and [Zipkin][2.3]**\*** | Serving component |
| [`monitoring-logs-elasticsearch.yaml`][1.3] | Installs only the [ELK stack][2]**\*** | Serving component |
| [`monitoring-metrics-prometheus.yaml`][1.4] | Installs only [Prometheus][2.1]**\*** | Serving component |
| [`monitoring-tracing-zipkin.yaml`][1.5] | Installs only [Zipkin][2.3].**\*** | Serving component, ELK stack (monitoring-logs-elasticsearch.yaml) |
| [`monitoring-tracing-zipkin-in-mem.yaml`][1.6] | Installs only [Zipkin in-memory][2.3]**\*** | Serving component |
| **knative/build** | | |
| [`release.yaml`][3.1]† | Installs the Build component. | Cluster roles enabled, if interacting with Serving |
| **knative/eventing** | | |
| [`release.yaml`][4.1]† | Installs the Eventing component. Includes the in-memory channel provisioner. | Serving component |
| [`eventing.yaml`][4.2] | Installs the Eventing component. Does not include the in-memory channel provisioner. | Serving component |
| [`in-memory-channel.yaml`][4.3] | Installs only the in-memory channel provisioner. | Serving component, Eventing component |
| [`kafka.yaml`][4.4] | Installs only the Kafka channel provisioner. | Serving component, Eventing component |
| **knative/eventing-sources** | | |
| Knative Install Filename | Notes | Dependencies |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------- |
| **knative/serving** | | |
| [`serving.yaml`][1.1]† | Installs the Serving component. | Cluster roles enabled, if interacting with Build |
| [`monitoring.yaml`][1.2]† | Installs the [ELK stack][2], [Prometheus][2.1], [Grafana][2.2], and [Zipkin][2.3]**\*** | Serving component |
| [`monitoring-logs-elasticsearch.yaml`][1.3] | Installs only the [ELK stack][2]**\*** | Serving component |
| [`monitoring-metrics-prometheus.yaml`][1.4] | Installs only [Prometheus][2.1]**\*** | Serving component |
| [`monitoring-tracing-zipkin.yaml`][1.5] | Installs only [Zipkin][2.3].**\*** | Serving component, ELK stack (monitoring-logs-elasticsearch.yaml) |
| [`monitoring-tracing-zipkin-in-mem.yaml`][1.6] | Installs only [Zipkin in-memory][2.3]**\*** | Serving component |
| **knative/build** | | |
| [`release.yaml`][3.1]† | Installs the Build component. | Cluster roles enabled, if interacting with Serving |
| **knative/eventing** | | |
| [`release.yaml`][4.1]† | Installs the Eventing component. Includes the in-memory channel provisioner. | Serving component |
| [`eventing.yaml`][4.2] | Installs the Eventing component. Does not include the in-memory channel provisioner. | Serving component |
| [`in-memory-channel.yaml`][4.3] | Installs only the in-memory channel provisioner. | Serving component, Eventing component |
| [`kafka.yaml`][4.4] | Installs only the Kafka channel provisioner. | Serving component, Eventing component |
| **knative/eventing-sources** | | |
| [`release.yaml`][5.1]† | Installs the following sources: [Kubernetes][6], [GitHub][6.1], [Container image][../eventing#containersource], [CronJob][6.2] | Serving component, Eventing component |
| [`release-gcppubsub.yaml`][5.2] | Installs the following sources: [PubSub][6.3] | Serving component, Eventing component |
| [`message-dumper.yaml`][5.3] | Installs an Event logging service for debugging. | Serving component, Eventing component |
| **Cluster roles** | | |
| [`clusterrole.yaml`][7]† | Enables the Build and Serving components to interact. | Serving component, Build component |
| [`release-gcppubsub.yaml`][5.2] | Installs the following sources: [PubSub][6.3] | Serving component, Eventing component |
| [`message-dumper.yaml`][5.3] | Installs an Event logging service for debugging. | Serving component, Eventing component |
| **Cluster roles** | | |
| [`clusterrole.yaml`][7]† | Enables the Build and Serving components to interact. | Serving component, Build component |
_\*_ See
[Installing logging, metrics, and traces](../serving/installing-logging-metrics-traces.md)
@ -228,6 +228,7 @@ for details about installing the various supported observability plug-ins.
† These are the recommended standard install files suitable for most use cases.
<!-- USE ONLY FULLY QUALIFIED URLS -->
[1]: https://github.com/knative/serving/releases/tag/v0.4.0
[1.1]: https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml
[1.2]:
@ -268,7 +269,8 @@ for details about installing the various supported observability plug-ins.
[6.2]:
https://github.com/knative/eventing-sources/blob/master/samples/cronjob-source/README.md
[6.3]: https://cloud.google.com/pubsub/
[7]: https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
[7]:
https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
### Installing Knative
@ -277,21 +279,24 @@ commands below.
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. To install Knative components or plugins, specify the filenames in the
`kubectl apply` command:
@ -324,14 +329,16 @@ commands below.
**Example install commands:**
* To install the Knative Serving component with the set of observability plug-ins:
- To install the Knative Serving component with the set of observability
plug-ins:
```bash
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml
```
* To install all three Knative components and the set of Eventing sources without an observability plugin:
* To install all three Knative components and the set of Eventing sources
without an observability plugin:
```bash
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \
@ -393,4 +400,3 @@ Except as otherwise noted, the content of this page is licensed under the
[Creative Commons Attribution 4.0 License](https://creativecommons.org/licenses/by/4.0/),
and code samples are licensed under the
[Apache 2.0 License](https://www.apache.org/licenses/LICENSE-2.0).

View File

@ -175,23 +175,27 @@ your Knative installation, see
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Run the `kubectl apply` command to install Knative and its dependencies:
```bash
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \
--filename https://github.com/knative/build/releases/download/v0.4.0/build.yaml \
@ -200,14 +204,16 @@ your Knative installation, see
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
```
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background
> info and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
1. Monitor the Knative components until all of the components show a `STATUS` of
`Running`:

View File

@ -64,8 +64,8 @@ rerun the command to see the current status.
Next, install [Knative Serving](https://github.com/knative/serving).
Because you have limited resources available, use the
`https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml`
file, which installs only Knative Serving:
`https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml` file,
which installs only Knative Serving:
```shell
curl -L https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \

View File

@ -176,21 +176,24 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Run the `kubectl apply` command to install Knative and its dependencies:
```bash
@ -201,14 +204,15 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
```
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background
> info and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
1. Monitor the Knative components until all of the components show a `STATUS` of
`Running`:
```bash

View File

@ -91,8 +91,8 @@ Knative depends on Istio.
kubectl label namespace default istio-injection=enabled
```
3. Monitor the Istio components until all of the components show a `STATUS` of
`Running` or `Completed`:
```bash
`Running` or `Completed`:
```bash
kubectl get pods --namespace istio-system`
```
@ -111,23 +111,27 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Run the `kubectl apply` command to install Knative and its dependencies:
```bash
kubectl apply --filename https://github.com/knative/serving/releases/download/v0.4.0/serving.yaml \
--filename https://github.com/knative/build/releases/download/v0.4.0/build.yaml \
@ -136,14 +140,17 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
```
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background
> info and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
1. Monitor the Knative components until all of the components show a `STATUS` of
`Running`:
```bash

View File

@ -99,8 +99,8 @@ curl -H "Host: helloworld-go.myproject.example.com" $GATEWAY_URL
```
The full instructions for the
[Go Hello-World Sample](../serving/samples/hello-world/helloworld-go) with this substitution
are published bellow:
[Go Hello-World Sample](../serving/samples/hello-world/helloworld-go) with this
substitution are published bellow:
### Deploy the Hello-World Go App:
@ -258,8 +258,8 @@ Hello Go Sample v1!
> Note: Add `-v` option to get more detail if the `curl` command failed.
Removing the sample app deployment
To remove the sample app from your cluster, delete the service record:
Removing the sample app deployment To remove the sample app from your cluster,
delete the service record:
```bash
kubectl delete --filename service.yaml

View File

@ -133,21 +133,24 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Run the following commands to install Knative:
@ -186,15 +189,17 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
| sed 's/LoadBalancer/NodePort/' \
| kubectl apply --filename -
```
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background
> info and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
See
[Installing logging, metrics, and traces](../serving/installing-logging-metrics-traces.md)
for details about installing the various supported observability plug-ins.

View File

@ -172,21 +172,24 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Run the `kubectl apply` command to install Knative and its dependencies:
```bash
@ -197,14 +200,15 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
```
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background
> info and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
1. Monitor the Knative components until all of the components show a `STATUS` of
`Running`:
```bash

View File

@ -98,23 +98,24 @@ component, omitting the other Knative components as well as the observability
and monitoring plugins.
If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
address to be associated with the LoadBalancer `istio-ingressgateway` instead of
`knative-ingressgateway`. Then run the following to clean up leftover resources:
```shell
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also need
to delete the following resource before upgrading:
```shell
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not prevent
modifications to Eventing Source resources, those changes will not be completed
until the upgrade process finishes.
Enter the following command:

View File

@ -7,9 +7,9 @@ type: "docs"
This guide walks you through the installation of the latest version of
[Knative Serving](https://github.com/knative/serving) on an
[OpenShift](https://github.com/openshift/origin) Minishift server using pre-built images and
demonstrates creating and deploying an image of a sample "hello world" app onto
the newly created Knative cluster.
[OpenShift](https://github.com/openshift/origin) Minishift server using
pre-built images and demonstrates creating and deploying an image of a sample
"hello world" app onto the newly created Knative cluster.
You can find [guides for other platforms here](./README.md).
@ -154,8 +154,8 @@ until oc login -u admin -p admin; do sleep 5; done;
### Installing Istio
Knative depends on Istio. The
[istio-openshift-policies.sh](./scripts/istio-openshift-policies.sh) does run the
required commands to configure necessary
[istio-openshift-policies.sh](./scripts/istio-openshift-policies.sh) does run
the required commands to configure necessary
[privileges](https://istio.io/docs/setup/kubernetes/platform-setup/openshift/)
to the service accounts used by Istio.
@ -190,9 +190,9 @@ curl -s https://raw.githubusercontent.com/knative/docs/master/docs/install/scrip
The following section details on deploying
[Knative Serving](https://github.com/knative/serving) to OpenShift.
The [knative-openshift-policies.sh](./scripts/knative-openshift-policies.sh) runs
the required commands to configure necessary privileges to the service accounts
used by Knative.
The [knative-openshift-policies.sh](./scripts/knative-openshift-policies.sh)
runs the required commands to configure necessary privileges to the service
accounts used by Knative.
```shell
curl -s https://raw.githubusercontent.com/knative/docs/master/docs/install/scripts/knative-openshift-policies.sh | bash
@ -207,21 +207,24 @@ curl -s https://raw.githubusercontent.com/knative/docs/master/docs/install/scrip
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
oc delete svc knative-ingressgateway -n istio-system
oc delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
oc delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Install Knative serving:
@ -230,8 +233,10 @@ curl -s https://raw.githubusercontent.com/knative/docs/master/docs/install/scrip
oc apply --filename https://github.com/knative/build/releases/download/v0.4.0/build.yaml \
oc apply --filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
```
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
1. Monitor the Knative components until all of the components show a `STATUS` of
`Running` or `Completed`:

View File

@ -54,7 +54,8 @@ Once the script completes, you'll be ready to test out Knative!
## Creating a new OpenShift cluster
Here are the manual steps which the above script automates for you in case you prefer doing this yourself:
Here are the manual steps which the above script automates for you in case you
prefer doing this yourself:
Create a new OpenShift cluster on your local machine using `oc cluster up`:

View File

@ -85,21 +85,24 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```
kubectl delete svc knative-ingressgateway -n istio-system
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Run the `kubectl apply` command to install Knative and its dependencies:
```bash
@ -110,14 +113,15 @@ see [Performing a Custom Knative Installation](./Knative-custom-install.md).
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
```
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background
> info and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
1. Monitor the Knative components until all of the components show a `STATUS` of
`Running`:
```bash

View File

@ -41,6 +41,7 @@ Containers.
```bash
kubectl label namespace default istio-injection=enabled
```
1. Monitor the Istio components until all of the components show a `STATUS` of
`Running` or `Completed`:
@ -63,7 +64,7 @@ your Knative installation, see
1. If you are upgrading from Knative 0.3.x: Update your domain and static IP
address to be associated with the LoadBalancer `istio-ingressgateway` instead
of `knative-ingressgateway`. Then run the following to clean up leftover
of `knative-ingressgateway`. Then run the following to clean up leftover
resources:
```bash
@ -71,14 +72,16 @@ your Knative installation, see
kubectl delete deploy knative-ingressgateway -n istio-system
```
If you have the Knative Eventing Sources component installed,
you will also need to delete the following resource before upgrading:
If you have the Knative Eventing Sources component installed, you will also
need to delete the following resource before upgrading:
```
kubectl delete statefulset/controller-manager -n knative-sources
```
While the deletion of this resource during the upgrade process will
not prevent modifications to Eventing Source resources, those changes will
not be completed until the upgrade process finishes.
While the deletion of this resource during the upgrade process will not
prevent modifications to Eventing Source resources, those changes will not be
completed until the upgrade process finishes.
1. Run the `kubectl apply` command to install Knative and its dependencies:
@ -90,14 +93,16 @@ your Knative installation, see
--filename https://github.com/knative/serving/releases/download/v0.4.0/monitoring.yaml \
--filename https://raw.githubusercontent.com/knative/serving/v0.4.0/third_party/config/build/clusterrole.yaml
```
> **Note**: If your install fails on the first attempt, try rerunning the commands.
They will likely succeed on the second attempt. For background info and to
track the upcoming solution to this problem, see issues
[#968](https://github.com/knative/docs/issues/968) and
[#1036](https://github.com/knative/docs/issues/1036).
> **Note**: If your install fails on the first attempt, try rerunning the
> commands. They will likely succeed on the second attempt. For background
> info and to track the upcoming solution to this problem, see issues
> [#968](https://github.com/knative/docs/issues/968) and
> [#1036](https://github.com/knative/docs/issues/1036).
> **Note**: For the v0.4.0 release and newer, the `clusterrole.yaml` file is
> required to enable the Build and Serving components to interact with each other.
> required to enable the Build and Serving components to interact with each
> other.
1. Monitor the Knative components until all of the components show a `STATUS` of
`Running`:

View File

@ -1,4 +1,3 @@
Follow this guide to install Knative components on a platform of your choice.
## Choosing a Kubernetes cluster

View File

@ -20,9 +20,9 @@ You need:
## Sample application
This guide uses the
[Hello World sample app in Go](../serving/samples/hello-world/helloworld-go) to demonstrate
the basic workflow for deploying an app, but these steps can be adapted for your
own application if you have an image of it available on
[Hello World sample app in Go](../serving/samples/hello-world/helloworld-go) to
demonstrate the basic workflow for deploying an app, but these steps can be
adapted for your own application if you have an image of it available on
[Docker Hub](https://docs.docker.com/docker-hub/repos/),
[Google Container Registry](https://cloud.google.com/container-registry/docs/pushing-and-pulling),
or another container image registry.

View File

@ -14,7 +14,6 @@ The API source files are located at:
- [Eventing API](./eventing/eventing.md)
- [Event Sources API](./eventing/eventing-sources.md)
## Updating API Reference docs (for Knative maintainers)
The Knative API reference documentation is manually generated using the
@ -31,78 +30,78 @@ reference page.
You must meet the following requirements to run the `gen-api-reference-docs.sh`
tool:
* You need the following software installed:
* [`git`](https://git-scm.com/download/)
* [`go` version 1.11+](https://golang.org/dl/)
* Clone [knative/docs](https://github.com/knative/docs)
locally. For example: `git clone git@github.com:knative/docs.git`
- You need the following software installed:
- [`git`](https://git-scm.com/download/)
- [`go` version 1.11+](https://golang.org/dl/)
- Clone [knative/docs](https://github.com/knative/docs) locally. For example:
`git clone git@github.com:knative/docs.git`
### Generating the API
To generate a version of the API:
1. Ensure that your `GOPATH` is empty. The `gen-api-reference-docs.sh`
script will result in the `GOPATH should not be set` error if your `GOPATH`
is configured. You view the value by running the following command:
1. Ensure that your `GOPATH` is empty. The `gen-api-reference-docs.sh` script
will result in the `GOPATH should not be set` error if your `GOPATH` is
configured. You view the value by running the following command:
```
echo $GOPATH
```
```
echo $GOPATH
```
If your `GOPATH` is already configured, temporarily clear the `GOPATH` value
by running the following command:
```
export GOPATH=""
```
```
export GOPATH=""
```
1. Locate the commits or tags that correspond to the version of the API
that you want to generate:
1. Locate the commits or tags that correspond to the version of the API that you
want to generate:
* [Build](https://github.com/knative/build/releases/)
* [Eventing](https://github.com/knative/eventing/releases/)
* [Eventing Sources](https://github.com/knative/eventing-sources/releases/)
* [Serving](https://github.com/knative/serving/releases/)
- [Build](https://github.com/knative/build/releases/)
- [Eventing](https://github.com/knative/eventing/releases/)
- [Eventing Sources](https://github.com/knative/eventing-sources/releases/)
- [Serving](https://github.com/knative/serving/releases/)
1. To run the `gen-api-reference-docs.sh` command from the `hack` directory,
you specify the commits or tags for each of the corresponding Knative
component variables (`KNATIVE_[component_name]_COMMIT`):
1. To run the `gen-api-reference-docs.sh` command from the `hack` directory, you
specify the commits or tags for each of the corresponding Knative component
variables (`KNATIVE_[component_name]_COMMIT`):
```
KNATIVE_BUILD_COMMIT=[commit_or_tag] \
KNATIVE_EVENTING_COMMIT=[commit_or_tag] \
KNATIVE_EVENTING_SOURCES_COMMIT=[commit_or_tag] \
KNATIVE_SERVING_COMMIT=[commit_or_tag] \
./gen-api-reference-docs.sh
```
```
KNATIVE_BUILD_COMMIT=[commit_or_tag] \
KNATIVE_EVENTING_COMMIT=[commit_or_tag] \
KNATIVE_EVENTING_SOURCES_COMMIT=[commit_or_tag] \
KNATIVE_SERVING_COMMIT=[commit_or_tag] \
./gen-api-reference-docs.sh
```
where `[commit_or_tag]` is the commit or tag in the specific repo that
represents the version of the API that you want to generate. Also see
the [example](#example) below.
where `[commit_or_tag]` is the commit or tag in the specific repo that
represents the version of the API that you want to generate. Also see the
[example](#example) below.
**Result**
**Result**
The `gen-api-reference-docs.sh` tool generates the API in a `tmp` folder.
After a successful build, the tool automatically opens that folder
in the `tmp` directory.
The `gen-api-reference-docs.sh` tool generates the API in a `tmp` folder.
After a successful build, the tool automatically opens that folder in the
`tmp` directory.
1. Copy the generated API files into the `docs/reference` directory of your
knative/docs clone.
You can now perform the necessary steps to open a PR, complete a review, and
merge the new API files into the appropriate branch of the `knative/docs` repo.
See the [contributor flow](../../contributing/DOCS-CONTRIBUTING.md) for
details about requesting changes in the `knative/docs` repo.
See the [contributor flow](../../contributing/DOCS-CONTRIBUTING.md) for details
about requesting changes in the `knative/docs` repo.
### Example
To build a set of Knative API docs for v0.3, you can use the `v0.3.0` the tags
from each of the Knative component repositories, like
[Serving v0.3.0](https://github.com/knative/serving/tree/v0.3.0). If you want to
use a commit for Serving v0.3.0, you would use
use a commit for Serving v0.3.0, you would use
[4d198d](https://github.com/knative/serving/commit/4d198db8756db2f8a3c228302a97fb3a216a9475).
Using tags from each repo, you would run the following command to generate the
Using tags from each repo, you would run the following command to generate the
v0.3.0 API source files:
```

View File

@ -1,4 +1,3 @@
Knative Serving builds on Kubernetes and Istio to support deploying and serving
of serverless applications and functions. Serving is easy to get started with
and scales to support advanced scenarios.
@ -40,9 +39,9 @@ serverless workload behaves on the cluster:
## Getting Started
To get started with Serving, check out one of the [hello world](./samples/) sample
projects. These projects use the `Service` resource, which manages all of the
details for you.
To get started with Serving, check out one of the [hello world](./samples/)
sample projects. These projects use the `Service` resource, which manages all of
the details for you.
With the `Service` resource, a deployed service will automatically have a
matching route and configuration created. Each time the `Service` is updated, a
@ -80,6 +79,7 @@ in the Knative Serving repository.
- [Assigning a static IP address for Knative on Google Kubernetes Engine](./gke-assigning-static-ip-address.md)
## Private Container Registry
- [Deploying to Knative using a Private Container Registry](./deploying-with-private-registry.md)
## Known Issues

View File

@ -194,8 +194,9 @@ kubectl get build $(kubectl get revision <revision-name> --output jsonpath="{.sp
If there is any failure, the `conditions` in `status` provide the reason. To
access build logs, first execute `kubectl proxy` and then open
[Kibana UI](http://localhost:8001/api/v1/namespaces/knative-monitoring/services/kibana-logging/proxy/app/kibana).
Use any of the following filters within Kibana UI to see build logs. For more information about the Knative
observability features, see [Installing logging, metrics, and traces](./Installing-logging-metrics-traces.md).
Use any of the following filters within Kibana UI to see build logs. For more
information about the Knative observability features, see
[Installing logging, metrics, and traces](./Installing-logging-metrics-traces.md).
- All build logs: `_exists_:"kubernetes.labels.build-name"`
- Build logs for a specific build: `kubernetes.labels.build-name:"<BUILD NAME>"`

View File

@ -5,8 +5,13 @@ weight: 10
type: "docs"
---
This guide walks you through deploying an application to Knative from source code in a git repository using a private container registry for the container image. The source code should contain a dockerfile. For this guide, we'll use this [helloworld app](./samples/hello-world/helloworld-go), but you could use your own.
>>>>>>> fe15327... explicit template types (#1061)
This guide walks you through deploying an application to Knative from source
code in a git repository using a private container registry for the container
image. The source code should contain a dockerfile. For this guide, we'll use
this [helloworld app](./samples/hello-world/helloworld-go), but you could use
your own.
> > > > > > > fe15327... explicit template types (#1061)
This guide walks you through deploying an application to Knative from source
code in a git repository using a private container registry for the container
@ -15,161 +20,193 @@ this [helloworld app](./samples/hello-world/helloworld-go), but you could use
your own.
## Set up a private container registry and obtain credentials
If you do not want your container image to be publicly available, you may want to use a private container registry. In this example, we'll use IBM Container Registry, but most of these concepts will be similar for other clouds.
1. Ensure you have the [IBM Cloud CLI](https://cloud.ibm.com/docs/cli/reference/ibmcloud/download_cli.html#install_use) installed.
If you do not want your container image to be publicly available, you may want
to use a private container registry. In this example, we'll use IBM Container
Registry, but most of these concepts will be similar for other clouds.
1. Ensure you have the
[IBM Cloud CLI](https://cloud.ibm.com/docs/cli/reference/ibmcloud/download_cli.html#install_use)
installed.
1. Install the container registry plugin:
```
ibmcloud plugin install container-registry
```
```
ibmcloud plugin install container-registry
```
1. Choose a name for your first namespace, and then create it:
```
ibmcloud cr namespace-add <my_namespace>
```
```
ibmcloud cr namespace-add <my_namespace>
```
A namespace represents the spot within a registry that holds your images. You can set up multiple namespaces as well as control access to your namespaces by using IAM policies.
A namespace represents the spot within a registry that holds your images. You
can set up multiple namespaces as well as control access to your namespaces
by using IAM policies.
1. Create a token:
```
ibmcloud cr token-add --description "token description" --non-expiring --readwrite
```
```
ibmcloud cr token-add --description "token description" --non-expiring --readwrite
```
The automated build processes you'll be setting up will use this token to access your images.
The automated build processes you'll be setting up will use this token to
access your images.
1. The CLI output should include a token identifier and the token. Make note of the token. You can verify that the token was created by listing all tokens:
1. The CLI output should include a token identifier and the token. Make note of
the token. You can verify that the token was created by listing all tokens:
```
ibmcloud cr token-list
```
```
ibmcloud cr token-list
```
## Provide container registry credentials to Knative
You will use the credentials you obtained in the previous section to authenticate to your private container registry. First, you'll need to create a secret to store the credentials for this registry. This secret will be used to push the built image to the container registry.
A Secret is a Kubernetes object containing sensitive data such as a password, a token, or a key. You can also read more about [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
You will use the credentials you obtained in the previous section to
authenticate to your private container registry. First, you'll need to create a
secret to store the credentials for this registry. This secret will be used to
push the built image to the container registry.
A Secret is a Kubernetes object containing sensitive data such as a password, a
token, or a key. You can also read more about
[Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
1. Create a file named `registry-push-secret.yaml` containing the following:
```yaml
apiVersion: v1
kind: Secret
metadata:
name: registry-push-secret
annotations:
build.knative.dev/docker-0: https://registry.ng.bluemix.net
type: kubernetes.io/basic-auth
stringData:
username: token
password: <token_value>
```
```yaml
apiVersion: v1
kind: Secret
metadata:
name: registry-push-secret
annotations:
build.knative.dev/docker-0: https://registry.ng.bluemix.net
type: kubernetes.io/basic-auth
stringData:
username: token
password: <token_value>
```
1. Update the "password" with your <token_value>. Note that username will be the string `token`. Save the file.
1. Update the "password" with your <token_value>. Note that username will be the
string `token`. Save the file.
1. Apply the secret to your cluster.
```bash
kubectl apply --filename registry-push-secret.yaml
```
```bash
kubectl apply --filename registry-push-secret.yaml
```
1. You will also need a secret for the knative-serving component to pull down an image from the private container registry. This secret will be a `docker-registry` type secret. You can create this via the commandline. For username, simply use the string `token`. For <token_value>, use the token you made note of earlier.
1. You will also need a secret for the knative-serving component to pull down an
image from the private container registry. This secret will be a
`docker-registry` type secret. You can create this via the commandline. For
username, simply use the string `token`. For <token_value>, use the token you
made note of earlier.
```bash
kubectl create secret docker-registry ibm-cr-secret --docker-server=https://registry.ng.bluemix.net --docker-username=token --docker-password=<token_value>
```
```bash
kubectl create secret docker-registry ibm-cr-secret --docker-server=https://registry.ng.bluemix.net --docker-username=token --docker-password=<token_value>
```
A Service Account provides an identity for processes that run in a Pod. This Service Account will be used to link the build process for Knative to the Secrets you just created.
A Service Account provides an identity for processes that run in a Pod. This
Service Account will be used to link the build process for Knative to the
Secrets you just created.
1. Create a file named `service-account.yaml` containing the following:
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: build-bot
secrets:
- name: registry-push-secret
imagePullSecrets:
- name: ibm-cr-secret
```
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: build-bot
secrets:
- name: registry-push-secret
imagePullSecrets:
- name: ibm-cr-secret
```
1. Apply the service account to your cluster:
```bash
kubectl apply --filename service-account.yaml
```
```bash
kubectl apply --filename service-account.yaml
```
## Deploy to Knative
To build our application from the source on GitHub, and push the resulting image to the IBM Container Registry, we will use the Kaniko build template.
To build our application from the source on GitHub, and push the resulting image
to the IBM Container Registry, we will use the Kaniko build template.
1. Install the Kaniko build template
```bash
kubectl apply --filename https://raw.githubusercontent.com/knative/build-templates/master/kaniko/kaniko.yaml
```
```bash
kubectl apply --filename https://raw.githubusercontent.com/knative/build-templates/master/kaniko/kaniko.yaml
```
1. You need to create a service manifest which defines the service to deploy, including where the source code is and which build-template to use. Create a file named `service.yaml` and copy the following definition. Make sure to replace {NAMESPACE} with your own namespace you created earlier:
1. You need to create a service manifest which defines the service to deploy,
including where the source code is and which build-template to use. Create a
file named `service.yaml` and copy the following definition. Make sure to
replace {NAMESPACE} with your own namespace you created earlier:
```yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
runLatest:
configuration:
build:
apiVersion: build.knative.dev/v1alpha1
kind: Build
spec:
serviceAccountName: build-bot
source:
git:
url: https://github.com/knative/docs
revision: master
subPath: docs/serving/samples/hello-world/helloworld-go
template:
name: kaniko
arguments:
- name: IMAGE
value: registry.ng.bluemix.net/{NAMESPACE}/helloworld-go:latest
revisionTemplate:
spec:
serviceAccountName: build-bot
container:
image: registry.ng.bluemix.net/{NAMESPACE}/helloworld-go:latest
imagePullPolicy: Always
env:
- name: TARGET
value: "Go Sample v1"
```
```yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: helloworld-go
namespace: default
spec:
runLatest:
configuration:
build:
apiVersion: build.knative.dev/v1alpha1
kind: Build
spec:
serviceAccountName: build-bot
source:
git:
url: https://github.com/knative/docs
revision: master
subPath: docs/serving/samples/hello-world/helloworld-go
template:
name: kaniko
arguments:
- name: IMAGE
value: registry.ng.bluemix.net/{NAMESPACE}/helloworld-go:latest
revisionTemplate:
spec:
serviceAccountName: build-bot
container:
image: registry.ng.bluemix.net/{NAMESPACE}/helloworld-go:latest
imagePullPolicy: Always
env:
- name: TARGET
value: "Go Sample v1"
```
1. Apply the configuration using `kubectl`:
```bash
kubectl apply --filename service.yaml
```
```bash
kubectl apply --filename service.yaml
```
Applying this service definition will kick off a series of events:
- Fetches the revision specified from GitHub and builds it into a container, using the Kaniko build template.
- Pushes the latest image to the private registry using the registry-push-secret
- Pulls down the latest image from the private registry using the ibm-cr-secret.
- Starts the service, and your app will be live.
Applying this service definition will kick off a series of events:
- Fetches the revision specified from GitHub and builds it into a container,
using the Kaniko build template.
- Pushes the latest image to the private registry using the
registry-push-secret
- Pulls down the latest image from the private registry using the
ibm-cr-secret.
- Starts the service, and your app will be live.
1. You can run `kubectl get pods --watch` to see the pods initializing.
1. Once all the pods are initialized, you can see that your container image was built and pushed to the IBM Container Registry:
1. Once all the pods are initialized, you can see that your container image was
built and pushed to the IBM Container Registry:
```
ibmcloud cr image-list
```
```
ibmcloud cr image-list
```
## Test Application Behavior
1. Run the following command to find the external IP address for your service:
```shell

View File

@ -45,9 +45,9 @@ which allows sending logs to Stackdriver.
Operators can build this image and push it to a container registry which their
Kubernetes cluster has access to. See
[Setting Up A Logging Plugin](../setting-up-a-logging-plugin.md) for
details. **NOTE**: Operators need to add credentials file the stackdriver agent
needs to the docker image if their Knative Serving is not built on a GCP based
cluster or they want to send logs to another GCP project. See
[Setting Up A Logging Plugin](../setting-up-a-logging-plugin.md) for details.
**NOTE**: Operators need to add credentials file the stackdriver agent needs to
the docker image if their Knative Serving is not built on a GCP based cluster or
they want to send logs to another GCP project. See
[here](https://cloud.google.com/logging/docs/agent/authorization) for more
information.

View File

@ -35,7 +35,9 @@ Using the Google Cloud SDK:
```shell
gcloud beta compute addresses create IP_NAME --region=REGION
```
For example:
```shell
gcloud beta compute addresses create knative-ip --region=us-west1
```

View File

@ -158,8 +158,8 @@ To configure and setup monitoring:
```
1. Choose a container image that meets the
[Fluentd image requirements](./fluentd-requirements.md#requirements).
For example, you can use a public image. Or you can create a custom one and
[Fluentd image requirements](./fluentd-requirements.md#requirements). For
example, you can use a public image. Or you can create a custom one and
upload the image to a container registry which your cluster has read access
to.

View File

@ -1,20 +1,20 @@
Use the following sample applications to help you understand the various
Knative Serving resources and how they can be applied across common use cases.
Use the following sample applications to help you understand the various Knative
Serving resources and how they can be applied across common use cases.
[Learn more about Knative Serving resources](../README.md).
| Name | Description | Languages |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| Name | Description | Languages |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------: |
| Hello World | A quick introduction that highlights how to deploy an app using Knative Serving. | [C#](./hello-world/helloworld-csharp/README.md), [Go](./hello-world/helloworld-go/README.md), [Java](./hello-world/helloworld-java/README.md), [Kotlin](./hello-world/helloworld-kotlin/README.md), [Node.js](./hello-world/helloworld-nodejs/README.md), [PHP](./hello-world/helloworld-php/README.md), [Python](./hello-world/helloworld-python/README.md), [Ruby](./hello-world/helloworld-ruby/README.md), [Scala](./hello-world/helloworld-scala/README.md) |
| Advanced Deployment | Simple blue/green-like application deployment pattern illustrating the process of updating a live application without dropping any traffic. | [YAML](./blue-green-deployment.md) |
| Autoscale | A demonstration of the autoscaling capabilities of Knative. | [Go](./autoscale-go/README.md) |
| Private Repo Build | An example of deploying a Knative Serving Service using a Github deploy-key and a DockerHub image pull secret. | [Go](./build-private-repo-go/README.md) |
| Buildpack for Applications | A sample app that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [.NET](./buildpack-app-dotnet/README.md) |
| Buildpack for Functions | A sample function that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [Node.js](./buildpack-function-nodejs/README.md) |
| Github Webhook | A simple webhook handler that demonstrates interacting with Github. | [Go](./gitwebhook-go/README.md) |
| gRPC | A simple gRPC server. | [Go](./grpc-ping-go/README.md) |
| Knative Routing | An example of mapping multiple Knative services to different paths under a single domain name using the Istio VirtualService concept. | [Go](./knative-routing-go/README.md) |
| REST API | A simple Restful service that exposes an endpoint defined by an environment variable described in the Knative Configuration. | [Go](./rest-api-go/README.md) |
| Source to URL | A sample that shows how to use Knative to go from source code in a git repository to a running application with a URL. | [Go](./source-to-url-go/README.md) |
| Telemetry | This sample runs a simple web server that makes calls to other in-cluster services and responds to requests with "Hello World!". The purpose of this sample is to show generating metrics, logs, and distributed traces. | [Go](./telemetry-go/README.md) |
| Thumbnailer | An example of deploying a "dockerized" application to Knative Serving which takes video URL as an input and generates its thumbnail image. | [Go](./thumbnailer-go/README.md) |
| Traffic Splitting | This samples builds off the [Creating a RESTful Service](./rest-api-go) sample to illustrate applying a revision, then using that revision for manual traffic splitting. | [YAML](./traffic-splitting/README.md) |
| Advanced Deployment | Simple blue/green-like application deployment pattern illustrating the process of updating a live application without dropping any traffic. | [YAML](./blue-green-deployment.md) |
| Autoscale | A demonstration of the autoscaling capabilities of Knative. | [Go](./autoscale-go/README.md) |
| Private Repo Build | An example of deploying a Knative Serving Service using a Github deploy-key and a DockerHub image pull secret. | [Go](./build-private-repo-go/README.md) |
| Buildpack for Applications | A sample app that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [.NET](./buildpack-app-dotnet/README.md) |
| Buildpack for Functions | A sample function that demonstrates using Cloud Foundry buildpacks on Knative Serving. | [Node.js](./buildpack-function-nodejs/README.md) |
| Github Webhook | A simple webhook handler that demonstrates interacting with Github. | [Go](./gitwebhook-go/README.md) |
| gRPC | A simple gRPC server. | [Go](./grpc-ping-go/README.md) |
| Knative Routing | An example of mapping multiple Knative services to different paths under a single domain name using the Istio VirtualService concept. | [Go](./knative-routing-go/README.md) |
| REST API | A simple Restful service that exposes an endpoint defined by an environment variable described in the Knative Configuration. | [Go](./rest-api-go/README.md) |
| Source to URL | A sample that shows how to use Knative to go from source code in a git repository to a running application with a URL. | [Go](./source-to-url-go/README.md) |
| Telemetry | This sample runs a simple web server that makes calls to other in-cluster services and responds to requests with "Hello World!". The purpose of this sample is to show generating metrics, logs, and distributed traces. | [Go](./telemetry-go/README.md) |
| Thumbnailer | An example of deploying a "dockerized" application to Knative Serving which takes video URL as an input and generates its thumbnail image. | [Go](./thumbnailer-go/README.md) |
| Traffic Splitting | This samples builds off the [Creating a RESTful Service](./rest-api-go) sample to illustrate applying a revision, then using that revision for manual traffic splitting. | [YAML](./traffic-splitting/README.md) |

View File

@ -1,120 +1,118 @@
A demonstration of the autoscaling capabilities of a Knative Serving Revision.
## Prerequisites
1. A Kubernetes cluster with [Knative Serving](../../../install/README.md)
installed.
1. A
[metrics installation](../../installing-logging-metrics-traces.md)
for viewing scaling graphs (optional).
1. A [metrics installation](../../installing-logging-metrics-traces.md) for
viewing scaling graphs (optional).
1. The `hey` load generator installed (`go get -u github.com/rakyll/hey`).
1. Clone this repository, and move into the sample directory:
```shell
git clone https://github.com/knative/docs knative-docs
cd knative-docs
```
```shell
git clone https://github.com/knative/docs knative-docs
cd knative-docs
```
## Deploy the Service
1. Deploy the [sample](./service.yaml) Knative Service:
```
kubectl apply --filename docs/serving/samples/autoscale-go/service.yaml
```
```
kubectl apply --filename docs/serving/samples/autoscale-go/service.yaml
```
1. Find the ingress hostname and IP and export as an environment variable:
```shell
# In Knative 0.2.x and prior versions, the `knative-ingressgateway` service was used instead of `istio-ingressgateway`.
INGRESSGATEWAY=knative-ingressgateway
```shell
# In Knative 0.2.x and prior versions, the `knative-ingressgateway` service was used instead of `istio-ingressgateway`.
INGRESSGATEWAY=knative-ingressgateway
# The use of `knative-ingressgateway` is deprecated in Knative v0.3.x.
# Use `istio-ingressgateway` instead, since `knative-ingressgateway`
# will be removed in Knative v0.4.
if kubectl get configmap config-istio -n knative-serving &> /dev/null; then
INGRESSGATEWAY=istio-ingressgateway
fi
# The use of `knative-ingressgateway` is deprecated in Knative v0.3.x.
# Use `istio-ingressgateway` instead, since `knative-ingressgateway`
# will be removed in Knative v0.4.
if kubectl get configmap config-istio -n knative-serving &> /dev/null; then
INGRESSGATEWAY=istio-ingressgateway
fi
export IP_ADDRESS=`kubectl get svc $INGRESSGATEWAY --namespace istio-system --output jsonpath=" . {.status.loadBalancer.ingress[*].ip}"`
```
export IP_ADDRESS=`kubectl get svc $INGRESSGATEWAY --namespace istio-system --output jsonpath=" . {.status.loadBalancer.ingress[*].ip}"`
```
## Load the Service
1. Make a request to the autoscale app to see it consume some resources.
```shell
curl --header "Host: autoscale-go.default.example.com" "http://${IP_ADDRESS?}?sleep=100&prime=10000&bloat=5"
```
```shell
curl --header "Host: autoscale-go.default.example.com" "http://${IP_ADDRESS?}?sleep=100&prime=10000&bloat=5"
```
```
Allocated 5 Mb of memory.
The largest prime less than 10000 is 9973.
Slept for 100.13 milliseconds.
```
```
Allocated 5 Mb of memory.
The largest prime less than 10000 is 9973.
Slept for 100.13 milliseconds.
```
1. Send 30 seconds of traffic maintaining 50 in-flight requests.
```shell
hey -z 30s -c 50 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=100&prime=10000&bloat=5" \
&& kubectl get pods
```
```shell
hey -z 30s -c 50 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=100&prime=10000&bloat=5" \
&& kubectl get pods
```
```shell
Summary:
Total: 30.3379 secs
Slowest: 0.7433 secs
Fastest: 0.1672 secs
Average: 0.2778 secs
Requests/sec: 178.7861
```shell
Summary:
Total: 30.3379 secs
Slowest: 0.7433 secs
Fastest: 0.1672 secs
Average: 0.2778 secs
Requests/sec: 178.7861
Total data: 542038 bytes
Size/request: 99 bytes
Total data: 542038 bytes
Size/request: 99 bytes
Response time histogram:
0.167 [1] |
0.225 [1462] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.282 [1303] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.340 [1894] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.398 [471] |■■■■■■■■■■
0.455 [159] |■■■
0.513 [68] |■
0.570 [18] |
0.628 [14] |
0.686 [21] |
0.743 [13] |
Response time histogram:
0.167 [1] |
0.225 [1462] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.282 [1303] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.340 [1894] |■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
0.398 [471] |■■■■■■■■■■
0.455 [159] |■■■
0.513 [68] |■
0.570 [18] |
0.628 [14] |
0.686 [21] |
0.743 [13] |
Latency distribution:
10% in 0.1805 secs
25% in 0.2197 secs
50% in 0.2801 secs
75% in 0.3129 secs
90% in 0.3596 secs
95% in 0.4020 secs
99% in 0.5457 secs
Latency distribution:
10% in 0.1805 secs
25% in 0.2197 secs
50% in 0.2801 secs
75% in 0.3129 secs
90% in 0.3596 secs
95% in 0.4020 secs
99% in 0.5457 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0007 secs, 0.1672 secs, 0.7433 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
req write: 0.0001 secs, 0.0000 secs, 0.0045 secs
resp wait: 0.2766 secs, 0.1669 secs, 0.6633 secs
resp read: 0.0002 secs, 0.0000 secs, 0.0065 secs
Details (average, fastest, slowest):
DNS+dialup: 0.0007 secs, 0.1672 secs, 0.7433 secs
DNS-lookup: 0.0000 secs, 0.0000 secs, 0.0000 secs
req write: 0.0001 secs, 0.0000 secs, 0.0045 secs
resp wait: 0.2766 secs, 0.1669 secs, 0.6633 secs
resp read: 0.0002 secs, 0.0000 secs, 0.0065 secs
Status code distribution:
[200] 5424 responses
```
Status code distribution:
[200] 5424 responses
```
```shell
NAME READY STATUS RESTARTS AGE
autoscale-go-00001-deployment-78cdc67bf4-2w4sk 3/3 Running 0 26s
autoscale-go-00001-deployment-78cdc67bf4-dd2zb 3/3 Running 0 24s
autoscale-go-00001-deployment-78cdc67bf4-pg55p 3/3 Running 0 18s
autoscale-go-00001-deployment-78cdc67bf4-q8bf9 3/3 Running 0 1m
autoscale-go-00001-deployment-78cdc67bf4-thjbq 3/3 Running 0 26s
```
```shell
NAME READY STATUS RESTARTS AGE
autoscale-go-00001-deployment-78cdc67bf4-2w4sk 3/3 Running 0 26s
autoscale-go-00001-deployment-78cdc67bf4-dd2zb 3/3 Running 0 24s
autoscale-go-00001-deployment-78cdc67bf4-pg55p 3/3 Running 0 18s
autoscale-go-00001-deployment-78cdc67bf4-q8bf9 3/3 Running 0 1m
autoscale-go-00001-deployment-78cdc67bf4-thjbq 3/3 Running 0 26s
```
## Analysis
@ -137,20 +135,20 @@ autoscaler operates on the shorter, more sensitive panic window. Once the panic
conditions are no longer met for 60 seconds, the autoscaler will return to the
initial 60 second `stable` window.
```
|
Panic Target---> +--| 20
| |
| <------Panic Window
| |
Stable Target---> +-------------------------|--| 10 CONCURRENCY
| | |
| <-----------Stable Window
| | |
--------------------------+-------------------------+--+ 0
120 60 0
TIME
```
```
|
Panic Target---> +--| 20
| |
| <------Panic Window
| |
Stable Target---> +-------------------------|--| 10 CONCURRENCY
| | |
| <-----------Stable Window
| | |
--------------------------+-------------------------+--+ 0
120 60 0
TIME
```
#### Customization
@ -164,54 +162,54 @@ autoscaler classes built into Knative:
Example of a Service scaled on CPU:
```yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
metadata:
annotations:
# Standard Kubernetes CPU-based autoscaling.
autoscaling.knative.dev/class: hpa.autoscaling.knative.dev
autoscaling.knative.dev/metric: cpu
spec:
container:
image: gcr.io/knative-samples/autoscale-go:0.1
```
```yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
metadata:
annotations:
# Standard Kubernetes CPU-based autoscaling.
autoscaling.knative.dev/class: hpa.autoscaling.knative.dev
autoscaling.knative.dev/metric: cpu
spec:
container:
image: gcr.io/knative-samples/autoscale-go:0.1
```
Additionally the autoscaler targets and scaling bounds can be specified in
annotations. Example of a Service with custom targets and scale bounds:
```yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
metadata:
annotations:
# Knative concurrency-based autoscaling (default).
autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
autoscaling.knative.dev/metric: concurrency
# Target 10 requests in-flight per pod.
autoscaling.knative.dev/target: "10"
# Disable scale to zero with a minScale of 1.
autoscaling.knative.dev/minScale: "1"
# Limit scaling to 100 pods.
autoscaling.knative.dev/maxScale: "100"
spec:
container:
image: gcr.io/knative-samples/autoscale-go:0.1
```
```yaml
apiVersion: serving.knative.dev/v1alpha1
kind: Service
metadata:
name: autoscale-go
namespace: default
spec:
runLatest:
configuration:
revisionTemplate:
metadata:
annotations:
# Knative concurrency-based autoscaling (default).
autoscaling.knative.dev/class: kpa.autoscaling.knative.dev
autoscaling.knative.dev/metric: concurrency
# Target 10 requests in-flight per pod.
autoscaling.knative.dev/target: "10"
# Disable scale to zero with a minScale of 1.
autoscaling.knative.dev/minScale: "1"
# Limit scaling to 100 pods.
autoscaling.knative.dev/maxScale: "100"
spec:
container:
image: gcr.io/knative-samples/autoscale-go:0.1
```
Note: for an `hpa.autoscaling.knative.dev` class service, the
`autoscaling.knative.dev/target` specifies the CPU percentage target (default
@ -226,9 +224,9 @@ customization (32 minutes).
View the Knative Serving Scaling and Request dashboards (if configured).
```
kubectl port-forward --namespace knative-monitoring $(kubectl get pods --namespace knative-monitoring --selector=app=grafana --output=jsonpath="{.items..metadata.name}") 3000
```
```
kubectl port-forward --namespace knative-monitoring $(kubectl get pods --namespace knative-monitoring --selector=app=grafana --output=jsonpath="{.items..metadata.name}") 3000
```
![scale dashboard](scale-dashboard.png)
@ -238,51 +236,51 @@ View the Knative Serving Scaling and Request dashboards (if configured).
1. Send 60 seconds of traffic maintaining 100 concurrent requests.
```shell
hey -z 60s -c 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=100&prime=10000&bloat=5"
```
```shell
hey -z 60s -c 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=100&prime=10000&bloat=5"
```
1. Send 60 seconds of traffic maintaining 100 qps with short requests (10 ms).
```shell
hey -z 60s -q 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=10"
```
```shell
hey -z 60s -q 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=10"
```
1. Send 60 seconds of traffic maintaining 100 qps with long requests (1 sec).
```shell
hey -z 60s -q 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=1000"
```
```shell
hey -z 60s -q 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?sleep=1000"
```
1. Send 60 seconds of traffic with heavy CPU usage (~1 cpu/sec/request, total
100 cpus).
```shell
hey -z 60s -q 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?prime=40000000"
```
```shell
hey -z 60s -q 100 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?prime=40000000"
```
1. Send 60 seconds of traffic with heavy memory usage (1 gb/request, total 5
gb).
```shell
hey -z 60s -c 5 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?bloat=1000"
```
```shell
hey -z 60s -c 5 \
-host "autoscale-go.default.example.com" \
"http://${IP_ADDRESS?}?bloat=1000"
```
## Cleanup
```
kubectl delete --filename docs/serving/samples/autoscale-go/service.yaml
```
```
kubectl delete --filename docs/serving/samples/autoscale-go/service.yaml
```
## Further reading

View File

@ -15,8 +15,7 @@ configuration.
You need:
- A Kubernetes cluster with [Knative installed](../../install/README.md).
- (Optional)
[A custom domain configured](../using-a-custom-domain.md) for use
- (Optional) [A custom domain configured](../using-a-custom-domain.md) for use
with Knative.
Note: The source code for the gcr.io/knative-samples/knative-route-demo image
@ -85,9 +84,8 @@ route "blue-green-demo" configured
You'll now be able to view the sample app at
http://blue-green-demo.default.YOUR_CUSTOM_DOMAIN.com (replace
`YOUR_CUSTOM_DOMAIN`) with the
[custom domain](../using-a-custom-domain.md) you configured for use
with Knative.
`YOUR_CUSTOM_DOMAIN`) with the [custom domain](../using-a-custom-domain.md) you
configured for use with Knative.
> Note: If you don't have a custom domain configured for use with Knative, you
> can interact with your app using cURL requests if you have the host URL and IP

View File

@ -1,4 +1,3 @@
This sample demonstrates:
- Pulling source code from a private Github repository using a deploy-key

View File

@ -1,4 +1,3 @@
A sample app that demonstrates using
[Cloud Foundry](https://www.cloudfoundry.org/) buildpacks on Knative Serving,
using the [packs Docker images](https://github.com/sclevine/packs).

View File

@ -1,4 +1,3 @@
A sample function that demonstrates using
[Cloud Foundry](https://www.cloudfoundry.org/) buildpacks on Knative Serving,
using the [packs Docker images](https://github.com/sclevine/packs).

View File

@ -1,12 +1,11 @@
A handler written in Go that demonstrates interacting with GitHub through a
webhook.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).
- An account on [GitHub](https://github.com) with read/write access to a
@ -97,8 +96,7 @@ service "gitwebhook" created
1. Finally, once the service is running, create the webhook from your GitHub
repo to the URL for this service. For this to work properly you will need to
[configure a custom domain](../../using-a-custom-domain.md)
and
[configure a custom domain](../../using-a-custom-domain.md) and
[assign a static IP address](../../gke-assigning-static-ip-address.md).
1. Retrieve the hostname for this service, using the following command:

View File

@ -1,4 +1,3 @@
A simple gRPC server written in Go that you can use for testing.
This sample requires knative/serving 0.4 or later.

View File

@ -4,4 +4,3 @@ linkTitle: "Hello world apps"
weight: 1
type: "docs"
---

View File

@ -1,4 +1,3 @@
A simple web app written in C# using .NET Core 2.2 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.
@ -6,8 +5,8 @@ is not specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).
- You have installed [.NET Core SDK 2.2](https://www.microsoft.com/net/core).
@ -18,7 +17,8 @@ While you can clone all of the code from this directory, hello world apps are
generally more useful if you build them step-by-step. The following instructions
recreate the source files from this folder.
1. First, make sure you have [.NET Core SDK 2.2](https://www.microsoft.com/net/core) installed:
1. First, make sure you have
[.NET Core SDK 2.2](https://www.microsoft.com/net/core) installed:
```shell
dotnet --version

View File

@ -1,4 +1,3 @@
A simple web app written in Go 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`.
@ -6,8 +5,8 @@ it will use `World` as the `TARGET`.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -1,4 +1,3 @@
A simple web app written in Java using Spring Boot 2.0 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.
@ -6,8 +5,8 @@ TARGET is not specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).
- You have installed
@ -207,9 +206,8 @@ folder) you're ready to build and deploy the sample app.
--output jsonpath={.status.domain}
```
1. Now you can make a request to your app to see the result. Presuming,
the IP address you got in the step above is in the `${IP_ADDRESS}`
env variable:
1. Now you can make a request to your app to see the result. Presuming, the IP
address you got in the step above is in the `${IP_ADDRESS}` env variable:
```shell
curl -H "Host: ${DOMAIN_NAME}" http://${IP_ADDRESS}

View File

@ -1,4 +1,3 @@
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.
@ -6,8 +5,8 @@ use for testing. It reads in an env variable `TARGET` and prints "Hello
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).
@ -215,9 +214,8 @@ folder) you're ready to build and deploy the sample app.
helloworld-kotlin helloworld-kotlin.default.example.com
```
1. Now you can make a request to your app to see the result. Presuming,
the IP address you got in the step above is in the `${IP_ADDRESS}`
env variable:
1. Now you can make a request to your app to see the result. Presuming, the IP
address you got in the step above is in the `${IP_ADDRESS}` env variable:
```shell
curl -H "Host: helloworld-kotlin.default.example.com" http://${IP_ADDRESS}

View File

@ -1,4 +1,3 @@
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.
@ -6,8 +5,8 @@ specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).
- [Node.js](https://nodejs.org/en/) installed and configured.
@ -18,7 +17,6 @@ While you can clone all of the code from this directory, hello world apps are
generally more useful if you build them step-by-step. The following instructions
recreate the source files from this folder.
1. Create a new directory and initialize `npm`:
```shell

View File

@ -1,4 +1,3 @@
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.
@ -6,8 +5,8 @@ will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -1,4 +1,3 @@
A simple web app written in Python 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.
@ -6,8 +5,8 @@ specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -1,4 +1,3 @@
A simple web app written in Ruby 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.
@ -6,8 +5,8 @@ specified, it will use "World" as the TARGET.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../../install/README.md)
if you need to create one.
[installation instructions](../../../../install/README.md) if you need to
create one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).

View File

@ -1,4 +1,3 @@
A microservice which demonstrates how to get set up and running with Knative
Serving when using [Scala](https://scala-lang.org/) and [Akka](https://akka.io/)
[HTTP](https://doc.akka.io/docs/akka-http/current/). It will respond to a HTTP
@ -7,9 +6,8 @@ to `"Hello World!"`.
## Prerequisites
- A Kubernetes cluster
[installation](../../../../install/README.md)
with Knative Serving up and running.
- A Kubernetes cluster [installation](../../../../install/README.md) with
Knative Serving up and running.
- [Docker](https://www.docker.com) installed locally, and running, optionally a
Docker Hub account configured or some other Docker Repository installed
locally.

View File

@ -1,4 +1,3 @@
This example shows how to map multiple Knative services to different paths under
a single domain name using the Istio VirtualService concept. Istio is a
general-purpose reverse proxy, therefore these directions can also be used to
@ -14,8 +13,7 @@ the Login service.
## Prerequisites
1. A Kubernetes cluster with
[Knative Serving](../../../install/README.md)
1. A Kubernetes cluster with [Knative Serving](../../../install/README.md)
installed.
2. Install
[Docker](https://docs.docker.com/get-started/#prepare-your-docker-environment).
@ -67,7 +65,8 @@ docker push "${REPO}/docs/serving/samples/knative-routing-go"
configuration file `docs/serving/samples/knative-routing-go/sample.yaml`:
- Manually replace:
`image: github.com/knative/docs/docs/serving/samples/knative-routing-go` with
`image: github.com/knative/docs/docs/serving/samples/knative-routing-go`
with
`image: <YOUR_CONTAINER_REGISTRY>docs/serving/samples/knative-routing-go`
Or

View File

@ -1,17 +1,15 @@
This sample demonstrates creating and running a simple RESTful service on
Knative Serving. The exposed endpoint takes a stock ticker (i.e. stock symbol),
then outputs the stock price.
## Prerequisites
1. A Kubernetes cluster with
[Knative Serving](../../../install/README.md)
v0.3 or higher installed.
1. A Kubernetes cluster with [Knative Serving](../../../install/README.md) v0.3
or higher installed.
1. [Docker](https://docs.docker.com/get-started/#prepare-your-docker-environment)
installed locally.
1. [Outbound network access](../../outbound-network-access.md)
enabled for this Service to make external API requests.
1. [Outbound network access](../../outbound-network-access.md) enabled for this
Service to make external API requests.
1. The code checked out locally.
1. `envsubst` installed locally. This is installed by the `gettext` package. If
not installed it can be installed by a Linux package manager, or by
@ -28,8 +26,7 @@ available to fetch from a container registry. Building and pushing a container
image can be accomplished locally using
[Docker](https://docs.docker.com/get-started) or
[ko](https://github.com/google/go-containerregistry/tree/master/cmd/ko) as well
as remotely using
[Knative Build](../../../build).
as remotely using [Knative Build](../../../build).
This sample uses Docker for both building and pushing.
@ -79,7 +76,7 @@ docker push "${REPO}/rest-api-go"
```
6. 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 command below substitutes using the \${REPO} variable into a new
file called `docs/serving/samples/rest-api-go/sample.yaml`.
```shell
@ -92,7 +89,6 @@ docker push "${REPO}/rest-api-go"
Now that our image is available from the container registry, we can deploy the
Knative Serving sample:
```shell
kubectl apply --filename docs/serving/samples/rest-api-go/sample.yaml
```
@ -177,10 +173,10 @@ echo $INGRESS_IP
#### Minikube
1. If your cluster is running outside a cloud provider (for example on Minikube),
your services will never get an external IP address, and your INGRESS_IP will
be empty. In that case, use the istio `hostIP` and `nodePort` as the ingress
IP:
1. If your cluster is running outside a cloud provider (for example on
Minikube), your services will never get an external IP address, and your
INGRESS_IP will be empty. In that case, use the istio `hostIP` and `nodePort`
as the ingress IP:
```shell
export INGRESS_IP=$(kubectl get po --selector $INGRESSGATEWAY_LABEL=ingressgateway --namespace istio-system \
@ -233,16 +229,14 @@ Response body: `stock price for ticker <ticker> is <price>`
## Next Steps
The
[traffic splitting example](../traffic-splitting/README.md)
continues from here to walk through creating new Revisions and splitting traffic
between multiple Revisions.
The [traffic splitting example](../traffic-splitting/README.md) continues from
here to walk through creating new Revisions and splitting traffic between
multiple Revisions.
## Clean Up
To clean up the sample Service:
```shell
kubectl delete --filename docs/serving/samples/rest-api-go/sample.yaml
```

View File

@ -8,8 +8,8 @@ into a container as a Volume.
## Prerequisites
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- [Docker](https://www.docker.com) installed and running on your local machine,
and a Docker Hub account configured (we'll use it for a container registry).
- Create a

View File

@ -1,4 +1,3 @@
A Go sample that shows how to use Knative to go from source code in a git
repository to a running application with a URL.
@ -11,8 +10,8 @@ deployment.
You need:
- A Kubernetes cluster with Knative installed. Follow the
[installation instructions](../../../install/README.md)
if you need to create one.
[installation instructions](../../../install/README.md) if you need to create
one.
- Go installed and configured. This is optional, and only required if you want
to run the sample app locally.
@ -76,7 +75,7 @@ available, but these are the key steps:
1. Create a new `Service Account` manifest which is used to link the build
process to the secret. Save this file as `service-account.yaml`:
```yaml
apiVersion: v1
kind: ServiceAccount
@ -86,7 +85,8 @@ available, but these are the key steps:
- name: basic-user-pass
```
1. After you have created the manifest files, apply them to your cluster with `kubectl`:
1. After you have created the manifest files, apply them to your cluster with
`kubectl`:
```shell
$ kubectl apply --filename docker-secret.yaml
@ -166,7 +166,9 @@ container for the application.
app-from-source-00001-deployment-6d6ff665f9-xfhm5 3/3 Running 0 11s
```
> **Note:** If the build pod never reaches Completed status and terminates after 10 minutes, Kaniko probably didn't finish pulling the build image within the default timeout period. Try increasing the `timeout` value in `service.yaml`.
> **Note:** If the build pod never reaches Completed status and terminates after
> 10 minutes, Kaniko probably didn't finish pulling the build image within the
> default timeout period. Try increasing the `timeout` value in `service.yaml`.
1. Once you see the deployment pod switch to the running state, press Ctrl+C to
escape the watch. Your container is now built and deployed!

View File

@ -1,4 +1,3 @@
This sample runs a simple web server that makes calls to other in-cluster
services and responds to requests with "Hello World!". The purpose of this
sample is to show generating [metrics](../../accessing-metrics.md),
@ -8,8 +7,7 @@ dedicated Prometheus instance rather than using the default installation.
## Prerequisites
1. A Kubernetes cluster with
[Knative Serving](../../../install/README.md)
1. A Kubernetes cluster with [Knative Serving](../../../install/README.md)
installed.
2. Check if Knative monitoring components are installed:

View File

@ -1,4 +1,3 @@
This is a walk-through example that demonstrates deploying a dockerized
application that accesses external dependencies to Knative Serving. In this demo
we will use a sample `golang` application that takes a video URL as an input and

View File

@ -1,4 +1,3 @@
This samples builds off the [Creating a RESTful Service](../rest-api-go) sample
to illustrate applying a revision, then using that revision for manual traffic
splitting.
@ -103,7 +102,8 @@ stock-configuration-example-00001 11m
stock-configuration-example-00002 4m
```
2. Update the `traffic` list in `docs/serving/samples/rest-api-go/sample.yaml` as:
2. Update the `traffic` list in `docs/serving/samples/rest-api-go/sample.yaml`
as:
```yaml
traffic:

View File

@ -36,8 +36,8 @@ collecting `stdout/stderr` logs from the containers:
in
[200-fluentd.yaml](https://github.com/knative/serving/blob/master/config/monitoring/logging/elasticsearch/200-fluentd.yaml)
with the Fluentd image including the desired Fluentd output plugin. See
[here](./fluentd-requirements.md) for the requirements of Flunetd
image on Knative.
[here](./fluentd-requirements.md) for the requirements of Flunetd image on
Knative.
### Configure the Sidecar for log files under /var/log
@ -71,7 +71,8 @@ kubectl apply --recursive --filename config/monitoring/100-namespace.yaml \
```
In the commands above, replace `<path-of-fluentd-daemonset-config>` with the
Fluentd DaemonSet configuration file, e.g. `config/monitoring/logging/stackdriver`.
Fluentd DaemonSet configuration file, e.g.
`config/monitoring/logging/stackdriver`.
**NOTE**: The deployment above will not affect the fluentd sidecar of existing
pods. Developers need to redeploy their app to get the newest configuration for
@ -85,8 +86,8 @@ the Elasticsearch and Kibana services. Knative provides this sample:
kubectl apply --recursive --filename third_party/config/monitoring/logging/elasticsearch
```
See [here](./installing-logging-metrics-traces.md) for deploying the
whole Knative monitoring components.
See [here](./installing-logging-metrics-traces.md) for deploying the whole
Knative monitoring components.
## Uninstalling

View File

@ -244,7 +244,8 @@ namespace:
kubectl edit configmap config-ingressgateway -n knative-serving
```
Replace the `ingress-gateway` field with the fully qualified url of your service. For the service above, it should be updated to:
Replace the `ingress-gateway` field with the fully qualified url of your
service. For the service above, it should be updated to:
```
custom-ingressgateway.istio-system.svc.cluster.local

View File

@ -82,9 +82,9 @@ You can also apply an updated domain configuration:
> deployed services and routes.
Deploy an app (for example,
[`helloworld-go`](./samples/hello-world/helloworld-go/README.md)), to your cluster as
normal. You can check the customized domain in Knative Route "helloworld-go"
with the following command:
[`helloworld-go`](./samples/hello-world/helloworld-go/README.md)), to your
cluster as normal. You can check the customized domain in Knative Route
"helloworld-go" with the following command:
```shell
kubectl get route helloworld-go --output jsonpath="{.status.domain}"

View File

@ -7,8 +7,8 @@ type: "docs"
These instructions assume you have already setup a Knative cluster and installed
cert-manager into your cluster. For more information, see
[using an SSL certificate](./using-an-ssl-cert.md#install-cert-manager). They also
assume you have already set up your managed zone with Cloud DNS as part of
[using an SSL certificate](./using-an-ssl-cert.md#install-cert-manager). They
also assume you have already set up your managed zone with Cloud DNS as part of
configuring the domain to map to your IP address.
To automate the generation of a certificate with cert-manager and LetsEncrypt,

View File

@ -116,9 +116,8 @@ permission to get the credential secret can access your Cloud DNS.
## Set up Knative
1. Follow the
[instruction](../install/README.md)
to install Knative on your cluster.
1. Follow the [instruction](../install/README.md) to install Knative on your
cluster.
1. Configure Knative to use your custom domain.
```shell

View File

@ -1,6 +1,4 @@
---
title: Search Results
layout: search
---