diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml index e718ba8ad80f..ace59f7df6cc 100644 --- a/_topic_maps/_topic_map.yml +++ b/_topic_maps/_topic_map.yml @@ -3495,6 +3495,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 @@ -3512,14 +3615,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 @@ -3579,10 +3674,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 diff --git a/_topic_maps/_topic_map_osd.yml b/_topic_maps/_topic_map_osd.yml index e9700f674be1..254c17dc726a 100644 --- a/_topic_maps/_topic_map_osd.yml +++ b/_topic_maps/_topic_map_osd.yml @@ -248,6 +248,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: @@ -262,14 +365,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 @@ -320,10 +415,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: diff --git a/_topic_maps/_topic_map_rosa.yml b/_topic_maps/_topic_map_rosa.yml index 700d58b404db..e90a72f37ace 100644 --- a/_topic_maps/_topic_map_rosa.yml +++ b/_topic_maps/_topic_map_rosa.yml @@ -451,6 +451,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: @@ -465,14 +568,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 @@ -523,10 +618,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: diff --git a/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc b/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc index 541c8445ec8d..7b26d2adb6be 100644 --- a/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc +++ b/applications/creating_applications/odc-creating-applications-using-developer-perspective.adoc @@ -75,8 +75,7 @@ include::modules/odc-using-the-developer-catalog-to-add-services-or-components.a [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]. diff --git a/modules/interacting-serverless-apps-http2-gRPC.adoc b/modules/interacting-serverless-apps-http2-gRPC.adoc index 48c89ce47171..7b7f32459a82 100644 --- a/modules/interacting-serverless-apps-http2-gRPC.adoc +++ b/modules/interacting-serverless-apps-http2-gRPC.adoc @@ -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): diff --git a/modules/knative-service-cluster-local.adoc b/modules/knative-service-cluster-local.adoc index 3061e36654f6..834950c7128b 100644 --- a/modules/knative-service-cluster-local.adoc +++ b/modules/knative-service-cluster-local.adoc @@ -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 diff --git a/modules/odc-splitting-traffic-between-revisions-using-developer-perspective.adoc b/modules/odc-splitting-traffic-between-revisions-using-developer-perspective.adoc index 24dd0232d2f0..54a747f172d1 100644 --- a/modules/odc-splitting-traffic-between-revisions-using-developer-perspective.adoc +++ b/modules/odc-splitting-traffic-between-revisions-using-developer-perspective.adoc @@ -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. diff --git a/modules/serverless-admin-init-containers.adoc b/modules/serverless-admin-init-containers.adoc index eea4010d517d..87d6a41e11ab 100644 --- a/modules/serverless-admin-init-containers.adoc +++ b/modules/serverless-admin-init-containers.adoc @@ -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. diff --git a/modules/serverless-autoscaling-developer-maxscale.adoc b/modules/serverless-autoscaling-developer-maxscale.adoc index b482684c0e0e..ac62ef5d2120 100644 --- a/modules/serverless-autoscaling-developer-maxscale.adoc +++ b/modules/serverless-autoscaling-developer-maxscale.adoc @@ -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}"] diff --git a/modules/serverless-autoscaling-developer-minscale.adoc b/modules/serverless-autoscaling-developer-minscale.adoc index 2c41882098de..a78988892d29 100644 --- a/modules/serverless-autoscaling-developer-minscale.adoc +++ b/modules/serverless-autoscaling-developer-minscale.adoc @@ -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}"] diff --git a/modules/serverless-autoscaling-maxscale-kn.adoc b/modules/serverless-autoscaling-maxscale-kn.adoc index 0615b7a99991..d1bf2a82aaf4 100644 --- a/modules/serverless-autoscaling-maxscale-kn.adoc +++ b/modules/serverless-autoscaling-maxscale-kn.adoc @@ -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}"] diff --git a/modules/serverless-autoscaling-minscale-kn.adoc b/modules/serverless-autoscaling-minscale-kn.adoc index 01a33575abee..41e7ddb3c26b 100644 --- a/modules/serverless-autoscaling-minscale-kn.adoc +++ b/modules/serverless-autoscaling-minscale-kn.adoc @@ -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}"] diff --git a/modules/serverless-blue-green-deploy.adoc b/modules/serverless-blue-green-deploy.adoc index c107fdf1f554..e895222c7d31 100644 --- a/modules/serverless-blue-green-deploy.adoc +++ b/modules/serverless-blue-green-deploy.adoc @@ -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. diff --git a/modules/serverless-concurrency-limits-configure-hard.adoc b/modules/serverless-concurrency-limits-configure-hard.adoc index fc0f8286db7d..1fd7e0e6b91f 100644 --- a/modules/serverless-concurrency-limits-configure-hard.adoc +++ b/modules/serverless-concurrency-limits-configure-hard.adoc @@ -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}"] diff --git a/modules/serverless-concurrency-limits-configure-soft.adoc b/modules/serverless-concurrency-limits-configure-soft.adoc index 786edce68714..22f2dc4ae2df 100644 --- a/modules/serverless-concurrency-limits-configure-soft.adoc +++ b/modules/serverless-concurrency-limits-configure-soft.adoc @@ -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}"] diff --git a/modules/serverless-config-emptydir.adoc b/modules/serverless-config-emptydir.adoc index b268dd1bfdaf..4e457652ac00 100644 --- a/modules/serverless-config-emptydir.adoc +++ b/modules/serverless-config-emptydir.adoc @@ -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 diff --git a/modules/serverless-config-replicas-serving.adoc b/modules/serverless-config-replicas-serving.adoc index a5789b6427f4..aa4ea87fdd84 100644 --- a/modules/serverless-config-replicas-serving.adoc +++ b/modules/serverless-config-replicas-serving.adoc @@ -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 diff --git a/modules/serverless-create-domain-mapping-kn.adoc b/modules/serverless-create-domain-mapping-kn.adoc index 817738e96afc..35fc7389e247 100644 --- a/modules/serverless-create-domain-mapping-kn.adoc +++ b/modules/serverless-create-domain-mapping-kn.adoc @@ -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. diff --git a/modules/serverless-create-domain-mapping.adoc b/modules/serverless-create-domain-mapping.adoc index e47bb9b11fb2..7f2d6c4c39b2 100644 --- a/modules/serverless-create-domain-mapping.adoc +++ b/modules/serverless-create-domain-mapping.adoc @@ -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}"] diff --git a/modules/serverless-create-traffic-split-kn.adoc b/modules/serverless-create-traffic-split-kn.adoc index 2210567f6022..960fbb8d0b01 100644 --- a/modules/serverless-create-traffic-split-kn.adoc +++ b/modules/serverless-create-traffic-split-kn.adoc @@ -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. diff --git a/modules/serverless-customize-labels-annotations-routes.adoc b/modules/serverless-customize-labels-annotations-routes.adoc index 01e5b18d4a63..efa05e808852 100644 --- a/modules/serverless-customize-labels-annotations-routes.adoc +++ b/modules/serverless-customize-labels-annotations-routes.adoc @@ -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. diff --git a/modules/serverless-domain-mapping-custom-tls-cert.adoc b/modules/serverless-domain-mapping-custom-tls-cert.adoc index 92026351cf7e..a1b3c659910b 100644 --- a/modules/serverless-domain-mapping-custom-tls-cert.adoc +++ b/modules/serverless-domain-mapping-custom-tls-cert.adoc @@ -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}"] diff --git a/modules/serverless-domain-mapping-odc-developer.adoc b/modules/serverless-domain-mapping-odc-developer.adoc index 128729d5cff2..7d12eabcdb68 100644 --- a/modules/serverless-domain-mapping-odc-developer.adoc +++ b/modules/serverless-domain-mapping-odc-developer.adoc @@ -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. diff --git a/modules/serverless-enable-scale-to-zero.adoc b/modules/serverless-enable-scale-to-zero.adoc index ec19a42a732f..b6cf7f2f1fab 100644 --- a/modules/serverless-enable-scale-to-zero.adoc +++ b/modules/serverless-enable-scale-to-zero.adoc @@ -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 diff --git a/modules/serverless-enabling-pvc-support.adoc b/modules/serverless-enabling-pvc-support.adoc index cc46402c7f1d..63e7fb0f3038 100644 --- a/modules/serverless-enabling-pvc-support.adoc +++ b/modules/serverless-enabling-pvc-support.adoc @@ -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 diff --git a/modules/serverless-https-redirect-global.adoc b/modules/serverless-https-redirect-global.adoc index 6a011c2ad14d..bfa65eb96e7c 100644 --- a/modules/serverless-https-redirect-global.adoc +++ b/modules/serverless-https-redirect-global.adoc @@ -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] ---- diff --git a/modules/serverless-https-redirect-service.adoc b/modules/serverless-https-redirect-service.adoc index d5783ee44add..f7bd1fc3112b 100644 --- a/modules/serverless-https-redirect-service.adoc +++ b/modules/serverless-https-redirect-service.adoc @@ -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] ---- diff --git a/modules/serverless-kourier-gateway-service-type.adoc b/modules/serverless-kourier-gateway-service-type.adoc index fc10c85cd18a..7cf010aa6db0 100644 --- a/modules/serverless-kourier-gateway-service-type.adoc +++ b/modules/serverless-kourier-gateway-service-type.adoc @@ -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 diff --git a/modules/serverless-openshift-routes.adoc b/modules/serverless-openshift-routes.adoc index 2127a3ab7b63..30c39c74387e 100644 --- a/modules/serverless-openshift-routes.adoc +++ b/modules/serverless-openshift-routes.adoc @@ -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 diff --git a/modules/serverless-ossm-v1x-jwt.adoc b/modules/serverless-ossm-v1x-jwt.adoc index 5eb8c97411e3..662a9e1c1043 100644 --- a/modules/serverless-ossm-v1x-jwt.adoc +++ b/modules/serverless-ossm-v1x-jwt.adoc @@ -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] ==== diff --git a/modules/serverless-ossm-v2x-jwt.adoc b/modules/serverless-ossm-v2x-jwt.adoc index 1dfbb7a2aa06..ff193e91d128 100644 --- a/modules/serverless-ossm-v2x-jwt.adoc +++ b/modules/serverless-ossm-v2x-jwt.adoc @@ -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] ==== diff --git a/modules/serverless-services-network-policies-enabling-comms.adoc b/modules/serverless-services-network-policies-enabling-comms.adoc new file mode 100644 index 000000000000..455db7f969bc --- /dev/null +++ b/modules/serverless-services-network-policies-enabling-comms.adoc @@ -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: <1> + 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. diff --git a/modules/serverless-services-network-policies.adoc b/modules/serverless-services-network-policies.adoc index 78b4b507fe7d..2f34179ff025 100644 --- a/modules/serverless-services-network-policies.adoc +++ b/modules/serverless-services-network-policies.adoc @@ -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: <1> - 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. diff --git a/modules/serverless-tag-to-digest-resolution.adoc b/modules/serverless-tag-to-digest-resolution.adoc index a2bee286feb7..2ec0714d0640 100644 --- a/modules/serverless-tag-to-digest-resolution.adoc +++ b/modules/serverless-tag-to-digest-resolution.adoc @@ -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. diff --git a/modules/serverless-target-utilization.adoc b/modules/serverless-target-utilization.adoc index bcf80c84f78d..b2f9ffd5ce8f 100644 --- a/modules/serverless-target-utilization.adoc +++ b/modules/serverless-target-utilization.adoc @@ -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}"] diff --git a/modules/serverless-traffic-splitting-flags-kn.adoc b/modules/serverless-traffic-splitting-flags-kn.adoc index 2d3046659c5c..ddc5ed414900 100644 --- a/modules/serverless-traffic-splitting-flags-kn.adoc +++ b/modules/serverless-traffic-splitting-flags-kn.adoc @@ -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. diff --git a/modules/serverless-url-scheme-external-routes.adoc b/modules/serverless-url-scheme-external-routes.adoc index 87c02aa9c902..ac9a96bb02f6 100644 --- a/modules/serverless-url-scheme-external-routes.adoc +++ b/modules/serverless-url-scheme-external-routes.adoc @@ -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] ---- diff --git a/serverless/admin_guide/serverless-admin-perspective.adoc b/serverless/admin_guide/serverless-admin-perspective.adoc index 4f5d760729cb..f94ebfeae374 100644 --- a/serverless/admin_guide/serverless-admin-perspective.adoc +++ b/serverless/admin_guide/serverless-admin-perspective.adoc @@ -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] diff --git a/serverless/admin_guide/serverless-configuration.adoc b/serverless/admin_guide/serverless-configuration.adoc index 2b0c8737a1fd..e85f01f82f9d 100644 --- a/serverless/admin_guide/serverless-configuration.adoc +++ b/serverless/admin_guide/serverless-configuration.adoc @@ -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"] diff --git a/serverless/admin_guide/serverless-ha.adoc b/serverless/admin_guide/serverless-ha.adoc index fbfc8795e11f..8d2970920e27 100644 --- a/serverless/admin_guide/serverless-ha.adoc +++ b/serverless/admin_guide/serverless-ha.adoc @@ -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] diff --git a/serverless/develop/serverless-applications.adoc b/serverless/develop/serverless-applications.adoc deleted file mode 100644 index 1ca40f9280e9..000000000000 --- a/serverless/develop/serverless-applications.adoc +++ /dev/null @@ -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] diff --git a/serverless/develop/serverless-traffic-management.adoc b/serverless/develop/serverless-traffic-management.adoc deleted file mode 100644 index 06d818a9822d..000000000000 --- a/serverless/develop/serverless-traffic-management.adoc +++ /dev/null @@ -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. -//// diff --git a/serverless/integrations/serverless-ossm-setup.adoc b/serverless/integrations/serverless-ossm-setup.adoc index a841690fbe2c..4fde8e480de7 100644 --- a/serverless/integrations/serverless-ossm-setup.adoc +++ b/serverless/integrations/serverless-ossm-setup.adoc @@ -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 diff --git a/serverless/knative-serving/_attributes b/serverless/knative-serving/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/autoscaling/_attributes b/serverless/knative-serving/autoscaling/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/autoscaling/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/autoscaling/images b/serverless/knative-serving/autoscaling/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/autoscaling/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/autoscaling/modules b/serverless/knative-serving/autoscaling/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/autoscaling/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/autoscaling/serverless-autoscaling-developer-scale-bounds.adoc b/serverless/knative-serving/autoscaling/serverless-autoscaling-developer-scale-bounds.adoc new file mode 100644 index 000000000000..da7d15668ddd --- /dev/null +++ b/serverless/knative-serving/autoscaling/serverless-autoscaling-developer-scale-bounds.adoc @@ -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] diff --git a/serverless/develop/serverless-autoscaling-developer.adoc b/serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc similarity index 62% rename from serverless/develop/serverless-autoscaling-developer.adoc rename to serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc index b4e8a859371c..4fb5626c7786 100644 --- a/serverless/develop/serverless-autoscaling-developer.adoc +++ b/serverless/knative-serving/autoscaling/serverless-autoscaling-developer.adoc @@ -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] diff --git a/serverless/knative-serving/autoscaling/serverless-autoscaling-scale-to-zero.adoc b/serverless/knative-serving/autoscaling/serverless-autoscaling-scale-to-zero.adoc new file mode 100644 index 000000000000..4724a2f9aa24 --- /dev/null +++ b/serverless/knative-serving/autoscaling/serverless-autoscaling-scale-to-zero.adoc @@ -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] \ No newline at end of file diff --git a/modules/serverless-about-concurrency.adoc b/serverless/knative-serving/autoscaling/serverless-concurrency.adoc similarity index 77% rename from modules/serverless-about-concurrency.adoc rename to serverless/knative-serving/autoscaling/serverless-concurrency.adoc index 1c986316db8f..5464b99de63c 100644 --- a/modules/serverless-about-concurrency.adoc +++ b/serverless/knative-serving/autoscaling/serverless-concurrency.adoc @@ -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] \ No newline at end of file diff --git a/serverless/knative-serving/autoscaling/snippets b/serverless/knative-serving/autoscaling/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/autoscaling/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/config-access/_attributes b/serverless/knative-serving/config-access/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/config-access/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/config-access/images b/serverless/knative-serving/config-access/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/config-access/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/config-access/modules b/serverless/knative-serving/config-access/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/config-access/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/config-access/serverless-ossm-v1x-jwt.adoc b/serverless/knative-serving/config-access/serverless-ossm-v1x-jwt.adoc new file mode 100644 index 000000000000..462a372b0494 --- /dev/null +++ b/serverless/knative-serving/config-access/serverless-ossm-v1x-jwt.adoc @@ -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] diff --git a/serverless/knative-serving/config-access/serverless-ossm-v2x-jwt.adoc b/serverless/knative-serving/config-access/serverless-ossm-v2x-jwt.adoc new file mode 100644 index 000000000000..8b67f4767c69 --- /dev/null +++ b/serverless/knative-serving/config-access/serverless-ossm-v2x-jwt.adoc @@ -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] \ No newline at end of file diff --git a/serverless/security/serverless-ossm-with-kourier-jwt.adoc b/serverless/knative-serving/config-access/serverless-ossm-with-kourier-jwt.adoc similarity index 79% rename from serverless/security/serverless-ossm-with-kourier-jwt.adoc rename to serverless/knative-serving/config-access/serverless-ossm-with-kourier-jwt.adoc index 6321049f5050..547d76fcc022 100644 --- a/serverless/security/serverless-ossm-with-kourier-jwt.adoc +++ b/serverless/knative-serving/config-access/serverless-ossm-with-kourier-jwt.adoc @@ -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] diff --git a/serverless/knative-serving/config-access/snippets b/serverless/knative-serving/config-access/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/config-access/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/_attributes b/serverless/knative-serving/config-applications/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/config-applications/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/empty-dir.adoc b/serverless/knative-serving/config-applications/empty-dir.adoc new file mode 100644 index 000000000000..5fade19bcb9c --- /dev/null +++ b/serverless/knative-serving/config-applications/empty-dir.adoc @@ -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] + diff --git a/serverless/knative-serving/config-applications/images b/serverless/knative-serving/config-applications/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/config-applications/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/init-containers.adoc b/serverless/knative-serving/config-applications/init-containers.adoc new file mode 100644 index 000000000000..72feb20aeb71 --- /dev/null +++ b/serverless/knative-serving/config-applications/init-containers.adoc @@ -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] \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/modules b/serverless/knative-serving/config-applications/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/config-applications/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/overriding-config.adoc b/serverless/knative-serving/config-applications/overriding-config.adoc new file mode 100644 index 000000000000..4b8828fc2063 --- /dev/null +++ b/serverless/knative-serving/config-applications/overriding-config.adoc @@ -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] \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/pvcs-for-serving.adoc b/serverless/knative-serving/config-applications/pvcs-for-serving.adoc new file mode 100644 index 000000000000..6063a02fb82e --- /dev/null +++ b/serverless/knative-serving/config-applications/pvcs-for-serving.adoc @@ -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::[] \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/resolving-image-tags-to-digests.adoc b/serverless/knative-serving/config-applications/resolving-image-tags-to-digests.adoc new file mode 100644 index 000000000000..092a73e58208 --- /dev/null +++ b/serverless/knative-serving/config-applications/resolving-image-tags-to-digests.adoc @@ -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] + diff --git a/serverless/knative-serving/config-applications/restrictive-network-policies.adoc b/serverless/knative-serving/config-applications/restrictive-network-policies.adoc new file mode 100644 index 000000000000..d2852e21b88b --- /dev/null +++ b/serverless/knative-serving/config-applications/restrictive-network-policies.adoc @@ -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] \ No newline at end of file diff --git a/serverless/knative-serving/config-applications/snippets b/serverless/knative-serving/config-applications/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/config-applications/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/config-custom-domains/_attributes b/serverless/knative-serving/config-custom-domains/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/config-custom-domains/create-domain-mapping-kn.adoc b/serverless/knative-serving/config-custom-domains/create-domain-mapping-kn.adoc new file mode 100644 index 000000000000..fcf121cc309e --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/create-domain-mapping-kn.adoc @@ -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] diff --git a/serverless/knative-serving/config-custom-domains/create-domain-mapping.adoc b/serverless/knative-serving/config-custom-domains/create-domain-mapping.adoc new file mode 100644 index 000000000000..c333c8f9c66d --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/create-domain-mapping.adoc @@ -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] diff --git a/serverless/knative-serving/config-custom-domains/domain-mapping-custom-tls-cert.adoc b/serverless/knative-serving/config-custom-domains/domain-mapping-custom-tls-cert.adoc new file mode 100644 index 000000000000..5f85b5e0e7b5 --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/domain-mapping-custom-tls-cert.adoc @@ -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] + diff --git a/serverless/knative-serving/config-custom-domains/domain-mapping-odc-admin.adoc b/serverless/knative-serving/config-custom-domains/domain-mapping-odc-admin.adoc new file mode 100644 index 000000000000..ba8414eea9bf --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/domain-mapping-odc-admin.adoc @@ -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] \ No newline at end of file diff --git a/serverless/knative-serving/config-custom-domains/domain-mapping-odc-developer.adoc b/serverless/knative-serving/config-custom-domains/domain-mapping-odc-developer.adoc new file mode 100644 index 000000000000..f9f084a3213f --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/domain-mapping-odc-developer.adoc @@ -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] diff --git a/serverless/knative-serving/config-custom-domains/images b/serverless/knative-serving/config-custom-domains/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/config-custom-domains/modules b/serverless/knative-serving/config-custom-domains/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/config-custom-domains/serverless-custom-domains.adoc b/serverless/knative-serving/config-custom-domains/serverless-custom-domains.adoc new file mode 100644 index 000000000000..ecaffcfefcaa --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/serverless-custom-domains.adoc @@ -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[] diff --git a/serverless/knative-serving/config-custom-domains/snippets b/serverless/knative-serving/config-custom-domains/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/config-custom-domains/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/config-ha-services/_attributes b/serverless/knative-serving/config-ha-services/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/config-ha-services/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/config-ha-services/ha-replicas-serving.adoc b/serverless/knative-serving/config-ha-services/ha-replicas-serving.adoc new file mode 100644 index 000000000000..41e70d9d65ea --- /dev/null +++ b/serverless/knative-serving/config-ha-services/ha-replicas-serving.adoc @@ -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] diff --git a/serverless/knative-serving/config-ha-services/ha-services-overview.adoc b/serverless/knative-serving/config-ha-services/ha-services-overview.adoc new file mode 100644 index 000000000000..b36cfaea5040 --- /dev/null +++ b/serverless/knative-serving/config-ha-services/ha-services-overview.adoc @@ -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[] diff --git a/serverless/knative-serving/config-ha-services/images b/serverless/knative-serving/config-ha-services/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/config-ha-services/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/config-ha-services/modules b/serverless/knative-serving/config-ha-services/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/config-ha-services/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/config-ha-services/snippets b/serverless/knative-serving/config-ha-services/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/config-ha-services/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/external-ingress-routing/_attributes b/serverless/knative-serving/external-ingress-routing/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/external-ingress-routing/cluster-local-availability.adoc b/serverless/knative-serving/external-ingress-routing/cluster-local-availability.adoc new file mode 100644 index 000000000000..e07211ffa9f6 --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/cluster-local-availability.adoc @@ -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] + diff --git a/serverless/knative-serving/external-ingress-routing/configuring-service-routes.adoc b/serverless/knative-serving/external-ingress-routing/configuring-service-routes.adoc new file mode 100644 index 000000000000..012224f4baac --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/configuring-service-routes.adoc @@ -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] \ No newline at end of file diff --git a/serverless/knative-serving/external-ingress-routing/customize-labels-annotations-routes.adoc b/serverless/knative-serving/external-ingress-routing/customize-labels-annotations-routes.adoc new file mode 100644 index 000000000000..a34ede8534bd --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/customize-labels-annotations-routes.adoc @@ -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] + diff --git a/serverless/knative-serving/external-ingress-routing/https-redirect-global.adoc b/serverless/knative-serving/external-ingress-routing/https-redirect-global.adoc new file mode 100644 index 000000000000..f572cb3c22d1 --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/https-redirect-global.adoc @@ -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] + diff --git a/serverless/knative-serving/external-ingress-routing/https-redirect-per-service.adoc b/serverless/knative-serving/external-ingress-routing/https-redirect-per-service.adoc new file mode 100644 index 000000000000..1bcda7254951 --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/https-redirect-per-service.adoc @@ -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] + diff --git a/serverless/knative-serving/external-ingress-routing/images b/serverless/knative-serving/external-ingress-routing/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/external-ingress-routing/kourier-gateway-service-type.adoc b/serverless/knative-serving/external-ingress-routing/kourier-gateway-service-type.adoc new file mode 100644 index 000000000000..fc7ff0370021 --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/kourier-gateway-service-type.adoc @@ -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] \ No newline at end of file diff --git a/serverless/knative-serving/external-ingress-routing/modules b/serverless/knative-serving/external-ingress-routing/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/develop/serverless-configuring-routes.adoc b/serverless/knative-serving/external-ingress-routing/routing-overview.adoc similarity index 66% rename from serverless/develop/serverless-configuring-routes.adoc rename to serverless/knative-serving/external-ingress-routing/routing-overview.adoc index a88010bfc054..7d8083723796 100644 --- a/serverless/develop/serverless-configuring-routes.adoc +++ b/serverless/knative-serving/external-ingress-routing/routing-overview.adoc @@ -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::[] diff --git a/serverless/knative-serving/external-ingress-routing/snippets b/serverless/knative-serving/external-ingress-routing/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/external-ingress-routing/url-scheme-external-routes.adoc b/serverless/knative-serving/external-ingress-routing/url-scheme-external-routes.adoc new file mode 100644 index 000000000000..4514b8913bf1 --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/url-scheme-external-routes.adoc @@ -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] + diff --git a/serverless/knative-serving/external-ingress-routing/using-http2-gRPC.adoc b/serverless/knative-serving/external-ingress-routing/using-http2-gRPC.adoc new file mode 100644 index 000000000000..ad24196dbd3b --- /dev/null +++ b/serverless/knative-serving/external-ingress-routing/using-http2-gRPC.adoc @@ -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] diff --git a/serverless/knative-serving/getting-started/_attributes b/serverless/knative-serving/getting-started/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/getting-started/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/getting-started/images b/serverless/knative-serving/getting-started/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/getting-started/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/getting-started/modules b/serverless/knative-serving/getting-started/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/getting-started/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/getting-started/serverless-applications.adoc b/serverless/knative-serving/getting-started/serverless-applications.adoc new file mode 100644 index 000000000000..fa4c322253cc --- /dev/null +++ b/serverless/knative-serving/getting-started/serverless-applications.adoc @@ -0,0 +1,39 @@ +:_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] + +// create service using YAML +include::modules/creating-serverless-apps-yaml.adoc[leveloffset=+1] + +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 create Knative components by using the *Administator* perspective of the {product-title} web console. + +// Create services as an admin +include::modules/creating-serverless-apps-admin-console.adoc[leveloffset=+1] + +// offline mode +include::modules/kn-service-offline-create.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/knative-serving/config-access/serverless-ossm-with-kourier-jwt.adoc#serverless-ossm-with-kourier-jwt[Configuring JSON Web Token authentication for Knative services] diff --git a/serverless/knative-serving/getting-started/snippets b/serverless/knative-serving/getting-started/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/getting-started/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/getting-started/verifying-application-deployment.adoc b/serverless/knative-serving/getting-started/verifying-application-deployment.adoc new file mode 100644 index 000000000000..ba10fe868cf0 --- /dev/null +++ b/serverless/knative-serving/getting-started/verifying-application-deployment.adoc @@ -0,0 +1,10 @@ +:_content-type: ASSEMBLY +[id="verifying-application-deployment"] += Verifying your serverless application deployment +include::_attributes/common-attributes.adoc[] +:context: verifying-application-deployment + + +To verify that your serverless application has been deployed successfully, you must get the application URL created by Knative, and then send a request to that URL and observe the output. {ServerlessProductName} supports the use of both HTTP and HTTPS URLs, however the output from `oc get ksvc` always prints URLs using the `http://` format. + +include::modules/verifying-serverless-app-deployment.adoc[leveloffset=+1] diff --git a/serverless/knative-serving/images b/serverless/knative-serving/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/modules b/serverless/knative-serving/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/snippets b/serverless/knative-serving/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/traffic-splitting/_attributes b/serverless/knative-serving/traffic-splitting/_attributes new file mode 120000 index 000000000000..20cc1dcb77bf --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/_attributes @@ -0,0 +1 @@ +../../_attributes/ \ No newline at end of file diff --git a/serverless/knative-serving/traffic-splitting/images b/serverless/knative-serving/traffic-splitting/images new file mode 120000 index 000000000000..847b03ed0541 --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/images @@ -0,0 +1 @@ +../../images/ \ No newline at end of file diff --git a/serverless/knative-serving/traffic-splitting/modules b/serverless/knative-serving/traffic-splitting/modules new file mode 120000 index 000000000000..36719b9de743 --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/modules @@ -0,0 +1 @@ +../../modules/ \ No newline at end of file diff --git a/serverless/knative-serving/traffic-splitting/snippets b/serverless/knative-serving/traffic-splitting/snippets new file mode 120000 index 000000000000..5a3f5add140e --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/snippets @@ -0,0 +1 @@ +../../snippets/ \ No newline at end of file diff --git a/serverless/knative-serving/traffic-splitting/traffic-spec-examples.adoc b/serverless/knative-serving/traffic-splitting/traffic-spec-examples.adoc new file mode 100644 index 000000000000..6fddaadf8d7f --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/traffic-spec-examples.adoc @@ -0,0 +1,71 @@ +:_content-type: ASSEMBLY +include::_attributes/common-attributes.adoc[] +[id="traffic-spec-examples"] += Traffic spec examples +:context: traffic-spec-examples + +toc::[] + +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 +---- diff --git a/serverless/knative-serving/traffic-splitting/traffic-splitting-blue-green.adoc b/serverless/knative-serving/traffic-splitting/traffic-splitting-blue-green.adoc new file mode 100644 index 000000000000..b2d8b13a59f1 --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/traffic-splitting-blue-green.adoc @@ -0,0 +1,13 @@ +:_content-type: ASSEMBLY +include::_attributes/common-attributes.adoc[] +[id="traffic-splitting-blue-green"] += Rerouting traffic using blue-green strategy +:context: traffic-splitting-blue-green + +toc::[] + +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]. + +// blue-green +include::modules/serverless-blue-green-deploy.adoc[leveloffset=+1] + diff --git a/serverless/knative-serving/traffic-splitting/traffic-splitting-flags.adoc b/serverless/knative-serving/traffic-splitting/traffic-splitting-flags.adoc new file mode 100644 index 000000000000..5b5ef0bac78c --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/traffic-splitting-flags.adoc @@ -0,0 +1,16 @@ +:_content-type: ASSEMBLY +include::_attributes/common-attributes.adoc[] +[id="traffic-splitting-flags"] += CLI flags for traffic splitting +:context: traffic-splitting-flags + +toc::[] + +The Knative (`kn`) CLI supports traffic operations on the traffic block of a service as part of the `kn service update` command. + +// 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] \ No newline at end of file diff --git a/serverless/knative-serving/traffic-splitting/traffic-splitting-overview.adoc b/serverless/knative-serving/traffic-splitting/traffic-splitting-overview.adoc new file mode 100644 index 000000000000..9f3fd4c2c82f --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/traffic-splitting-overview.adoc @@ -0,0 +1,34 @@ +:_content-type: ASSEMBLY +include::_attributes/common-attributes.adoc[] +[id="traffic-splitting-overview"] += Traffic splitting overview +:context: traffic-splitting-overview + +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. + +//// +# 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. +//// diff --git a/serverless/knative-serving/traffic-splitting/traffic-splitting-revisions.adoc b/serverless/knative-serving/traffic-splitting/traffic-splitting-revisions.adoc new file mode 100644 index 000000000000..ac0281fe1f4b --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/traffic-splitting-revisions.adoc @@ -0,0 +1,14 @@ +:_content-type: ASSEMBLY +include::_attributes/common-attributes.adoc[] +[id="traffic-splitting-revisions"] += Splitting traffic between revisions +:context: traffic-splitting-revisions + +toc::[] + +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. + +// ODC +include::modules/odc-splitting-traffic-between-revisions-using-developer-perspective.adoc[leveloffset=+1] \ No newline at end of file diff --git a/serverless/knative-serving/traffic-splitting/traffic-splitting-using-cli.adoc b/serverless/knative-serving/traffic-splitting/traffic-splitting-using-cli.adoc new file mode 100644 index 000000000000..fdab469dd416 --- /dev/null +++ b/serverless/knative-serving/traffic-splitting/traffic-splitting-using-cli.adoc @@ -0,0 +1,11 @@ +:_content-type: ASSEMBLY +include::_attributes/common-attributes.adoc[] +[id="traffic-splitting-using-cli"] += Traffic splitting using the Knative CLI +:context: traffic-splitting-using-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. + +// kn CLI +include::modules/serverless-create-traffic-split-kn.adoc[leveloffset=+1] + diff --git a/serverless/security/serverless-config-tls.adoc b/serverless/security/serverless-config-tls.adoc index 996552ca5e51..a589cc67d124 100644 --- a/serverless/security/serverless-config-tls.adoc +++ b/serverless/security/serverless-config-tls.adoc @@ -27,8 +27,6 @@ ifndef::openshift-dedicated[] * xref:../../serverless/integrations/serverless-ossm-setup.adoc#serverless-ossm-enabling-serving-metrics_serverless-ossm-setup[Enabling Knative Serving metrics when using Service Mesh with mTLS] endif::[] -include::modules/serverless-domain-mapping-custom-tls-cert.adoc[leveloffset=+1] - // TLS for kafka include::modules/serverless-kafka-broker-tls-default-config.adoc[leveloffset=+1] include::modules/serverless-kafka-tls-channels.adoc[leveloffset=+1] diff --git a/serverless/security/serverless-custom-domains.adoc b/serverless/security/serverless-custom-domains.adoc deleted file mode 100644 index 7182cff327b8..000000000000 --- a/serverless/security/serverless-custom-domains.adoc +++ /dev/null @@ -1,16 +0,0 @@ -:_content-type: ASSEMBLY -[id="serverless-custom-domains"] -= Configuring a custom domain for a Knative service -include::_attributes/common-attributes.adoc[] -:context: serverless-custom-domains - -toc::[] - -include::snippets/serverless-domain-mapping.adoc[] - -include::modules/serverless-create-domain-mapping.adoc[leveloffset=+1] -include::modules/serverless-create-domain-mapping-kn.adoc[leveloffset=+1] -// ODC -include::modules/serverless-domain-mapping-odc-developer.adoc[leveloffset=+1] - -include::modules/serverless-domain-mapping-custom-tls-cert.adoc[leveloffset=+1] diff --git a/snippets/serverless-domain-mapping.adoc b/snippets/serverless-domain-mapping.adoc index c0f172348376..72f6004789a5 100644 --- a/snippets/serverless-domain-mapping.adoc +++ b/snippets/serverless-domain-mapping.adoc @@ -1,6 +1,6 @@ // Text snippet included in the following files // -// * serverless/security/serverless-custom-domains.adoc +// * serverless/knative-serving/config-custom-domains/serverless-custom-domains.adoc // * modules/serverless-domain-mapping-odc-admin.adoc Knative services are automatically assigned a default domain name based on your cluster configuration. For example, `-.example.com`. You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service. diff --git a/snippets/serverless-ha-intro.adoc b/snippets/serverless-ha-intro.adoc new file mode 100644 index 000000000000..a32b902e4e9d --- /dev/null +++ b/snippets/serverless-ha-intro.adoc @@ -0,0 +1,4 @@ +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. + +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. \ No newline at end of file