openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

[enterprise-4.13]SRVKS-969 Restructure knative serving

Browse Source
This commit is contained in:
Gabriel McGoldrick
2023-01-19 12:17:28 +00:00
parent d7d9ac4aba
commit b5fcb1aa42
121 changed files with 991 additions and 469 deletions
Download Patch File Download Diff File Expand all files Collapse all files

115
_topic_maps/_topic_map.yml
View File

@@ -3769,6 +3769,109 @@ Topics:
File: installing-knative-eventing
- Name: Configuring Serverless Functions
File: configuring-serverless-functions
- Name: Knative Serving
Dir: knative-serving
Topics:
- Name: Getting started with Knative Serving
Dir: getting-started
Topics:
- Name: Creating Serverless applications
File: serverless-applications
- Name: Verifying application deployment
File: verifying-application-deployment
- Name: Autoscaling
Dir: autoscaling
Topics:
- Name: Autoscaling overview
File: serverless-autoscaling-developer
- Name: Scale bounds
File: serverless-autoscaling-developer-scale-bounds
- Name: Concurrency
File: serverless-concurrency
- Name: Scale-to-zero
File: serverless-autoscaling-scale-to-zero
- Name: Configuring Serverless applications
Dir: config-applications
Topics:
- Name: Overriding system deployment configurations
File: overriding-config
- Name: EmptyDir volumes
File: empty-dir
- Name: Persistent Volume Claims
File: pvcs-for-serving
- Name: Init containers
File: init-containers
- Name: Resolving image tags to digests
File: resolving-image-tags-to-digests
- Name: Restrictive network policies
File: restrictive-network-policies
- Name: Traffic splitting
Dir: traffic-splitting
Topics:
- Name: Traffic splitting overview
File: traffic-splitting-overview
- Name: Traffic spec examples
File: traffic-spec-examples
- Name: Traffic splitting using the CLI
File: traffic-splitting-using-cli
- Name: CLI flags for traffic splitting
File: traffic-splitting-flags
- Name: Splitting traffic between revisions
File: traffic-splitting-revisions
- Name: Reroute traffic using blue-green strategy
File: traffic-splitting-blue-green
- Name: External and Ingress routing
Dir: external-ingress-routing
Topics:
- Name: Routing overview
File: routing-overview
- Name: Customizing labels and annotations
File: customize-labels-annotations-routes
- Name: Configuring routes for Knative services
File: configuring-service-routes
- Name: Global HTTPS redirection
File: https-redirect-global
- Name: URL scheme for external routes
File: url-scheme-external-routes
- Name: HTTPS redirection per service
File: https-redirect-per-service
- Name: Cluster local availability
File: cluster-local-availability
- Name: Kourier Gateway service type
File: kourier-gateway-service-type
- Name: Using HTTP2 and gRPC
File: using-http2-gRPC
- Name: Configuring access to Knative services
Dir: config-access
Topics:
- Name: Configuring JSON Web Token authentication for Knative services
File: serverless-ossm-with-kourier-jwt
- Name: Using JSON Web Token authentication with Service Mesh 2.x
File: serverless-ossm-v2x-jwt
- Name: Using JSON Web Token authentication with Service Mesh 1.x
File: serverless-ossm-v1x-jwt
- Name: Configuring custom domains for Knative services
Dir: config-custom-domains
Topics:
- Name: Configuring custom domains overview
File: serverless-custom-domains
- Name: Custom domain mapping
File: create-domain-mapping
- Name: Custom domains using the Knative CLI
File: create-domain-mapping-kn
- Name: Domain mapping using the Developer perspective
File: domain-mapping-odc-developer
- Name: Domain mapping using the Administrator perspective
File: domain-mapping-odc-admin
- Name: Securing a mapped service using a TLS certificate
File: domain-mapping-custom-tls-cert
- Name: Configuring high availability for Knative services
Dir: config-ha-services
Topics:
- Name: High availability for Knative services overview
File: ha-services-overview
- Name: High availability for Knative services
File: ha-replicas-serving
# Knative kn CLI
- Name: Knative CLI
Dir: cli_tools
@@ -3786,14 +3889,6 @@ Topics:
- Name: Develop
Dir: develop
Topics:
- Name: Serverless applications
File: serverless-applications
- Name: Autoscaling
File: serverless-autoscaling-developer
- Name: Traffic management
File: serverless-traffic-management
- Name: Routing
File: serverless-configuring-routes
- Name: Event sinks
File: serverless-event-sinks
- Name: Event delivery
@@ -3853,10 +3948,6 @@ Topics:
Topics:
- Name: Configuring TLS authentication
File: serverless-config-tls
- Name: Configuring JSON Web Token authentication for Knative services
File: serverless-ossm-with-kourier-jwt
- Name: Configuring a custom domain for a Knative service
File: serverless-custom-domains
# Functions
- Name: Functions
Dir: functions

115
_topic_maps/_topic_map_osd.yml
View File

@@ -365,6 +365,109 @@ Topics:
File: installing-knative-eventing
- Name: Configuring Serverless Functions
File: configuring-serverless-functions
- Name: Knative Serving
Dir: knative-serving
Topics:
- Name: Getting started with Knative Serving
Dir: getting-started
Topics:
- Name: Creating Serverless applications
File: serverless-applications
- Name: Verifying application deployment
File: verifying-application-deployment
- Name: Autoscaling
Dir: autoscaling
Topics:
- Name: Autoscaling overview
File: serverless-autoscaling-developer
- Name: Scale bounds
File: serverless-autoscaling-developer-scale-bounds
- Name: Concurrency
File: serverless-concurrency
- Name: Scale-to-zero
File: serverless-autoscaling-scale-to-zero
- Name: Configuring Serverless applications
Dir: config-applications
Topics:
- Name: Overriding system deployment configurations
File: overriding-config
- Name: EmptyDir volumes
File: empty-dir
- Name: Persistent Volume Claims
File: pvcs-for-serving
- Name: Init containers
File: init-containers
- Name: Resolving image tags to digests
File: resolving-image-tags-to-digests
- Name: Restrictive network policies
File: restrictive-network-policies
- Name: Traffic splitting
Dir: traffic-splitting
Topics:
- Name: Traffic splitting overview
File: traffic-splitting-overview
- Name: Traffic spec examples
File: traffic-spec-examples
- Name: Traffic splitting using the CLI
File: traffic-splitting-using-cli
- Name: CLI flags for traffic splitting
File: traffic-splitting-flags
- Name: Splitting traffic between revisions
File: traffic-splitting-revisions
- Name: Rerouting traffic using blue-green strategy
File: traffic-splitting-blue-green
- Name: External and Ingress routing
Dir: external-ingress-routing
Topics:
- Name: Routing overview
File: routing-overview
- Name: Customizing labels and annotations
File: customize-labels-annotations-routes
- Name: Configuring routes for Knative services
File: configuring-service-routes
- Name: Global HTTPS redirection
File: https-redirect-global
- Name: URL scheme for external routes
File: url-scheme-external-routes
- Name: HTTPS redirection per service
File: https-redirect-per-service
- Name: Cluster local availability
File: cluster-local-availability
- Name: Kourier Gateway service type
File: kourier-gateway-service-type
- Name: Using HTTP2 and gRPC
File: using-http2-gRPC
- Name: Configuring access to Knative services
Dir: config-access
Topics:
- Name: Configuring JSON Web Token authentication for Knative services
File: serverless-ossm-with-kourier-jwt
- Name: Using JSON Web Token authentication with Service Mesh 2.x
File: serverless-ossm-v2x-jwt
- Name: Using JSON Web Token authentication with Service Mesh 1.x
File: serverless-ossm-v1x-jwt
- Name: Configuring custom domains for Knative services
Dir: config-custom-domains
Topics:
- Name: Configuring custom domains overview
File: serverless-custom-domains
- Name: Custom domain mapping
File: create-domain-mapping
- Name: Custom domains using the Knative CLI
File: create-domain-mapping-kn
- Name: Domain mapping using the Developer perspective
File: domain-mapping-odc-developer
- Name: Domain mapping using the Administrator perspective
File: domain-mapping-odc-admin
- Name: Securing a mapped service using a TLS certificate
File: domain-mapping-custom-tls-cert
- Name: Configuring high availability for Knative services
Dir: config-ha-services
Topics:
- Name: High availability for Knative services overview
File: ha-services-overview
- Name: High availability for Knative services
File: ha-replicas-serving
- Name: Knative CLI
Dir: cli_tools
Topics:
@@ -379,14 +482,6 @@ Topics:
- Name: Develop
Dir: develop
Topics:
- Name: Serverless applications
File: serverless-applications
- Name: Autoscaling
File: serverless-autoscaling-developer
- Name: Traffic management
File: serverless-traffic-management
- Name: Routing
File: serverless-configuring-routes
- Name: Event sinks
File: serverless-event-sinks
- Name: Event delivery
@@ -437,10 +532,6 @@ Topics:
Topics:
- Name: Configuring TLS authentication
File: serverless-config-tls
- Name: Configuring JSON Web Token authentication for Knative services
File: serverless-ossm-with-kourier-jwt
- Name: Configuring a custom domain for a Knative service
File: serverless-custom-domains
- Name: Functions
Dir: functions
Topics:

115
_topic_maps/_topic_map_rosa.yml
View File

@@ -563,6 +563,109 @@ Topics:
File: installing-knative-eventing
- Name: Configuring Serverless Functions
File: configuring-serverless-functions
- Name: Knative Serving
Dir: knative-serving
Topics:
- Name: Getting started with Knative Serving
Dir: getting-started
Topics:
- Name: Creating Serverless applications
File: serverless-applications
- Name: Verifying application deployment
File: verifying-application-deployment
- Name: Autoscaling
Dir: autoscaling
Topics:
- Name: Autoscaling overview
File: serverless-autoscaling-developer
- Name: Scale bounds
File: serverless-autoscaling-developer-scale-bounds
- Name: Concurrency
File: serverless-concurrency
- Name: Scale-to-zero
File: serverless-autoscaling-scale-to-zero
- Name: Configuring Serverless applications
Dir: config-applications
Topics:
- Name: Overriding system deployment configurations
File: overriding-config
- Name: EmptyDir volumes
File: empty-dir
- Name: Persistent Volume Claims
File: pvcs-for-serving
- Name: Init containers
File: init-containers
- Name: Resolving image tags to digests
File: resolving-image-tags-to-digests
- Name: Restrictive network policies
File: restrictive-network-policies
- Name: Traffic splitting
Dir: traffic-splitting
Topics:
- Name: Traffic splitting overview
File: traffic-splitting-overview
- Name: Traffic spec examples
File: traffic-spec-examples
- Name: Traffic splitting using the CLI
File: traffic-splitting-using-cli
- Name: CLI flags for traffic splitting
File: traffic-splitting-flags
- Name: Splitting traffic between revisions
File: traffic-splitting-revisions
- Name: Reroute traffic using blue-green strategy
File: traffic-splitting-blue-green
- Name: External and Ingress routing
Dir: external-ingress-routing
Topics:
- Name: Routing overview
File: routing-overview
- Name: Customizing labels and annotations
File: customize-labels-annotations-routes
- Name: Configuring routes for Knative services
File: configuring-service-routes
- Name: Global HTTPS redirection
File: https-redirect-global
- Name: URL scheme for external routes
File: url-scheme-external-routes
- Name: HTTPS redirection per service
File: https-redirect-per-service
- Name: Cluster local availability
File: cluster-local-availability
- Name: Kourier Gateway service type
File: kourier-gateway-service-type
- Name: Using HTTP2 and gRPC
File: using-http2-gRPC
- Name: Configuring access to Knative services
Dir: config-access
Topics:
- Name: Configuring JSON Web Token authentication for Knative services
File: serverless-ossm-with-kourier-jwt
- Name: Using JSON Web Token authentication with Service Mesh 2.x
File: serverless-ossm-v2x-jwt
- Name: Using JSON Web Token authentication with Service Mesh 1.x
File: serverless-ossm-v1x-jwt
- Name: Configuring custom domains for Knative services
Dir: config-custom-domains
Topics:
- Name: Configuring custom domains overview
File: serverless-custom-domains
- Name: Custom domain mapping
File: create-domain-mapping
- Name: Custom domains using the Knative CLI
File: create-domain-mapping-kn
- Name: Domain mapping using the Developer perspective
File: domain-mapping-odc-developer
- Name: Domain mapping using the Administrator perspective
File: domain-mapping-odc-admin
- Name: Securing a mapped service using a TLS certificate
File: domain-mapping-custom-tls-cert
- Name: Configuring high availability for Knative services
Dir: config-ha-services
Topics:
- Name: High availability for Knative services overview
File: ha-services-overview
- Name: High availability for Knative services
File: ha-replicas-serving
- Name: Knative CLI
Dir: cli_tools
Topics:
@@ -577,14 +680,6 @@ Topics:
- Name: Develop
Dir: develop
Topics:
- Name: Serverless applications
File: serverless-applications
- Name: Autoscaling
File: serverless-autoscaling-developer
- Name: Traffic management
File: serverless-traffic-management
- Name: Routing
File: serverless-configuring-routes
- Name: Event sinks
File: serverless-event-sinks
- Name: Event delivery
@@ -635,10 +730,6 @@ Topics:
Topics:
- Name: Configuring TLS authentication
File: serverless-config-tls
- Name: Configuring JSON Web Token authentication for Knative services
File: serverless-ossm-with-kourier-jwt
- Name: Configuring a custom domain for a Knative service
File: serverless-custom-domains
- Name: Functions
Dir: functions
Topics:

8
applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc
View File

@@ -84,10 +84,8 @@ include::modules/odc-exporting-an-application-to-another-project-or-cluster.adoc
[id="additional-resources_odc-creating-applications-using-developer-perspective"]
== Additional resources
* For more information about Knative routing settings for {ServerlessProductName}, see xref:../../serverless/develop/serverless-configuring-routes.adoc#serverless-configuring-routes[Routing].
* For more information about domain mapping settings for {ServerlessProductName}, see xref:../../serverless/security/serverless-custom-domains.adoc#serverless-custom-domains[Configuring a custom domain for a Knative service].
* For more information about Knative autoscaling settings for {ServerlessProductName}, see xref:../../serverless/develop/serverless-autoscaling-developer.adoc#serverless-autoscaling-developer[Autoscaling].
* For more information about Knative routing settings for {ServerlessProductName}, see xref:../../serverless/knative-serving/external-ingress-routing/routing-overview.adoc#routing-overview[Routing].
* For more information about domain mapping settings for {ServerlessProductName}, see xref:../../serverless/knative-serving/config-custom-domains/serverless-custom-domains.adoc#serverless-custom-domains[Configuring a custom domain for a Knative service].
* For more information about Knative autoscaling settings for {ServerlessProductName}, see xref:../../serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc#serverless-autoscaling-developer[Autoscaling].
* For more information about adding a new user to a project, see xref:../projects/working-with-projects.adoc#odc-providing-project-permissions-using-developer-perspective_projects[Working with projects].
* For more information about creating a Helm Chart repository, see xref:../working_with_helm_charts/configuring-custom-helm-chart-repositories.adoc#odc-creating-helm-releases-using-developer-perspective_configuring-custom-helm-chart-repositories[Creating Helm Chart repositories].

4
modules/interacting-serverless-apps-http2-gRPC.adoc
View File

@@ -1,13 +1,11 @@
// Module included in the following assemblies:
//
// serverless/develop/serverless-applications.adoc
// serverless/knative-serving/external-ingress-routing/using-http2-gRPC.adoc
:_content-type: PROCEDURE
[id="interacting-serverless-apps-http2-gRPC_{context}"]
= Interacting with a serverless application using HTTP2 and gRPC
{ServerlessProductName} supports only insecure or edge-terminated routes. Insecure or edge-terminated routes do not support HTTP2 on {product-title}. These routes also do not support gRPC because gRPC is transported by HTTP2. If you use these protocols in your application, you must call the application using the ingress gateway directly. To do this you must find the ingress gateway's public address and the application's specific host.
[IMPORTANT]
====
This method needs to expose Kourier Gateway using the `LoadBalancer` service type. You can configure this by adding the following YAML to your `KnativeServing` custom resource definition (CRD):

14
modules/knative-service-cluster-local.adoc
View File

@@ -1,24 +1,12 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-configuring-routes.adoc
// * serverless/knative-serving/external-ingress-routing/routing-overview.adoc
:_content-type: PROCEDURE
[id="knative-service-cluster-local_{context}"]
= Setting cluster availability to cluster local
By default, Knative services are published to a public IP address.
Being published to a public IP address means that Knative services are public applications, and have a publicly accessible URL.
Publicly accessible URLs are accessible from outside of the cluster.
However, developers may need to build back-end services that are only be accessible from inside the cluster, known as _private services_.
// Cluster administrators can configure private services for the cluster so that all services are private by default.
// Need to add additional details about editing the configmap for admins
Developers can label individual services in the cluster with the `networking.knative.dev/visibility=cluster-local` label to make them private.
[IMPORTANT]
====
For {ServerlessProductName} 1.15.0 and newer versions, the `serving.knative.dev/visibility` label is no longer available. You must update existing services to use the `networking.knative.dev/visibility` label instead.
====
// remove note for 4.10, OSD
.Prerequisites

4
modules/odc-splitting-traffic-between-revisions-using-developer-perspective.adoc
View File

@@ -6,10 +6,6 @@
[id="odc-splitting-traffic-between-revisions-using-developer-perspective_{context}"]
= Managing traffic between revisions by using the {product-title} web console
After you create a serverless application, the application is displayed in the *Topology* view of the *Developer* perspective in the {product-title} web console. The application revision is represented by the node, and the Knative service is indicated by a quadrilateral around the node.
Any new change in the code or the service configuration creates a new revision, which is a snapshot of the code at a given time. For a service, you can manage the traffic between the revisions of the service by splitting and routing it to the different revisions as required.
.Prerequisites
* The {ServerlessOperatorName} and Knative Serving are installed on your cluster.

7
modules/serverless-admin-init-containers.adoc
View File

@@ -6,13 +6,6 @@
[id="serverless-admin-init-containers_{context}"]
= Enabling init containers
link:https://kubernetes.io/docs/concepts/workloads/pods/init-containers/[Init containers] are specialized containers that are run before application containers in a pod. They are generally used to implement initialization logic for an application, which may include running setup scripts or downloading required configurations. You can enable the use of init containers for Knative services by modifying the `KnativeServing` custom resource (CR).
[NOTE]
====
Init containers may cause longer application start-up times and should be used with caution for serverless applications, which are expected to scale up and down frequently.
====
.Prerequisites
* You have installed {ServerlessOperatorName} and Knative Serving on your cluster.

2
modules/serverless-autoscaling-developer-maxscale.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-autoscaling-developer.adoc
// * serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
:_content-type: REFERENCE
[id="serverless-autoscaling-developer-maxscale_{context}"]

2
modules/serverless-autoscaling-developer-minscale.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-autoscaling-developer.adoc
// * serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
:_content-type: REFERENCE
[id="serverless-autoscaling-developer-minscale_{context}"]

2
modules/serverless-autoscaling-maxscale-kn.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-autoscaling-developer.adoc
// * serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
:_content-type: PROCEDURE
[id="serverless-autoscaling-maxscale-kn_{context}"]

2
modules/serverless-autoscaling-minscale-kn.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-autoscaling-developer.adoc
// * serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
:_content-type: PROCEDURE
[id="serverless-autoscaling-minscale-kn_{context}"]

2
modules/serverless-blue-green-deploy.adoc
View File

@@ -6,8 +6,6 @@
[id="serverless-blue-green-deploy_{context}"]
= Routing and managing traffic by using a blue-green deployment strategy
You can safely reroute traffic from a production version of an app to a new version, by using a link:https://en.wikipedia.org/wiki/Blue-green_deployment[blue-green deployment strategy].
.Prerequisites
* The {ServerlessOperatorName} and Knative Serving are installed on the cluster.

2
modules/serverless-concurrency-limits-configure-hard.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-autoscaling-developer.adoc
// * serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
:_content-type: PROCEDURE
[id="serverless-concurrency-limits-configure-hard_{context}"]

2
modules/serverless-concurrency-limits-configure-soft.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-autoscaling-developer.adoc
// * serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
:_content-type: PROCEDURE
[id="serverless-concurrency-limits-configure-soft_{context}"]

4
modules/serverless-config-emptydir.adoc
View File

@@ -1,14 +1,12 @@
// Module included in the following assemblies:
//
// * serverless/admin_guide/serverless-configuration.adoc
// * serverless/knative-serving/config-applications/serverless-configuration.adoc
:_content-type: REFERENCE
[id="serverless-config-emptydir_{context}"]
= Configuring the EmptyDir extension
// should probably be a procedure doc, but this is out of scope for the abstracts PR
`emptyDir` volumes are empty volumes that are created when a pod is created, and are used to provide temporary working disk space. `emptyDir` volumes are deleted when the pod they were created for is deleted.
The `kubernetes.podspec-volumes-emptydir` extension controls whether `emptyDir` volumes can be used with Knative Serving. To enable using `emptyDir` volumes, you must modify the `KnativeServing` custom resource (CR) to include the following YAML:
.Example KnativeServing CR

4
modules/serverless-config-replicas-serving.adoc
View File

@@ -1,12 +1,12 @@
// Module included in the following assemblies:
//
// * /serverless/admin_guide/serverless-ha.adoc
// * /serverless/knative-serving/config-ha-services/ha-replicas-serving.adoc
:_content-type: PROCEDURE
[id="serverless-config-replicas-serving_{context}"]
= Configuring high availability replicas for Knative Serving
High availability (HA) is available by default for the Knative Serving `activator`, `autoscaler`, `autoscaler-hpa`, `controller`, `webhook`, `kourier-control`, and `kourier-gateway` components, which are configured to have two replicas each by default. You can change the number of replicas for these components by modifying the `spec.high-availability.replicas` value in the `KnativeServing` custom resource (CR).
To specify three minimum replicas for the eligible deployment resources, set the value of the field `spec.high-availability.replicas` in the custom resource to `3`.
.Prerequisites

2
modules/serverless-create-domain-mapping-kn.adoc
View File

@@ -7,8 +7,6 @@
[id="serverless-create-domain-mapping-kn_{context}"]
= Creating a custom domain mapping by using the Knative CLI
You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service. You can use the Knative (`kn`) CLI to create a `DomainMapping` custom resource (CR) that maps to an Addressable target CR, such as a Knative service or a Knative route.
.Prerequisites
* The {ServerlessOperatorName} and Knative Serving are installed on your cluster.

2
modules/serverless-create-domain-mapping.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/security/serverless-custom-domains.adoc
// * serverless/knative-serving/config-custom-domains/create-domain-mapping.adoc
:_content-type: PROCEDURE
[id="serverless-create-domain-mapping_{context}"]

2
modules/serverless-create-traffic-split-kn.adoc
View File

@@ -6,8 +6,6 @@
[id="serverless-create-traffic-split-kn_{context}"]
= Creating a traffic split by using the Knative CLI
Using the Knative (`kn`) CLI to create traffic splits provides a more streamlined and intuitive user interface over modifying YAML files directly. You can use the `kn service update` command to split traffic between revisions of a service.
.Prerequisites
* The {ServerlessOperatorName} and Knative Serving are installed on your cluster.

4
modules/serverless-customize-labels-annotations-routes.adoc
View File

@@ -1,13 +1,11 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-configuring-routes.adoc
// * serverless/knative-serving/external-ingress-routing/customize-labels-annotations-routes.adoc
:_content-type: PROCEDURE
[id="serverless-customize-labels-annotations-routes_{context}"]
= Customizing labels and annotations for {product-title} routes
{product-title} routes support the use of custom labels and annotations, which you can configure by modifying the `metadata` spec of a Knative service. Custom labels and annotations are propagated from the service to the Knative route, then to the Knative ingress, and finally to the {product-title} route.
.Prerequisites
* You must have the {ServerlessOperatorName} and Knative Serving installed on your {product-title} cluster.

3
modules/serverless-domain-mapping-custom-tls-cert.adoc
View File

@@ -1,7 +1,6 @@
// Module included in the following assemblies:
//
// * /serverless/security/serverless-custom-domains.adoc
// * /serverless/security/serverless-config-tls.adoc
// * /serverless/knative-serving/config-custom-domains/domain-mapping-custom-tls-cert.adoc
:_content-type: PROCEDURE
[id="serverless-domain-mapping-custom-tls-cert_{context}"]

2
modules/serverless-domain-mapping-odc-developer.adoc
View File

@@ -6,8 +6,6 @@
[id="serverless-domain-mapping-odc-developer_{context}"]
= Mapping a custom domain to a service by using the Developer perspective
You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service. You can use the *Developer* perspective of the {product-title} web console to map a `DomainMapping` custom resource (CR) to a Knative service.
.Prerequisites
* You have logged in to the web console.

2
modules/serverless-enable-scale-to-zero.adoc
View File

@@ -6,7 +6,7 @@
[id="serverless-enable-scale-to-zero_{context}"]
= Enabling scale-to-zero
Knative Serving provides automatic scaling, or _autoscaling_, for applications to match incoming demand. You can use the `enable-scale-to-zero` spec to enable or disable scale-to-zero globally for applications on the cluster.
You can use the `enable-scale-to-zero` spec to enable or disable scale-to-zero globally for applications on the cluster.
.Prerequisites

1
modules/serverless-enabling-pvc-support.adoc
View File

@@ -6,7 +6,6 @@
[id="serverless-enabling-pvc-support_{context}"]
= Enabling PVC support
Some serverless applications need permanent data storage. To achieve this, you can configure persistent volume claims (PVCs) for your Knative services.
.Procedure

4
modules/serverless-https-redirect-global.adoc
View File

@@ -1,13 +1,11 @@
// Module included in the following assemblies:
//
// * serverless/admin_guide/serverless-configuration.adoc
// * serverless/knative-serving/external-ingress-routing/https-redirect-global.adoc
:_content-type: REFERENCE
[id="serverless-https-redirect-global_{context}"]
= HTTPS redirection global settings
HTTPS redirection provides redirection for incoming HTTP requests. These redirected HTTP requests are encrypted. You can enable HTTPS redirection for all services on the cluster by configuring the `httpProtocol` spec for the `KnativeServing` custom resource (CR).
.Example `KnativeServing` CR that enables HTTPS redirection
[source,yaml]
----

6
modules/serverless-https-redirect-service.adoc
View File

@@ -1,13 +1,13 @@
// Module is included in the following assemblies:
//
// * serverless/develop/serverless-applications.adoc
// * serverless/knative-serving/external-ingress-routing/https-redirect-per-service.adoc
:_content-type: REFERENCE
[id="serverless-https-redirect-service_{context}"]
= HTTPS redirection per service
= Redirecting HTTPS for a service
// need better details from eng team about use case to update this topic
You can enable or disable HTTPS redirection for a service by configuring the `networking.knative.dev/http-option` annotation. The following example shows how you can use this annotation in a Knative `Service` YAML object:
The following example shows how you can use this annotation in a Knative `Service` YAML object:
[source,yaml]
----

15
modules/serverless-kourier-gateway-service-type.adoc
View File

@@ -1,25 +1,12 @@
// Module included in the following assemblies
//
// * serverless/admin_guide/serverless-configuration.adoc
// * serverless/knative-serving/external-ingress-routing/kourier-gateway-service-type.adoc
:_content-type: REFERENCE
[id="serverless-kourier-gateway-service-type_{context}"]
= Setting the Kourier Gateway service type
// should probably be a procedure but this is out of scope for the abstracts PR
The Kourier Gateway is exposed by default as the `ClusterIP` service type. This service type is determined by the `service-type` ingress spec in the `KnativeServing` custom resource (CR).
.Default spec
[source,yaml]
----
...
spec:
ingress:
kourier:
service-type: ClusterIP
...
----
You can override the default service type to use a load balancer service type instead by modifying the `service-type` spec:
.LoadBalancer override spec

8
modules/serverless-openshift-routes.adoc
View File

@@ -1,17 +1,11 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-configuring-routes.adoc
// * serverless/knative-serving/external-ingress-routing/configuring-service-routes.adoc
:_content-type: PROCEDURE
[id="serverless-openshift-routes_{context}"]
= Configuring {product-title} routes for Knative services
If you want to configure a Knative service to use your TLS certificate on {product-title}, you must disable the automatic creation of a route for the service by the {ServerlessOperatorName} and instead manually create a route for the service.
[NOTE]
====
When you complete the following procedure, the default {product-title} route in the `knative-serving-ingress` namespace is not created. However, the Knative route for the application is still created in this namespace.
====
.Prerequisites

6
modules/serverless-ossm-v1x-jwt.adoc
View File

@@ -1,12 +1,10 @@
// Module included in the following assemblies:
//
// * serverless/security/serverless-ossm-with-kourier-jwt.adoc
// * serverless/knative-serving/config-access/serverless-ossm-with-kourier-jwt.adoc
:_content-type: PROCEDURE
[id="serverless-ossm-v1x-jwt_{context}"]
= Using JSON Web Token authentication with {SMProductShortName} 1.x and {ServerlessProductName}
You can use JSON Web Token (JWT) authentication with Knative services by using {SMProductShortName} 1.x and {ServerlessProductName}. To do this, you must create a policy in the application namespace that is a member of the `ServiceMeshMemberRoll` object. You must also enable sidecar injection for the service.
= Configuring JSON Web Token authentication for {SMProductShortName} 1.x and {ServerlessProductName}
[IMPORTANT]
====

6
modules/serverless-ossm-v2x-jwt.adoc
View File

@@ -1,12 +1,10 @@
// Module included in the following assemblies:
//
// * serverless/security/serverless-ossm-with-kourier-jwt.adoc
// * serverless/knative-serving/config-access/serverless-ossm-with-kourier-jwt.adoc
:_content-type: PROCEDURE
[id="serverless-ossm-v2x-jwt_{context}"]
= Using JSON Web Token authentication with {SMProductShortName} 2.x and {ServerlessProductName}
You can use JSON Web Token (JWT) authentication with Knative services by using {SMProductShortName} 2.x and {ServerlessProductName}. To do this, you must create authentication requests and policies in the application namespace that is a member of the `ServiceMeshMemberRoll` object. You must also enable sidecar injection for the service.
= Configuring JSON Web Token authentication for {SMProductShortName} 2.x and {ServerlessProductName}
[IMPORTANT]
====

76
modules/serverless-services-network-policies-enabling-comms.adoc Normal file
View File

@@ -0,0 +1,76 @@
// Module included in the following assemblies:
//
// * serverless/knative-serving/config-applications/restrictive-cluster-policies.adoc
:_content-type: PROCEDURE
[id="serverless-services-network-policies-enabling-comms_{context}"]
= Enabling communication with Knative applications on a cluster with restrictive network policies
To allow access to your applications from Knative system pods, you must add a label to each of the Knative system namespaces, and then create a `NetworkPolicy` object in your application namespace that allows access to the namespace for other namespaces that have this label.
[IMPORTANT]
====
A network policy that denies requests to non-Knative services on your cluster still prevents access to these services. However, by allowing access from Knative system namespaces to your Knative application, you are allowing access to your Knative application from all namespaces in the cluster.
If you do not want to allow access to your Knative application from all namespaces on the cluster, you might want to use _JSON Web Token authentication for Knative services_ instead. JSON Web Token authentication for Knative services requires Service Mesh.
====
.Prerequisites
* Install the OpenShift CLI (`oc`).
* {ServerlessOperatorName} and Knative Serving are installed on your cluster.
.Procedure
. Add the `knative.openshift.io/system-namespace=true` label to each Knative system namespace that requires access to your application:
.. Label the `knative-serving` namespace:
+
[source, terminal]
----
$ oc label namespace knative-serving knative.openshift.io/system-namespace=true
----
.. Label the `knative-serving-ingress` namespace:
+
[source, terminal]
----
$ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
----
.. Label the `knative-eventing` namespace:
+
[source, terminal]
----
$ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
----
.. Label the `knative-kafka` namespace:
+
[source, terminal]
----
$ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
----
. Create a `NetworkPolicy` object in your application namespace to allow access from namespaces with the `knative.openshift.io/system-namespace` label:
+
.Example `NetworkPolicy` object
[source,yaml]
----
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: <network_policy_name> <1>
namespace: <namespace> <2>
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
knative.openshift.io/system-namespace: "true"
podSelector: {}
policyTypes:
- Ingress
----
<1> Provide a name for your network policy.
<2> The namespace where your application exists.

75
modules/serverless-services-network-policies.adoc
View File

@@ -1,10 +1,10 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-applications.adoc
// * serverless/knative-serving/config-applications/restrictive-cluster-policies.adoc
:_content-type: PROCEDURE
:_content-type: Concept
[id="serverless-services-network-policies_{context}"]
= Enabling communication with Knative applications on a cluster with restrictive network policies
= Clusters with restrictive network policies
If you are using a cluster that multiple users have access to, your cluster might use network policies to control which pods, services, and namespaces can communicate with each other over the network. If your cluster uses restrictive network policies, it is possible that Knative system pods are not able to access your Knative application. For example, if your namespace has the following network policy, which denies all requests, Knative system pods cannot access your Knative application:
@@ -20,72 +20,3 @@ spec:
podSelector:
ingress: []
----
To allow access to your applications from Knative system pods, you must add a label to each of the Knative system namespaces, and then create a `NetworkPolicy` object in your application namespace that allows access to the namespace for other namespaces that have this label.
[IMPORTANT]
====
A network policy that denies requests to non-Knative services on your cluster still prevents access to these services. However, by allowing access from Knative system namespaces to your Knative application, you are allowing access to your Knative application from all namespaces in the cluster.
If you do not want to allow access to your Knative application from all namespaces on the cluster, you might want to use _JSON Web Token authentication for Knative services_ instead. JSON Web Token authentication for Knative services requires Service Mesh.
====
.Prerequisites
* Install the OpenShift CLI (`oc`).
* {ServerlessOperatorName} and Knative Serving are installed on your cluster.
.Procedure
. Add the `knative.openshift.io/system-namespace=true` label to each Knative system namespace that requires access to your application:
.. Label the `knative-serving` namespace:
+
[source, terminal]
----
$ oc label namespace knative-serving knative.openshift.io/system-namespace=true
----
.. Label the `knative-serving-ingress` namespace:
+
[source, terminal]
----
$ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
----
.. Label the `knative-eventing` namespace:
+
[source, terminal]
----
$ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
----
.. Label the `knative-kafka` namespace:
+
[source, terminal]
----
$ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
----
. Create a `NetworkPolicy` object in your application namespace to allow access from namespaces with the `knative.openshift.io/system-namespace` label:
+
.Example `NetworkPolicy` object
[source,yaml]
----
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: <network_policy_name> <1>
namespace: <namespace> <2>
spec:
ingress:
- from:
- namespaceSelector:
matchLabels:
knative.openshift.io/system-namespace: "true"
podSelector: {}
policyTypes:
- Ingress
----
<1> Provide a name for your network policy.
<2> The namespace where your application exists.

2
modules/serverless-tag-to-digest-resolution.adoc
View File

@@ -6,8 +6,6 @@
[id="serverless-tag-to-digest-resolution_{context}"]
= Tag-to-digest resolution
If the Knative Serving controller has access to the container registry, Knative Serving resolves image tags to a digest when you create a revision of a service. This is known as _tag-to-digest resolution_, and helps to provide consistency for deployments.
To give the controller access to the container registry on {product-title}, you must create a secret and then configure controller custom certificates. You can configure controller custom certificates by modifying the `controller-custom-certs` spec in the `KnativeServing` custom resource (CR). The secret must reside in the same namespace as the `KnativeServing` CR.
If a secret is not included in the `KnativeServing` CR, this setting defaults to using public key infrastructure (PKI). When using PKI, the cluster-wide certificates are automatically injected into the Knative Serving controller by using the `config-service-sa` config map. The {ServerlessOperatorName} populates the `config-service-sa` config map with cluster-wide certificates and mounts the config map as a volume to the controller.

2
modules/serverless-target-utilization.adoc
View File

@@ -1,6 +1,6 @@
// Module included in the following assemblies:
//
// * serverless/develop/serverless-autoscaling-developer.adoc
// * serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
:_content-type: REFERENCE
[id="serverless-target-utilization_{context}"]

4
modules/serverless-traffic-splitting-flags-kn.adoc
View File

@@ -4,9 +4,7 @@
:_content-type: REFERENCE
[id="serverless-traffic-splitting-flags-kn_{context}"]
= Knative CLI traffic management flags
The Knative (`kn`) CLI supports traffic operations on the traffic block of a service as part of the `kn service update` command.
= Knative CLI traffic splitting flags
The following table displays a summary of traffic splitting flags, value formats, and the operation the flag performs. The *Repetition* column denotes whether repeating the particular value of flag is allowed in a `kn service update` command.

4
modules/serverless-url-scheme-external-routes.adoc
View File

@@ -1,14 +1,12 @@
// Module included in the following assemblies
//
// * serverless/admin_guide/serverless-configuration.adoc
// * serverless/knative-serving/external-ingress-routing/url-scheme-external-routes.adoc
:_content-type: REFERENCE
[id="serverless-url-scheme-external-routes_{context}"]
= Setting the URL scheme for external routes
// should probably be a procedure, but this is out of scope for the abstracts PR
The URL scheme of external routes defaults to HTTPS for enhanced security. This scheme is determined by the `default-external-scheme` key in the `KnativeServing` custom resource (CR) spec.
.Default spec
[source,yaml]
----

5
serverless/admin_guide/serverless-admin-perspective.adoc
View File

@@ -10,8 +10,7 @@ If you do not want to switch to the *Developer* perspective in the {product-titl
// Create services as an admin
include::modules/creating-serverless-apps-admin-console.adoc[leveloffset=+1]
// domain mapping as an admin
include::modules/serverless-domain-mapping-odc-admin.adoc[leveloffset=+1]
// Event sources
include::modules/serverless-creating-event-source-admin-web-console.adoc[leveloffset=+1]
// Brokers
@@ -26,7 +25,7 @@ include::modules/serverless-creating-subscription-admin-web-console.adoc[levelof
[id="additional-resources_serverless-cluster-admin-eventing"]
[role="_additional-resources"]
== Additional resources
* xref:../../serverless/develop/serverless-applications.adoc#serverless-applications[Serverless applications]
* xref:../../serverless/knative-serving/getting-started/serverless-applications.adoc#serverless-applications[Serverless applications]
* xref:../../serverless/discover/knative-event-sources.adoc#knative-event-sources[Event sources]
* xref:../../serverless/develop/serverless-using-brokers.adoc#serverless-using-brokers[Brokers]
* xref:../../serverless/develop/serverless-triggers.adoc#serverless-triggers[Triggers]

30
serverless/admin_guide/serverless-configuration.adoc
View File

@@ -22,22 +22,7 @@ include::modules/serverless-global-config-broker-class-default.adoc[leveloffset=
* xref:../../serverless/admin_guide/serverless-kafka-admin.adoc#serverless-kafka-broker-configmap_serverless-kafka-admin[Configuring Kafka broker settings]
* xref:../../serverless/admin_guide/serverless-configuration.adoc#serverless-broker-backing-channel-default_serverless-configuration[Configuring the default broker backing channel]
// Knative Serving
//autoscaling
include::modules/serverless-enable-scale-to-zero.adoc[leveloffset=+1]
include::modules/serverless-scale-to-zero-grace-period.adoc[leveloffset=+1]
// deployments
[id="serverless-configuration-CR-system-deployments"]
== Overriding system deployment configurations
You can override the default configurations for some specific deployments by modifying the `deployments` spec in the `KnativeServing` and `KnativeEventing` custom resources (CRs).
include::modules/knative-serving-CR-system-deployments.adoc[leveloffset=+2]
[role="_additional-resources"]
.Additional resources
* link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#probe-v1-core[Probe configuration section of the Kubernetes API documentation]
include::modules/knative-eventing-CR-system-deployments.adoc[leveloffset=+2]
@@ -45,21 +30,6 @@ include::modules/knative-eventing-CR-system-deployments.adoc[leveloffset=+2]
.Additional resources
* link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#probe-v1-core[Probe configuration section of the Kubernetes API documentation]
// enable emptydirs
include::modules/serverless-config-emptydir.adoc[leveloffset=+1]
// global https redirect
include::modules/serverless-https-redirect-global.adoc[leveloffset=+1]
// URL scheme for external routes
include::modules/serverless-url-scheme-external-routes.adoc[leveloffset=+1]
// Kourier Gateway service type
include::modules/serverless-kourier-gateway-service-type.adoc[leveloffset=+1]
// Enabling PVC for Serving
include::modules/serverless-enabling-pvc-support.adoc[leveloffset=+1]
// enable init containers
include::modules/serverless-admin-init-containers.adoc[leveloffset=+1]
// Tag to digest resolution
include::modules/serverless-tag-to-digest-resolution.adoc[leveloffset=+1]
include::modules/knative-serving-controller-custom-certs-secrets.adoc[leveloffset=+2]
ifdef::openshift-enterprise[]
[id="additional-resources_knative-serving-CR-config"]

6
serverless/admin_guide/serverless-ha.adoc
View File

@@ -6,11 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
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 readily available. This controller takes over processing of the APIs that were being serviced by the controller that is now unavailable.
include::snippets/serverless-ha-intro.adoc[]
HA in {ServerlessProductName} is available through leader election, which is enabled by default after the Knative Serving or Eventing control plane is installed. When using a leader election HA pattern, instances of controllers are already scheduled and running inside the cluster before they are required.
These controller instances compete to use a shared resource, known as the leader election lock. The instance of the controller that has access to the leader election lock resource at any given time is called the leader.
include::modules/serverless-config-replicas-serving.adoc[leveloffset=+1]
include::modules/serverless-config-replicas-eventing.adoc[leveloffset=+1]
include::modules/serverless-config-replicas-kafka.adoc[leveloffset=+1]

49
serverless/develop/serverless-applications.adoc
View File

@@ -1,49 +0,0 @@
:_content-type: ASSEMBLY
[id="serverless-applications"]
= Serverless applications
include::_attributes/common-attributes.adoc[]
:context: serverless-applications
toc::[]
include::snippets/serverless-apps.adoc[]
You can create a serverless application by using one of the following methods:
* Create a Knative service from the {product-title} web console.
+
ifdef::openshift-enterprise[]
See xref:../../applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc#odc-creating-applications-using-developer-perspective[Creating applications using the Developer perspective] for more information.
endif::[]
* Create a Knative service by using the Knative (`kn`) CLI.
* Create and apply a Knative `Service` object as a YAML file, by using the `oc` CLI.
// create service using CLI
include::modules/creating-serverless-apps-kn.adoc[leveloffset=+1]
// offline mode
include::modules/kn-service-offline-create.adoc[leveloffset=+1]
// create service using YAML
include::modules/creating-serverless-apps-yaml.adoc[leveloffset=+1]
include::modules/verifying-serverless-app-deployment.adoc[leveloffset=+1]
include::modules/interacting-serverless-apps-http2-gRPC.adoc[leveloffset=+1]
// OCP only
ifdef::openshift-enterprise[]
// Using Knative services w/ restrictive NetworkPolicies
include::modules/serverless-services-network-policies.adoc[leveloffset=+1]
endif::[]
// move to admin guide, outside scope of this PR
// config init containers
include::modules/serverless-init-containers-apps.adoc[leveloffset=+1]
// HTTPS redirection
include::modules/serverless-https-redirect-service.adoc[leveloffset=+1]
[id="additional-resources_serverless-applications"]
[role="_additional-resources"]
== Additional resources
* xref:../../serverless/cli_tools/kn-serving-ref.adoc#kn-serving-ref[Knative Serving CLI commands]
* xref:../../serverless/security/serverless-ossm-with-kourier-jwt.adoc#serverless-ossm-with-kourier-jwt[Configuring JSON Web Token authentication for Knative services]

114
serverless/develop/serverless-traffic-management.adoc
View File

@@ -1,114 +0,0 @@
:_content-type: ASSEMBLY
[id="serverless-traffic-management"]
= Traffic management
include::_attributes/common-attributes.adoc[]
:context: serverless-traffic-management
toc::[]
In a Knative application, traffic can be managed by creating a traffic split. A traffic split is configured as part of a route, which is managed by a Knative service.
image::knative-service-architecture.png[Traffic management for a Knative application]
Configuring a route allows requests to be sent to different revisions of a service. This routing is determined by the `traffic` spec of the `Service` object.
// add additional resources link to knative services /apps docs
A `traffic` spec declaration consists of one or more revisions, each responsible for handling a portion of the overall traffic. The percentages of traffic routed to each revision must add up to 100%, which is ensured by a Knative validation.
The revisions specified in a `traffic` spec can either be a fixed, named revision, or can point to the “latest” revision, which tracks the head of the list of all revisions for the service. The "latest" revision is a type of floating reference that updates if a new revision is created. Each revision can have a tag attached that creates an additional access URL for that revision.
The `traffic` spec can be modified by:
* Editing the YAML of a `Service` object directly.
* Using the Knative (`kn`) CLI `--traffic` flag.
* Using the {product-title} web console.
When you create a Knative service, it does not have any default `traffic` spec settings.
[id="serverless-traffic-management-spec-examples"]
== Traffic spec examples
The following example shows a `traffic` spec where 100% of traffic is routed to the latest revision of the service. Under `status`, you can see the name of the latest revision that `latestRevision` resolves to:
[source,yaml]
----
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: example-service
namespace: default
spec:
...
traffic:
- latestRevision: true
percent: 100
status:
...
traffic:
- percent: 100
revisionName: example-service
----
The following example shows a `traffic` spec where 100% of traffic is routed to the revision tagged as `current`, and the name of that revision is specified as `example-service`. The revision tagged as `latest` is kept available, even though no traffic is routed to it:
[source,yaml]
----
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: example-service
namespace: default
spec:
...
traffic:
- tag: current
revisionName: example-service
percent: 100
- tag: latest
latestRevision: true
percent: 0
----
The following example shows how the list of revisions in the `traffic` spec can be extended so that traffic is split between multiple revisions. This example sends 50% of traffic to the revision tagged as `current`, and 50% of traffic to the revision tagged as `candidate`. The revision tagged as `latest` is kept available, even though no traffic is routed to it:
[source,yaml]
----
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: example-service
namespace: default
spec:
...
traffic:
- tag: current
revisionName: example-service-1
percent: 50
- tag: candidate
revisionName: example-service-2
percent: 50
- tag: latest
latestRevision: true
percent: 0
----
// kn flags
include::modules/serverless-traffic-splitting-flags-kn.adoc[leveloffset=+1]
// creating custom URLs by using tags
include::modules/serverless-custom-revision-urls.adoc[leveloffset=+2]
// kn CLI
include::modules/serverless-create-traffic-split-kn.adoc[leveloffset=+1]
// ODC
include::modules/odc-splitting-traffic-between-revisions-using-developer-perspective.adoc[leveloffset=+1]
// blue-green
include::modules/serverless-blue-green-deploy.adoc[leveloffset=+1]
////
# move this to services / apps docs eventually, also include diagram again there
Each time the configuration of a service is updated, a new revision for the service is created.
A revision is a point-in-time snapshot of the code and configuration for each modification made to a Knative service. Revisions are immutable objects and can be retained for as long as they are required or used. Knative Serving revisions can be automatically scaled up and down according to incoming traffic.
////

2
serverless/integrations/serverless-ossm-setup.adoc
View File

@@ -22,7 +22,7 @@ To complete and verify these procedures in your deployment, you need either a ce
* You must configure the wildcard certificate to match the domain of your {product-title} cluster. For example, if your {product-title} console address is `https://console-openshift-console.apps.openshift.example.com`, you must configure the wildcard certificate so that the domain is `*.apps.openshift.example.com`. For more information about configuring wildcard certificates, see the following topic about _Creating a certificate to encrypt incoming external traffic_.
* If you want to use any domain name, including those which are not subdomains of the default {product-title} cluster domain, you must set up domain mapping for those domains. For more information, see the {ServerlessProductName} documentation about xref:../../serverless/security/serverless-custom-domains.adoc#serverless-create-domain-mapping_serverless-custom-domains[Creating a custom domain mapping].
* If you want to use any domain name, including those which are not subdomains of the default {product-title} cluster domain, you must set up domain mapping for those domains. For more information, see the {ServerlessProductName} documentation about xref:../../serverless/knative-serving/config-custom-domains/create-domain-mapping.adoc#serverless-create-domain-mapping_create-domain-mapping[Creating a custom domain mapping].
include::modules/serverless-ossm-external-certs.adoc[leveloffset=+1]
// without kourier

1
serverless/knative-serving/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

1
serverless/knative-serving/autoscaling/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

1
serverless/knative-serving/autoscaling/images Symbolic link
View File

@@ -0,0 +1 @@
../../images/

1
serverless/knative-serving/autoscaling/modules Symbolic link
View File

@@ -0,0 +1 @@
../../modules/

17
serverless/knative-serving/autoscaling/serverless-autoscaling-developer-scale-bounds.adoc Normal file
View File

@@ -0,0 +1,17 @@
:_content-type: ASSEMBLY
[id="serverless-autoscaling-developer-scale-bounds"]
= Scale bounds
include::_attributes/common-attributes.adoc[]
:context: serverless-serving-scale-bounds
toc::[]
Scale bounds determine the minimum and maximum numbers of replicas that can serve an application at any given time. You can set scale bounds for an application to help prevent cold starts or control computing costs.
// minscale docs
include::modules/serverless-autoscaling-developer-minscale.adoc[leveloffset=+1]
include::modules/serverless-autoscaling-minscale-kn.adoc[leveloffset=+2]
// maxscale docs
include::modules/serverless-autoscaling-developer-maxscale.adoc[leveloffset=+1]
include::modules/serverless-autoscaling-maxscale-kn.adoc[leveloffset=+2]

17
serverless/develop/serverless-autoscaling-developer.adoc → serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc
View File

@@ -23,21 +23,4 @@ You can modify per-revision settings for your services by using the {product-tit
Any limits or targets that you set for a service are measured against a single instance of your application. For example, setting the `target` annotation to `50` configures the autoscaler to scale the application so that each revision handles 50 requests at a time.
====
[id="serverless-autoscaling-developer-scale-bounds"]
== Scale bounds
Scale bounds determine the minimum and maximum numbers of replicas that can serve an application at any given time. You can set scale bounds for an application to help prevent cold starts or control computing costs.
// minscale docs
include::modules/serverless-autoscaling-developer-minscale.adoc[leveloffset=+2]
include::modules/serverless-autoscaling-minscale-kn.adoc[leveloffset=+3]
// maxscale docs
include::modules/serverless-autoscaling-developer-maxscale.adoc[leveloffset=+2]
include::modules/serverless-autoscaling-maxscale-kn.adoc[leveloffset=+3]
// concurrency
include::modules/serverless-about-concurrency.adoc[leveloffset=+1]
include::modules/serverless-concurrency-limits-configure-soft.adoc[leveloffset=+2]
include::modules/serverless-concurrency-limits-configure-hard.adoc[leveloffset=+2]
include::modules/serverless-target-utilization.adoc[leveloffset=+2]

13
serverless/knative-serving/autoscaling/serverless-autoscaling-scale-to-zero.adoc Normal file
View File

@@ -0,0 +1,13 @@
:_content-type: ASSEMBLY
[id="serverless-autoscaling-scale-to-zero"]
= Scale-to-zero
include::_attributes/common-attributes.adoc[]
:context: serverless-autoscaling-scale-to-zero
toc::[]
Knative Serving provides automatic scaling, or _autoscaling_, for applications to match incoming demand.
include::modules/serverless-enable-scale-to-zero.adoc[leveloffset=+1]
include::modules/serverless-scale-to-zero-grace-period.adoc[leveloffset=+1]

14
modules/serverless-about-concurrency.adoc → serverless/knative-serving/autoscaling/serverless-concurrency.adoc
View File

@@ -1,10 +1,8 @@
// Module included in the following assemblies:
//
// * /serverless/develop/serverless-autoscaling-developer.adoc
:_content-type: CONCEPT
[id="serverless-about-concurrency_{context}"]
:_content-type: ASSEMBLY
[id="serverless-concurrency"]
= Concurrency
include::_attributes/common-attributes.adoc[]
:context: serverless-concurrency
Concurrency determines the number of simultaneous requests that can be processed by each replica of an application at any given time. Concurrency can be configured as a _soft limit_ or a _hard limit_:
@@ -20,3 +18,7 @@ Using a hard limit configuration is only recommended if there is a clear use cas
Adding a soft target and a hard limit means that the autoscaler targets the soft target number of concurrent requests, but imposes a hard limit of the hard limit value for the maximum number of requests.
If the hard limit value is less than the soft limit value, the soft limit value is tuned down, because there is no need to target more requests than the number that can actually be handled.
include::modules/serverless-concurrency-limits-configure-soft.adoc[leveloffset=+1]
include::modules/serverless-concurrency-limits-configure-hard.adoc[leveloffset=+1]
include::modules/serverless-target-utilization.adoc[leveloffset=+1]

1
serverless/knative-serving/autoscaling/snippets Symbolic link
View File

@@ -0,0 +1 @@
../../snippets/

1
serverless/knative-serving/config-access/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

1
serverless/knative-serving/config-access/images Symbolic link
View File

@@ -0,0 +1 @@
../../images/

1
serverless/knative-serving/config-access/modules Symbolic link
View File

@@ -0,0 +1 @@
../../modules/

10
serverless/knative-serving/config-access/serverless-ossm-v1x-jwt.adoc Normal file
View File

@@ -0,0 +1,10 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="serverless-ossm-v1x-jwt"]
= Using JSON Web Token authentication with {SMProductShortName} 1.x
:context: serverless-ossm-v1x-jwt
You can use JSON Web Token (JWT) authentication with Knative services by using {SMProductShortName} 1.x and {ServerlessProductName}. To do this, you must create a policy in the application namespace that is a member of the `ServiceMeshMemberRoll` object. You must also enable sidecar injection for the service.
include::modules/serverless-ossm-v1x-jwt.adoc[leveloffset=+1]

9
serverless/knative-serving/config-access/serverless-ossm-v2x-jwt.adoc Normal file
View File

@@ -0,0 +1,9 @@
:_content-type: ASSEMBLY
[id="serverless-ossm-v2x-jwt"]
= Using JSON Web Token authentication with {SMProductShortName} 2.x
include::_attributes/common-attributes.adoc[]
:context: serverless-ossm-v2x-jwt
You can use JSON Web Token (JWT) authentication with Knative services by using {SMProductShortName} 2.x and {ServerlessProductName}. To do this, you must create authentication requests and policies in the application namespace that is a member of the `ServiceMeshMemberRoll` object. You must also enable sidecar injection for the service.
include::modules/serverless-ossm-v2x-jwt.adoc[leveloffset=+1]

5
serverless/security/serverless-ossm-with-kourier-jwt.adoc → serverless/knative-serving/config-access/serverless-ossm-with-kourier-jwt.adoc
View File

@@ -4,9 +4,4 @@
include::_attributes/common-attributes.adoc[]
:context: serverless-ossm-with-kourier-jwt
toc::[]
{ServerlessProductName} does not currently have user-defined authorization features. To add user-defined authorization to your deployment, you must integrate {ServerlessProductName} with {SMProductName}, and then configure JSON Web Token (JWT) authentication and sidecar injection for Knative services.
include::modules/serverless-ossm-v2x-jwt.adoc[leveloffset=+1]
include::modules/serverless-ossm-v1x-jwt.adoc[leveloffset=+1]

1
serverless/knative-serving/config-access/snippets Symbolic link
View File

@@ -0,0 +1 @@
../../snippets/

1
serverless/knative-serving/config-applications/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

11
serverless/knative-serving/config-applications/empty-dir.adoc Normal file
View File

@@ -0,0 +1,11 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="empty-dir"]
= EmptyDir volumes
:context: empty-dir
`emptyDir` volumes are empty volumes that are created when a pod is created, and are used to provide temporary working disk space. `emptyDir` volumes are deleted when the pod they were created for is deleted.
// enable emptydirs
include::modules/serverless-config-emptydir.adoc[leveloffset=+1]

1
serverless/knative-serving/config-applications/images Symbolic link
View File

@@ -0,0 +1 @@
../../images/

15
serverless/knative-serving/config-applications/init-containers.adoc Normal file
View File

@@ -0,0 +1,15 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="init-containers"]
= Init containers
:context: init-containers
link:https://kubernetes.io/docs/concepts/workloads/pods/init-containers/[Init containers] are specialized containers that are run before application containers in a pod. They are generally used to implement initialization logic for an application, which may include running setup scripts or downloading required configurations. You can enable the use of init containers for Knative services by modifying the `KnativeServing` custom resource (CR).
[NOTE]
====
Init containers may cause longer application start-up times and should be used with caution for serverless applications, which are expected to scale up and down frequently.
====
// enable init containers
include::modules/serverless-admin-init-containers.adoc[leveloffset=+1]

1
serverless/knative-serving/config-applications/modules Symbolic link
View File

@@ -0,0 +1 @@
../../modules/

13
serverless/knative-serving/config-applications/overriding-config.adoc Normal file
View File

@@ -0,0 +1,13 @@
:_content-type: ASSEMBLY
[id="overriding-config"]
= Overriding system deployment configurations
include::_attributes/common-attributes.adoc[]
:context: overriding-config
You can override the default configurations for some specific deployments by modifying the `deployments` spec in the `KnativeServing` and `KnativeEventing` custom resources (CRs).
include::modules/knative-serving-CR-system-deployments.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* link:https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.25/#probe-v1-core[Probe configuration section of the Kubernetes API documentation]

18
serverless/knative-serving/config-applications/pvcs-for-serving.adoc Normal file
View File

@@ -0,0 +1,18 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="pvcs-for-serving"]
= Persistent Volume Claims for Serving
:context: pvcs-for-serving
Some serverless applications need permanent data storage.
To achieve this, you can configure persistent volume claims (PVCs) for your Knative services.
// Enabling PVC for Serving
include::modules/serverless-enabling-pvc-support.adoc[leveloffset=+1]
ifdef::openshift-enterprise[]
[id="additional-resources_pvcs-for-serving"]
[role="_additional-resources"]
== Additional resources
* xref:../../../storage/understanding-persistent-storage.adoc#understanding-persistent-storage[Understanding persistent storage]
endif::[]

12
serverless/knative-serving/config-applications/resolving-image-tags-to-digests.adoc Normal file
View File

@@ -0,0 +1,12 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="resolving-image-tags-to-digests"]
= Resolving image tags to digests
:context: resolving-image-tags-to-digests
If the Knative Serving controller has access to the container registry, Knative Serving resolves image tags to a digest when you create a revision of a service. This is known as _tag-to-digest resolution_, and helps to provide consistency for deployments.
// Tag to digest resolution
include::modules/serverless-tag-to-digest-resolution.adoc[leveloffset=+1]
include::modules/knative-serving-controller-custom-certs-secrets.adoc[leveloffset=+2]

9
serverless/knative-serving/config-applications/restrictive-network-policies.adoc Normal file
View File

@@ -0,0 +1,9 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="restrictive-network-policies"]
= Restrictive network policies
:context: restrictive-network-policies
include::modules/serverless-services-network-policies.adoc[leveloffset=+1]
include::modules/serverless-services-network-policies-enabling-comms.adoc[leveloffset=+1]

1
serverless/knative-serving/config-applications/snippets Symbolic link
View File

@@ -0,0 +1 @@
../../snippets/

1
serverless/knative-serving/config-custom-domains/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

9
serverless/knative-serving/config-custom-domains/create-domain-mapping-kn.adoc Normal file
View File

@@ -0,0 +1,9 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="create-domain-mapping-kn"]
= Custom domains for Knative services using the Knative CLI
:context: create-domain-mapping-kn
You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service. You can use the Knative (`kn`) CLI to create a `DomainMapping` custom resource (CR) that maps to an Addressable target CR, such as a Knative service or a Knative route.
include::modules/serverless-create-domain-mapping-kn.adoc[leveloffset=+1]

9
serverless/knative-serving/config-custom-domains/create-domain-mapping.adoc Normal file
View File

@@ -0,0 +1,9 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="create-domain-mapping"]
= Custom domain mapping
:context: create-domain-mapping
You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service. To map a custom domain name to a custom resource (CR), you must create a `DomainMapping` CR that maps to an Addressable target CR, such as a Knative service or a Knative route.
include::modules/serverless-create-domain-mapping.adoc[leveloffset=+1]

8
serverless/knative-serving/config-custom-domains/domain-mapping-custom-tls-cert.adoc Normal file
View File

@@ -0,0 +1,8 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="domain-mapping-custom-tls-cert"]
= Securing a mapped service using a TLS certificate
:context: domain-mapping-custom-tls-cert
include::modules/serverless-domain-mapping-custom-tls-cert.adoc[leveloffset=+1]

10
serverless/knative-serving/config-custom-domains/domain-mapping-odc-admin.adoc Normal file
View File

@@ -0,0 +1,10 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="domain-mapping-odc-admin"]
= Domain mapping using the Administrator perspective
:context: domain-mapping-odc-admin
If you do not want to switch to the *Developer* perspective in the {product-title} web console or use the Knative (`kn`) CLI or YAML files, you can use the *Administator* perspective of the {product-title} web console.
// domain mapping as an admin
include::modules/serverless-domain-mapping-odc-admin.adoc[leveloffset=+1]

9
serverless/knative-serving/config-custom-domains/domain-mapping-odc-developer.adoc Normal file
View File

@@ -0,0 +1,9 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="domain-mapping-odc-developer"]
= Domain mapping using the Developer perspective
:context: domain-mapping-odc-developer
You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service. You can use the *Developer* perspective of the {product-title} web console to map a `DomainMapping` custom resource (CR) to a Knative service.
include::modules/serverless-domain-mapping-odc-developer.adoc[leveloffset=+1]

1
serverless/knative-serving/config-custom-domains/images Symbolic link
View File

@@ -0,0 +1 @@
../../images/

1
serverless/knative-serving/config-custom-domains/modules Symbolic link
View File

@@ -0,0 +1 @@
../../modules/

7
serverless/knative-serving/config-custom-domains/serverless-custom-domains.adoc Normal file
View File

@@ -0,0 +1,7 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="serverless-custom-domains"]
= Configuring a custom domain for a Knative service
:context: serverless-custom-domains
include::snippets/serverless-domain-mapping.adoc[]

1
serverless/knative-serving/config-custom-domains/snippets Symbolic link
View File

@@ -0,0 +1 @@
../../snippets/

1
serverless/knative-serving/config-ha-services/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

9
serverless/knative-serving/config-ha-services/ha-replicas-serving.adoc Normal file
View File

@@ -0,0 +1,9 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="ha-replicas-serving"]
= High availability for Knative services
:context: ha-replicas-serving
High availability (HA) is available by default for the Knative Serving `activator`, `autoscaler`, `autoscaler-hpa`, `controller`, `webhook`, `kourier-control`, and `kourier-gateway` components, which are configured to have two replicas each by default. You can change the number of replicas for these components by modifying the `spec.high-availability.replicas` value in the `KnativeServing` custom resource (CR).
include::modules/serverless-config-replicas-serving.adoc[leveloffset=+1]

7
serverless/knative-serving/config-ha-services/ha-services-overview.adoc Normal file
View File

@@ -0,0 +1,7 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="ha-services-overview"]
= High availability for Knative services
:context: ha-services-overview
include::snippets/serverless-ha-intro.adoc[]

1
serverless/knative-serving/config-ha-services/images Symbolic link
View File

@@ -0,0 +1 @@
../../images/

1
serverless/knative-serving/config-ha-services/modules Symbolic link
View File

@@ -0,0 +1 @@
../../modules/

1
serverless/knative-serving/config-ha-services/snippets Symbolic link
View File

@@ -0,0 +1 @@
../../snippets/

1
serverless/knative-serving/external-ingress-routing/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

22
serverless/knative-serving/external-ingress-routing/cluster-local-availability.adoc Normal file
View File

@@ -0,0 +1,22 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="cluster-local-availability"]
= Cluster local availability
:context: cluster-local-availability
By default, Knative services are published to a public IP address.
Being published to a public IP address means that Knative services are public applications, and have a publicly accessible URL.
Publicly accessible URLs are accessible from outside of the cluster.
However, developers may need to build back-end services that are only be accessible from inside the cluster, known as _private services_.
// Cluster administrators can configure private services for the cluster so that all services are private by default.
// Need to add additional details about editing the configmap for admins
Developers can label individual services in the cluster with the `networking.knative.dev/visibility=cluster-local` label to make them private.
[IMPORTANT]
====
For {ServerlessProductName} 1.15.0 and newer versions, the `serving.knative.dev/visibility` label is no longer available. You must update existing services to use the `networking.knative.dev/visibility` label instead.
====
include::modules/knative-service-cluster-local.adoc[leveloffset=+1]

15
serverless/knative-serving/external-ingress-routing/configuring-service-routes.adoc Normal file
View File

@@ -0,0 +1,15 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="configuring-service-routes"]
= Configuring routes for Knative services
:context: configuring-service-routes
If you want to configure a Knative service to use your TLS certificate on {product-title}, you must disable the automatic creation of a route for the service by the {ServerlessOperatorName} and instead manually create a route for the service.
[NOTE]
====
When you complete the following procedure, the default {product-title} route in the `knative-serving-ingress` namespace is not created. However, the Knative route for the application is still created in this namespace.
====
include::modules/serverless-openshift-routes.adoc[leveloffset=+1]

13
serverless/knative-serving/external-ingress-routing/customize-labels-annotations-routes.adoc Normal file
View File

@@ -0,0 +1,13 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="customize-labels-annotations-routes"]
= Customizing labels and annotations
:context: customize-labels-annotations-routes
toc::[]
{product-title} routes support the use of custom labels and annotations, which you can configure by modifying the `metadata` spec of a Knative service. Custom labels and annotations are propagated from the service to the Knative route, then to the Knative ingress, and finally to the {product-title} route.
include::modules/serverless-customize-labels-annotations-routes.adoc[leveloffset=+1]

11
serverless/knative-serving/external-ingress-routing/https-redirect-global.adoc Normal file
View File

@@ -0,0 +1,11 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="https-redirect-global"]
= Global HTTPS redirection
:context: https-redirect-global
HTTPS redirection provides redirection for incoming HTTP requests. These redirected HTTP requests are encrypted. You can enable HTTPS redirection for all services on the cluster by configuring the `httpProtocol` spec for the `KnativeServing` custom resource (CR).
// global https redirect
include::modules/serverless-https-redirect-global.adoc[leveloffset=+1]

10
serverless/knative-serving/external-ingress-routing/https-redirect-per-service.adoc Normal file
View File

@@ -0,0 +1,10 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="https-redirect-per-service"]
= HTTPS redirection per service
:context: https-redirect-per-service
You can enable or disable HTTPS redirection for a service by configuring the `networking.knative.dev/http-option` annotation.
include::modules/serverless-https-redirect-service.adoc[leveloffset=+1]

1
serverless/knative-serving/external-ingress-routing/images Symbolic link
View File

@@ -0,0 +1 @@
../../images/

21
serverless/knative-serving/external-ingress-routing/kourier-gateway-service-type.adoc Normal file
View File

@@ -0,0 +1,21 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="kourier-gateway-service-type"]
= Kourier Gateway service type
:context: kourier-gateway-service-type
The Kourier Gateway is exposed by default as the `ClusterIP` service type. This service type is determined by the `service-type` ingress spec in the `KnativeServing` custom resource (CR).
.Default spec
[source,yaml]
----
...
spec:
ingress:
kourier:
service-type: ClusterIP
...
----
// Kourier Gateway service type
include::modules/serverless-kourier-gateway-service-type.adoc[leveloffset=+1]

1
serverless/knative-serving/external-ingress-routing/modules Symbolic link
View File

@@ -0,0 +1 @@
../../modules/

13
serverless/develop/serverless-configuring-routes.adoc → serverless/knative-serving/external-ingress-routing/routing-overview.adoc
View File

@@ -1,10 +1,8 @@
:_content-type: ASSEMBLY
[id="serverless-configuring-routes"]
= Routing
:context: serverless-configuring-routes
include::_attributes/common-attributes.adoc[]
toc::[]
[id="routing-overview"]
= Routing overview
:context: routing-overview
Knative leverages {product-title} TLS termination to provide routing for Knative services. When a Knative service is created, an {product-title} route is automatically created for the service. This route is managed by the {ServerlessOperatorName}. The {product-title} route exposes the Knative service through the same domain as the {product-title} cluster.
@@ -12,13 +10,10 @@ You can disable Operator control of {product-title} routing so that you can conf
Knative routes can also be used alongside the {product-title} route to provide additional fine-grained routing capabilities, such as traffic splitting.
include::modules/serverless-customize-labels-annotations-routes.adoc[leveloffset=+1]
include::modules/serverless-openshift-routes.adoc[leveloffset=+1]
include::modules/knative-service-cluster-local.adoc[leveloffset=+1]
ifdef::openshift-enterprise[]
[id="additional-resources_serverless-configuring-routes"]
[role="_additional-resources"]
== Additional resources
* xref:../..//networking/routes/route-configuration.adoc#nw-route-specific-annotations_route-configuration[Route-specific annotations]
* xref:../../../networking/routes/route-configuration.adoc#nw-route-specific-annotations_route-configuration[Route-specific annotations]
endif::[]

1
serverless/knative-serving/external-ingress-routing/snippets Symbolic link
View File

@@ -0,0 +1 @@
../../snippets/

11
serverless/knative-serving/external-ingress-routing/url-scheme-external-routes.adoc Normal file
View File

@@ -0,0 +1,11 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="url-scheme-external-routes"]
= URL scheme for external routes
:context: url-scheme-external-routes
The URL scheme of external routes defaults to HTTPS for enhanced security. This scheme is determined by the `default-external-scheme` key in the `KnativeServing` custom resource (CR) spec.
// URL scheme for external routes
include::modules/serverless-url-scheme-external-routes.adoc[leveloffset=+1]

9
serverless/knative-serving/external-ingress-routing/using-http2-gRPC.adoc Normal file
View File

@@ -0,0 +1,9 @@
:_content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="using-http2-gRPC_{context}"]
= Using HTTP2 and gRPC
:context: using-http2-gRPC
{ServerlessProductName} supports only insecure or edge-terminated routes. Insecure or edge-terminated routes do not support HTTP2 on {product-title}. These routes also do not support gRPC because gRPC is transported by HTTP2. If you use these protocols in your application, you must call the application using the ingress gateway directly. To do this you must find the ingress gateway's public address and the application's specific host.
include::modules/interacting-serverless-apps-http2-gRPC.adoc[leveloffset=+1]

1
serverless/knative-serving/getting-started/_attributes Symbolic link
View File

@@ -0,0 +1 @@
../../_attributes/

1
serverless/knative-serving/getting-started/images Symbolic link
View File

@@ -0,0 +1 @@
../../images/

Some files were not shown because too many files have changed in this diff Show More