Service代理模式

    1. userspace代理模式 client pod -> iptables -> kube-proxy -> server pod
    2. iptables 代理模式 client pod -> iptables -> server pod
    3. ipvs代理模式 client pod -> ipvs -> server pod

    SVC 服务发现 解决IP变动问题
    只能实现4层负责均衡 不具备7层负载均衡
    image.png

    Service 有四种形态
    1.Clusterlp 默认类型 自动分配一个Cluster内部可以访问的虚拟IP
    client pod -> clusterIp,Port - > Server1,Server2,Server3
    image.png
    为了实现图上的功能，主要需要以下几个组件的协同工作：
    apiserver 用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中
    kube-proxy kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中
    iptables 使用NAT等技术将virtualIP的流量转至endpoint中
    deployment信息如下:

    1. apiVersion: apps/v1
    2. kind: Deployment
    3. metadata:
    4.   name: myapp-deploy
    5.   namespace: default
    6. spec:
    7.   replicas: 3
    8.   selector:
    9.     matchLabels:
    10.       app: myapp
    11.       release: stabel
    12.     template:
    13.       metadata:
    14.         labels:
    15.           app: myapp
    16.           release: stabel
    17.           env: test
    18.       spec:
    19.         containers:
    20.         - name: myapp
    21.           image: wangyanglinux/myapp:v2
    22.           imagePullPolicy: IfNotPresent
    23.           ports:
    24.             - name: http
    25.               containerPort: 80

    Service信息如下

    apiVersion: v1
kind: Service
metadata:
  name: myapp
  namespace: default
spec:
  type: ClusterIP
  selector:
    app: myapp
    release: stabel
  ports:
  - name: http
    port: 80
    targetPort: 80

    2.NodePort 在ClusterIP基础上为 Service在每台机器上绑定一个端口 这样可以通过NodePort来访问改服务
    如果你想指定特定的 IP 代理端口，则可以将 kube-proxy 中的 --nodeport-addresses 标志设置为特定的 IP 块。从 Kubernetes v1.10 开始支持此功能。 该标志采用逗号分隔的 IP 块列表（例如，10.0.0.0/8、192.0.2.0/25）来指定 kube-proxy 应该认为是此节点本地的 IP 地址范围。
    例如，如果你使用 --nodeport-addresses=127.0.0.0/8 标志启动 kube-proxy， 则 kube-proxy 仅选择 NodePort Services 的本地回路接口。 --nodeport-addresses 的默认值是一个空列表。 这意味着 kube-proxy 应该考虑 NodePort 的所有可用网络接口。 （这也与早期的 Kubernetes 版本兼容）。
    image.png
    3.LoadBalance 在NodePort基础上 借助云供应商 创建一个外部负载均衡器 并将请求转发到NodePort上把集群外部服务引入到 集群内部 在集群内部直接使用 没有任何代理被创建
    4.ExternalName 这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容( 例如：hub.atguigu.com )。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务。将外部链接导入到内部Service。

    Nginx/LoadBalancer -> NodePort -> Service -> Pod
    个人总结

    1. Service 在集群内部提供了一个虚拟IP，这个虚拟IP在他的生命周期内不会变动，这个IP不能ping，只能与service port一起使用。
    2. 因此可以通过service去访问不断变动IP的Pod。Service通过selector选择 后端提供服务的Pod
    3. Service提供的是集群内的虚拟IP，集群外并不能访问。可以给Service设置NotePort，外部应用可以通过NodeIP+NodePort的方式访问到集群内的Pod
    4. Node存在多个，多个Node IP地址并不能作为统一的入口。于是需要一个LoadBalancer，在公有云上可以使用公有云的NLB/ELB接入解决。