This topic describes how you can configure Cloud Native Runtimes (CNRs) with your existing Contour instance. Cloud Native Runtimes uses Contour to manage internal and external access to the services in a cluster.
Follow the instructions in this topic if:
an existing Contour installation
when you install the Cloud Native Runtimes package.Cloud Native Runtimes needs two instances of Contour:
If installed as part of a Tanzu Application Platform profile, by default Cloud Native Runtimes 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 can use your own Contour if it matches the Contour version used by Tanzu Application Platform.
You can use the same single instance of Contour for both internal and external traffic. However, this causes Contour to handle internal and external traffic the same way. For example, if the Contour instance is configured to be accessible from clients outside the cluster, then any internal traffic is also accessible from outside the cluster. Tanzu Application Platform only supports using a single Contour instance for both internal and external traffic.
In all of these cases, Cloud Native Runtimes uses the Tanzu Application Platform’s Contour CustomResourceDefinition
s.
The following prerequisites are required to configure Cloud Native Runtimes with an existing Contour installation:
Contour CustomResourceDefinition
s versions:
Resource Name | Version |
---|---|
contourdeployments.projectcontour.io |
v1alpha1 |
contourconfigurations.projectcontour.io |
v1alpha1 |
extensionservices.projectcontour.io |
v1alpha1 |
httpproxies.projectcontour.io |
v1 |
tlscertificatedelegations.projectcontour.io |
v1 |
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.
To install Cloud Native Runtimes on a cluster with an existing Contour instance, you can add values to your cnr-values.yaml
file so that Cloud Native Runtimes uses your Contour instance.
An example of a cnr-values.yaml
file where Cloud Native Runtimes uses the Contour version in a different namespace:
---
contour:
external:
namespace: "tanzu-system-ingress"
internal:
namespace: "tanzu-system-ingress"
NoteIf your Contour instance is removed or configured incorrectly, apps running on Cloud Native Runtimes lose connectivity.