K8S Ingress Controller技术细节探讨

K8S Ingress Controller技术细节探讨

对于许多企业来说，将生产环境转移到Kubernetes集群上，会让应用程序的流量管理变得复杂且具有挑战性。

而Ingress Controller允许通过Yaml编排脚本提供高可用的七层负载均衡、Waf防火墙或者API Gateway，它是Kubernetes集群对外服务的核心组件。

Ingress-nginx是Kubernetes Ingress Controller开源版本中的一种，它使用了NGINX作为反向代理和负载均衡器，生态完善、功能丰富，性能与稳定性也是极优秀的。

最近五年随着devops的落地，很多运维岗位都消失了，可能只需要在抽象的web界面上配置一下，或者k8s里面yaml去管理。

现在很多的开源产品就是拿openresty或者nginx做了一些插件的开发，通过WAF或者service mesh去包装给到用户。

Ingress是七层负载均衡，nginx最擅长的，这里主要讲nginx的两种实现。第一种是k8s官方的，第二重是nginx官方的。注意这两个ingress control是基于go实现的

Ingress control的工作原理

工作场景：Ingress control就是在处理南北向的流量，尤其是整个集群出入口的流量

早期时候是基于物理机，之后是基于虚拟机，比如在公有云上面买了ecs，后面有了docker，K8s相对于docker来说最强大之处是在编排上面，托管上面。

外部的traffic流量下来以后，来到ingress这里可以理解为nginx，nginx是基于虚拟主机域名，这个东西就是server_name，根据server_name做第一级的匹配，匹配到之后再匹配url，也就是location。Nginx里面最核心的两级匹配一个是server一个是location。

匹配完以后就丢给了service

负载均衡服务怎么实现的呢？其实挺简单的，当有一个VIP的时候其实是通过iptables完成的，Linux上面有一个配置net.ipv4.ip_forward当其值为1的时候就具备了转发报文的能力，转发报文的时候有一个iptables的规则，这个规则就可以做了。

如果你去访问虚拟IP，50%的流量给到pod1，50%的流量给到pod2，这个就是通过iptables来完成的。

一个service可以绑定多个endpoint。

Ingress将nginx的很多东西给抽象出来了，server location upstream。

Ingress抽象出来了域名，host的值就和server_name的值一样，path就和我们的location一样。我们知道nginx location进行匹配的时候可以基于正则匹配，忽略大小写匹配。但是k8s抽象出来的是非常有限的，因为k8s没有认为其是其唯一的选择，因为还可以放lvs和其他的负载均衡，所以只将最小能力抽象出来了。

在nginx里面会有upstream(server pod1 ip server pod2 ip)其实，一个service就对应了一个upstream

数据会丢失？

要实现高可用，要很多维度保障，随着机器宕机，nginx的配置也会随之丢掉

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。