Kubernetes: 일괄 작업에서 사이드카 컨테이너에 대한 더 나은 지원

/보결

또한 포드가 실패한 것으로 간주되고 전체 작업이 성공적인 것으로 간주되지 않기 때문에 http://stackoverflow.com/questions/36208211/sidecar-containers-in-kubernetes-jobs에 제안된 대로 활성 문제를 사용하면 작동하지 않습니다.

포드가 0을 반환할 때까지 기다리는 대신 작업이 성공을 감지하도록 프로브할 수 있도록 작업 성공 프로브를 선언한 것은 어떻습니까?
프로브가 성공을 반환하면 포드를 종료할 수 있습니다.

이미 종료된 컨테이너에 대해 실행을 조사할 수 있습니다.
그것이 무너지고 있는 경주가 될 것인가?

또 다른 옵션은 특정 종료 코드를 특별한 의미가 있는 것으로 지정하는 것입니다.

"전체 포드의 성공" 또는 "전체 포드의 실패"는 모두
유용한.

이것은 Pod 객체에 있어야 하므로 API가 크게 변경됩니다.

2016년 9월 22일 목요일 오후 1시 41분에 Ming Fang [email protected]에서 다음과 같이 썼습니다.

Job이 이를 프로브할 수 있도록 작업 성공 프로브를 선언한 것은 어떻습니까?
포드가 0을 반환할 때까지 기다리는 대신 성공을 감지합니다.

프로브가 성공을 반환하면 포드를 종료할 수 있습니다.

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -249021627,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AHuudjrpVtef6U35RWRlZr3mDKcCRo7oks5qsugRgaJpZM4IiqQH
.

@erictune 좋은 지적; 종료된 컨테이너를 조사할 수 없습니다.

컨테이너가 종료될 때 작업이 완료되었다고 말할 수 있도록 포드의 특정 컨테이너를 "완료" 컨테이너로 지정할 수 있습니까?

사이드카 컨테이너는 로그 전달 및 모니터링과 같은 작업을 위해 오래 지속되는 경향이 있습니다.
작업이 완료되면 강제 종료할 수 있습니다.

컨테이너가 종료될 때 작업이 완료되었다고 말할 수 있도록 포드의 특정 컨테이너를 "완료" 컨테이너로 지정할 수 있습니까?

기본적으로 .spec.completions 설정하지 않고 첫 번째 컨테이너가 종료 코드 0으로 완료되는 즉시 작업이 완료되는 여기 에서 자세히 설명된 이 문서 포인트 3을 살펴보았습니까?

사이드카 컨테이너는 로그 전달 및 모니터링과 같은 작업을 위해 오래 지속되는 경향이 있습니다.
작업이 완료되면 강제 종료할 수 있습니다.

개인적으로 이것들은 직업이라기보다는 RS처럼 보이지만, 그것은 제 개인적인 의견이며 가장 중요한 것은 귀하의 설정에 대한 자세한 내용을 알지 못한다는 것입니다.

일반적으로 이 주제를 다루는 https://github.com/kubernetes/kubernetes/issues/17244 및 https://github.com/kubernetes/kubernetes/issues/30243 토론이 있습니다.

위에서 보낸 @soltysh 링크, 포인트 3은 컨테이너 완성이 아니라 포드 완성을 참조합니다.

두 컨테이너는 emptyDir을 공유할 수 있으며 첫 번째 컨테이너는 "지금 종료 중입니다" 메시지를 파일에 쓰고 다른 컨테이너는 해당 메시지를 볼 때 종료할 수 있습니다.

@erictune 이 양동이에 해당한다고 생각하는 사용 사례가 있으며 이 문제를 해결하기 위해 공식적으로 권장되는 방법이 없기 때문에 올바른 방향으로 안내해 주시기 바랍니다.

나는 client-go 라이브러리를 사용하여 아래의 모든 것을 코딩하고 있습니다.

그래서 기본적으로 하나의 컨테이너 포드에서 도구를 실행하는 작업이 있습니다. 도구 실행이 완료되는 즉시 결과 파일을 생성해야 합니다. 도구 실행이 완료되자마자 포드가 삭제되고 결과 파일이 손실되기 때문에 이 결과 파일을 캡처할 수 없는 것 같습니다.

HostPath 를 VolumeSource로 사용하고 로컬에서 minikube를 실행하고 있기 때문에 결과 파일을 내 워크스테이션에 저장하면 이 결과 파일을 캡처할 수 있습니다.

그러나 이것이 권장되지 않고 프로덕션 컨테이너에 이상적이라는 것을 이해합니다. 그래서 위에서 제안한 대로 EmptyDir 를 사용했습니다. 그런데 또 그렇게 하면 팟 자체와 함께 삭제되기 때문에 제대로 캡처가 안 된다.

그렇다면 사이드카 컨테이너 패턴도 사용하여 문제를 해결해야 합니까?

기본적으로 위에서 제안한 대로 하십시오. 작업이 시작될 때마다 포드에서 2개의 컨테이너를 시작합니다. 1 컨테이너가 작업을 실행하고 작업이 완료되자마자 다른 컨테이너에서 선택하는 메시지를 삭제한 다음 결과 파일을 가져와 어딘가에 저장합니까?

처음에 2개의 컨테이너가 필요한 이유를 이해하지 못합니다. 작업 컨테이너가 이 모든 작업을 자체적으로 수행할 수 없는 이유는 무엇입니까? 즉, 작업을 완료하고 결과 파일을 어딘가에 저장하고 액세스/읽고 어딘가에 저장합니다.

@anshumanbh 당신에게 제안합니다:

1. 영구 저장소를 사용하면 결과 파일을 저장합니다.
2. 1과 거의 동일한 hostPath 마운트를 사용하고 이미 시도했습니다.
3. 결과 파일을 알려진 원격 위치(s3, google 드라이브, dropbox), 일반적으로 모든 종류의 공유 ​​드라이브에 업로드

@soltysh 파일이 영구적으로 저장되는 것을 원하지 않습니다. 실행할 때마다 그 결과를 마지막 결과와 비교하고 싶습니다. 그래서, 내가 이것을 하려고 생각했던 방식은 모든 실행에서 github 저장소에 커밋한 다음 무엇이 변경되었는지 확인하기 위해 diff를 수행하는 것이었습니다. 그래서 그렇게 하려면 결과를 임시로 어딘가에 저장하여 Github에 보낼 수 있도록 액세스하면 됩니다. 말이 됩니까?

@anshumanbh 완벽하게 명확하지만 여전히

@soltysh 그래서 위에서 제안한 목록에서 옵션 3으로 가고 싶다고 생각하면 어떻게 구현할까요?

내가 직면한 문제는 작업이 완료되자마자 컨테이너가 종료되고 파일이 손실된다는 것입니다. 파일이 없는 경우 S3/Google 드라이브/Dropbox와 같은 공유 드라이브에 어떻게 업로드합니까? 작업이 종료되기 전에 어딘가에 자동으로 업로드하도록 작업의 코드를 수정할 수 없으므로 불행히도 먼저 작업을 실행한 다음 파일을 어딘가에 저장해야 합니다.

작업 코드를 수정할 수 없는 경우 파일을 업로드할 수 있도록 랩핑해야 합니다. 작업 중인 이미지가 이미 이미지인 경우 복사 코드로 이미지를 확장하세요.

@soltysh 네, 이해가 됩니다. 할 수 있어요. 그러나 다음 질문은 - 여러 작업을 실행해야 하고(다른 도구를 실행하는 것으로 생각) 이러한 도구 중 어느 것도 내장된 업로드 부분이 없다고 가정합니다. 따라서 이제 해당 래퍼를 빌드하고 업로드 부분으로 해당 도구 각각을 확장해야 합니다. 래퍼/확장자를 한 번만 작성하고 모든 도구에 사용할 수 있는 방법이 있습니까?

사이드카 패턴이 저러면 안 어울리나요?

예, 그럴 수 있습니다. 같은 포드 내에서 여러 컨테이너로 시도했지만 패턴입니다. 아이오. 포드는 작업 컨테이너를 실행 중이며 출력을 기다리고 업로드하는 추가 컨테이너와 함께 실행됩니다. 이것이 얼마나 실현 가능한지 확실하지 않지만 이미 시도해 볼 수 있습니다.

부드러운 핑 -- 사이드카 인식은 Envoy와 같은 마이크로서비스 프록시 관리를 훨씬 더 즐겁게 합니다. 공유할 진행 상황이 있습니까?

현재 상황은 각 컨테이너가 수명을 조정하기 위해 번들 도구가 필요하다는 것입니다. 즉, 업스트림 컨테이너 이미지를 직접 사용할 수 없습니다. 또한 추가 argv 및 마운트 지점을 주입해야 하므로 템플릿이 상당히 복잡해집니다.

이전 제안은 일부 컨테이너를 "완료" 컨테이너로 지정하는 것이었습니다. 나는 그 반대의 제안을 하고 싶습니다. 일부 컨테이너를 "사이드카"로 지정하는 기능입니다. 포드의 마지막 비 사이드카 컨테이너가 종료되면 포드는 사이드카에 TERM 를 보내야 합니다. 이것은 Python의 Thread.daemon 와 같은 많은 스레딩 라이브러리에서 발견되는 "백그라운드 스레드" 개념과 유사합니다.

예제 구성, main 컨테이너가 종료되면 kubelet은 envoy .

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/my-batch-job/bin/main", "--config=/config/my-job-config.yaml"]
  - name: envoy
    image: lyft/envoy:latest
    sidecar: true
    command: ["/usr/local/bin/envoy", "--config-path=/my-batch-job/etc/envoy.json"]

참고로 다음은 원하는 사이드카 동작을 시뮬레이션하는 데 사용하는 bash madness입니다.

containers:
  - name: main
    image: gcr.io/some/image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        trap "touch /tmp/pod/main-terminated" EXIT
        /my-batch-job/bin/main --config=/config/my-job-config.yaml
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
  - name: envoy
    image: gcr.io/our-envoy-plus-bash-image:latest
    command: ["/bin/bash", "-c"]
    args:
      - |
        /usr/local/bin/envoy --config-path=/my-batch-job/etc/envoy.json &
        CHILD_PID=$!
        (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; fi; sleep 1; done) &
        wait $CHILD_PID
        if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; fi
    volumeMounts:
      - mountPath: /tmp/pod
        name: tmp-pod
        readOnly: true
volumes:
  - name: tmp-pod
    emptyDir: {}

나는 그 반대의 제안을 하고 싶습니다. 일부 컨테이너를 "사이드카"로 지정하는 기능입니다. Pod의 마지막 비 사이드카 컨테이너가 종료되면 Pod는 TERM을 사이드카로 보내야 합니다.

@jmillikin-stripe 나는 이 아이디어를 좋아하지만 이것이 Pod에서 일부 컨테이너를 다르게 처리하거나 컨테이너 간에 종속성을 도입하는 원칙을 따르는지 확실하지 않습니다. 마지막 통화는 @erictune 으로

하지만 #17244를 확인했지만 이러한 유형의 솔루션이 사용 사례에 적합할까요? 이것은 @erictune 이 이전에 몇 가지 의견을 언급한 내용입니다.

또 다른 옵션은 특정 종료 코드를 특별한 의미가 있는 것으로 지정하는 것입니다.

@jmillikin-stripe 나는 이 아이디어를 좋아하지만 이것이 Pod에서 일부 컨테이너를 다르게 처리하거나 컨테이너 간에 종속성을 도입하는 원칙을 따르는지 확실하지 않습니다. 마지막 통화는 @erictune 으로

Kubernetes는 컨테이너를 다르게 취급하지 않는다는 원칙에 대해 유연해야 할 필요가 있다고 생각합니다. 우리(Stripe)는 Envoy와 같은 타사 코드를 Lamprey 스타일의 수명 주기 후크를 갖도록 개조하는 것을 원하지 않으며 Envelope 스타일의 exec 반전을 채택하려는 시도는 Kubelet이 특정 사이드카를 종료하도록 하는 것보다 훨씬 더 복잡할 것입니다.

하지만 #17244를 확인했지만 이러한 유형의 솔루션이 사용 사례에 적합할까요? 이것은 @erictune 이 이전에 몇 가지 의견을 언급한 내용입니다.

또 다른 옵션은 특정 종료 코드를 특별한 의미가 있는 것으로 지정하는 것입니다.

저는 Kubernetes 또는 Kubelet이 "0 또는 0이 아닌 것"보다 더 미세한 단위로 오류 코드를 해석하는 것에 매우 반대합니다. Borglet의 종료 코드 매직 번호 사용은 불쾌한 오작동이었고 특정 컨테이너 이미지가 다른 파드에서 "메인" 또는 "사이드카"가 될 수 있는 Kubernetes에서는 훨씬 더 나쁩니다.

추가 수명 주기 후크가 이 문제를 해결하기에 충분할까요?

다음과 같을 수 있습니다.

• PostStop: 포드의 다른 컨테이너에서 수명 주기 이벤트를 트리거하는 수단(예: 트리거 중지)
• PeerStopped: 포드의 "피어" 컨테이너가 죽었다는 신호 - 종료 코드를 인수로 사용할 수 있음

이것은 또한 컨테이너를 다시 시작하기 위한 사용자 정의 정책을 정의하는 수단을 정의할 수 있습니다. 또는 기본적으로 시작되지 않은 컨테이너를 시작하여 컨테이너의 일부 데이지 체인을 허용할 수도 있습니다(컨테이너 a가 끝나면 컨테이너 b 시작).

또한 이것을 놓치고 있습니다. 연결을 위해 VPN 클라이언트가 필요한 작업을 30분마다 실행하지만 이것이 매우 유용할 수 있는 많은 사용 사례가 있는 것 같습니다(예: kubectl 프록시가 필요한 항목). 현재 jobSpec.concurrencyPolicy: Replace 를 해결 방법으로 사용하고 있지만 물론 이것은 a.) 병렬 작업 실행 없이 살 수 있고 b.) 작업 실행 시간이 예약 간격보다 짧은 경우에만 작동합니다.

편집: 내 사용 사례에서는 컨테이너를 종료 상태로 표시하고 작업이 종료 상태를 모니터링하고 나머지를 종료하도록 작업 사양에 일부 속성이 있으면 완전히 충분할 것입니다.

나 역시 이것이 필요하다. 우리의 경우에는 cloudsql-proxy 컨테이너를 사이드카 서비스로 사용하는 작업입니다.

포드의 '기본' 컨테이너 이름에 매핑되는 주석을 추가하는 것은 어떻습니까? 그렇게 하면 포드 사양을 어쨌든 수정할 필요가 없습니다.

파드 설계 방식의 특성상 이는 매우 일반적인 사용 사례처럼 보입니다. @soltysh @erictune 곧 작업할 계획이 있습니까? 가능하다면 기꺼이 도와주세요 :)

이 기능도 필요합니다. 우리의 사용 사례 :
포드 A 는 컨테이너에

• 컨테이너 A1 : 로그를 파일로 출력하는 실행 완료 컨테이너
• 컨테이너 A2 : 파일에서 stdout으로 로그를 추적하는 사이드카 컨테이너

내가 원하는 것 : 컨테이너 A1 이 성공으로 완료되면 포드 A 가 성공으로 완료됩니다. 컨테이너 A1 을 기본 컨테이너 로 레이블을 지정할 수 있습니까? 기본 컨테이너가 종료될 때 포드가 종료됩니까? @erictune (이 아이디어는 @mingfang 도 설명합니다)

안녕하세요 여러분, 이 문제가 공개된 지 한 달이 된 것 같습니다. 이것에 대한 최신 정보는 무엇입니까? 작업을 실행하려는 사용 사례가 있습니다. 작업은 몇 개의 사이드카 containers 가 있는 main 컨테이너를 실행합니다. main 컨테이너가 종료될 때 작업이 종료되기를 원합니다. file 를 공유하여 컨테이너 간에 signal 를 보내는 것이 최신 기술입니까?

나는 이것에 대한 몇 가지 작업을 시작하는 것을 꺼리지 않을 것입니다. 누군가가 내가 할 경우(아마도 kubecon 이후) 향후 PR을 검토할 수 있는지 알고 싶습니다.

cc @erictune @a-robinson @soltysh

@andrewsykim 어떤 접근 방식을 취 main 컨테이너는 사이드카가 초기화될 때까지 시작되지 않아야 합니다.

사이드카가 초기화될 때까지 메인 컨테이너가 시작되어서는 안 되는 것처럼

main 사이드카가 초기화될 때(또는 준비 프로브를 사용하여) 확인할 수 있어야 하므로 이 경우는 문제가 되지 않는다고 생각합니다. 이것은 main 가 종료되었기 때문에 이 문제의 경우가 아닙니다. :)

나는 kubernetes API를 감시하고 일치하는 주석으로 작업을 종료하고 주 컨테이너가 종료된 간단한 스크립트를 작성하게 되었습니다. 완벽하지는 않지만 핵심 요구 사항을 해결합니다. 사람들이 관심이 있다면 공유할 수 있습니다.

@ajbouh 요점으로 공유해 주시면 감사하겠습니다. 비슷한거 쓰려고했는데

@nrmitchi 여기에 내가 작성한 yaml의 요지가 있습니다. 이것은 매우 셸 스크립트이지만 사용할 API와 작동하는 것을 얻는 방법 측면에서 좋은 출발점이 될 수 있습니다. 질문이 있는 경우 수행 중인 작업에 대한 질문에 답변할 수 있습니다.

https://gist.github.com/ajbouh/79b3eb4833aa7b068de640c19060d126

@mrbobbytables와 동일한 Cloud SQL 프록시 사용 사례가 있습니다. 클라우드 SQL에 안전하게 연결하려면 프록시를 사용하는 것이 좋지만 작업이 완료될 때 해당 프록시가 종료되지 않아 다음과 같은 미친 해킹 또는 모니터링이 발생합니다. 앞으로 나아갈 길은 있습니까?

@amaxwell01 Cloud SQL Proxy가 이에 관여하는 것과 관련하여 Google에 문제를 열어 별표 표시하거나 업데이트를 확인할 수 있습니다. https://issuetracker.google.com/issues/70746902 그 순간의 열기 속에서 거기에; 불행히도 그것을 편집할 수 없습니다)

@abevoelker 감사합니다. 거기에서 귀하의 게시물을

우리도 이 문제의 영향을 받습니다.
마이크로 서비스에는 k8s cronjob에서 실행할 수 있지만 작업 완료 시 중지되지 않는 cloudsqlproxy 사이드카로 인해 성공하지 못하는 몇 가지 django 관리 명령이 있습니다.
우리가 언제 솔루션을 가질 수 있는지에 대한 업데이트가 있습니까?
사이드카 컨테이너 패턴은 ​​점점 더 많이 사용되며 많은 사람들이 이 문제가 해결될 때까지 k8s cronjob 및 작업을 사용할 수 없습니다.

이것을 위해 내 +1을 던지고 싶었습니다. 다른 모든 사람과 동일한 GCE Cloud SQL 프록시 문제가 있습니다. 그것은 나를 죽이고 있습니다 ... helm deploy 실패하고 차례로 내 terraform 적용에 실패합니다.

이것에 대한 어떤 종류의 해결책을 정말로 보고 싶습니다... 젠장 , 그건 해키입니다.

cloudsql-proxy 필요한 다른 사람의 경우 cloudsql-proxy 를 DaemonSet으로 실행하는 데 사용 사례에 적합합니까? 제 경우에는 프록시가 필요한 영구 배포와 CronJob이 모두 있었기 때문에 개별 포드에서 분리하고 대신 노드당 하나의 인스턴스를 연결하는 것이 합리적이었습니다.

네,

우리는 cloudsql 프록시 사이드카를 제거하기로 결정하고 다음 풀을 구축했습니다.
cloudsql 프록시는 중앙 네임스페이스에 있으며 완벽하게 작동하며
확장성과 더 쉬운 배포를 이동합니다.
이제 문제 없이 작업과 cronjob을 실행할 수 있습니다.

2018년 2월 7일 수요일 오전 9:37, Rob Jackson 알림 @github.com
썼다:

cloudsql-proxy가 필요한 다른 사람의 경우 사용 사례에 적합합니까?
cloudsql-proxy를 DaemonSet으로 실행하시겠습니까? 제 경우에는 두 가지 모두 지속적으로
프록시가 필요한 배포 및 CronJob, 따라서 분리하는 것이 합리적이었습니다.
개별 포드에서 가져오고 대신 노드당 하나의 인스턴스를 연결합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/25908#issuecomment-363710890 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/ACAWMwetx6gA_SrHL_RRbTMJVOhW1FKLks5tSW7JgaJpZM4IiqQH
.

흥미롭게도 deamonset을 사용하는 것은 좋은 선택인 것 같습니다. @RJacksonm1 & @devlounge - 데몬셋을 사용할 때 클라우드 SQL 프록시 검색은 어떻게 작동합니까?

트릭을 할 것처럼 보이는 이것을 찾았습니다 ...
https://buoyant.io/2016/10/14/a-service-mesh-for-kubernetes-part-ii-pods-are-great-until-theyre-not/

기본적으로 호스트 IP를 얻기 위해 다음과 같은 것을 사용합니다.

env:
- name: NODE_NAME
  valueFrom:
    fieldRef:
      fieldPath: spec.nodeName

@RJacksonm1 - hostPort 작동시키기 위해 특별히 한 일이 있습니까? fieldPath: spec.nodeName 접근 방식과 함께 사용할 때 지속적으로 connection refused 발생합니다 🤔

편집: spec.nodeName 이(가) 올바르게 처리되고 있고 GKE v1.9.2-gke.1 있는지 확인 spec.nodeName

@cvallance 내 애플리케이션이 DNS를 통해 액세스할 수 있는 DaemonSet을 노출하도록 서비스를 설정했습니다. 이것은 애플리케이션이 동일한 호스트에서 실행 중인 cloudsql-proxy 인스턴스와 통신할 것이라고 보장하지 않지만 cloudsql-proxy 가 클러스터 전체와 함께 확장된다는 것을 보장합니다(원래는 프록시를 Deployment 및 HorizontalPodAutoscaler로 사용했지만 너무 많이 확장/축소하여 앱에서 MySQL has gone away 오류가 발생함을 발견했습니다. 이것은 DaemonSet의 진정한 정신이 아닌 것 같습니다... 🤔

@RJacksonm1 - hostPort 및 spec.nodeName 와 함께 작동합니다 ... 이제 노드의 DaemonSet에 직접 연결됩니다 😄

CloudSql 프록시 명령이 작동하지 않음:
-instances={{ .Values.sqlConnectionName }}=tcp:{{ .Values.internalPort }}
일하고있는:
-instances={{ .Values.sqlConnectionName }}=tcp:0.0.0.0:{{ .Values.internalPort }}

🤦‍♂️

이 문제에 대한 관심을 끌기 위해 우리가 할 수 있는 일이 있습니까?
오픈한 지 거의 2년이 지났지만 여전히 해결 방법만 있습니다.

나는 이것을 구현하기 위해 스스로 자원하더라도 구현할 솔루션, API 변경 등에 대해 내부 직원의 승인이 필요하기 때문에 할 수 없을 것이라고 생각합니다.

이 작업을 완료하는 데 도움이 될 수 있는 작업이 있습니까?

참고로 저는 공유 볼륨의 파일이 사이드카에 상태를 전달하는 @jmillikin-stripe의 해결 방법의 cloud-sql-proxy 사이드카 버전을 만들었습니다.

그것은 잘 작동하지만 지금까지 내 K8s 구성에서 가장 불쾌한 해킹입니다 :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

프로젝트 내부의 누군가가 이 문제의 진행 상황에 대해 언급할 수 있습니까?

여기서도 같은 문제

cc @kubernetes/sig-apps-feature-requests @kubernetes/sig-node-feature-requests

다음과 같이 작업 포드를 완료됨(다른 컨테이너가 중지됨)으로 표시하기 위해 사용자가 성공적으로 완료되기를 원하는 작업의 컨테이너를 (이름으로) 지정하도록 허용하는 것이 합리적입니까?

apiVersion: batch/v2beta1
kind: Job
metadata:
  name: my-job
  namespace: app
spec:
  template:
    spec:
      containers:
        - name: my-container
          image: my-job-image
          ...
        - name: cloudsql-proxy
          image: gcr.io/cloudsql-docker/gce-proxy:1.11
          ...
  backoffLimit: 2
  jobCompletedWith:
    - my-container

즉, 포드가 실행되고 my-container 성공적으로 종료될 때까지 기다린 다음 cloudsql-proxy 종료합니다.

편집: 이 스레드를 위로 스크롤하면 이것이 이전에 제안되었음을 알 수 있습니다. @erictune 또는 다른 누군가가 이것이 작동하지 않는 이유에 대해 다시 설명할 수 있습니까?

네 완벽할 것 같아요. 작업 상태를 보고 완료되면 파이프라인을 계속할 수 있는 것

예, 완벽할 것입니다.

이 아이디어가 좋아요 @jpalomaki

순수하게 작업 컨트롤러 내에서 이 문제를 해결하는 접근 방식에 대한 한 가지 우려는 작업이 완료된 후에도 포드가 계속 실행된다는 것입니다. 현재 포드는 종료 단계에 들어가고 노드는 해당 리소스를 해제할 수 있습니다.

컨트롤러가 완료되었다고 결정하면 Job 컨트롤러가 포드를 삭제하도록 할 수 있지만 이는 종료된 포드 레코드가 API 서버에서 유지되는 현재 동작과도 다릅니다(노드 리소스를 차지하지 않음).

이러한 이유로 Pod API 수준에서 이 문제를 해결하는 것이 더 깔끔해 보입니다. 노드는 관심 있는 "완료" 컨테이너가 이미 종료되었기 때문에 개별 컨테이너에 도달하여 종료해야 하는 유일한 것입니다. 이것은 대기해야 하는 컨테이너의 개념을 지정할 수 있는 파드 수준 API의 형태를 취하거나 외부 에이전트(예: 작업 컨트롤러)가 실제로 삭제하지 않고 파드를 강제 종료하도록 허용하는 파드 수준 API의 형태를 취할 수 있습니다. 포드.

또한 프로세서 컨테이너가 성공적으로 종료된 경우 컨테이너에서 생성된 파일을 업로드하는 솔루션을 찾고 있습니다.

사이드카 컨테이너가 k8s API를 통해 컨테이너 상태를 관찰하여 업로드 또는 종료를 시작할지 여부와 시기를 알도록 하는 것에 반대하는 @mingfang 의 주장을 이해하고 있는지 잘 모르겠습니다. 사이드카 컨테이너가 포드를 종료하면 작업이 성공적으로 종료되어야 합니다.

해킹처럼 보이지만 데이터 생성 컨테이너를 초기화 컨테이너로 만들고 데이터 업로드 컨테이너(더 이상 사이드카 컨테이너일 필요가 없는 ) 프로세서 컨테이너가 성공적으로 종료된 후에만 자동으로 시작됩니다. 제 경우에는 처리 컨테이너에 데이터를 제공하기 위해 첫 번째 초기화 컨테이너로 데이터 다운로더 컨테이너도 필요합니다. 이것이 특히 나쁜 생각이라면 그 이유를 알고 싶습니다.

사이드카를 일류 k8s 개념으로 홍보하면 이 문제가 해결되지 않습니까? Kubelet은 실행 중인 모든 컨테이너가 사이드카 컨테이너로 표시된 경우 포드를 종료할 수 있습니다.

FWIW, Cloud SQL 프록시를 일반 배포( replicas: 1 )로 배포하여 이 문제를 해결하고 Job 및 CronJob 가 type: ClusterIP 를 통해 사용하도록 했습니다. 서비스. 이제 작업이 잘 완료됩니다.

이에 대한 공식적인 입장을 원합니다.

API의 지원을 받지 않으려면 최소한 대체 솔루션을 공식적으로 문서화하여 사람들이 이 문제에 직면했을 때 무엇을 해야 하는지 알 수 있도록 해야 합니다.

누구에게 핑을 보내야 할지, 어떻게 주의를 기울여야 할지 모르겠습니다...

이 문제가 해결되면 정말 좋을 것입니다. 작업이 사라지지 않는 것 외에도 전체 Pod 상태가 분명히 잘못되었습니다.

Init Containers:
  initializer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:52:57 -0500
      Finished:     Wed, 21 Mar 2018 17:52:57 -0500
    Ready:          True
Containers:
  sideCar:
    State:          Running
      Started:      Wed, 21 Mar 2018 17:53:40 -0500
    Ready:          True
  mainContainer:
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 21 Mar 2018 17:53:41 -0500
      Finished:     Wed, 21 Mar 2018 17:55:12 -0500
    Ready:          False
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 

흥미로운 점은 initContainer(Terminated, Completed, Ready=True) 및 기본 앱 컨테이너(Terminated, Completed, Ready=False)에 대한 상태 및 준비 상태입니다. 그것은 False의 over Pod Ready 상태를 유도하는 것 같습니다. 제 생각에는 잘못되었습니다. 이로 인해 이 Pod가 대시보드에서 문제가 있는 것으로 플래그가 지정됩니다.

특히 Cloud SQL 프록시에서 이 문제가 발생한 다른 고객이 있습니다. 크론 작업이 Cloud SQL에 액세스할 수 있도록 하기 위해 영구 서비스로 실행할 필요가 없기를 바랍니다.

@yuriatgoogle 가장 쉬운 솔루션은 다음과 같은 bash 및 emptyDir "마법"입니다. https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -365924958

해킹이지만 해야 합니다. @phidah를 공격하려는 의도는 없습니다.

많은 사람들이 다양한 이유로 이것을 원하는 것 같습니다. 공식적인 지원을 받는 것이 좋을 것입니다. 나는 우리 자신의 사이드카와 작업에 같은 문제가 있었기 때문에 사이드카가 kube API를 사용하여 포드에 있는 다른 컨테이너의 상태를 확인하도록 했습니다. completed 사이드카가 종료되면 사이드카가 1을 종료한다는 오류가 발생했습니다. 가장 우아한 솔루션은 아니지만 개발자가 많이 변경할 필요 없이 트릭을 수행했습니다. 관심 있는 사람이 있으면 여기에 코드가 있습니다: https://github.com/uswitch/vault-creds/blob/master/cmd/main.go#L132.

고릴라즈 노래 M1 A1 생각나네...

안녕하세요? 안녕하세요? 사람이 있습니까?

예, 견인력을 얻으십시오. +1

따라서 업스트림 변경이 필요한 제안된 솔루션은 다음과 같습니다.

1. sidecar: true 작성자 @jmillikin-stripe
2. @msperl의 추가 수명 주기 후크
3. jobCompletedWith @jpalomaki 작성

사이드카를 위한 임시 솔루션, 해킹된 것(그러나 작동함):

1. @phidah의 cloudsql-proxy 사이드카

제안된 솔루션에 대한 Kubernetes 유지 관리자의 응답을 보고 싶습니다. 기존 kubernetes 버전을 사용하여 이 사용 사례를 해결하는 방법에 대한 권장 사항을 알려주세요. 감사 해요!

내 렌더링 작업의 stdout / stderr을 데이터베이스에 업로드하는 로그 에이전트를 작성하려고 하루를 보낸 후 이 스레드를 발견했습니다. 포드에 에이전트가 있다는 것은 작업이 절대 종료되지 않는다는 것을 의미한다는 것을 발견하기만 하면 됩니다.

위에 제시된 제안 중에서 저는 'sidecar: true'가 가장 마음에 듭니다. 저 같은 개발자가 매우 이해할 수 있을 정도로 간단하고 요점도 있기 때문입니다. '사이드카'는 실제로 단순한 작업 이상에 적용되고 완료 요구 사항 외에 다른 것을 의미하는 포드 디자인 패턴이기 때문에 아마도 약간 다른 것으로 부를 것입니다. 내 자전거 이동을 용서한다면, 이 작업이 아직 실행 중이더라도 작업이 완료된 것으로 간주될 수 있음을 나타내기 위해 아마도 'ambient: true'와 같은 이름으로 부를 것입니다. 다른 단어는 '보조' 또는 '지원'일 수 있습니다.

다른 많은 사람들이 설명한 것과 동일한 워크플로(연결을 프록시하거나 메트릭을 수집하는 데 사용되며 포드의 다른 컨테이너가 성공적으로 종료된 후에는 목적이 없는 사이드카 컨테이너)에 대해 이 문제도 겪었습니다.

이전 제안은 일부 컨테이너를 "완료" 컨테이너로 지정하는 것이었습니다. 나는 그 반대의 제안을 하고 싶습니다. 일부 컨테이너를 "사이드카"로 지정하는 기능입니다. Pod의 마지막 비 사이드카 컨테이너가 종료되면 Pod는 TERM을 사이드카로 보내야 합니다.

이것은 나의 이상적인 솔루션이기도 합니다. SIGTERM 대신 SIGHUP을 제안할 수 있습니다. 이것은 SIGHUP의 의미가 관련된 정확한 사용 사례인 것 같습니다! - 하지만 나는 둘 중 하나에 만족할 것입니다.

그대로 Kubernetes에서 작업을 실행하려면 사이드카가 아닌 컨테이너가 완료될 때 Kubernetes 관련 컨테이너 간 통신을 처리하기 위해 업스트림 컨테이너 이미지를 수동으로 패치하거나 좀비 포드가 작동하지 않도록 모든 작업에 대한 사이드카를 종료하기 위해 수동으로 개입해야 합니다. 놀아요. 둘 다 특히 즐겁지 않습니다.

이에 대한 패치를 기꺼이 만들고 싶지만 코드를 파헤치기 전에 @kubernetes/sig-apps-feature-requests의 지침을 받고 싶습니다. 이 작업을 수행하기 위해 포드 사양에 sidecar 필드를 추가해도 됩니까? 우리가 원한다는 확신 없이 포드 사양을 변경하는 것을 주저합니다. 지금은 주석을 사용하시겠습니까?

@andrewsykim 나는 이 문제를 잠시 동안

내 추론은 다음과 같습니다.

• 이 문제는 거의 2년 동안 주변에 있었고 실제로 kubernetes 코어에서 많은 관심을 끌지 못했습니다. 따라서 Pod 사양 변경을 기다리거나 직접 입력을 기다리면 아마 오랜 시간을 기다려야 할 것입니다.
• 실행 가능한 PR은 오래된 문제보다 관심을 끌기가 훨씬 쉽습니다.
• 나중에 pod 속성을 사용하기 위해 주석 접근 방식을 전환하는 것이 각각 예쁠 것입니다.

생각?

안녕하세요, 저는 이 문제에 대해 kubecon의 sig-apps 직원 중 일부와 이야기했습니다. 기본적으로 즉각적인 로드맵에 없는 것이지만 유효한 사용 사례라고 생각하는 것입니다. 그들은 이것을 다루는 커뮤니티의 누군가에게 매우 개방적입니다.

이 문제를 해결하기 위해 개선 제안을 위한 PR을 만들었으므로 이것이 https://github.com/kubernetes/community/pull/2148에 대한 토론을 일으키기를

@Joseph-Irving을 함께해주셔서 감사합니다! 이에 대해 해결해야 할 세부 정보가 더 있는 것 같으므로 그때까지 작업을 보류하겠습니다. :)

지속적-장기적 문제 :(

cc @ kow3ns @janetkuo

문제를 더 복잡하게 만들 필요 없이 initContainers 와 함께 "사이드카" 스타일 컨테이너를 실행할 수 있는 것도 유용할 것입니다.

제 사용 사례는 여기 사람들과 비슷합니다. 데이터베이스 마이그레이션을 실행하는 initContainer와 동시에 클라우드 SQL 프록시를 실행해야 합니다. initContainers가 한 번에 하나씩 실행되기 때문에 프록시를 배포+서비스로 실행하는 것을 제외하고는 이 작업을 수행하는 방법을 볼 수 없지만 적절한 작업이 아닌 다른 사용 사례(로그 관리 등)가 있을 것으로 예상합니다. 약.

@mcfedr 초기화 컨테이너 동작에 대한 관찰을 높이 평가할 수 있는 합리적으로 적극적인 개선 제안 이 있습니다. 이것이 이 제안의 범위 내인지 또는 관련 개선 사항인지는 확실하지 않지만 고려 대상으로 제기하는 것이 합리적이므로 충분히 관련이 있다고 생각합니다.

잠재적인 구현/호환성 문제에도 불구하고 이상적인 모델은 아마도 사이드카 초기화 컨테이너가 현재와 같이 순차적으로 계속 실행되는 비-사이드카 초기화 컨테이너와 동시에 실행되고 메인 시퀀스 컨테이너가 시작되기 전에 사이드카가 종료되는 것입니다.

그 가치에 대해 CloudSQL Proxy et.al과 같이 여전히 실행 중인 사이드카를 무시할 필요성을 표현하고 싶습니다.

내 스크립트가 이렇게 오래 걸리지 않을 것이라는 것을 알고 있기 때문에 30초 후에 cloudsql 컨테이너를 종료할 수 있었습니다. 내 접근 방식은 다음과 같습니다.

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: schedule
spec:
  concurrencyPolicy: Forbid
  schedule: "*/10 * * * *"
  startingDeadlineSeconds: 40
  jobTemplate:
    spec:
      completions: 1
      template:
        spec:
          containers:
          - image: someimage
            name: imagename
            args:
            - php
            - /var/www/html/artisan
            - schedule:run
          - command: ["sh", "-c"]
            args:
            - /cloud_sql_proxy -instances=cloudsql_instance=tcp:3306 -credential_file=some_secret_file.json & pid=$! && (sleep 30 && kill -9 $pid 2>/dev/null)
            image: gcr.io/cloudsql-docker/gce-proxy:1.11
            imagePullPolicy: IfNotPresent
            name: cloudsql
            resources: {}
            volumeMounts:
            - mountPath: /secrets/cloudsql
              name: secretname
              readOnly: true
          restartPolicy: OnFailure
          volumes:
          - name: secretname
            secret:
              defaultMode: 420
              secretName: secretname

그리고 그것은 나를 위해 일하고 있습니다.
이 접근 방식의 단점이 있습니까?

CronJobs에도 관련이 있고 쉽게 적용할 수 있다고 생각하기 때문에 이것이 제 솔루션입니다. https://github.com/GoogleCloudPlatform/cloudsql-proxy/issues/128#issuecomment -413444029

여기에 게시된 해결 방법 중 하나를 기반으로 하지만 배포용이므로 preStop 를 사용합니다. 사이드카를 트래핑하면 훌륭하게 작동합니다.

이 문제에 이어. 또한 cronjob에서 cloud_sql_proxy 컨테이너를 사이드카로 사용
@stiko 의 타임아웃 구현 을 사용 했습니다.

Replace 사용에 대해 @oxygen0211이 제안한 솔루션을 대화에 추가하는 것만으로도 현재로서는 괜찮은 해결 방법입니다. 저처럼 이 문제가 발생하면 확인하십시오.

https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -327396198

우리는 이 KEP를 잠정적으로 승인했습니다 https://github.com/kubernetes/community/pull/2148 , 우리는 여전히 동의해야 하는 몇 가지 사항이 있지만 희망적으로 작업을 비교적 곧 시작할 수 있는 위치에 도달할 것입니다. . 참고 KEP는 30일에 https://github.com/kubernetes/enhancements 로 이동하므로 따라하고 싶다면 거기에 있을 것입니다.

사이드카 지원이 도착할 때까지 나중에 쉽게 제거할 수 있는 도커 수준 솔루션을 사용할 수 있습니다. https://gist.github.com/janosroden/78725e3f846763aa3a660a6b2116c7da

마운트된 도커 소켓과 표준 Kubernetes 레이블이 있는 권한 있는 컨테이너를 사용하여 작업의 컨테이너를 관리합니다.

우리는 Istio와 그 사이드카와 같은 문제를 겪고 있었고, 우리가 하기로 결정한 것은 다음과 같이 curl + preStop hook을 통해 포드를 삭제하는 것입니다.

다음과 같은 최소한의 RBAC 규칙을 작업에 부여하십시오.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myservice-job
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-role
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["delete"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myservice-job-rolebinding
subjects:
  - kind: ServiceAccount
    name: myservice-job
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myservice-role

그리고 POD_NAME 및 POD_NAMESPACE 를 ENV에 이렇게

   env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace

마지막으로 다음과 같은 preStop 후크를 추가합니다.

 lifecycle:
      preStop:
        exec:
          command: 
            - "/bin/bash" 
            - "-c"
            - "curl -X DELETE -H "Authorization: Bearer $(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/$POD_NAMESPACE/pods/$POD_NAME?gracePeriodSeconds=1"

일종의 지저분하지만 올바른 도커 컨테이너를 죽이는 것보다 조금 더 안전하고 덜 까다롭습니다.

여기에 이것을 던지고 있지만 실행 중인 포드 변경 사항을 모니터링하고 SIGTERM을 사이드카 컨테이너에 적절하게 보내기 위한 컨트롤러를 얼마 전에 함께 던졌습니다. 확실히 가장 강력하지는 않으며 솔직히 한동안 사용하지 않았지만 도움이 될 수 있습니다.

https://github.com/nrmitchi/k8s-controller-sidecars

에서 @jpalomaki 덕분에 https://github.com/kubernetes/kubernetes/issues/25908#issuecomment 제안에 대한 -371469801 실행하기 cloud_sql_proxy 와 배포로 ClusterIP , 그리고에 서비스를 @ cvallance ( https://github.com/kubernetes/kubernetes/issues/25908#issuecomment -364255363) cloud_sql_proxy instances 매개변수에서 tcp:0.0.0.0 설정에 대한 팁을 -프로세스에 대한 로컬 연결. 그것들을 함께 사용하면 cron 작업이 프록시를 사용할 수 있습니다.

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

같은 문제입니다. Cloud SQL GKE cron 작업을 사용하는 방법에 대한 방법 또는 공식 문서를 찾고 있습니다.

참고 사항:
구글은 클라우드 SQL 업데이트 -> 구글는 Kubernetes 엔진에서 연결 , 문서 이제 이외에 Connecting using the Cloud SQL Proxy Docker image 할 수 있습니다 Connecting using a private IP address
그래서 당신이 여기에 있는 것과 같은 이유로 여기 있다면(cloud_sql_proxy 때문에) 이제 사설 IP의 새로운 기능을 사용할 수 있습니다.

참고 사항:
구글은 클라우드 SQL 업데이트 -> 구글는 Kubernetes 엔진에서 연결 , 문서 이제 이외에 Connecting using the Cloud SQL Proxy Docker image 할 수 있습니다 Connecting using a private IP address
그래서 당신이 여기에 있는 것과 같은 이유로 여기 있다면(cloud_sql_proxy 때문에) 이제 사설 IP의 새로운 기능을 사용할 수 있습니다.

Private IP 기능은 전체 클러스터를 삭제하고 다시 생성해야 할 것 같습니다........?

@cropse 클러스터가 VPC 기반이 아닌 경우에만 필요합니다.

나는 이 문제에 대한 해결 방법 을 만들었지만 훌륭한 솔루션은 아니었지만 효과가 있었습니다. 기능이 추가되기 전에 이 도움이 되었기를 바랍니다. VPC는 ​​슬레이브에 대한 한 가지 방법이지만 전체 클러스터를 삭제하는 것은 여전히 ​​고통스럽습니다.

내 두 센트를 추가하기 위해: 포드가 완료되지 않아 istio 사이드카 주입이 발생하면 조타 장치 테스트도 중단됩니다.

@dansiviter 내 해결 방법을 확인할 수 있습니다. 이미 내 프로젝트에서 키를 사용하여 테스트했습니다.

이것이 구현되기를 기대합니다! :)

Istio 프록시가 주입될 때 일반 작업과 동일한 문제가 있습니다. 그 외에도 Prow로 CI 작업을 실행하기를 원하기 때문에 이것을 원합니다.
예: 테스트 목적을 위한 Rails 앱 컨테이너 + 사이드카 데이터베이스 컨테이너.

@cropse 감사합니다. 모든 테스트에 대해 이것을 구성해야 하므로 시도하지 않았습니다. 우리는 단지 Pod(유감스럽게도 Helm 테스트에서는 Job을 허용하지 않음)가 실패하도록 허용하고 이 문제가 장기적으로 수정될 때까지 수동으로 로그를 검사하는 데 의존하고 있습니다. 그러나 그것은 다른 잡스에게도 문제가 되고 있으므로 그 입장을 재고해야 할 수도 있습니다.

참고로, 이 기능에 대한 추적 문제는 https://github.com/kubernetes/enhancements/issues/753에 있습니다. 사람들이 따라하고 싶다면 KEP가 있고 일부 프로토타이핑이 완료되었습니다(POC 분기/비디오가 있습니다. ), 구현 가능한 상태가 되기 전에 구현 세부 사항 중 일부를 수정해야 합니다.

참고 사항:
구글은 클라우드 SQL 업데이트 -> 구글는 Kubernetes 엔진에서 연결 , 문서 이제 이외에 Connecting using the Cloud SQL Proxy Docker image 할 수 있습니다 Connecting using a private IP address
그래서 당신이 여기에 있는 것과 같은 이유로 여기 있다면(cloud_sql_proxy 때문에) 이제 사설 IP의 새로운 기능을 사용할 수 있습니다.

같은 이유로 여기에 왔지만 이 기능이 준비되기 전에 Cloud SQL이 프로비저닝되었습니다. 나는 이전 제안을 결합하고 내 dbmate migrator helm 차트에 대해 이것을 (아마 이상적이지는 않지만 작동합니다) 나왔습니다.

      containers:
      - name: migrator
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        command: ["/bin/bash", "-c"]
        args:
          - |
            /cloud_sql_proxy -instances={{ .Values.gcp.project }}:{{ .Values.gcp.region }}:{{ .Values.gcp.cloudsql_database }}=tcp:5432 -credential_file=/secrets/cloudsql/credentials.json &
            ensure_proxy_is_up.sh dbmate up
        env:
        - name: DATABASE_URL
          valueFrom:
            secretKeyRef:
              name: mysecret
              key: DATABASE_URL
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials

ensure_proxy_is_up.sh

#!/bin/bash

until pg_isready -d $(echo $DATABASE_URL); do
    sleep 1
done

# run the command that was passed in
exec "$@"

Kubernetes의 사이드카 컨테이너 개념을 도입하고 사이드카가 아닌 컨테이너가 완료되었는지 여부에 따라 포드 정리를 허용하는 것이 좋을까요?

@Willux 저는 atm에 전화를 하고 있어서 참고할 링크를 찾기가 더 어렵지만, 방금 제안하신 내용은 이미 잘 진행되고 있습니다.

@krancour 업데이트에 감사드립니다. 나는 그 세부 사항을 놓쳤을 것입니다. 최근에 여기에서 많은 활동이 일어나지 않았으므로 진행 중인 일이 있는지 확인하고 싶었습니다. :)

참고로 저는 공유 볼륨의 파일이 사이드카에 상태를 전달하는 @jmillikin-stripe의 해결 방법의 cloud-sql-proxy 사이드카 버전을 만들었습니다.

그것은 잘 작동하지만 지금까지 내 K8s 구성에서 가장 불쾌한 해킹입니다 :(

apiVersion: batch/v1
kind: Job
metadata:
  name: example-job
spec:
  template:
    spec:
      containers:
      - name: example-job
        image: eu.gcr.io/example/example-job:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            trap "touch /tmp/pod/main-terminated" EXIT
            run-job.sh
        volumeMounts:
          - mountPath: /tmp/pod
            name: tmp-pod
      - name: cloudsql-proxy
        image: gcr.io/cloudsql-docker/gce-proxy:1.11
        command: ["/bin/sh", "-c"]
        args:
          - |
            /cloud_sql_proxy --dir=/cloudsql -instances=example:europe-west3:example=tcp:3306 -credential_file=/secrets/cloudsql/credentials.json &
            CHILD_PID=$!
            (while true; do if [[ -f "/tmp/pod/main-terminated" ]]; then kill $CHILD_PID; echo "Killed $CHILD_PID as the main container terminated."; fi; sleep 1; done) &
            wait $CHILD_PID
            if [[ -f "/tmp/pod/main-terminated" ]]; then exit 0; echo "Job completed. Exiting..."; fi
        volumeMounts:
          - name: cloudsql-instance-credentials
            mountPath: /secrets/cloudsql
            readOnly: true
          - name: cloudsql
            mountPath: /cloudsql
          - mountPath: /tmp/pod
            name: tmp-pod
            readOnly: true
      restartPolicy: Never
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: cloudsql
          emptyDir:
        - name: tmp-pod
          emptyDir: {}
  backoffLimit: 1

프로젝트 내부의 누군가가 이 문제의 진행 상황에 대해 언급할 수 있습니까?

이것이 아마도 최소한 몇 달 동안 Kubernetes 1.18을 따라잡지 못할 GKE의 안정적인 릴리스 채널에서 작업하는 우리에게 최고의 옵션이라고 가정하는 것이 공정합니까?

@Datamance 이 시점에서 이 문제를 해결하기 위한 KEP 는 무기한 보류된 것처럼 보입니다 .

나는 얼마 전에 이 댓글을 게시했는데, 이는 내 오래된 솔루션이었습니다. 나는 내 자신의 것을 여기에 밀어 넣으려는 것이 아니라 github의 "100 more comments..."에서 해당 댓글이 손실되었으며 다시 표시하는 것이 다시 유용할 수 있다고 생각했습니다.

@nrmitchi 다시 게시해 주셔서 감사합니다. 나는 댓글의 바다에서 그것을 간과했던 사람이며 이것은 환상적인 단기 솔루션처럼 보입니다.

Pod 컨테이너에 다음을 추가하면 다른 접근 방식을 알아냅니다.

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

그러면 다른 컨테이너에서 Pid를 grep할 수 있습니다. 기본 컨테이너 끝에서 다음을 실행합니다.
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@krancour 도움이 되었다

IIRC 레모네이드-HQ 포크 에는 몇 가지 유용한 추가 기능이 있습니다.

@nrmitchi , 나는 코드를 흘끗 보았지만 당신에게 묻는 것이 더 빠를 수도 있습니다 ...

README에 언급되지 않은 전제 조건에 대해 간단히 언급할 수 있습니까?

예를 들어, 사이드카의 기반이 되는 이미지에 이 해결 방법에 대한 특별한 인식이 필요합니까? 예를 들어 컨트롤러의 신호에 대해 특정 포트에서 수신 대기해야 합니까? 아니면 특정 쉘(bash?)을 포함해야 합니다.

@krancour 이 솔루션은 몇 년 전에 작성되었으며 내 기억이 약간 녹슬 서두에 드리겠습니다.

문제의 컨테이너가 해결 방법을 알 필요가 없도록 당시에 설계되었습니다. 우리는 사이드카에서 주로 타사 응용 프로그램을 사용하고 있었고(예: 스트라이프/베너 가 하나라고 생각합니다) 분기/수정을 원하지 않았습니다.

사이드카의 유일한 요구 사항은 SIGTERM 신호를 제대로 수신한 다음 종료하는 것입니다. 다른 신호를 예상하고 해결해야 했던 사이드카에서 실행되는 타사 코드에 몇 가지 문제가 있었던 것을 기억합니다. 그러나 실제로 컨트롤러는 전송된 신호를 지정하도록 허용해야 했습니다(즉, SIGTERM 대신 SIGINT).

컨트롤러가 exec 를 사용하여 사이드카의 주요 프로세스에 직접 신호를 보내기 때문에 신호를 위해 포트를 수신할 필요가 없습니다. 그 기능이 클라이언트에 존재하지 않았기 때문에 kubernetes 코드에서 복사된 시점의 IIRC입니다. 나는 이것이 현재 공식 클라이언트에 존재하며 아마도 업데이트되어야 한다고 생각합니다.

Pod 컨테이너에 다음을 추가하면 다른 접근 방식을 알아냅니다.

    securityContext:
            capabilities:
                   add:
                    - SYS_PTRACE

그러면 다른 컨테이너에서 Pid를 grep할 수 있습니다. 기본 컨테이너 끝에서 다음을 실행합니다.
sql_proxy_pid=$(pgrep cloud_sql_proxy) && kill -INT $sql_proxy_pid

@ruiyang2015 이 해킹에 감사드립니다.
그래도 구현하는 사람이 있다면 컨테이너 간에 프로세스 ns를 공유하는 것의 의미 를

@nrmitchi

exec를 사용하여 사이드카의 주요 프로세스에 직접 신호를 보냅니다.

그것이 내가 질문한 이유의 일부입니다. 특히 FROM scratch 빌드된 이미지를 기반으로 하는 컨테이너에서는 이것이 작동하지 않는지 궁금합니다.

@krancour 공정한 요점, 나는 scratch 떨어져있는 컨테이너로 가서 테스트 한 적이 없습니다. 코드(또는 내 원래 버전, 포크에서 변경되었을 수 있음)를 보면 bash 에 종속되는 것처럼 보이지만 수정할 수 있어야 합니다.

bash에 의존할 것이지만 수정할 수 있어야 합니다.

물론, 하지만 실행되는 한 항상 컨테이너에 있는 일부 바이너리에 종속되고 스크래치 컨테이너의 경우 명시적으로 거기에 넣는 것 외에는 _아무것도_ 없습니다. 🤷‍♂

이러한 제한 사항을 감안할 때 실행 중인 컨테이너가 완전히 임의적이고 제3자가 지정한 경우에는 이를 사용할 수 없습니다. 아, 그리고 Windows 컨테이너도 사용 중입니다.

내가 대신 해결하려고 하는 것에 대해 언급하겠습니다. 아마도 대부분의 사용 사례에는 너무 무겁지만 다른 사람의 사용 사례가 나와 비슷한 경우를 대비하여 언급하는 것입니다.

종료 상태를 먼저 기록하기만 하면 "기본" 컨테이너가 종료된 포드를 단순히 _삭제_하는 사치를 누릴 수 있습니다. 그래서 나는 완료를 위해 일부 지정된(주석을 통해) 컨테이너를 모니터링하고, 이미 "작업" 상태를 추적하는 데이터 저장소에 성공 또는 실패를 기록한 다음, 포드를 완전히 삭제하는 컨트롤러를 작성하게 될 것입니다.

좋은 측정을 위해, 어뢰가 발생하기 전에 기본 컨테이너 출력의 마지막 몇 줄을 얻을 수 있는 중앙 로그 집계의 가능성을 최대화하기 위해 포드 삭제에 약간의 지연을 둘 것입니다.

무겁지만 일부에게는 효과가 있을 수 있습니다.

@krancour 완전히 사실입니다. 그대로 컨트롤러는 임의의 사용 기반에서 작동하지 않습니다. 솔직히 저는 이전에 언급한 KEP가 병합되어 이 기능에 대한 필요성을 무의미하게 만들 것이라고 정말로 생각했기 때문에 다시 돌아가서 다른 경우를 지원하기 위해 구현의 일부를 추상화하려고 시도하지 않았습니다.

이 문제가 4년 전의 일이고 KEP가 아직 아무데도 가지 않았고 최신 기술이 모든 진입점을 대체하는 해킹 인라인 셸 스크립트라는 점을 감안할 때 "표준" 핵(공유 볼륨의 삭제 표시)을 성문화하기로 결정했습니다. ) 다단계 빌드를 사용하여 컨테이너 이미지로 쉽게 구울 수 있는 Go 바이너리로.

https://github.com/karlkfi/kubexit

몇 가지 사용 방법이 있습니다.

1. 당신의 이미지에 굽기
2. init 컨테이너와 임시 볼륨을 사용하여 사이드 로드합니다.
3. 각 노드에 프로비저닝하고 호스트 바인드 마운트를 사용하여 컨테이너에 사이드 로드

편집: v0.2.0은 이제 "출생 종속성"(지연된 시작) 및 "사망 종속성"(자체 종료)을 지원합니다.

드라이브 바이 코멘트: https://github.com/kubernetes/enhancements/issues/753 과 정확히 같습니다.

@vanzin 은 KEP가 무기한 보류 중이라고 이전에 언급했습니다 .

이에 대한 나의 사용 사례는 Vault가 CronJob을 실행할 자격 증명을 제공한다는 것입니다. 작업이 완료되면 Vault 사이드카는 보류 상태의 작업과 함께 계속 실행되고 모니터링 시스템에서 문제가 있다고 생각하게 합니다. KEP에 일어난 일은 유감입니다.