cc @ironcladlou @bgrant0607

사양을 변경하지 않고 포드를 다시 시작하는 사용 사례는 무엇입니까?

포드가 다시 시작될 때 실패하기 시작한 경우 변경 사항을 롤백할 수 있는 방법이 없습니다.

서비스가 쐐기형이거나 바람직하지 않은 상태가 될 때마다(최대 연결 및 현재 중단됨, 잘못된 내부 상태 등). 서비스가 심각하게 오작동하는 경우 일반적으로 첫 번째 문제 해결 단계 중 하나입니다.

첫 번째 포드가 다시 시작될 때 실패하면 계속을 중단하거나 포드를 시작하기 위해 계속 재시도할 것으로 예상합니다.

또한 사양 변경 없이 롤링 다시 시작하면 전체에 포드가 재할당됩니다.
무리.

그러나 일정을 재조정하지 않고도 이 작업을 수행할 수 있는 기능을 원합니다.
꼬투리. 이는 롤링 레이블 변경일 수 있지만 새로운 동적
로컬 파일 상태를 구성하거나 지웁니다.

2015년 9월 2일 수요일 오전 12시 1분에 Sam Ghods [email protected]이 다음과 같이 썼습니다.

서비스가 일부 쐐기형 또는 바람직하지 않은 상태가 될 때마다(최대
연결이 중단되고 내부 상태가 좋지 않음 등). 그것은 일반적으로
서비스가 심각한 경우 첫 번째 문제 해결 단계 중 하나
잘못된 행동.

첫 번째 포드가 다시 시작될 때 실패하면 중지될 것으로 예상됩니다.
계속하거나 계속해서 포드를 시작하려고 시도합니다.

—
이 이메일에 직접 답장하거나 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136931790
.

클레이튼 콜먼 | 수석 엔지니어, OpenShift

@smarterclayton 위에 나열된 내 옵션 2와 같습니까? 라벨이 변경되는 이유는 무엇입니까?

답장. wedged: 이것이 바로 활성도 프로브의 용도입니다.

답장. 재조정: #12140 참조

우리가 이것을 지원한다면 #9043으로 묶을 것입니다. 동일한 메커니즘이 필요합니다.

이것은 포드가 살아 있고 검사에 응답하지만 여전히 다시 시작해야 하는 상황에 더 적합하다고 생각합니다. 한 가지 예는 메모리 내 캐시 또는 내부 상태가 손상되어 지워야 하는 서비스입니다.

응용 프로그램을 다시 시작하도록 요청하는 것은 상당히 일반적인 사용 사례인 것 같지만 아마도 제가 틀릴 수 있습니다.

부패는 단지 하나의 꼬투리일 뿐이며 RC로 대체될 수 있습니다.

오프라인에서 언급된 다른 경우는 구성을 다시 읽는 것입니다. 어떤 이유로든 다시 시작하면 컨테이너가 새 구성을 로드하게 되므로 암시적으로 수행하는 것은 위험합니다. 새로운 버전의 구성 참조(예: env var)를 포드에 푸시하려면 롤링 업데이트를 수행하는 것이 좋습니다. 이것은 동기 #1353과 유사합니다.

@bgrant0607 우리는 이것을하고 싶지 않다고 결정 했습니까?

@gmarek 현재 아닙니다 . 너무 많은 일이 이미 진행 중입니다.

중요하다고 생각하는 항목에 대해 post v1.1 이정표(또는 무언가)를 가질 수 있지만 즉시 수정할 사람이 부족합니까?

나도 이 기능의 팬이 될 것입니다. 롤아웃하려는 모든 사소한 업데이트에 대해 강제로 태그를 전환하고 싶지는 않을 것입니다.

저는 이 기능의 팬입니다. 사용 사례: 새로 푸시된 도커 이미지( imagePullPolicy: Always )를 사용하도록 모든 포드를 쉽게 업그레이드합니다. 저는 현재 약간의 해키 솔루션을 사용하고 있습니다. 이미지 이름에 :latest 태그가 있거나 없는 롤링 업데이트입니다.

또 다른 사용 사례: 비밀 업데이트.

이 기능을 정말 보고 싶습니다. kubernetes에서 노드 앱을 실행하고 현재 앱 의사 캐싱에서 지우기 위해 포드를 다시 시작하는 특정 사용 사례가 있습니다.

지금 하고 있는 일은 다음과 같습니다.

kubectl get pod | grep 'pod-name' | cut -d " " -f1 - | xargs -n1 -P 10 kubectl delete pod

이렇게 하면 포드 10개를 한 번에 삭제하고 복제 컨트롤러 설정에서 잘 작동합니다. 포드 할당 또는 새 포드 시작 실패와 같은 문제는 다루지 않습니다. 필요할 때 빠른 솔루션입니다.

나는 롤링 재시작을 할 수 있기를 정말로 원합니다.
주된 이유는 ConfigMap을 사용하여 Pod에 ENV 변수를 제공한 다음 구성을 변경하는 경우 해당 ConfigMap의 소비자를 다시 시작해야 하기 때문입니다.

예, 내부 변경 없이 포드/컨테이너를 다시 시작하려는 경우가 많습니다...
구성, 캐시, 외부 서비스 재접속 등. 이 기능이 개발되기를 진심으로 바랍니다.

작은 해결 방법(배포를 사용하고 이미지/포드를 실제로 변경하지 않고 구성을 변경하고 싶습니다):

• configMap 생성
• 모든 컨테이너에서 ENV 변수를 사용하여 배포 생성(배포에 대한 지표로 사용)
• configMap 업데이트
• 배포 업데이트(이 ENV 변수 변경)

k8s는 배포 정의가 변경되었음을 확인하고 포드 교체 프로세스를 시작합니다.
추신:
누군가 더 나은 솔루션을 가지고 있다면 공유하십시오

@paunin 감사합니다

@paunin 그것이 바로 우리가 현재 필요로 하는 경우입니다. 서비스에 매우 중요한 ConfigMap 값을 변경해야 하며 몇 분에서 몇 시간 내에 컨테이너에 롤아웃해야 합니다. 그 동안 배포가 발생하지 않으면 컨테이너가 모두 동시에 실패하고 최소 몇 초의 부분적 다운타임이 발생합니다.

from (kinda-related #9043): @paunin 의 접근 방식을 한 RESTART_ 는 환경 변수이고 ISO 타임스탬프로 설정됩니다.

kubectl patch deployment mydeployment \
-p'{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"$(date -uIseconds)"}]}]}}}}'

(어떤 이유로 _ 시작하는 환경 변수가 사라지는 것처럼 보이고 숫자 env value 가 오류를 일으키므로 문자열이어야 함)

@paunin @rcoup 우리는 요즘 매우 비슷한 일을 하고 있습니다. 말 그대로 "DUMMY_VAR_FOR_NO_OP_DEPLOYMENT"라는 환경 변수가 있습니다.

여기에서 올바른 솔루션을 사용하면 배포를 다시 시작하고 MinReadyCount와 같은 롤아웃을 위해 대부분의 배포 매개변수를 재사용할 수 있는 동시에 모든 것이 즉시 바운스되어야 하는 비상 상황에 대한 병렬 처리를 늘리는 것과 같은 명령줄 재정의를 허용할 수 있을 것 같습니다.

이에 대한 진전이 있습니까?

이 추가는 CLI API의 불필요한 팽창이라고 생각합니다. 이는 @paunin이 제안한 대로 배포 환경 변수 값

우리는 또한 kubectl restart deployment some-api 와 같은 배포에 대해 이것을 보고 싶습니다.

Kubernetes는 모든 종류의 이유로 Pod를 다시 시작할 수 있지만 클러스터 관리자는 허용되지 않습니다.
껐다가 다시 켜는 방식이 바람직한 운영 방식이 아닐 수도 있다는 도덕적 입장은 이해합니다만.. 원하는 분들이 범위에 의존하지 않고 디플로이먼트를 다시 시작하게 하는 것도 괜찮을 거라고 생각합니다. 다음과 같은 덜 식욕을 돋우는 트릭:

• 포드 삭제
• 더미 레이블
• 더미 환경 변수
• 환경 변수에 매핑된 더미 구성 맵
• 작업자 노드 재부팅
• 데이터 센터 전력 차단 😄

'아니요, 아니요, 아무것도 다시 시작하지 않고 여기 이 레이블의 오타를 수정하는 것뿐입니다' 😛

이 기능은 kubectl apply 와 함께 사용하면 유용합니다. apply 는 복제 컨트롤러를 포함하여 구성을 업데이트하지만 포드는 다시 시작되지 않습니다.

따라서 이러한 포드를 Blue-Green 방식으로 다시 시작하는 방법이 필요합니다.

@DmitryRomanenko ReplicationController에서 Deployment로 전환하는

@kargakis 불가능: 배포는 복제본 세트 및
kubectl apply ConfigMaps, Services 등도 업데이트합니다.

@DmitryRomanenko 문제가 "ConfigMap/Secret이 업데이트될 때 Pod를 다시 시작하고 싶습니다"인 경우 가능한 솔루션은 ConfigMap 및 Secrets에 대한 버전을 갖고 해당 버전을 배포 사양의 일부로 만드는 것입니다. 따라서 kubectl apply 하면 Deployment 사양이 변경되고 Pod가 다시 생성됩니다.
다른 상황에서는 Pod를 다시 시작해야 하는 이유를 알 수 없습니다(Service/Ingress/etc 업데이트를 의미함).

@tyranron , 감사합니다! ConfigMap 버전을 만드는 가장 좋은 방법은 무엇입니까? 새 배포에 대해 다른 이름으로 새 구성 맵을 생성해야 합니까?

@DmitryRomanenko 실제로 할 수 있습니다. 왜

여기서 가장 좋은 솔루션은 configmap 개체에 대한 일종의 감시자 또는 해시섬 검사기가 될 수 있다고 생각합니다. 관련 개체/포드 재시작을 트리거해야 합니다(모든 것이 configmap , secret ). k8s 아키텍처에서 액세스할 수 있는지 확실하지 않지만...

또한 configmap|secret 개체에서 제어하여 변경 사항에 따라 다시 시작 여부를 트리거하는 것이 더 낫다고 생각합니다.

@tyranron ,

따라서 kubectl을 적용하면 Deployment 사양이 변경되고 Pod가 다시 생성됩니다.

설명해 주시겠습니까? 업데이트된 배포와 함께 kubectl apply -f new_config.yml 를 사용해야 하며 이러한 배포는 롤링 다시 시작됩니까?

@DmitryRomanenko 네 맞습니다 .

@DmitryRomanenko 새로운 사양을 적용하면된다 배포를 업데이트 하고, 그 사양이 변경된 경우 배포에 업데이트 다시 시작 트리거됩니다.

기본적으로 다시 시작 전략은 RollingUpdate 이지만 다른 전략을 명시적으로 지정할 수도 있습니다.

90일 동안 활동이 없으면 문제가 부실해집니다.
/remove-lifecycle stale 하여 문제를 최신으로 표시합니다.
부실 문제는 추가로 30일 동안 사용하지 않으면 썩고 결국 닫힙니다.

/lifecycle frozen 주석으로 이슈가 자동으로 닫히지 않도록 합니다.

이 문제를 지금 종료해도 안전하다면 /close .

sig-testing, kubernetes/test-infra 및/또는 @fejta 피드백을 보내십시오.
/수명 주기 부실

@rcoup 의 솔루션에 대한 약간의 변경: date 가 쉘 내에서 평가되는지 확인하십시오.

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

/remove-lifecycle 부실
/수명 주기 동결

Kubernetes보다 유연하지 않은 것으로 간주되는 Swarm 모드를 한동안 사용하여 docker service update --force <service-name> 과 같이 강제 업데이트(사양 변경 없이)를 수행하여 서비스 작업(읽기: 배포 포드)을 다시 시작할 수 있습니다
configmaps 및 secrets의 경우 swarm에서는 편집을 허용하지 않으므로 대신 회전해야 합니다. 새로운 configmaps/secrets를 생성하고, 새로운 것을 사용하도록 서비스 사양을 업데이트하고, 이전 것들을 삭제함으로써 이를 수행합니다. 이것은 일반적으로 configmaps/secerts의 버전을 관리하고 이를 사용하는 배포를 업데이트하여 위에서 권장하는 것입니다. 솔직히 말해서, 이 회전 동작은 내가 Swarm을 떠난 주요 이유 중 하나입니다! 로컬 복사본을 가지고 업데이트한 다음 새 리소스를 만들고 마지막으로 종속 리소스를 업데이트하는 것은 매우 불편합니다. 추가로 swarm의 비밀은 API에서 읽을 수 없으므로 모든 컨테이너(또는 이를 사용하는 컨테이너 내부의 exec)에 탑재한 다음 파일을 cat 해야 합니다.
관련 메모에서 나는 얼마 동안 openshift를 사용했으며 env/configmap/secret 변경 시 포드를 자동으로 다시 시작한다고 생각합니다. 그래도 정정합니다.

언급한 대로 configmap/secret에서 체크섬을 사용하고 그런 식으로 강제로 다시 시작할 수 있습니다.

그러나 구성을 전혀 변경하고 싶지 않고 임의의 일시 중지로 롤링 재시작을 수행하면 간단한 파이프라인이 작업을 수행합니다(종료된 포드 사이에 30초 대기)

kubectl get po -l release=my-app -o name | cut -d"/" -f2 | while read p;do kubectl  delete po $p;sleep 30;done

ctrl+c를 누르면 중단한 부분부터 다시 시작하기가 쉽지 않습니다.

@so0k , 대체 명령:

kubectl get pods|grep somename|awk '{print $1}' | xargs -i sh -c 'kubectl delete pod -o name {} && sleep 4'

2년 반이 지났지만 사람들은 더미 환경 변수, 더미 레이블, ConfigMap 및 Secret 감시자 사이드카, 0으로 조정, 롤링 업데이트를 트리거하는 기능을 시뮬레이션하는 롤링 업데이트 셸 스크립트를 사용하여 여전히 새로운 해결 방법을 만들고 있습니다. 이것이 여전히 클러스터 관리자가 트릭 없이 정직하게 해서는 안 되는 일입니까?

27081 #33664 https://github.com/kubernetes/helm/issues/2639

https://stackoverflow.com/questions/41735829/update-a-deployment-image-in-kubernetes

kubectl scale --replicas=0 deployment application
kubectl scale --replicas=1 deployment application

https://stackoverflow.com/questions/40366192/kubernetes-how-to-make-deployment-to-update-image

또 다른 트릭은 처음에 다음을 실행하는 것입니다.

kubectl set image deployment/my-deployment mycontainer=myimage:latest

그리고:

kubectl set image deployment/my-deployment mycontainer=myimage

실제로 롤링 업데이트를 트리거하지만 imagePullPolicy: "항상"도 설정되어 있는지 확인합니다.

이미지 이름을 변경할 필요가 없는 또 다른 트릭은 TerminationGracePeriodSeconds와 같이 롤링 업데이트를 트리거할 필드 값을 변경하는 것입니다. kubectl edit deployment your_deployment 또는 kubectl apply -f your_deployment.yaml을 사용하거나 다음과 같은 패치를 사용하여 이 작업을 수행할 수 있습니다.

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

http://rancher.com/docs/rancher/v1.4/en/cattle/upgrading/

# Force an upgrade even though the docker-compose.yml for the services didn't change
$ rancher-compose up --force-upgrade

@so0k @KIVagant 포드 삭제는 여러 인스턴스를 실행하는 경우에도 다운타임을 의미합니다. 누군가 strategy.rollingUpdate.maxUnavailable = 0 로 단일 포드를 실행하면 일반 배포는 기존 포드를 종료하기 전에 먼저 새 포드를 생성합니다. kubectl patch deployment 트릭은 이 동작을 트리거하지만 포드를 삭제하면 그렇지 않습니다. 요청 시 이 동작을 트리거하는 비핵화 방법을 정말 원합니다.

예를 들어, hub.docker.com에서 이미지를 실행할 때 보안 업데이트를 위해 동일한 태그를 패치할 수 있습니다. "최신 이미지를 가져오고" 오래된 이미지에 대해 롤링 업데이트를 수행하고 싶습니다.

ConfigMap/비밀 업데이트 롤아웃은 #22368입니다.
새 이미지의 더 쉬운 롤아웃은 #1697입니다.
인플레이스 롤링 업데이트는 #9043입니다.

이미지 빌드에서 다시 시작: https://github.com/GoogleCloudPlatform/freshpod
템플릿 주석을 사용하여 배포 롤아웃을 트리거하는 트릭에 대한 Helm Summit 프레젠테이션: https://www.youtube.com/watch?v=dSw0w1x96ak

@bgrant0607 다른 티켓에서 다루지 않는 중요한 사용 사례는 다음과 같습니다. https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -136946912

@ghodss 는 다음
이것은 포드가 살아 있고 검사에 응답하지만 여전히 다시 시작해야 하는 상황에 더 적합하다고 생각합니다. 한 가지 예는 메모리 내 캐시 또는 내부 상태가 손상되어 지워야 하는 서비스입니다.

응용 프로그램을 다시 시작하도록 요청하는 것은 상당히 일반적인 사용 사례인 것 같지만 아마도 제가 틀릴 수 있습니다.

수동 트릭 없이 모든 애플리케이션 상태를 지우기 위해 롤링 다시 시작을 강제하고 싶습니다.

@rcoup 과 @paunin이 설명한 접근 방식을 기반으로 한 비슷한 한 줄 짜리가 있지만 더 일반적인 경우에 작동해야 합니다. JSON 출력에 의존하고 구문 분석을 위해 jq를 사용합니다. 나는 이것을 함수로 내 bashrc에 로드하여 어디서나 호출할 수 있습니다.

kubectl-restart() {
  kubectl get deploy $1 -o json | jq \
    'del(
      .spec.template.spec.containers[0].env[]
      | select(.name == "RESTART_"))
    | .spec.template.spec.containers[0].env += [{name: "RESTART_", value: now|tostring}]' | kubectl apply -f -
}

이것은 내가 kubectl-restart my-deployment-name 라고 말할 수 있게 하고 첫 번째 컨테이너의 RESTART_ env var를 현재 타임스탬프로 "업데이트"합니다. 나는 jq 전문가와 거리가 멀기 때문에 더 나은 방법이 있을 수 있지만 기본적으로 출력에서 ​​이전 RESTART_ env var를 삭제한 다음(존재하는 경우) 거기에 다시 추가합니다. 현재 시간.

이 작업을 수행하는 기본 방법이 없다는 것이 제게는 매우 이상하게 느껴지지만... 확실히 엔지니어들로 가득 찬 회의실은 "껐다가 다시 켜는" 기능이 우리가 갖고 싶어하는 기능이라는 데 동의할 것입니다.

그것은 좋은 해킹이지만 큰 단점이 있습니다. 다음에 kubectl apply -f 사용하여 배포할 때 다른 변경 사항이 없더라도 RESTART_xxx 환경 변수가 있으면 해당 구성 요소가 다시 시작됩니다. 즉, 마지막 배포와 이 배포 사이에 다시 시작된 적이 있는 경우 다음 배포에서 잘못된 다시 시작이 발생합니다. 이상적이지 않은...

이것이 바로 롤링 재시작 기능이 맨 위에 구축되지 않고 배포 컨트롤러에 구워져야 하는 이유입니다.

나는 위의 그의 의견 (출처: https://stackoverflow.com/a/40368520/90442)에서 인용된 " terminationGracePeriodSeconds 의 패치 배포" 전략 @whereisaaron 을 수행하기 위해 bash 함수를 작성했습니다.

# $1 is a valid namespace
function refresh-all-pods() {
  echo
  DEPLOYMENT_LIST=$(kubectl -n $1 get deployment -o json|jq -r .items[].metadata.name)
  echo "Refreshing pods in all Deployments"
  for deployment_name in $DEPLOYMENT_LIST ; do
    TERMINATION_GRACE_PERIOD_SECONDS=$(kubectl -n $1 get deployment "$deployment_name" -o json|jq .spec.template.spec.terminationGracePeriodSeconds)
    if [ "$TERMINATION_GRACE_PERIOD_SECONDS" -eq 30 ]; then
      TERMINATION_GRACE_PERIOD_SECONDS='31'
    else
      TERMINATION_GRACE_PERIOD_SECONDS='30'
    fi
    patch_string="{\"spec\":{\"template\":{\"spec\":{\"terminationGracePeriodSeconds\":$TERMINATION_GRACE_PERIOD_SECONDS}}}}"
    kubectl -n $1 patch deployment $deployment_name -p $patch_string
  done
  echo
}

여기 요점을 통해 댓글을 하세요 . 나는 이것이 필요하지 않다면 더 좋을 것이라는 다른 사람들의 의견을 반영할 것입니다.

보다 구체적으로 kube 관련 정당화를 통해 다시 시작하면 키를 롤링하거나 구성을 업데이트하거나 초기화 컨테이너를 사용하는 데 사용할 수 있는 초기화 컨테이너를 다시 실행할 수도 있습니다.

@ kubernetes / sig-apps-feature-requests @ kow3ns @janetkuo

@gjcarneiro 적용한 구성에 RESTART_xxx env var가 있습니까, 없습니까? 그렇지 않은 경우 라이브 상태에서 추가 env var를 무시하도록 적용할 것으로 예상합니다.

cc @apelisse

@gjcarneiro 예, @mattdodge 스크립트의 문제는 적용을 사용하고 있으므로 변경 사항이 lastApplied 주석에 저장된다는 것입니다. 패치 또는 다른 방법을 사용하여 배포를 업데이트하여 스크립트를 수정할 수 있습니다.

이 기능이 있으면 좋겠습니다. 매우 기본적이고 필요한 것 같습니다.

여기도 #22368에도 진전이 없습니다. 한숨 쉬세요 :-(

마운트된 ConfigMap이 업데이트된 후 DaemonSet를 다시 시작하는 빠르고 더러운 솔루션을 추천할 수 있는 사람이 있습니까(이름은 여전히 ​​동일함)?

@alcohol , 이것을 확인하십시오 https://github.com/kubernetes/kubernetes/issues/13488#issuecomment -356892053

팁 고마워 :-)

Openshift에는 이미지 변경, 웹훅 또는 구성 변경에 대한 롤아웃을 트리거하는 배포 트리거 개념이 있습니다. Kubernetes에 있으면 매우 좋은 기능입니다. 물론 수동 롤아웃도 마찬가지입니다.

또한 Docker 저장소에는 기록이 있으므로 롤백이 작동하지 않을 이유가 없습니다. .spec.template 에서 생성된 포드는 컨테이너의 이미지를 가져올 때 image-tag:@digest 형식을 사용할 수 있습니다. 롤백은 이전 롤아웃의 다이제스트 ID를 사용합니다.

내가 올바르게 이해하고 있는지 확실하지 않습니다. 이것이 누군가에게 도움이되는 경우를 대비하여.

포드 > 템플릿 > 메타데이터에서 레이블 값을 업데이트하면 kubectl apply -f file.yaml 이후에 롤링 업데이트가 발생하는 것 같습니다.

따라서 항상 버전에 대한 레이블을 가질 수 있고 롤링 업데이트를 원할 때마다 버전을 변경하고 파일을 적용할 수 있습니다.

물론 단점은 다음에 배포할 때 kubectl apply -f some.yaml . 맞죠? 일반적으로 some.yaml 에서 아무 것도 변경되지 않으면 아무 것도 다시 시작되지 않는 것이 Kubernetes의 가장 좋은 점 중 하나입니다.

그러나 레이블을 변경하여 배포를 다시 시작한 후 어떤 일이 발생하는지 상상해 보십시오. 다음 일반 소프트웨어 배포에서는 평소와 같이 kubectl apply -f some.yaml 를 수행하지만 yaml 파일에 동일한 레이블이 포함되어 있지 않기 때문에 배포가 불필요하게 다시 시작됩니다.

@gjcarneiro apply 변경하지 않으면 kubectl.kubernetes.io/last-applied-configuration 주석이 업데이트되지 않으므로 다음 apply 인해 다시 시작되지 않습니다.

나는 kubectl에 롤링 재시작 명령을 추가하는 것을 강력히 지지하지만 그 동안에는 다음을 사용하고 있습니다(위의 솔루션을 기반으로 함).

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"RESTART_","value":"'$(date +%s)'"}]}]}}}}'

이것을 매개변수화하고 .bashrc에 함수로 추가하면 좋은 임시 솔루션입니다.

아 그렇군요 몰랐네요 감사합니다!

나는 bash 별칭이 필요하지 않습니다. 우리 회사에서 Python+aiohttp를 사용하여 Kubernetes를 관리하기 위한 자체 웹 인터페이스를 만들었고 이미 패치를 사용하고 있습니다. 오픈소스로 할까 생각하다가 그냥 게을러서...

사람들이 이 스레드에서 동일한 해결 방법을 반복하는 것 같습니다. 여기에 게시하기 전에 전체 스레드를 읽으십시오.

@joelittlejohn 매크로를 실행했는데 내 포드가 재부팅되었지만 모두 동시에 다시 시작되었습니다. 나는 이것이 롤링 재부팅을 유발할 것이라고 생각했습니다.

@Macmee 배포 구성에 따라 다릅니다. 위의 명령은 배포만 변경합니다. 그런 다음 배포에서 정의한 롤아웃 strategy 에 따라 포드가 업데이트됩니다. 이는 배포에 대한 다른 변경 사항과 같습니다.

이것이 동시에 모든 포드를 대체하는 유일한 방법은 .spec.strategy.rollingUpdate.maxUnavailable 허용하는 경우입니다.

우리도 이 기능이 필요합니다. 우리 측의 한 가지 사용 사례는 우리의 spring-boot 앱에 대해 및 scm가 지원하는 spring-cloud-config-server를 사용하는 것입니다. 구성 속성을 변경할 때 새 구성 변경을 가져올 수 있도록 스프링 부트 앱을 다시 시작해야 하므로 재배포를 수행하지 않고도 이러한 종류의 우아한 재시작 트리거가 필요합니다.

@japzio Helm이 제안한 것처럼 주석의 configmap 체크섬은 이 경우를 처리하는 좋은 방법입니다.

이것에 대한 업데이트가 있습니까? 우리도 이 기능을 찾고 있습니다. @bgrant0607 @nikhiljindal

@bholagabbar-mt 사용 사례는 무엇입니까?

cc @kow3ns @janetkuo

@bgrant0607 @kow3ns @janetkuo 우리 시스템의 사용

1. 비밀 업데이트 - 저와 같이 kubernetes를 통해 자체 추상화를 구축한 회사가 많이 있다는 것을 알고 계실 것입니다. 우리는 kubernetes를 통해 오케스트레이션되는 자체 컨테이너 관리 시스템을 보유하고 있습니다. 따라서 투구 비밀 제안 댓글 등은 해당되지 않습니다. dev 클러스터의 ConfigMaps에서 비밀을 다시 로드하려면 포드를 강제 종료해야 하므로 몇 초의 가동 중지 시간이 발생합니다. 이런 경우가 있어서는 안 됩니다. 이것은 롤링 업데이트의 실제 사용 사례입니다.

2. 이것은 약간 복잡하지만 누군가가 제안한 것처럼 전반적인 범위는 비정상적인 동작을 수정하는 것입니다. Play 프레임워크에서 실행되는 4-5개의 무거운 Java 앱이 있습니다. Java 포드의 메모리 소비가 선형적으로 증가한 다음 메모리 제한에 도달하면 포드를 다시 시작하는 상황이 발생했습니다. 이것은 stackoverflow 문제 및 이와 관련된 Kubernetes 문제 가 있는 문서화된 Java 문제입니다. 3-4시간 동안 모든 포드를 롤링-다시 시작하면 메모리 소비가 재설정되고 앱이 스파이크 없이 원활하게 작동할 수 있습니다.

이것이 충분히 설득력이 있기를 바라며 이 기능은 개발을 위해 누군가가 채택할 수 있습니까?

@bholagabbar-mt 환경 변수를 변경하면 롤링 배포가 트리거됩니다.

kubectl patch deployment mydeployment -p '{"spec":{"template":{"spec":{"containers":[{"name":"mycontainer","env":[{"name":"LAST_MANUAL_RESTART","value":"'$(date +%s)'"}]}]}}}}'

@montanaflynn 완벽합니다. 우리는 이 변경 사항을 현재 시스템 자체에 통합했으며 잘 실행되고 있습니다. 정말 감사합니다!

cc @huzhengchuan

이에 대한 또 다른 사용 사례: containerd의 보안 문제로 인해 모든 포드를 다시 시작하고 싶습니다. https://seclists.org/oss-sec/2019/q1/119 클러스터가 완전히 다운되거나 롤링 재시작을 수행합니다. 다시 시작 명령을 사용하면 큰 차이를 만들 것입니다!

업데이트 , 해결 방법:

kubectl set env --all deployment --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...
kubectl set env --all daemonset --env="LAST_MANUAL_RESTART=$(date +%s)" --namespace=...

@realfresh 당신은 모범 사례입니다. 목장에 annotation:{creatTime: 12312312} 추가!

kubectl set env deployment mydeployment --env="LAST_RESTART=$(date)" --namespace ...

하나의 배포에 대한 작업을 수행하는 최소한의 명령인 것 같습니다. 명령형 구성을 사용한 예입니다.

cc @monopole @apelisse

~2~ 3 년 반이 지났지만 사람들은 더미 환경 변수, 더미 레이블, 더미 주석 , ConfigMap 및 Secret 감시자 사이드카, 0으로 조정, 기능을 시뮬레이션하기 위한 롤링 업데이트 셸 스크립트를 사용하여 여전히 새로운 해결 방법을 만들고 있습니다. 롤링 업데이트를 트리거합니다. 이것이 여전히 클러스터 관리자가 트릭 없이 정직하게 해서는 안 되는 일입니까?

롤링 업데이트는 아직 사용 사례가 없는 것으로 보이는 매우 인기 있는 활동입니다 😄

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

1. 명령형 논리가 선언적 API로 흘러 들어가게 하여 API를 선언적으로 유지하고 컨트롤러에서 명령적 동작을 구현하고 대부분의 CI/CD 관행과 비호환성을 도입하는 관습을 깨뜨리지 않고는 이 작업을 수행할 방법이 없습니다.
2. RollingRestart 리소스 생성으로 인해 컨트롤러가 축출을 통해 Pod 1을 1씩 다시 시작하는(따라서 중단 예산을 고려한) RollingRestart API 및 컨트롤러를 상상할 수 있지만 이러한 컨트롤러를 CRD로 구현할 수 있습니다. 우리는 이것을 트리에서 해야 합니다).
3. 예를 들어 lastRestartedAt=TIMESTAMP 주석을 추가하는 것과 같은 선언적 접근 방식은 나에게 해킹처럼 보이지 않습니다.
4. 누구든지 이 기능을 구현하기 위해 선언적 디자인과 기여를 제공하고 싶다면(트리 또는 다른 방식으로) 개선된 저장소 에 대해 KEP PR을 작성하는 것을 고려하십시오. 선언적인 기본 제공 구현을 설계할 수 있다면 기꺼이 워크로드 API를 검토/공유하겠습니다. [2]와 같은 CRD 컨트롤러가 제공되면 SIG Apps에서 커뮤니티 후원 확장으로 후원할 수 있습니다.

예를 들어 lastRestartedAt=TIMESTAMP 주석을 추가하는 것과 같은 선언적 접근 방식은 나에게 해킹처럼 보이지 않습니다.

해킹이 아닙니다. 이에 대한 약식 명령줄만 있어야 합니다.

누군가는 패치를 보내는 크루 플러그인을 만들 수 있습니다. kubectl restart-deployment <deployment_name> ?

새로운 '롤아웃'을 트리거하기 위해 배포/데몬셋/스테이트풀셋을 패치하는 kubectl rollout restart ?

이는 @kow3ns 의 접근 방식(3)과 일치하며 다른 kubectl rollout 명령으로 방금 시작한 롤아웃을 시청/일시 중지/재개할 수 있기 때문에 의미가 있습니다.

@whereisaaron 패치를 보낼 수 있는지 확인하겠습니다 (말장난이 아님)

새로운 비밀과 configmaps를 롤아웃하기 위해 내 권장 사항은 여전히 ​​#22368: 새 비밀 만들기입니다. 이는 롤아웃을 제어하고 롤백하는 수단을 제공합니다. 오래된 객체의 GC만 완료하면 됩니다.
https://github.com/kubernetes/community/pull/1163
https://github.com/kubernetes/community/pull/2287

그러나 기존 API로 롤링 재시작을 수행하는 권장 방법을 문서화 및/또는 지원(kustomize, kubectl 또는 kubectl 플러그인에서)하는 것이 합리적입니다.

cc @모노폴

새로운 이미지의 경우, CI/CD 또는 태그를 다이제스트로 해석하는 컨트롤러: #1697.

불행한 포드를 이동하는 것은 descheduler(https://github.com/kubernetes-incubator/descheduler) 또는 이와 유사한 것으로 컨테이너 상태, 핵심 메트릭 및 사용자 지정 메트릭을 사용할 수 있습니다.

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduler.md
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/rescheduling.md

또한 비밀 및 configmap을 처리하는 방법에 대한 공식 문서: https://kubectl.docs.kubernetes.io/pages/app_management/secrets_and_configmaps.html

롤링 재시작이 매우 필요합니다. 한 가지 예는 AWS에서 SSM의 모든 비밀을 가져오는 것입니다. SSM에서 일부 비밀을 변경하면 포드가 부팅될 때 최신 정보를 선택할 수 있도록 롤링 재시작을 수행하고 싶습니다. 또한 실제 수정 사항이 프로덕션에 적용될 때까지 롤링 다시 시작해야 하는 응용 프로그램 문제가 있는 경우도 있습니다.

알겠습니다. kubectl rollout restart 이(가) 병합되었습니다!

거의 4년만에 듣게 되어서 너무 좋네요, 감사합니다!

병합된 PR은 배포만 지원한다고 생각합니다. 맞습니까?

이 문제의 일부 사람들은 데몬 세트와 상태 저장 세트도 다시 시작해야 할 필요성을 표현했습니다.

@apelisse sdk 또는 kubectl을 통해이 작업을 수행하는 방법도 있습니까?

@e-nikolov SDK가 무엇인가요?

Go 프로그램에서 kubernetes와 대화하는 데 사용할 수 있는 Go 클라이언트를 의미했습니다.

아니요, kubectl에 구현된 (매우 간단한) 로직을 다시 구현해야 합니다.

OK, kubectl 롤아웃 재시작이 병합되었습니다!

어떤 kubectl 버전이 있습니까?

어떤 kubectl 버전이 있습니까?

쿠버네티스 1.15

"신속한" 릴리스 채널의 GKE 클러스터가 Kubernetes 1.16으로 업그레이드되었으며 이제 kubectl rollout restart 작동이 중지되었습니다.

kubectl 롤아웃 다시 시작 배포 myapp
오류: 알 수 없는 명령 "배포 myapp 다시 시작"

@nikhiljindal 은 사양을 변경하지 않고 배포를 업데이트하는 사용 사례에 대해 얼마 전에 질문했습니다. 어쩌면 우리는 최적이 아닌 방식으로 작업을 수행하고 있을 수도 있지만 여기에서는 사전 훈련된 ML 모델이 Google Cloud Storage에서 메모리로 로드됩니다. 모델 파일이 GCS에서 업데이트되면 GCS에서 모델을 가져오는 K8S 배포를 롤아웃 다시 시작하려고 합니다.

이전 모델 파일로 배포를 쉽게 롤백할 수 없다는 점에 감사하지만 모델을 앱에 최대한 가깝게 가져오고 네트워크 호출을 피하기 위해 채택한 절충안입니다(일부는 제안할 수 있음).

안녕하세요 @dimileeh

지금 사용하고 있는 kubectl의 버전을 알고 계십니까? 이전에 사용한 버전은 무엇입니까? 회귀가 있는지 알고 싶지만 동시에 기능이 완전히 사라졌다면 놀랐을 것입니다.

GCS와 관련하여 사용 사례에 대해 거의 알지 못하므로 의미가 없다면 죄송합니다. gcs 모델이 수정될 때마다 다른 이름을 갖도록 제안합니다(해시가 붙은 접미사). 이름이 배포에 포함됩니다. 새 파일을 사용하도록 배포를 업데이트하면 롤아웃이 자동으로 트리거됩니다. 이를 통해 이전 배포/모델로 롤백하고 모델에 발생하는 변경 사항 등을 더 잘 이해할 수 있습니다.

안녕하세요 @apelisse님 , 답변 감사합니다!

Google Cloud Terminal에서 kubectl version 를 실행하면 다음이 표시됩니다.

Client Version: version.Info{Major:"1", Minor:"13+", GitVersion:"v1.13.11-dispatcher", GitCommit:"2e298c7e992f83f47af60cf4830b11c7370f6668", GitTreeState:"clean", BuildDate:"2019-09-19T22:20:12Z", GoVersion:"go1.11.13", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16+", GitVersion:"v1.16.0-gke.20", GitCommit:"d324c1db214acfc1ff3d543767f33feab3f4dcaa", GitTreeState:"clean", BuildDate:"2019-11-26T20:51:21Z", GoVersion:"go1.12.11b4", Compiler:"gc", Platform:"linux/amd64"}

gcloud components update 를 통해 kubectl을 업그레이드하려고 하면 이미 모든 제품의 최신 버전을 사용하고 있다고 표시됩니다. 따라서 K8S 클러스터가 1.15에서 1.16으로 업그레이드되는 동안 내 kubectl 버전은 동일하게 유지되었다고 생각합니다.

Kubenetes 문서 1.17, 1.16 및 1.15에는 kubectl rollout restart 기능에 대한 내용이 없습니다. 그래서 당신의 소중한 기여가 1.16에서 사라질 수 있었는지 궁금합니다.

모델 버전 관리에 대한 제안에 감사드립니다. 우리는 그것에 대해 생각했지만 매일 모델을 재교육하기 때문에 너무 많은 모델을 축적하기 시작할 것이라고 생각했습니다(그리고 상당히 무겁습니다). 물론 시간이 지나면 스크립트를 사용하여 이전 버전을 정리할 수 있지만 지금까지는 kubectl rollout restart 에 의존하고 모델 버전 관리에 신경 쓰지 않고 단순하게 유지하기로 결정했습니다. :)

여기에서 문서를 볼 수 있습니다.
https://v1-16.docs.kubernetes.io/docs/reference/generated/kubectl/kubectl-commands# -em-restart-em-

아, 감사합니다. 여기를 찾고 있었습니다.
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

해당 링크에 대해 대단히 감사합니다. 업데이트되면 확인하겠습니다!

2019년 12월 19일 목요일 오후 12시 40분 Dmitri Lihhatsov [email protected]
썼다:

아, 감사합니다. 여기를 찾고 있었습니다.
https://v1-16.docs.kubernetes.io/docs/reference/kubectl/cheatsheet/

—
당신이 언급되었기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/kubernetes/kubernetes/issues/13488?email_source=notifications&email_token=AAOXDLCDSTPYK6EGBQWSRADQZPL5BA5CNFSM4BOYZ5Z2YY3PNVWWK3TUL52HS4DFVEXG43NVMVBW6
또는 구독 취소
https://github.com/notifications/unsubscribe-auth/AAOXDLHWCU4T6NCSHOYZIELQZPL5BANCNFSM4BOYZ5ZQ
.

@dimileeh PTAL https://github.com/kubernetes/website/pull/18224 (이것이 병합되면 관련 브랜치를 선택하겠습니다).

@dimileeh 귀하의 kubectl 버전에 무엇이 문제인지 파악한 것 같습니다. 우리는 이에 대해 작업할 것입니다.

예, configmap을 업데이트한 후 코드 변경 없이 포드를 다시 시작하는 사용 사례도 있습니다. 서비스를 다시 배포하지 않고 ML 모델을 업데이트하기 위한 것입니다.

실행할 수 있는 최신 버전의 @anuragtr

kubectl rollout restart deploy NAME

[1]에 대한 사용자 지정 명령을 사용하고 있었는데 이제 표준 kubectl에 포함되어 기쁩니다! 감사 해요

[1] https://github.com/mauri870/kubectl-renew

실행할 수 있는 최신 버전의 @anuragtr

kubectl rollout restart deploy NAME

@countrogue