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、使用命令行进行操作

#给nginx02工作负载节点暴露端口8080指向后端的80端口
kubectl expose deploy nginx02 --port=8080 --target-port=80

#查看service产生的虚拟IP
kubectl get service

#删除service命令
kubectl delete service nginx02

#查看每组pod的标签
kubectl get pods --show-labels

1.1 负载均衡测试

crul 192.168.72.130:8080

2、使用yaml文件进行操作

apiVersion: v1
kind: Service
metadata:
  labels:
    run: nginx02
  name: nginx02
spec:
  selector:
    app: nginx02
  ports:
    - port: 8080
      protocol: TCP
      targetPort: 80

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

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

4、通过域名进行访问

命名的规则是: 服务名.所在名称空间.scv

如：上述实验对应的域名为: nginx02.default.svc

curl nginx02.default.svc:8080

不过此方法仅限于在运行的容器pod中进行，如果在外部无法访问

在pod中访问成功

二、NodeIP

NodePort‌：在每台机器上绑定一个端口，可以通过NodeIP来访问该服务。

NodePort会随机在每个pod之间生成一个端口范围在30000-32767之间。

1、使用命令行创建NodeIP

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

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

在上一步骤中得知对外暴露的端口为32361，在浏览器上输出真实主机IP:端口进行访问。

三、ExternalName

ExtenlName：将服务通过DNS CNAME 记录方式转发到指定的域名

在访问的时候service过程如下：

client ——> test.domain.org (service) ——> pod(n) 直接用ip访问应用里边的地址可能会改变

1、创建externalName

[root@master test]# vim ex-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx02
spec:
  type: ExternalName
  externalName: test.domain.org

2、安装域名测试工具

sudo yum install bind-utils -y

3、测试验证

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

四、LoadBalancer

从外部访问的Service的第二种方式是用于共有云上的Kubernetes服务，这时候，可以指定一个LoadBalancer类型的Service。

在service提交后，Kubernetes就会调用CloudProvider 在共有云上你可以创建一个负载均衡服务，并且把代理的pod的IP 地址配置给负载均衡服务做后缀。（共有云、阿里云、亚马逊）。

在外部的公有云上才可以创建（因为要收费）

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

1、创建Service

#执行yaml文件
[root@master test]# cat exposeIpService-2.yaml

apiVersion: v1                  ##版本
kind: Service                   ##类型
metadata:
  name: nginx02                 ##名称
spec:
  ports:
    - name: nginx02             ##端口服务名称
      port: 8080                ##外部访问的端口号
      targetPort: 80            ##转发的端口号
  selector:
      app: nginx02
  externalIPs:
    - 192.168.72.133             ##创建一个供外部访问的共有ip
 
[root@master test]# kubectl get service      #查看service是否创建成功
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP      PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1       <none>           443/TCP    10d
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生效的前提

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

3、开启kube-proxy 的povs模式

#查看IPVS中是否有策略
ipvsadm -ln

#开启kube-proxy的povs模式
kubectl -n kube-system edit cm kube-proxy      ##改为IPVS mode"ipvs"

#查看是否已经更新
kubectl get pod -n kube-system -o wide | grep kube-proxy | awk '{system("kubectl delete pod "$1" -n kube-system")}'

#查看更新是否成功
kubectl get pod -n kube-system -o wide -w

4、验证IPVS策略是否生效

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

#将之前的2个副本扩容到5个
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的版本和配置‌。