kubernetes基础知识之service服务类型LB

摘要：对于纯粹的NodePort没办法解决高可用的问题，每一个worker node节点上创建了NodePort类型的服务service以后，它们都会在对应的节点打开一个物理网卡物理IP的对应端口，我们需要把客户的请求导入过去。但是如果一个节点宕机后，那么客户的请求

kubernetes service类型分成：

①：ClusterIP

②：NodePort

③：LoadBalancer

④：ExternalName

service是四层负载均衡，ingress是七层负载均衡。

对于纯粹的NodePort没办法解决高可用的问题，每一个worker node节点上创建了NodePort类型的服务service以后，它们都会在对应的节点打开一个物理网卡物理IP的对应端口，我们需要把客户的请求导入过去。但是如果一个节点宕机后，那么客户的请求就中断了。虽然还有其它节点的端口可以访问，但是没有意义。所以一般在私有云的环境中，在前面架设一个调度器。这个调度器可以是四层的，也可以是七层的，也可以是F5走二层的。在这种情况下，比如上了F5，就是直接上最贵的。这里可以用一个四层的负载均衡，当用户的请求到了以后，会被负载到不同物理服务器的不同端口。虽然某一台物理服务器宕机了，但是还有其它的服务器的端口，可以通过其它服务器的端口提供给客户进行负载访问。这种模型需要自己去实现，可以用F5、ipvs、nginx等。还有其它的方案，有且只有一个前提，就是必须工作在云环境中，那就是LoadBalancer。

LoadBalancer的方只能在云的环境中去使用，也可以有其它的开源软件去模拟。云服务商也可以提供负载均衡产品去实现LoadBalancer。但是由于稳定性的原因，目前还没有大规模地应用，所以不建议用开源的方式。

loadBalancer模式的服务需要在云供应商的环境中去使用，有一个客户通过云供应商提供的负载均衡产品将流量导入到每个节点的物理网卡的对应端口，再通过集群内部的ipvs，负载客户请求到后端的多个pod上，以此将流量从公网导向到kubernetes集群内部，并且这个导向的过程是高可用的。如果某一天一个节点的网卡故障了，我们还可以导向客户的请求到其它服务器，去实现请求的高可用。

LoadBalancer模式服务的资源清单文件：

touch lb-service.yaml

apiVersion: v1

kind: Service

metadata:

annotations:

service.beta.kunernetes.io/xxx-cloud-loadbalancer-id: ${YOUR_LB_ID}

service.beta.kubernetes.io/xxxx-loadbalancer-force-override-listeners: 'true'

labels:

app: nginx

name:my-nginx-service

namespace: default

spec:

ports:

- port: 80

protocol: TCP

targetPort: 80

selector:

app: nginx

type: LoadBalancer

可以通过LoadBalancer类型服务的资源清单文件创建出来一个LoadBalancer类型的服务。可以把内部的服务暴露出公网，并且绑定一个公网的IP地址。

annotations也是key-value的结构，是一个信息的描述。它是一种非官方的实现，比如开发扩展一些第三方的功能，可以在annotations上添加一些key和value。key和value被第三方的组件和软件识别以后，可以根据这些信息去确认想要配置的结果。七层负载均衡ingress里面需要使用annotations写很多配置信息，annotations是跟第三方开发者的一些非官方约定。

Labels标签主要是用在集群内部的匹配关系。service匹配pod，就是匹配pod的标签。pod控制器deployment确定pod是不是自己的，就会创建标签匹配。标签匹配，也是用的标签。删除pod的时候，也是用的标签匹配，通过标签选择的方式去删除对应的匹配到的标签去删除pod。集群内部的一些命令工具，也使用标签在做筛选，labels一般是官方的比较正式的标签。

Ingress是一种四层负载均衡，service是一种七层负载均衡。

这种loadBalancer类型的服务用的比较局限，只适合使用在公网的云环境中。