This article will specifically define the Route, its components, and how to use it in ArvanCloud Cloud Platform.
ArvanCloud Route Requirements
The only requirements to get started are ArvanCloud User Account and ArvanCloud PaaS service.
- Go to: arvancloud.ir, sign in to the account, or create a new one.
- Click on: Profile name > API Keys.
- Create a new API key, and save it.
ArvanCLoud CLI is needed for the steps above. Download the command line (place it in the PATH if necessary) and use the command below to login. Then add the created API key.
What is Route in PaaS?
The route is an essential part of ArvanCloud Cloud Platform, and it will make it possible for users to send requests to different pods from outside of the ArvanCloud PaaS.
Once the application is developed, the deployment and service are created, the requests need to be sent to pods from outside of the ArvanCloud Cloud Platform. The route will use the domain’s name, connecting the outside world to ArvanCloud Cloud Platform.
The route will only accept http and https requests. These requests will be sent to the route from the domain; then, the route will send them to specified services. It is possible to use TLS certification for the route to be able to manage the http traffic, eliminate the load from the application, and consume fewer resources.
How to Create a Route?
To create a route, enter the required data in a YAML file, and use the command line to add it to ArvanCloud Cloud Platform. The following example is an Nginx service route.
Tips: Indentation is important for YAML files. If ignored, unwanted settings and errors will occur.
Here is an explanation of the related fields:
- Kind: This will define the nature of the route. It can have values like Pod, Route, Service, and StatefulSet. In the example, the route is defined, and for that, the value is the route.
- Name: It will determine the Route’s name.
- Host: It shows the domain outside of ArvanCloud Cloud Platform, from which the requests will be sent to the route.
- To: It determines the modality to which the request will be sent. In this example, the requests will be sent to Nginx service.
- TLS: It contains the tls termination data.
- TLS.termination: This will specify the termination types. The allowed values of this field are passthrough, edge, and reencrypt. Later on, they will be explained.
- TLS.insecureEdgeTerminationPolicy: Here the unsecured traffic (http) is banned by default. If the spec.tls.insecureEdgeTerminationPolicy is specified as “Allow,” then the unsecured traffic will pass through the route. Other values of this field are none (http traffic is banned) and redirect (the http traffic redirected to https).
- Port.targetPort: Please note that a route can only send the traffic to a specific port defined in service. For that, the route will send the traffic to the port, which has been defined in a service beforehand. This field will help to determine sending the traffic to a specific port in a service.
Enter and save the fields mentioned above in an Nginx-route.yaml file. Then use a command-line based on the command below, and add the Route to ArvanCloud Cloud Platform.
The command below will display the route status on ArvanCloud Cloud Platform.
The output will be similar to this:
In the output above:
NAME: It defines the Route’s name.
PORT/HOST: It shows the Route’s domain.
PATH: It determines the path to which the traffic will be sent. (It will be discussed in future articles)
SERVICES: It determines the name of the service to which the traffic will be sent.
PORT: It specifies the service’s port to which the traffic will be sent.
TERMINATION: It determines the type of termination specified in the route.
(WILDCARD will be discussed in the next articles).
Route’s Domain Name
It has been said before that the route will use the domain’s name to connect to out-of-cluster pods. For now, it is only possible to use the ArvanCloud default domains. They are defined as below:
First, enter the intended name (e.g., app name), use a “-,” and add the project’s name. The project’s name is a must.
TLS Termination
The spec.tls.termination can be valued as edge, reencrypt, and passthrough. All are explained below.
Edge
Choose edge value if the ArvanCloud Cloud Platform default domain is used. This way, the ArvanCloud PaaS route’s tls will manage encrypted traffic. The traffic will be sent from route to pod in http. The https loads will be reduced, and fewer resources will be used.
If the ArvanCloud Cloud Platform Domain is being used, there is no need to add a certificate to the route. Users can use both the intended domain and edge termination. (Since the domain uses ArvanCloud CDN, no certification is needed). Generally, the certificate،ca certificate and private key should be added to the route. For instance:
Reencrypt
This will cause the tls termination in the route. Then the traffic will be encrypted again and sent to services and pods. The termination process happens for the second time by pods. The traffic will be encrypted in ArvanCloud Cloud Platform as well. In this case, the internal web server “ca certificate” (destination pod) must be added to the route. The rest of the values are the same as the edge. For instance:
Passthrough
Here the traffic will be sent first to services and then to pods. The route will not use any termination on the traffic. The traffic will be sent encrypted, and the application must decrypt the https traffic—the spec.tls.insecureEdgeTerminationPolicy value can only be none and redirect. Check out the example below.
To learn more about this subject, check out the OKD documents. This article is based on this reference:
- https://docs.okd.io/3.11/dev_guide/routes.html
- https://docs.okd.io/3.11/architecture/networking/routes.html