À quoi sert un sélecteur de pod de déploiement kubernetes?

Question

Je ne vois pas pourquoi kubernetes a besoin d'un sélecteur de pod dans une déclaration de déploiement qui ne peut contenir qu'un seul modèle de pod? N'hésitez pas à m'informer pourquoi les ingénieurs de kubernetes ont introduit une instruction de sélection dans une définition de déploiement au lieu de sélectionner automatiquement le pod dans le modèle?

 ---
apiVersion: v1
kind: Service
metadata:
  name: grpc-service

spec:
  type: LoadBalancer
  ports:
  - name: grpc
    port: 8080
    targetPort: 8080
    protocol: TCP
  selector:
    app: grpc-test

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: grpc-deployment

spec:
  replicas: 1
  revisionHistoryLimit: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0

  selector:
    matchLabels:
      app: grpc-test

  template:
    metadata:
      labels:
        app: grpc-test

    spec:
      containers:
      ...
 

Pourquoi ne pas simplement définir quelque chose comme ça?

 ---
apiVersion: v1
kind: Service
metadata:
  name: grpc-service

spec:
  type: LoadBalancer
  ports:
  - name: grpc
    port: 8080
    targetPort: 8080
    protocol: TCP
  selector:
    app: grpc-test

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: grpc-deployment

spec:
  replicas: 1
  revisionHistoryLimit: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0

  template:
    metadata:
      labels:
        app: grpc-test

    spec:
      containers:
      ...
 

Answer 1

Ah! C'est marrant, j'ai essayé une fois enveloppant ma tête autour de la notion de label sélecteurs ainsi avant. Donc, ici, il va...

Tout d'abord, ce que l'enfer sont ces étiquettes? Étiquettes à l'intérieur de kubernetes sont les principaux moyens d'identifier des objets. Un contrôleur de contrôles gousses basé sur leur étiquette à la place de leur nom. Dans ce cas particulier, ils sont par exemple destinés à identifier les gousses appartenant au déploiement du jeu de réplicas.

En fait vous n'avez pas à définissent implicitement .spec.selector lors de l'utilisation de l' v1beta1 extensions. Il serait, dans ce cas, par défaut de .spec.template.labels. Toutefois, si vous ne le faites pas, vous pouvez rencontrer des problèmes avec kubectl apply une fois que l'un ou plusieurs des étiquettes qui sont utilisés pour la sélection de changer, car kubeclt apply examinera kubectl.kubernetes.io/last-applied-configuration lorsque l'on compare les changements et annotation contient uniquement la saisie de l'utilisateur quand il a créé la ressource et aucun de la valeur par défaut des champs. Vous recevrez un message d'erreur car il ne peut pas calculer la diff comme:

spec.template.metadata.labels: Invalid value: {"app":"nginx"}: `selector` does not match template `labels`

Comme vous pouvez le voir, c'est une grosse lacune, car il signifie que vous ne pouvez pas modifier les étiquettes qui sont en train d'être utilisé comme sélecteur étiquette ou elle serait complètement casser votre déploiement de flux. Il a été "fixé" en apps/v1beta2 en exigeant des sélecteurs être définis de façon explicite, le refus de mutation sur ces champs.

Donc dans votre exemple, vous avez réellement n'avez pas à les définir! La création de l'œuvre et de l'utilisation de vos .spec.template.labels par défaut. Mais ouais, dans un avenir proche, si vous devez utiliser v1beta2, le champ est obligatoire. J'espère que ce genre de réponses à votre question et je n'ai pas plus de confusion ;)

Answer 2

Toutefois, si vous ne le faites pas, vous pouvez rencontrer des problèmes avec kubectl de s'appliquer dès que l'un ou plusieurs des étiquettes qui sont utilisés pour la sélection de changer parce que kubeclt s'appliquent regarder kubectl.kubernetes.io/dernière appliqué à la configuration lorsque l'on compare les changements et annotation contient uniquement la saisie de l'utilisateur quand il a créé la ressource et aucun de la valeur par défaut des champs.

Citant Toon réponse.

Mon interprétation est qu'il n'est pas logiquement nécessaire à tous. C'est seulement en raison de la limitation de la mise en œuvre actuelle de Kubernetes, qu'il a une certaine bizarre "comportement" en ce que la fonctionnalité qu'il utilise pour "comparer" deux déploiements / objets ne tient pas compte des "valeurs par défaut".

Answer 3

Pour autant que je sache, le sélecteur dans le déploiement est une propriété facultative.

Le modèle est le seul champ de spécifications requis.

Donc, vous n'avez pas besoin d'utiliser le sélecteur d'étiquettes dans le déploiement, et dans votre exemple, je ne vois pas pourquoi vous ne pouviez pas utiliser cette dernière partie?