全部的 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> $ 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 $ 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的方式做改造:
为mysql创建一个固定clusterIp的Service,把clusterIp配置在myblog的环境变量中
利用集群服务发现的能力,组件之间通过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 $ 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的规则,所以这里的规则是我手动添加的,仅供参考。
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 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$ yum install ipset ipvsadm -y $ kubectl -n kube-system edit cm kube-proxy ... kind: KubeProxyConfiguration metricsBindAddress: "" mode: "ipvs" nodePortAddresses: null oomScoreAdj: null ... $ kubectl -n kube-system get po | grep kube-proxy | awk '{print $1}' | xargs kubectl -n kube-system delete po $ 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 -F -t nat $ iptables -F $ ipvsadm -ln
此时 ping svc 可以通了 (理论上是,但是我这里不行,可能是因为我使用的是虚拟机,没有物理网卡,所以ping不通)
为什么呢?为什么之前的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