k8s学习之路-k8s service|雪风的小破站

k8s service是k8s中的一个重要组件，它是k8s中的一个抽象层，用来提供一组pod的访问方式，它可以将一组pod的访问方式抽象为一个service，这样就可以通过service来访问这组pod，而不用关心这组pod的具体情况。

Kubernetes服务访问之Service

通过以前的学习，我们已经能够通过Deployment来创建一组Pod来提供具有高可用性的服务。虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两个问题：

Pod IP仅仅是集群内可见的虚拟IP，外部无法访问。
Pod IP会随着Pod的销毁而消失，当ReplicaSet对Pod进行动态伸缩时，Pod IP可能随时随地都会变化，这样对于我们访问这个服务带来了难度。

Service 负载均衡之Cluster IP

service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP 。使用Service对象，通过selector进行标签选择，找到对应的Pod
创建service的yaml文件如下所示 svc-myblog.yaml

apiVersion: v1
kind: Service
metadata:
  name: myblog
  namespace: test
spec:
  ports:
    - protocol: TCP
      # 集群内部端口
      port: 80
      # 容器内部端口
      targetPort: 80
  selector:
    app: myblog
  type: ClusterIP

创建 service

## 创建服务
$ kubectl -n test create -f svc-myblog.yaml
$ kubectl -n test get po --show-labels
NAME                      READY   STATUS    RESTARTS   AGE   LABELS
myblog-84985b5b66-jp9gg   1/1     Running   0          22m   app=myblog,pod-template-hash=84985b5b66
mysql-7f97cb6cc9-vzxpd    1/1     Running   0          13h   app=mysql,pod-template-hash=7f97cb6cc9

$ kubectl -n test get svc
NAME     TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
myblog   ClusterIP   10.104.58.9   <none>        80/TCP    54s

$ kubectl -n test describe svc myblog
Name:              myblog
Namespace:         test
Labels:            <none>
Annotations:       <none>
Selector:          app=myblog
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.104.58.9
IPs:               10.104.58.9
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.2.10:80
Session Affinity:  None
Events:            <none>

## 扩容myblog服务
$ kubectl -n test scale deploy myblog --replicas=2
deployment.extensions/myblog scaled

## 再次查看
$ kubectl -n test describe svc myblog
Name:              myblog
Namespace:         test
Labels:            <none>
Annotations:       <none>
Selector:          app=myblog
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.104.58.9
IPs:               10.104.58.9
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.244.1.5:80,10.244.2.10:80
Session Affinity:  None
Events:            <none>

Service与Pod如何关联:

service对象创建的同时，会创建同名的endpoints对象，若服务设置了readinessProbe,当readinessProbe检测失败时，endpoints列表中会剔除掉对应的pod_ip，这样流量就不会分发到健康检测失败的Pod中

# -l app=myblog 选择label是app=myblog的pod
$ kubectl -n test get po -o wide -l app=myblog
NAME                      READY   STATUS    RESTARTS   AGE   IP            NODE        NOMINATED NODE   READINESS GATES
myblog-84985b5b66-jp9gg   1/1     Running   0          23h   10.244.2.10   k8s-node2   <none>           <none>
myblog-84985b5b66-smpwb   1/1     Running   0          23h   10.244.1.5    k8s-node1   <none>           <none>

$ kubectl -n test get ep myblog
NAME     ENDPOINTS                      AGE
myblog   10.244.1.5:80,10.244.2.10:80   23h

Service Cluster-IP如何访问:

$ kubectl -n test get svc myblog
NAME     TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)   AGE
myblog   ClusterIP   10.104.58.9   <none>        80/TCP    23h

$ curl http://10.104.58.9/

为mysql服务创建service，创建资源配置文件 svc-mysql.yaml，如下所示，具体的导入k8s参考上一节的内容。

apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: test
spec:
  ports:
  - port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app: mysql
  type: ClusterIP

访问mysql：

$ kubectl -n test get svc mysql
kubectl -n test get svc mysql
NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
mysql   ClusterIP   10.110.89.44   <none>        3306/TCP   66s

mysql目前在集群中使用hostNetwork进行部署，通过宿主机ip+port访问，这样有以下几个弊端：

服务使用hostNetwork，使得宿主机的端口大量暴漏，存在安全隐患
容易引发端口冲突
而服务均属于k8s集群，应当尽可能使用k8s的网络访问，由此可以对目前myblog访问mysql的方式做改造：

为mysql创建一个固定clusterIp的Service，把clusterIp配置在myblog的环境变量中
利用集群服务发现的能力，组件之间通过service name来访问

Service负载均衡之NodePort

cluster-ip为虚拟地址，只能在k8s集群内部进行访问，集群外部如果访问内部服务，实现方式之一为使用NodePort方式。NodePort会默认在 30000-32767 ，不指定的会随机使用其中一个。
创建资源配置文件 svc-myblog-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: myblog-np
  namespace: test
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: myblog
  type: NodePort

查看并访问服务：

$ kubectl create -f svc-myblog-nodeport.yaml
service/myblog-np created
$ kubectl -n test get svc
NAME        TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
myblog      ClusterIP   10.104.58.9     <none>        80/TCP         23h
myblog-np   NodePort    10.98.222.213   <none>        80:31174/TCP   38s
mysql       ClusterIP   10.110.89.44    <none>        3306/TCP       8m51s

# 集群内每个节点的NodePort端口都会进行监听
$ curl http://k8s-node1:31174/
$ curl http://k8s-node2:31174/

## 浏览器访问

思考：

NodePort的端口监听如何转发到对应的Pod服务？
CLUSTER-IP为虚拟IP，集群内如何通过虚拟IP访问到具体的Pod服务？

kube-proxy

运行在每个节点上，监听 API Server 中服务对象的变化，再通过创建流量路由规则来实现网络的转发。参照
有三种模式：

User space，让 Kube-Proxy 在用户空间监听一个端口，所有的 Service 都转发到这个端口，然后 Kube-Proxy 在内部应用层对其进行转发，所有报文都走一遍用户态，性能不高，k8s v1.2版本后废弃。
Iptables，当前默认模式，完全由 IPtables 来实现，通过各个node节点上的iptables规则来实现service的负载均衡，但是随着service数量的增大，iptables模式由于线性查找匹配、全量更新等特点，其性能会显著下降。
IPVS，与iptables同样基于Netfilter，但是采用的hash表，因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。 k8s 1.8版本开始引入，1.11版本开始稳定，需要开启宿主机的ipvs模块。

IPtables模式

示意图：

以下是理想情况，因为我一开始就是使用的ipvs模式，所以没有iptables的规则，所以这里的规则是我手动添加的，仅供参考。

$ iptables-save | grep -v myblog-np |grep "test/myblog"
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.99.174.93/32 -p tcp -m comment --comment "test/myblog: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.99.174.93/32 -p tcp -m comment --comment "test/myblog: cluster IP" -m tcp --dport 80 -j KUBE-SVC-WQNGJ7YFZKCTKPZK

$ iptables-save | grep KUBE-SVC-WQNGJ7YFZKCTKPZK
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-GB5GNOM5CZH7ICXZ
-A KUBE-SVC-WQNGJ7YFZKCTKPZK -j KUBE-SEP-7GWC3FN2JI5KLE47

$  iptables-save | grep KUBE-SEP-GB5GNOM5CZH7ICXZ
-A KUBE-SEP-GB5GNOM5CZH7ICXZ -p tcp -m tcp -j DNAT --to-destination 10.244.1.158:80

$ iptables-save | grep KUBE-SEP-7GWC3FN2JI5KLE47
-A KUBE-SEP-7GWC3FN2JI5KLE47 -p tcp -m tcp -j DNAT --to-destination 10.244.1.159:80

面试题： k8s的Service Cluster-IP能不能ping通

IPVS模式

iptables转换ipvs模式，注意，这里需要在每个节点都执行，因为kube-proxy是运行在每个节点上的。

# 内核开启ipvs模块，集群各节点都执行
cat > /etc/sysconfig/modules/ipvs.modules <<EOF
#!/bin/bash
ipvs_modules="ip_vs ip_vs_lc ip_vs_wlc ip_vs_rr ip_vs_wrr ip_vs_lblc ip_vs_lblcr ip_vs_dh ip_vs_sh ip_vs_nq ip_vs_sed ip_vs_ftp nf_conntrack_ipv4"
for kernel_module in \${ipvs_modules}; do
    /sbin/modinfo -F filename \${kernel_module} > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        /sbin/modprobe \${kernel_module}
    fi
done
EOF

chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep ip_vs

# 安装ipvsadm工具
$ yum install ipset ipvsadm -y

# 修改kube-proxy模式
$ kubectl -n kube-system edit cm kube-proxy
...
    kind: KubeProxyConfiguration
    metricsBindAddress: ""
    mode: "ipvs"
    nodePortAddresses: null
    oomScoreAdj: null
...

# 重建kube-proxy
$ kubectl -n kube-system get po | grep kube-proxy | awk '{print $1}' | xargs kubectl -n kube-system delete po

# 查看日志，确认使用了ipvs模式
$ kubectl -n kube-system logs -f 
I0605 08:47:52.334298       1 node.go:136] Successfully retrieved node IP: 172.21.51.143
I0605 08:47:52.334430       1 server_others.go:142] kube-proxy node IP is an IPv4 address (172.21.51.143), assume IPv4 operation
I0605 08:47:52.766314       1 server_others.go:258] Using ipvs Proxier.
...

# 清理iptables规则
$ iptables -F -t nat
$ iptables -F

# 查看规则生效
$ ipvsadm -ln

此时 ping svc 可以通了（理论上是，但是我这里不行，可能是因为我使用的是虚拟机，没有物理网卡，所以ping不通）

$ ping 10.104.58.9

为什么呢？为什么之前的iptables模式下，ping不通，而ipvs模式下，ping可以通呢？

因为ipvs模式下，kube-proxy会在宿主机上创建一个虚拟网卡，service的cluster-ip都会挂到这个网卡上，这样就可以通过ip来访问到service了。

ip a s kube-ipvs0
5: kube-ipvs0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default
    link/ether da:ef:cb:66:0e:22 brd ff:ff:ff:ff:ff:ff
    inet 10.96.0.1/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.96.0.10/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.104.58.9/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.110.89.44/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever
    inet 10.98.222.213/32 scope global kube-ipvs0
       valid_lft forever preferred_lft forever