Querverweis mit kubernetes / kubernetes: Ausgabe # 62822

Danke für das Update!

/ @leblancd zuweisen
/freundliches Feature
/sig-Netzwerk
/Meilenstein 1,11

@leblancd ein

/cc @thockin @dcbw @luxas @kubernetes/sig-network-feature-requests

@idvoretskyi -

Bedeutet dies, dass Kubernetes Ingress Dual-Stack unterstützt?
Bedeutet dies, dass CNI (Calico) Dual Stack ausführen muss (sowohl BIRD- als auch BIRD6-Daemons zum Beispiel)?

@sb1975 - Was die Unterstützung von Dual-Stack-Ingress

• Die Dual-Stack-Ingress-Unterstützung hängt hauptsächlich davon ab, welchen Ingress-Controller Sie verwenden (ob er unterstützt und wie er implementiert ist). Bestehende Ingress-Controller müssen wahrscheinlich einige Änderungen vornehmen, um Dual-Stack zu unterstützen.
• Ich erwarte, dass sich die Ingress- Konfiguration für einen typischen Ingress-Controller nicht ändert (die Konfiguration könnte z. B. immer noch eine L7-Adresse einem Dienstnamen / Dienstport zuordnen, ohne die V4/V6-Familie zu erwähnen).
• Für den Fall, dass ein Dienst über Dual-Stack-Endpunkt-Pods verfügt, müssen die Eingangscontroller möglicherweise Änderungen vornehmen, um Eingangspakete basierend auf der Paketfamilie zuzuordnen, dh IPv4-Eingangspakete einem IPv4-Endpunkt zuzuordnen und IPv6-Eingangspakete zuzuordnen zu einem IPv6-Endpunkt. Für die Lastenausgleichsgewichtung sollte ein Dual-Stack-Endpunkt als einzelnes Endpunktziel gelten.

- Wir möchten vielleicht die ZUKÜNFTIGE Unterstützung für eine Ingress-Controller-Zuordnung für V4/V6-Familien in Betracht ziehen (ingress-IPv4-Pakete einem IPv6-Backend zuordnen und umgekehrt), aber unsere anfängliche Entwicklung wird für strikten Dual-Stack (dh getrennt, unabhängig) sein Stapel).

Bezüglich Calico und anderen CNI-Plugins:

• Die CNI-Plugins MÜSSEN nicht im Dual-Stack-Modus ausgeführt werden, wenn ein Cluster-Szenario keinen Dual-Stack erfordert, sie sollten dennoch in der Lage sein, nur IPv4 oder nur IPv6 auszuführen (wenn das Plugin dies unterstützt).
• Die Dual-Stack-Unterstützung wird wahrscheinlich Änderungen in den verschiedenen CNI-Plugins erfordern, aber diese Arbeit wird außerhalb des Umfangs dieses Kubernetes-Problems betrachtet (wir konzentrieren uns darauf, Kubernetes für jedes beliebige Dual-Stack-Plugin zum Laufen zu bringen, wahrscheinlich unter Verwendung des Bridge-Plugins als eine Referenz) und die CNI-Arbeit wird von Fall zu Fall separat durchgeführt.
• Speziell für Calico bin ich kein Experte, aber ich glaube, dass ein einzelner BIRD-Daemon so konfiguriert werden kann, dass er sowohl IPv4- als auch IPv6-Routen verarbeitet (suchen Sie hier nach "template bgp": http://bird.network.cz/?get_doc&v= 20&f=bird-3.html#ss3.1). Obwohl Calico bereits Dual-Stack-Adressen im Pod unterstützt, sind möglicherweise Änderungen erforderlich, damit das BGP-Routing für beide Familien funktioniert.

@leblancd : Also hier ist das Szenario:

1. Nehmen wir an, wir werden den NGINX Ingress Controller verwenden
2. Ich stelle meine Dienste über Ingress zur Verfügung.
3. Ich betreibe meine Pods, die auf Dual-Stack konfiguriert sind
4. Ich versuche, den Dienst aus der Ferne mit A- und AAAA-DNS-Datensätzen zu erreichen.
   Hoffe das alles
5. Zusammenfassend: Ich möchte eine Verbindung zu Pod-Schnittstellen über IPv4- oder IPv6-Adressen herstellen, wie durch meine eigenen Abfragen nach A- und/oder AAAA-Einträgen für den Pod-Dienstnamen gelöst.
   Kann ich mich an dieser Initiative beteiligen, um zu testen, zu dokumentieren, Architektur zu erstellen, brauche aber etwas Anleitung.
   Wie erfahre ich bitte über den Fortschritt.

@ sb1975 - Gute Frage

• Wenn Sie versuchen, die Kube-Dienste von außen zu erreichen, sollte Ihr DNS-Controller den Dienst mit A- und AAAA-DNS-Einträgen für den Ingress-Controller auflösen. Es wäre die Entscheidung Ihres Clients/Ihrer App, den A- vs. den AAAA-Datensatz zu verwenden, um den Ingress-Controller zu erreichen. Der externe Zugriff auf den Ingress-Controller wäre also Dual-Stack.
• Am NGINX-Ingress-Controller würde NGINX dann die L7-URL prüfen (unabhängig davon, ob die Anfrage in einem IPv4- oder IPv6-Paket vorliegt) und diese Last auf Upstream-Endpunkte verteilen. Wenn der Load Balancer des Eingangscontrollers mit ipv6=on konfiguriert ist (was der Standardwert ist, siehe https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#configuring-http-load -balancing-using-dns) und die Dienstendpunkte sind Dual-Stack, dann sollte die Upstream-Konfiguration sowohl IPv4- als auch IPv6-Einträge für jeden Dual-Stack-Endpunkt haben. Wie vorgesehen behandelt der NGINX-Load-Balancer den IPv4-Eintrag und den IPv6-Eintrag für einen Endpunkt als separate Server . (Siehe die Zeile im oben erwähnten Dokument "Wenn ein Domänenname in mehrere IP-Adressen aufgelöst wird, werden die Adressen in der Upstream-Konfiguration gespeichert und mit Lastausgleich versehen.") Dies kann als gute oder schlechte Nachricht angesehen werden. Die gute Nachricht ist, dass der Lastausgleich über IPv4- und IPv6-Endpunkte erfolgt (was Ihnen eine gewisse Redundanz gibt), wo zB eine eingehende IPv4-Anfrage entweder einem IPv4- oder einem IPv6-Endpunkt zugeordnet werden könnte. Die potenziell schlechte Nachricht ist jedoch die Granularität des Lastausgleichs: Eine Verbindung zu einem IPv4-Endpunkt und eine Verbindung zum entsprechenden IPv6-Endpunkt werden (aus Gründen des Lastausgleichs) als 2 Lasten auf separate Endpunkte und nicht als 2 separate Lasten auf denselben Endpunkt behandelt . Wenn diese Granularität des Lastenausgleichs ein Problem darstellt, könnte jemand den Lastenausgleich auf IPv6 (oder auf IPv4, wenn es einen Konfigurationsknopf dafür gibt?) deaktivieren, sodass der Lastenausgleich nur auf IPv4-Endpunkte erfolgt. ODER , möglicherweise kann der NGINX-Load-Balancer so geändert werden, dass eine Verbindung zu einer IPv4-Adresse und eine Verbindung zu ihrer entsprechenden IPv6-Adresse als zwei Lasten zum selben Endpunkt behandelt werden.

Über Mithilfe und Engagement wäre ich sehr dankbar! Wir sind dabei, ernsthaft an Dual-Stack zu arbeiten (es wurde ein wenig verzögert durch die Arbeit, CI nur für IPv6 zum Laufen zu bringen). Ich hoffe, bald eine Gliederung für eine Spezifikation (Google Doc oder KEPs WIP doc) veröffentlichen zu können, und suche nach Hilfe bei der Überprüfung und vielleicht beim Schreiben einiger Abschnitte. Außerdem benötigen wir DEFINITIV Hilfe bei der offiziellen Dokumentation (über die Designspezifikation hinaus) und bei der Definition und Implementierung von Dual-Stack-E2E-Tests. Einige der Bereiche, in denen ich für das Design noch etwas skizzenhaft bin, sind:

• Wie sind Gesundheits-/Lebens-/Bereitschaftssonden betroffen oder werden mit Dual-Stack . gehandhabt?
• Wird es Auswirkungen auf die Netzwerkrichtlinien geben?
• Bedenken beim Load-Balancer?
• Bedenken bezüglich Cloud-Provider-Plugin?
• Bedenken bezüglich des L3/L4-Eingangs?
  Wenn Sie darüber nachgedacht haben, könnten Sie vielleicht bei diesen Abschnitten helfen?

Wir erwägen auch einen intermediären "Dual-Stack at the Edge"-Ansatz (mit IPv6 nur innerhalb des Clusters), bei dem der Zugriff von außerhalb des Clusters auf K8s-Dienste Dual-Stack wäre, dies jedoch abgebildet würde (z. B. über NGINX .). Ingress-Controller) zu reinen IPv6-Endpunkten innerhalb des Clusters (oder verwenden Sie zustandsloses NAT46). Pods und Dienste im Cluster müssten alle IPv6 sein, aber der große Vorteil wäre, dass der externe Dual-Stack-Zugriff im Hinblick auf die Time-to-Market viel schneller verfügbar wäre.

/Meilenstein 1,12

@leblancd / @caseydavenport - Ich
Sollte dies vom 1.11-Meilenstein abgezogen werden?

@justaugustus - Ja, dies sollte auf 1.12 verschoben werden. Muss ich eine Zeile in der Release-Tabelle löschen oder muss ich etwas tun, um dies zu ändern?

@leblancd Ich habe es abgedeckt. Danke fürs Nachverfolgen! :)

@leblancd @kubernetes/sig-network-feature-requests --

Diese Funktion wurde aus dem vorherigen Meilenstein entfernt, daher würden wir gerne prüfen, ob dies in Kubernetes 1.12 geplant ist.

Wenn dies der Fall ist, stellen Sie bitte sicher, dass dieses Problem mit ALLEN der folgenden Informationen aktuell ist:

• Einzeilige Funktionsbeschreibung (kann als Versionshinweis verwendet werden):
• Hauptansprechpartner (Beauftragter):
• Verantwortliche SIGs:
• Link zum Designvorschlag (Community-Repository):
• Link zu e2e- und/oder Unit-Tests:
• Reviewer(s) – (für LGTM) empfehlen, dass 2+ Reviewer (mindestens einer aus der Datei OWNERS des Codebereichs) der Überprüfung zustimmen. Rezensenten von mehreren Unternehmen bevorzugt:
• Genehmiger (wahrscheinlich von SIG/Gebiet, zu dem das Feature gehört):
• Funktionsziel (welches Ziel entspricht welchem ​​Meilenstein):
  
  
  
  • Alpha-Release-Ziel (xy)
  
  
  • Beta-Release-Ziel (xy)
  
  
  • Stabiles Freigabeziel (xy)
  
  

Stellen Sie Folgendes ein:

• Beschreibung
• Bevollmächtigte(n)
• Etiketten:
  
  
  
  • Stufe/{Alpha, Beta, stabil}
  
  
  • sig/*
  
  
  • Art/Eigenschaft
  
  

Bitte beachten Sie, dass die Funktionssperre am 31. Juli endet. Danach erfordern unvollständige Funktionsprobleme eine Ausnahmeanfrage , um in den Meilenstein aufgenommen zu werden.

Bitte beachten Sie außerdem die folgenden relevanten Fristen:

• Docs-Deadline (offene Platzhalter-PRs): 21.8
• Testfall einfrieren: 8/28

Bitte stellen Sie sicher, dass alle PRs für Funktionen auch relevante Versionshinweise enthalten.

Glücklicher Versand!

/cc @justaugustus @kacole2 @robertsandoval @rajendar38

@leblancd --
Feature Freeze ist heute. Planen Sie, dies in Kubernetes 1.12 auf die Beta zu übertragen?
Wenn ja, können Sie sicherstellen, dass alles auf dem neuesten Stand ist, damit ich es in die Tabelle 1.12 Feature-Tracking aufnehmen kann?

Hallo @justaugustus - Beta-Status muss in Kubernetes 1.13 schlüpfen. Wir machen (wenn auch langsam) Fortschritte beim Design KEP (https://github.com/kubernetes/community/pull/2254), und wir sind kurz davor, uns wieder mit der CI-Test-PR zu befassen, aber die Kubernetes 1.12 Ziel war ein bisschen zu optimistisch.

Ich werde die obige Beschreibung/Zusammenfassung mit den von Ihnen zuvor angeforderten Informationen aktualisieren. Vielen Dank für Ihre Geduld.

/Entferne-Stufen-Alpha
/Bühne Beta

Keine Sorge, @leblancd. Danke für das Update!

Hallo, @justaugustus @leblancd

Ich habe gerade das Update gelesen, dass die Beta für Dual Stack auf 1.13 verschoben wird. Was ist das voraussichtliche Erscheinungsdatum von 1.13? Wir suchen eigentlich nach Dual-Stack-Unterstützung. Es ist eine Go-Nogo-Entscheidung, dass unser Produkt in Container verlagert wird.

@navjotsingh83 - Ich glaube nicht, dass das Veröffentlichungsdatum für Kubernetes 1.13 Dokumentation zu den

@navjotsingh83 @leblancd 1.13 Release-Zeitplan wurde veröffentlicht . Es ist ein kurzer Release-Zyklus mit Code Freeze am 15. November. Glaubst du, es ist genug Zeit, um diese Funktion in die Beta zu überführen. Können Sie dieses Problem bitte mit Ihrem Vertrauen aktualisieren, was in Bezug auf Code, Tests und Dokumentationen noch aussteht?

Laut Diskussion beim SIG-Netzwerktreffen wird an dieser Funktion in 1.13 zwar noch viel Arbeit geleistet, aber es wird nicht erwartet, dass sie in 1.13 in die Beta-Phase geht. Meilenstein entsprechend entfernen.

/Meilenstein klar

@kacole2 , um dies aus der

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/Entferne-Lebenszyklus veraltet

@leblancd Hallo - Ich bin der prüfe dieses Problem, um zu sehen, welche Arbeit (falls vorhanden) für die Version 1.14 geplant ist. Das Einfrieren der Erweiterungen ist am 29. Januar und ich möchte daran erinnern, dass alle Erweiterungen ein KEP haben müssen

@leblancd Wollte Ihren vorherigen Kommentar zum Erstellen einer Abgrenzung am Rand des Clusters für IPv4/IPv6 weiterverfolgen:

„Wir erwägen auch einen intermediären „Dual-Stack at the Edge“-Ansatz (mit IPv6 nur innerhalb des Clusters), bei dem der Zugriff von außerhalb des Clusters auf K8s-Dienste Dual-Stack wäre, dies jedoch abgebildet würde (z. B. über NGINX Ingress Controller) zu reinen IPv6-Endpunkten innerhalb des Clusters (oder verwenden Sie zustandsloses NAT46). Pods und Dienste im Cluster müssten alle IPv6 sein, aber der große Vorteil wäre, dass der externe Dual-Stack-Zugriff im Hinblick auf die Time-to-Market viel schneller verfügbar wäre.“

Dieser Anwendungsfall wäre gut für ein aktuelles Projekt, also wollte ich Ihre Meinung zum Zeitrahmen sehen und sehen, ob ich oder jemand in unserer Gruppe etwas dazu beitragen könnte, diesen Weg zu einer schnelleren Markteinführung zu erleichtern.

@KevinAtDesignworx Wenn der Edge-Dual-Stack, aber nur interner IPv6-Ansatz immer noch externe IPv4-Anfragen aus einem Container (dh curl -v 93.184.216.34 -H "Host: example.com" ) erreichen kann, halte ich dies wirklich für den besten Ansatz. Wenn Ihre Infrastruktur IPv6 verwenden kann, warum sollten Sie aus Kompatibilitätsgründen IPv4 außer am Rand verwenden. Wenn dieser Ansatz jedoch dazu führt, dass ich ältere Websites nicht ausschließlich mit IPv4 aus meinem Cluster heraus erreichen kann, bin ich mir nicht mehr so ​​sicher.

Nun, es gibt 464XLAT, also wäre IPv6 nur innerhalb des Containers machbar.

@KevinAtDesignworx - Wenn die Verwendung eines Ingress-Controllers in Ihrem Szenario funktionieren würde, ist es möglich, einen NGINX-Ingress-Controller für den Dual-Stack-Betrieb von außen zu konfigurieren (Proxy für Single Family innerhalb des Clusters): https://github.com/leblancd/ kube-v6#installing -a-dual-stack-ingress-controller-on-an-ipv6-only-kubernetes-cluster

Die Ingress-Controller müssten auf jedem Knoten im Host-Netzwerk ausgeführt werden, daher müssten die Controller als Daemonset eingerichtet werden (ein Ingress-Controller auf jedem Knoten). Dies setzt voraus:

• Ihre Knoten sind Dual-Stack (im Gegensatz zu Pods und Diensten, die Einfamilienhäuser sind)
• Ihre /etc/hosts auf jedem Knoten hat IPv6-Einträge und nur IPv6-Einträge (keine IPv4-Adressen) für den Hostnamen dieses Knotens.

Dies wäre zusätzlich zu einem NAT64/DNS64 für Verbindungen von V6-Clients innerhalb des Clusters zu externen IPv4-Servern.

Stateless NAT46 ist auch eine Option, aber das habe ich nicht ausprobiert, daher habe ich keine Konfigurationsanleitungen dafür.

@leblancd irgendwelche Arbeiten hier für 1.15 geplant? Es sieht so aus, als ob ein KEP zu diesem Zeitpunkt auch noch nicht akzeptiert wurde. Vielen Dank!

@leblancd Wollte Ihren vorherigen Kommentar zum Erstellen einer Abgrenzung am Rand des Clusters für IPv4/IPv6 weiterverfolgen:

„Wir erwägen auch einen intermediären „Dual-Stack at the Edge“-Ansatz (mit IPv6 nur innerhalb des Clusters), bei dem der Zugriff von außerhalb des Clusters auf K8s-Dienste Dual-Stack wäre, dies jedoch abgebildet würde (z. B. über NGINX Ingress Controller) zu reinen IPv6-Endpunkten innerhalb des Clusters (oder verwenden Sie zustandsloses NAT46). Pods und Dienste im Cluster müssten alle IPv6 sein, aber der große Vorteil wäre, dass der externe Dual-Stack-Zugriff im Hinblick auf die Time-to-Market viel schneller verfügbar wäre.“

Dieser Anwendungsfall wäre gut für ein aktuelles Projekt, also wollte ich Ihre Meinung zum Zeitrahmen sehen und sehen, ob ich oder jemand in unserer Gruppe etwas dazu beitragen könnte, diesen Weg zu einer schnelleren Markteinführung zu erleichtern.

Von innerhalb eines Containers (der nur IPv6 ist), der eine curl-Anfrage (dh curl -v 93.184.216.34 -H "Host: example.com") an die Außenseite des Clusters sendet. Ich denke, es wird ein Fehler mit unbekanntem Ziel oder unerreichbarem Ziel ausgegeben, es sei denn, es gibt eine IPv4-Route auf dem Host, auf dem der Container vorhanden ist.

@GeorgeGuo2018 Wenn k8s DNS64/NAT64 implementieren würde, würde es funktionieren. es hängt stark davon ab, wie weit k8s in 464xlat/plat-Lösungen gehen wird und was bei Edge-Routern usw.

Tatsächlich denke ich, dass es möglich wäre, ein DaemonSet/Deployment zu verwenden, das Host-Networking und Tayga innerhalb des Kube-System-Namespace verwendet, sodass der interne DNS64 Tayga verwenden würde, um außerhalb des Netzwerks zu gehen.

Klingt für mich nach einer Lösung.

Wir betreiben intern ein IPv6-only-Netzwerk und NAT64/DNS64 funktioniert bei uns recht gut. Bei einigen älteren Sachen, bei denen es überhaupt keine IPv6-Unterstützung gab, haben wir cladd direkt dort eingesetzt, wo es gebraucht wurde. (In unserem Fall direkt auf einer VM.)

@kacole2 - Ich möchte, dass dies für 1.15 verfolgt wird. Ich arbeite daran, die folgende PR zusammenzuführen - https://github.com/kubernetes/enhancements/pull/808

Speziell für 1.15 würden wir Unterstützung für Folgendes hinzufügen:

• Änderungen des API-Typs
  
  
  
  • Kubernetes-Typen
  
  
  • CRI-Typen
  
  
• Dual-Stack-Pod-Netzwerk (Multi-IP-Pod)
• kubenet-Mehrfamilienunterstützung

cc @caseydavenport für Meilensteinverfolgung ^

@kacole2 der KEP ist jetzt zusammengeführt. Lassen Sie es mich wissen, wenn wir noch etwas brauchen, um dies in 1.15 zu verfolgen

Hey @leblancd @lachie83 Nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.15), die bis Donnerstag, den 30. Mai, fällig ist. Es wäre großartig, wenn es der Beginn der vollständigen Dokumentation wäre, aber sogar ein Platzhalter PR ist akzeptabel. Lassen Sie es mich wissen, wenn Sie Fragen haben!

@kacole2 der KEP ist jetzt zusammengeführt. Lassen Sie es mich wissen, wenn wir noch etwas brauchen, um dies in 1.15 zu verfolgen

@lachie83 Hallo Lachie,

@kacole2 der KEP ist jetzt zusammengeführt. Lassen Sie es mich wissen, wenn wir noch etwas brauchen, um dies in 1.15 zu verfolgen

Eigentlich möchte ich herausfinden, ob in k8s 1.15 sicherlich Dual-Stack-Unterstützung hinzugefügt wird.

@leblancd Der Platzhalter-PR gegen k8s.io dev-1.15 ist am Donnerstag, den 30. Mai, fällig.

@leblancd Der Platzhalter-PR gegen k8s.io dev-1.15 ist am Donnerstag, den 30. Mai, fällig.

Könnte ich davon ausgehen, dass Dual-Stack-Unterstützung in Version 1.15 verfügbar sein wird?

@GeorgeGuo2018 Es ist immer noch auf dem Verbesserungsblatt für 1.15, aber nur der Verbesserungsleiter @kacole2 kann Ihnen bessere Details dazu liefern.

Hallo @lachie83 @leblancd. Code Freeze ist Donnerstag, der 30. Mai 2019 @ EOD PST . Alle Erweiterungen, die in die Veröffentlichung eingehen, müssen vollständig im Code enthalten sein, einschließlich Tests , und die Dokumentations-PRs müssen geöffnet sein.

Bitte listen Sie alle aktuellen k/k PRs auf, damit sie bis zum Einfrieren nachverfolgt werden können. Wenn die PRs nicht durch Freeze zusammengeführt werden, wird diese Funktion für den Release-Zyklus 1.15 verschoben. Im Meilenstein sind nur Release-Blockierungsprobleme und PRs zulässig.

Ich sehe kubernetes/kubernetes#62822 im ursprünglichen Beitrag ist noch offen. Gibt es andere PRs, von denen wir erwarten, dass sie ebenfalls zusammengeführt werden?

Wenn Sie wissen, dass dies verrutscht, antworten Sie bitte zurück und teilen Sie uns dies mit. Vielen Dank!

@simplytunde -

@GeorgeGuo2018 - Dies wird ein KEP mit mehreren Veröffentlichungen sein. Wir planen die Landephase 1 in 1.15. Bitte werfen Sie einen Blick auf den Implementierungsplan im KEP für weitere Details - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6-dual-stack.md#implementation -planen.

@simplytunde - Ich habe den ersten Platzhalter-Dokumenten-PR hier mit einem WIP erstellt https://github.com/kubernetes/website/pull/14600. Ich habe vor, es in den nächsten Tagen fertigzustellen und zur Überprüfung bereit zu stellen.

@kacole2 Danke für den Ping. Ich habe die 1.15-Erweiterungstabelle mit der k/k-PR aktualisiert, die wir verfolgen (https://github.com/kubernetes/kubernetes/pull/73977) zusammen mit dem Entwurf der Dokumentations-PR (https://github.com/ kubernetes/website/pull/14600). Wir sind derzeit noch auf dem besten Weg, diese PR vor dem Einfrieren des Codes zusammenzuführen. LMK falls ich noch was vermisse

@kacole2 nach Diskussion mit @claurence und dem Release-Team haben wir uns entschieden, dies aus dem 1.15-Meilenstein zu entfernen. Bitte entfernen Sie sie und aktualisieren Sie die Tabelle entsprechend. Vielen Dank für Ihre bisherige Hilfe.

/Meilenstein klar

@simplytunde Ich habe auch die Docs-PR kommentiert. Können Sie bitte sicherstellen, dass dies auch aus dem 1.15-Meilenstein entfernt wird?

Hallo @lachie83 @leblancd , ich bin der 1.16 Enhancement Shadow. Wird diese Funktion in 1.16 die Alpha-/Beta-/Stable-Phasen abschließen? Bitte lassen Sie es mich wissen, damit es der 1.16 Tracking-Tabelle hinzugefügt werden kann.

Meilensteintermine sind Enhancement Freeze 30.07. und Code Freeze 29.08.

Dankeschön.

https://github.com/kubernetes/dns/issues/315 behandelt das Hinzufügen von IPv6 / AAAA zur DNS-Service-Discovery-Spezifikation .

@lachie83 @leblancd eine Idee, ob dies in 1.16 abgeschlossen wird, um es zu verfolgen?

@evilgenius75 @kacole2 Dies muss in 1.16 verfolgt werden. Diese Funktion befindet sich im Alpha-Status. Wir werden Phase 1 implementieren und Phase 2 wie im KEP definiert ist 1,16

Tracking-KEP

• https://github.com/kubernetes/enhancements/pull/808

Zusammengeführte k/k PRs (derzeit im Master wird in 1.16) sein

• [MERGED] Phase 1 - https://github.com/kubernetes/kubernetes/pull/73977
• [MERGED] Phase 1 e2e-Tests – https://github.com/kubernetes/kubernetes/pull/78801
• [MERGED] Phase 1 e2e-Testbereinigung - https://github.com/kubernetes/kubernetes/pull/80001
• Phase-2-Dienste/Endpunkte – https://github.com/kubernetes/kubernetes/pull/79386
• Phase 2 Kube-Proxy - https://github.com/kubernetes/kubernetes/pull/79576

Zugehörige PRs

• Unterstützung für IPv6 https://github.com/kubernetes-incubator/ip-masq-agent/pull/45
• Phase 1-Dokumente – werden wieder geöffnet, sobald wir die Werkzeugbeispiele fertiggestellt haben – https://github.com/kubernetes/website/pull/14600
• [MERGED] clean up - node dropDisabledFields - https://github.com/kubernetes/kubernetes/pull/79741
• Unterstützt mehrere Maskengrößen für Cluster-Cidrs - https://github.com/kubernetes/kubernetes/pull/79993
• E2e Prow Job für Dualstack https://github.com/kubernetes/test-infra/pull/12966

Hey, @leblancd Ich bin der Versionsleiter von v1.16 docs.

Erfordert diese Verbesserung (oder die für v1.16) geplante Arbeit neue Dokumente (oder Änderungen)?

Nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.16), die bis Freitag, den 23. August fällig ist. Es wäre toll, wenn es der Anfang der vollständigen Dokumentation wäre, aber selbst ein Platzhalter-PR ist akzeptabel. Lassen Sie es mich wissen, wenn Sie Fragen haben!

@simplytunde hier ist die Docs PR - https://github.com/kubernetes/website/pull/16010

@lachie83 Einfrieren des freundlichen Erinnerungscodes für 1.16 ist am Donnerstag, den 29.08. (als ob du das nicht wüsstest). Sieht so aus, als ob diese PRs noch ausstehen:
Phase-2-Dienste/Endpunkte – kubernetes/kubernetes#79386
Phase 2 kube-proxy - kubernetes/kubernetes#79576

Damit verbundenen:
Unterstützt mehrere Maskengrößen für Cluster-Cidrs - kubernetes/kubernetes#79993
E2e Prow Job für Dualstack kubernetes/test-infra#12966

Hallo @lachie83 @leblancd, es sieht so aus, als ob https://github.com/kubernetes/kubernetes/pull/79576 und https://github.com/kubernetes/kubernetes/pull/79993 nicht zusammengeführt wurden, bevor der Code einfriert und es nicht ist im Tide Merge Pool . Diese Funktion wird ab v1.16 erweitert. Wenn Sie dies dennoch in der Version 1.16 haben möchten, reichen Sie bitte eine Ausnahme ein

@kacole2 Entschuldigung für die Verzögerungen bei der Antwort. Die primäre PR, die verfolgt wurde, war https://github.com/kubernetes/kubernetes/pull/79386. Was kubernetes/kubernetes#79576 betrifft, haben wir beschlossen, dies auf 1.17 zu verschieben und uns stattdessen auf https://github.com/kubernetes/kubernetes/pull/82091 (in Übereinstimmung mit sig-network) zu konzentrieren, das die gleichen Phase2-Ziele erfüllt wie wurden im KEP angelegt. Die andere verwandte PR, die in dieser Pressemitteilung verfolgt wurde, war https://github.com/kubernetes/kubernetes/pull/80485, die ebenfalls zusammengeführt wurde. kubernetes/kubernetes#79993 wurde ebenfalls auf 1.17 verschoben

Hallo @lachie83 @leblancd -- 1.17 Verbesserungen führen hierher. Ich wollte einchecken und sehen, ob diese Verbesserung Ihrer Meinung nach in 1.17 zu Alpha/Beta/Stable wird?

Der aktuelle Veröffentlichungsplan ist:

• Montag, 23. September - Der Release-Zyklus beginnt
• Dienstag, 15. Oktober, EOD PST – Verbesserungen einfrieren
• Donnerstag, 14. November EOD PST - Code Freeze
• Dienstag, 19. November – Dokumente müssen ausgefüllt und überprüft werden
• Montag, 9. Dezember – Kubernetes 1.17.0 veröffentlicht

Wenn Sie dies tun, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können. 👍

Vielen Dank!

/Meilenstein klar

Hallo Bob. Danke, dass Sie sich gemeldet haben. Ich plane noch Phase 3 dieser Erweiterung, die die Erweiterung bis zum Abschluss abrunden wird. Diese Verbesserung wird am Ende dieser Version noch in der Alpha-Phase sein, aber es wird Phase 3-bezogene Arbeiten geben, die als Teil von 1.17 in k/k landen werden.

Hier ist eine Liste von High-Level-Ergebnissen für 1.17 für Dual-Stack. Ich werde diese Liste während der Veröffentlichung aktualisieren.

• IPtables-Dual-Stack-Proxy – https://github.com/kubernetes/kubernetes/pull/79576
• Abwärts-API-Unterstützung für Pod.Status.PodIPs - https://github.com/kubernetes/kubernetes/pull/83123
• e2e testet ein CNI-Plugin
• Änderungen an der Hostdatei (IPv6-Adresse für den Hostnamen muss hinzugefügt werden /etc/hosts) - https://github.com/kubernetes/kubernetes/pull/83123
• Art Dual-Stack - https://github.com/kubernetes-sigs/kind/pull/692
• e2e-Suite aktualisieren – https://github.com/kubernetes/kubernetes/pull/80725
• Unterstützung von Endpunkt-Slices
• Dual-Stack-Unterstützung für Kubeadm – https://github.com/kubernetes/kubeadm/issues/1612

Sehr geschätzt, vielen Dank

/Meilenstein v1.17

@mrbobbytables Ich habe auch eine PR hinzugefügt, um die oben aufgeführten Arbeiten im Rahmen von Phase 3 im KEP detailliert darzustellen, nachdem der Plan über das sig-Netzwerk kommuniziert wurde. Das KEP selbst befindet sich noch immer im Zustand implementable und diese Änderungen dokumentieren lediglich die geplanten Arbeiten als Teil von 1.17.

Irgendwann möchte ich sicherstellen, dass https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/ IPv6-DNS abdeckt. https://github.com/kubernetes/website/issues/15434 verfolgt diese Änderung; Erwähnen Sie es hier, um einen Querverweis zu beachten.

KEP aktualisiert, um e2e-Tests der Phase 2 hinzuzufügen - https://github.com/kubernetes/enhancements/pull/1311

Hallo @lachie83 Ich bin einer der v1.17 Docs Shadows.
Erfordert diese Verbesserung für (oder die für v1.17 geplanten Arbeiten) neue Dokumente (oder Änderungen an bestehenden Dokumenten)? Wenn nicht, können Sie bitte das 1.17 Enhancement Tracker Sheet aktualisieren (oder lassen Sie es mich wissen und ich werde dies tun)

Wenn ja, nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.17), die bis Freitag, den 8. November fällig ist, es kann zu diesem Zeitpunkt nur eine Platzhalter-PR sein. Lassen Sie es mich wissen, wenn Sie Fragen haben!

@lachie83

Da wir uns am 8. November der PR-Frist für Docs-Platzhalter nähern. Bitte versuchen Sie, einen gegen den Zweig k/website dev-1.17 zu bekommen.

Hey, @lachie83 , ich weiß, dass du den Überblick behältst, aber ich muss trotzdem vorbeischauen und es erwähnen 🙈
Code-Freeze steht vor der Tür (14. November). Wie sieht es aus? Ist alles auf dem richtigen Weg, bis dahin zusammengeführt zu werden?

Vielen Dank!

Hey @mrbobbytables! Danke für den Ping. Wir verfolgen die folgenden PRs, um in 1.17 zu landen. Es kann auch ein oder zwei weitere PRs geben, die mit dieser Änderung verbunden sind. Für diese Änderungen sind Dokumente erforderlich. Ich werde einen Platzhalter für Dokumente erstellen PR

• Dualstack-Unterstützung für den Kube-Proxy-IPtables-Modus pr/82462
• Dualstack abwärts gerichtete API pr/82462
• IPvs-Metaproxier-Endpunktslice-Unterstützung hinzufügen pr/84089
• Erlaube mehrere Knoten-Cidr-Masken in kube-controller-manager pr/79993

@irvifa - Hier ist die Platzhalter-Dokumentation PR. https://github.com/kubernetes/website/pull/17457

Cool danke 🎉 @lachie83

@lachie83 morgen ist der Code-Freeze für den Release-Zyklus 1.17. Es sieht so aus, als ob die k/k-PRs noch nicht zusammengeführt wurden. 😬 Wir kennzeichnen dies im Verbesserungs-Tracking-Sheet 1.17 als Gefährdet.
Glaubst du, dass sie bis zum EoD vom 14. (Donnerstag) zusammengeführt werden? Ab diesem Zeitpunkt sind im Meilenstein nur noch Probleme mit Release-Blockierung und PRs zulässig, mit einer Ausnahme.

Danke Bob - ich werde das heute mit sig-network besprechen und ein Update bereitstellen.

Hallo @mrbobbytables. Hier ist eine Liste von PRs, an deren Zusammenführung wir heute von EoD arbeiten und die von sig-network genehmigt wurden.

• https://github.com/kubernetes/kubernetes/pull/85246
• https://github.com/kubernetes/kubernetes/pull/83123
• https://github.com/kubernetes/kubernetes/pull/79993

Der verbleibende PR wird höchstwahrscheinlich auf 1,18 gesetzt - https://github.com/kubernetes/kubernetes/pull/82462

@mrbobbytables bestätigt nur, dass alle oben genannten PRs zusammengeführt wurden und wir tatsächlich kubernetes/kubernetes#82462 auf 1.18 setzen werden. Diese Verbesserung kann immer noch verfolgt werden, da diese PRs bedeutende Änderungen am Dualstack-Verhalten in 1.17 hinzufügen. Jetzt muss ich nur noch die Docs PR fertig machen! Wir hoffen, kubernetes/kubernetes#82462 in 1.18 zu landen und diese Arbeit in die Beta-Phase zu bringen

Super, danke @lachie83!

Und es ist live! https://kubernetes.io/blog/2019/12/09/kubernetes-1-17-release-announcement/

Wir planen, diese Erweiterung in die Betaversion 1.18 zu verschieben. Kriterien und Testpläne für die Verbesserung des Abschlusses finden Sie im KEP zusammen mit dieser PR - https://github.com/kubernetes/enhancements/pull/1429

/Meilenstein 1.18

@lachie83 : Der angegebene Meilenstein ist für dieses Repository nicht gültig. Meilensteine ​​in diesem Repository: [ keps-beta , keps-ga , v1.17 , v1.18 , v1.19 , v1.20 , v1.21 ]

Verwenden Sie /milestone clear , um den Meilenstein zu löschen.

/Meilenstein v1.18

Wir planen, diese Erweiterung in die Betaversion 1.18 zu verschieben. Kriterien und Testpläne für die Verbesserung des Abschlusses finden Sie im KEP zusammen mit dieser PR - #1429

Danke für das Update @lachie83 , ich habe dies in der Tabelle 1.18 als nachverfolgt markiert!

Bitte verfolgen Sie die folgende PR als Teil der Arbeit, um in 1.18 zu landen. https://github.com/kubernetes/kubernetes/pull/82462

Hinzufügen anderer verwandter PRs zum Tracking:
https://github.com/kubernetes/test-infra/pull/15893
https://github.com/kubernetes-sigs/kind/pull/692

Danke @lachie83!

Hallo @lachie83 , hast du andere PR's, die wir verfolgen sollten, außer den oben genannten?

Hallo, @lachie83 @leblancd - Ich bin ein Docs-Schatten im 1.18-Release-Team.

Sind für diese für 1.18 geplanten Erweiterungsarbeiten neue Dokumente oder Änderungen an bestehenden Dokumenten erforderlich?

Wenn nicht, können Sie bitte das 1.18 Enhancement Tracker Sheet aktualisieren (oder lassen Sie es mich wissen und ich werde dies tun)

Wenn Aktualisierungen der Dokumentation erforderlich sind, erinnern Sie sich daran, dass die Platzhalter-PRs für k/website (Zweig dev-1.18) bis Freitag, 28. Februar, fällig sind.

Lassen Sie es mich wissen, wenn Sie Fragen haben!

Wenn jemand Hilfe bei der Dokumentation von IPv6- oder Dual-Stack-Zeug für v1.18 braucht, gib mir einen Schubs. Ich kann vielleicht helfen.

Hey @lachie83 ,

Sieht so aus, als ob kubernetes-sigs/kind#692 noch nicht zusammengeführt wurde. Ist das entscheidend für Ihren Beta-Abschluss?

Hey @jeremyrickard @sethmccombs, wir müssen dies angesichts dieser PR https://github.com/kubernetes/kubernetes/pull/86895 vom Abschluss in die Betaphase verschieben

/Meilenstein klar

@lachie83 Vielen Dank für das Update. Ich habe diese Verbesserung aus dem Meilenstein entfernt. Ich freue mich darauf am 1.19. :)

Ich möchte bestätigen, dass der Status der Dualstack-Erweiterung in 1.18 in alpha bleibt. Ich arbeite derzeit mit der Community zusammen, um die Arbeiten zu bewerten, die in 1.19 abgeschlossen sein sollen. Es ist wahrscheinlich, dass diese Verbesserung in 1.19 noch im Alpha-Zustand bleiben wird, aber ich möchte es bestätigen. Ich werde auch Maßnahmen ergreifen, um die Dokumente zu aktualisieren, um den Verbesserungsstatus in den Dokumenten 1.18 widerzuspiegeln.

Wenn es Seiten auf der Website gibt, die Dual-Stack-Kubernetes als Beta anzeigen, melden Sie diese bitte gegen k/website als Priorität/in Kürze wichtige Fehler.

Hallo @lachie83 -- 1.19 Erweiterungen Führen Sie hier durch, ich wollte einchecken, ob Sie denken, dass diese Erweiterung in 1.19 abgeschlossen werden würde?

Der aktuelle Veröffentlichungsplan ist:

• Montag, 13. April: Woche 1 - Release-Zyklus beginnt
• Dienstag, 19. Mai: Woche 6 – Einfrieren der Verbesserungen
• Donnerstag, 25. Juni: Woche 11 - Code Freeze
• Donnerstag, 9. Juli: Woche 14 – Dokumente müssen ausgefüllt und überprüft werden
• Dienstag, 4. August: Woche 17 - Kubernetes v1.19.0 veröffentlicht

Wenn es Seiten auf der Website gibt, die Dual-Stack-Kubernetes als Beta anzeigen, melden Sie diese bitte gegen k/website als Priorität/in Kürze wichtige Fehler.

@sftim Ich habe zwei PRs erhoben, um die Release-Kennzeichnung in 1.17 und 1.18 anzugehen

@palnabarun Wir arbeiten daran, den Dualstack-KEP im Release-Zeitrahmen von 1.19 zu aktualisieren, glauben jedoch derzeit nicht, dass wir Codeänderungen in der Version 1.19 vornehmen werden. Wir haben ein Blockierungsproblem mit der bereits erledigten Arbeit (dank der Tatsache, dass sie sich im Zustand alpha ). Das Blockierungsproblem ist https://github.com/kubernetes/kubernetes/pull/86895. Wir planen, dies über das folgende KEP-Update https://github.com/kubernetes/enhancements/pull/1679 anzugehen, aber es wird einige Zeit dauern, um einen Konsens über die vorgeschlagene Änderung zu erzielen. In dieser Phase bleibt die Dualstack-Erweiterung im Zustand alpha bis wir dieses Blockierungsproblem mit der aktuellen Implementierung beheben. Ich werde Updates bereitstellen, wenn die Dinge voranschreiten.

Danke, Lachie, für die Updates. Ich schätze alle Bemühungen! :leicht_smiling_face:

Die Probleme veralten nach 90 Tagen Inaktivität.
Markieren Sie das Problem mit /remove-lifecycle stale .
Veraltete Ausgaben verrotten nach weiteren 30 Tagen Inaktivität und werden schließlich geschlossen.

Wenn dieses Problem jetzt sicher geschlossen werden kann, tun Sie dies bitte mit /close .

Senden Sie Feedback an sig-testing, kubernetes/test-infra und/oder fejta .
/Lebenszyklus veraltet

/Entferne-Lebenszyklus veraltet

Wir möchten, dass diese Verbesserung in 1.20 verfolgt wird. Es wird gemäß dem aktualisierten kep im Alpha-Zustand neu implementiert - https://github.com/kubernetes/enhancements/pull/1679. Bitte verfolgen Sie die folgende PR für die Implementierung - https://github.com/kubernetes/kubernetes/pull/91824. Wir planen, die Überprüfung abzuschließen und die PR zu Beginn des Veröffentlichungszyklus von 1.20 zusammenzuführen.

Neueste Dual-Stack-Promotion zum Beta-Status, wie sie beim SIG Network-Meeting am 17. September diskutiert wurde, für diejenigen, die zu Hause mitspielen:

• Muss die Mehrdeutigkeit der Kubelet-Dual-Stack-Systemdiagnose auflösen; über https://github.com/kubernetes/enhancements/pull/1975
• Muss die bestehende Dual-Stack-Dienste-PR (in aktiver Überprüfung) beenden und zusammenführen; über https://github.com/kubernetes/kubernetes/pull/91824
• Muss das Verhalten von Dual-Stack-Knoten-IPs abschließen; über https://github.com/kubernetes/enhancements/pull/1665
• Sollte bestimmen, welche (falls vorhanden) Änderungen für das Feld Spec.LoadBalancerIPs des Dienstes erforderlich sind

An all diesen Elementen wird aktiv gearbeitet, und 1.20 ist immer noch das Ziel für die Dual-Stack-API-Beta-Abstufung. Trotz aller Bemühungen besteht jedoch immer die Möglichkeit, dass etwas nicht rechtzeitig gelöst wird, und wenn ja, wird SIG Network in unseren öffentlichen Sitzungen entscheiden, ob die Beta-Phase fortgesetzt wird oder nicht. Alle sind herzlich eingeladen mitzumachen.

@dcbw vielen Dank für das Update (sorry, dass ich den Anruf nicht tätigen konnte). Ist es sinnvoll, dies in 1.20 zur Beta zu verbessern oder einfach in der Alpha zu bleiben? Wenn wir in die Beta gehen möchten, sind die Abschlusskriterien im KEP immer noch sinnvoll, da es sich um eine Neuimplementierung handelt https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#graduation -kriterien

@dcbw vielen Dank für das Update (sorry, dass ich den Anruf nicht tätigen konnte). Ist es sinnvoll, dies in 1.20 zur Beta zu verbessern oder einfach in der Alpha zu bleiben? Wenn wir in die Beta gehen möchten, sind die Abschlusskriterien im KEP immer noch sinnvoll, da es sich um eine Neuimplementierung handelt https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#graduation -kriterien

Es ist jedoch nicht wirklich eine Neuimplementierung. Alle vorherigen Arbeiten sind weiterhin gültig und die Arbeiten in 1.20 bauen darauf auf, um die letzten erforderlichen Änderungen, die identifiziert wurden, abzuschließen. Meine Interpretation der Sign-Network-Diskussion ist, dass die von @dcbw veröffentlichte Liste die verbleibenden bekannten Probleme darstellt, die für den Abschluss gelöst werden müssen.

Hallo zusammen,

1.20 Erweiterungen Führen Sie hierher, ich werde dies als verfolgt festlegen, bitte aktualisieren Sie mich, wenn sich etwas ändert :)

Zur Erinnerung Enhancements Freeze ist der 6. Oktober.

Als Hinweis verwendet das KEP ein altes Format, das wir auf aktualisiert haben: https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

Am besten,
Kirsten

/Meilenstein v1.20

Hallo @russellb -

Es ist jedoch nicht wirklich eine Neuimplementierung. Alle vorherigen Arbeiten sind weiterhin gültig und die Arbeiten in 1.20 bauen darauf auf, um die letzten erforderlichen Änderungen, die identifiziert wurden, abzuschließen.

Angesichts der API-Änderungen in https://github.com/kubernetes/kubernetes/pull/91824 ist genug anders, dass die Kennzeichnung von Dual-Stack als Alpha für 1.20 Raum für weitere Neuimplementierungen lässt, die sich als notwendig erweisen. Ich weiß, wir sind alle gespannt auf die Beta, aber lassen Sie uns zuerst die PR mit +9,319 −3,261 landen und den Staub legen. :)

Angesichts der API-Änderungen in kubernetes/kubernetes#91824 ist genug anders, dass die Markierung von Dual-Stack als Alpha für 1.20 Raum für weitere Neuimplementierungen lässt, die sich als notwendig erweisen. Ich weiß, wir sind alle gespannt auf die Beta, aber lassen Sie uns zuerst die PR mit +9,319 −3,261 landen und den Staub legen. :)

@bridgetkromhout ja, wir müssen https://github.com/kubernetes/kubernetes/pull/91824 landen, bevor wir eine Entscheidung über die API-Bereitschaft treffen können. Ich hoffe wirklich, dass wir das so schnell wie möglich tun können.

Hallo zusammen,

1.20 Verbesserungsschatten hier 👋

Da diese Erweiterung für 1.20 geplant ist, denken Sie bitte an die folgenden wichtigen Termine:
Freitag, 6. November: Woche 8 - PR-Deadline für Docs-Platzhalter
Donnerstag, 12. November: Woche 9 - Code Freeze

Zur Erinnerung: Verlinken Sie bitte alle Ihre k/k PR sowie docs PR mit dieser Ausgabe, damit wir sie verfolgen können.

Dankeschön!

Hallo @kinarashah @kikisdeliveryservice - Ich habe beim Sign -Network-Aufruf bestätigt, dass wir dies für 1.20 in Alpha umklassifizieren müssen. Es handelt sich um eine komplette Neuimplementierung, die Zeit braucht, um in der Alpha-Phase eingeweicht und getestet zu werden.

Hallo @lachie83 , 1.20 Docs Shadow hier.

Sind für diese für 1.20 geplanten Erweiterungsarbeiten neue Dokumente oder Änderungen an bestehenden Dokumenten erforderlich?

Wenn dies der Fall ist, befolgen Sie bitte die hier beschriebenen Schritte, um eine PR für den dev-1.20 Zweig im k/website Repo zu eröffnen. Diese PR kann derzeit nur ein Platzhalter sein und muss vor dem 6. November erstellt werden .

Werfen Sie auch einen Blick auf Dokumentation für ein Release , um sich mit den Dokumentationsanforderungen für das Release vertraut zu machen.

Dankeschön!

Danke @reylejano-rxm - wir haben kubernetes/website#24725 geöffnet

Hallo @lachie83

Vielen Dank für die Erstellung der Docs-PR!

Bitte beachten Sie die wichtigen kommenden Termine:

• Freitag, 6. November: Woche 8 - Docs Placeholder PR-Deadline FERTIG!
• Donnerstag, 12. November: Woche 9 - Code Freeze
• Montag, 23. November: Woche 11 – Docs PR bereit zur Überprüfung

Zur Erinnerung: Verlinken Sie bitte alle Ihre k/k PR sowie docs PR mit dieser Ausgabe, damit das Release-Team sie verfolgen kann.

Hallo @kinarashah @kikisdeliveryservice - Ich habe beim Sign -Network-Aufruf bestätigt, dass wir dies für 1.20 in Alpha umklassifizieren müssen. Es handelt sich um eine komplette Neuimplementierung, die Zeit braucht, um in der Alpha-Phase eingeweicht und getestet zu werden.

Hey @lachie83

Angesichts des oben Gesagten gehe ich davon aus, dass dies immer noch für Alpha gedacht ist, wie es ist? Ich sehe keine ausstehenden PRs, die zusammengeführt werden müssen / Arbeit wurde bereits zusammengeführt.

_Nur zur Erinnerung, dass Code Freeze in 2 Tagen am Donnerstag, den 12. November erscheint . Alle PRs müssen bis zu diesem Datum zusammengeführt werden, andernfalls ist eine Ausnahme erforderlich._

Vielen Dank!
Kirsten

Hallo, @kikisdeliveryservice - ja, IPv4/IPv6-Dual-Stack-Unterstützung (reimplementiert) wird für 1.20 Alpha sein.

Hier sind die Fortschritte, die wir für diese Verbesserung haben:

1) Code wird von https://github.com/kubernetes/kubernetes/pull/91824 zusammengeführt - wird Alpha für 1.20 sein
2) Dokumentationsaktualisierungen zu dieser Codeänderung finden Sie in https://github.com/kubernetes/website/pull/24725/ - überprüft und in den Zweig dev-1.20 zusammengeführt

Wird für 1.20 noch etwas benötigt, das wir bei dieser Verbesserung noch nicht abgeschlossen haben?

@bridgetkromhout Danke für das klare Update, ihr seid alle gut!

Es sieht so aus, als ob LoadBalancerIP in ServiceSpec noch nicht Teil der Dual-Stack-Implementierung ist. Gibt es einen Plan, es zu unterstützen oder habe ich es verpasst?

Hallo @chenwng - Änderungen am Cloud-Provider-Code für Loadbalancer liegen derzeit außerhalb des Geltungsbereichs, wie im KEP hier definiert - https://github.com/kubernetes/enhancements/blob/master/keps/sig-network/20180612-ipv4-ipv6 -dual-stack.md#load -balancer-operation.

Sie können helfen, indem Sie Ihren Anwendungsfall und Änderungsvorschläge angeben, um zu verstehen und zu entscheiden, ob wir Änderungen an der KEP vornehmen müssen.

@chenwng Es wird an einem KEP für LoadBalancerIPs in Dual-Stack-Clustern gearbeitet - https://github.com/kubernetes/enhancements/pull/1992

Danke für die Info, @aramase , @lachie83 .