Objekty w Kubernetesie

• 1: Etykiety i selektory
• 2: Adnotatcje
• 3: Selektory pól

Ta strona wyjaśnia, jak obiekty Kubernetesa są reprezentowane w API Kubernetesa oraz jak można je wyrazić w formacie .yaml.

Czym są obiekty Kubernetesa

Obiekty Kubernetesa to trwałe byty w systemie Kubernetes. Kubernetes wykorzystuje te byty do reprezentowania stanu klastra. Konkretne zastosowania to m.in.:

• Jakie aplikacje kontenerowe są uruchomione (i na których węzłach)
• Zasoby dostępne dla tych aplikacji
• Polityki dotyczące zachowania tych aplikacji, takie jak polityki restartu, aktualizacje i tolerancja na błędy

Obiekt Kubernetesa to "zapis zamiaru" - gdy go utworzysz, Kubernetes będzie stale pilnować, aby taki obiekt faktycznie istniał. Tworząc obiekt, efektywnie informujesz Kubernetesa, jak ma wyglądać workload klastra; to jest pożądany stan twojego klastra.

Aby pracować z obiektami Kubernetesa-czy to w celu ich tworzenia, modyfikacji, czy usuwania—musisz użyć API Kubernetesa. Na przykład, kiedy używasz interfejsu wiersza poleceń kubectl, CLI wykonuje dla ciebie niezbędne wywołania do API Kubernetesa. Możesz także używać API Kubernetesa bezpośrednio w swoich własnych programach, korzystając z jednej z bibliotek klienckich.

Specyfikacja i status obiektu

Prawie każdy obiekt Kubernetesa zawiera dwa zagnieżdżone pola obiektowe, które zarządzają konfiguracją obiektu: obiekt spec i obiekt status. W przypadku obiektów, które mają spec, musisz go ustawić podczas tworzenia obiektu, dostarczając opis cech, jakie chcesz, aby zasób posiadał: jego pożądany stan.

Status opisuje aktualny stan obiektu, dostarczany i aktualizowany przez system Kubernetes i jego komponenty. Kubernetes warstwa sterowania stale i aktywnie zarządza rzeczywistym stanem każdego obiektu, aby dopasować go do pożądanego stanu, który dostarczyłeś.

Na przykład: w Kubernetesie, Deployment jest obiektem, który może reprezentować aplikację działającą na twoim klastrze. Kiedy tworzysz Deployment, możesz ustawić spec Deploymentu, aby określić, że chcesz, aby uruchomione były trzy repliki aplikacji. System Kubernetes odczytuje spec Deploymentu i uruchamia trzy instancje twojej pożądanej aplikacji—aktualizując status, aby dopasować go do twojego spec. Jeśli któraś z instancji ulegnie awarii (czyli zmieni się status), Kubernetes zareaguje na różnicę między spec a status - w tym przypadku, uruchamiając nową instancję.

Aby uzyskać więcej informacji na temat specyfikacji obiektu, statusu i metadanych, zobacz Kubernetes API Conventions.

Opis obiektu w Kubernetesie

Kiedy tworzysz obiekt w Kubernetesie, musisz dostarczyć specyfikację obiektu, która opisuje jego pożądany stan, a także podstawowe informacje o obiekcie (takie jak nazwa). Gdy używasz API Kubernetesa do tworzenia obiektu (bezpośrednio lub za pośrednictwem kubectl), żądanie API musi zawierać te informacje w formacie JSON w treści żądania. Najczęściej dostarczasz informacje do kubectl w pliku znanym jako manifest. Zgodnie z konwencją, manifesty są w formacie YAML (możesz również użyć formatu JSON). Narzędzia takie jak kubectl konwertują informacje z manifestu na JSON lub inny obsługiwany format serializacji podczas wysyłania żądania API przez HTTP.

Oto przykład manifestu pokazujący wymagane pola oraz specyfikację obiektu dla Deployment w Kubernetesie:

application/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

Jednym ze sposobów utworzenia Deploymentu przy użyciu pliku manifestu, takiego jak powyżej, jest użycie polecenia kubectl apply w interfejsie wiersza poleceń kubectl, przekazując plik .yaml jako argument. Oto przykład:

kubectl apply -f https://k8s.io/examples/application/deployment.yaml

Wynik jest podobny do tego:

deployment.apps/nginx-deployment created

Wymagane pola

W manifeście (pliku YAML lub JSON) dla obiektu Kubernetesa, który chcesz utworzyć, musisz ustawić wartości dla następujących pól:

• apiVersion - Której wersji API Kubernetesa używasz do utworzenia tego obiektu
• kind - Jakiego rodzaju obiekt chcesz utworzyć
• metadata - Dane pomagające jednoznacznie zidentyfikować obiekt, w tym łańcuch znaków name, UID oraz opcjonalnie namespace.
• spec - Jaki stan jest pożądany dla obiektu

Dokładny format obiektu spec jest inny dla każdego obiektu Kubernetesa i zawiera zagnieżdżone pola specyficzne dla tego obiektu. Kubernetes API Reference może pomóc ci znaleźć format spec dla wszystkich obiektów, które możesz utworzyć przy użyciu Kubernetesa.

Na przykład, zobacz pole spec w odniesieniu do API Poda. Dla każdego Poda, pole .spec określa pod i jego pożądany stan (taki jak nazwa obrazu kontenera dla każdego kontenera w ramach tego poda). Innym przykładem specyfikacji obiektu jest pole spec dla API StatefulSet. Dla StatefulSet, pole .spec określa StatefulSet i jego pożądany stan. W ramach .spec dla StatefulSet znajduje się szablon dla obiektów Pod. Ten szablon opisuje Pody, które kontroler StatefulSet utworzy w celu spełnienia specyfikacji StatefulSet. Różne rodzaje obiektów mogą również mieć różne .status; ponownie, strony referencyjne API szczegółowo opisują strukturę tego pola .status i jego zawartość dla każdego rodzaju obiektu.

Zobacz Najlepsze Praktyki Konfiguracji aby uzyskać dodatkowe informacje na temat pisania plików konfiguracyjnych YAML.

Walidacja pól po stronie serwera

Począwszy od wersji Kubernetesa v1.25, serwer API oferuje walidację pól po stronie serwera, która wykrywa nierozpoznane lub zduplikowane pola w obiekcie. Zapewnia ona całą funkcjonalność kubectl --validate po stronie serwera.

Narzędzie kubectl używa flagi --validate do ustawiania poziomu walidacji pól. Akceptuje wartości ignore, warn oraz strict, a także akceptuje wartości true (równoważne strict) i false (równoważne ignore). Domyślne ustawienie walidacji dla kubectl to --validate=true.

Strict : Ścisła walidacja pól, błędy w przypadku niepowodzenia walidacji

Warn : Walidacja pola jest przeprowadzana, ale błędy są zgłaszane jako ostrzeżenia zamiast powodować niepowodzenie żądania.

Ignore : Nie jest wykonywana żadna walidacja pola po stronie serwera

Kiedy kubectl nie może połączyć się z serwerem API, który obsługuje walidację pól, przełączy się na użycie walidacji po stronie klienta. Kubernetes 1.27 i nowsze wersje zawsze oferują walidację pól; starsze wydania Kubernetesa mogą tego nie robić. Jeśli twój klaster jest starszy niż v1.27, sprawdź dokumentację dla swojej wersji Kubernetesa.

Co dalej?

Jeśli dopiero zaczynasz swoją przygodę z Kubernetesem, przeczytaj więcej na temat:

• Pody, które są najważniejszymi podstawowymi obiektami Kubernetesa.
• Obiekty Deployment.
• Kontrolery w Kubernetesie.
• kubectl i kubectl commands.

Zarządzanie obiektami Kubernetesa wyjaśnia, jak używać kubectl do zarządzania obiektami. Możesz potrzebować zainstalować kubectl, jeśli jeszcze go nie masz.

Aby dowiedzieć się więcej ogólnie o API Kubernetesa, odwiedź:

• Kubernetes API overview

Aby dowiedzieć się więcej o obiektach w Kubernetesie, przeczytaj inne strony w tej sekcji:

1 - Etykiety i selektory

Etykiety to pary klucz/wartość, które są dołączane do obiektów takich jak Pody. Etykiety służą do określania identyfikacyjnych atrybutów obiektów, które są istotne i ważne dla użytkowników, ale bezpośrednio nie wpływają na semantykę głównego systemu. Etykiety mogą być używane do organizowania i wybierania podzbiorów obiektów. Etykiety mogą być dołączane do obiektów w momencie ich tworzenia, a następnie mogą być dodawane i modyfikowane w dowolnym momencie. Każdy obiekt może mieć zdefiniowany zestaw etykiet w postaci par klucz/wartość. Każdy klucz musi być unikalny dla konkretnego obiektu.

"metadata": {
  "labels": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Etykiety umożliwiają wydajne zapytania i obserwacje, co czyni je idealnym rozwiązaniem do użycia w interfejsach użytkownika (UI) i interfejsach wiersza poleceń (CLI). Informacje nieidentyfikujące powinny być rejestrowane przy użyciu adnotacji.

Motywacja

Etykiety umożliwiają użytkownikom odwzorowanie własnych struktur organizacyjnych na obiekty systemowe w sposób luźno powiązany, bez konieczności przechowywania tych odwzorowań przez klientów.

Rozmieszczanie usług i przetwarzanie wsadowe to często byty wielowymiarowe (np. wiele partycji lub wdrożeń, wiele ścieżek wydania, wiele poziomów, wiele mikrousług na poziom). Zarządzanie często wymaga operacji przekrojowych, co łamie enkapsulację ściśle hierarchicznych reprezentacji, zwłaszcza sztywnych hierarchii określanych przez infrastrukturę, a nie przez użytkowników.

Przykłady etykiet:

• "release" : "stable", "release" : "canary"
• "environment" : "dev", "environment" : "qa", "environment" : "production"
• "tier" : "frontend", "tier" : "backend", "tier" : "cache"
• "partition" : "customerA", "partition" : "customerB"
• "track" : "daily", "track" : "weekly"

Oto przykłady zalecanych etykiet ; możesz swobodnie opracowywać własne konwencje. Pamiętaj, że klucz etykiety musi być unikalny dla danego obiektu.

Składnia i zestaw znaków

Etykiety to pary klucz/wartość. Prawidłowe klucze etykiet mają dwa segmenty: opcjonalny prefiks i nazwę, oddzielone ukośnikiem (/). Segment nazwy jest wymagany i musi mieć maksymalnie 63 znaki, zaczynając i kończąc się znakiem alfanumerycznym ([a-z0-9A-Z]), z myślnikami (-), podkreśleniami (_), kropkami (.) i znakami alfanumerycznymi pomiędzy. Prefiks jest opcjonalny. Jeśli jest podany, prefiks musi być subdomeną DNS: serią etykiet DNS oddzielonych kropkami (.), o długości nieprzekraczającej łącznie 253 znaków, zakończoną ukośnikiem (/).

Jeśli prefiks zostanie pominięty, uważa się, że klucz etykiety jest prywatny dla użytkownika. Zautomatyzowane komponenty systemowe (np. kube-scheduler, kube-controller-manager, kube-apiserver, kubectl lub inne zewnętrzne automatyzacje), które dodają etykiety do obiektów końcowego użytkownika, muszą określać prefiks.

Prefiksy kubernetes.io/ i k8s.io/ są zarezerwowane dla podstawowych komponentów Kubernetesa.

Prawidłowa wartość etykiety:

• musi mieć 63 znaki lub mniej (może być puste),
• o ile ciąg nie jest pusty, musi zaczynać się i kończyć znakiem alfanumerycznym ([a-z0-9A-Z]),
• może zawierać myślniki (-), podkreślenia (_), kropki (.) oraz znaki alfanumeryczne pomiędzy.

Na przykład, oto manifest dla Poda, który ma dwie etykiety environment: production oraz app: nginx:

apiVersion: v1
kind: Pod
metadata:
  name: label-demo
  labels:
    environment: production
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Selektory etykiet

W przeciwieństwie do nazw i identyfikatorów UID, etykiety nie zapewniają unikalności. To oznacza, że wiele obiektów może mieć te same etykiety.

Za pomocą selektora etykiet klient/użytkownik może zidentyfikować zestaw obiektów. Selektor etykiet jest podstawowym mechanizmem grupującym w Kubernetesie.

API obecnie obsługuje dwa typy selektorów: oparte na równości i oparte na zbiorach. Selektor etykiet może składać się z wielu wymagań, które są oddzielone przecinkami. W przypadku wielu wymagań, wszystkie muszą być spełnione, więc separator przecinka działa jako logiczny operator AND (&&).

Interpretacja pustych lub niepodanych selektorów zależy od kontekstu. Każdy typ API, który je wykorzystuje, powinien jasno udokumentować ich dopuszczalność i sposób działania.

Wymóg oparty na równości

Wymagania oparte na równości lub nierówności umożliwiają filtrowanie według kluczy i wartości etykiet. Pasujące obiekty muszą spełniać wszystkie określone ograniczenia etykiet, chociaż mogą mieć również dodatkowe etykiety. Dopuszczalne są trzy rodzaje operatorów: =,==,!=. Pierwsze dwa reprezentują równość (i są synonimami), podczas gdy ostatni reprezentuje nierówność. Na przykład:

environment = production
tier != frontend

Poprzedni wybiera wszystkie zasoby, których klucz jest równy environment, a wartość równa się production. Drugi wybiera wszystkie zasoby, których klucz jest równy tier, a wartość różni się od frontend, oraz wszystkie zasoby bez etykiet z kluczem tier. Można filtrować zasoby w production wyłączając frontend przy użyciu operatora przecinka: environment=production,tier!=frontend

Jednym ze scenariuszy użycia dla wymagań etykiet opartych na równości jest specyfikacja kryteriów wyboru węzła przez Pody. Na przykład, poniższy przykładowy Pod wybiera węzły, na których etykieta accelerator istnieje i jest ustawiona na nvidia-tesla-p100.

apiVersion: v1
kind: Pod
metadata:
  name: cuda-test
spec:
  containers:
    - name: cuda-test
      image: "registry.k8s.io/cuda-vector-add:v0.1"
      resources:
        limits:
          nvidia.com/gpu: 1
  nodeSelector:
    accelerator: nvidia-tesla-p100

Wymagania oparte na zbiorach

Wymagania dotyczące etykiet bazujących na zbiorach (Set-based) umożliwiają filtrowanie kluczy według zbioru wartości. Obsługiwane są trzy rodzaje operatorów: in, notin oraz exists (tylko identyfikator klucza). Na przykład:

environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

• Pierwszy przykład wybiera wszystkie zasoby z kluczem równym environment i wartością równą production lub qa.
• Drugi przykład wybiera wszystkie zasoby z kluczem równym tier i wartościami innymi niż frontend i backend, oraz wszystkie zasoby bez etykiet z kluczem tier.
• Trzeci przykład wybiera wszystkie zasoby zawierające etykietę z kluczem partition; wartości nie są sprawdzane.
• Czwarty przykład wybiera wszystkie zasoby bez etykiety z kluczem partition; wartości nie są sprawdzane.

Podobnie separator przecinka działa jako operator AND. Filtrowanie zasobów z kluczem partition (bez względu na wartość) i z environment innym niż qa można osiągnąć używając partition,environment notin (qa). Selekcja etykiet oparta na zbiorach jest ogólną formą równości, ponieważ environment=production jest równoważne environment in (production); podobnie dla != i notin.

Wymagania oparte na zbiorach mogą być mieszane z wymaganiami opartymi na równości. Na przykład: partition in (customerA, customerB),environment!=qa.

API

Filtrowanie LIST i WATCH

Dla operacji list i watch można określić selektory etykiet, aby filtrować zestawy zwracanych obiektów; filtr określasz za pomocą parametru zapytania. (Aby dowiedzieć się więcej o mechanizmie watch w Kubernetesie, przeczytaj o wydajnym wykrywaniu zmian ). Oba wymagania są dozwolone (przedstawione tutaj tak, jak mogą się pojawić w ciągu zapytania URL):

• wymagania oparte na równości: ?labelSelector=environment%3Dproduction,tier%3Dfrontend
• _wymagania oparte na zbiorach: ?labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

Oba style selektorów etykiet mogą być używane do wylistowania lub obserwacji zasobów za pomocą klienta REST. Na przykład, kierując się na apiserver z kubectl i używając selekcji opartej na równości, można napisać:

kubectl get pods -l environment=production,tier=frontend

lub używając wymagań opartych na zbiorach:

kubectl get pods -l 'environment in (production),tier in (frontend)'

Jak już wspomniano, wymagania oparte na zbiorach są bardziej wyraziste. Na przykład mogą implementować operator LUB na wartościach:

kubectl get pods -l 'environment in (production, qa)'

lub ograniczenie dopasowywania negatywnego za pomocą operatora notin:

kubectl get pods -l 'environment,environment notin (frontend)'

Ustaw referencje w obiektach API

Niektóre obiekty Kubernetesa, takie jak services i replicationcontrollers, również używają selektorów etykiet do określania zbiorów innych zasobów, takich jak pods.

Usługa i Kontroler Replikacji

Zestaw podów, na które skierowana jest usługa (service), jest określany za pomocą selektora etykiet. Podobnie, populacja podów, którą powinien zarządzać kontroler replikacji (replicationcontroller), jest również określana za pomocą selektora etykiet.

Selektory etykiet dla obu obiektów są definiowane w plikach json lub yaml za pomocą map, i obsługiwane są tylko selektory wymagań oparte na równości:

"selector": {
    "component" : "redis",
}

lub

selector:
  component: redis

Ten selektor (odpowiednio w formacie json lub yaml) jest równoważny z component=redis lub component in (redis).

Zasoby, które obsługują wymagania oparte na zbiorach

Nowsze zasoby, takie jak Job, Deployment, ReplicaSet oraz DaemonSet, obsługują również wymagania oparte na zbiorach.

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - { key: tier, operator: In, values: [cache] }
    - { key: environment, operator: NotIn, values: [dev] }

matchLabels to mapa par {klucz,wartość}. Pojedyncza para {klucz,wartość} w mapie matchLabels jest równoważna elementowi matchExpressions, którego pole key to "klucz", operator to "In", a tablica values zawiera wyłącznie "wartość". matchExpressions to lista wymagań selektora podów. Prawidłowe operatory to In, NotIn, Exists i DoesNotExist. Zbiór wartości musi być niepusty w przypadku In i NotIn. Wszystkie wymagania zarówno z matchLabels, jak i matchExpressions są łączone za pomocą operatora AND - muszą być wszystkie spełnione, aby dopasowanie było możliwe.

Wybieranie zestawów węzłów

Jednym z przypadków użycia wybierania w oparciu o etykiety jest ograniczenie zestawu węzłów, na które można umieścić pod. Więcej informacji można znaleźć w dokumentacji na temat wyboru węzła.

Skuteczne wykorzystywanie etykiet

Możesz zastosować pojedynczą etykietę do dowolnych zasobów, ale nie zawsze jest to najlepsza praktyka. Istnieje wiele scenariuszy, w których należy użyć wielu etykiet, aby odróżnić zestawy zasobów od siebie nawzajem.

Na przykład różne aplikacje mogą używać różnych wartości dla etykiety app, ale aplikacja wielowarstwowa, taka jak przykład książki gości, będzie dodatkowo musiała rozróżniać każdą warstwę. Frontend mógłby nosić następujące etykiety:

labels:
  app: guestbook
  tier: frontend

podczas gdy instancje master i replica Redis miałyby różne etykiety tier, a być może nawet dodatkową etykietę role:

labels:
  app: guestbook
  tier: backend
  role: master

i

labels:
  app: guestbook
  tier: backend
  role: replica

Etykiety umożliwiają sortowanie i filtrowanie zasobów według dowolnego wymiaru określonego przez etykietę:

kubectl apply -f examples/guestbook/all-in-one/guestbook-all-in-one.yaml
kubectl get pods -Lapp -Ltier -Lrole

NAME                           READY  STATUS    RESTARTS   AGE   APP         TIER       ROLE
guestbook-fe-4nlpb             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-ght6d             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-fe-jpy62             1/1    Running   0          1m    guestbook   frontend   <none>
guestbook-redis-master-5pg3b   1/1    Running   0          1m    guestbook   backend    master
guestbook-redis-replica-2q2yf  1/1    Running   0          1m    guestbook   backend    replica
guestbook-redis-replica-qgazl  1/1    Running   0          1m    guestbook   backend    replica
my-nginx-divi2                 1/1    Running   0          29m   nginx       <none>     <none>
my-nginx-o0ef1                 1/1    Running   0          29m   nginx       <none>     <none>

kubectl get pods -lapp=guestbook,role=replica

NAME                           READY  STATUS   RESTARTS  AGE
guestbook-redis-replica-2q2yf  1/1    Running  0         3m
guestbook-redis-replica-qgazl  1/1    Running  0         3m

Aktualizacja etykiet

Czasami możesz chcieć zmienić etykiety istniejących podów i innych zasobów przed utworzeniem nowych zasobów. Można to zrobić za pomocą kubectl label. Na przykład, jeśli chcesz oznaczyć wszystkie swoje pody NGINX jako warstwę frontendową, wykonaj:

kubectl label pods -l app=nginx tier=fe

pod/my-nginx-2035384211-j5fhi labeled
pod/my-nginx-2035384211-u2c7e labeled
pod/my-nginx-2035384211-u3t6x labeled

Najpierw filtruje wszystkie pody z etykietą "app=nginx", a następnie nadaje im etykietę "tier=fe". Aby zobaczyć pody, które zostały oznaczone etykietą, uruchom:

kubectl get pods -l app=nginx -L tier

NAME                        READY     STATUS    RESTARTS   AGE       TIER
my-nginx-2035384211-j5fhi   1/1       Running   0          23m       fe
my-nginx-2035384211-u2c7e   1/1       Running   0          23m       fe
my-nginx-2035384211-u3t6x   1/1       Running   0          23m       fe

To wyświetla wszystkie pody z etykietą "app=nginx", z dodatkową kolumną etykiet reprezentującą warstwę podów (określoną za pomocą -L lub --label-columns).

Aby uzyskać więcej informacji, zobacz kubectl label.

Co dalej?

• Dowiedz się, jak dodać etykietę do węzła
• Zobacz Well-known labels, Annotations and Taints
• Zobacz Zalecane etykiety
• Enforce Pod Security Standards with Namespace Labels
• Przeczytaj blog Writing a Controller for Pod Labels

2 - Adnotatcje

Możesz używać Kubernetesowych adnotacji do dołączania dodatkowych (czyli takich, które nie są wykorzystywane przy identyfikacji) metadanych do obiektów. Narzędzia i biblioteki mogą odczytywać te metadane.

Dołączanie metadanych do obiektów

Możesz używać etykiet (ang. labels) lub adnotacji (ang. annotations), aby dołączać metadane do obiektów Kubernetesa. Etykiety pomagają w wybieraniu obiektów i wyszukiwaniu ich zbiorów na podstawie określonych warunków. Z kolei adnotacje nie są używane do identyfikacji ani selekcji obiektów. Metadane w adnotacjach mogą mieć dowolny rozmiar i strukturę - mogą być małe lub duże, uporządkowane lub nie, i zawierać znaki niedozwolone w etykietach. Dopuszczalne jest jednoczesne użycie etykiet i adnotacji w tym samym obiekcie.

Adnotacje, podobnie jak etykiety, są mapami klucz/wartość:

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}

Oto przykłady informacji, które mogą być zapisane w adnotacjach:

• Pola zarządzane przez warstwę konfiguracji deklaratywnej. Dołączanie tych pól jako adnotacji odróżnia je od wartości domyślnych ustawianych przez klientów lub serwery, oraz od pól generowanych automatycznie i pól ustawianych przez systemy automatycznego skalowania lub automatycznego dopasowywania rozmiaru.

• Informacje dotyczące kompilacji, wersji lub obrazów, takie jak znaczniki czasu, identyfikatory wersji, gałąź git, numery PR, skróty obrazów i adres rejestru.

• Referencje do zewnętrznych źródeł danych takich jak logi, metryki monitorujące, wyniki analiz czy dane audytowe.

• Informacje o bibliotece klienckiej lub narzędziu, które mogą być wykorzystane do debugowania - na przykład nazwa, wersja i dane o kompilacji.

• Informacje o pochodzeniu użytkownika, narzędzia lub systemu, takie jak adresy URL powiązanych obiektów z innych komponentów ekosystemu.

• Metadane wykorzystywane przez proste narzędzia do wdrażania zmian (rollout), takie jak zapis stanu konfiguracji lub punktów kontrolnych służących do śledzenia postępu wdrożenia.

• Numery telefonów lub pagerów osób odpowiedzialnych, lub wpisy do katalogu określające, gdzie można znaleźć te informacje, takie jak strona internetowa zespołu.

• Instrukcje od użytkownika końcowego kierowane do implementacji, mające na celu zmianę zachowania systemu lub uruchomienie niestandardowych funkcji.

Zamiast używać adnotacji, można przechowywać tego typu informacje w zewnętrznej bazie danych lub katalogu, ale to znacznie utrudniłoby tworzenie wspólnych bibliotek klienckich i narzędzi do wdrażania, zarządzania, introspekcji i tym podobnych działań.

Składnia i zestaw znaków

Adnotacje są parami klucz/wartość. Prawidłowe klucze adnotacji mają dwa segmenty: opcjonalny prefiks oraz nazwę, oddzielone ukośnikiem (/). Segment nazwy jest wymagany i musi mieć maksymalnie 63 znaki, zaczynać się i kończyć znakiem alfanumerycznym ([a-z0-9A-Z]) oraz może zawierać myślniki (-), podkreślenia (_), kropki (.) i znaki alfanumeryczne pomiędzy nimi. Prefiks jest opcjonalny. Jeśli zostanie określony, prefiks musi być subdomeną DNS: serią etykiet DNS oddzielonych kropkami (.), nie dłuższą w sumie niż 253 znaki, zakończoną ukośnikiem (/).

Jeśli prefiks jest pominięty, zakłada się, że klucz adnotacji należy wyłącznie do użytkownika. Zautomatyzowane komponenty systemowe (np. kube-scheduler, kube-controller-manager, kube-apiserver, kubectl lub inna automatyzacja firm trzecich), które dodają adnotacje do obiektów końcowego użytkownika, muszą określić prefiks.

Prefiksy kubernetes.io/ i k8s.io/ są zarezerwowane dla podstawowych komponentów Kubernetesa.

Na przykład, oto manifest dla Poda, który posiada adnotację imageregistry: https://hub.docker.com/ :

apiVersion: v1
kind: Pod
metadata:
  name: annotations-demo
  annotations:
    imageregistry: "https://hub.docker.com/"
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Co dalej?

• Dowiedz się więcej o Etykietach i Selektorach.
• Znajdź Typowe etykiety, Adnotacje i Tainty (ang. Taints)

3 - Selektory pól

Selektory pól (Field selectors) pozwalają na wybór obiektów Kubernetesa na podstawie wartości jednego lub kilku pól zasobów. Oto kilka przykładów zapytań z użyciem selektora pól:

• metadata.name=my-service
• metadata.namespace!=default
• status.phase=Pending

Polecenie kubectl wybiera wszystkie Pody, dla których wartość pola status.phase to Running:

kubectl get pods --field-selector status.phase=Running

Obsługiwane pola

Obsługiwane selektory pól różnią się w zależności od typu zasobu Kubernetesa. Wszystkie typy zasobów obsługują pola metadata.name oraz metadata.namespace. Użycie nieobsługiwanych selektorów pól skutkuje błędem. Na przykład:

kubectl get ingress --field-selector foo.bar=baz

Error from server (BadRequest): Unable to find "ingresses" that match label selector "", field selector "foo.bar=baz": "foo.bar" is not a known field selector: only "metadata.name", "metadata.namespace"

Lista obsługiwanych pól

Pola zasobów niestandardowych

Wszystkie niestandardowe typy zasobów obsługują pola metadata.name oraz metadata.namespace.

Dodatkowo, pole spec.versions[*].selectableFields w CustomResourceDefinition określa, które inne pola w zasobie niestandardowym mogą być używane w selektorach pól. Zobacz selectable fields for custom resources aby uzyskać więcej informacji o tym, jak używać selektorów pól z CustomResourceDefinitions.

Obsługiwane operatory

Możesz używać operatorów =, == i != z selektorami pól (= and == oznaczają to samo). Na przykład ta komenda kubectl wybiera wszystkie usługi Kubernetesa, które nie znajdują się w przestrzeni nazw default:

kubectl get services  --all-namespaces --field-selector metadata.namespace!=default

Złożone selektory

Podobnie jak etykieta i inne selektory, selektory pól mogą być łączone w postaci listy rozdzielanej przecinkami. To polecenie kubectl wybiera wszystkie Pody, dla których status.phase nie jest równe Running, a pole spec.restartPolicy jest równe Always:

kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always

Wiele typów zasobów

Możesz używać selektorów pól w różnych typach zasobów. To polecenie kubectl wybiera wszystkie obiekty typu Statefulset i Service, które nie znajdują się w przestrzeni nazw default:

kubectl get statefulsets,services --all-namespaces --field-selector metadata.namespace!=default