Вирішення проблем доступу до мережі для стручок K3S у Rancher

Розуміння обмежень мережі POD у K3S 🛜

Створюючи кластер Kubernetes з Rancher та K3S, мережа може стати головною проблемою. Поширене питання виникає, коли вузли працівників можуть охопити зовнішні мережі, але стручки, що працюють у цих вузлах, обмежені. Це може бути неприємно, особливо коли ваші вузли налаштовані належні маршрути, але ваші стручки залишаються ізольованими.

Цей сценарій часто зустрічається в умовах, де робочі вузли є частиною більш широкої мережевої архітектури. Наприклад, ваші вузли працівників можуть належати до підмережі 192.168.1.x і можуть отримати доступ до іншої підмережі, як 192.168.2.x, через статичні маршрути. Однак стручки, що працюють на цих вузлах, не в змозі спілкуватися з машинами в 192.168.2.x.

Завдання тут полягає в тому, як Kubernetes керує мережею та як трафік протікає від стручок до зовнішніх напрямків. Без належної конфігурації стручки можуть мати можливість отримати доступ лише до ресурсів у мережі власного вузла, залишаючи зовнішні машини недоступними. Розуміння, чому це відбувається, має вирішальне значення для пошуку рішення.

У цій статті ми вивчимо, чому стручки стикаються з цими мережевими обмеженнями та як дозволити їм отримати доступ до зовнішніх підмереж. За допомогою практичних кроків та прикладів у реальному світі ми допоможемо вам подолати цей розрив. Давайте зануримось! 🚀

Забезпечення підключення між мережею для стручок K3S

При розгортанні К3 За допомогою Rancher проблеми з мережею можуть виникати, коли стручки повинні спілкуватися з машинами поза їх безпосередньою підмережею. Сценарії надали цю проблему шляхом зміни правил маршрутизації та налаштування NAT (переклад мережевої адреси). Використовує один ключовий сценарій iptables Щоб застосувати правило маскування, гарантуючи, що трафік POD надходить із самого робітничого вузла. Це дозволяє зовнішнім машинам реагувати на стручки, подолавши ізоляцію мережі за замовчуванням.

Інший підхід передбачає вручну додавання статичних маршрутів. Вузли робітників часто мають доступ до інших мереж за допомогою статичних маршрутів, але Кубернети стручки не успадують ці маршрути за замовчуванням. Запускаючи сценарій, який явно додає маршрут до 192.168.2.x через шлюз вузла, ми переконуємось, що стручки можуть дістатися до цих машин. Це важливо в середовищах, де потрібно спілкуватися з кількома внутрішніми мережами, наприклад, компаніями з окремими VLAN для різних відділів.

Для автоматизації процесу, a Kubernetes Deemonset може бути розгорнутий. Це гарантує, що конфігурації мережі застосовуються послідовно у всіх вузлах кластера. Deemonset запускає привілейований контейнер, який виконує мережеві команди, що робить його масштабованим рішенням. Цей метод особливо корисний при управлінні великим флотом робочих вузлів, де вручну налаштування кожного вузла було б непрактичним. Уявіть собі хмарний додаток, який потребує доступу до застарілої бази даних, розміщеної в іншій підмережі-це налаштування забезпечує безперебійне підключення.

Нарешті, тестування має вирішальне значення. Наданий сценарій розгортає простий Podbox Pod, який намагається пінг -зовнішній машину. Якщо пінг досягає успіху, це підтверджує, що виправлення підключення працює. Цей тип перевірки в реальному світі є неоціненним у виробничих умовах, де розбиті конфігурації мережі можуть призвести до порушення послуг. Поєднуючи ці підходи-Nat, статичні маршрути, автоматизацію Kubernetes та тестування в прямому ефірі-ми створюємо надійне рішення для доступу до перехресної мережі в кластерах K3S. 🚀

#!/bin/bash
# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Add NAT rule to allow pods to access external networks
iptables -t nat -A POSTROUTING -s 10.42.0.0/16 -o eth0 -j MASQUERADE
# Persist iptables rule
iptables-save > /etc/iptables/rules.v4
# Restart networking service
systemctl restart networking

#!/bin/bash
# Add a static route to allow pods to reach 192.168.2.x
ip route add 192.168.2.0/24 via 192.168.1.1 dev eth0
# Verify the route
ip route show
# Make the route persistent
echo "192.168.2.0/24 via 192.168.1.1 dev eth0" >> /etc/network/interfaces
# Restart networking
systemctl restart networking

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: k3s-network-fix
spec:
  selector:
    matchLabels:
      app: network-fix
  template:
    metadata:
      labels:
        app: network-fix
    spec:
      hostNetwork: true
      containers:
      - name: network-fix
        image: alpine
        command: ["/bin/sh", "-c"]
        args:
        - "ip route add 192.168.2.0/24 via 192.168.1.1"
        securityContext:
          privileged: true

apiVersion: v1
kind: Pod
metadata:
  name: network-test
spec:
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "ping -c 4 192.168.2.10"]
  restartPolicy: Never

Оптимізація мереж K3S для зв'язку Multi-Subnet

Один вирішальний, але часто не помічений аспект Мережа K3S - роль інтерфейсу контейнерної мережі (CNI) у управлінні підключенням POD. За замовчуванням K3S використовує Flannel як свій CNI, який спрощує мережу, але може не підтримувати розширену маршрутизацію з коробки. У випадках, коли стручкам потрібно отримати доступ до ресурсів поза їх основною підмережею, замінити фланель на більш багатий на функції CNI, такі як Calico або Cilium, може забезпечити додаткову гнучкість та спеціальні варіанти маршрутизації.

Ще одним важливим фактором є роздільна здатність DNS. Навіть якщо маршрутизація належним чином налаштована, стручки все ще можуть намагатися підключитися до зовнішніх служб через неправильні налаштування DNS. Kubernetes, як правило, покладається на Coredns, що може автоматично вирішувати імена хостів із зовнішніх мереж. Налаштування користувацьких налаштувань DNS в кластері може допомогти забезпечити плавне спілкування між стручками та машинами в інших підмережах, покращуючи як доступність, так і продуктивність.

Міркування щодо безпеки також відіграють ключову роль. Розширюючи доступ до POD за межі локальної мережі, правила брандмауера та мережеві політики повинні бути ретельно скориговані, щоб уникнути розкриття конфіденційних ресурсів. Реалізація мережевих політики Kubernetes може обмежувати непотрібний трафік, дозволяючи необхідними з'єднаннями. Наприклад, веб -сервіс, що працює в стручку, може знадобитися доступ до віддаленої бази даних, але не повинна мати необмежений доступ до всіх зовнішніх машин. Управління цими політиками ефективно підвищує безпеку, зберігаючи необхідну зв’язок. 🔐