Kubernetes的三种外部访问方式：NodePort、LoadBalancer和Ingress（转发）

时间 2020-06-20

标签 kubernetes 三种外部访问方式 nodeport loadbalancer ingress 转发繁體版

原文原文链接

原文 http://cloud.51cto.com/art/201804/570386.htm前端

Kubernetes的三种外部访问方式：NodePort、LoadBalancer和Ingress

最近有些同窗问我 NodePort，LoadBalancer 和 Ingress 之间的区别。它们都是将集群外部流量导入到集群内的方式，只是实现方式不一样。让咱们看一下它们分别是如何工做的，以及你该如何选择它们。node

做者：池剑锋译来源： Docker| 2018-04-12 13:35: 收藏

分享

技术沙龙 | 4月21日多位区块链专家进行区块链技术应用场景解读！

最近有些同窗问我 NodePort，LoadBalancer 和 Ingress 之间的区别。它们都是将集群外部流量导入到集群内的方式，只是实现方式不一样。让咱们看一下它们分别是如何工做的，以及你该如何选择它们。git

注意：这里说的每一点都基于Google Kubernetes Engine。若是你用 minikube 或其它工具，以预置型模式（om prem）运行在其它云上，对应的操做可能有点区别。我不会太深刻技术细节，若是你有兴趣了解更多，官方文档[1]是一个很是棒的资源。github

ClusterIP后端

ClusterIP 服务是 Kubernetes 的默认服务。它给你一个集群内的服务，集群内的其它应用均可以访问该服务。集群外部没法访问它。api

ClusterIP 服务的 YAML 文件相似以下：app

apiVersion: v1
kind: Service
metadata:
name: my-internal-service
selector:
app: my-app
spec:
type: ClusterIP
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP

若是从Internet 无法访问 ClusterIP 服务，那么咱们为何要讨论它呢？那是由于咱们能够经过 Kubernetes 的 proxy 模式来访问该服务！负载均衡

启动 Kubernetes proxy 模式：dom

$ kubectl proxy --port=8080

这样你能够经过Kubernetes API，使用以下模式来访问这个服务：socket

http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/

要访问咱们上面定义的服务，你可使用以下地址：

http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/

什么时候使用这种方式？

有一些场景下，你得使用 Kubernetes 的 proxy 模式来访问你的服务：

因为某些缘由，你须要调试你的服务，或者须要直接经过笔记本电脑去访问它们。
允许内部通讯，展现内部仪表盘等。

这种方式要求咱们运行 kubectl 做为一个未认证的用户，所以咱们不能用这种方式把服务暴露到 internet 或者在生产环境使用。

NodePort

NodePort 服务是引导外部流量到你的服务的最原始方式。NodePort，正如这个名字所示，在全部节点（虚拟机）上开放一个特定端口，任何发送到该端口的流量都被转发到对应服务。

NodePort 服务的 YAML 文件相似以下：

apiVersion: v1
kind: Service
metadata:
name: my-nodeport-service
selector:
app: my-app
spec:
type: NodePort
ports:
- name: http
port: 80
targetPort: 80
nodePort: 30036
protocol: TCP

NodePort 服务主要有两点区别于普通的“ClusterIP”服务。第一，它的类型是“NodePort”。有一个额外的端口，称为 nodePort，它指定节点上开放的端口值。若是你不指定这个端口，系统将选择一个随机端口。大多数时候咱们应该让 Kubernetes 来选择端口，由于如评论中 thockin 所说，用户本身来选择可用端口代价太大。

什么时候使用这种方式？

这种方法有许多缺点：
每一个端口只能是一种服务
端口范围只能是 30000-32767

若是节点/VM 的 IP 地址发生变化，你须要能处理这种状况

基于以上缘由，我不建议在生产环境上用这种方式暴露服务。若是你运行的服务不要求一直可用，或者对成本比较敏感，你可使用这种方法。这样的应用的最佳例子是 demo 应用，或者某些临时应用。

LoadBalancer

LoadBalancer 服务是暴露服务到 internet 的标准方式。在 GKE 上，这种方式会启动一个 Network Load Balancer[2]，它将给你一个单独的 IP 地址，转发全部流量到你的服务。

什么时候使用这种方式？

若是你想要直接暴露服务，这就是默认方式。全部通往你指定的端口的流量都会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎能够发送任何种类的流量到该服务，像 HTTP，TCP，UDP，Websocket，gRPC 或其它任意种类。

这个方式的最大缺点是每个用 LoadBalancer 暴露的服务都会有它本身的 IP 地址，每一个用到的 LoadBalancer 都须要付费，这将是很是昂贵的。

Ingress

有别于以上全部例子，Ingress 事实上不是一种服务类型。相反，它处于多个服务的前端，扮演着“智能路由”或者集群入口的角色。

你能够用 Ingress 来作许多不一样的事情，各类不一样类型的 Ingress 控制器也有不一样的能力。

GKE 上的默认 ingress 控制器是启动一个 HTTP(S) Load Balancer[3]。它容许你基于路径或者子域名来路由流量到后端服务。例如，你能够将任何发往域名 foo.yourdomain.com 的流量转到 foo 服务，将路径 yourdomain.com/bar/path 的流量转到 bar 服务。

GKE 上用 L7 HTTP Load Balancer[4]生成的 Ingress 对象的 YAML 文件相似以下：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: my-ingress
spec:
backend:
serviceName: other
servicePort: 8080
rules:
- host: foo.mydomain.com
http:
paths:
- backend:
serviceName: foo
servicePort: 8080
- host: mydomain.com
http:
paths:
- path: /bar/*
backend:
serviceName: bar
servicePort: 8080

什么时候使用这种方式？

Ingress 多是暴露服务的最强大方式，但同时也是最复杂的。Ingress 控制器有各类类型，包括 Google Cloud Load Balancer， Nginx，Contour，Istio，等等。它还有各类插件，好比 cert-manager[5]，它能够为你的服务自动提供 SSL 证书。

若是你想要使用同一个 IP 暴露多个服务，这些服务都是使用相同的七层协议（典型如 HTTP），那么Ingress 就是最有用的。若是你使用本地的 GCP 集成，你只须要为一个负载均衡器付费，且因为 Ingress是“智能”的，你还能够获取各类开箱即用的特性（好比 SSL、认证、路由等等）。