NodePort,LoadBalancer还是Ingress?我该如何选择 - kubernetes - justmine - 博客园

来源: NodePort,LoadBalancer还是Ingress?我该如何选择 – kubernetes – justmine – 博客园

原文:http://mp.weixin.qq.com/s/dHaiX3H421jBhnzgCCsktg

当我们使用k8s集群部署好应用的Service时,默认的Service类型是ClusterIP,这种类型只有 Cluster 内的节点和 Pod 可以访问。如何将应用的Service暴露给Cluster外部访问呢,Kubernetes 提供了多种类型的 Service,如下:

ClusterIP


ClusterIP服务是Kuberntets的默认服务。它在集群内部生成一个服务,供集群内的其他应用访问。外部无法访问。

ClusterIP服务的 YAML 文件如下:

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

如果不能从互联网访问ClusterIP服务,那我们还介绍它干啥?其实,我们可以使用Kubernetes proxy来访问它!

 

开启Kubernetes Proxy:

$ kubectl proxy --port=8080

现在可以通过Kubernetes API使用下面这个地址来访问这个服务:

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来访问服务:

  1. 调试服务,或者是因为某些原因需要从电脑直接连接服务;
  2. 允许内部流量,显示内部仪表盘等。

这个访问需要你作为一个已验证的用户去运行kubectl,所以不要通过这种方式将服务发布到互联网,或者是在生产环境下使用。

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说的,关于能使用哪些端口,有很多注意事项。

使用场景

这种方式有一些不足:

  1. 一个端口只能供一个服务使用;
  2. 只能使用30000–32767的端口;
  3. 如果节点 / 虚拟机的IP地址发生变化,需要进行处理。

因此,我不推荐在生产环境使用这种方式来直接发布服务。如果不要求运行的服务实时可用,或者在意成本,这种方式适合你。例如用于演示的应用或是临时运行就正好用这种方法。

LoadBalancer


LoadBalancer服务是发布服务到互联网的标准方式。在GKE中,它会启动一个Network Load Balancer,分配一个单独的IP地址,将所有流量转发到服务中。

 

使用场景

如果你想直接发布服务,这是默认方式。指定端口的所有流量都会转发到服务中,没有过滤,也没有路由。这意味着你几乎可以发送任意类型的流量到服务中,比如HTTP、TCP、UDP、Websockets、gRPC等等。

这里最大的不足是,使用LoadBalancer发布的每个服务都会有一个自己的IP地址,你需要支付每个服务的LoadBalancer 费用,这是一笔不小的开支。

Ingress


Ingress实际上不是一种服务。相反,它在多个服务前面充当“智能路由”的角色,或者是集群的入口。

使用Ingress可以做很多事情,不同类型的Ingress控制器有不同的功能。

默认的GKE ingress控制器会启动一个 HTTP(S) Load Balancer,可以通过基于路径或者是基于子域名的方式路由到后端服务。例如,可以通过foo.yourdomain.com 发送任何东西到foo服务,或者是发送yourdomain.com/bar/路径下的任何东西到bar服务。

对于使用第 7 层HTTP Load Balancer 的GKE上的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等等。还有一些Ingress控制器插件,比如证书管理器,可以自动为服务提供SSL认证。

如果想在同一个IP地址下发布多个服务,并且这些服务使用相同的第 7 层协议(通常是 HTTP),Ingress是最有用的。如果使用原生的GCP集成,只需要支付一个负载均衡器的费用。因为Ingress是“智能”的,你可以得到很多开箱即用的特性(比如SSL、认证、路由等)。

实践


NodePort: kubernetes实践之运行aspnetcore webapi微服务  

Ingress:等待正在更新中…..

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏