Route service grid traffic through two-level gateway design

Editor's words

This article is from my company  Tetrate^[1]  The engineer Petr McAllister The share of ,Tetrate Our flagship product is  Tetrate Service Bridge^[2]（ Hereinafter referred to as" TSB）, It is open source Istio and Envoy Based on , But it adds a management plane .

brief introduction

Tetrate Application connection platform Tetrate Service Bridge（TSB） There are two types of gateways , They are primary gateways （Tier-1） And secondary gateway （Tier-2）, They are all based on Envoy structure , But the purpose is different . This article will discuss the functions of these two types of gateways , And when to choose which gateway .

A brief introduction to the two-level gateway ：

• •  Primary gateway （ Hereinafter referred to as" T1） At the edge of the application , For multi cluster environments . The same application will be hosted on different clusters at the same time ,T1 The gateway routes the request traffic of the application between these clusters .

• •  Secondary gateway （ Hereinafter referred to as" T2） At the edge of a cluster , It is used to route traffic to services managed by the service grid in the cluster .

Definition of two-level gateway

Hosted in TSB Design and open source of application deployment in managed cluster Istio The model is very similar . They have the same structure , Use an entry gateway to route incoming traffic .T2 Gateway is equivalent to Istio Gateway to （Ingress Gateway）, Logically with Istio The open source model is the same , Pictured 1 Shown .

chart 1：Istio Gateway comparison Tetrate T2 gateway

Tetrate Service Bridge Use Istio and Envoy The control plane and data plane of the built service grid management cluster , It does not exist in the application data path itself . Open source Istio Managed clusters and TSB Managed packet paths between clusters , You will find no difference between the two .TSB Configuration list for （manifest） By Istio Consumption and use . In this way ,TSB Is similar to CI/CD Automation logic , The deployment process will affect the behavior of the application , But it will not affect the application logic itself .

TSB Open source Istio Has added some components , To manage the installation and configuration of each group of application gateway scope , To speed up the work progress of development and operation and maintenance personnel , Separate responsibilities between infrastructure and Applications , Compare the impact of misconfigured gateways with other applications / Business group isolation .

When to use T1 gateway ？

When you have two or more Kubernetes When the cluster serves the same application , To increase capacity 、 Blue and green deployment 、 Failover, etc , Problems always arise ： How inbound traffic is distributed among these clusters ？ At the edge of each cluster T2 Gateways allow direct access to applications —— for example , colony A Will monitor  service1A.example.com, colony X Will monitor  service1X.example.com. In turn, ,T2 The gateway provides global load balancing across clusters . The traffic routing allocation across clusters is based on 1 To 100 The weight value between , Specify the percentage of traffic sent to a specific cluster .

Here's a simple one T1 Example of gateway configuration . This example shows a complete T1 Gateway list , To prove the simplicity of the solution . Details about specific settings , Please refer to  Tetrate API file  ^[3].

apiVersion: gateway.tsb.tetrate.io/v2
kind: Tier1Gateway
metadata:
  name: service1-tier1
  group: demo-gw-group
  organization: demo-org
  tenant: demo-tenant
  workspace: demo-ws
spec:
  workloadSelector:
    namespace: service1-tier1
    labels:
      app: tsb-gateway-service1-tier1
      istio: ingressgateway
  externalServers:
  - name: service1
    hostname: service1.cx.example.com
    port: 80
    tls: {}
    clusters:
    - name: site-1-gcp
      weight: 75
    - name: site-2-aws
      weight: 25

In this case , To  service1.cx.example.com  Of 75% User requests are forwarded to GCP Medium  site-1, The rest are forwarded to AWS Medium  site-2. The traffic in this example reaches the plaintext port 80, after T1 All communication between the gateway and the application cluster goes through mTLS encryption .

chart 2：T1 and T2 Gateway network path diagram

Cloud supply gateway integration

Istio Users usually implement the entry gateway according to the application model . This method ensures the security of an application and its artifacts 、 Independent management .

The most common pain points noted here —— Every application needs to use the load balancer of the cloud provider . This makes the user need to maintain the location Envoy Entrance gateway Pod Before a large number of load balancers , This brings capital overhead and management costs .

TSB Allowed to pass through NodePort Service type instead of LoadBalancer Service discovery and communication , This means that the load balancer of the cloud provider is no longer needed ;TSB Services in the cluster can be accessed through NodePort Directly to .T1 The gateway allows us to compress the use of cloud provider load balancers to a single entry point .

chart 3： Cloud provider gateway integration

chart 3 Shows how to transfer service connections in the cluster to TSB, Instead of using the load balancer of the cloud provider to simplify cloud settings . In the absence of TSB Under the circumstances , To achieve the above settings , Need to use an external load balancer .TSB Also maintenance Kubernetes List of nodes .

Resource requirements

Just T2 In terms of the resources required by the gateway , Open source Istio and TSB There is no difference in the requirements of . in fact , The implementation is the same —— Gateway and VirtualService Lists can be created manually , It can also be created through open source automation tools . stay Tetrate In the use case of ,TSB by Istio Create manifest .

T1 The gateway really needs a special control plane , This means that grid management applications and T1 The gateway cannot run in the same cluster , Although bearing T1 The gateway Kubernetes Clusters can also host applications outside the service grid . however ,Tetrate Some of our customers will T1 The gateway is placed with TSB On a cluster with the same management plane .

Architectural considerations

With the development and maturity of the application environment , It is common for new requirements to appear .T1 The gateway can be planned and implemented as part of the initial service grid architecture implementation , You can also add later . Adding a primary gateway only affects the inbound traffic at the entry point , But there is no need to make any changes to the existing cluster .

chart 4 Show a no T1 Deployment configuration of gateway .

chart 4： No, T1 Deployment configuration of gateway

When introducing T1 Gateway time （ chart 5）, Must update DNS Record to point to the primary gateway , There is no need to modify the settings of the application cluster .

chart 5： Multi cluster deployment instance with primary gateway

Be careful ：TSB No DNS Management tools ,DNS The recorded changes were made in TSB In addition to （ There are a variety of automation tools and technologies available for this operation ).

However , Adding T2 Gateway time , From using LoadBalancer Switch to NodePort framework , It really needs to make slight changes to the application cluster .

although T1 The gateway acts as the front end of the incoming traffic at the application edge , But it can be deployed in a high availability configuration （ chart 6）.

chart 6： In high availability configuration T1 gateway

In terms of high availability , have access to T1 There is no limit to the number of gateways . This flexible architecture allows users to build powerful designs to meet a wide range of requirements .

summary

This article covers the design of service grid architects in the enterprise environment TSB The most common architecture problems during deployment . The following are the most important gains ：

• • TSB T1 and T2 Gateway use Istio Entrance gateway Pod And the service . There are no additional proprietary components introduced here .

• • TSB Support the open source Istio Gateway mode in . Just a change in name , Such as TSB The gateway is called T2 gateway .

• •  A single gateway can be used for all applications , The gateway mode divided by application can also be adopted .

• • TSB By using Kubernetes NodePort instead of LoadBalancer Communicate within the cluster , Reduce the number of cloud vendor load balancers used , So as to reduce the cost of Cloud Computing .

• • TSB T1 The gateway provides cross cluster load balancing .

• •  Since cross cluster load balancing may not be required in the early stages of implementation , therefore T1 The gateway does not need to be part of the initial deployment , You can add later , No significant impact on existing applications .

• •  Multiple T1 The gateway can be deployed in front of the same application , To achieve high availability .

Reference link

[1] Tetrate: https://tetrate.io/
[2] Tetrate Service Bridge: https://tetrate.io/tetrate-service-bridge
[3] Tetrate API file : https://docs.tetrate.io/service-bridge/1.4.x/en-us/refs/tsb/gateway/v2/tier1_gateway#tier1gateway

Get more information about cloud native communities , Join wechat group , please Join the cloud native community , Click to read the original to learn more .