Thank you for reading this post, don't forget to subscribe!

Мет­ки (labels) пред­став­ля­ют собой пары ключ/значение, кото­рые назна­ча­ют­ся объ­ек­там (напри­мер, подам) в кла­сте­ре Kubernetes. Эти мет­ки пред­на­зна­че­ны для ука­за­ния иден­ти­фи­ци­ру­ю­щих атри­бу­тов объ­ек­тов, осмыс­лен­ных и име­ю­щих отно­ше­ние к пользователям

Мет­ки чаще все­го исполь­зу­ют­ся для выбо­ра под­мно­жеств и орга­ни­за­ции объ­ек­тов в кла­сте­ре. В дан­ном слу­чае под “орга­ни­за­ци­ей” сле­ду­ет пони­мать воз­мож­ность поль­зо­ва­те­лей сопо­став­лять свои соб­ствен­ные орга­ни­за­ци­он­ные струк­ту­ры и систем­ные объ­ек­ты, не тре­буя от кли­ен­тов хра­нить эти сопоставления.

Мет­ки могут при­креп­лять­ся к объ­ек­там во вре­мя созда­ния или же добав­лять­ся (и изме­нять­ся) в любое вре­мя. Каж­дый объ­ект в кла­сте­ре Kubernetes может иметь соб­ствен­ный набор ключей/значений. Каж­дый ключ дол­жен быть уни­каль­ным для дан­но­го объекта:

В зави­си­мо­сти от кон­крет­ных тре­бо­ва­ний про­ек­та, под­хо­да к раз­ра­бот­ке и тести­ро­ва­нию, исполь­зу­е­мых тех­но­ло­гий, бюд­же­та (и про­чих фак­то­ров) для достав­ки при­ло­же­ния конеч­но­му поль­зо­ва­те­лю у вас может быть несколь­ко датацентров/кластеров, раз­ные набо­ры нод в кла­сте­ре (отли­ча­ю­щи­е­ся, напри­мер по CPU), несколь­ко раз­лич­ных окру­же­ний, мно­же­ство мик­ро­сер­ви­сов и т. д. С помо­щью меток мож­но “задо­ку­мен­ти­ро­вать” запу­щен­ные в кла­сте­ре объ­ек­ты в понят­ном для поль­зо­ва­те­ля фор­ма­те, а так­же исполь­зо­вать мет­ки в селек­то­рах, что суще­ствен­но упро­ща­ет управ­ле­ние инфра­струк­ту­рой. При­мер наи­бо­лее часто исполь­зу­е­мых меток:

Мож­но исполь­зо­вать свои соб­ствен­ные обо­зна­че­ния, глав­ное пом­нить, что ключ мет­ки дол­жен быть уни­каль­ным для объекта.

Кор­рект­ные име­на клю­чей в мет­ках состо­ят из двух сег­мен­тов: опци­о­наль­но­го пре­фик­са и име­ни, раз­де­лен­ных сим­во­лом /. Имя - обя­за­тель­ная часть - долж­но начи­нать­ся и закан­чи­вать­ся бук­вен­но-циф­ро­вым сим­во­лом ([a-z0-9A-Z]), может содер­жать в себе дефи­сы (-), под­чер­ки­ва­ния (_) и точ­ки (.). Мак­си­маль­но допу­сти­мая дли­на име­ни клю­ча - 63 символа.

Опци­о­наль­ный пре­фикс (если опре­де­лен) дол­жен быть DNS-под­до­ме­ном (раз­ре­ша­ет­ся исполь­зо­ва­ние точек) не длин­нее 253 сим­во­лов и закан­чи­вать­ся сим­во­лом /. Напри­мер, пре­фикс kubernetes.io/ заре­зер­ви­ро­ван для основ­ных ком­по­нен­тов Kubernetes.

Зна­че­ния меток, так же как и име­на клю­чей, долж­ны начи­нать­ся и закан­чи­вать­ся бук­вен­но-циф­ро­вым сим­во­лом ([a-z0-9A-Z]), содер­жать в себе дефи­сы (-), под­чер­ки­ва­ния (_) и точ­ки (.). Мак­си­маль­но допу­сти­мая дли­на зна­че­ния мет­ки - 63 символа.

С исполь­зо­ва­ни­ем селек­то­ра меток (label selector) в кла­сте­ре Kubernetes поль­зо­ва­тель может иден­ти­фи­ци­ро­вать набор объ­ек­тов. Селек­тор - это при­ми­тив основ­ной груп­пи­ров­ки в Kubernetes. В дан­ный момент API под­дер­жи­ва­ет два вида селек­то­ров - осно­ван­ных на точ­ном соот­вет­ствии (equality-based) и на соот­вет­ствии набо­ру (set-based). Если в селек­то­ре ука­зы­ва­ет­ся несколь­ко соот­вет­ствий, то они долж­ны быть пере­чис­ле­ны через запя­тую - в дан­ном слу­чае для их объ­еди­не­ния будет исполь­зо­вать­ся логи­че­ский опе­ра­тор AND (&&).

Селек­тор, осно­ван­ный на точ­ном соот­вет­ствии под­дер­жи­ва­ет толь­ко три воз­мож­ных опе­ра­то­ра срав­не­ния - =, == и != - пер­вые два из них озна­ча­ют равен­ство, тре­тий - нера­вен­ство. Например:

В дан­ном при­ме­ре селек­тор выбе­рет все ресур­сы, у кото­рый ключ environment соот­вет­ству­ет зна­че­нию production, а так­же те ресур­сы, у кото­рых ключ tier не равен frontend (в том чис­ле ресур­сы, у кото­рых нет клю­ча tier).

Селек­тор, осно­ван­ный на соот­вет­ствии набо­ру так­же под­дер­жи­ва­ет три воз­мож­ных опе­ра­то­ра - in, notin и exists (послед­ний исполь­зу­ет­ся толь­ко для про­вер­ки наличия/отсутствия клю­ча). Например:

В дан­ном при­ме­ре, пер­вая стро­ка поз­во­лит выбрать все ресур­сы, у кото­рых есть ключ environment со зна­че­ни­я­ми production или qa. Вто­рая стро­ка выби­ра­ет ресур­сы у кото­рых есть ключ tier и любые зна­че­ния кро­ме frontend и backend. Тре­тья стро­ка слу­жит для выбо­ра всех ресур­сов, у кото­рых в мет­ках есть ключ partition (зна­че­ния не про­ве­ря­ют­ся), а чет­вер­тая - наобо­рот, выби­ра­ет ресур­сы кото­рые не име­ют клю­ча partition.

Есть воз­мож­ность ком­би­ни­ро­вать оба типа селек­то­ров, например:

Несколь­ко при­ме­ров исполь­зо­ва­ния селек­то­ров с ути­ли­той kubectl:

Набор подов для сер­ви­са (service) опре­де­ля­ет­ся с помо­щью селек­то­ра. Ана­ло­гич­но, набор подов, кото­ры­ми управ­ля­ет Replication Controller так­же опре­де­ля­ет­ся с помо­щью селек­то­ра. Для этих двух объ­ек­тов может быть исполь­зо­ван толь­ко селек­тор на осно­ве точ­но­го соот­вет­ствия (equality-based)
Выгля­деть это может при­мер­но так:

Для более новых объ­ек­тов Kubernetes, напри­мер, (Job, Deployment, Replica Set, Daemon Set) может быть исполь­зо­ван селек­тор на осно­ве соот­вет­ствия набо­ру (set-based). Например: