kubernetes 의 nginx 를 우아 하 게 닫 습 니 다.

SIGINT SIGTERM SIGKILL 구별
세 가 지 는 모두 프로 세 스 실행 을 종료 / 중지 합 니 다.
1. SIGINT SIGTERM 구별
전 자 는 문자 ctrl + c 와 연결 되 어 있 으 며 후 자 는 제어 문자 와 연결 되 어 있 지 않 습 니 다.전 자 는 프론트 프로 세 스 만 끝 낼 수 있 고 후 자 는 그렇지 않다.
2. SIGTERM SIGKILL 의 차이
전 자 는 막 히 고 처리 되 며 무시 할 수 있 지만 후 자 는 안 된다.KILL 명령 의 기본 매개 변수 없 이 보 내 는 신 호 는 SIGTERM 입 니 다. 프로그램 을 잘 종료 시 키 는 것 입 니 다.막 힐 수 있 기 때문에 어떤 프로 세 스 가 끝나 지 않 을 때 kill 로 후자 신 호 를 보 내 면 됩 니 다.즉, kill - 9 프로 세 스 번호 입 니 다.
docker stop 과 docker kill
docker stop
docker stop 명령 으로 용 기 를 멈 출 때 docker 는 기본적으로 용기 에 있 는 프로그램 이 10 초 동안 실행 을 중지 할 수 있 도록 합 니 다.
docker stop 명령 이 실 행 될 때 용기 에 PID 가 1 인 프로 세 스 main process 에 시스템 신호 SIGTERM 을 보 낸 다음 용기 에 있 는 프로그램 이 실 행 될 때 까지 기 다 립 니 다. 대기 시간 이 설정 한 시간 초과 시간 이나 기본 10 초 에 이 르 면 SIGKILL 의 시스템 신 호 를 계속 보 내 kill 프로 세 스 를 강제로 제거 합 니 다.용기 에 있 는 프로그램 은 SIGTERM 신 호 를 무시 하고 처리 하지 않 는 것 을 선택 할 수 있 습 니 다. 그러나 시간 이 초과 되면 프로그램 은 시스템 에 의 해 강제로 kill 되 어 떨 어 집 니 다. SIGKILL 신 호 는 시스템 커 널 로 직접 전송 되 기 때문에 프로그램 이 처리 할 기회 가 없습니다.
docker kill
기본적으로 docker kill 명령 은 용기 에 있 는 프로그램 에 gracefully shutdown 의 기 회 를 주지 않 습 니 다.용기 에서 프로그램의 운행 을 강제로 중지 하기 위해 SIGKILL 의 시스템 신 호 를 직접 보 냅 니 다.
docker stop 명령 과 다른 점 은 docker kill 은 시간 초과 설정 이 없 으 며 SIGKILL 신 호 를 직접 보 내 고 사용자 가 signal 매개 변 수 를 통 해 지정 한 다른 신 호 를 보 냅 니 다.
docker stop 명령 은 Linux 시스템 의 kill 명령 과 유사 하 며, 둘 다 시스템 신호 SIGTERM 을 보 냅 니 다.docker kill 명령 은 Linux 시스템 의 kill - 9 또는 kill - SIGKILL 명령 처럼 SIGKILL 신 호 를 보 내 고 프로 세 스 를 강제로 종료 합 니 다.
pid 1 프로 세 스
process ID 가 1 인 프로 세 스 는 보통 UNIX init 프로 세 스 로 운영 체제 에서 중요 한 역할 을 합 니 다. 프로 세 스 가 종 료 될 때마다 하위 프로 세 스 가 존재 한다 면 이 프로 세 스 는 고아 프로 세 스 가 되 고 init 프로 세 스 가 인수 합 니 다.유 닉 스 는 이러한 방식 으로 설계 되 었 습 니 다. 부모 프로 세 스 는 종료 상 태 를 수집 하기 위해 하위 프로 세 스 가 종 료 될 때 까지 명확 하 게 기 다 려 야 합 니 다.
하위 프로 세 스 가 끝 난 후에 도 커 널 은 기본 적 인 구 조 를 유지 하고 pid, 종료 원인 과 상태 등 정 보 를 저장 합 니 다. 부모 프로 세 스 는 waitpid 시스템 을 통 해 호출 되 며 이 정 보 를 얻 을 수 있 습 니 다.부모 프로 세 스 가 waitpid 를 호출 하지 않 으 면 이 상태 정 보 는 계속 남아 서 이른바 좀 비 프로 세 스 로 변 합 니 다.자식 프로 세 스 가 부모 프로 세 스 로 끝나 면 일반적으로 init 프로 세 스 는 이 고아 프로 세 스 를 책임 집 니 다.
일반적인 용기 에서 하나의 프로 세 스 만 실행 하 는 원칙 에 따라 하나의 웹 서비스 에 대해 용기 에서 실 행 될 때 pid 는 1 입 니 다. bash 의 cgi 스 크 립 트 를 호출 했다 고 가정 하면 이 스 크 립 트 는 grep 를 호출 했 습 니 다. 한 동안 cgi 스 크 립 트 는 특정한 이유 로 시간 을 초과 하여 웹 서 비 스 를 죽 이려 고 시 도 했 지만 grep 는 영향 을 받 지 않 아 고아 프로 세 스 가 되 었 습 니 다.이때 pid = 1 의 웹 서 비 스 는 인수 할 수 있어 야 하지만 절대 다수의 웹 서 비 스 는 init 와 같은 능력 이 없 기 때문에 grep 는 좀 비 프로 세 스 가 되 었 다.
kubernetes 의 pod 닫 기 메커니즘
pod 는 클 러 스 터 의 노드 에서 실행 되 는 프로 세 스 를 대표 합 니 다. 이 프로 세 스 가 더 이상 필요 하지 않 고 우아 하 게 종료 하 는 것 이 중요 합 니 다.사용 자 는 삭 제 를 요청 할 수 있 을 뿐만 아니 라, 실 프로 세 스 가 종 료 된 상황 에서 도 알 수 있 을 뿐만 아니 라, 삭제 가 최종 적 으로 완 료 될 수도 있다.사용자 가 pod 삭 제 를 요청 하면 시스템 이 원 하 는 우아 한 종료 시간 대 를 기록 합 니 다. 그 전에 pod 는 강제 적 으로 죽 이 는 것 을 허용 하지 않 습 니 다. TERM 신 호 는 용기 의 주요 프로 세 스에 보 냅 니 다.우아 하 게 종료 하 는 기한 이 지나 면 KILL 신 호 는 이 프로 세 스 로 보 내 고 pod 는 API 서버 에서 삭 제 됩 니 다.프로 세 스 가 끝 날 때 까지 기다 리 는 동안 Kubelet 이나 용기 관리자 가 다시 시작 되면 끝 나 는 과정 은 완전한 우아 한 종료 시간 대 를 가지 고 다시 시도 합 니 다.
예제 프로 세 스:

1. 사용자 가 Pod 를 삭제 하 라 는 명령 을 보 냅 니 다. 기본 우아 한 종료 시간 은 30 초

입 니 다.

2. API 서버 의 Pod 업데이트 시간, 이 시간 을 초과 하면 Pod 가 사망 한 것 으로 간주

3. 클 라 이언 트 명령 에서 Pod 는 'Terminating (종료 중)' 상태 로 표 시 됩 니 다

4. (3 과 동시에) Kubelet 이 Pod 가 종료 로 표 시 된 것 을 보 았 을 때 2 단계 에 시간 이 설정 되 어 있 기 때문에 pod 가 닫 히 는 절 차 를 시작 합 니 다.

4.1 이 Pod 가 정지 전의 갈 고 리 를 정의 하면 pod 내부 에서 호출 됩 니 다.만약 갈고리 가 우아 한 탈퇴 시간 대 에 시간 을 초과 하여 여전히 운행 하고 있다 면, 두 번 째 단 계 는 아주 작은 우아 한 시간 이 호출 되 는 것 을 의미 합 니 다

.

4.2 프로 세 스 가 TERM 의 신 호 를 보 냅 니 다

5. (세 번 째 단계 와 동시에 진행) Pod 는 service 목록 에서 삭제 되 고 실행 중인 pod 의 일부분 으로 여 겨 지지 않 습 니 다.천천히 닫 힌 pod 는 부하 이퀄 라이저 가 돌아 가면 서 대외 서 비 스 를 계속 할 수 있 습 니 다.

6. 우아 한 종료 시간 이 초과 되면 모든 pod 에서 실행 중인 프로 세 스 가 SIGKILL 신 호 를 보 내 죽 습 니 다.

7. Kubelet 은 pod 삭 제 를 완료 하고 우아 하 게 종료 하 는 시간 을 0 으로 설정 합 니 다.pod 는 API 에서 삭제 되 며 클 라 이언 트 에 보이 지 않 습 니 다.

기본적으로 모든 삭제 작업 의 우아 한 종료 시간 은 30 초 이내 입 니 다.kubectl delete 명령 지원 -- grace - period = 의 옵션 을 사용 하여 기본 값 을 변경 합 니 다.0. 삭제 즉시 실행 하고 API 에서 pod 를 즉시 삭제 하 는 새로운 pod 가 동시에 생 성 됩 니 다.노드 에 즉시 끝 나 는 pod 가 설정 되 어 있 고 아주 짧 은 우아 한 탈퇴 시간 대 를 주어 야 강제 적 으로 죽 기 시작 합 니 다.
nginx 와 SIGTERM
실행 중인 Nginx 프로 세 스에 신 호 를 보 내 서 작업 을 완전히 관리 할 수 있 는 두 가지 방법 이 있 습 니 다. Nginx 프로 세 스 의 - s 옵션 을 사용 하거나 시스템 명령 kill 을 직접 사용 하여 master 프로 세 스에 신 호 를 보 낼 수 있 습 니 다.- s 옵션 을 사용 할 때 nginx 는 실행 중인 master 프로 세 스 ID 를 자동 으로 찾 습 니 다 (master 프로 세 스 는 신 호 를 받 고 처리 하 는 동시에 서로 다른 신호 에 따라 모든 작업 프로 세 스 에 대해 서로 다른 관리 작업 을 수행 합 니 다).
SIGINT 는 SIGTERM 과 마찬가지 로 Nginx 프로 세 스 를 강제로 종료 하 는 데 사 용 됩 니 다.master 프로 세 스 가 강제 종료 신 호 를 받 았 을 때 모든 작업 프로 세 스에 강제 종료 신 호 를 보 냅 니 다. 작업 프로 세 스 가 제때에 종료 되 지 않 으 면 master 는 타이머 로 강제 신 호 를 반복 해서 보 냅 니 다. 타이머 가 실 행 될 때 SIGALRM 신 호 를 보 냅 니 다.SIGIO 신 호 는 Nginx 명시 적 으로 무시 되 었 습 니 다.SIGCHLD 신 호 는 master 프로 세 스 가 작업 프로 세 스 를 종료 하고 자원 회수 나 작업 프로 세 스 를 다시 시작 해 야 한 다 는 것 을 알려 줍 니 다.
Nginx 프로 세 스 종료

master 프로 세 스 가 SIGQUIT 신 호 를 받 았 을 때 이 신 호 를 작업 프로 세 스에 전달 합 니 다.작업 프로 세 스 는 새로운 연결 요청 을 받 지 않 기 위해 감청 포트 를 닫 고 남 은 연결 을 닫 습 니 다. 활성 연결 이 모두 정상 적 인 결 속 될 때 까지 기다 린 후 ngx 를 호출 합 니 다.worker_process_exit 종료.마스터 프로 세 스 는 모든 작업 프로 세 스 가 종료 되면 ngx 를 호출 합 니 다.master_process_exit 함수 종료;

master 프로 세 스 가 SIGTERM 이나 SIGINT 신 호 를 받 았 을 때 작업 프로 세 스에 신 호 를 전달 합 니 다.작업 프로 세 스 직접 호출 ngxworker_process_exit 함수 종료.master 프로 세 스 는 모든 작업 프로 세 스 가 종료 되면 ngx 를 호출 합 니 다.master_process_exit 함수 종료.또한 작업 프로 세 스 가 정상적으로 종료 되 지 않 으 면 master 프로 세 스 는 1 초 를 기다 린 후 SIGKILL 신 호 를 보 내 작업 프로 세 스 를 강제로 종료 합 니 다.

nginx 의 우아 한 탈퇴

 -s signal      Send signal to the master process. The argument signal can be
                one of: stop, quit, reopen, reload.

                The following table shows the corresponding system signals.

                stop    SIGTERM
                quit    SIGQUIT
                reopen  SIGUSR1
                reload  SIGHUP

그 중에서 stop - quit - 우아 하 게 종료 합 니 다. 현재 요청 을 실행 한 후 reload 를 종료 합 니 다. 프로필 reopen 을 다시 불 러 옵 니 다. 로그 파일 을 다시 엽 니 다.
kubernetes Lifecycle Hooks 를 사용 하여 nginx 를 우아 하 게 종료 합 니 다.

kind: Deployment
metadata:
  name: nginx-demo
  namespace: scm
  labels:
    app: nginx-demo
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - name: nginx-demo
        image: library/nginx-demo
        imagePullPolicy: IfNotPresent
        lifecycle:
          preStop:
            exec:
              # nginx -s quit gracefully terminate while SIGTERM triggers a quick exit
              command: ["/usr/local/openresty/nginx/sbin/nginx","-s","quit"]
        env:
          - name: PROFILE
            value: "test"
        ports:
          - name: http
            containerPort: 8080

주제 밖
자바 응용 프로그램 을 우아 하 게 닫 는 방법

command: ["/bin/bash", "-c", "PID=`pidof java` && kill -SIGTERM $PID && while ps -p $PID > /dev/null; do sleep 1; done;"]

doc

uinx 신호 SIGINT SIGTERM SIGKILL 구별

우아 한 종료 docker 용기

Termination of Pods

Issues with running as PID 1 in a Docker container.

Docker and the PID 1 zombie reaping problem

Docker 와 PID 1 좀 비 프로 세 스 문제

Docker 시스템 에서 좀 비 프로 세 스 문제

kubernetes-chinese-docs-pods

Nginx 소스 코드 노트 - 운영 명령

Does nginx have a soft quit?

Container Lifecycle Hooks

Graceful shutdown of pods with Kubernetes

Gracefully stopping a Java process in a pod in Kubernetes?

How can I ensure graceful scaling in kubernetes?

Do Kubernetes pods still receive requests after receiving SIGTERM?

Deleting pods and other resources with graceful shutdown