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 не е автоматски погодна на стекот на јазолот. Користете ги механизмите за мрежна и безбедносна политика што ги поддржува кластерот и не претпоставувајте дека секоја имплементација на CNI или политика се однесува кон VPN интерфејсот исто; разликите се покажуваат токму во случаите на отказ што ви се важни.

Тестирајте од вистинскиот контејнер на апликацијата, со свежи барања до приватно одредиште, услуга во кластерот и јавниот интернет. Тестот од sidecar докажува дека тунелот работи, не дека апликацијата стигнува до она што ѝ треба.

Документирајте ги мрежните претпоставки на кластерот до VPN конфигурацијата. Тогаш преместувањето на работното оптоварување во друг кластер е вежба во проверка на планот на рути, а не промена на имиџ што тивко престанува да работи.