从我看到的文档
<块引用>NodePort：在静态端口（NodePort）处公开每个节点 IP 上的服务。 NodePort 服务将路由到的 ClusterIP 服务会自动创建。您将能够通过请求 :.
从集群外部联系 NodePort 服务 <块引用>LoadBalancer：使用云提供商的负载均衡器在外部公开服务。自动创建外部负载均衡器将路由到的 NodePort 和 ClusterIP 服务
但它没有提到何时选择一个而不是另一个。我能想到的 Nodeport 的缺点之一是安全性（在防火墙规则中打开端口），我想知道在选择一个而不是另一个时是否还有其他考虑因素。
答案 0 :(得分：2)
它们具有相同的潜在风险（相对于您所写的“缺点”而言），因为 type: LoadBalancer is type: NodePort 仅适用于集群的配置 cloud-provider 以提供云负载均衡器，该负载均衡器指向分配的 NodePort 并使节点成员资格与云负载均衡器的目标主机保持同步
因此，回答您的问题：当您希望云提供商为您配置云资源并管理其生命周期时，请使用 type: LoadBalancer；当您有其他方式将外部流量获取到节点上分配的端口时，请使用 type: NodePort。
答案 1 :(得分：1)
NodePort 服务在所有 <NodeIP:NodePort> 地址上公开您的服务，即您可以通过任何节点 IP 和 nodePort 组合访问您的服务。这可以由 kubernetes 本地实现，因为 kubernetes 有一个代理（kube-proxy）在所有节点上运行，以创建所需的配置，以将在 nodeIP:nodePort 上接收到的流量转发到后备 pod。
直接使用 Nodeport 服务的几个缺点是：
节点必须对外公开：除非您的节点本身对外公开，否则您无法接收 <NodeIP:NodePort> 地址上的流量。
无节点级负载平衡：客户端可以连接到 <NodeIP:NodePort> 处的服务，但节点之间没有流量负载平衡，除非客户端自己这样做。如果一个节点宕机了怎么办？谁会通知客户端不要使用节点？
非标准端口号：由于 <NodePort> 在所有节点上保持不变，因此它必须是所有节点上的空闲端口。 Kubernetes 通过在节点端口范围内选择一个空闲端口来确保这一点，默认情况下为 30000-32767。但我可能想在更标准的端口（如 80、443 等）上公开该服务。
如果我们有一个实体在我们喜欢的端口上接收外部可访问 IP 上的流量，然后将流量转发到 <NodePort:NodeIP 处的 NodePort 服务，我们就可以解决上述所有问题。接收流量的这个实体还可以通过保留所有节点的活动标签，然后将传入流量分配到集群中的后端节点，从而在节点之间进行负载平衡。集群节点可以保留在只能从此实体访问的专用网络中。
由于该实体位于 kubernetes 集群之外，因此 kubernetes 本身无法创建或管理它。但是在拓扑/网络级别具有控制权的人可以做到，即您的云提供商。他们可以创建此实体以接收外部可访问 IP 和您喜欢的端口上的流量，并将其转发到您的 nodePort 服务。但是有很多云提供商。您如何以统一的方式告诉云提供商您需要此功能？
LoadBalancer 服务来了。当您创建一个 LoadBalancer 服务时，Kubernetes 将创建一个 NodePort 服务并通知您的云提供商您已经创建了一个 LoadBalancer 类型的服务。然后您的云提供商将实例化负载均衡器以接收外部可访问 IP 上的流量并转发到集群。它还将使用外部 IP 更新您的 status 服务的 LoadBalancer 部分，然后您可以通过查询 kubernetes api-server（例如通过执行 kubectl get svc）来找到该 IP。云提供商通常对您创建的每项 LoadBalancer 服务收费。
如果您创建 LoadBalancer 类型的服务，vanilla 裸机（或自配置）集群会发生什么？
Kubernetes 将完成创建 NodePort 服务的工作。由于没有其他实体（如云提供商）监视 LoadBalancer 服务，因此此类集群上的 LoadBalancer 和 NodePort 之间没有任何区别。如果您为 ExternalIP 服务执行 <Pending>，您会看到 kubectl get svc 字段为 LoadBalancer。
参考：