Il fonctionne en deux phases. Le filtrage écarte les noeuds qui ne peuvent pas héberger le pod, selon les requests de ressources face à la capacité allouable, les node selectors, les taints que le pod ne tolère pas, et les contraintes de volume ou d'affinité. Le scoring classe ensuite les survivants avec des règles comme l'étalement entre noeuds et la préférence pour les moins chargés. Le gagnant reçoit le binding, et c'est le kubelet de ce noeud qui démarre réellement le pod.
Pourquoi les recruteurs posent cette question
L'ordonnancement apparaît dans les vrais incidents sous forme de pods en Pending et de charge déséquilibrée, donc le recruteur veut savoir si vous savez le déboguer. Le détail clé qu'il attend, c'est que l'ordonnancement se base sur les requests, pas sur les limits ni sur l'usage réel, ce qui explique la plupart des têtes surprises pendant les incidents de capacité. L'affinité, les taints et les topology spread constraints montrent que vous avez façonné le placement volontairement plutôt que d'accepter les valeurs par défaut.
Comment structurer votre réponse
- Nommez les deux phases : filtrage puis scoring, puis binding.
- Soulignez que ce sont les requests qui pilotent le placement, pas les limits ni l'usage réel.
- Listez les leviers : selectors, affinité, taints, topology spread.
- Dites comment vous déboguez un pod bloqué en Pending.
Exemple de réponse
L'ordonnanceur surveille les pods sans noeud assigné et les passe par le filtrage puis le scoring. Le filtrage élimine tout noeud qui ne peut pas convenir : pas assez de CPU ou de mémoire allouable pour les requests du pod, un node selector qui ne correspond pas, un taint sans toleration, un volume qui ne peut pas s'attacher dans cette zone. Le scoring classe ensuite ce qui reste, en favorisant l'étalement et l'équilibre d'utilisation, et le meilleur noeud gagne et reçoit le binding. Le détail qui compte en exploitation, c'est qu'il ordonnance sur les requests, pas sur ce que le pod consomme vraiment. Du coup un cluster peut afficher quinze pour cent d'utilisation dans les tableaux de bord et refuser quand même d'ordonnancer quoi que ce soit, parce que tout le monde a mis des requests très au-dessus de l'usage réel. Quand un pod reste en Pending, je vais droit aux events du pod, puisque l'ordonnanceur vous dit exactement quel prédicat a échoué et sur combien de noeuds. Pour façonner le placement, j'utilise des topology spread constraints entre zones pour la disponibilité, et des taints avec tolerations pour garder les charges générales hors des noeuds à matériel spécial.
Vous passez cet entretien bientôt ? GhostPilot écoute votre appel en direct, repère la question dès qu'elle est posée et affiche une réponse structurée à l'écran en temps réel. Essayez-le lors de votre prochain entretien blanc, ou prenez un Session Pass à $29, sans abonnement, pour le jour J.
Voir comment ça marcheQuestions de relance à prévoir
- Quelle est la différence entre un pod évincé et un pod préempté ?
- Comment les requests et les limits interagissent-elles avec les classes de qualité de service ?
- Comment empêcheriez-vous deux réplicas du même service de se retrouver sur un seul noeud ?
Autres questions pour Ingénieur DevOps
Votre recruteur posera sa propre version de celle-ci. Collez votre véritable fiche de poste dans le Question Predictor gratuit et obtenez les 20 questions que ce poste a le plus de chances de poser, avec ce que chacune cherche vraiment à sonder.
Prédire mes questions