Shulou(Shulou.com)06/01 Report--

All related links to this article pdf: https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case-2.pdf

The Ingress documentation page of Kubernetes describes it as:

"the API object used to manage external access to services in the cluster, usually HTTP. Ingress can provide load balancing, SSL termination, and name-based virtual hosts."

CNI does not provide Ingress functionality. This means that Kubernetes cluster managers typically install, manage, and support separate Ingress controller solutions for their clusters.

For Kubernetes deployments in local and public clouds without built-in Ingress support, Tungsten Fabric bundles its own Ingress controller. It uses HAProxy in the background and implements all the basic functions described in the Kubernetes Ingress document page.

When running on AWS, you can configure Kubernetes to use AWS's Application Load Balancer (ALB) as its Ingress service. By setting up in this way, the Kubernetes in the sandbox most closely reflects the typical real-world deployment scenario.

The following figure outlines the final deployment architecture of the sample application:

Working with scen

The Ingress controller option is only compatible with applications that use HTTP or HTTPS. If this is the case with your application, you may want to consider using Ingress to achieve the following goals:

Protect the application with HTTPS, then expose the program on the network by configuring Ingress for SSL offload; and / or direct incoming requests to different Kubernetes Services based on the HTTP path in the request, for example, / blog/ can go to Service A, / account/ can go to Service B, and so on. And / or through name-based virtual hosts, applications serve multiple DNS domains, such as Host: applications with headers set to test.project.com go to Service C, while those with prod.project.com go to Service D. Expose the sample application through Ingress

Before exploring the above three scenarios, let's deploy a simple Ingress sample application, similar to what we did with LoadBalancer, and then build on that.

Make sure you are on the sandbox control node, logged in as root, and in the correct directory:

# confirm that you are a root account

Whoami | grep root | | sudo-s

# switch to inventory directory

Cd / home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

# deploy a sample program with Ingress

Kubectl create-f cnawebapp-ingress-alb.yaml

After a few minutes, the deployment process should be complete, and we should be able to access the sample application from Internet. First find the DNS name of Ingress:

Based on the output above, our sample application can now be accessed from http://539db10e-default-yelbui-3c9c-1330819777.us-west-1.elb.amazonaws.com on Internet.

Access the Yelb using the DNS name obtained by running the above command in the environment to ensure that it is valid.

Use HTTPS to secure applications

For this exercise, we need to generate a self-signed certificate and add it to AWS Certificate Manager. AWS Application Load Balancer (ALB) that provides the Ingress feature needs to use this feature to perform encryption.

Note: for production purposes, it may be necessary to obtain the "appropriate" certificate for a fully registered domain name through the appropriate functions of AWS Certificate Manager. Since we are just practicing, we will use a self-signed fictitious domain.

Step 1: generate a self-signed certificate and add it to AWS Certificate Manager

Perform the following steps on the host where the AWS CLI tool with Access and Secret keys is installed. The key here allows you to make changes to Certificate Manager.

# generate a self-signed certificate for a fictional domain name (yelb.mydomain.com):

Openssl req-x509-nodes-days 365-newkey rsa:2048-keyout tls.key-out tls.crt-subj "/ CN=yelb.mydomain.com"

# add a new certificate to AWS Certificate Manager

# Note "--region"-this must be the same AWS area

# in our example, when running the Tungsten sandbox, it is "us-west-1"

Aws acm import-certificate-certificate file://tls.crt-private-key file://tls.key-region us-west-1

If all goes well, the last command displays something similar:

{

"CertificateArn": "arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46"

}

We will need the value after CertificateArn to proceed to the next step.

Step 2: establish the Ingress definition

Make sure you are on the sandbox control node, logged in as root, and in the correct directory:

# make sure you are root

Whoami | grep root | | sudo-s

# switch to inventory directory

Cd / home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml

Now, let's create a new Ingress definition:

Next, we put CertificateArn in. Edit the command before running it, and replace the command CertificateArn with the value of arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46 obtained from step 1.

Sed-i "s#INSERT_CERT_ARN_HERE#arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46#" ingress-https.yaml

If the command runs successfully, the ingress-https.yaml file will have the ARN of the self-signed certificate instead of the string INSERT_CERT_ARN_HERE.

Step 3: set up HTTPS Ingress and test it

# create a new Ingress

Kubectl create-f ingress-https.yaml

After running the above command, wait a few minutes for the new ALB Ingress to appear. Then, let's find the DNS name that has been assigned to it and try to connect to it:

From the output above, we can see the address of the new Ingress; let's see if it works:

This means it works-- we can access Yelb applications through encrypted connections!

The new topology looks like this (note that we still have the original HTTP Ingress that is not shown in this figure):

Conclusion: why do you want to do this?

In addition to increasing end-user connection security, privacy, and data integrity, implementing HTTPS Ingress has some benefits:

Applications consume less computing resources because encryption overhead has been transferred to ALB; applications that now support HTTP / 2, which is a good thing; the ability to automatically redirect HTTP to HTTPS can be easily implemented. Clear

Let's remove the added HTTPS Ingress because we no longer need it in the rest of this chapter:

Kubectl delete-f ingress-https.yaml

Then, on the computer that performed step 1 (generate and install the self-signed certificate into AWS Certificate Manager), run the following command to delete the certificate and ensure that you use your own value, CertificateArn:

Aws acm delete-certificate-certificate-arn arn:aws:acm:us-west-1:180612498884:certificate/e7341ff5-52ef-4a7b-94b5-05643ef6ab46

Direct request based on URL path

In some cases, you may want to run multiple applications under the same DNS domain name. For example, www.corp.com may support your main application, while other applications such as WordPress may be dealing with www.corp.com/blog.

For this exercise, we assume that you followed the instructions to run a copy of Yelb at the beginning of the chapter "exposing the sample application through Ingress." If you are starting from scratch, skip to this section, follow the instructions to deploy, and then come back.

To demonstrate routing through the URL path, we will add another deployment to the environment and update the configuration of Ingress accordingly. Under this new configuration, Ingres will direct requests for / paths to our main application yelb, while path requests for / echo will be directed to the new application EchoServer.

This is a diagram of the target state:

We should have put the portion of Yelb in place, so we added EchoServer:

# create an EchoServer Deployment and Service list:

# deploy it now:

Kubectl create-f echoserver.yaml

Next, we will create an updated configuration for Ingress. To do this, we will copy the Ingress resource cnawebapp-ingress-alb.yaml from it and make two changes in the routing section:

Update the path of yelb from / * to / so as not to interfere with echoserver; and

Add a new / echo path to echoserver

Note: the reason we want to include a complete resource definition instead of just applying the differences is because the Ingress object does not support strategic merge patching.

# updated Ingress resources:

# deploy it now:

Kubectl apply-f ingress-paths.yaml

A warning about kubectl apply is displayed here, which can be ignored. Because our update resources are essentially the same as the rules configuration.

The updated configuration takes effect in a few seconds, after which we can check whether the URL-based routing is valid. When we request a basic URL / (or empty), we should reach Yelb, and if we request / echo, the output we should return is EchoServer.

# get the basic URL of Ingress

BaseUrl=$ (kubectl get ing yelb-ui | grep amaz | awk'{print $3}')

Echo "Our Ingress is at: ${baseUrl}"

# try to visit $baseUrl; you should be able to get the contents of the Yelb UI page

Curl http://${baseUrl}

# now try / echo; you should get the output of EchoServer

Curl http://${baseUrl}/echo

Service multiple DNS domain

The solution in this scenario is useful when you have multiple domain names and provide different applications for each domain, while wanting to share the same Ingress infrastructure. This helps save money and, in some cases, is less complex than having a dedicated Ingress instance for each domain name.

This exercise builds on the previous exercise based on URL directed requests. If not, review the previous steps and simply cut and paste the steps for creating and deploying the echoserver.yaml manifest. We will create a new one for Ingress, so there is no need to create and deploy ingress-paths.yaml.

When you are ready, you should already have a copy of yelb and a copy of echoserver. It doesn't matter what your Ingress configuration is, because we will overwrite it.

In our target state, Ingress will define two domain names, yelb.mydomain.com and echo.mydomain.com, and will route incoming requests based on the values in the Host:HTTP header, and the Web browser will automatically insert these requests for the host portion of your requested URL.

This is a diagram of the target state:

Let's create and deploy a configuration for Ingress that will perform the required routing:

# updated Ingress resources:

# deploy it now:

Kubectl apply-f ingress-hosts.yaml

After the configuration is successfully applied, we can test it. Because the domain name is mapped to the host, we will use curl to add the correct Host: header. When set to yelb.mydomain.com, Yelb should be reached, and when set to echo.mydomain.com, output EchoServer should be returned.

# Get the base URL of our Ingress

BaseUrl=$ (kubectl get ing yelb-ui | grep amaz | awk'{print $3}')

Echo "Our Ingress is at: ${baseUrl}"

# visit Ingress Host: set it to yelb; and we should be able to get the content of the Yelb UI page

Curl http://${baseUrl}-H "Host: yelb.mydomain.com"

# try to access Host on the spot: if set to echo;, we should be able to get the output of EchoServer

Curl http://${baseUrl}-H "Host: echo.mydomain.com"

Clear

Once you have done enough testing, please feel free to clean up:

# Delete "yelb" and "hoserver" applications:

Kubectl delete-f cnawebapp-ingress-alb.yaml

Kubectl delete-f echoserver.yaml

# Delete the additional list we created:

Rm-f echoserver.yaml ingress-paths.yaml ingress-hosts.yaml

Review and next step

Kubernetes provides three basic ways to expose applications to the outside world: LoadBalancer or NodePort service types and Ingress. The first two protocols support any protocol, but do not add much in terms of protocol intelligence. Ingress, on the other hand, provides protocol-based functionality, which makes it compatible only with HTTP or HTTPS applications.

Like other functions, Kubernetes needs a controller to implement the actual Ingress functionality-simply creating an Ingress resource in Kubernetes API does nothing. The Ingress controller is part of the software that the Kubernetes cluster administrator must install, monitor, patch, and upgrade. Tungsten Fabric comes with an Ingress controller, which makes this process easier.

Once you have determined how your application should be exposed to Internet, you need to consider how to deal with network access control. Read use case 3 and use case 4 in this guide, and we will introduce some of these scenarios.

(this official account will release the details of several use cases one after another. Please follow us.)

MORE

More TF+K8s articles

Part I: TF Carbide Evaluation Guide-preparation

Part 2: basic application connections through Kubernetes services

Follow Wechat: TF Chinese Community

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.