The Contour Operator extends the Kubernetes API to create, configure and manage instances of Contour on behalf of users.

Overview of Contour Operator

Trademarks: This software listing is packaged by Bitnami. The respective trademarks mentioned in the offering are owned by the respective companies, and use of them does not imply any affiliation or endorsement.

$ helm repo add bitnami https://charts.bitnami.com/bitnami
$ helm install my-release bitnami/contour-operator

Bitnami charts for Helm are carefully engineered, actively maintained and are the quickest and easiest way to deploy containers on a Kubernetes cluster that are ready to handle production workloads.

This chart bootstraps a Contour Operator Deployment in a Kubernetes cluster using the Helm package manager.

Bitnami charts can be used with Kubeapps for deployment and management of Helm Charts in clusters.

• Kubernetes 1.21
• Helm 3.2.0

To install the chart with the release name my-release:

helm install my-release bitnami/contour-operator

The command deploys the Contour Operator on the Kubernetes cluster in the default configuration. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-release deployment:

helm delete my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

In the Bitnami catalog we offer both the bitnami/contour and bitnami/contour-operator charts. Each solution covers different needs and use cases.

The bitnami/contour chart deploys a single Contour installation using a Kubernetes Deployment object (together with Services, PVCs, ConfigMaps, etc.). The figure below shows a simplified view of the deployed objects in the cluster after executing helm install:

                     --------------                  ------------- 
                    |              |                |             |
 Service            |   Contour    |                |    Envoy    |
<-------------------                <---------------              |
                    |  Deployment  |                |  DaemonSet  |
                    |              |                |             |
                     ----------- --                  ------------- 
                                ^
                                |                 ------------ 
                                |                |            |
                                 ----------------  Configmaps |
                                                 |            |
                                                  ------------ 

Its lifecycle is managed using Helm.

The bitnami/contour-operator chart deploys a Contour Operator installation using a Kubernetes Deployment. The figure below shows the Contour Operator deployment after executing helm install:

 -------------------- 
|                    |       --------------- 
|  Contour Operator  |      |               |
|                    |      |     RBAC      |
|     Deployment     |      | Privileges    |
 ------- ------------        ------- ------- 
        ^                           |
        |    -----------------      |
         ---  Service Account  <---- 
             ----------------- 

The operator will extend the Kubernetes API with the Contour object, among others. From that moment, the user will be able to deploy objects of these kinds and the previously deployed Operator will take care of deploying all the required Deployments, ConfigMaps and Services for running a Contour instance. Its lifecycle is managed using kubectl on the Contour objects. The following figure shows a simplified view of the deployed objects after deploying a Contour object using kubectl:

   -------------------- 
  |                    |       --------------- 
  |  Contour Operator  |      |               |
  |                    |      |     RBAC      |
  |     Deployment     |      | Privileges    |
   ------- ------------        ------- ------- 
    |     ^                           |
    |     |    -----------------      |
    |      ---  Service Account  <---- 
    |          ----------------- 
    |
    |
    |
    |
    |     ----------------------------------------------------------------------- 
    |    |                        --------------                  -------------  |
    |->  |                       |              |                |             | |
         |    Service            |   Contour    |                |    Envoy    | |
         |   <-------------------                <---------------              | |
         |                       |  Deployment  |                |  DaemonSet  | |
         |                       |              |                |             | |
         |                        ----------- --                  -------------  |
         |                                   ^                                   |
         |                                   |                 ------------      |
         |                                    ----------------  Configmaps |     |
         |                                                    |  Secrets   |     |
         |                                                     ------------      |
          ----------------------------------------------------------------------- 

This solution allows to easily deploy multiple Contour instances compared to the bitnami/contour chart. As the operator automatically deploys Contour installations, the Contour Operator pods will require a ServiceAccount with privileges to create and destroy multiple Kubernetes objects. This may be problematic for Kubernetes clusters with strict role-based access policies.

See readme-generator-for-helm to create the table.

Specify each parameter using the --set key=value[,key=value] argument to helm install. For example,

helm install my-release \
  --set livenessProbe.enabled=false \
    bitnami/contour-operator

The above command disables the Operator liveness probes.

Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example,

helm install my-release -f values.yaml bitnami/contour-operator

Tip: You can use the default values.yaml

It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.

Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.

If the images for Contour and Envoy are in a private registry and require pull secrets to be set, you need to create three service accounts (Contour, Envoy and Contour Certgen) with your pull secrets in the same namespace as you wish to deploy a Contour object. For example, if you want to deploy a Contour object in the projectcontour namespace and your image pull secret is mySecret, you would need to create the following service accounts first:

kind: ServiceAccount
metadata:
  name: contour
  namespace: projectcontour
imagePullSecrets:
  - name: mySecret
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: contour-certgen
  namespace: projectcontour
imagePullSecrets:
  - name: mySecret
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: envoy
  namespace: projectcontour
imagePullSecrets:
  - name: mySecret

In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the extraEnvVars property.

contour-operator:
  extraEnvVars:
    - name: MY_VARIABLE
      value: my_value

Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the extraEnvVarsCM or the extraEnvVarsSecret values.

If additional containers are needed in the same pod as contour-operator (such as additional metrics or logging exporters), they can be defined using the sidecars parameter. If these sidecars export extra ports, extra port definitions can be added using the service.extraPorts parameter. Learn more about configuring and using sidecar containers.

This chart allows you to set your custom affinity using the affinity parameter. Find more information about Pod affinity in the kubernetes documentation.

As an alternative, use one of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the bitnami/common chart. To do so, set the podAffinityPreset, podAntiAffinityPreset, or nodeAffinityPreset parameters.

There are cases where you may want to deploy extra objects, such your custom Contour objects. For covering this case, the chart allows adding the full specification of other objects using the extraDeploy parameter.

For instance, to deploy your custom Contour definition, you can install the Contour using the values below:

extraDeploy:
  - |
    apiVersion: operator.projectcontour.io/v1alpha1
    kind: Contour
    metadata:
      name: contour-sample
    spec:
      namespace:
        name: {{ .Release.Namespace | quote }}

This version updates the chart to use Contour's latest release, 1.20.1. Among other features, exisiting CRDs have been syncronised with the official Contour repository

This version bumps the Envoy and Contour container to the ones matching the Contour Operator requirements.

Find more information about how to deal with common errors related to Bitnami's Helm charts in this troubleshooting guide.

Copyright © 2022 Bitnami

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.