Résidence des données

Le problème

Un déploiement est parfois requis — par contrat, par un régulateur ou par la politique propre d’un locataire — pour s’exécuter à l’intérieur d’un pays particulier. Quelqu’un doit faire de cette exigence une propriété du déploiement plutôt qu’une note dans un runbook, et elle doit être vérifiée, dans les deux sens : l’exigence doit être bien formée, et la machine sur laquelle elle atterrit doit réellement se trouver là où elle le prétend.

La partie difficile n’est pas la vérification. C’est ce qui se passe lorsque l’exigence est mal écrite. Une contrainte exprimée en texte libre n’est pas rejetée lorsqu’elle est mal orthographiée — elle ne correspond tout simplement à rien et ne contraint rien, silencieusement, sur le déploiement unique dont le but entier était la contrainte.

Ce qu’il applique : le placement

La résidence détermine quelle machine exécute le conteneur. Rien d’autre.

Vous le déclarez dans le bloc placement du déploiement :

apiVersion: odysseus/v1
kind: Deployment
metadata:
  name: ledger-api
spec:
  image: registry.example.com/ledger-api:1.4.0
  replicas: 2
  placement:
    residency:
      country: CA

Cela signifie : exécuter ceci uniquement sur un nœud qui se déclare comme étant au Canada. Un region — un nom que le plan de contrôle auquel vous vous adressez déclare — est l’alternative lorsque la juridiction couvre plusieurs pays, et blockedCountries indique le type de règle opposé, une exclusion. Chaque clé, son type, sa valeur par défaut et le rejet qu’elle déclenche sont décrits dans la référence du déploiement.

La déclaration est vérifiée lors de l’écriture. Un pays doit être un code ISO 3166-1 alpha-2 attribué, et une région doit être une région déclarée par ce plan de contrôle — tout autre chose est refusée au moment de l’écriture, avec la valeur citée en retour et la forme acceptée explicitée. C’est tout l’intérêt d’un champ typé plutôt qu’une étiquette.

La définition manuelle des labels sous-jacents est refusée, pas dépréciée. L’ordonnanceur lit trois labels — odysseus.io/data-residency-country, odysseus.io/data-residency-region et odysseus.io/blocked-countries — et le bloc typé se compile exactement en ceux-ci. Mais les écrire vous-même est rejeté catégoriquement, car un label est du texte libre et rien ne vérifie sa valeur. Un label mal orthographié n’est pas une contrainte rejetée ; c’est une absence de contrainte, appliquée silencieusement. Le rejet vous renvoie vos propres valeurs sous la forme acceptée, de sorte que la correction est un copier-coller.

Le pays d’un nœud est un fait que le nœud lui-même rapporte. Chaque agent annonce odysseus.io/country et odysseus.io/geo-region à partir de sa propre configuration. Il n’existe aucune API permettant au plan de contrôle d’affirmer où se trouve une machine — cela ferait de la résidence une affirmation plutôt qu’une propriété de la machine.

Quand rien ne correspond, le déploiement reste en attente. Il n’est jamais placé ailleurs en solution de secours. Le refus de l’ordonnanceur nomme le pays que vous avez requis et le pays que le nœud a rapporté, de sorte qu’une incohérence est visible plutôt que déduite. Si rien n’est jamais étiqueté pour correspondre, consultez a deployment never leaves scheduling.

Ce qu’il n’applique pas : la sortie

Un déploiement placé au Canada peut toujours appeler un service n’importe où dans le monde.

Ceci est la phrase à retenir de cette page. La résidence contraint le placement et uniquement le placement. La plateforme n’inspecte, ne filtre, ne proxifie ni ne bloque le trafic réseau sortant d’un conteneur sur la base de la résidence que vous avez déclarée, et la déclaration de résidence ne crée aucune politique réseau de quelque nature que ce soit. Un conteneur s’exécutant sur un nœud canadien est libre d’ouvrir une connexion vers une API dans un autre pays, d’écrire dans une base de données dans un autre pays ou d’envoyer sa télémétrie partout où son image est configurée pour l’envoyer. Si cela a une incidence sur vos obligations, c’est votre image et votre conception réseau qui doivent en répondre, pas ce champ.

Quatre autres choses qu’elle ne fait pas, pour la même raison — elles relèvent de ce qu’un filtre de placement ne peut pas décider :

Elle ne déplace pas des données déjà présentes ailleurs. La résidence s’applique à partir du moment où un conteneur est placé ; elle ne dit rien des volumes, du stockage objet ou des bases de données qui résident en dehors du nœud.
Elle ne régit pas l’endroit où la plateforme conserve ses propres enregistrements. La spécification de déploiement, ses événements et sa piste d’audit sont détenus par le plan de contrôle, où qu’il s’exécute. La résidence contraint vos conteneurs, pas le magasin propre à la plateforme.
Elle ne contraint pas l’origine d’une image. L’image est extraite du registre que le déploiement indique.
Ce n’est pas une attestation. Un nœud signale son propre pays. La résidence est exactement aussi fiable que la configuration des machines que vous avez inscrites, et aucune recherche de géolocalisation n’est effectuée pour la contester.

Les régions sont déclarées par chaque plan de contrôle, pas par le produit

Une région est un regroupement de pays par un opérateur — un nom, une description et la liste des pays qu’elle couvre — déclaré dans la configuration propre du plan de contrôle sous scheduler.geo_awareness.regions. Il n’existe pas de liste fixe prédéfinie pour le produit, de sorte que les noms autorisés ici ne sont pas nécessairement autorisés sur un autre plan de contrôle.

Demandez à celui avec qui vous parlez : GET /api/v1/scheduler/regions retourne les régions qu’il déclare et, dans la même réponse, si l’application de la résidence est activée ou non. Une région est satisfaite par un nœud dont l’étiquette odysseus.io/geo-region la nomme, ou par un nœud dont le pays fait partie des pays de cette région.

Une contrainte qui ne peut être honorée est déclarée, pas cachée

Deux situations acceptent le déploiement et avertissent, au lieu de le refuser :

L’application est désactivée sur ce plan de contrôle. La contrainte est stockée et n’est pas appliquée ; la réponse l’indique et nomme le paramètre qui l’activerait. Un opérateur doit pouvoir déclarer une intention avant l’activation, ce n’est donc pas un refus.
Aucun nœud auquel le locataire peut accéder n’annonce un label correspondant. La réponse indique quelles valeurs de pays et de région les nœuds du locataire annoncent réellement — uniquement les valeurs, jamais quel nœud — de sorte que l’écart est visible immédiatement plutôt qu’après que le déploiement soit resté non placé. Un locataire doit pouvoir déclarer une résidence avant qu’un opérateur ne labellise les machines, ce qui est l’ordre dans lequel ces choses se produisent réellement.

Aucune des deux n’est silencieuse, et aucune n’est un succès discret. Le refus au moment du placement se produit toujours ; le déploiement attend simplement.

Limites à connaître avant de s’y fier

L’application est désactivée sauf si le plan de contrôle l’a activée. Le filtre géographique n’est ajouté au planificateur que lorsque scheduler.geo_awareness.enabled est vrai. Lorsqu’il est désactivé, une déclaration de résidence est stockée et ignorée — c’est pourquoi la réponse vous en informe.
Un pays bloqué n’est pas évalué lorsqu’une exigence de région a déjà été satisfaite. Le filtre répond d’abord à region et s’arrête là, donc associer region à blockedCountries ne crée pas d’exception pour cette région. Exprimez une exclusion avec country, ou en ne déclarant pas la région qui la contient.
La variante imposée par la plateforme n’est pas encore accessible. Le planificateur lit les labels …-country-enforced et …-region-enforced, par lesquels un opérateur de plateforme pourrait imposer une résidence qu’un locataire ne peut pas supprimer. Rien ne les définit aujourd’hui, et l’API destinée au locataire ne le peut pas.

Not this

Cette page ne répertorie pas les valeurs acceptées, les valeurs par défaut ou les codes de rejet pour chaque clé — ceux-ci sont générés dans la référence de déploiement et les rejets et altérations, afin qu’ils ne puissent pas diverger du code.

Ce n’est pas non plus une déclaration de conformité. Elle décrit une contrainte de placement et ses limites ; le fait que cette contrainte satisfait une obligation particulière est une question concernant l’obligation, et cette page ne répond pas délibérément à cette question.

Où le consulter

Les clés et leurs règles : manifeste de déploiement.
Comment le placement est décidé en général : placement et allocation.
Pourquoi une déclaration de résidence a été refusée, et quoi écrire à la place : rejets et altérations.
Un déploiement qui a été accepté mais jamais placé : un déploiement ne quitte jamais la planification.