@enisoc @dchen1107 @fejta @thockin @kow3ns @derekwaynecarr , 논의할 수 있도록 이 추적 문제를 열었습니다.

/양수인

@derekwaynecarr 다음 주 sig-node 회의에 필요한 kubelet 변경 사항에서 일부 범위를 지정했습니다. 변경 사항은 kuberuntime 패키지, 특히 kuberuntime_manager.go in 및 kuberuntime_container.go 에만 필요하다고 _믿습니다_

kuberuntime_manager.go computePodActions 를 수정하여 종료 트리거(모든 비 사이드카가 영구적으로 종료되면 사이드카 종료)를 구현하고 사이드카를 먼저 시작할 수 있습니다.

에서 kuberuntime_container.go 수정할 수 killContainersWithSyncResult preStop 후크를 마지막으로 사이드카를 종료하고 보내는합니다 (preStop 그 수행 여부를해야하는지 여부를 비트는 비트 논쟁의 여지가, 그것이 해결되지 하였다 후크. @ thockin 은 왜 당신이 그 행동을 장려하고 싶지 않은지에 대해 좋은 지적을 했습니다( 댓글 참조).

추가 조사를 원하시면 알려주세요.

@kow3ns Pod 사양(sig-app)에서 컨테이너 시퀀스에 대한 전체 설명을 정의할 수 있고 시작, 다시 시작 및 계단식 고려 사항(sig-node)을 위해 kubelet에서 시퀀스를 처리하는 방법을 정의할 수 있다면 토론이 더 의미가 있습니다. 더 많은 정보를 제공하기 위해 2월 5일 서명 노드 회의를 살펴보겠습니다.

cc @Joseph-어빙

제안에 따르면 사이드카는 초기화 컨테이너가 실행된 후에만 실행됩니다. 그러나 유스 케이스에서 초기화 컨테이너가 실행되는 동안/이전에 사이드카를 실행해야 하는 경우에는 어떻게 될까요? 예를 들어 Istio에서와 같이 사이드카로 실행되는 프록시를 통해 포드의 트래픽을 라우팅하려는 경우 초기화 컨테이너 자체가 네트워크 호출을 수행하는 경우에 대비하여 초기화 컨테이너가 실행되는 동안 해당 프록시가 제자리에 있기를 원할 수 있습니다.

@luksa 어느 시점에서 초기화 단계에서 실행되는 사이드카를 가질 가능성이 있다고 생각하지만 현재 제안은 해당 사용 사례를 다루지 않을 것입니다. 현재로서는 init 단계에서 동시 컨테이너를 실행할 수 있는 방법이 없으므로 여기에 제안된 것보다 잠재적으로 훨씬 더 크고 지저분한 변경이 될 수 있습니다.

이 KEP에 대한 업데이트:
나는 이것에 대해 sig-node에서 @derekwaynecarr 와 @dchen1107 모두에게 이야기했지만 그들은 제안에 대해 큰 우려를 표명하지 않았습니다. 나는 구현 세부 사항에 대한 몇 가지 초기 참고 사항을 추가하고 토론 중에 나온 몇 가지 요점을 명확히 하는 PR을 KEP에 제기할 것입니다.

우리는 여전히 API에 동의해야 합니다. 컨테이너를 사이드카로 표시하는 간단한 방법이 보다 심층적인 주문 플래그보다 선호된다는 데 동의하는 것 같습니다. bool을 갖는 것은 다소 제한적이지만 아마도 containerLifecycle: Sidecar 라인을 따라 더 많은 것이 더 선호되어 미래에 확장할 수 있는 옵션이 있습니다.

@Joseph-Irving 사실, boolean이나 containerLifecycle: Sidecar 모두 적절한 미래 확장성에 적합하지 않습니다. 대신 containerLifecycle 는 deployment.spec.strategy 와 type: Sidecar 와 같은 객체여야 합니다. 그러면 추가 필드를 도입할 수 있습니다. "파드의 전체 수명 동안 사이드카" 솔루션의 경우 다음 행을 따라 표현됩니다.

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: CompletePodLifetime

반대로

containerLifecycle: 
  type: Sidecar
  sidecar:
    scope: AfterInit

제 잘못된 이름을 용서해 주십시오. 이름이 아이디어를 전달하기를 바랍니다.

그러나 containerLifecycle 를 pod.spec.containers 도입하는 접근 방식에는 한 가지 문제가 있습니다. 즉, pod.spec.containers 지정된 초기화 컨테이너와 병렬로 실행되는 사이드카를 갖는 것은 잘못된 것입니다. 따라서 이것을 확장하여 결국 컨테이너를 초기화할 수 있기를 원한다면 대체 솔루션을 찾아야 합니다. 즉, pod.spec.containers 또는 pod.spec.initContainers 아래가 아닌 더 높은 수준에서 컨테이너를 사이드카로 표시할 수 있는 솔루션을 찾아야 합니다 pod.spec.sidecarContainers 와 같은 것입니다. 이미 논의했지만 무시했습니다. 컨테이너 초기화 문제는 확실히 이러한 라인에 따른 솔루션을 요구합니다.

@luksa 초기화 컨테이너를 사이드카로 표시하고 초기화 컨테이너와 함께 실행하도록 하여 초기화 문제를 해결할 수도 있습니다. 내가 이해하는 한, 문제는 초기화 컨테이너에 때때로 사이드카가 필요하다는 것입니다. 이는 포드의 전체 수명 동안 실행되는 컨테이너가 필요한 것과 다릅니다.

pod.spec.sidecarContainers 의 문제는 훨씬 더 복잡한 변경이며 도구를 업데이트해야 하고 kubelet이 다른 컨테이너 세트를 지원하기 위해 많은 수정이 필요하다는 것입니다. 현재 제안은 훨씬 더 겸손하며 이미 있는 것을 기반으로 할 뿐입니다.

@Joseph-Irving 우리는 예와 함께 일할 수 있습니다. 초기화 컨테이너가 실행된 후 사이드카가 종료되고 동일한 사이드카가 다시 시작되는 것은 이상적이지 않지만 해당 옵션이 없는 것보다는 낫습니다. 더 큰 문제는 구형 Kubelets가 init-sidecar 컨테이너를 제대로 처리하지 않는다는 것입니다(메인 사이드카 컨테이너의 경우와 마찬가지로).

제안을 마무리할 때 init-sidecars를 염두에 두시기 바랍니다. 본질적으로 "사이드카" 개념을 k8에 도입하고 있습니다(이전에는 기본적으로 모두 동일한 컨테이너 세트만 있었습니다). 이제 실제 사이드카를 도입하고 있으므로 IMHO, 정말 이것을 철저히 생각하고 매우 중요한 사이드카 사용 사례를 무시해서는 안 됩니다.

이를 구현하는 데 도움이 되었으면 합니다. 이것이 없으면 Istio는 컨테이너를 초기화하는 기능을 제공할 수 없습니다(실제로 Istio를 실행하는 적절하게 보안된 Kubernetes 클러스터에서 초기화 컨테이너는 _any_ 서비스와 통신하는 기능을 완전히 상실함).

https://github.com/kubernetes/enhancements/pull/841 의 구현 논의와 관련하여 이 제안에 대한 기본 PoC가 포함된 WIP PR을 열었습니다. https://github.com/kubernetes/kubernetes/pull /75099. 그것은 단지 첫 번째 초안이고 분명히 완벽하지는 않지만 기본 기능이 작동하고 필요한 변경의 양에 대한 아이디어를 제공합니다.

cc @enisoc

PoC가 현재 https://youtu.be/4hC8t6_8bTs에서 어떻게 작동하는지 보여주는 짧은 비디오를 만들었습니다
면책 조항: 저는 프로 유튜버가 아닙니다.

두 개의 새로운 PR을 열었습니다.

• https://github.com/kubernetes/enhancements/pull/918 은 졸업 기준, 버전 왜곡, 업그레이드/다운그레이드에 관한 것입니다.
• https://github.com/kubernetes/enhancements/pull/919 는 API 구현을 결정하는 것입니다.

어떤 생각이나 제안이라도 대단히 감사하겠습니다.

@Joseph-Irving 디자인 과정에서 늦게 댓글을 달게 되어서 죄송합니다. 하지만 현재 디자인 제안에서 지원되지 않을 수 있는 사이드카 컨테이너에 대한 잠재적인 사용 사례가 있습니다. 나는 단지 고려를 위해 그것을 높이고 싶었습니다. 요점은 포드 종료 시 1개의 사이드카가 메인 컨테이너보다 먼저 종료되어야 하고 다른 사이드카가 메인 컨테이너 이후에 종료되어야 하는 시나리오가 있다는 것입니다.

구체적인 예로는 Django 앱 컨테이너가 있는 포드, 서비스 등록을 위한 영사 사이드카, 데이터베이스 연결을 관리하기 위한 pgbouncer 사이드카가 있습니다. 포드가 종료되면 영사 사이드카를 먼저 중지하고(더 이상 트래픽이 포드로 라우팅되지 않도록) 앱 컨테이너(짧은 유예 기간 후 이상적으로는)를 중지한 다음 pgbouncer 사이드카를 중지합니다. 현재 제안은 앱 <-> pgbouncer 컨테이너 종속성을 처리하는 데는 훌륭해 보이지만 기본 컨테이너 _before_ 사이드카를 분해하려는 경우를 포착할 만큼 표현력이 부족해 보입니다.

@currankaushik , 설명한 시나리오에서 사전 중지 후크를 사용하여 영사 컨테이너에 종료를 준비하고 요청 라우팅을 중지하도록 지시할 수 있습니다(이와 같은 것을 지원할 수 있다고 가정). 사전 중지 후크는 컨테이너 종료가 시작되기 전에 먼저 사이드카로 전송됩니다.

이에 대한 동기는 istio와 같은 프록시 사이드카가 트래픽을 사용자에게 라우팅하지 않지만 애플리케이션이 완료되고 종료되는 동안 여전히 트래픽을 허용하는 상태에 들어갈 수 있기 때문입니다.

@Joseph-Irving에게 감사드립니다. 그래서 높은 수준에서 내 이해를 확인하기 위해 사전 중지 후크가 먼저 사이드카로 전송되고 그 다음 사전 중지 후크가 비 사이드카로 전송되고 SIGTERM이 비 사이드카로 전송된 다음 (모든 비-사이드카가 종료된 후) ) SIGTERM을 사이드카로? 디자인 제안(https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/sidecarcontainers.md)은 이것을 암시하지만 다음과 같이 말합니다.

PreStop Hooks는 사이드카와 컨테이너로 동시에 전송됩니다.

@currankaushik 네 설명하신 내용은 의도한 동작입니다.

당신이 인용한 그 줄은 수정이 필요합니다. 나는 그것을 썼을 때 prestop hooks가 어떻게 컨테이너로 보내졌는지에 대해 약간의 오해가 있었습니다. 지적해주셔서 감사합니다.

@Joseph-Irving 이 기능은 1.15용 알파 포함을 대상으로 합니까?

@kacole2 네, 개선 동결(4월 30일)에 맞춰 KEP를 구현할 수 있다고 가정하면 계획입니다. API가 완료되면 https://github.com/kubernetes/enhancements/pull/919 그리고 테스트 계획이 https://github.com/kubernetes/enhancements/pull/951에 동의하면 모든 준비가 완료되어야 한다고 생각합니다.

/마일스톤 v1.15
/스테이지 알파

@Joseph-Irving Kubernetes 1.15 Enhancement Freeze는 2019년 4월 30일입니다. Kubernetes 1.15 마일스톤에 포함되려면 KEP가 적절한 테스트 계획 및 졸업 기준과 함께 "구현 가능" 상태여야 합니다. 이 KEP가 포함 기준을 준수하도록 하는 데 필요한 PR을 제출하십시오. 이것이 1.15 이정표에서 벗어나면 적절한 추적 변경을 할 수 있도록 알려주십시오.

@mrbobbytables 불행히도 이것을 구현 가능한 상태로 만들기 위해 열린 PR이 많이 움직이지 않았으므로 1.16까지 이를 연기해야 ​​한다고 생각합니다.

걱정 마. 신속하게 응답하고 알려주셔서 감사합니다!
/마일스톤 클리어

이 KEP는 Istio에게 매우 중요합니다.

그것은 메쉬 함께 istio 서비스와 통합 된 부트 스트랩 / 종료와 서비스 프레임 워크를 사용하는 모든 프로젝트 (akka 클러스터, lagom 등) 쇼 스토퍼입니다 참조 .

cc @jroper

@Joseph-Irving은 늦은 댓글에 대해 부끄러워하지만 디자인 문서에는 다음이 표시되지 않으며 의도한 동작이 무엇인지 궁금했습니다.

사이드카 오류가 발생하면 기본 컨테이너가 완료되지 않은 경우 항상 다시 시작합니까(포드의 restartPolicy 무시)? 이것은 프록시, 로드 밸런싱, 하우스 키핑 역할로 사용되는 사이드카로 유용할 것이며 메인 컨테이너가 계속 작동할 수 있는 한 몇 번 실패해도 문제가 되지 않습니다.

또한 포드 단계를 계산할 때 모든 기본 컨테이너가 성공하고 사이드카가 실패한 경우(사이드카가 SIGTERM을 포착하지 못하는 경우가 매우 일반적이며 반환 코드는 143과 같을 것입니다), 포드 단계는 여전히 "성공"입니까?

@zhan849 현재 사이드카 컨테이너는 포드 재시작 정책을 따르며 Succeeded 와 같은 포드 단계를 계산할 때 계산됩니다.

우리는 프로세스 초기에 이에 대해 논의했지만 일반적인 느낌은 설명된 사용 사례를 가능하게 하는 경우에만 일반 컨테이너에서 가능한 한 적게 벗어나야 한다는 것이었습니다.

포드 단계와 관련하여: 나는 쿠버네티스에서 실행되는 모든 애플리케이션이 SIGTERM(특히 사이드카)을 처리해야 한다고 주장하지만 때로는 사이드카가 잘못된 방식으로 종료되고 포드 단계에 반영되어야 하는지 알고 싶을 수도 있습니다. 그 정보를 숨기면 혼란을 초래할 수 있습니다.

다시 시작 정책의 경우 다시 시작 정책이 전혀 적용되지 않고 사이드카가 충돌하기 쉬운 경우에만 문제가 되는 것 같습니다. 특히 일부 사람들은 사이드카가 포드 다시 시작 정책을 따르기를 원할 수 있기 때문에 포드 다시 시작 정책에서 파생시키는 복잡성이 그만한 가치가 있는지 확실하지 않습니다.

이 두 가지 모두 일반 컨테이너가 수행하는 작업과 현재 발생하는 작업과 일치합니다.
Kep에 나열된 목표를 달성하기 위해 변경하는 것이 필요하지 않은 것 같습니다.

이러한 목표를 달성하기 위해 변경이 필요한 이유에 대한 광범위한 사용 사례가 있는 경우 유용할 것입니다. 코드 기반에 대한 더 복잡한 변경을 정당화하기 쉽기 때문입니다.

@Joseph-Irving 우리는 즉각적인 필요를 위해 내부적으로 실행되고 있는 더 간단한 사이드카 impls를 가지고 있습니다(이것은 커뮤니티에서 이미 진행 중이므로 기여하지 않았습니다). 그리고 여기에 우리가 배운 것이 있습니다.

포드 단계에 대해:

1. 컨테이너 존재 상태는 이미 pod.status.containerStatuses 반영되어 있으므로 정보를 잃지 않습니다. 또한 사이드카의 큰 사용 사례는 Job(또는 Kubeflow의 경우와 같이 run-to-finish 포드)에 있으므로 기본 컨테이너에만 의미 있는 워크로드가 적용되고 포드 단계가 사이드카 오류로 인해 실패로 표시되는 경우 , 불필요한 재시도가 발생하고 작업 실패 등과 같은 잘못된 결과를 초래할 수 있습니다.

2. 사이드카가 SIGTERM을 처리하는 것이 이상적이지만 프로덕션 환경에는 단순히 오픈 소스 소프트웨어를 기반으로 구축된 사이드카가 많이 있을 수 있으며 kube-proxy , postfix , rsyslogd 포함하여 SIGTERM을 제대로 처리하지 못합니다.

다시 시작 정책과 관련하여(논의할 수 있지만 사이드카가 restartPolicy를 엄격히 준수하도록 하는 것은 프로덕션에서 비현실적입니다):

1. "OnFailure"를 설정하여 기본 컨테이너가 계속 실행 중일 때 사이드카를 강제로 다시 시작하는 것은 실패한 기본 컨테이너를 다시 시작하고 작업 수준 재시도 제한과 혼동되기 때문에 옵션이 아닙니다.

2. 일반적으로 사이드카를 처리할 때 기본 컨테이너에는 사용할 수 없는 사이드카에 대한 재시도 논리가 많이 있으며 커뮤니티에서 명시적 컨테이너 시작 순서로 사이드카를 지원하기 전에 수행됩니다. 이러한 역사적 오류 처리는 범위를 감안할 때 변경하기가 쉽지 않습니다. 사이드카를 다시 시작하지 않으면 기본 컨테이너가 중단되고 다시 시도됩니다.

3. 상위 수준 컨트롤러에 오류를 전파하면 조정 체인과 많은 API 호출이 트리거되므로 불필요한 오류 에스컬레이션으로 인해 Kubernetes의 확장성이 떨어질 수 있습니다.
   더 구체적인 예: 작업의 기본 컨테이너가 여전히 실행 중이고 사이드카가 실패하는 경우 사이드카를 다시 시작하면 1개의 PATCH 포드 상태 작업과 최대 1개의 이벤트 관련 API 호출만 갖게 됩니다. 그러나 포드가 완전히 실패하면 작업이 조정되고 CronJob 및 기타 CRD와 같은 더 많은 고용 수준 컨트롤러와 API 호출이 훨씬 더 많이 발생할 수 있습니다.

다른 사람들이 유사한 문제를 본 적이 있는지도 확인하고 싶습니다(/cc @kow3ns ).

이 변경 사항은 https://github.com/kubernetes/community/pull/2342 에서 원하는 동작을 통합하여 사이드카 실패?

@JacobHenner 현재 이 KEP에 그런 종류의 메커니즘을 구현할 계획이 없습니다. 통합에 대해 논의했지만 실제로 이 KEP에 대한 종속성이 많지 않으며 이와 독립적으로 개발될 수 있습니다. 따라서 자체 KEP를 갖는 것이 더 적합해 보입니다.

@Joseph-Irving은 공식 지원을 기다리는 것이 목표이므로 참조용으로 위에서 언급한 함정을 해결한 impl을 공유합니다(https://github.com/zhan849/kubernetes/commits/kubelet-sidecar). 이 커밋에서 변경 사항을 가능한 한 로컬로 유지합니다.

따라서 작업 재시작 정책의 경우 == 절대, 1개의 메인 컨테이너, 지속적으로 충돌하는 1개의 불량 사이드카, 계속 실행되는 1개의 양호한 사이드카, 위의 impl로 메인 컨테이너가 종료된 후 포드 상태가 다음과 같이 보일 것입니다.

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"

나는 일반적으로 사이드카 KEP가 구현 가능한 상태로 전환되기 전에 포드 단계 및 다시 시작 정책을 고려해야 한다는 데 동의합니다. 이것이 KEP인지 아닌지는 신경 쓰지 않지만 @zhan849 의 주장에 일반적으로 동의하며 여기서 다루어야 합니다.

@smarterclayton 감사
@Joseph-Irving은 실제로 사이드카와 공유하고 싶은 다른 것이 있으면 알려주십시오.

@smarterclayton @zhan849 , 나는 당신의 주장에 특별히 동의하지 않습니다. Pod 단계/재시작 정책을 변경하지 않는 것은 이 제안의 범위를 더욱 확대할 수 있는 의식적인 선택이었고 아무도 이에 대해 강력하게 느끼지 않았습니다.

나는 이 피드백을 sig-apps/sig-node로 가져가서 그들이 어떻게 생각하는지 볼 것입니다. 특히 sig-node는 @derekwaynecarr 또는 @dchen1107 이 차임벨을 이었습니다 .

테스트 계획 https://github.com/kubernetes/enhancements/pull/951 및 API 디자인 https://github.com/kubernetes/enhancements/pull/919 PR이 이제 병합되었습니다.

KEP를 구현 가능한 것으로 표시하기 위해 https://github.com/kubernetes/enhancements/pull/1109 를 열었습니다. 일단 모두가 만족하면 1.16에서 알파로 개발을 시작할 수 있어야 합니다.

이 Kep은 구현 가능한 것으로 표시되어 있으므로 다음 주부터 이를 1.16으로 만들기 위해 PR을 올릴 것입니다!

API를 구현하기 위해 https://github.com/kubernetes/kubernetes/pull/79649 를 올렸습니다. Kubelet 변경 사항에 대한 별도의 PR이 있을 것입니다.

안녕하세요 @Joseph-Irving, 저는 1.16 Enhancement Lead입니다. 이 기능이 1.16에서 알파/베타/안정 단계를 졸업하게 됩니까? 1.16 추적 스프레드시트에 추가할 수 있도록 알려주십시오. 졸업하지 않은 경우 이정표에서 제거하고 추적 레이블을 변경합니다.

코딩이 시작되거나 이미 코딩이 시작되면 이 호에 있는 모든 관련 k/k PR을 나열하여 올바르게 추적할 수 있도록 하십시오.

이정표 날짜는 Enhancement Freeze 7/30 및 Code Freeze 8/29입니다.

감사합니다.

@Joseph-Irving 이것을 구현하기 위해 추가 인력이 필요하거나 필요하다면 이 상륙에 많은 관심을 갖고 있으므로 기꺼이 도움을 드리겠습니다.

안녕하세요 @kacole2 이것은 1.16의 Alpha를 대상으로 하며 KEP는 구현 가능한 것으로 표시되었습니다.
현재 이에 대한 유일한 PR은 API에 대한 kubernetes/kubernetes#79649입니다.

@mhuxtable 곧 kubelet 변경 사항에 대한 PR을 올릴 예정이며 몇 가지 사항을 마무리할 예정입니다. 이를 살펴보는 데 도움을 주시면 대단히 감사하겠습니다. 올라오면 여기에 링크하겠습니다.

kubelet 변경 사항을 구현하는 https://github.com/kubernetes/kubernetes/pull/80744 를 열었습니다.

kubernetes/kubernetes#79649(api)가 아직 열려 있으므로 이 PR에는 커밋이 포함되어 있어 크게 보입니다. 나는 그것을 각각 다른 비트의 기능을 구현하는 커밋으로 나누어서 그런 식으로 쉽게 검토할 수 있어야 합니다.

이에 대한 모든 테스트 사례를 완료하지는 않았지만 첫 번째 작업 구현 초안이 완료되었으므로 사람들이 살펴보기를 바랍니다.

cc @kacole2

@조셉-어빙

저는 v1.16 문서 그림자 중 하나입니다.
이 개선 사항(또는 v1.16에 대해 계획된 작업)에 새로운 문서(또는 기존 문서에 대한 수정)가 필요합니까? 그렇지 않은 경우 1.16 Enhancement Tracker Sheet를 업데이트할 수 있습니까(또는 알려주시면 업데이트하겠습니다)

그렇다면 8월 23일 금요일까지 k/website(branch dev-1.16)에 대한 PR을 찾고 있으며 현재로서는 자리 표시자 PR일 ​​수 있습니다. 질문이 있으면 알려주세요!

@daminisatya 안녕하세요. 예, 문서를 업데이트해야 합니다. https://github.com/kubernetes/website/pull/15693 을 자리 표시자 PR로 올렸습니다.
문서가 어디로 가야 하는지에 대한 의견이 있는 사람이 있는지 알고 싶습니다. 지금은 content/en/docs/concepts/workloads/pods/pod-lifecycle.md 에 무언가를 넣어두었습니다.

Code Freeze까지 앞으로 1주일도 채 남지 않은 상황에서 이것이 1.16에 포함될 가능성은 매우 낮아 보입니다.
리뷰를 얻기 위해 고군분투한 두 개의 비교적 큰 공개 PR인 kubernetes/kubernetes#80744와 kubernetes/kubernetes#79649가 있습니다.
바라건대 다음 릴리스 주기에서 검토자 대역폭이 더 많아지기를 바랍니다.

/양수인

이를 통해 요청 시 실제 서비스를 시작할 수 있는 사이드카를 작성할 수 있습니까?

scale to zero와 비슷하지만 유휴 상태에서 실행되는 것은 사이드카뿐입니다. 요청이 오면 실제 서비스를 가동하고 마지막 응답(예: 30초) 후에 서비스를 종료합니다. 이를 통해 거의 0에 가깝게 크기를 조정하는 간단한 방법을 사용할 수 있습니다(사이드카만 실행됨).

@Ciantic Operator Framework 를 사용하면 그 이상을 할 수 있습니다. 구경하다

@janosroden 보았지만 실행 중인 서비스를 확장성이 없는 수준으로 올리는 방법을 이해하기가 꽤 어려운 것 같습니다.

문제는 Osiris , Keda 또는 knative 와 같은 사용 가능한 옵션이 없다는 것입니다. 나는 마지막 것을 시도했지만 8Gb의 메모리를 잡아먹습니다. 그 시점에서 '서버리스'라고 말하기는 어렵습니다.

문제는 이러한 구현의 대부분이 새로운 리소스 등을 필요로 한다는 것입니다. 전체 수명 주기(요청 시 시작 및 다시 시작 포함)를 제어할 수 있는 사이드카를 주입하여 서비스를 제어할 수 있다고 생각하는 것이 훨씬 쉽습니다. 거기 앉아.

이것이 왜 유익할까요? 이는 사용률이 낮고 메모리가 부족한 상황(예: Raspberry Pi가 있는 k3 또는 취미 프로젝트용 Digital Ocean droplet)에서 정말 유용합니다. 우리 중 많은 사람들이 항상 실행할 필요가 없는 많은 웹 서비스를 가지고 있습니다. 필요할 때 깨울 수 있는 사이드카만 있으면 충분합니다.

이것이 귀하의 사용 사례에 실제로 작동하는지 확실하지 않습니다. 리소스가 제한된 시스템에서 원하는 작업을 수행하려는 열망을 완전히 이해합니다. 그러나 실제로 안정적이려면 리소스 요청을 사용하여 작업 부하를 예약해야 합니다. 워크로드가 실행 중인지 여부에 관계없이 리소스를 예약해야 하므로 미리 지정해야 합니다.

이 문제를 해결하려면 초기 연결 수신을 수행하고 k8에 대한 새 포드 요청을 수행하고 회전할 때까지 기다린 다음 트래픽을 보낼 자체 포드가 필요합니다. 이 경우 사이드카 컨테이너 향상이 필요하지 않다고 생각합니다. k8s용 xinetd와 같은 것이 더 필요하다고 생각합니다.

안녕하세요 @Joseph-Irving -- 1.17 개선 사항이 여기에 있습니다. 이 개선 사항이 1.17에서 알파로 전환될 것이라고 생각하는지 확인하고 싶었습니다.

현재 출시 일정은 다음과 같습니다.

• 9월 23일 월요일 - 출시 주기 시작
• 10월 15일 화요일, EOD PST - 개선 사항 동결
• 11월 14일 목요일, EOD PST - 코드 동결
• 11월 19일 화요일 - 문서를 작성하고 검토해야 합니다.
• 12월 9일 월요일 - Kubernetes 1.17.0 릴리스

그렇다면 코딩이 시작되면 이 호에 있는 모든 관련 k/k PR을 나열하여 올바르게 추적할 수 있도록 하십시오. 👍

감사 해요!

@mrbobbytables 안녕하세요. 1.17에서 알파로 전환할 계획인 시간 내에 모든 것을 검토할 수 있다고 가정합니다.

현재 공개된 PR은 다음과 같습니다.
https://github.com/kubernetes/kubernetes/pull/79649 - API 변경 사항
https://github.com/kubernetes/kubernetes/pull/80744 - Kubelet 변경 사항

다른 것이 필요하면 알려주세요!

엄청난! @Joseph-Irving 감사합니다 추적 시트에 정보를 추가하겠습니다 👍

@조셉-어빙

저는 v1.17 문서 그림자 중 하나입니다.
이 개선 사항(또는 v1.17에 대해 계획된 작업)에 새로운 문서(또는 기존 문서에 대한 수정)가 필요합니까? 그렇지 않은 경우 1.17 Enhancement Tracker Sheet를 업데이트할 수 있습니까(또는 알려주시면 업데이트하겠습니다)

그렇다면 11월 8일 금요일까지 k/website(branch dev-1.17)에 대한 PR을 찾고 있으며 현재로서는 자리 표시자 PR일 ​​수 있습니다. 질문이 있으면 알려주세요!

감사 해요!

안녕하세요 @VineethReddy02 예, 문서가 필요합니다. 자리 표시자 PR은 https://github.com/kubernetes/website/pull/17190입니다.

나는 KEP https://github.com/kubernetes/enhancements/pull/1344 를 업데이트하기 위해 PR을 올렸습니다. 이것은 우리가 구현 PR에서 있었던 토론을 기반으로 합니다 https://github.com/kubernetes/kubernetes/pull /80744.

어떤 의견이든 감사하겠습니다.

안녕하세요 @Joseph-Irving 1.17 인핸스먼트 섀도우입니다! 👋 이 개선 사항이 어떻게 진행되고 있는지 확인하기 위해 연락을 드리고 있습니다.

개선 팀은 현재 추적 시트에서 kubernetes/kubernetes#79649 및 kubernetes/kubernetes#80744를 추적하고 있습니다. 추적해야 하는 다른 k/k PR도 있습니까?

또한 코드 동결(11월 14일)이 빠르게 다가오고 있음을 알려드립니다.

안녕하세요 @annajung , 네, 추적이 필요한 유일한 PR입니다.

@Joseph-Irving 안녕하세요. 내일은 1.17 릴리스 주기의 코드 동결입니다 . k/k PR이 병합되지 않은 것 같습니다. 1.17 추적 시트에서 이 개선 사항을 At Risk 로 표시합니다.

14일(목) EoD까지 필요한 PR이 다 합쳐질 것 같나요? 그 후에는 예외를 제외하고 마일스톤에서 릴리스 차단 문제 및 PR만 허용됩니다.

안녕하세요 @annajung , 불행히도 코드 동결 전에 병합될 가능성은 매우 낮아 보입니다. 이번 릴리스 주기에 많은 진전을 이루었으므로 1.18 초기에 이를 병합할 수 있기를 바랍니다.

@Joseph-Irving 업데이트 감사합니다. 이에 따라 이정표를 업데이트하고 이 개선 사항을 1.18로 연기된 것으로 표시하겠습니다. 감사합니다!

/마일스톤 v1.18

안녕하세요 @Joseph-Irving입니다. 1.18 개선 사항은 여기 👋 .

1.18 릴리스가 어제 시작되었으므로 1.18 릴리스에 이를 상륙할 계획이 있는지 알아보기 위해 연락을 드리고 있습니다. 코드 동결로 인해 이것이 1.17을 놓친 것 같습니다. 1.18을 어떻게 찾고 있습니까? PR이 아직 열려 있는 것을 알 수 있습니다.

감사 해요!

안녕하세요 @jeremyrickard 님 ,

네, 1.18 릴리스에서 이를 얻을 계획입니다.

API PR(https://github.com/kubernetes/kubernetes/pull/79649)은 요전 thockin으로부터 몇 가지 요점을 가지고 검토를 받았지만 문제가 해결되면 해당 PR을 닫고 커밋을 (https://github.com/kubernetes/kubernetes/pull/80744) API와 구현을 함께 병합할 수 있습니다.

Kubelet PR(https://github.com/kubernetes/kubernetes/pull/80744)의 경우 검토가 필요합니다. 이번 주기에서 검토할 서명 노드 대역폭을 얻을 수 있기를 바랍니다.

@Joseph-Irving 업데이트 감사합니다.

추적 시트에 추가했습니다!

파티에 늦어서 죄송합니다. 이것은 일반적인 경우에 상당한 개선입니다. 그러나 고급 사례를 다루지는 않는 것 같습니다.

Istio 사이드카에도 의존하는 로그를 내보내는 사이드카의 경우를 고려하십시오. Istio 사이드카가 먼저 종료되면 일부 민감한 로그를 내보내지 못할 수 있습니다.

보다 일반적인 접근 방식은 컨테이너 간에 명시적 종속성을 정의하는 것입니다. 그들이 사이드카이든 아니든 상관없이.

대신 이러한 API 정의에 대해 어떻게 생각하십니까?

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

@rubenhak 정말 빨리 지저분해집니다. 종속성이 명확하게 진행되기 위해 충족되어야 하는 것은 무엇입니까? 시작됨과 준비됨 사이에 종종 갭이 있는데, 내가 생각하기에 extendsOn은 그 API가 다루지 않는 것에 대해 정말로 신경을 쓸 것입니다.

@kfox1111 제안된 디자인은 메인 컨테이너를 시작하기 위해 사이드카가 시작되고 준비되었는지 어떻게 결정합니까? 내가 제안하는 유일한 차이점은 컨테이너를 "사이드카"로 표시하는 대신 종속성을 정의하는 보다 일반적인 방법을 사용하는 것입니다.

나는 extendsOn 이 기준을 지정해야 한다고 생각하지 않는다. 종속 컨테이너에 지정할 수 있습니다. readyinessProbe 및/또는 livenessProbe 로 충분하지 않습니까? 그렇지 않은 경우 startupProbe 가 있을 수 있습니다. 성공하면 종속 컨테이너를 시작할 수 있음을 나타냅니다.

안녕하세요 @Joseph-Irving 저는 v1.18 문서 섀도우 중 한 명입니다.
이 개선 사항(또는 v1.18에 대해 계획된 작업)에 새 문서(또는 기존 문서 수정)가 필요합니까? 그렇지 않은 경우 1.18 Enhancement Tracker Sheet를 업데이트할 수 있습니까(또는 알려주시면 업데이트하겠습니다)

그렇다면 2월 28일 금요일까지 k/website(branch dev-1.18)에 대한 PR을 찾고 있으며 현재로서는 자리 표시자 PR일 ​​수 있습니다. 질문이 있으면 알려주세요!

안녕하세요 @irvifa https://github.com/kubernetes/website/pull/19046에 자리 표시자 PR을 올렸습니다.

안녕하세요 @Joseph-Irving 빠른 응답에 감사드립니다!

@rubenhak - 종속성에 대한 전체 그래프가 있으면 꽤 빨리 지저분 해질 수 있다는

@rgulewich , 좀 더 자세히

순서에 대한 아이디어는 괜찮지만 대부분의 사이드카는 승인 컨트롤러를 사용하여 주입되기 때문에 순서의 정확성을 보장하기가 정말 어렵습니다. 간접화가 필요합니다.

@rubenhak 컨테이너의 종속성 순서에 주기가 있을 수 있습니다. k8s/kubelet은 주기를 깨고 컨테이너를 시작/중지할 순서를 어떻게 결정합니까? 큰 소리로 생각하면 API 측 유효성 검사가 될 수 있습니다.

안녕하세요 @Joseph-Irving

1.18의 코드 동결은 2020년 3월 5일 이라는 친근한 알림입니다.

코드 고정을 추적하는 동안 이 개선 사항을 완료하기 위해 작업 중인 PR을 나열/링크하십시오!

안녕하세요 @jeremyrickard ,

https://github.com/kubernetes/kubernetes/pull/80744 를 추적하는 홍보입니까?
이 PR에는 API 변경 사항이 포함되어 있지만 검토가 완료되면 커밋이 위의 PR에 병합됩니다. https://github.com/kubernetes/kubernetes/pull/79649

@rubenhak 컨테이너의 종속성 순서에 주기가 있을 수 있습니다. k8s/kubelet은 주기를 깨고 컨테이너를 시작/중지할 순서를 어떻게 결정합니까? 큰 소리로 생각하면 API 측 유효성 검사가 될 수 있습니다.

@bjhaid , API 측에서 유효성 검사를 수행할 수 있습니다. 루프 감지는 DFS 탐색과 마찬가지로 선형 시간 복잡도를 가진 간단한 알고리즘입니다.

사이드카 삽입 후 유효성 검사를 다시 실행해야 할 수도 있습니다.

나는 이것에 대해 잠시 동안 생각했습니다... 의존성과 관련된 대부분의 문제는 정말로 요약됩니다. 저는 메시를 서비스하는 것이라고 생각합니다. (누군가 다른 예를 생각할 수도 있지만)

서비스 메시 프록시는 다른 무엇보다 먼저 시작하고 준비해야 하고 다른 작업 후에 종료해야 하는 사이드카입니다. 그들은 오래 실행되므로 초기화 컨테이너보다 사이드카에 가깝습니다.

그러나 initContainers는 이상적으로는 모두 서비스 메시도 사용할 수 있어야 합니다.

그러나 initContainers는 다른 사이드카 컨테이너를 초기화해야 할 수도 있습니다.

초기화 컨테이너, 사이드카 컨테이너 및 일반 컨테이너를 포함하는 일종의 복잡한 종속성 시스템을 설계할 수 있지만 두 가지 클래스의 사이드카만 있어야 합니까? 일반 사이드카와 네트워크 사이드카?

네트워크 사이드카는 처음부터 모두 준비되어 있어야 합니다. 서비스 메시 프록시는 여기로 이동합니다.
init 컨테이너는 순서대로 다음에 실행됩니다.
사이드카가 모두 시작되고 준비됩니다. 여기에는 인증 프록시, 로거 등과 같은 항목이 포함될 수 있습니다.
일반 컨테이너가 시작되고 준비됩니다.

분해는 반대입니다.

이렇게 하면 서비스 메시가 컨테이너 주문과 관련하여 가지고 있는 것처럼 보이는 모든 문제를 계속 해결하면서 종속성 문제를 제거할 수 있습니까? 나는 그렇게 생각하고 있습니까?

@kfox1111 , 이제 Vault는 사이드카를 사용하여 비밀 주입을 수행합니다. 어떤 클래스에 맞춰야 할까요? 또한 경우에 따라 볼트는 서비스 메시에 의존하거나 그 반대일 수 있습니다.

내가 말하는 것은 그러한 디자인이 결국 10개의 사이드카 클래스로 폭발할 것이라는 것입니다. 이러한 접근 방식은 상황이 어떻게 실행되어야 하는지에 대한 더 강력한 의견을 의미합니다. 사람들은 응용 프로그램을 시작하는 데 필요한 순서를 달성하기 위해 클래스로 해킹을 시작했습니다.

이러한 클래스의 유일한 목적이 순서를 정의하는 것이라면 명시적으로 수행하지 않는 이유는 무엇입니까?

귀하의 질문에 답하면 그러한 디자인이 일부 사용 사례를 다루지만 볼트 사이드카, 로깅 사이드카 등과 같은 다른 경우에는 도움이 되지 않습니다. 이것은 이미 원래 기능의 재설계에 대한 제안입니다. 이것은 두 번째 시도이기 때문에 이번에 올바르게 만들 가치가 있습니다.

나는 종속성이 얼마나 복잡한지 모릅니다. 이에 대해 더 자세히 설명해 주시겠습니까? 종속성은 YAML 정의를 더 명확하게 만들고 숨겨진 논리가 없습니다. 하드코딩된 클래스로 접근하려면 숨겨진 논리와 네트워킹 사이드카가 다른 사이드카 이후에 실행되어야 하는 이유를 설명하는 훨씬 더 많은 문서가 필요합니다.

Container에 필드를 도입하면 어떻게 될까요?

    // +optional
    Priority int

이 필드는 동일한 유형(사이드카, 일반)의 컨테이너 간에 유효합니다.
사이드카 컨테이너의 경우 우선 순위가 더 높은 사이드카 컨테이너가 먼저 인스턴스화되고 마지막에 해체됩니다.

@tedyu , 의존성은 "우선순위"에 비해 훨씬 더 많은 메타데이터와 가치를 가집니다. 주어진 종속성 https://www.geeksforgeeks.org/find-the-ordering-of-tasks-from-given-dependencies/ 에 따라 우선 순위를 생성하려면 30줄의 C++ 코드가 필요합니다. 그 반대는 불가능합니다.

또 다른 이점은 주어진 종속성 그래프에서 특정 컨테이너를 동시에 시작할 수 있다는 것입니다.
다음 예에서 "A -> B, B -> C, D -> C" 컨테이너 B와 D는 C가 초기화되면 동시에 시작할 수 있습니다. 구현이 이를 지원해야 한다고 말하는 것은 아니지만 적어도 API가 그러한 정의를 허용한다면 매우 가치가 있을 수 있습니다.

정수 우선 순위는 제대로 작동하지 않습니다. 사람들은 CSS z-index 속성(예 -9999 )과 마찬가지로 표준화되지 않은 모든 종류의 숫자를 사용합니다.

@rubenhak 이 시점에서 제안하는 것은 기본적으로 이 KEP에서 설명하는 것과 완전히 다른 기능이며, 작은 수정이 아니라 완전히 다시 작성하는 것입니다. 이전에 이 기능에 동의한 모든 사람(모든 당사자가 이를 승인하는 데 1년이 소요됨)을 재평가하도록 해야 합니다.
이러한 기능에 대해 열정을 갖고 있다면 고유한 KEP를 만들고 다양한 SIG에 가져가 피드백을 받는 것이 좋습니다.

이 제안이 2018년에 시작되었을 때 종속성 그래프에 대한 아이디어가 길게 논의되었지만 결론은 만장일치로 더 많은 사용 사례를 가능하게 하지만 충분히 강력하지 않으며 추가된 복잡성은 가치가 없다는 점에서 만장일치였습니다.

나는 당신이 설명하는 것을 구현하는 데 필요한 변경 정도를 다소 과소 평가하고 있다고 생각합니다. 그러나 그것이 생각하는 것만큼 간단하다면 Kubernetes에서 이 작업에 대한 개념 증명을 직접 생성하고 이를 SIG에 제출하여 사례를 강화할 수 있습니다.

이 KEP는 아직 GA 기능이 아닙니다. KEP가 승인되고 구현되면 이 기능을 제거할 수 있습니다. 그것들은 아직 상호 배타적이지 않습니다.

이 변경 사항은 모든 단일 사용 사례에 대한 완벽한 솔루션이 아닐 수도 있지만 대부분의 경험을 극적으로 개선하고 구현에 대해 1년 더 논의하기 위해 이를 병합하는 것이 훨씬 더 낫다고 생각합니다.

KEP가 승인 및 구현되면 이 항목을 제거할 수 있습니다. 그것들은 아직 상호 배타적이지 않습니다.

그들은 _항상_ 상호 배타적입니까?

나는 이 기능에 가치가 있는지 스스로에게 묻고 있습니다. 더 명시적인 컨테이너 시작/종료 순서(내 생각에 훌륭할 것입니다)가 미래의 또 다른 개선 사항을 통해 활성화된다면... 그리고 저는 그렇다고 생각합니다.

컨테이너를 init, sidecar 또는 "일반"으로 분류하는 것으로 암시되는 모든 시작/종료 순서는 이러한 분류도 _기타_ 유용하고 컨테이너의 원하는 동작과 관련이 없는 측면도 표현하지 않습니까?

예를 들어 restartPolicy != Always 있는 포드(아마도 작업을 구현하는 포드)에서는 사이드카로 지정된 컨테이너가 완료 상태로 들어가는 포드와 관련이 없다는 것이 유용합니다.

@kfox1111 , 이제 Vault는 사이드카를 사용하여 비밀 주입을 수행합니다. 어떤 클래스에 맞춰야 할까요? 또한 경우에 따라 볼트는 서비스 메시에 의존하거나 그 반대일 수 있습니다.

볼트와 같은 항목에 사이드카/초기화 컨테이너가 필요하지 않도록 csi 임시 드라이버를 통해 작업했습니다. 작업 중인 볼트 드라이버가 있다고 생각합니다.

emptyDir이 있는 일반 사이드카가 네트워크 사이드카를 사용해야 하는 사이드카에 적합한 것처럼 보이지만?

@Joseph-Irving, 나는 결코 이 KEP가 들어오는 것을 막으려는 것이 아닙니다. 당신이 거의 2년 전에 그것을 시작했고 이것이 출시되기를 기다리는 사람들이 꽤 있다는 것을 알고 있습니다.

종속성 그래프와 관련된 이전 논의에 대한 링크가 있습니까?

안녕하세요 @Joseph-Irving

2020년 3월 5일 에 코드 동결이 매우 빨리 마감됨을 알려드립니다. 아직 PR이 병합되지 않은 것 같습니다. 이 개선 사항에 대한 코드 동결을 계속 진행 중인 것 같습니까?

@jeremyrickard님 , API 검토(https://github.com/kubernetes/kubernetes/pull/79649)가 기본적으로 완료되었습니다. 우리는 해당 PR을 닫고 모든(API 및 구현)이 하나의 PR에 병합될 수 있도록 구현 PR로 완전히 이동할 것입니다.

구현 PR(https://github.com/kubernetes/kubernetes/pull/80744)을 철저히 검토하였으므로 최종 승인을 위해 sig-node 승인자를 구하려고 합니다.

이것이 코드 동결 시간에 발생하는지 여부는 제가 말하기가 다소 어렵습니다. 제 시간에 일부 승인자의 관심을 끌 수 있는지 여부에 따라 크게 달라집니다.

이것이 코드 동결로 들어가는 것을 보고 싶습니다. 그것은 https://github.com/istio/istio/issues/7136에 대한 Istio의 솔루션을 더 간단하고 더 좋게 만들 것입니다.

1.18에 들어가는 것에 대한 움직임이 있습니까? istio 사이드카가 빠르게 실행되는 작업에서 예상대로 작동하려면 필요한 것 같습니다.

다양한 방법으로 서명 노드 승인자에게 연락을 시도했지만 응답이 없었습니다. 그래서 저는 이것이 1.18에 포함될 것이라고 낙관하지 않습니다.

@Joseph-Irving #pr-reviews slack 채널은 이러한 경우를 위해 만들어졌습니다. 당신은 그것을 시도 했습니까? 홍보 리뷰에 대한 에스컬레이션을 받는 방법입니다. (나는 거기에서 그것을 보지 못했다)

안녕하세요 @Joseph-Irving ,

이제 코드 동결이 며칠 남지 않았습니다. 리뷰어 대역폭에 따라 이것을 1.19로 연기하시겠습니까? 아니면 시도하고 밀어?

안녕하세요 @jeremyrickard ,

아무도 이 PR을 1.18에 병합하는 것에 대해 답장을 보내지 않았으므로 그런 일이 일어날지 매우 의심스럽습니다.

우리는 1.19로 연기할 수 있지만 그렇게 하는 것이 의미가 있는지 궁금해지기 시작했습니다.
이 KEP는 거의 2년 동안 비행 중이었고(원래 알파 목표는 1.15) 문제의 PR은 거의 1년 동안 공개되었으며 "검토자 대역폭"이 전혀 없습니다.
나는 정중하게 이메일을 보내고, 여유를 부리고, 시그미팅에 갔고, 심지어 리뷰를 받기 위해 직접 사람들을 찾았지만 진전이 거의 없었습니다.
내가 얻을 수 있었던 모든 리뷰는 사소한 변경 사항만을 제안했습니다. 대규모 재작성이 요청된 것과 같지 않고 PR은 기본적으로 모두 1년 전과 동일하며 좀 더 세련되었습니다.
그들이 나에게 응답할 때까지 내가 공격적으로 사람들에게 매일 핑을 대는 것이 의도된 것인지는 모르겠지만 그것은 정말로 내가 편안하게 할 수 있는 일이 아닙니다.

문제는 아무도 실제로 이 기능에 관심을 두지 않는다는 것입니다. 이 기능을 추진하는 사람은 저뿐이고 SIG의 누구도 이 기능을 확인하는 데 관심이 없는 것 같습니다. 알파에 들어가는 데 2년이 걸린다면 베타/GA에 도달하는 데 얼마나 걸립니까? (대부분의 사람들이 실제로 이것을 사용할 수 있을 때)

실망스럽게도 이 기능을 도입하는 데 더 많은 커뮤니티와 최종 사용자의 관심이 있는 것 같습니다. 처음에 이 작업을 수행한 이유는 SIG에 문제를 해결할 것인지 물어보고 문제를 보았기 때문입니다. "우리는 능력이 없지만 당신이 할 수 있게 되어 기쁩니다"라고 말했습니다.
그래서 나는 그들이 요구하는 모든 것을 수행하고 KEP를 작성했으며 모든 당사자의 승인을 얻었고 모든 코드와 모든 테스트를 작성했으며 각 릴리스가 통과할 때마다 지속적으로 최신 상태를 유지했지만 여기까지 왔습니다.

이걸 미룰 때마다 사람들을 많이 실망시키는 것 같아, 이게 다 내 잘못이야? 코드가 너무 끔찍해서 아무도 언급하지 않습니까? 내가 관심을 끌기에 충분히 공격적이지 않습니까?
혼자서는 이 일을 끝낼 수 없다는 생각이 들고, 이 죽은 말을 이기는데 조금 지쳐갑니다.

긴 욕설에 대해 유감스럽게 생각합니다(그 문제에 대해 개인적으로 Jeremy 또는 그 누구에게도 개인적으로 지시한 것이 아님). 그러나 이것은 이제 오랫동안 천천히 제 영혼을 갉아먹고 있습니다.

실망스럽게도 이 기능을 도입하는 데 더 많은 커뮤니티와 최종 사용자의 관심이 있는 것 같습니다. 처음에 이 작업을 수행한 이유는 SIG에 문제를 해결할 것인지 물어보고 문제를 보았기 때문입니다. "우리는 능력이 없지만 당신이 할 수 있게 되어 기쁩니다"라고 말했습니다.

@Joseph-Irving 이에 대해. 활성 사용자로서 관심이 있기 때문에 이 스레드를 보고 있습니다(내 동료 두 명도 마찬가지입니다). 문제, 풀 리퀘스트, 여유 채널 또는 시그에 대한 활동은 이 기능에 대한 가장 좋은 관심 지표가 아닐 수 있습니다.

@dims 어쩌면 당신이 약간의 빛을 비출 수 있습니까?

@thockin ~1년 전에 Kubernetes 팟캐스트에서 인터뷰하는 것을 들었고 Kubernetes에 기여하는 것에 대해 이야기했습니다. 이 사이드카 KEP가 1.16에 도달하지 못한 것이 정말 안타까웠던 것은 다른 팟캐스트 에피소드에서 당신이나 다른 누군가였을 것입니다. 자, 여기 다시 왔습니다.

이 문제는 예를 들어 의 직원이 아닌 경우 기여하기가 얼마나 어려운지를 보여주는 대표적인 예인 것 같습니다. Google, RedHat 또는 기타 대기업.

Slack에서도 검토하는 데 도움을 요청했지만 @thockin 이 명시적으로 보류하고

나는 임시 csi 드라이버 기능에 많은 시간을 할애했습니다. 그것을 통과하는 것도 마찬가지로 실망스러웠고 많은 지연과 재설계를 거쳐 성공할지 확신할 수 없었던 때가 있었습니다. 그래서 나는 당신의 고통을 느낍니다. 고통을 덜 수 있는 방법을 찾을 수 있다면 좋을 것입니다. 즉, 몇 가지 주요 릴리스를 놓치고 결국에는 그것을 얻었습니다. 그러니 제발 포기하지 마세요/희망을 버리지 마세요! 배는 회전하기 어려울 수 있지만 결국에는 회전합니다.

네트워크 사이드카에 의존하는 모든 종류의 토폴로지를 실행하는 사람은 이 KEP가 잠재적으로 해결할 수 있는 컨테이너 시작/종료 순서 문제를 겪을 가능성이 큽니다. 이 티켓에서 "Istio"에 대해 Ctrl-F를 누르면 컨테이너 주문과 관련된 많은 성가신 사항을 볼 수 있습니다.

여기에 Istio 유지 관리자가 있습니까? 많은 사람들이 Google 직원이며 내부적으로 K8 사용자에게 더 많은 영향력을 행사할 수 있습니다.

Istio / K8 상점으로서, @Joseph-Irving이 상륙하는 것을 절대적으로 응원합니다! ✊❤️

여기까지 사이드카를 만들어준 @Joseph-Irving에 대한 찬사입니다.

사이드카 수명 주기 관리의 경우에도 모든 배치 작업에는 이 기능이 필요하거나 Kubernetes가 작동하지 않습니다. 그래서 우리는 코드 리뷰를 돕고 피드백을 제공하는 데 많은 시간을 할애했습니다!

이 때문에 우리는 한동안 k8을 포크해 왔으며 공식적으로 지원되는 그러한 중요한 기능을 보기를 정말로 고대하고 있습니다.

Istio + Kubernetes 상점으로서 우리도 이 기능을 간절히 기다리고 있습니다. 그리고 릴리스에서 릴리스로 미끄러지는 것에 점점 더 좌절감을 느낍니다. 우리는 작업 워크로드에서 사이드카를 죽이기 위해 해킹에 의존해야 하는 것을 기쁘게 생각하지 않습니다. 우리의 필요에 따라 이것은 1년이 훨씬 넘는 기간 동안 Kubernetes에서 가장 중요한 단일 기능이었습니다.

@thockin 위에서 명시적으로 보류했다고 보고되었습니다. 이유를 설명해 주시겠습니까?

이를 기다리고 있는 Linkerd 사용자들도 많이 있습니다. @Joseph-Irving 잠시만 기다려 주십시오. 우리는 당신을 응원합니다.

여기 있는 모든 사람들이 보았는지 확실하지 않지만 kubecon 비디오를 파헤치고 본 후 Lyft가 이와 유사한 작업을 수행했다는 것을 알았습니다. 다음은 kubernetes 포크에서 언급된 커밋입니다. https://github.com/lyft/kubernetes/commit/ba9e7975957d61a7b68adb75f007c410fc9c80cc

Istio + Kubernetes 상점으로서 우리도 이 기능을 간절히 기다리고 있습니다. 그리고 릴리스에서 릴리스로 미끄러지는 것에 점점 더 좌절감을 느낍니다.

저는 잠재적인 istio 사용자이지만 이와 같은 기능을 기다리기 때문에 잠시 옆으로 물러났습니다. 하지만 위의 논의 중에, 여기서 논의된 사이드카 기능만으로는 istio 사이드카가 워크플로에 대해 가지고 있는 모든 문제를 해결할 수 없다고 생각하게 만드는 것들을 계속 보게 됩니다. 그래도 도움이 될 수 있습니다. 이것이 중단된 이유의 일부라고 생각합니다.

istio cni 드라이버를 사용할 때 사이드카에서 istio를 실행하는 방법은 무엇입니까? 네트워크에 도달하려는 초기화 컨테이너는 여전히 istio 문서에 설명된 대로 제대로 작동하지 않을 것이라고 생각합니다.

따라서 네트워크 사이드카가 자체적인지 위의 질문입니다.

이 문제는 예를 들어 의 직원이 아닌 경우 기여하기가 얼마나 어려운지를 보여주는 대표적인 예인 것 같습니다. Google, RedHat 또는 기타 대기업.

하! 당신이 모르는 것은 그 사람들도 때때로 붙어 있다는 것입니다!

죄송합니다. 변명거리가 있지만 귀찮으니 귀찮게 하지 않겠습니다.

설명:
접근 방식에 대한 피드백을 얻기 위해 이것을 알파로 병합해서는 안 된다는 의미가 아닙니다. 일반적으로 나는 그것이 소리라고 생각합니다. 서비스 메시와 같은 사용 사례에는 제대로 다루지 못하는 몇 가지 구멍이 있다고 생각합니다. 그러나 그것이 우리가 다루지 않는 다른 모든 사용 사례를 찾을 수 있도록 최대한 빨리 이 기능을 가져오는 것을 차단하는 이유는 아니므로 기능의 베타 버전이 모든 사람에게 잘 작동하도록 할 수 있습니다. 이것이 바로 IMO의 알파입니다.

저는 제가 한 일, 특히 이것이 기존 서비스 메시 문제에 대한 은총알이 되기를 바라는 사람들에게 언급한 것입니다. 제안된 알파가 그 특정 문제를 완전히 고칠 것이라고 생각하지 않습니다. 그러니 아직 희망을 너무 높이지 마십시오. 그러나 이 기능이 아직 모든 사람을 지원하지 않는다는 이유로 차단하지 마십시오.

나는 예외를 요청했습니다. 우리가 이것을 얻을 수 있는지 봅시다:
https://groups.google.com/d/msg/kubernetes-sig-release/RHbkIvAmIGM/nNUthrQsCQAJ

이 사이드카 KEP가 1.16에 도달하지 못한 것이 정말 안타까운 것은 다른 [Kubernetes Podcast] 에피소드에서 당신이나 다른 누군가였을 것입니다.

Lachie Evenson과 함께 에피소드 Guinevere Saenger 와 함께 에피소드 83을 참조하십시오. 나는 이번 주 에 이 문제를 해결하기 위해 PR 검토가 필요하다고 말했습니다. 우린 할 수있어!

여기에 Istio 유지 관리자가 있습니까? 많은 사람들이 Google 직원이며 내부적으로 K8 사용자에게 더 많은 영향력을 행사할 수 있습니다.

@duderino 와 @howardjohn 은 이미 이 스레드에 댓글을 달았습니다.

명확하게 하려면 병합해야 합니다.
쿠버네티스/쿠버네티스#79649
쿠버네티스/쿠버네티스#80744

추적해야 하는 다른 PR이 있습니까?

감사 해요!

• 개선팀

매우 감사한 지원 메시지(공개 또는 비공개)를 게시한 모든 사람에게 큰 감사를 드립니다 ❤️

확장 요청을 수락한 릴리스 팀을 포함하여 이를 1.18에 적용하려는 커뮤니티 구성원의 용감한 노력이 있었지만 안타깝게도 1.19로 연기하기로 결정했습니다. https://github.com/kubernetes/kubernetes/pull/80744#issuecomment -595292034 댓글부터 관련 대화를 볼 수 있습니다.

비록 1.18에 들어가지 않았지만 이것은 꽤 오랜 시간 동안보다 지난 며칠 동안 훨씬 더 많은 관심을 받았기 때문에 이 모멘텀이 1.19로 이어지기를 바랍니다.

cc @jeremyrickard , @kikisdeliveryservice

좋은 물건 @Joseph-Irving, 당신의 좌절감 중 일부가 가치 있고 경청한 것 같습니다. 기다려 주셔서 감사합니다.

/마일스톤 v1.19

안녕 모두. 우리 그룹은 지난 주에 이 주제에 대해 토론했습니다.

먼저 이곳에서 일어난 일에 대해 사과드립니다. 우리는 그것에 대해 행복하지 않습니다.

이 PR 및 관련 KEP는 프로젝트가 더 잘할 수 있는 여러 가지를 밝혀냈습니다. 우리는 사회적, 절차적, 기술적 문제를 분리하고자 합니다.

사회적으로 이 기능은 서로를 기쁘게 하려는 우리의 욕망에 희생되었습니다. Derek은 SIG 내에서 표명된 유보에도 불구하고 KEP를 승인했습니다. Clayton과 Tim이 이를 추진했기 때문입니다. 우리 모두는 서로를 신뢰하지만 분명히 우리가 항상 "아니오"라고 말할 수 있다고 느끼지는 않습니다. 우리는 모두 똑같은 일을 했기 때문에 이것을 압니다. 우리 중 누구도 다음 위대한 아이디어를 방해하는 사람이 되고 싶어하지 않습니다.

서로를 신뢰한다는 것은 우리가 "아니오"라고 말할 수 있다는 믿음과 누군가가 "아니오"라고 말할 때 그들이 그렇게 하는 데 합당한 이유가 있다는 믿음을 포함해야 합니다. 이 기술 영역은 SIG에 걸쳐 있으며 궁극적으로 문제를 해결하는 sig-node가 아직 지원하기가 쉽지 않은 새로운 기능을 수용하도록 압력을 가해서는 안됩니다. 이것은 특히 Tim, Derek 또는 Clayton에 관한 것이 아닙니다. 그러나 모든 고위 승인자 및 SIG 리드 및 "상급" 기고자입니다.

이 기능은 또한 KEP에 대한 절차상의 불확실성의 희생양이 되었습니다. KEP 검토자로서 코드 검토자가 되어야 합니까? 코드 검토자에게 위임하려면? 아니면 그냥 KEP를 읽기 위해? KEP가 릴리스에 걸쳐 있으므로 특정 릴리스 범위에 예산이 책정된 일련의 변경 사항에 대해 셰퍼드를 사용할 수 있도록 하는 방법은 무엇입니까? KEP가 SIG에 걸쳐 있는 경우 SIG 전체에 시간을 어떻게 할당하고 할당합니까? 우리는 이것을 명확히 할 필요가 있습니다. 우리는 KEP 프로세스에서 역할 정의를 강화하기 위해 일부 KEP 변경 제안(KEP KEP)에 대해 작업할 것입니다.

기술적으로 이 기능은 시간과 관심의 희생양이 되었습니다. 검토자가 검토할 시간이 충분하지 않았거나 단순히 우선 순위가 높지 않았습니다. 앞뒤 논의에는 시간이 걸립니다. 문제 공간에 대한 상황과 이해는 시간이 지남에 따라 변합니다.

더 많은 사용자가 Kubernetes를 채택함에 따라 시그니처 노드에 보고되는 이상한 엣지 케이스 또는 플레이크의 수가 증가하는 것을 봅니다. Pod 수명 주기는 Kubernetes의 핵심이므로 해당 하위 시스템에 대한 변경 사항은 신중하게 수행해야 합니다. 새로운 기능을 병합하는 우리의 능력은 안정성을 향상시키려는 우리의 열망과 균형을 이루어야 합니다. 오늘날 우리가 Pod 수명 주기에 대해 생각하는 방식은 이 기능이 시작되었을 때 생각했던 방식과 약간 다릅니다. 이것은 어떤 식으로든 이에 이르는 사용 사례를 감소시키지 않지만 장기 실행 KEP를 시간이 지남에 따라 주기적으로 재검토해야 함을 시사합니다.

우리는 Pod 수명 주기에 대해 생각하는 약간의 첫 번째 원칙을 수행해야 한다고 생각합니다. 우리가 진정으로 원하는 것은 무엇입니까? 우리는 너무 많은 복잡성에 빠지지 않으려고 노력했지만 그 복잡성을 여러 단계로 나누었을 뿐이며 최종 결과는 정면으로 맞서는 것보다 더 복잡할 수 있습니다.

이 PR 및 관련 KEP에 대해 의미하는 바는 무엇입니까? 100% 확신할 수는 없습니다. 이것은 아마도 우리가 아직 이것을 통과해서는 안된다는 것을 의미합니다.

Derek은 종료 순서에 대해 몇 가지 우려를 제기했습니다. KEP는 지금은 범위를 벗어났지만 약간의 망설임이 있습니다. 우리는 이미 노드 종료 시 정상적인 종료를 존중하지 않으며 이는 많은 사용자를 놀라게 했습니다. 이게 한전의 잘못은 아니지만 '참작할 수 있는 상황'이라고 합시다. 누군가가 사이드카를 사용하여 포드를 "정리"하는 경우(예: 캐시된 로그를 로깅 서비스로 배출하기 위해) 종료와 관련된 명확하고 유용한 의미 체계를 (합리적으로) 예상할 것입니다. 이는 이 KEP가 보장하지 않습니다.

Tim은 init-sidecar가 하나의 것이 되어야 할 필요가 있고 그것은 옳지 않다고 생각합니다. 그는 과거에 그 걱정을 포기했지만 여전히 그를 괴롭히고 있습니다.

우리는 포드 라이프사이클에 대한 중기 목표가 무엇인지, 그리고 이를 수행하기 위해 원하는 것이 무엇인지 정의하는 데 도움이 되는 SIG 노드가 필요합니다. 우리가이 목표를 향해 증분 단계에 동의 할 수 있다면, 우리는 그것을 차단을 해제 할 수 있습니다,하지만 우리는 목표를 알지 못한다면, 우리는 아마 우리의 헤드 라이트를 통해 운전하고 있습니다.

우리 모두 이것이 악취가 난다는 것을 처음으로 말하도록 합시다. 우리는 실제 문제 진술, 열정적인 기여자 및 선의의 유지 관리자를 보유하고 있으며 결국 ... 여기까지 왔습니다. Tim은 브레인스토밍과 디자인을 돕기 위해 시간을 할애할 것입니다. Derek은 현재 포드 수명 주기 동안 노드 종료 작업을 추진하여 더 성장할 수 있는 안정적인 기반을 확보할 것입니다. 우리는 계획되지 않은 기계 고장에 직면했을 때 우리가 할 수 있는 것과 할 수 없는 것을 매우 신중하게 지정해야 합니다.

감사 해요,
클레이튼, 데이비드, 던, 데릭, 존, 팀

앞으로의 움직임에 박차를 가하기 위해: Derek 또는 Dawn - 보다 전체적인 포드 및 컨테이너 수명 주기에 대해 브레인 스토밍을 할 시간을 낼 수 있는 서명 노드가 있습니까?

@thockin 은 이것을 sig-node 의제에 추가할 것입니다.

@thockin @derekwaynecarr 이게 왜 안들어가 는지 tl;dr이 뭐죠?

한 줄 개선 설명: 이제 컨테이너를 사이드카로 표시하여 일반 컨테이너보다 먼저 시작하고 다른 모든 컨테이너가 종료된 후에 종료할 수 있습니다.

서비스 메시 사이드카의 이 새로운 시대에 삶을 더 쉽게 만들어 줄 것 같습니다.

또한 사이드카가 기본 앱 컨테이너보다 먼저 시작되고 오늘 기본 앱 컨테이너가 종료된 후 종료되도록 하는 권장 사항이 있습니까?

... 왜 이것이 들어갈 수 없는지에 대한 tl;dr은 무엇입니까?

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

이 PR 및 관련 KEP에 대해 의미하는 바는 무엇입니까? 100% 확신할 수는 없습니다. 이것은 아마도 우리가 아직 이것을 통과해서는 안된다는 것을 의미합니다.

Derek은 종료 순서에 대해 몇 가지 우려를 제기했습니다. KEP는 지금은 범위를 벗어났지만 약간의 망설임이 있습니다. 우리는 이미 노드 종료 시 정상적인 종료를 존중하지 않으며 이는 많은 사용자를 놀라게 했습니다. 이게 한전의 잘못은 아니지만 '참작할 수 있는 상황'이라고 합시다. 누군가가 사이드카를 사용하여 포드를 "정리"하는 경우(예: 캐시된 로그를 로깅 서비스로 배출하기 위해) 종료와 관련된 명확하고 유용한 의미 체계를 (합리적으로) 예상할 것입니다. 이는 이 KEP가 보장하지 않습니다.

[...]

우리는 포드 라이프사이클에 대한 중기 목표가 무엇인지, 그리고 이를 수행하기 위해 원하는 것이 무엇인지 정의하는 데 도움이 되는 SIG 노드가 필요합니다. 이것이 목표를 향한 점진적인 단계라는 데 동의할 수 있다면 차단을 해제할 수 있지만 목표를 알지 못한다면 아마도 헤드라이트를 과도하게 운전하고 있을 것입니다.

정중하게, 리드가 이 문제를 우선적으로 분류할 계획이 있는지 궁금합니다. @Joseph-Irving은 이것에 엄청난 양의 작업을 했으며 그의 솔루션에 만족했을 엄청난 수의 사람들이 이것을 거부한 사람들로부터 더 나은 솔루션을 듣기를 열망하고 있습니다.

최소한 몇 가지 면에서 아쉬운 부분이 있긴 하지만, 실전에서 어떤 이슈가 나올지 알아보기 위해 알파로 진입하는 것이 여전히 합리적이라고 생각합니다. 이것을 병합할 수 있습니까? 문제로 인해 베타가 되지 않을 수 있으므로 초기 알파가 만들어지기 전에 완벽해지는 것이 중요하다고 생각하지 않습니다.

sig-node 의제에 이것을 추가합니다.

@thockin @derekwaynecarr 현재 상태에 대한 업데이트가 있습니까? 나는 시그니처 노드 회의 노트를 살펴 보았고 이에 대해 아무것도 보지 못했습니다.

이 스레드에는 많은 사용 사례에서 중요하므로 이를 구현하는 데 기꺼이 시간을 할애하는 많은 개발자가 있습니다(KEP 자체에는 다른 KEP보다 2.5배 많은 :+1:이 있습니다). 이를 위해 우리는 무엇을 할 수 있습니까? 이 영역의 안정성을 위한 전제 조건 목록이 있는 경우 달성해야 할 릴리스가 많다고 해도 적극적으로 작업을 시작할 수 있다면 오늘날의 위치에서 크게 개선될 것입니다.

안녕하세요 @Joseph-Irving @thockin @khenidak @kow3ns -- 1.19 개선 사항 리드, 이 개선 사항이 1.19에서

릴리스의 이 부분을 포함하려면:

1. KEP PR은 구현 가능한 상태로 병합되어야 합니다.
2. KEP에는 테스트 계획이 있어야 합니다.
3. KEP에는 졸업 기준이 있어야 합니다.

현재 출시 일정은 다음과 같습니다.

• 4월 13일 월요일: 1주차 - 출시 주기 시작
• 5월 19일 화요일: 6주차 - 개선 사항 동결
• 6월 25일 목요일: 11주차 - 코드 동결
• 7월 9일 목요일: 14주차 - 문서를 작성하고 검토해야 합니다.
• 8월 4일 화요일: 17주차 - Kubernetes v1.19.0 릴리스

@palnabarun , 이 의견 https://github.com/kubernetes/enhancements/issues/753#issuecomment -597372056에 따라 이 KEP는 무기한 보류되었으므로 1.19에서 졸업하지 않습니다.

상황을 명확히 해주신 @Joseph-Irving에게 감사드립니다. :+1:

당신의 노력에 감사드립니다!

이 사실을 알고 싶어 하는 모든 사람들과 @Joseph-Irving에게 다시 한 번 이 상황에 대해 개인적으로 매우 유감스럽게 생각합니다. 나도 이것(또는 이와 유사한 것)을 원하지만 문제의 사실은 sig-node가 지금 당장 하는 사람들보다 해야 할 일이 더 많고 그들은 이것을 고려할 준비가 되어 있지 않다는 것입니다.

짜증난다. 알겠어. 정말 정말 해요.

사람들이 도울 수 있는 가장 좋은 방법은 시그노드로 뛰어들어 코드 검토 및 문제 분류를 수행하고, 버그와 테스트를 수정하고, 시그니처 노드 전문가가 더 많은 용량과 그러한 변화에 대한 확신.

sig-node는 지금 사람들보다 해야 할 일이 더 많습니다.

이해했다. 우리는 내부적으로 sig-node의 용량 요구 사항을 강조하여 홍보해 왔습니다. 우리는 sig-node OSS 자원 봉사자를 데려오고 멘토링하고 있습니다. 일부는 새로운 경험을 했으며 모두 이 분야에서 일하고 싶어했습니다(지금까지 4명). 귀하의 의견을 인용 하겠습니다 @thockin , 감사합니다!

/마일스톤 클리어

사람들이 도울 수 있는 가장 좋은 방법은 시그노드로 뛰어들어 코드 검토 및 문제 분류를 수행하고, 버그와 테스트를 수정하고, 시그니처 노드 전문가가 더 많은 용량과 그러한 변화에 대한 확신.

@thockin 리포지토리, 메일링 리스트, 가이드 등과 같은 링크를 제공할 수 있습니까? 그것은 사람들이 시그노드에 효과적으로 참여하는 방법에 대한 아이디어를 얻는 데 도움이 될 것입니다. 이 특정 기능 요청은 2년 이상 된 것이며 해결 방법이 없습니다.

@tariq1890 이 KEP를 작성하는 사람들은 모든 것을 올바르게 수행했습니다. 그들은 돌을 돌이키지 않고 남겨두지 않았습니다. 여기서 문제는 @thockin이 말한 것과 정확히 같습니다. 먼저 해결해야 하는 기술 부채가 있으며 이를 고려하기 전에 이를 위해 손이 필요합니다. 따라서 사람들이 해야 할 일을 도와달라고 요청합니다.

여기에서 최신 업데이트를 확인하세요: https://github.com/kubernetes/enhancements/pull/1874

@dims 제가 잘못 이해한 것 같습니다. 내가 말하려는 것은 실행 가능한 목표와 목표의 목록이 필요하다는 것입니다. 처리해야 할 기술 부채가 있는 경우 GitHub 마일스톤을 유지하거나 OP 의견에 보류 중인 작업 항목의 글머리 기호 목록을 제공하여 이 문제를 방문하는 사람들이 해결해야 할 사항을 즉시 알 수 있도록 할 수 있습니다.

나는 이 KEP를 발전시키는 데 있어 서명/노드에 기꺼이 도움을 줄 의향이 있지만 어떻게 해야 할지 모르겠습니다.

@ tariq1890 특정 질문은 다음과 같습니다. "(아직 제출되지 않은 KEP) kubelet 노드 단계적 종료에 대한 전제 조건" https://github.com/kubernetes/enhancements/pull/1874/files#diff -c6212b56619f2b462935ad5f631d47

시작해야 합니다. 누군가는 요점을 잡고 진행해야 합니다.

-- 딤

따라서 이 문제의 사람들을 위해 https://github.com/kubernetes/enhancements/pull/1874 를 요약합니다. Sig-node(및 기타)는 더 복잡한 동작을 추가하는 이 KEP와 같은 새로운 기능을 도입하는 것이 현명하지 않다고 생각합니다. 포드 종료, 노드가 종료되는 동안 포드 종료의 더 일반적인 문제가 여전히 있습니다.
따라서 이 기능은 노드 종료에 대한 솔루션이 구현될 때까지 진행되지 않기로 결정했습니다.
현재 Google 문서가 있습니다. https://docs.google.com/document/d/1mPBLcNyrGzsLDA6unBn00mMwYzlP2tSct0n8lWfuRGE
여기에는 이 문제에 대한 많은 논의가 포함되어 있지만 이에 대한 KEP는 아직 제출되지 않았습니다.
아직 미해결 질문이 있으므로 거기에 대한 논평이 도움이 될 수 있습니다. 저는 @bobbypage 와 @mrunalp 가 이 노력을 이끌고 있다고 믿습니다. 그래서 사람들이 이 일을 진행하는 데 도움이 될 수 있는 다른 방법을 공유할 수 있을 것입니다.

@Joseph-Irving 요약해주셔서 감사합니다. 이 개선 사항에 대한 모든 +ve 에너지가 기능을 위한 일회성이 아니라 정기적으로 서명 노드의 모든 사람이 더 많은 참여로 이어지기를 바랍니다. 해야 할 일은 많고 손은 거의 없습니다.

안녕하세요! 이 KEP에 대한 또 하나의 의견입니다. 저는 지난 SIG 노드 회의(녹화를 보고 싶다면 6월 23일)에서 이 KEP에 대한 몇 가지 극단적인 사례를 제기했으며 토론을 계속하는 적절한 방법은 해당 토론에 대한 PR을 여는 것이라고 결정했습니다. 가장 좋은 진행 방법을 결정할 수 있습니다.

저는 현재 이러한 문제와 제가 생각할 수 있는 몇 가지 대안을 설명하기 위해 PR 작업을 하고 있습니다.

또한 KEP 상태는 이제 (구현 가능 대신) 잠정적이므로 검토할 수 있으며 모든 사람들이 KEP로 진행하는 데 편안하다고 느끼는 경우에만 다시 구현 가능하도록 설정할 수 있습니다.

이 문제에서 이것이 유일하게 누락된 정보라고 생각합니다. 감사 해요!

@rata 문제를 처리하는 적절한 방법으로 문제/PR을

@mattfarina 이것은 PR입니다 https://github.com/kubernetes/enhancements/pull/1913
여기에는 KEP의 현재 문제/에지 케이스에 대한 제안된 솔루션이 많이 포함되어 있습니다.
또한 특정 결정이 내려진 이유에 대해 더 잘 기록할 수 있도록 논의되고 결정된 여러 대안에 대한 세부 정보가 포함되어 있습니다.

사이드카 기능이 스케일링도 포함하는 것을 보고 싶습니다.
오늘날 HPA 확장은 메트릭(예: CPU)을 기반으로 합니다. 포드에 둘 이상의 컨테이너가 포함된 경우 모든 컨테이너의 평균이 사용됩니다(내가 아는 한). 사이드카가 있는 포드(app+nginx 등)의 경우 스케일링 기능을 올바르게 만들기가 매우 어렵습니다. Kubernetes의 사이드카 구현에 HPA 확장에 사용되는 메트릭 측면에서 포드의 한 컨테이너를 "권한 있는" 것으로 표시하는 것이 포함되기를 바랐습니다.

사이드카 기능이 스케일링도 포함하는 것을 보고 싶습니다.

나는 이것이 유용할 것이라는 데 동의하지만 반드시 "사이드카"에만 국한되는 것은 아니며 구현이 이것과 분리되어 있기 때문에 별도의 문제로 만드는 것이 합리적일 수 있습니다. 이 문제는 이미 매우 복잡합니다. 나는 또한 당신이 사이드카를 무시하고 싶어한다고 확신하지 않습니다. 예를 들어 대신 컨테이너별 HPA 확장을 원할 수 있습니다. 확실하지 않음 - 내 생각에 자체 문제로 탐색해야 할 것입니다.

이 문제, 특히 Istio Envoy 사이드카의 경우에 대한 현재 해결 방법에 대해 언급했거나 공유할 수 있는 사람이 있습니까?

다음과 관련된 가능한 해결 방법을 기억합니다.

• SIGTERM을 무시하는 사용자 지정 Envoy 이미지입니다.
• 종료 시 애플리케이션 컨테이너 내에서 Envoy의 /quitquitquit 호출(작업 완료 해결 방법과 유사)

이 문제, 특히 Istio Envoy 사이드카의 경우에 대한 현재 해결 방법에 대해 언급했거나 공유할 수 있는 사람이 있습니까?

supervisor 와 같은 사용자 정의 데몬 이미지를 사용하여 사용자 프로그램을 래핑합니다. 데몬은 또한 사용자 프로그램의 상태(종료 여부)를 전달하기 위해 특정 포트를 수신합니다.

해결 방법은 다음과 같습니다.

• 데몬 이미지를 initContainers 로 사용하여 바이너리를 공유 볼륨에 복사합니다.
• 우리의 CD 는 사용자의 명령을 가로채고 데몬이 먼저 시작하도록 합니다. 그런 다음 데몬은 Envoy가 준비될 때까지 사용자 프로그램을 실행합니다.
• 또한 Envoy를 위해 데몬의 상태를 계속 확인하는 스크립트 preStop 추가합니다.

결과적으로 Envoy가 준비되면 사용자 프로세스가 시작되고 사용자 프로세스가 종료되면 Envoy가 중지됩니다.

복잡한 해결 방법이지만 프로덕션 환경에서는 잘 작동합니다.

설명의 링크는 404를 제공합니다.

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

제 생각에는 다음과 같아야 합니다.

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

예, https://github.com/kubernetes/enhancements/pull/1913 으로 이동했습니다. 링크를 업데이트했습니다.

이 문제, 특히 Istio Envoy 사이드카의 경우에 대한 현재 해결 방법에 대해 언급했거나 공유할 수 있는 사람이 있습니까?

@shaneqld 시작 문제에 대해 istio 커뮤니티는 기본적으로 envoy를 컨테이너 목록의 첫 번째 컨테이너로 주입하고 envoy가 준비될 때까지 확인하고 기다리는 postStart 후크를 추가하는 아주 영리한 해결 방법 을 제시했습니다. 이는 차단 중이며 앱 컨테이너를 시작하기 전에 Envoy가 있고 준비가 되었는지 확인하기 위해 다른 컨테이너가 시작되지 않습니다.

우리는 이것을 우리가 실행 중인 버전으로 이식해야 했지만 매우 간단하고 지금까지의 결과에 만족합니다.

종료의 경우에도 preStop 후크로 '해결'하지만 SIGTERM을 계속하기 전에 애플리케이션이 정상적으로 종료되기를 바라는 임의의 절전 모드를 추가합니다.

관련 홍보: https://github.com/kubernetes/enhancements/pull/1980

안녕하세요 @Joseph-Irving @thockin 과 다른 모든 사람들 :미소:

개선 사항은 여기로 연결됩니다. 아직 진행 중인 대화가 많이 있지만, 진행 상황을 추적할 수 있도록 1.20에 이를 포함할 계획이 결정되었음을 알려드립니다.

감사 해요!
커스틴

@kikisdeliveryservice 가 계속해서

이 문제, 특히 Istio Envoy 사이드카의 경우에 대한 현재 해결 방법에 대해 언급했거나 공유할 수 있는 사람이 있습니까?

@shaneqld 시작 문제에 대해 istio 커뮤니티는 기본적으로 envoy를 컨테이너 목록의 첫 번째 컨테이너로 주입하고 envoy가 준비될 때까지 확인하고 기다리는 postStart 후크를 추가하는 아주 영리한 해결 방법 을 제시했습니다. 이는 차단 중이며 앱 컨테이너를 시작하기 전에 Envoy가 있고 준비가 되었는지 확인하기 위해 다른 컨테이너가 시작되지 않습니다.

우리는 이것을 우리가 실행 중인 버전으로 이식해야 했지만 매우 간단하고 지금까지의 결과에 만족합니다.

종료의 경우에도 preStop 후크로 '해결'하지만 SIGTERM을 계속하기 전에 애플리케이션이 정상적으로 종료되기를 바라는 임의의 절전 모드를 추가합니다.

이러한 작업을 수행하는 방법에 대해 몇 가지 통찰력을 자세히 보여줄 수 있습니까? Istio-proxy 사이드카에 '사전 중지'를 추가하는 방법은 무엇입니까? 사용자 정의 구성이 필요하거나 사용자 정의 사이드카를 사용해야 하는 것 같습니다. 포드가 축소될 때 기본 컨테이너가 작업을 완료하려고 시도하지만 SIGTERM 직후 Istio 사이드카가 닫히기 때문에 외부와의 연결이 끊어지는 것과 동일한 문제에 직면합니다. 지금은 기본 사이드카 주입만 사용합니다. 감사합니다!

알겠습니다. 이 스레드가 하이재킹되고 있습니다. 주제에 머물도록 합시다.

Enhancements Freeze가 다음 주인 10월 6일 화요일에 있음을 살짝 알려드립니다. 그때까지 KEP는 구현 가능한 것으로 표시되도록 업데이트해야 합니다.

또한 KEP는 이전 형식을 사용하고 있으므로 업데이트하는 것이 좋습니다(세부 사항을 망치고 나면): https://github.com/kubernetes/enhancements/tree/master/keps/NNNN-kep-template

@kikisdeliveryservice 나머지를 주셔서 감사합니다. 1.20에 포함되기로 결정되면 할 것입니다. 감사 해요! :)

이것은 1.20의 일부가 아닙니다. 핑 주셔서 감사합니다! :)

저는 이 문제에 관심이 있으며 이에 대한 통찰력을 제공한 @Joseph-Irving과 싶습니다 .

이 제안을 가로채고 싶지는 않지만 위의 대화를 기반으로 하여 이것이 지금까지 인식된 것보다 약간 더 광범위하거나 더 큰 문제인지 궁금합니다.

이 문제에 대한 다음 솔루션을 상상할 수 있습니다.

1. initContainers 이후, "메인 컨테이너" 이전에 시작하고 "메인 컨테이너" 종료 후 종료되는 새 컨테이너 엔터티 "사이드카 컨테이너"를 정의합니다(@Joseph-Irving 원래 제안에 따라).
2. @luksa 제안에 따라 "사이드카 컨테이너"가 initContainer(s)보다 먼저 시작되는지 여부를 설정하는 추가 필드를 (1)에 정의합니다.
3. 더 넓게 가십시오.

개인적으로 옵션 (2)는 내 즉각적인 문제를 해결 합니다.

그러나 이러한 질문이 일정 및 포드를 정의하는 방법에 관한 K8의 보다 전략적인 문제에 대해 이야기하지 않는지 궁금합니다. 내 특정(Istio 관련) 경우에는 포드 내의 런레벨과 같은 것을 제안했습니다.

옵션(2)도 내 문제를 해결하지만 pod/statefulSet/daemonSet/무엇이든 간에 컨테이너 종속성의 DAG를 포함해야 하는 훨씬 더 복잡한 종속성 구조를 상상할 수 있습니다. 이것이 옵션(3)입니다.

좀 더 일반적인 것을 만들기 위해 이 문제가 실제로 포드 정의 자체에 다시 초점을 맞춰야 하는지 궁금하십니까? 원래는 런레벨 비유의 관점에서 생각했지만 Airflow와 같은 DAG 구조가 가장 광범위하게 적용할 수 있습니다.

envoy를 초기화 컨테이너로 추가하는 것은 어떻습니까? 이런 식으로 다른 초기화 컨테이너에 네트워크를 제공합니다. init가 완료되면 'exit 0'도 수행되고 일반 특사(init가 아님)가 인계받습니다.

@michalzxc 제 말이 틀리지 않다면 init 컨테이너가 하나씩 순차적으로 실행되기 때문에 현재 init-container 로 다른 컨테이너 옆에 특사를 둘 수 없습니다.

안녕하세요!

사이드카 토론은 이 위치에서 계속되었습니다(나는 시그노드 슬랙, 이것을 시작한 github PR 및 여러 메일링 리스트를 업데이트했습니다):
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

보시다시피, 우리는 지금 사용 사례를 수집하고 있습니다. 몇 가지 사용 사례를 더 확보한 후 서로 다른 소그룹이 이를 해결하는 사전 제안을 만들 수 있습니다. 자유롭게 사용 사례를 추가하거나(아직 없는 경우) 나중에 사전 제안 부분에 참여하세요 :-)

이 개선 문제를 주제에 대해 계속 다루도록 합시다. 그 장소에 대한 대화에 참여할 수 있습니다. :)

이 KEP는 진행되지 않을 것이며, Sig-node 및 다른 사람들은 이것이 올바른 방향으로의 점진적인 단계가 아니라고 생각하여 도면 보드로 돌아가 모든 사용을 희망적으로 해결할 수 있는 몇 가지 새로운 KEP를 제시할 것입니다. 이 KEP 및 기타 사항에 명시된 경우.

@rata 의 이전 댓글을 참조하세요. https://github.com/kubernetes/enhancements/issues/753#issuecomment -707014341
토론에 기여할 수 있는 장소.

이 KEP에서 수행한 모든 작업이 사용되지 않는다는 것은 유감스러운 일이지만 더 많은 사람들이 이제 이러한 문제에 대해 생각하고 있으므로 그들이 제시하는 솔루션이 모든 사람에게 가장 좋은 것이 되기를 바랍니다.
저는 이미 2년 넘게 이 문제를 해결하기 위해 노력해왔기 때문에 지금이 앞으로 나아가 기에 좋은 때라고 생각합니다.

/닫다

@Joseph-Irving: 이 문제를 종료합니다.