Pod IP, ClusterIP або внутрішній балансувальник навантаження для користувачів VPN

З VPC CNI Pod може отримати адресу з VPC, і користувач VPN із правильним маршрутом може звернутися до нього напряму. Тому прямий доступ до Pod здається найпростішим варіантом, і так воно і є, доки Pod не буде замінено. Адреса, яку пам’ятає користувач, має належати застосунку, а не репліці. Порівняння трьох входів зводиться до того, який об’єкт володіє адресою і що має продовжувати працювати, коли навантаження переміщується.

Спочатку вибирайте за життєвим циклом, потім за тим, що мережа має зробити, щоб вхід став доступним.

Три входи, три життєві цикли

Pod IP належить Pod: він виділяється разом із ним і звільняється після його завершення. ClusterIP належить Service і є віртуальним, він має сенс лише там, де існує маршрутизація сервісів кластера. Внутрішнім балансувальником володіє хмарний ресурс, який контролер кластера програмує бекендами. Ці моделі володіння передбачають збій, який ви отримаєте: застаріла адреса, недоступне ім’я або застарілий набір бекендів.

Запишіть порівняння до вибору. Коли власник і збій названі, вибір зазвичай робиться сам.

Прямий доступ до Pod: корисний, тимчасовий

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

Це також запрошує широкі правила. Дозвіл одному адміністратору досягати одного Pod не є дозволом для кожної адреси в підмережі вузла, і зазвичай записується саме друге.

ClusterIP: обмежений кластером за задумом

ClusterIP працює тому, що dataplane кластера програмує для нього маршрутизацію всередині кластера. З ноутбука у VPN адреса нічого не означає, якщо щось навмисно її не відкриває. Ім’я, що закінчується на svc.cluster.local, належить DNS кластера, тому копіювання його на клієнт з іншим резолвером дає не помилку маршрутизації, а неіснуюче ім’я.

ClusterIP залишається правильним входом для викликів усередині кластера, включно з іншими робочими навантаженнями. Він просто не є механізмом публікації для користувачів за межами домену маршрутизації кластера.

Внутрішній балансувальник: опублікований шлях

Внутрішній балансувальник дає вам стабільну приватну адресу й ім’я, на яке може вказувати ваша зона, а контролер підтримує набір бекендів актуальним, як описує посібник EKS з балансування навантаження. Це той вхід, який переживає звичайну заміну Pod без редагування документа будь-ким. Він коштує хмарний ресурс, конфігурацію контролера й маршрут із VPN, і саме ці частини люди недооцінюють.

Використовуйте ту модель контролера, яку кластер справді виконує. Анотації, написані для однієї інтеграції, не застосовуються до іншої.

Хто є адресою джерела

Групи безпеки бачать джерело, яке надходить на їхній кордон, і це може бути підключений клієнт або трансляційна адреса залежно від шляху VPN і балансування навантаження. На вузлах на базі EC2 звичайні Pod VPC CNI за замовчуванням успадковують групи ENI вузла, тоді як підтримувані конфігурації можуть приєднувати групи, специфічні для Pod. Пишіть правила для документованого шляху, а не для гаданої адреси ноутбука.

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

Що передати користувачам

Дайте користувачам ім’я сервісу, а не адресу. Опублікуйте ім’я в приватній зоні, спрямуйте його на внутрішній вхід, а потім перевірте, замінивши бекенд-Pod, поки клієнт тримає те саме ім’я відкритим. Ця вправа перевіряє властивість, яка важлива: досягнення того самого застосунку після рутинного розгортання.

Тримайте прямий доступ до Pod як документований операційний виняток із власним обсягом, далеко від інструкцій для користувачів.