apiVersion: serving.knative.dev/v1beta1
kind: DomainMapping
metadata:
name: <domain_name> (1)
namespace: <namespace> (2)
spec:
ref:
name: <target_name> (3)
kind: <target_type> (4)
apiVersion: serving.knative.dev/v1
If you do not want to switch to the Developer perspective in the OpenShift Container Platform web console or use the Knative (kn
) CLI or YAML files, you can use the Administator perspective of the OpenShift Container Platform web console.
Knative services are automatically assigned a default domain name based on your cluster configuration. For example, <service_name>-<namespace>.example.com
. You can customize the domain for your Knative service by mapping a custom domain name that you own to a Knative service.
You can do this by creating a DomainMapping
resource for the service. You can also create multiple DomainMapping
resources to map multiple domains and subdomains to a single service.
If you have cluster administrator permissions on OpenShift Container Platform (or cluster or dedicated administrator permissions on OpenShift Dedicated or Red Hat OpenShift Service on AWS), you can create a DomainMapping
custom resource (CR) by using the Administrator perspective in the web console.
You have logged in to the web console.
You are in the Administrator perspective.
You have installed the OpenShift Serverless Operator.
You have installed Knative Serving.
You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads.
You have created a Knative service and control a custom domain that you want to map to that service.
Your custom domain must point to the IP address of the cluster. |
Navigate to CustomResourceDefinitions and use the search box to find the DomainMapping custom resource definition (CRD).
Click the DomainMapping CRD, then navigate to the Instances tab.
Click Create DomainMapping.
Modify the YAML for the DomainMapping
CR so that it includes the following information for your instance:
apiVersion: serving.knative.dev/v1beta1
kind: DomainMapping
metadata:
name: <domain_name> (1)
namespace: <namespace> (2)
spec:
ref:
name: <target_name> (3)
kind: <target_type> (4)
apiVersion: serving.knative.dev/v1
1 | The custom domain name that you want to map to the target CR. |
2 | The namespace of both the DomainMapping CR and the target CR. |
3 | The name of the target CR to map to the custom domain. |
4 | The type of CR being mapped to the custom domain. |
apiVersion: serving.knative.dev/v1beta1
kind: DomainMapping
metadata:
name: custom-ksvc-domain.example.com
namespace: default
spec:
ref:
name: showcase
kind: Service
apiVersion: serving.knative.dev/v1
Access the custom domain by using a curl
request. For example:
$ curl custom-ksvc-domain.example.com
{"artifact":"knative-showcase","greeting":"Welcome"}
When you specify net-kourier
for ingress and use DomainMapping
, the TLS for OpenShift routing is set to passthrough, and TLS is handled by the Kourier Gateway. In such cases, you might need to restrict which TLS cipher suites for Kourier are allowed for users.
You have logged in to the web console.
You are in the Administrator perspective.
You have installed the OpenShift Serverless Operator.
You have installed Knative Serving.
You have created a project or have access to a project with the appropriate roles and permissions to create applications and other workloads.
Your custom domain must point to the IP address of the cluster. |
In the KnativeServing
CR, use the cipher-suites
value to specify the cipher suites you want to enable:
spec:
config:
kourier:
cipher-suites: ECDHE-ECDSA-AES128-GCM-SHA256,ECDHE-ECDSA-CHACHA20-POLY1305
Other cipher suites will be disabled. You can specify multiple suites by separating them with commas.
The Kourier Gateway’s container image utilizes the Envoy proxy image, and the default enabled cipher suites depend on the version of the Envoy proxy. |