【K8S】外部访问请求原理流程(service、kube-proxy、pod的关系)

这篇具有很好参考价值的文章主要介绍了【K8S】外部访问请求原理流程(service、kube-proxy、pod的关系)。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。


简单流程

kube-proxy ingress,k8s,kubernetes
用户发起请求,请求传送到Ingress
Ingress :作用是定义请求如何转发到service的规则,ingress支持7层代理转发,它可以通过根据不同的域名或者URL访问路径把请求流量转发到不同的service上,实现调度不同业务域、不同URL访问路径的业务流量。
Service: 提供了服务的负载均衡和反向代理的能力,发来的请求通过负载均衡 4层代理转发到它所关联的后端pod上。
KubeDNS:依靠DNS进行解析,将域名解析成DNS获得虚拟IP。
Kube-proxy:对虚拟IP的请求按策略转发给后端,通过不同的工作模式设置不同的转发规则,确定转发到哪个pod上。

一、Ingress

为什么要发明 Ingress 这个概念呢?
其一重要原因:为了便于服务动态发现和负载均衡,利用不同的 path 路径来访问不同的服务,实现负载均衡。

Ingress 可以把进入到集群内部的请求转发到集群中的一些服务上,从而可以把服务映射到集群外部。Ingress 能把集群内 Service 配置成外网能够访问的 URL,流量负载均衡,提供基于域名访问的虚拟主机等。

Ingress Controller 可以理解为控制器,它通过不断的跟 Kubernetes API 交互,实时获取后端
Service、Pod 的变化,比如新增、删除等,结合 Ingress 定义的规则生成配置,然后动态更新上边的 Nginx 或者 trafik 负载均衡器,并刷新使配置生效,来达到服务自动发现的作用
工作流程如下图:
kube-proxy ingress,k8s,kubernetes

二、Service

1.关键概念

为了方便访问Pod资源,k8s定义了一个统一访问入口:service资源对象。
Service是一个固定接入层,客户端可以通过访问service的IP和端口访问到service关联的后端Pod。Service能够提供负载均衡的能力,但是在使用上有以下限制:只提供 4 层负载均衡能力,而没有 7 层功能,但有时我们可能需要更多的匹配规则来转发请求,这点上 4 层负载均衡是不支持的。

2.Service类型以及使用案例:

1) ClusterIP:

kubernetes :默认类型,是集群内部访问的方式,外部是无法访问的。其主要用于为集群内Pod访问时,提供的固定访问地址,默认是自动分配地址,可使用 ClusterIP 关键字指定固定IP。(特殊用法,无头服务headless,添加字段ClusterIP: None,直连pod)

kind: Service
apiVersion: v1
metadata:
  name: my-svc
spec:
  type: ClusterIP
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

2) NodePort

NodePort 是将主机 IP 和端口跟 kubernetes 集群所需要暴露的 IP 和端口进行关联,方便其对外提供服务。内部可以通过 ClusterIP 进行访问,外部用户可以通过 NodeIP:NodePort 的方式单独访问每个Node 上的实例。(备注,nodeport端口的开放是集群性质的,所以任意节点都可以访问,另外注意如果不指定nodeport端口,默认从30000-32767端口随机分配)

kind: Service
apiVersion: v1
metadata:
  name: my-svc
spec:
  type: NodePort
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080 #(此处指定了端口,可不写,用随机指定)

拓展:
service 的三种端口:
port :service 暴露在 cluster IP 上的端口,port 是提供给集群内部客户访问 service 的入口。
nodePort :nodePort 是 k8s 提供给集群外部客户访问 service 入口的一种方式。
targetPort :targetPort 是 pod 中容器实例上的端口,从 port 和 nodePort 上到来的数据最终经过 kube-proxy 流入到后端 pod 的 targetPort 上进入容器。

port、nodePort 总结:
port 和 nodePort 都是 service 的端口,前者暴露给集群内客户访问服务,
后者暴露给集群外客户访问服务。从这两个端口到来的数据都需要经过反向代理 kube-proxy 流入后端 pod 的 targetPort,从而到达 pod 上的容器内。

3) LoadBalancer

对外暴露应用,适用于公有云
LoadBalancer 类型的 service 是可以实现集群外部访问服务的另外一种解决方案。不过并不是所有的k8s集群都会支持,大多是在公有云托管集群中会支持该类型。负载均衡器是异步创建的,关于被提供的负载均衡器的信息将会通过 Service 的 status.loadBalancer 字段被发布出去。是kubernetes针对云服务商提供的svc资源类型,本地无法演示,可以写出来但是资源会处于pending状态。

apiVersion: v1
kind: Service
metadata:
  name: loadbalancer
spec:
  type: LoadBalancer
  selector:
    app: nginx
  ports:
     - port: 80
       targetPort: 80

4)ExternalName:
ExternalName Service 是 Service 的一个特例,它没有选择器,也没有定义任何端口或Endpoints。它的作用是返回集群外 Service 的外部别名。它将外部地址经过集群内部的再一次封装(实际上就是集群DNS 服务器将CNAME解析到了外部地址上),实现了集群内部访问即可。例如你们公司的镜像仓库,最开始是用ip 访问,等到后面域名下来了再使用域名访问。你不可能去修改每处的引用。但是可以创建一个 ExternalName,首先指向到ip,等后面再指向到域名。相当于dns的域名回源,用的较少,也得注意kubernetes的dns插件版本,过低的版本是不支持该功能的。

参考 : 文章链接

三、Kube-proxy

1.简介

提供网络代理和负载均衡,是实现 service 的通信与负载均衡机制的重要组件,kube-proxy 负责为 Pod 创建代理服务,从 apiserver 获取所有 service 信息,并根据 service 信息创建代理服务,对虚拟IP的请求按策略转发给后端,通过不同的工作模式设置不同的转发规则,实现 service 到 Pod 的请求路由和转发,从而实现 Kubernetes层级的虚拟转发网络,将到service 的请求转发到后端的 pod 上。

2.三种代理模式的介绍

kube-proxy ingress,k8s,kubernetes

参考 :文章链接

1)userspace模式:

(该模式已弃用)userspace这种模式下,kube-proxy 持续监听 Service 以及 Endpoints 对象的变化;对每个 Service,它都为其在本地节点开放一个端口,作为其服务代理端口;发往该端口的请求会采用一定的策略转发给与该服务对应的后端 Pod 实体。kube-proxy 同时会在本地节点设置 iptables 规则,配置一个 Virtual IP,把发往 Virtual IP 的请求重定向到与该 Virtual IP 对应的服务代理端口上。其工作流程大体如下:
kube-proxy ingress,k8s,kubernetes

2)IPtables模式:

iptables 模式与 userspace 相同,kube-proxy 持续监听 Service 以及 Endpoints 对象的变化;但它并不在本地节点开启反向代理服务,而是把反向代理全部交给 iptables (iptables讲解)来实现;即 iptables 直接将对 VIP 的请求转发给后端 Pod,通过 iptables 设置转发策略。其工作流程大体如下:
kube-proxy ingress,k8s,kubernetes

3)ipvs模式:

与iptables、userspace 模式一样,kube-proxy 依然监听Service以及Endpoints对象的变化, 不过它并不创建反向代理, 也不创建大量的 iptables 规则, 而是通过netlink 创建ipvs规则,并使用k8s Service与Endpoints信息,对所在节点的ipvs规则进行定期同步; netlink 与 iptables 底层都是基于 netfilter 钩子,但是 netlink 由于采用了 hash table 而且直接工作在内核态,在性能上比 iptables 更优。其工作流程大体如下:

kube-proxy ingress,k8s,kubernetes

四、service与kube-proxy与pod的关系

kube-proxy ingress,k8s,kubernetes
1.Service:服务访问入口
门口的侍客,承接客人的所有要求。
2.Pod:业务容器
真正干活的人,产出者,接触不到客人。
3.Endpoints:管理 Pod
管理者,接触不到客人。
4.Kube-proxy:转发
大堂联络人,建立侍客与干活人的直接联系,接触不到客人
具有负载均衡模块,建立 iptables 或 ipvs 规则,使客人的要求从侍客直达干活人。文章来源地址https://www.toymoban.com/news/detail-795797.html


到了这里,关于【K8S】外部访问请求原理流程(service、kube-proxy、pod的关系)的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 玩转k8s(四)—— 通过Service访问Pod

            我们不应该期望k8s Pod是健壮的,而是要假设Pod中的容器很可能因为各种原因发生故障而死掉。Deployment等Controller会通过动态的创建和销毁Pod来保证应用整体的健壮性。换句话说, Pod是脆弱的,但应用是健壮的 。         每个Pod都有自己的IP地址,当Controller用新的

    2024年02月05日
    浏览(38)
  • k8s 自身原理之 Service

    好不容易,终于来到 k8s 自身的原理之 关于 Service 的一部分了 前面我们用 2 个简图展示了 pod 之间和 pod 与 node 之间是如何通信息的,且通信的数据包是不会经过 NAT 网络地址转换 的 Service 我们知道是用来对外暴露服务的 ip 和 端口的,好让外部的客户端可以访问到我们内部

    2024年02月12日
    浏览(37)
  • 外部节点访问 k8s 集群内的 starrocks

    用kubeadm在虚拟机搭建了k8s,按starrocks官网步骤,用k8s部署了starrocks 部署成功: 在 k8s集群内节点访问到 sr:(通过 clusterIP )  k8s 节点内访问成功: ​​​​​​​  尝试在集群外访问sr:  修改完成后查看端口 集群外部的客户端访问不了,错误是 BE 节点 not found 本地无法

    2024年02月13日
    浏览(41)
  • k8s中部署nginx-ingress实现外部访问k8s集群内部服务

    k8s通过nginx-ingress实现集群外网访问功能 1.1 ingress 工作原理 step1:ingress contronler通过与k8s的api进行交互,动态的去感知k8s集群中ingress服务规则的变化,然后读取它,并按照定义的ingress规则,转发到k8s集群中对应的service。 step2:而这个ingress规则写明了哪个域名对应k8s集群中的

    2024年02月07日
    浏览(37)
  • 从外部访问K8s中Pod的五种方式

    hostNetwork、 hostPort、 NodePort、 LoadBalancer、 Ingress 暴露Pod与Service一样,因为Pod就是Service的backend 这是一种直接定义 Pod 网络的方式。 如果在 Pod 中使用 hostNetwork:true 配置, pod 中运行的应用程序可以直接看到 pod 启动的主机的网络接口。 在主机的所有网络接口上都可以访问到该

    2024年02月12日
    浏览(36)
  • k8s外部访问pod内部容器的端口-NodePort

    Kubernetes的Pod IP和Cluster IP都只能在集群内部访问,而我们通常需要从外部网络上访问集群中的某些服务,Kubernetes提供了下述几种方式来为集群提供外部流量入口。 有一pod,里面有rabbitmq服务,先想从外部通过ip:15672访问MQ的管理员界面查看队列消费情况。 方法1(pod会重启): 方法

    2023年04月23日
    浏览(32)
  • k8s自定义Endpoint实现内部pod访问外部应用

    endpoint除了可以暴露pod的IP和端口还可以代理到外部的ip和端口 使用场景 公司业务还还没有完成上云, 一部分云原生的,一部分是实体的 业务上云期间逐步实现上云,保证各个模块之间的解耦性 比如使用云数据库或者实体数据库服务器啥的,因为像数据库实现容器化的话在

    2024年01月25日
    浏览(50)
  • k8s kube-proxy详解

    kube-proxy是kubernetes中网络核心组件,实现了服务暴露和转发等网络功能。kube-proxy支持userspace,ipvs和iptables三种代理模式。userspace性能问题较严重,基本不再使用,应用最多的是iptables和ipvs模式。 kube-proxy 以daemonset的方式运行在每个Node计算节点上,负责Pod网络代理, 它会定时通

    2024年02月10日
    浏览(57)
  • 持续集成部署-k8s-服务发现-Service:Service、Endpoint、Pod之间的关系与原理

    在 Kubernetes 中, Service 是一种抽象的逻辑概念,用于将一组具有相同功能的 Pod 组合成一个逻辑服务。 Service 提供了一种稳定的 IP 地址和 DNS 域名,供客户端访问这个逻辑服务。同时, Service 还提供了负载均衡、会话保持等功能,可以很方便地实现服务发现与调用。 在 Kuber

    2024年02月06日
    浏览(48)
  • K8S应用流程安全(镜像安全 配置管理 访问安全)

    1.1.1 构建原则 学习目标 这一节,我们从 基础知识、原则解读、小结 三个方面来学习。 基础知识 k8s平台使用业务环境 需求 镜像的使用流程 Docker镜像加载 UnionFS 原则解读 构建样式 构建原则 实践原则 分层效果 功能效果 小结 1.1.2 Dockerfile实践 学习目标 这一节,我们从 基础

    2024年02月13日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包