Introducing Ambassador 0.17: self-service Kubernetes-native API Gateway

In a microservices world, the development workflow goes from product definition all the way to operations. This is why, at Datawire, we believe it’s crucial for a services team to have full control over the entire workflow. Yet giving a team of developers unfettered access to operational infrastructure can be a recipe for shooting yourself in the foot.

In working with organizations adopting Kubernetes, we’ve seen first hand how it’s possible to safely give developers access to some crucial operational infrastructure. Developers can use Kubernetes manifests to safely define how their infrastructure is supposed to run, without worrying (too much) about shooting themselves in the foot.

Ambassador 0.17

We’re excited to announce Ambassador 0.17, which extends the concept of self-service operational infrastructure to your edge service. With 0.17, Ambassador now supports Kubernetes annotations for configuration.

Here’s an example annotation:

apiVersion: v1
kind: Service
name: hello-world-canary
annotations: |
apiVersion: ambassador/v0
kind: Mapping
name: hello-world-canary-mapping
prefix: /hello/
service: hello-world-canary
weight: 10
app: hello-world-canary
- port: 80
targetPort: http-api
type: ClusterIP

In this example, we’re configuring a new mapping in Ambassador named hello-world-canary-mapping that maps the hello prefix to the hello-world-canary service.

Canary deployments

In this release, we’re also adding support for canary deployments. By specifying the weight parameter as shown in the example above, you can tell Ambassador to route a specific percentage of traffic (10% in the above example) to the given service. We’ve found this to be extraordinarily useful capability in our own service rollouts, as developers can easily do a canary deployment with a trivial configuration change. Rollback is as simple as deleting the service and deployment.

Header and Host matching

Ambassador 0.17 also supports mappings that match HTTP headers (including the Host header) in addition to the URL prefix, allowing your application to more easily take advantage of header data or host-based routing. Of course, header matching can be trivially combined with weights to allow for maximum flexibility when rolling out upgrades or entirely new services.

Envoy and Ambassador

Ambassador uses the Envoy Proxy for all of the L7 routing capabilities. Envoy’s incredibly powerful and has a ton of features. In response to our many customer feature requests, we’ve gradually been exposing more features of Envoy in Ambassador’s configuration.

Give it a try!

You can give Ambassador a quick spin with a Docker image, or run it in Kubernetes. Try it now. For more details on what else is in the 0.17 release, read the changelog.