Kubernetes 集群外部的 HTTP/HTTPS 请求是如何达到 Pod 中的 container 的？
如上图所示，全过程大致为：
(1) 用户从 web/mobile/pc 等客户端发出 HTTP/HTTPS 请求。
(2) 由于应用服务通常是通过域名的形式对外暴露，所以请求将会先进行 DNS 域名解析，得到对应的公网 IP 地址。
(3) 公网 IP 地址通常会绑定一个 Load Balancer 负载均衡器，此时请求会进入此负载均衡器。
(4) Load Balancer 再将请求转发到 kubernetes 集群的某个流量入口点，通常是 ingress。
(5) ingress 根据用户自定义的路由规则进一步转发到 service。
(6) service 根据 selector（匹配 label 标签）将请求转发到 pod。
(7) pod 最后将请求发送给其中的 container 容器。
同一个 pod 内部可能有多个 container，但是多个容器不能共用同一个端口，因此这里会根据具体的端口号将请求发给对应的 container。
以上就是一种典型的集群外部 HTTP 请求如何达到 Pod 中的 container 的全过程。
需要注意的是，由于网络配置灵活多变，以上请求流转过程并不是唯一的方式，例如：
如果你使用的是云服务，那么可以通过使用 LoadBalancer 类型的 service 直接绑定一个云服务商提供的负载均衡器，然后再接 ingress 或者其它 service。
你也可以通过 NodePort 类型的 service 直接使用节点上的端口，通过这些节点自建负载均衡器。
如果你的服务特别简单，没啥内部流量需要管理的，这时不用 ingress 也是可以的。
容器技术的底座有三样东西：
正是 Linux 内核的 namespace 实现了资源的隔离。因为每个 pod 有各自的 Linux namespace，所以不同的 pod 是资源隔离的。namespace 有多种，包括 PID、IPC、Network、Mount、Time 等等。其中 PID namespace 实现了进程的隔离，因此 pod 内可以有自己的 1 号进程。而 Network namespace 则让每个 pod 有了自己的网络。
Pod 有自己的网络，node 节点也有自己的网络，那么流量是如何从 node 节点到 pod 的呢？
每个 node 节点上都有：
(1)kubelet：节点的小管家。
(2)kube-proxy：操作节点的 iptables/ipvs 。
(3)plugins:
每个 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 的全过程就是这样了。
参考资料：
本文链接：http://www.28at.com/showinfo-26-54961-0.htmlKubernetes 外部 HTTP 请求到达 Pod 容器的全过程
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
下一篇： 我们一起聊聊枚举规范化
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
