Kubernetes: CronJobs должен поддерживать часовые пояса

@iterion По этому вопросу нет добавьте подпись :
(1) упоминание сигнатуры: @kubernetes/sig-<team-name>-misc
(2) указание метки вручную: /sig <label>

_Примечание: метод (1) вызовет уведомление для команды. Вы можете найти список команд здесь и список ярлыков здесь _

/ sig приложения

Предпочитаю второй вариант, так как мне он кажется более естественным

@soltysh @ kubernetes / sig-приложения-особенности-запросы

Мне также нравится вторая форма, но кажется, что проще всего реализовать это время и использовать его отдельно. Кроме того, можно привести аргумент, что, поскольку мы используем «стандартный» шаблон cron, мы не должны с ним связываться.

Похоже, это должно быть просто реализовать:
В настоящее время мы просто передаем time.Now () в цикл syncOne . Библиотека cron, которую использует k8s, похоже, работает, просто используя время в интересующей вас зоне. Итак, мы можем извлечь часовой пояс из CronJob и передать это время с помощью zone в функцию syncOne.

//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)

Кроме того, я счастлив попробовать это реализовать.

Я не тот человек, который проверяет ваш PR, но у меня есть несколько вопросов по семантике.

• Какова семантика, когда часовой пояс не указан?
• Зависит ли реализация от правильной настройки часового пояса на хосте контроллера?
• Когда мы проверяем законность часового пояса? Во время создания / обновления объекта или позже?
• Что произойдет, если имя часового пояса было допустимым, когда объект API был создан, но в будущем больше не существует? Это могло произойти из-за того, что имя было удалено (возможно, город или страна перестали существовать), или из-за того, что базовый пакет tzdata был изменен на более старую версию.

Если часовой пояс не определен, по умолчанию будет использоваться текущее поведение, которое будет использовать часовой пояс хоста. Я предполагаю, что в большинстве случаев это будет настроено как UTC, но пользователь действительно может выбрать любой часовой пояс. Таким образом, нет большей зависимости от правильной настройки часового пояса на хосте в результате этого PR.

В настоящее время я просто выхожу и использую часовой пояс хоста, если пользователь указал что-то недопустимое. Здесь я опираюсь на метод golang time.LoadLocation (str) . Любая строка, принятая этой функцией, будет считаться действительной. В настоящее время я не проверяю это при создании / обновлении, хотя кажется, что это было бы довольно легко сделать.

Что касается последнего вопроса, он немного более неопределенный. В настоящее время и, вероятно, в будущем он, скорее всего, вернется к планированию задания на основе часового пояса по умолчанию. Я открыт для предложений о том, как поступить в этом случае.

Что произойдет, если имя часового пояса было допустимым, когда объект API был создан, но в будущем больше не существует? Это могло произойти из-за того, что имя было удалено (возможно, город или страна перестали существовать), или из-за того, что базовый пакет tzdata был изменен на более старую версию.

Я предлагаю не создавать рабочие места с помощью соответствующего события. Но, честно говоря, я сомневаюсь, что такое случается так часто. Я обязательно добавлю это в вашу реализацию @iterion.

и формат cron не поддерживает год подачи, как запустить задание только один раз в указанное время?

: +1:

@iterion Спасибо за вопрос и запрос на

В то же время произошел сдвиг в развитии Kubernetes. Я не уверен, насколько широко это было распространено (коммуникация была еще одним вопросом, обсуждаемым в SIG Architecture). Сдвиг - это желание сосредоточить основное внимание Kubernetes на стабильности и медлительности. Людей теперь поощряют вводить новшества и решать подобные проблемы в экосистеме, а не в ядре.

Вместо того, чтобы помещать это в Kubernetes, попросите:

1. Разработайте это в экосистеме (например, в контроллере), чтобы другие могли использовать. Распространите его, решите там проблемы и посмотрите, как выглядит обновление
2. Если решение широко применяется и может использоваться кем угодно (в том числе в небольших масштабах, с несколькими кластерами и т. Д.), То его можно рассматривать для ядра Kubernetes.

Если это помогает, то это не единственные функции, получившие то же направление (даже на том же собрании SIG Architecture). Я начинаю думать об этом в том же ключе, что и wordpress (я использую wordpress, потому что это очень распространенный пример). Есть разница между плагином или частью WordPress. Текущее направление - так сказать, поощрять инновации в плагинах.

Если вы создадите что-то подобное, мы хотели бы продемонстрировать это на сайте SIG Apps, чтобы продемонстрировать это людям. Его также можно было продемонстрировать на собрании сообщества.

Если у вас есть вопросы по этому поводу, не стесняйтесь обращаться ко мне.

Учитывая предыдущий комментарий, я чувствую, что мы можем закрыть эту проблему. Не стесняйтесь открывать снова, если не согласны.

FWIW, «как установить часовой пояс», спрашивает каждый из моих пользователей, которые создают CronJob (как разработчики, так и администраторы).

@iterion Что вы в итоге сделали с этим? Мы рассматриваем различные варианты нашего сценария использования, в том числе

• бегу от вилки кубернетов с вашим исправлением
• Копирование кода контроллера cron на внешний контроллер и использование другого apiVersion для их различения.
• Создание чего-то особенного для нашего проекта на Ruby, который отражает реализацию контроллера kube cronjob, но на основе файла конфигурации для конкретного приложения, а не ресурсов CronJob.

Если у вас уже есть что-то, что работает для вас, что мы могли бы использовать в качестве отправной точки, или если бы мы могли сотрудничать в чем-то, что могло бы побудить @mattfarina отменить свое решение не разрешать включение этого (что резко вредит принятию этого куба особенность), это было бы здорово.

Я фактически перешел на новую работу, поэтому лично для меня первоначальной проблемы больше не существует. Насколько мне известно, мои бывшие коллеги просто справляются с болью, которая от этого возникает.

Тем не менее, если бы у меня было время посвятить это этому, я бы, вероятно, просто написал небольшой контроллер, который будет отслеживать и изменять CronJobs по мере необходимости. Скорее всего, я просто добавлю аннотацию к CronJobs с желаемым временем и часовым поясом, а контроллер переведет это расписание в UTC и изменит CronJobs. Вы можете просто запускать этот цикл синхронизации с определенным интервалом, чтобы выявить края проблемы, например, когда начинается или заканчивается переход на летнее время. Таким образом, контроллер будет просто очень тонкой оболочкой поверх уже существующего CronJob API.

призвать @mattfarina отменить свое решение не разрешать включение этого

Чтобы было понятно, это решение было принято коллективно во время одной из встреч по подписной архитектуре. Мэтт был единственным человеком, выразившим это решение в этом вопросе.

Проблема часовых поясов со всеми наворотами давно решена в мире Linux. Почему это необходимое условие для развертывания Kubernetes?

Я признаю, что трудно обсуждать важность вариантов использования. Однако (и по моему скромному мнению) возможность планировать службы синхронно с пользователями служб кажется мне достаточно важной, чтобы иметь право на ядро ​​Kubernetes.

Кто-нибудь захочет написать оператор с TimezoneAwareCronjobController? Большая часть кода, написанного @iterion, вероятно, может быть переработана.
Перенос обработки TZ в пакетное приложение решит проблему распределения, которая убила первоклассную поддержку cronjob в Kubernetes.

FWIW, https://gopkg.in/robfig/cron.v2 (который существующий контроллер использует более старое подмножество), поддерживает передачу в TZ и немного более богатый набор определений времени.
У нас есть внутренний контроллер, который создает задания cron для некоторых из наших внутренних рабочих нагрузок, и это отличный запрос функции, позволяющий указать для них часовой пояс. Мне нужно решить, как безопасно обновить существующее определение cronjob без случайного пропуска или повторного запуска заданий. На этом этапе кажется, что на самом деле может быть проще украсть планирование заданий из существующего контроллера и напрямую создавать определения заданий (а не cronjobs).

С тех пор, как я начал использовать K8s, я возвращаюсь к этому вопросу дважды в год, когда мне приходится менять расписание для всех CronJobs, надеясь, что оно наконец будет возобновлено. Если у chronos и crontab есть эта функция, почему K8s все еще не поддерживает ее?

долгосрочная проблема (примечание для себя)

Надеюсь, эта проблема будет вновь открыта, и немного странно смотреть на время в формате UTC каждый день.

У меня есть cronjob, который нужно запускать в первый день каждого месяца по местному времени, но время UTC - 16:00 в последний день прошлого месяца. Как определить последний день прошлого месяца? Cronjob не поддерживает L.

Похоже, альтернативного решения не существует. Смотрите мои вопросы здесь и здесь

Для тех, кто все еще ждет этого; Я создал контроллер, производный от встроенного контроллера cronjob Kubernetes и исходного PR, который был закрыт.

https://github.com/hiddeco/cronjobber

Изменить (2019-05-12): благодаря @mterron , Cronjobber теперь поддерживает независимую от хоста базу данных часовых сопутствующего символа.

@hiddeco Было бы лучше иметь стандартный контроллер CJ, управляющий контроллером, вместо того, чтобы изменять существующий? При последнем подходе нужно идти в ногу с фактическими изменениями контроллера CJ, что не всегда возможно. Спасибо вам за вашу работу.

@andrewsav, что было бы предпочтительнее, но невыполнимо. Единственный способ «контролировать» существующий контроллер CJ - это изменить расписание CronJob со смещением часового пояса. Невозможно сделать это для всех возможных комбинаций расписания.

Я не ожидаю, что в контроллере CJ все равно будет много изменений, плюс мы не обязаны синхронизироваться с ним, чтобы он работал, поскольку он самодостаточен (за исключением зависимостей от клиента и спецификаций Job ) .

@hiddeco

Невозможно сделать это для всех возможных комбинаций расписания.

Вы можете объяснить это, пожалуйста?

@AndrewSav простой пример: 0 0 1 * * запущенный в NZDT (UTC + 13), будет означать, что вам нужно будет пересчитывать его каждый месяц, потому что вам нужно будет запускать в последний день предыдущего месяца в 11:00 по всемирному координированному времени.

Если сложность вашего расписания возрастает, количество изменений, которые вам необходимо внести, чтобы поддерживать его синхронизацию, также возрастает. Кроме того, вам нужно будет менять его каждый раз, когда область часового пояса меняется с DST на ST.

Это делает его чрезвычайно сложным и открывает много места для запуска в неподходящее время или, может быть, даже хуже; нисколько.

Решение состоит в том, чтобы запускать cron каждый «возможный» час в зависимости от вашего часового пояса и пропускать его, если текущее время не является ожидаемым. Хотя я бы хотел сделать это на уровне кубернетов.

Для летнего времени это означает, что он будет запускаться дважды в день, а не один раз, и пропускать первый или второй в зависимости от летнего времени.

Например, каждый совместимый дистрибутив Kubernetes должен иметь базу данных часовых поясов и поддерживать ее в актуальном состоянии. Часовые пояса, переход на летнее время и детали выполнения этой работы, в то время как детали реального мира могут и меняются, сложно. Это будет дополнительная работа для более чем 20 существующих сегодня дистрибутивов.

Базы данных часовых поясов, DST, очень хорошо поддерживаются дистрибутивами ОС, на которые должны полагаться дистрибутивы Kubernetes. Оправдание "это тяжелая работа для дистрибутивов" неверно, ИМО.

Я бы не стал спорить, если бы эта концепция называлась PeriodicJob или RepeatingJob . Но вместо этого он называется CronJob . Он привязан к календарю и часам. Нельзя отрицать, что знание часового пояса является критически важным требованием для этого.

Другое решение; возможно проблему удастся решить, полностью удалив CronJob из кубернетов. Не то чтобы это кому-то помогло.

Другое решение; возможно проблему удастся решить, полностью удалив CronJob из кубернетов. Не то чтобы это кому-то помогло.

Согласны, если они не могут реализовать правильное решение в k8s, они не должны добавлять решение вообще. Cronjob разработан для работы с часовыми поясами, а также все современные ОС прозрачно обрабатывают часовые пояса с соответствующими функциями ОС.

Рассуждения не кажутся последовательными, если мы собираемся следовать этой логике, тогда в K8s должно быть много функций, которых не должно быть.

Это действительно ошибка. Само имя Cronjob вводит в заблуждение, поскольку не соответствует спецификации Cron. Большинство пользователей kubernetes предполагают, что поддержка часовых поясов идет из коробки. Очень досадно, что основные разработчики предпочли не включать это. Эта проблема должна затронуть> 90% пользователей, которые не работают по времени UTC.

Я настоятельно рекомендую вернуться к этому. Одна из проблем, с которыми я сталкиваюсь, заключается в том, что я хочу, чтобы определенные задания выполнялись в 1 час ночи первого числа месяца в Японии, что, безусловно, является разумным / стандартным вариантом использования. Учитывая, что cron определен в UTC, у меня нет возможности указать это; 0 0 1 * * будет запущен в 9 утра по японскому времени. (Также было бы неплохо добавить 0 0 L * * для последнего дня месяца, который используется в некоторых реализациях cron)

@johnnyshields, вам, вероятно, следует попросить @soltysh снова открыть.

Хотя я бы хотел, чтобы это было пересмотрено, я думаю, что шансы невелики. Команда собралась, обсудила это и решила, что это потребует слишком много дополнительной работы. С тех пор это не изменилось, поэтому решение вряд ли изменилось.

Просто взгляните (и внесите свой вклад!) В CronJobber https://github.com/hiddeco/cronjobber. Он делает то, что хочет каждый.

PR перебазирован на последнюю версию контроллера CronJob было бы здорово, но он и так работает отлично.

Хотя я бы хотел, чтобы это было пересмотрено, я думаю, что шансы невелики. Команда собралась, обсудила это и решила, что это потребует слишком много дополнительной работы. С тех пор это не изменилось, поэтому решение вряд ли изменилось.

Тогда они должны по крайней мере быть последовательными и удалить текущую реализацию cronjob, потому что это очень вводит в заблуждение (мягко говоря).

@mterron проблема в том, что он исправлялся почти год за раз и с тех пор не обновлялся, в то время как у нас была дюжина точечных выпусков кубернетов с улучшениями и исправлениями безопасности. Таким образом, нельзя быть уверенным, запустив устаревший контроллер, что они получают все преимущества всех последних изменений и функций кубернетов в этой области.

@AndrewSav, и поэтому я просил помочь с этим. Я сделал все, что мог. Я не уверен, что в этом есть какая-то угроза безопасности, Kubernetes постоянно меняется, но это не означает, что это изменение имеет значение с точки зрения безопасности.

Сказав это, перебазирование было бы круто, не стесняйтесь вносить свой вклад и помогать с этим.

@mterron, ты же автор той, не так ли? Поэтому, учитывая, что даже у вас нет времени на это, маловероятно, что люди будут вносить свой вклад в то, что больше не активно. Хотя было бы очень хорошо, согласен. Когда этот проект был впервые запущен, я вкратце подумал, поставлю ли я на него ставку и помещу его в свои кластеры, а затем подумал, что шансы на его поддержку невелики. Теперь, год спустя, я вижу, что не ошибался. Так что я благодарю вас за вашу работу, но, боюсь, в нынешней форме она не является устойчивой.

Если бы он взлетел, и кто-то постоянно обновлял и поддерживал его, это было бы просто замечательно.

Нет, я не автор. Я просто пользователь, который участвует в проектах, которые я использую, когда могу.
Я понимаю, откуда вы пришли, но я думаю, что ваши ожидания немного завышены в отношении того, что люди делают в свое свободное время на благо сообщества.

@mterron Я думаю, что оправдал свои ожидания. Во всяком случае, они низкие. Это основная причина, по которой я воздержался от использования связанных работ в своих кластерах.

@AndrewSav, вы должны сделать разницу между cronjobber и вышестоящим контроллером cronjob. В прошлый раз (1.17) разницы не было. Вышестоящий контроллер cronjob фактически не поддерживается вашим определением.

У вышестоящего контроллера также ужасающие характеристики производительности, которые, конечно же, наследует cronjobber.

@benlangfeld

вы должны сделать разницу между cronjobber и вышестоящим контроллером cronjob

Дело не столько во мне, сколько в том, чтобы он был устойчивым для общего использования. Вряд ли разумно просить каждого потенциального пользователя сделать разницу. Даже если это факт, что никаких изменений не было, я бы хотел подробнее изучить их ниже.

Вышестоящий контроллер cronjob фактически не поддерживается вашим определением.

Это неверная интерпретация того, что я сказал.

По поводу различий: с чем вы не согласны? В этом репо более 50 файлов, и не все имена соответствуют имени из исходников kubernetes. Вы можете объяснить, как мы можем убедить себя, что изменений не было? Желательно немного подробнее, чем в вашем предыдущем комментарии, поскольку это не очевидно. В частности, какие файлы, в каких ветвях / коммитах с каждой стороны вы сравнивали и не обнаружили никаких изменений?

Учитывая активное участие в этом вопросе, я считаю справедливым запросить пересмотр основной функции Kubernetes.

Я считаю важным следующее утверждение, приведенное выше: «Если решение широко применяется и может использоваться всеми (в том числе в небольших масштабах, с несколькими кластерами и т. Д.), То его можно рассмотреть для ядра Kubernetes». Кажется, есть решения, возможно, еще не полностью готовые. Таким образом, заявление основной группы о том, что вариант использования признан подходящим для ядра K8s, будет отличным сигналом для разработчиков этих решений, чтобы они были готовы к запросу на вытягивание.

@AndrewSav, как автор «форка», я должен с уважением не согласиться со всем, что вы сказали до сих пор, и как сопровождающий нескольких проектов OSS я удивлен вашим отношением.

Во-первых, cronjobber был просто производным от контроллера Kubernetes CronJob, потому что это было наиболее простое исправление, требующее наименьшего количества времени для зрелого (и проверенного) решения. Учитывая причины, указанные ниже, я не ожидал, что восходящий поток сильно изменится (да и не изменился).

Во-вторых, создание задания X во время Y с учетом часового пояса Z - это не ракетостроение, спецификация концептуального времени не менялась годами и не должна ' не требуют какого-либо обслуживания, кроме обеспечения того, чтобы он по-прежнему мог запускать собственные задания Kubernetes в нужное время (и базы данных часовых поясов обновлены, для чего есть помощник, доступный благодаря @mterron).

Пока он может порождать эти задания, на что он вполне способен в последний раз, когда я проверял, мое время лучше потратить в другом месте. Если это не соответствует вашим стандартам, я бы посоветовал нанять кого-нибудь, кто напишет и поддержит аналогичное решение для вас.

@hiddeco

Я должен с уважением не согласиться со всем, что вы сказали до сих пор

Что-либо? Это сильное заявление.

Учитывая причины, указанные ниже, я не ожидал, что восходящий поток сильно изменится (да и не изменился).

Он может не сильно измениться, но он также не останется статичным. Команда kubernetes заявила, что им нужно «широко используемое» решение, прежде чем его «можно будет рассмотреть для ядра Kubernetes». По моему опыту, решения, которые не поддерживаются активно (без изменений почти год), редко получают «широкое распространение». Кроме того, пока никто не продемонстрировал, что контроллер Kubernetes CronJob и его зависимости вообще не изменились. Я лично не могу найти хороший способ сравнения всех затронутых файлов и всех лежащих в основе зависимостей.

Во-вторых, создание задания X в момент Y с учетом часового пояса Z - это не ракетостроение, спецификация для концептуального времени не менялась годами и не требует какого-либо обслуживания, кроме обеспечения того, чтобы оно по-прежнему могло порождать нативные задания Kubernetes в правильное время (и базы данных часовых поясов обновлены, для чего есть помощник благодаря @mterron).

Мне это кажется излишне оптимистичным. Речь идет редко об изменениях «спецификаций». Убивает тебя мелочь. Ошибки обнаруживаются постоянно, даже в «зрелых и проверенных временем» проектах, и исправляются. Создание работы, возможно, не является ракетной наукой, но выяснить, как соответствующие изменения в кодовой базе Kubernetes влияют на ваши изменения, может оказаться непросто. Например, в прошлом году были предприняты попытки перенести клиентский api (kubectl) на staging. Влияет ли это на cron jobber? Я не знаю. Используемая версия библиотеки cron была обновлена ​​в апстриме. Влияет ли это на cron jobber? Опять же, не знаю.

Пока он может порождать эти задания, на что он вполне способен в последний раз, когда я проверял, мое время лучше потратить в другом месте.

И это нормально. Вы уже сделали больше, чем должны были. Вы объединили PR и опубликовали свою работу для всех. Спасибо.

Если это не соответствует вашим стандартам, я бы посоветовал нанять кого-нибудь, кто напишет и поддержит аналогичное решение для вас.

Опять же, это не обо мне, как я объяснил в комментарии выше. Речь идет о том, чтобы быть полезным для более широкого круга людей. Кажется, я сейчас повторяюсь. Может быть, все, что было сказано по теме, уже было сказано? Что вы думаете?

Мне это кажется излишне оптимистичным. Речь идет редко об изменениях «спецификаций». Убивает тебя мелочь. Ошибки обнаруживаются постоянно, даже в «зрелых и проверенных временем» проектах, и исправляются. Создание работы, возможно, не является ракетной наукой, но выяснить, как соответствующие изменения в кодовой базе Kubernetes влияют на ваши изменения, может оказаться непросто. Например, в прошлом году были предприняты попытки перенести клиентский api (kubectl) на staging. Влияет ли это на cron jobber? Я не знаю. Используемая версия библиотеки cron была обновлена ​​в апстриме. Влияет ли это на cron jobber? Опять же, не знаю.

Честно говоря, это приходит ко мне как к обструкционизму. Эту логику можно использовать, чтобы возразить против чего угодно, поэтому я понятия не имею, чего вы здесь пытаетесь достичь. Нет ничего сложного в запуске cronjobs, учитывающих часовой пояс. Любая основная система * nix (на которой работает k8) десятилетиями имела надежную поддержку часовых поясов (неожиданно оказалось, что системы * nix преимущественно работают в серверных средах, которые вызывают схожие проблемы уже более 40 лет).

Опять же, это не обо мне, как я объяснил в комментарии выше. Речь идет о том, чтобы быть полезным для более широкого круга людей. Кажется, я сейчас повторяюсь. Может быть, все, что было сказано по теме, уже было сказано? Что вы думаете?

И, как уже было сказано до тошноты, текущая реализация близка к бесполезной, потому что она полностью игнорирует часовой пояс, тогда как реализация, учитывающая часовой пояс, намного более полезна для более широкого круга людей, о чем вы здесь говорите?

Эту логику можно использовать, чтобы возразить против чего угодно.

Я не думаю, что это возможно. Вы можете продемонстрировать это, если хотите, но, пожалуйста, придерживайтесь того, что сказано, а не того, что могло подразумеваться.

поэтому я понятия не имею, чего вы здесь пытаетесь достичь.

О, я просто отвечаю на комментарий от hiddeco, адресованный мне, вы можете найти его выше.

И, как было сказано до тошноты, текущая реализация близка к бесполезной, потому что она полностью игнорирует часовой пояс, тогда как реализация, которая учитывает часовой пояс, намного более полезна для более широкого круга людей.

Если мы перефразируем это и скажем, что мы с вами предпочитаем, чтобы kubernetes cronjob поддерживал часовые пояса, это будет правильно. Я считаю, что «от закрытия до бесполезного» слишком сильно, но я полностью согласен с тем, что поддерживаемая реализация с учетом часовых поясов была бы более полезной.

что ты здесь делаешь?

Дело в том, что нет никаких доказательств того, что обсуждаемая «вилка» является «широко распространенной», и поэтому маловероятно, что команда kubernetes возьмет ее на вооружение, что очень жаль, потому что это то, что я хотел бы см. включенные в кубернеты.

Ошибки обнаруживаются постоянно, даже в «зрелых и проверенных временем» проектах, и исправляются.

Во-первых, словам «зрелый» и «проверенный временем» нет места в предложении о кубернетах или их экосистеме.

Во-вторых, с каких это пор баги становятся проблемой в кубернетах? @ fejta-bot просто "исправит" (закроет) их автоматически. Не нужно думать об ошибках. Все хорошо.

Интересно, когда / будет ли какой-нибудь сопровождающий позаботиться / прокомментировать?

Я думаю, что это должно быть задокументировано в https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron -job-limits

Я согласен с тем, что « cronjobs » на кубернетах должны иметь поддержку часовых поясов, потому что кластеры Kubernetes работают в Linux, который обеспечивает это. Отвергаем ли мы это мнение, потому что какая-то сторона планирует запустить Kubernetes (или его вариант) в Windows в отдаленном будущем? Довольно слабый повод отказаться от этого вопроса, если таковой имеется. Можем ли мы хотя бы добавить тег «сортировка / нерешенные», чтобы отличать это от уже решенных проблем?

Если принято решение, что ядро ​​k8s не должно распространяться на эту функциональность, то я согласен с вышеприведенным комментарием о том, что поддержка cronjob должна быть удалена, чтобы людям было предложено принять решение экосистемы по своему усмотрению. Это действительно выделяется в ядре k8s, что не дает явного указания на предполагаемый результат, и это сбивает людей с толку.

Поскольку Go 1.15 теперь имеет пакет time/tzdata в своей основной библиотеке, возможно…?

Как я должен перерасходовать мой кластер с 7 утра до 7 вечера?
Там, где мои пользователи, есть летнее время и зимнее время.
Так что я вообще не могу полагаться на это.

Вы приняли очень странное решение НЕ управлять часовым поясом с помощью cronjobs.

Мы нашли хорошее решение этой проблемы: прекратите использование K8s CronJobs и используйте вместо него Apache Airflow.

С тех пор жизнь стала намного лучше. Присоединяйтесь к нам!

Там эта проблема решается извне: https://github.com/hiddeco/cronjobber

@mattfarina

1. Если решение широко применяется и может использоваться кем угодно (в том числе в небольших масштабах, с несколькими кластерами и т. Д.), То его можно рассматривать для ядра Kubernetes.

Как и когда измеряется принятие решения сообщества?

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

@mattfarina @soltysh теперь с KEP-19: перейти на стабильную версию CronJob , в которой часовой пояс упоминается как одно из улучшений для рассмотрения, утвержден и объединен, и работа над контроллером cronjob v2 находится в процессе, можно ли снова открыть и пересмотреть эту проблему?

Он упоминает это как соображение / возможное улучшение. Он не гарантирует, когда и когда это будет сделано. Я могу сказать со 100% гарантией, что этого не произойдет до CronJob GA, который примет этот и еще 2 релиза.

@soltysh Это еще можно как следует обсудить. Было широко продемонстрировано, что это необходимая функция. Настойчивость в том, что это не так, показывает огромный разрыв между разработчиками и пользователями.

@benlangfeld Я открыт для этого, но время - главный ограничивающий фактор здесь: разочарован:

@benlangfeld Я открыт для этого, но время - главный ограничивающий фактор здесь 😞

Предлагаемое исправление уже есть. Что вам нужно сделать, чтобы это было принято?

Контроллер переписывается, это сейчас в центре внимания. Изменение будет возможно только с новым контроллером. Менять старую, которую предполагается заменить, бессмысленно.