NGINX 튜토리얼: 자동 확장으로 Kubernetes 대기 시간 단축
이 튜토리얼은 Microservices March 2022의 개념을 실제로 적용한 4가지 튜토리얼 중 하나입니다. 쿠버네티스 네트워킹 :
- 자동 확장으로 Kubernetes 대기 시간 단축(이 게시물)
- 속도 제한으로 Kubernetes API 보호
- Kubernetes 앱을 SQL 주입으로부터 보호
- Canary 배포로 가동 시간과 회복성 향상
더욱 다양한 Kubernetes 네트워킹 사용 사례에 NGINX를 사용하는 방법에 대한 자세한 지침을 원하시나요? 무료 전자책, NGINX로 Kubernetes 트래픽 관리 다운로드: 실용 가이드
귀하의 조직에서 Kubernetes로 앱을 빌드했는데 이제 인기가 높아지고 있습니다! 하루에 방문자가 몇 명에서 수백 명(가끔은 수천 명)으로 늘어났습니다. 하지만 문제가 하나 있습니다. 트래픽이 증가하면서 병목 현상이 발생하여 고객에게 지연 및 시간 초과가 발생하고 있습니다. 사용자 경험을 개선하지 못하면 사람들은 앱 사용을 중단할 것입니다.
당신, 즉 용감한 Kubernetes 엔지니어 에게는 해결책이 있습니다. Ingress 컨트롤러를 배포하여 트래픽을 라우팅하고 자동 확장 정책을 설정하면 Ingress 컨트롤러 포드의 수가 트래픽 변동에 맞춰 즉시 확장되거나 축소됩니다. 이제 Ingress 컨트롤러 포드가 트래픽 급증을 원활하게 처리합니다. "안녕, 지연 시간!" - 그리고 트래픽이 감소하면 리소스를 보존하기 위해 축소합니다. "안녕, 비용 절감!" 잘했어요.
랩 및 튜토리얼 개요
이 블로그는 2022년 3월 마이크로서비스 단원 1 랩에 대한 내용으로, 트래픽이 많은 웹사이트를 위한 Kubernetes 클러스터 아키텍처를 설명합니다. 이 랩에서는 NGINX Ingress Controller를 사용하여 앱을 노출한 다음 트래픽이 많은 상황에 따라 Ingress 컨트롤러 포드를 자동으로 확장하는 방법을 보여줍니다.
튜토리얼을 실행하려면 다음 사양을 갖춘 장비가 필요합니다.
- 2개 이상의 CPU
- 2GB의 여유 메모리
- 20GB의 여유 디스크 공간
- 인터넷 연결
- Docker, Hyperkit, Hyper‑V, KVM, Parallels, Podman, VirtualBox 또는 VMware Fusion/Workstation과 같은 컨테이너 또는 가상 머신 관리자
- minikube 설치됨
- 헬름 설치됨
- 브라우저 창을 시작할 수 있는 구성입니다. 이것이 가능하지 않다면 브라우저를 통해 관련 서비스에 접속하는 방법을 알아내야 합니다.
랩과 튜토리얼을 최대한 활용하려면 시작하기 전에 다음을 권장합니다.
라이브 스트리밍된 개념적 개요의 녹화를 시청하세요
배경 블로그를 검토하세요
랩의 20분 분량의 비디오 요약을 시청하세요.
이 튜토리얼에서는 다음 기술을 사용합니다.
각 과제에 대한 지침에는 앱을 구성하는 데 사용되는 YAML 파일의 전체 텍스트가 포함되어 있습니다. GitHub 저장소 에서 텍스트를 복사할 수도 있습니다. 각 YAML 파일의 텍스트와 함께 GitHub에 대한 링크가 제공됩니다.
이 튜토리얼에는 4가지 과제가 포함되어 있습니다.
- Kubernetes 클러스터에서 간단한 앱 구성
- NGINX Ingress Controller를 사용하여 앱으로 트래픽 라우팅
- 트래픽 생성 및 모니터링
- 자동 확장 NGINX Ingress 컨트롤러
도전 1: Kubernetes 클러스터에서 간단한 앱 구성
이 챌린지에서는 Minikube 클러스터를 생성 하고 Podinfo를 샘플 앱으로 설치합니다 .
Minikube 클러스터 생성
Minikube 클러스터를 생성합니다. 몇 초 후에 배포가 성공적이었음을 확인하는 메시지가 나타납니다.
$ minikube start 🏄 완료! kubectl은 이제 기본적으로 "minikube" 클러스터와 "기본" 네임스페이스를 사용하도록 구성되었습니다.
Podinfo 앱 설치
Podinfo 는 "Kubernetes에서 마이크로서비스를 실행하는 모범 사례를 보여주는 Go로 만든 웹 애플리케이션"입니다. 크기가 작기 때문에 샘플 앱으로 사용하고 있습니다.
원하는 텍스트 편집기를 사용하여 다음 내용으로 1-deployment.yaml 이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사합니다 ). 이는 단일 복제본과 서비스를 포함하는 배포를 정의합니다.
apiVersion: 앱/v1 종류: 배포 메타데이터: 이름: podinfo 스펙: 선택자: matchLabels: 앱: podinfo 템플릿: 메타데이터: 레이블: 앱: podinfo 스펙: 컨테이너: - 이름: podinfo 이미지: stefanprodan/podinfo 포트: - 컨테이너 포트: 9898 --- apiVersion: v1 종류: 서비스 메타데이터: 이름: podinfo 스펙: 포트: - 포트: 80 대상 포트: 9898 노드포트: 30001 선택자: 앱: podinfo 유형: 로드 밸런서앱 배포:
$ kubectl apply -f 1-deployment.yaml deployment.apps/podinfo가 생성됨 서비스/podinfo가 생성됨STATUS열에Running값이 표시된 대로 Podinfo Pod가 배포되었는지 확인합니다.$ kubectl get pods 이름 준비 상태 재시작 나이 podinfo-5d76864686-rd2s5 1/1 실행 중 0 3m38s브라우저에서 Podinfo를 엽니다. podinfo 페이지의 인사말은 Podinfo가 실행 중임을 나타냅니다.
$ minikube 서비스 podinfo
도전 2: NGINX Ingress Controller를 사용하여 앱으로 트래픽 라우팅
이 챌린지에서는 NGINX Ingress Controller를 배포 하고 트래픽을 Podinfo 앱으로 라우팅 하도록 구성합니다.
NGINX Ingress Controller 배포
NGINX Ingress Controller를 설치하는 가장 빠른 방법은 Helm을 사용하는 것입니다.
Helm에 NGINX 저장소를 추가합니다.
$ helm repo nginx-stable 추가 https://helm.nginx.com/stableF5 NGINX에서 유지 관리하는 NGINX 오픈 소스 기반 NGINX Ingress Controller를 다운로드하여 설치합니다. 출력의 마지막 줄은 설치가 성공했음을 확인합니다.
$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30005 이름: main 마지막 배포: 화 3월 15일 09:49:17 2022 네임스페이스: 기본 상태: 배포됨 개정: 1 테스트 모음: 없음 참고사항: NGINX Ingress Controller가 설치되었습니다.STATUS열에'Running'이라는 값이 표시되어 NGINX Ingress Controller 포드가 배포되었는지 확인합니다(읽기 쉽도록 출력이 두 줄로 나뉘어져 있습니다).$ kubectl get pods 이름 준비 상태 ... main-nginx-ingress-779b74bb8b-mtdkr 1/1 실행 중 ... podinfo-5d76864686-fjncl 1/1 실행 중 ... ... RESTARTS AGE ... 0 18초 ... 0 2분 36초
앱으로 트래픽 라우팅
원하는 텍스트 편집기를 사용하여 다음 내용으로 2-ingress.yaml 이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사합니다 ). Podinfo로 트래픽을 라우팅하는 데 필요한 Ingress 매니페스트를 정의합니다.
apiVersion: networking.k8s.io/v1 종류: Ingress 메타데이터: 이름: podinfo 스펙: ingressClassName: nginx 규칙: - 호스트: "example.com" http: 경로: - 백엔드: 서비스: 이름: podinfo 포트: 번호: 80 경로: / 경로 유형: 접두사Ingress 리소스 배포:
$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/podinfo가 생성되었습니다.
도전 3: 트래픽 생성 및 모니터링
이번 챌린지에서는 다양한 트래픽 부하에서 NGINX Ingress Controller의 성능을 관찰합니다. 준비 단계로, NGINX Ingress Controller에서 사용 가능한 메트릭을 나열하고 , Prometheus를 배포하고 , Locust를 설치합니다 . 그런 다음 Locust를 사용하여 트래픽 급증을 시뮬레이션하고 Prometheus에서 성능에 미치는 영향을 추적합니다 .
이미 알고 계시겠지만 Ingress 컨트롤러는 Kubernetes와 통합하기 위한 일부 코드와 함께 역방향 프록시(이 경우 NGINX)를 묶은 일반적인 Kubernetes Pod입니다. 앱이 많은 트래픽을 수신하는 경우 NGINX Ingress Controller가 과부하로 인해 발생하는 지연을 피하기 위해 NGINX Ingress Controller Pod 복제본의 수를 늘려야 할 수 있습니다.
사용 가능한 메트릭 나열
언제, 어느 정도로 확장할지 알려면 NGINX Ingress Controller 성능에 대한 정확한 정보가 필요합니다. 이 튜토리얼에서는 확장 시기를 결정하는 데 사용되는 NGINX 메트릭은 활성 연결 수( nginx_connections_active )입니다. 여기서 NGINX Ingress Controller가 해당 메트릭을 추적하는지 확인합니다.
NGINX Ingress Controller는 여러 가지 메트릭을 노출합니다 . 이 튜토리얼에서는 NGINX 오픈 소스 기반 모델을 사용하여 8개의 메트릭을 사용하고, NGINX Plus 기반 모델을 사용하여 80개 이상의 메트릭을 사용합니다.
NGINX Ingress Controller Pod의 IP 주소를 얻어서 메트릭 목록을 쿼리할 수 있습니다. 주소는
IP필드에 나타나며 여기에 있습니다.172.17.0.4. (가독성을 위해RESTARTS및AGE열은 생략되었으며 출력은 두 줄에 걸쳐 표시됩니다.)$ kubectl get pods -o wide 이름 준비 상태 ... main-nginx-ingress-779b74bb8b-6hdwx 1/1 실행 중 ... podinfo-5d76864686-nl8ws 1/1 실행 중 ... ... IP 노드 지정 노드 준비 게이트 ...172.17.0.4 minikube <없음> <없음> ... 172.17.0.3 minikube <없음> <없음>Kubernetes 클러스터 내부의 호스트에 셸이 있는 임시 BusyBox 포드를 만듭니다.
$ kubectl run -ti --rm=true busybox --image=busybox 명령 프롬프트가 보이지 않으면 enter 키를 눌러보세요. / #NGINX Ingress Controller에서 생성된 메트릭을 나열하고
nginx_connections_active가포함되어 있는지 확인하세요. 을 위한<IP 주소>1단계의 값을 대체합니다./# wget -qO- <IP 주소>:9113/메트릭스셸을 종료하고 Kubernetes 서버로 돌아갑니다.
/# 출구
프로메테우스 배포
이제 NGINX Ingress Controller가 nginx_connections_active 메트릭을 추적한다는 것을 알았으므로 메트릭을 수집("스크랩")하는 도구가 필요합니다. 이 튜토리얼에서는 Prometheus를 사용합니다.
NGINX Ingress Controller의 경우 Helm은 Prometheus를 설치하는 가장 빠른 방법입니다.
Helm에 Prometheus 저장소를 추가합니다.
$ helm repo prometheus-community 추가 https://prometheus-community.github.io/helm-chartsPrometheus를 다운로드하고 설치하세요:
$ helm install prometheus prometheus-community/prometheus \ --set 서버.서비스.유형=노드포트 --set 서버.서비스.노드포트=30010설치를 확인하세요. 완료하는 데 보통 최대 60초가 걸립니다. 다음 샘플 출력에서는
helminstall명령 후 몇 초 뒤에 검증 명령이 실행되었으므로 설치가 진행 중이고 일부 Prometheus Pod의 경우STATUS필드에ContainerCreating이보고된 것을 확인할 수 있습니다. 모든 포드가Running상태가 되면 설치가 완료됩니다. (출력 내용은 가독성을 위해 두 줄로 나누어져 있습니다.)$ kubectl get pods NAME READY ... main-nginx-ingress-779b74bb8b-mtdkr 1/1 ... podinfo-5d76864686-fjncl 1/1 ... prometheus-alertmanager-d6d94cf4b-85ww5 0/2 ... prometheus-kube-state-metrics-7cd8f95cb-86hhs 0/1 ... prometheus-node-exporter-gqxfz 1/1 ... prometheus-pushgateway-56745d8d8b-qnwcb 0/1 ... prometheus-server-b78c9449f-kwhzp 0/2 ... ... 상태가 다시 시작됩니다. 실행 중 0 3m23s ... 0 5m41s 실행 중 ... 컨테이너 생성 0 7초 ... 0.7초 달리고 ... 0.7초 달리고 ... 컨테이너 생성 0 7초 ... 컨테이너 생성 0 7s프로메테우스를 엽니다. Minikube 환경에서 다음 명령을 실행하면 기본 브라우저에서 Prometheus 대시보드가 열립니다.
$ minikube 서비스 prometheus-server다음과 같은 페이지는 서버가 작동하고 있음을 확인합니다.
검색 창에
nginx_ingress_nginx_connections_active를입력하면 활성 연결 메트릭의 현재 값을 확인할 수 있습니다. NGINX Ingress Controller Pod 하나를 배포했기 때문에 활성 연결이 하나 표시됩니다.
로커스트 설치
다음 섹션에서는 오픈소스 부하 테스트 도구인 Locust를 사용하여 트래픽 급증을 시뮬레이션하고 Prometheus에서 NGINX Ingress Controller의 성능을 확인해 보겠습니다. 여기서는 Locust를 배치합니다.
원하는 텍스트 편집기를 사용하여 다음 내용으로 3-locust.yaml 이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사합니다 ). 배포 및 서비스 객체는 Locust Pod를 정의합니다. ConfigMap 객체는 올바른 헤더를 포함하여 Pod에 전송할 요청을 생성하는 locustfile.py 라는 스크립트를 정의합니다.
apiVersion: v1 종류: ConfigMap 메타데이터: 이름: locust-script 데이터: locustfile.py: |- from locust import HttpUser, task, between class QuickstartUser(HttpUser): wait_time = between(0.7, 1.3) @task def hello_world(self): self.client.get("/", headers={"Host": "example.com"}) --- apiVersion: apps/v1 종류: 배포 메타데이터: 이름: 로커스트 스펙: 선택자: matchLabels: 앱: 로커스트 템플릿: 메타데이터: 레이블: 앱: 로커스트 스펙: 컨테이너: - 이름: 로커스트 이미지: locustio/locust 포트: - 컨테이너 포트: 8089 볼륨 마운트: - 마운트 경로: /home/locust 이름: locust-script 볼륨: - 이름: locust-script configMap: 이름: locust-script --- apiVersion: v1 종류: 서비스 메타데이터: 이름: 로커스트 스펙: 포트: - 포트: 8089 대상 포트: 8089 노드포트: 30015 선택자: 앱: 메뚜기 유형: 로드 밸런서메뚜기 배치:
$ kubectl apply -f 3-locust.yaml configmap/locust-script가 생성되었습니다. deployment.apps/locust가 생성되었습니다. service/locust가 생성되었습니다.
교통량 급증을 시뮬레이션하고 성능에 미치는 영향 관찰
브라우저에서 Locust를 엽니다.
$ minikube 서비스 메뚜기
다음 값을 필드에 입력하세요.
- 사용자 수 – 1000
- 스폰율 – 10
- 호스트 – http://main-nginx-ingress
'Swarming 시작 ' 버튼을 클릭하여 Podinfo 앱으로 트래픽을 보내세요.
Prometheus 대시보드로 돌아가서 NGINX Ingress Controller가 어떻게 응답하는지 확인하세요. 변경 사항을 보려면
nginx_ingress_nginx_connections_active에 대한 새 쿼리를 수행해야 할 수도 있습니다.다음 화면 출력에서 보인 것처럼, 단일 NGINX Ingress Controller Pod는 많은 수의 연결이 설정되면서 지연 없이 증가한 트래픽을 처리하는 데 어려움을 겪습니다. Prometheus 그래프는 NGINX Ingress Controller Pod당 약 100개의 활성 연결이 지연 시간 급증의 시작점임을 보여줍니다. 이 정보를 사용하면 지연 시간 증가를 방지하기 위해 NGINX Ingress Controller Pod의 수를 늘려야 하는 시점을 판단할 수 있습니다.
도전 4: 자동 확장 NGINX Ingress 컨트롤러
마지막 과제에서는 트래픽 볼륨이 증가함에 따라 리소스를 자동으로 확장하는 구성을 구축합니다. 이 튜토리얼에서는 자동 확장을 위해 KEDA를 사용하므로, 먼저 KEDA를 설치 하고 확장이 발생하는 시기와 방법을 정의하는 정책을 만듭니다 . 챌린지 3에서와 마찬가지로 Locust를 사용하여 트래픽 급증을 시뮬레이션 하고 Prometheus를 사용하여 자동 크기 조정이 활성화되었을 때 NGINX Ingress Controller의 성능을 관찰합니다.
KEDA 설치
Kubernetes 이벤트 기반 자동 확장기인 KEDA 는 메트릭 서버(Kubernetes용 메트릭을 저장하고 변환하는 구성 요소)를 통합하고 Prometheus(및 다른 도구)에서 직접 메트릭을 사용할 수 있습니다. Prometheus가 수집한 메트릭을 사용하여 수평적 Pod 자동 확장기 (HPA)를 생성하고, 이를 Kubernetes에 제공합니다.
NGINX Ingress Controller와 Prometheus의 경우와 마찬가지로 이 튜토리얼에서는 Helm을 사용하여 KEDA를 설치합니다.
Helm 저장소에 KEDA 추가:
$ helm repo add kedacore https://kedacore.github.io/charts "kedacore"가 귀하의 저장소에 추가되었습니다.KEDA 설치:
$ helm install keda kedacore/keda 이름: keda 네임스페이스: 기본 상태: 배포됨 개정: 1 테스트 모음: 없음KEDA가 두 개의 포드로 실행되는지 확인하세요. (가독성을 위해
NAME열의 일부 값이 줄었습니다. 또한RESTARTS열은 생략되며 값은 다음과 같습니다.0모든 포드에 해당)$ kubectl get pods 이름 준비 상태 나이 keda-operator-8644dcdb79-492x5 1/1 실행 중 59초 keda-operator-metrics-apiserver-66d... 1/1 실행 중 59초 locust-77c699c94d-dvb5n 1/1 실행 중 8분 59초 main-nginx-ingress-779b74bb8b-v7ggw 1/1 실행 중 48분 podinfo-5d76864686-c98rb 1/1 실행 중 50분 prometheus-alertmanager-d6d94cf4b-8... 2/2 37m prometheus-kube-state-metrics-7cd8f... 실행 중 1/1 실행 중 37m prometheus-node-exporter-j4qf4 1/1 실행 중 37m prometheus-pushgateway-56745d8d8b-9n4nl 1/1 실행 중 37m prometheus-server-b78c9449f-6ktn9 2/2 실행 중 37m
자동 확장 정책 생성
이제 KEDA ScaledObject 사용자 정의 리소스 정의(CRD)를 사용하여 NGINX Ingress Controller의 확장 방식을 결정하는 매개변수를 정의합니다. 구성은 다음과 같습니다.
- Prometheus가 수집한
nginx_connections_active메트릭 값을 기반으로 자동 크기 조정을 트리거합니다. - 기존 Pod가 각각 100개의 활성 연결에 도달하면 새 Pod를 배포합니다.
- 단일 포드에서 최대 20개 포드까지 NGINX Ingress Controller 포드를 자동 확장합니다.
다음 단계를 수행하세요.
원하는 텍스트 편집기를 사용하여 다음 내용으로 4-scaled-object.yaml 이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사합니다 ). KEDA
ScaledObject 를정의합니다.apiVersion: keda.sh/v1alpha1 종류: ScaledObject 메타데이터: 이름: nginx-scale 스펙: scaleTargetRef: 종류: 배포 이름: main-nginx-ingress minReplicaCount: 1 최대 복제본 수: 20 쿨다운기간: 30 폴링 간격: 1 트리거: - 유형: 프로메테우스 메타데이터: 서버 주소: http://프로메테우스-서버 메트릭 이름: nginx_connections_active_keda 쿼리: | sum(avg_over_time(nginx_ingress_nginx_connections_active{app="main-nginx-ingress"}[1m])) 임계값: "100"ScaledObject배포:$ kubectl apply -f 4-scaled-object.yaml scaledobject.keda.sh/nginx-scale 생성됨
트래픽 급증을 시뮬레이션하고 자동 확장이 성능에 미치는 영향을 관찰합니다.
자동 확장의 효과를 실제로 테스트하려면 챌린지 3에 비해 연결 수를 두 배로 늘립니다.
브라우저에서 Locust 서버로 돌아갑니다. 다음 값을 필드에 입력하고 '군집 시작' 버튼을 클릭하세요.
- 사용자 수 – 2000
- 스폰율 – 10
- 호스트 – http://main-nginx-ingress
Prometheus와 Locust 대시보드로 돌아갑니다. Prometheus 그래프 아래의 분홍색 상자는 NGINX Ingress Controller Pod의 수가 확장되거나 축소되는 것을 나타냅니다.
터미널로 돌아가서 KEDA HPA를 수동으로 검사하세요. 출력의
REPLICAS필드는 현재 배포된 Pod 복제본의 수를 보여줍니다. (출력 내용은 읽기 쉽도록 두 줄로 나누어져 있습니다.)$ kubectl get hpa 이름 참조 ... keda-hpa-nginx-scale 배포/main-nginx-ingress ... ... 타겟 MINPODS MAXPODS REPLICAS 연령 ... 101500m/100(평균) 1 20 10 2m45s
다음 단계
활성 연결 수에만 기반하여 자동 크기 조정을 적용하는 경우 잠재적인 제한이 있습니다. (확장 시에도) NGINX Ingress Controller가 너무 바빠서 연결을 끊어야 하는 경우, 자동 확장기는 활성 연결이 줄어드는 것을 확인하고 이를 요청이 감소한 것으로 해석하여 복제본 수를 줄입니다. 이로 인해 성과가 저하될 수 있지만, 다양한 측정 항목을 조합하면 그런 일이 발생하지 않도록 할 수 있습니다. 예를 들어, nginxplus_connections_dropped (NGINX Plus 기반 NGINX Ingress Controller에서 사용 가능)는 삭제된 클라이언트 연결을 추적합니다.
NGINX Plus와 NGINX App Protect와 함께 NGINX Ingress Controller를 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의해 보세요 .
NGINX 오픈 소스로 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 얻거나 DockerHub 에서 미리 빌드된 컨테이너를 다운로드하세요.
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."