Kubernetes ingress is usually used to expose services in the form of L7 loadbalance, which will not be repeated here
Here is just to describe some neglected problems of ingress itself as clearly as possible
Ingress is one of the standard resource types of kubernetes API. It is actually a set of rules that forward requests to specified service resources based on DNS name (host) or URL path
The implementation of ingress is divided into two parts: ingress controller and ingress
Ingress controller is the entrance of traffic. It is an entity software, generally nginx and haproxy.
Ingress describes specific routing rules.
Because the content is messy, it is divided into several specific real cases to discuss
K3s
Recently, I tried k3s. The default implementation of k3s (no need to install rancher, bare k3s) is not nginx ingress, but traefik
After installing the cluster, I encountered a very strange problem. In the past, when using kubernetes, as long as an ingress rule is added, DNS can access this deployment as long as it points to any node, but only one node can access it normally in k3s, for example
- 192.168.204.165
- 192.168.204.166
- 192.168.204.167
- 192.168.204.168
Only 192.168.204.168 can access ingress
Checking the ingress nginx controller, it is found that rke2 does not use the daemon set to deploy the controller like rke1, but inexplicably uses ordinary deployment, which leads to that only 168 deployed with ingress controller can receive requests normally
Rke1 is much better, because it is a daemonset, so every node can work normally
Here, we manually change the deployment quantity to 4, and the controller is successfully distributed on 4 nodes
In this case, any node can receive the request normally
Address shows all addresses
