Kubernetes 详解-Replica Sets 和Service
原文地址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 影响了客户端输入