Skip to content

Configure Knative networking

This page provides installation and configuration guidance for configuring Knative networking. These options include Ingress controls, service-meshes, and gateways.

Use the following command to determine which controllers are installed and their status.

kubectl get pods -n knative-serving

The controllers tested for Knative have the following base names:

  • Kourier: kourier-control-*, and kourier-gateway-*.
  • Contour: contour-*
  • Istio: istio-webhook-*
    • The main Istio control plane pods such as istiod-* are in the istio-system namespace, but Knative adds the istio-webhook-* pod in knative-serving when Istio is the chosen networking layer.

The network-config ConfigMap specifies the controller to be used with the ingress controller key. This key is patched with the name of the new controller when you configure a new one, as described in these instructions. See Changing the controller for more information about the ingress controller key.

Network layer options

Review the following tabs to determine the optimal networking layer for your cluster. Knative installs the Kourier controller as the default ingress. For most users, the Kourier ingress controller is sufficient with the already installed default Istio gateway resource. You can expand your capabilities with more ingress using Contour, a full-feature service mesh with Istio, and the Kubernetes Gateway API.

---
config:
  theme: default
  layout: elk
  look: neo
---
flowchart LR
K1["Knative<br>net-kourier"] -- creates --> K2["Ingress&nbsp;objects"]
K2 --> K3["Class: kourier.ingress.networking.knative.dev"]

The Knative net-kourier is an Ingress for Knative Serving. Kourier is a lightweight alternative for the Istio ingress as its deployment consists only of an Envoy proxy and a control plane.

Designed for Knative Serving with efficient serverless function deployment is the goal. Kourier is the default ingress choice for most users, when a service mesh is not required, as it has a simple setup.

Use the following steps to install Kourier and enable its Knative integration.

  1. Install the Knative Kourier controller:

    kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml

  2. Configure Knative Serving to use Kourier by default:

    kubectl patch configmap/config-network \
--namespace knative-serving \
--type merge \
--patch '{"data":{"ingress-class":"kourier.ingress.networking.knative.dev"}}'

  3. Verify the installation by having pods with the base name of kourier-controller and kourier-gateway in the results.

    kubectl get pods -n knative-serving

  4. Get the external IP address (FQDN) to configure DNS records:

    kubectl --namespace kourier-system get service kourier

---
config:
  theme: default
  layout: elk
  look: neo
---
flowchart LR
C1["Knative<br>net-contour"] -- creates --> C2["Ingress&nbsp;objects"]
C2 --> C3["Class: contour.ingress.networking.knative.dev"]

The Knative net-contour controller enables Contour to satisfy the networking needs of Knative Serving by bridging Knative's KIngress resources to Contour's HTTPProxy resources.

A good choice for clusters that already run non-Knative apps and want to reuse a single Ingress controller as well as teams who are already using Contour/Envoy and wanting Knative integration with advanced routing but not full service mesh.

Use the following steps to install and enable Contour and enable its Knative integration.

  1. Install the Knative Contour controller:

    kubectl apply -f https://github.com/knative/net-kourier/releases/latest/download/kourier.yaml

  2. Configure Knative Serving to use Contour:

  kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress-class":"contour.ingress.networking.knative.dev"}}'

  1. Verify the installation by having a pod with the base name of contour in the results.

    kubectl get pods -n knative-serving

  2. Get the external IP address (FQDN) to configure DNS records:

    kubectl --namespace contour-external get service envoy

---
config:
  theme: default
  layout: elk
---
flowchart LR
    I1["Knative&nbsp;net-istio"] -- creates --> I2["Service + Gateway"]
    I2 --> I3["Class: istio.ingress.networking.knative.dev<br>No native Ingress objects"]

The Knative net-istio defines a KIngress controller for Istio. A full-feature service mesh integrated with Knative that can also function as a Knative ingress. Best for enterprises already running Istio or needing advanced service mesh features alongside Knative.

Note that Knative has a default Istio integration without the full-feature service mesh. The knative-ingress-gateway in the knative-serving namespace is a shared Istio gateway resource that handles all incoming (north-south) traffic to Knative services. This gateway points to the underlying 1istio-ingressgatewayservice in theistio-system` namespace. You can replace this gateway with one of your own, see Configuring the Ingress gateway.

Use the following steps to install Istio and enable its Knative integration.

  1. Install a properly configured Istio:

    kubectl apply -l knative.dev/crd-install=true -f {{ artifact(repo="net-istio",org="knative-extensions",file="istio.yaml")}}
kubectl apply -f {{ artifact(repo="net-istio",org="knative-extensions",file="istio.yaml")}}

  2. Install the Knative Istio controller:

    kubectl apply -f {{ artifact(repo="net-istio",file="net-istio.yaml")}}

  3. Verify the installation by having pods with the base name of istio and istio-webhook in the results.

    kubectl get pods -n knative-serving

  4. Get the external IP address (FQDN) to configure DNS records:

    kubectl --namespace istio-system get service istio-ingressgateway

---
config:
  layout: elk
  theme: default
  look: neo
---
flowchart LR
    Client["External&nbsp;Client"] --> CGW["Custom&nbsp;Ingress&nbsp;Gateway"]
    CGW --> KIGW["Knative&nbsp;Ingress&nbsp;Gateway"] & Client
    KIGW --> Revision["Knative&nbsp;Revision"] & CGW
    Revision --> KIGW

Knative uses a shared ingress gateway to serve all incoming traffic within Knative service mesh. For information on customizing the gateway, see Configure the Ingress Gateway.

---
config:
  layout: elk
  theme: default
---
flowchart LR
 subgraph net-gateway-api["net-gateway-api&nbsp;controller"]
        GW["Gateway"]
        Route["Knative&nbsp;Route"]
        HR["HTTPRoute"]
  end
 subgraph underlying["Underlying&nbsp;Controller<br>(Contour │ Istio │ Envoy Gateway │ …)"]
    Controller["GatewayClass&nbsp;Controller"]
  end
    KSvc["Knative&nbsp;Service"] --> Route
    Route -- translates&nbsp;to --> GW & HR
    GW --> Controller
    HR --> Controller
    Controller -- routes&nbsp;traffic&nbsp;to --> Pods["Your&nbsp;Pods"]

style net-gateway-api fill:#e3f2fd,stroke:#1976d2
style underlying fill:#fff3e0,stroke:#ef6c00

The Knative net-gateway-api is a KIngress implementation and testing for Knative integration with the Kubernetes Gateway API.

Best for forward-looking teams adopting the Gateway API to unify ingress across Kubernetes, with Knative leveraging to the same standard.

The Kubernetes Gateway API requires a controller or service mesh. Istio and Contour implementations are tested though other Gateway API implementations should work. Currently, there is no native Gateway API support for Kourier. For more information see Tested Gateway API version and Ingress.

The controller Knative uses is determined by which Gateway API-compatible controller you install and configure in your cluster.

Use the following steps to install the Knative Gateway API controller.

  1. Configure Knative Serving to use net-gateway-api controller:

    kubectl patch configmap/config-network \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"ingress-class":"gateway-api.ingress.networking.knative.dev"}}'

  2. Get the external IP address (FQDN) to configure DNS records:

    kubectl get gateway --all-namespaces

Configure DNS

You can configure DNS to avoid running curl commands with a host header.

The following tabs show instructions for configuring DNS. Follow the procedure for the DNS of your choice:

Knative provides a Kubernetes Job called default-domain that configures Knative Serving to use sslip.io as the default DNS suffix.

kubectl apply -f {{artifact(repo="serving",file="serving-default-domain.yaml")}}

This configuration works only if the cluster LoadBalancer Service exposes an IPv4 address or hostname. It does not work with IPv6 clusters or local setups such as minikube, unless minikube tunnel is running, and should consider using the "Real DNS" or "No DNS" tabs.

To configure DNS for Knative, take the External IP or CNAME from setting up networking, and configure it with your DNS provider as follows:

  • If the networking layer produced an External IP address, then configure a wildcard A record for the domain:

    # Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == A 35.233.41.212

  • If the networking layer produced a CNAME, then configure a CNAME record for the domain:

    # Here knative.example.com is the domain suffix for your cluster
*.knative.example.com == CNAME a317a278525d111e89f272a164fd35fb-1510370581.eu-central-1.elb.amazonaws.com

  • Once your DNS provider has been configured, direct Knative to use that domain:

    # Replace knative.example.com with your domain suffix
kubectl patch configmap/config-domain \
  --namespace knative-serving \
  --type merge \
  --patch '{"data":{"knative.example.com":""}}'

If you are using curl to access the sample applications, or your own Knative app, and are unable to use the "Magic DNS (sslip.io)" or "Real DNS" methods, there is a temporary approach. This is useful for those who wish to evaluate Knative without altering their DNS configuration, as per the "Real DNS" method, or cannot use the "Magic DNS" method due to using, for example, minikube locally or IPv6 clusters.

To access your application using curl using this method:

  1. Configure Knative to use a domain reachable from outside the cluster: 

    kubectl patch configmap/config-domain \
      --namespace knative-serving \
      --type merge \
      --patch '{"data":{"example.com":""}}'

  2. After starting your application, get the URL of your application: 

    kubectl get ksvc
    The output should be similar to: 
    NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
helloworld-go   http://helloworld-go.default.example.com   helloworld-go-vqjlf   helloworld-go-vqjlf   True

  3. Instruct curl to connect to the External IP or CNAME defined by the networking layer mentioned in section 3, and use the -H "Host:" command-line option to specify the Knative application's host name. For example, if the networking layer defines your External IP and port to be http://192.168.39.228:32198 and you wish to access the helloworld-go application mentioned earlier, use: 

    curl -H "Host: helloworld-go.default.example.com" http://192.168.39.228:32198
    In the case of the provided helloworld-go sample application, using the default configuration, the output is: 
    Hello Go Sample v1!
    Refer to the "Real DNS" method for a permanent solution.

Change the controller

We use analytics and cookies to understand site traffic. Information about your use of our site is shared with Google for that purpose. Learn more.

× OK