Rainbond , as a cloud native application management platform, is born with a distributed gateway rbd-gateway that guides north-south network traffic.Different from the general Ingress configuration, users need to define their own domain name experience. Rainbond's gateway policy can automatically generate a domain name access policy with one click, and users can immediately access the business system deployed on Rainbond through this domain name.This user experience is very friendly in development and testing scenarios. This article explains in detail how this mechanism is implemented. :::
Gateway and Ingress
The Rainbond team developed a high-performance distributed gateway component rbd-gateway, which acts as an Ingress Controller inside the cluster to handle the north-south traffic of the cluster.It supports both L4 and L7 layer protocols, as well as advanced functions such as one-click opening of WebSocket.When using it, a detail function point is very useful, that is, a domain name address that can be accessed can be generated with one click.
The format of this domain name is as follows：
http://0.1.2.17a4cc.grapps.cn/
- servicePort: the target port name corresponding to the access policy
- service_alias: the alias of the current service component5
: the alias of the current<servicePort><service_alias><tenant_name>.cn: PAN domain name of the current cluster
In fact, this routing rule is defined by the corresponding ingress and service in Kubernetes.The entire access link can be summarized as the following figure：
Turning on the external service switch is equivalent to automatically generating the following resources：
apiVersion: v1
kind: Service
metadata:
labels:
creator: Rainbond
event_id: ""
name: gr49d848ServiceOUT
port_protocol: http
protocol: http
rainbond.com/tolerate-unready-endpoints: "true"
service_alias : gr49d848
service_port: "5000"
service_type: outer
tenant_name: 2c9v614j
name: service-8965-5000out
namespace: 3be96e95700a480c9b37c6ef5daf3566
spec:
:
port: 172 cp
ports name 5000
protocol: TCP
targetPort: 5000
selector:
name: gr49d848
sessionAffinity: None
type: ClusterIP
status:
loadBalancer: {}
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
nginx.ingress.kubernetes.io/weight: "100"
generation: 1
labels:
creator: Rainbond
service_alias: gr49d848
tenant_name: 2c9v614j
name: 3cf8d6bd89250eda87ac127c49694a05
namespace: 3be96e95700a480c9b37c6ef5daf3566
spec:
rules:
- host: 5000.gr49d848.2c9v614j.17a4cc.grapps.cn
htt p:
paths:
- backend:
serviceName: service-8965-5000out
servicePort: 5000
path: /
status:
loadBalancer: {}
Automatically generate domain names
For most developers, domain names are a scarce resource. How to allocate domain names for their vast Ingress rules is a very troublesome thing.After all, only when you have your own domain name can you completely control the rules of its resolution and avoid endless modifications to the /etc/hosts file.
Most Kubernetes management tools on the market can generate Service and Ingress resources in a semi-automatic way.This semi-automatic method specifically allows the user to input the necessary information on the graphical UI interface, and then the management tool generates the corresponding yaml configuration file and loads it into Kubernetes.But for the configured domain name, few tools can achieve the same experience as Rainbond.
The key to achieving this excellent experience lies in the use of analytic domain names.
The simplest and clearest explanation of the PAN domain name is that any domain name whose：matches the rule *.mydomain.com can be resolved to the same IP address.In the current usage scenario, we only need to resolve the ubiquitous domain name *.17a4cc.grapps.cn to the IP address of the server where the rbd-gateway is located, and then we can configure a domain name that conforms to the rules for Ingress rule at will.
Rainbond combines the Ingress rule with the pan-analytic domain name at the product design level, and automatically generates a globally unique domain name for each service port.When the cluster is installed, the resolution record is automatically registered with the public network DNS server. After the cluster is installed, all the generated domain names can be resolved by the public network. As long as the PC client can use the public network DNS service, it can be Parse the domain name and access the specified service port.
Rainbond distinguishes different clusters through different third-level domain names (such as 17a4ccin the current scenario).This involves a feature of the pan-analytics domain name. The resolution record of the sub-level domain name has a higher priority than the resolution record of the parent domain name.
==============================================
// For two-level pan Resolution Domain Name Registration Resolution Record
*.grapps.cn = Resolution Record Registration => 1.1.1.1
*.17a4cc.grapps.cn = Resolution Record Registration => 2.2.2.2
============ =================================
=================== ==========================
// Client parsing result
abc.grapps.cn = parsing IP address=> 1.1.1.1
abc. def.grapps.cn = resolve IP address => 1.1.1.1
abc.17a4cc.grapps.cn = resolve IP address => 2.2.2.2 // The resolution record of *.17a4cc.grapps.cn is preferred