k8s基础(4)—Kubernetes-Service

Service概述

抽象层

‌k8s的Service是一种抽象层，用于为一组具有相同功能的Pod提供一个同一的入口地点，并通过负载均衡将网络流量分发到这些Pod上。‌ Service解决了Pod动态变化的题目，例如Pod的IP地点和端口大概会发生变化，通过Service可以提供稳定的访问地点和负载均衡功能，从而屏蔽后端Endpoint的变化。‌
Service的作用

‌服务发现‌：Service通过标签选择器（Label Selector）与Pod关联，提供稳定的访问地点，纵然Pod的IP地点发生变化，客户端仍旧可以通过Service访问到服务。
‌负载均衡‌：Service可以将网络流量分发到后端的多个Pod上，提供负载均衡的功能，确保服务的可用性和扩展性。
‌抽象层‌：Service提供了一种抽象层，使得客户端不需要关心具体的Pod细节，只需要通过Service的地点进行访问。
Service的类型

k8s中的Service有四种类型：
‌ClusterIP‌：默认类型，为集群内部提供一个虚拟IP，只能在集群内部访问。
‌NodePort‌：在每台机器上绑定一个端口，可以通过NodeIP来访问该服务。
‌LoadBalancer‌：在NodePort的基础上，创建一个外部负载均衡器，将请求转发到NodeIP。
‌ExternalName‌：将集群外部的服务引入到集群内部，直接使用外部服务的名称，没有任何代理被创建。
Service的工作原理

在k8s集群中，每个Node运行一个kube-proxy进程，负责为Service实现虚拟IP（VIP）的情势。从k8s v1.2版本起，默认使用Iptables代理模式，从v1.8.0-beta.0版本开始，添加了ipvs代理模式。

一、ClusterIP‌

ClusterIP‌：默认类型，为集群内部提供一个虚拟IP，只能在集群内部访问。
实验配景

   启动3个nginx pod 每一个节点的nginx设置相关的访问信息
  pod1——> web1
  pod2——> web2
  pod3 ——> web3
  修改nginx的访问页面

方便区分service是否实现了负载均衡

pod2、pod3按照上边的操作步调进行。


测试查看了设置是否见效

访问pod节点IP，检查设置是否乐成。

1、使用下令行进行操作

1. #给nginx02工作负载节点暴露端口8080指向后端的80端口
2. kubectl expose deploy nginx02 --port=8080 --target-port=80
4. #查看service产生的虚拟IP
5. kubectl get service
7. #删除service命令
8. kubectl delete service nginx02
10. #查看每组pod的标签
11. kubectl get pods --show-labels

复制代码

1.1 负载均衡测试

1. crul 192.168.72.130:8080

复制代码

2、使用yaml文件进行操作

1. apiVersion: v1
2. kind: Service
3. metadata:
4.   labels:
5.     run: nginx02
6.   name: nginx02
7. spec:
8.   selector:
9.     app: nginx02
10.   ports:
11.     - port: 8080
12.       protocol: TCP
13.       targetPort: 80

复制代码

3、使用Service产生的虚拟IP进行访问

1. #在服务器上进行查看产生的虚拟IP信息
2. kubectl get service

复制代码

4、通过域名进行访问

命名的规则是: 服务名.所在名称空间.scv
如：上述实验对应的域名为: nginx02.default.svc
   curl nginx02.default.svc:8080
  不过此方法仅限于在运行的容器pod中进行，如果在外部无法访问

在pod中访问乐成

二、NodeIP

NodePort‌：在每台机器上绑定一个端口，可以通过NodeIP来访问该服务。
NodePort会随机在每个pod之间生成一个端口范围在30000-32767之间。

1、使用下令行创建NodeIP

1. #创建NodePort类型的service
2. kubectl expose deploy nginx02 --port=8080 --target-port=80 --type=NodePort
4. #查看service端口对应的真实主机映射的端口是多少
5. kubectl get service

复制代码

2、通过NodePort袒露的端口访问到集群

在上一步调中得知对外袒露的端口为32361，在欣赏器上输出真实主机IP:端口进行访问。

三、ExternalName

ExtenlName：将服务通过DNS CNAME 记载方式转发到指定的域名
在访问的时候service过程如下：
client ——> test.domain.org (service) ——> pod(n) 直接用ip访问应用里边的地点大概会改变


1、创建externalName

1. [root@master test]# vim ex-service.yaml
2. apiVersion: v1
3. kind: Service
4. metadata:
5.   name: nginx02
6. spec:
7.   type: ExternalName
8.   externalName: test.domain.org

复制代码

2、安装域名测试工具

1. sudo yum install bind-utils -y

复制代码

3、测试验证

1. [kubeadm@server1 ~]$ sudo yum install bind-utils -y     ##安装测试软件
3. [kubeadm@server1 ~]$ kubectl get svc -n kube-system     ##查看dns 对应的ClusterIP
4. NAME       TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
5. kube-dns   ClusterIP   10.96.0.10   <none>        53/UDP,53/TCP,9153/TCP   8d
6. [kubeadm@server1 ~]$
7. [kubeadm@server1 ~]$
8. [kubeadm@server1 ~]$ dig -t A test.domain.org @10.96.0.10      ##测试
10. ; <<>> DiG 9.9.4-RedHat-9.9.4-61.el7 <<>> -t A test.westos.ortg @10.96.0.10
11. ;; global options: +cmd
12. ;; Got answer:
13. ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 23243
14. ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
15. ;; WARNING: recursion requested but not available
17. ;; OPT PSEUDOSECTION:
18. ; EDNS: version: 0, flags:; udp: 4096
19. ;; QUESTION SECTION:
20. ;test.westos.ortg.        IN    A
22. ;; Query time: 1255 msec
23. ;; SERVER: 10.96.0.10#53(10.96.0.10)
24. ;; WHEN: Mon Mar 02 09:35:40 EST 2020
25. ;; MSG SIZE  rcvd: 45
27. [kubeadm@server1 ~]$
29. [kubeadm@server1 ~]$ kubectl describe svc nginx02
30. Name:              my-nginx
31. Namespace:         default
32. Labels:            <none>
33. Annotations:       <none>
34. Selector:          <none>
35. Type:              ExternalName
36. IP:               
37. External Name:     test.domain.org
38. Session Affinity:  None
39. Events:            <none>
40. [kubeadm@server1 ~]$

复制代码

四、LoadBalancer

从外部访问的Service的第二种方式 是用于共有云上的Kubernetes服务，这时候，可以指定一个LoadBalancer类型的Service。
在service提交后，Kubernetes就会调用CloudProvider 在共有云上 你可以创建一个负载均衡服务，而且把代理的pod的IP 地点设置给负载均衡服务做后缀。（共有云、阿里云、亚马逊）。
在外部的公有云上才可以创建 （因为要收费）



五、创建一个对外访问的指定IP和端口



1、创建Service

1. #执行yaml文件
2. [root@master test]# cat exposeIpService-2.yaml
4. apiVersion: v1                  ##版本
5. kind: Service                   ##类型
6. metadata:
7.   name: nginx02                 ##名称
8. spec:
9.   ports:
10.     - name: nginx02             ##端口服务名称
11.       port: 8080                ##外部访问的端口号
12.       targetPort: 80            ##转发的端口号
13.   selector:
14.       app: nginx02
15.   externalIPs:
16.     - 192.168.72.133             ##创建一个供外部访问的共有ip
18. [root@master test]# kubectl get service      #查看service是否创建成功
19. NAME         TYPE        CLUSTER-IP      EXTERNAL-IP      PORT(S)    AGE
20. kubernetes   ClusterIP   10.96.0.1       <none>           443/TCP    10d
21. nginx02      ClusterIP   10.96.103.205   192.168.72.133   8080/TCP   8m38s

复制代码

2、访问测试

六、服务发现机制验证



1、将缩容节点从负载均衡中剔除

将一个pod节点缩容后，再重新扩容到之前的副本数，通过Service可以访问到新扩容节点的信息。

2、将扩容节点添加到负载均衡中

对节点进行扩容之后，Service能够发现并将扩容的pod节点重新加入集群中，此时访问会出现web1、web2和nginx的原始页面信息，因为web3在上一步调的缩容中已经被删除，重新扩容之后为新节点的信息。



七、开启kube-proxy的IPVS模式 



1、为什么要使用IPVS取代iptables

IPVS和iptables对比说明

service代理默认使用iptables规则通过内核模块netfilter实现流量转发，内核转发服从高，但是iptables不具备更为灵活的负载均衡战略，只是将流量随意的转发至后端Pod，当Pod不可用时也无法进行健康检查；就以下是将默认流量转发修改为ipvs。
kubernetes自1.8版本开始强推ipvs，之前版本默认使用iptables，是比较古老的一种网络模式。
ipvs接纳的hash表，iptables接纳一条条的规则列表。集群数量越多iptables规则就越多，而 iptables规则是从上到下匹配，所以服从就越是低下。因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而进步service的服务性能。
kubernetes在版本v1.6中已经支持5000个节点，但使用iptables 的 kube-proxy 实际上是将集群扩展到5000个节点的瓶颈。 在5000节点集群中使用 NodePort 服务，如果有2000个服务而且每个服务有10个 pod，这将在每个工作节点上至少产生20000个iptable 记载，这大概使内核非常繁忙。因此，如果是大集群的话，iptables大概会造成集群瓦解。
IPVS模式与iptables同样基于Netfilter，作为linux内核的一部分实现传输层负载均衡的技术，通常称为第4层LAN交换。但是ipvs接纳的hash表（性能更加高效），Iptables接纳一条条的规则列表。
iptables 模式

iptables 是一个 Linux 内核功能，是一个高效的防火墙，并提供了大量的数据包处置惩罚和过滤方面的能力。它可以在核心数据包处置惩罚管线上用 Hook 挂接一系列的规则。iptables 模式中 kube-proxy 在 NAT pre-routing Hook 中实现它的 NAT 和负载均衡功能。这种方法简单有效，依赖于成熟的内核功能，而且能够和其它跟 iptables 协作的应用（例如 Calico）融洽相处。
然而 kube-proxy 的用法是一种 O(n) 算法，其中的 n 随集群规模同步增长，这里的集群规模，更明白的说就是服务和后端 Pod 的数量。
IPVS 模式

IPVS 是一个用于负载均衡的 Linux 内核功能。IPVS 模式下，kube-proxy 使用 IPVS 负载均衡取代了 iptable。这种模式同样有效，IPVS 的计划就是用来为大量服务进行负载均衡的，它有一套优化过的 API，使用优化的查找算法，而不是简单的从列表中查找规则。
如许一来，kube-proxy 在 IPVS 模式下，其连接过程的复杂度为 0。换句话说，多数情况下，他的连接处置惩罚服从是和集群规模无关的。
另外作为一个独立的负载均衡器，IPVS 包含了多种差别的负载均衡算法，例如轮询、最短期望耽误、最少连接以及各种哈希方法等。而 iptables 就只有一种随机平等的选择算法。
IPVS 的一个潜伏缺点就是，IPVS 处置惩罚数据包的路径和通常情况下 iptables 过滤器的路径是差别的。如果计划在有其他步伐使用 iptables 的情况中使用 IPVS，需要进行一些研究，看看他们是否能够协调工作。（Calico 已经和 IPVS kube-proxy 兼容）


2、安装ipvsadm服务

各个节点上的内核一定要装有ip_vs_rr 这是ipvsadm见效的前提

1. #查看内核是否已经安装ip_vs_rr
2. lsmod | grep ip_vs
4. #安装ipvsadm服务
5. yum install ipvsadm -y

复制代码

3、开启kube-proxy 的povs模式

1. #查看IPVS中是否有策略
2. ipvsadm -ln
4. #开启kube-proxy的povs模式
5. kubectl -n kube-system edit cm kube-proxy      ##改为IPVS mode"ipvs"
7. #查看是否已经更新
8. kubectl get pod -n kube-system -o wide | grep kube-proxy | awk '{system("kubectl delete pod "$1" -n kube-system")}'
10. #查看更新是否成功
11. kubectl get pod -n kube-system -o wide -w

复制代码

4、验证IPVS战略是否见效

开启firewalld防火墙服务iptables战略失效，此时可以对集群的pod进行扩容，如果能够正常扩容说明IPVS已经见效。

1. #将之前的2个副本扩容到5个
2. kubectl scale deploy/nginx02 --replicas=5

复制代码

八、VIP 和 Service 代理的区别

VIP和Kubernetes Service代理的区别重要表现在界说、功能、实现方式以及应用场景等方面。‌
界说和功能

‌VIP（虚拟IP）‌：VIP是一个全局唯一的虚拟IP地点，用于集群内部服务的访问。它不是一个物理IP地点，而是通过负载均衡器或DNS解析来指向实际的物理服务器或服务实例。VIP通常用于实现高可用性和负载均衡，确保服务故障时的自动切换。
‌Kubernetes Service‌：Kubernetes Service界说了一个服务的访问入口地点，前端应用通过这个入口地点访问其背后的一组由Pod副本组成的集群实例。Service通过Label Selector与后端Pod副本集群对接，实现负载均衡和会话保持机制。Service不是共用一个负载均衡器的IP，而是被分配了一个全局唯一的虚拟IP地点，称为Cluster IP‌。
实现方式

‌VIP‌：通常通过硬件负载均衡器或软件负载均衡器来实现，如F5 BIG-IP或Keepalived等。这些工具负责将VIP指向实际的服务器或服务实例，实现高可用和负载均衡。
‌Kubernetes Service‌：Kubernetes通过kube-proxy进程实现Service代理。kube-proxy运行在每个Node上，负责将请求转发到后端的Pod实例。Kubernetes支持多种代理模式，包括iptables和ipvs等，具体使用哪种模式取决于Kubernetes的版本和设置‌。
应用场景

‌VIP‌：适用于需要高可用性和负载均衡的场景，如数据库、Web服务器等关键服务。VIP确保在服务故障时能够快速切换到备用服务器，减少服务中断时间。
‌Kubernetes Service‌：适用于微服务架构中的应用，通过Service抽象服务访问入口，简化应用摆设和维护。
在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的情势，而不是 ExternalName 的情势。

参考资料：
参考资料：k8s Service 服务 - misakivv - 博客园
IPVS设置参考文档：Kubernetes 当中启用IPVS模式_kubernetes ipvs-CSDN博客
更详细信息可参考之前写的博客：k8s（6）——— service详解_qmfjs-CSDN博客
官网信息：https://kubernetes.io/zh-cn/docs/concepts/services-networking

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。