Обычно, когда речь идет о подключаемых модулях CNI L2 против L3, они меньше говорят о достижимости своих модулей (общедоступных или частных) и больше говорят об уровне подключения к сетевой модели OSI, который сетевой плагин обеспечивает между этим модулем идругие модули Kubernetes.
Например, если все модули могут отправлять друг другу трафик L2 (например, ARP), то подключаемый модуль CNI обеспечивает подключение L2.Большинство плагинов CNI обеспечивают сетевые соединения IP (L3) для модулей Kubernetes, поскольку именно это определяется сетевой моделью Kubernetes.
Некоторые примеры реализаций сети Kubernetes, которые обеспечивают сетевое подключение L3 на хостах:Бязь, фланель, канал, куб-роутер и т. Д.
Единственный пример, который я могу придумать, может обеспечить сетевое соединение L2 между хостами, это Weave Net, но я ожидаю, что есть и другие, которые я забыл.
Обратите внимание, что многие из вышеперечисленных могут использовать методы инкапсуляции, такие как VXLAN, для обеспечения межсетевого взаимодействия между хостами.Это обычно неправильно понимается, чтобы означать, что они обеспечивают сеть L2 между модулями.Тем не менее, они часто по-прежнему используют шаг IP-маршрутизации между модулем и его хостом, что означает, что он обеспечивает соединение между модулями L3 и модулем.
Также обратите внимание, что многие из вышеперечисленных модулей подключаются на одном и том же хосте с использованием моста linux, это означает, что модули на том же хосте получат подключение L2, но модули на других узлах будут маршрутизироваться (L3).Гораздо проще масштабировать сети L3 до большого количества конечных точек, поэтому это имеет смысл.Calico - небольшое исключение, использующее сеть с маршрутизацией L3 даже для модулей на одном хосте.