Kubernetes에서 configmap이 업데이트되면 포드를 다시 시작 하시겠습니까?

configmap이 변경 / 업데이트 될 때 배포와 연결된 Kubernetes 포드 및 포드를 자동으로 다시 시작하려면 어떻게해야합니까?

구성 맵이 변경 될 때 포드를 자동으로 다시 시작하는 기능에 대해 이야기 한 적이 있지만 내 지식으로는 아직 Kubernetes 1.2에서 사용할 수 없습니다.

그래서 제가하고 싶은 것은 구성 맵을 소비하는 포드와 관련된 배포 리소스 의 "롤링 재시작"입니다 . 실제 템플릿에서 아무것도 변경하지 않고 Kubernetes에서 배포의 롤링 재시작을 강제하는 것이 가능합니까? 그렇다면 어떻게해야합니까? 이것이 현재 가장 좋은 방법입니까, 아니면 더 나은 옵션이 있습니까?

구성 맵 업데이트시 포드에 신호를 보내는 것은 작업중인 기능입니다 ( https://github.com/kubernetes/kubernetes/issues/22368 ).

confimap이 변경되었음을 알리고 앱을 다시 시작하는 사용자 지정 pid1을 언제든지 작성할 수 있습니다.

예를 들어, 2 개의 컨테이너에 동일한 구성 맵을 마운트하고, 구성 맵 콘텐츠의 해시가 변경되면 실패하는 두 번째 컨테이너에 http 상태 확인을 노출하고,이를 첫 번째 컨테이너의 활성 프로브로 밀어 넣을 수 있습니다 (컨테이너가 포드는 동일한 네트워크 네임 스페이스를 공유 함). 프로브가 실패하면 kubelet이 첫 번째 컨테이너를 다시 시작합니다.

물론 포드가 어떤 노드에 있는지 신경 쓰지 않는 경우 간단히 삭제하면 복제 컨트롤러가 노드를 "다시 시작"합니다.

이 문제에 대한 현재 최선의 해결책 ( https://github.com/kubernetes/kubernetes/issues/22368 에서 자세히 참조 됨 )은 배포를 사용하고 ConfigMap을 변경할 수없는 것으로 간주하는 것입니다.

구성을 변경하려면 원하는 변경 사항으로 새 ConfigMap을 만들고 새 ConfigMap에서 배포를 가리 킵니다. 새 구성이 손상되면 배포에서 작동중인 ReplicaSet 축소를 거부합니다. 새 구성이 작동하면 이전 ReplicaSet이 0 개의 복제본으로 확장되고 삭제되고 새 pod가 새 구성으로 시작됩니다.

ConfigMap을 제자리에서 편집하는 것만 큼 빠르지는 않지만 훨씬 안전합니다.

내가 찾은 가장 좋은 방법은 Reloader를 실행하는 것입니다.

이를 통해 configmap 또는 secrets를 정의하여 업데이트 될 때 배포의 롤링 업데이트가 수행되는 것을 볼 수 있습니다. 예를 들면 다음과 같습니다.

foo라는 배포 및 ConfigMap이 foo-configmap있습니다. configmap이 변경 될 때마다 배치의 팟 (Pod)을 롤링하려고합니다. 다음을 사용하여 Reloader를 실행해야합니다.

kubectl apply -f https://raw.githubusercontent.com/stakater/Reloader/master/deployments/kubernetes/reloader.yaml

그런 다음 배포에서이 주석을 지정합니다.

kind: Deployment
metadata:
  annotations:
    configmap.reloader.stakater.com/reload: "foo-configmap"
  name: foo
...

https://github.com/kubernetes/helm/blob/master/docs/charts_tips_and_tricks.md#user-content-automatically-roll-deployments-when-configmaps-or-secrets-change

종종 configmaps 또는 secrets는 컨테이너의 구성 파일로 삽입됩니다. 애플리케이션에 따라 후속 helm upgrade.

이 sha256sum함수를 함수와 함께 사용하여 include다른 사양이 변경되는 경우 배포 템플릿 섹션이 업데이트되도록 할 수 있습니다 .

kind: Deployment
spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ include (print $.Template.BasePath "/secret.yaml") . | sha256sum }}
[...]

제 경우에는 어떤 이유로 $.Template.BasePath작동하지 않았지만 작동합니다 $.Chart.Name.

spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: admin-app
      annotations:
        checksum/config: {{ include (print $.Chart.Name "/templates/" $.Chart.Name "-configmap.yaml") . | sha256sum }}

배포와 관련이없는 메타 데이터 레이블을 업데이트 할 수 있습니다. 롤링 업데이트를 트리거합니다.

예를 들면 :

metadata:
  labels:
    configmap-version: 1

배포가 하위 차트에 있고이를 제어하는 ​​값이 상위 차트의 값 파일에있는이 문제가있었습니다. 다음은 다시 시작을 트리거하는 데 사용한 것입니다.

spec:
  template:
    metadata:
      annotations:
        checksum/config: {{ tpl (toYaml .Values) . | sha256sum }}

분명히 이것은 모든 값 변경 에 대해 재시작을 트리거 하지만 우리 상황에서는 작동합니다. 원래 자식 차트에 있던 것은 자식 차트 자체의 config.yaml이 변경된 경우에만 작동합니다.

    checksum/config: {{ include (print $.Template.BasePath "/config.yaml") . | sha256sum }}

나는 퀀 타의 해법을 수행하고 완벽하게 작동합니다. 그러나 내가 이해하지 못하는 것은 포드가 실제로 다시 시작되지 않는다는 것입니다. 포드는 여전히 동일하지만 변화가 있습니다!

예 : Pod가 50 분 이후 실행 중이고 변경 내용이 온라인 상태입니다. 내 브라우저에서 확인할 수 있으며 Pod가 여전히 +50 분 실행 중입니다 !! Helm3을 사용하고 있습니다 ... configmap 업데이트를 다시 시작하지 않고이를 가능하게하는 이유를 알고 있습니까?

또 다른 방법은 배포의 명령 섹션에 삽입하는 것입니다.

...
command: [ "echo", "
  option = value\n
  other_option = value\n
" ]
...

또는 좀 더 ConfigMap과 비슷하게 만들려면 command섹션 에서 해당 구성을 호스팅 하고 실행 kubectl create하면서 이름에 고유 한 '버전'을 추가하고 (예 : 콘텐츠의 해시 계산) 모든 항목을 수정 하는 추가 배포를 사용 합니다. 해당 구성을 사용하는 배포 :

...
command: [ "/usr/sbin/kubectl-apply-config.sh", "
  option = value\n
  other_option = value\n
" ]
...

kubectl-apply-config.sh작동이 끝나면 게시 할 것입니다 .

(그렇게하지 마십시오. 너무 나빠 보입니다)