Kubernetes: CronJobs는 시간대를 지원해야 합니다.

@iterion 이 문제에 대한 서명 레이블이 없습니다. 다음을 통해 서명 레이블 을
(1) 시그 언급: @kubernetes/sig-<team-name>-misc
(2) 수동으로 레이블 지정: /sig <label>

_참고: 방법 (1)은 팀에 알림을 트리거합니다. 당신은 팀 목록을 찾을 수 있습니다 여기 및 목록에 레이블을 여기 _

/ 시그 앱

나에게 더 자연스러워 보이므로 두 번째 옵션을 선호합니다.

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

두 번째 형식도 마음에 들지만 가장 쉬운 구현 방법은 그 시간을 빼서 따로 사용하는 것 같다. 또한 "표준" 크론 템플릿을 사용하고 있으므로 이를 엉망으로 만들어서는 안 된다는 주장이 제기될 수 있습니다.

다음과 같이 구현하는 것이 간단해야 합니다.
현재 syncOne 루프에 time.Now()를 전달합니다. k8s가 사용하는 cron lib는 관심 있는 영역의 시간만 사용하면 작동하는 것 같습니다. 따라서 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 문제와 풀 리퀘스트에 감사드립니다. 우리는 지난 주에 SIG Apps와 SIG Architecture에서 이에 대해 상당히 논의했습니다. 사용 사례가 의미가 있을 때 유용할 수 있지만 단점에 대해서도 논의해야 했습니다. 예를 들어, 규정을 준수하는 모든 Kubernetes 배포에는 시간대 데이터베이스가 있어야 하고 이를 최신 상태로 유지해야 합니다. 표준 시간대, 일광 절약 시간제, 실제 세부 사항이 변경될 수 있고 할 수 있는 동안 이 작업을 수행하는 세부 사항은 어렵습니다. 이것은 오늘날 존재하는 20개 이상의 배포판에 대한 추가 작업이 될 것입니다.

동시에 Kubernetes 개발에도 변화가 있었습니다. 얼마나 널리 전달되었는지 잘 모르겠습니다(통신은 SIG 아키텍처에서 논의된 또 다른 요점입니다). 변화는 핵심 Kubernetes가 안정성에 초점을 맞추고 천천히 움직이도록 하려는 것입니다. 사람들은 이제 핵심이 아닌 생태계에서 이러한 종류의 문제를 혁신하고 해결하도록 권장됩니다.

이것을 Kubernetes에 넣는 대신 요청은 다음과 같습니다.

1. 다른 사람들이 사용할 수 있는 생태계(예: 컨트롤러)에서 이것을 개발하십시오. 배포하고 문제를 해결하고 업데이트가 어떻게 보이는지 확인하십시오.
2. 솔루션이 널리 채택되고 모든 사람이 사용할 수 있는 경우(소규모, 다중 클러스터 등 포함) 핵심 Kubernetes에 대해 고려할 수 있습니다.

도움이 된다면 이것은 동일한 지시를 받는 유일한 기능이 아닙니다(동일한 SIG 아키텍처 회의에서도). 나는 이것을 wordpress와 비슷한 맥락에서 생각하기 시작했습니다. 플러그인인지 워드프레스 자체의 일부인지에는 차이가 있습니다. 현재 방향은 말하자면 플러그인의 혁신을 장려하는 것입니다.

이와 같은 것을 구축하면 SIG Apps에서 데모를 통해 사람들에게 선보일 수 있기를 바랍니다. 커뮤니티 회의에서 시연할 수도 있습니다.

이에 대한 질문이 있는 경우 언제든지 저에게 연락해 주십시오.

이전 의견을 감안할 때 이 문제를 종료할 수 있다고 생각합니다. 동의하지 않으시면 다시 열어주세요.

FWIW, "시간대 설정 방법"은 CronJob을 만드는 모든 사용자(개발자와 관리자 모두)가 묻습니다.

@iterion 결국 이것에 대해 무엇을 하였습니까? 다음을 포함하여 사용 사례에 대한 다양한 옵션을 고려하고 있습니다.

• 수정 사항으로 Kubernetes 포크에서 실행
• cron 컨트롤러 코드를 외부 컨트롤러에 복사하고 다른 apiVersion을 사용하여 둘을 구분합니다.
• kube cronjob 컨트롤러 구현을 미러링하지만 CronJob 리소스가 아닌 앱별 구성 파일을 기반으로 하는 Ruby에서 프로젝트에 특정한 것을 빌드합니다.

시작점으로 사용할 수 있는 효과가 있는 무언가가 이미 있거나 @mattfarina가 이를 포함하지 않기로 한 그의 결정을 뒤집을 수 있도록 협력할 수 있는 경우(이는 이 kube의 채택에 극적으로 해를 끼칩니다. 기능), 그것은 굉장할 것입니다.

나는 실제로 새 직장으로 옮겼기 때문에 개인적으로 더 이상 원래의 문제가 존재하지 않습니다. 내가 아는 한, 내 전 동료들은 그로 인한 고통을 겪고 있습니다.

즉, 이 작업에 할애할 시간이 있다면 필요에 따라 CronJobs를 감시하고 수정할 수 있는 작은 컨트롤러를 작성할 것입니다. 원하는 시간과 시간대를 사용하여 CronJobs에 주석을 추가하고 컨트롤러가 해당 일정을 UTC로 전송하고 CronJobs를 수정하도록 합니다. 이 동기화 루프를 일정한 간격으로 실행하여 문제의 경계를 포착할 수 있습니다. 즉, 일광 절약 시간제가 시작되거나 종료될 때입니다. 이런 식으로 컨트롤러는 이미 존재하는 CronJob API 위에 매우 얇은 래퍼가 될 것입니다.

@mattfarina 가 이것을 포함하는 것을 허용하지 않기로 한 그의 결정을 번복하도록 격려하십시오.

분명히 하기 위해 이 결정은 sig-architecture 회의 중 하나에서 집합적으로 이루어졌습니다. Matt는 이번 호에서 그 결정을 표현한 유일한 사람이었습니다.

모든 종과 휘파람이 있는 시간대 문제는 Linux 세계에서 오랫동안 해결되었습니다. 이것이 Kubernetes 배포의 필수 조건인 이유는 무엇입니까?

내가 인정하는 사용 사례의 중요성에 대해 논의하는 것은 어렵습니다. 그러나 (그리고 내 겸손한 생각으로는) 서비스 사용자와 동기화하여 서비스를 예약할 수 있다는 것은 Kubernetes 코어에 적합하기에 충분히 중요해 보입니다.

TimezoneAwareCronjobController를 사용하여 연산자를 작성하려는 사람이 있습니까? @iterion 이 작성한 대부분의 코드는 재활용될 수 있습니다.
TZ 처리를 패키지 애플리케이션으로 이동하면 Kubernetes에서 일급 cronjob 지원을 중단시킨 배포 인수가 해결됩니다.

FWIW, https://gopkg.in/robfig/cron.v2 (기존 컨트롤러가 사용하는 이전 하위 집합임)는 TZ 및 약간 더 풍부한 시간 정의 세트 전달을 지원합니다.
일부 내부 작업 부하에 대해 cron 작업을 생성하는 컨트롤러가 내부에 있으며, 이러한 작업에 대한 시간대를 지정할 수 있는 것은 뛰어난 기능 요청입니다. 실수로 작업을 건너뛰거나 다시 실행하지 않고 기존 cronjob 정의를 안전하게 업데이트하는 방법을 찾아야 합니다. 이 시점에서 기존 컨트롤러에서 작업 일정을 훔치고 cronjob보다 직접 작업 정의를 만드는 것이 실제로 더 쉬울 수 있을 것 같습니다.

K8을 사용하기 시작한 이후로 1년에 두 번 이 문제로 돌아오는데, 마침내 모든 CronJobs의 일정을 변경해야 하고 마침내 재개되기를 바랍니다. 경우 크로노스가 와 의 crontab 기능을 가지고, 어떻게 K8S 여전히이 지원되지 않는 이유는 무엇입니까?

장기 문제(자신에 대한 메모)

이 문제가 다시 열리길 바라며 매일 UTC 시간을 보는 것이 조금 이상합니다.

매월 1일 현지 시간으로 실행해야 하는 cronjob이 있지만 UTC 시간은 지난달 마지막 날 16:00입니다. 지난 달의 마지막 날을 어떻게 정의합니까? Cronjob은 L을 지원하지 않습니다.

대체 솔루션이 없는 것 같습니다. 여기 및 여기에서 내 질문을 참조

아직 이것을 기다리고 있는 누군가를 위해; 네이티브 Kubernetes cronjob 컨트롤러와 닫힌 원래 PR에서 파생된 컨트롤러를 만들었습니다.

https://github.com/hiddeco/cronjobber

편집(2019-05-12): @mterron 덕분에 Cronjobber 는 이제 사이드카를 사용하여 호스트 독립 시간대 데이터베이스를 지원합니다.

@hiddeco 기존 컨트롤러를 수정하는 것보다 컨트롤러 제어 표준 CJ 컨트롤러를 갖는 것이 더

@andrewsav 는 바람직하지만 수행할 수 없습니다. 기존 CJ 컨트롤러를 '제어'하는 유일한 방법은 CronJob 의 일정을 시간대 오프셋으로 수정하는 것입니다. 가능한 모든 일정 조합에 대해 그렇게 할 수 있는 방법은 없습니다.

어쨌든 CJ 컨트롤러에 많은 변경 사항이 있을 것으로 기대하지 않습니다. 또한 자체 포함된 상태로 실행을 유지하기 위해 동기화를 유지할 의무가 없습니다(클라이언트 및 Job 사양에 대한 종속성 제외). .

@hiddeco

가능한 모든 일정 조합에 대해 그렇게 할 수 있는 방법은 없습니다.

설명해주실 수 있나요?

@AndrewSav 간단한 예: 0 0 1 * * NZDT (UTC+13)에서 실행되는 0 0 1 * * 는 이전 달의 마지막 날에 실행해야 하기 때문에 매월 다시 계산해야 함을 의미합니다. 오전 11시(UTC 기준)

일정의 복잡성이 증가하면 동기화를 유지하기 위해 수행해야 하는 변경 사항의 양도 증가합니다. 또한 시간대 영역이 DST에서 ST로 변경될 때마다 변경해야 합니다.

이것은 그것을 극도로 복잡하게 만들고 잘못된 시간에 실행하거나 더 나빠질 수 있는 많은 공간을 엽니다. 별말씀을 요.

해결책은 시간대에 따라 "가능한" 시간마다 cron을 실행하고 현재 시간이 예상 시간이 아닌 경우 건너뛰는 것입니다. 쿠버네티스 수준에서 할 수 있기를 바랍니다.

DST의 경우 이는 하루에 한 번이 아니라 두 번 실행되고 DST에 따라 첫 번째 또는 두 번째를 건너뛴다는 것을 의미합니다.

예를 들어, 규정을 준수하는 모든 Kubernetes 배포에는 시간대 데이터베이스가 있어야 하고 이를 최신 상태로 유지해야 합니다. 표준 시간대, 일광 절약 시간제, 실제 세부 사항이 변경될 수 있고 할 수 있는 동안 이 작업을 수행하는 세부 사항은 어렵습니다. 이것은 오늘날 존재하는 20개 이상의 배포판에 대한 추가 작업이 될 것입니다.

시간대 데이터베이스인 DST는 kubernetes 배포가 의존해야 하는 OS 배포에서 매우 잘 유지 관리됩니다. "배포를 위해 열심히 일한다"는 변명은 유효한 IMO가 아닙니다.

개념이 PeriodicJob 인지 RepeatingJob 인지 논쟁하지 않습니다. 그러나 대신 CronJob 합니다. 달력과 시계로 연결되어 있습니다. 이를 위해 시간대 인식이 매우 중요하다는 사실은 부인할 수 없습니다.

또 다른 솔루션; kubernetes에서 CronJob을 완전히 제거하여 문제를 해결할 수 있습니다. 누구에게나 도움이 되는 것은 아닙니다.

또 다른 솔루션; kubernetes에서 CronJob을 완전히 제거하여 문제를 해결할 수 있습니다. 누구에게나 도움이 되는 것은 아닙니다.

동의합니다. k8에서 적절한 솔루션을 구현할 수 없다면 솔루션에 전혀 추가해서는 안 됩니다. Cronjob은 시간대와 함께 작동하도록 설계되었으며 오늘날 모든 OS는 연관된 OS 기능과 함께 시간대를 투명하게 처리합니다.

추론이 일관되지 않은 것 같습니다. 이 논리에 따르면 K8에는 존재해서는 안 되는 기능이 많이 있어야 합니다.

이것은 실제로 버그입니다. Cronjob 이름 자체는 Cron 사양을 따르지 않기 때문에 오해의 소지가 있습니다. 대부분의 kubernetes 사용자는 표준 시간대 지원이 기본적으로 제공된다고 가정합니다. 핵심 개발자가 이것을 포함하지 않기로 선택한 것은 실망스럽습니다. 이 문제는 UTC 시간에 작동하지 않는 사용자의 90% 이상에게 영향을 미칩니다.

나는 이것을 재검토할 것을 촉구하고 싶다. 내가 겪고 있는 한 가지 문제는 일본에서 특정 작업이 매월 1일 오전 1시에 실행되기를 원한다는 것입니다. 확실히 합리적인/표준 사용 사례입니다. cron이 UTC로 정의되어 있다는 점을 감안할 때 이것을 지정할 방법이 없습니다. 0 0 1 * * 는 일본 시간으로 오전 9시에 실행됩니다. (일부 cron 구현에서 사용되는 월의 마지막 날에 0 0 L * * 를 추가하는 것도 좋을 것입니다)

@johnnyshields 에 다시 열어달라고 @soltysh 에 요청해야 합니다.

나는 이것을 다시 고려하고 싶지만 가능성은 희박하다고 생각합니다. 팀은 함께 모여 의논한 후 너무 많은 추가 작업이 발생할 것이라고 결정했습니다. 이것은 그 이후로 변경된 사항이 아니므로 결정도 변경되지 않았을 것입니다.

CronJobber https://github.com/hiddeco/cronjobber 를 살펴보고 기여하십시오! 모두가 원하는 대로 이루어집니다.

최신 버전의 CronJob 컨트롤러를 기반으로 하는 PR은 훌륭하지만 그대로 완벽하게 작동합니다.

나는 이것을 다시 고려하고 싶지만 가능성은 희박하다고 생각합니다. 팀은 함께 모여 의논한 후 너무 많은 추가 작업이 발생할 것이라고 결정했습니다. 이것은 그 이후로 변경된 사항이 아니므로 결정도 변경되지 않았을 것입니다.

그런 다음 최소한 일관성이 있어야 하고 크론잡의 현재 구현을 제거해야 합니다. 그 이유는 (최소한 말해서) 매우 오해의 소지가 있기 때문입니다.

@mterron 의 문제는 거의 1년 전에 패치되었고 그 이후로 업데이트되지 않았다는 것입니다. 그 동안 개선 및 보안 수정이 포함된 수십 개의 kubernetes 릴리스가 있었습니다. 따라서 이 영역에서 쿠버네티스의 모든 최신 변경 사항과 기능을 활용하고 있다고 확신할 수 없습니다.

@AndrewSav 그리고 그것이 내가 도움을 요청한 이유입니다. 내가 할 수 있는 모든 일을 했습니다. 보안 위험이 있는지 확실하지 않습니다. Kubernetes는 항상 변경되지만 보안 측면에서 변경이 의미 있는 것은 아닙니다.

rebase는 멋지고 자유롭게 기여하고 도움을 줄 수 있습니다.

@mterron 그 작가님이세요 ? 그래서 당신이 그렇게 할 시간을 낼 수 없다는 점을 감안할 때 사람들이 더 이상 활동하지 않는 일에 기여할 가능성은 거의 없습니다. 매우 좋겠지만 동의합니다. 그 프로젝트가 처음 추진되었을 때 도박을 하고 클러스터에 넣을까 하는 생각을 잠시 하다가 유지될 가능성이 크지 않다고 생각했습니다. 1년이 지난 지금 나는 내가 틀리지 않았다는 것을 알았다. 그래서 나는 당신의 작업에 감사하지만 현재의 형태로는 지속 가능하지 않습니다.

그러나 그것이 시작되고 누군가가 지속적으로 rebase하고 유지 관리한다면 그것은 정말 멋진 일이 될 것입니다.

아니요, 저는 저자가 아닙니다. 저는 제가 할 수 있을 때 사용하는 프로젝트에 기여하는 사용자일 뿐입니다.
나는 당신이 어디에서 왔는지 이해하지만 사람들이 여가 시간에 지역 사회의 이익을 위해하는 일에 대한 기대가 조금 높다고 생각합니다.

@mterron 제 기대치에

@AndrewSav 당신은 cronjobber와 업스트림 cronjob 컨트롤러 사이에 diff를 수행해야 합니다. 지난 번 (1.17)에는 차이가 없었습니다. 업스트림 cronjob 컨트롤러는 정의에 따라 효과적으로 유지 관리되지 않습니다.

업스트림 컨트롤러에는 물론 cronjobber가 상속하는 끔찍한 성능 특성도 있습니다.

@benlangfeld

cronjobber와 업스트림 cronjob 컨트롤러 간에 diff를 수행해야 합니다.

그것은 나에 관한 것이 아니라 일반적인 사용을 위해 지속 가능한 것에 관한 것입니다. 모든 잠재적인 사용자에게 diff를 수행하도록 요청하는 것은 합리적이지 않습니다. 비록 차질이 없었다는 사실이지만, 이에 대해서는 아래에서 더 살펴보고자 한다.

업스트림 cronjob 컨트롤러는 정의에 따라 효과적으로 유지 관리되지 않습니다.

이것은 내가 말한 것에 대한 공정한 해석이 아닙니다.

diff의 주제에 대해: 당신은 무엇과 무엇을 구별하고 있습니까? 해당 리포지토리에는 50개가 넘는 파일이 있으며 모든 이름이 kubernetes 소스의 이름과 일치하지는 않습니다. 변화가 없었다는 것을 어떻게 확신할 수 있는지 설명할 수 있습니까? 명확하지 않기 때문에 이전 의견에서보다 조금 더 자세히 설명하는 것이 좋습니다. 특히, 각 측면에서 분기/커밋하는 파일을 비교하고 변경 사항을 감지하지 못한 것은 무엇입니까?

이번 이슈에 집중적으로 참여했다는 점을 감안할 때 쿠버네티스 핵심 기능에 대한 재검토를 요청하는 것이 타당하다고 생각합니다.

위의 다음 진술이 중요하다고 생각합니다. "솔루션이 널리 채택되고 모든 사람(소규모, 다중 클러스터 등 포함)이 사용할 수 있다면 핵심 Kubernetes에 대해 고려할 수 있습니다." 아직 완전히 준비되지 않은 솔루션이 있는 것 같습니다. 따라서 사용 사례가 K8s 코어에 적합하다고 인정되었다는 코어 팀의 성명은 이러한 솔루션 개발자가 풀 리퀘스트에 대비할 수 있도록 하는 훌륭한 신호가 될 것입니다.

'포크'의 저자인 @AndrewSav 는 지금까지 언급한 내용에 정중하게 동의하지 않으며 여러 OSS 프로젝트의 관리자로서 귀하의 태도에 놀랐습니다.

첫째, cronjobber는 Kubernetes CronJob 컨트롤러에서 파생된 것입니다. 가장 직접적인 수정 사항이었기 때문에 성숙한(그리고 검증된) 솔루션에 최소한의 시간이 필요했습니다. 아래에 언급된 이유를 감안할 때 저는 업스트림이 많이 변경될 것이라고 기대하지 않았습니다.

둘째, Y 시간대 Z 를 고려하여 X 작업을 생성하는 것은 로켓 과학이 아니며 개념 시간에 대한 사양은 몇 년 동안 변경되지 않았으므로 ' 적절한 시간에 Kubernetes 기본 작업을 생성할 수 있는지 확인하는 것 외에는 유지 관리가 필요하지 않습니다(시간대 데이터베이스가 최신 상태이며 @mterron 덕분에 도우미를 사용할 수 있음).

내가 마지막으로 확인할 때 완벽하게 수행할 수 있는 이러한 작업을 생성할 수 있는 한 내 시간은 다른 곳에서 보내는 것이 좋습니다. 이것이 귀하의 표준에 맞지 않으면 귀하를 위해 유사한 솔루션을 작성하고 유지 관리할 사람을 고용하는 것이 좋습니다.

@hiddeco

나는 당신이 지금까지 말한 모든 것에 정중하게 동의하지 않을 수 없습니다

아무것? 강력한 발언입니다.

아래에 설명된 이유를 감안할 때 업스트림이 많이 변경될 것이라고 기대하지 않았습니다(또는 그렇지도 않음).

_많이_ 변경되지 않을 수도 있지만 고정 상태로 유지되지도 않습니다. kubernetes 팀은 "코어 Kubernetes에 대해 고려되기 전에" "광범위하게 채택된" 솔루션을 원한다고 말했습니다. 내 경험에 따르면 적극적으로 유지 관리되지 않는 솔루션(거의 1년 동안 변경 사항 없음)은 거의 "널리 채택"되지 않습니다. 또한 Kubernetes CronJob 컨트롤러와 해당 종속성이 전혀 변경되지 않았음을 지금까지 아무도 입증하지 못했습니다. 나는 개인적으로 영향을 받은 모든 파일과 모든 기본 종속성을 비교하는 좋은 방법을 알아낼 수 없습니다.

둘째, 시간대 Z를 고려하면서 Y 시간에 작업 X를 생성하는 것은 로켓 과학이 아니며 개념 시간에 대한 사양은 몇 년 동안 변경되지 않았으며 여전히 Kubernetes 기본 작업을 생성할 수 있는지 확인하는 것 외에는 유지 관리가 필요하지 않아야 합니다. 적절한 시간(및 표준 시간대 데이터베이스가 최신 상태이므로 @mterron 덕분에 도우미를 사용할 수 있음).

이것은 나에게 지나치게 낙관적으로 들린다. 이것은 "사양" 변경에 관한 경우는 드뭅니다. 당신을 죽이는 것은 작은 것들입니다. 버그는 "성숙하고 시간이 입증된" 프로젝트에서도 지속적으로 발견되고 수정됩니다. 작업 생성은 로켓 과학이 아닐 수도 있지만 kubernetes 코드베이스의 관련 변경 사항이 변경 사항에 어떤 영향을 미치는지 알아내는 것은 빠르게 까다로울 수 있습니다. 예를 들어 작년에는 클라이언트 API(kubectl)를 스테이징으로 옮기려는 노력이 있었습니다. cron jobber에 영향을 줍니까? 모르겠어요. 사용된 cron 라이브러리 버전이 업스트림으로 업데이트되었습니다. 크론 잡버에 영향을 줍니까? 다시, 나는 모른다.

내가 마지막으로 확인할 때 완벽하게 수행할 수 있는 이러한 작업을 생성할 수 있는 한 내 시간은 다른 곳에서 보내는 것이 좋습니다.

괜찮습니다. 당신은 이미 해야 할 일보다 더 많은 일을 했습니다. PR을 병합하고 모든 사람이 사용할 수 있도록 작업을 게시했습니다. 감사합니다.

이것이 귀하의 표준에 맞지 않으면 귀하를 위해 유사한 솔루션을 작성하고 유지 관리할 사람을 고용하는 것이 좋습니다.

다시 말하지만, 이것은 내가 위의 의견에서 설명했듯이 나에 관한 것이 아닙니다. 더 많은 사람들에게 유용하다는 것입니다. 지금 제 자신을 되풀이하고 있는 것 같습니다. 주제에 대한 모든 것이 이미 언급되었을 수 있습니까? 어떻게 생각해?

이것은 나에게 지나치게 낙관적으로 들린다. 이것은 "사양" 변경에 관한 경우는 드뭅니다. 당신을 죽이는 것은 작은 것들입니다. 버그는 "성숙하고 시간이 입증된" 프로젝트에서도 지속적으로 발견되고 수정됩니다. 작업 생성은 로켓 과학이 아닐 수도 있지만 kubernetes 코드베이스의 관련 변경 사항이 변경 사항에 어떤 영향을 미치는지 알아내는 것은 빠르게 까다로울 수 있습니다. 예를 들어 작년에는 클라이언트 API(kubectl)를 스테이징으로 옮기려는 노력이 있었습니다. 크론 잡버에 영향을 줍니까? 모르겠어요. 사용된 cron 라이브러리 버전이 업스트림으로 업데이트되었습니다. 크론 잡버에 영향을 줍니까? 다시, 나는 모른다.

솔직히 이것은 방해주의를 초래하는 Whatabouttism으로 나에게옵니다. 이 논리는 무엇이든 반대하는 데 사용할 수 있으므로 여기서 달성하려는 것이 무엇인지 모르겠습니다. 시간대를 인식하는 cronjob을 실행하는 것만큼 복잡한 것은 없습니다. 모든 주류 *nix 시스템(k8이 실행되는 시스템)은 수십 년 동안 확고한 시간대 지원을 제공했습니다(놀랍게도 *nix 시스템은 40년 이상 동안 유사한 우려 사항이 있는 서버 환경에서 주로 실행되어 왔습니다).

다시 말하지만, 이것은 내가 위의 의견에서 설명했듯이 나에 관한 것이 아닙니다. 더 많은 사람들에게 유용하다는 것입니다. 지금 제 자신을 되풀이하고 있는 것 같습니다. 주제에 대한 모든 것이 이미 언급되었을 수 있습니까? 어떻게 생각해?

그리고 ad-nauseam에서 언급했듯이 현재 구현은 표준 시간대를 완전히 무시하기 때문에 거의 쓸모가 없습니다.

이 논리는 무엇이든 반대하는 데 사용할 수 있습니다.

그럴 수 없다고 생각합니다. 원한다면 그것을 시연할 수 있지만 암시될 수 있는 것이 아니라 말한 것을 고수하십시오.

그래서 나는 당신이 여기서 달성하려는 것이 무엇인지 전혀 모릅니다.

오, 나는 단지 나를 향한 hiddeco의 댓글에 답하고 있습니다. 위에서 찾을 수 있습니다.

그리고 ad-nauseam에서 언급했듯이 현재 구현은 시간대를 완전히 무시하기 때문에 거의 쓸모가 없습니다. 시간대를 인식하는 구현이 더 많은 사람들에게 훨씬 더 유용합니다

다시 말하면, 당신과 내가 kubernetes cronjob이 표준 시간대를 지원한다는 기본 설정이 있다고 말하면 맞을 것입니다. 나는 "쓸모없는 것에 가깝다"는 것이 너무 강하다고 생각하지만 지원되는 시간대 인식 구현이 훨씬 더 유용할 것이라는 데 강력히 동의합니다.

여기서 당신의 요점은 무엇입니까?

요점은 우리가 논의하고 있는 "포크"가 "널리 채택"되었다는 증거가 없고 따라서 kubernetes 팀이 이를 채택할 가능성이 낮다는 것입니다. 이는 정말 유감입니다. 왜냐하면 그것이 제가 원하기 때문입니다. kubernetes에 통합 참조.

버그는 "성숙하고 시간이 입증된" 프로젝트에서도 지속적으로 발견되고 수정됩니다.

첫째, "성숙한" 및 "시간이 입증된" 단어는 쿠버네티스 또는 해당 생태계에 대한 문장에서 설 자리가 없습니다.

둘째, 언제부터 쿠버네티스에서 버그가 문제였습니까? @fejta-bot은 자동으로 "수정"(닫기)합니다. 버그에 대해 생각할 필요가 없습니다. 모든 것이 잘됩니다.

나는 언제/어떤 유지 보수가 관심을 갖고/댓글을 달 것인지 궁금합니다.

나는 이것이 https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/#cron -job-limitations 아래에 문서화되어야 한다고 생각합니다.

저는는 Kubernetes 클러스터이 제공 리눅스에서 실행되기 때문에는 Kubernetes에 그 "cronjobs는"시간대 지원이 있어야 동의합니다. 먼 미래에 Windows에서 Kubernetes(또는 변형)를 실행할 계획이 있는 당사자가 있기 때문에 이 개념을 거부하는 것입니까? 이 문제를 거부하는 매우 약한 이유. 해결된 문제와 구별하기 위해 최소한 "triage/unresolved" 태그를 추가할 수 있습니까?

핵심 k8이 이 기능으로 확장되어서는 안 된다는 결정이라면 cronjob 지원을 제거하여 사람들이 원하는 대로 생태계 솔루션을 채택하도록 권장해야 한다는 위의 의견에 동의합니다. 이것은 의도한 결과에 대해 명시적이지 않고 사람들을 혼란에 빠뜨리는 핵심 k8의 무언가로 실제로 두드러집니다.

Go 1.15 이후로 코어 라이브러리에 time/tzdata 패키지가 생겼습니다. 아마도 ...?

아침 7시에 클러스터를 저녁 7시까지 오버 프로비저닝하려면 어떻게 해야 합니까?
내 사용자가 있는 곳에는 여름 시간과 겨울 시간이 있습니다.
그래서 나는 그것에 전혀 의존할 수 없다.

cronjob으로 시간대를 관리하지 않는 것은 매우 이상한 결정이었습니다.

이 문제에 대한 좋은 해결 방법을 찾았습니다. K8s CronJobs 사용을 중지하고 대신 Apache Airflow를 사용합니다.

우리가 한 이후로 삶은 훨씬 나아졌습니다. 우리와 함께!

이 문제는 https://github.com/hiddeco/cronjobber에서 외부적으로 해결됩니다.

@mattfarina

1. 솔루션이 널리 채택되고 모든 사람이 사용할 수 있는 경우(소규모, 다중 클러스터 등 포함) 핵심 Kubernetes에 대해 고려할 수 있습니다.

커뮤니티 솔루션의 채택은 언제, 어떻게 측정됩니까?

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

@mattfarina @soltysh with KEP-19: 표준 시간대를 고려해야 할 개선 사항 중 하나로 언급 cronjob 컨트롤러 v2 에 대한 작업이 진행 중입니다. 이 문제를 다시 열고 재고할 수 있습니까?

이를 고려 사항/개선 가능성으로 언급합니다. 이것이 접근할 것인지 또는 언제 접근할 것인지는 보장하지 않습니다. CronJob GA 이전에는 이러한 일이 발생하지 않을 것이라고 100% 보장할 수 있습니다.

@soltysh 아직 제대로 논의할 수 있습니다. 이것은 필요한 기능이라는 것이 널리 입증되었습니다. 이것에 대해 공을 차라고 주장하는 것은 메인테이너와 사용자 사이의 엄청난 단절을 보여줍니다.

@benlangfeld 저는 이에 대해 매우 개방적이지만 시간이 여기서 주요 제한 요소입니다.실망:

@benlangfeld 저는 이에 대해 매우 개방적이지만 시간이 주요 제한 요소입니다 😞

이미 제안된 수정 사항이 있습니다. 이를 수락하려면 어떤 입력이 필요합니까?

컨트롤러가 다시 작성되고 있으며, 이것이 바로 지금의 주요 초점입니다. 변경은 새 컨트롤러에서만 가능합니다. 교체해야 할 오래된 것을 변경하는 것은 의미가 없습니다.