Nazwy i identyfikatory objektów

Każdy obiekt w Twoim klastrze ma Nazwę, która jest unikalna dla tego typu zasobu. Każdy obiekt Kubernetesa posiada również UID, który jest unikalny w całym Twoim klastrze.

Na przykład, w jednym namespace można mieć tylko jeden Pod o nazwie myapp-1234, ale można mieć jeden Pod i jeden Deployment, które są nazwane myapp-1234.

Dla nieunikalnych atrybutów dostarczonych przez użytkownika, Kubernetes udostępnia etykiety oraz adnotacje.

Nazwy

Ciąg znaków dostarczony przez klienta, który odnosi się do obiektu w adresie URL zasobu, na przykład /api/v1/pods/some-name.

W danym momencie tylko jeden obiekt danego typu może mieć określoną nazwę. Jednak po usunięciu tego obiektu można utworzyć nowy o tej samej nazwie.

Nazwy muszą być unikalne we wszystkich wersjach API dla tego samego zasobu.

Kubernetes jednoznacznie identyfikuje obiekty przy użyciu kombinacji czterech atrybutów:

• **Grupa API (ang. API group) ** (np. apps)
• Rodzaj zasobu (ang. resource type) (np. deployments)
• **Przestrzeń nazw (ang. namespace) ** (dla zasobów z przestrzeniami nazw)
• Nazwa (ang. name)

Choć do tego samego zasobu można dostać się przez różne wersje API (takie jak v1 lub v1beta1), wersje te są tylko odmiennymi reprezentacjami tego samego obiektu źródłowego. Ponieważ wersja API nie wchodzi w skład klucza jednoznacznie identyfikującego obiekt, nie można utworzyć w tej samej przestrzeni nazw dwóch obiektów o identycznej nazwie i typie zasobu, różniących się jedynie wersją API.

Serwer może wygenerować nazwę, gdy zamiast name w żądaniu utworzenia zasobu podano generateName. Gdy używane jest generateName, podana wartość służy jako prefiks nazwy, do którego serwer dodaje wygenerowany sufiks. Nawet jeśli nazwa jest generowana, może wystąpić konflikt z istniejącymi nazwami, co skutkuje odpowiedzią HTTP 409. W Kubernetes v1.31 i nowszych wersjach jest to znacznie mniej prawdopodobne, ponieważ serwer podejmuje do 8 prób wygenerowania unikalnej nazwy przed zwróceniem odpowiedzi HTTP 409.

Poniżej znajdują się cztery typy często używanych ograniczeń nazw dla zasobów.

Nazwy subdomen DNS

Większość typów zasobów wymaga nazwy, która może być używana jako nazwa poddomeny DNS, zgodnie z definicją w RFC 1123. Oznacza to, że nazwa musi:

• zawierać nie więcej niż 253 znaki
• zawierać tylko małe litery alfanumeryczne, '-' lub '.'
• zaczynać się od znaku alfanumerycznego
• kończyć się znakiem alfanumerycznym

Nazwy etykiet zgodnie z RFC 1123

Niektóre typy zasobów wymagają, aby ich nazwy były zgodne ze standardem etykiet DNS, jak zdefiniowano w RFC 1123. Oznacza to, że nazwa musi:

• zawierać maksymalnie 63 znaków
• zawierać tylko małe litery alfanumeryczne lub '-'
• zaczynać się od litery alfabetu
• kończyć się znakiem alfanumerycznym

Nazwy etykiet zgodne z RFC 1035

Niektóre typy zasobów wymagają, aby ich nazwy spełniały standardy etykiet DNS zgodnie z definicją w RFC 1035. Oznacza to, że nazwa musi:

• zawierać maksymalnie 63 znaków
• zawierać tylko małe litery alfanumeryczne lub '-'
• zaczynać się od litery alfabetu
• kończyć się znakiem alfanumerycznym

Nazwy segmentów ścieżki

Niektóre typy zasobów wymagają, aby ich nazwy mogły być bezpiecznie kodowane jako segment ścieżki. Innymi słowy, nazwa nie może być "." ani ".." oraz nie może zawierać "/" ani "%".

Oto przykładowy manifest dla Poda o nazwie nginx-demo.

apiVersion: v1
kind: Pod
metadata:
  name: nginx-demo
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

UIDy

Unikalny identyfikator obiektu generowany automatycznie przez system Kubernetes.

Każdy obiekt utworzony w trakcie całego cyklu życia klastra Kubernetesa posiada unikalny UID. Jego celem jest rozróżnianie historycznych wystąpień podobnych jednostek.

UID-y Kubernetesa to uniwersalne unikalne identyfikatory (znane również jako UUID). UUID są ustandaryzowane jako ISO/IEC 9834-8 oraz jako ITU-T X.667.

Co dalej?

• Przeczytaj o etykietach i adnotacjach w Kubernetesie.
• Zobacz Identyfikatory i nazwy w Kubernetesie.