Shulou(Shulou.com)05/31 Report--

This article mainly analyzes how to analyze the relevant knowledge points of Kubernetes Ingress resource objects, the content is detailed and easy to understand, the operation details are reasonable, and has a certain reference value. If you are interested, you might as well follow the editor to have a look, and follow the editor to learn more about how to analyze Kubernetes Ingress resource objects.

Kubernetes Ingress is just a common resource object in Kubernetes, which needs a corresponding Ingress controller to parse the rules of Ingress, expose services such as ingress-nginx, which is essentially just a Nginx Pod, and then redirect requests to other internal (ClusterIP) services. This Pod itself is also exposed through Kubernetes services, and the most common way is through LoadBalancer. Also in this article, we want to use a simple and clear overview to let you understand what's behind Kubernetes Ingress and make it easier for you to understand the Ingress you use.

We can use Ingress to expose internal services to the outside of the cluster, which saves you valuable static IP because you don't need to declare multiple LoadBalancer services, and this time it can be configured for more. Let's use a simple example to illustrate Ingress.

Simple HTTP server

First of all, let's go back to the days before containers and Kubernetes.

Previously, we would use a (Nginx) HTTP server to host our service, which can receive a request for a specific file path through the HTTP protocol, then check the file path in the file system, and return it if it exists.

For example, in Nginx, we can do this through the following configuration.

Location / folder {

Root / var/www/

Index index.html

}

In addition to the functions mentioned above, when the HTTP server receives the request, we can redirect the request to another server (meaning it acts as a proxy), and then redirect the server's response to the client. For the client, nothing has changed, and the result received is still the requested file, if any.

Similarly, if you are in Nginx, the redirection can be configured as follows:

Location / folder {

Proxy_pass http://second-nginx-server:8000;

}

This means that Nginx can provide files from the file system or redirect responses to other servers through agents and return their responses.

A simple Kubernetes example uses a ClusterIP service

After deploying the application in Kubernetes, we should first learn about Kubernetes Service services (explained in the previous article). For example, we have two worker nodes, two service service-nginx and service-python, which point to different pods. These two services are not scheduled to any specific node, that is, it is possible on any node, as shown in the following figure:

Within the cluster, we can request to Nginx pods and Python pods through their Service services, and now we want these services to be accessible from outside the cluster. As mentioned earlier, we need to convert these services into LoadBalancer services.

Using LoadBalancer services

Of course, the premise of using LoadBalancer service is that the hosting service provider of our Kubernetes cluster can support it. If we support it, we can convert the above ClusterIP service into LoadBalancer service, create two external load balancers, redirect the request to our node IP, and then redirect the request to the internal ClusterIP service.

We can see that both LoadBalancers have their own IP, and if we send a request to LoadBalancer 22.33.44.55, it should be redirected to our internal service-nginx service. If the request is sent to 77.66.55.44, it will be redirected to our internal service-python service.

This is indeed very convenient, but you should know that IP addresses are relatively rare, and the price is not cheap. Imagine that there are not only two services in our Kubernetes cluster, but if there are many, the cost of creating LoadBalancers for these services will increase exponentially.

So is there another solution that allows us to forward requests to our internal services using only one LoadBalancer? Let's explore this problem manually (non-Kubernetes) first.

Manually configure the Nginx proxy service

We know that Nginx can be used as an agent, so it's easy to think of running a Nginx to proxy our service. As shown in the figure below, we have added a new service called service-nginx-proxy, which is actually our only LoadBalancer service. Service-nginx-proxy will still point to one or more Nginx-pod-endpoints (not identified on the diagram for simplicity), and the other two services have been converted to simple ClusterIP services.

You can see that we only assigned a load balancer with an IP address of 11.22.33.44, and we marked different http request paths in yellow. Their goals are the same, but they contain different request URL.

Service-nginx-proxy services decide which service they should redirect the request to based on the URL of the request.

In the figure above, we have two services behind, marked with red and blue, respectively. Red is redirected to the service-nginx service and blue is redirected to the service-python service. The corresponding Nginx agent configuration is as follows:

Location / folder {

Proxy_pass http://service-nginx:3001;

}

Location / other {

Proxy_pass http://service-python:3002;

}

It's just that at present, we need to manually configure the service-nginx-proxy service. For example, if we add a request path that needs to be routed to other services, we need to reconfigure the configuration of Nginx to make it take effect, but this is indeed a feasible solution, it's just a bit of trouble.

The purpose of Kubernetes Ingress is to make our configuration easier, smarter and easier to manage, so in the Kubernetes cluster we will use Ingress instead of the manual configuration above to expose the service outside the cluster.

Use Kubernetes Ingress

Now let's convert the above manual configuration of agents to Kubernetes Ingress. As shown in the following figure, we only use a preconfigured Nginx (Ingress), which has done all the agent redirection for us, which saves us a lot of manual configuration work.

This actually shows what Kubernetes Ingress is, so let's take a look at some configuration examples.

Install the Ingress controller

Ingress is only a resource object of Kubernetes, in which we can configure our service routing rules, but to really identify the Ingress and provide proxy routing function, we still need to install a corresponding controller.

Kubectl apply-f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml

Kubectl apply-f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/provider/cloud-generic.yaml

Using the following command, you can see the K8s resources installed in the namespace ingress-nginx.

We can see a normal LoadBalancer service with an external IP and a subordinate pod, and we can use the command kubectl exec to enter the pod, which contains a preconfigured Nginx server.

The nginx.conf file contains various agent redirection settings and other related configurations.

Ingress configuration example

The Ingress yaml example we use could look like this.

# just example, not tested

ApiVersion: networking.k8s.io/v1beta1

Kind: Ingress

Metadata:

Annotations:

Kubernetes.io/ingress.class: nginx

Namespace: default

Name: test-ingress

Spec:

Rules:

-http:

Paths:

-path: / folder

Backend:

ServiceName: service-nginx

ServicePort: 3001

-http:

Paths:

-path: / other

Backend:

ServiceName: service-python

ServicePort: 3002

As with other resource objects, you can create the resource object through kubectl create-f ingress.yaml. After creation, the Ingress object will be converted to the corresponding Nginx configuration by the Ingress controller installed above.

What if one of your internal services, the services to which Ingress should be redirected, is in a different namespace? Because the Ingress resources we define are namespace-level. In an Ingress configuration, you can only redirect to services of the same namespace.

If you define multiple Ingress yaml configurations, these configurations will be merged by a single Ingress controller into a single Nginx configuration. This means that all people are using the same LoadBalancer IP.

Configure Ingress Nginx

Sometimes we need to fine-tune the configuration of Ingress Nginx, which we can do through the annotations annotation in the Ingress resource object, for example, we can configure various configuration options that are usually directly in the Nginx.

Kind: Ingress

Metadata:

Name: ingress

Annotations:

Kubernetes.io/ingress.class: nginx

Nginx.ingress.kubernetes.io/proxy-connect-timeout: '30'

Nginx.ingress.kubernetes.io/proxy-send-timeout: '500'

Nginx.ingress.kubernetes.io/proxy-read-timeout: '500'

Nginx.ingress.kubernetes.io/send-timeout: 500

Nginx.ingress.kubernetes.io/enable-cors: "true"

Nginx.ingress.kubernetes.io/cors-allow-methods: "*"

Nginx.ingress.kubernetes.io/cors-allow-origin: "*"

...

You can also do more fine-grained rule configuration, as follows:

Nginx.ingress.kubernetes.io/configuration-snippet: |

If ($host = 'www.qikqiak.com') {

Rewrite ^ https://qikqiak.com$request_uri permanent

}

These comments will be converted to Nginx configurations, which you can check by manually connecting (kubectl exec) to nginx pod.

For more information on the configuration and use of ingress-nginx, please refer to the official documentation:

Https://github.com/kubernetes/ingress-nginx/tree/master/docs/user-guide/nginx-configurationhttps://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#lua-resty-waf View ingress-nginx Log

To troubleshoot problems, it is very helpful to view the logs of the Ingress controller.

Testing with Curl

If we want to test the Ingress redirection rules, we'd better use curl-v [yourhost.com] (http://yourhost.com) instead of the browser) to avoid problems such as caching.

Redirection rule

In the example in this article, we use paths such as / folder and / other/directory to redirect to different services, and we can also distinguish requests by hostname, such as redirecting api.myurl.com and site.myurl.com to different internal ClusterIP services.

ApiVersion: networking.k8s.io/v1beta1

Kind: Ingress

Metadata:

Name: simple-fanout-example

Spec:

Rules:

-host: api.myurl.com

Http:

Paths:

-path: / foo

Backend:

ServiceName: service1

ServicePort: 4200

-path: / bar

Backend:

ServiceName: service2

ServicePort: 8080

-host: website.myurl.com

Http:

Paths:

-path: /

Backend:

ServiceName: service3

ServicePort: 3333

SSL/HTTPS

Maybe we want the site to use a secure HTTPS service, and Kubernetes Ingress also provides a simple TLS check, which means it handles all SSL communications, decrypts / validates SSL requests, and then sends these decrypted requests to the internal service.

If your multiple internal services use the same (possibly wildcard) SSL certificate, so we only need to configure it once on Ingress, not on the internal service, Ingress can use the configured TLS Kubernetes Secret to configure the SSL certificate.

ApiVersion: networking.k8s.io/v1beta1

Kind: Ingress

Metadata:

Name: tls-example-ingress

Spec:

Tls:

-hosts:

-sslexample.foo.com

SecretName: testsecret-tls

Rules:

-host: sslexample.foo.com

Http:

Paths:

-path: /

Backend:

ServiceName: service1

ServicePort: 80

It is important to note, however, that if you have multiple Ingress resources in different namespaces, then your TLS secret needs to be available in all the namespaces of the Ingress resources you use.

This is the end of the introduction on "how to analyze Kubernetes Ingress resource objects". More related content can be searched for previous articles, hoping to help you answer questions and questions, please support the website!

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.