Core Concepts on

Architecture

Mon, 01 Jan 0001 00:00:00 +0000

The Emissary architecture

Emissary is a control plane

Emissary is a specialized control plane for Envoy Proxy. In this architecture, Emissary translates configuration (in the form of Kubernetes Custom Resources) to Envoy configuration. All actual traffic is directly handled by the high-performance Envoy Proxy.

Details

The service owner defines configuration in Kubernetes manifests.
When the manifest is applied to the cluster, the Kubernetes API notifies Emissary of the change.
Emissary parses the change and transforms the configuration into a semantic intermediate representation. Envoy configuration is generated from this IR.
The new configuration is passed to Envoy via the gRPC-based Aggregated Discovery Service (ADS) API.
Traffic flows through the reconfigured Envoy, without dropping any connections.

Scaling and availability

Emissary relies on Kubernetes for scaling, high availability, and persistence. All Emissary configuration is stored directly in Kubernetes; there is no database. Emissary is packaged as a single container that contains both the control plane and an Envoy Proxy instance. By default, Emissary is deployed as a Kubernetes deployment and can be scaled and managed like any other Kubernetes deployment.

Kubernetes Network Architecture

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes Network architecture

Kubernetes has its own isolated network

Each Kubernetes cluster provides its own isolated network namespace. This approach has a number of benefits. For example, each pod can be easily accessed with its own IP address. One of the consequences of this approach, however, is that a network bridge is required in order to route traffic from outside the Kubernetes cluster to services inside the cluster.

Routing traffic to your Kubernetes cluster

While there are a number of techniques for routing traffic to a Kubernetes cluster, by far the most common and popular method involves deploying an in-cluster edge proxy / ingress controller along with an external load balancer. In this architecture, the network topology looks like this:

Microservices & API gateways

Mon, 01 Jan 0001 00:00:00 +0000

A microservices API gateway is an API gateway designed to accelerate the development workflow of independent services teams. A microservices API gateway provides all the functionality for a team to independently publish, monitor, and update a microservice.

This focus on accelerating the development workflow is distinct from the purpose of traditional API gateways, which focus on the challenges of managing APIs. Over the past decade, organizations have worked to expose internal systems through well-defined APIs. The challenge of safely exposing hundreds or thousands of APIs to end-users (both internal and external) led to the emergence of API gateways. Over time, API gateways have become centralized, mission critical pieces of infrastructure that control access to these APIs.

Operating Model

Mon, 01 Jan 0001 00:00:00 +0000

The Ambassador operating model: GitOps and continuous delivery

Containerized applications deployed in Kubernetes generally follow the microservices design pattern, where an application composed of dozens or even hundreds of services communicate with each other. Independent application development teams are responsible for the full lifecycle of a service, including coding, testing, deployment, release, and operations. By giving these teams independence, microservices enable organizations to scale their development without sacrificing agility.

Policies, declarative configuration, and Custom Resource Definitions

Emissary configuration is built on the concept of policies. A policy is a statement of intent and codified in a declarative configuration file. Emissary takes advantage of Kubernetes Custom Resource Definitions (CRDs) to provide a declarative configuration workflow that is idiomatic with Kubernetes.

Progressive Delivery

Mon, 01 Jan 0001 00:00:00 +0000

Today’s cloud-native applications may consist of hundreds of services, each of which are being updated at any time. Thus, many cloud-native organizations augment regression test strategies with testing in production using progressive delivery techniques.

Progressive Delivery is an approach for releasing software to production users. In the progressive delivery model, software is released to ever growing subsets of production users. This approach reduces the blast radius in the event of a failure.

Rate limiting at the edge

Mon, 01 Jan 0001 00:00:00 +0000

Rate limiting at the edge is a technique that is used to prevent a sudden or sustained increase in user traffic from breaking an API or underlying service. On the Internet, users can do whatever they want to your APIs, as you have no direct control over these end-users. Whether it’s intentional or not, these users can impact the availability, responsiveness, and scalability of your service.

Two approaches: Rate limiting and load shedding

Rate limiting use cases that fall into this scenario range from implementing functional requirements related to a business scenario – for example, where requests from paying customers is prioritized over requests from non-paying trial users – to implementing cross-functional requirements, such as resilience from a malicious actor attempting to issue a denial-of-service (DoS) attack.