您的位置:首页 > 其它

Kubernetes 详解-Replica Sets 和Service

2016-09-27 14:37 525 查看

原文地址http://www.damonyi.cc/kubernetes-%E8%AF%A6%E8%A7%A3-replica-sets-%E5%92%8Cservice/

1.1 Replica Sets

下一代的Replication Controller,两者的区别主要在选择器selector,Replica 支持集合级别的选择器,而前期的Replication Controller,支持在等号描述的选择器,kubectl命令支持使用replica

sets (目前kubectl命令中的rolling-update 还不支持),目前replica

sets主要用于deployment中
Replica Sets 能够确保在某个时间点上,一定数量的Pod在运行。然而Deployment 是Replica Sets更高一层的抽象,用于更新Pods 以及其他一些特性。推荐使用Deployment而不是直接使用Replica

Set进行编排Pods。
 
 

1.2 Service

由于Pod的IP会变化,提供某些功能的POD如果IP发生变化,会导致其他Pod无法发现这些功能,因此 引入了Service的功能。
Service是一组逻辑Pod的抽象,定义了一个访问这些Pod的策略(或者叫做微服务),这些Service 通常通过Label Selector指向这些Pod。
举个例子:一个提供镜像处理的后端有三个运行的副本,这些副本是可以取代的,但是前端并不需要感知,这时就需要Service作为抽象
对于可以部署在K8s内部应用,K8s通过Endpoints Api更新Service对应的Pod集合,对于那些没K8s外部的应用,K8s提供了虚拟IP桥接到Service,然后Service重定向到Pod集合。

1.2.1 Service 定义

{
    “kind”: “Service”,
    “apiVersion”: “v1”,
    “metadata”: {
        “name”: “my-service”
    },
    “spec”: {
        “selector”: {
            “app”: “MyApp”
        },
        “ports”: [
            {
                “protocol”: “TCP”,
                “port”: 80,
                “targetPort”: 9376
            }
        ]
    }
}
 
该Service 对应的Pod集合:带有label app=Myapp,对外暴露端口9376
Service 能将任意的流入Port 重定向到targetPort,默认情况下,targetPort和Port为相同值,不同的Pod 可以对应不同的端口号(例如,在你应用的下一个版本中会使用不同的端口号,但是并不应用之前版本的使用)
Service 支持UDP和TCP,默认是TCP

1.2.2 Service

without selector

Service可以抽象访问Pod集群,同时 Service也可以抽象其他后端
1、  在生产环境中使用外部数据库,在测试环境中使用自己的数据库
2、  将自己的Service指向其他集群或者其他命名空间的Service
3、  迁移应用到k8s,但是还是有些应用运行在k8s之外
通过定义不包含selector的Service实现
{
    “kind”: “Service”,
    “apiVersion”: “v1”,
    “metadata”: {
        “name”: “my-service”
    },
    “spec”: {
        “ports”: [
            {
                “protocol”: “TCP”,
                “port”: 80,
                “targetPort”: 9376
            }
        ]
    }
}
Service 没有Selector,K8s不会创建Endpoints,你可以通过手动创建Endpoint指向自己的endpoint
{
    “kind”: “Endpoints”,
    “apiVersion”: “v1”,
    “metadata”: {
        “name”: “my-service”
    },
    “subsets”: [
        {
            “addresses”: [
                { “ip”: “1.2.3.4” }
            ],
            “ports”: [
                { “port”: 9376 }
            ]
        }
    ]
}
 
Endpoint的IP不能是loopback(127.0.0.1/8),link-local(169.254.0.0/16), link-local

multicast (224.0.0.0/24).
访问不含有selector的Service和访问含有Selector的Service 方式一样,都会讲流向重定向的endpoint
 其他命名空间的服务是一个特例,他不会定义ports和endpoint,他只是返回一个访问外部服务的别名
{
    “kind”: “Service”,
    “apiVersion”: “v1”,
    “metadata”: {
        “name”: “my-service”,
        “namespace”: “prod”
    },
    “spec”: {
        “type”: “ExternalName”,
        “externalName”: “my.database.example.com”
    }
}
当你访问服务my-service.prod.svc.CLUSTER时,cluster的dns服务会返回记录my.database.example.com 的CNAME,这个重定向是发生在dns解析阶段。

1.2.3 虚拟IP 和服务代理

1.2.3.1 代理

K8s集群内每个节点都会运行kube-proxy,负责实现服务的虚拟机IP(不是externalName)。1.0版本的代理模式在是userspace,1.1增加了iptables proxy,从1.2开始 iptables 代理是默认的模式
K8s 1.0的service是三层(TCP/UDP),从k8s1.1开始,增加了Ingress,实现七层(HTTP)服务
用户空间的代理模式
Kube-proxy监控k8s master节点来发现Service、Endpointd的增加和删除,对于Service,在本地打开一个随机端口作为代理端口,任何访问改代理端口的连接都会被指向Service对象的Pod集合,最终指向哪个Pod取决于Service的SessionAffinity,最后,他会配置iptables,捕获流向Service 的Cluster IP 和Port的连接,并重定向到这个代理端口。
最终结果,任何到Service Cluster Ip 和port的流量都会指向合适的Pod
默认情况下,都是轮训算法选择后端,也可以通过设置service.spec.sessionAffinity 为ClientIP,将选择算法改为Client-IP based session affinity
 
Iptables的代理模式
该模式与userspace模式类似,只是没有这个代理端口
比userspace方式更快更可靠,然后与userspace方式不同,当选择的pod异常时,该方式无法自动尝试选择其他Pod。

1、userspace模式只不适合大规模集群使用(数千个服务)
2、userspace模式隐藏了访问服务的源IP,iptables模式虽然没有隐藏源IP,但是也是通过负载均衡或者nodeport 影响了客户端输入
内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: