大浪网站建设 优帮云,linux系统服务器怎么做网站,用户体验设计的概念,国外做网站网站安全吗Service概述
抽象层
k8s的Service是一种抽象层#xff0c;用于为一组具有相同功能的Pod提供一个统一的入口地址#xff0c;并通过负载均衡将网络流量分发到这些Pod上。 Service解决了Pod动态变化的问题#xff0c;例如Pod的IP地址和端口可能会发生变化#xff0c;通过…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实现虚拟IPVIP的形式。从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 --port8080 --target-port80#查看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: nginx02name: nginx02
spec:selector:app: nginx02ports:- port: 8080protocol: TCPtargetPort: 803、使用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类型的servicekubectl expose deploy nginx02 --port8080 --target-port80 --typeNodePort#查看service端口对应的真实主机映射的端口是多少kubectl get service 2、通过NodePort暴露的端口访问到集群
在上一步骤中得知对外暴露的端口为32361在浏览器上输出真实主机IP:端口进行访问。 三、ExternalName
ExtenlName将服务通过DNS CNAME 记录方式转发到指定的域名
在访问的时候service过程如下
client —— test.domain.org (service) —— pod(n) 直接用ip访问应用里边的地址可能会改变 1、创建externalName
[rootmaster test]# vim ex-service.yaml
apiVersion: v1
kind: Service
metadata:name: nginx02
spec:type: ExternalNameexternalName: test.domain.org 2、安装域名测试工具
sudo yum install bind-utils -y 3、测试验证
[kubeadmserver1 ~]$ sudo yum install bind-utils -y ##安装测试软件[kubeadmserver1 ~]$ 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
[kubeadmserver1 ~]$
[kubeadmserver1 ~]$
[kubeadmserver1 ~]$ 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[kubeadmserver1 ~]$[kubeadmserver1 ~]$ 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
[kubeadmserver1 ~]$ 四、LoadBalancer
从外部访问的Service的第二种方式 是用于共有云上的Kubernetes服务这时候可以指定一个LoadBalancer类型的Service。
在service提交后Kubernetes就会调用CloudProvider 在共有云上 你可以创建一个负载均衡服务并且把代理的pod的IP 地址配置给负载均衡服务做后缀。共有云、阿里云、亚马逊。
在外部的公有云上才可以创建 因为要收费 五、创建一个对外访问的指定IP和端口 1、创建Service
#执行yaml文件
[rootmaster test]# cat exposeIpService-2.yamlapiVersion: v1 ##版本
kind: Service ##类型
metadata:name: nginx02 ##名称
spec:ports:- name: nginx02 ##端口服务名称port: 8080 ##外部访问的端口号targetPort: 80 ##转发的端口号selector:app: nginx02externalIPs:- 192.168.72.133 ##创建一个供外部访问的共有ip[rootmaster 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_rrlsmod | 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 modeipvs#查看是否已经更新
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 --replicas5 八、VIP 和 Service 代理的区别
VIP和Kubernetes Service代理的区别主要体现在定义、功能、实现方式以及应用场景等方面。
定义和功能
VIP虚拟IPVIP是一个全局唯一的虚拟IP地址用于集群内部服务的访问。它不是一个物理IP地址而是通过负载均衡器或DNS解析来指向实际的物理服务器或服务实例。VIP通常用于实现高可用性和负载均衡确保服务故障时的自动切换。
Kubernetes ServiceKubernetes Service定义了一个服务的访问入口地址前端应用通过这个入口地址访问其背后的一组由Pod副本组成的集群实例。Service通过Label Selector与后端Pod副本集群对接实现负载均衡和会话保持机制。Service不是共用一个负载均衡器的IP而是被分配了一个全局唯一的虚拟IP地址称为Cluster IP。
实现方式
VIP通常通过硬件负载均衡器或软件负载均衡器来实现如F5 BIG-IP或Keepalived等。这些工具负责将VIP指向实际的服务器或服务实例实现高可用和负载均衡。
Kubernetes ServiceKubernetes通过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博客
更详细信息可参考之前写的博客k8s6——— service详解_qmfjs-CSDN博客
官网信息https://kubernetes.io/zh-cn/docs/concepts/services-networking
