ServiceType字段的合法值是:
ClusterIP: 仅仅使用一个集群内部的IP地址 - 这是默认值。选择这个值意味着你只想这个服务在集群内部才可以被访问到。
NodePort: 在集群内部IP的基础上,在集群的每一个节点的端口上开放这个服务。你可以在任意<NodeIP>:NodePort地址上访问到这个服务。
LoadBalancer: 在使用一个集群内部IP地址和在NodePort上开放一个服务之外,向云提供商申请一个负载均衡器,会让流量转发到这个在每个节点上以<NodeIP>:NodePort的形式开放的服务上。
Service:
Protocol:支持tcp和udp协议,默认情况下是tcp协议;
targetPort:后端调度pod暴露的端口,连接到服务的端口;
Ports: server监听的端口
情况1. 在生传中svc会在selector定义调度 创建pod的时定义的标签(调度方式为默认为轮询);
情况2. 如果需要调度的pod的没有定义标签,或者就想单独匹配某个pod的IP地址
Services without(为咯特) selectors(没有选择器的服务)的使用场景:
1:比如你希望有一个额外的数据库云在生产环境中,但是在测试的时候,我们希望使用自己的数据库
2:我们希望将服务指向其它的服务或者其它命名空间或者其它的云平台上的服务
3:我们正在向kubernete迁移,并且我们后台并没有在Kubernete中
如上的情况下,我们可以定义一个服务没有选择器
如果需要调度的pod的没有定义标签,或者就想单独匹配某个pod的IP地址可以这样:
Subsets可以指定一个IP地址addresses
{
“kind”: “Endpoints”,
“apiVersion”: “v1″,
“metadata”: {
“name”: “my-service”
},
“subsets”: [
{
“addresses”: [
{ “IP”: “1.2.3.4” }
],
“ports”: [
{ “port”: 80 }
]
}
]
}
Virtual IPs and service proxies(虚拟IP和服务代理)
Nodeport的访问方式:
如果你选择了“NodePort”,那么 Kubernetes master 会分配一个区域范围内,(默认是30000-32767),并且,每一个node,都会代理(proxy)这个端口到你的服务中,我们可以在spec.ports[*].nodePort 找到具体的值
如果我们向指定一个端口,我们可以直接写在nodePort上,系统就会给你指派指定端口,但是这个值必须是指定范围内的。
这样的话就能够让开发者搭配自己的负载均衡器,去撘建一个kubernete不是完全支持的系统,又或者是直接暴露一个node的ip地址
Multi-每一个节点上都运行了一个kube-proxy,这个应用监控着Kubermaster增加和删除服务,对于每一个服务,kube-proxy会随机开启一个本机端口,任何发向这个端口的请求都会被转发到一个后台的Pod当中,而如何选择是哪一个后台的pod的是基于SessionAffinity进行的分配。kube-proxy会增加iptables rules来实现捕捉这个服务的Ip和端口来并重定向到前面提到的端口。
最终的结果就是所有的对于这个服务的请求都会被转发到后台的Pod中,这一过程用户根本察觉不
默认的,后台的选择是随机的,基于用户session机制的策略可以通过修改service.spec.sessionAffinity 的值从NONE到ClientIP
Port Services(多端口服务)
可能很多服务需要开发不止一个端口,为了满足这样的情况,Kubernetes允许在定义时候指定多个端口,当我们使用多个端口的时候,我们需要指定所有端口的名称,这样endpoints才能清楚,例如
{
“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
}
]
}
}
我们可以在创建服务的时候指定IP地址,将spec.clusterIP的值设定为我们想要的IP地址即可
Discovering services(服务的发现)
我们常用的server服务发现功能:在创建svc的kubernetes会自动在dnx中注册一个A记录,直接访问这个svc的名字即.
Headless services(无头服务)
特点
1.headless service相较于一般service的区别在于不分配culsterIP;
2.解析普通service通过core-dns的集群内域名将返回clusterIP, headless service则将返回所有Pod的地址和集群内域名。 当然,只有statefulSet部署的Pod才会有集群内域名