Notez que nous devrions probablement aussi renommer service en lbservice ou autre pour les distinguer des autres types de services.

Dans ce cadre, je supprimerais les objets de service de l'apiserver principal et faciliterais l'utilisation d'autres équilibreurs de charge, tels que HAProxy et nginx.

Ce serait bien si la définition logique d'un service (la requête et/ou le nom global) pouvait être utilisée/spécialisée de plusieurs manières - en tant que simple équilibreur de charge installé via l'infrastructure, en tant qu'équilibreur de charge plus complet comme nginx ou haproxy également proposé par l'infrastructure, en tant que point de terminaison interrogeable sur lequel un intégrateur pourrait interroger/attendre (GET /services/foo -> { points de terminaison : [{host, port}, ...] }), ou en tant qu'informations disponibles pour les hôtes pour exposer les équilibreurs de charge locaux. Évidemment, il peut s'agir de plusieurs cas d'utilisation différents et, en tant que tels, divisés en leurs propres ressources, mais avoir une certaine flexibilité pour spécifier l'intention (unifier sous un lb) distincte du mécanisme permet de satisfaire plus facilement un large éventail de demandes.

@smarterclayton Je suis d'accord avec la séparation de la politique et du mécanisme.

Primitives dont nous avons besoin :

1. La possibilité d'interroger/regarder un ensemble identifié par un sélecteur d'étiquette. Je ne sais pas s'il y a encore un problème déposé.
2. La possibilité d'interroger les adresses IP des pods (#385).

Cela suffirait pour composer avec d'autres mécanismes de nommage/découverte et/ou des équilibreurs de charge. Nous pourrions ensuite créer une couche de niveau supérieur au-dessus du noyau qui regroupe des modèles communs avec une API simple.

Les deux primitives décrites par @ bgrant0607 valent-elles la peine de garder ce problème ouvert ? Ou y a-t-il des problèmes plus spécifiques que nous pouvons déposer ?

Je ne pense pas que zookeeper soit résolu - car vous avez besoin de l'identifiant unique dans chaque conteneur. Je pense que vous pouvez le faire avec 3 contrôleurs de réplication séparés (un par instance) ou un mode sur le contrôleur de réplication.

Je pense que la conception des services mérite une discussion, comme le note Brian. Actuellement, il couple une abstraction d'infrastructure (proxy local) avec un mécanisme d'exposition (variables d'environnement dans tous les conteneurs) avec une requête d'étiquette. Il existe un cas d'utilisation tout aussi valable pour un proxy de périphérie qui prend les hôtes/chemins L7 et les équilibre avec une requête d'étiquette, ainsi que la prise en charge de protocoles tels que http(s) et les sockets Web. De plus, les services ont aujourd'hui une limite d'échelle stricte de 60 000 backends, partagés sur l'ensemble du cluster (le nombre d'adresses IP allouées). Il devrait être possible d'exécuter un proxy local sur un minion qui n'utilise que les services dont les conteneurs sur cet hôte ont besoin, et également pour éviter que les conteneurs aient à connaître le port externe. Nous pouvons déplacer cette discussion au #494 si nécessaire.

Résoudre le problème des services singleton et des services non auto-scalés avec une réplication fixe, tels que des bases de données répliquées maître-esclave, des magasins de valeurs-clés avec des groupes de pairs de taille fixe (par exemple, etcd, zookeeper), etc.

Les cas de réplication fixe nécessitent un comportement de type tableau prévisible. Les pairs doivent pouvoir se découvrir et s'adresser individuellement. Ces services ont généralement leurs propres bibliothèques et/ou protocoles client, nous n'avons donc pas besoin de résoudre le problème de déterminer à quelle instance un client doit se connecter, autre que de rendre les instances adressables individuellement.

Proposition : nous devrions créer une nouvelle saveur de service, appelée services Cardinal, qui mappe N adresses IP au lieu d'une seule. Les services cardinaux effectueraient une affectation stable de ces adresses IP à N instances ciblées par leur sélecteur d'étiquette (c'est-à-dire un N spécifié, pas seulement le nombre de cibles existant). Une fois que nous avons DNS ( #1261, #146 ), il attribuerait des noms DNS prévisibles en fonction d'un préfixe fourni, avec les suffixes 0 à N-1. Les affectations pourraient être enregistrées dans des annotations ou des étiquettes des pods ciblés.

Cela préserverait le découplage de l'attribution des rôles des identités des pods et des contrôleurs de réplication, tout en fournissant des noms et des adresses IP stables, qui pourraient être utilisés dans les mécanismes de configuration d'application standard.

Une partie des discussions autour des différents types d'équilibrage de charge a eu lieu dans la conception des services v2 : #1107.

Je vais déposer une question distincte pour l'élection principale.

/cc @smarterclayton @thockin

Les affectations devraient se poursuivre dans les pods via un mécanisme de paramétrage de l'environnement (presque certainement).

Pour l'exemple etcd, je créerais :

• Cardinalité du contrôleur de réplication 1 : 1 pod, pointant vers le volume de stockage stable A
• Cardinalité du contrôleur de réplication 2 : 1 pod, pointant vers le volume de stockage stable B
• Cardinalité du contrôleur de réplication 3 : 1 pod, pointant vers le volume de stockage stable C
• service cardinal 'etcd' pointant vers les pods

Si le pod 2 meurt, le contrôleur de réplication 2 en crée une nouvelle copie et la rattache au volume B. Le service cardinal 'etcd' sait que ce pod est nouveau, mais comment sait-il qu'il doit être de cardinalité 2 (qui provient des données stockées sur le tome B) ?

Plutôt que 3 contrôleurs de réplication, pourquoi pas un contrôleur de sharding, qui
regarde une étiquette comme "kubernetes.io/ShardIndex" lors de la prise de décision. Si
vous voulez un sharding à 3 voies, cela fait 3 pods avec les indices 0, 1, 2. J'ai l'impression que
cela a déjà été abattu, mais je ne peux pas reconstituer les problèmes qu'il a causés dans
ma tête.

Il semble tout simplement erroné d'imposer ce fardeau aux utilisateurs s'il s'agit d'un
scénario commun.

Pensez-vous qu'il est important que l'adresse IP nominale d'un pod donné change en raison de
des changements sans rapport dans l'ensemble ? Par example:

au temps 0, les pods (A, B, C) constituent un service cardinal, avec des IP
10.0.0.{1-3} respectivement

à l'instant 1, le nœud qui héberge le pod B meurt

à l'instant 2, le contrôleur de réplication pilotant B crée un nouveau pod D

à l'instant 3, le service cardinal passe à (A, C, D) avec l'IP 10.0.0.{1-3}
respectivement

NB : l'« IP stable » du pod C est passée de 10.0.0.3 à 10.0.0.2 lorsque l'ensemble
l'adhésion a changé. Je m'attends à ce que cela fasse du mal à courir
Connexions.

Pour contourner cela, nous aurions besoin d'avoir les valeurs ordinales spécifiées
en dehors du service, ou autre chose d'intelligent. C'est peut-être bien, mais c'est
semble fragile et facile de se tromper si les gens doivent y faire face.

Le jeu. 2 octobre 2014 à 10h17, Clayton Coleman [email protected]
a écrit:

Les affectations devraient se poursuivre dans les pods via certains
mécanisme de paramétrage de l'environnement (presque certainement).

Pour l'exemple etcd, je créerais :

• Cardinalité du contrôleur de réplication 1 : 1 pod, pointant vers stable
  volume de stockage A
• Cardinalité du contrôleur de réplication 2 : 1 pod, pointant vers stable
  volume de stockage B
• cardinalité du contrôleur de réplication 3 : 1 pod, pointant vers stable
  volume de stockage C
• service cardinal 'etcd' pointant vers les pods

Si le pod 2 meurt, le contrôleur de réplication 2 en crée une nouvelle copie et
le rattache au volume B. Le service Cardinal 'etcd' sait que ce pod est
nouveau, mais comment sait-il qu'il doit être de cardinalité 2 (qui vient de
données stockées sur le volume B) ?

Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

Je pense qu'un contrôleur de partitionnement a du sens et est probablement plus utile dans le contexte d'un service cardinal.

Je pense que les changements d'IP basés sur l'appartenance sont effrayants et je peux penser à un tas de cas extrêmes dégénérés. Cependant, si la cardinalité est stockée avec les pods, la décision est moins difficile.

Tout d'abord, je n'avais pas l'intention de parler de sharding -- c'est #1064. Déplaçons les discussions de partitionnement là-bas. Nous avons vu de nombreux cas d'essayer d'utiliser un mécanisme analogue pour le sharding, et nous avons conclu que ce n'était pas la meilleure façon d'implémenter le sharding.

Deuxièmement, mon intention est qu'il ne soit pas nécessaire d'exécuter N contrôleurs de réplication. Il devrait être possible d'en utiliser un seul, bien que le nombre requis dépende des détails du déploiement (canaris, plusieurs pistes de publication, mises à jour continues, etc.).

Troisièmement, je conviens que nous devons examiner comment cela interagirait avec la proposition de données durables (#1515) -- @erictune .

Quatrièmement, je suis d'accord que nous devons probablement refléter l'identité dans le module. Conformément à #386, idéalement, un mécanisme standard serait utilisé pour rendre les attributions de noms IP et DNS visibles pour le pod. Comment les alias d'IP et d'hôte seraient-ils normalement affichés sous Linux ?

Cinquièmement, j'ai suggéré que nous garantissions la stabilité des affectations en enregistrant les affectations dans les pods via des étiquettes ou des annotations.

Sixièmement, le problème avec un "contrôleur de partitionnement" remplaçant le contrôleur de réplication est que je souhaite dissocier l'attribution des rôles de la gestion de l'image/de l'environnement. Je considère que le contrôleur de réplication fournit ce dernier (voir https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564).

Dans le cas de données durables, selon #1515 :

1. Pour les gousses durables, cette proposition fonctionnerait tout simplement. L'affectation serait stable pour le pod durable.
2. Pour des objets de données distincts, le service cardinal devrait également gérer l'attribution de rôle pour les objets de données et reporter l'attribution de rôle aux pods jusqu'à ce qu'ils soient mis en correspondance avec les données. Je pense que ce serait simple.

/cc @erictune

Je pense que vous essayiez de rendre la conversation plus facile à avoir, mais je ne suis pas sûr que cela ait fonctionné.

Re: sharding - "un ensemble de répliques avec une identité distincte" n'est-il pas fondamentalement du sharding ?

Re : 1 contrôleur de réplication - nous n'avons pas de contrôleur de réplication assignant des index aujourd'hui. Je ne pense pas qu'on veuille ça, n'est-ce pas ?

Re : dire au pod sa propre identité - le service est une couche propre sur le pod. Il serait compliqué d'informer un service d'un pod imminent afin qu'il puisse attribuer une adresse IP avant qu'elle n'existe. Je pense que l'ID doit faire partie du pod, par exemple une étiquette ShardIndex ou quelque chose. Nous pouvons refléter cela dans le pod (d'une manière ou d'une autre) et le service peut l'utiliser pour attribuer l'IP. Si nous laissons le service Cardinal le faire lui-même, le pod aura déjà été démarré au moment où il est attribué. Nous pourrions avoir des métadonnées par pod comme nous le faisons avec les machines virtuelles dans GCE, mais c'est une proposition plus vaste.

Non, fournir des identités stables et distinctes n'est ni nécessaire ni suffisant pour le sharding. Voir #1064 pour les détails, que je viens d'ajouter ici.

Non, nous ne voulons pas que le contrôleur de réplication attribue des index. J'ai intentionnellement proposé que les services Cardinal fassent cela à la place.

Oui, je m'attends à ce que les pods existent (et aient potentiellement commencé) avant de se voir attribuer des rôles (indices). C'était délibéré. Il doit également être possible de révoquer une affectation.

Approche d'identité possible : créez un alias IP non persistant dans le conteneur et fournissez une recherche DNS inversée dans l'implémentation DNS.

Cependant, je ne pense pas que l'identification de l'identité dans les conteneurs de pods soit essentielle pour de nombreux cas d'utilisation. Si l'application utilise l'auto-enregistrement, elle n'a probablement même pas besoin de ce mécanisme.

Si le gestionnaire de service est prêt à conserver un état en dehors de ce qu'il
fait actuellement, nous pouvons juste nous souvenir des mappages qui ont été précédemment effectués
et essayez de les respecter.

Le jeu. 2 octobre 2014 à 20 h 59, bgrant0607 [email protected] a écrit :

Approche d'identité possible : créez un alias IP non persistant dans le
conteneur et fournir une recherche DNS inversée dans l'implémentation DNS.

Cependant, je ne pense pas que plomber l'identité dans les conteneurs de dosettes soit
indispensable pour de nombreux cas d'utilisation. Si l'application utilise
auto-enregistrement, il n'a probablement même pas besoin de ce mécanisme.

Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

Ré. en me souvenant des mappages, je suis d'accord -- voir https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787.

Je ne sais pas en quoi cela est pertinent pour le commentaire auquel vous avez répondu, cependant.

GitHub et e-mail ne font pas bon ménage. Pardon

Le jeu. 2 octobre 2014 à 21h39, bgrant0607 [email protected] a écrit :

Ré. me souvenant des mappages, je suis d'accord -- voir #260 (commentaire)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

Je ne sais pas en quoi cela est pertinent pour le commentaire auquel vous avez répondu, cependant.

Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

Tim a suggéré "nominal", ce qui, je suis d'accord, convient mieux.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

J'aime aussi le nominatif. Je détesterai l'expliquer aux utilisateurs, mais il sera très souvent utilisé pour les choses créées par la configuration (c'est-à-dire qu'un jeu de réplicas mongodb nominal sera un contrôleur de réplication, un service nominal, des volumes, donc c'est déjà un peu complexe).

----- Message d'origine -----

Tim a suggéré "nominal", ce qui, je suis d'accord, convient mieux.

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

Deux problèmes que je vois :

1. L'attribution de rôle implique de définir au moins des variables d'environnement ou des paramètres de volume par pod (c'est-à-dire que le premier pod doit obtenir le volume a, et s'il est supprimé, son remplacement a besoin du même volume)
2. Si les pods d'un service nominal proviennent d'un seul contrôleur de remplacement, le modèle doit être modifié après la création mais avant que le pod ne soit lié.

Cela semble impliquer que l'attribution des rôles est un contrôleur qui se situe entre l'apiserver et le planificateur en tant qu'étape de workflow. Cela implique également une forme de transformation ou de remplacement du modèle, de sorte que le modèle sans l'attribution de rôle n'a pas nécessairement de sens.

Le contrôleur de partition semble être une variante de ce problème, juste pour une attribution de rôle plus compliquée.

Exemple d'exécution de zookeeper avec un service par instance : http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

Donc je sais que c'est un vieux fil, mais il touche un sujet qui m'est cher ;-)

À condition que le système puisse pousser les enregistrements avant + inverse pour les "services nominaux" non nat'd vers skydns et utiliser les noms comme injection ENV dans les pods qui utilisent ce service, y a-t-il d'autres limitations ?

Cela peut sembler un peu étrange dans le cas de ZK où chaque élément du quorum utiliserait les autres éléments, par exemple :
zk1 utilise : zk2, zk3
zk2 utilise : zk1, zk3
zk3 utilise : zk1, zk2

mais en théorie ça devrait marcher non ? Pourvu que nous puissions ajouter les enregistrements inverses pour les services nominaux.

@ bgrant0607 est -ce que je manque quelque chose ?

Cela devient légèrement plus étrange lorsque d'autres applications souhaitent utiliser le service global qu'elles fournissent. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc Ce que vous proposez fonctionnerait si zk1, zk2 et zk3 étaient des services, au moins une fois que les services multi-ports sont pris en charge.

Ouais, il y a un laid ici, cependant.

Un pod en cours d'exécution ne sait pas quels services le « devant ». Par exemple, un service
d'une instance backend, le VIP utilisé pour accéder au service n'est pas connu par
le backend (à moins qu'il ne recherche cette information en connaissant le service
Nom). Dans un service nominal (N), vous auriez N backends et N VIP (et
vraisemblablement des noms DNS N ou un nom d'adresse N), mais les backends seraient toujours
ne connaissent pas leurs propres VIP. Ils peuvent observer le pool de noms DNS, mais
ne sais pas (sans sonder) lequel est soi. Cela rendrait votre ZK
cas difficile d'utiliser les VIP (également les VIP sont visiblement proxy en ce moment).

Alternatives :

1) configurez 1 service (N) et demandez à chaque instance de sonder tous les VIP pour elle-même

2) configurer N instances de service (1) et utiliser des étiquettes et des indicateurs de ligne de commande pour
attribuer manuellement des index, faire connaître (a priori) à chaque backend ZK le nom DNS
l'un de l'autre ZK backend

3) Faire DNS pour les sélecteurs d'étiquettes, attribuer un nom DNS au jeu de répliques ZK,
espérons que les clients utilisent correctement DNS

4) Exécutez des ponts kube2zk à côté de chaque ZK qui synchronise les points de terminaison kubernetes ->
Configuration ZK

5) Concevoir une autre façon d'attribuer des VIP ou des indices qui est plus
replcation-controller-centric que service centric. Brendan et moi
réfléchi à quelques idées ici il y a quelque temps, mais je n'ai pas eu le temps de suivre
dessus.

Quant au DNS inversé, je ne suis pas sûr d'en voir le rôle ? Je ne suis pas contre
le soutenir (c'est-à-dire demander à @bketelsen de le soutenir :) mais je ne le pense pas
s'applique ici. Le trafic ne vient jamais "de" une IP de service.

Tim

Le samedi 7 mars 2015 à 20h56, Brian Grant [email protected]
a écrit:

@timothysc https://github.com/timothysc Ce que vous proposez fonctionnerait si
zk1, zk2 et zk3 étaient des services, au moins une fois que les services multi-ports sont
prise en charge.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) ressemble à cette proposition.

Je suis un grand fan de 5 - les pods sachant que leur rôle est la première étape, les pods ayant un identifiant DNS unique ou utilisant des points de terminaison pour obtenir l'adresse IP des autres et y réagir sont deux. Pouvoir rechercher l'adresse IP du pod dans les points de terminaison par un identifiant de rôle stable serait le troisième.

Le 8 mars 2015, à 11h06, Tim Hockin [email protected] a écrit :

Ouais, il y a un laid ici, cependant.

Un pod en cours d'exécution ne sait pas quels services le « devant ». Par exemple, un service
d'une instance backend, le VIP utilisé pour accéder au service n'est pas connu par
le backend (à moins qu'il ne recherche cette information en connaissant le service
Nom). Dans un service nominal (N), vous auriez N backends et N VIP (et
vraisemblablement des noms DNS N ou un nom d'adresse N), mais les backends seraient toujours
ne connaissent pas leurs propres VIP. Ils peuvent observer le pool de noms DNS, mais
ne sais pas (sans sonder) lequel est soi. Cela rendrait votre ZK
cas difficile d'utiliser les VIP (également les VIP sont visiblement proxy en ce moment).

Alternatives :

1) configurez 1 service (N) et demandez à chaque instance de sonder tous les VIP pour elle-même

2) configurer N instances de service (1) et utiliser des étiquettes et des indicateurs de ligne de commande pour
attribuer manuellement des index, faire connaître (a priori) à chaque backend ZK le nom DNS
l'un de l'autre ZK backend

3) Faire DNS pour les sélecteurs d'étiquettes, attribuer un nom DNS au jeu de répliques ZK,
espérons que les clients utilisent correctement DNS

4) Exécutez des ponts kube2zk à côté de chaque ZK qui synchronise les points de terminaison kubernetes ->
Configuration ZK

5) Concevoir une autre façon d'attribuer des VIP ou des indices qui est plus
replcation-controller-centric que service centric. Brendan et moi
réfléchi à quelques idées ici il y a quelque temps, mais je n'ai pas eu le temps de suivre
dessus.

Quant au DNS inversé, je ne suis pas sûr d'en voir le rôle ? Je ne suis pas contre
le soutenir (c'est-à-dire demander à @bketelsen de le soutenir :) mais je ne le pense pas
s'applique ici. Le trafic ne vient jamais "de" une IP de service.

Tim

Le samedi 7 mars 2015 à 20h56, Brian Grant [email protected]
a écrit:

@timothysc https://github.com/timothysc Ce que vous proposez fonctionnerait si
zk1, zk2 et zk3 étaient des services, au moins une fois que les services multi-ports sont
prise en charge.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je vais devoir prendre le temps de rédiger un peu plus cette idée, alors.

Le dimanche 8 mars 2015 à 10h25, Clayton Coleman [email protected]
a écrit:

Je suis un grand fan de 5 - les pods sachant que leur rôle est la première étape, les pods
avoir un identifiant DNS unique ou utiliser des points de terminaison pour obtenir d'autres adresses IP et
y réagir est deux. Pouvoir rechercher l'adresse IP du pod dans les points de terminaison par un
L'identifiant de rôle stable serait le troisième.

Le 8 mars 2015, à 11h06, Tim Hockin [email protected]
a écrit:

Ouais, il y a un laid ici, cependant.

Un pod en cours d'exécution ne sait pas quels services le « devant ». Par exemple, étant donné un
un service
d'une instance backend, le VIP utilisé pour accéder au service n'est pas connu
par
le backend (à moins qu'il ne recherche cette information en connaissant le service
Nom). Dans un service nominal (N), vous auriez N backends et N VIP
(et
vraisemblablement des noms DNS N ou un nom d'adresse N), mais les backends
toujours
ne connaissent pas leurs propres VIP. Ils peuvent observer le pool de noms DNS, mais
ne sais pas (sans sonder) lequel est soi. Cela rendrait votre ZK
cas difficile d'utiliser les VIP (également les VIP sont visiblement proxy en ce moment).

Alternatives :

1) configurez 1 service (N) et demandez à chaque instance de sonder tous les VIP pour elle-même

2) configurer N instances de service (1) et utiliser des étiquettes et des indicateurs de ligne de commande pour
attribuer manuellement des index, faire connaître (a priori) à chaque backend ZK le DNS
Nom
l'un de l'autre ZK backend

3) Faire DNS pour les sélecteurs d'étiquettes, attribuer un nom DNS au jeu de répliques ZK,
espérons que les clients utilisent correctement DNS

4) Exécutez des ponts kube2zk à côté de chaque ZK qui synchronise les points de terminaison kubernetes
->
Configuration ZK

5) Concevoir une autre façon d'attribuer des VIP ou des indices qui est plus
replcation-controller-centric que service centric. Brendan et moi
réfléchi à quelques idées ici il y a quelque temps, mais je n'ai pas eu le temps de
suivre
dessus.

Quant au DNS inversé, je ne suis pas sûr d'en voir le rôle ? Je ne suis pas contre
le soutenir (c'est-à-dire demander à @bketelsen de le soutenir :) mais je ne le pense pas
s'applique ici. Le trafic ne vient jamais "de" une IP de service.

Tim

Le samedi 7 mars 2015 à 20h56, Brian Grant [email protected]
a écrit:

@timothysc https://github.com/timothysc Ce que vous proposez fonctionnerait
si
zk1, zk2 et zk3 étaient des services, au moins une fois que les services multi-ports sont
prise en charge.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: DNS inversé,

ZK se brisera sans lui, comme beaucoup d'autres systèmes distribués.

RC qui a appliqué une étiquette unique (members=#) à chaque pod qu'il crée et essaie de créer une séquence jusqu'à N réplicas, puis un service headless qui a créé un nom A et CNAME pour chaque valeur de l'étiquette "member" (# .service.namespace.local), où la racine a servi tous ces service.namespace.local -> round robin -> 1.service.namespace.local, 2.service.namespace.local semble local.

Nous _pourrions_ utiliser des adresses IP de pod strictes pour ces étiquettes DNS individuelles. Créer de fausses IP pour chacun coûte cher et le conteneur ne pourra pas envoyer sa propre IP à quelqu'un.

----- Message d'origine -----

@thockin re: DNS inversé,
exigence.

ZK se brisera sans lui, comme beaucoup d'autres systèmes distribués.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re : DNS inversé - qu'est-ce que c'est le DNS inversé ? L'IP source de
Connexions? Rien de tout cela ne fonctionne dans kube. Les connexions via les services sont
proxy, donc source-ip ne fonctionne pas en premier lieu (pourrait être corrigé).

Je ne connais pas ZK - pouvez-vous expliquer ce qu'ils essaient d'obtenir en faisant marche arrière
DNS ? Cela semble être une hypothèse très fragile.

Le lundi 9 mars 2015 à 9h05, Timothy St. Clair [email protected]
a écrit:

@thockin https://github.com/thockin re: DNS inversé, faisons un signe de la main
nos mains et le considèrent comme une exigence.

ZK se brisera sans lui, comme beaucoup d'autres systèmes distribués.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

Je pense que mon expérience (et peut-être celle de Tim) est que la majorité des logiciels en cluster attendent aujourd'hui ce qui suit :

• chaque nœud a une identité stable
• cette identité est un nom DNS
• l'IP de l'identité sous-jacente n'a pas besoin d'être stable
• le nœud s'attend à s'identifier auprès des autres nœuds soit par son identité stable (DNS) soit par son IP publique
• certains logiciels en cluster s'attendent à ce que l'IP du nœud sur lequel un client l'atteigne corresponde à une IP qu'il peut annoncer aux autres dans le cluster et que cette IP soit accessible.

----- Message d'origine -----

@timothysc re : DNS inversé - qu'est-ce que c'est le DNS inversé ? L'IP source de
Connexions? Rien de tout cela ne fonctionne dans kube. Les connexions via les services sont
proxy, donc source-ip ne fonctionne pas en premier lieu (pourrait être corrigé).

Je ne connais pas ZK - pouvez-vous expliquer ce qu'ils essaient d'obtenir en faisant marche arrière
DNS ? Cela semble être une hypothèse très fragile.

Le lundi 9 mars 2015 à 9h05, Timothy St. Clair [email protected]
a écrit:

@thockin https://github.com/thockin re: DNS inversé, faisons un signe de la main
nos mains et le considèrent comme une exigence.

ZK se brisera sans lui, comme beaucoup d'autres systèmes distribués.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

Le lun 9 mars 2015 à 12:49, Clayton Coleman
[email protected] a écrit :

RC qui a appliqué une étiquette unique (members=#) à chaque pod qu'il crée et essaie de créer une séquence jusqu'à
N réplicas, puis un service sans tête qui a créé un nom A et CNAME pour chaque valeur de « membre »
étiquette (#.service.namespace.local), où la racine a servi tous ces service.namespace.local -> round
robin -> 1.service.namespace.local, 2.service.namespace.local semble local.

L'idée que Brendan et moi rebondissions était essentiellement une piscine
de jetons, peut-être une partie de RC, peut-être pas, que chaque élément d'un RC
serait attribué. Étant donné ce jeton, d'autres choses pourraient être attribuées

• VIP, PD, index génériques, etc. Ce qui est bien, c'est que lorsqu'un pod
  meurt, le jeton est remis dans le pool, et lorsque ce pod est remplacé
  ce jeton est réutilisé.

Le problème vient de trouver comment transformer un « jeton arbitraire » en
quelque chose de significatif.

Nous _pourrions_ utiliser des adresses IP de pod strictes pour ces étiquettes DNS individuelles. Créer de fausses IP pour chacun coûte cher et le conteneur ne pourra pas envoyer sa propre IP à quelqu'un.

Je n'ai pas essayé, mais je parie que nous pourrions faire en sorte que les services nominaux fassent du SNAT complet
et DNAT puisqu'ils sont 1:1. Ce serait un moyen de se stabiliser
IP par pod sans IP migrables.

----- Message d'origine -----

@thockin re: DNS inversé,
exigence.

ZK se brisera sans lui, comme beaucoup d'autres systèmes distribués.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Loin de moi l'idée de nager en amont - si suffisamment d'applications s'attendent vraiment à ce que DNS
fonctionner de cette façon, nous pouvons le faire fonctionner de cette façon.

Esquisser:

La création d'un contrôleur de réplication R crée un nom DNS "$R.rc" qui est le
pool d'adresses IP de pod qui sont "sous" ce RC. Chaque pod P obtient un nom DNS
"$P.$R.rc". MAIS qu'est-ce que P ? Il pourrait s'agir d'indices simples, mais cela a
nous a mordu durement à l'intérieur. Il peut s'agir de chaînes aléatoires telles que GenerateName,
mais ils doivent survivre à la mort/au redémarrage du pod (et peut-être que les noms d'hôte des pods devraient
correspondre?).

Le mar 10 mars 2015 à 7h59, Clayton Coleman [email protected]
a écrit:

Je pense que mon expérience (et peut-être celle de Tim) est que la majorité des
le logiciel attend aujourd'hui ce qui suit :

• chaque nœud a une identité stable
• cette identité est un nom DNS
• l'IP de l'identité sous-jacente n'a pas besoin d'être stable
• le nœud s'attend à s'identifier aux autres nœuds soit par sa stabilité
  identité (DNS) ou son IP publique
• certains logiciels en cluster attendent l'adresse IP du nœud d'un client
  l'atteint pour correspondre à une IP, il peut s'annoncer à d'autres dans le
  cluster et pour que cette IP soit accessible.

----- Message d'origine -----

@timothysc re : DNS inversé - qu'est-ce que c'est le DNS inversé ? L'IP source de
Connexions? Rien de tout cela ne fonctionne dans kube. Les connexions via les services sont
proxy, donc source-ip ne fonctionne pas en premier lieu (pourrait être corrigé).

Je ne connais pas ZK - pouvez-vous expliquer ce qu'ils essaient d'obtenir en faisant marche arrière
DNS ? Cela semble être une hypothèse très fragile.

Le lun 9 mars 2015 à 9 h 05, Timothy St. Clair <
[email protected]>
a écrit:

@thockin https://github.com/thockin re: DNS inversé, faisons un signe de la main
nos mains et le considèrent comme une exigence.

ZK se brisera sans lui, comme beaucoup d'autres systèmes distribués.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

J'aime bien que le DNS soit attaché à des services nominaux plutôt qu'à RC.

Quel était le problème avec des indices simples en interne ? P > 5000 ?

----- Message d'origine -----

Loin de moi l'idée de nager en amont - si suffisamment d'applications s'attendent vraiment à ce que DNS
fonctionner de cette façon, nous pouvons le faire fonctionner de cette façon.

Esquisser:

La création d'un contrôleur de réplication R crée un nom DNS "$R.rc" qui est le
pool d'adresses IP de pod qui sont "sous" ce RC. Chaque pod P obtient un nom DNS
"$P.$R.rc". MAIS qu'est-ce que P ? Il pourrait s'agir d'indices simples, mais cela a
nous a mordu durement à l'intérieur. Il peut s'agir de chaînes aléatoires telles que GenerateName,
mais ils doivent survivre à la mort/au redémarrage du pod (et peut-être que les noms d'hôte des pods devraient
correspondre?).

Le mar 10 mars 2015 à 7h59, Clayton Coleman [email protected]
a écrit:

Je pense que mon expérience (et peut-être celle de Tim) est que la majorité des
le logiciel attend aujourd'hui ce qui suit :

• chaque nœud a une identité stable
• cette identité est un nom DNS
• l'IP de l'identité sous-jacente n'a pas besoin d'être stable
• le nœud s'attend à s'identifier aux autres nœuds soit par sa stabilité
  identité (DNS) ou son IP publique
• certains logiciels en cluster attendent l'adresse IP du nœud d'un client
  l'atteint pour correspondre à une IP, il peut s'annoncer à d'autres dans le
  cluster et pour que cette IP soit accessible.

----- Message d'origine -----

@timothysc re : DNS inversé - qu'est-ce que c'est le DNS inversé ? L'IP source de
Connexions? Rien de tout cela ne fonctionne dans kube. Les connexions via les services sont
proxy, donc source-ip ne fonctionne pas en premier lieu (pourrait être corrigé).

Je ne connais pas ZK - pouvez-vous expliquer ce qu'ils essaient d'obtenir en faisant marche arrière
DNS ? Cela semble être une hypothèse très fragile.

Le lun 9 mars 2015 à 9 h 05, Timothy St. Clair <
[email protected]>
a écrit:

@thockin https://github.com/thockin re: DNS inversé, faisons un signe de la main
nos mains et le considèrent comme une exigence.

ZK se brisera sans lui, comme beaucoup d'autres systèmes distribués.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 aux VIP 1:1 à boîtier spécial. Je pense que ça va être un cas courant.

Je m'inquiète toujours de la modification dynamique des mappages DNS. Je préférerais une approche qui n'exige pas cela.

Une chose à garder à l'esprit lors de l'évaluation des alternatives est que je suis certain à 100% que nous aurons finalement besoin de 2 modules avec le même rôle pour coexister en même temps, l'ancien et le nouveau. Par conséquent, le rôle ne peut pas être lié au nom de l'objet ni à quelque chose d'autre qui doit à la fois être unique et doit être gravé dans le marbre au moment de la création du pod.

Si nous lions le mécanisme d'attribution de rôle au contrôleur de réplication, cela exclut à peu près les mises à jour continues, les canaris, etc. J'aimerais éviter cela si possible.

@smarterclayton Les indices simples ne posent pas de problème en raison de l'échelle. C'est dû au modèle. Voir mes commentaires d'il y a quelques minutes. Les indices simples sont la voie à suivre s'ils peuvent être attribués dynamiquement indépendamment de l'identité du pod et du RC.

Étant donné que l'un des problèmes réside dans les hypothèses orientées système, Linux pourrait-il faire quelque chose pour nous ici ? Par exemple, pourrions-nous créer un alias IP ou autre dans le conteneur pour le service VIP ?

Salut les gars,

Je suis dehors toute cette semaine. C'est une conversation vraiment amusante, mais elle nécessite
plus de temps que je n'en ai sous la main. Je serais heureux de m'asseoir et de discuter en vrai
fois la semaine prochaine.

Le mar 10 mars 2015 à 15h56, Brian Grant [email protected]
a écrit:

Étant donné que l'un des problèmes réside dans les hypothèses axées sur le système, y a-t-il
quelque chose que Linux pourrait faire pour nous ici ? Par exemple, pourrions-nous créer une IP
alias ou autre dans le conteneur du service VIP ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

Je n'ai plus de poche les deux prochains jours - la semaine prochaine c'est.

Le 10 mars 2015, à 23h33, Tim Hockin [email protected] a écrit :

Salut les gars,

Je suis dehors toute cette semaine. C'est une conversation vraiment amusante, mais elle nécessite
plus de temps que je n'en ai sous la main. Je serais heureux de m'asseoir et de discuter en vrai
fois la semaine prochaine.

Le mar 10 mars 2015 à 15h56, Brian Grant [email protected]
a écrit:

Étant donné que l'un des problèmes réside dans les hypothèses axées sur le système, y a-t-il
quelque chose que Linux pourrait faire pour nous ici ? Par exemple, pourrions-nous créer une IP
alias ou autre dans le conteneur du service VIP ?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

+1 pour la semaine prochaine, peut-être un lieu de rencontre.

Relancer ce fil en raison de l'apparition de sujets connexes (https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, #6393).

1. Comment attribuer des identités réseau (noms DNS et/ou adresses IP) à des pods individuels, qui peuvent être des singletons ou faire partie d'un ensemble nominal ?
2. Comment transmettre l'identité aux conteneurs d'un pod ?

Devrions-nous planifier un Hangout ou utiliser un Hangout communautaire hebdomadaire ?

Aussi https://github.com/openshift/mongodb/pull/14 que nous commençons à prototyper ce que serait un modèle générique pour l'initialisation de l'ensemble de membres (quelque chose que nous pouvons mettre dans un conteneur, ou une bibliothèque, ou...)

@danmcp @mfojtik

----- Message d'origine -----

Repiquer ce fil en raison de l'apparition de sujets connexes
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902,
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147,

6393).

1. Comment attribuer des identités réseau (noms DNS et/ou adresses IP) à
   gousses individuelles, qui peuvent être des singletons ou faire partie d'un ensemble nominal ?
2. Comment transmettre l'identité aux conteneurs d'un pod ?

Devrions-nous planifier un Hangout ou utiliser un Hangout communautaire hebdomadaire ?

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-91041442

IIUC, une pièce de ce puzzle est l'élection principale #1542.

Oui, nous en avons discuté. Pour la plupart des clusters qui peuvent faire leur propre élection, l'appartenance est la plus importante (détecter l'appartenance à partir des points de terminaison Kube, appliquer au cluster), mais il existe toujours différentes manières de l'aborder. Par exemple, Cassandra utilise essentiellement Kube comme source externe de vérité pour l'adhésion, c'est donc le SEP et cela facilite l'élection des dirigeants. Bien que je pense que selon le décalage des membres, vous pourriez vous retrouver avec une partition si l'adhésion s'effondre.

Pour mongo, vous souhaitez contacter chacun des membres et les faire rejoindre un cluster existant ou former un nouveau cluster. Si plusieurs clusters existent, vous ne voulez pas les aggraver.

Notez que le problème de la communication d'une IP de service à un conteneur est similaire à la communication d'une IP externe à une VM : https://cloud.google.com/compute/docs/networking. GCE traduit les adresses externes vers/depuis les adresses internes, et les adresses externes sont communiquées via le serveur de métadonnées : http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS est similaire : http://169.254.169.254/latest/meta-data/public-ipv4 .

@smarterclayton J'ai mis à jour le prototype de PR de mongo : https://github.com/openshift/mongodb/pull/17

il utilise maintenant un pod one shot qui initialise le réplicaSet

Ré. lier ce mécanisme au contrôleur de réplication/shard :

Essayer des noms DNS sur des contrôleurs de réplication et/ou sur des noms d'objets pod force un modèle de mise à jour sur place. Un type complètement différent de mise à jour progressive "sur place" devrait être implémenté, tout en prenant en charge plusieurs modèles simultanément avec un seul contrôleur. Cela signifierait également que pour effectuer certains types de mises à jour (y compris le déplacement vers de nouveaux hôtes), les pods devraient être supprimés puis recréés avec les mêmes noms, ce qui augmenterait les temps d'arrêt par rapport à l'approche où nous ajoutons un nouveau cosse avant d'en emporter une ancienne.

L'idée du pool de jetons sonne bien. Je pense juste qu'il doit être découplé des RC.

Cela pourrait être couplé à un contrôleur de niveau supérieur, si nous devions en ajouter un. Commentera plus loin sur #1743 et/ou #503.

Cela ne devrait pas vraiment être couplé au DeploymentController proposé dans #1743. Cela ne fonctionnerait pas pour le scénario de plusieurs pistes de publication indépendantes, ni dans le cas où quelqu'un voudrait contrôler leurs déploiements avec un mécanisme différent, tel que la mise à jour progressive proposée par échange de noms. Pour des raisons similaires, je ne lierais pas les noms DNS aux noms d'objets pod/RC/DC.

Nous revenons donc à une sorte de service, ou à un contrôleur entièrement séparé. Peut-être que le contrôleur de points de terminaison pourrait attribuer des indices aux points de terminaison de service ? Endpoints lui-même est-il un endroit suffisamment fiable pour enregistrer ces données ? S'il était perdu, tous les pods seraient réindexés.

Pour faciliter la communication de l'identité jusqu'aux conteneurs du pod (comme via env. var. substitution discutée dans #2316), il serait utile de définir un champ sur le pod lorsque le rôle a été attribué/non attribué, via une sous-ressource. Cela pourrait également résoudre le problème de la durabilité.

Nous devrions réserver de l'espace dans le schéma DNS pour les instances nominales -- #6666.

Je pourrais acheter que nous pourrions essayer d'utiliser des adresses IP de pod et simplement remapper DNS pour les instances nominales, par https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406.

De plus, j'ai supprimé cela du jalon 1.0 en février (mais pas roadmap.md), mais la discussion dans #6393 suggère qu'il peut être rajouté.

Suggéré par @thockin : la recherche inversée à l'aide de DNS (enregistrements PTR) semble être un moyen raisonnable de passer des adresses IP de pod aux noms DNS nominaux :
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Oui, cela rendrait "qui suis-je" vraiment facile via des outils de nom standard.

Le 10 avril 2015 à 20h11, Brian Grant [email protected] a écrit :

Suggéré par @thockin : la recherche inversée à l'aide de DNS (enregistrements PTR) semble être un moyen raisonnable de passer des adresses IP de pod aux noms DNS nominaux :
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

/s'abonner

Je ne suis plus sûr de comprendre les exigences ici.

Il existe une relation N-à-M inhérente entre les services et les pods, par le
conception du système. Des choses comme le DNS inversé s'attendent généralement à obtenir un
réponse unique : étant donné l'adresse IP d'un pod, obtenez un nom canonique. Chaque doc écrit
à propos de DNS dit "ne retournez pas plusieurs enregistrements inversés". Puisqu'un pod peut être
dans N services, cette réponse unique ne peut pas vraiment être liée au service. Nous
pourrait faire une recherche inversée sur un nom canonique, puis une recherche TXT sur ce nom
nom pour "quels services êtes-vous sous", mais c'est difficile à maintenir et c'est
essentiellement un protocole personnalisé de toute façon.

La raison pour laquelle j'ai pensé attacher quelque chose de nominal aux RC est que c'est un
relation plus concrète. Mais ce n'est même pas. Un pod peut être créé par
un CR, orphelin, adopté par un autre CR, et détruit par cela. Ou
détruit manuellement

Je ne suis donc pas sûr de ce que nous voulons faire avec cela, à moins de limiter le nombre
de services qu'un pod peut être "sous", ce qui semble affreux.

Quelles sont les exigences comportementales ? Que voulons-nous atteindre. Nous
peut fournir une sémantique simple avec des services DNS et sans tête. Est-ce
suffisant? Si non, pourquoi ?

Nous pourrions aller à l'extrême et configurer des règles iptables pour les pods SNAT/DNAT dans un
service pour qu'ils se voient tous sur des VIP. Par exemple, étant donné un ensemble de dosettes
(P1, P2, P3) ils obtiendraient des VIP (V1, V2, V3). Le trafic de P1 à V2 serait
semblent provenir de V1, etc. Les clients accéderaient à V{1,2,3}. Mais quoi
problème est-ce que cela résout, vraiment? Cela donne des IP stables mais n'est-ce pas un
problème général pour les services sans tête partout?

Le mar 21 avril 2015 à 14:17, David Oppenheimer < [email protected]

a écrit:

/s'abonner

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

L'objectif était très concret. Les systèmes en cluster réels ont des membres qui ont une "identité" qui devrait être continue en présence de défaillances de nœuds. Cette identité peut être attachée à un disque persistant ou à un "nom", mais le nom qui l'identifie aux autres systèmes ne peut pas changer.

Exemple, zookeeper a une identité par nœud. Cette identité doit rester stable dans l'appartenance au cluster - il pourrait y avoir deux pods qui pensent qu'ils sont host1, mais si host1 disparaît, host435 ne peut pas le remplacer. Il peut y avoir un disque persistant réutilisé pour ce pod qui se déplace d'un endroit à un autre, mais quand c'est le cas, le pod doit être capable de définir cette identité. Mais nous avons besoin d'un moyen d'attribuer ce #.

Je soupçonne que la façon dont je pense aux services nominaux consiste toujours à activer les logiciels existants avec de petits (3/5/7) membres, et non le cas d'utilisation de plusieurs centaines totalement flexible. Peut-être devrions-nous séparer ce cas d'utilisation de cette discussion.

Le 22 avril 2015, à 01h59, Tim Hockin [email protected] a écrit :

Je ne suis plus sûr de comprendre les exigences ici.

Il existe une relation N-à-M inhérente entre les services et les pods, par le
conception du système. Des choses comme le DNS inversé s'attendent généralement à obtenir un
réponse unique : étant donné l'adresse IP d'un pod, obtenez un nom canonique. Chaque doc écrit
à propos de DNS dit "ne retournez pas plusieurs enregistrements inversés". Puisqu'un pod peut être
dans N services, cette réponse unique ne peut pas vraiment être liée au service. Nous
pourrait faire une recherche inversée sur un nom canonique, puis une recherche TXT sur ce nom
nom pour "quels services êtes-vous sous", mais c'est difficile à maintenir et c'est
essentiellement un protocole personnalisé de toute façon.

La raison pour laquelle j'ai pensé attacher quelque chose de nominal aux RC est que c'est un
relation plus concrète. Mais ce n'est même pas. Un pod peut être créé par
un CR, orphelin, adopté par un autre CR, et détruit par cela. Ou
détruit manuellement

Je ne suis donc pas sûr de ce que nous voulons faire avec cela, à moins de limiter le nombre
de services qu'un pod peut être "sous", ce qui semble affreux.

Quelles sont les exigences comportementales ? Que voulons-nous atteindre. Nous
peut fournir une sémantique simple avec des services DNS et sans tête. Est-ce
suffisant? Si non, pourquoi ?

Nous pourrions aller à l'extrême et configurer des règles iptables pour les pods SNAT/DNAT dans un
service pour qu'ils se voient tous sur des VIP. Par exemple, étant donné un ensemble de dosettes
(P1, P2, P3) ils obtiendraient des VIP (V1, V2, V3). Le trafic de P1 à V2 serait
semblent provenir de V1, etc. Les clients accéderaient à V{1,2,3}. Mais quoi
problème est-ce que cela résout, vraiment? Cela donne des IP stables mais n'est-ce pas un
problème général pour les services sans tête partout?

Le mar 21 avril 2015 à 14:17, David Oppenheimer < [email protected]

a écrit:

/s'abonner

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Certains types de contrôleurs peuvent activer/désactiver dynamiquement certains champs sur les pods. Il ne peut tout simplement pas être confondu avec l'identité du pod ou du RC. Lier l'identité du réseau aux identités du pod ou du RC est totalement rompu.

Je n'essaierais pas de faire fonctionner la recherche DNS inversée pour les services ordinaires ou sans tête, et je ne pense pas qu'il soit déraisonnable d'imposer un maximum d'un service nominal par pod - ce qui ne doit pas du tout limiter les autres types de services .

Il existe un certain nombre de limitations DNS que nous voudrons appliquer à long terme (invalidation du cache, prise en charge des interrogations longues, etc.). Plusieurs enregistrements PTR ne sont peut-être qu'un autre élément ajouté à cette liste.

L'autre alternative est que nous pouvons donner une IP de service à chaque pod du service nominal et ensuite résoudre les problèmes que cela crée.

----- Message d'origine -----

Certains types de contrôleurs peuvent activer/désactiver dynamiquement certains champs sur les pods. Ce
ne peut tout simplement pas être confondu avec le pod ni l'identité RC. Lier l'identité du réseau
aux identités pod ou RC est totalement cassé.

Je n'essaierais pas de faire fonctionner la recherche DNS inversée pour les personnes ordinaires ou sans tête
services, et je ne pense pas qu'il soit déraisonnable d'imposer un maximum d'un nominal
service par pod - ce qui n'a pas à limiter d'autres types de services à
tout.

Il y a un certain nombre de limitations DNS que nous voudrons repousser à long terme
(invalidation de cache, prise en charge d'interrogations longues, etc.). Plusieurs enregistrements PTR
est peut-être juste un autre élément ajouté à cette liste.

L'autre alternative est que nous pouvons donner une IP de service à chaque pod du
service nominal et ensuite résoudre les problèmes que cela crée.

Beaucoup de ces services s'attendent à ce que l'IP qu'ils ont (leur nom) se résolve en l'IP sur laquelle ils se connectent - donc s'ils se connectent à X sur 172.1.1.1, alors X pense que c'est 172.1.1.1. Ce n'est pas tous les logiciels, mais certains d'entre eux. Il s'agit généralement d'un nom DNS, ce qui signifie que l'IP peut changer en dessous.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

J'ai bien peur que tout cela soit encore un peu abstrait pour moi.

Les systèmes en cluster réels ont des membres qui ont une « identité » qui est
devrait être continue en présence de défaillances de nœuds. Cette identité
peut être attaché à un disque persistant ou à un "nom", mais le nom
identifier à d'autres systèmes ne peut pas changer.

Ce n'est pas une exigence. C'est tellement vague qu'il est impossible à mettre en œuvre.

Exemple, zookeeper a une identité par nœud. Cette identité doit rester
stable dans l'appartenance au cluster

Qu'est-ce qu'une identité ? Une adresse IP ? Un indicateur de chaîne passé au logiciel ?
et env var? Comment un processus zk apprend-il quelle est sa propre identité ?

Certains types de contrôleurs peuvent définir/désactiver dynamiquement certains champs sur les pods

Ce qui déclenchera le redémarrage de ces pods, et ne répond toujours pas au
question de quels champs, quelles valeurs, et quelle logique dire au pod ?

Je pouvais voir quelque chose comme développer des annotations dans des drapeaux de ligne de commande
(comme nous en discutons avec env vars) ou simplement dans env vars. Par exemple
le contrôleur écrit des annotations["zookeeper.com/index"] = 9, nous convertissons
$.metatdata["zookeeper.com/index"] dans ZK_INDEX env. Mais je fais ça
vers le haut, je n'ai vu aucune demande concrète qui dit ce qu'exactement le gardien de zoo (ou
quoi que ce soit) besoin.

Je ne pense pas qu'il soit déraisonnable d'imposer un maximum d'un service nominal
par dosette

Je pense qu'il sera difficile de mettre en œuvre de telles restrictions. Le système est tellement
faiblement couplé et asynchrone qu'imposer ces limites pourrait être pire que
simplement résoudre les problèmes.

on peut donner une IP de service à chaque pod du service nominal

C'est par là que nous avons commencé, mais...

Beaucoup de ces services s'attendent à ce que l'IP qu'ils ont (leur nom)
se résout à l'adresse IP sur laquelle ils se connectent - donc s'ils se connectent à X sur 172.1.1.1,
alors X pense que c'est 172.1.1.

Les IP de service ne satisfont pas à cela, à moins que nous ne fassions quelque chose de plus approfondi comme
J'ai mentionné avec SNAT/DNAT. Et même cela a de réels défauts.

Je n'essaye pas d'être une douleur dans le cou, c'est juste que nous avons très peu
temps dans la course à 1.0, et il n'y a rien ici qui est assez clair pour
même preuve de concept, encore moins mettre en œuvre correctement.

J'essaie de déterminer exactement ce que nous voulons vivre afin que je puisse voir
ce que nous pouvons mettre en œuvre. Compte tenu des références répétées au DNS, je retiens
hors de la refonte DNS jusqu'à ce que je sache ce qui se passe ici.

Le mer. 22 avril 2015 à 10h12, Clayton Coleman [email protected]
a écrit:

----- Message d'origine -----

Certains types de contrôleurs peuvent activer/désactiver dynamiquement certains champs sur
gousses. Ce
ne peut tout simplement pas être confondu avec le pod ni l'identité RC. Attacher le réseau
identité
aux identités pod ou RC est totalement cassé.

Je n'essaierais pas de faire fonctionner la recherche DNS inversée pour les personnes ordinaires ou sans tête
services, et je ne pense pas qu'il soit déraisonnable d'imposer un maximum d'un
nominal
service par pod - ce qui n'a pas à limiter d'autres types de services à
tout.

Il y a un certain nombre de limitations DNS que nous voudrons repousser à long terme
Cours
(invalidation de cache, prise en charge d'interrogations longues, etc.). RPT multiples
enregistrements
est peut-être juste un autre élément ajouté à cette liste.

L'autre alternative est que nous pouvons donner une IP de service à chaque pod du
service nominal et ensuite résoudre les problèmes que cela crée.

Beaucoup de ces services s'attendent à ce que l'adresse IP qu'ils ont (leur nom) soit résolue
à l'adresse IP sur laquelle ils se connectent - donc s'ils se connectent à X sur 172.1.1.1, alors X
pense que son 172.1.1.1. Ce n'est pas tous les logiciels, mais certains d'entre eux. D'habitude c'est
un nom DNS cependant, ce qui signifie que l'IP peut changer en dessous.

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :

https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

La plupart des exemples multi-ports sont des systèmes en cluster. Par example:
ZK : nom d'hôte ou adresse IP résolvable dans un fichier de configuration, plus un "id" (c'est-à-dire un index : 1, 2, 3, ...) dans un fichier

Nous devrions également parcourir certaines bases de données.

Quoi que nous fassions, cela ne fonctionnera pas pour tout. Nous devons juste trouver le bon endroit.

----- Message d'origine -----

J'ai bien peur que tout cela soit encore un peu abstrait pour moi.

Les systèmes en cluster réels ont des membres qui ont une « identité » qui est
devrait être continue en présence de défaillances de nœuds. Cette identité
peut être attaché à un disque persistant ou à un "nom", mais le nom
identifier à d'autres systèmes ne peut pas changer.

Ce n'est pas une exigence. C'est tellement vague qu'il est impossible à mettre en œuvre.

Exemple, zookeeper a une identité par nœud. Cette identité doit rester
stable dans l'appartenance au cluster

Qu'est-ce qu'une identité ? Une adresse IP ? Un indicateur de chaîne passé au logiciel ?
et env var? Comment un processus zk apprend-il quelle est sa propre identité ?

Certains types de contrôleurs peuvent définir/désactiver dynamiquement certains champs sur les pods

Ce qui déclenchera le redémarrage de ces pods, et ne répond toujours pas au
question de quels champs, quelles valeurs, et quelle logique dire au pod ?

Je pouvais voir quelque chose comme développer des annotations dans des drapeaux de ligne de commande
(comme nous en discutons avec env vars) ou simplement dans env vars. Par exemple
le contrôleur écrit des annotations["zookeeper.com/index"] = 9, nous convertissons
$.metatdata["zookeeper.com/index"] dans ZK_INDEX env. Mais je fais ça
vers le haut, je n'ai vu aucune demande concrète qui dit ce qu'exactement le gardien de zoo (ou
quoi que ce soit) besoin.

Je ne pense pas qu'il soit déraisonnable d'imposer un maximum d'un service nominal
par dosette

Je pense qu'il sera difficile de mettre en œuvre de telles restrictions. Le système est tellement
faiblement couplé et asynchrone qu'imposer ces limites pourrait être pire que
simplement résoudre les problèmes.

on peut donner une IP de service à chaque pod du service nominal

C'est par là que nous avons commencé, mais...

Beaucoup de ces services s'attendent à ce que l'IP qu'ils ont (leur nom)
se résout à l'adresse IP sur laquelle ils se connectent - donc s'ils se connectent à X sur 172.1.1.1,
alors X pense que c'est 172.1.1.

Les IP de service ne satisfont pas à cela, à moins que nous ne fassions quelque chose de plus approfondi comme
J'ai mentionné avec SNAT/DNAT. Et même cela a de réels défauts.

Je n'essaye pas d'être une douleur dans le cou, c'est juste que nous avons très peu
temps dans la course à 1.0, et il n'y a rien ici qui est assez clair pour
même preuve de concept, encore moins mettre en œuvre correctement.

J'essaie de déterminer exactement ce que nous voulons vivre afin que je puisse voir
ce que nous pouvons mettre en œuvre. Compte tenu des références répétées au DNS, je retiens
hors de la refonte DNS jusqu'à ce que je sache ce qui se passe ici.

Je pense que c'est sage, nous devrions spécifiquement consacrer du temps à résoudre un ensemble d'exemples connus. Nous en avons 3 de notre côté que nous pouvons exploiter pour des exemples concrets (jeu de répliques MongoDB, Zookeeper, Mysql Master/Slave) ainsi que les exemples existants dans kube/examples. Peut-être une session de travail pour trier les éléments, fixer des limites aux problèmes insolubles, identifier ce qui reste.

Suggérez de modifier le nom de cette fonctionnalité, car elle peut également être utilisée pour les tâches par lots pour attribuer un numéro d'identification de partition.

Les travaux par lots ont des exigences quelque peu différentes, j'aimerais donc garder cela séparé.

Exemple de gardien de zoo : https://github.com/openshift/origin/pull/1965

Exemple de service nominal dont ish a besoin https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

Je ne comprends pas pourquoi la direction n'est toujours pas claire ici, en particulier de la part des Googleurs. Google exécute des services avec état sous Borg depuis de nombreuses années, et ce qui est requis pour ce type de charge de travail est assez clair :

• Un identifiant stable pour lequel l'un des ensembles de "shards" (répliques non identiques) représente le pod actuel (en borg, il s'agit du "numéro de tâche" - un entier simple). Cet identifiant doit rester constant lors des replanifications/redémarrages des pods.
• Un moyen d'énumérer et de contacter tous les fragments "pairs", probablement en utilisant leurs identifiants stables d'une manière ou d'une autre (dans borg, il s'agit d'un préfixe potelé avec le numéro de tâche)

.. et nous avons terminé.

Remarque : si l'exclusion de ressources est critique pour chaque partition, les applications devront effectuer leur propre verrouillage distribué car il est toujours possible que les durées de vie des pods se chevauchent lors des échecs/redémarrages (peut-être en utilisant un verrou etcd basé sur l'identifiant de la partition). Une extension de fonctionnalité exotique potentielle consiste à autoriser plus d'une réplique identique dans chaque partition, pour la redondance/la charge.

Cela peut être falsifié dès maintenant en créant un service/port unique pour chaque fragment et en exécutant un contrôleur de réplication avec des répliques : 1, mais il est un peu maladroit de gérer un grand nombre de fragments "à la main" comme celui-ci.

Un moyen naturel d'implémenter cela dans kubernetes pourrait être :

• Les pods reçoivent des variables d'environnement supplémentaires donnant leur propre index de partition (entier) et le nombre total de partitions (ou peut-être le communiquent via l'API descendante ?).
• Les ReplicationControllers obtiennent un nombre de « shards » (par défaut : 1), et « replicas » est réinterprété pour signifier « répliques dans chaque shard » (par défaut : 1). Lors de la réduction de l'ensemble des réplicas, ils doivent tuer à partir de la fin (pour garder les indices de partition contigus). Notez que la modification des « shards » nécessitera un redémarrage progressif des pods contrôlés pour mettre à jour leur var env « shards totaux » (bon, vous ne voulez pas que cela se produise instantanément).
• Les services obtiennent un nombre de "shards" similaire qui mappe une plage contiguë de ports au sélecteur régulier plus un sélecteur "shard index" implicite.
• Les pods peuvent trouver d'autres fragments en utilisant SERVICE_PORT (ou une nouvelle variable d'environnement ?) + le décalage d'index de fragment.

Notez que ce qui précède se dégrade gracieusement vers le comportement actuel lorsque shards=1.

Je suis généralement d'accord avec cela (et comme vous le dites, cela a fait ses preuves dans Borg), bien que je déconseille d'opter pour "l'extension de fonctionnalité exotique" de plusieurs répliques par fragment (bien que nous ayons probablement besoin de quelque chose comme ça sous le couvertures pour la migration).

Comme je l'ai mentionné plus tôt, cela est étroitement lié à ce que nous devons faire pour prendre en charge les tâches par lots avec une affectation de travail statique (ce que j'appelais "type 1" ici : https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142 )

Les autres fonctionnalités que nous devons aligner si nous modifions RC (ou ajoutions quelque chose de nouveau) sont la manière dont le déploiement s'intègre, en particulier :

Comment effectuer une mise à jour progressive pour :

1. Un RC régulier
2. Un PerNodeController
3. Un RC fragmenté
4. Un travail par lots ?

Nous pourrions souhaiter soit suspendre la mise en œuvre du déploiement jusqu'à ce que nous ayons un homme de paille pour chacun d'entre eux, car je pense qu'un déploiement qui ne fonctionne que contre un simple RC pose certains problèmes.

----- Message d'origine -----

Je suis généralement d'accord avec cela (et comme vous le dites, cela a résisté à l'épreuve du temps
en Borg), bien que je déconseille d'opter pour la "fonction exotique
extension" de plusieurs répliques par partition (bien que nous ayons probablement besoin de quelque chose
comme ça sous les couvertures pour la migration).

Comme je l'ai mentionné plus tôt, cela est étroitement lié à ce que nous devons faire pour
prend en charge les travaux par lots avec affectation de travail statique (ce que j'appelais "type 1"
ici:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

Nous avons choisi de ne pas prioriser cela (et les revendications de volume persistant générées automatiquement) pour la version 1.0, car il existe plusieurs solutions de contournement, telles que la création d'un service, d'une RC et d'une revendication de volume persistant par instance.

Bien que les index de tâches densément affectés de manière statique dans Borg soient très largement utilisés, nous avons appris qu'ils présentent un certain nombre de lacunes et ont passé du temps au cours des dernières années à développer des alternatives. Bon nombre des problèmes proviennent du fait que les indices sont couplés au cycle de vie et à l'identité des tâches elles-mêmes. Cela rend difficile la mise en œuvre d'un certain nombre de stratégies de déploiement, de migration, de gestion dynamique des tâches et de nombreux autres scénarios. Une autre complexité provient de la génération statique de la configuration par index pour chaque pré-déploiement de tâche - cela équivaut à générer un RC par valeur d'index. Ce serait simple à faire pour quelqu'un s'il le voulait vraiment. Des étiquettes pourraient encore être utilisées pour démolir l'ensemble.

Contrôleur par nœud/démon : bon point. Les indices densément attribués sont un mauvais modèle pour ce cas. Que faites-vous lorsqu'un nœud disparaît définitivement, par exemple ? Les indices se raréfient. Je recommande que nous ne soutenions pas cela.

Tâches par lots : comme indiqué dans #1624, nous voudrions attribuer des indices en fonction des achèvements, et non des pods en cours d'exécution.

Comme indiqué ci-dessus, l'attribution d'index doit prendre en compte le stockage associé, tel que les revendications de volume persistant - l'identité découle de l'identité du réseau (nom DNS et/ou adresse IP) et du stockage.

L'affectation ne peut pas être pilotée par un seul contrôleur de réplication. Cela ne fonctionne tout simplement pas. Les contrôleurs de réplication ne sont pas des entités durables, et nous nous attendons à ce qu'il y ait plusieurs RC par service, pour les canaris, les mises à jour progressives, plusieurs pistes de publication, plusieurs clusters, etc. Même l'objet de déploiement proposé (#1743) n'a pas la bonne portée .

Il y a 3 alternatives pour l'affectation :

1. Associez l'affectation à un type particulier de service. Le service a exactement la bonne portée. (Nous aurons également éventuellement besoin de services régionaux.) Ce serait une sorte d'hybride entre les services réguliers et les services sans tête. C'est ce que j'envisageais lorsque j'ai initialement proposé ce mécanisme. L'affectation serait enregistrée dans Endpoints. Les points de terminaison et/ou le DNS sans tête seraient les moyens évidents d'énumérer tous les pairs.
2. Créez un nouveau type d'objet similaire à Service, mais uniquement pour les services nominaux. Nous aurions probablement besoin d'un nouvel objet pour enregistrer l'affectation également. Cela élargirait inutilement notre surface API, IMO.
3. "Tirer" au lieu de "pousser". Les pods sont programmés sur des hôtes sans contrôleur explicite, même avec des contraintes de nœud (sélecteur) ou l'un des mécanismes d'anti-affinité proposés (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529). Ceci est également similaire à l'affectation VIP de service. Nous pourrions faire quelque chose de similaire pour les services nominaux. Un pod (ou modèle de pod) spécifierait le pool d'index à partir duquel il souhaite qu'un index soit affecté. Contrairement aux services généraux, nous ne nous attendons pas à ce que les pods aient besoin de se voir attribuer plusieurs index provenant de différents pools. L'affectation serait enregistrée dans la spécification du pod.
4. Avantages : Plus simple pour les utilisateurs. Ne nécessite pas d'autre objet. Permet l'attribution par les utilisateurs.
5. Inconvénients : Différent des autres types de services.

L'affectation PVC utiliserait idéalement le même modèle.

Il convient également de considérer comment la migration de pod #3949 serait orchestrée. Le pod de remplacement DOIT être créé avant de supprimer le pod en cours de remplacement afin de transférer l'état du conteneur. Cela pourrait rendre le modèle de traction un peu problématique. Quoi qu'il en soit, le mécanisme d'allocation devrait être adapté à la migration.

Autres considérations:

1. Comment communiquer l'index/l'identité aux pairs. DNS est la réponse évidente.
2. Comment communiquer l'index/l'identité aux conteneurs du pod. Variables d'environnement, DNS inversé, ... L'index attribué ne changera pas de manière dynamique, bien que la liaison DNS puisse être modifiée tant que le pod existe toujours. J'aimerais choisir un mécanisme que les applications s'attendent déjà à ce qu'il fonctionne dans d'autres environnements, et comme pour la discussion plus large de l'API vers le bas (#386), je ne veux pas coupler les applications à des variables d'environnement spécifiques à Kubernetes, mais au nouveau EnvVarSource et la substitution env var (#7936) aiderait à éviter cela.

Je ne suis pas d'accord avec ce que vous avez dit, mais attendons de continuer cette discussion après la 1.0.

Relancer ce vieux fil pour poser une question. Existe-t-il un intérêt pour une politique de nommage du contrôleur de réplication ? Nommage spécifiquement nominal comme indiqué ci-dessus, où tous les pods contrôlés par ce contrôleur de réplication auraient des suffixes numérotés, quelque chose comme 0001, 0002 ....

Un exemple de cas d'utilisation est un équilibreur de charge nginx pointant vers ces ensembles de pods par noms de domaine. Ainsi, au fur et à mesure que les pods vont et viennent, les noms de domaine devraient toujours être fixes de xxx-0001 à xxx-000N.

@ravigadde Veuillez lire mon dernier commentaire sur ce problème : https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

J'ai rencontré ce problème en essayant de configurer un conteneur RabbitMQ. La persistance de Rabbit dépend du nom d'hôte, donc avoir des noms d'hôte variables signifie que vous perdez la base de données Mnesia au redémarrage du conteneur.

J'ai essayé d'y remédier avec la configuration de l'image (nom d'hôte directement et Rabbit), les variables ENV et l'API Downward. Je n'ai pas pu en obtenir pour résoudre le problème - Rabbit récupère toujours le nom du pod généré. Résoudre temporairement en passant de l'utilisation d'un contrôleur de réplication selon la suggestion de

Si je comprends bien, le pod rabbitmq (créé avec un contrôleur de réplication) dans l'exemple celerey-rabbit perdra des données en cas de défaillance du pod, même si les données sont stockées sur un disque persistant. De la doc de rabbitmq :

RabbitMQ nomme le répertoire de la base de données en utilisant le nom d'hôte actuel du système. Si le nom d'hôte change, une nouvelle base de données vide est créée. Pour éviter la perte de données, il est essentiel de configurer un nom d'hôte fixe et résolvable.

Il n'y a pas de bonne solution pour cela maintenant, mais vous pouvez créer un pod (non lié à un rc) avec un disque persistant migrable, la mise en garde étant que le pod devra être replanifié manuellement dans certains cas d'échec. C'est la seule façon à laquelle je peux penser pour que le nom d'hôte reste statique.

Ou au démarrage, créez un lien symbolique du nom d'hôte vers un emplacement stable

Le 11 juillet 2015, à 17h26, Mike Danese [email protected] a écrit :

Si j'ai bien compris, le pod rabbitmq (créé avec une réplication
contrôleur) dans le clerey-rabbit
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
exemple perdra des données en cas d'échec du pod même si les données sont stockées sur un
disque persistant. De la doc de rabbitmq :

RabbitMQ nomme le répertoire de la base de données en utilisant le nom d'hôte actuel du
système. Si le nom d'hôte change, une nouvelle base de données vide est créée. Éviter
perte de données, il est crucial de configurer un nom d'hôte fixe et résolvable.

Il n'y a pas de bonne solution pour cela maintenant, mais vous pouvez créer un pod (pas
lié à un rc) avec un disque persistant migrable, la mise en garde étant le pod
devra être reprogrammé manuellement dans certains cas d'échec. C'est le
seul moyen auquel je peux penser pour que le nom d'hôte reste statique.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-120662490
.

C'est un exemple de la raison pour laquelle le nom d'hôte ne doit pas être dérivé du nom du pod -- #4825

Pour donner un petit coup de pouce à cela :

Plusieurs problèmes fondamentaux doivent être résolus :

1. Certains composants doivent avoir une identité unique par pod liée à leur stockage sur disque
   
   
   
   1. Autre problème, certains d'entre eux (zookeeper dans certains cas) ont besoin que le nom d'hôte soit résoluble et corresponde
   
   
2. Certains composants évolutifs doivent avoir un stockage persistant différent par pod (les pods pointent vers des PVC qui diffèrent par pod, liés à l'identité)
   
   
   
   1. Parfois, ces volumes doivent être créés à la demande à l'échelle
   
   
   2. Parfois, ces volumes doivent être réutilisés à partir d'un pool et non recréés
   
   
3. Certains composants peuvent évoluer jusqu'à des dizaines de milliers d'instances, où le suivi des identités allouées individuelles devient impossible
   
   
   
   1. La majorité des utilisations pour le nominal se situeront probablement entre 2 et 7 instances d'un pod (les bases de données évolutives les plus actuelles, la plupart des configurations multi-maîtres fragmentées)
   
   
4. Certains composants aimeraient ne pas avoir à implémenter leur propre élection de maître, mais laisser la plate-forme gérer cela en rendant l'une des identités arbitraire (l'identité 1 devient le maître)
5. Lorsque nous résoudrons ces problèmes, les utilisateurs devront toujours apporter des modifications aux pods (via des déploiements) et s'assurer que toute identité est conservée ou réaffectée.

Ceux-ci ne doivent pas nécessairement tous être résolus dans la même solution. Par exemple, je pense qu'il existe une différence significative entre l'identité de cluster de petite taille (2-7) et l'identité de cluster à grande échelle (>7). Par exemple, dans le grand cas, ce logiciel est moins concerné par les lacunes ou dispose d'un protocole de consensus / d'adhésion existant. Dans le petit cas, le logiciel a besoin de plus d'aide pour établir l'identité. Je les séparerais en logiciels natifs du cloud (>7) et en clusters existants (2-7).

Je suis d'accord avec 1a, 1b et 2a. 2b ressemble à un problème différent, bien que la solution puisse peut-être réutiliser le même modèle.

Je pense que l'échelle (3) suggère principalement que notre solution de contournement d'un service et d'un RC par instance n'est pas adéquate, bien que je sois d'accord avec la distinction entre cloud natif et non.

L'élection principale (4) peut être adressée séparément.

Aussi d'accord avec (5).

Je pense que la plupart des exigences de conception sont claires à ce stade.

Questions de conception restantes :

I. Allouer des VIP ou permettre aux IP de changer ? Cela est étroitement lié à la question de savoir si les conteneurs doivent pouvoir découvrir leurs propres adresses IP via Linux ou non, car les VIP ne sont actuellement pas détectables via le système. Je suppose qu'ils doivent pouvoir découvrir leurs adresses IP, mais pourraient utiliser l'API descendante, comme avec l'adresse IP du pod (#12595). Permettre aux IP de changer (en raison de l'utilisation d'IP de pod) implique une limite du taux de changement d'IP, en raison des TTL DNS et des "bugs" de mise en cache. À un moment donné, nous avons également l'intention de rendre les IP des pods migrables (#3949), donc changer les IP ne serait pas éternel.

II. Pousser (vers les cosses) vs tirer (depuis les cosses). Les services et les RC sont intentionnellement faiblement couplés aux pods et utilisent donc tous les deux le modèle « push ». Les services nominaux seraient plus intrinsèquement liés à l'identité du pod (mais pas de façon permanente - les pods doivent être remplaçables). Par conséquent, je vois moins de motivation pour le modèle push. D'autres cas d'allocation, tels que l'ordonnancement, et esp. la liaison exclusive, telle que les revendications de volume persistant sur des volumes persistants, utilise un modèle de demande/accusé de réception, alias « pull ». C'est actuellement le modèle que je privilégie pour les services nominaux.

Quelqu'un a-t-il des opinions sur (I)?

L'élection principale est n° 1542 et est en cours de discussion dans le cadre de la mise en œuvre de la haute disponibilité (par exemple, n° 12884).

Je ne sais pas ce que vous entendez par pousser et tirer.

J'ai relu la majeure partie de ce numéro et je suis convaincu qu'il n'y a pas un seul
Solution. Nous allons avoir besoin d'une famille de fonctionnalités pour construire un pont vers
ce genre d'applications.

Je commence par l'axiome qu'une fois qu'un pod est en marche, vous ne pouvez pas vraiment
changer un pod en cours d'exécution. Il y a quelques exceptions à cela (par ex.
contenu du système de fichiers) mais les choses qui semblent importantes (env vars, IP,
hostname) vous restez coincé avec tout ce avec quoi vous commencez.

Je commence également par l'affirmation selon laquelle le couplage lâche entre
Le service et le pod restent, ce qui fait de cette chose dont nous parlons pas vraiment un
Un service. Les pods ne savent pas vraiment à quels services ils sont confrontés. Si nous changeons
ça, ce n'est plus un Service.

Je vais juste faire un courant de conscience et voir ce qui ne pue pas.

Idée 1 : ThingPools et patchs.

Définissez un nouvel objet API ou quelque chose qui vous permet de définir un pool de
des choses. Qu'est-ce qu'une chose ? Une chose est une chaîne (ou peut-être un blob JSON) qui
a un type énuméré. Vous pouvez créer un pool de Choses et de ces Choses
sont à vous d'utiliser. Les types d'objets incluent les VUID (noms d'hôte), les chaînes, les VIP.

Définissez une nouvelle construction d'API qui peut être transmise pour créer des opérations - un
pièce. Un correctif contient des instructions sur la façon de corriger l'objet qui est
établi. L'une des options de correctif est « allouer à partir d'un ThingPool ».

Pour les assembler :

Définissez un ThingPool { meatadata.name : my-quorum-hostnames, tapez : VUID,
autogenerate : 5, } // crée un pool de 5 VUID valides

Définir un RC { répliques : 5 ...}

Dans la création du RC (POST), envoyez également un patch : { quoi :
"podTemplate.spec.containers[*].metadata.VUID", pool : "my-quorum-hostnames"
}

L'opération POST appliquerait le correctif au RC - en allouant un VUID
par conteneur du ThingPool. Chaque fois qu'un pod est tué et recréé,
le VUID est renvoyé au pool et le prochain pod à démarrer l'obtiendra.

Vous pouvez l'utiliser pour générer un pool de chaînes ("0" à "99") et coller
ceux dans une var env. Vous pouvez l'utiliser pour allouer un pool de VIP et
puis attribuez ces VIP aux pods (ce serait une nouvelle fonctionnalité - pod durable
IPs - je ne sais pas comment cela va évoluer :) Vous pouvez générer un pool de
PersistentVolumeClaim nomme et corrige le volume de réclamation utilisé par chaque pod.

Cette idée est imparfaite à bien des égards, mais je pense qu'elle capture le mieux le
idée d'un ensemble de pods sans carrément définir un ensemble de pods.

Idée 2 : Définir un ensemble de pods. Ne prétendez pas que c'est un service. C'est plus proche
à un travail Borg. C'est comme un RC mais il assigne l'ordinalité aux pods qu'il
contrôles - numéros de partition. Il contrôle le pool de VUID (mais nous ne voulons pas
que le nom d'hôte soit quelque chose que les utilisateurs peuvent définir, hmmm...).

Je pensais avoir plus d'idées, mais je n'en ai pas. Je lutte avec des abstractions
et implémentations - il est inutile de définir une abstraction que nous ne pouvons pas
mettre en œuvre. Les VIP pour les nominaux sonnent bien, mais je pense que cela poussera le
limites d'iptables. Fournir un ensemble de noms d'hôtes stables pour un ensemble de pods
semble être la chose la plus importante, avec un ensemble de rangement pour un ensemble de
gousses chaudes sur sa queue.

Le mar. 18 août 2015 à 19:28, Brian Grant [email protected]
a écrit:

Je suis d'accord avec 1a, 1b et 2a. 2b semble être un problème différent, cependant
peut-être que la solution peut réutiliser le même modèle.

Je pense que l'échelle (3) suggère principalement que notre solution de contournement d'un service et
RC par instance n'est pas adéquat, bien que je sois d'accord avec la distinction entre
Cloud natif vs non.

L'élection principale (4) peut être adressée séparément.

Aussi d'accord avec (5).

Je pense que la plupart des exigences de conception sont claires à ce stade.

Questions de conception restantes :

I. Allouer des VIP ou permettre aux IP de changer ? Étroitement lié à cela est de savoir si
les conteneurs doivent pouvoir découvrir leurs propres IP via Linux ou non,
puisque les VIP ne sont actuellement pas détectables via le système. je suppose qu'ils le font
doivent être en mesure de découvrir leurs adresses IP, mais pourraient utiliser l'API descendante, car
avec IP du pod (#12595 https://github.com/kubernetes/kubernetes/pull/12595).
Permettre aux IP de changer (en raison de l'utilisation d'IP de pod) implique une limite au taux
de changement de l'IP, en raison de DNS TTL et de "bugs" de mise en cache. À un moment donné, nous
J'ai également l'intention de rendre les IP des pods migrables (#3949
https://github.com/kubernetes/kubernetes/issues/3949), donc en changeant les IP
ne serait pas pour toujours.

II. Pousser (vers les cosses) vs tirer (depuis les cosses). Les services et les RC sont
intentionnellement faiblement couplés aux gousses, et donc les deux utilisent le "push"
maquette. Les services nominaux seraient plus intrinsèquement liés à l'identité du pod
(mais pas de façon permanente - les gousses doivent être remplaçables). Par conséquent, je vois
moins de motivation pour le modèle push. D'autres cas d'attribution, tels que
planification, et esp. liaison exclusive, telle que le volume persistant prétend à
volumes persistants, utilisez un modèle de demande/accusé de réception, alias « pull ». C'est actuellement
le modèle que je privilégie pour les services nominaux.

Quelqu'un a-t-il des opinions sur (I)?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-132423385
.

Je ne voulais probablement pas vraiment dire l'élection principale comme vous y pensez - plus que
lors de la création de fonctionnalités où un ensemble d'instances doit être initialisé
(sans coordonner explicitement) n'ayant que l'instance qui pense que c'est
"1" parler à d'autres pods est généralement suffisant pour amorcer un cluster. Une
l'exemple est mongodb où vous devez lancer le jeu de réplicas - si les pods
qui pensent qu'ils sont initiés "2" ou "3", vous pouvez obtenir dans les cas où vous
initier une scission. Mais "1" peut s'initier en toute sécurité à chaque fois, puis
essayez d'ajouter les autres membres (qui ont un état persistant qu'ils peuvent utiliser pour
déterminer s'ils font déjà partie d'un cluster). En fonction de la
garanties fournies par le service d'identité, vous ne pouvez pas réellement obtenir un
cluster réussi, mais vous n'avez pas besoin de créer un pod séparé à l'extérieur pour
initialisez votre service (même si ce n'est pas terrible non plus).

Le mar. 18 août 2015 à 23:59, Brian Grant [email protected]
a écrit:

L'élection principale est #1542
https://github.com/kubernetes/kubernetes/issues/1542 , et est en cours
discuté dans le cadre de la mise en œuvre de la haute disponibilité (par exemple, #12884
https://github.com/kubernetes/kubernetes/pull/12884).

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-132439272
.

Clayton Coleman | Ingénieur en chef, OpenShift

@smarterclayton C'est un aparté au problème des services nominaux, mais il n'est pas sûr de démarrer comme vous le décrivez. Si "1" est redémarré sur une nouvelle machine et s'avère incapable d'atteindre les nœuds existants, il redémarrera et vous aurez maintenant deux mongodb prétendant faire autorité. Vous devez modifier la définition du travail pour supprimer la possibilité d'amorcer une fois l'amorçage terminé.

Comme @thockin pourrait y faire allusion, je pense que nous

Je vois deux cas d'utilisation assez différents décrits ci-dessus - différant par la source de vérité :

_Prescriptif :_ "Je veux que N fragments fonctionnent, et s'il y en a plus ou moins que cela, alors apportez des modifications pour le ramener à N."
_Descriptif :_ "Je veux juste découvrir automatiquement tous les fragments disponibles, et me laisser découvrir d'une manière ou d'une autre au fur et à mesure qu'ils vont et viennent."

Je pense que ceux-ci sont différents et devraient être décrits différemment (bien qu'ils puissent présenter des métadonnées similaires aux pods en cours d'exécution).

La discussion a également intégré la clôture des ressources et les garanties d'accès unique. Afaics, le _seulement_ cas où cela doit être fait dans k8s est le montage de volumes persistants distants (car le montage fs doit être fait en dehors du conteneur), et c'est assez facile à faire via les verrous etcd si le service de volume distant sous-jacent ne le fait pas. t déjà fournir des clôtures en interne. Tous les autres cas peuvent être traités par les travaux des utilisateurs eux-mêmes, en utilisant un service de verrouillage distribué (ou en accédant à des services qui assurent le verrouillage en interne). Demander aux travaux de faire leur propre verrouillage ouvre toutes sortes de schémas (affectation fixe, affectation opportuniste, "réserves à chaud", etc.)

Je suggère de déplacer la demande de fonctionnalité de clôture de ressources générales hors de ce bogue (et nous implémentons la clôture simplement en fournissant une recette pour exécuter divers services de verrouillage distribués sur k8s sans autre implication de k8s lui-même).

Juste un rappel : il y a _beaucoup_ de ports derrière un seul VIP. Je suis d'accord que nous ne voulons pas migrer les adresses IP car cela semble difficile sur le réseau sous-jacent à grande échelle, et difficile pour le réseau de traiter les doublons temporaires lors des cas extrêmes d'échec/récupération. Cependant, je pense qu'il est tout à fait faisable d'attribuer un port de service unique à chaque membre de partition et des données de proxy à chaque instance de pod, même pour les très gros travaux. (Cette suggestion suppose que les proxys sont toujours la direction que nous voulons prendre avec les k8 - je n'ai pas suivi les discussions récentes dans ce domaine)

Par push, je voulais dire qu'une autre ressource, comme un service ou un contrôleur, surveillerait des ensembles de pods via un sélecteur d'étiquettes et leur attribuerait des "choses" (noms DNS résolvables, VIP, PVC).

Par pull, je voulais dire que le pod demanderait explicitement l'allocation d'une "chose", qui lui serait ensuite liée via quelque chose comme /binding.

Concernant la modification des pods en cours d'exécution : la modification d'un pod après sa création est différente de la modification d'un pod avec des conteneurs en cours d'exécution. Le planificateur exécute async. initialisation, par exemple. PodIP est également attribué tardivement. Discuté plus généralement dans #3585.

Quant à savoir s'il s'agit vraiment d'un « service » ou non :

• Les choses doivent être réparties entre des ensembles de pods
• La chose (par exemple, les noms DNS) ne doit pas être intrinsèquement liée au nom de la ressource d'un pod
• Une chose doit être transférable d'un pod à un autre
• Le pod doit « savoir » (ou être capable de découvrir via une API descendante) à quelle chose (en particulier le nom DNS et le VIP) il a été attribué.
• Une chose que nous devons prendre en charge est le DNS résolvable
• Ma seule question en suspens était de savoir si nous avions besoin de VIP. Je suis d'accord pour ne pas utiliser de VIP.
• Ce n'est pas idéal, mais l'utilisateur pourrait créer un deuxième service sans tête ciblant l'ensemble pour la découverte des pairs via DNS et/ou Endpoints.

Idée (1), ThingPools + Patches est une idée intéressante. Je la décrirais comme une approche « tirer ». ThingPool n'est pas mauvais, mais je crains que les correctifs soient difficiles à utiliser, et je ne voudrais pas procéder à une ingénierie inverse des informations sémantiques des correctifs à l'intérieur du système pour fournir un comportement acceptable autour du cycle de vie du stockage, etc. Je préfère quelque chose de plus spécifique au domaine. De plus, les ThingPools indépendants pour les noms DNS et les PVC ne fonctionneraient pas, car ils doivent être co-alloués.

Je décrirais l'idée (2) comme une approche « poussée ». Je ne veux pas dupliquer le travail sur les RC et les déploiements, nous ne devrions donc pas introduire un autre contrôleur de pod. Un assignateur conviendrait, mais il est couplé de manière plus lâche que nécessaire et ne correspond pas au précédent sur la façon dont nous gérons l'assignation.

Ré. bourrer des informations dans env vars : cela est également arrivé pour Job. Je souhaite fourrer les informations dans une annotation et étendre l'API vers le bas pour pouvoir demander des annotations spécifiques. Je souhaite continuer à permettre aux utilisateurs de ne demander que les informations dont ils ont besoin et de choisir les noms des variables d'environnement.

Ré. attribuer différents ports à chaque instance : cela ne fonctionnerait pas pour de nombreuses applications héritées et n'est pas non plus compatible avec la conception de notre système.

Ré. prescriptif : Garder N en cours d'exécution est ce que fait ReplicationController.

Ré. descriptif : ce sont des services sans tête, qui existent déjà.

Ré. verrouillage : Oui, c'est l'API de bail qui est en cours.

L'approvisionnement du stockage est discuté dans #6773 (push) et #12450 (pull).

C'est trop tard maintenant, mais je vais essayer de prendre le temps de faire une proposition après un peu de sommeil.

Remarque rapide : les services sans tête n'attribuent pas de VIP

Nous pourrions dissocier l'allocation/affectation de la publication DNS. Ignorant comment l'allocation/l'affectation se déroule pour le moment, nous pourrions avoir une saveur particulière de service sans tête qui prendrait les noms de certains champs sur les pods représentant le nom d'hôte.

Et les problèmes de stockage local durable sont pertinents : #7562, #1515, #598

Des mises à jour plus rapides comme je fais principalement d'autres critiques de relations publiques :

L'un des avantages de l'utilisation d'un service est que nous n'aurions pas besoin de garantir que les noms d'hôte demandés pour les pods étaient globalement uniques, car le service délimiterait les noms publiés dans DNS.

Ré. allocation/affectation : je veux éviter d'ajouter plus de types de modèles à ReplicationController, Deployment, Daemon, etc., et je veux que le stockage et les noms puissent migrer entre les contrôleurs aussi facilement qu'entre les pods (si c'est ce que l'utilisateur veut).

Le 19 août 2015, à 1 h 04, Angus Lees [email protected] a écrit :

@smarterclayton https://github.com/smarterclayton C'est un aparté au
problème de services nominaux, mais il n'est pas sûr de démarrer car vous êtes
décrivant. Si "1" est redémarré sur une nouvelle machine et s'avère incapable
pour atteindre les nœuds existants, alors il va redémarrer et maintenant vous avez deux
mongodb prétend faire autorité. Vous devez changer de travail
définition pour supprimer la possibilité d'amorçage après l'amorçage est
Achevée.

Il est tout à fait possible que vous ayez un chevauchement dans ce cas - mais dans la plupart
cas, nous parlons de stockage persistant avec des verrous afin que vous puissiez bloquer
de toute façon jusqu'à ce que gce/AWS libère votre clôture et que vous puissiez l'attacher. Alors
vous sacrifiez la disponibilité au démarrage mais pas nécessairement au moment de l'exécution
(sauf si vous êtes sur un stockage non clôturé, auquel cas je suis d'accord que ce ne serait pas
en sécurité)

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-132448150
.

Le 19 août 2015, à 1 h 35, Angus Lees [email protected] a écrit :

Comme @thockin https://github.com/thockin pourrait faire allusion, je pense
nous confondons inutilement plusieurs caractéristiques similaires mais différentes ici

• et nous incluons plus que ce qui est strictement nécessaire au niveau k8s.

Je vois deux cas d'utilisation assez différents décrits ci-dessus - différant selon la source
de la verité:

_Prescriptif :_ "Je veux que N shards fonctionnent, et s'il y a plus ou moins
que cela, puis apportez des modifications pour le ramener à N."
_Descriptif :_ "Je veux juste découvrir automatiquement tous les fragments disponibles, et
laissez-moi découvrir d'une manière ou d'une autre au fur et à mesure qu'ils vont et viennent."

Je pense qu'elles sont différentes et devraient être décrites différemment (bien que

ils peuvent présenter des métadonnées similaires aux pods en cours d'exécution).

La discussion a également intégré la clôture des ressources et l'accès unique
garanties. Afaics, le _seulement_ cas où cela doit être fait dans k8s
(afaics) monte des volumes distants - car le montage fs doit être fait
à l'extérieur du conteneur. Tous les autres cas peuvent être traités par les jobs utilisateurs
eux-mêmes, en utilisant un service de verrouillage distribué (ou en accédant à des services qui
prévoir un verrouillage interne). Demander aux travaux de faire leur propre verrouillage ouvre
toutes sortes de modèles (affectation fixe, affectation opportuniste, « hot
pièces de rechange", etc) et les stratégies d'inaccessibilité/récupération (échec matériel,
continuer avec le dernier connu, etc.).

Je suggère de déplacer la demande de fonctionnalité de clôture de ressources générale hors de cette
bug (et nous implémentons l'escrime simplement en fournissant une recette pour exécuter
divers services de verrouillage distribués sur k8 sans autre implication de
k8s lui-même).

Je ne pense pas qu'on puisse découpler l'objectif d'exécuter certains types de
sortie de logiciel - la conception dit des services nominaux mais les cas d'utilisation que nous sommes
décrire, c'est réutiliser l'identité et le disque. Je suis d'accord, l'escrime est une propriété de
volumes - mais en liant l'acquisition d'un volume à une certaine propriété de
l'instance de pod ne l'est pas.

Juste un rappel : il y a _beaucoup_ de ports derrière un seul VIP. je suis d'accord nous
je ne veux pas migrer les IP car cela semble difficile sur le réseau sous-jacent
à grande échelle et difficile pour le réseau de gérer les doublons temporaires
pendant les cas limites d'échec/récupération. Cependant, je pense que c'est tout à fait faisable
pour attribuer un port de service unique à chaque membre de la partition et des données proxy à chacun
instance de pod - même pour les très gros travaux. (Cette suggestion suppose que
les proxys sont toujours la direction que nous voulons prendre avec les k8 - je n'ai pas suivi
avec toute discussion récente dans ce domaine)

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-132451774
.

Légère torsion à l' idée ThingPool + Patches de @thockin :

Modèle : liste des ressources + paramètres et substitution. Voir https://github.com/openshift/origin/blob/master/pkg/template/api/types.go pour l'inspiration. Réf #503, #1743, #4210, #6487.

Pool de modèles. Fondamentalement, ThingPool. Génère des instances de modèle densément indexées à la demande plutôt que par nombre de réplicas.

Pour le plaisir/la cohérence : v2 ReplicationController pourrait répliquer des modèles arbitraires au lieu de simplement des pods. réf #170 (en quelque sorte). Peut-être pas nécessaire si toute l'allocation est pilotée par la réplication de pod.

L'alternative principale serait quelque chose de plus spécifique au domaine, axé sur les pools de noms d'hôte et PVC, mais des pools séparés pour chacun ne fonctionneraient pas. Un seul pool devrait pouvoir allouer des tuples de noms d'hôtes et (potentiellement plusieurs) PVC. L'un des avantages du TemplatePool est que quelqu'un peut l'utiliser pour allouer un service (peut-être externe) par réplica, automatisant ainsi la solution de contournement actuelle de Zookeeper. Je ne sais pas s'il pourrait y avoir d'autres ressources que quelqu'un voudrait répliquer de la même manière 1 à 1 avec des pods, mais étant donné la vitesse à laquelle notre API se développe, je ne parierais pas qu'il n'y en aura pas.

@smarterclayton Pour info, lorsque vous répondez par e-mail avec des commentaires en ligne, vos réponses sont illisibles, à la fois dans gmail et sur github. Dans gmail, il n'y a pas de sauts de ligne et dans github il n'y a pas de préfixes de citation, donc votre réponse est difficile à démêler en dehors du texte cité.

Oui, il y a quelque chose qui ne va pas avec gmail + github + iPhones.

Le jeu. 20 août 2015 à 14:24, Brian Grant [email protected]
a écrit:

@smarterclayton https://github.com/smarterclayton Pour info lorsque vous répondez
par e-mail avec des commentaires en ligne, vos réponses sont illisibles, à la fois dans
gmail et sur github. Dans gmail, il n'y a pas de saut de ligne et dans github là
ne citent pas de préfixes, il est donc difficile de distinguer votre réponse en dehors du
texte cité.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-133108803
.

Clayton Coleman | Ingénieur en chef, OpenShift

Nous avons eu une discussion rapide aujourd'hui, quelques points saillants :

A parlé des trois classes d'applications :

• Applications qui sont des applications Web sans état (fonctionne uniquement avec les RC)
• Applications à grande échelle qui utilisent des maîtres externes et ont une cohérence existante
  protocoles (Cassandra, Infiniband) pour gérer le consensus
• Petit logiciel avec état en cluster comme Mongodb, rethinkdb, volt, etcd,
  zookeeper, riak, clusters redis, qui ont besoin de quelques modèles pour bien fonctionner
  
  
  
  • Identité unique (généralement)
  
  
  • Volume persistant unique par instance qui est réutilisé (généralement)
  
  
  • Adresse IP stable ou nom DNS (généralement) - Le nom DNS est généralement un
    
    standin pour l'adresse IP stable
  
  
  • Nom d'hôte stable (rarement)
  
  

Aujourd'hui, vous pouvez résoudre l'identité unique et le volume persistant en ayant N
contrôleurs de réplication, adresse IP stable avec N services. Nous voudrions
ne pas exiger de NRC et de services pour certains de ces cas d'utilisation.

Nous avons parlé des suggestions de Tim et Brian, sans ordre particulier :

• TemplatePool est problématique car le réplicateur doit avoir le
  autorité pour créer des objets sur l'ensemble du cluster, et doit savoir
  où se trouve chaque point de terminaison d'API.
  
  
  
  • Vous pouvez avoir un point de terminaison de modèle d'instanciation, mais vous devez toujours
    
    résoudre le problème de délégation d'autorité (avec des comptes de service ?)
  
  
  • La localisation d'objets et la restriction des autorisations sont des choses à plus long terme
  
  
• Le "pod identity" aka vuid field dont nous avons parlé - l'argument a été avancé
  et généralement convenu qu'il n'a pas besoin d'être unique au monde, seulement
  unique dans le domaine que le pod prévoit de l'utiliser.
  
  
  
  • Un assignateur d'index hypothétique (parsemé ou dense) pourrait définir cette valeur
    
    après la création, et le kubelet pouvait attendre de démarrer les pods jusqu'à ce qu'ils aient un
    
    identité (peut avoir besoin d'indiquer qu'ils en attendent un)
  
  
  • Les index denses sont généralement utiles pour des choses simples, mais parce que cela
    
    est la création de poste et découplée du kubelet, vous pourriez avoir différents
    
    types d'algorithmes d'affectation (anneau de hachage numérique dense et cohérent,
    
    aléatoire, etc.)
  
  
• La création de modèles simples sur les pods semble être un bon point de départ, mais nous avons besoin
  pour la rendre cohérente avec notre chaîne d'outils existante d'une manière qui ne
  le casser totalement
  
  
  
  • Utilisez le champ d'identité pour modéliser d'autres champs
  
  
• Ajoutez un champ de nom d'hôte sur la spécification du pod que les utilisateurs peuvent définir eux-mêmes et
  paramétrer avec l'identité
• Autoriser un service sans tête à répondre aux requêtes DNS pour les points de terminaison par leur
  identité (faire en sorte que le contrôleur de points de terminaison matérialise l'identité à partir d'un pod
  en points finaux) qui garantit une certaine stabilité
• Permettre d'une manière ou d'une autre de paramétrer ou de modifier les revendications de volume persistant pour
  puiser dans un pool (ou demander à un contrôleur de pool de s'assurer qu'il y a un volume par
  identité, ou demander au contrôleur d'identité de puiser dans les pools), doit être réfléchi
• Besoin d'outils qui permettent de transformer facilement l'environnement / l'API descendante en
  fichiers de configuration (orthogonaux, mais devrait être plus facile)
• Encore quelques inquiétudes sur le modèle

Le jeu. 20 août 2015 à 15h34 , Clayton Coleman
a écrit:

Oui, il y a quelque chose qui ne va pas avec gmail + github + iPhones.

Le jeu. 20 août 2015 à 14:24, Brian Grant [email protected]
a écrit:

@smarterclayton https://github.com/smarterclayton Pour info lorsque vous répondez
par e-mail avec des commentaires en ligne, vos réponses sont illisibles, à la fois dans
gmail et sur github. Dans gmail, il n'y a pas de saut de ligne et dans github là
ne citent pas de préfixes, il est donc difficile de distinguer votre réponse en dehors du
texte cité.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-133108803
.

Clayton Coleman | Ingénieur en chef, OpenShift

Clayton Coleman | Ingénieur en chef, OpenShift

Encore un problème : les certificats TLS pour les membres d'un service nominal

Des certificats TLS pour les services en général seraient également une bonne chose (signé
par l'AC du cluster automatiquement sur demande).

Le jeu 20 août 2015 à 17h19, Brian Grant [email protected] a écrit :

Encore un problème : les certificats TLS pour les membres d'un service nominal

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Clayton Coleman | Ingénieur en chef, OpenShift

Oui : 11725

Ré:

• Ajoutez un champ de nom d'hôte sur la spécification du pod que les utilisateurs peuvent définir eux-mêmes et
  paramétrer avec l'identité
• Autoriser un service sans tête à répondre aux requêtes DNS pour les points de terminaison par leur
  identité (faire en sorte que le contrôleur de points de terminaison matérialise l'identité à partir d'un pod
  en points finaux) qui garantit une certaine stabilité

Je pense que nous avons convenu que DNS devrait être pris en charge à l'aide des noms d'hôte définis dans les spécifications du pod (qui pourraient être paramétrés par leurs identités une fois que nous avons ajouté cette fonctionnalité), de sorte que les noms d'hôte vus par les conteneurs puissent être résolus par d'autres conteneurs.

Afin de définir le sous-domaine, nous devons indiquer au pod quel service l'a ciblé, explicitement ou implicitement. L'inconvénient d'explicite est qu'il nécessite plus de configuration glue/templating. L'inconvénient de l'implicite est qu'il serait sujet aux défis que nous avons avec le couplage lâche dans le système : courses d'ordre de création et incohérence, difficultés d'application 1 à 1, etc. Je penche pour l'explicite. Nous devrions simplement travailler sur l'amélioration de la portée des références croisées.

Quelque chose comme:

Hostname string
Subdomain string

au-dessus de HostNetwork dans le PodSpec.

Nous ne fournirions le DNS basé sur le nom d'hôte que si le sous-domaine correspondait à celui d'un service du bon type. Nous pourrions également rassembler les deux dans un seul champ.

Je pense que nous devrions réutiliser le numéro 4825 pour cela et demander à quelqu'un de travailler dessus. C'est beaucoup plus concret et moins de travail que le reste.

Permettre d'une manière ou d'une autre de paramétrer ou de modifier les revendications de volume persistant pour
puiser dans un pool (ou demander à un contrôleur de pool de s'assurer qu'il y a un volume par
identité, ou demander au contrôleur d'identité de puiser dans les pools), doit être réfléchi

Je pense que deux choses sur les réclamations peuvent aider ici :

1. Changer la liaison de 1:1 à 1:N
   
   
   
   1. pvc.Spec.VolumeName à pvc.Spec.VolumeNames[] comme référence de liaison
   
   
2. pvc.Spec.Singelton booléen qui indique si une revendication doit être liée exactement une fois pour le partage ou permettre à la revendication d'être liée plusieurs fois.

Un RC peut se lier à de nouveaux volumes selon les besoins. Je trouverais comment gérer ça dans le classeur.

Il serait toujours important de faire correspondre le bon volume au bon pod.

Vous devriez avoir une carte des identités aux noms de volume.

Le ven 21 août 2015 à 15h17, Mark Turansky [email protected]
a écrit:

Permettre d'une manière ou d'une autre de paramétrer ou de modifier les revendications de volume persistant pour
puiser dans un pool (ou demander à un contrôleur de pool de s'assurer qu'il y a un volume par
identité, ou demander au contrôleur d'identité de puiser dans les pools), doit être réfléchi

Je pense que deux choses sur les réclamations peuvent aider ici :

1. Changer la liaison de 1:1 à 1:N
   
   
   
   1. pvc.Spec.VolumeName à pvc.Spec.VolumeNames[] comme liaison
      
      référence
   
   
2. pvc.Spec.Singelton booléen qui indique si une revendication doit être liée
   exactement une fois pour le partage ou permettre à la créance d'être liée plusieurs fois.

Un RC peut se lier à de nouveaux volumes selon les besoins. Je trouverais comment gérer ça
dans le classeur.

Il serait toujours important de faire correspondre le bon volume au bon pod.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

Clayton Coleman | Ingénieur en chef, OpenShift

Le vendredi 21 août 2015 à 00h56, Brian Grant [email protected] a écrit :

Afin de définir le sous-domaine, nous devons indiquer au pod quel service l'a ciblé,
explicitement ou implicitement. L'inconvénient d'explicite est qu'il nécessite plus
colle de configuration / gabarit. L'inconvénient de l'implicite est qu'il serait
sujettes aux défis que nous avons avec le couplage lâche dans le système : création-
courses d'ordre et incohérence, difficultés d'exécution 1 à 1, etc. Je me penche
vers explicite. Nous devrions simplement travailler sur l'amélioration de la portée des références croisées.

Soyons clairs - si nous ne définissons PAS de sous-domaine, nous ne pouvons pas laisser les utilisateurs fournir
leurs propres noms d'hôtes. Si nous définissons un sous-domaine, nous devons le faire dans un
manière qui est assez unique (dans l'espace DNS, ce qui signifie actuellement à travers
l'espace de noms). Faire du sous-domaine le nom d'un service est
assez unique.

Étant donné certaines des limitations de notre DNS (un seul TLD), ce
signifie de manière réaliste que nous donnons aux utilisateurs deux champs DNS_LABEL - nom d'hôte
et l'ensemble nominal. Pour un exemple concret :

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

Cela se traduirait par le pod voyant :

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

et DNS servant les enregistrements A et PTR pour foo.bar.my-app.nom.cluster.local

C'est un niveau plus profond que notre structure DNS actuelle, mais je pense
notre ndots=5 actuel couvre cela. Alternativement, on pourrait dire qu'un
namespace EST le nom de famille, et remettez-le aux utilisateurs pour attribuer un
noms d'hôtes dans un espace de noms. Le résultat DNS serait
foo.my-app.pod.cluster.local qui reflète les services. On pourrait même
rendez-les plus semblables en ajoutant un champ de nom d'hôte facultatif aux services.

Nous ne fournirions le DNS basé sur le nom d'hôte que si le sous-domaine correspondait à celui pour
un service du bon type. Nous pourrions également rassembler les deux dans un seul champ.

Ce que je préfère le moins, c'est que le Pod déclare "Je fais partie
de Service 'bar'" (dans l'exemple ci-dessus). A priori. A priori.

La pente glissante est pourquoi ne pas permettre cela en général ? ce serait
simplifier un tas de choses qui ne peuvent pas faire d'hypothèses aujourd'hui (parce que
de couplage lâche) même si en pratique on voit rarement un seul Pod
derrière plus d'un Service. Si chaque Pod était sous zéro ou un
Service, le système se simplifie-t-il ?

Je pense que nous devrions réutiliser le numéro 4825 pour cela et demander à quelqu'un de travailler dessus. C'est beaucoup plus concret et moins de travail que le reste.

C'est certainement quelque chose qui pourrait commencer tout de suite, mais (pour ceux
suivre à la maison) c'est juste le mécanisme de mise en œuvre du pod
l'identité, et non la politique de gestion des ensembles d'identités.

Le vendredi 21 août 2015 à 15h17, Mark Turansky [email protected] a écrit :

Je pense que deux choses sur les réclamations peuvent aider ici :

1. Changer la liaison de 1:1 à 1:N

C'est par là que j'ai commencé, mais...

Le ven. 21 août 2015 à 12:38, Clayton Coleman
[email protected] a écrit :

Vous devriez avoir une carte des identités aux noms de volume.

Ouais. Cela s'avère vraiment être un problème de modèle.
Que vous considériez le problème comme un « modèle de pod » dans lequel certains
les champs ont des espaces réservés qui sont remplis par un "tuple de substitution"
tiré d'un pool au moment de l'exécution ou vous le pensez comme un pod entièrement réifié
spec qui est "corrigé" avec un "tuple de substitution" tiré d'un pool
au moment de l'exécution - ils sont isomorphes et tout aussi désagréables.

Et pourtant, je pense que c'est l'un des plus grands problèmes que nous devons résoudre.
Devrions-nous commencer à élaborer des propositions d'homme de paille pour ceux-ci ?

Nous avons plusieurs exemples de pods sous deux ou trois services, un pour
propagation, un pour l'exposition et un pour tester l'exposition.

En ce qui concerne l'identité, chaque pod créé par un contrôleur de démon doit avoir une identité attribuée dérivée de l'identité du nœud et de l'identité du contrôleur. Cela peut être un cas où l'identité est évidente (le pod x sur l'hôte y a l'identité f(y)) et fait partie de la responsabilité des démons.

@smarterclayton donc un besoin commun (mais pas universel) ici est de maintenir une liste stable et ordonnée des membres du groupe. Comment cela peut-il fonctionner lorsque l'identité est liée au nœud sur lequel le pod est programmé ?

Le contrôleur de démon _only_ a une identité dans le contexte du nœud sur lequel se trouve le pod
courir. Les contrôleurs et services de réplication sont différents. Démon
le contrôleur dit "il devrait y en avoir un en cours d'exécution sur chaque nœud". Là
n'y a pas d'autre identité que le pod peut avoir à l'exception de son nœud.

Le ven 11 sept. 2015 à 01h13, Angus Lees [email protected]
a écrit:

@smarterclayton https://github.com/smarterclayton donc commun (mais pas
universel) le besoin ici est de maintenir une liste stable et ordonnée de groupes
membres. Je pense que cela implique que l'identité ne devrait _pas_ être liée au
nœud sur lequel le pod est planifié.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

Clayton Coleman | Ingénieur en chef, OpenShift

@smarterclayton ah, ce problème s'est clairement transformé en quelque chose de plus que la demande de fonctionnalité d'origine - je suis perdu sur ce que j'essayais de construire ici, donc je vais reculer plutôt que de continuer à ajouter du bruit ...

Désolé, cela ne voulait pas dire que le point n'était pas pertinent. Le défi est que nous devons définir des ensembles et les propager dans le pod. Nous avons besoin que le pod soit réactif à l'appartenance à l'ensemble (volume de montage X qui correspond à l'identité du pod dans l'ensemble). Il y a une question ouverte : un groupe pourrait-il être membre de deux ensembles simultanément et avoir une identité unique dans l'un ou l'autre ?

Il se peut que des pods exécutés par un contrôleur démon aient une identité « évidente » (le contrôleur démon opère sur un ensemble de nœuds, le RC opère sur un ensemble de pods).

Une exigence d'identité est qu'elle soit unique dans l'ensemble. Pourrions-nous tirer parti des noms de pod et de la génération de noms de pod pour garantir cette unicité ? Par exemple, les RC génèrent des noms aléatoires. Un RC pourrait-il générer des noms pour les pods de manière déterministe en fonction de l'ensemble de pods qu'il sélectionne ?

Considérons un RC qui sélectionne les pods avec l'étiquette a=b. Afin de calculer le prochain pod à créer, il doit récupérer les pods et les réduire à un nombre. Et si nous le réduisions à un ensemble de noms unique, puis que le RC essayait de suivre un modèle de génération de noms au sein de cet ensemble ? Deux RC qui ne se chevauchent pas, mais qui ont créé des pods dans une étiquette de service, seraient incapables de générer des noms uniques (ils peuvent se battre pour un nom, mais c'est implicite). Les noms peuvent être réutilisés après leur suppression

Ensuite, les volumes persistants dans le pod pourraient utiliser des PVC en fonction du nom du pod. Un pooler de PVC pourrait s'assurer qu'il y a suffisamment de réclamations pour un pool observé de RC. Le contrôleur de démon peut choisir des noms déterministes par rapport à un nom de nœud. Nous pouvons également câbler des noms DNS aux noms de pod dans un service basé sur un modèle.

Cela semble plus parcimonieux que d'ajouter un champ d'identité distinct sur le pod. Cela signifie que les gousses ne sont toujours pas des animaux de compagnie, mais leurs noms peuvent l'être (ce qui n'est pas une déclaration déraisonnable). Nous ne pouvons pas empêcher l'exécution simultanée de deux instances du même processus de pod sur le cluster, mais nous pouvons garantir (et nous le faisons) que le nom n'est utilisé qu'à un seul endroit aujourd'hui.

Signifiait "pool de noms observé" ci-dessus. Le DNS du point de terminaison serait hashpodname.ept.service.namespace.svc.cluster.local. Nous avons déjà le nom du pod sur le point de terminaison, nous n'avons donc même pas besoin d'ajouter quoi que ce soit.

lié à https://github.com/kubernetes/contrib/tree/master/service-loadbalancer qui propose la résolution de ce problème comme prochaine itération possible

Pourquoi parlons-nous de DaemonSet ici ? Cela a été résolu par #12893, IMO.

@smarterclayton Ne https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

Une possibilité serait d'avoir une option RC qui vous permet de générer des noms de la manière décrite par @smarterclayton si vous le souhaitez, et des ensembles de fonctionnalités distincts à votre disposition en fonction de la façon dont vous définissez l'option. Ainsi, les éléments difficiles à mettre en œuvre avec une approche « index des tâches » ne seraient pas disponibles si vous activiez l'option, mais la fonctionnalité décrite ici le serait. Et inversement, le comportement par défaut (option désactivée) vous donnerait ces autres fonctionnalités mais pas celle décrite ici.

Il semble que l'utilité de quelque chose comme l'abstraction de l'index des tâches Borg continue d'apparaître _pour certains cas d'utilisation_ et je ne comprends pas pourquoi nous ne pouvons pas l'offrir en option.

DaemonSet, je ne pense pas qu'il résolve le cas du stockage du système de fichiers distribué
(Gluster) où chaque hôte doit avoir une identité cohérente pour rejoindre
la grappe. Je vais creuser plus mais je pense qu'il peut encore avoir besoin de quelque chose le long
les besoins de #260 - Je ne sais pas si le nom d'hôte est suffisant si vous rattachez
un disque hôte sur une nouvelle instance. Peut-être que je n'ai pas compris ce que DaemonSet
fourni et #12893 livré, mais je ne pense pas que ce soit le problème pour un
hôte système qui souhaite réutiliser le disque.

Le mercredi 16 septembre 2015 à 00h22, Brian Grant [email protected]
a écrit:

@smarterclayton https://github.com/smarterclayton Ne revisitons pas
dériver l'identité des noms de pod, ni utiliser des RC pour attribuer une identité.
Les problèmes liés à ces approches ont été discutés ici : #260 (commentaire)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-140623023
.

Clayton Coleman | Ingénieur en chef, OpenShift

Comme exemple concret, imaginez un cluster etcd. Il a 7 instances, et 7
tomes. Je veux (à des fins d'argumentation), les noms et volumes etcd-1
via etcd-7 et etcd-pvc-1 via etc-pvc-7.

Un déploiement continu a MaxUnavailable 90% (ou équivalent), MaxSurge 0%. Ce
réduit l'ancien RC et augmente le nouveau RC. Le vieux RC gracieusement
supprime etcd-5. Il sort instantanément de l'ensemble RC effectif. Le nouveau
RC essaie de créer etcd-5 (par observation de l'écart défini). Il reçoit un
"DéjàExisteException". Il traite cela comme une interruption et des mises en file d'attente. Une fois
etcd-5 est vraiment parti, il peut continuer. Une fois que etcd-5 est prêt, le DC
passe à l'étape suivante.

Pour l'alternative - identité définie sur le pod - l'ancienne RC est réduite. UNE
le nouveau pod est créé instantanément avec un nouveau nom. Impossible de lancer le nouveau pod
car il a besoin d'un ensemble d'identités pour déterminer quel PVC monter pour son
le volume. Il entre dans une boucle d'attente sur le Kubelet. Le contrôleur d'identité
regarde un ensemble de sélecteurs d'étiquettes et observe l'identité etcd-5 n'est pas
alloué. Il définit l'identité etcd-5 sur le nouveau pod. Le kubelet observe
ce changement et peut ensuite déterminer quel PVC monter, démarre le pod
(en supposant que le volume a été détaché de l'autre nœud).

Structurellement, ceux-ci sont très similaires. Ce dernier permet le chevauchement de démarrage.
Les deux nécessitent le mappage du PVC.

Le mer. 16 sept. 2015 à 00h39, Clayton Coleman [email protected]
a écrit:

DaemonSet, je ne pense pas qu'il résolve le cas du stockage du système de fichiers distribué
(Gluster) où chaque hôte doit avoir une identité cohérente pour rejoindre
la grappe. Je vais creuser plus mais je pense qu'il peut encore avoir besoin de quelque chose le long
les besoins de #260 - Je ne sais pas si le nom d'hôte est suffisant si vous rattachez
un disque hôte sur une nouvelle instance. Peut-être que je n'ai pas compris ce que DaemonSet
fourni et #12893 livré, mais je ne pense pas que ce soit le problème pour un
hôte système qui souhaite réutiliser le disque.

Le mercredi 16 septembre 2015 à 00h22, Brian Grant [email protected]
a écrit:

@smarterclayton https://github.com/smarterclayton Ne revisitons pas
dériver l'identité des noms de pod, ni utiliser des RC pour attribuer une identité.
Les problèmes liés à ces approches ont été discutés ici : #260 (commentaire)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-140623023
.

Clayton Coleman | Ingénieur en chef, OpenShift

Clayton Coleman | Ingénieur en chef, OpenShift

Pour moi, ce qui rend ce problème difficile, ce n'est pas de générer un pool de noms unique stable ou d'utiliser un pool de PD. Le problème est de faire les DEUX en même temps. Et si vous étendez cela, pourquoi à peu près n'importe quel identifiant de la spécification ne peut-il pas être mis en commun de cette manière ?

Autant que je connais (principalement de seconde main) les problèmes avec les index emballés, je pense qu'ils pourraient être vivables (surtout si nous faisons comme David le suggère et les rendons mutuellement exclusifs avec d'autres fonctionnalités). Mais aussi, plus je mijote dessus, moins je déteste l'idée de Patch qu'un crétin a posté dans le fil de discussion.

Ce problème s'est attardé et j'ai peur que nous ayons une paralysie de l'analyse.

J'aimerais que nous ayons plus d'exemples d'autres cas d'utilisation de mise en commun. J'ai pensé Gluster
serait différent mais c'est juste une autre variante sur le
cassandra/etcd/mongo/zookeeper "je veux réutiliser un volume et j'ai besoin de
rappelez-vous qui j'ai dit que j'étais avant". Nous n'avons pas vraiment eu de rôle basé (je
voulez faire les premiers N pods coordinateurs et les prochains M workers) exemple
à tirer parti.

Le mercredi 16 septembre 2015 à 00h46, Tim Hockin [email protected]
a écrit:

La chose qui rend ce problème difficile, pour moi, n'est pas de générer une stabilité
pool unique de noms ou en utilisant un pool de PD. Le problème est de faire les DEUX à
le même temps. Et si vous prolongez cela, pourquoi n'importe quel
identifiant dans la spécification être mis en commun comme ça?

Autant que je sache (principalement de seconde main) les problèmes avec les index emballés, je
pense qu'ils pourraient être habitables (surtout si nous faisons comme David le suggère et faisons
s'excluent mutuellement avec d'autres fonctionnalités). Mais aussi, plus je mijote
ça, moins je déteste l'idée de Patch qu'un crétin a posté dans le fil de discussion.

Ce problème a persisté et s'est attardé et je crains que nous ayons une analyse
paralysie.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

Clayton Coleman | Ingénieur en chef, OpenShift

Ensemble de démons :

12893 définit le nom d'hôte du pod sur le nom d'hôte du nœud lors de l'utilisation de la mise en réseau hôte, ce qui est tout à fait raisonnable à utiliser pour DaemonSet, car ceux-ci utiliseraient sinon hostPort, de toute façon.

En outre, l'intention est d'intégrer DaemonSet au contrôleur de nœud afin de fournir un pardon implicite indéfini n° 1574 et d'activer la « planification » avant que la planification ne soit activée pour les nœuds en général. Une hiérarchisation implicite peut également être raisonnable.

Pour un système de stockage en cluster, je pourrais imaginer provisionner des disques supplémentaires sur chaque hôte auxquels accèdent via hostPath uniquement par le système de stockage - ils ne seraient pas utilisés par Docker ni par emptyDir.

En ce qui concerne l'identité, je ne vois pas de problème avec la proposition ici : https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Cette question a persisté principalement en raison du manque de priorité suffisante, l'OMI.

Pour riffer sur Clayton (ou peut-être juste pour dire les mêmes choses mais plus bêtement) :

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

L'implication est que le RC (ou quelque chose) se rend compte qu'il s'agit d'un ensemble d'identités, attribue un index à partir du pool d'identité, attribue cette identité au nom du pod, puis jette un œil à l'intérieur pour voir si d'autres champs centrés sur l'identité sont définis - l'identité volume dans ce cas.

Ce n'est pas totalement générique (vous ne pouvez pas regrouper de champ aléatoire) mais nous pouvons ajouter plus d'options prenant en compte les identités si nécessaire

J'ai le sentiment que si nous définissons une spécification que nous aimons à ce sujet, cela pourrait être fait plus tôt que tard.

Même écrire une spécification prend du temps.

En ce qui concerne IdentityPool/VolumePool, nous avons déjà décidé il y a longtemps que plusieurs pools ne fonctionneraient pas.

La date limite de saisie du code 1.1 est vendredi. Pourrions-nous s'il vous plaît ne pas le faire maintenant?

Également lié : #170. Cela proposait de simplement séparer le modèle de pod, mais si nous optons pour un schéma de modèle (que je préfère fortement au patch), alors nous devrions les considérer ensemble.

J'ai mis au moins le design sur le candidat v1.2.

Désolé, je n'ai pas été clair dans mon croquis - le RC (ou IC?) A un concept de
pool principal ou index. Une fois qu'un pod se voit attribuer un index dans l'IC, ce
index est utilisé pour indexer dans tous les champs centrés sur le pool.

Si nous divisons le modèle, je suppose que l'hypothèse est que le RC ne peut pas
muter le modèle. C'est un peu plus délicat.

Je vais bien arrêter d'en parler cette semaine. Il vient d'apparaître dans mon
boîte de réception et j'avais ruminé cette idée...

Le mar. 15 sept. 2015 à 22:09, Brian Grant [email protected]
a écrit:

Même écrire une spécification prend du temps.

Concernant IdentityPool/VolumePool, nous avons déjà décidé depuis longtemps
il y a plusieurs piscines ne fonctionneront pas.

La date limite de saisie du code 1.1 est vendredi. Pourrions-nous s'il vous plaît ne pas le faire maintenant?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

Oui, il y avait juste des choses qui ont déclenché des discussions de notre côté.
Les problèmes des clients n'attendent aucun processus de publication.

Le mercredi 16 septembre 2015 à 01h14, Tim Hockin [email protected]
a écrit:

Désolé, je n'ai pas été clair dans mon croquis - le RC (ou IC?) A un concept de
pool principal ou index. Une fois qu'un pod se voit attribuer un index dans l'IC, ce
index est utilisé pour indexer dans tous les champs centrés sur le pool.

Si nous divisons le modèle, je suppose que l'hypothèse est que le RC ne peut pas
muter le modèle. C'est un peu plus délicat.

Je vais bien arrêter d'en parler cette semaine. Il vient d'apparaître dans mon
boîte de réception et j'avais ruminé cette idée...

Le mar. 15 sept. 2015 à 22:09, Brian Grant [email protected]
a écrit:

Même écrire une spécification prend du temps.

Concernant IdentityPool/VolumePool, nous avons déjà décidé depuis longtemps
il y a plusieurs piscines ne fonctionneront pas.

La date limite de saisie du code 1.1 est vendredi. Pourrions-nous s'il vous plaît ne pas faire cela
à présent?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

Clayton Coleman | Ingénieur en chef, OpenShift

La discussion porte uniquement sur les numéros d'adresse IP et les pods, mais d'après mon expérience avec Mongo & Zookeeper, l'IP les pods devraient rester sans importance (ne pas devenir des animaux de compagnie). Le _volume_ persistant a besoin d'un numéro nominal puisque ce volume enregistre le numéro IP des autres 'volumes'. Quel que soit le Pod qui monte ce volume, il devrait pouvoir utiliser ce numéro IP enregistré d'une manière ou d'une autre. Le volume est l'animal de compagnie...

Un nom DNS constant dans le temps pour un volume et attribué à un pod qui monte le volume ferait beaucoup de chemin, je pense.

La modification de l'appartenance à un ensemble dans Mongo & ZK nécessitera toujours l'exécution d'un code personnalisé et je m'attends à ce qu'il en soit de même pour la plupart des autres ensembles. Le contrôleur de réplication n'est donc pas le bon nom, ces animaux de compagnie ont davantage besoin d'un contrôleur de navire membre. Un contrôleur de navire membre devrait être capable de gérer la configuration initiale, puis les modifications incrémentielles des ensembles, et enfin de l'éliminer.

Étant donné un nom DNS constant basé sur le volume monté et la possibilité de gérer l'appartenance à l'ensemble avec un code personnalisé devrait permettre de gérer ce type de systèmes, je pense.

Oui, pod IP est plus un hack à court terme.

Où va cette proposition est quelque chose au-dessus du DNS et du volume que les deux
peut tirer parti pour rester couplé. Le problème est que le volume définissant le nom DNS
est l'inverse du couplage que nous avons déjà établi, et nous avons également
vouloir laisser d'autres parties de la spécification du pod tirer parti de ce concept supérieur
(identité) comme l'API descendante sur l'environnement. Cela permet de s'adapter
identité à différents logiciels d'ensemble plus facile (réduit le code personnalisé par
taper).

Nous devons toujours nous assurer qu'il n'y a pas de cas d'utilisation au-delà des ensembles qui
chevauchements ici (je n'en ai pas entendu de suggestion), puis essayez d'arriver à un
proposition concrète qui semble minimale et appropriée. Tim je pense a
résumé cela le plus récemment ici.

Le 23 septembre 2015, à 11h33, Peter Kriens [email protected] a écrit :

La discussion porte uniquement sur les numéros IP et les pods, mais d'après mon expérience avec
Mongo & Zookeeper l'IP les Pods devraient rester sans importance (ne pas devenir des animaux de compagnie).
Le _volume_ persistant a besoin d'un numéro nominal puisque ce volume enregistre
le numéro IP des autres « volumes ». Quel que soit le Pod qui monte ce volume
devrait pouvoir utiliser ce numéro IP enregistré d'une manière ou d'une autre. Le volume est le
animaux ...

Un nom DNS constant dans le temps pour un volume et attribué à un Pod qui
monte le volume viendrait un long chemin je pense.

Le changement d'appartenance à l'ensemble dans Mongo & ZK nécessitera toujours une personnalisation
code à exécuter et je m'attends à ce qu'il en soit de même pour la plupart des autres ensembles. Alors
Le contrôleur de réplication n'est pas le bon nom, ces animaux ont besoin de plus d'un membre
Contrôleur de navire. Un contrôleur de navire membre devrait être en mesure de gérer les
configuration initiale, puis modifications incrémentielles des ensembles, et enfin
tue-le.

Étant donné un nom DNS constant basé sur le volume monté et la possibilité de
gérer l'appartenance à l'ensemble avec un code personnalisé devrait permettre de
gérer ce type de systèmes je pense.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-142640825
.

/ping

Vous pouvez trouver un exemple de configuration d'un cluster ZK sous Kubernetes en utilisant les capacités existantes sur https://hub.docker.com/r/elevy/zookeeper/. La principale exigence est la stabilité des adresses IP et des noms d'hôte pour les membres de l'ensemble. Ceci est accompli en utilisant des services individuels pour chaque membre du cluster. Le seul problème est que, par défaut, ZK tentera de se lier à l'adresse IP à laquelle son nom d'hôte est résolu, mais cela peut être évité via un paramètre de configuration.

@smarterclayton @thockin

Pensées en allant au bureau à vélo il y a quelques jours :

Je pense actuellement à cela comme un contrôleur PetSet, ou peut-être un contrôleur ShardSet, si les gens veulent y penser de cette façon, comme indiqué au début : https://github.com/kubernetes/kubernetes/issues/260# questioncommentaire -57671926.

Le cas que nous essayons de traiter est celui où il y a N animaux de compagnie similaires, mais ce sont toujours des animaux de compagnie -- ils ne sont pas fongibles.

Je pense toujours que lier cela à ReplicationController ne peut pas fonctionner, en partie parce que ReplicationController n'a qu'un seul modèle. PetSet/ShardSet doit être une abstraction de niveau supérieur, plus comme Deployment ou DaemonSet. PetSet pourrait potentiellement générer un objet PodTemplate par instance.

Je ne pense pas que nous puissions simplement réutiliser l'API de déploiement. Entre autres choses, la stratégie de déploiement de mise à jour progressive maintenant dans kubectl et Deployment ne fonctionnera pas dans ce cas. La plupart des animaux de compagnie voudraient probablement des mises à jour Recréer, et tous ceux qui voudraient des mises à jour continues ne seraient pas en mesure de gérer une augmentation supérieure à leur nombre de fragments et seraient particulièrement attentifs à l'ordre de mise à jour.

Autant j'aime l'idée, autant je ne pense pas que l'attribution d'identité de bas en haut fonctionnera. Trop de conditions de concurrence avec le retour des identités allouées au pool par rapport à l'attribution de nouvelles. Tout comme les problèmes rencontrés par @erictune en explorant l'utilisation de RabbitMQ avec Job.

Je ne veux pas représenter l'échelle du PetSet à plus d'un endroit, comme dans un contrôleur et dans un pool d'identités, ou dans un contrôleur et dans un service, car cela rendrait la mise à l'échelle délicate/maladroite.

Je ne pense pas que nous ayons besoin de modèles à usage général pour ce cas. Nous avons juste besoin d'éliminer les pods avec le stockage associé et des identités réseau prévisibles et durables. L'équivalent approximatif a été suffisant en Borg. Par conséquent, je penche fortement vers quelque chose du genre #12450, mais dans le modèle de pod plutôt que dans les pods eux-mêmes. Peut-être un tableau de persistentVolumeClaimTemplates en plus d'un podTemplate. Je ne veux pas ajouter de substitution fantaisiste pour toutes les sources de volume spécifiques au fournisseur de cloud, d'autant plus que nous voulons les déprécier de toute façon. L'ajout d'exigences et/ou de sélecteurs supplémentaires aux PVC devrait être suffisant. Nous devrons également être en mesure de provisionner des volumes persistants d'une manière ou d'une autre à un moment donné.

Nous devrons encore faire quelque chose sur le stockage local éventuellement, mais je pense que c'est séparable.

Et puis les changements de nom d'hôte et de service sans tête mentionnés ci-dessus, ici :
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-133318903

Travailler sur une proposition maintenant, aura bientôt une ébauche.

La proposition est en ligne sur https://github.com/kubernetes/kubernetes/pull/18016

... alors où en sommes-nous avec PetSet ?

Je crée des solutions de base de données HA sur Kubernetes. Certaines, en particulier les bases de données à maître unique, nécessitent des services avec des points de terminaison qui correspondent à des pods particuliers en fonction des événements de ces pods. Par example:

1. le service « postgres » mappe en boucle sur tous les pods du ReplicaSet, mais le service « postgres-master » est mappé sur un seul pod.
2. le pod maître meurt.
3. le basculement se produit. Dans le cadre du basculement, le nouveau maître met à jour Kube-master via l'API pour "saisir" le service postgres-master.
4. Quand il fait cela, toutes les connexions précédentes à postgres-master sont terminées.

@jberkus le code alpha initial pour activer les PetSets a été fusionné ou est en attente de fusion. @ingvagabund de mon équipe va commencer à rassembler des exemples qui utilisent PetSet pour voir ce qui fonctionne bien et ce qui doit encore être amélioré. Je vous recommande de le contacter si vous avez des cas d'utilisation spécifiques que vous souhaitez mettre en place et tester.

@ncdc Est-ce que tout est fait pour cela dans la v1.3 ? Ce n'est pas clair car la proposition n'est pas fusionnée et il n'y a pas eu d'autres PR y faisant référence depuis un certain temps.

@bprashanth ^

Nous débarquons e2es et continuons à travailler sur des exemples. c'est en alpha
maintenant, mais la proposition va prendre le premier tour de rétroaction alpha
avant de fusionner.

Le 19 mai 2016, à 10h25, Brandon Philips [email protected]
a écrit:

@ncdc https://github.com/ncdc Est-ce que tout est fait pour cela dans la v1.3 ? Il est
pas clair car la proposition n'est pas fusionnée et il n'y a pas eu d'autres PR
faisant référence à cela pendant un certain temps.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

Où puis-je trouver des docs pour cela? J'aimerais le tester pour un cas d'utilisation de basculement de base de données.

Ah ha, juste ce dont nous avons besoin d'un expert postgres :)

voir https://github.com/kubernetes/contrib/pull/921 pour des exemples, je peux répondre à toutes les questions sur le prototypage [db of choice] comme petset. Nous avons un tas de croquis sous l'étiquette "apps/stateful" (par exemple : https://github.com/kubernetes/kubernetes/issues/23790, @philips un exemple etcd serait génial). Je n'ai pas encore écrit de docs, je le ferai vers les dernières semaines de la 1.3 (encore 5 semaines pour sortir une fois le code terminé vendredi).

Je suppose que vous allez essayer d'automatiser le basculement avec postgres car c'est assez courant. J'admets qu'actuellement ce n'est toujours pas aussi facile que je le souhaiterais, vous avez probablement besoin d'un chien de garde. @jberkus J'aimerais entendre des commentaires sur les modèles qui facilitent cela.

Pour vous donner un aperçu rapide, le petset vous offre aujourd'hui une identité de réseau cohérente (DNS, nom d'hôte) qui correspond à un volume monté sur le réseau et des garanties de commande. Donc, si vous créez un petset avec replicas: 3 , vous obtiendrez :
service de gouvernance : *.galear.default.svc.cluster.local
mysql-0 - volume0
mysql-1 - volume1 : ne démarre que lorsque 0 est en cours d'exécution et prêt
mysql-2 - volume2 : ne démarre pas avant 0, 1 est prêt

Les pods peuvent utiliser DNS pour la découverte de services en recherchant les enregistrements SRV insérés sous le service de gouvernance. C'est ce que fait ce pod simple : https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62. Donc, si vous utilisez le peer-finder via un conteneur d'initialisation comme dans les exemples ci-dessus, mysql-1 ne démarrera pas tant que le conteneur d'initialisation ne verra pas (mysql-1, mysql-0) dans DNS et n'écrira pas la configuration appropriée.

Les volumes sont provisionnés par un approvisionneur dynamique (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md), donc si vous n'en avez pas s'exécutant dans votre cluster mais que vous souhaitez simplement prototyper, vous pouvez simplement utiliser emptyDir. Le cas "data-gravity" (https://github.com/kubernetes/kubernetes/issues/7562) ne fonctionne pas encore, mais finira par le faire.

J'ajouterai qu'il est actuellement plus facile de fournir une notification "au démarrage" avec une liste de pairs, via des conteneurs d'initialisation. Il est clair que nous exigeons également des notifications "en cas de modification". Actuellement, pour remarquer les changements d'appartenance au cluster, vous devez utiliser un pid1 personnalisé. Les espaces de noms pid partagés peuvent rendre cela plus facile, puisque vous pouvez ensuite utiliser un side-car, c'est aussi quelque chose qui doit simplement fonctionner.

J'ai un chien de garde, c'est le basculement du service qui est plus compliqué que je ne le souhaiterais. A tester, merci !

J'ai également besoin de prendre en charge etcd, il peut donc y avoir beaucoup de tests dans mon futur.

@ncdc Quel est le statut du code alpha pour cela ? J'aimerais commencer à tester / mettre en œuvre. Nous devons déployer un cluster cassandra très bientôt ici. Je peux le faire avec la base de code existante, mais ce serait bien de tester le petset.

Vous pouvez l'obtenir si vous construisez à partir de HEAD

@bprashanth a-t-il fusionné dans le

https://github.com/kubernetes/contrib/tree/master/pets

yaml intégré dans les chaînes d'annotation ? oof, aïe :(. merci cependant, je vais étudier la possibilité de créer un ensemble de cassandra.

c'est json. Il s'agit d'une fonctionnalité alpha ajoutée à un objet GA (conteneurs d'initialisation dans les pods).
@chrislovecnm travaille sur Cassandra, pourrait juste vouloir l'attendre.

@paralin voici ce sur quoi je travaille. Pas le temps de documenter et de le mettre dans le dépôt k8s maintenant, mais c'est un plan à long terme. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra Travaille pour moi localement, sur HEAD.

La dernière image C* de la démo fonctionne bien.

Nous avons un problème ouvert pour plus de documentation. Clin d'œil, coup de coude @bprashanth

Exemple de PetSets avec le cluster etcd [1].

[1] https://github.com/kubernetes/contrib/pull/1295

Assurez-vous de capturer les demandes de conception sur le document de proposition après avoir terminé l'examen

Le 30 juin 2016, à 01h25, Jan Chaloupka [email protected] a écrit :

Exemple de PetSets avec le cluster etcd [1].

[1] kubernetes/contrib#1295
https://github.com/kubernetes/contrib/pull/1295

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/kubernetes/kubernetes/issues/260#issuecomment-229594658 ,
ou couper le fil
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

les documents de petset sont https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md et https://github.com/kubernetes/kubernetes.github. io/tree/release-1.3/docs/user-guide/petset/bootstrapping , je prévois de fermer ce problème et d'en ouvrir un nouveau qui traite du passage de petset à la version bêta à moins que quelqu'un ne s'y oppose

https://github.com/kubernetes/kubernetes/issues/28718