mirror of https://github.com/knative/docs.git
Add classification for remainder of docs (serving+install)
This commit is contained in:
parent
51bc498ce1
commit
aaac40ea8e
|
@ -2,6 +2,9 @@
|
|||
title: "Learn about Google Analytics cookies"
|
||||
linkTitle: "Learn about cookies"
|
||||
type: "docs"
|
||||
audience: developer
|
||||
components: []
|
||||
function: community
|
||||
---
|
||||
|
||||
By using this website, you are confirming that you accept our use of cookies for
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Installing Knative
|
||||
|
||||
!!! note
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Installing Knative Backstage Plugins
|
||||
|
||||
Knative community is planning to provide a set of Backstage plugins for Knative and their respective backends.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Installing cert-manager for TLS certificates
|
||||
|
||||
Knative leverages [cert-manager](https://github.com/jetstack/cert-manager) to request TLS certificates
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Installing Istio for Knative
|
||||
|
||||
This guide walks you through manually installing and customizing Istio for use
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: buyer
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative Offerings
|
||||
|
||||
Knative has a rich community with many vendors participating, and many of those
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring the Eventing Operator custom resource
|
||||
|
||||
You can configure the Knative Eventing operator by modifying settings in the `KnativeEventing` custom resource (CR).
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring the Knative Serving Operator custom resource
|
||||
|
||||
You can modify the KnativeServing CR to configure different options for Knative Serving.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring Knative by using the Operator
|
||||
|
||||
The Operator manages the configuration of a Knative installation, including propagating values from the `KnativeServing` and `KnativeEventing` custom resources to system [ConfigMaps](https://kubernetes.io/docs/concepts/configuration/configmap/).
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Install by using the Knative Operator CLI Plugin
|
||||
|
||||
Knative provides a CLI Plugin to install, configure and manage Knative via the command lines. This CLI plugin facilitates
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Install by using the Knative Operator
|
||||
|
||||
Knative provides a [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) to install, configure and manage Knative.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: tutorial
|
||||
---
|
||||
|
||||
# Install Knative using quickstart
|
||||
|
||||
Following this quickstart tutorial provides you with a simplified, local Knative installation by using the Knative `quickstart` plugin.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Troubleshooting a Knative Installation
|
||||
|
||||
This page describes how you can troubleshoot a Knative installation. Please try these instructions before filing a bug report.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Uninstalling Knative
|
||||
|
||||
To uninstall an Operator-based Knative installation, see the following [Uninstall an Operator-based Knative Installation](#uninstall-an-operator-based-knative-installation) procedure.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Upgrading Knative
|
||||
|
||||
Knative supports upgrading by a single [minor](https://semver.org/) version number. For example, if you have v0.21.0 installed, you must upgrade to v0.22.0 before attempting to upgrade to v0.23.0.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Checking your Knative version
|
||||
|
||||
To check the version of your Knative installation, use one of the following commands,
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Upgrading using the Knative Operator
|
||||
|
||||
This topic describes how to upgrade Knative if you installed using the Operator.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Upgrading with kubectl
|
||||
|
||||
If you installed Knative using YAML, you can use the `kubectl apply` command in
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: reference
|
||||
---
|
||||
|
||||
# About YAML-based installation
|
||||
|
||||
You can install the Serving component, Eventing component, or both on your cluster
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- eventing
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative Eventing installation files
|
||||
|
||||
This guide provides reference information about the core Knative Eventing YAML files, including:
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Installing Knative Eventing using YAML files
|
||||
|
||||
This topic describes how to install Knative Eventing by applying YAML files using the `kubectl` CLI.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Install a networking layer on IBM Z and IBM Power platforms
|
||||
|
||||
This additional step is required for installing the Kourier networking layer on IBM Z and IBM Power platforms.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Installing Knative Serving using YAML files
|
||||
|
||||
This topic describes how to install Knative Serving by applying YAML files using the `kubectl` CLI.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative Serving installation files
|
||||
|
||||
This guide provides reference information about the core Knative Serving YAML files, including:
|
||||
|
|
|
@ -1,3 +1,12 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- functions
|
||||
- serving
|
||||
- eventing
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative release notes
|
||||
|
||||
For details about the Knative releases, see the following pages:
|
||||
|
|
|
@ -1,3 +1,12 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- functions
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Knative Security and Disclosure Information
|
||||
|
||||
This page describes Knative security and disclosure information.
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Verifying Knative Images
|
||||
|
||||
Knative publishes SBOMs and SLSA provenance documents for each image in the
|
||||
|
|
|
@ -1,3 +1,11 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
- eventing
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative code samples
|
||||
|
||||
You can use Knative code samples to help you get up and running with common use
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- eventing
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative Eventing code samples
|
||||
|
||||
Use the following code samples to help you understand the various use cases for
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative Serving code samples
|
||||
|
||||
Use the following code samples to help you understand the various Knative
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Knative Serving
|
||||
|
||||
--8<-- "about-serving.md"
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Accessing request traces
|
||||
|
||||
Depending on the request tracing tool that you have installed on your Knative
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# About Security-Guard
|
||||
|
||||
Security-Guard provides visibility into the security status of deployed Knative Services, by monitoring the behaviors of user containers and events. Security-Guard also supports optional blocking of events and termination of user container instances, all based on behavior.
|
||||
|
|
|
@ -1,3 +1,9 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Security-Guard example alerts
|
||||
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Installing Security-Guard
|
||||
|
||||
Here we show how to install Security-Guard in Knative. Security-Guard is an enhancement to knative-Serving and needs to be installed after the Knative-Serving is successfully installed.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: tutorial
|
||||
---
|
||||
|
||||
# Security-Guard monitoring quickstart
|
||||
|
||||
This tutorial shows how you can use Security-Guard to protect a deployed Knative Service.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Knative Serving Architecture
|
||||
|
||||
Knative Serving consists of several components forming the backbone of the Serverless Platform.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Autoscaling
|
||||
|
||||
Knative Serving provides automatic scaling, or _autoscaling_, for applications to match incoming demand. This is provided by default, by using the Knative Pod Autoscaler (KPA).
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Autoscale Sample App - Go
|
||||
|
||||
A demonstration of the autoscaling capabilities of a Knative Serving Revision.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Supported Autoscaler types
|
||||
|
||||
Knative Serving supports the implementation of Knative Pod Autoscaler (KPA) and Kubernetes' Horizontal Pod Autoscaler (HPA). This topic lists the features and limitations of each of these Autoscalers, as well as how to configure them.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Metrics
|
||||
|
||||
The metric configuration defines which metric type is watched by the Autoscaler.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Targets
|
||||
|
||||
Configuring a target provide the Autoscaler with a value that it tries to maintain for the configured metric for a revision.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Configuring concurrency
|
||||
|
||||
Concurrency determines the number of simultaneous requests that can be processed by each replica of an application at any given time.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Additional autoscaling configuration for Knative Pod Autoscaler
|
||||
|
||||
The following settings are specific to the Knative Pod Autoscaler (KPA).
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Configuring the requests per second (RPS) target
|
||||
|
||||
This setting specifies a target for requests-per-second per replica of an application. Your revision must also be configured to use the `rps` [metric annotation](autoscaling-metrics.md).
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Configuring scale bounds
|
||||
|
||||
You can configure upper and lower bounds to control autoscaling behavior.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Configuring scale to zero
|
||||
|
||||
!!! warning
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring high-availability components
|
||||
|
||||
Active/passive high availability (HA) is a standard feature of Kubernetes APIs that helps to ensure that APIs stay operational if a disruption occurs. In an HA deployment, if an active controller crashes or is deleted, another controller is available to take over processing of the APIs that were being serviced by the controller that is now unavailable.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Configuring the Defaults ConfigMap
|
||||
|
||||
The `config-defaults` ConfigMap, known as the Defaults ConfigMap, contains settings that determine how Knative sets default values for resources.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Configure Deployment resources
|
||||
|
||||
The `config-deployment` ConfigMap, known as the Deployment ConfigMap, contains settings that determine how Kubernetes `Deployment` resources, which back Knative services, are configured. This ConfigMap is located in the `knative-serving` namespace.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Feature and extension flags
|
||||
|
||||
The Knative API is designed to be portable, and abstracts away specific implementation details for user deployments. The intention of the API is to empower users to surface extra features and extensions that are possible within their platform of choice.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
{% include "gradual-rollout-intro.md" %}
|
||||
|
||||
## Procedure
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Converting a Kubernetes Deployment to a Knative Service
|
||||
|
||||
This topic shows how to convert a Kubernetes Deployment to a Knative Service.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Deploying images from a private container registry
|
||||
|
||||
You can configure your Knative cluster to deploy images from a private registry across multiple Services and Revisions. To do this, you must create a list of Kubernetes secrets ([`imagePullSecrets`](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#pod-v1-core)) by using your registry credentials. You must then add those secrets to the default [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/) for all Services, or the Revision template for a single Service.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configure cluster-local domain encryption
|
||||
|
||||
{% include "encryption-notice.md" %}
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring Knative cert-manager integration
|
||||
|
||||
Knative Serving relies on a bridging component to use cert-manager for automated certificate provisioning.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Serving Encryption Overview
|
||||
|
||||
{% include "encryption-notice.md" %}
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configure external domain encryption
|
||||
|
||||
Knative allows to use either use custom TLS certificates or to use automatically generated TLS certificates
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configure Knative system-internal encryption
|
||||
|
||||
{% include "encryption-notice.md" %}
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Enabling requests to Knative services when additional authorization policies are enabled
|
||||
|
||||
Knative Serving system pods, such as the activator and autoscaler components, require access to your deployed Knative services.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Kubernetes services
|
||||
|
||||
This guide describes the
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Load balancing
|
||||
|
||||
You can turn on Knative load balancing, by placing the _Activator service_ in the request path to act as a load balancer. To do this, you must first ensure that individual pod addressability is enabled.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring Activator capacity
|
||||
|
||||
If there is more than one Activator in the system, Knative puts as many Activators on the request path as required to handle the current request load plus the target burst capacity. If the target burst capacity is 0, Knative only puts the Activator into the request path if the Revision is scaled to zero.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Configuring target burst capacity
|
||||
|
||||
_Target burst capacity_ is a [global and per-revision](../autoscaling/autoscaler-types.md#global-versus-per-revision-settings) integer setting that determines the size of traffic burst a Knative application can handle without buffering.
|
||||
|
|
|
@ -1 +1,8 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
--8<-- "collecting-logs.md"
|
||||
|
|
|
@ -1 +1,8 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
--8<-- "configuring-logs.md"
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring Request Log Settings
|
||||
|
||||
The request logging for knative serving is managed through the `config-observability` ConfigMap in `knative-serving` namespace. The request logs will be printed by the queue-proxy sidecar.
|
||||
|
|
|
@ -1 +1,8 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
--8<-- "collecting-metrics.md"
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Knative Serving metrics
|
||||
|
||||
Administrators can monitor Serving control plane based on the metrics exposed by each Serving component.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: contributor
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Extending Queue Proxy image with QPOptions
|
||||
|
||||
Knative service pods include two containers:
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# HTTP Request Flows
|
||||
|
||||
While [the overview](/docs/serving) describes the logical components and
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# About Revisions
|
||||
|
||||
--8<-- "about-revisions.md"
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Administrator configuration options
|
||||
|
||||
If you have cluster administrator permissions for your Knative installation, you can modify ConfigMaps to change the global default configuration options for Revisions of Knative Services on the cluster.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Developer configuration options
|
||||
|
||||
While Revisions cannot be created manually without modifying the Configuration of a Knative Service, you can modify the spec of an existing Revision to change its behavior.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
{% include "gradual-rollout-intro.md" %}
|
||||
|
||||
## Procedure
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# About Knative Services
|
||||
|
||||
Knative Services are used to deploy an application. To create an application using Knative, you must create a YAML file that defines a Service. This YAML file specifies metadata about the application, points to the hosted image of the app, and allows the Service to be configured.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring a custom certificate class for a Service
|
||||
|
||||
When `external-domain-tls` is enabled and Knative Services are created, a certificate class (`certificate-class`) is automatically chosen based on the value in the `config-network` ConfigMap located inside the `knative-serving` namespace. This ConfigMap is part of Knative Serving installation. If the certificate class is not specified, this defaults to `cert-manager.certificate.networking.knative.dev`. After `certificate-class` is configured, it is used for all Knative Services unless it is overridden with a `certificate-class` annotation.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring Probing
|
||||
|
||||
## General understanding of Knative Probing
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configure resource requests and limits
|
||||
|
||||
You can configure resource limits and requests, specifically for CPU and memory, for individual Knative services.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Creating a Service
|
||||
|
||||
You can create a Knative service by applying a YAML file or using the `kn service create` CLI command.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring custom domains
|
||||
|
||||
{{ feature(beta="0.24") }}
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Using a custom TLS certificate for DomainMapping
|
||||
|
||||
{{ feature(beta="0.24") }}
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring HTTP
|
||||
|
||||
## HTTPS redirection
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring Services custom ingress class
|
||||
|
||||
When a Knative Service is created an ingress class (`ingress-class`) is automatically assigned to it, based on the value in the `config-network` ConfigMap located inside the `knative-serving` namespace. This ConfigMap is part of Knative Serving installation. If the ingress class is not specified, this defaults to `istio.ingress.networking.knative.dev`. Once configured the `ingress-class` is used for all Knative Services unless it is overridden with an `ingress-class` annotation.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring private Services
|
||||
|
||||
By default, Services deployed through Knative use the `.svc.cluster.local` domain, meaning
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: reference
|
||||
---
|
||||
|
||||
# Service metrics
|
||||
|
||||
Every Knative Service has a proxy container that proxies the connections to the application container. A number of metrics are reported for the queue proxy performance.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Volume Support for Knative services
|
||||
|
||||
You can provide data storage for Knative Services by configuring different volumes types.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: explanation
|
||||
---
|
||||
|
||||
# Using extensions enabled by QPOptions
|
||||
|
||||
QPOptions is a Queue Proxy feature that enables extending Queue Proxy with additional Go packages. For example, the [security-guard](https://knative.dev/security-guard#section-readme) repository extends Queue Proxy by adding runtime security features to protect user services.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring the ingress gateway
|
||||
|
||||
Knative uses a shared ingress Gateway to serve all incoming traffic within
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Tag resolution
|
||||
|
||||
Knative Serving resolves image tags to a digest when you create a Revision. This
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Traffic management
|
||||
|
||||
You can manage traffic routing to different Revisions of a Knative Service by modifying the `traffic` spec of the Service resource.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: developer
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Debugging application issues
|
||||
|
||||
If you have deployed an application but are having issues, you can use the following steps to troubleshoot the application.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Configuring domain names
|
||||
|
||||
You can customize the domain of an individual Knative Service, or set a global default domain for all Services created on a cluster. The fully qualified domain name for a route by default is `{route}.{namespace}.svc.cluster.local`.
|
||||
|
|
|
@ -1,3 +1,10 @@
|
|||
---
|
||||
audience: administrator
|
||||
components:
|
||||
- serving
|
||||
function: how-to
|
||||
---
|
||||
|
||||
# Exclude namespaces from the Knative webhook
|
||||
|
||||
The Knative webhook examines resources that are created, read, updated, or deleted. This includes system namespaces, which can cause issues during an upgrade if the webhook becomes non-responsive. Cluster administrators may want to disable the Knative webhook on system namespaces to prevent issues during upgrades.
|
||||
|
|
Loading…
Reference in New Issue