{"id":256,"date":"2018-10-16T05:08:47","date_gmt":"2018-10-16T05:08:47","guid":{"rendered":"https:\/\/www.appservgrid.com\/paw93\/?p=256"},"modified":"2018-10-16T05:19:01","modified_gmt":"2018-10-16T05:19:01","slug":"improving-the-multi-team-kubernetes-ingress-experience-with-heptio-contour-0-6","status":"publish","type":"post","link":"https:\/\/www.appservgrid.com\/paw93\/index.php\/2018\/10\/16\/improving-the-multi-team-kubernetes-ingress-experience-with-heptio-contour-0-6\/","title":{"rendered":"Improving the multi-team Kubernetes ingress experience with Heptio Contour 0.6"},"content":{"rendered":"

Kubernetes has a variety of primitives that make it a great platform for running workloads submitted by multiple teams. Features like Role Based Access Control (RBAC) and Namespaces make it possible to divide clusters across multiple teams in a safe way. There are some challenges however, and one of the most important ones our enterprise customers have encountered lies in the Ingress API. In this post, we will explore how a bad Ingress resource can break your ingress layer, and walk through our novel approach to multi-team ingress using Heptio Contour\u2019s new IngressRoute resource.<\/a>
\n
\nMulti-team Ingress on Kubernetes
\nMost organizations typically have more than one team interacting with a given cluster. Cluster operators assign one or more namespaces to each team and use RBAC to ensure that no team can mess with another team\u2019s resources.
\nEven though Ingress is a namespaced resource that can be locked down with RBAC, it poses a challenge in multi-team clusters because it controls cluster-level configuration: the hosts and paths on which to serve application traffic.
\nLet us imagine a scenario where the marketing team owns www.example.com\/blog<\/em>. They are responsible for the organization\u2019s blog and they have configured an Ingress resource that looks like this:<\/p>\n

apiVersion: extensions\/v1beta1
\nkind: Ingress
\nmetadata:
\nname: blog
\nnamespace: marketing
\nspec:
\nrules:
\n– host: www.example.com
\nhttp:
\npaths:
\n– path: \/blog
\nbackend:
\nserviceName: blog
\nservicePort: 80<\/p>\n

Now, the engineering team is looking to run their own engineering-focused blog, and they mistakenly apply the following Ingress resource into the engineering namespace:<\/p>\n

apiVersion: extensions\/v1beta1
\nkind: Ingress
\nmetadata:
\nname: blog
\nnamespace: engineering
\nspec:
\nrules:
\n– host: www.example.com
\nhttp:
\npaths:
\n– path: \/blog
\nbackend:
\nserviceName: engineering-blog
\nservicePort: 80<\/p>\n

We now have two conflicting Ingress configurations that point www.example.com\/blog<\/em> to different services. The Ingress API does not define how to handle this conflict and the behavior of Ingress Controllers frequently differs \u2014 this results in a negative user experience affecting multiple parties. The engineering team is completely unaware that they have taken down the company blog, while the avid blog readers are unable to access their favorite blog.
\nAs you can see in this example, the Ingress resource can become the Achilles\u2019 heel of a multi-team cluster. We have heard from multiple customers that have been bitten by this in production, and thus we decided to address this issue in Contour.
\nIngressRoute delegation to the rescue
\nOne of the most exciting features introduced in the latest version of Heptio Contour is the IngressRoute Custom Resource Definition (CRD). Among the many improvements available in this new custom resource is delegation support, which allow you to delegate the configuration of a specific host or path to another IngressRoute.
\nThe crux of the problem with the Ingress resource in a multi-team cluster is that operators do not have a way to prevent teams from claiming hosts and paths at will. The ability to create root IngressRoutes in a specific namespace, as well as the ability to do cross-namespace delegation is our answer to this problem.
\nUsing the delegation feature of the IngressRoute, cluster operators get full control of the roots of their ingress layer by limiting which namespaces are authorized to create root IngressRoutes<\/a>. This eliminates the possibility for two teams to create configurations that collide. The IngressRoute roots specify the top level domains and TLS configuration, while delegating the configuration of specific subdomains or paths to other IngressRoutes in other namespaces. In this way, each team gets the ability to use and configure the slice of the ingress space that has been delegated to their team\u2019s namespace.
\nLet us revisit the problematic scenario we outlined above. The cluster operator creates a \u201croots\u201d namespace, and configures Contour to only accept root IngressRoutes from this namespace. Then, the cluster operator creates a root IngressRoute for www.example.com<\/em> and delegates the \/blog path to the marketing team:<\/p>\n

apiVersion: contour.heptio.com\/v1beta1
\nkind: IngressRoute
\nmetadata:
\nname: example-com-root
\nnamespace: roots
\nspec:
\nvirtualhost:
\nfqdn: www.example.com
\nroutes:
\n– match: \/blog
\ndelegate:
\nname: blog
\nnamespace: marketing<\/p>\n

The marketing team creates an IngressRoute that sets up the company blog. Note that the virtualhost <\/em>is missing, as this is not a root IngressRoute.<\/p>\n

apiVersion: contour.heptio.com\/v1beta1
\nkind: IngressRoute
\nmetadata:
\nname: blog
\nnamespace: marketing
\nspec:
\nroutes:
\n– match: \/blog
\nservices:
\n– name: blog
\nport: 80<\/p>\n

As you might imagine, if the engineering team were to create a conflicting IngressRoute, the company\u2019s blog would remain accessible as there is no delegation path that points to the engineering team IngressRoute. Instead of producing an outage, Contour ignores the orphaned route<\/em> and sets its status field accordingly:<\/p>\n

apiVersion: contour.heptio.com\/v1beta1
\nkind: IngressRoute
\nmetadata:
\nname: blog
\nnamespace: engineering
\nspec:
\nroutes:
\n– match: \/blog
\nservices:
\n– name: engineering-blog
\nport: 80
\nstatus:
\ncurrentStatus: orphaned
\ndescription: this IngressRoute is not part of a delegation chain from a root IngressRoute<\/p>\n

What\u2019s next?
\nWe have explored the new IngressRoute and more specifically, the delegation model that enables you to run multi-team Kubernetes clusters in a safe way; this is one of the exciting features available in the latest version of Heptio Contour<\/a>. But, there\u2019s more.
\nIn future posts, we will explore other patterns enabled by the IngressRoute, including blue\/green deployments, canary deployments and load balancing strategies. If you have any questions, or are interested in learning more, feel to reach us via the #contour channel on the Kubernetes community Slack<\/a>, or follow us on Twitter<\/a>.
\nSource<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

Kubernetes has a variety of primitives that make it a great platform for running workloads submitted by multiple teams. Features like Role Based Access Control (RBAC) and Namespaces make it possible to divide clusters across multiple teams in a safe way. There are some challenges however, and one of the most important ones our enterprise … <\/p>\n

Continue reading “Improving the multi-team Kubernetes ingress experience with Heptio Contour 0.6”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-256","post","type-post","status-publish","format-standard","hentry","category-kubernetes"],"_links":{"self":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/256","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/comments?post=256"}],"version-history":[{"count":2,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/256\/revisions"}],"predecessor-version":[{"id":261,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/posts\/256\/revisions\/261"}],"wp:attachment":[{"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/media?parent=256"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/categories?post=256"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.appservgrid.com\/paw93\/index.php\/wp-json\/wp\/v2\/tags?post=256"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}