Noms et identifiants d'objets
Chaque objet dans votre cluster a un Nom qui est unique pour ce type de ressource. Chaque objet Kubernetes a également un UID qui est unique dans l'ensemble de votre cluster.
Par exemple, vous ne pouvez avoir qu'un seul Pod nommé myapp-1234 dans le même namespace, mais vous pouvez avoir un Pod et un Déploiement qui sont chacun nommés myapp-1234.
Pour les attributs fournis par l'utilisateur qui ne sont pas uniques, Kubernetes fournit des labels et des annotations.
Noms
Un texte fourni par le client qui fait référence à un objet dans une URL de ressource, comme /api/v1/pods/some-name.
Seul un objet d'un certain type peut avoir un nom donné à la fois. Cependant, si vous supprimez l'objet, vous pouvez créer un nouvel objet avec le même nom.
Les noms doivent être uniques pour toutes les versions d'API de la même ressource. Les ressources API sont distinguées par leur groupe API, leur type de ressource, leur label (pour les ressources avec label) et leur nom. En d'autres termes, la version de l'API est sans importance dans ce contexte.
Note:
Dans les cas où les objets représentent une entité physique, comme un Noeud représentant un hôte physique, lorsque l'hôte est recréé sous le même nom sans supprimer et recréer le Noeud, Kubernetes considère le nouvel hôte comme l'ancien, ce qui peut entraîner des incohérences.Voici quatre types de contraintes de nom couramment utilisées pour les ressources.
Noms de sous-domaine DNS
La plupart des types de ressources nécessitent un nom qui peut être utilisé comme un sous-domaine DNS tel que défini dans RFC 1123. Cela signifie que le nom doit :
- ne pas contenir plus de 253 caractères
- contenir uniquement des caractères alphanumériques minuscules, '-' ou '.'
- commencer par un caractère alphanumérique
- se terminer par un caractère alphanumérique
Noms de label RFC 1123
Certains types de ressources nécessitent que leurs noms suivent la norme des labels DNS telle que définie dans RFC 1123. Cela signifie que le nom doit :
- contenir au maximum 63 caractères
- contenir uniquement des caractères alphanumériques minuscules ou '-'
- commencer par un caractère alphanumérique
- se terminer par un caractère alphanumérique
Noms de label RFC 1035
Certains types de ressources nécessitent que leurs noms suivent la norme des labels DNS telle que définie dans RFC 1035. Cela signifie que le nom doit :
- contenir au maximum 63 caractères
- contenir uniquement des caractères alphanumériques minuscules ou '-'
- commencer par un caractère alphabétique
- se terminer par un caractère alphanumérique
Note:
La seule différence entre les normes des labels RFC 1035 et RFC 1123 est que les labels RFC 1123 sont autorisées à commencer par un chiffre, tandis que les labels RFC 1035 ne peuvent commencer qu'avec une lettre alphabétique minuscule.Noms de segment de chemin
Certains types de ressources nécessitent que leurs noms puissent être encodés en toute sécurité en tant que segment de chemin. En d'autres termes, le nom ne peut pas être "." ou ".." et le nom ne peut pas contenir "/" ou "%".
Voici un exemple de manifeste pour un Pod nommé nginx-demo.
apiVersion: v1
kind: Pod
metadata:
name: nginx-demo
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
Note:
Certains types de ressources ont des restrictions supplémentaires sur leurs noms.UIDs
Chaîne de caractères générée par les systèmes Kubernetes pour identifier de manière unique les objets.
Chaque objet créé pendant toute la durée de vie d'un cluster Kubernetes possède un UID distinct. Il vise à distinguer les occurrences historiques d'entités similaires.
Les UIDs Kubernetes sont des identifiants universellement uniques (également connus sous le nom d'UUID). Les UUID sont normalisés selon ISO/IEC 9834-8 et ITU-T X.667.
A suivre
- Lisez à propos des labels et des annotations dans Kubernetes.
- Consultez le document de conception Identifiers and Names in Kubernetes.