FLBzh's questions

我在这里展示的是我的设置的简化版本，并且语法错误。

我有一个高级“代理”列表，我想在 kubernetes 集群上部署为 pod。

这个集群中的一些节点有特殊的硬件，一些没有，但是所有的 pod 都应该使用同一个容器。

可能看起来像（再次：语法错误）：

agent1 wlan
...
agent8 wlan
agent9 wlan rs232.1
agent10 wlan rs232.2

我设置了一个大致看起来像这样的部署（语法错误）：

deployment (standard nodes)
  replicas: 8
---
deployment (rs232, terminal 1)
  replicas: 1
  nodeSelector:
    rs232=1
  env:
    rs232=1 (because nodeSelector can't be passed nicely afaik)
---
deployment (rs232, terminal 2)
  replicas: 1
  nodeSelector:
    rs232=2
  env:
    rs232=2

我希望这些代理中的每一个都启动并从列表中获取一个身份，当然同时拥有匹配的硬件。

所以就像一个 pod 会像这样与一个角色分发服务交谈：

pod - Hi, I'm pod/container-xyz and I have env/label/annotation rs232=2
service - Hi, well then you are now agent10
pod - OK I'll do the work of agent10 then
(service - cool, I'll add agent10 as an alias to you in the cluster DNS) <- that will be my next question

没有特殊硬件的代理也是如此：该服务为每个代理赋予一个代理角色。

我尝试了 StatefulSet 的一些东西，但这不符合要求（因为各种 nodeSelector 并且它们启动速度非常慢）。

我开始考虑一个专用的自我实现的服务器 pod，它会保留我的代理列表并将它们租给匹配的硬件（有点像 dhcp 服务器），但我很确定我不是唯一遇到这个问题的人，而且一定有一个解决方案。我快速查看了 Zookeeper，但我认为它不适合我。我可能找不到解决方案，因为我的词汇量不是我猜的正确词汇。

有人有好主意吗？我是否朝着正确的方向前进？

对于我的客户，我必须在不同的机器上设置 docker 容器，这些机器在各种物理链路上运行各种服务。

我不能对我的 docker 容器使用“主机”模式。

到目前为止，我已经愉快地使用 macvlan 驱动程序在我的容器中生成了新的网络接口。

例如：

networks:
  good_net:
    driver: macvlan
    driver_opts:
      parent: eno0
  slow_net:
    driver: macvlan
    driver_opts:
      parent: eno0
  high_latency_net:
    driver: macvlan
    driver_opts:
      parent: eno0

我在容器启动时有一个脚本：

• 给一个唯一的mac地址
• 培养
• dhcp 或静态地址
• 应用 tc 过滤器来调整每个网络的流量

工作正常：我可以在各个链接上运行 ping 和 iperf3 以测试它们是否按预期工作。

问题：现在真正的界面来了，它们破坏了我的设置。

其中一个链接现在是 LTE。

lte_net:
  driver: macvlan
  driver_opts:
    parent: lte0

在 PC1（主机，而不是容器）上：

4: lte0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
   link/ether 7e:c4:d2:6a:e3:07 brd ff:ff:ff:ff:ff:ff
   inet 10.0.250.1/30 brd 10.0.250.3 scope global noprefixroute lte0
      valid_lft forever preferred_lft forever

在 PC2（主机，而不是容器）上：

4: lte0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
   link/ether b6:30:cb:12:31:16 brd ff:ff:ff:ff:ff:ff
   inet 10.0.250.5/30 brd 10.0.250.7 scope global noprefixroute lte0
      valid_lft forever preferred_lft forever

主机可以通过 LTE 链路愉快地相互 ping 和 iperf3。

但是：在容器中，使用 macvlan 方法，它们不能：

• 我为每个容器中的接口分配了同一子网中的 IP 地址：10.100.10.1/24 和 10.100.10.2/24
• 我已经关闭了所有其他接口，所以只剩下一条路线：10.100.10.0/24 dev lte0 proto kernel scope link src 10.100.10.1
• 从 pc1 上的容器，我尝试在 pc2 上的容器中 ping 通 LTE 接口的 IP
• 在主机上使用 tcpdump，我可以看到 lte 接口上的 ARP 数据包： 02:2d:6d:ad:63:62 (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.100.10.2 tell 10.100.10.1, length 28

但是我看不到它们到达 pc2，甚至在主机级别也看不到。

原因很可能是来自 LTE 调制解调器无法识别的 MAC 地址的数据包被丢弃。这类似于 WLAN 发生的情况。

所以我尝试使用 ipvlan l2 代替，正如有时建议的那样：

lte_net:
  driver: ipvlan
  driver_opts:
    ipvlan_mode: l2
    parent: lte0

容器中的 lte0 接口与其在主机上的父接口具有相同的 MAC 地址。但是没有变化：仍然没有跨越 LTE...

ipvlan l3 甚至没有出现，但我认为这不是我需要的。

所以我的问题是：我做错了什么？如何正确访问我的物理 LTE 作为 docker 容器中 IP 流量的网络接口？

对 3G 标记感到抱歉：我没有足够的声誉来创建 LTE 标记...

谢谢 ！

在两台不同的机器（桌面和服务器）上，同一个docker-compose 文件的行为不同......

在一台机器上docker-compose down似乎完全删除了以下docker-compose up不会重新创建的 ip 路由。

成绩单：

给出后systemctl restart docker ip route：

default via 192.168.22.1 dev enp3s0 proto dhcp src 192.168.22.30 metric 202 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-b32036613f97 proto kernel scope link src 172.18.0.1 linkdown 172.20.0.0/16 dev br-3f0603a1198c proto kernel scope link src 172.20.0.1 linkdown 192.168.22.0/24 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 202 192.168.22.1 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 1024

之后docker-compose up：

default via 192.168.22.1 dev enp3s0 proto dhcp src 192.168.22.30 metric 202 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-b32036613f97 proto kernel scope link src 172.18.0.1 172.20.0.0/16 dev br-3f0603a1198c proto kernel scope link src 172.20.0.1 192.168.22.0/24 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 202 192.168.22.1 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 1024

之后compose-compose down服务器会给出：

default via 192.168.22.1 dev enp3s0 proto dhcp src 192.168.22.30 metric 202 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 192.168.22.0/24 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 202 192.168.22.1 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 1024

但是桌面会显示（如预期的那样）：

default via 192.168.22.1 dev enp3s0 proto dhcp src 192.168.22.30 metric 202 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 172.18.0.0/16 dev br-b32036613f97 proto kernel scope link src 172.18.0.1 linkdown 172.20.0.0/16 dev br-3f0603a1198c proto kernel scope link src 172.20.0.1 linkdown 192.168.22.0/24 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 202 192.168.22.1 dev enp3s0 proto dhcp scope link src 192.168.22.30 metric 1024

桌面上的后续docker-compose up操作将成功，但在服务器上不会重新创建路由，并且容器对外界不可见......

只有完全重启 docker 服务的代价太高，才会将路由带回服务器上......

我不知道我做错了什么。

两台机器都运行最新版本的 arch linux。桌面使用 Gnome 并运行 NetworkManager，服务器是无头的并运行 systemd-networkd ......这几乎是我能看到的唯一区别......

两个版本都运行：

• Docker 版本 19.03.5-ce，构建 633a0ea838
• docker-compose 版本 1.25.1，构建未知