아 리 클 라 우 드 K8S Ingress Controller 를 통 해 경로 설정 의 동적 업 데 이 트 를 실현 합 니 다.

요약: 본 고 는 주로 아 리 운 Kubernetes 클 러 스 터 Ingress Controller 가 어떻게 동적 업데이트 방식 으로 퍼 가기 평면 Nginx 의 빈번 한 Reload 가 가 져 온 영향 을 크게 완화 하 는 지 묘사 했다.
간단 한 소개
Kubernetes 클 러 스 터 에서 Ingress 는 클 러 스 터 내 서비스 가 대외 적 으로 노출 된 방문 접속 점 으로서 클 러 스 터 내 서비스 방문 의 모든 데 이 터 를 담 고 있다.우 리 는 Nginx Ingress Controller 가 Kubernetes 지역사회 에서 매우 중요 한 서브 프로젝트 라 는 것 을 알 고 있다. 그 내 부 는 주로 고성능 의 부하 균형 소프트웨어 Nginx 를 바탕 으로 Kubernetes Ingress 자원 대상 을 실시 간 으로 자동화 하여 Nginx 배치 규칙 으로 전환 시 켜 대외 적 으로 기대 하 는 권한 방문 입 구 를 제공한다.
현실 문제
Kubernetes 클 러 스 터 에 배 치 된 마이크로 서비스 가 점점 많아 지면 서 대외 적 으로 노출 된 경로 규칙 이 점점 복잡 해 지고 서비스 백 엔 드 포인트 의 변화 가 빈번 해 지면 서 대응 하 는 것 은 Nginx Ingress Controller 구성 요소 내 Nginx 설정 파일 의 변화 가 점점 빈번 해 질 것 이다.한편, 우 리 는 모든 줄 의 Nginx 설정 의 변 화 는 Reload Nginx 가 있어 야 효력 이 발생 한 다 는 것 을 알 고 있다. 이것 은 변화 빈도 가 비교적 낮은 장면 에서 아예 받 아들 일 수 있 지만 고주파 변화 장면 에서 Nginx 의 빈번 한 Reload 를 일 으 킬 수 있다.
한편, Nginx 의 빈번 한 Reload 가 가 져 온 문 제 는 흔히 말 하 는 화제 이다. 그 문제 의 본질은 주로 Nginx 자체 의 최초의 구조 디자인 모델 에서 비롯 된 것 이다.
일반적으로 Linux 서버 에 서 는 Nginx 를 사용 하 는 EPOLL 다 중 프로 세 스 모드 를 설정 합 니 다.우리 가 Nginx 프로필 을 수정 한 후에 통과 해 야 합 니 다.

nginx -s reload

새로운 Nginx 설정 규칙 을 다시 불 러 오 는 명령;
Nginx Master 프로 세 스 가 reload signal 을 받 으 면 지정 한 경로 에서 새로운 Nginx 프로필 내용 을 다시 불 러 오고 설정 규칙 의 유효성 을 검증 합 니 다. 유효한 프로필 로 검사 되면 새로운 프로필 의 worker 에 따라processes 값 fork 에서 지정 한 수량의 새로운 Nginx Worker 프로 세 스 를 내 보 냅 니 다. 이 때 새 fork 에서 나 온 하위 프로 세 스 는 부모 프로 세 스 의 메모리 데이터 ngx 를 완전히 계승 합 니 다.cycle (새로운 분석 후의 Nginx 설정 규칙 을 포함 합 니 다) 설정 에 있 는 모든 Listen Socket FD 를 커 널 의 EPOLL 이벤트 감청 에 등록 합 니 다. 이 때 이 새로운 Nginx Worker 프로 세 스 는 클 라 이언 트 로부터 요청 을 받 을 수 있 습 니 다.
또한 Nginx Master 프로 세 스 는 QUIT signal 을 보 내 오래된 Nginx Worker 프로 세 스 가 부 드 럽 게 종료 되 었 음 을 알 립 니 다. 오래된 Nginx Worker 프로 세 스 가 QTUI 신 호 를 받 은 후에 EPOLL 에 등 록 된 감청 이 벤트 를 제거 합 니 다. 이로써 새로운 클 라 이언 트 요청 을 받 지 않 고 오래된 프로필 에 설 치 된 Workershutdown_timeout 값 으로 타 이 머 를 설정 한 다음 에 받 은 클 라 이언 트 요청 을 계속 처리 합 니 다.workershutdown_timeout 전에 기 존 클 라 이언 트 요청 을 처리 하면 자동 으로 종 료 됩 니 다. 처리 되 지 않 으 면 Kill 에서 강제로 종 료 됩 니 다. 이 경우 클 라 이언 트 요청 응답 이 이상 합 니 다.
따라서 고주파 변화 장면 에서 Nginx 의 잦 은 Reload 는 비교적 뚜렷 한 요청 방문 문 제 를 가 져 올 수 있 습 니 다.

일정한 QPS 떨 림 과 접근 실패 상황 발생

긴 연결 서비스 가 자주 끊 긴 다

shutting down 에 있 는 Nginx Worker 프로 세 스 를 대량으로 만들어 메모리 팽창

동적 업데이트
Nginx 의 잦 은 Reload 의 영향 을 완화 하기 위해 서 는 동적 업데이트 방식 으로 Nginx 설정 규칙 을 불 러 와 야 합 니 다. 즉, Fork 새 Nginx Worker 프로 세 스 가 아 닌 상태 에서 메모리 에 불 러 온 Nginx 설정 규칙 을 실시 간 으로 업데이트 해 야 합 니 다.
우선 Nginx 의 프로필 스타일 을 살 펴 보 겠 습 니 다. 주로 아래 의 몇 가지 설정 장 을 포함 합 니 다.

# 1\. main configuration
daemon off;
worker_processes 4;

events {
  # 2\. event configuration
  multi_accept        on;
  worker_connections  1024;
  use                 epoll;
}

http {
  # 3\. http main configuration
  access_log /var/log/nginx/access.log;
  error_log  /var/log/nginx/error.log;

  upstream {
    # 4\. upstream configuration
    server 0.0.0.1;
  }

  server {
    # 5\. server configuration
    server_name _ ;
    listen 80 default_server;

    location / {
      # 6\. location configuration
      proxy_pass http://upstream_balancer;
    }
}

한편, Kubernetes 클 러 스 터 에서 한 Ingress 자원 대상 은 주로 Nginx 에 비 친 HTTP Main Block, Server Block, Upstream Block 과 Location Block 등 장절 의 설정 규칙 에 해석 되 기 때문에 우 리 는 이 몇 가지 자주 변화 하 는 설정 내용 을 Shared Memory 방식 으로 메모리 에 통일 적 으로 유지 하 는 동시에 Ingress Controller 내부 에 관리 포트 를 노출 시 킬 수 있다.API 를 통 해 Nginx 경로 규칙 설정 을 실시 간 으로 관리 합 니 다.
K8S Ingress Controller 가 클 러 스 터 내 Ingress 및 연 결 된 자원 의 변 화 를 감시 할 때 Internal API 를 통 해 최신 Nginx 설정 규칙 을 통 일 된 공유 메모리 설정 으로 보 낼 수 있 습 니 다. Reload Nginx 방식 으로 새 설정 을 적용 하지 않 아 도 됩 니 다. 이로써 Nginx 가 새로 받 은 클 라 이언 트 요청 을 처리 할 때,최신 공유 메모리 의 설정 을 기반 으로 규칙 적 인 일치 와 경로 전송 을 할 수 있 습 니 다.
설정 설명
1. 현재 아 리 클 라 우 드 용기 서비스 Kubernetes 클 러 스 터 의 최신 버 전의 Nginx Ingress Controller 구성 요 소 는 기본적으로 Upstream 의 동적 업 데 이 트 를 시 작 했 습 니 다. 또한 응용 서비스의 그 레이스 케 일 발표 와 파란색 발표 기능 을 지원 합 니 다. 구체 적 인 설정 설명 은 여 기 를 참고 할 수 있 습 니 다.
현재 공유 메모리 에 있 는 Nginx Upstream 의 설정 목록 을 다음 명령 으로 볼 수 있 습 니 다.

kubectl -n kube-system exec -it  -- curl http://127.0.0.1:18080/configuration/backends

2. HTTPS 인증서 의 동적 업데이트 도 지원 합 니 다. nginx - ingress - controller deployment 의 다음 매개 변수 설정 을 수정 하여 Nginx Ingress Controller 의 인증서 동적 업 데 이 트 를 시작 할 수 있 습 니 다.

- args:
  - /nginx-ingress-controller
  - --configmap=$(POD_NAMESPACE)/nginx-configuration
  - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
  - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
  - --annotations-prefix=nginx.ingress.kubernetes.io
  - --publish-service=$(POD_NAMESPACE)/nginx-ingress-lb
  - --enable-dynamic-certificates=true  ###      
  - --v=2

HTTPS 인증서 의 동적 업 데 이 트 를 시작 하면 Ingress 의 TLS 인증 서 는 Nginx 의 공유 메모리 에 통일 적 으로 유 지 됩 니 다. 현재 공유 메모리 에 설 정 된 인증서 목록 을 다음 명령 으로 볼 수 있 습 니 다.

kubectl -n kube-system exec -it  -- curl http://127.0.0.1:18080/configuration/certs

3. 저 희 는 Nginx Server 와 Location 설정 의 동적 업 데 이 트 를 지원 합 니 다. nginx - ingress - controller deployment 의 다음 매개 변수 설정 을 수정 하여 Nginx Ingress Controller 의 Server 와 Location 의 동적 업 데 이 트 를 시작 할 수 있 습 니 다.

- args:
  - /nginx-ingress-controller
  - --configmap=$(POD_NAMESPACE)/nginx-configuration
  - --tcp-services-configmap=$(POD_NAMESPACE)/tcp-services
  - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
  - --annotations-prefix=nginx.ingress.kubernetes.io
  - --publish-service=$(POD_NAMESPACE)/nginx-ingress-lb
  - --enable-dynamic-certificates=true  ###      
  - --enable-dynamic-servers=true ###      ，    enable-dynamic-certificates
  - --v=2

마찬가지 로 Nginx Ingress Controller 의 서버 동적 업 데 이 트 를 열 었 을 때 모든 Nginx Server 와 Location 설정 은 공유 메모리 에 통일 적 으로 유 지 됩 니 다. 현재 공유 메모리 의 Server 설정 목록 을 다음 명령 을 통 해 볼 수 있 습 니 다.

kubectl -n kube-system exec -it  -- curl http://127.0.0.1:18080/configuration/servers

주의 설명: 서버 의 동적 업데이트 기능 을 켜 면 일부 Ingress Annotation 설정 은 지원 되 지 않 습 니 다. 지원 을 점차적으로 최적화 하고 있 습 니 다. 이에 따라 ConfigMap 방식 으로 직접 설정 할 수 있 습 니 다.
본문 저자: chenqz
원문 을 읽다
본 고 는 운 서 지역사회 의 오리지널 내용 으로 허락 없 이 전재 할 수 없다.