Pod, вузол чи кластер: що насправді перенаправляє sidecar VPN

Sidecar VPN у Pod Kubernetes виглядає як VPN рівня хоста з кращими манерами, і схожість закінчується на межі простору імен. Контейнери в одному Pod поділяють мережевий простір імен, включно з простором адрес і портів, тому sidecar, який встановлює маршрути й політику, справді змінює, куди йдуть пакети застосунку. Для інших Pod на вузлі він не змінює нічого і не зачіпає власний стек вузла, якщо ви не налаштуєте його так. Правильне розуміння цієї межі визначає і те, що можна розгорнути, і те, що треба перевірити. Розділи нижче простежують це від простору імен назовні.

Спільний простір імен, спільні наслідки

Два контейнери в Pod спілкуються через loopback і бачать ті самі інтерфейси, і саме тому шаблон sidecar взагалі працює: застосунку не потрібно знати про існування тунелю, бо маршрут, який він отримує, встановлено в просторі імен, який він використовує. Та сама властивість означає, що помилки sidecar — це помилки застосунку. Маршрут, який захоплює занадто багато, або зміна DNS, що вказує на резолвер усередині тунелю, негайно застосовується до кожного процесу в цьому Pod. У спільному просторі імен немає маршрутизації за контейнерами, тому sidecar не можна обмежити одним процесом.

Це механізм, який варто тримати в голові під час перевірки: радіус ураження — це Pod, а не вузол і не кластер.

Куди sidecar не дістає

Інші Pod зберігають власні простори імен і власну маршрутизацію, тому навантаженню, якому потрібен той самий вихід, потрібен той самий sidecar або, замість цього, проєкт на рівні вузла. Трафік вузла також поза простором імен Pod, а Pod із мережею хоста навмисно повністю відмовляються від цієї ізоляції. Якщо ви запускаєте sidecar з мережею хоста, щоб дістатися до чогось зручного, ви розширили область з одного Pod на весь вузол і повинні сказати це вголос.

Трафік до сервісів кластера — інший частий сюрприз. Широкий маршрут за замовчуванням усередині Pod може перехопити запити, призначені серверу API або сервісу ClusterIP, і вони потім падають так, ніби тунель зламано.

План маршрутів: діапазони Pod, сервісів, вузла та VPN

Запишіть чотири діапазони й перевірте їх на перетин, перш ніж щось розгортати: CIDR Pod, CIDR сервісів, адреси вузла й призначення за VPN. Перетин приватних діапазонів VPN із власним простором кластера не рідкість, і маршрут за замовчуванням — неправильне рішення для цього. План маршрутів має лежати в тому самому репозиторії, що й маніфест, бо наступний кластер може видати зовсім інші діапазони Pod і сервісів.

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

Запуск і відмова — це явні стани

Процес sidecar, що працює, — не політика виходу. Вирішіть, який трафік може йти до готовності тунелю, і що станеться, якщо він помре після цього, а потім реалізуйте це рішення: проба, що притримує контейнер застосунку, мережева політика, що відхиляє за замовчуванням, або і те, і інше. Без одного з цього застосунок запускається, розв'язує імена й надсилає трафік звичайним шляхом вузла, поки тунель ще підключається.

Ця прогалина коротка в здоровому кластері й постійна в зламаному, і саме цю властивість полюбляє нападник або випадковий витік даних.

Поєднайте порядок із тестом відмови. Убийте sidecar і переконайтеся, що застосунок втрачає призначений вихід, а не відкочується мовчки.

Можливості, політики й тестування з контейнера застосунку

Надання можливостей, потрібних для створення інтерфейсів і зміни маршрутів, — це рішення про привілеї, і привілей, доречний для ізольованого Pod, не обов'язково доречний на стеку вузла. Використовуйте підтримувані кластером механізми мережевої та безпекової політики й не припускайте, що кожна реалізація CNI чи політики ставиться до VPN-інтерфейсу однаково; відмінності виявляються саме в тих випадках відмови, які вам важливі.

Тестуйте зі справжнього контейнера застосунку, з новими запитами до приватного призначення, сервісу кластера й публічного інтернету. Тест із sidecar доводить, що тунель працює, а не що застосунок дістається потрібного.

Задокументуйте мережеві припущення кластера поруч із конфігурацією VPN. Тоді перенесення навантаження в інший кластер — це вправа з перевірки плану маршрутів, а не зміна образу, яка мовчки перестає працювати.