V2AS问路
Kubernetes hostPort 使用
阅读原文时间：2023年08月18日阅读：10

在 Kubernetes 中，hostPort 是一种用于将主机上的特定端口映射到运行在 Pod 内部容器的端口的配置选项。通过使用 hostPort，你可以在主机上暴露容器的服务，从而允许外部网络通过主机的 IP 地址和指定的端口访问容器内的应用程序。如：

apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-v1-deployment
spec:
replicas: 2
selector:
matchLabels:
app: tomcat-v1
template:
metadata:
labels:
app: tomcat-v1
spec:
containers:
- name: tomcat
image: tomcat
ports:
- containerPort: 8080
hostPort: 9000

注意 1：hostPort 与 NodePort 的区别是，NodePort 服务默认是把请求转发到随机的一个运行的 Pod 上，而 hostPort 是直接转发到本 Node 上的指定 Pod。

一个 Node 只能启动一个 hostPort，所以最初是用于把守护进程集（DaemonSets）部署到每个 Node (确保一个 Node 只有一个 hostPort )。如下图所示，3个 Node 上部署4个带 hostPort 的 Pod，会有一个不成功。

即便是3个 Node 上部署3个带 hostPort 的 Pod 滚动升级时也会有问题，所以使用 hostPort 的服务在升级的时候一定要保障先停掉旧版本的 Pod 实例再启动新版本的 Pod 实例，服务升级这块内容配置详情可以参见 《Kubernetes应用编排与管理 —— Deployment升级策略》这篇博文。

讲到 hostPort 就不得不提 hostNetwork。hostNetwork 也是一种用于将主机上的特定端口映射到运行在 Pod 内部容器的端口的配置选项，对于客户端来说这两种访问方式都是一样的，但是它们的原理却大不相同，下面说一下 hostPort 与 hostNetwork 的异同。

相同点：

  1. hostPort 与 hostNetwork 本质上都是终端用户能访问到pod中的业务；
  2. 访问的时候，只能用 pod所有宿主机IP + 容器端口或 hostport 端口进行访问。

不同点：

  1. 网络地址空间不同。hostport使用CNI分配的地址，hostNetwork使用宿主机网络地址空间；
  2. 宿主机端口生成。hostport宿主机不生成端口，hostNetwork宿主机生成端口；
  3. hostport通过 iptables 防火墙的 nat 表进行转发，hostNetwork 直接通过主机端口到容器中；
  4. 定义的路径不同。deploy.spec.template.spec.containers.ports.hostPort 与 deploy.spec.template.spec.hostNetwork；
  5. 优先级不同，hostNetwork 高于 hostPort。

hostPort 截图：

hostNetwork 截图：

（1）示例环境

当前示例Kubernetes集群节点信息如下（共五个节点，k8s版本为1.21.14）：

[root@master1 ~]# kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
master1 Ready control-plane,master 19d v1.21.14 10.20.32.201 Kylin Linux Advanced Server V10 (Lance) 4.19.90-52.22.v2207.ky10.x86_64 docker://20.10.9
master2 Ready control-plane,master 19d v1.21.14 10.20.32.202 Kylin Linux Advanced Server V10 (Lance) 4.19.90-52.22.v2207.ky10.x86_64 docker://20.10.9
master3 Ready control-plane,master 19d v1.21.14 10.20.32.203 Kylin Linux Advanced Server V10 (Lance) 4.19.90-52.22.v2207.ky10.x86_64 docker://20.10.9
worker1 Ready worker 19d v1.21.14 10.20.32.204 Kylin Linux Advanced Server V10 (Lance) 4.19.90-52.22.v2207.ky10.x86_64 docker://20.10.9
worker2 Ready worker 19d v1.21.14 10.20.32.205 Kylin Linux Advanced Server V10 (Lance) 4.19.90-52.22.v2207.ky10.x86_64 docker://20.10.9

当前集群kube-proxy模式为ipvs：

[root@master1 ~]# kubectl get configmaps -n=kube-system kube-proxy -o yaml|grep mode
mode: ipvs

（2）示例

启动一个 Pod 示例，其是使用 Go 语言来创建一个简单的 HTTP 服务器，使用 hostPort 将主机上的 80 端口映射到运行在 Pod 内部的容器端口上，其调度到 woker1 （10.20.32.204）节点上。

客户端通过主机 ip:hostPort 访问服务能够正常响应。

（3）原理解析

3.1）节点外客户端访问当前节点容器

现在连接到 worker1 机器，由于当前集群 kube-proxy 模式选用的是 ipvs，所以当外部客户端的访问当前节点的容器时，流量包通常会先后经过以下链：

  1. PREROUTING 链（iptables）： 外部流量进入主机后，首先经过 PREROUTING 链（位于 nat 表），这是网络地址转换（NAT）处理的第一个步骤。你可以在 PREROUTING 链中创建规则，以便将流量导入其他自定义的 iptables 链或 ipvs 转发路径。

  2. IPVS 转发路径： 如果你使用了 ipvs 来进行负载均衡，外部流量可能会直接进入 ipvs 的负载均衡路径。这是流量被转发到正确的后端 Pod 的地方，绕过了 iptables 的后续处理。

  3. FORWARD 链（iptables）： 如果流量需要在主机内部进行转发，它会进入 FORWARD 链（位于 filter 表），在这里可以进行进一步的处理，例如网络策略、防火墙规则等。

  4. POSTROUTING 链（iptables）： 流量最终经过 POSTROUTING 链（位于 nat 表），这是 NAT 处理的最后一步。你可以在这里进行出站流量的地址转换等处理。

总结起来，流量通常会按照 PREROUTING -> IPVS -> FORWARD -> POSTROUTING 的顺序进行处理。但是，实际流量的经过路径可能会受到你的配置和网络堆栈的影响，所以在进行流量管理和路由时，请务必仔细考虑你的需求和设置。

3.1.1）分析 PREROUTING 链规则

外部流量进来后首先经过PREROUTING 链，通过规则匹配只要是访问当前节点的80端口，都会进行dnat转换，转换成 PodIP:Pod端口。

3.1.2）分析 IPVS 规则

执行 ipvsadm -L -n 命令查看当前节点 IPVS 规则，在规则中没有查找到 10.20.32.204:80 匹配项。

3.1.3）分析 FORWARD 链规则规则

无 CNI-HOSTPORT 相关规则。

3.1.4）分析 POSTROUTING 链规则

CNI-HOSTPORT_MASQ规则在最前面，并且无需源地址转换。

3.1.5) 抓包验证

进入示例容器网络命令空间：

[root@worker1 ~]# docker ps|grep http-request-printer
267f462be8b6 25585bdfb0f7 "/usr/local/bin/pilo…" About an hour ago Up About an hour k8s_istio-proxy_http-request-printer-v1-856959f7d9-kxx6g_tracing_fa8a0a82-e233-4757-ba28-f16eb2d311f4_0
e60564d42fc6 6246a84777e8 "./http_request_prin…" About an hour ago Up About an hour k8s_container-rr19ea_http-request-printer-v1-856959f7d9-kxx6g_tracing_fa8a0a82-e233-4757-ba28-f16eb2d311f4_0
432a811e77e1 10.20.32.201:80/cloudbases/pause:3.4.1 "/pause" About an hour ago Up About an hour k8s_POD_http-request-printer-v1-856959f7d9-kxx6g_tracing_fa8a0a82-e233-4757-ba28-f16eb2d311f4_0
[root@worker1 ~]# nsenter -n -t 308222
nsenter: cannot open /proc/308222/ns/net: No such file or directory
[root@worker1 ~]# docker ps|grep http-request-printer
267f462be8b6 25585bdfb0f7 "/usr/local/bin/pilo…" About an hour ago Up About an hour k8s_istio-proxy_http-request-printer-v1-856959f7d9-kxx6g_tracing_fa8a0a82-e233-4757-ba28-f16eb2d311f4_0
e60564d42fc6 6246a84777e8 "./http_request_prin…" About an hour ago Up About an hour k8s_container-rr19ea_http-request-printer-v1-856959f7d9-kxx6g_tracing_fa8a0a82-e233-4757-ba28-f16eb2d311f4_0
432a811e77e1 10.20.32.201:80/cloudbases/pause:3.4.1 "/pause" About an hour ago Up About an hour k8s_POD_http-request-printer-v1-856959f7d9-kxx6g_tracing_fa8a0a82-e233-4757-ba28-f16eb2d311f4_0
[root@worker1 ~]# docker inspect --format "{{.State.Pid}}" 267f462be8b6
145003
[root@worker1 ~]# nsenter -n -t 145003
[root@worker1 ~]# ifconfig
eth0: flags=4163 mtu 1450
inet 10.233.1.133 netmask 255.255.255.0 broadcast 10.233.1.255
ether 2e:2c:82:08:eb:8e txqueuelen 0 (Ethernet)
RX packets 15372 bytes 9093248 (8.6 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 14493 bytes 23701690 (22.6 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73 mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
loop txqueuelen 1000 (Local Loopback)
RX packets 8483 bytes 37018407 (35.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 8483 bytes 37018407 (35.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

[root@worker1 ~]#

抓包来确定进入容器中的包没有进行源地址转换（抓包时客户端 10.20.32.201 通过 curl http://10.20.32.204:80 命令访问此服务）。

[root@worker1 ~]# tcpdump -i eth0 host 10.233.1.133 and dst port 80 -w svc_host_port.pcap
dropped privs to tcpdump
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C6 packets captured
6 packets received by filter
0 packets dropped by kernel

将抓的包下载到本地通过并使用 wireshark 软件进行分析，可以看到当节点外客户端通过 hostPort 访问容器时，进入容器中的包没有进行源地址转换。

3.2）节点上客户端访问当前节点容器

现在连接到 worker1 机器，由于当前集群 kube-proxy 模式选用的是 ipvs，所以当当前节点客户端的访问当前节点的容器时，流量包通常会先后经过以下链：

OUTPUT -> IPVS -> POSTROUTING

3.2.1）分析 OUTPUT 链规则

当前节点流量先经过OUTPUT 链，通过规则匹配只要是访问当前节点的80端口，都会进行dnat转换，转换成 PodIP:Pod端口，除了源地址是PodIp或127.0.0.1时会对数据包打标签，其他规则和3.1.1中类似，这里不再赘余。

3.2.2）分析 IPVS 规则

执行 ipvsadm -L -n 命令查看当前节点 IPVS 规则，在规则中没有查找到 10.20.32.204:80 匹配项。

3.2.3）分析 POSTROUTING 链规则

CNI-HOSTPORT_MASQ规则在最前面，如果源地址是PodIp或者127.0.0.1需要源地址转换。

注意 1：没太想明白Pod是互通的，为什么源PodIP还需要进行源地址转换。

3.2.4) 路由匹配将流量发送到 Pod 里面。

在 Kubernetes 中，hostPort 是一种用于将主机上的特定端口映射到运行在 Pod 内部容器的端口的配置选项。通过使用 hostPort，你可以在主机上暴露容器的服务，从而允许外部网络通过主机的 IP 地址和指定的端口访问容器内的应用程序。

一个 Node 只能启动一个 hostPort，所以最初是用于把守护进程集（DaemonSets）部署到每个 Node (确保一个 Node 只有一个 hostPort )，或者部署固定在特定节点的应用程序（比如 Nginx Ingress Controller 通常以高可用形式部署在固定三个节点上面）。

按照官方文档说的，除非绝对必要，否则不要为 Pod 指定 hostPort。 将 Pod 绑定到 hostPort 时，它会限制 Pod 可以调度的位置数，因为每个 组合必须是唯一的。 如果您没有明确指定 hostIP 和 protocol，Kubernetes 将使用 0.0.0.0 作为默认 hostIP 和 TCP 作为默认 protocol，请在使用 hostPort 之前考虑使用 NodePort 服务。

参考：https://knowledge.zhaoweiguo.com/build/html/cloudnative/k8s/yamls/option_hostport

参考：hostPort 与 hostNetwork 异同

手机扫一扫

移动阅读更方便

阿里云服务器
腾讯云服务器
七牛云服务器

你可能感兴趣的文章

kubernetes dashboard在ssl的各种场景下的手动部署
Kubernetes Ingress Controller的使用介绍及高可用落地
Cilium系列-5-Cilium替换KubeProxy

4

ingress-nginx 的使用 =》 部署在 Kubernetes 集群中的应用暴露给外部的用户使用

5

Kubernetes基础_Service暴露的两种方式

6

kind：Kubernetes in Docker，单机测试 Kubernetes 群集的最佳方案

7

Kubernetes【K8S】(三)：资源清单

8

四、Pod 介绍

9

kubernetes之DaemonSet以及滚动更新

10

第十二章 Kubernetes的服务暴露插件--traefik