一、service简介

Service可以看作是一组提供相同服务的Pod对外的访问接口。借助Service，应用可以方便地实现服务发现和负载均衡。
• service默认只支持4层负载均衡能力，没有7层功能。（可以通过Ingress实现）
service的类型：
• ClusterIP：默认值，k8s系统给service自动分配的虚拟IP，只能在集群内部访问。
• NodePort：将Service通过指定的Node上的端口暴露给外部，访问任意一个NodeIP:nodePort都将路由到ClusterIP。
• LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部的负载均衡器，并将请求转发到 NodeIP:NodePort，此模式只能在云服务器上使用。
• ExternalName：将服务通过 DNS CNAME 记录方式转发到指定的域名（通过spec.externlName 设定）。

二、定义service

一个 Service 在 Kubernetes 中是一个 REST 对象，和 Pod 类似。 像所有的 REST 对象一样， Service 定义可以基于 POST 方式，请求 API server 创建新的实例。

例如，假定有一组 Pod，它们对外暴露了 9376 端口，同时还被打上 app=MyApp 标签。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

上述配置创建一个名称为 “my-service” 的 Service 对象，它会将请求代理到使用 TCP 端口 9376，并且具有标签 “app=MyApp” 的 Pod 上。 Kubernetes 为该服务分配一个 IP 地址（有时称为 “集群IP” ），该 IP 地址由服务代理使用。服务选择器的控制器不断扫描与其选择器匹配的 Pod，然后将所有更新发布到也称为 “my-service” 的Endpoint对象。
注意： 需要注意的是， Service 能够将一个接收 port 映射到任意的 targetPort。 默认情况下，targetPort 将被设置为与 port 字段相同的值。
更改service的type为NodePort，kubectl edit svc myservice

三、ipvs模式的service

Service 是由 kube-proxy 组件，加上 iptables 来共同实现的.
• kube-proxy 通过 iptables 处理 Service 的过程，需要在宿主机上设置相当多的iptables 规则，如果宿主机有大量的Pod，不断刷新iptables规则，会消耗大量的CPU资源。
• IPVS模式的service，可以使K8s集群支持更多量级的Pod。
开启kube-proxy的ipvs模式：

 yum install -y ipvsadm //所有节点安装
 kubectl edit cm kube-proxy -n kube-system
 kubectl get pod -n kube-system |grep kube-proxy | awk '{system("kubectl delete pod "$1" -n kube-system")}'

可以通过服务来访问
这样当集群ip或者nodeport变化时不会影响访问结果

查看集群dns地址
解析集群ip
Headless Service “无头服务”
Headless Service不需要分配一个VIP，而是直接以DNS记录的方式解析出被代理Pod的IP地址。
域名格式：$(servicename).$(namespace).svc.cluster.local

在pod更新ip以后通过域名也可以访问
调用外部的公有云生成负载均衡器slb，用户在访问时先访问公有云上的负载均衡器，在访问后端的NodePort

集群内部的pod如何访问集群外部的资源
外部资源名称改变时不影响集群内部pod的访问

service允许为其分配一个公有IP
公有IP必须是合法ip

四、Flanner vxlan模式跨主机通信原理

node1节点上的container-1和node2节点上的container2进行通信
真实实验环境：
server2节点上的pod的ip为10.244.2.65，server2的IP为172.20.10.2
server3节点上的pod的ip为10.244.5.104，server3的IP为172.20.10.3
数据包的源地址为10.244.5.104，目标地址为10.244.2.65，是两个不同的网段
container-1中的数据包通过cni0，flannel.1，eth0进入node2中
首先查看server2上的主机路由，可以看到数据包出去是通过cni0，进入5网段需要通过网关10.244.5.0，走的设备是flannel.1
源地址ip：10.244.2.65，mac地址：2e:57:5f:4d:3f:d4
目标地址ip：10.244.5.104，mac地址：e6:33:f0:0a:6b:52
要通过eth0出去，需要知道server3上的ip的mac地址00:0c:29:9f:4f:5a

五、Ingress 服务

Ingress由两部分组成：Ingress controller和Ingress服务。
Ingress Controller 会根据你定义的 Ingress 对象，提供对应的代理能力。业界常用的各种
反向代理项目，比如 Nginx、HAProxy、Envoy、Traefik 等，都已经为Kubernetes 专门维
护了对应的 Ingress Controller。

ingress-nginx是以service的NodePort的方式暴露pod的

六、Ingress TLS 配置

七、Ingress 认证配置

使得nginx能够识别认证文件
secret卷应用到pod内