Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Mode préfixe pour Windows

Dans Amazon EKS, chaque pod qui s'exécute sur un hôte Windows se voit attribuer une adresse IP secondaire par défaut par le contrôleur de ressources VPC. Cette adresse IP est une VPC-routable adresse attribuée depuis le sous-réseau de l'hôte. Sous Linux, chaque ENI attachée à l'instance possède plusieurs emplacements qui peuvent être renseignés par une adresse IP secondaire ou un CIDR /28 (un préfixe). Les hôtes Windows ne prennent toutefois en charge qu'un seul ENI et ses emplacements disponibles. L'utilisation d'adresses IP secondaires peut limiter artificiellement le nombre de pods que vous pouvez exécuter sur un hôte Windows, même lorsque de nombreuses adresses IP peuvent être attribuées.

Afin d'augmenter la densité des pods sur les hôtes Windows, en particulier lorsque vous utilisez des types d'instances plus petits, vous pouvez activer la délégation de préfixes pour les nœuds Windows. Lorsque la délégation de préfixes est activée, les préfixes IPv4 /28 sont attribués aux emplacements ENI plutôt qu'aux adresses IP secondaires. La délégation de préfixes peut être activée en ajoutant l'enable-windows-prefix-delegation: "true"entrée à la carte de amazon-vpc-cni configuration. Il s'agit de la même carte de configuration où vous devez définir enable-windows-ipam: "true" l'entrée pour activer le support Windows.

Suivez les instructions mentionnées dans le guide de l'utilisateur d'EKS pour activer le mode de délégation de préfixes pour les nœuds Windows.

Figure : Comparaison entre le mode IP secondaire et le mode de délégation de préfixe

Le nombre maximum d'adresses IP que vous pouvez attribuer à une interface réseau dépend du type d'instance et de sa taille. Chaque préfixe attribué à une interface réseau consomme un emplacement disponible. Par exemple, une c5.large instance possède une limite d'10emplacements par interface réseau. Le premier emplacement d'une interface réseau est toujours utilisé par l'adresse IP principale de l'interface, ce qui vous laisse 9 emplacements pour les préfixes des adresses IP and/or secondaires. Si des préfixes sont attribués à ces emplacements, le nœud peut prendre en charge (9 * 16) 144 adresses IP, tandis que s'il reçoit des adresses IP secondaires, il ne peut prendre en charge que 9 adresses IP. Consultez la documentation sur les adresses IP par interface réseau et par type d'instance et sur l'attribution de préfixes aux interfaces réseau pour plus d'informations.

Lors de l'initialisation du nœud de travail, le contrôleur de ressources VPC attribue un ou plusieurs préfixes à l'ENI principal pour accélérer le démarrage du pod en maintenant un pool chaud d'adresses IP. Le nombre de préfixes à conserver dans le pool chaud peut être contrôlé en définissant les paramètres de configuration suivants dans la carte de amazon-vpc-cni configuration.

Au fur et à mesure que de nouveaux Pods sont prévus sur le nœud, des préfixes supplémentaires seront demandés pour l'ENI existant. Lorsqu'un pod est planifié sur le nœud, le contrôleur de ressources VPC essaie d'abord d'attribuer une adresse IPv4 à partir des préfixes existants sur le nœud. Si cela n'est pas possible, un nouveau préfixe IPv4 sera demandé tant que le sous-réseau dispose de la capacité requise.

Figure : Workflow lors de l'attribution d'une adresse IPv4 au Pod

Recommandations

Utilisez la délégation de préfixes lorsque

Utilisez la délégation de préfixes si vous rencontrez des problèmes de densité de pods sur les nœuds de travail. Pour éviter les erreurs, nous vous recommandons d'examiner les sous-réseaux pour détecter un bloc d'adresses contigu pour le préfixe /28 avant de passer en mode préfixe. Consultez la section «  Utiliser les réservations de sous-réseaux pour éviter la fragmentation des sous-réseaux (IPv4)  » pour plus de détails sur les réservations de sous-réseaux.

Par défaut, le paramètre max-pods sur les nœuds Windows est défini sur110. Pour la grande majorité des types d'instances, cela devrait être suffisant. Si vous souhaitez augmenter ou diminuer cette limite, ajoutez ce qui suit à la commande bootstrap dans vos données utilisateur :

-KubeletExtraArgs '--max-pods=example-value'

Pour plus de détails sur les paramètres de configuration du bootstrap pour les nœuds Windows, consultez la documentation ici.

Évitez la délégation de préfixes lorsque

Si votre sous-réseau est très fragmenté et que les adresses IP disponibles sont insuffisantes pour créer des préfixes /28, évitez d'utiliser le mode préfixe. La pièce jointe du préfixe peut échouer si le sous-réseau à partir duquel le préfixe est produit est fragmenté (sous-réseau très utilisé avec des adresses IP secondaires dispersées). Ce problème peut être évité en créant un nouveau sous-réseau et en réservant un préfixe.

Configurer les paramètres de délégation de préfixes afin de conserver les adresses IPv4

warm-prefix-targetwarm-ip-target, et minimum-ip-target peut être utilisé pour affiner le comportement de la pré-mise à l'échelle et de la mise à l'échelle dynamique à l'aide de préfixes. Par défaut, les valeurs suivantes sont utilisées :

warm-ip-target: "1"
minimum-ip-target: "3"

En ajustant ces paramètres de configuration, vous pouvez atteindre un équilibre optimal entre la conservation des adresses IP et la réduction de la latence du Pod due à l'attribution d'une adresse IP. Pour plus d'informations sur ces paramètres de configuration, consultez la documentation ici.

Utiliser les réservations de sous-réseaux pour éviter la fragmentation des sous-réseaux (IPv4)

Lorsqu'EC2 attribue un préfixe IPv4 /28 à un ENI, il doit s'agir d'un bloc contigu d'adresses IP provenant de votre sous-réseau. Si le sous-réseau à partir duquel le préfixe est généré est fragmenté (sous-réseau très utilisé avec des adresses IP secondaires dispersées), la pièce jointe du préfixe peut échouer et l'événement de nœud suivant s'affichera :

InsufficientCidrBlocks: The specified subnet does not have enough free cidr blocks to satisfy the request

Pour éviter la fragmentation et disposer d'un espace contigu suffisant pour créer des préfixes, utilisez les réservations d'adresse CIDR du sous-réseau VPC pour réserver de l'espace IP au sein d'un sous-réseau à l'usage exclusif des préfixes. Une fois que vous avez créé une réservation, les adresses IP des blocs réservés ne seront pas attribuées à d'autres ressources. De cette façon, VPC Resource Controller pourra obtenir les préfixes disponibles lors de l'appel d'affectation au nœud ENI.

Il est recommandé de créer un nouveau sous-réseau, de réserver de l'espace pour les préfixes et d'activer l'attribution de préfixes pour les nœuds de travail exécutés dans ce sous-réseau. Si le nouveau sous-réseau est dédié uniquement aux pods exécutés dans votre cluster EKS avec la délégation de préfixe activée, vous pouvez ignorer l'étape de réservation du préfixe.

Remplacez tous les nœuds lors de la migration du mode IP secondaire vers le mode Délégation de préfixes ou vice versa

Il est vivement recommandé de créer de nouveaux groupes de nœuds pour augmenter le nombre d'adresses IP disponibles plutôt que de remplacer progressivement les nœuds de travail existants.

Lors de l'utilisation de groupes de nœuds autogérés, les étapes de transition seraient les suivantes :

Lors de l'utilisation de groupes de nœuds gérés, les étapes de transition seraient les suivantes :

Pour Windows, nous vous recommandons d'éviter d'exécuter les Pods à la fois en mode IP secondaire et en mode délégation de préfixe. Une telle situation peut survenir lorsque vous passez du mode IP secondaire au mode de délégation de préfixe ou vice versa avec des charges de travail Windows en cours d'exécution.

Bien que cela n'ait aucun impact sur vos Pods en cours d'exécution, il peut y avoir des incohérences en ce qui concerne la capacité d'adresse IP du nœud. Par exemple, considérez un nœud t3.xlarge qui possède 14 emplacements pour les adresses IPv4 secondaires. Si vous utilisez 10 pods, 10 emplacements de l'ENI seront utilisés par des adresses IP secondaires. Après avoir activé la délégation de préfixe, la capacité annoncée au serveur kube-api serait de (14 emplacements * 16 adresses IP par préfixe) 244 mais la capacité réelle à ce moment-là serait de (4 emplacements restants * 16 adresses par préfixe) 64. Cette incohérence entre la quantité de capacité annoncée et la quantité de capacité réelle (emplacements restants) peut entraîner des problèmes si vous utilisez plus de Pods qu'il n'y a d'adresses IP disponibles pour l'attribution.

Cela dit, vous pouvez utiliser la stratégie de migration décrite ci-dessus pour faire passer en toute sécurité vos Pods d'une adresse IP secondaire à des adresses obtenues à partir de préfixes. Lorsque vous passez d'un mode à l'autre, les Pods continueront de fonctionner normalement et :

Problèmes de débogage liés à la délégation de préfixes

Vous pouvez utiliser notre guide de débogage ici pour approfondir le problème que vous rencontrez avec la délégation de préfixes sous Windows.