理解Kubernetes的NodePort、LoadBalancer和Ingress

Posted 2023-03-23

参考技术A

这三个东西都可以实现将集群内的服务暴露到集群外，那么它们到底有什么不同，要如何正确地使用这些组件，希望通过这篇文章，可以给大家一些启示。首先明确一点，NodePort和LoadBalancer指Kubernetes Service组件的两种类型。
在正式开始之前，有必要对Service做简单介绍。Service是一组Pod的抽象，虽然在集群中Pod可以通过IP直达，但是Pod不稳定，它可能会经常死掉，这时集群会重新启动一个Pod，这是一个全新的Pod，它的IP地址会发生变化，这样不利于客户端访问。为了解决这个问题，Kubernetes引入了Service组件，从Pod创建之初到人为删除这段时间，为其创建的Service访问方式都是稳定的，即它的访问IP不变，再配合集群内置的DNS服务，客户端可以利用不变的Service名称或Service IP访问到目标Pods，而且Service还实现了简单的负载均衡功能。
到这里，还有一个很重要的问题没有解决，在Kubernetes集群外如何访问集群内的服务，这就引出了标题中列举的三个对象，下面逐一介绍。
NodePort
Nodeport是Service的三种类型之一（ExternalName不常用故除外），其他两种是ClusterIP和LoadBalancer。当Service工作在NodePort类型时，默认每个Node会在全部网络接口开启一个端口来转发对集群内服务的请求。当请求到来时，Node会转发请求到集群中的服务。这样就带来一个问题，请求的目标Node可能会Down掉或其他别的原因导致网络不能访问，NodePort还有一个问题就是对外暴露的端口有限制，默认端口范围是30,000-32,767。这就限制了可以对外暴露服务的个数，使用这些不易记录的端口访问服务也是让人头疼的问题，这就引入了下一个Service类型：LoadBalancer。
LoadBalancer
大多数公有云平台都支持创建这种类型的服务，每个服务可以支持多种协议和多个端口，使用单个IP来访问。因为需要在集群外访问内部服务，所以这个IP地址是公有的，这会产生额外的费用。如果暴露的服务很多，使用时需要慎重。在私有云环境中，不能创建此类的服务，可以创建NodePort类型的服务然后使用HAproxy来充当Load Balancer，这样和公有云平台的LoadBalancer差别不大。Service的三种类型：ClusterIP、NodePort、LoadBalancer，后一种是前一种的增强，NodePort类型Service会创建ClusterIP类型Service，LoadBalancer类型Service会创建NodePort和ClusterIP类型Service。Service组件依赖操作系统中的iptables或ipvs，这是Service的灵魂。有一点需要注意，当使用NodePort类型的服务时，请求会直接转发给实际的Pod而不用转发给Service的Cluster IP（kube-proxy工作在iptables模式），具体实现方法可以在搜索引擎上搜“NodePort类型Service的工作原理”。
Ingress
前面介绍的内容都围绕Service，主要解决网络层的问题，Ingress的出现主要是解决应用层的问题。Ingress实际上充当一个反向代理的角色，和Nginx的功能很类似。Kubernetes中广泛使用的Nginx Ingress其本质就是一个Nginx服务。Ingress依赖LoadBalancer类型的Service，因为它自己没有暴露集群内服务到外部的能力。这里以Nginx Ingress为例，介绍它的工作原理，其他类型的Ingress可以参考其官方文档介绍。

集群部署Ingress资源后，进入集群流量的第一站就是Nginx Ingress中的Nginx服务，由它做HTTP层的负载均衡，还有TLS终结等工作。
总结
文章对NodePort和LoadBalancer类型的Service做了简单介绍，在测试环境中如果需要快速将服务从集群内暴露出来，可以使用NodePort类型的Service，生产环境，如果使用了阿里云或腾讯云可以使用LoadBalancer类型的Service并配合Ingress，如果没有也可以使用NodePort类型的Service并配置Haproxy等来实现负载均衡。