vorlon001

PART1

Архитектура стенда (ANSI)

       +-------------------------------------------------------------------+

       |                        ФИЗИЧЕСКИЙ ХОСТ (Linux)                    |
       |                                                                   |
       |  +-------------------------+             +---------------------+  |

vorlon001

#!/usr/bin/env bash
# gen.sh — генератор скриптов лабы EVPN-VXLAN (3 ноды FRR + netns)
# Создаёт: evpn_setup.sh, test_evpn.sh, deploy.sh, evpn_cleanup.sh
set -euo pipefail

# ==================== КОНФИГ ЛАБЫ (всё меняется только здесь) ====================
NODES=(130 131 132)       # номер ноды = последний октет underlay-IP
U_PREFIX="192.168.200"    # underlay-подсеть

vorlon001

Готово. Изменения в gen.sh:

1. iptables убран — секция firewall в evpn_setup.sh удалена целиком.
2. Underlay-порт — enp1s0.200 — вынесен в конфиг генератора (IF_U). Скрипт сам создаст VLAN-сабинтерфейс (id 200 на enp1s0), если его ещё нет, поднимет родителя.
3. Из-за VLAN-тега пересчитан MTU: overlay = MTU_U − 54 (50 байт VXLAN + 4 байта тег) → 1446 при underlay 1500. Раньше стояло жёстко 1450 — теперь считается.

Обновлённый gen.sh целиком:

#!/usr/bin/env bash

vorlon001

gen.sh — генератор скриптов лабы

Один скрипт, в шапке — вся конфигурация лабы (ноды, подсети, VNI, AS). Запуск создаёт рядом 4 файла: evpn_setup.sh, test_evpn.sh, deploy.sh, evpn_cleanup.sh (те самые из прошлого шага, но значения уже прошиты из конфига). Поменяли конфиг — перезапустили gen.sh, файлы перегенерировались.

#!/usr/bin/env bash
# gen.sh — генератор скриптов лабы EVPN-VXLAN (ноды FRR + netns)
# Создаёт рядом: evpn_setup.sh, test_evpn.sh, deploy.sh, evpn_cleanup.sh
set -euo pipefail

vorlon001

Три файла

• evpn_setup.sh — универсальный, запускается на каждой ВМ (нода сама определяет себя по IP 192.168.200.x). Ставит FRR (если нет), настраивает bridge+VXLAN+netns, генерирует frr.conf и перезапускает FRR.
• test_evpn.sh — тест: BGP, VNI, ping'и из netns, MAC-таблицы.
• deploy.sh — раскатка со своей рабочей машины на все 3 ноды по SSH + автотест.

Итоговая адресация:

ВМ	underlay	AS	netns	IP в netns

vorlon001

L2 EVPN (VXLAN) на FRR: 3 ВМ + netns, 10.0.0.0/24

example: https://docs.frrouting.org/en/latest/evpn.html

Схема

      netns host1          netns host2          netns host3
      10.0.0.11/24         10.0.0.12/24         10.0.0.13/24
          | veth               | veth               | veth
        [br0]                [br0]                [br0]
 | vxlan0 VNI 10010 | |

vorlon001

---

Чтобы реализовать эту схему на 10 000 хостов, мы полностью отказываемся от модели «один VRF = один интерфейс» на стыке OVS и Linux. Вместо этого мы используем VLAN-ориентированный Trunk-интерфейс, заставляя ядро Linux разбирать локальные VLAN-теги прямо на лету, маппить их в сетевые пространства (VRF/Маршруты) и передавать демону FRR (Free Range Routing) для BGP EVPN SRv6 сигнализации.

Ниже представлена полная техническая реализация одного такого гипервизора.

---

1. Архитектурная схема датаплана на хосте

vorlon001

WORK

cat <<EOF > /etc/kubernetes/auth-config.yaml
apiVersion: apiserver.config.k8s.io/v1beta1
kind: AuthenticationConfiguration
anonymous:
  enabled: true
  conditions:
  - path: /livez

vorlon001

Для того чтобы детально разобраться в проблеме, рассмотрим архитектуру процесса kubeadm join (фаза bootstrap-discovery), проанализируем текущую логику кода Kubernetes v1.37.0 и определим, почему возникает ошибка 401 Unauthorized.

---

Архитектурная суть процесса Discovery

Когда новый узел (воркер) пытается присоединиться к кластеру, он находится в состоянии «нулевого доверия»:

1. У него нет клиентских сертификатов для авторизации в API-сервере.
2. У него нет корневого сертификата CA кластера, чтобы проверить, является ли мастер-узел подлинным, а не поддельным (защита от атаки Man-in-the-Middle).

vorlon001

PART 1

Ниже представлены готовые, протестированные примеры для Ванильного Kubernetes (NetworkPolicy) и для Cilium (CiliumNetworkPolicy) под оба твоих кейса.

Поскольку политики безопасности работают в режиме Stateful, ответный трафик на легитимный входящий запрос (от Istio, Envoy-Gateway или внешнего клиента) всегда улетает обратно автоматически.

---

🛠️ КЕЙС 1: Трехзвенка (Gateway API -> Web -> Backend -> DB + Внешний SSO по IP/Домену)