Installing Cloud Native Runtimes with your Existing Contour Installation

This topic describes how you can configure Cloud Native Runtimes, commonly known as CNRs, with your existing Contour instance. Cloud Native Runtimes uses Contour to manage internal and external access to the services in a cluster.

About Using Contour with Cloud Native Runtimes

The instructions on this page assume that you have an existing Contour installation on your cluster.

Follow the instructions on this page if:

• You have installed Contour as part of Tanzu Application Platform and wish to configure Cloud Native Runtimes to use it.
• You see an error about an existing Contour installation when you install the Cloud Native Runtimes package.

Cloud Native Runtimes needs two instances of Contour: one instance for exposing services outside the cluster, and another instance for services that are private in your network. If installed as part of a Tanzu Application Platform profile, by default Cloud Native Runtimes will use the Contour instance installed in the namespace tanzu-system-ingress for both internal and external traffic.

If you already use a Contour instance to route requests from clients outside and inside the cluster, you may use your own Contour if it matches the Contour version used by Tanzu Application’s Platform.

You may use the same single instance of Contour for both internal and external traffic. However, this will cause internal and external traffic will be handled the same way. For example, if the Contour instance is configured to be accessible from clients outside the cluster, then any internal traffic will also be accessible from outside the cluster. Note that currently Tanzu Application Platform only supports using a single Contour instance for both internal and external traffic.

In all of the above cases, Cloud Native Runtimes will use the Tanzu Application Platform’s Contour CustomResourceDefinitions.

Prerequisites

The following prerequisites are required to configure Cloud Native Runtimes with an existing Contour installation:

• Contour version v1.22.0 (Contour version that is installed as part of Tanzu Application Platform). To identify your cluster’s Contour version, see Identify Your Contour Version below.

• Contour CustomResourceDefinitions versions:

  Resource Name	Version
  contourdeployments.projectcontour.io	v1alpha1
  contourconfigurations.projectcontour.io	v1alpha1
  extensionservices.projectcontour.io	v1alpha1
  httpproxies.projectcontour.io	v1
  tlscertificatedelegations.projectcontour.io	v1

Identify Your Contour Version

To identify your cluster’s Contour version, run:

export CONTOUR_NAMESPACE=CONTOUR-NAMESPACE
export CONTOUR_DEPLOYMENT=$(kubectl get deployment --namespace $CONTOUR_NAMESPACE --output name)
kubectl get $CONTOUR_DEPLOYMENT --namespace $CONTOUR_NAMESPACE --output jsonpath="{.spec.template.spec.containers[].image}"
kubectl get crds extensionservices.projectcontour.io --output jsonpath="{.status.storedVersions}"
kubectl get crds httpproxies.projectcontour.io --output jsonpath="{.status.storedVersions}"
kubectl get crds tlscertificatedelegations.projectcontour.io --output jsonpath="{.status.storedVersions}"

Where CONTOUR-NAMESPACE is the namespace where Contour is installed on your Kubernetes cluster.

Install Cloud Native Runtimes on a Cluster with Your Existing Contour Instances

To install Cloud Native Runtimes on a cluster with an existing Contour instance, you can add values to your cnr-values.yml file so that Cloud Native Runtimes will use your Contour instance.

An example of a cnr-values.yml file where you wish Cloud Native Runtimes to use the Contour version in a different namespace would look like this:

---
ingress:
  external:
    namespace: "tanzu-system-ingress"
  internal:
    namespace: "tanzu-system-ingress"

Note: If your Contour instance is removed or configured incorrectly, apps running on Cloud Native Runtimes will lose connectivity.