The core of Gimbal is IngressRoutes, which allow traffic to be routed into one or more applications. This section will discuss how to utilize Contour IngressRoute objects to create these definitions.
Before beginning it is important to understand how service discovery functions within Gimbal. The Discoverer components should be deployed per upstream cluster. Once synchronized, services will show up in your team namespace with the cluster name appended.
For example, if a Kubernetes cluster is being discovered and there was a service named s1
which existed in the namespace team1
, in the cluster cluster1
, once synchronized, the service in the Gimbal cluster would be named cluster1-s1
and it would be in the team1
namespace.
Following is a basic IngressRoute which routes any request to foo.bar.com
and proxies to a service named s1
on the remote cluster node02
over port 80
.
apiVersion: contour.heptio.com/v1beta1
kind: IngressRoute
metadata:
name: test
spec:
virtualhost:
fqdn: foo.bar.com
routes:
- match: /
services:
- name: cluster1-service1
port: 80
The IngressRoute API provides a number of enhancements over Kubernetes Ingress:
- Weight shifting
- Multiple services per route
- Load balancing strategies
- Multi-team support
Gimbal's multi-team support is enabled through Contour's IngressRoute Delegation.
Contour has an enforcing mode which accepts a list of namespaces where root IngressRoutes are valid.
Only users permitted to operate in those namespaces can therefore create IngressRoutes with the virtualhost
field.
This restricted mode is enabled in Contour by specifying a command line flag, --ingressroute-root-namespaces
, which will restrict Contour to only searching the defined namespaces for root IngressRoutes.
More information regarding IngressRoutes can be found in the Contour Documentation