Проверка работоспособности виртуального коммутатора - NFS, BGP и Kubernetes

У меня есть домашний кластер Kubernetes, который работает на 4 виртуальных машинах поверх Proxmox. Proxmox привязан к VLAN 20, виртуальные машины Kubernetes привязаны к VLAN 40.

Виртуальные машины Kubernetes являются BGP-соседями моего маршрутизатора, так что я могу пометить модули для последующего запуска в одной из двух других виртуальных локальных сетей, которые обозначены как пространства DMZ, 50 и 60. Вкратце, сеть выглядит так:

- VLAN1: Networking Hardware
    - VLAN20: Physical Machines
        - VLAN40: Kubernetes VMs
            - VLAN50: Internal Kubernetes Deployments
            - VLAN60: External Kubernetes Deployments

Она отлично работает, все может взаимодействовать друг с другом, и Интернет просто отлично. За одним исключением, производительность.

Мой сервер Proxmox также действует как мой сервер хранения, объявляя пул ZFS как сервер NFS. Это отлично работает и позволяет довольно быстро читать и писать для домашнего сервера хранения. Например, скорость чтения выше 6 Гбит / с.

Когда я запускал контейнеры Docker непосредственно на моем сервере Proxmox, виртуальная коммутация позволяла контейнерам взаимодействовать с сервером NFS, размещенным в Proxmox, по имени хоста почти с такой скоростью.

Кроме того, до того, как я настроил VLAN, виртуальные машины Kubernetes работали в той же VLAN (1), что и сам Proxmox. И любые поды, которые были развернуты в Kubernetes, также могли взаимодействовать с сервером NFS, размещенным Proxmox, по имени хоста почти с такой скоростью.

Однако теперь, когда я настроил виртуальные локальные сети и использовал BGP для предоставления моих модулей Kubernetes в виртуальных локальных сетях, отдельных от хостов, скорость сети была ограничена 1 Гбит / с, если не хуже.

Мои Ubiquiti Edgerouter Lite и Unifi Switch 8 имеют емкость 1 Гб, так что это имеет смысл. Однако в моей лаборатории это становится очень болезненным. Например, обложка в Plex Media Server загружается более 10 секунд, когда я прокручиваю свою библиотеку, потому что том Kubernetes монтирует базу данных на сервере NFS. Точно так же Потоп действует невероятно плохо. Веб-интерфейс часто дает сбой, и любое действие, такое как открытие панели настроек или попытка увидеть раздел «Подробности» нового торрента, может занять несколько минут! В настройках кэша Deluge установлено использование 4 ГБ памяти, но я не уверен, связаны ли эти проблемы с производительностью с моей сетью или потому, что Deluge просто плохо масштабируется до 1100 торрентов. Наконец, иногда мои развертывания Kubernetes, которые сильно взаимодействуют с базой данных (Plex, Jira и т. Д.), Заканчиваются повреждением базы данных через несколько недель работы. Предположительно, это из-за задержки в сети, но я не уверен.

Я ищу ответы на несколько вопросов в этом сообщении:

  1. Я знаю, что моя сеть сложна, особенно для домашней лаборатории. Однако моя домашняя лаборатория почти полностью используется для обучения работе. И это хобби доставляет мне удовольствие, особенно когда я работаю с непристойными уровнями сложности. Однако мне просто любопытно, кажется ли вам, что все настроено правильно, учитывая тот факт, что меня устраивает сложность.

  2. Решит ли эту проблему покупка коммутатора 10 Гбит / с или потребуется также приобрести маршрутизатор 10 Гбит / с, поскольку Edgerouter является BGP-соседом узлов Kubernetes?

  3. Если бы необходимо было приобрести и коммутатор, и маршрутизатор, можно ли было бы вместо этого приобрести коммутатор 10 Гбит с возможностями BGP?

  4. Какое оборудование вы порекомендуете приобрести для решения этой проблемы? В идеале я бы хотел, чтобы общая стоимость не превышала 500–1000 долларов, но похоже, что это невозможно, учитывая невероятно высокую стоимость маршрутизаторов на 10 Гбит / с.

  5. Можно ли использовать другой класс хранилища Kubernetes для хранения данных непосредственно на узлах? Как это будет выглядеть?

  6. Вы бы порекомендовали другое решение моей проблемы?

0
задан 14 April 2019 в 05:03
1 ответ

Оглядываясь назад:

  1. Конфигурация была хорошей, но есть подходы получше. В основном децентрализация безопасности в сетевой ячеистой сети, такой как Istio, а не в виртуальном разделении, которое требует больших ресурсов.

2-3. Да, это решило бы проблему, если бы коммутатор имел возможности BGP.

  1. Да, таких много. На ум приходит hostPath. А также такие вещи, как динамический поставщик ZFS, предлагаемый OpenEBS.

  2. Да, обеспечение сетевой безопасности с помощью Istio.

0
ответ дан 8 April 2020 в 19:34

Теги

Похожие вопросы