Je suis toujours en train d'expérimenter la migration de mon application Service Fabric vers Kubernetes. Dans la structure de service, j'ai deux types de nœuds (en fait des sous-réseaux), et pour chaque service, je configure le sous-réseau sur lequel il sera déployé. Je ne vois pas d'option équivalente dans le fichier yml de kubernetes. Est-ce possible dans kubernetes?
3 Réponses :
Tout d'abord, ce ne sont pas en fait des sous-réseaux. Ils peuvent tous être dans le même sous-réseau. Mais avec AKS, vous avez des pools de nœuds. de la même manière que Service Fabric, ceux-ci peuvent être dans différents sous-réseaux (à l'intérieur du même vnet *, afaik). Ensuite, vous utiliseriez nodeSelectors pour attribuer des pods aux nœuds sur le pool de nœuds.
Le même principe s'appliquerait si vous créez vous-même un cluster kubernetes, vous devrez étiqueter les nœuds et utiliser nodeSelectors pour cibler des nœuds spécifiques pour vos déploiements.
Il me manque peut-être quelque chose, mais en regardant ce document: docs.microsoft.com/en-us/azure/aks/use-multiple-node-pools , il indique que "Tous les pools de nœuds doivent résider dans le même sous-réseau.". Cela semble suggérer que je ne peux avoir qu'un seul sous-réseau, ou est-ce que je le lis mal?
hm, je jure devant Dieu que cela fonctionnait avant même que plusieurs pools de nœuds n'existent, mais cette configuration (plusieurs sous-réseaux) n'est probablement pas encore prise en charge. Je suis sûr que cela fonctionnera lorsque vous le créerez à l'aide d'un modèle ARM, par exemple
Ha, merci, je vais essayer de le faire avec un modèle ARM alors.
mais il ne sera pas pris en charge, même si cela fonctionne et il pourrait ne pas survivre à une mise à niveau
vous seriez mieux avec aks-engine < / a>. il serait pris en charge d'avoir plusieurs pools de nœuds avec différents sous-réseaux
Dans Azure, le cluster AKS peut être déployé sur un sous-réseau spécifique. Si vous recherchez une isolation au niveau de déploiement, déployez les deux types de nœuds sur différents espaces de noms dans le cluster k8s. De cette façon, les types de nœuds sont isolés et peuvent être atteints en utilisant une combinaison de nom de service et d'espace de noms
Je souhaite que mes services backend accèdent à ma base de données SQL dans un sous-réseau différent vers le front-end. De cette façon, je peux limiter l'accès à la base de données au sous-réseau principal uniquement.
Il s'agit d'une ancienne façon de résoudre la sécurité du réseau. Une méthode plus moderne est appelée Zero Trust Networking , voir par exemple BeyondCorp sur Google ou le livre Zero Trust Networks .
La méthode Kubernetes pour limiter le service qui peut accéder à ce service en utilisant Règles du réseau .
Une stratégie de réseau est une spécification de la manière dont les groupes de pods sont autorisés à communiquer entre eux et avec les autres points de terminaison du réseau.
Les ressources NetworkPolicy utilisent des libellés pour sélectionner les pods et définir des règles qui spécifient le trafic autorisé vers les pods sélectionnés.
Il s'agit d'une manière plus définie par logiciel de limiter l'accès que l'ancienne, basée sur un sous-réseau. Et les règles sont plus déclaratives en utilisant des étiquettes Kubernetes au lieu de numéros IP difficiles à comprendre.
Ceci doit être utilisé en combinaison avec l ' authentification .
Pour vous inspirer, lisez également Nous avons construit l'isolation du réseau pour 1 500 services pour rendre Monzo plus sécurisé .
Dans l'équipe de sécurité de Monzo, l'un de nos objectifs est d'évoluer vers une plateforme de confiance totalement zéro. Cela signifie qu'en théorie, nous serions capables d'exécuter du code malveillant à l'intérieur de notre plate-forme sans risque - le code ne pourrait pas interagir avec quoi que ce soit de dangereux sans que l'équipe de sécurité n'accorde un accès spécial.
De plus, si vous utilisez Istio, vous pouvez limiter l'accès aux services externes en utilisant Entrée de service Istio . Il est également possible d'utiliser des stratégies de réseau personnalisées pour le même comportement, par ex. Cilium .
Ok merci, je vais en lire plus. Certains des services back-end sont un peu gourmands en ressources, j'aurais probablement toujours besoin d'utiliser l'approche nodeSelector ci-dessus pour m'assurer que ces services sont sur différents nœuds avec différentes tailles de VM.
Qu'essayez-vous de réaliser en utilisant plusieurs sous-réseaux? Pour quelle raison souhaitez-vous utiliser plusieurs sous-réseaux?
Je souhaite que mes services backend accèdent à ma base de données SQL dans un sous-réseau différent vers le front-end. De cette façon, je peux limiter l'accès à la base de données au sous-réseau principal uniquement.