🐇明明跟你说过：个人主页
🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅
🔖行路有良友，便是天堂🔖
目录
一、前言
1、k8s概述
Kubernetes单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。
Kubernetes（简称K8s）的前世今生可以追溯到谷歌（Google）内部的一个项目，它起源于2003年，当时谷歌正面临着不断增长的应用程序和服务的管理挑战。这个项目最初被称为"Borg"，是一个早期的容器编排系统。Borg 的成功经验成为 Kubernetes 开发的契机。
有关k8s起源的介绍，请参考《初识K8s之前世今生、架构、组件、前景》这篇文章
Kubernetes的优点包括可移植性、可伸缩性和扩展性。它使用轻型的YAML清单文件实现声明性部署方法，对于应用程序更新，无需重新构建基础结构。管理员可以计划和部署容器，根据需要扩展容器并管理其生命周期。借助Kubernetes的开放源代码API，用户可以通过首选编程语言、操作系统、库和消息传递总线来构建应用程序，还可以将现有持续集成和持续交付（CI/CD）工具集成。
2、四层代理的概念
在Kubernetes (k8s) 中，四层代理是指在OSI七层网络模型中的第四层（传输层）进行的代理服务。这种代理主要处理基于TCP或UDP协议的流量，不涉及HTTP等应用层协议的具体内容。
在Kubernetes环境中，四层代理主要用于Service对象的网络通信。当创建一个Kubernetes Service时，可以选择不同的Service类型来暴露Pod的应用服务。
通过这样的机制，即使Pod的IP地址发生变化，客户端仍然可以通过稳定的Service IP地址访问服务，并且能够自动负载均衡，从而实现了服务的高可用性和无状态性，以及Pod层面的动态管理。
二、Service的类型
1、ClusterIP
在Kubernetes中，Service的ClusterIP类型是一种定义一组Pod网络访问规则的抽象方式。具体来说，ClusterIP为Service分配一个内部IP地址，使得该Service只能在集群内部被访问。这个IP地址是一个虚拟的IP地址，用于连接客户端和Pod。它主要用于服务发现和负载均衡，确保集群内部的流量能够按照预期的方式流动。
ClusterIP类型的Service通常用于后端服务，如数据库或缓存服务，这些服务主要供集群内部的其他组件使用，而不需要从集群外部直接访问。此外，由于ClusterIP仅在集群内部有效，它提供了一定程度的安全性，可以防止未经授权的外部访问。
2、NodePort
NodePort是Kubernetes中Service的一种类型，它提供了一种将Service暴露到集群外部的方式。具体来说，NodePort会在每个集群节点上打开一个特定的端口，然后将来自该端口的流量转发到对应的Service。NodePort会为Service分配一个静态的端口号（通常是30000-32767的范围），并将该端口映射到Service的端口。
通过集群节点的IP地址和指定的NodePort端口号，可以从集群外部访问到相应的Service。这使得NodePort类型的Service特别适合需要从外部访问集群中的服务的场景，例如开发和测试环境。并且，NodePort也可以用于将Kubernetes内部的服务与集群外的现有服务进行关联，例如连接到外部的数据库或其他资源。
3、LoadBalancer
Service的LoadBalancer类型是Kubernetes中用于将流量从集群外部的负载均衡器路由到集群内的服务的一种机制。这种Service类型通常用于公共云环境，如AWS、GCP、Azure等，或其他支持这种负载均衡机制的环境中。
当创建一个LoadBalancer类型的Service时，Kubernetes会根据云提供商的支持自动创建一个负载均衡器，并为该Service分配一个外部IP地址。这个负载均衡器会动态地将外部流量转发到后端Pod。通过这种方式，用户可以通过分配的外部IP地址直接访问Kubernetes集群中的服务。
除了自动创建负载均衡器和分配IP地址外，LoadBalancer类型的Service还提供了负载均衡和动态调整的能力。负载均衡器会根据Pod的健康状况和负载情况进行动态调整，确保流量能够均匀地分发到各个Pod上，并提供高可用性和可扩展性
4、ExternalName
在Kubernetes中，Service的类型ExternalName是一种特殊的类型，它用于将服务映射到一个外部的DNS名称，而不是典型的选择器（如Pod标签）来选择一组Pod实例来提供服务。通过使用ExternalName，可以在Kubernetes集群内部为外部服务创建一个别名，这样集群内的Pod就可以通过这个名字来访问外部服务。
具体来说，当为Service指定ExternalName类型时，需要使用spec.externalName字段来指定要映射的外部DNS名称。一旦创建了这个Service，Kubernetes就会将对该Service的DNS查询解析为指定的外部DNS名称，从而允许集群内的Pod通过该Service名称来访问外部服务。
三、四层代理Service的原理
1、Service的发现机制
k8s在创建Service时，会根据标签选择器selector(lable selector)来查找Pod，据此创建与Service同名的endpoint对象，当Pod 地址发生变化时，endpoint也会随之发生变化，service接收前端client请求的时候，就会通过endpoint，找到转发到哪个Pod进行访问的地址。(至于转发到哪个节点的Pod，由负载均衡kube-proxy决定)。
2、iptables与ipvs代理模式的比较
iptables与ipvs代理模式在Kubernetes环境中各自扮演着不同的角色，具有不同的特点和适用场景。
下面是对这两种代理模式的比较：
1. 性能：
- IPVS：IPVS是一种高效的Layer-4交换机，专为负载均衡设计。它使用基于哈希的负载均衡算法，能够快速处理大量的并发连接，因此在性能方面通常表现更好。适用于集群规模较大或Service数量较多的场景，能够提供更好的吞吐和速度。
- iptables：iptables是社区传统的kube-proxy模式，性能可能会受到规则数量和链的复杂度的影响。当集群中Service数量较少或客户端会出现大量并发短连接时，iptables可能是一个合适的选择。然而，当集群规模扩大或Service数量增多时，iptables可能会出现网络延迟的情况。
2. 工作原理：
- IPVS：IPVS基本上是一种高效的Layer-4交换机，它提供负载平衡的功能。当一个TCP连接的初始SYN报文到达时，IPVS就选择一台服务器，将报文转发给它。此后，通过查发报文的IP和TCP报文头地址，确保此连接的后继报文被转发到相同的服务器。
- iptables：iptables并不是实现防火墙功能的软件，而是一个中间代理程序。用户通过iptables软件写入的安全规则，最终会被netfilter包过滤型防火墙写入到内核空间的安全框架中。iptables主要工作在网络层，实现客户端到目标端的安全策略，通过过滤数据包中的header信息来匹配防火墙规则，决定是否放行或阻止进入。
3. 支持的协议：
- IPVS：支持TCP、UDP和SCTP协议的负载均衡。
- iptables：通常用于处理IP层和TCP/UDP层的防火墙规则。
4. 配置方式：
- IPVS：配置是基于集群中的Service和Endpoint对象，由Kube-proxy直接与内核交互进行配置。
- iptables：模式下的Kube-proxy会生成一系列的iptables规则来实现服务代理。
iptables和IPVS在性能、工作原理、支持的协议和配置方式等方面都存在差异。在选择使用哪种代理模式时，需要根据具体的需求和集群环境的特点来决定。对于大规模集群或需要处理大量并发连接的场景，IPVS可能更适合；而对于较小规模的集群或需要处理防火墙规则的场景，iptables可能是一个更合适的选择。
3、kube-proxy的工作流程
首先，kube-proxy会在每个节点上运行，并监听Kubernetes API Server中的Service和Endpoints对象的变化。当新的Service或Endpoint被添加、更新或移除时，API Server会将这些更改通知给kube-proxy。
接下来，kube-proxy会根据配置的模式（iptables或IPVS）来更新节点的网络规则。在iptables模式下，kube-proxy会动态地修改iptables规则，确保每个Service都能够正确路由到对应的后端Pod。而在IPVS模式下，kube-proxy则使用Linux内核提供的IPVS技术来进行高效的负载均衡，支持多种负载均衡算法。
一旦网络规则更新完成，kube-proxy就会将Service的IP和端口映射成节点本地的一个端口进行代理。这样，当客户端发送请求到Service的IP和端口时，kube-proxy会根据网络规则将请求转发到相应的后端Pod。
在转发过程中，kube-proxy还会根据配置的负载均衡策略（如轮询或会话亲和力）来选择具体的后端Pod进行请求分发。这样可以确保流量的均匀分布和服务的稳定性。
4、kube-proxy三种工作模式
kube-proxy在Kubernetes集群中有三种主要的工作模式：Userspace模式、iptables模式和IPVS模式。
1. Userspace模式：
- 在这种模式下，kube-proxy通过在主机上创建一个userspace进程来实现服务代理。该进程会拦截所有服务流量，并根据服务配置信息将流量转发到后端Pod。具体地说，kube-proxy会观察Kubernetes中service和endpoint对象的变化，当有新的service创建时，所有节点的kube-proxy会在node节点上随机选择一个端口，并在iptables中追加一条把访问service的请求重定向到这个端口的记录。然后，kube-proxy开始监听这个端口的连接请求。然而，这种模式的缺点是性能损耗，因为请求数据需要到kube-proxy的用户空间中才能决定真正要转发的实际服务地址。
- 在Userspace模式下，kube-proxy收到报文后，会通过Round Robin（轮询）或者Session Affinity（会话亲和力，即同一Client IP都走同一链路给同一Pod服务）分发给对应的Pod。
2. iptables模式：
- 从Kubernetes 1.2开始，iptables模式被引入并在之后的版本中作为默认模式。在这种模式下，kube-proxy不再使用用户空间代理进行转发，而是直接利用Linux内核的iptables规则来实现服务的转发。当创建或删除服务时，kube-proxy会动态更新主机上的iptables规则，以将服务的虚拟IP地址映射到后端Pod的IP地址。
- 由于iptables模式直接在内核层面进行转发，因此性能通常比Userspace模式要高。
3. IPVS模式：
- IPVS模式是基于Linux内核中的IPVS模块实现的。IPVS是一个高效的Layer-4交换机，专为负载均衡设计，它允许kube-proxy在大量服务和高并发环境下实现高性能的负载均衡。
- 与iptables模式相比，IPVS模式具有更好的性能，特别是在处理大量服务和连接时。此外，IPVS还提供了更丰富的负载均衡算法和更灵活的转发策略。
💕💕💕每一次的分享都是一次成长的旅程，感谢您的陪伴和关注。希望这些关于Kubernetes的文章能陪伴您走过技术的一段旅程，共同见证成长和进步！😺😺😺
🧨🧨🧨让我们一起在技术的海洋中探索前行，共同书写美好的未来！！！
1114
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
