Meilleures pratiques concernant les réseaux

Meilleure pratique : Créer des compartiments distincts pour chaque équipe

Nous vous recommandons de créer un compartiment distinct pour chaque équipe si plusieurs équipes sont censées créer des clusters.

Par exemple, les ressources réseau telles que le réseau cloud virtuel (VCN) et les sous-réseaux utilisés pour Kubernetes Engine peuvent tous résider dans le compartiment racine. Toutefois, si plusieurs équipes doivent créer des clusters, nous vous recommandons de créer un compartiment distinct pour les ressources de cluster de chaque équipe (par exemple, en tant que compartiments enfant du compartiment racine). La raison en est que, comme un cluster et ses ressources ne doivent pas nécessairement se trouver dans le même compartiment que le VCN et les sous-réseaux, le fait d'avoir des compartiments distincts pour chaque équipe facilite et rend plus propre la séparation des clusters et leur sécurisation.

Reportez-vous à Configuration de ressources réseau pour la création et le déploiement de clusters.

Meilleure pratique : dimensionnez votre VCN de manière appropriée

Nous vous recommandons d'autoriser d'éventuelles exigences futures de redimensionnement de cluster et de pool de noeuds lors du dimensionnement du VCN dans lequel vous souhaitez créer et déployer des clusters Kubernetes.

Le VCN doit comporter un bloc CIDR suffisamment grand pour allouer des adresses réseau à toutes les ressources requises par un cluster (sous-réseaux, adresse d'API Kubernetes, noeuds de processus actif, pods, équilibreurs de charge).

Reportez-vous à VCN Configuration et à IPv4 CIDR Blocks and Kubernetes Engine (OKE).

Meilleure pratique : Sélectionnez le plugin CNI de réseau de pod qui correspond le mieux à vos besoins

Nous vous recommandons d'examiner attentivement les exigences de mise en réseau de pod, puis de sélectionner le plugin CNI de mise en réseau de pod qui correspond le mieux à vos besoins.

Par exemple :

• Si les applications nécessitent l'utilisation d'exigences de mise en réseau de base (et non l'utilisation d'adresses IP du VCN) ou nécessitent une densité élevée de pods par noeud de processus actif, nous vous recommandons d'utiliser le plug-in Flannel CNI.
• Si les applications nécessitent que les pods aient une adresse IP du CIDR VCN et/ou nécessitent les performances réseau cohérentes offertes par les machines virtuelles (quel que soit le noeud sur lequel les pods sont exécutés) sans superposition supplémentaire, nous vous recommandons d'utiliser le module d'extension CNI OCI VCN-Native Pod Networking.

Reportez-vous à Mise en réseau de pod et à Blocs IPv4 CIDR et moteur Kubernetes (OKE).

Meilleure pratique : configurer externalTrafficPolicy de manière appropriée lors de l'exposition des applications

Nous vous recommandons d'examiner attentivement la valeur la plus appropriée pour le paramètre externalTrafficPolicy lors du provisionnement d'un équilibreur de charge réseau pour un service Kubernetes de type LoadBalancer :

• externalTrafficPolicy: Cluster (mode cluster)

  Indiquez le mode cluster si vous souhaitez toujours acheminer le trafic vers tous les pods exécutant un service de distribution égale et que vous ne souhaitez pas conserver les adresses IP client. En mode cluster, Kubernetes transmet tout trafic envoyé à un noeud de processus actif sur un port particulier à l'un des pods de ce service.

  Le mode cluster entraîne souvent moins d'attrition des back-ends dans le cluster car le routage des demandes ne dépend pas de l'état des pods dans le cluster. Toute demande peut être envoyée à n'importe quel noeud et Kubernetes gère l'acheminement de la demande au bon endroit. Le mode cluster permet de répartir correctement la charge entre les noeuds de processus actif à partir de l'équilibreur de charge réseau. Lorsque le trafic atteint un noeud de processus actif, il le gère de la même manière. L'équilibreur de charge ne sait pas quels noeuds du cluster exécutent des pods pour son service. Si vous avez sélectionné un sous-réseau régional pour les noeuds de processus actif, la charge est répartie sur tous les noeuds de tous les domaines de disponibilité de la région du sous-réseau. En mode cluster, la charge du trafic est équilibrée sur tous les noeuds du cluster, même les noeuds qui n'exécutent pas de pod pertinent.

• externalTrafficPolicy: Local (mode local)

  Spécifiez le mode local si vous souhaitez que les demandes soient interrompues aux adresses IP client spécifiées dans les en-têtes de paquets IP. Vous avez uniquement la possibilité de conserver les adresses IP client lorsque les demandes sont interrompues sur les adresses IP client spécifiées dans les en-têtes de paquets IP. Autrement dit, lorsque le paramètre externalTrafficPolicy est défini sur Local.

  Le mode local supprime le saut réseau supplémentaire requis en mode cluster, mais le trafic réseau peut potentiellement devenir déséquilibré si le réseau n'est pas configuré correctement. En mode local, le trafic entrant doit être envoyé aux noeuds qui exécutent les pods correspondants pour ce service. Sinon, le trafic est supprimé. Par conséquent, certains pods d'application peuvent recevoir plus de trafic que d'autres pods.

Pour plus d'informations, reportez-vous aux sections Terminating Requests at the Receiving Node et Preserving The Client IP Address.

Meilleure pratique : Eviter le chevauchement de blocs CIDR de pod et de service avec un bloc CIDR sur site et lors de l'utilisation du module d'extension CNI flannel

Nous vous recommandons d'éviter le cas où le bloc CIDR utilisé par le réseau de superposition de flanelle pour provisionner des pods et des services avec des adresses IP chevauche un bloc CIDR utilisé pour provisionner des instances de calcul externes avec des adresses IP.

Les clusters Kubernetes requièrent une adresse IP unique pour chaque pod. Par conséquent, la planification des adresses IP est nécessaire car les adresses ne peuvent pas chevaucher l'espace d'adresses IP privées utilisé sur site ou dans d'autres réseaux cloud virtuels connectés.

Lors de l'utilisation du plug-in CNI de flanelle, la communication entre les pods d'un cluster est encapsulée dans le réseau de superposition de flanelle. Le réseau superposé flannel utilise son propre bloc CIDR pour provisionner les pods et les noeuds de processus actif avec des adresses IP. Les pods du réseau superposé flannel ne sont accessibles qu'à partir d'autres pods du même cluster. Les instances de calcul externes en dehors du cluster ne peuvent pas accéder directement aux pods. Si un pod tente d'accéder à une instance de calcul externe qui a la même adresse IP qu'un autre pod du cluster, la demande est acheminée de manière incorrecte et des problèmes surviennent.

Reportez-vous à Utilisation du module d'extension CNI flannel pour les fonctions de réseau de pod.

Meilleure pratique : utiliser des sous-réseaux régionaux et distribuer des charges de travail pour une haute disponibilité

Nous vous recommandons de sélectionner des sous-réseaux régionaux pour les noeuds de processus actif afin d'assurer une haute disponibilité et de répartir les charges de travail entre eux.

Le VCN doit comporter un nombre approprié de sous-réseaux définis pour les noeuds de processus actif, les équilibreurs de charge et l'adresse d'API Kubernetes. L'utilisation de sous-réseaux régionaux et la répartition des charges de travail entre eux assurent une haute disponibilité et simplifient l'implémentation du basculement entre les domaines de disponibilité.

Reportez-vous à Configuration des services.

Meilleure pratique : utiliser des contraintes de répartition de topologie pour contrôler la distribution des pods

Nous vous recommandons d'utiliser des contraintes de répartition de topologie de pod pour contrôler la façon dont les pods sont répartis entre les domaines de disponibilité et les noeuds de processus actif.

Par exemple, lorsque de nombreux noeuds de processus actif sont disponibles mais que seuls deux ou trois pods sont requis, vous ne voulez généralement pas que tous les pods s'exécutent sur le même noeud de processus actif afin d'éviter le risque d'un point d'échec unique en cas de problème.

Cependant, comme de plus en plus de pods sont requis pour les clients de plusieurs domaines de disponibilité, vous souhaitez généralement les répartir uniformément sur plusieurs noeuds de processus actif dans ces différents domaines de disponibilité. Dans ce scénario, la distribution des pods pour réduire la latence et les coûts réseau associés à l'envoi du trafic réseau entre les domaines de disponibilité est tout aussi préoccupante que d'éviter un point de panne unique. Vous préférerez peut-être disposer d'un nombre similaire de pods dans chaque domaine de disponibilité et faire en sorte que le cluster se corrige automatiquement en cas de problème.

L'utilisation de contraintes de répartition de topologie de pod vous permet de configurer un cluster pour atteindre les deux objectifs de haute disponibilité et d'utilisation efficace des ressources.

Reportez-vous à Contraintes de répartition de topologie de pod dans la documentation Kubernetes.

Meilleure pratique : Planifier le nombre de noeuds

Nous vous recommandons de mettre en place un plan pour le nombre de noeuds d'un cluster qui tienne compte de la taille des noeuds, du profil d'application des pods et du module d'extension CNI de mise en réseau de pod sélectionné.

Lors de l'utilisation du module d'extension CNI flannel, les clusters créés par Kubernetes Engine réservent une plage /25 pour les pods à partir du réseau superposé flannel et autorisent jusqu'à 110 pods par noeud. Lors de l'utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN, le même noeud peut avoir une plage différente en fonction de la forme sélectionnée pour les noeuds de processus actif. En fonction de la taille des noeuds et du profil d'application des pods, déterminez à l'avance le nombre de noeuds souhaités dans le cluster.

Reportez-vous à la section Pod Networking.

Meilleure pratique : Utiliser des sous-réseaux et des règles de sécurité distincts

Nous vous recommandons d'utiliser des sous-réseaux et des règles de sécurité distincts lors de la configuration des ressources réseau.

Le VCN dans lequel vous souhaitez créer et déployer des clusters doit comporter au moins deux sous-réseaux différents (facultatif, plus) :

• Un sous-réseau d'adresse d'API Kubernetes
• Un sous-réseau de noeuds de processus actif
• un ou deux sous-réseaux d'équilibreur de charge régionaux propres à un domaine de disponibilité (facultatif)
• un sous-réseau de pods (lors de l'utilisation du module d'extension CNI OCI VCN-Native Pod Networking)
• un sous-réseau de bastion (facultatif)

Vous pouvez choisir de combiner les sous-réseaux ainsi que les règles de sécurité. Toutefois, cette approche rend la sécurité plus difficile à gérer et n'est donc pas recommandée, sauf si vous utilisez des groupes de sécurité réseau pour contrôler l'accès aux clusters.

Reportez-vous à Configuration des services.

Meilleure pratique : Utiliser des sous-réseaux distincts pour les équilibreurs de charge

Nous vous recommandons de créer des sous-réseaux distincts pour les équilibreurs de charge afin d'exposer les services.

Si vous ne créez pas de sous-réseau d'équilibreur de charge distinct, les services sont affichés à l'aide d'une adresse IP du sous-réseau de noeud de processus actif. Par conséquent, l'espace alloué dans le sous-réseau de noeuds de processus actif peut être complètement utilisé avant ce que vous prévoyiez, ce qui peut empêcher le cluster de passer au nombre de noeuds indiqué.

Les sous-réseaux d'équilibreurs de charge peuvent être publics ou privés, selon la façon dont les applications déployées sur le cluster sont accessibles. Si les applications sont accessibles en interne à partir de votre réseau cloud virtuel, optez pour des sous-réseaux d'équilibreurs de charge privés. Si les applications sont accessibles à partir d'Internet, optez pour des sous-réseaux d'équilibreurs de charge publics.

Reportez-vous à Configuration du sous-réseau de l'équilibreur de charge.

Meilleure pratique : utiliser un sous-réseau de noeuds de processus actif privé pour une sécurité maximale

Pour une sécurité maximale, nous vous recommandons de spécifier un sous-réseau privé en tant que sous-réseau de noeuds de processus actif.

Le sous-réseau de noeuds de processus actif peut être un sous-réseau régional unique ou plusieurs sous-réseaux propres à des domaines de disponibilité (un dans chaque domaine de disponibilité). Le sous-réseau de noeuds de processus actif peut être un sous-réseau public ou privé. Cependant, pour une sécurité maximale, nous recommandons que le sous-réseau de noeuds de processus actif soit un sous-réseau privé.

Reportez-vous à la section Worker Node Subnet Configuration.

Meilleure pratique : Migrez les clusters pour qu'ils soient natifs du VCN afin d'intégrer l'adresse d'API Kubernetes dans votre VCN

Nous vous recommandons de migrer des clusters qui ne sont pas déjà natifs du VCN pour qu'ils soient natifs du VCN.

Dans un cluster natif VCN, les noeuds de processus actif, les équilibreurs de charge et l'adresse d'API Kubernetes sont entièrement intégrés à votre propre VCN, et vous pouvez les configurer en tant que publics ou privés. Vous pouvez contrôler l'accès au sous-réseau d'adresse d'API Kubernetes à l'aide de règles de sécurité définies pour des groupes de sécurité réseau (recommandé) ou de listes de sécurité.

Pour tirer parti du contrôle de sécurité offert par les clusters natifs du VCN, migrez un cluster qui n'est pas déjà natif du VCN pour intégrer son adresse d'API Kubernetes dans votre propre VCN.

Reportez-vous à Migration vers des clusters natifs VCN.

Meilleure pratique : créer un élément ConfigMap pour remplacer le comportement CoreDNS par défaut

Nous vous recommandons de créer et d'appliquer votre propre fichier ConfigMap pour remplacer les paramètres du fichier noyau CoreDNS afin de personnaliser le comportement CoreDNS par défaut.

Si vous personnalisez le comportement CoreDNS par défaut, les personnalisations sont périodiquement supprimées lors des mises à jour internes du cluster.

Reportez-vous à Configuration des serveurs DNS pour les clusters Kubernetes.

Meilleure pratique : Utiliser des sondes de préparation et de vivacité pour les vérifications de l'état

Nous vous recommandons d'utiliser des sondes de vivacité et de préparation Kubernetes pour vérifier l'état des conteneurs dans un cluster et de personnaliser les sondes afin de répondre à vos besoins.

La gestion de grands systèmes distribués peut être compliquée, en particulier en cas de problème. Les vérifications de l'état de Kubernetes sont un moyen facile de s'assurer que les instances d'application fonctionnent. La création de vérifications personnalisées de l'état vous permet d'adapter ces vérifications à votre environnement.

En particulier, nous vous recommandons fortement d'envisager d'utiliser des sondes de préparation et de vivacité pour confirmer que les conteneurs fonctionnent et fonctionnent correctement avant de les rendre candidats à la réception du trafic d'un service. Les paramètres de sonde et de sonde spécifiques à utiliser dépendent de la charge de travail. Trouvez un équilibre entre rendre la sonde trop agressive et trop lente, et ajustez les paramètres pour répondre aux besoins de l'application.

Reportez-vous à Configuration des sondes de disponibilité, de préparation et de démarrage dans la documentation Kubernetes.

Meilleure pratique : utiliser des mesures d'équilibreur de charge et d'équilibreur de charge réseau pour surveiller les back-ends

Nous vous recommandons d'utiliser des mesures pour surveiller l'état de l'équilibreur de charge OCI ou de l'équilibreur de charge réseau provisionné pour un service Kubernetes de type LoadBalancer.

Nous vous recommandons également de configurer des alarmes pour vous alerter si la disponibilité du back-end est inférieure au seuil de votre choix. Par exemple :

• Utilisez la mesure d'équilibreur de charge UnhealthyBackendServers pour configurer une alarme afin de vous alerter si le nombre de serveurs back-end en mauvais état dans un ensemble de back-ends est supérieur à zéro.
• Utilisez la mesure d'équilibreur de charge BackendTimeouts pour configurer une alarme afin de vous alerter si le nombre d'expirations sur tous les serveurs back-end est supérieur à zéro.
• Utilisez la mesure d'équilibreur de charge réseau HealthyBackends pour configurer une alarme afin de vous alerter si le nombre de back-ends qu'Oracle considère comme sains est inférieur à un.
• Utilisez la mesure d'équilibreur de charge réseau UnhealthyBackends pour configurer une alarme afin de vous avertir si le nombre de back-ends qu'Oracle considère comme en mauvais état dépasse zéro.

Reportez-vous à Mesures d'équilibreur de charge, à Mesures d'équilibreur de charge réseau et à Création d'une alarme.

Meilleure pratique : utiliser des libellés de noeud pour inclure un sous-ensemble de noeuds de processus actif dans un ensemble de back-ends

Nous vous recommandons d'utiliser l'annotation node-label-selector pour inclure dans l'ensemble de back-ends d'un équilibreur de charge ou d'un équilibreur de charge réseau donné uniquement ce sous-ensemble de noeuds de processus actif disposant des pods d'application requis. L'inclusion de sous-ensembles de noeuds de processus actif d'un cluster dans les ensembles de back-ends de différents équilibreurs de charge et équilibreurs de charge réseau vous permet de présenter un seul cluster Kubernetes sous la forme de plusieurs clusters logiques (services).

Après avoir attaché un libellé Kubenetes aux noeuds de processus actif à inclure dans l'ensemble de back-ends d'un équilibreur de charge ou d'un équilibreur de charge réseau, vous indiquez ce libellé dans le manifeste du service de type LoadBalancer :

• pour un équilibreur de charge, utilisez l'annotation oci.oraclecloud.com/node-label-selector:
• pour un équilibreur de charge réseau, utilisez l'annotation oci-network-load-balancer.oraclecloud.com/node-label-selector:

apiVersion: v1
kind: Service
metadata:
  name: my-nginx-svc
  labels:
    app: nginx
  annotations:
    oci.oraclecloud.com/node-label-selector: lbset=ServiceA
spec:
  type: LoadBalancer
...

apiVersion: v1
kind: Pod
...
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: lbset
            operator: In
            values:
            - ServiceA
...

Reportez-vous à Sélection des noeuds de processus actif à inclure dans les ensembles de back-ends.

Meilleure pratique : installer Calico avant de créer des pools de noeuds

Nous vous recommandons d'installer Calico sur un cluster avant de créer des pools de noeuds si vous souhaitez utiliser Calico pour améliorer la sécurité du cluster.

Vous pouvez améliorer la sécurité des clusters en implémentant des stratégies réseau Kubernetes. Pour implémenter des stratégies réseau Kubernetes, vous devez installer et configurer un fournisseur réseau prenant en charge les ressources NetworkPolicy. L'un de ces fournisseurs est Calico.

Si vous installez Calico sur un cluster qui dispose de pools de noeuds dans lesquels des pods sont déjà exécutés, vous devrez recréer les pods une fois l'installation de Calico terminée. Par exemple, en exécutant la commande kubectl rollout restart. Si vous installez Calico sur un cluster avant de créer des pools de noeuds dans ce cluster (comme recommandé), vous n'aurez pas besoin de recréer de pods.

Reportez-vous à Exemple : installation de Calico et configuration de stratégies réseau.