Ensemble de répliques 1
C02T30K2GTFM:ask erkanerol$ kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS rs-1-996cz 1/1 Running 0 5m13s app=nginx,version=1.7.1 rs-1-ktv9z 1/1 Running 0 5m13s app=nginx,version=1.7.1 rs-1-w7sbg 1/1 Running 0 5m13s app=nginx,version=1.7.1 rs-2-2z8rb 1/1 Running 0 4m26s app=nginx,version=1.7.9 rs-2-5c56s 1/1 Running 0 4m26s app=nginx,version=1.7.9 rs-2-hls9p 1/1 Running 0 4m26s app=nginx,version=1.7.9
Ensemble de répliques 2
apiVersion: apps/v1
kind: ReplicaSet
metadata:
labels:
app: nginx
name: rs-2
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
version: 1.7.9
spec:
containers:
- image: nginx:1.7.9
name: nginx-1
restartPolicy: Always
Lorsque je crée ces deux ReplicaSets, l'un ignore les pods créés par l'autre .
apiVersion: apps/v1
kind: ReplicaSet
metadata:
labels:
app: nginx
name: rs-1
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
version: 1.7.1
spec:
containers:
- image: nginx:1.7.1
name: nginx-1
restartPolicy: Always
D'après ce que je comprends de la documentation, s'il y a suffisamment de pods qui correspondent au sélecteur d'un réplicaset, il ne devrait pas créer de nouveaux pods. Pourquoi est-ce arrivé? Utilise-t-il les références ownerReferences?
3 Réponses :
Les libellés sont des paires clé / valeur attachées aux objets tels que les pods, le déploiement, etc. Les libellés sont utilisés pour identifier et regrouper les ressources kubernetes.
Selon la documentation officielle de kubernetes,
Contrairement aux noms et aux étiquettes UUID, elles ne fournissent pas d’unicité. En général, nous nous attendons à ce que de nombreux objets portent les mêmes étiquettes.
Les étiquettes ne sont pas uniques, les étiquettes sont utilisées pour identifier le groupe d'objets qui sont liés d'une certaine manière afin que vous puissiez lister ou regarder ces objets.
Prenons l'exemple que vous avez mentionné dans votre question, qui a deux réplicas avec 3 répliques chacun. Les deux répliques représentent les étiquettes app: nginx et version: 1.7.9 ou version:1.7.1
Maintenant si vous voulez identifier tous les pods ayant des étiquettes app = nginx , vous pouvez exécuter la commande suivante:
kubectl get pods -l app=nginx,version=1.7.1
Il vous montrera les 6 pods. p>
Maintenant, si vous souhaitez identifier les pods qui ont app = nginx ainsi qu'une version spécifique de ce nginx, vous devez exécuter la commande suivante:
kubectl get pods -l app=nginx
Maintenant, il ne vous montrera que trois pods qui ont les deux étiquettes.
Pour plus d'informations, consultez la documentation officielle sur les étiquettes ici
les réplicasets utilisent le sélecteur pour lister les pods à gérer. ils doivent utiliser la première requête que vous avez partagée. pourquoi créent-ils de nouveaux pods alors qu'il y en a déjà 3?
En effet, deux jeux de réplicas ont deux valeurs .metadata.name différentes et ont donc tous deux leurs propres ressources isolées. Le même comportement sera disponible même avec les ensembles de déploiement. En supposant que vous nommez les deux avec des valeurs différentes, les deux ensembles de déploiement feraient également tourner des pods isolés avec les mêmes étiquettes.
les déploiements utilisent l'étiquette «pod-template-hash» pour éviter les conflits.
Il semble qu'ils utilisent ownerReferences. Si tel est le cas, cela ne correspond pas au comportement documenté.
PR: https://github.com/kubernetes/kubernetes/pull/27600
Problème: https://github.com/kubernetes/website/issues/12205