概述

kubernetes中pods是平凡的,可创建可销毁而且不可再生。 ReplicationControllers可以动态的创建&销毁pods(如扩容 or 缩容 or 更新)。虽然pods有他们单独的ip,但是他们的ip并不能得到稳定的保证,这将会导致一个问题,如果在kubernetes集群中,有一些pods(backends)为另一些pods(frontend)提供一些功能,如何能保证frontend能够找到&链接到backends。

引入Services。

kubernetes services是一个抽象的概念,定义了如何和一组pods相关联—— 有时候叫做“micro-service”。一个service通过Label Selector来筛选出一组pods(下文会说明什么情况下不需要selector)。

举个栗子,设想一个拥有三个节点的图片处理backend,这三个节点都可以随时替代——frontend并不关系链接的是哪一个。即使组成backend的pods发生了变动,frontend也不必关心连接到哪个backend。services将frontend和backend的链接关系解耦。

对于kubernetes本身的应用来说,kubernetes提供了一个简单的endpoint 的api,对于非kubernetes本身的应用,kubernetes为servicet提供了一个解决方案,通过一个设定vip的bridge来链接pods。

定义一个service

在kubernetes中,services和pods一样都是一个REST对象。同其他的REST对象一样,通过POST来创建一个service。比如,有一组pods,每个pod对外暴露9376端口 他们的label为“app=MyApp”:

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

上述的json将会做以下事情:创建一个叫“my-service”的service,它映射了label为“app=MyApp”的pods端口9376,这个service将会被分配一个ip(cluster ip),service用这个ip作为代理,service的selector将会一直对pods进行筛选,并将起pods结果放入一个也焦作“my-service”的Endpoints中。

注意,一个service可能将流量引入到任何一个targetPost,默认targetPort字段和port字段是相同的。有趣的是targetPort 也可以是一个string,可以设定为是一组pods所映射port的name。在每个pod中,这个name所对应的真实port都可以不同。这为部署& 升级service带来了很大的灵活性,比如 可以在

kubernetes services支持TCP & UDP协议,默认为tcp。

Services without selectors

kubernetes service通常是链接pods的一个抽象层,但是service也可以作用在其他类型的backend。比如:

  • 在生产环境中你想使用一个外部的database集群,在测试环境中使用自己的database;
  • 希望将一个service指向另一个namespace中的service 或者 指向另外一个集群;
  • 希望将非kubernetes的工作代码环境迁移到kubernetes中;

在以上任意一个情景中,都可以使用到不指定selector的service:

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

在这个例子中,因为没有使用到selector,因此没有一个明确的Endpoint对象被创建。 因此需要手动的将service映射到对应的endpoint:

{
    "kind": "Endpoints",
    "apiVersion": "v1",
    "metadata": {
        "name": "my-service"
    },
    "subsets": [
        {
            "addresses": [
                { "IP": "1.2.3.4" }
            ],
            "ports": [
                { "port": 80 }
            ]
        }
    ]
}

无论有没有selector都不会影响这个service,其router指向了这个endpoint(在本例中为1.2.3.4:80)。

虚IP & service代理(Virtual IPs and service proxies)

kubernetes中的每个node都会运行一个kube-proxy。他为每个service都映射一个本地port,任何连接这个本地port的请求都会转到backend后的随机一个pod,service中的字段SessionAffinity决定了使用backend的哪个pod,最后在本地建立一些iptables规则,这样访问service的cluster ip以及对应的port时,就能将请求映射到后端的pod中。

最终的结果就是,任何对service的请求都能被映射到正确的pod中,而client不需要关心kubernetes、service或pod的其他信息。

默认情况下,请求会随机选择一个backend。可以将service.spec.sessionAffinity 设置为 "ClientIP" (the default is "None"),这样可以根据client-ip来维持一个session关系来选择pod。

在kubernetes中,service是基于三层(TCP/UDP over IP)的架构,目前还没有提供专门作用于七层(http)的services。

Multi-Port Services

在很多情况下,一个service需要对多个port做映射。下面举个这样的例子,注意,使用multi-port时,必须为每个port设定name,如:

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

Choosing your own IP address

用户可以为service指定自己的cluster ip,通过字段spec.clusterIP来实现。用户设定的ip必须是一个有效的ip,必须符合service_cluster_ip_range 范围,如果ip不合符上述规定,apiserver将会返回422。

Why not use round-robin DNS?

有一个问题会时不时的出现,为什么不用一个DNS轮询来替换vip?有如下几个理由:

  • 已经拥有很长历史的DNS库不会太注意DNS TTL 并且会缓存name lookup的结果;
  • 许多应用只做一次name lookup并且将结果缓存;
  • 即使app和dns库做了很好的解决,client对dns做一遍又一遍的轮询将会增加管理的复杂度;

我们做这些避免用户做哪些作死的行为,但是,如果真有那么多用户要求,我们会提供这样的选择。

Discovering services

对于每个运行的pod,kubelet将为其添加现有service的全局变量,支持Docker links compatible变量 以及 简单的{SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT变量。

比如,叫做”redis-master“的service,对外映射6379端口,已经被分配一个ip,10.0.0.11,那么将会产生如下的全局变量:

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

这意味着一个顺序依赖——service要想被pod使用,必须比pod先建立,否则这些service环境变量不会构建在pod中。DNS没有这些限制。

DNS

一个可选的扩展(强烈建议)是DNS server。DNS server通过kubernetes api server来观测是否有新service建立,并为其建立对应的dns记录。如果集群已经enable DNS,那么pod可以自动对service做name解析。

举个栗子,有个叫做”my-service“的service,他对应的kubernetes namespace为”my-ns“,那么会有他对应的dns记录,叫做”my-service.my-ns“。那么在my-ns的namespace中的pod都可以对my-service做name解析来轻松找到这个service。在其他namespace中的pod解析”my-service.my-ns“来找到他。解析出来的结果是这个service对应的cluster ip。

Headless services

有时候你不想做负载均衡 或者 在意只有一个cluster ip。这时,你可以创建一个”headless“类型的service,将spec.clusterIP字段设置为”None“。对于这样的service,不会为他们分配一个ip,也不会在pod中创建其对应的全局变量。DNS则会为service 的name添加一系列的A记录,直接指向后端映射的pod。此外,kube proxy也不会处理这类service
,没有负载均衡也没有请求映射。endpoint controller则会依然创建对应的endpoint。

这个操作目的是为了用户想减少对kubernetes系统的依赖,比如想自己实现自动发现机制等等。Application可以通过api轻松的结合其他自动发现系统。

External services

对于你应用的某些部分(比如frontend),你可能希望将service开放到公网ip,kubernetes提供两种方式来实现,NodePort and LoadBalancer。

每个service都有个type字段,值可以有以下几种:

  • ClusterIP: 使用集群内的私有ip —— 这是默认值。
  • NodePort: 除了使用cluster ip外,也将service的port映射到每个node的一个指定内部port上,映射的每个node的内部port都一样。
  • LoadBalancer: 使用一个ClusterIP & NodePort,但是会向cloud provider申请映射到service本身的负载均衡。

注意:NodePort支持TCP/UDP,LoadBalancer只支持TCP。

Type = NodePort

如果将type字段设置为NodePort,kubernetes master将会为service的每个对外映射的port分配一个”本地port“,这个本地port作用在每个node上,且必须符合定义在配置文件中的port范围(为--service-node-port-range)。这个被分配的”本地port“定义在service配置中的spec.ports[*].nodePort字段,如果为这个字段设定了一个值,系统将会使用这个值作为分配的本地port 或者 提示你port不符合规范。

这样就方便了开发者使用自己的负载均衡方案。

Type = LoadBalancer

如果在一个cloud provider中部署使用service,将type地段设置为LoadBalancer将会使service使用人家提供的负载均衡。这样会异步的来创建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",
        "type": "LoadBalancer"
    },
    "status": {
        "loadBalancer": {
            "ingress": [
                {
                    "ip": "146.148.47.155"
                }
            ]
        }
    }
}

这样外部的负载均衡方案将会直接作用在后端的pod上。

Shortcomings

通过iptables和用户控件映射可以很好的为中小型规模服务,但是并不适用于拥有数千个service的集群。详情请看” the original design proposal for portals“。

使用kube-proxy不太可能看到访问的源ip,这样使得某些类型防火墙实效。

LoadBalancers 只支持TCP.

type字段被设计成嵌套的结构,每一层都被增加到了前一层。很多云方案提供商支持的并不是很好(如,gce没有必要分配一个NodePort来使LoadBalancer正常工作,但是AWS需要),但是当前的API需要。

Future work

The gory details of virtual IPs

以上的信息应该足够用户来使用service。但是还是有许多东西值得大家来深入理解。
(懒得翻了,大家自己看吧,最后贴上最后一个图)

Avoiding collisions

IPs and VIPs


03-05 19:50