入口与负载平衡器 [英] Ingress vs Load Balancer
问题描述
对于Ingress和负载均衡器在Kubernetes中的作用，我感到很困惑.
据我了解，Ingress用于将来自Internet的传入流量映射到集群中运行的服务.
负载均衡器的作用是将流量转发到主机.在这方面，入口与负载均衡器有何不同?与Amazon ELB和ALB相比，kubernetes内的负载均衡器的概念又是什么?
负载均衡器: kubernetes LoadBalancer服务是指向不在Kubernetes群集中但存在的外部负载均衡器的服务别处.他们可以与您的Pod一起使用，前提是您的Pod在外部是可路由的. Google和AWS本机提供此功能.对于亚马逊而言，当在AWS中运行时，它可以直接映射到ELB和kubernetes，可以为部署的每个LoadBalancer服务自动配置和配置ELB实例.
入口:入口实际上只是一组要传递给正在侦听它们的控制器的规则.您可以部署一堆入口规则，但是除非您有可以处理它们的控制器，否则什么也不会发生.如果将LoadBalancer服务配置为侦听入口规则，则可以侦听入口规则.
您还可以创建 NodePort 服务，该服务在群集外部具有可外部路由的IP，但指向群集中存在的Pod.这可能是一个Ingress控制器.
入口控制器只是配置为解释入口规则的Pod. ngerx是kubernetes支持的最流行的入口控制器之一.就亚马逊而言，可以用作入口控制器. /p>
例如，此 nginx控制器能够提取入口您定义的规则并将其转换为nginx.conf文件，该文件会在其pod中加载并启动.
例如，假设您定义了一个入口，如下所示:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app
如果您随后检查nginx控制器容器，则会看到在/etc/nginx.conf中定义的以下规则:
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;
}
Nginx刚刚创建了一条规则，以路由http://kubernetes.foo.bar/app指向集群中的服务appsvc.
以下是示例，介绍了如何使用nginx入口实现kubernetes集群.控制器.希望这会有所帮助！
I am quite confused about the roles of Ingress and Load Balancer in Kubernetes.
As far as I understand Ingress is used to map incoming traffic from the internet to the services running in the cluster.
The role of load balancer is to forward traffic to a host. In that regard how does ingress differ from load balancer? Also what is the concept of load balancer inside kubernetes as compared to Amazon ELB and ALB?
Load Balancer: A kubernetes LoadBalancer service is a service that points to external load balancers that are NOT in your kubernetes cluster, but exist elsewhere. They can work with your pods, assuming that your pods are externally routable. Google and AWS provide this capability natively. In terms of Amazon, this maps directly with ELB and kubernetes when running in AWS can automatically provision and configure an ELB instance for each LoadBalancer service deployed.
Ingress: An ingress is really just a set of rules to pass to a controller that is listening for them. You can deploy a bunch of ingress rules, but nothing will happen unless you have a controller that can process them. A LoadBalancer service could listen for ingress rules, if it is configured to do so.
You can also create a NodePort service, which has an externally routable IP outside the cluster, but points to a pod that exists within your cluster. This could be an Ingress Controller.
An Ingress Controller is simply a pod that is configured to interpret ingress rules. One of the most popular ingress controllers supported by kubernetes is nginx. In terms of Amazon, ALB can be used as an ingress controller.
For an example, this nginx controller is able to ingest ingress rules you have defined and translate them to an nginx.conf file that it loads and starts in its pod.
Let's for instance say you defined an ingress as follows:
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
annotations:
ingress.kubernetes.io/rewrite-target: /
name: web-ingress
spec:
rules:
- host: kubernetes.foo.bar
http:
paths:
- backend:
serviceName: appsvc
servicePort: 80
path: /app
If you then inspect your nginx controller pod you'll see the following rule defined in /etc/nginx.conf:
server {
server_name kubernetes.foo.bar;
listen 80;
listen [::]:80;
set $proxy_upstream_name "-";
location ~* ^/web2\/?(?<baseuri>.*) {
set $proxy_upstream_name "apps-web2svc-8080";
port_in_redirect off;
client_max_body_size "1m";
proxy_set_header Host $best_http_host;
# Pass the extracted client certificate to the backend
# Allow websocket connections
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header X-Real-IP $the_real_ip;
proxy_set_header X-Forwarded-For $the_x_forwarded_for;
proxy_set_header X-Forwarded-Host $best_http_host;
proxy_set_header X-Forwarded-Port $pass_port;
proxy_set_header X-Forwarded-Proto $pass_access_scheme;
proxy_set_header X-Original-URI $request_uri;
proxy_set_header X-Scheme $pass_access_scheme;
# mitigate HTTPoxy Vulnerability
# https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
proxy_set_header Proxy "";
# Custom headers
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
proxy_redirect off;
proxy_buffering off;
proxy_buffer_size "4k";
proxy_buffers 4 "4k";
proxy_http_version 1.1;
proxy_cookie_domain off;
proxy_cookie_path off;
rewrite /app/(.*) /$1 break;
rewrite /app / break;
proxy_pass http://apps-appsvc-8080;
}
Nginx has just created a rule to route http://kubernetes.foo.bar/app to point to the service appsvc in your cluster.
Here is an example of how to implement a kubernetes cluster with an nginx ingress controller. Hope this helps!
这篇关于入口与负载平衡器的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
