Kubernetes: CronJobs sollte Zeitzonen unterstützen

@iterion Es gibt keine fügen Sie ein Sign-Label hinzu, indem Sie:
(1) ein Zeichen erwähnen: @kubernetes/sig-<team-name>-misc
(2) manuelles Angeben des Labels: /sig <label>

_Hinweis: Methode (1) löst eine Benachrichtigung an das Team aus. Die Teamliste findet ihr hier und die Labelliste hier _

/sig-Apps

Bevorzuge die zweite Option, da sie für mich mehr Natur aussieht

@soltysh @kubernetes/sig-apps-feature-requests

Ich mag auch die zweite Form, aber es scheint, dass der einfachste Weg zur Implementierung darin besteht, diese Zeit zu entfernen und sie separat zu verwenden. Es könnte auch argumentiert werden, dass wir uns nicht damit anlegen sollten, da wir das "Standard"-Cron-Template verwenden.

Es scheint, als ob dies einfach zu implementieren sein sollte:
Derzeit übergeben wir nur time.Now() in die syncOne Schleife. Die Cron-Bibliothek, die k8s verwendet, scheint zu funktionieren, indem sie nur Zeiten in der Zone verwendet, die Ihnen wichtig ist. Wir könnten also die Zeitzone aus dem CronJob ziehen und diese Zeit mit zone an die syncOne-Funktion übergeben.

//init the loc, needs error handling
//perhaps default to local if Timezone was invalid
loc, _ := time.LoadLocation(cronjob.Spec.Timezone)

//set timezone,  
now := time.Now().In(loc)

Gerne versuche ich dies auch umzusetzen.

Ich bin nicht die richtige Person, um Ihre PR zu überprüfen, aber ich habe ein paar Fragen zur Semantik.

• Wie sieht die Semantik aus, wenn keine Zeitzone angegeben ist?
• Hängt die Implementierung von der korrekten Konfiguration der Zeitzone auf dem Controller-Host ab?
• Wann überprüfen wir die Rechtmäßigkeit der Zeitzone? Zum Zeitpunkt der Objekterstellung/-aktualisierung oder später?
• Was passiert, wenn ein Zeitzonenname beim Erstellen des API-Objekts zulässig war, aber in Zukunft nicht mehr existiert? Dies kann passieren, weil ein Name entfernt wird (vielleicht hört eine Stadt oder Nation auf zu existieren) oder weil das zugrunde liegende tzdata-Paket in eine ältere Version geändert wurde.

Wenn keine Zeitzone definiert ist, wird standardmäßig das aktuelle Verhalten verwendet, das darin besteht, die Zeitzone des Hosts zu verwenden. Ich würde vermuten, dass dies in den meisten Fällen als UTC konfiguriert ist, aber ein Benutzer könnte wirklich jede Zeitzone auswählen. Daher besteht aufgrund dieses PR keine größere Abhängigkeit von der korrekten Konfiguration der Zeitzone auf dem Host.

Ich steige derzeit einfach aus und verwende die Zeitzone des Hosts, wenn der Benutzer etwas Ungültiges angegeben hat. Hier stütze ich mich auf die time.LoadLocation(str) -Methode von

Soweit die letzte Frage, die ist etwas undefinierter. Derzeit und wahrscheinlich auch in Zukunft würde es höchstwahrscheinlich darauf zurückgreifen, den Job basierend auf der Standardzeitzone zu planen. Ich bin offen für Vorschläge, wie man mit diesem Fall umgeht.

Was passiert, wenn ein Zeitzonenname beim Erstellen des API-Objekts zulässig war, aber in Zukunft nicht mehr existiert? Dies kann passieren, weil ein Name entfernt wird (vielleicht hört eine Stadt oder Nation auf zu existieren) oder weil das zugrunde liegende tzdata-Paket in eine ältere Version geändert wurde.

Mein Vorschlag dafür wäre, die Schaffung von Arbeitsplätzen mit einer entsprechenden Veranstaltung zu scheitern. Aber ehrlich gesagt bezweifle ich, dass das so oft vorkommt. Ich werde sicherstellen, dass dies in Ihrer Implementierung @iterion hinzugefügt wird.

und Cron-Format unterstützen keine Jahresdatei, wie kann man einen Job nur einmal zu einer bestimmten Zeit ausführen?

:+1:

@iterion Danke für das Problem und die Pull-Anfrage. Wir haben in der letzten Woche viel darüber diskutiert, sowohl in SIG Apps als auch in SIG Architecture. Während die Anwendungsfälle, für die dies nützlich sein könnte, sinnvoll sein könnten, mussten wir auch die Nachteile besprechen. Beispielsweise müsste jede konforme Kubernetes-Distribution über eine Zeitzonendatenbank verfügen und diese aktuell halten. Zeitzonen, Sommerzeit und die Details, wie dies funktioniert, während sich die Details der realen Welt ändern können und sich ändern, ist hart. Dies wäre ein zusätzlicher Aufwand für die heute mehr als 20 Distributionen.

Gleichzeitig hat sich die Entwicklung von Kubernetes verschoben. Ich bin mir nicht sicher, wie weit dies kommuniziert wurde (die Kommunikation war ein weiterer Punkt, der in SIG Architecture diskutiert wurde). Die Verschiebung ist ein Wunsch, den Kern von Kubernetes auf Stabilität und Langsamkeit zu konzentrieren. Die Menschen werden jetzt ermutigt, Innovationen zu entwickeln und diese Art von Problemen eher im Ökosystem als im Kern zu lösen.

Anstatt dies in Kubernetes einzugeben, lautet die Aufforderung:

1. Entwickeln Sie dies im Ökosystem (z. B. einem Controller), den andere verwenden können. Verteilen Sie es, lösen Sie die Probleme dort und sehen Sie, wie das Update aussieht
2. Wenn die Lösung weit verbreitet ist und von jedem verwendet werden kann (einschließlich kleiner Unternehmen, Multi-Cluster usw.), könnte sie für Kern-Kubernetes in Betracht gezogen werden

Wenn es hilft, ist dies nicht die einzige Funktion, die dieselbe Richtung erhält (sogar im selben SIG Architecture-Meeting). Ich fange an, an so etwas wie WordPress zu denken (ich benutze WordPress, weil es ein sehr häufiges Beispiel ist). Es gibt einen Unterschied zwischen einem Plugin oder einem Teil von WordPress selbst. Die aktuelle Richtung ist sozusagen die Förderung von Innovationen bei Plugins.

Wenn Sie so etwas bauen, würden wir es gerne bei SIG Apps vorführen, um es den Leuten zu präsentieren. Es könnte auch beim Community-Meeting vorgeführt werden.

Bei Fragen hierzu können Sie sich gerne an mich wenden.

Angesichts des vorherigen Kommentars habe ich das Gefühl, dass wir dieses Thema schließen können. Fühlen Sie sich frei, wieder zu öffnen, wenn Sie nicht einverstanden sind.

FWIW, "wie man die Zeitzone einstellt" wird von jedem einzelnen meiner Benutzer gefragt, der einen CronJob macht (Entwickler und Admins gleichermaßen).

@iterion Was hast du dazu gemacht? Wir erwägen verschiedene Optionen für unseren Anwendungsfall, einschließlich

• mit deinem Fix aus einer Gabel von Kubernetes laufen
• Den Cron-Controller-Code in einen externen Controller kopieren und eine andere apiVersion verwenden, um die beiden zu unterscheiden.
• Erstellen Sie etwas Spezifisches für unser Projekt in Ruby, das die kube-Cronjob-Controller-Implementierung widerspiegelt, jedoch auf einer App-spezifischen Konfigurationsdatei und nicht auf CronJob-Ressourcen basiert.

Wenn Sie bereits etwas haben, das für Sie funktioniert, das wir als Ausgangspunkt verwenden könnten, oder wenn wir an etwas zusammenarbeiten könnten, das dazu dienen könnte, @mattfarina zu ermutigen, seine Entscheidung, dies nicht

Ich habe tatsächlich in einen neuen Job gewechselt, das ursprüngliche Problem existiert also für mich persönlich nicht mehr. Meine ehemaligen Kollegen haben, soweit ich weiß, nur mit den Schmerzen zu kämpfen, die daraus resultieren.

Das heißt, wenn ich die Zeit hätte, mich diesem Thema zu widmen, würde ich wahrscheinlich einfach einen kleinen Controller schreiben, der CronJobs nach Bedarf überwacht und modifiziert. Ich würde CronJobs wahrscheinlich einfach eine Anmerkung mit der gewünschten Zeit und Zeitzone hinzufügen und den Controller diesen Zeitplan in UTC umwandeln lassen und die CronJobs ändern. Sie können diese Synchronisierungsschleife einfach in einem Intervall ausführen, um die Problemkanten abzufangen, dh wenn die Sommerzeit beginnt oder endet. Auf diese Weise wäre der Controller nur ein sehr schlanker Wrapper auf der bereits vorhandenen CronJob-API.

ermutige @mattfarina , seine Entscheidung, dies nicht

Zur Verdeutlichung wurde diese Entscheidung gemeinsam während eines der sig-architecture-Meetings getroffen. Matt war nur die Person, die diese Entscheidung in dieser Ausgabe zum Ausdruck brachte.

Das Problem der Zeitzonen mit allem Drum und Dran ist in der Linux-Welt längst gelöst. Warum ist dies eine so wichtige Voraussetzung für eine Kubernetes-Bereitstellung?

Ich gebe zu, dass es schwierig ist, über die Bedeutung von Anwendungsfällen zu diskutieren. Allerdings (und meiner bescheidenen Meinung nach) scheint es mir wichtig genug, Dienste synchron mit den Benutzern der Dienste zu planen, um für Kubernetes Core in Frage zu kommen.

Wäre jemand bereit, einen Operator mit einem TimezoneAwareCronjobController zu schreiben? Der größte Teil des von @iterion geschriebenen
Das Verschieben der TZ-Behandlung in eine gepackte Anwendung würde das Verteilungsargument lösen, das die erstklassige Cronjob-Unterstützung in Kubernetes zerstört hat.

FWIW, https://gopkg.in/robfig/cron.v2 (von dem der vorhandene Controller eine ältere Untermenge verwendet), unterstützt die Übergabe von TZ und einen etwas umfangreicheren Satz an Zeitdefinitionen.
Wir haben intern einen Controller, der Cron-Jobs für einige unserer internen Workloads erstellt, und es ist eine herausragende Funktionsanforderung, für diese eine Zeitzone angeben zu können. Ich muss herausfinden, wie ich eine vorhandene Cronjob-Definition sicher aktualisieren kann, ohne Jobs versehentlich zu überspringen oder erneut auszuführen. An diesem Punkt scheint es tatsächlich einfacher zu sein, die Jobplanung vom bestehenden Controller zu stehlen und Jobdefinitionen direkt zu erstellen (anstelle von Cronjobs).

Seit ich K8s benutze, komme ich zweimal im Jahr auf diese Ausgabe zurück, wenn ich gezwungen bin, den Zeitplan für alle CronJobs zu ändern, in der Hoffnung, dass sie endlich wieder geöffnet wird. Wenn Chronos und Crontab diese Funktion haben, warum unterstützt K8s dies immer noch nicht?

Langzeit-Problem (Notiz an sich selbst)

Hoffentlich wird dieses Problem wieder geöffnet und es ist ein wenig seltsam, jeden Tag auf die UTC-Zeit zu schauen.

Ich habe einen Cronjob, der am ersten Tag jedes Monats zur Ortszeit ausgeführt werden muss, aber die UTC-Zeit ist 16:00 Uhr am letzten Tag des letzten Monats. Wie definiere ich den letzten Tag des letzten Monats? Cronjob unterstützt L nicht.

Eine alternative Lösung scheint es nicht zu geben. Siehe meine Fragen hier und hier

Für alle, die noch darauf warten; Ich habe einen Controller erstellt, der aus dem nativen Kubernetes-Cronjob-Controller und dem ursprünglichen PR, der geschlossen wurde, abgeleitet wurde.

https://github.com/hiddeco/cronjobber

Bearbeiten (2019-05-12): Dank @mterron unterstützt Cronjobber jetzt eine hostunabhängige Zeitzonendatenbank mit einem Sidecar.

@hiddeco wäre es besser, einen standardmäßigen CJ-Controller zur Steuerung zu haben, anstatt einen vorhandenen zu

@andrewsav das wäre vorzuziehen, ist aber nicht machbar. Die einzige Möglichkeit, den vorhandenen CJ-Controller zu "kontrollieren", besteht darin, den Zeitplan von CronJob auf den Versatz einer Zeitzone zu ändern. Dies ist nicht für alle möglichen Zeitplankombinationen möglich.

Ich erwarte ohnehin nicht so viele Änderungen am CJ-Controller, außerdem sind wir nicht verpflichtet, mit ihm synchron zu bleiben, um ihn am Laufen zu halten, da er in sich geschlossen ist (außer Abhängigkeiten vom Client und Job Spezifikationen). .

@hiddeco

Dies ist nicht für alle möglichen Zeitplankombinationen möglich.

Können Sie das bitte erklären?

@AndrewSav einfaches Beispiel: 0 0 1 * * das in NZDT (UTC+13) ausgeführt wird, würde bedeuten, dass Sie es jeden Monat neu berechnen müssen, da Sie am letzten Tag des Vormonats um . einlaufen müssen 11 Uhr UTC.

Wenn die Komplexität Ihres Zeitplans zunimmt, steigt auch die Anzahl der Änderungen, die Sie vornehmen müssen, um ihn synchron zu halten. Außerdem müssten Sie es jedes Mal ändern, wenn sich ein Zeitzonenbereich von DST auf ST ändert.

Dies macht es extrem komplex und eröffnet viel Platz, um es zum falschen Zeitpunkt oder vielleicht sogar noch schlimmer auszuführen; ganz und gar nicht.

Eine Lösung besteht darin, je nach Zeitzone zu jeder "möglichen" Stunde einen Cron auszuführen und ihn zu überspringen, wenn die aktuelle Uhrzeit nicht die erwartete ist. Ich wünschte, ich könnte es auf Kubernetes-Ebene tun.

Für die Sommerzeit bedeutet dies, dass sie zweimal täglich statt einmal ausgeführt wird und je nach Sommerzeit die erste oder die zweite überspringt.

Beispielsweise müsste jede konforme Kubernetes-Distribution über eine Zeitzonendatenbank verfügen und diese aktuell halten. Zeitzonen, Sommerzeit und die Details, wie dies funktioniert, während sich die Details der realen Welt ändern können und sich ändern, ist hart. Dies wäre ein zusätzlicher Aufwand für die heute mehr als 20 Distributionen.

Zeitzonendatenbanken, DSTs, werden von OS-Distributionen sehr gut gepflegt, auf die sich Kubernetes-Distributionen verlassen sollten. Die Ausrede "es ist harte Arbeit für die Verteilungen" ist IMO nicht gültig.

Ich würde nicht argumentieren, wenn das Konzept PeriodicJob oder RepeatingJob . Stattdessen heißt es CronJob . Es ist mit Kalender und Uhr verbunden. Es ist nicht zu leugnen, dass die Kenntnis der Zeitzone hierfür eine entscheidende Voraussetzung ist.

Eine andere Lösung; Vielleicht kann das Problem gelöst werden, indem CronJob vollständig aus Kubernetes entfernt wird. Nicht, dass es irgendjemandem helfen würde.

Eine andere Lösung; Vielleicht kann das Problem gelöst werden, indem CronJob vollständig aus Kubernetes entfernt wird. Nicht, dass es irgendjemandem helfen würde.

Zugegeben, wenn sie keine richtige Lösung in k8s implementieren können, sollten sie die Lösung überhaupt nicht hinzufügen. Cronjobs sind so konzipiert, dass sie mit Zeitzonen arbeiten, auch alle heutigen Betriebssysteme handhaben Zeitzonen transparent mit den zugehörigen Betriebssystemfunktionen.

Die Argumentation scheint nicht schlüssig zu sein. Wenn wir dieser Logik folgen, sollten viele Funktionen in K8s vorhanden sein, die nicht vorhanden sein sollten.

Dies ist in der Tat ein Fehler. Der Name Cronjob selbst ist irreführend, da er nicht der Cron-Spezifikation entspricht. Die meisten Kubernetes-Benutzer werden davon ausgehen, dass die Zeitzonenunterstützung sofort einsatzbereit ist. Es ist enttäuschend, dass die Kernentwickler sich entschieden haben, dies nicht aufzunehmen. Dieses Problem sollte > 90 % der Benutzer betreffen, die nicht nach UTC-Zeit arbeiten.

Ich würde dringend bitten, dies noch einmal zu überprüfen. Ein Problem, das ich habe, ist, dass ich möchte, dass bestimmte Jobs in Japan am ersten des Monats um 1 Uhr morgens ausgeführt werden - sicherlich ein vernünftiger / normaler Anwendungsfall. Da cron in UTC definiert ist, kann ich dies nicht angeben. 0 0 1 * * läuft um 9 Uhr japanischer Zeit. (Es wäre auch schön, 0 0 L * * für den letzten Tag des Monats hinzuzufügen, was in einigen Cron-Implementierungen verwendet wird)

@johnnyshields sollten Sie wahrscheinlich fragen @soltysh wieder zu öffnen.

Obwohl ich es lieben würde, dies noch einmal zu überdenken, denke ich, dass die Chancen gering sind. Das Team hat sich zusammengetan, diskutiert und entschieden, dass dies zu viel zusätzliche Arbeit bedeuten würde. Daran hat sich seither nichts geändert, daher hat sich die Entscheidung wahrscheinlich auch nicht geändert.

Schauen Sie sich einfach CronJobber https://github.com/hiddeco/cronjobber an (und tragen Sie dazu bei!)

Eine auf der neuesten Version des CronJob-Controllers basierende PR wäre großartig, funktioniert aber so wie sie ist perfekt.

Obwohl ich es lieben würde, dies noch einmal zu überdenken, denke ich, dass die Chancen gering sind. Das Team hat sich zusammengetan, diskutiert und entschieden, dass dies zu viel zusätzliche Arbeit bedeuten würde. Daran hat sich seither nichts geändert, daher hat sich die Entscheidung wahrscheinlich auch nicht geändert.

Sie sollten dann zumindest konsistent sein und die aktuelle Implementierung von Cronjob entfernen, da diese (um es gelinde auszudrücken) sehr irreführend ist.

@mterron Das Problem mit diesem ist, dass es fast vor einem Jahr gepatcht wurde und seitdem nicht mehr aktualisiert wurde. In der Zwischenzeit hatten wir ein Dutzend Point-Releases von Kubernetes mit Verbesserungen und Sicherheitsfixes. Man kann also nicht sicher sein, den veralteten Contorller zu betreiben, um die neuesten Änderungen und Funktionen von Kubernetes in diesem Bereich zu nutzen.

@AndrewSav und deshalb habe ich um Hilfe gebeten. Ich habe alles getan, was ich konnte. Ich bin mir jedoch nicht sicher, ob es ein Sicherheitsrisiko gibt, Kubernetes ändert sich ständig, aber das bedeutet nicht, dass die Änderung im Sinne der Sicherheit sinnvoll ist.

Trotzdem wäre ein Rebase cool, zögere nicht, einen Beitrag zu leisten und dabei zu helfen.

@mterron du bist der Autor davon, oder? Da selbst Sie dafür keine Zeit finden, ist es unwahrscheinlich, dass Menschen zu etwas beitragen, das nicht mehr aktiv ist. Wäre aber sehr nett, da stimme ich zu. Als dieses Projekt zum ersten Mal vorangetrieben wurde, habe ich kurz überlegt, ob ich es aufs Spiel setzen und es in meine Cluster legen sollte, und dann dachte ich, dass die Chancen, dass es beibehalten wird, nicht groß sind. Jetzt, ein Jahr später, sehe ich, dass ich mich nicht geirrt habe. Ich danke Ihnen für Ihre Arbeit, aber ich fürchte, in der jetzigen Form ist sie nicht nachhaltig.

Wenn es jedoch abhebt und jemand es konsequent umbaut und pflegt, wäre das einfach wunderbar.

Nein, ich bin nicht der Autor. Ich bin nur ein Benutzer, der zu Projekten beiträgt, die ich benutze, wenn ich kann.
Ich verstehe, woher Sie kommen, aber ich denke, Ihre Erwartungen sind etwas hoch für etwas, das Menschen in ihrer Freizeit zum Wohle der Gemeinschaft tun.

@mterron Ich denke, ich bin auf dem Niveau meiner Erwartungen. Wenn überhaupt, sind sie niedrig. Das ist der Hauptgrund, warum ich darauf verzichtet habe, die verlinkten Arbeiten in meinen Clustern zu verwenden.

@AndrewSav Sie sollten einen Unterschied zwischen Cronjobber und dem vorgeschalteten Cronjob-Controller machen. Beim letzten Mal (1.17) gab es keinen Unterschied. Der vorgelagerte Cronjob-Controller wird nach Ihrer Definition effektiv nicht gewartet.

Auch der vorgeschaltete Controller hat grauenhafte Leistungsmerkmale, die natürlich Cronjobber erbt.

@benlangfeld

Sie sollten einen Unterschied zwischen Cronjobber und dem vorgeschalteten Cronjob-Controller machen

Es geht nicht so sehr um mich, sondern darum, nachhaltig für den allgemeinen Gebrauch zu sein. Es ist kaum vernünftig, jeden potenziellen Benutzer aufzufordern, einen Unterschied zu machen. Auch wenn es Fakt ist, dass es keine Veränderungen gab, auf die ich weiter unten eingehen möchte.

Der vorgelagerte Cronjob-Controller wird nach Ihrer Definition effektiv nicht gewartet.

Dies ist keine faire Interpretation dessen, was ich gesagt habe.

Apropos Diffs: Wovon differenzierst du dich? Dieses Repository enthält über 50 Dateien, und nicht alle Namen stimmen mit denen aus den Kubernetes-Quellen überein. Können Sie erklären, wie wir uns davon überzeugen können, dass es keine Änderungen gab? Am besten etwas ausführlicher als in Ihrem vorherigen Kommentar, da es nicht offensichtlich ist. Insbesondere, welche Dateien auf welchen Branches/Commits auf jeder Seite haben Sie verglichen und keine Änderungen festgestellt?

Angesichts der intensiven Beteiligung an dieser Ausgabe halte ich es für angemessen, eine erneute Prüfung eines Kubernetes-Kernfeatures zu beantragen.

Ich finde die obige Aussage oben wichtig: „Wenn die Lösung weit verbreitet ist und von jedem verwendet werden kann (einschließlich kleiner Maßstab, Multi-Cluster usw.), könnte sie für Kern-Kubernetes in Betracht gezogen werden“. Es scheint Lösungen zu geben, vielleicht noch nicht ganz fertig. Eine Erklärung des Kernteams, dass der Anwendungsfall als für den K8-Kern geeignet anerkannt wird, wäre also ein großartiges Signal an die Entwickler dieser Lösungen, um sie für einen Pull-Request bereit zu machen.

@AndrewSav als Autor des 'Fork' muss ich allem, was Sie bisher gesagt haben, respektvoll widersprechen, und als Betreuer mehrerer OSS-Projekte bin ich von Ihrer Einstellung überrascht.

Erstens wurde cronjobber einfach vom Kubernetes CronJob-Controller abgeleitet, weil es die einfachste Lösung war und am wenigsten Zeit für eine ausgereifte (und bewährte) Lösung benötigte. Aus den unten genannten Gründen habe ich nicht erwartet, dass sich der Upstream viel ändert (und hat es auch nicht).

Zweitens ist das Spawnen des Jobs X zum Zeitpunkt Y unter Berücksichtigung der Zeitzone Z kein Hexenwerk, die Spezifikation für das Konzept Zeit hat sich seit Jahren nicht geändert und sollte Es ist keine weitere Wartung erforderlich, außer sicherzustellen, dass weiterhin native Kubernetes-Jobs zur richtigen Zeit erzeugt werden können (und die Zeitzonendatenbanken sind auf dem neuesten Stand, für die es dank @mterron einen Helfer gibt).

Solange es in der Lage ist, diese Jobs hervorzubringen, zu denen es beim letzten Mal, als ich es überprüft habe, vollkommen in der Lage ist, ist meine Zeit besser woanders verbracht. Wenn dies nicht Ihren Anforderungen entspricht, würde ich vorschlagen, jemanden zu beauftragen, der eine ähnliche Lösung für Sie schreibt und pflegt.

@hiddeco

Ich muss allem, was Sie bisher gesagt haben, respektvoll widersprechen

Irgendetwas? Das ist eine starke Aussage.

Aus den unten genannten Gründen habe ich nicht erwartet, dass sich der Upstream viel ändert (und hat es auch nicht).

Es kann sich nicht _viel_ ändern, aber es wird auch nicht statisch bleiben. Das Kubernetes-Team erklärte, dass es eine "weit verbreitete" Lösung wünsche, bevor sie "für Kern-Kubernetes in Betracht gezogen werden könnte". Meiner Erfahrung nach werden Lösungen, die nicht aktiv gepflegt werden (seit fast einem Jahr keine Änderungen), selten "weit verbreitet". Außerdem konnte bisher niemand belegen, dass sich der Kubernetes CronJob Controller und seine Abhängigkeiten überhaupt nicht verändert haben. Ich persönlich kann keine gute Möglichkeit finden, alle betroffenen Dateien und alle zugrunde liegenden Abhängigkeiten zu vergleichen.

Zweitens ist es kein Hexenwerk, Job X zum Zeitpunkt Y zu erzeugen, während die Zeitzone Z berücksichtigt wird die richtige Zeit (und die Zeitzonendatenbanken sind aktuell, wofür es dank @mterron einen Helfer gibt).

Das klingt für mich zu optimistisch. Hier geht es selten um "Spezifikations"-Änderungen. Es sind kleine Dinge, die dich töten. Fehler werden auch in "ausgereiften und bewährten" Projekten ständig gefunden und behoben. Einen Job hervorzubringen ist vielleicht kein Hexenwerk, aber herauszufinden, wie sich verwandte Änderungen in der Kubernetes-Codebasis auf Ihre Änderungen auswirken, kann schnell knifflig werden. Im letzten Jahr wurde beispielsweise versucht, die Client-API (kubectl) in das Staging zu verschieben. Betrifft es Cron Jobber? Ich weiß nicht. Die verwendete Cron-Bibliotheksversion wurde Upstream aktualisiert. Betrifft es Cron Jobber? Wieder weiß ich es nicht.

Solange es in der Lage ist, diese Jobs hervorzubringen, zu denen es beim letzten Mal, als ich es überprüft habe, vollkommen in der Lage ist, ist meine Zeit besser woanders verbracht.

Und das ist in Ordnung. Du hast schon mehr getan, als du musstest. Sie haben die PR zusammengeführt und Ihre Arbeit für jedermann veröffentlicht. Danke schön.

Wenn dies nicht Ihren Anforderungen entspricht, würde ich vorschlagen, jemanden zu beauftragen, der eine ähnliche Lösung für Sie schreibt und pflegt.

Auch hier geht es nicht um mich, wie ich oben in einem Kommentar erklärt habe. Es geht darum, für eine breitere Klasse von Menschen nützlich zu sein. Es scheint, als ob ich mich jetzt wiederhole. Vielleicht war alles zu dem Thema schon gesagt? Was denkst du?

Das klingt für mich zu optimistisch. Hier geht es selten um "Spezifikations"-Änderungen. Es sind kleine Dinge, die dich töten. Fehler werden auch in "ausgereiften und bewährten" Projekten ständig gefunden und behoben. Einen Job hervorzubringen ist vielleicht kein Hexenwerk, aber herauszufinden, wie sich verwandte Änderungen in der Kubernetes-Codebasis auf Ihre Änderungen auswirken, kann schnell knifflig werden. Im letzten Jahr wurde beispielsweise versucht, die Client-API (kubectl) in das Staging zu verschieben. Betrifft es Cron Jobber? Ich weiß nicht. Die verwendete Cron-Bibliotheksversion wurde Upstream aktualisiert. Betrifft es Cron Jobber? Wieder weiß ich es nicht.

Ehrlich gesagt kommt mir das als Whatabouttism vor, das zu Obstruktionismus führt. Diese Logik kann verwendet werden, um gegen alles zu argumentieren, daher habe ich keine Ahnung, was Sie hier erreichen möchten. Es ist nicht wirklich komplex, zeitzonenbewusste Cronjobs auszuführen. Jedes Mainstream-*nix-System (auf dem k8 läuft) hat seit Jahrzehnten eine grundsolide Zeitzonenunterstützung (zur Überraschung, *nix-Systeme laufen seit über 40 Jahren überwiegend in Serverumgebungen, die ähnliche Bedenken haben).

Auch hier geht es nicht um mich, wie ich oben in einem Kommentar erklärt habe. Es geht darum, für eine breitere Klasse von Menschen nützlich zu sein. Es scheint, als ob ich mich jetzt wiederhole. Vielleicht war alles zu dem Thema schon gesagt? Was denkst du?

Und wie ad-neuseam gesagt wurde, ist die aktuelle Implementierung fast nutzlos, da sie die Zeitzone vollständig ignoriert, während die zeitzonenbewusste Implementierung für eine breitere Gruppe von Menschen viel nützlicher ist. Was ist Ihr Punkt hier?

Diese Logik kann verwendet werden, um gegen alles zu argumentieren

Ich glaube nicht, dass es möglich ist. Sie können es gerne demonstrieren, wenn Sie möchten, aber bitte halten Sie sich an das Gesagte, nicht an das, was impliziert werden könnte.

also ich habe keine ahnung was du hier erreichen willst.

Oh, ich beantworte nur den an mich gerichteten Kommentar von hiddeco, den Sie oben finden können.

Und wie ad-neuseam gesagt wurde, ist die aktuelle Implementierung fast nutzlos, da sie die Zeitzone vollständig ignoriert, während die zeitzonenbewusste Implementierung für eine breitere Gruppe von Menschen viel nützlicher ist

Wenn wir das umformulieren, um zu sagen, dass Sie und ich eine Präferenz dafür haben, dass kubernetes cronjob Zeitzonen unterstützt, wäre das richtig. Ich finde "nahezu nutzlos" ein bisschen zu stark, aber ich stimme voll und ganz zu, dass eine unterstützte zeitzonenbewusste Implementierung mir nützlicher wäre.

was ist dein Punkt hier?

Der Punkt ist, dass es keine Beweise dafür gibt, dass die von uns diskutierte "Gabel" "weit verbreitet" ist und es daher unwahrscheinlich ist, dass das kubernetes-Team sie an Bord nimmt, was wirklich schade ist, denn das würde ich gerne tun siehe in Kubernetes integriert.

Fehler werden auch in "ausgereiften und bewährten" Projekten ständig gefunden und behoben.

Erstens haben "reife" und "bewährte" Wörter keinen Platz in einem Satz über Kubernetes oder sein Ökosystem.

Zweitens, seit wann sind Fehler in Kubernetes ein Problem? @fejta-bot "repariert" (schließt) sie einfach automatisch. Sie müssen nicht an Fehler denken. Alles ist gut.

Ich frage mich, wann/ob sich ein Betreuer darum kümmert/kommentiert?

Ich denke das sollte unter https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron -job-limitations dokumentiert werden

Ich stimme zu, dass " Cronjobs " auf Kubernetes Zeitzonenunterstützung haben sollten, da Kubernetes-Cluster unter Linux laufen, das dies bietet. Lehnen wir diese Vorstellung ab, weil einige Parteien Pläne haben, Kubernetes (oder eine Variante) unter Windows in ferner Zukunft auszuführen? Ziemlich schwacher Grund, dieses Problem abzulehnen, wenn dies der Fall ist. Können wir bitte zumindest das Tag "triage/unresolved" hinzufügen, um dies von gelösten Problemen zu unterscheiden?

Wenn die Entscheidung lautet, dass Core-K8s nicht auf diese Funktionalität erweitert werden sollten, stimme ich dem obigen Kommentar zu, dass die Cronjob-Unterstützung entfernt werden sollte, damit die Leute ermutigt werden, eine Ökosystemlösung nach Belieben zu übernehmen. Dies sticht wirklich als etwas in Core-K8s heraus, das das beabsichtigte Ergebnis nicht explizit ausdrückt und die Leute aus der Fassung bringt.

Da Go 1.15 jetzt ein time/tzdata Paket in seiner Kernbibliothek hat, möglicherweise …?

Wie soll ich meinen Cluster von 7 Uhr morgens bis 7 Uhr abends überbestücken?
Wo meine Nutzer sind, gibt es Sommer- und Winterzeit.
Darauf kann ich mich also überhaupt nicht verlassen.

Die Zeitzone NICHT mit Cronjobs zu verwalten, war eine sehr seltsame Entscheidung, die Sie getroffen haben.

Wir haben eine gute Problemumgehung für dieses Problem gefunden: Verwenden Sie K8s CronJobs nicht mehr und verwenden Sie stattdessen Apache Airflow.

Das Leben ist seitdem viel besser geworden. Begleiten Sie uns!

Dieses Problem wird dort extern gelöst: https://github.com/hiddeco/cronjobber

@mattfarina

1. Wenn die Lösung weit verbreitet ist und von jedem verwendet werden kann (einschließlich kleiner Unternehmen, Multi-Cluster usw.), könnte sie für Kern-Kubernetes in Betracht gezogen werden

Wie und wann wird die Akzeptanz der Community-Lösung gemessen?

https://github.com/kubernetes/enhancements/pull/1996

@mattfarina @soltysh jetzt mit KEP-19: Absolvent CronJob to stable , in dem die Zeitzone als eine der zu berücksichtigenden Verbesserungen erwähnt wird, wurde genehmigt und zusammengeführt und die Arbeit am Cronjob-Controller v2 ist in Bearbeitung. Kann dieses Problem erneut geöffnet und überdacht werden?

Er erwähnt dies als Überlegung/mögliche Verbesserung. Es garantiert nicht, ob und wann dies in Angriff genommen wird. Ich kann mit 100%iger Garantie sagen, dass es nicht vor CronJob GA passieren wird, das diese und weitere 2 Veröffentlichungen dauern wird.

@soltysh Es kann immer noch richtig diskutiert werden. Es ist weithin gezeigt worden, dass dies ein notwendiges Merkmal ist. Das Beharren darauf, den Ball auf die Straße zu kicken, zeigt eine enorme Kluft zwischen den Betreuern und den Benutzern.

@benlangfeld Ich bin sehr offen dafür, aber die Zeit ist hier der limitierende Faktor :enttäuscht:

@benlangfeld Dafür bin ich sehr offen, aber die Zeit ist hier der limitierende Faktor 😞

Es gibt bereits einen Lösungsvorschlag. Welche Eingaben benötigen Sie, damit dies akzeptiert wird?

Der Controller wird neu geschrieben, das ist derzeit der Hauptfokus. Der Wechsel ist nur mit dem neuen Controller möglich. Es ist sinnlos, das alte auszutauschen, das ersetzt werden soll.