Kubernetes 外部 HTTP 请求到达 Pod 容器的全过程

简介: Kubernetes 外部 HTTP 请求到达 Pod 容器的全过程

1、问题一

当外部发送一个HTTP/HTTPS 请求到Kubernetes 集群时,它是如何达到 Pod 中的 container 的呢?

2、HTTP 请求流转过程概述图

3、详细过程分析

如第二节图所示,全过程大致为:

  1. 用户从 web/mobile/pc 等客户端发出 HTTP/HTTPS 请求。
  2. 由于应用服务通常是通过域名的形式对外暴露,所以请求将会先进行 DNS 域名解析,得到对应的公网 IP 地址。
  3. 公网 IP 地址通常会绑定一个 Load Balancer 负载均衡器,此时请求会进入此负载均衡器。
• Load Balancer 负载均衡器可以是硬件,也可以是软件,它通常会保持稳定(固定的公网 IP 地址),因为如果切换 IP> 地址会因为 DNS 缓存的原因导致服务某段时间内不可达。     
 • Load Balancer 负载均衡器是一个重要的中间层,对外承接公网流量,对内进行流量的管理和转发。
  1. Load Balancer 再将请求转发到 kubernetes 集群的某个流量入口点,通常是 ingress。
• ingress 负责集群内部的路由转发,可以看成是集群内部的网关。
 
 • ingress 只是配置,具体进行流量转发的是 ingress-controller,后者有多种选择,比如 Nginx、HAProxy、Traefik、Kong 等等。
  1. ingress 根据用户自定义的路由规则进一步转发到 service。
• 比如根据请求的 path 路径或 host 做转发。

  1. service 根据 selector(匹配 label 标签)将请求转发到 pod。
• service 有多种类型,集群内部最常用的类型就是 ClusterIP。
 
 • service 本质上也只是一种配置,这种配置最终会作用到 node 节点上的 kube-proxy 组件,后者会通过设置 iptables/ipvs 来完成实际的请求转发。
 
 • service 可能会对应多个 pod,但最终请求只会被随机转发到一个 pod 上。
  1. pod 最后将请求发送给其中的 container 容器。
• 同一个 pod 内部可能有多个 container,但是多个容器不能共用同一个端口,因此这里会根据具体的端口号将请求发给对应的 container。

以上就是一种典型的集群外部 HTTP 请求如何达到 Pod 中的 container 的全过程。

需要注意的是,由于网络配置灵活多变,以上请求流转过程并不是唯一的方式,例如:

• 如果你使用的是云服务,那么可以通过使用 LoadBalancer 类型的 service 直接绑定一个云服务商提供的负载均衡器,然后再接 ingress 或者其它 service。
  
  • 你也可以通过 NodePort 类型的 service 直接使用节点上的端口,通过这些节点自建负载均衡器。
  
  • 如果你的服务特别简单,没啥内部流量需要管理的,这时不用 ingress 也是可以的。

4、容器技术底座

容器技术的底座有三样东西:

• Namespace(这里是指 Linux 系统内核的命名空间)

• Cgroups

• UnionFS

正是 Linux 内核的 namespace 实现了资源的隔离。因为每个 pod 有各自的 Linux namespace,所以不同的 pod 是资源隔离的。namespace 有多种,包括 PID、IPC、Network、Mount、Time 等等。其中 PID namespace 实现了进程的隔离,因此 pod 内可以有自己的 1 号进程。而 Network namespace 则让每个 pod 有了自己的网络。

5、问题二

Pod 有自己的网络,node 节点也有自己的网络,那么流量是如何从 node 节点到 pod 的呢?

6、详细过程分析(补充)

HTTP 请求流转过程补充

每个 node 节点上都有:

• kubelet:节点的小管家。
  
  • kube-proxy:操作节点的 iptables/ipvs 。
  
  • plugins:
  
  • CRI:容器运行时接口
  
  • CNI:容器网络接口
  
  • CSI(可选):容器存储接口

每个 node 节点有自己的 root namespace,其中也包括网络相关的 root netns,每个 pod 有自己的 pod netns,从 node 到 pod 则可以通过 veth pairs 的方式连通,流量也正是通过此通道进行的流转。而构建 veth pairs、设置 pod network namespace、为 pod 分配 IP 地址等等工作则正是 CNI 的任务。

至此,一个典型的 kubernetes 集群外部的 HTTP/HTTPS 请求如何达到 Pod 中的 container 的全过程就是这样了。


如果停止,就是低谷;如果继续,就是上坡。

相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
目录
相关文章
|
6天前
|
运维 Kubernetes 监控
Kubernetes详解(十九)——Kubernetes Pod控制器
Kubernetes详解(十九)——Kubernetes Pod控制器
24 3
|
11天前
|
运维 Kubernetes 网络协议
Kubernetes详解(十六)——Pod容器探测
Kubernetes详解(十六)——Pod容器探测
40 1
|
2天前
|
Kubernetes 算法 调度
k8s群集调度之 pod亲和 node亲和 标签指定
k8s群集调度之 pod亲和 node亲和 标签指定
|
2天前
|
存储 Kubernetes Linux
pod介绍之 容器分类与重启策略
pod介绍之 容器分类与重启策略
|
5天前
|
弹性计算 Kubernetes 监控
【阿里云弹性计算】阿里云 ECS 与 Kubernetes 集成:轻松管理容器化应用
【5月更文挑战第28天】阿里云ECS与Kubernetes集成,打造强大容器管理平台,简化应用部署,实现弹性扩展和高效资源管理。通过Kubernetes声明式配置在ECS上快速部署,适用于微服务和大规模Web应用。结合监控服务确保安全与性能,未来将深化集成,满足更多业务需求,引领容器化应用管理新趋势。
20 2
|
6天前
|
运维 Prometheus Kubernetes
基于Kubernetes的容器化运维实践
本文将介绍如何在Kubernetes平台上进行容器化运维。首先,我们将了解Kubernetes的基本概念和组件。然后,我们将探讨如何部署和管理应用程序,以及如何使用Kubernetes进行自动化运维。最后,我们将讨论一些最佳实践和常见问题解答。通过阅读本文,您将能够更好地理解Kubernetes在现代IT环境中的重要性,并学会如何有效地利用它来提高运维效率。
|
11天前
|
存储 运维 分布式计算
分布式云容器平台ACK One概述
分布式云容器平台ACK One概述
32 2
|
11天前
|
运维 Kubernetes 网络协议
Kubernetes详解(十八)——Pod就绪性探针实战
Kubernetes详解(十八)——Pod就绪性探针实战
46 5
|
11天前
|
Kubernetes 网络协议 应用服务中间件
Kubernetes详解(十七)——Pod存活性探针应用实战
Kubernetes详解(十七)——Pod存活性探针应用实战
28 4
|
应用服务中间件 调度 nginx
Kubernetes-项目中pod调度使用法则
前言kubernetes中部署的pod默认根据资源使用情况自动调度到某个节点。可在实际项目的使用场景中都会有更细粒度的调度需求,比如:某些pod调度到指定主机、某几个相关的服务的pod最好调度到一个节点上、Master节点不允许某些pod调度等。
2024 0