Beachten Sie, dass wir Dienste wahrscheinlich auch in lbservice oder so umbenennen sollten, um sie von anderen Arten von Diensten zu unterscheiden.

Als Teil davon würde ich Serviceobjekte vom Core-Apiserver entfernen und die Verwendung anderer Load Balancer wie HAProxy und nginx erleichtern.

Es wäre schön, wenn die logische Definition eines Dienstes (die Abfrage und/oder der globale Name) auf verschiedene Weise verwendet/spezialisiert werden könnte - als einfacher Load Balancer, der über die Infrastruktur installiert wird, als funktionsreicherer Load Balancer wie nginx oder Haproxy, das auch von der Infrastruktur angeboten wird, als abfragbarer Endpunkt, auf den ein Integrator abfragen/warten könnte (GET /services/foo -> { endpoints: [{host, port}, ...] }), oder als Informationen, die Hosts zur Verfügung stehen lokale Load Balancer verfügbar zu machen. Offensichtlich können dies mehrere verschiedene Anwendungsfälle sein und als solche in ihre eigenen Ressourcen aufgeteilt werden, aber eine gewisse Flexibilität bei der Angabe der Absicht (Vereinheitlichung unter einem lb) getrennt vom Mechanismus macht es einfacher, eine Vielzahl von Anforderungen zu erfüllen.

@smarterclayton Ich stimme der Trennung von Richtlinie und Mechanismus zu.

Primitive, die wir brauchen:

1. Die Möglichkeit, ein Set abzurufen/zu beobachten, das von einem Label-Selektor identifiziert wurde. Ich bin mir nicht sicher, ob noch ein Problem eingereicht wurde.
2. Die Möglichkeit, Pod-IP-Adressen abzufragen (#385).

Dies würde ausreichen, um mit anderen Benennungs-/Ermittlungsmechanismen und/oder Load-Balancern zu komponieren. Wir könnten dann eine übergeordnete Schicht auf dem Kern aufbauen, die gängige Muster mit einer einfachen API bündelt.

Lohnt es sich bei den beiden von

Ich glaube nicht, dass Zookeeper gelöst ist - da Sie die eindeutige Kennung in jedem Container benötigen. Ich _glaube_, dass Sie dies mit 3 separaten Replikationscontrollern (einer pro Instanz) oder einem Modus auf dem Replikationscontroller tun könnten.

Das Service-Design verdient meiner Meinung nach einige Diskussionen, wie Brian bemerkt. Derzeit koppelt es eine Infrastrukturabstraktion (lokaler Proxy) mit einem Mechanismus für die Offenlegung (Umgebungsvariablen in allen Containern) mit einer Label-Abfrage. Es gibt einen ebenso gültigen Anwendungsfall für einen Edge-Proxy, der L7-Hosts/-Pfade nimmt und sie auf eine Label-Abfrage abgleicht sowie Protokolle wie http(s) und Web-Sockets unterstützt. Darüber hinaus haben Dienste heute eine harte Skalierungsgrenze von 60.000 Back-Ends, die über den gesamten Cluster (die Anzahl der zugewiesenen IPs) gemeinsam genutzt werden. Es sollte möglich sein, einen lokalen Proxy auf einem Minion auszuführen, der nur die Dienste durchführt, die die Container auf diesem Host benötigen, und es sollte auch vermieden werden, dass Container den externen Port kennen müssen. Wir können diese Diskussion bei Bedarf auf #494 verschieben.

Bewältigung des Problems von Singleton-Diensten und nicht automatisch skalierten Diensten mit fester Replikation, wie z. B. Master-Slave-replizierte Datenbanken, Schlüsselwertspeicher mit Peer-Gruppen fester Größe (z.

Die Fälle mit fester Replikation erfordern ein vorhersagbares Array-ähnliches Verhalten. Peers müssen sich entdecken und individuell ansprechen können. Diese Dienste haben im Allgemeinen ihre eigenen Clientbibliotheken und/oder Protokolle, sodass wir das Problem der Bestimmung, mit welcher Instanz sich ein Client verbinden soll, nicht lösen müssen, außer die Instanzen einzeln adressierbar zu machen.

Vorschlag: Wir sollten eine neue Art von Dienst entwickeln, die sogenannten Cardinal-Dienste, die N IP-Adressen statt nur einer abbilden. Cardinal-Dienste würden eine stabile Zuweisung dieser IP-Adressen zu N Instanzen durchführen, auf die ihr Label-Selektor abzielt (dh ein spezifiziertes N, nicht nur, wie viele Ziele zufällig existieren). Sobald wir DNS ( #1261, #146 ) haben, würde es vorhersagbare DNS-Namen basierend auf einem bereitgestellten Präfix mit den Suffixen 0 bis N-1 zuweisen. Die Zuweisungen könnten in Anmerkungen oder Beschriftungen der Ziel-Pods aufgezeichnet werden.

Dies würde die Entkopplung der Rollenzuweisung von den Identitäten von Pods und Replikationscontrollern bewahren und gleichzeitig stabile Namen und IP-Adressen bereitstellen, die in Standardmechanismen für die Anwendungskonfiguration verwendet werden könnten.

Einige der Diskussionen über verschiedene Arten des Lastenausgleichs fanden im Design von Services v2 statt: #1107.

Ich werde eine separate Ausgabe für die Meisterwahl einreichen.

/cc @smarterclayton @tockin

Die Zuweisungen müssten über einen Umgebungsparametrisierungsmechanismus (fast sicher) in die Pods übertragen werden.

Für das etcd-Beispiel würde ich Folgendes erstellen:

• Kardinalität des Replikationscontrollers 1: 1 Pod, der auf ein stabiles Speichervolumen A hinweist
• Kardinalität des Replikationscontrollers 2: 1 Pod, der auf ein stabiles Speichervolumen verweist B
• Kardinalität des Replikationscontrollers 3: 1 Pod, der auf ein stabiles Speichervolumen C hinweist
• Kardinaldienst 'etcd' zeigt auf die Schoten

Wenn Pod 2 stirbt, erstellt Replikations-Controller 2 eine neue Kopie davon und fügt sie wieder an Volume B an. Der Kardinaldienst 'etcd' weiß, dass dieser Pod neu ist, aber woher weiß er, dass es Kardinalität 2 sein sollte (was aus gespeicherten Daten stammt) auf Band B)?

Anstelle von 3 Replikationscontrollern, warum nicht ein Sharding-Controller, der
schaut bei Entscheidungen auf ein Label wie "kubernetes.io/ShardIndex". Wenn
Sie möchten 3-Wege-Sharding, es macht 3 Pods mit den Indizes 0, 1, 2. Ich fühle mich wie
das wurde schon einmal abgeschossen, aber ich kann die Probleme nicht rekonstruieren, die es verursacht hat
mein Kopf.

Es scheint einfach falsch, diese Last den Benutzern aufzuerlegen, wenn dies relativ ist
gemeinsames Szenario.

Glauben Sie, dass es wichtig ist, wenn sich die nominale IP für einen bestimmten Pod aufgrund von . ändert?
nicht damit verbundene Änderungen im Set? Beispielsweise:

zum Zeitpunkt 0 bilden Pods (A, B, C) einen Kardinaldienst mit IPs
10.0.0.{1-3} bzw.

zum Zeitpunkt 1 stirbt der Knoten, der Pod B hostet

zum Zeitpunkt 2 erstellt der Replikationscontroller, der B antreibt, einen neuen Pod D

zum Zeitpunkt 3 ändert sich der Kardinaldienst zu (A, C, D) mit IPs 10.0.0.{1-3}
bzw

Hinweis: Die "stabile IP" von Pod C wurde von 10.0.0.3 auf 10.0.0.2 geändert, wenn das Set
Mitgliedschaft geändert. Ich gehe davon aus, dass dies dem Laufen schadet
Verbindungen.

Um dies zu umgehen, müssten wir die Ordinalwerte angeben
außerhalb des Dienstes, oder etwas anderes Gescheites. Vielleicht ist das in Ordnung, aber es
scheint zerbrechlich und leicht falsch zu machen, wenn die Leute damit umgehen müssen.

Am Donnerstag, 2. Oktober 2014 um 10:17 Uhr, Clayton Coleman [email protected]
schrieb:

Die Aufgaben müssten über einige in die Pods übertragen werden
Umgebungsparametrisierungsmechanismus (fast sicher).

Für das etcd-Beispiel würde ich Folgendes erstellen:

• Kardinalität des Replikationscontrollers 1: 1 Pod, der auf Stable zeigt
  Speichervolumen A
• Kardinalität des Replikationscontrollers 2: 1 Pod, der auf Stable zeigt
  Speichervolumen B
• Kardinalität des Replikationscontrollers 3: 1 Pod, der auf Stable zeigt
  Speichervolumen C
• Kardinaldienst 'etcd' zeigt auf die Schoten

Wenn Pod 2 stirbt, erstellt Replikationscontroller 2 eine neue Kopie davon und
fügt es wieder an Band B an. Der Kardinaldienst 'etcd' weiß, dass dieser Pod
neu, aber woher weiß es, dass es Kardinalität 2 sein sollte (die von
Daten auf Band B) gespeichert?

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

Ich denke, ein Sharding-Controller ist sinnvoll und im Kontext eines Kardinaldienstes wahrscheinlich nützlicher.

Ich denke, dass IP-Änderungen aufgrund der Mitgliedschaft beängstigend sind, und ich kann mir eine Reihe degenerierter Randfälle vorstellen. Wenn die Kardinalität jedoch mit den Pods gespeichert wird, ist die Entscheidung weniger schwer.

Zunächst einmal wollte ich nicht, dass es hier um Sharding geht – das ist #1064. Verschieben wir Sharding-Diskussionen dorthin. Wir haben viele Fälle erlebt, in denen versucht wurde, einen analogen Mechanismus für das Sharding zu verwenden, und wir kamen zu dem Schluss, dass dies nicht der beste Weg ist, Sharding zu implementieren.

Zweitens soll es nicht notwendig sein, N Replikationscontroller auszuführen. Es sollte möglich sein, nur einen zu verwenden, obwohl die erforderliche Anzahl von den Bereitstellungsdetails abhängt (Canaries, mehrere Release-Tracks, Rolling Updates usw.).

Drittens stimme ich zu, dass wir überlegen müssen, wie dies mit dem Vorschlag für dauerhafte Daten (#1515) interagieren würde – @erictune .

Viertens, ich stimme zu, dass wir wahrscheinlich die Identität in der Kapsel widerspiegeln müssen. Gemäß Nr. 386 würde idealerweise ein Standardmechanismus verwendet, um die IP- und DNS-Namenszuweisungen für den Pod sichtbar zu machen. Wie würden IP- und Host-Aliasnamen normalerweise in Linux auftauchen?

Fünftens schlug ich vor, dass wir die Stabilität der Aufgaben sicherstellen, indem wir Aufgaben in den Pods über Labels oder Anmerkungen aufzeichnen.

Sechstens besteht das Problem bei einem "Sharding-Controller", der den Replikationscontroller ersetzt, darin, dass ich die Rollenzuweisung von der Image-/Umgebungsverwaltung entkoppeln möchte. Ich sehe den Replikationscontroller als Bereitstellung des letzteren (siehe https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564).

Bei dauerhaften Daten gemäß #1515:

1. Für haltbare Pods würde dieser Vorschlag einfach funktionieren. Die Zuweisung wäre für die langlebige Kapsel stabil.
2. Für separate Datenobjekte müsste der Kardinaldienst auch die Rollenzuweisung für die Datenobjekte verwalten und würde die Rollenzuweisung an die Pods aufschieben, bis sie mit den Daten abgeglichen wurden. Ich denke, das wäre einfach.

/cc @erictune

Ich glaube, Sie wollten das Gespräch einfacher machen, aber ich bin mir nicht sicher, ob es funktioniert hat.

Re: Sharding - ist "ein Satz von Replikaten mit unterschiedlicher Identität" nicht im Grunde Sharding?

Betreff: 1 Replikationscontroller - wir haben heute keine Replikationscontroller, die Indizes zuordnen. Ich glaube nicht, dass wir das wollen, oder?

Re: Dem Pod seine eigene Identität mitteilen - Service ist eine saubere Schicht über dem Pod. Es wäre chaotisch, einen Dienst über einen bevorstehenden Pod zu informieren, damit er eine IP zuweisen könnte, bevor er existiert. Ich denke, die ID muss Teil des Pods sein, zB ein ShardIndex-Label oder so. Wir können das (irgendwie) in den Pod einfließen lassen und der Dienst kann dies zum Zuweisen von IP verwenden. Wenn wir dies dem Cardinal-Dienst selbst überlassen, ist der Pod zum Zeitpunkt der Zuweisung bereits gestartet. Wir könnten Metadaten pro Pod haben, wie wir es bei VMs in GCE tun, aber das ist ein größerer Vorschlag.

Nein, die Bereitstellung stabiler, eindeutiger Identitäten ist für das Sharding weder notwendig noch ausreichend. Siehe #1064 für Details, die ich gerade dort hinzugefügt habe.

Nein, wir möchten nicht, dass der Replikationscontroller Indizes zuweist. Ich habe absichtlich vorgeschlagen, dass die Kardinaldienste dies stattdessen tun.

Ja, ich erwarte, dass Pods existieren (und möglicherweise gestartet wurden), bevor ihnen Rollen (Indizes) zugewiesen werden. Das war Absicht. Eine Abtretung muss auch wieder rückgängig gemacht werden können.

Möglicher Identitätsansatz: Erstellen Sie einen nicht persistenten IP-Alias ​​im Container und stellen Sie in der DNS-Implementierung eine Reverse-DNS-Suche bereit.

Ich glaube jedoch, dass es für viele Anwendungsfälle nicht unbedingt erforderlich ist, die Identität in die Pod-Container zu übertragen. Wenn die Anwendung die Selbstregistrierung verwendet, benötigt sie diesen Mechanismus wahrscheinlich nicht einmal.

Wenn der Servicemanager bereit ist, einen anderen Status als das, was er ist, zu behalten?
derzeit tut, können wir uns nur an die zuvor erstellten Mappings erinnern
und versuche, sie zu respektieren.

Am Do, 2. Oktober 2014 um 20:59 Uhr schrieb bgrant0607 [email protected] :

Möglicher Identitätsansatz: Erstellen Sie einen nicht persistenten IP-Alias ​​im
Container und bieten Reverse-DNS-Lookup in der DNS-Implementierung.

Ich glaube jedoch nicht, dass die Identität in die Pod-Container eindringt
für viele Anwendungsfälle unverzichtbar. Wenn die Anwendung verwendet
Selbstregistrierung, es braucht diesen Mechanismus wahrscheinlich nicht einmal.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

Betreff. Wenn ich mich an die Zuordnungen erinnere, stimme ich zu - siehe https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787.

Ich weiß jedoch nicht, inwiefern das für den Kommentar relevant ist, auf den Sie geantwortet haben.

GitHub und E-Mail passen nicht zusammen. Verzeihung

Am Do, 2. Oktober 2014 um 21:39 Uhr schrieb bgrant0607 [email protected] :

Betreff. Wenn ich mich an die Zuordnungen erinnere, stimme ich zu - siehe #260 (Kommentar)
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.

Ich weiß jedoch nicht, inwiefern das für den Kommentar relevant ist, auf den Sie geantwortet haben.

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

Tim schlug "nominal" vor, was meiner Meinung nach besser passt.

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

Ich mag auch nominell. Wird es hassen, es Benutzern zu erklären, aber es wird sehr oft für config-erstellte Dinge verwendet (dh ein nominaler Mongodb-Replikatsatz wird ein Replikationscontroller, ein nominaler Dienst, Volumes sein, also ist es bereits etwas komplex).

----- Originale Nachricht -----

Tim schlug "nominal" vor, was meiner Meinung nach besser passt.

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

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

Zwei Probleme sehe ich:

1. Die Rollenzuweisung beinhaltet das Festlegen von mindestens Umgebungsvariablen oder Volume-Einstellungen pro Pod (dh der erste Pod muss Volume a erhalten, und wenn er gelöscht wird, benötigt sein Ersatz dasselbe Volume).
2. Wenn die Pods für einen nominellen Dienst von einem einzelnen Replikat-Controller stammen, muss die Vorlage nach der Erstellung, aber vor dem Binden des Pods geändert werden.

Dies scheint zu implizieren, dass die Rollenzuweisung ein Controller ist, der als Workflow-Schritt zwischen dem Apiserver und dem Scheduler sitzt. Es impliziert auch eine Form der Transformation oder Überschreibung der Vorlage, sodass die Vorlage ohne die Rollenzuweisung nicht unbedingt sinnvoll ist.

Der Shard-Controller scheint eine Variante dieses Problems zu sein, nur für kompliziertere Rollenzuweisungen.

Beispiel für die Ausführung von Zookeeper mit einem Dienst pro Instanz: http://iocanel.blogspot.com/2014/10/zookeeper-on-kubernetes.html

Ich weiß also, dass dies ein langer alter Thread ist, aber er trifft ein Thema, das mir am Herzen liegt ;-)

Vorausgesetzt, das System kann Vorwärts- und Rückwärtsaufzeichnungen für nicht-nat'd "nominal-services" an skydns senden und Namen als ENV-Injection in die Pods verwenden, die diesen Service verwenden, gibt es andere Einschränkungen?

Im Fall von ZK, wo jedes Element im Quorum die anderen Elemente verwenden würde, kann es etwas seltsam aussehen, z.
zk1 verwendet: zk2, zk3
zk2 verwendet: zk1, zk3
zk3 verwendet: zk1, zk2

aber theoretisch sollte es funktionieren oder? Vorausgesetzt, wir können die umgekehrten Datensätze für die Nominalleistungen hinzufügen.

@bgrant0607 habe ich etwas verpasst?

Etwas seltsamer wird es, wenn andere Anwendungen den von ihnen bereitgestellten Gesamtdienst nutzen möchten. (https://github.com/GoogleCloudPlatform/kubernetes/issues/1542)

@timothysc Was Sie vorschlagen, würde funktionieren, wenn zk1, zk2 und zk3 Dienste wären, zumindest wenn Multi-Port-Dienste unterstützt werden.

Ja, aber hier ist ein Hässliches.

Ein laufender Pod weiß nicht, welche Dienste ihm "vorgeschaltet" sind. ZB einen Dienst gegeben
einer Backend-Instanz ist die für den Zugriff auf den Dienst verwendete VIP nicht bekannt
das Backend (es sei denn, es sucht diese Informationen, indem es den Dienst kennt
Name). In einem nominalen Dienst (N) hätten Sie N Back-Ends und N VIPs (und
vermutlich N DNS-Namen oder ein N-Adressname), aber die Backends würden es trotzdem tun
kennen ihre eigenen VIPs nicht. Sie könnten den Pool der DNS-Namen beobachten, aber
weiß nicht (ohne zu prüfen), wer man selbst ist. Dies würde Ihre ZK
Fall schwer, die VIPs zu verwenden (auch VIPs werden derzeit sichtbar proxied).

Alternativen:

1) Richten Sie 1 Dienst (N) ein und lassen Sie jede Instanz alle VIPs selbst prüfen

2) Richten Sie N service(1)-Instanzen ein und verwenden Sie Labels und cmdline-Flags, um
Indizes manuell zuweisen, jedem ZK-Backend (a priori) den DNS-Namen bekannt geben
voneinander ZK-Backend

3) Führen Sie DNS für Label-Selektoren durch, weisen Sie dem ZK-Replikatsatz einen DNS-Namen zu.
hoffe, dass die Clients DNS richtig verwenden

4) Führen Sie kube2zk-Bridges neben jedem ZK aus, das Kubernetes-Endpunkte synchronisiert ->
ZK-Konfiguration

5) Entwerfen Sie eine alternative Methode zur Zuweisung von VIPs oder Indizes, die mehr ist
Replikations-Controller-zentriert als service-zentriert. Brendan und ich
habe hier vor einiger Zeit ein paar Ideen gesammelt, aber keine Zeit gehabt, ihnen zu folgen
drauf drauf.

Was Reverse-DNS angeht - ich bin mir nicht sicher, ob ich die Rolle davon sehe? Ich bin nicht gegen
unterstützen (dh @bketelsen bitten,
gilt hier. Verkehr kommt nie "von" einer Dienst-IP.

Tim

Am Samstag, 7. März 2015 um 20:56 Uhr, Brian Grant [email protected]
schrieb:

@timothysc https://github.com/timothysc Was du vorschlägst, würde funktionieren, wenn
zk1, zk2 und zk3 waren Dienste, mindestens einmal Multi-Port-Dienste
unterstützt.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

(5) klingt nach diesem Vorschlag.

Ich bin ein großer Fan von 5 - die Pods, die wissen, dass ihre Rolle der erste Schritt ist, die Pods, die eine einzigartige DNS-Identifikation haben oder Endpunkte verwenden, um die IP anderer zu erhalten, und die darauf reagieren, sind zwei. In der Lage zu sein, die Pod-IP in Endpunkten anhand einer stabilen Rollen-ID nachzuschlagen, wäre an dritter Stelle.

Am 8. März 2015 um 11:06 Uhr schrieb Tim Hockin [email protected] :

Ja, aber hier ist ein Hässliches.

Ein laufender Pod weiß nicht, welche Dienste ihm "vorgeschaltet" sind. ZB einen Dienst gegeben
einer Backend-Instanz ist die für den Zugriff auf den Dienst verwendete VIP nicht bekannt
das Backend (es sei denn, es sucht diese Informationen, indem es den Dienst kennt
Name). In einem nominalen Dienst (N) hätten Sie N Back-Ends und N VIPs (und
vermutlich N DNS-Namen oder ein N-Adressname), aber die Backends würden es trotzdem tun
kennen ihre eigenen VIPs nicht. Sie könnten den Pool der DNS-Namen beobachten, aber
weiß nicht (ohne zu prüfen), wer man selbst ist. Dies würde Ihre ZK
Fall schwer, die VIPs zu verwenden (auch VIPs werden derzeit sichtbar proxied).

Alternativen:

1) Richten Sie 1 Dienst (N) ein und lassen Sie jede Instanz alle VIPs selbst prüfen

2) Richten Sie N service(1)-Instanzen ein und verwenden Sie Labels und cmdline-Flags, um
Indizes manuell zuweisen, jedem ZK-Backend (a priori) den DNS-Namen bekannt geben
voneinander ZK-Backend

3) Führen Sie DNS für Label-Selektoren durch, weisen Sie dem ZK-Replikatsatz einen DNS-Namen zu.
hoffe, dass die Clients DNS richtig verwenden

4) Führen Sie kube2zk-Bridges neben jedem ZK aus, das Kubernetes-Endpunkte synchronisiert ->
ZK-Konfiguration

5) Entwerfen Sie eine alternative Methode zur Zuweisung von VIPs oder Indizes, die mehr ist
Replikations-Controller-zentriert als service-zentriert. Brendan und ich
habe hier vor einiger Zeit ein paar Ideen gesammelt, aber keine Zeit gehabt, ihnen zu folgen
drauf drauf.

Was Reverse-DNS angeht - ich bin mir nicht sicher, ob ich die Rolle davon sehe? Ich bin nicht gegen
unterstützen (dh @bketelsen bitten,
gilt hier. Verkehr kommt nie "von" einer Dienst-IP.

Tim

Am Samstag, 7. März 2015 um 20:56 Uhr, Brian Grant [email protected]
schrieb:

@timothysc https://github.com/timothysc Was du vorschlägst, würde funktionieren, wenn
zk1, zk2 und zk3 waren Dienste, mindestens einmal Multi-Port-Dienste
unterstützt.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Dann muss ich mir etwas Zeit nehmen, um diese Idee noch etwas aufzuschreiben.

Am Sonntag, 8. März 2015 um 10:25 Uhr, Clayton Coleman [email protected]
schrieb:

Ich bin ein großer Fan von 5 - die Pods, die wissen, dass ihre Rolle der erste Schritt ist, die Pods
eine eindeutige DNS-Identifikation haben oder Endpunkte verwenden, um die IP-Adresse anderer zu erhalten und
darauf zu reagieren ist zwei. In der Lage sein, die Pod-IP in Endpunkten durch a . nachzuschlagen
stabile Rollen-ID wäre die dritte.

Am 8. März 2015, um 11:06 Uhr, Tim Hockin [email protected]
schrieb:

Ja, aber hier ist ein Hässliches.

Ein laufender Pod weiß nicht, welche Dienste ihm "vorgeschaltet" sind. ZB gegeben a
Service
einer Backend-Instanz ist die VIP, die für den Zugriff auf den Dienst verwendet wurde, nicht bekannt
durch
das Backend (es sei denn, es sucht diese Informationen, indem es den Dienst kennt
Name). In einem nominalen Dienst (N) hätten Sie N Back-Ends und N VIPs
(und
vermutlich N DNS-Namen oder ein N-Adressname), aber die Backends würden
still
kennen ihre eigenen VIPs nicht. Sie könnten den Pool der DNS-Namen beobachten, aber
weiß nicht (ohne zu prüfen), wer man selbst ist. Dies würde Ihre ZK
Fall schwer, die VIPs zu verwenden (auch VIPs werden derzeit sichtbar proxied).

Alternativen:

1) Richten Sie 1 Dienst (N) ein und lassen Sie jede Instanz alle VIPs selbst prüfen

2) Richten Sie N service(1)-Instanzen ein und verwenden Sie Labels und cmdline-Flags, um
Indizes manuell zuweisen, jedem ZK-Backend (a priori) das DNS bekannt machen
Name
voneinander ZK-Backend

3) Führen Sie DNS für Label-Selektoren durch, weisen Sie dem ZK-Replikatsatz einen DNS-Namen zu.
hoffe, dass die Clients DNS richtig verwenden

4) Führen Sie kube2zk-Bridges neben jedem ZK aus, das Kubernetes-Endpunkte synchronisiert
->
ZK-Konfiguration

5) Entwerfen Sie eine alternative Methode zur Zuweisung von VIPs oder Indizes, die mehr ist
Replikations-Controller-zentriert als service-zentriert. Brendan und ich
habe hier vor einiger Zeit ein paar Ideen gesammelt, hatte aber keine Zeit dafür
Folgen
drauf drauf.

Was Reverse-DNS angeht - ich bin mir nicht sicher, ob ich die Rolle davon sehe? Ich bin nicht gegen
unterstützen (dh @bketelsen bitten,
gilt hier. Verkehr kommt nie "von" einer Dienst-IP.

Tim

Am Samstag, 7. März 2015 um 20:56 Uhr, Brian Grant [email protected]
schrieb:

@timothysc https://github.com/timothysc Was du vorschlägst, würde funktionieren
wenn
zk1, zk2 und zk3 waren Dienste, mindestens einmal Multi-Port-Dienste
unterstützt.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>

.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

@thockin re: Reverse-DNS, lass uns einfach mit den Händen winken und es als Voraussetzung betrachten.

ZK wird ohne sie kaputt gehen, wie viele andere verteilte Systeme auch.

RC, der jedem erstellten Pod ein eindeutiges Label (members=#) zugewiesen hat und versucht, eine Sequenz von bis zu N Replikaten zu erstellen, und dann einen Headless-Dienst, der einen A- und CNAME-Namen für jeden Wert des "member"-Labels erstellt hat (# .service.namespace.local), wobei die Wurzel all diese Dienste bedient.namespace.local -> Round-Robin -> 1.service.namespace.local, 2.service.namespace.local scheint lokal zu sein.

Wir _könnten_ strikte Pod-IPs für diese einzelnen DNS-Labels verwenden. Das Erstellen von gefälschten IPs für jeden einzelnen wird teuer und der Container kann nicht in der Lage sein, seine eigene IP an jemanden zu senden.

----- Originale Nachricht -----

@thockin re: Reverse DNS, lass uns einfach mit den Händen ansehen
Erfordernis.

ZK wird ohne sie kaputt gehen, wie viele andere verteilte Systeme auch.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

@timothysc re: Reverse DNS - Was ist Reverse DNSing? Die Quell-IP von
Verbindungen? Nichts davon funktioniert in kube. Verbindungen über Dienste sind
proxied, so dass die Quell-IP überhaupt nicht funktioniert (könnte behoben werden).

Ich kenne ZK nicht - kannst du erklären, was sie mit dem Rückwärtsgang erreichen wollen?
DNS? Es scheint eine sehr fragile Annahme zu sein.

Am Mo, 9. März 2015 um 9:05 Uhr, Timothy St. Clair [email protected]
schrieb:

@tockin https://github.com/tockin re: Reverse DNS, lass uns einfach winken
unsere Hände um und halten es für eine Voraussetzung.

ZK wird ohne sie kaputt gehen, wie viele andere verteilte Systeme auch.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

Ich denke, meine Erfahrung (und vielleicht die von Tim) ist, dass die Mehrheit der geclusterten Software heute Folgendes erwartet:

• jeder Knoten hat eine stabile Identität
• diese Identität ist ein DNS-Name
• die IP der zugrunde liegenden Identität muss nicht stabil sein
• der Knoten erwartet, sich gegenüber anderen Knoten entweder durch seine stabile Identität (DNS) oder seine öffentliche IP zu identifizieren
• Einige der geclusterten Software erwarten, dass die IP des Knotens, auf dem ein Client sie erreicht, mit einer IP übereinstimmt, die sie anderen im Cluster mitteilen kann, und dass diese IP erreichbar ist.

----- Originale Nachricht -----

@timothysc re: Reverse DNS - Was ist Reverse DNSing? Die Quell-IP von
Verbindungen? Nichts davon funktioniert in kube. Verbindungen über Dienste sind
proxied, so dass die Quell-IP überhaupt nicht funktioniert (könnte behoben werden).

Ich kenne ZK nicht - kannst du erklären, was sie mit dem Rückwärtsgang erreichen wollen?
DNS? Es scheint eine sehr fragile Annahme zu sein.

Am Mo, 9. März 2015 um 9:05 Uhr, Timothy St. Clair [email protected]
schrieb:

@tockin https://github.com/tockin re: Reverse DNS, lass uns einfach winken
unsere Hände um und halten es für eine Voraussetzung.

ZK wird ohne sie kaputt gehen, wie viele andere verteilte Systeme auch.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

Am Mo, 9. März 2015 um 12:49 Uhr, Clayton Coleman
[email protected] schrieb:

RC, der jedem erstellten Pod ein eindeutiges Label (members=#) zugewiesen hat und versucht, eine Sequenz bis zu zu erstellen
N Replikate und dann ein Headless-Dienst, der einen A- und CNAME-Namen für jeden Wert von "member" erstellt hat
Label (#.service.namespace.local), wobei die Wurzel all diese Dienste bedient.namespace.local -> round
robin -> 1.service.namespace.local, 2.service.namespace.local scheint lokal zu sein.

Die Idee, dass Brendan und ich herumhüpften, war im Grunde ein Pool
von Token, vielleicht ein Teil von RC, vielleicht nicht, dass jedes Element eines RC
zugewiesen bekommen würde. Angesichts dieses Tokens könnten andere Dinge zugewiesen werden

• VIPs, PDs, generische Indizes usw. Das Schöne ist, wenn ein Pod
  stirbt, wird der Marker in den Pool zurückgegeben und wenn dieser Pod ersetzt wird
  dieses Token wird wiederverwendet.

Das Problem besteht darin, herauszufinden, wie man "willkürliche Token" in umwandelt
etwas Sinnvolles.

Wir _könnten_ strikte Pod-IPs für diese einzelnen DNS-Labels verwenden. Das Erstellen von gefälschten IPs für jeden einzelnen wird teuer und der Container kann nicht in der Lage sein, seine eigene IP an jemanden zu senden.

Ich habe es nicht versucht, aber ich wette, wir könnten die nominalen Dienste voll machen SNAT
und DNAT, da sie 1:1 sind. Dies wäre ein Weg, um stabil zu werden
IPs pro Pod ohne migrierbare IPs.

----- Originale Nachricht -----

@thockin re: Reverse DNS, lass uns einfach mit den Händen ansehen
Erfordernis.

ZK wird ohne sie kaputt gehen, wie viele andere verteilte Systeme auch.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Es liegt mir fern, stromaufwärts zu schwimmen – wenn genug Apps wirklich DNS erwarten
so arbeiten, können wir es so machen.

Skizzieren:

Beim Erstellen eines Replikationscontrollers R wird ein DNS-Name "$R.rc" erstellt, der der
Pool von Pod-IPs, die sich "unter" diesem RC befinden. Jeder Pod P erhält einen DNS-Namen
"$P.$R.rc". Aber was ist P? Es könnten einfache Indizes sein, aber das hat
hat uns innerlich hart gebissen. Es könnten zufällige Zeichenfolgen wie GenerateName sein,
aber sie müssen den Tod/Neustart des Pods überleben (und vielleicht sollten Pod-Hostnamen das sollten)
Spiel?).

Am Dienstag, 10. März 2015 um 7:59 Uhr, Clayton Coleman [email protected]
schrieb:

Ich denke, meine Erfahrung (und vielleicht die von Tim) ist, dass die Mehrheit der Cluster
Software erwartet heute Folgendes:

• jeder Knoten hat eine stabile Identität
• diese Identität ist ein DNS-Name
• die IP der zugrunde liegenden Identität muss nicht stabil sein
• der Knoten erwartet, sich gegenüber anderen Knoten entweder durch seine stabile
  Identität (DNS) oder seine öffentliche IP
• Einige der geclusterten Software erwarten die IP des Knotens eines Clients
  erreicht es weiter, um eine IP abzugleichen, die es anderen in der bekannt geben kann
  Cluster und damit diese IP erreichbar ist.

----- Originale Nachricht -----

@timothysc re: Reverse DNS - Was ist Reverse DNSing? Die Quell-IP von
Verbindungen? Nichts davon funktioniert in kube. Verbindungen über Dienste sind
proxied, so dass die Quell-IP überhaupt nicht funktioniert (könnte behoben werden).

Ich kenne ZK nicht - kannst du erklären, was sie mit dem Rückwärtsgang erreichen wollen?
DNS? Es scheint eine sehr fragile Annahme zu sein.

Am Mo, 9. März 2015 um 9:05 Uhr, Timothy St. Clair <
[email protected]>
schrieb:

@tockin https://github.com/tockin re: Reverse DNS, lass uns einfach winken
unsere Hände um und halten es für eine Voraussetzung.

ZK wird ohne sie kaputt gehen, wie viele andere verteilte Systeme auch.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:

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

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

Ich mag es, wenn DNS eher an nominale Dienste als an RC angehängt wird.

Was war intern der Schmerzpunkt bei einfachen Indizes? P > 5000?

----- Originale Nachricht -----

Es liegt mir fern, stromaufwärts zu schwimmen – wenn genug Apps wirklich DNS erwarten
so arbeiten, können wir es so machen.

Skizzieren:

Beim Erstellen eines Replikationscontrollers R wird ein DNS-Name "$R.rc" erstellt, der der
Pool von Pod-IPs, die sich "unter" diesem RC befinden. Jeder Pod P erhält einen DNS-Namen
"$P.$R.rc". Aber was ist P? Es könnten einfache Indizes sein, aber das hat
hat uns innerlich hart gebissen. Es könnten zufällige Zeichenfolgen wie GenerateName sein,
aber sie müssen den Tod/Neustart des Pods überleben (und vielleicht sollten Pod-Hostnamen das sollten)
Spiel?).

Am Dienstag, 10. März 2015 um 7:59 Uhr, Clayton Coleman [email protected]
schrieb:

Ich denke, meine Erfahrung (und vielleicht die von Tim) ist, dass die Mehrheit der Cluster
Software erwartet heute Folgendes:

• jeder Knoten hat eine stabile Identität
• diese Identität ist ein DNS-Name
• die IP der zugrunde liegenden Identität muss nicht stabil sein
• der Knoten erwartet, sich gegenüber anderen Knoten entweder durch seine stabile
  Identität (DNS) oder seine öffentliche IP
• Einige der geclusterten Software erwarten die IP des Knotens eines Clients
  erreicht es weiter, um eine IP abzugleichen, die es anderen in der bekannt geben kann
  Cluster und damit diese IP erreichbar ist.

----- Originale Nachricht -----

@timothysc re: Reverse DNS - Was ist Reverse DNSing? Die Quell-IP von
Verbindungen? Nichts davon funktioniert in kube. Verbindungen über Dienste sind
proxied, so dass die Quell-IP überhaupt nicht funktioniert (könnte behoben werden).

Ich kenne ZK nicht - kannst du erklären, was sie mit dem Rückwärtsgang erreichen wollen?
DNS? Es scheint eine sehr fragile Annahme zu sein.

Am Mo, 9. März 2015 um 9:05 Uhr, Timothy St. Clair <
[email protected]>
schrieb:

@tockin https://github.com/tockin re: Reverse DNS, lass uns einfach winken
unsere Hände um und halten es für eine Voraussetzung.

ZK wird ohne sie kaputt gehen, wie viele andere verteilte Systeme auch.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:

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

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

+1 für 1:1 VIPs mit Spezialgehäuse. Ich denke, das wird ein häufiger Fall sein.

Ich mache mir immer noch Sorgen, DNS-Zuordnungen dynamisch zu ändern. Ich würde einen Ansatz bevorzugen, der das nicht erfordert.

Bei der Bewertung von Alternativen ist zu beachten, dass ich zu 100 % sicher bin, dass wir irgendwann zwei Pods mit derselben Rolle brauchen werden, um gleichzeitig zu koexistieren, den alten und den neuen. Daher kann die Rolle weder an den Objektnamen noch an etwas anderes gebunden werden, das sowohl eindeutig sein muss als auch zum Zeitpunkt der Pod-Erstellung in Stein gemeißelt werden muss.

Wenn wir den Rollenzuweisungsmechanismus an den Replikationscontroller binden, schließt dies Rolling Updates, Canaries usw. so gut wie aus. Das möchte ich nach Möglichkeit vermeiden.

@smarterclayton Einfache Indizes sind aufgrund der Skalierung nicht problematisch. Das liegt am Modell. Siehe meine Kommentare von vor ein paar Minuten. Einfache Indizes sind der richtige Weg, wenn sie unabhängig von Pod- und RC-Identität dynamisch zugewiesen werden können.

Da eines der Probleme systemorientierte Annahmen sind, kann Linux hier etwas für uns tun? Könnten wir beispielsweise einen IP-Alias ​​oder ähnliches im Container für den Service-VIP erstellen?

Hallo Leute,

Ich bin die ganze Woche unterwegs. Das ist ein wirklich lustiges Gespräch, aber es erfordert
mehr Zeit als ich zur Verfügung habe. Ich würde gerne sitzen und in echt diskutieren
nächste Woche Zeit.

Am Dienstag, 10. März 2015 um 15:56 Uhr, Brian Grant [email protected]
schrieb:

Da eines der Probleme systemorientierte Annahmen sind, gibt es da
könnte Linux hier etwas für uns tun? Könnten wir zum Beispiel eine IP erstellen
Alias ​​oder so im Container für den Dienst VIP?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

Ich habe die nächsten zwei Tage keine Tasche mehr - nächste Woche ist es soweit.

Am 10. März 2015 um 23:33 Uhr schrieb Tim Hockin [email protected] :

Hallo Leute,

Ich bin die ganze Woche unterwegs. Das ist ein wirklich lustiges Gespräch, aber es erfordert
mehr Zeit als ich zur Verfügung habe. Ich würde gerne sitzen und in echt diskutieren
nächste Woche Zeit.

Am Dienstag, 10. März 2015 um 15:56 Uhr, Brian Grant [email protected]
schrieb:

Da eines der Probleme systemorientierte Annahmen sind, gibt es da
könnte Linux hier etwas für uns tun? Könnten wir zum Beispiel eine IP erstellen
Alias ​​oder so im Container für den Dienst VIP?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

+1 für nächste Woche, vielleicht ein Treffpunkt.

Diesen Thread erneut anstoßen, da verwandte Themen auftauchen (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. Wie weisen wir einzelnen Pods, die Singletons oder Teil eines Nominalsets sein können, Netzwerkidentitäten (DNS-Namen und/oder IP-Adressen) zu?
2. Wie übermitteln wir die Identität an Container innerhalb eines Pods?

Sollen wir einen Hangout planen oder einen wöchentlichen Community-Hangout nutzen?

Auch https://github.com/openshift/mongodb/pull/14, mit dem wir beginnen, einen Prototyp für ein generisches Muster für die Initialisierung von Mitgliedschaftssätzen zu erstellen (etwas, das wir entweder in einen Container oder eine Bibliothek legen können oder ...)

@danmcp @mfojtik

----- Originale Nachricht -----

Ich stoße diesen Thread erneut an, da ähnliche Themen auftauchen
( 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. Wie weisen wir Netzwerkidentitäten (DNS-Namen und/oder IP-Adressen) zu
   einzelne Schoten, die Singletons oder Teil eines Nominalsets sein können?
2. Wie übermitteln wir die Identität an Container innerhalb eines Pods?

Sollen wir einen Hangout planen oder einen wöchentlichen Community-Hangout nutzen?

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

IIUC, ein Teil dieses Puzzles ist die Meisterwahl Nr. 1542.

Ja, wir haben darüber gesprochen. Für die meisten Cluster, die ihre eigenen Wahlen durchführen können, ist die Mitgliedschaft am wichtigsten (Mitgliedschaft von Kube-Endpunkten erkennen, auf Cluster anwenden), aber es gibt immer verschiedene Möglichkeiten, dies zu erreichen. Cassandra zum Beispiel verwendet Kube im Grunde als externe Quelle der Wahrheit für die Mitgliedschaft, also ist es SEP und das erleichtert die Wahl der Führungsspitze. Obwohl ich glaube, dass Sie je nach Verzögerung der Mitglieder eine Partition erhalten könnten, wenn die Mitgliedschaft schwankt.

Für mongo möchten Sie jedes der Mitglieder kontaktieren und sie entweder einem bestehenden Cluster beitreten oder einen neuen Cluster bilden. Wenn mehrere Cluster vorhanden sind, möchten Sie diese nicht verschlechtern.

Beachten Sie, dass das Problem der Übermittlung einer Dienst-IP an einen Container ähnlich der Übermittlung einer externen IP an eine VM ist: https://cloud.google.com/compute/docs/networking. GCE übersetzt die externen Adressen in/von internen Adressen, und externe Adressen werden über den Metadatenserver kommuniziert: http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip . AWS ist ähnlich: http://169.254.169.254/latest/meta-data/public-ipv4 .

@smarterclayton Ich habe den Mongo-Prototyp-PR aktualisiert: https://github.com/openshift/mongodb/pull/17

Es verwendet jetzt einen One-Shot-Pod, der das ReplicaSet initialisiert

Betreff. Binden dieses Mechanismus an den Replikations-/Shard-Controller:

Das Ausprobieren von DNS-Namen für Replikationscontroller und/oder für Pod-Objektnamen erzwingt ein direktes Aktualisierungsmodell. Eine völlig andere Art von "in-place" Rolling Update müsste implementiert werden, während irgendwie mehrere Templates gleichzeitig mit einem einzigen Controller unterstützt werden. Es würde auch bedeuten, dass Pods gelöscht und dann mit den gleichen Namen neu erstellt werden müssten, um einige Arten von Updates (einschließlich des Verschiebens auf neue Hosts) durchzuführen, was die Ausfallzeit im Vergleich zu dem Ansatz erhöhen würde, bei dem wir einen neuen hinzufügen Pod, bevor Sie einen alten wegnehmen.

Die Token-Pool-Idee klingt großartig. Ich denke nur, es muss von RCs entkoppelt werden.

Dies könnte an eine übergeordnete Steuerung gekoppelt werden, wenn wir eine hinzufügen würden. Werde weiter zu #1743 und/oder #503 kommentieren.

Dies sollte nicht wirklich an den in #1743 vorgeschlagenen DeploymentController gekoppelt werden. Es würde weder für das Szenario mehrerer unabhängiger Release-Tracks funktionieren, noch für den Fall, dass jemand seine Rollouts mit einem anderen Mechanismus steuern wollte, wie zum Beispiel das vorgeschlagene Rolling-Update mit Namenstausch. Aus ähnlichen Gründen würde ich die DNS-Namen nicht an Pod-/RC-/DC-Objektnamen binden.

Wir sind also zurück zu einer Art Service oder einem völlig separaten Controller. Vielleicht könnte der Endpunkt-Controller den Dienstendpunkten Indizes zuweisen? Ist Endpoints selbst ein ausreichend zuverlässiger Ort, um diese Daten aufzuzeichnen? Bei Verlust würden alle Pods neu indiziert.

Um die Kommunikation der Identität bis hinunter zu den Containern im Pod zu erleichtern (z. B. über die in #2316 diskutierte Ersetzung der Umgebungsvar.), wäre es nützlich, ein Feld im Pod festzulegen, wenn die Rolle über eine Unterressource zugewiesen/nicht zugewiesen wurde. Das könnte auch das Haltbarkeitsproblem lösen.

Wir sollten Platz im DNS-Schema für nominale Instanzen reservieren – #6666.

Ich könnte kaufen, dass wir versuchen könnten, Pod-IPs zu verwenden und nur DNS für nominale Instanzen neu zuzuordnen, per https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406.

Außerdem habe ich dies aus dem 1.0-Meilenstein im Februar entfernt (wenn auch nicht roadmap.md), aber die Diskussion in #6393 deutet darauf hin, dass es möglicherweise wieder hinzugefügt wird.

Vorgeschlagen von @thockin : Reverse Lookup mit DNS (PTR-Einträgen) sieht wie ein vernünftiger Weg aus, um von Pod-IPs zu nominalen DNS-Namen zu
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Ja, würde "Wer bin ich" mit Standardnamenstools wirklich einfach machen.

Am 10. April 2015 um 20:11 schrieb Brian Grant [email protected] :

Vorgeschlagen von @thockin : Reverse Lookup mit DNS (PTR-Einträgen) sieht wie ein vernünftiger Weg aus, um von Pod-IPs zu nominalen DNS-Namen zu
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

/Abonnieren

Ich bin mir nicht mehr sicher, ob ich die Anforderungen hier verstehe.

Zwischen Diensten und Pods besteht eine inhärente N-zu-M-Beziehung
Auslegung des Systems. Dinge wie Reverse-DNS erwarten im Allgemeinen, dass sie ein
einzelne Antwort: Erhalten Sie einen kanonischen Namen, wenn die IP eines Pods gegeben ist. Jedes geschriebene Dokument
über DNS sagt "nicht mehrere Reverse-Records zurückgeben". Da ein Pod sein kann
bei N Diensten kann diese einzelne Antwort nicht wirklich dienstbezogen sein. Wir
könnte einen Reverse-Lookup zu einem kanonischen Namen und dann einen TXT-Lookup darauf machen
Name für "unter welchen Diensten sind Sie", aber das ist schwer zu pflegen und ist
im Wesentlichen ein benutzerdefiniertes Protokoll sowieso.

Der Grund, warum ich dachte, den RCs nominal etwas beizufügen, ist, dass dies a . ist
konkretere Beziehung. Aber es ist nicht einmal. Ein Pod kann erstellt werden von
ein RC, verwaist, von einem anderen RC adoptiert und von diesem zerstört. Oder
manuell zerstört

Ich bin mir also nicht sicher, was wir damit machen wollen, außer die Anzahl zu begrenzen
von Diensten kann ein Pod "unter" sein, was sich schrecklich anhört.

Was sind die Verhaltensanforderungen? Was versuchen wir zu erreichen. Wir
kann einfache Set-Semantik mit DNS und Headless-Diensten bereitstellen. Ist dass
reicht aus? Wenn nicht, warum?

Wir könnten bis zum Äußersten gehen und iptables-Regeln für SNAT/DNAT-Pods einrichten
Service, damit sie sich alle auf VIPs sehen. ZB ein Set von Pods gegeben
(P1, P2, P3) würden sie VIPs bekommen (V1, V2, V3). Verkehr von P1 zu V2 würde
scheinen von V1 zu kommen usw. Clients würden auf V{1,2,3} zugreifen. Aber was
Problem löst das wirklich? Es gibt stabile IPs, aber ist das nicht so?
Allgemeines Problem für Headless-Dienste überall?

Am Di, 21. April 2015 um 14:17 Uhr, David Oppenheimer < [email protected]

schrieb:

/Abonnieren

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

Das Ziel war sehr konkret. Reale geclusterte Systeme haben Mitglieder, die eine "Identität" haben, von der erwartet wird, dass sie bei Vorhandensein von Knotenfehlern kontinuierlich ist. Diese Identität kann an eine persistente Festplatte oder einen "Namen" angehängt werden, aber der Name, der für andere Systeme identifiziert wird, kann nicht geändert werden.

Beispiel: Zookeeper hat eine Pro-Knoten-Identität. Diese Identität muss in der Clustermitgliedschaft stabil bleiben - es _könnte_ zwei Pods geben, die denken, dass sie host1 sind, aber wenn host1 wegfällt, kann host435 es nicht ersetzen. Es kann eine wiederverwendete persistente Festplatte für diesen Pod geben, die von einem Ort zum anderen verschoben wird, aber wenn dies der Fall ist, muss der Pod in der Lage sein, diese Identität zu definieren. Aber wir brauchen eine Möglichkeit, diese # zuzuweisen.

Ich vermute, dass die Art und Weise, wie ich über nominale Dienste denke, immer darin besteht, vorhandene Software mit kleinen (3/5/7) Mitgliedschaften zu aktivieren, und nicht den völlig flexiblen Anwendungsfall mit mehreren Hundert. Vielleicht sollten wir diesen Anwendungsfall von dieser Diskussion trennen.

Am 22. April 2015 um 1:59 Uhr schrieb Tim Hockin [email protected] :

Ich bin mir nicht mehr sicher, ob ich die Anforderungen hier verstehe.

Zwischen Diensten und Pods besteht eine inhärente N-zu-M-Beziehung
Auslegung des Systems. Dinge wie Reverse-DNS erwarten im Allgemeinen, dass sie ein
einzelne Antwort: Erhalten Sie einen kanonischen Namen, wenn die IP eines Pods gegeben ist. Jedes geschriebene Dokument
über DNS sagt "nicht mehrere Reverse-Records zurückgeben". Da ein Pod sein kann
bei N Diensten kann diese einzelne Antwort nicht wirklich dienstbezogen sein. Wir
könnte einen Reverse-Lookup zu einem kanonischen Namen und dann einen TXT-Lookup darauf machen
Name für "unter welchen Diensten sind Sie", aber das ist schwer zu pflegen und ist
im Wesentlichen ein benutzerdefiniertes Protokoll sowieso.

Der Grund, warum ich dachte, den RCs nominal etwas beizufügen, ist, dass dies a . ist
konkretere Beziehung. Aber es ist nicht einmal. Ein Pod kann erstellt werden von
ein RC, verwaist, von einem anderen RC adoptiert und von diesem zerstört. Oder
manuell zerstört

Ich bin mir also nicht sicher, was wir damit machen wollen, außer die Anzahl zu begrenzen
von Diensten kann ein Pod "unter" sein, was sich schrecklich anhört.

Was sind die Verhaltensanforderungen? Was versuchen wir zu erreichen. Wir
kann einfache Set-Semantik mit DNS und Headless-Diensten bereitstellen. Ist dass
reicht aus? Wenn nicht, warum?

Wir könnten bis zum Äußersten gehen und iptables-Regeln für SNAT/DNAT-Pods einrichten
Service, damit sie sich alle auf VIPs sehen. ZB ein Set von Pods gegeben
(P1, P2, P3) würden sie VIPs bekommen (V1, V2, V3). Verkehr von P1 zu V2 würde
scheinen von V1 zu kommen usw. Clients würden auf V{1,2,3} zugreifen. Aber was
Problem löst das wirklich? Es gibt stabile IPs, aber ist das nicht so?
Allgemeines Problem für Headless-Dienste überall?

Am Di, 21. April 2015 um 14:17 Uhr, David Oppenheimer < [email protected]

schrieb:

/Abonnieren

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Eine Art von Controller könnte einige Felder in Pods dynamisch setzen/deaktivieren. Es kann einfach nicht mit Pod oder RC-Identität zusammengeführt werden. Das Binden der Netzwerkidentität an Pod- oder RC-Identitäten ist völlig kaputt.

Ich würde nicht versuchen, Reverse-DNS-Lookup für normale oder Headless-Dienste zum Laufen zu bringen, und ich halte es nicht für unvernünftig, maximal einen nominalen Dienst pro Pod vorzuschreiben – was andere Arten von Diensten überhaupt nicht einschränken muss .

Es gibt eine Reihe von DNS-Einschränkungen, die wir auf lange Sicht vorantreiben möchten (Cache-Invalidierung, Unterstützung für lange Abfragen usw.). Mehrere PTR-Einträge sind vielleicht nur ein weiteres Element, das dieser Liste hinzugefügt wurde.

Die andere Alternative besteht darin, dass wir jedem Pod des nominellen Dienstes eine Dienst-IP zuweisen und dann die dadurch entstehenden Probleme lösen können.

----- Originale Nachricht -----

Eine Art von Controller könnte einige Felder in Pods dynamisch setzen/deaktivieren. Es
kann einfach nicht mit Pod- oder RC-Identität zusammengeführt werden. Binden der Netzwerkidentität
zu Pod- oder RC-Identitäten ist völlig kaputt.

Ich würde nicht versuchen, die Reverse-DNS-Suche für gewöhnlich oder ohne Kopf zum Laufen zu bringen
Dienstleistungen, und ich denke nicht, dass es unvernünftig ist, maximal eine Nominale vorzuschreiben
Service pro Pod – wodurch andere Arten von Services nicht eingeschränkt werden müssen
alle.

Es gibt eine Reihe von DNS-Einschränkungen, die wir auf lange Sicht vorantreiben möchten
(Cache-Invalidierung, Unterstützung für lange Abfragen usw.). Mehrere PTR-Einträge
ist vielleicht nur ein weiterer Punkt, der dieser Liste hinzugefügt wurde.

Die andere Alternative besteht darin, dass wir jedem Pod des eine Dienst-IP zuweisen können
nominellen Service und lösen Sie dann die Probleme, die entstehen.

Viele dieser Dienste erwarten, dass die IP, die sie haben (ihr Name), in die IP aufgelöst wird, mit der sie sich verbinden - wenn sie sich also mit 172.1.1.1 zu X verbinden, dann denkt X, dass es 172.1.1.1 ist. Das ist nicht alles Software, aber einiges davon. Normalerweise ist es jedoch ein DNS-Name, was bedeutet, dass sich die IP darunter ändern kann.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

Für mich ist das alles leider noch etwas abstrakt.

Echte geclusterte Systeme haben Mitglieder, die eine "Identität" haben, die
erwartet, dass sie bei Knotenausfällen kontinuierlich ist. Diese Identität
kann an eine persistente Festplatte oder einen "Namen" angehängt sein, aber der Name
Identifikation mit anderen Systemen kann sich nicht ändern.

Dies ist keine Voraussetzung. Es ist so vage, dass es nicht umsetzbar ist.

Beispiel: Zookeeper hat eine Pro-Knoten-Identität. Diese Identität muss bleiben
stabil in Clusterzugehörigkeit

Was ist eine Identität? Eine IP-Adresse? Ein String-Flag an die Software übergeben?
und envvar? Wie lernt ein zk-Prozess, was seine eigene Identität ist?

Eine Art von Controller könnte einige Felder in Pods dynamisch setzen/deaktivieren

Was den Neustart dieser Pods auslöst und immer noch nicht auf die Antwort antwortet
Frage, welche Felder, welche Werte und welche Logik dem Pod mitgeteilt werden soll?

Ich konnte etwas wie das Erweitern von Anmerkungen in Befehlszeilen-Flags sehen
(wie wir mit env vars diskutieren) oder einfach in env vars. Z.B
Controller schreibt Annotationen["zookeeper.com/index"] = 9, wir konvertieren
$.metatdata["zookeeper.com/index"] in die ZK_INDEX-Umgebung. Aber ich mache das
Ich habe keine konkreten Forderungen gesehen, die sagen, was genau Tierpfleger (oder
was auch immer) brauchen.

Ich denke nicht, dass es unvernünftig ist, maximal eine Nennleistung vorzuschreiben
pro Pod

Ich denke, es wird schwer, solche Einschränkungen umzusetzen. Das System ist so
lose gekoppelt und asynchron, dass das Auferlegen dieser Grenzen schlimmer sein könnte als
einfach die Probleme lösen.

wir können jedem Pod des nominellen Dienstes eine Dienst-IP zuweisen

Hier haben wir angefangen, aber ...

Viele dieser Dienste erwarten, dass die IP, die sie haben (ihr Name)
wird zu der IP aufgelöst, auf der sie sich verbinden - wenn sie also eine Verbindung zu X auf 172.1.1.1 herstellen,
dann denkt X, es sei 172.1.1.

Service-IPs erfüllen dies nicht, es sei denn, wir tun etwas tiefergehendes wie
Ich erwähnte mit SNAT/DNAT. Und selbst das hat echte Mängel.

Ich versuche nicht, ein Schmerz im Nacken zu sein, es ist nur so, dass wir sehr wenig haben
Zeit im Vorfeld bis 1.0, und hier ist nichts klar genug, um
sogar Proof-of-Concept, geschweige denn richtig implementieren.

Ich versuche genau festzulegen, was wir erleben möchten, damit ich sehen kann
was wir umsetzen können. Angesichts der wiederholten Verweise auf DNS halte ich
weg von der DNS-Überarbeitung, bis ich weiß, was hier vor sich geht.

Am Mittwoch, 22. April 2015 um 10:12 Uhr, Clayton Coleman [email protected]
schrieb:

----- Originale Nachricht -----

Eine Art von Controller könnte einige Felder dynamisch aktivieren/deaktivieren
Schoten. Es
kann einfach nicht mit Pod- oder RC-Identität zusammengeführt werden. Das Netzwerk binden
Identität
zu Pod- oder RC-Identitäten ist völlig kaputt.

Ich würde nicht versuchen, die Reverse-DNS-Suche für gewöhnlich oder ohne Kopf zum Laufen zu bringen
Dienstleistungen, und ich denke nicht, dass es unvernünftig ist, ein Maximum von einem vorzuschreiben
nominal
Service pro Pod – wodurch andere Arten von Services nicht eingeschränkt werden müssen
alle.

Es gibt eine Reihe von DNS-Einschränkungen, die wir in Zukunft weiter ausbauen möchten
Lauf
(Cache-Invalidierung, Unterstützung für lange Abfragen usw.). Mehrere PTR
Aufzeichnungen
ist vielleicht nur ein weiterer Punkt, der dieser Liste hinzugefügt wurde.

Die andere Alternative besteht darin, dass wir jedem Pod des eine Dienst-IP zuweisen können
nominellen Service und lösen Sie dann die Probleme, die entstehen.

Viele dieser Dienste erwarten, dass ihre IP (ihr Name) aufgelöst wird
zu der IP, auf der sie sich verbinden - wenn sie sich also auf 172.1.1.1 mit X verbinden, dann X
denkt, es ist 172.1.1.1. Das ist nicht alles Software, aber einiges davon. Normalerweise ist es
einen DNS-Namen, was bedeutet, dass sich die IP darunter ändern kann.

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:

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

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

Die meisten der Multi-Port-Beispiele sind geclusterte Systeme. Beispielsweise:
ZK : auflösbarer Hostname oder IP-Adresse in einer Konfigurationsdatei, plus eine "ID" (dh ein Index: 1, 2, 3, ...) in einer Datei

Wir sollten auch einige DBs durchsehen.

Was auch immer wir tun, wird nicht für alles funktionieren. Wir müssen nur den Sweetspot finden.

----- Originale Nachricht -----

Für mich ist das alles leider noch etwas abstrakt.

Echte geclusterte Systeme haben Mitglieder, die eine "Identität" haben, die
erwartet, dass sie bei Knotenausfällen kontinuierlich ist. Diese Identität
kann an eine persistente Festplatte oder einen "Namen" angehängt sein, aber der Name
Identifikation mit anderen Systemen kann sich nicht ändern.

Dies ist keine Voraussetzung. Es ist so vage, dass es nicht umsetzbar ist.

Beispiel: Zookeeper hat eine Pro-Knoten-Identität. Diese Identität muss bleiben
stabil in Clusterzugehörigkeit

Was ist eine Identität? Eine IP-Adresse? Ein String-Flag an die Software übergeben?
und envvar? Wie lernt ein zk-Prozess, was seine eigene Identität ist?

Eine Art von Controller könnte einige Felder in Pods dynamisch setzen/deaktivieren

Was den Neustart dieser Pods auslöst und immer noch nicht auf die Antwort antwortet
Frage, welche Felder, welche Werte und welche Logik dem Pod mitgeteilt werden soll?

Ich konnte etwas wie das Erweitern von Anmerkungen in Befehlszeilen-Flags sehen
(wie wir mit env vars diskutieren) oder einfach in env vars. Z.B
Controller schreibt Annotationen["zookeeper.com/index"] = 9, wir konvertieren
$.metatdata["zookeeper.com/index"] in die ZK_INDEX-Umgebung. Aber ich mache das
Ich habe keine konkreten Forderungen gesehen, die sagen, was genau Tierpfleger (oder
was auch immer) brauchen.

Ich denke nicht, dass es unvernünftig ist, maximal eine Nennleistung vorzuschreiben
pro Pod

Ich denke, es wird schwer, solche Einschränkungen umzusetzen. Das System ist so
lose gekoppelt und asynchron, dass das Auferlegen dieser Grenzen schlimmer sein könnte als
einfach die Probleme lösen.

wir können jedem Pod des nominellen Dienstes eine Dienst-IP zuweisen

Hier haben wir angefangen, aber ...

Viele dieser Dienste erwarten, dass die IP, die sie haben (ihr Name)
wird zu der IP aufgelöst, auf der sie sich verbinden - wenn sie also eine Verbindung zu X auf 172.1.1.1 herstellen,
dann denkt X, es sei 172.1.1.

Service-IPs erfüllen dies nicht, es sei denn, wir tun etwas tiefergehendes wie
Ich erwähnte mit SNAT/DNAT. Und selbst das hat echte Mängel.

Ich versuche nicht, ein Schmerz im Nacken zu sein, es ist nur so, dass wir sehr wenig haben
Zeit im Vorfeld bis 1.0, und hier ist nichts klar genug, um
sogar Proof-of-Concept, geschweige denn richtig implementieren.

Ich versuche genau festzulegen, was wir erleben möchten, damit ich sehen kann
was wir umsetzen können. Angesichts der wiederholten Verweise auf DNS halte ich
weg von der DNS-Überarbeitung, bis ich weiß, was hier vor sich geht.

Ich denke, das ist klug, wir sollten uns gezielt Zeit nehmen, um eine Reihe bekannter Beispiele zu lösen. Wir haben 3 auf unserer Seite, die wir für konkrete Beispiele (MongoDB-Replikatsatz, Zookeeper, Mysql Master/Slave) sowie die vorhandenen Beispiele in kube/examples nutzen können. Vielleicht eine Arbeitssitzung, um die Dinge auszusortieren, Grenzen für unlösbare Probleme zu setzen und herauszufinden, was noch übrig ist.

Schlagen Sie vor, den Namen dieser Funktion zu ändern, da sie auch für Batch-Jobs verwendet werden könnte, um eine Shard-ID-Nummer zuzuweisen.

Batch-Jobs haben etwas andere Anforderungen, daher möchte ich das getrennt halten.

Beispiel Tierpfleger: https://github.com/openshift/origin/pull/1965

Beispiel für die nominellen Serviceanforderungen https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

Ich bin etwas verwirrt, warum die Richtung hier immer noch unklar ist - insbesondere von den Googlern. Google betreibt seit vielen Jahren zustandsbehaftete Dienste unter Borg, und es ist ziemlich klar, was für diese Art von Workload erforderlich ist:

• Ein stabiler Bezeichner, für den einer der "Shards" (nicht identische Replikate) den aktuellen Pod repräsentiert (in Borg ist dies die "Aufgabennummer" - eine einfache ganze Zahl). Dieser Bezeichner sollte über Pod-Neuplanungen/Neustarts hinweg konstant bleiben.
• Eine Möglichkeit, alle "Peer" -Shards aufzuzählen und zu kontaktieren, wahrscheinlich unter Verwendung ihrer stabilen Kennungen in irgendeiner Weise (in borg ist dies ein pummeliges Präfix zusammen mit der Aufgabennummer).

.. und wir sind fertig.

Hinweis: Wenn der Ressourcenausschluss für jeden Shard kritisch ist, müssen die Anwendungen ihre eigenen verteilten Sperren durchführen, da immer die Möglichkeit besteht, dass sich die Pod-Lebensdauer bei Fehlern/Neustarts überschneiden kann (möglicherweise mithilfe einer etcd-Sperre basierend auf der Shard-ID). Eine potenzielle exotische Funktionserweiterung besteht darin, aus Redundanz/Last mehr als ein identisches Replikat innerhalb jedes Shards zuzulassen.

Dies kann jetzt gefälscht werden, indem für jeden Shard ein eindeutiger Dienst/Port erstellt und ein Replikationscontroller mit Replikaten ausgeführt wird:1, aber es ist etwas umständlich, eine große Anzahl von Shards auf diese Weise "von Hand" zu verwalten.

Ein natürlicher Weg, dies in Kubernetes zu implementieren, könnte sein:

• Pods erhalten zusätzliche Umgebungsvariablen, die ihren eigenen Shard-Index (Integer) und die Gesamtzahl der Shards angeben (oder vielleicht über die Abwärts-API kommunizieren?).
• ReplicationControllers erhalten einen "Shards"-Zähler (Standard: 1), und "Replicas" wird neu interpretiert als "Replikate in jedem Shard" (Standard: 1). Wenn Sie den Satz von Replikaten verkleinern, sollten sie am Ende töten (um die Shard-Indizes zusammenhängend zu halten). Beachten Sie, dass das Ändern von "Shards" einen fortlaufenden Neustart der kontrollierten Pods erfordert, um ihre "total Shards"-Env-Var zu aktualisieren (gut, Sie möchten nicht, dass dies sofort geschieht).
• Dienste erhalten eine ähnliche "Shards"-Anzahl, die einen zusammenhängenden Bereich von Ports dem regulären Selektor plus einem impliziten "Shard-Index"-Selektor zuordnet.
• Pods können andere Shards finden, indem sie SERVICE_PORT (oder eine neue Umgebungsvariable?) + Shard-Index-Offset verwenden.

Beachten Sie, dass sich das Obige auf das aktuelle Verhalten reduziert, wenn shards=1 ist.

Ich stimme dem grundsätzlich zu (und wie Sie sagen, es hat sich in Borg bewährt), obwohl ich davon abraten würde, die "exotische Feature-Erweiterung" mehrerer Replikate pro Shard zu verwenden (obwohl wir so etwas wahrscheinlich unter der Migrationsschutz).

Wie ich bereits erwähnt habe, hängt dies eng damit zusammen, was wir tun müssen, um Batch-Jobs mit statischer Arbeitszuweisung zu unterstützen (was ich hier "Typ 1" nannte: https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142 )

Die anderen Funktionen, die wir anpassen müssen, wenn wir RC geändert (oder etwas Neues hinzugefügt haben) sind die Einpassung der Bereitstellung, insbesondere:

Wie mache ich ein fortlaufendes Update für:

1. Ein normaler RC
2. Ein PerNodeController
3. Ein zersplitterter RC
4. Ein Batch-Job?

Vielleicht möchten wir entweder die Implementierung der Implementierung so lange aufhalten, bis wir für jeden einen Strohmann haben, da ich glaube, dass eine Implementierung, die nur gegen einen einfachen RC funktioniert, einige Probleme hat.

----- Originale Nachricht -----

Dem stimme ich im Allgemeinen zu (und wie Sie sagen, es hat sich bewährt
in Borg), obwohl ich davon abraten würde, auf das "Exoten-Feature" zu setzen
Erweiterung" mehrerer Replikate pro Shard (obwohl wir wahrscheinlich etwas brauchen
so unter der Decke für die Migration).

Wie ich bereits erwähnt habe, hängt dies eng mit dem zusammen, was wir tun müssen
Batch-Jobs mit statischer Arbeitszuweisung unterstützen (was ich "Typ 1" nannte)
Hier:
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)

---

Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an:
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

Wir haben uns entschieden, dies (und automatisch generierte Ansprüche auf persistente Volumes) für 1.0 nicht zu priorisieren, da es mehrere Problemumgehungen gibt, z.

Während in Borg stark statisch zugewiesene Aufgabenindizes verwendet werden, haben wir festgestellt, dass sie eine Reihe von Mängeln aufweisen, und haben in den letzten Jahren einige Zeit damit verbracht, Alternativen zu entwickeln. Viele der Probleme resultieren aus der Tatsache, dass die Indizes an den Lebenszyklus und die Identität der Aufgaben selbst gekoppelt sind. Dies erschwert die Implementierung einer Reihe von Bereitstellungsstrategien, Migration, dynamischer Aufgabenverwaltung und vielen anderen Szenarien. Andere Komplexität ergibt sich aus der statischen Generierung der Konfiguration pro Index für jede Aufgabe vor der Bereitstellung – dies ist gleichbedeutend mit der Generierung eines RC pro Indexwert. Das wäre für jemanden einfach zu tun, wenn er es wirklich wollte. Etiketten könnten immer noch verwendet werden, um das gesamte Set abzureißen.

Pro-Knoten-/Daemon-Controller: Guter Punkt. Dicht belegte Indizes sind für diesen Fall ein schlechtes Modell. Was tun, wenn zum Beispiel ein Knoten dauerhaft wegfällt? Indizes werden spärlich. Ich empfehle, dass wir das nicht unterstützen.

Batch-Jobs: Wie in #1624 besprochen, möchten wir Indizes basierend auf Abschlüssen zuweisen, die derzeit nicht auf Pods ausgeführt werden.

Wie oben erörtert, muss bei der Indexzuweisung der zugehörige Speicher berücksichtigt werden, wie z. B. dauerhafte Volume-Ansprüche – die Identität stammt aus der Netzwerkidentität (DNS-Name und/oder IP-Adresse) und dem Speicher.

Die Zuweisung kann nicht von einem einzelnen Replikationscontroller gesteuert werden. Dies funktioniert einfach nicht. Replikationscontroller sind keine dauerhaften Entitäten, und wir erwarten, dass es mehrere RCs pro Dienst gibt, für Canaries, Rolling Updates, mehrere Release-Tracks, mehrere Cluster usw. Selbst das vorgeschlagene Deployment-Objekt (#1743) hat nicht den richtigen Umfang .

Es gibt 3 Alternativen für die Zuweisung:

1. Ordnen Sie den Auftrag einer besonderen Art von Service zu. Service hat genau den richtigen Umfang. (Wir werden irgendwann auch regionale Dienste brauchen.) Dies wäre eine Art Hybrid zwischen Liniendiensten und kopflosen Diensten. Es ist das, was ich mir vorgestellt habe, als ich diesen Mechanismus ursprünglich vorgeschlagen habe. Die Zuweisung würde in Endpoints aufgezeichnet. Endpunkte und/oder Headless-ähnliches DNS wären die offensichtlichen Möglichkeiten, alle Peers aufzuzählen.
2. Erstellen Sie einen neuen Objekttyp, der Service ähnelt, jedoch nur für nominelle Services. Wir würden wahrscheinlich auch ein neues Objekt benötigen, um die Aufgabe aufzuzeichnen. Dies würde unsere API-Oberfläche unnötig erweitern, IMO.
3. „Ziehen“ statt „drücken“. Pods werden für Hosts ohne expliziten Controller geplant, selbst mit Knotenbeschränkungen (Selektor) oder einem der vorgeschlagenen Anti-Affinitätsmechanismen (https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529). Dies ist auch vergleichbar mit der Service-VIP-Zuweisung. Wir könnten etwas Ähnliches für nominale Dienste tun. Ein Pod (oder eine Pod-Vorlage) würde den Indexpool angeben, aus dem ein Index zugewiesen werden soll. Im Gegensatz zu allgemeinen Diensten erwarten wir nicht, dass Pods mehrere Indizes aus verschiedenen Pools zugewiesen werden müssen. Die Zuweisung würde in der Pod-Spezifikation aufgezeichnet.
4. Vorteile: Einfacher für Benutzer. Benötigt kein weiteres Objekt. Ermöglicht die Zuweisung durch Benutzer.
5. Nachteile: Anders als bei anderen Arten von Dienstleistungen.

Die PVC-Zuweisung würde idealerweise das gleiche Modell verwenden.

Es ist auch eine Überlegung wert, wie die Pod-Migration #3949 orchestriert werden würde. Der Ersatz-Pod MUSS vor dem Löschen des zu ersetzenden Pods erstellt werden, um den Containerstatus zu übertragen. Dies könnte das Pull-Modell etwas problematisch machen. Unabhängig davon müsste der Zuweisungsmechanismus migrationsbewusst gemacht werden.

Weitere Überlegungen:

1. Wie man den Index/die Identität an Peers kommuniziert. DNS ist die offensichtliche Antwort.
2. So übermitteln Sie den Index/die Identität an die Container im Pod. Umgebungsvariablen, Reverse-DNS, ... Der zugewiesene Index wird sich nicht dynamisch ändern, obwohl die DNS-Bindung geändert werden kann, während der Pod noch existiert. Ich möchte einen Mechanismus wählen, von dem Anwendungen bereits erwarten, dass sie in anderen Umgebungen funktionieren, und wie bei der breiteren API-Diskussion (#386) möchte ich Anwendungen nicht an Kubernetes-spezifische Umgebungsvariablen koppeln, sondern die neue EnvVarSource und env var-Ersetzung (#7936) würde helfen, dies zu vermeiden.

Ich bin mit einigen Ihrer Aussagen nicht einverstanden, aber warten wir mit dieser Diskussion bis nach 1.0.

Belebe diesen alten Thread wieder, um eine Frage zu stellen. Besteht Interesse an einer Benennungsrichtlinie für Replikationscontroller? Insbesondere die nominelle Benennung wie oben beschrieben, bei der alle von diesem Replikationscontroller gesteuerten Pods nummerierte Suffixe hätten, etwa 0001, 0002 ....

Ein Beispielanwendungsfall ist ein nginx-Load-Balancer, der über Domänennamen auf diese Gruppe von Pods verweist. Wenn Pods kommen und gehen, wird erwartet, dass die Domänennamen immer von xxx-0001 bis xxx-000N festgelegt werden.

@ravigadde Bitte lesen Sie meinen letzten Kommentar zu diesem Thema: https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -102107352

Dieses Problem ist beim Einrichten eines RabbitMQ-Containers aufgetreten. Die Persistenz von Rabbit hängt vom Hostnamen ab. Wenn Sie also variable Hostnamen haben, verlieren Sie die Mnesia-Datenbank beim Neustart des Containers.

Habe versucht, Abhilfe mit der Image-Konfiguration (Hostname direkt und Rabbit), ENV-Variablen und der Downward-API zu schaffen. Konnte keine finden, um das Problem zu lösen - Rabbit nimmt immer noch den generierten Pod-Namen auf. Vorübergehendes Lösen durch Wechseln von der Verwendung eines Replikationscontrollers gemäß dem Vorschlag von @mikedanese .

Wenn ich das richtig verstehe, verliert der Rabbitmq-Pod (erstellt mit einem Replikations-Controller) im celerey-rabbit- Beispiel Daten bei einem Pod-Fehler, selbst wenn Daten auf einer persistenten Festplatte gespeichert sind. Aus dem Kaninchenmq-Dokument:

RabbitMQ benennt das Datenbankverzeichnis mit dem aktuellen Hostnamen des Systems. Wenn sich der Hostname ändert, wird eine neue leere Datenbank erstellt. Um Datenverlust zu vermeiden, ist es wichtig, einen festen und auflösbaren Hostnamen einzurichten.

Dafür gibt es derzeit keine gute Lösung, aber Sie könnten einen Pod (nicht an einen RC gebunden) mit einer migrierbaren persistenten Festplatte erstellen, wobei der Pod in bestimmten Fehlerfällen manuell neu geplant werden muss. Das ist der einzige Weg, den ich mir vorstellen kann, den Hostnamen statisch zu halten.

Oder beim Start symbolisieren Sie den Hostnamen dir mit einem stabilen Ort

Am 11. Juli 2015 um 17:26 Uhr schrieb Mike Danese [email protected] :

Wenn ich das richtig verstehe, ist der Rabbitmq-Pod (erstellt mit einer Replikation
Controller) im Clerey-Kaninchen
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
Beispiel verliert bei einem Pod-Ausfall Daten, selbst wenn die Daten auf einem gespeichert sind
persistente Festplatte. Aus dem Kaninchenmq-Dokument:

RabbitMQ benennt das Datenbankverzeichnis mit dem aktuellen Hostnamen des
System. Wenn sich der Hostname ändert, wird eine neue leere Datenbank erstellt. Vermeiden
Datenverlust Es ist wichtig, einen festen und auflösbaren Hostnamen einzurichten.

Dafür gibt es jetzt keine gute Lösung, aber Sie könnten einen Pod erstellen (nicht
an einen rc gebunden) mit einer migrierbaren persistenten Festplatte, wobei die Einschränkung der Pod ist
müssen in bestimmten Fehlerfällen manuell neu geplant werden. Das ist der
Der einzige Weg, den ich mir vorstellen kann, den Hostnamen statisch zu halten.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

Das ist ein Beispiel dafür, warum der Hostname nicht vom Pod-Namen abgeleitet werden sollte – #4825

Um dem einen kleinen Kick zu geben:

Es gibt mehrere grundlegende Probleme, die gelöst werden müssen:

1. Einige Komponenten müssen pro Pod eine eindeutige Identität haben, die an ihren Speicher auf der Festplatte gebunden ist
   
   
   
   1. Als weiterer Nachteil müssen einige von ihnen (in einigen Fällen Zookeeper) den Hostnamen auflösen und übereinstimmen
   
   
2. Einige Komponenten, die skaliert werden, müssen über einen persistenten Speicher verfügen, der sich je nach Pod unterscheidet (Pods weisen auf PVCs hin, die sich je nach Pod unterscheiden und an die Identität gebunden sind).
   
   
   
   1. Manchmal sollten diese Volumes nach Bedarf beim Scale-Up erstellt werden
   
   
   2. Manchmal sollten diese Volumes aus einem Pool wiederverwendet und nicht neu erstellt werden
   
   
3. Einige Komponenten können auf Zehntausende von Instanzen skaliert werden, wo die Verfolgung individuell zugewiesener Identitäten nicht praktikabel ist
   
   
   
   1. Die meisten Anwendungen für nominal werden wahrscheinlich zwischen 2-7 Instanzen eines Pods liegen (die meisten aktuellen skalierbaren DBs, die meisten Shard-Multi-Master-Setups).
   
   
4. Einige Komponenten möchten keine eigene Master-Wahl implementieren, sondern lassen dies der Plattform überlassen, indem sie eine der Identitäten beliebig machen (Identität 1 wird zum Master)
5. Wenn wir diese Probleme lösen, müssen die Benutzer weiterhin Änderungen an den Pods vornehmen (über Bereitstellungen) und sicherstellen, dass jede Identität entweder beibehalten oder neu zugewiesen wird.

Diese müssen nicht unbedingt alle in derselben Lösung gelöst werden. Ich denke zum Beispiel, dass es einen signifikanten Unterschied zwischen der Identität eines kleinen Clusters (2-7) und der Identität eines großen Clusters (>7) gibt. Im großen Fall beschäftigt sich diese Software beispielsweise weniger mit Lücken oder hat ein bestehendes Konsens-/Mitgliedschaftsprotokoll. Im kleinen Fall braucht die Software mehr Hilfe bei der Identitätsfeststellung. Ich würde diese in Cloud-native (>7) und vorhandene geclusterte (2-7) Software unterteilen.

Ich stimme 1a, 1b und 2a zu. 2b klingt nach einem anderen Problem, obwohl die Lösung möglicherweise dasselbe Muster wiederverwenden kann.

Ich denke, Skala (3) deutet hauptsächlich darauf hin, dass unsere Problemumgehung von einem Dienst und RC pro Instanz nicht angemessen ist, obwohl ich der Unterscheidung zwischen Cloud-nativ und nicht zustimme.

Masterwahl (4) kann gesondert angesprochen werden.

Stimmen Sie auch (5) zu.

Ich denke, die meisten Designanforderungen sind an dieser Stelle klar.

Restliche Gestaltungsfragen:

I. VIPs zuweisen oder IPs ändern lassen? Eng damit verbunden ist, ob Container ihre eigenen IPs über Linux ermitteln können müssen oder nicht, da VIPs derzeit nicht über das System auffindbar sind. Ich gehe davon aus, dass sie in der Lage sein müssen, ihre IPs zu erkennen, könnten aber die Abwärts-API verwenden, wie bei der Pod-IP (#12595). Die Änderung von IPs (aufgrund der Verwendung von Pod-IPs) impliziert eine Begrenzung der Änderungsrate der IP aufgrund von DNS-TTLs und Caching-"Bugs". Irgendwann beabsichtigen wir jedoch auch, Pod-IPs migrierbar zu machen (#3949), damit das Ändern von IPs nicht ewig dauern würde.

II. Push (zu Pods) vs. Pull (aus Pods). Dienste und RCs sind absichtlich lose an Pods gekoppelt und verwenden daher beide das "Push"-Modell. Nominale Dienste wären stärker an die Pod-Identität gebunden (wenn auch nicht dauerhaft – Pods müssen austauschbar sein). Folglich sehe ich weniger Motivation für das Push-Modell. Andere Fälle der Zuteilung, wie z. B. Terminplanung und insb. Exklusive Bindungen, wie zum Beispiel persistente Volume-Ansprüche auf persistente Volumes, verwenden ein Request/Ack-Modell, auch bekannt als "Pull". Dies ist derzeit das Modell, das ich für Nominaldienste bevorzuge.

Hat jemand eine Meinung zu (I)?

Die Master-Auswahl ist Nr. 1542 und wird als Teil der HA-Implementierung diskutiert (zB Nr. 12884).

Ich weiß nicht was du mit drücken und ziehen meinst.

Ich habe den Großteil dieser Ausgabe noch einmal gelesen und bin überzeugt, dass es keine einzige gibt
Lösung. Wir werden eine Familie von Funktionen brauchen, um eine Brücke zu bauen zu
diese Art von Apps.

Ich beginne mit dem Axiom, dass, wenn ein Pod läuft, man nicht wirklich kann
einen laufenden Pod ändern. Hiervon gibt es einige Ausnahmen (z. B. virtuelle
Dateisysteminhalt), aber die Dinge, die wichtig zu sein scheinen (env vars, IP,
hostname) bleiben Sie bei allem stecken, womit Sie beginnen.

Ich beginne auch mit der Behauptung, dass die lose Kopplung zwischen
Service und Pod bleiben, was diese Sache, über die wir sprechen, nicht wirklich zu einem macht
Service. Pods wissen nicht wirklich, welche Dienste ihnen gegenüberstehen. Wenn wir uns ändern
dass es kein Service mehr ist.

Ich werde einfach einen Bewusstseinsstrom machen und sehen, was nicht stinkt.

Idee 1: ThingPools und Patches.

Definieren Sie ein neues API-Objekt oder etwas, mit dem Sie einen Pool von
Dinge. Was ist ein Ding? Ein Ding ist ein String (oder vielleicht ein JSON-Blob), der
hat einen Aufzählungstyp. Sie können einen Pool von Dingen und diesen Dingen erstellen
stehen Ihnen zur Verfügung. Ding-Typen umfassen VUIDs (Hostnamen), Strings, VIPs.

Definieren Sie ein neues API-Konstrukt, das an die Erstellung von Operationen übergeben werden kann - a
aufnähen. Ein Patch ist eine Anleitung zum Patchen des zu bearbeitenden Objekts
erstellt. Eine der Patch-Optionen ist "Aus einem ThingPool zuordnen".

Um diese zusammenzufassen:

Definiere einen ThingPool { Meatadata.name: my-quorum-hostnames, type: VUID,
autogenerate: 5, } // erstellt einen Pool von 5 gültigen VUIDs

Definiere einen RC { Repliken: 5 ...}

Im RC's erstellen (POST) auch einen Patch senden: { what:
"podTemplate.spec.containers[*].metadata.VUID", Pool: "my-quorum-hostnames"
}

Der POST-Vorgang würde den Patch auf den RC anwenden und eine VUID zuweisen
pro Container aus dem ThingPool. Jedes Mal, wenn ein Pod getötet und neu erstellt wird,
die VUID wird an den Pool zurückgegeben und der nächste zu startende Pod erhält sie.

Sie könnten dies verwenden, um einen Pool von Zeichenfolgen ("0" bis "99") zu generieren und zu kleben
diese in eine env var. Sie können dies verwenden, um einen Pool von VIPs zuzuweisen und
Weisen Sie dann diese VIPs den Pods zu (wäre eine neue Funktion - dauerhafter Pod
IPs - nicht sicher, wie das skaliert :) Sie könnten einen Pool von generieren
PersistentVolumeClaim benennt und patcht das Anspruchsvolumen, das jeder Pod verwendet.

Diese Idee ist in vielerlei Hinsicht unvollkommen, aber ich denke, sie fängt am besten die ein
Idee einer Gruppe von Pods, ohne eine Gruppe von Pods direkt zu definieren.

Idee 2: Definieren Sie eine Reihe von Pods. Tu nicht so, als wäre es ein Service. Es ist näher
zu einem Borg-Job. Es ist wie ein RC, aber es weist den Pods eine Ordinalität zu
Kontrollen - Shard-Nummern. Es steuert den Pool der VUIDs (aber wir wollen nicht
Hostname etwas sein, das Benutzer einstellen können, hmmm...).

Ich dachte, ich hätte mehr Ideen, aber das habe ich nicht. Ich kämpfe mit Abstraktionen
und Implementierungen - es ist sinnlos, eine Abstraktion zu definieren, die wir nicht können
implementieren. VIPs für Nominale hört sich gut an, aber ich denke, das wird die treiben
Grenzen von iptables. Bereitstellung einer Reihe stabiler Hostnamen für eine Reihe von Pods
scheint das Wichtigste zu sein, mit einer Reihe von Aufbewahrungsmöglichkeiten für eine Reihe von
Schoten heiß auf seinem Schwanz.

Am Dienstag, 18. August 2015 um 19:28 Uhr, Brian Grant [email protected]
schrieb:

Ich stimme 1a, 1b und 2a zu. 2b klingt aber nach einem anderen Problem
vielleicht kann die Lösung dasselbe Muster wiederverwenden.

Ich denke, Skala (3) deutet hauptsächlich darauf hin, dass unser Workaround von einem Dienst und
RC pro Instanz ist nicht angemessen, obwohl ich der Unterscheidung zwischen stimme
Cloud-nativ vs. nicht.

Masterwahl (4) kann gesondert angesprochen werden.

Stimmen Sie auch (5) zu.

Ich denke, die meisten Designanforderungen sind an dieser Stelle klar.

Restliche Gestaltungsfragen:

I. VIPs zuweisen oder IPs ändern lassen? Eng damit verbunden ist, ob
Container müssen in der Lage sein, ihre eigenen IPs über Linux zu finden oder nicht,
da VIPs derzeit nicht über das System auffindbar sind. Ich nehme an, sie tun es
müssen in der Lage sein, ihre IPs zu erkennen, könnten aber die Abwärts-API verwenden, da
mit Pod-IP (#12595 https://github.com/kubernetes/kubernetes/pull/12595).
Das Ändern von IPs (aufgrund der Verwendung von Pod-IPs) impliziert eine Begrenzung der Rate
der Änderung der IP, aufgrund von DNS-TTLs und Caching-"Bugs". Irgendwann haben wir
beabsichtigen jedoch auch, Pod-IPs migrierbar zu machen (#3949
https://github.com/kubernetes/kubernetes/issues/3949), also IPs ändern
wäre nicht für immer.

II. Push (zu Pods) vs. Pull (aus Pods). Dienste und RCs sind
absichtlich lose an Pods gekoppelt, und daher verwenden beide den "Push"
Modell. Nominale Dienste wären stärker an die Pod-Identität gebunden
(allerdings nicht dauerhaft – Pods müssen austauschbar sein). Folglich sehe ich
weniger Motivation für das Push-Modell. Andere Zuteilungsfälle, wie z
Terminplanung und insb. exklusive Bindung, wie z. B. persistente Volumenansprüche an
persistente Volumes verwenden, verwenden Sie ein Request/Ack-Modell, auch bekannt als "Pull". Das ist aktuell
das Modell, das ich für nominelle Dienste bevorzuge.

Hat jemand eine Meinung zu (I)?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

Ich meinte wahrscheinlich nicht wirklich Meisterwahl, wie du es denkst - mehr darüber
beim Aufbau von Funktionen, bei denen eine Reihe von Instanzen initialisiert werden müssen
(ohne explizit zu koordinieren) nur die Instanz haben, die denkt, dass sie es ist
"1"-Gespräch mit anderen Pods reicht normalerweise aus, um einen Cluster zu booten. Ein
Beispiel ist mongodb, wo Sie den Replikatsatz initiieren müssen - wenn pods
die denken, sie seien "2" oder "3" eingeweiht, kannst du in Fällen bekommen, in denen du
eine Spaltung einleiten. Aber "1" kann sich jedes Mal sicher selbst initiieren, und dann
Versuchen Sie, die anderen Mitglieder hinzuzufügen (die einen dauerhaften Status haben, den sie verwenden können)
feststellen, ob sie bereits Teil eines Clusters sind). Abhängig von
Garantien des Identitätsdienstes, die Sie möglicherweise nicht erhalten
erfolgreicher Cluster, aber Sie müssen keinen separaten Pod außerhalb erstellen, um
initialisieren Sie Ihren Dienst (obwohl das auch nicht schlimm ist).

Am Dienstag, 18. August 2015 um 23:59 Uhr, Brian Grant [email protected]
schrieb:

Meisterwahl ist Nr. 1542
https://github.com/kubernetes/kubernetes/issues/1542 und wird
als Teil der HA-Implementierung besprochen (z. B. #12884
https://github.com/kubernetes/kubernetes/pull/12884).

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

Clayton Coleman | Leitender Ingenieur, OpenShift

@smarterclayton Es ist eine Problems der nominalen Dienste, aber es ist nicht sicher, wie Sie es beschreiben. Wenn "1" auf einer neuen Maschine neu gestartet wird und die vorhandenen Knoten nicht erreicht werden können, wird es neu gestartet und jetzt haben Sie zwei Mongodbs, die behaupten, autorisierend zu sein. Sie müssen die Jobdefinition ändern, um die Möglichkeit zum Bootstrapping zu entfernen, nachdem das Bootstrapping abgeschlossen ist.

Wie @tockin anspielen könnte, denke ich, dass wir hier unnötigerweise mehrere ähnliche, aber unterschiedliche Funktionen zusammenführen – und wir fügen mehr ein, als auf k8s-Ebene unbedingt erforderlich ist.

Ich sehe zwei recht unterschiedliche Anwendungsfälle, die oben beschrieben wurden - je nach Quelle der Wahrheit:

_Vorschreibend:_ "Ich möchte, dass N Shards ausgeführt werden, und wenn mehr oder weniger als das sind, dann nehmen Sie Änderungen vor, um es wieder auf N zu bringen."
_Beschreibend:_ "Ich möchte einfach alle verfügbaren Shards automatisch erkennen und mich irgendwie herausfinden lassen, wie sie kommen und gehen."

Ich denke, diese sind unterschiedlich und sollten anders beschrieben werden (obwohl sie möglicherweise ähnliche Metadaten wie die tatsächlich ausgeführten Pods enthalten).

Die Diskussion hat auch Ressourcenzäune und Single-Access-Garantien einbezogen. Afaics, der _einzige_ Fall, in dem dies innerhalb von k8s erfolgen muss, ist das Mounten von persistenten Remote-Volumes (weil das fs-Mount außerhalb des Containers erfolgen muss), und dies ist ziemlich einfach über etcd-Sperren, wenn der zugrunde liegende Remote-Volume-Dienst dies nicht tut t bieten bereits intern Zäune an. Alle anderen Fälle können von den Benutzerjobs selbst bearbeitet werden, indem ein verteilter Sperrdienst verwendet wird (oder auf Dienste zugegriffen wird, die intern Sperren bereitstellen). Wenn Sie die Jobs auffordern, ihre eigene Sperrung durchzuführen, werden alle möglichen Muster (feste Zuweisung, opportunistische Zuweisung, "Hot Spares" usw.)

Ich schlage vor, die allgemeine Funktionsanforderung für das Ressourcen-Fencing aus diesem Fehler zu entfernen (und wir implementieren Fencing einfach, indem wir ein Rezept zum Ausführen verschiedener verteilter Sperrdienste auf k8s ohne weitere Beteiligung von k8s selbst bereitstellen).

Nur zur Erinnerung: Hinter einem einzelnen VIP stecken _viele_ Ports. Ich stimme zu, dass wir keine IPs migrieren möchten, da dies für das zugrunde liegende Netzwerk im Maßstab schwer klingt und für das Netzwerk umständlich ist, mit temporären Duplikaten in Grenzfällen bei Ausfall/Wiederherstellung umzugehen. Ich denke jedoch, dass es durchaus machbar ist, jedem Shard-Mitglied einen eindeutigen Service-Port und jeder Pod-Instanz Proxy-Daten zuzuweisen - selbst bei sehr großen Jobs. (Dieser Vorschlag geht davon aus, dass die Proxys immer noch die Richtung sind, in die wir mit k8s gehen wollen - ich habe die aktuelle Diskussion in diesem Bereich nicht weiterverfolgt)

Mit Push meinte ich eine andere Ressource, wie ein Service oder Controller, die Pod-Sets über einen Label-Selektor überwacht und ihnen "Dinge" (auflösbare DNS-Namen, VIPs, PVCs) zuweist.

Mit Pull meinte ich, dass der Pod explizit die Zuweisung eines "Dings" anfordert, das dann über so etwas wie /binding daran gebunden wird.

Zum Ändern laufender Pods: Das Ändern eines Pods nach der Erstellung unterscheidet sich vom Ändern eines Pods mit laufenden Containern. Der Scheduler führt asynchron durch. Initialisierung zum Beispiel. PodIP wird auch spät zugewiesen. Allgemeiner diskutiert in #3585.

Ob dies wirklich ein "Service" ist oder nicht:

• Dinge müssen über mehrere Pod-Sets verteilt werden
• Dinge (z. B. DNS-Namen) dürfen nicht an den Ressourcennamen eines Pods gebunden sein
• Ein Ding muss von einem Pod auf einen anderen übertragbar sein
• Der Pod muss "wissen" (oder über eine nach unten gerichtete API herausfinden können), was (insbesondere DNS-Name und VIP) ihm zugewiesen wurde.
• Eine Sache, die wir unterstützen müssen, ist auflösbares DNS
• Ob wir VIPs brauchen, war meine einzige offene Frage. Ich bin damit einverstanden, keine VIPs zu verwenden.
• Es ist nicht ideal, aber der Benutzer könnte einen zweiten, Headless-Dienst erstellen, der auf das gesamte Set für die Peer-Erkennung über DNS und/oder Endpunkte abzielt.

Idee (1), ThingPools + Patches ist eine interessante Idee. Ich würde es als "Pull"-Ansatz bezeichnen. ThingPool ist nicht schlecht, aber ich befürchte, dass die Patches schwer zu verwenden sind, und ich möchte keine semantischen Informationen aus den Patches innerhalb des Systems zurückentwickeln, um ein akzeptables Verhalten während des Speicherlebenszyklus usw. bereitzustellen. Ich bevorzuge etwas Domänenspezifischeres. Außerdem würden unabhängige ThingPools für DNS-Namen und PVCs nicht funktionieren, da sie gemeinsam zugeordnet werden müssen.

Idee (2) würde ich als „Push“-Ansatz beschreiben. Ich möchte die Arbeit an RCs und Bereitstellungen nicht duplizieren, daher sollten wir keinen weiteren Pod-Controller einführen. Ein Zuweiser wäre in Ordnung, ist aber lockerer als nötig gekoppelt und entspricht nicht dem Präzedenzfall für die Art und Weise, wie wir Zuweisungen handhaben.

Betreff. Stuffing info into env vars: Das ist auch für Job aufgekommen. Ich möchte die Informationen in eine Anmerkung stopfen und die Abwärts-API erweitern, um bestimmte Anmerkungen anfordern zu können. Ich möchte Benutzern weiterhin erlauben, nur die benötigten Informationen anzufordern und env var-Namen auszuwählen.

Betreff. Zuweisen verschiedener Ports zu jeder Instanz: Das würde für viele Legacy-Apps nicht funktionieren und ist auch nicht mit unserem Systemdesign kompatibel.

Betreff. präskriptiv: N am Laufen zu halten ist das, was ReplicationController tut.

Betreff. beschreibend: Das sind Headless-Dienste, die es bereits gibt.

Betreff. Locking: Ja, das ist die Lease-API, die im Gange ist.

Die Speicherbereitstellung wird in #6773 (Push) und #12450 (Pull) besprochen.

Es ist jetzt zu spät, aber ich werde irgendwie versuchen, nach etwas Schlaf Zeit zu finden, um einen Vorschlag zu machen.

Kurze Beobachtung: Headless-Dienste weisen keine VIPs zu

Wir könnten die Zuweisung/Zuweisung von der DNS-Veröffentlichung entkoppeln. Wenn wir die Zuweisung/Zuweisung im Moment ignorieren, könnten wir eine spezielle Variante des Headless-Dienstes haben, die Namen aus einem Feld in den Pods nimmt, die den Hostnamen darstellen.

Und die dauerhaften lokalen Speicherprobleme sind relevant: #7562, #1515, #598

Weitere schnelle Updates, da ich meistens andere PR-Rezensionen mache:

Ein Vorteil der Verwendung eines Dienstes besteht darin, dass wir nicht garantieren müssen, dass die für Pods angeforderten Hostnamen global eindeutig sind, da der Dienst die im DNS veröffentlichten Namen einbezieht.

Betreff. Zuweisung/Zuweisung: Ich möchte vermeiden, dass ReplicationController, Deployment, Daemon usw. weitere Vorlagentypen hinzugefügt werden, und ich möchte, dass Speicher und Namen genauso einfach zwischen Controllern wie zwischen Pods migriert werden können (falls der Benutzer dies wünscht).

Am 19. August 2015 um 01:04 Uhr schrieb Angus Lees [email protected] :

@smarterclayton https://github.com/smarterclayton Es ist eine Nebensache
Nominelles Serviceproblem, aber es ist nicht sicher, so wie Sie zu booten
beschreiben. Wenn "1" auf einem neuen Computer neu gestartet wird und zufällig nicht funktioniert
Um die vorhandenen Knoten zu erreichen, wird es neu gestartet und jetzt haben Sie zwei
mongodb behauptet, maßgebend zu sein. Sie müssen den Job wechseln
Definition zum Entfernen der Bootstrap-Funktion nach dem Bootstrapping ist
Komplett.

Es ist durchaus möglich, dass Sie sich in diesem Fall überlappen - aber in den meisten Fällen
In Fällen sprechen wir über persistenten Speicher mit Sperren, damit Sie blockieren würden
Jedenfalls, bis gce/AWS Ihren Zaun freigegeben hat und Sie ihn anbringen konnten. So
Sie opfern die Verfügbarkeit beim Bootstrapping, aber nicht unbedingt zur Laufzeit
(es sei denn, Sie befinden sich in einem nicht eingezäunten Speicher. In diesem Fall stimme ich zu, dass dies nicht der Fall ist
sicher)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

Am 19. August 2015 um 1:35 Uhr schrieb Angus Lees [email protected] :

Wie @tockin https://github.com/tockin anspielen könnte, denke ich
Wir vermischen hier unnötigerweise mehrere ähnliche, aber unterschiedliche Funktionen

• und wir fügen mehr hinzu, als auf der k8s-Ebene unbedingt erforderlich ist.

Ich sehe zwei recht unterschiedliche Anwendungsfälle, die oben beschrieben wurden - je nach Quelle unterschiedlich
der Wahrheit:

_Vorschreibend:_ "Ich möchte, dass N Shards ausgeführt werden, und wenn es mehr oder weniger sind
als das, dann nehmen Sie Änderungen vor, um es wieder auf N zu bringen."
_Beschreibend:_ "Ich möchte einfach alle verfügbaren Shards automatisch erkennen und
lass es mich irgendwie herausfinden, wenn sie kommen und gehen."

Ich denke, diese sind unterschiedlich und sollten anders beschrieben werden (obwohl

sie könnten ähnliche Metadaten wie die tatsächlich ausgeführten Pods präsentieren).

In die Diskussion wurden auch Ressourcenzäune und Single-Access einbezogen
garantiert. Afaics, der _einzige_ Fall, in dem dies innerhalb von k8s erfolgen muss
(afaics) mountet Remote-Volumes - weil der fs-Mount durchgeführt werden muss
außerhalb des Behälters. Alle anderen Fälle können von den Benutzerjobs bearbeitet werden
selbst, indem sie einen verteilten Sperrdienst verwenden (oder auf Dienste zugreifen, die
sorgen für interne Verriegelung). Das Auffordern der Jobs, ihre eigene Sperre durchzuführen, wird geöffnet
alle möglichen Muster auf (feste Zuweisung, opportunistische Zuweisung, "heiße"
Spares" usw.) und Unerreichbarkeits-/Wiederherstellungsstrategien (Hard Fail,
weiter-mit-zuletzt bekannt usw.).

Ich schlage vor, die allgemeine Funktionsanforderung für das Ressourcen-Fencing daraus zu entfernen
Fehler (und wir implementieren Fencing, indem wir einfach ein Rezept für das Laufen bereitstellen
verschiedene verteilte Sperrdienste auf k8s ohne weitere Beteiligung von
k8s selbst).

Ich glaube nicht, dass wir das Ziel entkoppeln können, um bestimmte Arten von auszuführen
Software out - das Design sagt nominelle Dienste aus, aber die Anwendungsfälle, die wir sind
Beschreiben ist die Wiederverwendung von Identität und Datenträger. Ich stimme zu, Zäune ist Eigentum von
Volumen - aber den Erwerb eines Volumens an eine bestimmte Eigenschaft von
die Pod-Instanz ist es nicht.

Nur zur Erinnerung: Hinter einem einzelnen VIP stecken _viele_ Ports. Ich stimme zu, wir
Ich möchte keine IPs migrieren, da das für das zugrunde liegende Netzwerk schwer klingt
maßstabsgetreu und umständlich für das Netzwerk, mit temporären Duplikaten umzugehen
während der Fehler-/Wiederherstellungs-Edgefälle. Aber ich denke, es _ist_ durchaus machbar
um jedem Shard-Mitglied einen eindeutigen Service-Port und jedem Proxy-Daten zuzuweisen
Pod-Instanz - auch für sehr große Jobs. (Dieser Vorschlag geht davon aus, dass
Proxies sind immer noch die Richtung, in die wir mit k8s gehen wollen - ich habe nicht mitgehalten
mit allen aktuellen Diskussionen in diesem Bereich)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

Leichte Wendung zu @thockins ThingPool + Patches-Idee:

Vorlage: Liste der Ressourcen + Parameter und Ersetzung. Inspiration finden Sie unter https://github.com/openshift/origin/blob/master/pkg/template/api/types.go . Nr. #503, #1743, #4210, #6487.

Vorlagenpool. Grundsätzlich ThingPool. Generiert dicht indizierte Vorlageninstanzen bei Bedarf statt nach Anzahl der Replikate.

Aus Spaß/Konsistenz: v2 ReplicationController könnte beliebige Vorlagen anstelle von nur Pods replizieren. Ref # 170 (irgendwie). Möglicherweise nicht erforderlich, wenn die gesamte Zuweisung durch die Pod-Replikation gesteuert wird.

Die Hauptalternative wäre etwas Domänenspezifischeres, das sich auf Hostnamen- und PVC-Pools konzentriert, aber separate Pools für jeden würden nicht funktionieren. Ein einzelner Pool müsste in der Lage sein, Tupel von Hostnamen und (möglicherweise mehrere) PVCs zuzuweisen. Ein Vorteil des TemplatePools besteht darin, dass jemand damit einen Dienst (eventuell extern) pro Replikat zuweisen kann, wodurch die aktuelle Zookeeper-Problemumgehung automatisiert wird. Ich weiß nicht, ob es andere Ressourcen gibt, die jemand ähnlich 1-zu-1 mit Pods replizieren möchte, aber angesichts der Geschwindigkeit, mit der unsere API wächst, würde ich nicht wetten, dass es sie nicht geben wird.

@smarterclayton FYI Wenn Sie per E-Mail mit Inline-Kommentaren antworten, sind Ihre Antworten sowohl in Google Mail als auch auf Github nicht lesbar. In Google Mail gibt es keine Zeilenumbrüche und in Github keine Präfixe für Anführungszeichen, sodass Ihre Antwort abgesehen vom zitierten Text schwer zu hänseln ist.

Ja, mit Google Mail + Github + iPhones stimmt etwas nicht.

Am Do, 20. August 2015 um 14:24 Uhr, Brian Grant [email protected]
schrieb:

@smarterclayton https://github.com/smarterclayton Zu Ihrer Information, wenn Sie antworten
per E-Mail mit Inline-Kommentaren, Ihre Antworten sind unlesbar, sowohl in
gmail und auf github. In gmail gibt es keine Zeilenumbrüche und in github gibt es da
sind keine Präfixe in Anführungszeichen, daher ist Ihre Antwort schwer zu leugnen, abgesehen von den
zitierter Text.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Leitender Ingenieur, OpenShift

Wir hatten heute ein kurzes Gespräch, einige Highlights:

Über die drei Klassen von Apps gesprochen:

• Apps, die zustandslose Web-Apps sind (funktioniert nur mit RCs)
• Riesige Apps, die externe Master verwenden und über eine bestehende Kohärenz verfügen
  Protokolle (Cassandra, Infiniband) zur Handhabung von Konsens
• Kleine geclusterte Stateful-Software wie Mongodb, rethinkdb, volt, etcd,
  Tierpfleger, Riak, Redis-Cluster, die ein paar Muster benötigen, um gut zu funktionieren
  
  
  
  • Eindeutige Identität (normalerweise)
  
  
  • Eindeutiges persistentes Volumen pro wiederverwendeter Instanz (normalerweise)
  
  
  • Stabile IP-Adresse oder DNS-Name (normalerweise) - DNS-Name ist normalerweise a
    
    steht für stabile IP-Adresse
  
  
  • Stabiler Hostname (selten)
  
  

Heute können Sie eine eindeutige Identität und ein persistentes Volumen lösen, indem Sie N
Replikationscontroller, stabile IP-Adresse mit N Diensten. Wir würden gerne
für einige dieser Anwendungsfälle keine N RCs und Dienste zu benötigen.

Wir sprachen über die Vorschläge von Tim und Brian, in keiner bestimmten Reihenfolge:

• TemplatePool ist problematisch, da der Replikator die
  Berechtigung zum Erstellen von Objekten im gesamten Cluster und muss wissen
  wo sich jeder API-Endpunkt befindet.
  
  
  
  • Sie könnten einen instanziierten Vorlagenendpunkt haben, müssen es aber trotzdem
    
    das Problem der Autoritätsdelegierung lösen (mit Dienstkonten?)
  
  
  • Das Auffinden von Objekten und das Einschränken von Berechtigungen sind längerfristige Dinge
  
  
• Das "Pod-Identität" alias vuid-Feld, über das wir gesprochen haben - das Argument wurde vorgebracht
  und allgemein damit einverstanden, dass es nicht global einzigartig sein muss, nur
  eindeutig innerhalb der Domäne, von der der Pod sie erwartet.
  
  
  
  • Ein hypothetischer Indexzuweiser (sparse oder dicht) könnte diesen Wert festlegen
    
    Post-Erstellung, und das Kubelet konnte warten, um Pods zu starten, bis sie ein
    
    Identität (möglicherweise muss angegeben werden, dass sie auf eine warten)
  
  
  • Dichte Indizes sind im Allgemeinen für einfache Dinge nützlich, aber weil dies
    
    ist die Post-Erstellung und vom Kubelet entkoppelt, du könntest anders sein
    
    Arten von Zuweisungsalgorithmen (dichte numerische, konsistente Hash-Ringe,
    
    zufällig usw.)
  
  
• Einfaches Templating auf Pods scheint ein guter Anfang zu sein, aber wir brauchen
  um es mit unserer bestehenden Werkzeugkette auf eine Weise in Einklang zu bringen, die es nicht tut
  total kaputt machen
  
  
  
  • Verwenden Sie das Identitätsfeld, um andere Felder mit Vorlagen zu versehen
  
  
• Fügen Sie in der Pod-Spezifikation ein Hostnamensfeld hinzu, das Benutzer selbst festlegen können und
  mit der Identität parametrisieren
• Zulassen, dass ein Headless-Dienst auf DNS-Abfragen für Endpunkte durch seine
  Identität (lassen Sie den Endpunkt-Controller die Identität aus einem Pod materialisieren
  in Endpunkte), was eine gewisse Stabilität garantiert
• Irgendwie erlauben, dass persistente Volume-Ansprüche parametrisiert oder geändert werden in
  aus einem Pool beziehen (oder einen Pool-Controller haben, um sicherzustellen, dass es ein Volume pro
  Identität, oder lassen Sie den Identitätscontroller aus Pools schöpfen), muss nachgedacht werden
• Benötigen Sie Tools, die es einfach machen, Umgebungs- / Abwärts-APIs in umzuwandeln
  config-Dateien (orthogonal, sollte aber einfacher sein)
• Noch einige Bedenken bezüglich des Musters

Am Do, 20. August 2015 um 15:34 Uhr, Clayton Coleman [email protected]
schrieb:

Ja, mit Google Mail + Github + iPhones stimmt etwas nicht.

Am Do, 20. August 2015 um 14:24 Uhr, Brian Grant [email protected]
schrieb:

@smarterclayton https://github.com/smarterclayton Zu Ihrer Information, wenn Sie antworten
per E-Mail mit Inline-Kommentaren, Ihre Antworten sind unlesbar, sowohl in
gmail und auf github. In gmail gibt es keine Zeilenumbrüche und in github gibt es da
sind keine Präfixe in Anführungszeichen, daher ist Ihre Antwort schwer zu leugnen, abgesehen von den
zitierter Text.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

Clayton Coleman | Leitender Ingenieur, OpenShift

Clayton Coleman | Leitender Ingenieur, OpenShift

Noch ein Problem: TLS-Zertifikate für Mitglieder eines nominellen Dienstes

TLS-Zertifikate für Dienstleistungen im Allgemeinen wären auch eine gute Sache (signiert
durch die Cluster-CA automatisch auf Anfrage).

Am Do, 20. August 2015 um 17:19 Uhr schrieb Brian Grant [email protected] :

Noch ein Problem: TLS-Zertifikate für Mitglieder eines nominellen Dienstes

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Clayton Coleman | Leitender Ingenieur, OpenShift

Ja: #11725

Betreff:

• Fügen Sie in der Pod-Spezifikation ein Hostnamensfeld hinzu, das Benutzer selbst festlegen können und
  mit der Identität parametrisieren
• Zulassen, dass ein Headless-Dienst auf DNS-Abfragen für Endpunkte durch seine
  Identität (lassen Sie den Endpunkt-Controller die Identität aus einem Pod materialisieren
  in Endpunkte), was eine gewisse Stabilität garantiert

Ich glaube, wir waren uns einig, dass DNS mit den Hostnamen unterstützt werden sollte, die in den Pod-Spezifikationen festgelegt sind (die durch ihre Identitäten parametrisiert werden könnten, sobald wir diese Funktionalität hinzufügen), sodass die von den Containern gesehenen Hostnamen von anderen Containern auflösbar wären.

Um die Subdomain festzulegen, müssen wir dem Pod explizit oder implizit mitteilen, welcher Dienst darauf ausgerichtet ist. Der Nachteil von explizit ist, dass mehr Konfigurationskleber/Vorlagen benötigt werden. Der Nachteil von implizit ist, dass es anfällig für die Herausforderungen wäre, die wir mit einer losen Kopplung im System haben: Rassen in der Erstellungsreihenfolge und Inkonsistenz, 1-zu-1-Erzwingungsschwierigkeiten usw. Ich tendiere zu explizit. Wir sollten nur daran arbeiten, den Umfang der Querverweise zu verbessern.

Etwas wie:

Hostname string
Subdomain string

über HostNetwork in der PodSpec.

Wir würden das Hostnamen-basierte DNS nur liefern, wenn die Subdomain mit der für einen Dienst des richtigen Typs übereinstimmt. Wir könnten die beiden auch in ein einziges Feld smoosen.

Ich denke, wir sollten Ausgabe Nr. 4825 dafür umfunktionieren und jemanden dazu bringen, daran zu arbeiten. Es ist viel konkreter und weniger Arbeit als der Rest.

Irgendwie erlauben, dass persistente Volume-Ansprüche parametrisiert oder geändert werden in
aus einem Pool beziehen (oder einen Pool-Controller haben, um sicherzustellen, dass es ein Volume pro
Identität, oder lassen Sie den Identitätscontroller aus Pools schöpfen), muss nachgedacht werden

Zwei Dinge zu Behauptungen können hier meiner Meinung nach hilfreich sein:

1. Bindung ändern von 1:1 auf 1:N
   
   
   
   1. pvc.Spec.VolumeName zu pvc.Spec.VolumeNames[] als Bindungsreferenz
   
   
2. pvc.Spec.Singelton boolescher Wert, der angibt, ob ein Anspruch genau einmal für die gemeinsame Nutzung gebunden werden soll oder ob der Anspruch viele Male gebunden werden soll.

Ein RC kann bei Bedarf an neue Volumes binden. Ich würde herausfinden, wie ich das im Ordner handhabe.

Es wäre immer noch wichtig, die richtige Lautstärke dem richtigen Pod zuzuordnen.

Sie müssten eine Zuordnung von Identitäten zu Volume-Namen haben.

Am Freitag, 21. August 2015 um 15:17 Uhr, Mark Turansky [email protected]
schrieb:

Irgendwie erlauben, dass persistente Volume-Ansprüche parametrisiert oder geändert werden in
aus einem Pool beziehen (oder einen Pool-Controller haben, um sicherzustellen, dass es ein Volume pro
Identität, oder lassen Sie den Identitätscontroller aus Pools schöpfen), muss nachgedacht werden

Zwei Dinge zu Behauptungen können hier meiner Meinung nach hilfreich sein:

1. Bindung ändern von 1:1 auf 1:N
   
   
   
   1. pvc.Spec.VolumeName zu pvc.Spec.VolumeNames[] als Bindung
      
      Hinweis
   
   
2. pvc.Spec.Singelton boolescher Wert, der angibt, ob ein Anspruch gebunden werden soll
   genau einmal zum Teilen oder zulassen, dass der Anspruch mehrmals gebunden wird.

Ein RC kann bei Bedarf an neue Volumes binden. Ich würde herausfinden, wie ich damit umgehen soll
im Binder.

Es wäre immer noch wichtig, die richtige Lautstärke dem richtigen Pod zuzuordnen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

Clayton Coleman | Leitender Ingenieur, OpenShift

Am Freitag, den 21. August 2015 um 00:56 Uhr schrieb Brian Grant [email protected] :

Um die Subdomain festzulegen, müssen wir dem Pod mitteilen, welcher Dienst darauf ausgerichtet ist.
explizit oder implizit. Der Nachteil von explizit ist, dass es mehr erfordert
Konfiguration Kleber / Schablone. Der Nachteil von implizit ist, dass es
anfällig für die Herausforderungen, die wir mit loser Kopplung im System haben: Erstellungs-
Ordnungsrennen und Inkonsistenz, 1-zu-1-Durchsetzungsschwierigkeiten usw. Ich lehne mich
in Richtung explizit. Wir sollten nur daran arbeiten, den Umfang der Querverweise zu verbessern.

Um es klar zu sagen - wenn wir KEINE Subdomain festlegen, können wir die Benutzer nicht bereitstellen
ihre eigenen Hostnamen. Wenn wir Subdomain setzen, müssen wir dies in a . tun
die eindeutig genug ist (im DNS-Raum, was derzeit quer bedeutet)
der Namensraum). Die Subdomain zum Namen eines Dienstes zu machen ist
einzigartig genug.

Angesichts einiger Einschränkungen unseres DNS (einer einzigen TLD) ist dies
realistisch bedeutet, dass wir den Benutzern zwei DNS_LABEL-Felder geben - hostname
und Nominalsatz. Für ein konkretes Beispiel:

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

Dies würde dazu führen, dass der Pod Folgendes sieht:

$ hostname
foo

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

und DNS, die A- und PTR-Einträge für foo.bar.my-app.nom.cluster.local serving bereitstellt

Dies ist eine Ebene tiefer als unsere aktuelle DNS-Struktur, aber ich denke
unser aktuelles ndots=5 deckt dies ab. Alternativ könnten wir sagen, dass a
namespace IST der Nachname, und geben Sie ihn den Benutzern zurück, um ihn eindeutig zuzuweisen
Hostnamen in einem Namespace. Das DNS-Ergebnis wäre
foo.my-app.pod.cluster.local das Dienste spiegelt. Wir könnten sogar
Machen Sie sie ähnlicher, indem Sie den Diensten ein optionales Feld für den Hostnamen hinzufügen.

Wir würden das Hostnamen-basierte DNS nur liefern, wenn die Subdomain damit übereinstimmt
ein Service der richtigen Art. Wir könnten die beiden auch in ein einziges Feld smoosen.

Was mir am wenigsten gefällt, ist, dass der Pod sagt: "Ich bin ein Teil"
of Service 'bar'" (im obigen Beispiel). Vorne. A priori.

Der rutschige Hang ist, warum dies nicht generell zulassen? Es würde
vereinfachen eine Reihe von Dingen, die heute keine Annahmen treffen können (weil
lose Kopplung), obwohl wir in der Praxis selten einen einzelnen Pod sehen
hinter mehr als einem Dienst. Wenn jeder Pod unter null oder eins wäre
Service, wird das System einfacher?

Ich denke, wir sollten Ausgabe Nr. 4825 dafür umfunktionieren und jemanden dazu bringen, daran zu arbeiten. Es ist viel konkreter und weniger Arbeit als der Rest.

Es ist sicherlich etwas, das sofort beginnen könnte, aber (für diejenigen
zu Hause mitverfolgen) ist es nur der Mechanismus zur Implementierung von pod
Identität, nicht die Politik der Verwaltung von Identitäten.

Am Freitag, den 21. August 2015 um 15:17 Uhr schrieb Mark Turansky [email protected] :

Zwei Dinge zu Behauptungen können hier meiner Meinung nach hilfreich sein:

1. Bindung ändern von 1:1 auf 1:N

Hiermit habe ich angefangen, aber...

Am Fr, 21. August 2015 um 12:38 Uhr, Clayton Coleman
[email protected] schrieb:

Sie müssten eine Zuordnung von Identitäten zu Volume-Namen haben.

Ja. Dies stellt sich wirklich nur als Vorlagenproblem heraus.
Ob Sie sich das Problem als "Pod-Vorlage" vorstellen, in der einige
Felder haben Platzhalter, die durch ein "Ersetzungstupel" ausgefüllt werden
zur Laufzeit aus einem Pool gezogen oder du denkst, dass es sich um einen vollständig verdinglichten Pod handelt
Spezifikation, die mit einem aus einem Pool gezogenen "Ersetzungstupel" "aufgeflickt" wird
zur Laufzeit - sie sind isomorph und gleichermaßen unangenehm.

Und doch denke ich, dass dies eines der größeren Probleme ist, die wir lösen müssen.
Sollten wir anfangen, dafür Strohmann-Vorschläge auszuarbeiten?

Wir haben mehrere Beispiele für Pods, die unter zwei oder drei Diensten stehen, einer für
Ausbreitung, einer für die Exposition und einer zum Testen der Exposition.

Was die Identität betrifft, sollte jedem von einem Daemon-Controller erstellten Pod eine Identität zugewiesen werden, die aus der Knotenidentität und der Controller-Identität abgeleitet wird. Dies kann ein Fall sein, in dem die Identität offensichtlich ist (Pod x auf Host y hat die Identität f(y)) und Teil der Daemons-Verantwortung ist.

@smarterclayton Daher besteht hier ein allgemeines (aber nicht universelles) Bedürfnis darin, eine stabile, geordnete Liste von Gruppenmitgliedern zu führen. Wie könnte das funktionieren, wenn die Identität an den Knoten gebunden ist, auf dem der Pod geplant ist?

Der Daemon-Controller hat _nur_ Identität im Kontext des Knotens, der der Pod ist
lauf weiter. Replikationscontroller und -dienste sind unterschiedlich. Dämon
Controller sagt "es sollte auf jedem Knoten einer davon laufen". Dort
ist keine andere Identität, die ein Pod haben kann, außer seinem Knoten.

Am Freitag, 11. September 2015 um 01:13 Uhr, Angus Lees [email protected]
schrieb:

@smarterclayton https://github.com/smarterclayton also ein gemeinsames (aber nicht
universell) ist hier die Aufrechterhaltung einer stabilen, geordneten Liste von Gruppen
Mitglieder. Ich denke, das impliziert, dass die Identität _nicht_ an die gebunden werden sollte
Knoten, auf dem der Pod geplant ist.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

Clayton Coleman | Leitender Ingenieur, OpenShift

@smarterclayton ah, dieses Problem hat sich eindeutig in etwas mehr als die ursprüngliche Funktionsanfrage verwandelt - ich bin verloren, was hier versucht wurde, zu bauen, also werde ich mich zurückziehen, anstatt weiter Rauschen hinzuzufügen ...

Entschuldigung, wollte nicht andeuten, dass der Punkt nicht relevant ist. Die Herausforderung besteht darin, dass wir Sets definieren und diese in den Pod übertragen müssen. Der Pod muss auf die Mitgliedschaft im Set reagieren (Mount-Volume X, das der Pod-Identität im Set entspricht). Es gibt eine offene Frage - könnte ein Pod gleichzeitig Mitglied von zwei Sets sein und in beiden eine einzigartige Identität haben?

Es kann vorkommen, dass Pods, die von einem Daemon-Controller ausgeführt werden, eine "offensichtliche" Identität haben (der Daemon-Controller arbeitet auf einer Gruppe von Knoten, die RC auf einer Gruppe von Pods).

Eine Anforderung an die Identität ist, dass sie in der Menge eindeutig ist. Könnten wir Pod-Namen und die Pod-Namensgenerierung nutzen, um diese Einzigartigkeit zu gewährleisten? RCs generieren zum Beispiel zufällige Namen. Könnte ein RC Namen für die Pods auf deterministische Weise basierend auf den ausgewählten Pods generieren?

Betrachten Sie eine RC, die Pods mit dem Label a=b ​​auswählt. Um den nächsten zu erstellenden Pod zu berechnen, muss er Pods abrufen und auf eine Anzahl reduzieren. Was wäre, wenn wir es auf einen eindeutigen Namenssatz reduzieren und der RC dann versuchen würde, einem Namensgenerierungsmuster innerhalb dieses Satzes zu folgen? Zwei RCs, die sich nicht überschneiden, aber Pods zu einem Service-Label erstellt haben, könnten keine eindeutigen Namen generieren (sie kämpfen möglicherweise um einen Namen, aber das ist implizit). Namen können nach dem Löschen wiederverwendet werden

Dann könnten persistente Volumes im Pod PVCs basierend auf dem Pod-Namen verwenden. Ein PVC-Pooler könnte sicherstellen, dass genügend Ansprüche für einen beobachteten Pool von RCs vorhanden sind. Der Daemon-Controller kann Namen auswählen, die für einen Knotennamen deterministisch sind. Wir können DNS-Namen auch basierend auf einem bestimmten Muster mit Pod-Namen in einem Dienst verbinden.

Dies fühlt sich sparsamer an, als ein eindeutiges Identitätsfeld auf dem Pod hinzuzufügen. Es bedeutet, dass Schoten immer noch keine Haustiere sind, aber ihre Namen können es sein (was keine unvernünftige Aussage ist). Wir können nicht verhindern, dass zwei Instanzen desselben Pod-Prozesses gleichzeitig auf dem Cluster ausgeführt werden, aber wir können eine harte Garantie geben (und tun), dass der Name heute nur an einer Stelle verwendet wird.

Bedeutete oben "beobachteter Pool von Namen". Endpunkt-DNS wäre hashpodname.ept.service.namespace.svc.cluster.local. Wir haben den Pod-Namen bereits auf dem Endpunkt, sodass wir nicht einmal etwas hinzufügen müssen.

bezogen auf https://github.com/kubernetes/contrib/tree/master/service-loadbalancer, das eine Lösung dieses Problems als mögliche nächste Iteration vorschlägt

Warum diskutieren wir hier über DaemonSet? Das wurde von #12893, IMO, gelöst.

@smarterclayton Lassen Sie uns nicht das Ableiten der Identität aus Pod-Namen oder die Verwendung von RCs zum Zuweisen von Identitäten wiederholen. Probleme mit diesen Ansätzen wurden hier diskutiert: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

Eine Möglichkeit wäre, eine RC-Option zu haben, mit der Sie Namen wie von @smarterclayton beschrieben generieren

Es scheint, dass der Nutzen von so etwas wie der Borg-Aufgabenindexabstraktion _für bestimmte Anwendungsfälle_ immer wieder auftaucht, und mir ist nicht klar, warum wir sie nicht als Option anbieten können.

Ich glaube nicht, dass DaemonSet den Fall des verteilten Dateisystems löst
(Gluster), wobei jeder Host eine konsistente Identität haben muss, um wieder beizutreten
der Cluster. Ich werde weiter graben, aber ich denke, es braucht vielleicht noch etwas zusammen
die Anforderungen von #260 - Ich weiß nicht, ob der Hostname ausreicht, wenn Sie ihn erneut anhängen
eine Hostfestplatte auf einer neuen Instanz. Vielleicht habe ich nicht verstanden, was DaemonSet
bereitgestellt und #12893 geliefert, aber ich glaube nicht, dass das das Problem für a ist
Systemhost, der die Festplatte wiederverwenden möchte.

Am Mittwoch, 16. September 2015 um 00:22 Uhr, Brian Grant [email protected]
schrieb:

@smarterclayton https://github.com/smarterclayton Lass uns nicht nochmal vorbeischauen
Ableiten der Identität aus Pod-Namen oder Verwenden von RCs zum Zuweisen von Identitäten.
Probleme mit diesen Ansätzen wurden hier diskutiert: #260 (Kommentar)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Leitender Ingenieur, OpenShift

Stellen Sie sich als konkretes Beispiel einen etcd-Cluster vor. Es hat 7 Instanzen und 7
Bände. Ich möchte (aus Gründen der Argumentation) die Namen und Bände etcd-1
bis etcd-7 und etcd-pvc-1 bis etc-pvc-7.

Eine rollierende Bereitstellung hat MaxUnavailable 90 % (oder Äquivalent), MaxSurge 0 %. Es
skaliert den alten RC herunter und skaliert den neuen RC hoch. Der alte RC anmutig
löscht etcd-5. Es geht sofort aus dem effektiven RC-Set heraus. Das neue
RC versucht, etcd-5 zu erzeugen (durch Beobachtung der eingestellten Lücke). Es erhält a
"AlreadyExistsException". Es behandelt dies als Backoff und Requeues. Einmal
etcd-5 ist wirklich weg, es kann fortfahren. Sobald etcd-5 fertig ist, wird der DC
geht zum nächsten Schritt.

Für die Alternative - Identität auf Pod festgelegt - wird der alte RC verkleinert. EIN
Ein neuer Pod wird sofort mit einem neuen Namen erstellt. Der neue Pod kann nicht gestartet werden
weil es einen Identitätssatz benötigt, um herauszufinden, welches PVC für seine montiert werden soll
Volumen. Es geht in eine Warteschleife auf dem Kubelet. Der Identitätscontroller
beobachtet einige Label-Selektor-Sets und beobachtet die Identität etcd-5 ist es nicht
zugeteilt. Es setzt die Identität etcd-5 auf den neuen Pod. Das Kubelet beobachtet
diese Änderung und kann dann herausfinden, welches PVC zu montieren ist, startet die Kapsel
(vorausgesetzt, das Volume wurde vom anderen Knoten getrennt).

Strukturell sind diese sehr ähnlich. Letzteres ermöglicht eine Startüberlappung.
Beide erfordern eine Zuordnung des PVC.

Am Mittwoch, 16. September 2015 um 00:39 Uhr, Clayton Coleman [email protected]
schrieb:

Ich glaube nicht, dass DaemonSet den Fall des verteilten Dateisystems löst
(Gluster), wobei jeder Host eine konsistente Identität haben muss, um wieder beizutreten
der Cluster. Ich werde weiter graben, aber ich denke, es braucht vielleicht noch etwas zusammen
die Anforderungen von #260 - Ich weiß nicht, ob der Hostname ausreicht, wenn Sie ihn erneut anhängen
eine Hostfestplatte auf einer neuen Instanz. Vielleicht habe ich nicht verstanden, was DaemonSet
bereitgestellt und #12893 geliefert, aber ich glaube nicht, dass das das Problem für a ist
Systemhost, der die Festplatte wiederverwenden möchte.

Am Mittwoch, 16. September 2015 um 00:22 Uhr, Brian Grant [email protected]
schrieb:

@smarterclayton https://github.com/smarterclayton Lass uns nicht nochmal vorbeischauen
Ableiten der Identität aus Pod-Namen oder Verwenden von RCs zum Zuweisen von Identitäten.
Probleme mit diesen Ansätzen wurden hier diskutiert: #260 (Kommentar)
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

Clayton Coleman | Leitender Ingenieur, OpenShift

Clayton Coleman | Leitender Ingenieur, OpenShift

Die Sache, die dieses Problem für mich erschwert, ist, dass kein stabiler eindeutiger Pool von Namen generiert oder ein Pool von PDs verwendet wird. Das Problem ist, BEIDE gleichzeitig zu tun. Und wenn Sie das erweitern, warum kann dann nicht einfach jeder Bezeichner in der Spezifikation so zusammengefasst werden?

So viel ich (meist aus zweiter Hand) die Probleme mit gepackten Indizes kenne, denke ich, dass sie lebenswert sein könnten (insbesondere wenn wir tun, was David vorschlägt und sie sich mit anderen Funktionen gegenseitig ausschließen). Aber auch, je mehr ich darüber schmore, desto weniger hasse ich die Patch-Idee, die irgendein Idiot im Up-Thread gepostet hat.

Dieses Problem ist immer und immer wieder aufgetreten, und ich fürchte, wir haben eine Analyselähmung.

Ich wünschte, wir hätten mehr Beispiele für andere Anwendungsfälle für das Pooling. Ich dachte Gluster
wäre anders, aber es ist nur eine andere Variante auf dem
cassandra/etcd/mongo/zookeeper "Ich möchte ein Volume wiederverwenden und muss es tun
Erinnere dich, wer ich vorher gesagt habe." Wir hatten nicht wirklich eine rollenbasierte (I
wollen die ersten N-Pods-Koordinatoren und die nächsten M-Arbeiter) zum Beispiel machen
Hebeln.

Am Mittwoch, 16. September 2015 um 00:46 Uhr, Tim Hockin [email protected]
schrieb:

Die Sache, die dieses Problem für mich erschwert, ist nicht die Generierung eines stabilen
eindeutigen Namenspool verwenden oder einen Pool von PDs verwenden. Das Problem ist, BEIDES zu tun
die selbe Zeit. Und wenn du das ausdehnst, warum kann nicht einfach jeder?
Bezeichner in der Spezifikation wie folgt zusammengefasst werden?

Soweit ich weiß (meist aus zweiter Hand) die Ausgaben mit gepackten Indizes, ich
denken, dass sie lebenswert sein könnten (besonders wenn wir tun, was David vorschlägt und macht
sie schließen sich mit anderen Merkmalen gegenseitig aus). Aber auch, je mehr ich schmore
es, desto weniger hasse ich die Patch-Idee, die irgendein Idiot auf den Kopf gestellt hat.

Dieses Problem ist immer und immer wieder aufgetreten und ich fürchte, wir haben eine Analyse
Lähmung.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

Clayton Coleman | Leitender Ingenieur, OpenShift

Dämonenset:

12893 setzt den Pod-Hostnamen auf den Hostnamen des Knotens, wenn Host-Networking verwendet wird, was für DaemonSet völlig vernünftig ist, da diese ansonsten sowieso hostPort verwenden würden.

Außerdem besteht die Absicht darin, DaemonSet mit dem Node-Controller zu integrieren, um implizite unbestimmte Vergebung #1574 bereitzustellen und "Scheduling" zu ermöglichen, bevor das Scheduling für Knoten im Allgemeinen aktiviert wird. Auch eine implizite Priorisierung kann sinnvoll sein.

Für ein Cluster-Speichersystem könnte ich mir vorstellen, auf jedem Host zusätzliche Festplatten bereitzustellen, auf die nur das Speichersystem über hostPath zugreift – sie würden weder von Docker noch von emptyDir verwendet.

In Bezug auf die Identität sehe ich kein Problem mit dem Vorschlag hier: https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Dieses Problem ist vor allem aufgrund mangelnder Priorität, IMO, nach wie vor geblieben.

Um Clayton zu riffen (oder vielleicht nur das Gleiche zu sagen, aber dümmer):

$ 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

Die Implikation ist, dass der RC (oder etwas) erkennt, dass dies ein Identitätssatz ist, einen Index aus dem identityPool zuweist, diese Identität dem Pod-Namen zuweist und dann hineinschaut, um zu sehen, ob andere identitätszentrierte Felder festgelegt sind – die Identität Lautstärke in diesem Fall.

Es ist nicht ganz allgemein (Sie können keine zufälligen Felder zusammenfassen), aber wir können bei Bedarf weitere ident-sensitive Optionen hinzufügen

Ich habe das Gefühl, dass wir früher oder später fertig werden, wenn wir eine Spezifikation festnageln, die uns gefällt.

Auch das Schreiben einer Spezifikation braucht Zeit.

In Bezug auf IdentityPool/VolumePool haben wir schon vor langer Zeit entschieden, dass mehrere Pools nicht funktionieren.

Die Frist für die Vervollständigung des 1.1-Codes ist Freitag. Könnten wir das bitte jetzt nicht tun?

Auch verwandt: #170. Das schlug vor, nur die Pod-Vorlage aufzuteilen, aber wenn wir uns für ein Vorlagenschema entscheiden (das ich dem Patch stark vorziehe), sollten wir sie zusammen betrachten.

Ich habe zumindest das Design auf v1.2-Kandidat gestellt.

Entschuldigung, ich war in meiner Skizze nicht klar - der RC (oder IC?) hat ein Konzept von
primärer Pool oder Index. Sobald einem Pod im IC ein Index zugewiesen wurde, ist das
index wird verwendet, um in alle Pool-zentrierten Felder zu indizieren.

Wenn wir die Vorlage aufteilen, gehe ich davon aus, dass der RC dies nicht kann
die Vorlage mutieren. Das ist etwas kniffliger.

Ich kann diese Woche nicht mehr darüber reden. Es ist mir gerade eingefallen
Posteingang und ich hatte an dieser Idee herumgekaut...

Am Dienstag, 15. September 2015 um 22:09, Brian Grant [email protected]
schrieb:

Auch das Schreiben einer Spezifikation braucht Zeit.

In Bezug auf IdentityPool/VolumePool haben wir uns schon lange entschieden
vor, dass mehrere Pools nicht funktionieren.

Die Frist für die Vervollständigung des 1.1-Codes ist Freitag. Könnten wir das bitte jetzt nicht tun?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

Ja, es gab einfach Dinge, die bei uns Diskussionen auslösten.
Kundenprobleme warten auf keinen Freigabeprozess.

Am Mittwoch, 16. September 2015 um 01:14 Uhr, Tim Hockin [email protected]
schrieb:

Entschuldigung, ich war in meiner Skizze nicht klar - der RC (oder IC?) hat ein Konzept von
primärer Pool oder Index. Sobald einem Pod im IC ein Index zugewiesen wurde, ist das
index wird verwendet, um in alle Pool-zentrierten Felder zu indizieren.

Wenn wir die Vorlage aufteilen, gehe ich davon aus, dass der RC dies nicht kann
die Vorlage mutieren. Das ist etwas kniffliger.

Ich kann diese Woche nicht mehr darüber reden. Es ist mir gerade eingefallen
Posteingang und ich hatte an dieser Idee herumgekaut...

Am Dienstag, 15. September 2015 um 22:09, Brian Grant [email protected]
schrieb:

Auch das Schreiben einer Spezifikation braucht Zeit.

In Bezug auf IdentityPool/VolumePool haben wir uns schon lange entschieden
vor, dass mehrere Pools nicht funktionieren.

Die Frist für die Vervollständigung des 1.1-Codes ist Freitag. Könnten wir das bitte nicht tun
jetzt?

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868

.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

Clayton Coleman | Leitender Ingenieur, OpenShift

Die Diskussion dreht sich nur um IP-Nummern und Pods, aber meiner Erfahrung mit Mongo & Zookeeper zufolge sollte die IP der Pods irrelevant bleiben (nicht zu Haustieren werden). Das persistente _volume_ benötigt eine nominelle Nummer, da dieses Volume die IP-Nummer der anderen 'Volumes' aufzeichnet. Jeder Pod, der dieses Volume bereitstellt, sollte diese aufgezeichnete IP-Nummer irgendwie verwenden können. Die Lautstärke ist das Haustier ...

Ein DNS-Name, der für ein Volume zeitlich konstant ist und einem Pod zugewiesen wird, der das Volume bereitstellt, würde meiner Meinung nach weit reichen.

Das Ändern der Ensemblemitgliedschaft in Mongo & ZK erfordert immer die Ausführung von benutzerdefiniertem Code, und ich erwarte, dass dies für die meisten anderen Ensembles derselbe ist. Replikationscontroller ist also der falsche Name, diese Haustiere brauchen mehr einen Mitgliedsschiff-Controller. Ein Controller eines Mitgliedsschiffs sollte in der Lage sein, die anfängliche Einrichtung und dann inkrementelle Änderungen an den Ensembles zu bewältigen und sie schließlich zu beenden.

Angesichts eines konstanten DNS-Namens basierend auf dem bereitgestellten Volume und der Möglichkeit, die Ensemble-Mitgliedschaft mit benutzerdefiniertem Code zu verwalten, sollte es meiner Meinung nach möglich sein, diese Art von Systemen zu handhaben.

Ja, Pod-IP ist eher ein kurzfristiger Hack.

Wohin dieser Vorschlag führt, ist etwas, das über DNS und Volumen hinausgeht, das beide
nutzen können, um gekoppelt zu bleiben. Das Problem besteht darin, dass das Volume den DNS-Namen definiert
ist die Umkehrung der Kopplung, die wir bereits etabliert haben, und wir auch
möchten, dass andere Teile der Pod-Spezifikation dieses höhere Konzept nutzen
(Identität) wie die Abwärts-API für die Umgebung. Das macht Anpassung
Identität mit unterschiedlicher Ensemble-Software einfacher (reduziert den benutzerdefinierten Code pro
Typ).

Wir müssen dennoch sicherstellen, dass es keinen Anwendungsfall jenseits von Ensembles gibt, der
überschneidet sich hier (habe noch keinen Vorschlag gehört) und versuche dann, zu einem zu gelangen
konkreten Vorschlag, der sich minimal und angemessen anfühlt. Tim glaube ich hat
fasste das zuletzt hier zusammen.

Am 23. September 2015 um 11:33 Uhr schrieb Peter Kriens [email protected] :

In der Diskussion dreht sich alles um IP-Nummern und Pods, aber meiner Erfahrung nach mit
Mongo & Zookeeper die IP die Pods sollten irrelevant bleiben (nicht zu Haustieren werden).
Das persistente _volume_ benötigt eine nominelle Zahl, da dieses Volume aufzeichnet
die IP-Nummer der anderen 'Volumes'. Welcher Pod auch immer dieses Volumen bereitstellt
sollte in der Lage sein, diese aufgezeichnete IP-Nummer irgendwie zu verwenden. Die Lautstärke ist die
Haustier ...

Ein DNS-Name, der für ein Volume zeitlich konstant ist und einem Pod zugewiesen ist, der
Mounts würde die Lautstärke ein langer Weg kommen, denke ich.

Der Wechsel der Ensemblemitgliedschaft in Mongo & ZK erfordert immer eine Anpassung
Code auszuführen, und ich erwarte, dass er für die meisten anderen Ensembles gleich ist. So
Replikationscontroller ist der falsche Name, diese Haustiere brauchen mehr ein Mitglied
Schiffscontroller. Ein Controller für Mitgliedsschiffe sollte in der Lage sein, die
Ersteinrichtung und dann schrittweise Änderungen an den Ensembles und schließlich
töte es ab.

Ein konstanter DNS-Name basierend auf dem bereitgestellten Volume und die Möglichkeit,
die Ensemblemitgliedschaft mit benutzerdefiniertem Code zu behandeln, sollte es ermöglichen,
Ich denke, mit solchen Systemen umgehen zu können.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

/Klingeln

Ein Beispiel für die Einrichtung eines ZK-Clusters unter Kubernetes mit den vorhandenen Fähigkeiten finden Sie unter https://hub.docker.com/r/elevy/zookeeper/. Die wichtigste Voraussetzung sind stabile IP-Adressen und Hostnamen für die Ensemblemitglieder. Dies wird mithilfe individueller Dienste für jedes Cluster-Mitglied erreicht. Der einzige Nachteil ist, dass ZK standardmäßig versucht, sich an die IP zu binden, in die sein Hostname aufgelöst wird, aber dies kann durch einen Konfigurationsparameter vermieden werden.

@smarterclayton @thockin

Gedanken beim Fahrradfahren ins Büro vor ein paar Tagen:

Ich betrachte dies derzeit als PetSet-Controller oder vielleicht als ShardSet-Controller, wenn die Leute so darüber nachdenken wollen, wie eingangs besprochen: https://github.com/kubernetes/kubernetes/issues/260# Ausgabekommentar -57671926.

Der Fall, den wir ansprechen möchten, ist, dass es N ähnliche Haustiere gibt, aber sie sind immer noch Haustiere – sie sind nicht fungibel.

Ich denke immer noch, dies an ReplicationController zu binden, kann nicht funktionieren, teilweise weil ReplicationController nur eine einzige Vorlage hat. PetSet/ShardSet muss eine Abstraktion auf höherer Ebene sein, eher wie Deployment oder DaemonSet. PetSet könnte potenziell ein PodTemplate-Objekt pro Instanz generieren.

Ich glaube nicht, dass wir die Bereitstellungs-API einfach wiederverwenden können. Unter anderem funktioniert die Rollout-Strategie für rollierende Updates jetzt in kubectl und Deployment in diesem Fall nicht. Die meisten Haustiere würden wahrscheinlich Recreate-Updates wünschen, und alle, die Rolling-Updates wollten, wären nicht in der Lage, einen Anstieg über ihre Shard-Anzahl zu bewältigen, und würden die Update-Reihenfolge besonders berücksichtigen.

So sehr ich die Idee mag, ich glaube nicht, dass eine Identitätszuweisung von unten nach oben funktionieren wird. Zu viele Race-Bedingungen mit Rückgabe zugewiesener Identitäten an den Pool vs. Zuweisung neuer Identitäten. Ähnliche Probleme, auf die @erictune stieß, als sie die Verwendung von RabbitMQ mit Job untersuchten.

Ich möchte die Skalierung des PetSet nicht an mehr als einer Stelle darstellen, beispielsweise in einem Controller und in einem Identitätspool oder in einem Controller und in einem Dienst, da dies die Skalierung schwierig/umständlich machen würde.

Ich glaube nicht, dass wir für diesen Fall universelle Vorlagen benötigen. Wir müssen nur Pods mit zugehörigem Speicher und vorhersehbaren, dauerhaften Netzwerkidentitäten ausmerzen. Das grobe Äquivalent hat in Borg gereicht. Daher tendiere ich stark zu etwas in der Art von #12450, aber in der Pod-Vorlage und nicht in den Pods selbst. Vielleicht ein Array von persistentVolumeClaimTemplates zusätzlich zu einem podTemplate. Ich möchte nicht alle Cloud-Anbieter-spezifischen Volume-Quellen ausgefallen ersetzen, zumal wir diese sowieso verwerfen wollen. Das Hinzufügen zusätzlicher Anforderungen und/oder Selektoren zu PVCs sollte ausreichend sein. Wir müssen auch irgendwann in der Lage sein, persistente Volumes bereitzustellen.

Wir werden irgendwann noch etwas bezüglich des lokalen Speichers tun müssen, aber ich denke, das ist trennbar.

Und dann ändert sich der oben erwähnte Hostname und der Headless-Dienst hier:
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

Arbeite jetzt an einem Vorschlag, ein Entwurf wird bald vorliegen.

Vorschlag ist in https://github.com/kubernetes/kubernetes/pull/18016

... wo stehen wir also bei PetSet?

Ich baue HA-Datenbanklösungen auf Kubernetes. Einige, insbesondere Single-Master-Datenbanken, erfordern Dienste mit Endpunkten, die bestimmten Pods basierend auf Ereignissen von diesen Pods zugeordnet werden. Beispielsweise:

1. service "postgres" ordnet Round-Robin allen Pods im ReplicaSet zu, aber service "postgres-master" ordnet nur einem Pod zu.
2. der Master-Pod stirbt.
3. Failover passiert. Als Teil des Failovers aktualisiert der neue Master Kube-master über die API, um den postgres-master-Dienst zu "greifen".
4. Dabei werden alle vorherigen Verbindungen zu postgres-master beendet.

@jberkus der anfängliche @ingvagabund aus meinem Team wird anfangen, Beispiele zusammenzustellen, die PetSet verwenden, um zu sehen, was gut funktioniert und was noch verbessert werden muss. Ich würde Ihnen empfehlen, sich an ihn zu wenden, wenn Sie einige spezifische Anwendungsfälle haben, die Sie zusammenstellen und testen möchten.

@ncdc Ist in v1.3 alles dafür getan? Es ist unklar, da der Vorschlag nicht zusammengeführt ist und es seit einiger Zeit keine anderen PRs mehr gegeben hat, die sich darauf beziehen.

@bprashanth ^

Wir landen e2es und arbeiten weiter an Beispielen. Es ist in Alpha
jetzt, aber der Vorschlag wird die erste Runde des Alpha-Feedbacks benötigen
vor dem Zusammenführen.

Am 19. Mai 2016 um 10:25 Uhr, Brandon Philips [email protected]
schrieb:

@ncdc https://github.com/ncdc Ist in v1.3 alles dafür gemacht? es ist
unklar, da der Vorschlag nicht zusammengeführt ist und es keine anderen PRs gab
verweise eine Weile darauf.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

Wo finde ich Unterlagen dazu? Ich würde es gerne für einen Anwendungsfall für ein Datenbank-Failover testen.

Ah ha, genau das, was wir für einen Postgres-Experten brauchen :)

siehe https://github.com/kubernetes/contrib/pull/921 für Beispiele, ich kann alle Fragen zum Prototyping von [db of choice] als Petset beantworten. Wir haben eine Reihe von Skizzen unter dem Label "apps/stateful" (zB: https://github.com/kubernetes/kubernetes/issues/23790, @philips ein etcd-Beispiel wäre toll). Ich habe noch keine Docs geschrieben, werde dies in den letzten Wochen von 1.3 tun (noch 5 Wochen bis zur Veröffentlichung, nachdem der Code am Freitag fertiggestellt wurde).

Ich vermute, Sie werden versuchen, das Failover mit Postgres zu automatisieren, da dies ziemlich üblich ist. Ich gebe zu, das ist derzeit noch nicht so einfach, wie ich es gerne hätte, du brauchst wahrscheinlich einen Watchdog. @jberkus Ich würde gerne Feedback dazu hören, welche Muster das einfacher machen.

Um Ihnen einen schnellen Überblick zu geben, bietet Ihnen das petset heute eine konsistente Netzwerkidentität (DNS, Hostname), die einem im Netzwerk bereitgestellten Volume entspricht, und Bestellgarantien. Wenn Sie also ein Haustierset mit replicas: 3 erstellen, erhalten Sie:
Regierender Dienst: *.galear.default.svc.cluster.local
mysql-0 - volume0
mysql-1 - volume1: startet nicht, bis 0 läuft und bereit ist
mysql-2 - volume2: startet nicht vor 0, 1 läuft bereit

Die Pods können DNS für die Diensterkennung verwenden, indem sie SRV-Einträge nachschlagen, die unter dem steuernden Dienst eingefügt wurden. Das macht dieser einfache Pod: https://github.com/kubernetes/contrib/pull/921/commits/4425930cea6f45385561313477662d6fb2ee2c62. Wenn Sie also den Peer-Finder über einen Init-Container wie in den obigen Beispielen verwenden, startet mysql-1 erst, wenn der Init-Container (mysql-1, mysql-0) im DNS sieht und die entsprechende Konfiguration schreibt.

Die Volumes werden von einem dynamischen Provisioner bereitgestellt (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md), wenn Sie also keinen haben in Ihrem Cluster laufen, aber nur Prototypen erstellen möchten, können Sie einfach emptyDir verwenden. Der Fall "data-gravity" (https://github.com/kubernetes/kubernetes/issues/7562) funktioniert noch nicht, wird es aber irgendwann.

Ich füge hinzu, dass es derzeit einfacher ist, "Beim Start"-Benachrichtigungen mit einer Liste von Peers über Init-Container zu übermitteln. Es ist klar, dass wir auch "On-Change"-Benachrichtigungen benötigen. Um Änderungen der Clustermitgliedschaft zu bemerken, müssen Sie derzeit eine benutzerdefinierte pid1 verwenden. Shared pid-Namespaces könnten dies erleichtern, da Sie dann einen Sidecar verwenden können, auch dies muss einfach funktionieren.

Ich habe einen Watchdog, es ist das Service-Failover, das komplizierter ist, als mir lieb ist. Werde testen, danke!

Ich muss auch etcd unterstützen, daher wird es in meiner Zukunft möglicherweise viele Tests geben.

@ncdc Wie ist der Status des

Sie können es bekommen, wenn Sie von HEAD bauen

@bprashanth mit dem

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

eingebettete yaml in Anmerkungszeichenfolgen? oof, autsch :(. danke aber, werde untersuchen, wie man ein Kassandra-Set macht.

das ist json. Es handelt sich um eine Alpha-Funktion, die einem GA-Objekt hinzugefügt wird (Init-Container in Pods).
@chrislovecnm arbeitet an Cassandra, möchte vielleicht nur auf ihn warten.

@paralin hier ist, woran ich arbeite. Keine Zeit, es jetzt zu dokumentieren und in das k8s-Repository zu übernehmen, aber das ist ein langfristiger Plan. https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra Arbeitet für mich lokal auf HEAD.

Das neueste C*-Image in der Demo funktioniert gut.

Wir haben ein Problem für weitere Dokumentation geöffnet. Zwinker, zwinker, knudge @bprashanth

PetSets-Beispiel mit etcd-Cluster [1].

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

Achten Sie darauf, Design-Anfragen im Angebotsdokument zu erfassen, nachdem Sie die Überprüfung abgeschlossen haben

Am 30. Juni 2016 um 1:25 Uhr schrieb Jan Chaloupka [email protected] :

PetSets-Beispiel mit etcd-Cluster [1].

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

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

die petset-Dokumente sind https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md und https://github.com/kubernetes/kubernetes.github. io/tree/release-1.3/docs/user-guide/petset/bootstrapping , habe ich vor, dieses Problem zu schließen und ein neues zu öffnen, das sich mit dem Verschieben von Petset in die Beta befasst, es sei denn, jemand widerspricht

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