Contour Logo

Getting Started

Getting Started with Contour

This guide shows how to install Contour in three different ways:

  • using Contour’s example YAML
  • using the Helm chart for Contour
  • using the Contour gateway provisioner

It then shows how to deploy a sample workload and route traffic to it via Contour.

This guide uses all default settings. No additional configuration is required.

Validate Kubernetes environment

This guide is designed to work with:

  • a Kubernetes cluster with support for services of type LoadBalancer (GKE, AKS, EKS, etc.); or
  • a locally-running kind cluster with port mappings configured

If you already have access to one of these Kubernetes environments, you’re ready to move on to installing Contour. If not, you can set up a local kind cluster for testing purposes.

Install Contour and Envoy

Option 1: YAML

Run the following to install Contour:

$ kubectl apply -f

Verify the Contour pods are ready by running the following:

$ kubectl get pods -n projectcontour -o wide

You should see the following:

  • 2 Contour pods each with status Running and 1/1 Ready
  • 1+ Envoy pod(s), each with the status Running and 2/2 Ready

Option 2: Helm

This option requires Helm to be installed locally.

Add the bitnami chart repository (which contains the Contour chart) by running the following:

$ helm repo add bitnami

Install the Contour chart by running the following:

$ helm install my-release bitnami/contour --namespace projectcontour --create-namespace

Verify Contour is ready by running:

$ kubectl -n projectcontour get po,svc

You should see the following:

  • 1 instance of pod/my-release-contour-contour with status Running and 1/1 Ready
  • 1+ instance(s) of pod/my-release-contour-envoy with each status Running and 2/2 Ready
  • 1 instance of service/my-release-contour
  • 1 instance of service/my-release-contour-envoy

Option 3: Contour Gateway Provisioner

The Gateway provisioner watches for the creation of Gateway API Gateway resources, and dynamically provisions Contour+Envoy instances based on the Gateway's spec. Note that although the provisioning request itself is made via a Gateway API resource (Gateway), this method of installation still allows you to use any of the supported APIs for defining virtual hosts and routes: Ingress, HTTPProxy, or Gateway API’s HTTPRoute and TLSRoute. In fact, this guide will use an Ingress resource to define routing rules, even when using the Gateway provisioner for installation.

Deploy the Gateway provisioner:

$ kubectl apply -f

Verify the Gateway provisioner deployment is available:

$ kubectl -n projectcontour get deployments
NAME                          READY   UP-TO-DATE   AVAILABLE   AGE
contour-gateway-provisioner   1/1     1            1           1m

Create a GatewayClass:

kubectl apply -f - <<EOF
kind: GatewayClass
  name: contour

Create a Gateway:

kubectl apply -f - <<EOF
kind: Gateway
  name: contour
  namespace: projectcontour
  gatewayClassName: contour
    - name: http
      protocol: HTTP
      port: 80
          from: All

Verify the Gateway is available (it may take up to a minute to become available):

$ kubectl -n projectcontour get gateways
NAME        CLASS     ADDRESS         READY   AGE
contour     contour                   True    27s

Verify the Contour pods are ready by running the following:

$ kubectl -n projectcontour get pods

You should see the following:

  • 2 Contour pods each with status Running and 1/1 Ready
  • 1+ Envoy pod(s), each with the status Running and 2/2 Ready

Test it out!

Congratulations, you have installed Contour and Envoy! Let’s install a web application workload and get some traffic flowing to the backend.

To install httpbin, run the following:

kubectl apply -f

Verify the pods and service are ready by running:

kubectl get po,svc,ing -l app=httpbin

You should see the following:

  • 3 instances of pods/httpbin, each with status Running and 1/1 Ready
  • 1 service/httpbin CLUSTER-IP listed on port 80
  • 1 Ingress on port 80

NOTE: the Helm install configures Contour to filter Ingress and HTTPProxy objects based on the contour IngressClass name. If using Helm, ensure the Ingress has an ingress class of contour with the following:

kubectl patch ingress httpbin -p '{"spec":{"ingressClassName": "contour"}}'

Now we’re ready to send some traffic to our sample application, via Contour & Envoy.

Note, for simplicity and compatibility across all platforms we’ll use kubectl port-forward to get traffic to Envoy, but in a production environment you would typically use the Envoy service’s address.

Port-forward from your local machine to the Envoy service:

# If using YAML
$ kubectl -n projectcontour port-forward service/envoy 8888:80

# If using Helm
$ kubectl -n projectcontour port-forward service/my-release-contour-envoy 8888:80

# If using the Gateway provisioner
$ kubectl -n projectcontour port-forward service/envoy-contour 8888:80

In a browser or via curl, make a request to (note, is a public DNS record resolving to to make use of the forwarded port). You should see the httpbin home page.

Congratulations, you have installed Contour, deployed a backend application, created an Ingress to route traffic to the application, and successfully accessed the app with Contour!

Next Steps

Now that you have a basic Contour installation, where to go from here?

Check out the following demo videos:

Explore the documentation:

Connect with the Team

Have questions? Send a Slack message on the Contour channel, an email on the mailing list, or join a Contour meeting.


If you encounter issues, review the troubleshooting page, file an issue, or talk to us on the #contour channel on Kubernetes Slack.

Ready to try Contour?

Read our getting started documentation.