泰拳图片做网站用网页版

Kubernetes在设计之初就充分考虑了针对容器的服务发现与负载均衡机制，提供了Service资源，并通过kube-proxy配合cloud provider 来适应不同的用于场景。随着kubernetes用户的激增，用户场景的不断丰富，又产生了一些新的负载均衡机制。目前kubernetes 中的负载均衡大致可以分为以下几种机制，每种机制都有其特定的应用场景：

        service:直接用Service提供cluster内部的负载均衡，但是通过自定义的LB提供外部访问

        Ingress Controller:还是用Service提供cluster内部的负载均衡，但是通过自定义的 IngressController提供访问

        Service Load Balancer:把load balancer直接跑在容器中，实现Bare Metal的Service LoadBalancer

        Custom Load Balancer:自定义负载均衡，并代替kube-proxy,一般在物理部署Kubernetes时使用，方便接入公司已有的外部服务

Service

        Service是对一组提供相同功能的Pods的抽象，并为它们提供一个统一的入口。借助Service,应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service通过标签来选取服务后端，一般配合Replication Controller 或者 Deployment来保证后端容器的正常运行。这些匹配标签的Pod IP和端口列表组成endpoints，由kube-proxy负责将服务IP负载均衡到这些endpoins上。

Service:有四种类型

        ClusterIP:默认类型，自动分配一个仅cluster内部可以访问的虚拟IP

        NodePort:在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过<NodeIP>:NodePort 来访问该服务。如果kube-proxy设置了--nodeport-addresses=10.240.0.0/16，那么仅该NodePort 仅对设置在范围内的IP有效

        LoadBalancer:在NodePort的基础上，借助cloud provider常见一个外部的负载均衡器，并将请求转发到<NodeIP>:NodePort

        ExternalName:将服务通过DNS CNAME记录方式转发到指定的域名（通过spec.externlName设定 ）。需要kube-dns版本在1.7以上。

        另外，也可以将已有的服务以Service的形式加入到Kubernetes集群中来，只需要在创建Service的时候不指定Label selector,而是在Service创建后手动为其添加endpoint

Service定义

        Service的定义也是通过yaml或json,比如下面定义了一个名为nginx的服务，将服务的80端口转发到default namespace中带有标签run=nginx的Pod的80端口

        Service可以说是kubernetes中最核心的资源对象之一了，每个Service就是一个“微服务”，RC、Pod等资源对象都是为Service来做嫁衣的！

Pod、RC与Service的逻辑关系如下图：

 

        Service定义一个服务的访问入口地址，前端的应用（pod)通过这个入口访问其背后的一组有Pod副本组成的集群实例，Service与后端Pod副本集群则是通过lable selector来实现无缝对接，而RC的作用实际上是保证Service的服务能力和服务质量始终保持在预期标准