service

Pod 对象的动态性会给客户端带来困扰
Pod资源对象存在生命周期，不可重现，必要时仅能创建一个新的替代者
Pod对象在其控制器进行应用规模伸缩时，同一个应用程序的Pod对象会增加和减少，service资源为动态管理的Pod对象添加一个有着固定访问入口的抽象层
service通过标签选择器关联拥有相关标签的Pod对象
客户端向service进行请求，而非目标Pod对象。
service后面有endPoint，service为中间层，还可以关联Node节点上的程序如MySQL，service，及proxy Mode
简单来讲，一个service 对象就是工作节点上的一组iptables或ipvs规则，用于将
到达service对象IP地址的流量调度转发至相应的Endpoint对象指向的IP地址和端口
工作于每个工作节点的kube-proxy组件通过API Server持续监控着各service及关联的Pod对象。并将其创建或变动时反映至当前工作节点上相应的iptables和ipvs规则
kube-proxy把申请请求代理至相关节点的方式有三种
userspace(用户空间），iptables和ipvs
userspace代理模型：userspace指linux操作系统上的“用户空间”
对于每个service对象，kube-proxy会随机打开一个本地端口，任何到达此代理端口的连接请求都将被通过DNAT转发至当前service资源对象的后端各Pod对象
kubernetes1.1及之前版本的默认模型，默认调度算法是round-robin
kube-proxy 还会此类的service对象创建iptables规则以捕获任何到达ClusterIP 和端口的流量

image.png

client -> iptables 转发至kube-proxy，kube-proxy起一个调度作用，通过iptables到pod
iptables代理模式
对于每个service对象，kube-proxy会创建iptables规则，直接捕获到到达clusterIP和port的流量，并将其重定向当前service对象后端Pod资源
对于每个Endpoints对象，service资源会为其创建iptables规则并关联至挑选的后端Pod资源对象，相对于用户空间模型来说，iptables模型无须将流量在用户空间和内核空间来回切换，因此也更为高效和可靠

ipvs代理模式

kubernetes的1.9-alpine 起引入ipvs代理模型，且自1.11版本起成为默认设置
kube-proxy跟踪API server上service 和Endpoints对象的变动，据此来调用netlink接口创建ipvs规则，并确保与API server的变动保持同步。它与iptables规则的不同之处仅在其请求流量的调度功能，由ipvs实现，余下的其他功能仍由iptables完成
类似于iptables模型，ipvs构建与netfilter的钩子函数上，但它使用hash表作为底层数据结构并工作于内核空间，因此具有流量转发速度快，规则同步性能好的特性，另外ipvs还支持众多调度算法例如: rr lc dn sh sed 和nq等
注意：所有的service只能使用一种调度算法

image.png

定义service资源

kubectl explain svc
[root@k8s-master basic]# cat myapp-svc.yaml 
apiVersion: v1
kind: Service
metadata:
  name: myapp-svc
  namespace: default
spec:
  ports:
   - name: http
     port: 81
     targetPort: 80
  selector:
     app: myapp

port: 为service的端口
targetPort：为Pod的端口
kubectl describe svc myapp-svc  
查看后端端点：kubectl get endpoints

service类型

ClusterIP

1、客户端Pod对象访问服务端，Pod对象不会进行源地址转换。
二者在同一主机时，源地址为客户端Pod地址
二者在不同主机时，源地址为客户端Pod所在点的flannel或cni接口

image.png

ClusterIP类型，为k8s内部资源访问，不能被外部访问到

NodePort

外部客户端的请求要求发往某个特定的节点的<NodeIP>:<NodePort>,此时对于服务端来说，源地址为当前节点的IP

image.png

[root@k8s-master basic]# cat myapp-nodeport.yaml 
apiVersion: v1
kind: Service
metadata:
  name: myapp-nodeport
  namespace: default
spec:
  type: NodePort
  ports:
   - nodePort: 30080
     name: http
     port: 81
     targetPort: 80
  selector:
     app: myapp

loadBalancer 类型，为NodePort类型引入自动管理的外部负载均衡器，向底层cloud provider的API发请求，由其按需创建用户也可以手动提供负载均衡器，但它不属于LoadBalancer

image.png

ExternalName

将集群外部service引入集群内部供各Pod客户端使用

image.png

引入外部服务的另一个方法
service不定义标签选择器，手动创建endpoint资源，让endpoint关联不是k8s的内部IP和Port
kubectl explain endpoints