Contour

Mon, 01 Jan 0001 00:00:00 +0000

Contour Architecture

The Contour Ingress controller is a collaboration between:

Envoy, which provides the high performance reverse proxy.
Contour, which acts as a management server for Envoy and provides it with configuration.

These containers are deployed separately, Contour as a Deployment and Envoy as a Kubernetes Daemonset or Deployment, although other configurations are possible.

In the Envoy Pods, Contour runs as an initcontainer in bootstrap mode and writes an Envoy bootstrap configuration to a temporary volume. This volume is passed to the Envoy container and directs Envoy to treat Contour as its management server.

Mon, 01 Jan 0001 00:00:00 +0000

Access Logging

Overview

Contour allows you to control Envoy’s access logging. By default, HTTP and HTTPS access logs are written to /dev/stdout by the Envoy containers and look like following:

[2021-04-14T16:36:00.361Z] "GET /foo HTTP/1.1" 200 - 0 463 6 3 "-" "HTTPie/1.0.3" "837aa8dc-344f-4faa-b7d5-c9cce1028519" "localhost:8080" "127.0.0.1:8081"

The detailed description of each field can be found in Envoy access logging documentation.

Customizing Access Log Destination

You can change the destination file where the access log is written by using Contour command line parameters --envoy-http-access-log and --envoy-https-access-log.

Mon, 01 Jan 0001 00:00:00 +0000

Annotations Reference

Annotations are used in Ingress Controllers to configure features that are not covered by the Kubernetes Ingress API.

Some of the features that have been historically configured via annotations are supported as first-class features in Contour’s HTTPProxy API, which provides a more robust configuration interface over annotations.

However, Contour still supports a number of annotations on the Ingress resources.

Standard Kubernetes Ingress annotations

The following Kubernetes annotations are supported on Ingress objects:

Mon, 01 Jan 0001 00:00:00 +0000

Packages:

projectcontour.io/v1
projectcontour.io/v1alpha1

projectcontour.io/v1

Package v1 holds the specification for the projectcontour.io Custom Resource Definitions (CRDs).

In building this CRD, we’ve inadvertently overloaded the word “Condition”, so we’ve tried to make this spec clear as to which types of condition are which.

MatchConditions are used by Routes and Includes to specify rules to match requests against for either routing or inclusion.

DetailedConditions are used in the Status of these objects to hold information about the relevant state of the object and the world around it.

Mon, 01 Jan 0001 00:00:00 +0000

Contour API Reference

Packages:

projectcontour.io/v1
projectcontour.io/v1alpha1

projectcontour.io/v1

Package v1 holds the specification for the projectcontour.io Custom Resource Definitions (CRDs).

In building this CRD, we’ve inadvertently overloaded the word “Condition”, so we’ve tried to make this spec clear as to which types of condition are which.

MatchConditions are used by Routes and Includes to specify rules to match requests against for either routing or inclusion.

DetailedConditions are used in the Status of these objects to hold information about the relevant state of the object and the world around it.

Mon, 01 Jan 0001 00:00:00 +0000

Client Authorization

Contour supports integrating external servers to authorize client requests.

Envoy implements external authorization in the ext_authz filter. This filter intercepts client requests and holds them while it sends a check request to an external server. The filter uses the check result to either allow the request to proceed, or to deny or redirect the request.

The diagram below shows the sequence of requests involved in the successful authorization of a HTTP request:

Mon, 01 Jan 0001 00:00:00 +0000

Contour now enables users to customize attributes on HTTP Set-Cookie response headers. Application specific cookies and cookies generated by Contour’s “cookie” load balancing strategy can be rewritten either per HTTPProxy Route or Service. Users can choose to rewrite the Path, Domain, Secure, and SameSite attributes of the Set-Cookie header currently. These attributes may be things an application may not be able to accurately set, without prior knowledge of how the application is deployed. For example, if Contour is in use to rewrite the path or hostname of a request before it reaches an application backend, the application may not be able to accurately set the Path and Domain attributes in a Set-Cookie response header. This feature can be used to apply security settings to ensure browsers treat generated cookies appropriately. The SameSite and Secure attributes are currently not set by Envoy when it generates the X-Contour-Session-Affinity, but with this feature, users can customize this cookie further.

Mon, 01 Jan 0001 00:00:00 +0000

CORS

A CORS (Cross-origin resource sharing) policy can be set for a HTTPProxy in order to allow cross-domain requests for trusted sources. If a policy is set, it will be applied to all the routes of the virtual host.

Contour allows configuring the headers involved in responses to cross-domain requests. These include the Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Expose-Headers, Access-Control-Max-Age, Access-Control-Allow-Private-Network and Access-Control-Allow-Credentials headers in responses.

In this example, cross-domain requests will be allowed for any domain (note the * value), with the methods GET, POST, or OPTIONS. Headers Authorization and Cache-Control will be passed to the upstream server and headers Content-Length and Content-Range will be made available to the cross-origin request client.

Mon, 01 Jan 0001 00:00:00 +0000

External Service Routing

HTTPProxy supports routing traffic to ExternalName service types, but this is disabled by default, as it can lead to inadvertent exposure of the Envoy Admin UI, allowing remote shutdown and restart of Envoy. Please see this security advisory for all the details. It can also be used to expose services in namespaces a user does not have access to, using an ExternalName of service.namespace.svc.cluster.local. Please see this Kubernetes security advisory for more details.

Mon, 01 Jan 0001 00:00:00 +0000

HTTPProxy Fundamentals

The Ingress object was added to Kubernetes in version 1.1 to describe properties of a cluster-wide reverse HTTP proxy. Since that time, the Ingress API has remained relatively unchanged, and the need to express implementation-specific capabilities has inspired an explosion of annotations.

The goal of the HTTPProxy Custom Resource Definition (CRD) is to expand upon the functionality of the Ingress API to allow for a richer user experience as well addressing the limitations of the latter’s use in multi tenant environments.

Mon, 01 Jan 0001 00:00:00 +0000

Gateway API

Introduction

Gateway API is an open source project managed by the SIG Network community. It is a collection of resources that model service networking in Kubernetes. These resources - GatewayClass, Gateway, HTTPRoute, TCPRoute, Service, etc - aim to evolve Kubernetes service networking through expressive, extensible, and role-oriented interfaces that are implemented by many vendors and have broad industry support.

Contour implements Gateway API in addition to supporting HTTPProxy and Ingress. In particular, Contour aims to support all core and extended features in Gateway API.

Mon, 01 Jan 0001 00:00:00 +0000

Upstream Health Checks

HTTP Proxy Health Checking

Active health checking can be configured on a per route basis. Contour supports HTTP health checking and can be configured with various settings to tune the behavior.

During HTTP health checking Envoy will send an HTTP request to the upstream Endpoints. It expects a 200 response by default if the host is healthy (see expectedStatuses below for configuring the “healthy” status codes). The upstream host can return 503 if it wants to immediately notify Envoy to no longer forward traffic to it. It is important to note that these are health checks which Envoy implements and are separate from any other system such as those that exist in Kubernetes.

Mon, 01 Jan 0001 00:00:00 +0000

HTTPProxy Inclusion

HTTPProxy permits the splitting of a system’s configuration into separate HTTPProxy instances using inclusion.

Inclusion, as the name implies, allows for one HTTPProxy object to be included in another, optionally with some conditions inherited from the parent. Contour reads the inclusion tree and merges the included routes into one big object internally before rendering Envoy config. Importantly, the included HTTPProxy objects do not have to be in the same namespace.

Mon, 01 Jan 0001 00:00:00 +0000

k8s Ingress Resource Support in Contour

This document describes Contour’s implementation of specific Ingress resource fields and features. As the Ingress specification has evolved between v1beta1 and v1, any differences between versions are highlighted to ensure clarity for Contour users.

Mon, 01 Jan 0001 00:00:00 +0000

IP Filtering

Contour supports filtering requests based on the incoming ip address using Envoy’s RBAC Filter.

Requests can be either allowed or denied based on a CIDR range specified on the virtual host and/or individual routes.

If the request’s IP address is allowed, the request will be proxied to the appropriate upstream. If the request’s IP address is denied, an HTTP 403 (Forbidden) will be returned to the client.

Specifying Rules

Rules are specified with the ipAllowPolicy and ipDenyPolicy fields on virtualhost and route:

Mon, 01 Jan 0001 00:00:00 +0000

JWT Verification

Contour supports verifying JSON Web Tokens (JWTs) on incoming requests, using Envoy’s jwt_authn HTTP filter. Specifically, the following properties can be checked:

issuer field
audiences field
signature, using a configured JSON Web Key Store (JWKS)
time restrictions (e.g. expiration, not before time)

If verification succeeds, the request will be proxied to the appropriate upstream. If verification fails, an HTTP 401 (Unauthorized) will be returned to the client.

JWT verification is only supported on TLS-terminating virtual hosts.

Mon, 01 Jan 0001 00:00:00 +0000

Overload Manager

Envoy uses heap memory when processing requests. When the system runs out of memory or memory resource limit for the container is reached, Envoy process is terminated abruptly. To avoid this, Envoy overload manager can be enabled. Overload manager controls how much memory Envoy will allocate at maximum and what actions it takes when the limit is reached.

Overload manager is disabled by default. It can be enabled at deployment time by using --overload-max-heap=[MAX_BYTES] command line flag in contour bootstrap command. The bootstrap command is executed in init container of Envoy pod to generate initial configuration for Envoy. To enable overload manager, modify the deployment manifest and add for example --overload-max-heap=2147483648 to set maximum heap size to 2 GiB. The appropriate number of bytes can be different from system to system.

Mon, 01 Jan 0001 00:00:00 +0000

Rate Limiting

Overview
Local Rate Limiting
Global Rate Limiting

Overview

Rate limiting is a means of protecting backend services against unwanted traffic. This can be useful for a variety of different scenarios:

Protecting against denial-of-service (DoS) attacks by malicious actors
Protecting against DoS incidents due to bugs in client applications/services
Enforcing usage quotas for different classes of clients, e.g. free vs. paid tiers
Controlling resource consumption/cost

Envoy supports two forms of HTTP rate limiting: local and global.

Mon, 01 Jan 0001 00:00:00 +0000

Request Rewriting

Path Rewriting

HTTPProxy supports rewriting the HTTP request URL path prior to delivering the request to the backend service. Rewriting is performed after a routing decision has been made, and never changes the request destination.

The pathRewritePolicy field specifies how the path prefix should be rewritten. The replacePrefix rewrite policy specifies a replacement string for a HTTP request path prefix match. When this field is present, the path prefix that the request matched is replaced by the text specified in the replacement field. If the HTTP request path is longer than the matched prefix, the remainder of the path is unchanged.

Mon, 01 Jan 0001 00:00:00 +0000

Request Routing

A HTTPProxy object must have at least one route or include defined. In this example, any requests to multi-path.bar.com/blog or multi-path.bar.com/blog/* will be routed to the Service s2 using the prefix conditions. Requests to multi-path.bar.com/feed will be routed to Service s2 using exact match condition. All other requests to the host multi-path.bar.com will be routed to the Service s1.

# httpproxy-multiple-paths.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
 name: multiple-paths
 namespace: default
spec:
 virtualhost:
 fqdn: multi-path.bar.com
 routes:
 - conditions:
 - prefix: / # matches everything else
 services:
 - name: s1
 port: 80
 - conditions:
 - prefix: /blog # matches `multi-path.bar.com/blog` or `multi-path.bar.com/blog/*`
 services:
 - name: s2
 port: 80
 - conditions:
 - exact: /feed # matches `multi-path.bar.com/feed` only
 services:
 - name: s2
 port: 80

In the following example, we match on headers and query parameters and send to different services, with a default route if those do not match.

Mon, 01 Jan 0001 00:00:00 +0000

Slow Start Mode

Slow start mode is a configuration setting that is used to gradually increase the amount of traffic targeted to a newly added upstream endpoint. By default, the amount of traffic will increase linearly for the duration of time window set by window field, starting from 10% of the target load balancing weight and increasing to 100% gradually. The easing function for the traffic increase can be adjusted by setting optional field aggression. A value above 1.0 results in a more aggressive increase initially, slowing down when nearing the end of the time window. Value below 1.0 results in slow initial increase, picking up speed when nearing the end of the time window. Optional field minWeightPercent can be set to change the minimum percent of target weight. It is used to avoid too small new weight, which may cause endpoint to receive no traffic in beginning of the slow start window.

Mon, 01 Jan 0001 00:00:00 +0000

TLS Certificate Delegation

In order to support wildcard certificates, TLS certificates for a *.somedomain.com, which are stored in a namespace controlled by the cluster administrator, Contour supports a facility known as TLS Certificate Delegation. This facility allows the owner of a TLS certificate to delegate, for the purposes of referencing the TLS certificate, permission to Contour to read the Secret object from another namespace. Delegation works for both HTTPProxy and Ingress resources, however it needs an annotation to work with Ingress v1.

Mon, 01 Jan 0001 00:00:00 +0000

TLS Termination

HTTPProxy follows a similar pattern to Ingress for configuring TLS credentials.

You can secure a HTTPProxy by specifying a Secret that contains TLS private key and certificate information. If multiple HTTPProxies utilize the same Secret, the certificate must include the necessary Subject Authority Name (SAN) for each fqdn.

Contour (via Envoy) requires that clients send the Server Name Indication (SNI) TLS extension so that requests can be routed to the correct virtual host. Virtual hosts are strongly bound to SNI names. This means that the Host header in HTTP requests must match the SNI name that was sent at the start of the TLS session.

Mon, 01 Jan 0001 00:00:00 +0000

Tracing Support

Overview
Tracing-config

Overview

Envoy has rich support for distributed tracing，and supports exporting data to third-party providers (Zipkin, Jaeger, Datadog, etc.)

OpenTelemetry is a CNCF project which is working to become a standard in the space. It was formed as a merger of the OpenTracing and OpenCensus projects.

Contour supports configuring envoy to export data to OpenTelemetry, and allows users to customize some configurations.

Custom service name, the default is contour.
Custom sampling rate, the default is 100.
Custom the maximum length of the request path, the default is 256.
Customize span tags from literal or request headers.
Customize whether to include the pod’s hostname and namespace.

Tracing-config

In order to use this feature, you must first select and deploy an opentelemetry-collector to receive the tracing data exported by envoy.

Mon, 01 Jan 0001 00:00:00 +0000

Upstream TLS

A HTTPProxy can proxy to an upstream TLS backend by annotating the upstream Kubernetes Service or by specifying the upstream protocol in the HTTPProxy services field. Applying the projectcontour.io/upstream-protocol.tls annotation to a Service object tells Contour that TLS should be enabled and which port should be used for the TLS connection. The same configuration can be specified by setting the protocol name in the spec.routes.services[].protocol field on the HTTPProxy object. If both the annotation and the protocol field are specified, the protocol field takes precedence. By default, the upstream TLS server certificate will not be validated, but validation can be requested by setting the spec.routes.services[].validation field. This field has mandatory caSecret and subjectName fields, which specify the trusted root certificates with which to validate the server certificate and the expected server name. The caSecret can be a namespaced name of the form <namespace>/<secret-name>. If the CA secret’s namespace is not the same namespace as the HTTPProxy resource, TLS Certificate Delegation must be used to allow the owner of the CA certificate secret to delegate, for the purposes of referencing the CA certificate in a different namespace, permission to Contour to read the Secret object from another namespace.

Mon, 01 Jan 0001 00:00:00 +0000

Virtual Hosts

Similar to Ingress, HTTPProxy support name-based virtual hosting. Name-based virtual hosts use multiple host names with the same IP address.

foo.bar.com --| |-> foo.bar.com s1:80
 | 178.91.123.132 |
bar.foo.com --| |-> bar.foo.com s2:80

Unlike Ingress however, HTTPProxy only support a single root domain per HTTPProxy object. As an example, this Ingress object:

# ingress-name.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: name-example
spec:
 rules:
 - host: foo1.bar.com
 http:
 paths:
 - backend:
 service:
 name: s1
 port:
 number: 80
 pathType: Prefix 
 - host: bar1.bar.com
 http:
 paths:
 - backend:
 service:
 name: s2
 port:
 number: 80
 pathType: Prefix

must be represented by two different HTTPProxy objects:

Mon, 01 Jan 0001 00:00:00 +0000

Websockets

WebSocket support can be enabled on specific routes using the enableWebsockets field:

# httpproxy-websockets.yaml
apiVersion: projectcontour.io/v1
kind: HTTPProxy
metadata:
 name: chat
 namespace: default
spec:
 virtualhost:
 fqdn: chat.example.com
 routes:
 - services:
 - name: chat-app
 port: 80
 - conditions:
 - prefix: /websocket
 enableWebsockets: true # Setting this to true enables websocket for all paths that match /websocket
 services:
 - name: chat-app
 port: 80

If you are using Gateway API, websockets are enabled by default at the Listener level.

Mon, 01 Jan 0001 00:00:00 +0000

Contour Configuration Reference

Serve Flags
Configuration File
Environment Variables
Bootstrap Config File

Overview

There are various ways to configure Contour, flags, the configuration file, as well as environment variables. Contour has a precedence of configuration for contour serve, meaning anything configured in the config file is overridden by environment vars which are overridden by cli flags.

Serve Flags

The contour serve command is the main command which is used to watch for Kubernetes resource and process them into Envoy configuration which is then streamed to any Envoy via its xDS gRPC connection. There are a number of flags that can be passed to this command which further configures how Contour operates. Many of these flags are mirrored in the Contour Configuration File.

Mon, 01 Jan 0001 00:00:00 +0000

Deployment Options

The Getting Started guide shows you a simple way to get started with Contour on your cluster. This topic explains the details and shows you additional options. Most of this covers running Contour using a Kubernetes Service of Type: LoadBalancer. If you don’t have a cluster with that capability see the Running without a Kubernetes LoadBalancer section.

Installation

Contour requires a secret containing TLS certificates that are used to secure the gRPC communication between Contour<>Envoy. This secret can be auto-generated by the Contour certgen job or provided by an administrator. Traffic must be forwarded to Envoy, typically via a Service of type: LoadBalancer. All other requirements such as RBAC permissions, configuration details, are provided or have good defaults for most installations.

Mon, 01 Jan 0001 00:00:00 +0000

This document outlines how we use GitHub.

Milestones

Contour attempts to ship on a quarterly basis. These releases are tracked with a milestone. The current release is the milestone with the closest delivery date.

Issues which are not assigned to the current milestone should not be worked on.

Priorities

This project has three levels of priority:

p0 - Must fix immediately. This is reserved for bugs and security issues. A milestone cannot ship with open p0 issues.
p1 - Should be done. p1 issues assigned to a milestone should be completed during that milestone.
p2 - May be done. p2 issues assigned to a milestone may be completed during that milestone if time permits.

Issues without a priority are unprioritised. Priority will be assigned by a PM or release manager during issue triage.

Mon, 01 Jan 0001 00:00:00 +0000

Enabling TLS between Envoy and Contour

This document describes the steps required to secure communication between Envoy and Contour. The outcome of this is that we will have two Secrets available in the projectcontour namespace:

contourcert: contains Contour’s keypair which is used for serving TLS secured gRPC, and the CA’s public certificate bundle which is used for validating Envoy’s client certificate. Contour’s certificate must be a valid certificate for the name contour in order for this to work. This is currently hardcoded by Contour.
envoycert: contains Envoy’s keypair which used as a client for connecting to Contour, and the CA’s public certificate bundle which is used for validating Contour’s server certificate.

Note that both Secrets contain a copy of the CA certificate bundle under the ca.crt data key.

Mon, 01 Jan 0001 00:00:00 +0000

Redeploying Envoy

The Envoy process, the data path component of Contour, at times needs to be re-deployed. This could be due to an upgrade, a change in configuration, or a node-failure forcing a redeployment.

When implementing this roll out, the following steps should be taken:

Stop Envoy from accepting new connections
Start draining existing connections in Envoy by sending a POST request to /healthcheck/fail endpoint
Wait for connections to drain before allowing Kubernetes to SIGTERM the pod

Overview

Contour implements an envoy sub-command named shutdown-manager whose job is to manage a single Envoy instances lifecycle for Kubernetes. The shutdown-manager runs as a new container alongside the Envoy container in the same pod. It uses a Kubernetes preStop event hook to keep the Envoy container running while waiting for connections to drain. The /shutdown endpoint blocks until the connections are drained.

Mon, 01 Jan 0001 00:00:00 +0000

Getting Started with Contributing

Thanks for your interest in contributing to Contour. Community contributions are always needed, welcome, and appreciated. This guide shows how you can contribute to Contour in the following areas:

Code
Website
Documentation

Please familiarize yourself with the Code of Conduct and project Philosophy before contributing.

Getting Started with Code

Everything is managed on the Project Contour GitHub organization. Create an issue for a new idea or look for issues labeled good first issue to get started.

Mon, 01 Jan 0001 00:00:00 +0000

Troubleshooting

If you encounter issues, follow the guides below for help. For topics not covered here, you can file an issue, or talk to us on the #contour channel on Kubernetes Slack.

Envoy Administration Access

Review the linked steps to learn how to access the administration interface for your Envoy instance.

Contour Debug Logging

Learn how to enable debug logging to diagnose issues between Contour and the Kubernetes API.

Envoy Debug Logging

Learn how to enable debug logging to diagnose TLS connection issues.

Mon, 01 Jan 0001 00:00:00 +0000

Enabling Contour Debug Logging

The contour serve subcommand has two command-line flags that can be helpful for debugging. The --debug flag enables general Contour debug logging, which logs more information about how Contour is processing API resources. The --kubernetes-debug flag enables verbose logging in the Kubernetes client API, which can help debug interactions between Contour and the Kubernetes API server. This flag requires an integer log level argument, where higher number indicates more detailed logging.

Mon, 01 Jan 0001 00:00:00 +0000

Visualizing Contour’s Internal Object Graph

Contour models its configuration using a directed acyclic graph (DAG) of internal objects. This can be visualized through a debug endpoint that outputs the DAG in DOT format. To visualize the graph, you must have graphviz installed on your system.

To download the graph and save it as a PNG:

# Port forward into the contour pod
$ CONTOUR_POD=$(kubectl -n projectcontour get pod -l app=contour -o name | head -1)
# Do the port forward to that pod
$ kubectl -n projectcontour port-forward $CONTOUR_POD 6060
# Download and store the DAG in png format
$ curl localhost:6060/debug/dag | dot -T png > contour-dag.png

The following is an example of a DAG that maps http://kuard.local:80/ to the kuard service in the default namespace:

Mon, 01 Jan 0001 00:00:00 +0000

Interrogate Contour’s xDS Resources

Sometimes it’s helpful to be able to interrogate Contour to find out exactly what xDS resource data it is sending to Envoy. Contour ships with a contour cli subcommand which can be used for this purpose.

Because Contour secures its communications with Envoy using Secrets in the cluster, the easiest way is to run contour cli commands inside the pod. Do this is via kubectl exec:

# Get one of the pods that matches the examples/daemonset
$ CONTOUR_POD=$(kubectl -n projectcontour get pod -l app=contour -o jsonpath='{.items[0].metadata.name}')
# Do the port forward to that pod
$ kubectl -n projectcontour exec $CONTOUR_POD -c contour -- contour cli lds --cafile=/certs/ca.crt --cert-file=/certs/tls.crt --key-file=/certs/tls.key

Which will stream changes to the LDS api endpoint to your terminal. Replace contour cli lds with contour cli rds for route resources, contour cli cds for cluster resources, and contour cli eds for endpoints.

Mon, 01 Jan 0001 00:00:00 +0000

Accessing the Envoy Administration Interface

Getting access to the Envoy administration interface can be useful for diagnosing issues with routing or cluster health. However, Contour doesn’t expose the entire Envoy Administration interface since that interface contains many options, such as shutting down Envoy or draining traffic. To prohibit this behavior, Contour only exposes the read-only options from the admin interface which still allows for debugging Envoy, but without the options mentioned previously.

Mon, 01 Jan 0001 00:00:00 +0000

Envoy container stuck in unready/draining state

It’s possible for the Envoy containers to become stuck in an unready/draining state. This is an unintended side effect of the shutdown-manager sidecar container being restarted by the kubelet. For more details on exactly how this happens, see this issue.

If you observe Envoy containers in this state, you should kubectl delete them to allow new Pods to be created to replace them.

To make this issue less likely to occur, you should:

Mon, 01 Jan 0001 00:00:00 +0000

Enabling Envoy Debug Logging

The envoy command has a --log-level flag that can be useful for debugging. By default, it’s set to info. To change it to debug, edit the envoy DaemonSet in the projectcontour namespace and replace the --log-level info flag with --log-level debug. Setting the Envoy log level to debug can be particilarly useful for debugging TLS connection failures.

Mon, 01 Jan 0001 00:00:00 +0000

Accessing Contour’s /debug/pprof Service

Contour exposes the net/http/pprof handlers for go tool pprof and go tool trace by default on 127.0.0.1:6060. This service is useful for profiling Contour. To access it from your workstation use kubectl port-forward like so,

# Get one of the pods that matches the Contour deployment
$ CONTOUR_POD=$(kubectl -n projectcontour get pod -l app=contour -o name | head -1)
# Do the port forward to that pod
$ kubectl -n projectcontour port-forward $CONTOUR_POD 6060

Contour

Contour Architecture

Access Logging

Overview

Customizing Access Log Destination

Annotations Reference

Standard Kubernetes Ingress annotations

projectcontour.io/v1

Contour API Reference

projectcontour.io/v1

Client Authorization

Cookie Rewriting

CORS

External Service Routing

HTTPProxy Fundamentals

Gateway API

Introduction

Upstream Health Checks

HTTP Proxy Health Checking

HTTPProxy Inclusion

k8s Ingress Resource Support in Contour

IP Filtering

Specifying Rules

JWT Verification

Overload Manager

Rate Limiting

Overview

Request Rewriting

Path Rewriting

Request Routing

Slow Start Mode

TLS Certificate Delegation

TLS Termination

Tracing Support

Overview

Tracing-config

Upstream TLS

Virtual Hosts

Websockets

Contour Configuration Reference

Overview

Serve Flags

Deployment Options

Installation

Milestones

Priorities

Enabling TLS between Envoy and Contour

Redeploying Envoy

Overview

Getting Started with Contributing

Getting Started with Code

Troubleshooting

Envoy Administration Access

Contour Debug Logging

Envoy Debug Logging

Enabling Contour Debug Logging

Visualizing Contour’s Internal Object Graph

Interrogate Contour’s xDS Resources

Accessing the Envoy Administration Interface

Envoy container stuck in unready/draining state

Enabling Envoy Debug Logging

Accessing Contour’s /debug/pprof Service