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

VPN sidecar в Kubernetes Pod изглежда като VPN на ниво хост с по-добри обноски и приликата свършва на границата на пространството от имена. Контейнерите в един Pod споделят мрежовото пространство от имена, включително адресното и портовото пространство, така че sidecar, който инсталира маршрути и политики, наистина променя накъде отиват пакетите на приложението. За другите Pod-ове на възела не променя нищо и не докосва собствения стек на възела, освен ако не го конфигурирате така. Правилното разбиране на тази граница определя и какво можете да внедрите, и какво трябва да тествате. Разделите по-долу проследяват това от пространството от имена навън.

Споделено пространство от имена, споделени последици

Два контейнера в един Pod говорят през loopback и виждат същите интерфейси и точно затова моделът със sidecar изобщо работи: приложението не трябва да знае, че съществува тунел, защото маршрутът, който то получава, е инсталиран в пространството от имена, което използва. Същото свойство означава, че грешките на sidecar са грешки на приложението. Маршрут, който прихваща твърде много, или DNS промяна, сочеща към резолвер вътре в тунела, се прилага веднага към всеки процес в този Pod. В споделено пространство от имена няма маршрутизация по контейнери, така че sidecar не може да бъде ограничен до един процес.

Това е механизмът, който да имате предвид при преглед: радиусът на поражението е Pod, не възелът и не клъстерът.

Докъде sidecar не стига

Другите Pod-ове пазят своите пространства от имена и своята маршрутизация, така че натоварване, което се нуждае от същия изход, се нуждае от същия sidecar или от дизайн на ниво възел. Трафикът на възела също е извън пространството от имена на Pod, а Pod-овете с хост мрежа съзнателно се отказват напълно от тази изолация. Ако пуснете sidecar с хост мрежа, за да стигнете до нещо удобно, сте разширили обхвата от един Pod до целия възел и трябва да го кажете на глас.

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

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

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

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

Стартирането и отказът са явни състояния

Работещият процес sidecar не е политика за изход. Решете какъв трафик може да тече, преди тунелът да е готов, и какво се случва, ако той умре след това, после приложете това решение: проверка, която пропуска контейнера на приложението, мрежова политика, която отказва по подразбиране, или и двете. Без едно от тях приложението стартира, резолвва и изпраща трафик по нормалния път на възела, докато тунелът още се свързва.

Тази пролука е кратка в здрав клъстер и постоянна в счупен и това е точно свойството, което предпочита нападател или случайно изтичане на данни.

Сдвоете подредбата с тест за отказ. Убийте sidecar и потвърдете, че приложението губи предвидения си изход, вместо тихо да се връща към стария път.

Възможности, политики и тестване от контейнера на приложението

Даването на възможностите, нужни за създаване на интерфейси и промяна на маршрути, е решение за привилегии и привилегия, подходяща за изолиран Pod, не е автоматично подходяща за стека на възела. Използвайте поддържаните от клъстера механизми за мрежова и security политика и не предполагайте, че всяка реализация на CNI или на политики третира VPN интерфейса по един и същ начин; разликите се показват точно в случаите на отказ, които ви интересуват.

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

Документирайте мрежовите допускания на клъстера до конфигурацията на VPN. Тогава преместването на натоварването в друг клъстер е упражнение по проверка на плана на маршрутите, а не смяна на образ, която тихо спира да работи.