@enisoc @dchen1107 @fejta @tockin @kow3ns @derekwaynecarr , hat dieses Tracking-Problem geöffnet, damit wir es diskutieren können.

/zuordnen

@derekwaynecarr Ich habe einige Änderungen an den Kubelet-Änderungen vorgenommen, die für das Sign-Node-Meeting nächste Woche erforderlich sind. Ich _glaube_, dass Änderungen nur im Paket kuberuntime erforderlich sind, insbesondere kuberuntime_manager.go in und kuberuntime_container.go .

In kuberuntime_manager.go könnten Sie computePodActions modifizieren, um das Auslösen des Herunterfahrens zu implementieren (Sidecars beenden, wenn alle Nicht-Sidecars dauerhaft beendet wurden) und zuerst die Sidecars starten.

In kuberuntime_container.go konnte man killContainersWithSyncResult modifizieren, um die Sidecars zuletzt zu beenden und die preStop-Hooks zu senden (das preStop-Hooks-Bit war etwas umstritten, es wurde nicht entschieden, ob das gemacht werden sollte oder nicht. @ thockin hatte einen guten Grund, warum Sie dieses Verhalten möglicherweise nicht fördern möchten, siehe Kommentar ).

Lassen Sie es mich wissen, wenn ich weitere Nachforschungen anstellen soll.

@kow3ns Die Diskussion macht für mich mehr Sinn, wenn wir vielleicht eine vollständige Beschreibung der Containersequenz in der Pod-Spezifikation (sig-app) definieren können und wie die Sequenz in Kubelet für den Start, Neustart und die kaskadierende Betrachtung (Sig-Knoten) behandelt wird. Lassen Sie uns das Sign-Node-Meeting am 5. Februar verfolgen, um weitere Inputs zu geben.

cc @Joseph-Irving

Der Vorschlag besagt, dass Sidecars erst ausgeführt werden, nachdem die Init-Container ausgeführt wurden. Aber was ist, wenn der Anwendungsfall erfordert, dass der Sidecar ausgeführt wird, während/bevor die Init-Container ausgeführt werden. Wenn Sie beispielsweise den Datenverkehr des Pods über einen als Sidecar ausgeführten Proxy leiten möchten (wie in Istio), möchten Sie wahrscheinlich, dass dieser Proxy vorhanden ist, während die Init-Container ausgeführt werden, falls der Init-Container selbst Netzwerkaufrufe durchführt.

@luksa Ich denke, es besteht die Möglichkeit, Sidecars zu verwenden, die irgendwann in der Initphase ausgeführt werden, aber derzeit wird der Vorschlag diesen Anwendungsfall nicht abdecken. Es gibt derzeit keine Möglichkeit, gleichzeitige Container in der Init-Phase auszuführen, sodass dies möglicherweise eine viel größere/unordentlichere Änderung als die hier vorgeschlagene wäre.

Update zu diesem KEP:
Ich habe sowohl mit @derekwaynecarr als auch mit @dchen1107 von

Wir müssen uns noch über die API einigen, es scheint Einigkeit darüber zu bestehen, dass eine einfache Möglichkeit, Container als Sidecars zu markieren, gegenüber tiefergehenden Sortierflags bevorzugt wird. Einen bool zu haben ist jedoch etwas einschränkend, daher wäre vielleicht etwas mehr in der Art von containerLifecycle: Sidecar vorzuziehen, damit wir die Möglichkeit haben, in Zukunft zu erweitern.

@Joseph-Irving Tatsächlich sind weder der boolesche containerLifecycle: Sidecar noch der containerLifecycle ein Objekt sein, genau wie deployment.spec.strategy , mit type: Sidecar . Damit könnten wir dann zusätzliche Felder einführen. Für die Lösung "Beiwagen für die gesamte Lebensdauer des Pods" würde dies wie folgt ausgedrückt:

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

im Gegensatz zu

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

Bitte verzeihen Sie meine schlechte Namensgebung - ich hoffe, die Namen vermitteln die Idee.

Aber es gibt ein Problem mit dem Ansatz, bei dem wir containerLifecycle in pod.spec.containers einführen. Es ist nämlich falsch, Sidecars zu haben, die parallel zu init-Containern laufen, die unter pod.spec.containers . Wenn Sie dies also wirklich auf Init-Container erweitern möchten, sollten Sie eine alternative Lösung finden - eine, die es Ihnen ermöglicht, Container als Sidecars auf einer höheren Ebene zu markieren - dh nicht unter pod.spec.containers oder pod.spec.initContainers , aber so etwas wie pod.spec.sidecarContainers , die Sie, glaube ich, bereits besprochen, aber abgetan haben. Das Problem der init-Container verlangt definitiv nach einer solchen Lösung.

@luksa Sie könnten das Init-Problem auch lösen, indem Sie einfach

Das Problem mit pod.spec.sidecarContainers ist, dass es sich um eine weitaus komplexere Änderung handelt, die Tools aktualisiert werden müssten und das Kubelet viele Änderungen erfordern würde, um einen anderen Satz von Containern zu unterstützen. Der aktuelle Vorschlag ist viel bescheidener, er baut nur auf dem auf, was bereits vorhanden ist.

@Joseph-Irving Damit könnten wir ja arbeiten. Es ist nicht ideal, wenn der Sidecar nach der Ausführung der Init-Container heruntergefahren und dann derselbe Sidecar erneut gestartet wird, aber es ist besser, als diese Option nicht zu haben. Das größere Problem ist, dass ältere Kubelets Init-Sidecar-Container nicht richtig handhaben würden (wie es bei Main-Sidecar-Containern der Fall ist).

Ich möchte nur, dass Sie die Init-Sidecars berücksichtigen, wenn Sie den Vorschlag abschließen. Im Wesentlichen führen Sie das Konzept des "Sidecar" in k8s ein (vorher hatten wir im Grunde nur eine Reihe von Containern, die alle gleich waren). Jetzt führen Sie echte Sidecars ein, also sollten Sie IMHO wirklich gründlich darüber nachdenken und einen sehr wichtigen Anwendungsfall für Sidecars nicht ablehnen.

Bei der Umsetzung helfe ich gerne. Ohne sie kann Istio seine Funktionen nicht für init-Container bereitstellen (eigentlich verlieren init-Container in einem ordnungsgemäß gesicherten Kubernetes-Cluster, auf dem Istio ausgeführt wird, die Fähigkeit, mit _jedem_ Dienst zu kommunizieren) vollständig.

In Bezug auf die Implementierungsdiskussion in https://github.com/kubernetes/enhancements/pull/841 habe ich eine WIP-PR mit einem grundlegenden PoC für diesen Vorschlag geöffnet https://github.com/kubernetes/kubernetes/pull /75099. Es ist nur ein erster Entwurf und offensichtlich nicht perfekt, aber die grundlegende Funktionalität funktioniert und gibt Ihnen eine Vorstellung davon, wie viel Änderungen erforderlich sind.

cc @enisoc

Ich habe ein kurzes Video zusammengestellt, das nur zeigt, wie sich der PoC derzeit verhält https://youtu.be/4hC8t6_8bTs. Es in Aktion zu sehen kann besser sein, als darüber zu lesen.
Haftungsausschluss: Ich bin kein professioneller Youtuber.

Ich habe zwei neue PRs eröffnet:

• https://github.com/kubernetes/enhancements/pull/918 handelt von Abschlusskriterien, Versionsverzerrung, Upgrade/Downgrade
• https://github.com/kubernetes/enhancements/pull/919 soll über die API-Implementierung entscheiden

Alle mögliche Gedanken oder Vorschläge werden sehr geschätzt.

@Joseph-Irving Entschuldigung, wenn ich spät im Designprozess kommentiere, aber ich habe einen potenziellen Anwendungsfall für Sidecar-Container, der im aktuellen Designvorschlag möglicherweise nicht unterstützt wird. Ich wollte es nur zur Überlegung ansprechen. Das Wesentliche ist, dass ich ein Szenario habe, in dem bei der Pod-Beendigung 1 Sidecar vor dem Hauptcontainer beendet werden sollte, während ein anderer Sidecar nach dem Hauptcontainer beendet werden sollte.

Ein konkretes Beispiel könnte ein Pod mit einem Django-App-Container, einem Konsul-Sidecar für die Dienstregistrierung und einem pgbouncer-Sidecar für die Verwaltung von Verbindungen zur Datenbank sein. Wenn der Pod beendet wird, möchte ich, dass zuerst der Konsul-Sidecar gestoppt wird (damit kein Verkehr mehr zum Pod geleitet wird), dann der App-Container (idealerweise nach einer kurzen Kulanzzeit) und dann der pgbouncer-Sidecar. Der aktuelle Vorschlag sieht gut aus, um die Abhängigkeit von App <-> pgbouncer-Containern zu behandeln, scheint jedoch nicht aussagekräftig genug zu sein, um den Fall zu erfassen, in dem ich einen Sidecar _vor_ dem primären Container abreißen möchte.

@currankaushik , in dem von Ihnen beschriebenen Szenario könnten Sie möglicherweise einen Pre-Stop-Hook verwenden, um den Konsul-Container

Die Motivation dafür war, dass Proxy-Sidecars wie istio in einen Zustand gelangen können, in dem sie keinen Datenverkehr an Sie weiterleiten, aber dennoch Datenverkehr zulassen, während Ihre Anwendung beendet und heruntergefahren wird.

Klingt gut, danke @Joseph-Irving. Um mein Verständnis auf hohem Niveau zu bestätigen: Pre-Stop-Hooks werden zuerst an die Beiwagen gesendet, gefolgt von Pre-Stop-Hooks an die Nicht-Beiwagen, SIGTERM an die Nicht-Beiwagen und dann (nachdem alle Nicht-Beiwagen ausgestiegen sind .) ) SIGTERM zu Beiwagen? Der Designvorschlag (https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md) scheint dies zu implizieren, sagt aber auch:

PreStop Hooks werden gleichzeitig an Beiwagen und Container gesendet.

@currankaushik ja, was Sie beschrieben haben, ist das beabsichtigte Verhalten.

Diese Zeile, die Sie zitiert haben, muss umformuliert werden. Ich hatte einige Missverständnisse darüber, wie die Prestop-Hooks an die Container gesendet wurden, als ich das schrieb. Danke für den Hinweis.

@Joseph-Irving zielt diese Funktion auf die Alpha-Inklusion für 1.15 ab?

@kacole2 Ja, das ist der Plan, vorausgesetzt, wir können das KEP rechtzeitig zum Einfrieren der Erweiterung (30. April) implementieren. Sobald die API https://github.com/kubernetes/enhancements/pull/919 fertiggestellt und der Testplan vereinbart wurde https://github.com/kubernetes/enhancements/pull/951 Ich denke, wir sollten fertig sein.

/Meilenstein v1.15
/Bühne-Alpha

@Joseph-Irving Kubernetes 1.15 Enhancement Freeze ist am 30.04.2019. Um in den Kubernetes 1.15-Meilenstein aufgenommen zu werden, müssen sich KEPs in einem "implementierbaren" Zustand mit geeigneten Testplänen und Abschlusskriterien befinden. Bitte reichen Sie alle PRs ein, die erforderlich sind, damit diese KEP den Aufnahmekriterien entspricht. Wenn dies vom 1.15-Meilenstein abweicht, teilen Sie uns dies bitte mit, damit wir entsprechende Tracking-Änderungen vornehmen können.

@mrbobbytables Leider hatten die PRs, die geöffnet wurden, um dies in einen implementierbaren Zustand zu bringen, nicht viel Bewegung, daher denke ich, dass wir dies bis zum 1.16 verschieben müssen.

Kein Problem. Vielen Dank, dass Sie so schnell geantwortet und uns informiert haben!
/Meilenstein klar

Bitte bedenken Sie, dass dieser KEP für Istio sehr wichtig ist!

Es ist ein Showstopper für alle Projekte, die Service-Frameworks mit koordiniertem Bootstrap/Shutdown (akka cluster, lagom etc.) verwenden, zusammen mit istio service mesh siehe .

cc @jroper

@Joseph-Irving sry über den späten Kommentar, aber ich sehe Folgendes nicht im Designdokument und frage mich, was das beabsichtigte Verhalten davon ist:

Wenn wir einen Sidecar-Fehler sehen, starten wir sie immer neu, wenn der Hauptcontainer nicht fertig ist (ohne die restartPolicy im Pod zu beachten)? Dies wäre nützlich, da Sidecar früher als Proxy, Lastenausgleich, Housekeeping-Rolle verwendet wurde, und es spielt keine Rolle, wenn es ein paar Mal fehlschlägt, solange der Hauptcontainer weiterhin funktionieren kann

Wenn beim Berechnen der Pod-Phase alle Hauptcontainer erfolgreich waren und Sidecar fehlgeschlagen ist (was sehr häufig vorkommt, als ob Sidecar SIGTERM nicht abfängt, wird der Rückgabecode wie 143 oder so aussehen), ist die Pod-Phase immer noch "Erfolgreich"?

@zhan849 Sidecar-Container befolgen derzeit die Pod-Neustart-Richtlinie und werden bei der Berechnung der Pod-Phase gezählt, z. B. Succeeded .

Wir haben dies schon früher diskutiert, aber die allgemeine Meinung war, dass wir so wenig wie möglich von einem normalen Container abweichen sollten, und zwar nur, wenn dies die beschriebenen Anwendungsfälle ermöglicht.

In Bezug auf die Pod-Phase: Ich würde argumentieren, dass alle Anwendungen, die in Kubernetes laufen, SIGTERMs (insbesondere Sidecars) verarbeiten sollten, aber manchmal möchten Sie auch wissen, ob Ihre Sidecars auf schlechte Weise beendet wurden, und dies sollte sich in der Pod-Phase widerspiegeln. Das Verbergen dieser Informationen kann zu Verwirrung führen.

Bei der Neustartrichtlinie scheint dies nur dann ein Problem zu sein, wenn die Neustartrichtlinie nie lautet und Ihr Sidecar anfällig für Absturz ist. Ich bin mir nicht sicher, ob es sich lohnt, sie von der Pod-Neustart-Richtlinie abzuweichen, zumal einige Leute möchten, dass ihre Sidecars der Pod-Neustart-Richtlinie gehorchen.

Beides entspricht genau dem, was ein normaler Container tut und was derzeit passiert.
Sie zu ändern schien nicht erforderlich zu sein, um die im Kep aufgeführten Ziele zu erreichen.

Wenn Sie einige weit verbreitete Anwendungsfälle haben, warum eine Änderung erforderlich ist, um diese Ziele zu erreichen, wäre dies nützlich. Da es einfacher ist, eine kompliziertere Änderung der Codebasis zu rechtfertigen.

@Joseph-Irving Wir haben einige einfachere Beiwagen-Impls, die intern für einige unmittelbare Bedürfnisse ausgeführt wurden (wir haben keinen Beitrag geleistet, da dies in der Community bereits im Gange ist), und hier ist, was wir gelernt haben.

Zur Pod-Phase:

1. Der Status "Container vorhanden" wird bereits in pod.status.containerStatuses damit wir die Informationen nicht verlieren. Da ein großer Anwendungsfall von Sidecar im Job (oder in allen Run-to-Finish-Pods wie denen in Kubeflow) liegt, werden sinnvolle Workloads nur auf den Hauptcontainer angewendet und wenn die Pod-Phase aufgrund eines Sidecar-Fehlers als fehlgeschlagen markiert ist , führt dies zu unnötigen Wiederholungsversuchen und zu anderen irreführenden Konsequenzen wie Job-Fehler usw.

2. Obwohl es für Sidecars ideal ist, SIGTERMs zu handhaben, könnte es in der Produktion viele Sidecars geben, die einfach auf Open-Source-Software basieren und SIGTERMs nicht gut handhaben, einschließlich kube-proxy , postfix , rsyslogd und viele andere (und selbst wenn SIGTERM behandelt wird, wird es für nicht abfangbares SIGKILL mit Sicherheit nicht 0 sein)

In Bezug auf die Neustartrichtlinie (es könnte fraglich sein, aber Sidecars müssen sich strikt an die Neustartrichtlinie halten, ist in der Produktion irgendwie nicht realistisch):

1. Den Sidecar-Neustart zu erzwingen, wenn die Hauptcontainer noch ausgeführt werden, indem "OnFailure" festgelegt wird, ist keine Option, da dies fehlgeschlagene Hauptcontainer neu startet und zusammen mit dem Wiederholungslimit auf Jobebene verwirrend ist.

2. Normalerweise haben Hauptcontainer bei der Handhabung von Sidecars viele Wiederholungslogiken für nicht verfügbare Sidecars, und diese werden ausgeführt, bevor die Community Sidecar-Unterstützung mit einer expliziten Container-Startreihenfolge hat. Solche historischen Fehlerbehandlungen sind angesichts ihres Umfangs nicht sehr einfach zu ändern. Wenn der Sidecar nicht neu gestartet wird, hängen die Hauptcontainer auf und versuchen es erneut.

3. Die Weitergabe von Fehlern an übergeordnete Controller löst Abgleichsketten und viele API-Aufrufe aus, sodass eine unnötige Eskalation von Fehlern Kubernetes weniger skalierbar machen kann.
   Ein spezifischeres Beispiel: Wenn die Hauptcontainer eines Jobs noch ausgeführt werden und der Sidecar fehlschlägt, hat der Neustart des Sidecars nur 1 PATCH-Pod-Statusoperation und höchstens 1 ereignisbezogenen API-Aufruf. Wenn der Pod jedoch vollständig fehlschlägt, führt dies zu einem Abgleich von Job und mehr Einstellungsebenen-Controllern wie CronJob und anderen CRDs und es könnte noch viele weitere API-Aufrufe geben.

möchte auch sehen, ob andere Leute ähnliche Probleme gesehen haben (/cc @kow3ns )

Würde diese Änderung das in https://github.com/kubernetes/community/pull/2342 gewünschte Verhalten beinhalten, so dass es eine Möglichkeit gäbe, den gesamten Pod (oder nur den Nicht-Sidecar-Container) für einen Neustart zu konfigurieren, wenn a Beiwagen schlägt fehl?

@JacobHenner es gibt derzeit keine Pläne, diese Art von Mechanismus in dieser KEP zu implementieren, wir haben diskutiert, sie aufzunehmen, aber sie hängt nicht wirklich von dieser KEP ab und könnte unabhängig davon entwickelt werden. Es scheint also besser geeignet zu sein, ein eigenes KEP zu haben.

@Joseph-Irving nur um unser Impl zu teilen, das die oben genannten Fallstricke als Referenz ansprach (https://github.com/zhan849/kubernetes/commits/kubelet-sidecar), da unser Ziel darin besteht, auf offizielle Unterstützung zu warten, versuchen wir es um Änderungen in diesem Commit so lokal wie möglich zu halten.

also für eine Job-Neustart-Richtlinie == Nie, mit 1 Hauptcontainer, 1 schlechten Sidecar, der ständig abstürzt, 1 guten Sidecar, der weiterläuft, sieht der Pod-Status so aus, nachdem der Hauptcontainer mit der obigen Impl. beendet wurde.

containerStatuses:
  - containerID: xxxxx
    image: xxxxx
    imageID: xxxxx
    lastState: {}
    name: main
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 0
        finishedAt: "2019-05-24T17:59:53Z"
        reason: Completed
        startedAt: "2019-05-24T17:59:43Z"
  - containerID: xxxxx
    image: xxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-bad
    ready: false
    restartCount: 1
    state:
      terminated:
        containerID: xxxxx
        exitCode: 1
        finishedAt: "2019-05-24T17:59:46Z"
        reason: Error
        startedAt: "2019-05-24T17:59:45Z"
  - containerID: xxxxx
    image: xxxxxxx
    imageID: xxxxx
    lastState: {}
    name: sidecar-healthy
    ready: false
    restartCount: 0
    state:
      terminated:
        containerID: xxxxx
        exitCode: 137
        finishedAt: "2019-05-24T18:00:24Z"
        reason: Error
        startedAt: "2019-05-24T17:59:44Z"
  hostIP: 10.3.23.230
  phase: Succeeded
  podIP: 192.168.1.85
  qosClass: BestEffort
  startTime: "2019-05-24T17:59:41Z"

Ich stimme im Allgemeinen zu, dass ein Sidecar-KEP die Pod-Phase und die Neustartrichtlinie berücksichtigen muss, bevor es in einen implementierbaren Zustand übergehen kann. Es ist mir egal, ob es sich um diesen KEP handelt oder nicht, aber ich stimme im Allgemeinen den Argumenten von @ zhan849 zu und muss hier behandelt werden.

danke @smarterclayton !
@Joseph-Irving lassen Sie uns wissen, ob wir in der Praxis noch etwas mit Sidecar teilen möchten.

@smarterclayton @zhan849 , Ich bin mit den Punkten, die Sie machen, nicht besonders nicht einverstanden, sondern versuche nur, einige

Ich werde dieses Feedback an sig-apps/sig-node zurückgeben und sehen, was sie denken. Insbesondere sig-node war daran interessiert, die Sidecars so nah wie möglich an normalen Containern zu halten, wenn @derekwaynecarr oder @dchen1107 dies begrüßen möchten.

Der Testplan https://github.com/kubernetes/enhancements/pull/951 und das API-Design https://github.com/kubernetes/enhancements/pull/919 PRs wurden nun zusammengeführt.

Ich habe https://github.com/kubernetes/enhancements/pull/1109 geöffnet, um das KEP als implementierbar zu markieren, sobald alle damit zufrieden sind, sollten wir die Entwicklung dafür als Alpha in 1.16 starten können

Dieses Kep wurde als implementierbar markiert, daher werde ich die PRs erhöhen, um es ab nächster Woche auf 1.16 zu bringen!

Ich habe https://github.com/kubernetes/kubernetes/pull/79649 erstellt , um die API zu implementieren, ich werde eine separate PR für die Kubelet-Änderungen haben.

Hallo @Joseph-Irving, ich bin der 1.16 Enhancement Lead. 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. Wenn dies nicht der Fall ist, werde ich es aus dem Meilenstein entfernen und das nachverfolgte Label ändern.

Wenn die Codierung beginnt oder bereits erfolgt ist, listen Sie bitte alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können.

Meilensteintermine sind Enhancement Freeze 30.07. und Code Freeze 29.08.

Dankeschön.

@Joseph-Irving Wenn Sie zusätzliche Leute benötigen, um dies umzusetzen, habe ich großes Interesse an dieser Landung, daher helfe ich gerne mit.

Hallo @kacole2 dies zielt auf Alpha für 1.16 ab, der KEP wurde als implementierbar markiert.
Die einzige PR hierfür ist derzeit kubernetes/kubernetes#79649 für die API

@mhuxtable Ich werde die PR für die Kubelet-Änderungen ziemlich bald erhöhen, nur einige Dinge beenden, ich würde mich sehr über Hilfe freuen,

Ich habe https://github.com/kubernetes/kubernetes/pull/80744 geöffnet, das die Kubelet-Änderungen implementiert.

Bitte beachten Sie, dass kubernetes/kubernetes#79649 (api) noch geöffnet ist, sodass dieser PR Commits davon enthält, was ihn groß erscheinen lässt. Ich habe es in Commits unterteilt, die jeweils eine andere Funktionalität implementieren, sodass es einfach sein sollte, es auf diese Weise zu überprüfen.

Ich bin noch nicht ganz fertig mit allen Testfällen dafür, aber der erste Entwurf einer funktionierenden Implementierung ist fertig, also möchte ich, dass die Leute einen Blick darauf werfen.

cc @kacole2

@Joseph-Irving

Ich bin einer der v1.16 Docs Shadows.
Erfordert diese Verbesserung (oder die für v1.16) geplanten Arbeiten neue Dokumente (oder Änderungen an bestehenden Dokumenten)? Wenn nicht, können Sie bitte das 1.16 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.16), die bis Freitag, den 23. August fällig ist, es kann zu diesem Zeitpunkt nur eine Platzhalter-PR sein. Lassen Sie es mich wissen, wenn Sie Fragen haben!

Hallo @daminisatya , ja, dazu werden Updates für Docs benötigt, ich habe https://github.com/kubernetes/website/pull/15693 als Platzhalter-PR erhoben.
Mich würde interessieren, ob jemand eine Meinung dazu hat, wohin die Docs gehen sollen. Ich habe jetzt etwas in content/en/docs/concepts/workloads/pods/pod-lifecycle.md .

Mit weniger als einer Woche bis zum Einfrieren von Code ist es sehr unwahrscheinlich, dass dies in 1.16 Einzug halten wird.
Wir haben immer noch zwei relativ große offene PRs kubernetes/kubernetes#80744 und kubernetes/kubernetes#79649, die Schwierigkeiten haben, irgendwelche Bewertungen zu bekommen.
Hoffentlich gibt es im nächsten Release-Zyklus mehr Reviewer-Bandbreite, um sich diese anzusehen.

/zuordnen

Könnte dies es ermöglichen, einen Sidecar zu schreiben, der den eigentlichen Dienst bei Bedarf starten (und zerstören) kann?

Wie auf Null skalieren, aber das einzige, was im Leerlauf läuft, ist der Beiwagen. Wenn eine Anfrage kommt, wird der eigentliche Dienst hochgefahren und nach einer letzten Antwort, z. B. 30s, geschlossen. Dies könnte eine einfache Möglichkeit ermöglichen, eine Skalierung auf fast Null durchzuführen (wobei nur noch Sidecars ausgeführt werden).

@Ciantic Mit Operator Framework können Sie das und vieles mehr tun. Schau mal

@janosroden Ich habe

Das Problem ist nicht, dass es keine Optionen gibt, zB Osiris , Keda oder Knative . Ich habe das letzte versucht, aber es beansprucht 8 GB Speicher, schwer zu sagen, dass es zu diesem Zeitpunkt "serverlos" ist.

Das Problem ist, dass die meisten dieser Implementierungen neue Ressourcen usw. benötigen. Es ist viel einfacher, sich dies vorzustellen, damit man einen Sidecar einfügen kann, der den gesamten Lebenszyklus (einschließlich Starten und Neustarten bei Bedarf) steuern kann, damit er den Dienst über nur hinaus steuern kann Dort sitzen.

Warum sollte dies von Vorteil sein? Es ist wirklich nützlich in Situationen mit geringer Auslastung und geringem Speicher, zB k3s mit Raspberry Pi oder Digital Ocean Droplet für Hobbyprojekte. Viele von uns haben viele Webdienste, die nicht die ganze Zeit laufen müssen, nur ein Sidecar zu haben, das sie bei Bedarf aufweckt, würde ausreichen.

Ich bin mir nicht sicher, ob dies für Ihren Anwendungsfall wirklich funktioniert. Ich sehe absolut den Wunsch, das zu tun, was Sie auf solchen Systemen mit eingeschränkten Ressourcen tun möchten. Um jedoch wirklich stabil zu sein, müssen Sie Ressourcenanforderungen verwenden, um die Arbeitsbelastung zu planen. Diese müssten im Voraus angegeben werden, sodass unabhängig davon, ob der Workload ausgeführt wird oder nicht, die Ressource reserviert werden sollte.

Um dies zu umgehen, benötigen Sie einen eigenen Pod, um den anfänglichen Verbindungsempfang durchzuführen und eine neue Pod-Anforderung an k8s zu senden, darauf zu warten, dass er hochgefahren wird, und dann den Datenverkehr dorthin zu senden. Sidecar-Container-Verbesserungen sind in diesem Fall meiner Meinung nach nicht erforderlich. Ich denke, Sie brauchen etwas mehr wie ein xinetd für k8s.

Hallo @Joseph-Irving -- 1.17 Verbesserungen führen hierher. Ich wollte mal reinschauen und sehen, ob diese Verbesserung Ihrer Meinung nach in 1.17 in die Alpha-Phase übergeht?

Der aktuelle Veröffentlichungsplan ist:

• Montag, 23. September – Beginn des Veröffentlichungszyklus
• 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 nach Beginn der Codierung alle relevanten k/k-PRs in dieser Ausgabe auf, damit sie ordnungsgemäß nachverfolgt werden können. 👍

Vielen Dank!

Hallo @mrbobbytables , vorausgesetzt, wir können alles rechtzeitig überprüfen, ist geplant, in 1.17 auf Alpha zu wechseln.

Die aktuellen offenen PRs sind:
https://github.com/kubernetes/kubernetes/pull/79649 - API-Änderungen
https://github.com/kubernetes/kubernetes/pull/80744 - Kubelet-Änderungen

Lass es mich wissen, wenn du noch etwas brauchst!

Groß! Danke @Joseph-Irving ich füge die Infos zum Tracking Sheet hinzu 👍

@Joseph-Irving

Ich bin einer der v1.17 Docs Shadows.
Erfordert diese Verbesserung (oder die für v1.17) geplante Arbeit 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!

Vielen Dank!

Hallo @VineethReddy02 ja, dazu ist eine Dokumentation erforderlich, Platzhalter-PR ist hier https://github.com/kubernetes/website/pull/17190

Ich habe eine PR erstellt, um das KEP zu aktualisieren https://github.com/kubernetes/enhancements/pull/1344. Es basiert auf einigen Diskussionen, die wir in der Implementierungs-PR hatten https://github.com/kubernetes/kubernetes/pull /80744.

Ich würde mich über Kommentare freuen

Hey @Joseph-Irving 1.17 Enhancement Shadow hier! 👋 Ich melde mich bei Ihnen, um zu sehen, wie diese Verbesserung verläuft.

Das Verbesserungsteam verfolgt derzeit kubernetes/kubernetes#79649 und kubernetes/kubernetes#80744 im Tracking-Sheet. Gibt es noch andere k/k-PRs, die ebenfalls verfolgt werden müssen?

Außerdem eine weitere freundliche Erinnerung daran, dass wir uns schnell dem Einfrieren des Codes nähern (14. November).

Hallo @annajung , ja, das sind die einzigen PRs, die Tracking benötigen.

Hallo @Joseph-Irving, morgen ist Code-Freeze für den Release-Zyklus 1.17 . Es sieht so aus, als ob die k/k-PRs nicht zusammengeführt wurden. Wir kennzeichnen diese Verbesserung als At Risk im Tracking-Sheet 1.17.

Glauben Sie, dass alle notwendigen PRs bis zum EoD vom 14. (Donnerstag) zusammengeführt werden? Danach sind mit Ausnahme nur noch Release-Blocking Issues und PRs im Meilenstein erlaubt.

Hallo @annajung , leider sieht es sehr unwahrscheinlich aus, dass sie vor dem Einfrieren des Codes zusammengeführt werden. Wir haben in diesem Release-Zyklus große Fortschritte gemacht, sodass wir sie hoffentlich früh in 1.18 zusammenführen können.

Hey @Joseph-Irving Danke für das Update. Ich werde den Meilenstein entsprechend aktualisieren und diese Verbesserung als auf 1.18 verschoben markieren. Dankeschön!

/Meilenstein v1.18

Hallo @Joseph-Irving. 1.18 Erweiterungen führen hierher 👋 .

Die Version 1.18 hat gestern begonnen, also frage ich nach, ob Sie planen, dies in der Version 1.18 zu landen. Ich denke, dass dies 1.17 wegen Code-Freeze verpasst hat. Wie sieht es mit 1.18 aus? Ich sehe, die PRs sind noch offen.

Vielen Dank!

Hallo @jeremyrickard ,

Ja, der Plan ist, dies in der Version 1.18 zu bekommen.

Der API-PR (https://github.com/kubernetes/kubernetes/pull/79649) hat neulich eine Bewertung von tockin erhalten, er hatte ein paar Punkte, aber sobald diese behoben sind, werden wir diesen PR schließen und die Commits in (https://github.com/kubernetes/kubernetes/pull/80744), damit wir die API und die Implementierung zusammenführen können.

Was den Kubelet PR (https://github.com/kubernetes/kubernetes/pull/80744) betrifft, muss er nur überprüft werden. Ich hoffe, wir können etwas Sign-Node-Bandbreite bekommen, um ihn in diesem Zyklus zu überprüfen.

Danke für das Update @Joseph-Irving

In das Tracking-Blatt aufgenommen!

Tut mir leid, dass ich zu spät zur Party komme. Dies ist eine deutliche Verbesserung für allgemeine Fälle. Scheint aber keinen fortgeschritteneren Fall abzudecken.

Betrachten Sie einen Fall mit Sidecar, das Protokolle exportiert, die auch vom Istio-Sidecar abhängig sind. Wenn der Istio-Sidecar zuerst heruntergefahren wird, werden einige sensible Protokolle möglicherweise nicht exportiert.

Ein allgemeinerer Ansatz wäre, explizite Abhängigkeiten zwischen Containern zu definieren. Egal ob Beiwagen oder nicht.

Was halten Sie stattdessen von einer solchen API-Definition:

kind: Pod
spec:
  containers:
  - name: myapp
    dependsOn: ["exporter", "istio"]
  - name: exporter
    dependsOn: ["istio"]
  - name: istio

@rubenhak , das wird sehr schnell unordentlich. Was muss erfüllt sein, damit die Abhängigkeit klar ist, um fortzufahren? Es gibt oft eine Lücke zwischen gestartet und fertig, von der ich denke, dass es sich wirklich darum kümmern würde, dass die API nicht anspricht.

@kfox1111 Wie bestimmt das vorgeschlagene Design, dass der Sidecar gestartet und bereit ist, um den

Ich denke nicht, dass DependOn Kriterien angeben sollte. Es könnte im abhängigen Container angegeben werden. Wären ReadinessProbe und/oder LivenessProbe nicht ausreichend? Wenn nicht, kann es eine startupProbe geben,

Hallo @Joseph-Irving Ich bin einer der v1.18 Docs Shadows.
Erfordert diese Verbesserung für (oder die für v1.18) geplante Arbeit neue Dokumente (oder Änderungen an bestehenden Dokumenten)? 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 ja, nur eine freundliche Erinnerung, wir suchen eine PR gegen k/website (Zweig dev-1.18), die bis Freitag, den 28. Februar fällig ist. Es kann derzeit nur eine Platzhalter-PR sein. Lassen Sie es mich wissen, wenn Sie Fragen haben!

Hallo @irvifa, ich habe hier eine Platzhalter-PR erstellt https://github.com/kubernetes/website/pull/19046

Hallo @Joseph-Irving Vielen Dank für Ihre schnelle Antwort!

@rubenhak - Ich stimme @kfox1111 zu , dass ein vollständiges Diagramm der Abhängigkeiten ziemlich schnell ziemlich chaotisch werden kann. Wie wäre es, die Container in der Reihenfolge in der Pod-Spezifikation zu starten und sie dann in umgekehrter Reihenfolge (wie einen Stapel) abzubauen? Dies wäre viel einfacher zu implementieren und deckt die meisten der gängigen Anwendungsfälle für die Bestellung ab, die mir einfallen.

@rgulewich , könnten Sie etwas genauer

Die Idee der Reihenfolge ist in Ordnung, aber da die meisten Sidecars mit Zugangscontrollern injiziert werden, wäre es wirklich schwierig, die Richtigkeit der Reihenfolge zu garantieren. Es ist eine Umleitung erforderlich.

@rubenhak könnte es einen Zyklus in der Abhängigkeitsreihenfolge der Container geben, wie entscheidet k8s/kubelet, den Zyklus zu unterbrechen und zu entscheiden, in welcher Reihenfolge die Container gestartet/gestoppt werden sollen? Wenn Sie laut denken, könnte dies eine API-seitige Validierung sein.

Hallo @Joseph-Irving,

Nur eine freundliche Erinnerung daran, dass der Code-Freeze für 1.18 am 05. März 2020 ist .

Während wir das Einfrieren des Codes verfolgen, listen Sie bitte alle PRs auf, an denen Sie arbeiten, um diese Verbesserung abzuschließen!

Hey @jeremyrickard ,

Ist die Pr zum Verfolgen https://github.com/kubernetes/kubernetes/pull/80744
Dieser PR enthält API-Änderungen, aber die Commits werden in den obigen PR zusammengeführt, sobald die Überprüfung abgeschlossen ist https://github.com/kubernetes/kubernetes/pull/79649

@rubenhak könnte es einen Zyklus in der Abhängigkeitsreihenfolge der Container geben, wie entscheidet k8s/kubelet, den Zyklus zu unterbrechen und zu entscheiden, in welcher Reihenfolge die Container gestartet/gestoppt werden sollen? Wenn Sie laut denken, könnte dies eine API-seitige Validierung sein.

@bjhaid , API-Seite kann die Validierung durchführen. Die Schleifenerkennung ist ein trivialer Algorithmus mit einer linearen Zeitkomplexität (genau wie die DFS-Durchquerung).

Möglicherweise muss die Validierung auch nach der Sidecar-Injektion erneut ausgeführt werden.

Ich habe eine Weile darüber nachgedacht ... Die meisten Probleme mit Abhängigkeiten laufen meiner Meinung nach auf Service Meshes hinaus. (vielleicht fällt jemandem ein anderes Beispiel ein)

Der Service-Mesh-Proxy ist ein Sidecar, das vor allem anderen gestartet und bereit sein muss und nach allem anderen beendet werden muss. Sie haben eine lange Laufzeit, sind also eher ein Sidecar als ein Init-Container.

Aber auch initContainer sollten idealerweise alle das Service Mesh nutzen können.

InitContainer müssen jedoch möglicherweise andere Sidecar-Container initieren.

Obwohl wir eine Art kompliziertes Abhängigkeitssystem mit Init-Containern, Sidecar-Containern und regulären Containern entwickeln könnten, sollten wir vielleicht nur zwei Klassen von Sidecars haben? reguläre Sidecars und Netzwerk-Sidecars?

Netzwerk-Sidecars müssen alle von Anfang an fertig werden. Service Mesh-Proxys gehen hier.
Init-Container werden der Reihe nach als nächstes ausgeführt.
Beiwagen alle starten und bereiten sich vor. Dies kann Dinge wie Authentifizierungs-Proxys, Logger usw. umfassen.
reguläre Container starten und werden fertig.

Abreißen ist in umgekehrter Reihenfolge.

Würde dies das Abhängigkeitsproblem beseitigen und gleichzeitig alle Probleme lösen, die Service Meshes mit der Containerbestellung zu haben scheinen? Ich denke schon?

@kfox1111 , Vault führt jetzt eine geheime Injektion mit Sidecars durch. In welche Klasse soll es passen? Je nach Fall kann der Tresor auch vom Service Mesh abhängen oder umgekehrt.

Ich sage nur, dass ein solches Design schließlich in 10 Beiwagenklassen explodieren würde. Ein solcher Ansatz impliziert eine noch stärkere Meinung darüber, wie die Dinge laufen sollten. Die Leute würden anfangen, mit Klassen zu hacken, nur um die Reihenfolge zu erreichen, die zum Starten der Anwendung erforderlich ist.

Wenn der einzige Zweck dieser Klassen darin besteht, die Reihenfolge zu definieren, warum dann nicht explizit?

Um Ihre Frage zu beantworten, würde ein solches Design zwar einige Anwendungsfälle abdecken, es hilft jedoch nicht bei anderen Fällen wie Vault-Sidecars, Logging-Sidecars usw. Dies ist bereits ein Vorschlag für die Neugestaltung der ursprünglichen Funktion. Da dies ein zweiter Versuch ist, lohnt es sich diesmal, es richtig zu machen.

Ich weiß nicht, wie kompliziert Abhängigkeiten sind. Könnten Sie das näher ausführen? Abhängigkeiten machen YAML-Definitionen offensichtlicher, es gibt keine versteckte Logik. Ein Ansatz mit hartcodierten Klassen würde eine versteckte Logik und viel mehr Dokumentation erfordern, die erklärt, warum Netzwerk-Sidecars nach anderen Sidecars usw. ausgeführt werden sollten.

Was passiert, wenn wir ein Feld in Container einführen?

    // +optional
    Priority int

Dieses Feld ist bei Containern desselben Typs (Sidecar, normal) wirksam.
Bei Sidecar-Containern würde der Sidecar-Container mit der höheren Priorität zuerst instanziiert / zuletzt abgerissen.

@tedyu , Abhängigkeit hat im Vergleich zu "Priorität" viel mehr Metadaten und einen höheren Wert. Es dauert 30 Zeilen c++-Code, um die Prioritätsreihenfolge bei gegebener Abhängigkeit zu erzeugen https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ . Umgekehrt ist nicht möglich.

Ein weiterer Vorteil besteht darin, dass bei gegebenem Abhängigkeitsgraph bestimmte Container gleichzeitig gestartet werden können.
Im folgenden Beispiel: "A -> B, B -> C, D -> C" können die Container B und D gleichzeitig gestartet werden, wenn C initialisiert wird. Ich sage nicht, dass die Implementierung dies unterstützen muss, aber es kann zumindest sehr wertvoll sein, wenn die API eine solche Definition zulässt.

Integer-Priorität wird nicht gut funktionieren – die Leute werden alle Arten von verschiedenen, nicht standardisierten Zahlen verwenden, wie sie es mit der CSS-Z-Index-Eigenschaft (wie -9999 ) tun.

@rubenhak Was Sie an dieser Stelle vorschlagen, ist im Grunde eine völlig andere Funktion als die in diesem KEP beschriebene. Es ist keine kleine Optimierung, sondern eine vollständige Neufassung. Es wäre erforderlich, dass alle, die diesem Feature zuvor zugestimmt hatten (es dauerte ein Jahr, bis es von allen Parteien genehmigt wurde), dies neu bewerten.
Wenn Sie sich für ein solches Feature begeistern, würde ich vorschlagen, dass Sie Ihr eigenes KEP erstellen und es zu den verschiedenen SIGs bringen, um ihr Feedback dazu zu erhalten.

Die Idee eines Abhängigkeitsgraphen wurde ausführlich diskutiert, als dieser Vorschlag im Jahr 2018 ins Leben gerufen wurde. Die Schlussfolgerung war einstimmig, dass zwar einige weitere Anwendungsfälle ermöglicht würden, diese jedoch nicht stark genug waren und sich die zusätzliche Komplexität nicht lohnte.

Ich glaube, Sie unterschätzen etwas den Grad der Änderung, der erforderlich ist, um das zu implementieren, was Sie beschreiben. Aber wenn es so einfach ist, wie Sie denken, könnten Sie Ihren eigenen Proof of Concept dieser Arbeit in Kubernetes erstellen und diesen den SIGs vorlegen, um Ihren Fall zu stärken.

Diese KEP ist noch keine GA-Funktion. Wenn Ihre KEP genehmigt und implementiert wird, können wir diese entfernen. Sie schließen sich noch nicht gegenseitig aus.

Diese Änderung ist vielleicht nicht die perfekte Lösung für jeden einzelnen Anwendungsfall, aber sie verbessert die Erfahrung für die meisten dramatisch und ich denke, wir wären viel besser dran, dies zusammenzuführen, um dann ein weiteres Jahr über die Implementierung zu diskutieren.

Wenn Ihr KEP genehmigt und implementiert wird, können wir dieses entfernen. Sie schließen sich noch nicht gegenseitig aus.

Würden sie sich gegenseitig ausschließen?

Ich frage mich, ob diese Funktion einen Wert hat _auch wenn_ eine explizitere Reihenfolge beim Starten / Herunterfahren von Containern (was ich für großartig halte) durch eine weitere Verbesserung in der Zukunft aktiviert wird ... und ich denke, ja.

Jede Start- / Shutdown-Reihenfolge, die durch die Klassifizierung von Containern als init, sidecar oder "regulär" beiseite gelegt wird, drücken auch _andere_ nützliche und wohl nicht verwandte Aspekte des gewünschten Verhaltens eines Containers aus, nicht wahr?

In einem Pod mit restartPolicy != Always (vielleicht ein Pod, der einen Job implementiert) ist es beispielsweise nützlich, dass als Sidecars bezeichnete Container keinen Einfluss darauf haben, dass ein Pod in einen abgeschlossenen Zustand übergeht.

@kfox1111 , Vault führt jetzt eine geheime Injektion mit Sidecars durch. In welche Klasse soll es passen? Je nach Fall kann der Tresor auch vom Service Mesh abhängen oder umgekehrt.

Wir arbeiteten mit ephemeren csi-Treibern, damit Dinge wie Vault keine Sidecars/Init-Container benötigen. Ich glaube, es ist ein Tresortreiber in Arbeit.

Obwohl ein normaler Sidecar mit emptyDir für einen Sidecar geeignet zu sein scheint, der die Netzwerk-Sidecars verwenden muss?

@Joseph-Irving, ich habe auf keinen Fall versucht, dieses KEP daran zu hindern.

Haben Sie einen Link zu einer früheren Diskussion zum Abhängigkeitsdiagramm?

Hallo @Joseph-Irving,

Freundliche Erinnerung daran, dass wir den Code Freeze am 05. März 2020 ziemlich schnell schließen. Es sieht nicht so aus, als ob Ihre PRs noch zusammengeführt wurden. Haben Sie immer noch das Gefühl, dass Sie auf dem richtigen Weg sind, um den Code für diese Erweiterung einzufrieren?

Hey @jeremyrickard , Der API-Review (https://github.com/kubernetes/kubernetes/pull/79649) ist grundsätzlich abgeschlossen. Wir werden diese PR schließen und vollständig in die Implementierungs-PR übergehen, damit alles (API und Implementierung) in einer PR zusammengeführt werden kann.

Die Implementierungs-PR (https://github.com/kubernetes/kubernetes/pull/80744) wurde gründlich überprüft, daher versuche ich, einen Sign-Node-Genehmiger zu veranlassen, die endgültige Genehmigung zu prüfen.

Ob dies rechtzeitig zum Code-Freeze passiert, ist für mich etwas schwer zu sagen, es hängt stark davon ab, ob ich es schaffe, rechtzeitig die Aufmerksamkeit einiger Genehmiger zu erregen.

Würde gerne sehen, dass dies per Code-Freeze eingeht. Dies würde die Lösung von Istio für https://github.com/istio/istio/issues/7136 sowohl einfacher als auch besser machen.

Irgendeine Bewegung in dieser Hinsicht, um auf 1.18 zu kommen? Scheint notwendig zu sein, damit istio-Sidecars bei schnell laufenden Jobs wie erwartet funktionieren.

Ich habe auf verschiedene Weise versucht, mit den Sign-Node-Genehmigern Kontakt aufzunehmen, aber ich habe keine Antworten erhalten. Daher bin ich nicht sehr optimistisch, dass dies es in 1.18 schaffen wird.

@Joseph-Irving der Slack-Channel #pr-reviews wurde für diese Fälle erstellt. Hast du das probiert? Es ist eine Möglichkeit, eine Eskalation bei PR-Rezensionen zu erreichen. (Ich habe es dort nicht gesehen)

Hallo @Joseph-Irving,

Wir sind jetzt nur noch wenige Tage vom Code-Freeze entfernt. Möchten Sie dies basierend auf der Bandbreite des Bewerters auf 1,19 verschieben? Oder versuchen, einen Schubs zu machen?

Hey @jeremyrickard ,

Niemand hat mir bezüglich der Zusammenführung dieser PRs in 1.18 geantwortet, daher bezweifle ich stark, dass dies passieren wird.

Wir können uns auf 1.19 verschieben, aber ich frage mich langsam, ob es einen Sinn hat, dies zu tun.
Dieses KEP ist seit fast zwei Jahren im Einsatz (ursprüngliches Alpha-Ziel war 1,15), die betreffenden PRs sind seit fast einem Jahr offen, es gibt nie eine "Rezensentenbandbreite" für sie.
Ich habe höflich per E-Mail gemailt, nachgelassen, bin zu Sig-Meetings gegangen und habe sogar Leute persönlich gefunden, um Bewertungen zu erhalten, aber wir haben nur sehr geringe Fortschritte gemacht.
Alle Rezensionen, die ich bekommen habe, haben immer nur kleine Änderungen vorgeschlagen, es ist nicht so, dass große Neufassungen angefordert wurden, die PRs sind im Grunde alle dieselben wie vor einem Jahr, nur ein bisschen ausgefeilter.
Ich weiß nicht, ob ich Leute jeden Tag aggressiv anpingen soll, bis sie mir antworten, aber das ist wirklich nichts, was ich gerne tue.

Ich denke, das Problem ist eher, dass sich niemand wirklich für dieses Feature interessiert, ich bin der einzige, der dieses Feature vorantreibt, niemand in den SIGs scheint daran interessiert zu sein, dies durchzuziehen. Wenn es zwei Jahre dauert, bis die Alpha-Version erreicht ist, wie lange dauert es dann, bis Beta/GA erreicht ist? (als wenn die meisten Leute dies tatsächlich verwenden können)

Frustrierenderweise scheint das Interesse der breiteren Community und der Endbenutzer daran zu bestehen, diese Funktion zu nutzen. Der Grund, warum ich dies in erster Linie getan habe, ist, dass ich sah, dass es ein Problem war, und die SIGs fragte, ob sie es beheben würden, und sie sagte: "Wir haben nicht die Kapazität, aber wir würden uns freuen, wenn Sie dies tun".
Also habe ich alles getan, was sie verlangten, ich habe das KEP geschrieben, ich habe es von allen Parteien genehmigt bekommen, ich habe den gesamten Code geschrieben, alle Tests, habe es ständig auf dem neuesten Stand gehalten, wenn jede Veröffentlichung bestanden wurde, und doch sind wir hier.

Jedes Mal, wenn wir das hinauszögern, habe ich das Gefühl, eine Menge Leute im Stich zu lassen, ist das nur meine Schuld? Ist der Code so schrecklich, dass niemand kommentiert? Bin ich einfach nicht aggressiv genug um Aufmerksamkeit zu bekommen?
Ich habe einfach das Gefühl, dass ich das nicht alleine hinbekomme, und ich habe es ein bisschen satt, dieses tote Pferd zu schlagen.

Es tut mir leid für das lange Gerede (das nicht an dich persönlich gerichtet ist, Jeremy oder irgendjemanden persönlich), aber das frisst schon seit langer Zeit langsam an meiner Seele.

Frustrierenderweise scheint das Interesse der breiteren Community und der Endbenutzer daran zu bestehen, diese Funktion zu nutzen. Der Grund, warum ich dies in erster Linie getan habe, ist, dass ich sah, dass es ein Problem war, und die SIGs fragte, ob sie es beheben würden, und sie sagte: "Wir haben nicht die Kapazität, aber wir würden uns freuen, wenn Sie dies tun".

@Joseph-Irving Dazu. Als aktiver Benutzer schaue ich mir diesen Thread an, weil ich daran interessiert bin (und zwei meiner Kollegen auch). Aktivitäten in Bezug auf das Problem, Pull Request, Slack Channels oder Sigs sind möglicherweise nicht der beste Indikator für das Interesse an dieser Funktion.

@dims Vielleicht kannst du etwas Licht ins Dunkel bringen?

@tockin Ich habe Sie vor einem Jahr im Kubernetes-Podcast interviewt und Sie haben darüber gesprochen, zu Kubernetes beizutragen. Vielleicht waren es Sie oder jemand anderes in einer anderen Podcast-Folge, der sich wirklich schlecht fühlte, dass dieser Beiwagen-KEP es nicht bis 1.16 geschafft hat. Nun, da sind wir wieder.

Dieses Thema scheint ein Paradebeispiel dafür zu sein, wie schwierig es sein kann, einen Beitrag zu leisten, wenn Sie kein Mitarbeiter von zB sind. Google, RedHat oder andere Big Player.

Ich habe auch in Slack um Hilfe bei der Überprüfung gebeten, aber mir wurde nur gesagt, dass @tockin eine explizite

Ich habe viel Zeit mit der kurzlebigen CSI-Treiberfunktion verbracht. Es war ähnlich frustrierend, es durchzubringen, und es gab Zeiten, in denen ich mir nicht sicher war, ob es nach so vielen Verzögerungen und Neugestaltungen es schaffen würde. Also, ich spüre deinen Schmerz. Es wäre toll, wenn wir einen Weg finden könnten, es weniger schmerzhaft zu machen. Davon abgesehen haben wir es auch irgendwann geschafft, nachdem wir einige wichtige Veröffentlichungen verpasst hatten. Also bitte nicht aufgeben/die Hoffnung verlieren! Das Schiff kann schwer zu drehen sein, aber irgendwann tut es das.

Jeder, der irgendeine Art von Topologie betreibt, die von einem Netzwerk-Sidecar abhängt, trifft höchstwahrscheinlich auf Probleme bei der Reihenfolge beim Starten / Herunterfahren von Containern, die dieser KEP möglicherweise lösen würde. Strg-F für "Istio" auf diesem Ticket, und Sie werden eine Reihe von Ärgernissen im Zusammenhang mit der Containerbestellung sehen.

Gibt es hier Istio-Maintainer? Viele sind Googler und haben vielleicht intern mehr Einfluss auf die K8s-Leute.

Als Istio / K8s-Shop sind wir absolut darauf bedacht, dass Sie das bekommen, @Joseph-Irving! ️

Kudos für @Joseph-Irving dafür, dass Sie den Beiwagen so weit gemacht haben.

Selbst für das Sidecar-Lifecycle-Management würde jeder Batch-Job diese Funktion erfordern oder Kubernetes funktioniert einfach nicht für sie, und deshalb haben wir viel Zeit damit verbracht, auch Code-Reviews zu unterstützen und Feedback zu geben!

Aus diesem Grund forken wir seit einiger Zeit k8s und freuen uns sehr darauf, dass so ein wichtiges Feature offiziell unterstützt wird.

Auf dieses Feature haben wir als Istio + Kubernetes Shop auch sehnsüchtig gewartet. Und zunehmend frustriert, dass es von Release zu Release rutscht. Wir sind nicht erfreut, auf Hacks zurückgreifen zu müssen, um die Sidecars bei Job-Workloads zu töten. Für unsere Bedürfnisse ist dies seit weit über einem Jahr das wichtigste Feature, das wir in Kubernetes benötigen.

@thockin Es wurde oben berichtet, dass Sie dies ausdrücklich

Darauf warten auch viele Linkerd-Benutzer sehnsüchtig. Halte durch @Joseph-Irving, wir feuern dich an.

Ich bin mir nicht sicher, ob alle anderen hier es gesehen haben, aber nachdem ich etwas gegraben und ein Kubecon-Video angesehen hatte, stellte ich fest, dass Lyft etwas Ähnliches getan hatte. Hier ist der erwähnte Commit aus ihrem Kubernetes-Fork: https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

Auf dieses Feature haben wir als Istio + Kubernetes Shop auch sehnsüchtig gewartet. Und zunehmend frustriert, dass es von Release zu Release rutscht.

Ich bin ein potenzieller Istio-Benutzer, habe mich aber ein wenig abseits gehalten, weil ich auf ein solches Feature gewartet habe. Während der obigen Diskussionen sehe ich jedoch immer wieder Dinge, die mich denken lassen, dass die hier besprochene Sidecar-Funktion allein nicht alle Probleme beheben wird, die der istio-Sidecar mit dem Workflow hat. Es kann aber helfen. Was meiner Meinung nach einer der Gründe dafür ist, dass dies ins Stocken geraten ist.

Wie funktioniert das Ausführen von istio in einem Sidecar, wenn der istio cni-Treiber verwendet wird? Ich glaube, dass init-Container, die versuchen, das Netzwerk zu erreichen, immer noch nicht richtig funktionieren, wie in der istio-Dokumentation dokumentiert.

daher meine obige Frage, ob Netzwerk-Sidecars eine eigene Sache sind.

Dieses Thema scheint ein Paradebeispiel dafür zu sein, wie schwierig es sein kann, einen Beitrag zu leisten, wenn Sie kein Mitarbeiter von zB sind. Google, RedHat oder andere Big Player.

Haha! Was Sie nicht wissen, ist, dass diese Leute auch manchmal stecken bleiben!

Im Ernst, es tut mir leid. Ich habe Ausreden, aber das ist scheiße, also werde ich mich nicht darum kümmern.

Zur Klarstellung:
Ich will damit nicht sagen, dass wir dies nicht als Alpha zusammenführen sollten, um Feedback zum Ansatz zu erhalten. Im Allgemeinen finde ich es solide. Ich denke, es gibt ein paar Lücken in den Anwendungsfällen wie Service Meshes, die es nicht ganz abdeckt. Aber das ist kein Grund, dies so schnell wie möglich zu blockieren, damit wir alle anderen Anwendungsfälle finden können, die es nicht abdeckt, damit wir die Beta-Version des Features für alle gut funktionieren lassen. Genau das ist ein Alpha für IMO.

Ich erwähne nur, was ich getan habe, insbesondere für die Leute, die hoffen, dass dies ein Allheilmittel für das bestehende Service-Mesh-Problem sein wird. Ich glaube nicht, dass die vorgeschlagene Alpha dieses spezielle Problem vollständig beheben wird. Machen Sie sich also noch nicht zu große Hoffnungen. Aber bitte, lasst uns diese Funktion nicht blockieren, nur weil sie noch nicht alle unterstützt.

Ich habe eine Ausnahme beantragt. Mal sehen, ob wir versuchen können, dies einzufügen:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

Vielleicht waren es Sie oder jemand anderes in einer anderen [Kubernetes Podcast]-Folge, der sich wirklich schlecht fühlte, dass dieser Sidecar-KEP es nicht auf 1.16 . geschafft hat

Bitte sehen Sie sich die Folgen 72 mit Lachie Evenson und 83 mit Guinevere Saenger an . Ich habe diese Woche sogar

Gibt es hier Istio-Maintainer? Viele sind Googler und haben vielleicht intern mehr Einfluss auf die K8s-Leute.

@duderino und @howardjohn haben diesen Thread bereits kommentiert.

Um es klar zu sagen, müssen wir zusammengeführt werden:
kubernetes/kubernetes#79649
kubernetes/kubernetes#80744

Gibt es andere PRs, die wir verfolgen sollten?

Vielen Dank!

• Verbesserungsteam

Großes Dankeschön an alle, die (öffentlich oder privat) Unterstützungsnachrichten gepostet haben, die sehr geschätzt wurden ❤️

Es gab tapfere Bemühungen von Mitgliedern der Community, dies in 1.18 zu bringen, einschließlich des Veröffentlichungsteams, das eine Verlängerungsanfrage akzeptierte, aber leider wurde beschlossen, dies auf 1.19 zu verschieben. Sie können die entsprechende Konversation ab diesem Kommentar sehen: https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034.

Obwohl es nicht in 1.18 angekommen ist, hat dies in den letzten Tagen viel mehr Aufmerksamkeit erfahren als seit einiger Zeit, daher hoffe ich, dass sich diese Dynamik in 1.19 fortsetzt.

cc @jeremyrickard , @kikisdeliveryservice

Tolles Zeug @Joseph-Irving, klingt so, als ob sich einige Ihrer Frustrationen gelohnt und gehört haben. Danke fürs Durchhalten.

/Meilenstein v1.19

Hallo zusammen. Eine Gruppe von uns hat dieses Thema in der letzten Woche diskutiert.

Zuerst entschuldigen wir uns für das, was hier passiert ist. Wir sind nicht glücklich darüber.

Diese PR und die damit verbundene KEP haben eine Reihe von Dingen ans Licht gebracht, die das Projekt besser machen kann. Wir möchten die sozialen, prozessualen und technischen Belange trennen.

Gesellschaftlich fiel diese Funktion unserem Wunsch zum Opfer, einander zu gefallen. Derek genehmigte die KEP trotz der innerhalb der SIG geäußerten Vorbehalte, weil Clayton und Tim darauf drängten. Wir vertrauen uns alle, aber anscheinend haben wir nicht immer das Gefühl, „nein“ sagen zu können. Wir wissen das, weil wir alle genau dasselbe getan haben. Keiner von uns möchte der Blocker für die nächste großartige Idee sein.

Einander zu vertrauen muss auch das Vertrauen beinhalten, dass wir „nein“ sagen können und dass jemand „nein“ sagt, dies aus guten Gründen tut. Dieser technische Bereich umfasst SIGs, und wir sollten Sign-Node, die letztendlich diejenigen sein werden, die Probleme vor Ort haben werden, NICHT dazu drängen, neue Funktionen zu akzeptieren, die sie noch nicht unterstützen können. Es geht hier nicht um Tim oder Derek oder Clayton im Besonderen. aber ALLE hochrangigen Genehmiger und SIG-Leiter und „leitenden“ Mitwirkenden.

Auch dieses Merkmal fiel der Verfahrensunsicherheit im Zusammenhang mit KEPs zum Opfer. Bin ich als KEP-Reviewer verpflichtet, Code-Reviewer zu sein? An einen Code-Reviewer delegieren? Oder einfach nur das KEP lesen? Da KEPs Releases umfassen, wie stellen wir sicher, dass ein Hirte für die in einem bestimmten Release-Zeitraum budgetierten Änderungen verfügbar ist. Wenn ein KEP SIGs umfasst, wie planen und verteilen wir Zeit auf die SIGs? Dies müssen wir klären. Wir werden an einigen KEP-Änderungsvorschlägen (KEP-KEPs) arbeiten, um die Rollendefinition im KEP-Prozess zu stärken.

Technisch fiel dieses Feature sowohl der Zeit als auch der Aufmerksamkeit zum Opfer. Die Rezensenten nahmen sich nicht genug Zeit, um es zu überprüfen, oder es hatte einfach nicht die hohe Priorität für sie. Hin- und Hergespräche brauchen Zeit. Die Umstände und unser Verständnis des Problemraums ändern sich im Laufe der Zeit.

Da immer mehr Benutzer Kubernetes übernehmen, sehen wir, dass eine zunehmende Anzahl seltsamer Edge-Cases oder Flakes an sign-node gemeldet wird. Da der Pod-Lebenszyklus den Kern von Kubernetes bildet, MÜSSEN alle Änderungen an diesem Subsystem sorgfältig vorgenommen werden. Unsere Fähigkeit, neue Funktionen zusammenzuführen, muss mit unserem Wunsch, die Zuverlässigkeit zu verbessern, in Einklang gebracht werden. Wie wir heute über den Pod-Lebenszyklus denken, unterscheidet sich ein wenig von der Vorstellung, als diese Funktion gestartet wurde. Dies schmälert die Anwendungsfälle, die dazu geführt haben, in keiner Weise, legt jedoch nahe, dass KEPs mit langer Laufzeit im Laufe der Zeit regelmäßig überprüft werden müssen.

Wir sind der Meinung, dass wir im Hinblick auf den Pod-Lebenszyklus einige grundlegende Überlegungen anstellen müssen. Was wollen wir wirklich? Wir haben versucht, nicht in zu viel Komplexität abzusinken, aber wir befürchten, dass wir diese Komplexität lediglich in mehrere Phasen aufgeteilt haben, und das Endergebnis könnte komplexer sein, als nur frontal anzugehen.

Was bedeutet das für diese PR und die dazugehörige KEP? Wir sind uns nicht 100% sicher. Es bedeutet wahrscheinlich, dass wir dies jedoch noch NICHT durchsetzen sollten.

Derek äußerte einige Bedenken hinsichtlich der Abfolge der Abschaltung. Die KEP hat sie vorerst außerhalb des Geltungsbereichs gerufen, aber es gibt einiges Zögern. Wir respektieren die ordnungsgemäße Beendigung beim Herunterfahren des Knotens bereits nicht, und das hat viele Benutzer überrascht. Das ist nicht die Schuld dieses KEP, aber nennen wir es „mildernde Umstände“. Wenn jemand Sidecars verwendet, um seine Pods zu „bereinigen“ (zB um zwischengespeicherte Protokolle in einen Protokollierungsdienst zu entleeren), wird er (angemessen) eine klare und nützliche Semantik zum Herunterfahren erwarten, die dieser KEP nicht garantiert.

Tim hat Bedenken, dass Init-Sidecars zu etwas werden müssen, und das fühlt sich nicht richtig an. Auf diese Sorge hat er in der Vergangenheit verzichtet, aber es stört ihn immer noch.

Wir brauchen SIG Node, um zu definieren, was das mittelfristige Ziel für den Pod-Lebenszyklus ist und welchen Appetit sie darauf haben. Wenn wir zustimmen , dass dies ein inkrementeller Schritt auf das Ziel, können wir es entsperren, aber wenn wir das Ziel kennen, werden wir wahrscheinlich über fahren unsere Scheinwerfer.

Lasst uns alle die Ersten sein, die sagen, dass das stinkt. Wir haben echte Problembeschreibungen, einen leidenschaftlichen Mitwirkenden und eine Reihe wohlmeinender Betreuer, und wir sind ... hier gelandet. Tim wird seine Zeit zur Verfügung stellen, um beim Brainstorming und bei der Gestaltung zu helfen. Derek wird die Arbeiten zum Herunterfahren von Knoten für den aktuellen Pod-Lebenszyklus vorantreiben, um sicherzustellen, dass wir eine stabile Basis für das weitere Wachstum haben. Wir müssen sehr genau spezifizieren, welche Garantien wir bei ungeplanten Maschinenausfällen geben können und welche nicht.

Vielen Dank,
Clayton, David, Dawn, Derek, John, Tim

Um zu versuchen, etwas nach vorne zu bringen: Derek oder Dawn – gibt es jemanden, der sich Zeit für ein Brainstorming über einen ganzheitlicheren Pod- und Container-Lebenszyklus nehmen kann?

@thockin fügt dies der

@tockin @derekwaynecarr was ist der tl;dr, warum das nicht reingehen konnte?

Einzeilige Beschreibung der Erweiterung: Container können jetzt als Sidecars markiert werden, so dass sie vor normalen Containern starten und herunterfahren, nachdem alle anderen Container beendet wurden.

Klingt nach etwas, das das Leben in dieser neuen Ära der Service-Mesh-Seitenwagen einfacher machen würde.

Gibt es außerdem Empfehlungen dafür, dass Sidecars heute vor dem Haupt-App-Container gestartet und nach der Beendigung des Haupt-App-Containers heruntergefahren werden?

... was ist der tl;dr, warum das nicht reingehen konnte?

@naseemkullah Von https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 ...

Was bedeutet das für diese PR und die dazugehörige KEP? Wir sind uns nicht 100% sicher. Es bedeutet wahrscheinlich, dass wir dies jedoch noch NICHT durchsetzen sollten.

Derek äußerte einige Bedenken hinsichtlich der Abfolge der Abschaltung. Die KEP hat sie vorerst außerhalb des Geltungsbereichs gerufen, aber es gibt einiges Zögern. Wir respektieren die ordnungsgemäße Beendigung beim Herunterfahren des Knotens bereits nicht, und das hat viele Benutzer überrascht. Das ist nicht die Schuld dieses KEP, aber nennen wir es „mildernde Umstände“. Wenn jemand Sidecars verwendet, um seine Pods zu „bereinigen“ (zB um zwischengespeicherte Protokolle in einen Protokollierungsdienst zu entleeren), wird er (angemessen) eine klare und nützliche Semantik zum Herunterfahren erwarten, die dieser KEP nicht garantiert.

[…]

Wir brauchen SIG Node, um zu definieren, was das mittelfristige Ziel für den Pod-Lebenszyklus ist und welchen Appetit sie darauf haben. Wenn wir uns darauf einigen können, dass dies ein schrittweiser Schritt in Richtung des Ziels ist, können wir die Blockierung aufheben, aber wenn wir das Ziel nicht kennen, übertreiben wir wahrscheinlich unsere Scheinwerfer.

Bei allem Respekt, ich bin gespannt, ob irgendwelche Leads planen, dies zu priorisieren. @Joseph-Irving hat enorm viel Arbeit hineingesteckt und eine erstaunliche Anzahl von Leuten, die mit seiner Lösung zufrieden gewesen wären, sind bestrebt, eine überlegene Lösung von denen zu hören, die dies verneint haben.

Obwohl es bei einigen Aspekten Bedenken gibt, halte ich es zumindest für sinnvoll, als Alpha einzusteigen, um herauszufinden, welche Probleme sich in der Praxis zeigen werden. Können wir das zusammenführen? Die Probleme können verhindern, dass es in die Beta geht, daher denke ich, dass es nicht entscheidend ist, perfekt zu werden, bevor eine erste Alpha erstellt wird.

wird dies der Sign-Node-Agenda hinzufügen.

@tockin @derekwaynecarr Gibt es ein Update zum aktuellen Stand? Ich habe die Sitzungsnotizen des Sign-Node durchgesehen und kann nichts darüber finden.

Es gibt eine große Anzahl von Entwicklern in diesem Thread, die gerne Zeit für die Implementierung beitragen würden, da dies für viele Anwendungsfälle von entscheidender Bedeutung ist (das KEP selbst hat 2,5x so viele :+1: wie jedes andere KEP). Was können wir tun, damit dies geschieht? Eine Liste von Voraussetzungen für die Stabilität dieses Bereichs zu haben, auch wenn sie viele Releases umfasst, an denen wir aktiv arbeiten könnten, wäre eine enorme Verbesserung gegenüber dem, was wir heute sind.

Hallo @Joseph-Irving @thockin @khenidak @kow3ns -- 1.19 Erweiterungen Führen Sie hier durch, ich wollte

Um diesen Teil der Veröffentlichung zu haben:

1. Die KEP PR muss in einem umsetzbaren Zustand zusammengeführt werden
2. Das KEP muss über Testpläne verfügen
3. Die KEP muss Abschlusskriterien haben.

Der aktuelle Veröffentlichungsplan ist:

• Montag, 13. April: Woche 1 - Release-Zyklus beginnt
• Dienstag, 19. Mai: Woche 6 – Verbesserungen einfrieren
• 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

@palnabarun , https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056 wurde diese KEP auf unbestimmte Zeit ausgesetzt, daher wird sie nicht in 1.19 abgeschlossen.

Danke @Joseph-Irving für die Klärung der Situation. :+1:

Schätze deine Bemühungen!

An alle, die das gerne reinbringen möchten, und nochmals an @Joseph-Irving – diese Situation tut mir persönlich sehr leid. Ich möchte dies (oder etwas Ähnliches) auch, aber Tatsache ist, dass Sign-Node mehr Arbeit zu tun hat als die Leute, die es jetzt tun, und sie sind nicht bereit, dies in Betracht zu ziehen.

Es nervt. Ich verstehe es. Ich wirklich wirklich.

Der beste Weg, um zu helfen, besteht darin, in Sign-Node zu springen und mehr Kapazität zu schaffen, indem sie Code-Reviews und Problem-Triage übernehmen, Fehler und Tests beheben und auf einen Ort hinarbeiten, an dem die Sign-Node-Experten mehr Kapazität haben und Vertrauen in eine solche Änderung.

sign-node hat im Moment mehr zu tun als die Leute, die es tun müssen

Verstanden. Wir haben den Kapazitätsbedarf von sign-node intern mit Nachdruck gefördert. Wir stellen und betreuen Sign-Node-OSS-Freiwillige, von denen einige neue Erfahrungen gemacht haben, und alle mit dem Wunsch, in diesem Bereich zu arbeiten (bisher vier). Ich werde auf deinen Kommentar @tockin zitieren , danke!

/Meilenstein klar

Der beste Weg, um zu helfen, besteht darin, in Sign-Node zu springen und mehr Kapazität zu schaffen, indem sie Code-Reviews und Problem-Triage übernehmen, Fehler und Tests beheben und auf einen Ort hinarbeiten, an dem die Sign-Node-Experten mehr Kapazität haben und Vertrauen in eine solche Änderung.

@thockin Könnten Sie die Links wie Repositorys, Mailinglisten, Leitfäden usw. bereitstellen? Das würde den Leuten helfen, eine Vorstellung davon zu bekommen, wie sie effektiv mit Sign-Node interagieren können. Diese spezielle Funktionsanfrage ist über 2 Jahre alt und es ist keine Lösung in Sicht.

@tariq1890 Leute, die diesen KEP schreiben, haben alles richtig gemacht. sie haben keinen Stein auf dem anderen gelassen. Das Problem hier ist genau das, was @thockin gesagt hat, es gibt technische Schulden, die wir zuerst beheben müssen, und dafür werden Hände benötigt, bevor wir diese in Betracht ziehen können. Die Bitte ist also, dass die Leute bei dem helfen, was getan werden muss.

Bitte sehen Sie sich das neueste Update hier an: https://github.com/kubernetes/enhancements/pull/1874

@dims Ich glaube, ich wurde missverstanden. Was ich damit sagen wollte, ist, dass wir eine Liste von umsetzbaren Zielen und Zielen brauchen. Wenn technische Schulden zu bewältigen sind, könnten wir einen GitHub-Meilenstein unterhalten oder eine Aufzählung der ausstehenden Aktionspunkte im OP-Kommentar bereitstellen, damit Besucher dieses Problems sofort wissen, was angegangen werden muss.

Ich bin definitiv bereit, meine Hilfe anzubieten, um dieses KEP voranzutreiben, aber ich weiß einfach nicht wie

@tariq1890 die spezifische Frage ist hier: "Voraussetzung für das (noch nicht eingereichte KEP) Kubelet-Knoten ordnungsgemäßes Herunterfahren" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d772fR94

Wir müssen damit beginnen. Jemand muss auf den Punkt kommen und das in Gang bringen.

-- Dimmt

Also die Zusammenfassung https://github.com/kubernetes/enhancements/pull/1874 für diejenigen in dieser Ausgabe: Sig-node (und andere) halten es für unklug, ein neues Feature wie dieses KEP einzuführen, das komplexeres Verhalten hinzufügt Pod-Beendigung, während es immer noch das allgemeinere Problem der Pod-Beendigung gibt, während ein Knoten heruntergefahren wird.
Daher wurde entschieden, dass diese Funktion nicht fortgesetzt wird, bis die Lösung für die Knotenbeendigung implementiert wurde.
Derzeit gibt es hier ein Google-Dokument: https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
Das enthält viele Diskussionen zu diesem Thema, aber die KEP dafür muss noch eingereicht werden.
Es gibt noch offene Fragen, daher könnte es hilfreich sein, diese zu kommentieren. Ich glaube, @bobbypage und @mrunalp leiten diese Bemühungen, damit sie vielleicht andere Möglichkeiten

@Joseph-Irving vielen Dank für die Zusammenfassung. Ich hoffe, dass all die +ve Energie für diese Verbesserung dazu führt, dass jeder regelmäßig an Sign-Node teilnimmt und nicht nur für Funktionen. Es gibt viel zu tun und nur sehr wenige Hände.

Hi! Noch ein Kommentar zu diesem KEP: Ich habe in früheren SIG-Knoten-Meetings (23 Fragen, damit wir entscheiden können, wie wir am besten vorgehen.

Ich arbeite derzeit an einer PR, um diese Probleme und einige Alternativen aufzuzeigen, die mir einfallen.

Außerdem ist der KEP-Zustand jetzt provisorisch (statt umsetzbar), so dass er überprüft und erst wieder auf umsetzbar gesetzt werden kann, wenn alle Menschen einverstanden sind, mit der KEP fortzufahren.

Ich denke, dies war die einzige fehlende Information in dieser Ausgabe. Vielen Dank!

@rata Haben Sie Probleme/PRs zur richtigen Handhabung der Probleme geöffnet?

@mattfarina Dies ist die PR https://github.com/kubernetes/enhancements/pull/1913
Es enthält eine Reihe von Lösungsvorschlägen für aktuelle Probleme/Randfälle im KEP
Enthält auch Details zu einer Reihe von Alternativen, die diskutiert und gegen die entschieden wurde, damit wir besser protokollieren können, warum bestimmte Entscheidungen getroffen wurden.

Ich würde sehr gerne sehen, dass die Sidecar-Funktionalität auch die Skalierung abdeckt:
Heutzutage basiert die HPA-Skalierung auf einer Metrik (z. B. CPU). Enthält der Pod mehr als einen Container, wird der Durchschnitt über alle Container verwendet (soweit ich weiß). Bei Pods mit Sidecar (App + nginx usw.) ist es sehr schwierig, die Skalierung richtig zu machen. Ich hatte gehofft, dass die Sidecar-Implementierung in Kubernetes beinhalten würde, einen Container im Pod als "autorativ" in Bezug auf die für die HPA-Skalierung verwendeten Metriken zu markieren.

Ich würde sehr gerne sehen, dass die Sidecar-Funktionalität auch die Skalierung abdeckt:

Ich stimme zu, dass dies nützlich wäre, aber es ist nicht unbedingt "sidecar"-spezifisch und da die Implementierung davon entkoppelt ist, kann es sinnvoll sein, es zu einem separaten Thema zu machen - dieses ist bereits sehr komplex. Ich bin auch nicht überzeugt, dass Sie den Beiwagen einfach ignorieren möchten. Wir können stattdessen beispielsweise eine HPA-Skalierung pro Container wünschen. Ich bin mir nicht sicher - müsste als eigenes Problem untersucht werden, denke ich.

Hat jemand einen Hinweis auf die aktuelle Problemumgehung für dieses Problem oder könnte diese mitteilen, insbesondere für den Fall des Istio Envoy-Sidecars?

Ich erinnere mich an eine mögliche Problemumgehung mit:

• ein benutzerdefiniertes Envoy-Image, das SIGTERM ignoriert.
• Aufrufen von /quitquitquit auf Envoy aus dem Anwendungscontainer beim Herunterfahren (ähnlich der Problemumgehung für den Jobabschluss)

Hat jemand einen Hinweis auf die aktuelle Problemumgehung für dieses Problem oder könnte diese mitteilen, insbesondere für den Fall des Istio Envoy-Sidecars?

Wir verwenden ein benutzerdefiniertes Daemon-Image wie ein supervisor , um das Programm des Benutzers einzuschließen. Der Daemon lauscht auch auf einen bestimmten Port, um den Zustand der Benutzerprogramme (beendet oder nicht) zu übermitteln.

Hier ist die Problemumgehung:

• Verwenden des Daemon-Images als initContainers um die Binärdatei auf ein freigegebenes Volume zu kopieren.
• Unser CD entführt den Benutzerbefehl, lassen Sie den Daemon zuerst starten. Anschließend führt der Daemon das Benutzerprogramm aus, bis Envoy bereit ist.
• Außerdem fügen wir preStop , ein Skript, das den Gesundheitsstatus des Daemons ständig überprüft, für Envoy.

Als Ergebnis wird der Benutzerprozess gestartet, wenn Envoy bereit ist, und Envoy stoppt, nachdem der Benutzerprozess beendet wurde.

Es ist eine komplizierte Problemumgehung, funktioniert aber in unserer Produktionsumgebung gut.

Der Link in der Beschreibung gibt einen 404

https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/0753-sidecarcontainers.md

Ich denke, es sollte sein:

https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0753-sidecarcontainers.md

ja, es wurde in https://github.com/kubernetes/enhancements/pull/1913 verschoben, ich habe den Link aktualisiert

Hat jemand einen Hinweis auf die aktuelle Problemumgehung für dieses Problem oder könnte diese mitteilen, insbesondere für den Fall des Istio Envoy-Sidecars?

@shaneqld Für Startprobleme hat sich die istio-Community eine ziemlich clevere Problemumgehung einfallen lassen, die im Grunde envoy als ersten Container in die Containerliste einfügt und einen postStart-Hook hinzufügt, der überprüft und wartet, bis envoy bereit ist. Dies blockiert und die anderen Container werden nicht gestartet. Stellen Sie sicher, dass envoy vorhanden und bereit ist, bevor Sie den App-Container starten.

Wir mussten dies auf die von uns ausgeführte Version portieren, ist aber recht unkompliziert und mit den bisherigen Ergebnissen zufrieden.

Für das Herunterfahren "lösen" wir auch mit dem preStop-Hook, fügen jedoch einen willkürlichen Sleep hinzu, von dem wir hoffen, dass die Anwendung ordnungsgemäß heruntergefahren wird, bevor sie mit SIGTERM fortfährt.

Verwandte PR: https://github.com/kubernetes/enhancements/pull/1980

Hallo @Joseph-Irving @tockin und alle anderen :smile:

Verbesserungen führen hierher. Ich sehe, dass es immer noch eine Menge an laufenden Gesprächen gibt, aber zur Erinnerung, bitte halte uns auf dem Laufenden, ob Pläne zur Aufnahme in 1.20 beschlossen wurden, damit wir den Fortschritt verfolgen können.

Vielen Dank!
Kirsten

@kikisdeliveryservice hält Sie auf dem

Hat jemand einen Hinweis auf die aktuelle Problemumgehung für dieses Problem oder könnte diese mitteilen, insbesondere für den Fall des Istio Envoy-Sidecars?

@shaneqld Für Startprobleme hat sich die istio-Community eine ziemlich clevere Problemumgehung einfallen lassen, die im Grunde envoy als ersten Container in die Containerliste einfügt und einen postStart-Hook hinzufügt, der überprüft und wartet, bis envoy bereit ist. Dies blockiert und die anderen Container werden nicht gestartet. Stellen Sie sicher, dass envoy vorhanden und bereit ist, bevor Sie den App-Container starten.

Wir mussten dies auf die von uns ausgeführte Version portieren, ist aber recht unkompliziert und mit den bisherigen Ergebnissen zufrieden.

Für das Herunterfahren "lösen" wir auch mit dem preStop-Hook, fügen jedoch einen willkürlichen Sleep hinzu, von dem wir hoffen, dass die Anwendung ordnungsgemäß heruntergefahren wird, bevor sie mit SIGTERM fortfährt.

Könnten Sie einige Einblicke im Detail zeigen, wie man diese macht? Wie erreicht man das Hinzufügen von "Pre-Stop" zum Istio-Proxy-Sidecar? Es scheint, dass es eine benutzerdefinierte Konfiguration benötigt oder einen benutzerdefinierten Sidecar verwendet. Ich stehe vor dem gleichen Problem, dass der Hauptcontainer beim Verkleinern von Pods versucht, die Jobs zu beenden, aber die Verbindung nach außen verliert, wahrscheinlich weil der Istio-Sidecar sofort nach SIGTERM geschlossen wurde. Im Moment verwende ich nur die Standard-Sidecar-Injection. Dankeschön!

Ok, dieser Thread wird gekapert. Bleiben wir bitte beim Thema.

Nur eine sanfte Erinnerung daran, dass Enhancements Freeze nächste Woche, Dienstag, 6. Oktober, stattfindet. Bis dahin müsste die KEP aktualisiert werden, um als umsetzbar markiert zu werden.

Auch das KEP verwendet ein älteres Format, daher wäre eine Aktualisierung großartig (sobald Sie die Details herausgearbeitet haben): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice danke für den Rest. Wird ausreichen, wenn beschlossen wird, für 1.20 aufgenommen zu werden. Vielen Dank! :)

Dies wird nicht Teil von 1.20 sein. Vielen Dank fürs Pingen! :)

Ich interessiere mich für dieses Problem und möchte sowohl @Joseph-Irving als auch @howardjohn für ihre Erkenntnisse dazu danken, die dazu beigetragen haben, einige meiner Fragen zu lösen.

Ich möchte diesen Vorschlag nicht entführen, aber basierend auf den obigen Gesprächen frage ich mich, ob dies vielleicht ein etwas breiteres / größeres Problem ist, als bisher erkannt wurde.

Ich kann mir folgende Lösungen für dieses Problem vorstellen:

1. Definieren Sie eine neue Container-Entität "Sidecar-Container", die nach initContainers vor "Hauptcontainern" beginnt und nach Beendigung von "Hauptcontainern" endet (gemäß dem ursprünglichen Vorschlag von @Joseph-Irving).
2. Definieren Sie ein zusätzliches Feld auf (1), das festlegt, ob der "Sidecar-Container" vor dem initContainer(s) per @luksa- Vorschlag beginnt).
3. Gehen Sie breiter.

Persönlich löst Option (2) mein unmittelbares Problem .

Aber ich frage mich, ob diese Fragen nicht zu einem strategischeren Thema in K8s sprechen, das die Planung und die Definition eines Pods betrifft. In meinem speziellen (Istio-bezogenen) Fall habe ich so etwas wie Runlevels innerhalb von Pods vorgeschlagen.

Option (2) löst auch mein Problem, aber ich kann mir noch komplexere Abhängigkeitsstrukturen vorstellen, die die Einbettung einer DAG von Container-Abhängigkeiten in ein Pod/statefulSet/daemonSet/was auch immer erfordern - dies ist die Option (3), an die ich denke.

Sie fragen sich nur, ob dieses Problem wirklich auf die Pod-Definition selbst konzentriert werden sollte, um etwas generischeres zu schaffen? Ich dachte ursprünglich in Bezug auf eine Runlevel-Analogie, aber vielleicht hätte eine Airflow-ähnliche DAG-Struktur die breiteste Anwendbarkeit.

Wie wäre es, envoy auch als Init-Container hinzuzufügen? Auf diese Weise wird ein Netzwerk für andere Init-Container bereitgestellt. Wenn die Init abgeschlossen ist, würde sie auch "0" verlassen, und dann würde der normale Gesandte (nicht Init) übernehmen

@michalzxc Wenn ich mich nicht irre, werden init-Container nacheinander nacheinander ausgeführt, sodass Sie derzeit keinen Gesandten neben einem anderen Container als init-container .

Hi!

Die Sidecar-Diskussion wurde an diesen Stellen fortgesetzt (ich habe sign-node slack, github PR, die dies gestartet haben, und mehrere Mailinglisten aktualisiert):
https://groups.google.com/g/kubernetes-sig-node/c/w019G3R5VsQ/m/bbRDZTv5CAAJ
https://groups.google.com/g/kubernetes-sig-node/c/7kUaX-jBN3M/m/dhI3E8LOAAAJ

Wie Sie sehen, sammeln wir jetzt Anwendungsfälle, nachdem wir einige weitere Anwendungsfälle haben, können verschiedene kleine Gruppen Vorvorschläge erstellen, die sich damit befassen. Fühlen Sie sich frei, Ihren Anwendungsfall hinzuzufügen (falls er noch nicht da ist) oder treten Sie später für den Teil der Vorvorschläge bei :-)

Bitte lassen Sie uns dieses Verbesserungsproblem beim Thema belassen (und wahrscheinlich geschlossen). Sie sind herzlich eingeladen, sich an diesen Orten zu unterhalten :)

Diese KEP wird nicht vorankommen, Sig-node und andere sind der Meinung, dass dies kein schrittweiser Schritt in die richtige Richtung ist, also sind sie zurück zum Reißbrett gegangen und werden einige neue KEPs entwickeln, die hoffentlich alle Probleme lösen können Fälle, die in dieser KEP sowie in anderen aufgeführt sind.

Bitte lesen Sie den vorherigen Kommentar von @rata https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
Für Orte, an denen Sie zur Diskussion beitragen können.

Es ist bedauerlich, dass die ganze Arbeit an diesem KEP nicht zur Anwendung kommt, aber eine größere Gruppe von Menschen denkt jetzt über diese Probleme nach, so dass die Lösung, die sie finden, hoffentlich die beste für alle ist.
Ich habe bereits über zwei Jahre damit verbracht, dies durchzubringen, daher denke ich, dass dies ein guter Zeitpunkt für mich ist, weiterzumachen.

/nah dran

@Joseph-Irving: Schließe dieses Problem.