k8s service

  |  

全部的 K8S学习笔记总目录,请点击查看。

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1
kind: Service
metadata:
name: myblog
namespace: test
spec:
ports:
- protocol: TCP
# 集群内部端口
port: 80
# 容器内部端口
targetPort: 80
selector:
app: myblog
type: ClusterIP

创建 service

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
## 创建服务
$ 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中

1
2
3
4
5
6
7
8
9
# -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如何访问:

1
2
3
4
5
$ 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参考上一节的内容。

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
name: mysql
namespace: test
spec:
ports:
- port: 3306
protocol: TCP
targetPort: 3306
selector:
app: mysql
type: ClusterIP

访问mysql:

1
2
3
4
$ 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的方式做改造:

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

Service负载均衡之NodePort

cluster-ip为虚拟地址,只能在k8s集群内部进行访问,集群外部如果访问内部服务,实现方式之一为使用NodePort方式。NodePort会默认在 30000-32767 ,不指定的会随机使用其中一个。

创建资源配置文件 svc-myblog-nodeport.yaml

1
2
3
4
5
6
7
8
9
10
11
12
13
apiVersion: v1
kind: Service
metadata:
name: myblog-np
namespace: test
spec:
ports:
- port: 80
protocol: TCP
targetPort: 80
selector:
app: myblog
type: NodePort

查看并访问服务:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ 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/

## 浏览器访问

思考:

  1. NodePort的端口监听如何转发到对应的Pod服务?
  2. 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模式

示意图:

services-iptables-overview

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

1
2
3
4
5
6
7
8
9
10
11
12
13
$ 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是运行在每个节点上的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
# 内核开启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不通)

1
$ ping 10.104.58.9

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 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
文章目录
  1. 1. Kubernetes服务访问之Service
  2. 2. Service 负载均衡之Cluster IP
  3. 3. Service负载均衡之NodePort
  4. 4. kube-proxy
    1. 4.1. IPtables模式
    2. 4.2. IPVS模式