Kubernetes基础(三)-Service外部网络访问方式

1 概述

NodePort、LoadBalancer 和 Ingress 都是将集群外部流量导入到集群内的方式,只是实现方式不同。以下是三种方式的工作原理

注意:这里说的每一点都基于Google Kubernetes Engine。如果用 minikube 或其它工具,以预置型模式(om prem)运行在其它云上,对应的操作可能有点区别。

2 ClusterIP

ClusterIP 服务是 Kubernetes 的默认服务。它提供一个集群内的服务,集群内的其它应用都可以访问该服务。集群外部无法访问ClusterIP。

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基础(三)-Service外部网络访问方式_第1张图片

proxy设置方式:

kubectl proxy --port=8080

2.1 访问方式

  • 启动 Kubernetes proxy后就可以使用http://localhost:8080/api/v1/proxy/namespaces//services/:/通过 Kubernetes API 访问 service。
  • 也可以使用http://localhost:8080/api/v1/proxy/namespaces/default/services/my-internal-service:http/这个地址,访问上面定义的 service。

2.2 使用场景

  • 调试service,或直接从笔记本电脑连接到 service;
  • 允许内部流量访问,显示内部 dashboards 

由于此方法要求将 kubectl 作为认证用户运行,因此不能使用这个方法将service 暴露在公网上或将其用于生产环境下。

3 NodePort

NodePort 类型的 service 是让外部流量可以访问集群内部服务最基本的方式。NodePort是在所有 Node(VM)上打开一个特定的 port,任何发送到此 port 的流量都将转发到 service 上。

Kubernetes基础(三)-Service外部网络访问方式_第2张图片

从技术上看,这也许不是最准确的图表,但它表明了 NodePort 的工作方式。

NodePort 类型的 service 的 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

3.1 与clusterip的区别

NodePort 类型的 service 与普通的 “ClusterIP” 类型的 service 有两点区别:

  • 类型是 “NodePort”;
  • 它有一个被称为 nodePort 的附加 port,可以在 node 上指定打开哪个 port 。如果不指定一个 port,NodePort 类型的 service 就会随机选择一个。大多数时候应该让 Kubernetes 来选择 port;

3.2 使用场景

  • 运行的服务不用保持始终可用;
  • 适用于一个演示应用程序或其他临时的东西

3.3 缺点

  • 每个端口只能绑定一个 service;
  • 可使用端口号只能是 30000 到 32767;
  • 如果节点/VM 的 IP 地址发生变化,需要做处理。

4 LoadBalancer

LoadBalancer (负载均衡器)类型的 service 是在公网上暴露服务的标准方式。在 GKE 上将启动一个网络LoadBalancer,该网络LoadBalancer将为svc提供一个 IP 地址,用来将所有流量转发到kubernetes service 上。

Kubernetes基础(三)-Service外部网络访问方式_第3张图片

在云提供商上运行的Kubernetes集群通常支持从云基础架构自动提供负载平衡器。 所有需要做的就是设置服务的类型为Load Badancer而不是NodePort。 负载均衡器拥有自己独一无二的可公开访问的 IP 地址, 并将所有连接重定向到服务。可以通过负载均衡器的 IP 地址访问服务。如果Kubemetes在不支持Load Badancer服务的环境中运行, 则不会调配负载平衡器, 但该服务仍将表现得像 一 个NodePort服 务。 这是因为LoadBadancer服务是NodePort服务的扩展。 

Yaml文件: 

apiVersion: v1
kind: Service
metadata:
  name: kubia-loadbalancer
spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
  selector:
    app: kubia

可以路由到 NodePort 服务和 ClusterIP 服务,这个需要结合具体的云厂商进行操作。 

4.1 使用场景

  • 需要直接暴露service到外部的应用。

4.2 缺点

  • 没有过滤条件,没有路由等。这意味着几乎可以发送任何种类的流量到该服务,像 HTTP,TCP,UDP,Websocket,gRPC 或其它任意种类。
  • 每一个用 LoadBalancer 暴露的服务都会有它自己的 IP 地址,每个用的 LoadBalancer 都需要付费,成本高;

5 Ingress

Ingress 实际上不是 service 的一个类型。其架构侧位于多个 service 之前,充当集群中的“智能路由器”或入口点。用户可以使用 Ingress 做很多不同的事情。现在市面上有许多不同类型的 Ingress 控制器,不同类型的ingress具有不同的功能。

默认的 GKE ingress 控制器将为k8s集群启动一个 HTTP(S)LoadBalancer。帮助用户用来执行基于路径和子域的路由到后端服务。例如:用户可以将http://a.baidu.com上的所有内容发送到 对应 service 上,将http://b.baiud.com/test 路径下所有内容发送到对应service 上。

Kubernetes基础(三)-Service外部网络访问方式_第4张图片

GKE 上 Ingress 对象的 YAML 如下所示(带有 L7 HTTPLoadBalancer):

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

 5.1 使用场景

Ingress 是暴露 service 最强大的方式,但也是最复杂的。其实,Ingress 控制器有很多类型,像来自 Google Cloud 的LoadBalancer,Nginx,Contour,Istio 等。还有用于 Ingress 控制器的插件,如 cert-manager,均可以为用户的 service 自动提供 SSL 证书。

如果业务需要在相同的 IP 地址下暴露多个 service,并且这些 service 都使用相同的 L7 协议(通常是 HTTP),此刻Ingress 是最适用的。如果业务需要使用GCP 集成,那么只需使用一台负载均衡器。由于 Ingress 是“智能的”,用户可以获得许多“开箱即用”的功能,如 SSL,Auth,路由等。

你可能感兴趣的:(#,Kubernetes系列,kubernetes,容器,云原生)