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 работи, защото dataplane на клъстера програмира маршрутизация за него вътре в клъстера. От лаптоп във VPN адресът не означава нищо, освен ако нещо умишлено не го изложи. Име, завършващо на svc.cluster.local, принадлежи на DNS на клъстера, така че копирането му към клиент с друг резолвер дава име, което не съществува, а не грешка в маршрутизацията.
ClusterIP остава правилната входна точка за извикващи в клъстера, включително други натоварвания. Той просто не е механизъм за публикуване за потребители извън домейна за маршрутизация на клъстера.
Вътрешен балансьор на натоварването: публикуваният път
Вътрешният балансьор на натоварването ви дава стабилен частен адрес и име, към което вашата зона може да сочи, докато контролерът поддържа набора от бекенди актуален, както описва ръководството на EKS за балансиране на натоварването. Това е входната точка, която преживява обичайна замяна на Pod, без някой да редактира документ. Той струва облачен ресурс, конфигурация на контролер и маршрут от VPN и точно тези части хората подценяват.
Използвайте модела на контролера, който клъстерът действително изпълнява. Анотациите, написани за една интеграция, не важат за друга.
Кой е адресът на източника
Групите за сигурност виждат източника, който пристига на тяхната граница, а той може да е свързаният клиент или транслатиран адрес в зависимост от пътя през VPN и балансирането на натоварването. На възли на базата на EC2 обикновените Pod на VPC CNI наследяват по подразбиране групите на ENI на възела, а поддържаните конфигурации могат да прикачват групи, специфични за Pod. Пишете правила за документирания път, а не за предполагаем адрес на лаптоп.
Дръжте собствения слушател и удостоверяването на приложението като отделни контроли. Мрежово правило, което разрешава потока, не е решение за оторизация и не бива да се третира като такова.
Какво да дадете на потребителите
Дайте на потребителите име на услуга, а не адрес. Публикувайте името в частната зона, насочете го към вътрешната входна точка и след това тествайте, като замените бекенд Pod, докато клиентът държи същото име отворено. Това упражнение проверява свойството, което има значение: достигане до същото приложение след рутинно разгръщане.
Дръжте директния достъп до Pod като документирано оперативно изключение със собствен обхват, далеч от инструкциите за потребителите.