【Kubernetes】Kubernetes的Service外部访问方式:NodePort和LoadBalancer

Kubernetes的Pod的寿命是有限的,它们不会复活,因此尽管每个Pod都有自己的IP地址,但是这些IP地址是不可靠的,会随着Pod的消亡而消失。

这就带来一个问题,如果一些Pod的集合(称之为backends)为集群的其他的Pod(称之为frontends),这些frontends应该如何找到并一直知道哪些backends在这样的集合中呢?

 

这就需要引入Service, 一个kubernetes的service是一种抽象,它定义了一个Pod的逻辑集合和一个用于访问它们的策略。一个Service的目标Pod的集合通常是由Label Selector来决定的。

举个例子,想象一个处理图片的后端运行了三个副本。这些副本都是可以替代的,前端不关心它们使用的是哪一个后端。尽管实际组成后端集合的Pod可能会变化,前端的客户端却不需要知道这个变化,也不需要自己有一个列表来记录这些后端服务。Service抽象能让你达到这种解耦。

 

对于那些Kubernetes原生的应用,Kubernetes提供了一个简单的Endpoints API,会在Service中的Pod集合发生改变的时候更新。对于非Kubernetes原生的应用,Kubernetes为Service提供了一种基于虚拟IP的桥接方式使其重定向到后端的Pods。

 

定义一个Service

Kubernetes中的Service是一个REST对象,这点与Pod类似。正如所有的REST对象一样,向apiserver POST一个Service的定义就能创建一个新的实例。例如,假设你有一组Pods,每一个Pod都开放了9376端口,并且都有一个"app=MyApp"的标签。

 

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376
            }
        ]
    }
}

 

这个定义会创建一个新的Service对象,名字为”my-service”,它指向所有带有”app=MyApp”标签的Pod上面的9376端口。这个Service同时也会被分配一个IP地址(有时被称作”cluster ip”),它会被服务的代理所使用(见下面)。这个Service的选择器,会不断的对Pod进行筛选,并将结果POST到名字同样为“my-service”的Endpoints对象。

注意一个Service能将一个来源的端口映射到任意的targetPort。默认情况下,targetPort会被设置成与port字段一样的值。可能更有意思的地方在于,targetPort可以是一个字符串,能引用一个后端Pod中定义的端口名。实际指派给该名称的端口号在每一个Pod中可能会不同。这为部署和更新你的Service提供了很大的灵活性。例如,你可以在你的后端的下一个版本中更改开放的端口,而无需导致客户出现故障。

Kubernetes的Service支持TCP和UDP协议。默认是TCP。

 

 

发布 services - service的类型

Kubernetes的ServiceTypes能让你指定你想要哪一种服务。默认的和基础的是ClusterIP,这会开放一个服务可以在集群内部进行连接。NodePort 和LoadBalancer是两种会将服务开放给外部网络的类型。

ServiceType字段的合法值是:

ClusterIP: 仅仅使用一个集群内部的IP地址 - 这是默认值。选择这个值意味着你只想这个服务在集群内部才可以被访问到。

NodePort: 在集群内部IP的基础上,在集群的每一个节点的端口上开放这个服务。你可以在任意:NodePort地址上访问到这个服务。

LoadBalancer: 在使用一个集群内部IP地址和在NodePort上开放一个服务之外,向云提供商申请一个负载均衡器,会让流量转发到这个在每个节点上以:NodePort的形式开放的服务上。

在使用一个集群内部IP地址和在NodePort上开放一个Service的基础上,还可以向云提供者申请一个负载均衡器,将流量转发到已经以NodePort形式开发的Service上。

注意尽管NodePort可以是TCP或者UDP的,对于Kubernetes 1.0来说,LoadBalancer还支持TCP。

 

NodePort类型

如果你把type字段设置为"NodePort",Kubernetes的master就会从由启动参数配置的范围(默认是:30000-32767)中分配一个端口,然后每一个Node都会将这个端口(在每一个Node上相同的端口)代理到你的Service。这个端口会被写入你的Service的spec.ports[*].nodePort字段中。

如果你想要一个特定的端口号,你可以在nodePort字段中指定一个值,确保系统能为你分配这个端口,否则API请求将会失败(例如你需要自己处理可能出现的端口冲突)。你指定的值必须在节点端口配置的范围内。

这给了开发者了设置他们自己的负载均衡器的自由,配置那些没有被Kubernetes完全支持的云环境,或者甚至可以直接开放一个或者多个节点的IP。

这种Service可以同时以:spec.ports[*].nodePort和spec.clusterIp:spec.ports[*].port的形式访问。

 

LoadBalancer类型

在那些支持外部负载均衡器的云提供者上面,将type字段设置为"LoadBalancer"会为你的Service设置好一个负载均衡器。该负载均衡器的实际的创建是异步进行的,并且该设置好均衡器会在该Service的status.loadBalancer字段中显示出来。例如:

 

{
    "kind": "Service",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "spec": {
        "selector": {
            "app": "MyApp"
        },
        "ports": [
            {
                "protocol": "TCP",
                "port": 80,
                "targetPort": 9376,
                "nodePort": 30061
            }
        ],
        "clusterIP": "10.0.171.239",
        "loadBalancerIP": "78.11.24.19",
        "type": "LoadBalancer"
    },
    "status": {
        "loadBalancer": {
            "ingress": [
                {
                    "ip": "146.148.47.155"
                }
            ]
        }
    }

 

从外部负载均衡器的流量将会被引到后端的Pod,然而具体这个如何实现则要看云提供商。一些云提供商允许指定loadBalancerIP。在这种场景,负载均衡器将随用户指定的loadBalancerIP一起创建。如果字段loadBalancerIP没有指定,该负载均衡器会被指定一个短暂性的IP。如果指定了loadBalancerIP,但是云提供商不支持这个特性,这个字段会被忽略。

转载于:https://www.cnblogs.com/yuxiaoba/p/9212280.html

你可能感兴趣的:(后端,前端,网络)