David Cheney, Steve Sloka, Alex Brand, and Ross Kukulinski
After several months of hard work behind the scenes, Heptio is proud to take the wraps off a brand new version of Heptio Contour, our Envoy based Ingress controller for Kubernetes.
An iceberg is 90% below the waterline
At its heart, Heptio Contour is a translator between Kubernetes’ API server and Envoy. This is its raison d’être. The big news for Heptio Contour 0.6 is that this translation layer has been entirely rewritten.
Previously, Heptio Contour would translate Kubernetes objects directly into their Envoy counterparts. In Heptio Contour 0.6, the Kubernetes objects that describe a web application deployment— hostnames, TLS certificates, routes, and backend services — are used to build a Directed Acyclic Graph (DAG).
(You can generate graphs like these from your Heptio Contour installation. See the troubleshooting documentation.)
The DAG abstracts away the specifics of the Kubernetes Ingress object and allows Heptio Contour to model the semantics of a web application deployment without being tied closely to either Kubernetes’ or Envoy’s data models.
For example, routes are treated as first class objects in the DAG, rather than fragments of YAML in the Ingress spec. Another example: because the canonical representation of your web service is defined by the contents of the DAG, adding support for multiple services connected to a single route becomes trivial. Finally, using the DAG allows Heptio Contour to support alternative ways of describing a web application deployment, like our headline 0.6 release feature, IngressRoute.
IngressRoute what?
Since it was added in Kubernetes 1.1, Ingress hasn’t seen much attention — it’s still in beta — but boy is it popular! There are close to a dozen Ingress controllers in use today trying to do their best with the unfinished Ingress object. Mostly this involves a cornucopia of annotations on the Ingress object to clarify, restrict, or augment the structure imposed by the Ingress object. In this respect, Heptio Contour is much the same as any other Ingress controller.
At the same time a number of web application deployment patterns like blue/green deployments, explicit load balancing strategies, and presenting more than one Kubernetes Service behind a single route, are difficult to achieve with Ingress as it stands today.
In collaboration with Actapio, a subsidiary of Yahoo Japan Corporation, we’ve added a new kind of layer seven ingress object to Heptio Contour. We call it IngressRoute.
We designed the IngressRoute CRD spec to do two things. The first is to provide a sensible home for configuration parameters that were previously crammed into annotations. The second is a mechanism to make it safer to share an ingress controller across multiple namespaces and teams in the same Kubernetes cluster. We do this using a process we call delegation.
Much like the way a subdomain is delegated from one domain name server to another, an IngressRoute may delegate control of some, or all, of the HTTP routing prefixes it controls to another IngressRoute.
# root.ingressroute.yaml
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: bar-com-root
namespace: default
spec:
virtualhost:
fqdn: root.bar.com
routes:
– match: /
services:
– name: s1
port: 80
# delegate the path, `/service2` to the IngressRoute object in this namespace with the name `service2`
– match: /service2
delegate:
name: bar-com-service
—
# service2.ingressroute.yaml
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: bar-com-service
namespace: default
spec:
routes:
– match: /service2
services:
– name: s2
port: 80
– match: /service2/blog
services:
– name: blog
port: 80
In this example the routes below http://root.bar.com/service2 are managed by the author of the bar-com-service IngressRoute object. The IngressRoute object bar-com-root is functioning as the “root” and the bar-com-service is the “delegation” IngressRoute object. This delegation also works across namespaces, allowing the ownership of the root of an IngressRoute, its hostname and TLS secret, to be handled in a namespace that is separate from the IngressRoute routes and Kubernetes Services that provide the web application itself.
That all means that Heptio Contour 0.6 has an ability to restrict the namespaces it uses to respond to IngressRoute roots. We’re excited about the possibilities this offers for deploying Heptio Contour in multi-team Kubernetes clusters.
You can read more about IngressRoute in the Heptio Contour docs/ directory
What next?
Over the next few weeks we’ll be writing about how you can use the new features of IngressRoute to implement patterns like blue/green deployment, load balancing strategies, and cross namespace delegation.
If you’re interested in hearing more about IngressRoute developments, you can find us on the Kubernetes #contour Slack channel or follow us on Twitter.
Last updated 2018–09–24 17:20:50 AEST