Ingress
最后更新于
最后更新于
This article will help you make sense of terms common to Kubernetes that you may often encounter used interchangeably elsewhere, in order to prevent confusion.
Node: a server in a Kubernetes cluster;
Cluster: a group of servers managed by Kubernetes;
Edge router: a router that routes data packets between a local area network and the internet, with the additional function as a firewall protecting the local network;
Cluster network: a specific implementation of networking that adheres to Kubernetes' networking model, for example, flannel and OVS;
Service: A Kubernetes service is a group of pods identified by label selectors Service. Unless stated otherwise, the virtual IP of a service is only accessible within the cluster.
Typically, service and pod IP addresses are only accessible within the cluster. External requests must be routed via a load balancer that directs them to a NodePort exposed on a node, which is then handled by the kube-proxy via an edge router. This process either forwards the requests to the relevant pod or discards them, like the illustration below.
Ingress is simply a set of rules that help route requests entering the cluster, as shown in the following figure.
Ingress offers load balancing, public URLs, SSL termination, and HTTP routing for services outside the cluster. To set these Ingress rules, a cluster administrator needs to deploy an Ingress controller. The controller listens for changes in Ingress and services, and based on the rules, it configures load balancing and makes the necessary access provisions.
Each Ingress rule needs to be configured. At present, Kubernetes only supports HTTP rules. The above example shows that when a request is made to '/testpath', it gets routed to the service 'test' on port 80.
Based on the configuration of the Ingress Spec, Ingress can be divided into the following types:
Single-service Ingress refers to an Ingress that only points to one backend service without any rules.
Note: A single service can be exposed externally by setting
Service.Type=NodePort
orService.Type=LoadBalancer
.
Routing-to-multi-service Ingress refers to different backend services being routed according to the request path.
The following Ingress defines the above:
After creating the ingress with kubectl create -f
:
Virtual host Ingress refers to different backend services being routed based on different names but sharing the same IP address.
The following Ingress routes a request based on the Host Header :
Note: A backend service that has no default rule definition is called the default backend service, which can easily handle 404 pages.
TLS Ingress obtains TLS private keys and certificates (named 'tls.crt' and 'tls.key') via Secret to perform TLS termination. If the TLS configuration part of Ingress specifies different hosts, these hosts will be reused on multiple same ports based on the host name specified by the SNI TLS extension—if the Ingress controller supports SNI.
Define a secret containing 'tls.crt' and 'tls.key':
The secret is referenced in Ingress:
Take note, different Ingress controllers support different TLS functionalities. Please refer to the documentation on nginx, GCE or any other Ingress controller to learn about their TLS support.
You can update Ingress with the kubectl edit ing name
command:
This opens an editor containing the existing IngressSpec yaml file. After editing and saving, it updates the Kubernetes API server, triggering the Ingress Controller to reconfigure load balancing:
After the update:
Of course, you can also update it with the kubectl replace -f new-ingress.yaml
command, where new-ingress.yaml is the modified Ingress yaml.
The normal operation of Ingress requires the running of an Ingress Controller in the cluster. The Ingress Controller is different from other controllers that automatically start when the cluster is created as part of kube-controller-manager—it requires users to choose an Ingress Controller that suits their cluster, or implement one themselves.
Ingress Controller is deployed as a Kubernetes Pod and runs as a daemon, constantly watching the /ingress interface of Apiserver to update Ingress resources to meet Ingress requests. For example, you can use the Nginx Ingress Controller:
Other Ingress Controllers available:
traefik ingress gives a practical example of a Traefik Ingress Controller
kubernetes/ingress-nginx provides a detailed example of an Nginx Ingress Controller
kubernetes/ingress-gce provides an example of an Ingress Controller for GCE
Before Ingress Class, to choose a specific Controller for Ingress required adding a special annotation (like kubernetes.io/ingress.class: nginx). But with IngressClass, cluster administrators can pre-create supported Ingress types, which can then be referenced directly in Ingress.
Kubernetes Version | Extension Version |
---|---|
v1.5-v1.17
extensions/v1beta1
v1.8-v1.18
networking.k8s.io/v1beta1
v1.19+
networking.k8s.io/v1