Multi-location dans Kubernetes – Un bon serveur Minecraft

Transcription

Probst: Permettez-moi de commencer par dire quelque chose que j'ai vu en parlant à beaucoup de nos clients. Qu'est-ce qui intéresse les entreprises? Ils se soucient de livrer leurs produits à leurs clients, idéalement, le plus rapidement possible, de façon rapide et idéale, avec le moins de coûts possible. Ce sont des thèmes que je vois encore et encore, et les gens choisissent des outils et une infrastructure qui les aident à atteindre ces objectifs. Ce dont je vais parler ici aujourd’hui, c’est de la façon dont Kubernetes, et en particulier de la multi-location à Kubernetes, peut être l’un des outils de votre boîte à outils que vous pouvez examiner pour vous aider à atteindre ces objectifs.

Permettez-moi de me présenter brièvement. Je m'appelle Katharina Probst, je suis directrice principale de l'ingénierie chez Google. Vous pouvez me trouver sur LinkedIn si vous le souhaitez. Je partagerai également les diapositives. Vous pouvez donc prendre des photos, mais vous pouvez également les télécharger plus tard.

Pourquoi le multi-logement

Commençons par comprendre pourquoi vous voudrez peut-être examiner de plus près les locations multiples. L'un de vous exploite-t-il des clusters Kubernetes multi-locataires? Un couple, super, j'aimerais entendre vos expériences aussi, peut-être que vous pourrez partager avec la salle plus tard. Pourquoi vous soucier de multi-location? Lorsque vous commencez avec Kubernetes, vous avez généralement un utilisateur qui interagit via un outil de ligne de commande ou l’API, ou une interface utilisateur avec un maître. Comme nous venons de l'entendre, le maître exécute le serveur API, le planificateur et le contrôleur. Ce maître est responsable de l’orchestration et du contrôle du cluster réel. Le cluster est constitué de plusieurs nœuds sur lesquels vous planifiez vos pods. Supposons que ces nœuds soient des machines ou des machines virtuelles, ou quel que soit le cas. En général, vous avez un maître logique qui contrôle un seul cluster. Cela semble relativement simple. Lorsque vous avez un utilisateur et un cluster, c'est ce que c'est.

Maintenant, que se passe-t-il lorsque vous commencez à avoir plusieurs utilisateurs? Supposons que votre entreprise décide d’utiliser Kubernetes pour une variété d’applications internes. Vous avez donc un développeur qui crée son cluster Kubernetes. Vous en avez un autre qui crée son cluster Kubernetes. Vos administrateurs pauvres doivent maintenant gérer deux d'entre eux. Cela commence à devenir un peu plus intéressant. Vous avez maintenant deux déploiements complètement distincts de Kubernetes avec deux maîtres et ensembles de nœuds complètement distincts. Ensuite, avant de vous en rendre compte, vous avez quelque chose qui ressemble davantage à ceci. Vous avez une multitude de grappes. Vous obtenez de plus en plus de clusters avec lesquels vous devez maintenant travailler.

Ce qui se passe maintenant, certaines personnes appellent cela l'étalement de cube, c'est en fait un phénomène assez bien compris à ce stade. Que se passe-t-il maintenant, je vais vous poser deux questions: comment fonctionne cette échelle? Réfléchissons un peu sur la manière dont ce modèle évolue financièrement. Combien vous en coûte-t-il pour faire fonctionner ces clusters? La première chose qui peut se démarquer est que vous avez maintenant tous ces maîtres qui traînent. Maintenant, vous devez exécuter tous ces maîtres. En règle générale, il est recommandé de ne pas exécuter un seul nœud maître, mais trois ou six, afin d'obtenir une meilleure disponibilité. Si l'un d'eux échoue, les autres peuvent prendre la relève. Lorsque vous regardez tous ces maîtres ici, ils ne sont pas normalement un seul nœud par maître, ils sont généralement trois. Cela commence à paraître un peu plus cher. C'est le numéro un.

Deuxièmement, nous constatons souvent que les clients disent: «J'ai toutes ces applications et certaines d'entre elles sont exécutées pendant la journée, et elles capturent le trafic des utilisateurs». Ils ont besoin de beaucoup de ressources pendant la journée, mais ils restent vraiment oisifs la nuit. Ils ne font rien vraiment la nuit, mais vous avez tous ces nœuds.

Ensuite, vous avez certaines applications qui sont des applications par lots, peut-être le traitement en arrière des journaux ou quoi que ce soit, et vous pouvez les exécuter à tout moment. Vous pouvez les exécuter la nuit, dans ce modèle où certaines applications s'exécutent pendant la journée, puis les autres applications s'exécutant la nuit, et utilisant les mêmes nœuds. Cela semble raisonnable. Avec ce modèle, où vous avez des grappes complètement séparées sur des nœuds complètement séparés, vous venez de rendre cela beaucoup plus difficile pour vous-même. C'est une considération.

Une autre considération que les gens évoquent beaucoup est les frais généraux opérationnels, ce qui signifie combien il est difficile de faire fonctionner toutes ces grappes. Si vous avez déjà vécu une telle situation auparavant, peut-être même pas avec Kubernetes, vous remarquerez que, souvent, ce qui se passe est que toutes ces grappes se ressemblent beaucoup au début, elles exécutent peut-être des applications très différentes. Les groupes de Kubernetes, comme les maîtres, appartiennent tous à la même version de Kubernetes, etc., mais avec le temps, ils ont tendance à dériver. Ils ont tendance à devenir tous ces flocons de neige spéciaux. Plus vous avez ces flocons de neige spéciaux, plus il est difficile de les faire fonctionner. Vous recevez des alertes tout le temps, et vous ne savez pas, s’agit-il d’une version spécifique, et vous devez faire un tas de travail. Nous avons maintenant des dizaines ou des centaines de tableaux de bord à examiner pour comprendre ce qui se passe. Cela devient maintenant très difficile sur le plan opérationnel et finit par vous ralentir.

Cela dit, il existe un modèle qui convient très bien dans certaines circonstances. Beaucoup de gens choisissent ce modèle, peut-être pas des centaines ou des milliers, mais beaucoup choisissent ce modèle de grappes complètement séparées, car il présente certains avantages, tels qu’il est plus facile de raisonner et que les frontières de sécurité sont très étroites. Disons que vous êtes dans cette situation et que vous avez des centaines de grappes, et que cela devient une telle douleur. Une chose que vous pouvez considérer est ce que nous appelons la multi-location dans Kubernetes.

Il existe de nombreuses définitions de la multi-location. Lorsque vous lisez des articles sur Internet concernant la multi-location dans Kubernetes, vous devez creuser un peu plus pour comprendre de quel modèle nous parlons. Habituellement, ce dont on parle, c’est ce modèle que vous voyez sur la diapositive. Ce modèle correspond au fait que de nombreux utilisateurs interagissent via la ligne de commande, l’API et l’interface utilisateur, avec un seul maître logique. Vous avez un maître en cours d'exécution, et ce maître contrôle maintenant un grand cluster – parce que pour les petits clusters, cela n'a pas beaucoup de sens, peut-être – mais un grand cluster et ce cluster est divisé en espaces de noms.

Il y a ce concept dont nous venons d'entendre parler dans Kubernetes et appelé espaces de noms. Ce que sont les espaces de noms, il est très important de comprendre qu’il s’agit de clusters virtuels. Vous avez un cluster physique, mais vous divisez ensuite ce cluster en espaces de noms. Cela ne signifie pas que ces deux nœuds appartiennent à cet espace de noms et que ces trois nœuds appartiennent à l'espace de noms suivant. Les nœuds sont en fait partagés entre les espaces de noms, mais celui-ci fournit une limite qui crée cet univers pour vous. Vous pouvez ensuite exécuter différentes applications dans ces espaces de noms tout en partageant les ressources.

Nous allons creuser un peu ce sujet. Habituellement, lorsque vous exécutez Kubernetes, vous avez différents rôles et différents types d’utilisateurs de ce cluster. Si vous avez un cluster multi-locataire, vous pouvez probablement avoir un administrateur de cluster. Cet administrateur de cluster a essentiellement beaucoup d'accès à tout le cluster. Ce sont eux qui configurent les espaces de noms, ils définissent les limites de ressources, comme nous le verrons plus tard, et ils veillent à la cohérence des espaces de noms du cluster afin d'éviter toute divergence. et tous ces différents flocons de neige. Bien entendu, ils sont souvent responsables de l’exploitation du cluster, de la gestion des incidents et du bon déroulement des opérations.

Nous avons maintenant un nouveau rôle qui s’applique uniquement à ce modèle de multi-hébergement, à savoir l’administrateur d’espace de nommage. L'administrateur de l'espace de noms n'a désormais plus nécessairement accès à notre contrôle sur l'ensemble du cluster, mais sur un seul espace de noms, peut-être plusieurs, mais pas sur l'intégralité du cluster. Par conséquent, seuls les droits d'administrateur sur des espaces de noms spécifiques.

Enfin, vous avez l'utilisateur du cluster, et l'utilisateur du cluster, comme auparavant, exécute ses applications sur le cluster. Maintenant, dans ce modèle à locataires multiples, c'est un peu différent, car l'utilisateur du cluster n'a désormais accès qu'à certains espaces de noms, voire à un seul. Il leur incombe de comprendre leurs propres espaces de noms, d'exécuter leurs applications dans ces espaces, de bien comprendre les limites des ressources et de ne pas piétiner d'autres locataires. Nous donnerons plus de détails à ce sujet plus loin dans les diapositives.

En gros, vous allez avoir des rôles, un administrateur de cluster, un administrateur d'espaces de noms et des utilisateurs différents de ceux que vous verrez généralement dans ce type de déploiement.

Hard Multitenancy

Lorsque les gens parlent de multi-location, ils parlent souvent – si vous allez, par exemple, de la communauté open source Kubernetes, du groupe de travail sur la multi-location – ils parlent de ce concept de multi-location ferme et de multi-location souple. . Je vais commencer par parler de multi-location difficile, mais permettez-moi de vous donner un bref aperçu de ce que cela signifie.

D'un côté, la multi-location difficile signifie que vous avez des locataires en qui vous ne faites pas confiance et qu'ils ne se font pas confiance, donc la confiance est nulle. Il peut s'agir de personnes aléatoires qui chargent du code et l'exécutent, ou de sociétés différentes qui se font concurrence. Ce pourrait être n'importe quoi, mais c'est vraiment au bout du spectre où la confiance est nulle.

De l'autre côté, il y a la multi-location souple, et je parlerai de cela plus tard aujourd'hui. Lorsque nous parlons de multi-location souple, il y a plus de confiance établie entre les locataires. Une chose qu'il est important de comprendre, c'est que les gens parlent souvent de multi-location simple ou souple. En réalité, il s’agit vraiment d’un spectre, car le degré de confiance que vous accordez à vos locataires n’est pas un binaire, c’est généralement un spectre. Quels types de cas d'utilisation fonctionnent pour vous, vous devez penser pour vous-même et pour votre cas d'utilisation spécifique.

Parlons un peu plus de la multi-location difficile. Encore une fois, c'est le cas où il n'y a pas de confiance. La multi-location difficile, pour diverses raisons, n'est pas encore largement utilisée en production. En gros, il s’agit des limites de sécurité et de la prévention des locataires. Il n'est pas encore largement utilisé dans la production. La communauté Kubernetes travaille actuellement à renforcer et à modifier Kubernetes afin que nous puissions nous rapprocher de plus en plus d'un point où il est très viable de le faire.

Parlons un peu de ce qu'il faudrait pour avoir ça. Pensez-y un peu. Vous avez maintenant un cluster avec un groupe de nœuds et ces nœuds sont partagés par des clients hébergés potentiellement malveillants. Que devez-vous faire pour vous assurer que cela fonctionne réellement? Vous devez vous assurer qu'il y a une grande isolation de sécurité, c'est la deuxième puce ici. Les locataires ne peuvent pas voir ou accéder aux affaires des autres, ils ne peuvent pas intercepter les demandes du réseau. Ils ne peuvent pas accéder au noyau hôte et augmenter leurs privilèges. Tout cela doit être assuré pour que vous puissiez avoir des locataires en lesquels vous ne pouvez pas faire confiance. L'autre chose est que vous devez vous assurer que les locataires ne se font pas essentiellement, ce qui signifie qu'ils n'ont pas d'incidence sur l'accès des autres aux ressources de l'autre.

Nous en reparlerons un peu plus tard, mais réfléchissons-y. Vous avez maintenant un groupe de nœuds qui sont partagés et vous devez vous assurer que tout le monde reçoit sa juste part. C'est une chose que cela prendrait. Une autre chose à vérifier est que, lorsque vous avez des ressources, il existe, par exemple, ce concept de contrôleurs personnalisés et de définitions de ressources personnalisées, qui permet d'étendre Kubernetes. Si vous avez maintenant tous ces différents locataires, et qu'ils s'étendent, ils ajoutent leurs propres API, leurs propres contrôleurs CRD, vous devez vous assurer qu'ils ne sont pas en conflit, afin qu'une personne ici ne crée pas une API qui en conflit avec quelque chose ici. Vous devez vous assurer qu'ils sont très bien isolés.

Enfin, une grande partie de ce dont nous parlons concerne ce que nous appelons le plan de données, qui est le cluster où se trouvent les nœuds. Les mêmes questions s'appliquent au maître, que nous appelons le plan de contrôle. Nous devons nous assurer que les ressources du plan de contrôle sont également partagées équitablement. Alors que nous sommes en train de faire en sorte que la multi-location difficile prenne de plus en plus de valeur, de plus en plus pratique et qu’elle soit utilisée en production, c’est le genre de questions à laquelle nous devons répondre.

Nous poursuivons notre cheminement vers la multi-location de plus en plus difficile. À l'heure actuelle, ce que les gens font beaucoup, c'est qu'ils utilisent la multi-location dans un contexte de confiance mutuelle. Les cas d'utilisation, par exemple, qui sont très communs ou très communs sont des équipes différentes au sein d'une même entreprise. Au sein d'une entreprise, vous dites que nous partageons un grand pool de ressources et que différentes équipes les partagent. Les différentes équipes ont vraiment une bonne motivation et une bonne raison de bien se comporter. Ils ne sont pas supposés être méchants, ils se font confiance et des accidents se produisent, et c'est ce que vous essayez de protéger, mais vous ne présumez pas qu'ils ne font pas complètement confiance.

Comme vous l'avez peut-être déjà deviné, dans ce modèle, différentes équipes auront généralement différents espaces de noms à partager dans un cluster. Comme je l'ai déjà dit, cela est utilisé dans la production. Souvent, ce qui se passe est que la multi-location est toujours quelque chose qui nécessite un peu de configuration ou peut-être beaucoup de configuration. Il y a un tas de boutons que vous devez tourner, nous en reparlerons dans un petit moment. J'ai souvent constaté que les entreprises utilisaient plusieurs locations, mais plusieurs personnes se sont consacrées à ce que les stratégies soient appliquées correctement et que le réseau soit configuré de manière cohérente, et ainsi de suite. ces clusters partagés.

Primitives multi-locataires

Il existe un certain nombre de primitives dans Kubernetes qui vous aideront à configurer et à gérer correctement un cluster à locataires multiples. J'ai déjà mentionné les espaces de noms. La bonne chose à propos des espaces de noms est qu’ils ont été intégrés très tôt dans Kubernetes et que ce sont des concepts très fondamentaux; ils sont donc implémentés partout et à peu près tous les composants comprennent les espaces de noms. C'est bien, mais les espaces de noms à eux seuls ne suffisent pas.

Un certain nombre de choses à faire pour configurer votre cluster multi-locataires de manière à protéger les locataires des accidents des autres, par exemple. Nous allons parler de trois choses un peu plus en détail. Le premier est le contrôle d’accès, qui signifie qui peut accéder à quoi. L’un est l’isolement, c’est-à-dire comment faire pour que tout le monde ne puisse pas se voir. Ensuite, la dernière chose, pour revenir à nos objectifs ambitieux concernant la multi-location, est le partage équitable. Ce qui existe déjà dans Kubernetes vous permet d’assurer un partage équitable entre les locataires.

Parlons un peu du contrôle d'accès. C'est notre premier primitif dont nous allons parler ici. Nous avons déjà entendu parler un peu de RBAC, cela a été mentionné dans le discours précédent. RBAC est un contrôle d'accès basé sur les rôles dans Kubernetes. RBAC est essentiellement un outil intégré à Kubernetes qui vous permet de contrôler qui peut accéder à quoi. En gros, la façon dont cela fonctionne est que vous définissez ces rôles et dans ces rôles, vous décrivez: "Je vais avoir mon rôle d'administrateur, et cet administrateur peut faire toutes ces choses différentes", il existe deux types de rôles . Il y a ClusterRoles, ce sont des rôles qui s'appliquent à l'ensemble du cluster, c'est logique.

Ensuite, ils ne sont que des rôles, et ces rôles sont étendus à un espace de noms, ce qui signifie qu'ils s'appliquent à des espaces de noms spécifiques, quels qu'ils soient. Kubernetes est déjà livré avec des rôles par défaut que vous pouvez utiliser, mais vous pouvez ensuite créer le vôtre et vous voudrez probablement le faire. Vous créez vos propres rôles qui indiquent exactement qui peut accéder à quels pods, quels espaces de noms, quels secrets et tout le reste.

Vous avez maintenant créé ces rôles et vous obtenez maintenant un nouvel employé. Maintenant, vous devez vous assurer que ces rôles sont attribués à cet employé. Pour ce faire, utilisez ClusterRoleBinding ou RoleBinding. ClusterRoleBbinding vous permet de lier des groupes de personnes ou des comptes de service, ou des individus, à ClusterRoles – là encore, à l'échelle du cluster – et à RoleBindings de lier des individus ou des groupes, ou des comptes de service à des rôles étendus à un espace de noms.

Vous allez utiliser ceci abondamment. À titre d’exemple très concret, vous l’utiliserez abondamment pour obtenir l’isolement souhaité. Un exemple très concret est Secrets. Kubernetes propose des secrets qui vous permettent de stocker des éléments tels que les mots de passe si vous en avez besoin. Pour ce faire, ils sont stockés dans SCD, donc dans le maître. Vous devez vous assurer qu'ils sont cryptés, mais également que seules les personnes ayant accès aux espaces de noms appropriés peuvent accéder à ces secrets. Même si vous êtes dans un endroit où vous vous faites tous plus ou moins confiance, vous devez vous assurer que les secrets sont bien protégés.

RBAC est ce mécanisme que vous allez utiliser de manière intensive pour vous assurer de créer essentiellement cet univers, ce cluster virtuel issu de ce concept appelé espace de nom. Kubernetes fournit d’autres fonctionnalités qui vous permettent d’être plus précis dans vos contrôles de sécurité. L'une d'entre elles est la politique de sécurité du pod, similaire en ce sens qu'elle vous permet de définir des politiques de sécurité. Cela vous permet essentiellement de dire: "Pour un pod spécifique, je n'autoriserai les pods que dans un espace de noms spécifique si ce pod ne s'exécute pas en tant que privilège", par exemple. Vous pouvez donc définir une politique de sécurité pour les pods, puis l’appliquer à nouveau au cluster et aux espaces de noms afin d’améliorer la sécurité.

Une des choses qui se passe, nous avons un peu entendu parler de stratégies de réseau. Permettez-moi de parler de cela dans le contexte de la multi-location. Lorsque vous avez un cluster à locataires multiples, vous avez un cluster qui est divisé en ces espaces de noms. Les espaces de noms sont des clusters virtuels, les nœuds sont donc partagés entre tous les espaces de noms. Maintenant, les pods sont planifiés sur ces nœuds, il est donc tout à fait possible et probable que vous ayez un nœud qui contiendra des pods de différents espaces de noms sur le nœud.

Si vous avez déjà travaillé sur des systèmes distribués volumineux comportant de nombreux composants différents, vous aurez sans doute constaté que c’est une très bonne idée d’être très attentif à la question de savoir qui peut parler à qui. J'ai travaillé sur des systèmes où nous ne l'avions pas fait au début, puis trois ans plus tard, nous nous sommes dit: "C'était une très mauvaise idée", car tout le monde peut parler à tout le monde et nous ne pouvons pas raison de rien, et nous n'avons aucune idée de ce qui se passe.

Dans un espace de noms d'un cluster Kubernetes à locataires multiples, il est vivement recommandé de définir avec soin les stratégies de réseau. Ce que ces stratégies réseau vous permettent de faire, c’est de vous permettre de définir les entrées et sorties, ainsi, pour des pods spécifiques, ils vous permettent de dire: "Ce pod peut parler à ce pod, mais pas à ces autres," pour que vous puissiez mieux raisonner. la topologie de vos déploiements.

Une autre meilleure pratique consiste à définir une définition de ressource personnalisée étendue à l'espace de noms. Ils peuvent être, et probablement ils devraient être. Il y a des cas d'utilisation où ce n'est peut-être pas la bonne chose à faire, mais en général, lorsque vous avez ces définitions de ressources personnalisées (qui sont des extensions), différentes équipes écrivent des extensions pour Kubernetes et leurs propres contrôleurs personnalisés. Dans certains cas, il est logique de les définir comme des espaces de noms afin qu’ils ne soient pas en conflit avec ce que font d’autres personnes, car elles pourraient ne pas vous intéresser, et vous pourriez ne pas aimer les effets secondaires qu’elles pourraient avoir.

La dernière chose que je veux aborder en termes d’isolement est le bac à sable. Les gens disent maintenant que les conteneurs ne contiennent pas, donc ils ne sont pas de grandes frontières de sécurité. En pratique, cela signifie que si vous exécutez vos conteneurs sur un nœud, vous devez prendre en compte certaines considérations de sécurité. Par exemple, vous devez vous assurer que, lorsque ce pod s'exécute sur le nœud, il ne peut pas facilement accéder au noyau hôte, puis pirater le noyau hôte et augmenter les privilèges, puis accéder à tout ce qui est en cours d'exécution dans le cluster. .

Les bacs à sable placent une frontière de sécurité plus étroite autour de chaque module et vous pouvez donc simplement lancer tous vos modules dans les bacs à sable. Ensuite, il y en a plusieurs, gVisor est l'un d'entre eux qui a été développé. C'est en fait une source ouverte, mais Google y investit énormément, alors j'en sais un peu plus à ce sujet. La façon dont cela fonctionne est, il met la frontière de sécurité et isole les pods plus. L’objectif est de s’assurer que les informations ne sont pas divulguées entre les locataires et qu’ils ne peuvent pas sortir accidentellement ou de manière malveillante, déranger tout le monde et arrêter les conteneurs de tous les autres. C'est quelque chose à considérer.

Il y a beaucoup de détails ici, mais ce que je veux que vous reteniez de cette partie de la présentation, c'est que lorsque vous avez un grand cluster multi-locataire, vous attribuez des espaces de noms, et c'est vraiment la première étape. Ce que vous faites ensuite, c’est que vous définissez tous les mécanismes de sécurité et d’isolation afin de créer un univers plus étroitement contrôlé pour chaque espace de noms.

Parlons un peu du partage équitable. Ce que je vais parler de cette diapositive est un partage juste dans ce que nous appelons le plan de données, qui est le groupe de nœuds, donc un partage juste des ressources. La raison pour laquelle je parle ici du plan des données est qu’il existe différents mécanismes sur le plan des données, qui sont en fait plus développés que sur le plan de contrôle du maître. Je parlerai du maître dans la prochaine partie de la présentation. Parlons un peu du plan de données.

Lorsque vous avez toutes vos équipes différentes qui exécutent vos applications, j'en ai fait l'expérience, peut-être que certaines d'entre vous le sont aussi, même si vous voulez bien vous comporter et que vous êtes incité à bien vous comporter, ce qui arrive parfois est que tout d'un coup, vous obtenez beaucoup de trafic. Ensuite, votre détecteur automatique démarre et c’est merveilleux, et votre application est toujours en cours d’exécution, mais d’autres ne peuvent plus s’exécuter. Vous devez vous assurer que vous avez les mécanismes en place pour que les locataires ne se piétinent pas les uns les autres et ne s'empêchent pas. Le moyen le plus important ou peut-être le plus fondamental de procéder dans un cluster Kubernetes à locataires multiples est d'utiliser un système appelé quotas de ressources.

Les quotas de ressources sont conçus pour vous permettre de définir des limites de ressources pour chaque espace de nom, ce qui est logique car vous avez un certain nombre de nœuds et vous devez vous assurer de répartir les ressources entre les espaces de nom. Il existe quelque chose appelé LimitRanger, qui vous permet de définir des valeurs par défaut pour tous les espaces de noms. Essentiellement, ce que vous allez faire, c'est penser au nombre de ressources que tout le monde obtient pour le processeur, la mémoire et d'autres éléments tels que le nombre d'objets. Combien de revendications de volume persistant puis-je avoir par espace de noms? En effet, le nombre de volumes que vous pouvez monter sur chaque machine virtuelle est limité, en fonction de l'emplacement où vous les exécutez. Vous devez également vous assurer que ceux-ci sont partagés équitablement. Les quotas de ressources vous permettent de le faire.

Ensuite, vous pouvez définir des priorités et des classes de qualité de service sur les pièces. Il y a des concepts connexes, et ce que je veux que vous reteniez, c'est qu'il existe des moyens de contrôler un tout petit peu, les pods ayant une priorité plus élevée que les autres. Vous connaissez probablement ce concept de priorité, même s'il ne provient pas de Kubernetes, ni d'autres systèmes comme Linux. Cela vous permet essentiellement de les contrôler. Les classes de qualité de service sont un autre inconvénient, car elles vous permettent également de dire: «C’est le nombre de ressources dont j’ai besoin, mais je peux les exploiter potentiellement", ou je peux dire: "j’ai besoin de la garantie absolue que ces modules fonctionneront. "

Enfin, les deux derniers éléments de la puce, nœud et pod. Ce sont des mécanismes qui vous permettent d’influencer le planificateur. L'ordonnanceur est une technologie complexe et complexe sur laquelle il n'est pas toujours facile de raisonner. Vos pods sont programmés et vous ne savez pas vraiment pourquoi ils se sont retrouvés là où ils l'ont fait. C'est compliqué de raisonner souvent, mais il existe des mécanismes qui vous permettent d'influencer le planificateur. Nous avons un peu entendu parler d'Affinity et de Pod Anti-affinity auparavant. Cela signifie que vous pouvez dire que ces deux modules ne doivent pas être programmés ensemble. Dans le contexte de la multi-location, cela peut signifier que les applications de deux espaces de nom différents ne doivent pas se retrouver sur le même pod. Vous avez peut-être des espaces de noms qui exécutent des applications financières que vous souhaitez conserver séparément des autres éléments.

Un concept intéressant que je voudrais évoquer ici est ce concept de souillure et de tolérance, qui est vraiment intéressant dans le contexte de la multi-location. Son fonctionnement, c’est que vous dites, pour un nœud, que vous le salissez et que vous lui attribuez simplement une étiquette. Vous dites «vert», puis uniquement les pods dont la tolérance correspond à celle qui est planifiée. Seules les parties ayant la même tolérance, verte, seront planifiées sur ce nœud. Cela signifie pour nous dans le contexte de la multi-location, c’est une façon pour vous de contrôler s’il est nécessaire d’avoir des nœuds ne planifiant que des parties d’un espace de noms spécifique. C'est comme ça que vous le faites.

Multitenancy du plan de contrôle

Parlons un peu plus du plan de contrôle. Le plan de contrôle, encore une fois, est le maître. Le serveur d'API et le planificateur, c'est ce qui compte le plus dans notre contexte. Une grande partie de ce dont nous avons parlé étaient les nœuds, alors parlons un peu du maître. Une des choses que vous remarquerez, en cours de route, est que nous partageons le cluster qui se trouve à droite. Toutes ces applications partagent donc le cluster, mais le maître est l’autre élément que nous partageons. Nous sommes toujours, tous ensemble, en train de partager ce maître.

Il y a une chose que je devrais souligner. Rappelez-vous ce que j’ai dit au début quand les gens parlent de multi-location, ils veulent parfois dire différent [inaudible] pas capable de faire ça. Nous sommes définitivement dans ce mode d’un maître contrôlant un cluster. C'est très bien.

Tous les locataires partagent le maître, et cela inclut des choses comme des secrets. Rappelez-vous ce dont nous avons parlé, vous devez protéger vos secrets avec RBAC. Une des choses pour lesquelles le maître, en particulier le serveur API, n’est pas vraiment formidable à l’heure actuelle est d’empêcher les locataires de se faire DDoSing ou DoSing les uns des autres et de s’évincer les uns les autres. Vous avez ce maître en cours d'exécution, et le maître reçoit ces demandes d'utilisateurs. Imaginez que vous ayez un utilisateur qui envoie tout d'un coup toutes ces demandes. Ensuite, le serveur d'API est "Je ne sais pas quoi faire avec toutes ces demandes". Ensuite, le serveur d'API prend du retard et les autres locataires ne reçoivent pas un mot, leurs demandes sont rejetées. En réalité, c'est pire car le serveur d'API peut également supprimer des éléments tels que le nettoyage de la mémoire et d'autres éléments qui sont supprimés.

Vous pouvez vérifier si des travaux sont en cours dans la communauté open source qui permettront un meilleur partage équitable sur le serveur d'API. La façon dont cela fonctionnera est une sorte de refonte de ce concept de requêtes max en vol. Le nombre maximal de requêtes en vol est un concept du serveur d'API qui dit essentiellement: "Voici le nombre de demandes que je peux traiter à un moment donné et le reste, je rejette simplement."

Vous pouvez lire ceci dans la proposition actuellement en cours, mais cela va permettre de généraliser le traitement des requêtes inflight maximales dans le serveur API afin de faire plus de distinctions entre les demandes et de fournir une hiérarchisation et une équité entre les catégories de serveurs. demandes. C'est long, vous pouvez ensuite le lire à nouveau dans les diapositives, mais laissez-moi simplement expliquer un peu ce que cela signifie pour nous dans le contexte de la multi-location.

Dans cette nouvelle façon de faire, lorsque différents locataires recevront des demandes, il y aura différents niveaux de priorité. Ainsi, ceux du système prendront le niveau de priorité le plus élevé, comme vous pouvez le deviner, puis différents locataires pourront peut-être avoir la même priorité. niveau, et différents locataires auront probablement des indices différents, puis ils se feront concurrence pour le serveur API.

Quelles entreprises se soucient de

Avant de conclure, je vous ai donné un certain nombre de points à examiner et à réfléchir à la manière dont vous avez organisé cette tâche. Permettez-moi maintenant de revenir au début de la présentation et de parler un peu, de montrer à quel point la multi-location peut vous aider avec rapidité et coût. Vous pouvez sortir de cette présentation en disant: «C'est vraiment compliqué», mais quand vous y tenez vraiment, quand vous avez un cluster partagé, vous avez maintenant la possibilité d'avoir des stratégies à travers le cluster, d'avoir les mêmes paramètres réseau à travers le cluster, et contrôler les choses plus étroitement.

D'après mon expérience, cela vous aidera vraiment à long terme avec votre vitesse, avec votre rapidité à sortir les choses plus rapidement, de sorte que vous n'ayez pas à chercher à 100 endroits. Revenons ensuite à la question des coûts. Le coût est quelque chose que vous pouvez économiser en partageant le maître, mais également en partageant les ressources des nœuds sous-jacents entre tous les espaces-noms.

Points clés à retenir

Ce que je veux que vous reteniez de cette présentation est de penser à la location multiple comme l’un des outils de votre boîte à outils si vous souhaitez améliorer l’efficacité des ressources, les coûts et les opérations. Nous avons parlé de vitesse et de coûts. Réfléchissez-y et voyez si cela s'applique à vos cas d'utilisation.

Lorsque vous en lirez un peu plus sur la multi-location, vous entendrez parler de dur et de doux. N'oubliez pas que c'est un spectre. Hard signifie que vous ne faites pas confiance aux locataires, soft signifie que vous leur faites entièrement confiance. La vérité est généralement quelque part au milieu, car même si vous faites entièrement confiance aux locataires, ceux-ci peuvent commettre des erreurs stupides et vous voulez toujours vous protéger contre eux, dans une certaine mesure.

Nous sommes sur la bonne voie pour rendre réellement viable la multi-location difficile. Il y a du travail en cours, ce qui m'encourage vraiment et c'est très excitant. À l'heure actuelle, nous constatons qu'un nombre assez important de sociétés utilisent la multi-location souple dans la production et, comme vous l'avez vu dans cette présentation, certaines configurations sont toujours nécessaires et vous devez tourner certains boutons pour vous assurer que cela fonctionne bien pour vous. . C'est certainement quelque chose qui peut très bien fonctionner.

Lorsque je partagerai les diapositives, j'aurai quelques liens à la fin, qui renverront au travail open-source dont je parlais ici, pour que vous puissiez en lire un peu plus.

Voir plus de présentations avec transcriptions