API gateways are an important presence in microservices architecture. On the one hand, it provides a unified entrance for external traffic access, which makes it convenient to implement firewall policies. On the other hand, the gateway can be used for traffic control, authentication, authorization, gray publishing, log collection, performance analysis and other advanced functions, effectively decoupled the service function from the non-service function, giving the system architecture greater flexibility. This series of articles attempts to analyze the current mainstream cloud native microservice gateways and compare their strengths and weaknesses.
Gateway selection criteria
In fact, Kubernetes itself has an Ingress Controller, based on Nginx or HAProxy 7 layer proxy for traffic forwarding. However, ingress can only perform simple reverse proxy and does not support flow control, gray scale, authentication, authorization and other necessary gateway functions. Therefore, ingress is generally considered to be a 7-layer HTTP proxy rather than an API gateway. This series focuses on analyzing gateway products such as Ambassador, Traefik and Kong, which have the required capabilities of microservices.
What is Ambassador?
Here is a quote from the official website
Ambassador is a kubernetes native open source microservices gateway built on Envoy Proxy. Ambassador was built to support multiple independent teams that needed to quickly publish, monitor and update services for end users. Ambassador also has Kubernetes Ingress and load balancing capabilities.
Note a few key words here: Envoy, Kubernetes native, microservices. Now there are many gateway products on the market, but Kubernetes native products are really few. Whereas traditional gateway products are configured based on REST apis or YAML files (they came out long before k8 came out), Ambassador is completely configured based on ANNOTATION or CRD of the K8S standard, which is, yes, very native.
Ambassador architecture
The specific process is as follows:
- The service owner defines the configuration in the Kubernetes Manifests (via annotation or CRD).
- When Manifest is applied to a cluster, the Kubernetes API notifies Ambassador of changes.
- Ambassador parses the changes and translates the configuration into an intermediate semantics. The Envoy configuration is generated by the IR.
- The new configuration is delivered to Envoy via the GRPC-based Aggregate Discovery Service (ADS) API.
- Traffic flows through the reconfigured Envoy without breaking any connections.
Scalability and availability
Ambassador relies on Kubernetes for scalability, high availability and persistence. All Ambassador configurations are stored directly in Kubernetes (ETCD) without a database. Ambassador is packaged into a separate container containing the control plane and an Ambassador Agent instance. By default, Ambassador is deployed as Kubernetes Deployment, which can be extended and managed just like any other Kubernetes Deployment.
Compare with other gateway products
The current mainstream gateway products can be divided into three categories:
- Hosted API gateways, such as the Amazon API Gateway
- Traditional API gateways, such as Kong
- Seven layers of proxies, such as Traefik, NGINX, HAProxy, or Envoy, or Ingress controllers based on these proxies
The problem with all of these managed and traditional API gateways is:
- Not self-serving. The management interfaces on traditional API gateways are not designed for developers to serve themselves and provide limited security and availability for developers.
- Not native to Kubernetes. They are typically configured using REST apis, which makes it difficult to adopt cloud native patterns such as GitOps and declarative configuration.
- Designed for API management, not microservices.
In general, tier 7 proxies can be used as API gateways, but additional custom development is required to support microservice use cases. In fact, many API gateways package the additional functionality required by the API gateway on top of the L7 proxy. Ambassador uses Envoy and Kong uses Nginx.
Istio
Istio is an open source service grid based on Envoy. The service grid is used to manage east/west traffic, while the API gateway is used to manage south/north traffic. In general, we find that south/north traffic is very different from east/west traffic (for example, you can’t control the client in north/south traffic).
Install the Ambassador
Installing Ambassador is very simple, using helm directly. If you are not familiar with helm, please refer to my previous article about helm. To install the helm, run the following command:
helm install --name my-release stable/ambassador
Copy the codeSlots on this side, it is recommended to use Microsoft’s azure charts mirror http://mirror.azure.cn/kubernetes/charts/, basic and official synchronization, and can be normal visit, ali cloud charts don’t know why the update is not very timely. Once installed, you can see that there are two Pods
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
ambassador-3655608000-43x86 1/1 Running 0 2m
ambassador-3655608000-w63zf 1/1 Running 0 2m
Copy the codeIf both are in the running state, then the Ambassador is installed. Next, let’s deploy the official app
---
apiVersion: v1
kind: Service
metadata:
name: tour
annotations:
getambassador.io/config: |
---
apiVersion: ambassador/v1
kind: Mapping
name: tour-ui_mapping
prefix: /
service: tour:5000
---
apiVersion: ambassador/v1
kind: Mapping
name: tour-backend_mapping
prefix: /backend/
service: tour:8080
labels:
ambassador:
- request_label:
- backend
spec:
ports:
- name: ui
port: 5000
targetPort: 5000
- name: backend
port: 8080
targetPort: 8080
selector:
app: tour
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: tour
spec:
replicas: 1
selector:
matchLabels:
app: tour
strategy:
type: RollingUpdate template: metadata: labels: app: tour spec: containers: - name: tour-ui image: IO /datawire/tour: UI-0.2.4 Ports: -name: HTTP containerPort: 5000-name: quote image: Quay. IO/datawire/tour: backend - 0.2.4 ports: - name: HTTP containerPort: 8080 resources: limits: CPU:"0.1"
memory: 100Mi
Copy the codeThis pod has two containers, UI at the front end and backend at the backend. Note the GetAmbassador. IO /config section of the Annotation, which is the Ambassador configuration. It defines two annotations, the Kind Mapping, which defines the matching path, service name, and port of the front and back end. This configuration means that those that match/go through port 5000 of tour, and those that match /backend go through port 8080 of Tour (corresponding to the service configuration of tour). CRDS can also be configured, and Ambassador has created a set of CRDS by default
[root@MiWiFi-R1CM-srv zuul]# kubectl get crds|grep ambassador
authservices.getambassador.io 2019-07-27T11:40:58Z
consulresolvers.getambassador.io 2019-07-27T11:40:58Z
kubernetesendpointresolvers.getambassador.io 2019-07-27T11:40:58Z
kubernetesserviceresolvers.getambassador.io 2019-07-27T11:40:58Z
mappings.getambassador.io 2019-07-27T11:40:58Z
modules.getambassador.io 2019-07-27T11:40:58Z
ratelimitservices.getambassador.io 2019-07-27T11:40:58Z
tcpmappings.getambassador.io 2019-07-27T11:40:58Z
tlscontexts.getambassador.io 2019-07-27T11:40:58Z
tracingservices.getambassador.io 2019-07-27T11:40:58Z
Copy the codeMapping is the core resource used for forwarding routes. The following is an example of mapping resource configuration
apiVersion: v1
items:
- apiVersion: getambassador.io/v1
kind: Mapping
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"getambassador.io/v1"."kind":"Mapping"."metadata": {"annotations": {},"name":"nginx"."namespace":"default"},"spec": {"prefix":"/nginx"."service":"nginx:80"}}
creationTimestamp: "2019-07-27T13:36:38Z"
generation: 1
name: nginx
namespace: default
resourceVersion: "420594"
selfLink: /apis/getambassador.io/v1/namespaces/default/mappings/nginx
uid: 8f1f4d33-b073-11e9-be4c-0800279f163b
spec:
prefix: /nginx
service: nginx:80
kind: List
metadata:
resourceVersion: ""
selfLink: ""
Copy the codeOnce you modify the annotation Settings in the Service, the Ambassador control side will automatically send the changes to Envoy without interrupting the service. (Thanks also to Envoy’s powerful xDS API)
Let’s take a look at a few uses of Ambassador:
Use cases
Use case 1: Edge (South/north) routing
This is the most common usage scenario. The gateway is located at the entrance of the entire cluster to perform flow control and authentication in a unified manner.
- Ability to control/route incoming traffic
- Uninstall request
- Authentication (e.g., requiring all incoming traffic to be authenticated)
- Encryption (TLS terminal and transport encryption)
- Retry and timeout
Real use cases in saas Services:
Use case 2: Internal (South/north) routing
Typically, an enterprise’s internal system architecture is complex, with multiple clusters or tenants, such as a cluster of Kubernetes and a cluster of VMS (perhaps openstack), so the traffic between clusters is internal south/north traffic, and traffic interaction between clusters can be done through Ambassador.
- Ability to control/route multi-tenant traffic
- Uninstall request
- Matching (based on headers)
- Retry and timeout
Real use cases in saas Services:
Use case 3: Internal (east/west) routing
In this scenario, the Ambassador already acts as a proxy for east-west traffic within the cluster, with its own control plane, which is kind of like a Service mesh. The difference is that Ambassador is a central node in the cluster (one or a group of Ambassador instances) under the server proxy category, rather than the Client Proxy (Sidecar) in the Service mesh. This architecture is actually much closer to a traditional ESB.
- Ability to control/route arbitrary traffic (north/south + East/West)
- Uninstall request
- Service discovery
- Load balancing
- Access control
As you can see, it’s already very close to the service Mesh capability (maybe ambassador will ship a Service Mesh product in the future?).
Real world use cases for saas Services:
Use case 4: Traffic mirroring
In this scenario, traffic can be copied to other services (shadow traffic), which is usually used in monitoring and testing scenarios
- Ability to test code and distribute packages
- Use real traffic/load
- Minimize duplicate resources
Note: The typical scenarios described above can be used not just with Ambassador, but with any type of API Gateway or proxy.
configuration
Configuration changes between versions of Ambassador are shown below. Configmap was an early and now obsolete mode, and CRD is now preferred.
Encryption configuration mode
Authentication configuration mode
Route configuration mode
Configuration mode for tracing
The shortage of the Ambassador
Ambassador is similar to similar gateway products, with both community and business versions. The Community version provides basic routing, speed limiting, TLS encryption, tracking, and authentication (you need to implement your own External Third Party Authentication service). But the very important OAuth2 integration authentication, RBAC, Custom Filter and other functions in the micro service gateway need to be realized in the Pro version, which is a pity. In particular, Custom Filter, according to our current experience, a complete capability, rich function of the micro service gateway, will inevitably introduce Custom Filter. Custom Filters also need to be written using Golang, which can be painful for developers who are not familiar with Golang.
conclusion
Ambassador is a relatively new open source microservices gateway product that blends well with Kubernetes, and its annotation – or CRD-based configuration is so integrated into the K8S that it feels like it’s part of the K8S itself. Truly kubernetes Native. The underlying traffic proxy, based on Envoy, is also less of a performance concern. This parameter can be used in routing, encryption, basic authentication, and link tracing scenarios. For users with requirements in scenarios such as Custom Filter, RBAC, and Advanced Rate Limiting, the Pro version can meet the requirements. I have also been in touch with the Ambassador development team. Unfortunately, Ambassador does not have Reseller in China at present. If using The Pro version, the convenience of later technical support also needs to be considered.
reference
- www.getambassador.io
- Using Ambassador to build Cloud-Native Applications – Steve Flanders, Omnition @ KubeCon 2019, Shanghai
Author: Lu Peier
Original: www.servicemesher.com/blog/cloud-…
Service Mesh Meetup #6 Guangzhou Station
-
Time: 2019-08-11 (Sunday) 9:00-12:30
-
Location: Zhongguancun + Silicon Valley, 15F tower B, Guangdian Pingyun, Tianhe District, Guangzhou, Guangdong
-
Registration address: www.huodongxing.com/event/55028…
Event details
09:00-09:15 sign in
09:15-10:00 Practice of Huya Live In Micro-service Transformation Zhang Bo Middleware team leader of Huya Basic Security Department
The transformation practice of tigress registry name Service and the integration with Istio helped smooth the transition from microservice to Service Mesh.
“Production-level Security Practice of Service Mesh in Ant Financial” Peng Zewen, Senior development engineer of Ant Financial
This paper introduces the landing scheme of Sidecar certificate management through Envoy SDS (Secret Discovery Service). Share how to build sensitive information data delivery channels for trusted identity services and how to implement TLS production level implementation for Service Mesh Sidecar.
10:50-11:35 micro-service Practice based on Kubernetes, Tu Xiaogang, Operation and maintenance Manager of Huizhe Network
This section describes how to develop a containerization solution based on the existing service environment, import services into the K8S platform, and communicate with the original service environment. Formulate access specifications, configure the center to connect with K8S service, network interworking scheme, DNS interworking scheme, Jenkins-pipeline pipeline construction scheme, log collection scheme, monitoring scheme, etc.
11:35-12:20 Development Trend of Service Mesh: Where is the Way to The Middle Game? Ao Xiaojian, Senior technical expert of Ant Financial
Continue the discussion of Service Mesh development trends: An in-depth analysis of Istio’s major innovations, Mixer V2, Envoy support for Web Assembly, and expedient solutions before Mixer V2 came out; An in-depth look at the innovative ways in which Google Traffic Director supports virtual machine mode and the recent stories surrounding SMI.
About the Service Mesh
Service Mesh is an infrastructure layer dedicated to communication between services. It is responsible for reliably delivering requests within the complex service topology of modern cloud native applications. In fact, a Service Mesh is typically implemented through a set of lightweight Sidecar proxies deployed with application code without being aware of the application itself.
About Service Mesh Meetup
ServiceMesh Meetup is sponsored by Ant Financial and hosted by the ServiceMesher community. It is a recurring technology salon around containers, Kubernetes, ServiceMesh and cloud native topics around the country.
About ServiceMesher community
The ServiceMesher community was launched in April 2018 by a group of volunteers who share the same values and ideals. Community website: www.servicemesher.com
Community focus areas: container, microservice, Service Mesh, Serverless, embrace open source and cloud native, dedicated to promoting the vigorous development of Service Mesh in China.
The community’s mission
Disseminate Service Mesh technology, build open source culture, strengthen industry communication, and promote Service Mesh to be implemented in enterprises.
Community vision
Be the evangelist and leader of Service Mesh in China.