mirror of https://github.com/knative/docs.git
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:
parent
9910b8a9ac
commit
01d4ba31ec
|
@ -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).
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -4,4 +4,3 @@ linkTitle: "Articles"
|
|||
weight: 30
|
||||
type: "blog"
|
||||
---
|
||||
|
||||
|
|
|
@ -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) |
|
||||
|
|
|
@ -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" %}}
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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/).
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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).
|
||||
|
||||
---
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
@ -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 |
|
||||
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
|
|
|
@ -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" %}}
|
||||
|
|
|
@ -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)
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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`
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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. |
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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`:
|
||||
|
|
|
@ -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 \
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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`:
|
||||
|
|
|
@ -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`:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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`:
|
||||
|
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
Follow this guide to install Knative components on a platform of your choice.
|
||||
|
||||
## Choosing a Kubernetes cluster
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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:
|
||||
|
||||
```
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>"`
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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) |
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
||||

|
||||
|
||||
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -1,4 +1,3 @@
|
|||
|
||||
This sample demonstrates:
|
||||
|
||||
- Pulling source code from a private Github repository using a deploy-key
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -4,4 +4,3 @@ linkTitle: "Hello world apps"
|
|||
weight: 1
|
||||
type: "docs"
|
||||
---
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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}
|
||||
|
|
|
@ -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}
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
```
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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!
|
||||
|
|
|
@ -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:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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}"
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue