February 2018 Summaries

This article discusses three general strategies in Kubernetes for managing ingress, which is a collection of routing rules that govern how external users access services running in a Kubernetes cluster. These strategies include using NodePort, LoadBalancer, and Ingress Resource. The article also explores more sophisticated requirements of an ingress strategy, such as content-based routing, resilience, support for multiple protocols, and authentication. It provides guidelines on how to pick your Kubernetes ingress strategy and discusses the evolution of the Ingress API, Ingress v1, and the Gateway API. The article concludes by recommending Ambassador Edge Stack as a popular Kubernetes native API Gateway that supports all the use cases mentioned in this article.

The evolution of L7 proxies in microservices architecture has been marked by the emergence of smart RPC libraries, such as Finagle and Hystrix, which aimed to manage L7 communications but faced challenges in portability and maintenance. The introduction of Smart Proxies like SmartStack, Linkerd, and Envoy Proxy has addressed these issues, with Envoy Proxy being a notable pioneer in using dynamic APIs for management and having an ecosystem of control planes that use it. HAProxy and NGINX have responded by releasing their own versions with enhanced features, including runtime APIs and support for hitless reloads, but Envoy Proxy now holds the lead as the most popular and widely adopted L7 proxy solution.

Canary deployments are a technique for testing changes on real-world traffic, particularly useful in microservices architectures. They allow teams to test multiple versions of their service simultaneously and control which versions are being tested. A Layer 7 reverse proxy is necessary to support these capabilities, with Envoy Proxy being an example. Ambassador Edge Stack, built around Envoy, can be configured using Kubernetes annotations for canary deployments. This involves deploying a stable version of the service and then creating a canary deployment with a different weight. Traffic can be tested between the two versions, and if necessary, rolled back to the stable version by deleting the canary deployment.