Meilleures pratiques concernant l' colocation

Meilleure pratique : utiliser l'autorisation RBAC pour un accès plus détaillé

Nous vous recommandons d'utiliser le donneur d'autorisation RBAC Kubernetes pour appliquer un contrôle d'accès détaillé aux utilisateurs sur des clusters spécifiques via les rôles et les rôles de cluster RBAC Kubernetes.

Un rôle RBAC Kubernetes est un ensemble de droits d'accès. Par exemple, un rôle peut inclure des droits d'accès permettant de lire et de répertorier des pods. Les rôles de cluster RBAC Kubernetes sont identiques aux rôles, à la différence près qu'ils peuvent être utilisés n'importe où dans le cluster. Une liaison de rôle RBAC Kubernetes met en correspondance un rôle avec un utilisateur ou un groupe, octroyant les droits d'accès de ce rôle à l'utilisateur ou au groupe pour les ressources de cet espace de noms. De même, une liaison de rôle de cluster RBAC Kubernetes met en correspondance un rôle de cluster avec un utilisateur ou un groupe, octroyant les droits d'accès de ce rôle de cluster à l'utilisateur ou au groupe sur l'ensemble du cluster.

Reportez-vous à A propos du contrôle d'accès et du moteur Kubernetes (OKE).

Meilleure pratique : Utiliser des espaces de noms si plusieurs clusters ne sont pas une option

Nous vous recommandons de créer des espaces de noms distincts pour chaque équipe si un cluster Kubernetes est volumineux (avec des centaines de noeuds) et que plusieurs équipes travaillent sur le cluster. Par exemple, vous allez généralement créer différents espaces de noms pour les équipes de développement, de test et de production.

Un cluster Kubernetes peut être organisé en espaces de noms afin de répartir les ressources du cluster entre plusieurs utilisateurs. A l'origine, un cluster possède les espaces de noms suivants :

• default, pour les ressources qui n'ont pas d'autre espace de noms
• kube-system, pour les ressources créées par le système Kubernetes
• kube-node-lease, pour un objet de location par noeud afin de déterminer la disponibilité du noeud
• kube-public, généralement utilisé pour les ressources qui doivent être accessibles dans le cluster

Les espaces de noms jouent un rôle important dans la sécurisation d'un cluster lorsque plusieurs utilisateurs et équipes travaillent sur le même cluster.

Reportez-vous à Espaces de noms dans la documentation Kubernetes.

Meilleure pratique : utiliser une convention de dénomination d'espace de noms pour faciliter le déploiement dans plusieurs environnements

Nous vous recommandons d'établir et d'utiliser une convention de dénomination d'espace de noms qui facilite la création de déploiements dans plusieurs environnements et hébergés dans différents clusters.

Par exemple, évitez d'inclure des noms d'environnement dans les noms d'espace de noms. Utilisez plutôt le même nom d'espace de noms dans tous les environnements. En utilisant le même nom d'espace de noms, vous pouvez utiliser les mêmes fichiers de configuration dans tous les environnements et vous évitez d'avoir à créer un fichier de configuration propre à chaque environnement.

Reportez-vous à Espaces de noms dans la documentation Kubernetes.

Meilleure pratique : Isoler les charges globales dans des pools de noeuds dédiés

Nous vous recommandons d'implémenter une isolation fiable de l'infrastructure en utilisant des pools de noeuds dédiés pour isoler les locataires. Par exemple, pour une application colocative exécutant chaque locataire sur une ressource de calcul dédiée, séparée par des pools de noeuds.

De nombreuses applications SaaS colocatives nécessitent que les locataires s'exécutent sur des ressources de calcul dédiées et qu'ils puissent contrôler le trafic réseau via des listes de sécurité par locataire. Les deux stratégies les plus courantes pour un tel modèle de location d'application SaaS sont les suivantes :

• Exploitez les espaces de noms et les stratégies réseau pour isoler les locataires.
• Tirez parti de listes de calcul/sécurité dédiées pour isoler les locataires.

Meilleure pratique : Appliquer des quotas de ressources

Nous vous recommandons de créer et d'appliquer des quotas de ressources Kubernetes pour vous assurer que tous les locataires partageant un cluster disposent d'un accès équitable aux ressources de cluster.

Créez un quota de ressources pour chaque espace de noms, en fonction du nombre de pods déployés par chaque locataire, ainsi que de la quantité de mémoire et d'UC requises par chaque pod.

Par exemple, la configuration ResourceQuota suivante :

• permet aux pods de l'espace de noms tenant-a de demander jusqu'à 16 UC et jusqu'à 64 Go de mémoire
• limite le nombre maximal de CPU à 32 et la mémoire maximale à 72 Go

apiVersion: v1
kind: ResourceQuota
metadata:
  name: tenant-a
spec:
  hard: "1"
    requests.cpu: "16"
    requests.memory: 64Gi
    limits.cpu: "32"
    limits.memory: 72Gi

Reportez-vous à Quotas de ressource dans la documentation Kubernetes.

Meilleure pratique : Redimensionnement automatique des noeuds de processus actifs et des pods

Nous vous recommandons d'activer le redimensionnement automatique pour répondre à la demande des locataires en redimensionnant automatiquement les pools de noeuds et les pods dans un cluster.

Le redimensionnement automatique garantit que le système reste réactif et en bon état, même lorsque différents locataires déploient des charges globales lourdes dans leurs propres espaces de noms. Le redimensionnement automatique aide également le système à réagir aux pannes.

Reportez-vous à Utilisation de l'outil de redimensionnement automatique de cluster Kubernetes, à Utilisation de l'outil de redimensionnement automatique de pod horizontal Kubernetes.

Meilleure pratique : Utiliser un équilibreur de charge flexible

Nous vous recommandons d'indiquer une forme flexible pour les équilibreurs de charge Oracle Cloud Infrastructure afin de répondre à la demande des locataires.

L'utilisation d'une forme flexible pour les équilibreurs de charge OCI fournie par Kubernetes Engine pour les services Kubernetes de type LoadBalancer vous permet d'effectuer les opérations suivantes :

• Evitez les restrictions associées aux formes d'équilibreur de charge à bande passante fixe, car vous pouvez spécifier des valeurs minimales et maximales afin de créer une plage de tailles supérieure et inférieure pour la forme de bande passante de l'équilibreur de charge.
• Evitez les limites associées à la mise à l'échelle basée uniquement sur des modèles de trafic généraux.

Reportez-vous à la section Specifying Flexible Load Balancer Shapes.

Meilleure pratique : centraliser le contrôle réseau (facultatif)

Nous vous recommandons de maintenir un contrôle centralisé sur les ressources réseau à l'aide d'une passerelle de routage dynamique (DRG) et (éventuellement) d'un VCN hub.

L'utilisation d'un DRG vous permet d'acheminer le trafic via une appliance virtuelle réseau centralisée.

La création facultative d'un VCN hub vous permet de configurer le routage principal et les pare-feu. Les ressources d'un VCN hub peuvent communiquer avec d'autres réseaux cloud virtuels de manière sécurisée et efficace à l'aide d'adresses IP internes. L'utilisation d'un hub VCN et IAM garantit que seuls les administrateurs réseau ont accès au VCN centralisé. Cette séparation vous aide à mettre en œuvre le principe du moindre privilège.

Par exemple :

• L'équipe réseau centralisée peut administrer le réseau sans disposer de droits d'accès aux clusters Kubernetes (résidant dans des réseaux cloud virtuels spoke).
• Les administrateurs du moteur Kubernetes peuvent gérer des clusters sans avoir le droit de manipuler le réseau partagé.

Reportez-vous à Routage du trafic via une appliance virtuelle de réseau central.