Linux企业应用——kubernates（六）之Service服务

一、什么是服务（Service）

它是指将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。
使用 Kubernetes，你无需修改应用程序即可使用不熟悉的服务发现机制。 Kubernetes 为 Pod 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。
动机创建和销毁 Kubernetes Pod 以匹配集群的期望状态。 Pod 是非永久性资源。 如果你使用 Deployment 来运行你的应用程序，则它可以动态创建和销毁 Pod。
每个 Pod 都有自己的 IP 地址，但是在 Deployment 中，在同一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。
这导致了一个问题： 如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能， 那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用提供工作负载的后端部分？
进入 Services。

Service资源

Kubernetes Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。 Service 所针对的 Pod 集合通常是通过选择算符来确定的。 要了解定义服务端点的其他方法，请参阅不带选择算符的服务。
举个例子，考虑一个图片处理后端，它运行了 3 个副本。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化， 前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。
Service 定义的抽象能够解耦这种关联。

Service理解

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

二、创建svc.yaml

利用命令创建一个svc模板yaml文件，并修改

[root@k8s1 ~]# kubectl expose deployment deployment-example --port 80 --target-port 80 --dry-run=client -o yaml >svc.yaml
[root@k8s1 ~]# ls
anaconda-ks.cfg  deployment.yaml   liveness.yaml        original-ks.cfg          svc.yaml
cronjob.yaml     job.yaml          nginx-1.21.1         pod.yaml
daemonset.yaml   kube-flannel.yml  nginx-1.21.1.tar.gz  replicaset-example.yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  name: svc1
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: ClusterIP

生效svc1.yaml，并查看

[root@k8s1 ~]# vim svc.yaml
[root@k8s1 ~]# kubectl apply -f svc.yaml
service/svc1 created
[root@k8s1 ~]# kubectl get svc
NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP   11d
liveness-http   ClusterIP   10.99.7.186     <none>        80/TCP    17h
svc1            ClusterIP   10.98.180.114   <none>        80/TCP    6s

[root@k8s1 ~]# kubectl describe svc svc1
Name:              svc1
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=nginx
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.98.180.114
IPs:               10.98.180.114
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.36:80,10.244.2.44:80,10.244.2.45:80
Session Affinity:  None
Events:            <none>
[root@k8s1 ~]# iptables -t nat -nL |grep :80
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/svc1 */ tcp to:10.244.2.45:80
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/svc1 */ tcp to:10.244.1.36:80
DNAT       tcp  --  0.0.0.0/0            0.0.0.0/0            /* default/svc1 */ tcp to:10.244.2.44:80
KUBE-SVC-DZERXHZGH3HKTTEJ  tcp  --  0.0.0.0/0            10.98.180.114        /* default/svc1 cluster IP */ tcp dpt:80
KUBE-MARK-MASQ  tcp  -- !10.244.0.0/16        10.98.180.114        /* default/svc1 cluster IP */ tcp dpt:80

三、IPVS模式的service

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

开启kube-proxy的ipvs模式：

[root@k8s1 ~]#  kubectl edit cm kube-proxy -n kube-system
configmap/kube-proxy edited

切换之后要进行重启容器，更新kube-proxy pod

 kubectl get pod -n kube-system |grep kube-proxy | awk'{system("kubectl delete pod "$1" -n kube-system")}'

此时使用ipvsadm查看svc，发现比iptables更为简洁

[root@k8s1 ~]# ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  10.96.0.1:443 rr
  -> 10.244.3.12:6443             Masq    1      0          0
TCP  10.96.0.10:53 rr
  -> 10.244.0.2:53                Masq    1      0          0
  -> 10.244.0.3:53                Masq    1      0          0
TCP  10.96.0.10:9153 rr
  -> 10.244.0.2:9153              Masq    1      0          0
  -> 10.244.0.3:9153              Masq    1      0          0
TCP  10.98.180.114:80 rr
  -> 10.244.1.36:80               Masq    1      0          0
  -> 10.244.2.44:80               Masq    1      0          0
  -> 10.244.2.45:80               Masq    1      0          0
TCP  10.99.7.186:80 rr
UDP  10.96.0.10:53 rr
  -> 10.244.0.2:53                Masq    1      0          0
  -> 10.244.0.3:53                Masq    1      0          0

切换为ipvs模式，一是可以减少CPU资源消耗，二是可以支持更多Pod
IPVS模式下，kube-proxy会在service创建后，在宿主机上添加一个虚拟网卡：kube-ipvs0，并分配service IP
kube-proxy通过linux的IPVS模块，以rr轮询方式调度service中的Pod

四、flannel插件

k8s通过CNI接口接入其他插件来实现网络通讯。目前比较流行的插件有flannel，calico等。
CNI插件存放位置：# cat /etc/cni/net.d/10-flannel.conflist
插件使用的解决方案如下：
• 虚拟网桥，虚拟网卡，多个容器共用一个虚拟网卡进行通信。
• 多路复用：MacVLAN，多个容器共用一个物理网卡进行通信。
• 硬件交换：SR-LOV，一个物理网卡可以虚拟出多个接口，这个性能最好。
• 容器间通信：同一个pod内的多个容器间的通信，通过lo即可实现；
• pod之间的通信：
• 同一