Five-minute K8S practice - using Ingress

background

Technology, life, opinions, originality. Original public account; mainly focusing on Go, JVM, concurrency, distribution, network and other related technologies.

In the first two chapters, we deployed the application to k8s. At the same time, different services can also be called through service. Now there is another step to expose our application to the public network and provide domain name access.

This step is similar to our previous configuration of Nginx and binding domain name. The service that provides this capability is called Ingress in k8s.

From this description, we can actually see that Ingress is more of an operation and maintenance job, but it does not prevent us as developers from understanding this part of the content; understanding how the entire system works is also a skill that developers should master.

Install Ingress Controller

Before officially using Ingress, you need to install an Ingress controller for k8s. Here we install the official Ingress-nginx controller.

Of course, there are also various controllers provided by the community or enterprises:

picture

There are two ways to install: helm or directly apply a resource file.

We will explain helm separately in the following chapters.

Here you can just use the resource file to install it. I have uploaded it to GitHub and can access it here: https://github.com/crossoverJie/k8s-combat/blob/main/deployment/ingress-nginx.yaml

In fact, this file is also copied directly from the official one, and you can also install it directly using this path:

 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.2/deploy/static/provider/cloud/deploy.yaml

The contents of the yaml files are the same.

However, please note that after installation, the container status may remain in the Pending state. When viewing the container events, you will find that the image pull failed.

 k describe pod ingress-nginx-controller-7cdfb9988c-lbcst -n ingress-nginx

describe is a command used to view the details of a k8s object.

In the yaml file just now, you can see that there are several images that need to be pulled. We can first manually pull the images locally:

picture

 docker pull registry.k8s.io/ingress-nginx/controller:v1.8.2

If you still cannot pull, you can try to configure several domestic mirror sources to pull images:

picture

I use the k8s that comes with docker-desktop here, and I recommend readers to use this tool as well.

Create Ingress

After the installation is successful using the yaml just now, a Pod will be created in the ingress-nginx namespace. If the status is Running through the get command, the installation is successful.

 $ k get pod -n ingress-nginx NAME READY STATUS RESTARTS AGE ingress-nginx-controller-7cdf 1/1 Running 2 (35h ago) 3d

Namespace is also a built-in object of k8s. It can be simply understood as grouping management of resources. We can usually use it to distinguish different environments, such as dev/test/prod, etc. Resources under different namespaces will not interfere with each other and are independent of each other.

After that, you can create the Ingress resource:

 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: k8s-combat-ingress spec: ingressClassName: nginx rules: - host: www.service1.io http: paths: - backend: service: name: k8s-combat-service port: number: 8081 path: / pathType: Prefix - host: www.service2.io http: paths: - backend: service: name: k8s-combat-service-2 port: number: 8081 path: / pathType: Prefix

It is easy to understand this content. An Ingress object is created, and the key point is how the rules are defined here.

In k8s, you will come into contact with various Kinds in the future.

The ingressClassName: nginx here is also the name defined in the controller that was just installed, defined by this resource.

 apiVersion: networking.k8s.io/v1 kind: IngressClass metadata: labels: app.kubernetes.io/component: controller app.kubernetes.io/instance: ingress-nginx app.kubernetes.io/name: ingress-nginx app.kubernetes.io/part-of: ingress-nginx app.kubernetes.io/version: 1.8.2 name: nginx

Our rule is very simple, which is to route two different domain names to two different services.

For the convenience of testing, a k8s-combat-service-2 service is created here, which is the same as k8s-combat-service, except that the name is changed.

test

Also to facilitate testing, I added a new interface in the application image to return the hostname of the current Pod.

 http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { name, _ := os.Hostname() fmt.Fprint(w, name) })

Since I don’t actually have the two domain names www.service1.io/www.service2.io, I can only configure the host locally for simulation.

 10.0.0.37 www.service1.io 10.0.0.37 www.service2.io

The k8s I used for testing was deployed on a restricted Mac at home, so here is its IP address.

When we repeatedly request this interface twice, we will get two different hostnames, which means that our request is loaded in a round-robin manner on the two Pods proxied by these two services.

 ❯ curl http://www.service1.io/ k8s-combat-service-79c5579587-b6nlj% ❯ curl http://www.service1.io/ k8s-combat-service-79c5579587-bk7nw% ❯ curl http://www.service2.io/ k8s-combat-service-2-7bbf56b4d9-dkj9b% ❯ curl http://www.service2.io/ k8s-combat-service-2-7bbf56b4d9-t5l4g

We can also use describe directly to view our ingress definition and routing rules:

picture

 $ k describe ingress k8s-combat-ingress Name: k8s-combat-ingress Labels: <none> Namespace: default Address: localhost Ingress Class: nginx Default backend: <default> Rules: Host Path Backends ---- ---- -------- www.service1.io / k8s-combat-service:8081 (10.1.0.65:8081,10.1.0.67:8081) www.service2.io / k8s-combat-service-2:8081 (10.1.0.63:8081,10.1.0.64:8081) Annotations: <none> Events: <none>

If we manually add a new domain name resolution:

 10.0.0.37 www.service3.io ❯ curl http://www.service3.io/ <html> <head><title>404 Not Found</title></head> <body> <center><h1>404 Not Found</h1></center> <hr><center>nginx</center> </body> </html>

It will directly return 404 because no rules for this domain name were found.

Access Principle

picture

The entire request path is shown in the figure above. In fact, our Ingress is essentially a service (so it can also start multiple copies to carry out load), but its type is LoadBalancer. Usually this type of service will be bound to an external IP by the cloud vendor, so that the Ingress can be accessed through this external IP.

The service of our application is ClusterIP, which can only be accessed within the application.

picture

From the service information, we can also see that the external IP bound to our ingress service is localhost (local reason).

Summarize

Ingress usually acts as a gateway. Later, when we use Istio, we can also use the controller provided by Istio to replace Ingress-nginx, which can more conveniently manage internal and external network traffic.

All source code of this article can be accessed here: https://github.com/crossoverJie/k8s-combat