Боковому контейнеру VPN потрібні правило запуску та правило відмови

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

Порядок закриває лише перший запит

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

Поза цією моделлю семантика порядку належить тому середовищу виконання чи системі залежностей, яку ви використовуєте, і вони не зобов'язані збігатися. Розгортання, скопійоване з іншої платформи, може виглядати так, ніби чекає на тунель, бо застосунок випадково стартує повільно. Це не та сама гарантія, і під навантаженням воно відмовляє.

Скажіть, що спостерігає брама: процес існує, інтерфейс існує, рукостискання завершено. Кожне з цього — слабше твердження, ніж «шлях даних до призначень, потрібних цьому pod, працює».

Примусово задайте шлях даних, а не припускайте його

Проба — це перевірка в один момент, а міжмережевий екран — властивість, що діє між моментами. Якщо вимога полягає в тому, щоб трафік застосунку ніколи не виходив за межі тунелю, її треба виразити в спільному мережевому просторі імен як правило «прийняти або відкинути». Порядок запуску контейнерів не може нести цю вимогу. Лише правило може.

Контейнери в одному pod поділяють цей простір імен, тому точкою примусу є сам простір імен. Що б ви не написали, воно має залишати доступним власне зовнішнє з'єднання тунелю, адже його блокування заради захисту застосунку обрізає шлях, потрібний застосунку.

Вирішіть політику відмови явно: чи має трафік застосунку повністю зупинятися, коли тунель нездоровий, чи продовжуватися й позначатися як незахищений? Обидва варіанти захистимі, і жоден не отримується запуском контейнерів у певному порядку.

Перевірте трафік, про який ви не згадали

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

Сторінка адреси виходу доводить, що один запит у той момент пішов туди, куди ви очікували. Вона не може перелічити інші шляхи, і розрив між тим, що ви перевірили, і тим, до чого pod може дістатися, — це місце, де живуть цікаві відмови.

Повторіть тест після перезапуску sidecar, а не лише після чистого старту. Перезапущений контейнер тунелю може залишити простір імен із маршрутами й політикою в проміжному стані.

Запишіть запис про розгортання

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

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

Насамкінець, один раз перевірте шлях відновлення, коли застосунок працює. Проєкт, що вимагає перестворити pod для відновлення вихідного трафіку, — це рішення, і воно має бути ухваленим вами, а не виявленим.