Pod IP, ClusterIP или внатрешен балансер на оптоварување за VPN корисници
Pod IP е рутирачки преку VPN додека Pod не се замени. Споредете директен пристап до Pod, ClusterIP и внатрешен балансер и што ве чини секој од нив.
Со VPC CNI, Pod може да има адреса од VPC, а VPN корисник со вистинската рута може да му пристапи директно. Тоа го прави директниот пристап до Pod наједноставната опција, и навистина е така, додека Pod не се замени. Адресата што корисникот ја памети треба да му припаѓа на апликацијата, а не на реплика. Споредбата на трите влеза се сведува на тоа кој објект ја поседува адресата и што мора да продолжи да работи кога работното оптоварување ќе се премести.
Изберете прво според животниот циклус, потоа според тоа што мрежата треба да направи за влезот да биде достапен.
Три влеза, три животни циклуси
Pod IP го поседува Pod: се доделува со него и се ослободува кога ќе заврши. ClusterIP го поседува Service и е виртуелен, има смисла само таму каде што постои рутирање на услугите во кластерот. Внатрешниот балансер го поседува облачен ресурс што контролерот на кластерот го програмира со бекенди. Овие модели на сопственост го предвидуваат дефектот што ќе го добиете: застарена адреса, недостапно име или застарен сет на бекенди.
Запишете ја споредбата пред да изберете. Кога сопственикот и дефектот се именувани, изборот обично се прави сам.
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
Директен пристап до Pod: корисен, привремен
Директниот пристап е навистина корисен за контролирана проверка: еден администратор, една кратка сесија, еден конкретен порт. Но тоа е лош договор за корисниците, бидејќи адресата е детаљ од имплементацијата што се менува при секое распоредување. А нејзиното запишување во вики е начинот на кој работна услуга станува гласина.
Тоа исто така повикува на широки правила. Дозволата еден администратор да стигне до еден Pod не е дозвола за секоја адреса во подмрежата на јазолот, а обично се пишува второто.
ClusterIP: ограничен на кластерот по дизајн
ClusterIP работи затоа што податочната рамнина на кластерот програмира рутирање за него внатре во кластерот. Од лаптоп на VPN адресата не значи ништо освен ако нешто намерно не ја изложи. Име што завршува на svc.cluster.local му припаѓа на DNS-от на кластерот, па неговото копирање на клиент со друг резолвер дава име што не постои, а не грешка во рутирањето.
ClusterIP останува вистинскиот влез за повикувачите внатре во кластерот, вклучително други работни оптоварувања. Тој едноставно не е механизам за објавување за корисници надвор од рутирачката домена на кластерот.
Внатрешен балансер: објавената патека
Внатрешниот балансер ви дава стабилна приватна адреса и име кон кое вашата зона може да покажува, додека контролерот го одржува сетот на бекенди ажурен, како што опишува упатството на EKS за балансирање на оптоварување. Тоа е влезот што преживува обична замена на Pod без никој да уредува документ. Чини облачен ресурс, конфигурација на контролер и рута од VPN, и токму тие делови луѓето ги потценуваат.
Користете го моделот на контролер што кластерот навистина го извршува. Анотациите напишани за една интеграција не важат за друга.
Кој е изворната адреса
Безбедносните групи го гледаат изворот што пристигнува на нивната граница, а тоа може да биде поврзаниот клиент или преведена адреса во зависност од патеката на VPN и балансирањето. На јазли базирани на EC2, обичните Pod на VPC CNI по правило ги наследуваат групите на ENI на јазолот, додека поддржаните конфигурации можат да прикачат групи специфични за Pod. Пишувајте правила за документираната патека, а не за претпоставена адреса на лаптоп.
Држете ги сопствениот слушател и автентикацијата на апликацијата како одделни контроли. Мрежно правило што го дозволува текот не е одлука за авторизација и не треба така да се третира.
Што да им дадете на корисниците
Дајте им на корисниците име на услуга, не адреса. Објавете го името во приватната зона, насочете го кон внатрешниот влез, потоа тестирајте со замена на бекенд Pod додека клиентот го држи истото име отворено. Таа вежба го проверува својството што е важно: да се стигне до истата апликација по рутинско распоредување.
Држете го директниот пристап до Pod како документиран оперативен исклучок со сопствен обем, далеку од упатствата за корисници.