Expose your App: Creating a Service and Ingress

Expose your App: Creating a Service and Ingress

In each project, namely, Kubernetes namespace, KubeSphere has pre-installed a load balancer which is Nginx Ingress Controller. You need to activate it before using it. As we know, ingress and ingress controller are used to expose services outside. The website Kubernetes-ingress provides an example showing how to use ingress. Let’s take a demo website https://cafe.example.com as an example. If users access the URL https://cafe.example.com/coffee, it will return “Coffee Ordering System”. Similarly, when access the URL https://cafe.example.com/tea, it will return “Tea Ordering System”.

To elaborate this demo, we will create two stateless applications which include Deployments, Services and Ingress in this tutorial.

Prerequisites

You have completed all steps in Getting Started with Multi-tenant Management including enabling gateway.

Estimated Time

About 20 minutes

Hands-on Lab

Step 1: Create a Tea Service

In this section, we will create a “Tea Ordering System” service as the following.

1.1. Sign in with project-regular, then enter demo-project. Choose Application Workloads → Services and click Create Service.

1.2. Choose the type Stateless Service in Service Type, and name it tea-svc, click Next.

1.3. Click Add Container Image. Then fill in the Image with nginxdemos/hello:plain-text, press Enter button, click Use Default Ports and choose √, then click Next.

1.4. It is not required to mount volumes or configure advanced settings in this step. Just click Next to skip it, then click Create to complete tea-svc creation.

Step 2: Create a Coffee Service

2.1. Similarly, click Create button to create a “Coffee Ordering System” service.

2.2. Name it coffee-svc and click Next, click Add Container Image. Then fill in the Image with nginxdemos/hello:plain-text and press Enter button, click Use Default Ports and choose √. Other steps are the same as the creation of the service tea-svc.

Step 3: Create a TLS Certificate

Since the domain name bound in the route, namely, Ingress, is the HTTPS protocol, we need to create a secret to store the TLS certificate.

3.1. Choose Configuration Center → Secrets, then click Create.

3.2. Name it cafe-secret, click Next. Select the TLS from the Type dropdown menu, then copy and paste Credential and Private Key as follows, click Create when you have done.

Credential

Private Key

Step 4: Create a Cafe Ingress

Now we are ready to expose the two services with Ingress.

4.1. Choose Application Workloads → Routes, and click Create Route button.

4.2. Name it cafe-ingress, click Next → Add Route Rule.

4.3. Choose Specify Domain and fill in the table as follows:

HostName: cafe.example.com
Protocol: Choose https
Secret Name: Choose cafe-secret
Paths:
- Input /coffee, then choose coffee-svc as the backend service and select 80 as the port
- Click Add Path, input /tea, then choose tea-svc as the backend service and select 80 as the port

4.4. Click √ and Next after you have done, then click Create. We can see the cafe-ingress has been created successfully.

Step 5: Access the Application Ingress

So far, we have exposed two different applications via route and its rules. We can access the tea and coffee applications through different paths.

For example, when we visit https://cafe.example.com:{$HTTPS_PORT}/coffee, the back-end Pod of coffee-svc should respond to the request. We can switch to admin account to log in KubeSphere and open web kubectl from Toolbox at the bottom right corner.

As shown in the following demo, the Server name and Server address is corresponding to the Pod coffee-svc-yfhqwu-7b7bbf49f4-6c55l. Please note the resolve information of the curl command is from the screenshot above. You should replace it with your real information.

$ curl --resolve cafe.example.com:30000:192.168.0.54 https://cafe.example.com:30000/coffee --insecure
Server address: 10.233.90.5:80
Server name: coffee-svc-yfhqwu-7b7bbf49f4-6c55l
Date: 05/Jan/2020:10:01:48 +0000
URI: /coffee
Request ID: 6fb79c32e0b99653d2f226eef374e798

Similarly, when we visit https://cafe.example.com:{$HTTPS_PORT}/tea, the back-end Pod of tea-svc should respond to the request. As shown in the following demo, the Server name and Server address is corresponding to the Pod tea-svc-9fukgs-754cbc8b9b-rfhpr.

$ curl --resolve cafe.example.com:30000:192.168.0.54 https://cafe.example.com:30000/tea --insecure
Server address: 10.233.90.4:80
Server name: tea-svc-9fukgs-754cbc8b9b-rfhpr
Date: 05/Jan/2020:10:07:16 +0000
URI: /tea
Request ID: 2173c1565b368a5258368d15f55ca050

Conclusion

As we can see from the instructions above, it demonstrates that the route has successfully forwarded different requests to the corresponding back-end services, and the services redirect traffic to one of the corresponding service’s backend Pods.

2. Expose your App Using Ingress