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

Для добав­ле­ния про­из­воль­ных, неиден­ти­фи­ци­ру­ю­щи­их мета­дан­ных к созда­ва­е­мым в кла­сте­ре Kubernetes объ­ек­там мож­но исполь­зо­вать анно­та­ции. Кли­ен­ты (в том чис­ле инстру­мен­ты и биб­лио­те­ки) могут полу­чать и исполь­зо­вать эти данные.

В Kubernetes для добав­ле­ния мета­дан­ных к объ­ек­там исполь­зу­ют­ся мет­ки и анно­та­ции. Мет­ки обыч­но исполь­зу­ют­ся для выбо­ра объ­ек­тов селек­то­ра­ми или для поис­ка набо­ров объ­ек­тов, кото­рые соот­вет­ству­ют опре­де­лен­ным усло­ви­ям. Анно­та­ции же, напро­тив, не исполь­зу­ют­ся для выбо­ра или иден­ти­фи­ка­ции объ­ек­тов. В анно­та­ци­ях мож­но исполь­зо­вать сим­во­лы, запре­щен­ные для исполь­зо­ва­ния в мет­ках, анно­та­ции могут быть струк­ту­ри­ро­ван­ны­ми или нет, а так­же отли­чать­ся раз­ме­ром (коли­че­ством символов).

Как и мет­ки, анно­та­ции пред­став­ля­ют собой пары ключ/значение, и в общем виде могут выгля­деть так:

Конеч­но, вме­сто исполь­зо­ва­ния анно­та­ций, все эти допол­ни­тель­ные дан­ные могут хра­нить­ся во внеш­ней базе дан­ных, но это не так удоб­но и тре­бу­ет допол­ни­тель­ных ресур­сов на под­дер­жа­ние базы дан­ных в акту­аль­ном состоянии.

Несколь­ко при­ме­ров инфор­ма­ции, кото­рую мож­но (а ино­гда и нуж­но) добав­лять в аннотации:

• поля, созда­ва­е­мые декла­ра­тив­ной кон­фи­гу­ра­ци­ей (declarative configuration layer). Такие поля, при­креп­лен­ные в виде анно­та­ций, поз­во­ля­ют отли­чать их от зна­че­ний по умол­ча­нию или от авто­ма­ти­че­ски гене­ри­ру­е­мых полей;
• вер­сия бил­да, рели­за, инфор­ма­ция о docker-обра­зе (вре­мен­ные мет­ки, имя вет­ви из репо­зи­то­рия, номер PR и т.д.);
• инфор­ма­ция о логи­ро­ва­нии, мони­то­рин­ге, ана­ли­ти­ке и пр.;
• инфор­ма­ция об исполь­зу­е­мых биб­лио­те­ках или ути­ли­тах, кото­рые могут исполь­зо­вать­ся в целях отладки;
• инфор­ма­ция о поль­зо­ва­те­ле или систе­ме (к при­ме­ру, URL-адре­са свя­зан­ных объ­ек­тов или спи­сок зави­си­мых микросервисов);
• мета­дан­ные для уско­рен­но­го отка­та на преды­ду­щую рабо­то­спо­соб­ную вер­сию при­ло­же­ния (напри­мер, конфиги);
• кон­такт­ные дан­ные ответ­ствен­ных за дан­ный объ­ект лиц.

Сто­ит отме­тить, что при созда­нии объ­ек­тов в кла­сте­ре Kubernetes с помо­щью коман­ды kubectl apply -а <имя_файла>, в анно­та­ции к объ­ек­ту авто­ма­ти­че­ски создаст­ся ключ kubectl.kubernetes.io/last-applied-configuration:, содер­жа­щий, как мож­но дога­дать­ся, послед­нюю успеш­но при­ме­нен­ную кон­фи­гу­ра­цию (в json-формате).

Напри­мер, если сер­вис опи­сан в фай­ле auth0-svc.yaml сле­ду­ю­щим образом:

и созда­ем его командой:

то с помо­щью команды:

мож­но полу­чить не толь­ко опи­са­ние сер­ви­са (в том чис­ле, с поля­ми по умол­ча­нию), но и послед­нюю удач­но раз­вер­ну­тую вер­сию из аннотации: