Limitations et quotas des services

Passez en revue les limitations et les quotas du service qui s'appliquent aux clusters, et découvrez quelles limites peuvent être ajustées si nécessaire.

Si vous prévoyez d'atteindre l'une des limitations suivantes pour IBM Cloud Kubernetes Service, contactez le support IBM et fournissez l'ID de cluster, la nouvelle limite de quota, la région et le fournisseur d'infrastructure dans votre ticket de demande de service.

Limitations et quotas de service

IBM Cloud Kubernetes Service est fourni avec les limitations et quotas de service ci-après qui s'appliquent à tous les clusters, quel que soit le fournisseur d'infrastructure que vous prévoyez d'utiliser. N'oubliez pas que les limitations propres aux clusters classiques et VPC s'appliquent également.

Pour afficher les limites de quota appliquées aux ressources liées aux clusters dans votre compte IBM Cloud, utilisez la commande ibmcloud ks quota ls.

Limitations deIBM Cloud Kubernetes Service
Catégorie Description
Limites de débit d'API 200 demandes par 10 secondes vers l'API IBM Cloud Kubernetes Service à partir de chaque adresse IP source unique.
Déploiement d"application Les applications que vous déployez et les services que vous intégrez dans votre cluster doivent être en mesure de s'exécuter sur le système d'exploitation des noeuds worker.
Plug-in réseau Calico La modification du plug-in, des composants ou des paramètres Calico par défaut n'est pas prise en charge. Par exemple, ne déployez pas de nouvelle version de plug-in Calico ou modifiez les ensembles de démons ou les déploiements pour les composants Calico, les ressources IPPool par défaut ou les nœuds Calico. A la place, vous pouvez suivre la documentation pour créer une règle Calico NetworkPolicy ou GlobalNetworkPolicy, pour modifier la MTU Calico ou pour désactiver le plug-in de mappage de port pour l'interface CNI Calico.
Quota de cluster Vous ne pouvez pas dépasser 100 clusters par région et par fournisseur d'infrastructure. Toutefois, à partir du 1er janvier 2024, les quotas sont augmentés progressivement avant d'atteindre 100. Si vous avez besoin de plus de ressources, contactez le support IBM. Dans la demande d'assistance, indiquez la nouvelle limite de quota pour la région et le fournisseur d'infrastructure de votre choix. Pour répertorier les quotas, exécutez ibmcloud quota ls.
Kubernetes Veillez à prendre connaissance des limitations du projet Kubernetes.
Fournisseur KMS La personnalisation des adresses IP autorisées à se connecter à votre instance IBM® Key Protect for IBM Cloud® n'est pas prise en charge.
Journaux de pod Kubernetes Pour vérifier les pods d'applications individuelles, vous pouvez utiliser la ligne de commande pour exécuter kubectl logs <pod name>. N'utilisez pas le tableau de bord Kubernetes pour diffuser les journaux de vos pods, car cela pourrait entraîner une interruption de l'accès au tableau de bord de Kubernetes.
Équilibreurs de charge Bien que le protocole SCTP Kubernetes soit généralement disponible dans l'édition de la communauté Kubernetes, la création d'équilibreurs de charge qui utilisent ce protocole n'est pas prise en charge dans les clusters IBM Cloud Kubernetes Service.
Système d'exploitation Les noeuds worker doivent exécuter l'un des systèmes d'exploitation pris en charge. Vous ne pouvez pas créer de cluster avec des noeuds worker qui exécutent différents types de systèmes d'exploitation. Pour plus d'informations, voir les informations de version deKubernetes.
Instances de pod Vous pouvez exécuter 110 pods par noeud worker. Si vous avez des noeuds worker dotés d'au moins 11 coeurs d'UC, vous pouvez prendre en charge 10 pods par coeur, dans la limite de 250 pods par noeud worker. Le nombre de pods inclut des pods kube-system et ibm-system qui s'exécutent sur le noeud worker. Pour améliorer les performances, pensez à limiter le nombre de pods que vous exécutez par coeur de traitement de sorte que vous ne sur-utilisiez pas le nœud worker. Par exemple, sur un noeud worker avec une version b3c.4x16, vous pouvez exécuter 10 pods par coeur qui n'utilisent pas plus de 75 % de la capacité totale du noeud worker.
Quota de noeud worker Un maximum de 500 nœuds de travail pour tous les comptes créés avant le 1er janvier 2024. Pour les comptes créés à partir de cette date, le quota maximum est de 200 après une période de baisse des quotas. Les quotas s'appliquent par fournisseur d'infrastructure de cluster. Si vous avez besoin de plus de ressources, contactez le support IBM. Dans la demande d'assistance, indiquez la nouvelle limite de quota pour la région et le fournisseur d'infrastructure de votre choix. Pour afficher la liste des quotas, exécutez la commande ibmcloud ks quota ls.
Taille de pool de noeuds worker Votre cluster doit toujours comporter au moins 1 nœud. En raison du quota de noeud worker, vous êtes limité quant au nombre de pools de noeuds worker par cluster et quant au nombre de noeuds worker par pool de noeuds worker. Par exemple, avec le quota de noeuds worker par défaut fixé à 500 par région, vous pouvez disposer d'un maximum de 500 pools de noeuds worker comportant chacun 1 noeud worker dans une région avec un seul cluster. Ou, vous pouvez disposer d'un pool de noeuds worker comportant un maximum de 500 noeuds worker dans une région avec un seul cluster.
Red Hat Enterprise Linux CoreOS Le nombre maximum de zones ajoutées à un cluster est de 12. Par exemple, 3 pools de travailleurs RHCOS avec 3 zones chacun représenteront 9/12 du quota pour ce cluster.
Nombre de noeuds worker Les grappes peuvent avoir un maximum de 500 nœuds de travail.
Désignation de cluster Pour que le sous-domaine Ingress et le certificat soient correctement enregistrés, les 24 premiers caractères du nom des clusters doivent être différents. Si vous créez et supprimez des clusters portant le même nom ou des noms ayant les mêmes 24 premiers caractères 5 fois ou plus en l'espace de 7 jours, par exemple à des fins d'automatisation ou de test, vous risquez d'atteindre la limite de taux Let's Encrypt Duplicate Certificate.
Groupes de ressources Un cluster peut être créé dans un seul groupe de ressources que vous ne pouvez plus modifier par la suite. Si vous créez un cluster dans le mauvais groupe de ressources, vous devez supprimer le cluster et le créer à nouveau dans le groupe de ressources approprié. En outre, si vous devez utiliser la commande ibmcloud ks cluster service bind pour intégrer un service IBM Cloud, ce dernier doit se trouver dans le même groupe de ressources que le cluster. Les services qui n'utilisent pas de groupes de ressources, comme IBM Cloud Container Registry, ou qui ne nécessitent pas de liaison de service, comme IBM Cloud Logs, fonctionnent même si le cluster se trouve dans un groupe de ressources différent.

Limitations associées aux clusters classique

Les clusters d'infrastructure classique dans IBM Cloud Kubernetes Service sont commercialisés avec les limitations suivantes :

Calcul

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de calcul liées aux clusters classiques
Catégorie Description
Instances réservées La capacité réservée et les instances réservées ne sont pas prises en charge.
Versions de noeud worker Les nœuds de travail sont disponibles dans certaines variantes de ressources de calcul.
Accès à l'hôte de noeud worker Pour la sécurité, vous ne pouvez pas utiliser SSH dans l'hôte de traitement du noeud worker.

Mise en réseau

N'oubliez pas que les limitations de service s'appliquent également.

Limitations liées à la mise en réseau des clusters classiques
Catégorie Description
ALB Ingress
Module complémentaire géré Istio Voir Limitations pour le module complémentaire Istio.
Equilibreurs de charge de réseau (NLB)
  • Vous ne pouvez pas mettre à jour un NLB existant de la version 1.0 à la version 2.0. Vous devez créer un NLB 2.0.
  • Vous ne pouvez pas créer de sous-domaines pour les NLB privés.
  • Vous pouvez enregistrer jusqu'à 128 sous-domaines. Cette limite peut être levée sur demande en ouvrant un cas de support.
Sous-réseaux par VLAN Chaque réseau local virtuel (VLAN) est limité à 40 sous-réseaux.

Stockage

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de stockage des clusters classiques
Catégorie Description
Instances de volume Vous pouvez avoir un total de 250 volumes de stockage par blocs et de fichier d'infrastructure IBM Cloud par compte. Si vous montez plus que cette quantité, un message out of capacity peut s'afficher lors de la création de volumes persistants. Pour plus de FAQ, voir la documentation sur le stockage de fichiers et de blocs. Si vous souhaitez monter plus de volumes, contactez le IBM. Dans votre ticket de demande de service, incluez votre ID de compte et le nouveau quota de volume de stockage de fichiers ou de stockage par blocs que vous souhaitez.
Portworx Passez en revue les limitations Portworx.

Accès des utilisateurs classiques

N'oubliez pas que les limitations de service s'appliquent également.

Limitations classiques de l'accès des utilisateurs aux clusters
Catégorie Description
Accès aux adresses IP IBM Cloud Kubernetes Service ne prend pas en charge la restriction de l'accès à des utilisateurs spécifiques en activant l'accès par adresse IP. Si vous souhaitez restreindre l'accès des utilisateurs ou limiter les services et les VPC auxquels un utilisateur peut accéder, envisagez une restriction basée sur le contexte.

Limitations de cluster de VPC

Les clusters VPC dans IBM Cloud Kubernetes Service sont libérés avec les limitations suivantes. En outre, l'ensemble des quotas de VPC, limites de VPC, limitations de service VPC et limitations de service standard s'applique.

Calcul

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de calcul liées aux clusters de VPC
Catégorie Description
Clusters par VPC Les VPC sont limités à 25 clusters chacun.
Chiffrement Par défaut, les disques secondaires de vos noeuds worker sont chiffrés au repos par le fournisseur d'infrastructure VPC sous-jacent. Cependant, vous ne pouvez pas apporter votre propre chiffrement aux instances de serveur virtuel sous-jacentes.
Emplacement Les clusters VPC ne sont disponibles que dans certaines régions multizones.
Virtual Private Cloud Voir Limitations et Quotas.
Quotas de ressources VPC VPC gère des quotas pour la mémoire vCPU,, le GPU, le stockage d'instance et les ressources de stockage d'instance optimisées par compte. Lorsque vous provisionnez des nœuds de travail d'instance de serveur virtuel (VSI) sur une infrastructure publique, ces ressources sont comptabilisées dans les quotas de votre compte VPC. Si vous atteignez une limite de quota, le provisionnement des nœuds de travailleur échoue. Pour afficher vos quotas actuels et leur utilisation, voir Affichage des métriques de ressources VPC. Pour demander une augmentation de quota, ouvrez un dossier d'assistance auprès du VPC. Pour plus d'informations, consultez la section « Quotas VPC ».

Remarque: cette gestion des quotas ne s'applique actuellement qu'aux nœuds de travail VSI hébergés sur une infrastructure publique. Le service « IBM Cloud Kubernetes Service » continue de gérer les quotas pour les nœuds de travail hébergés sur des serveurs dédiés et les nœuds de travail « bare metal ».
Versions de noeud worker Seules certaines versions sont disponibles pour les machines virtuelles des nœuds de travail et les nœuds de travail « bare metal ».
Accès à l'hôte de noeud worker Pour la sécurité, vous ne pouvez pas utiliser SSH dans l'hôte de traitement du noeud worker.
Mises à jour de noeud worker Les actions de mise à jour des workers VPC dépendent du type de worker. Pour les machines « bare metal » VPC, vous pouvez utiliser la commande « ibmcloud ks worker reload » pour effectuer un rechargement. Pour les instances de serveur virtuel VPC, utilisez la commande « ibmcloud ks worker replace ». Si vous remplacez plusieurs noeuds worker en même temps, ils sont supprimés et remplacés simultanément, et non un par un. Vérifiez que vous disposez de suffisamment de capacité dans votre cluster pour replanifier vos charges de travail avant de remplacer des noeuds worker.

Mise en réseau

N'oubliez pas que les limitations de service s'appliquent également.

Limitations liées à la mise en réseau des clusters de VPC
Catégorie Description
Longueur d'URL d'application La résolution DNS est gérée par le noeud final privé virtuel (VPE), qui peut résoudre les URL jusqu'à 130 caractères. Si vous exposez des applications dans votre cluster avec des URL, telles que le sous-domaine Ingress, vérifiez que ces URL ne comportent pas plus de 130 caractères.
Module complémentaire géré Istio Voir Limitations pour le module complémentaire Istio.
Vitesses réseau Les vitesses réseau de profil VPC font référence aux vitesses des interfaces de noeud worker. La bande passante disponible pour les instances VPC est partagée entre le stockage et le trafic réseau. Par défaut, l'allocation de stockage est de 25% de la bande passante maximale. La vitesse du réseau, telle qu'indiquée dans les tableaux ci-dessous, correspond à la bande passante disponible pour un travailleur disposant d'une seule interface réseau, après déduction de l'allocation par défaut de 25 % de la bande passante de stockage.
NodePort Vous pouvez accéder à une application via un port de noeud (NodePort) uniquement si vous êtes connecté à votre réseau VPC privé, par exemple, via une connexion VPN. Pour accéder à une application via Internet, vous devez utiliser à la place un équilibreur de charge VPC ou un service Ingress.
Réseau de pods Les listes de contrôle d'accès VPC filtrent le trafic entrant et sortant pour votre cluster au niveau du sous-réseau et les groupes de sécurité filtrent le trafic entrant et sortant pour votre cluster au niveau des noeuds worker. Pour contrôler le trafic dans le cluster au niveau pod à pod, vous ne pouvez pas utiliser les groupes de sécurité VPC ou les listes de contrôle d'accès. A la place, utilisez des règles réseau Kubernetes et Calico, qui peuvent contrôler le trafic réseau de niveau pod qui utilise l'encapsulation IP-in-IP.
Sous-réseaux
  • Consultez les restrictions relatives à la mise en réseau VPC.
  • Ne supprimez pas les sous-réseaux que vous associez à votre cluster lors de la création de celui-ci ou lorsque vous ajoutez des nœuds de travail dans une zone. Si vous supprimez un sous-réseau VPC que votre cluster a utilisé, des problèmes peuvent se produire au niveau des équilibreurs de charge qui utilisent des adresses IP à partir du sous-réseau et il se peut que vous ne puissiez pas créer de nouveaux équilibreurs de charge.
Équilibreur de charge de VPC Voir les limitations d'équilibreur de charge VPC.

Stockage

N'oubliez pas que les limitations de service s'appliquent également.

Limitations de stockage des clusters de VPC
Catégorie Description
Module complémentaire de cluster Block Storage for VPC Le module complémentaire de cluster Block Storage for VPC est activé par défaut sur les clusters de VPC. Toutefois, le module complémentaire n'est actuellement pas pris en charge pour les clusters avec des noeuds worker UBUNTU_18_S390X. Lorsque vous créez un cluster de VPC avec des noeuds worker UBUNTU_18_S390X, les pods de module complémentaire restent à l'état Pending. Vous pouvez désactiver le module complémentaire en exécutant la commande ibmcloud ks cluster addon disable.
Classe de stockage pour les tailles de profil Pour plus d'informations, voir Profils de volume disponibles.
Types pris en charge

Vous pouvez configurer Block Storage for VPC, IBM Cloud Object Storage et Cloud Databases uniquement.
Connexions de volume Voir Limites de connexion de volume.
Portworx Passez en revue les limitations Portworx.
Block Storage for VPC La classe de stockage par défaut dans les clusters VPC ne peut pas être modifiée. Toutefois, vous pouvez créer votre propre classe de stockage.

Accès des utilisateurs VPC

N'oubliez pas que les limitations de service s'appliquent également.

Limitations d'accès des utilisateurs du cluster VPC
Catégorie Description
Accès aux adresses IP IBM Cloud Kubernetes Service ne prend pas en charge la restriction de l'accès à des utilisateurs spécifiques en activant l'accès par adresse IP. Si vous souhaitez restreindre l'accès des utilisateurs ou limiter les services et les VPC auxquels un utilisateur peut accéder, envisagez une restriction basée sur le contexte.