30 pods.

Données

Grandeur Valeur

Capacité mémoire du nœud 24000 MB
Réserve (système, kubelet, seuil d'éviction) 3000 MB
Mémoire allouable 
24000
−
3000
=
21000
24000−3000=21000 MB
Requête mémoire par pod 700 MB

Raisonnement chiffré

Le nombre maximal entier de pods est le plancher du quotient de la mémoire allouable par la requête unitaire :

𝑁
max
⁡
=
⌊
24000
−
3000
700
⌋
=
⌊
21000
700
⌋
=
⌊
30
,
0
⌋
=
30
N
max
	​

=⌊
700
24000−3000
	​

⌋=⌊
700
21000
	​

⌋=⌊30,0⌋=30

Vérification par substitution : 
30
×
700
=
21000
30×700=21000 MB, soit exactement la mémoire allouable, reste 
21000
−
21000
=
0
21000−21000=0 MB. Un 31e pod exigerait 
31
×
700
=
21700
>
21000
31×700=21700>21000 MB, donc impossible (calcul exécuté dans le laboratoire Python local, sortie : 21000, 30,0, 30, 21000, 0).

Résultat

𝑁
max
⁡
=
30
 pods
N
max
	​

=30 pods
	​


Hypothèses explicites

Le dimensionnement se fait sur les requests (c'est la requête qui est utilisée par le planificateur pour l'admission), pas sur les limites ; hypothèse conforme à l'énoncé qui ne fournit qu'une requête.
La « réserve » de 3000 MB est supposée couvrir l'ensemble des retenues non allouables (réservation système, réservation kubelet, seuil d'éviction), et n'est pas comptée deux fois.
Aucune autre charge ni aucun DaemonSet ne consomme de mémoire allouable sur ce nœud.
La contrainte de nombre maximal de pods par nœud (paramètre --max-pods, dont la valeur par défaut usuelle n'est pas fournie ici) est supposée non limitante ; je ne peux pas la vérifier avec les données de l'énoncé.
Ce cas est un partage exact (reste nul) : en pratique, prévoir une marge est prudent, car planifier 30 pods consomme 100 % de l'allouable et ne laisse aucun coussin en cas de dépassement réel au-delà des requêtes.