NGINX 튜토리얼: 속도 제한으로 Kubernetes API 보호
이 튜토리얼은 Microservices March 2022의 개념을 실제로 적용한 4가지 튜토리얼 중 하나입니다. 쿠버네티스 네트워킹 :
- 자동 확장으로 Kubernetes 대기 시간 단축
- 속도 제한을 사용하여 Kubernetes API 보호(이 게시물)
- Kubernetes 앱을 SQL 주입으로부터 보호
- Canary 배포로 가동 시간과 회복성 향상
더욱 다양한 Kubernetes 네트워킹 사용 사례에 NGINX를 사용하는 방법에 대한 자세한 지침을 원하시나요? 무료 전자책, NGINX로 Kubernetes 트래픽 관리 다운로드: 실용 가이드
귀하의 조직이 Kubernetes에서 첫 번째 앱과 API를 출시했습니다. 트래픽 양이 많을 것으로 예상되며(NGINX Ingress Controller가 트래픽을 빠르게 라우팅할 수 있도록 자동 크기 조정이 이미 구현됨) API가 악의적인 공격의 표적이 될 수 있다는 우려가 있습니다. API가 대량의 HTTP 요청을 수신하는 경우(무차별 대입 공격이나 DDoS 공격 가능성) API와 앱 모두 과부하가 걸리거나 충돌할 수 있습니다.
하지만 당신은 운이 좋습니다! 트래픽 제어 기술은 속도 제한 이라고 하며, 실제 사용자에게 일반적인 값으로 들어오는 요청 속도를 제한하는 API 게이트웨이 사용 사례입니다. NGINX Ingress Controller를 구성하여 속도 제한 정책을 구현하면 앱과 API가 너무 많은 요청으로 인해 과부하가 걸리는 것을 방지할 수 있습니다. 좋은 일이에요!
랩 및 튜토리얼 개요
이 블로그는 2022년 3월 마이크로서비스 단원 2 - Kubernetes에서 API 공개 랩에 대한 내용으로, 앱과 API가 과부하되지 않도록 속도 제한과 여러 NGINX Ingress 컨트롤러를 결합하는 방법을 보여줍니다.
튜토리얼을 실행하려면 다음 사양을 갖춘 장비가 필요합니다.
- 2개 이상의 CPU
- 2GB의 여유 메모리
- 20GB의 여유 디스크 공간
- 인터넷 연결
- Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox 또는 VMware Fusion/Workstation과 같은 컨테이너 또는 가상 머신 관리자
- minikube 설치됨
- 헬름 설치됨
- 브라우저 창을 시작할 수 있는 구성입니다. 이것이 가능하지 않다면 브라우저를 통해 관련 서비스에 접속하는 방법을 알아내야 합니다.
랩과 튜토리얼을 최대한 활용하려면 시작하기 전에 다음을 권장합니다.
라이브 스트리밍된 개념적 개요의 녹화를 시청하세요
배경 블로그, 웨비나 및 비디오를 검토하세요
랩의 18분 분량 비디오 요약을 시청하세요.
이 튜토리얼에서는 다음 기술을 사용합니다.
각 과제에 대한 지침에는 앱을 구성하는 데 사용되는 YAML 파일의 전체 텍스트가 포함되어 있습니다. GitHub 저장소 에서 텍스트를 복사할 수도 있습니다. 각 YAML 파일의 텍스트와 함께 GitHub에 대한 링크가 제공됩니다.
이 튜토리얼에는 세 가지 과제가 포함되어 있습니다.
도전 1: 클러스터, 앱, API 및 Ingress 컨트롤러 배포
이 챌린지에서는 minikube 클러스터를 배포 하고 Podinfo를 샘플 앱 및 API로 설치합니다 . 그런 다음 NGINX Ingress Controller를 배포하고 트래픽 라우팅을 구성 하고 Ingress 구성을 테스트합니다 .
Minikube 클러스터 생성
Minikube 클러스터를 생성합니다. 몇 초 후에 배포가 성공적이었음을 확인하는 메시지가 나타납니다.
$ minikube start 🏄 완료! kubectl은 이제 기본적으로 "minikube" 클러스터와 "기본" 네임스페이스를 사용하도록 구성되었습니다.
Podinfo 앱과 Podinfo API 설치
Podinfo 는 "Kubernetes에서 마이크로서비스를 실행하는 모범 사례를 보여주는 Go로 만든 웹 애플리케이션"입니다. 크기가 작기 때문에 샘플 앱과 API로 사용하고 있습니다.
원하는 텍스트 편집기를 사용하여 다음 내용으로 1-apps.yaml 이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사합니다 ). 다음을 포함하는 배포를 정의합니다.
- HTML 페이지를 렌더링하는 웹 앱( Podinfo Frontend 라고 부르겠습니다)
- JSON 페이로드를 반환하는 API( Podinfo API )
apiVersion: apps/v1 종류: 배포 메타데이터: 이름: api 스펙: 선택자: 매치 라벨: 앱: api 템플릿: 메타데이터: 라벨: 앱: api 스펙: 컨테이너: - 이름: api 이미지: stefanprodan/podinfo 포트: - 컨테이너 포트: 9898 --- apiVersion: v1 종류: 서비스 메타데이터: 이름: API 스펙: 포트: - 포트: 80 대상 포트: 9898 노드포트: 30001 선택자: 앱: api 유형: 로드밸런서 --- apiVersion: apps/v1 종류: 배포 메타데이터: 이름: 프런트엔드 스펙: 선택자: 매치 라벨: 앱: 프런트엔드 템플릿: 메타데이터: 라벨: 앱: 프런트엔드 스펙: 컨테이너: - 이름: 프런트엔드 이미지: stefanprodan/podinfo 포트: - 컨테이너 포트: 9898 --- apiVersion: v1 종류: 서비스 메타데이터: 이름: 프런트엔드 스펙: 포트: - 포트: 80 대상 포트: 9898 노드포트: 30002 선택기: 앱: 프런트엔드 유형: 로드 밸런서앱과 API 배포:
$ kubectl apply -f 1-apps.yaml deployment.apps/api가 생성됨 서비스/api가 생성됨 deployment.apps/frontend가 생성됨 서비스/frontend가 생성됨Podinfo API 와 Podinfo Frontend 의 Pod가
STATUS열의 '실행중' 값에서 알 수 있듯이 성공적으로 배포되었는지 확인합니다.$ kubectl get pods 이름 준비 상태 재시작 나이 api-7574cf7568-c6tr6 1/1 실행 중 0 87초 frontend-6688d86fc6-78qn7 1/1 실행 중 0 87초
NGINX Ingress Controller 배포
NGINX Ingress Controller를 설치하는 가장 빠른 방법은 Helm을 사용하는 것입니다.
Helm을 사용하여 별도의 네임스페이스( nginx )에 NGINX Ingress Controller를 설치합니다.
네임스페이스를 만듭니다.
$ kubectl nginx 네임스페이스 생성Helm에 NGINX 저장소를 추가합니다.
$ helm repo nginx-stable 추가 https://helm.nginx.com/stable클러스터에 NGINX Ingress Controller를 다운로드하여 설치하세요.
$ helm install main nginx-stable/nginx-ingress \ --set controller.watchIngressWithoutClass=true \ --set controller.ingressClass=nginx \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30010 \ --set controller.enablePreviewPolicies=true \ --namespace nginxSTATUS열에'Running'이라는 값이 표시되어 NGINX Ingress Controller 포드가 배포되었는지 확인합니다(읽기 쉽도록 출력이 두 줄로 나뉘어져 있습니다).$ kubectl get pods -namespace nginx 이름 준비 상태 ... main-nginx-ingress-779b74bb8b-d4qtc 1/1 실행 중 ... ... RESTARTS AGE ... 0 92초
앱으로 트래픽 라우팅
- 원하는 텍스트 편집기를 사용하여 다음 내용으로 2-ingress.yaml 이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사 ). 앱과 API로 트래픽을 라우팅하는 데 필요한 Ingress 매니페스트를 정의합니다.
- Ingress 리소스 배포:
apiVersion: networking.k8s.io/v1
종류: Ingress
메타데이터:
이름: 첫 번째
사양:
ingressClassName: nginx
규칙:
- 호스트: "example.com"
http:
경로:
- 백엔드:
서비스:
이름: 프런트엔드
포트:
번호: 80
경로: /
경로 유형: 접두사
- 호스트: "api.example.com"
http:
경로:
- 백엔드:
서비스:
이름: api
포트:
번호: 80
경로: /
경로 유형: 접두사
$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/first 생성됨
Ingress 구성 테스트
Ingress 구성이 예상대로 수행되는지 확인하려면 임시 Pod를 사용하여 테스트하세요. 클러스터에서 일회용 BusyBox 포드를 시작합니다.
$ kubectl run -ti --rm=true busybox --image=busybox 명령 프롬프트가 보이지 않으면 enter 키를 눌러보세요. / #호스트 이름 api.example.com 을 사용하여 NGINX Ingress Controller Pod에 요청을 발행하여 Podinfo API를 테스트합니다. 표시된 출력은 API가 트래픽을 수신하고 있음을 나타냅니다.
/ # wget --header="호스트: api.example.com" -qO- main-nginx-ingress.nginx { "호스트 이름": "api-687fd448f8-t7hqk", "버전": "6.0.3", "revision": "", "color": "#34577c", "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", "message": "podinfo v6.0.3에서 인사드립니다", "goos": "linux", "goarch": "arm64", "runtime": "go1.16.9", "num_goroutine": "6", "숫자_CPU": "4" }- 같은 BusyBox Pod에서 다음 명령을 실행하여 웹 브라우저를 시뮬레이션하고 웹 페이지를 검색하여 Podinfo 프런트엔드를 테스트합니다. 표시된 출력은 웹 페이지 시작 부분에 대한 HTML 코드입니다.
/ # wget --header="호스트: example.com" --header="사용자 에이전트: Mozilla" -qO- main-nginx-ingress.nginx <!DOCTYPE html> <html> <head> <title>프런트엔드-596d5c9ff4-xkbdc</title> # ... 다른 터미널에서 브라우저로 Podinfo를 엽니다. podinfo 페이지의 인사말은 Podinfo가 실행 중임을 나타냅니다.
$ minikube 서비스 podinfo
축하해요! NGINX Ingress Controller는 요청을 받아서 앱과 API로 전달합니다.
원래 터미널에서 BusyBox 세션을 종료합니다.
/ # 종료 $
도전 2: 앱과 API를 압도하다
이번 챌린지에서는 오픈소스 부하 생성 도구인 Locust를 설치 하고 이를 사용하여 API에 과부하를 일으켜 앱이 충돌하는 트래픽 급증을 시뮬레이션합니다 .
로커스트 설치
원하는 텍스트 편집기를 사용하여 다음 내용으로 3-locust.yaml 이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사합니다 ).
ConfigMap객체는 올바른 헤더를 포함하여 Pod에 전송할 요청을 생성하는 locustfile.py 라는 스크립트를 정의합니다. 트래픽이 앱과 API 간에 균등하게 분산되지 않았습니다. 요청은 Podinfo API 로 편향되어 5개 요청 중 1개만 Podinfo 프런트엔드 로 전송됩니다.배포및서비스객체는 Locust Pod를 정의합니다.apiVersion: v1 종류: ConfigMap 메타데이터: 이름: locust-script 데이터: locustfile.py: |- from locust import HttpUser, task, between class QuickstartUser(HttpUser): wait_time = between(0.7, 1.3) @task(1) def visit_website(self): with self.client.get("/", headers={"Host": "example.com", "User-Agent": "Mozilla"}, timeout=0.2, catch_response=True) as response: if response.request_meta["response_time"] > 200: response.failure("프런트엔드 실패") else: response.success() @task(5) def visit_api(self): with self.client.get("/", headers={"Host": "api.example.com"}, timeout=0.2) as response: if response.request_meta["response_time"] > 200: response.failure("API 실패") else: response.success() --- apiVersion: apps/v1 kind: 배포 메타데이터: 이름: 로커스트 스펙: 선택자: 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 배포를 확인합니다. 다음 샘플 출력에서는
kubectlapply명령 후 몇 초 후에 검증 명령이 실행되었으므로STATUS필드에 있는 Locust Pod의ContainerCreating값에서 알 수 있듯이 설치가 아직 진행 중입니다. 다음 섹션으로 넘어가기 전에 값이실행 중이될 때까지 기다리세요. (출력 내용은 읽기 쉽도록 두 줄로 나누어져 있습니다.)$ kubectl get pods 이름 준비 상태 ... api-7574cf7568-c6tr6 1/1 실행 중 ... frontend-6688d86fc6-78qn7 1/1 실행 중 ... locust-77c699c94d-hc76t 0/1 컨테이너 생성 중 ... ... RESTARTS AGE ... 0 33분 ... 0 33분 ... 0 4초
교통량 급증 시뮬레이션
브라우저에서 Locust를 엽니다.
$ minikube 서비스 메뚜기
다음 값을 필드에 입력하세요.
- 사용자 수 – 1000
- 스폰율 – 30
- 호스트 – http://main-nginx-ingress
Podinfo API 와 Podinfo 프런트엔드 로 트래픽을 보내려면 'Swarming 시작' 버튼을 클릭하세요. Locust Charts 및 Failures 탭에서 트래픽 패턴을 관찰하세요.
- 차트 - API 요청 수가 증가함에 따라 Podinfo API 응답 시간이 느려집니다.
- 오류 – Podinfo API 와 Podinfo 프런트엔드는 Ingress 컨트롤러를 공유하기 때문에 API 요청 수가 증가하면 곧 웹 앱에서 오류가 반환되기 시작합니다.
이것이 문제가 되는 이유는 API를 사용하는 단 한 명의 나쁜 행위자가 API뿐만 아니라 NGINX Ingress Controller가 제공하는 모든 앱을 다운시킬 수 있기 때문입니다!
도전 3: 듀얼 인그레스 컨트롤러와 속도 제한으로 앱과 API 저장
마지막 과제에서는 이전 배포의 제한을 제거하기 위해 두 개의 NGINX Ingress Controller를 배포하고, 각각에 대한 별도 네임스페이스를 생성하고 , Podinfo 프런트엔드 와 Podinfo API 에 대해 별도의 NGINX Ingress Controller 인스턴스를 설치하고, Locust를 재구성하여 앱과 API의 트래픽을 해당 NGINX Ingress Controller로 전달하고, 속도 제한이 효과적인지 확인합니다 . 먼저, 건축적 문제를 어떻게 해결할지 살펴보겠습니다. 이전 챌린지에서 여러분은 API 요청으로 NGINX Ingress Controller를 압도했고, 이는 앱에도 영향을 미쳤습니다. 이는 단일 Ingress 컨트롤러가 웹 앱( Podinfo Frontend )과 API( Podinfo API ) 모두로의 트래픽 라우팅을 담당했기 때문에 발생했습니다.
각 서비스에 대해 별도의 NGINX Ingress Controller Pod를 실행하면 앱이 너무 많은 API 요청으로 영향을 받는 것을 방지할 수 있습니다. 이는 반드시 모든 사용 사례에 필요한 것은 아니지만 시뮬레이션에서는 여러 NGINX Ingress 컨트롤러를 실행하는 이점을 쉽게 확인할 수 있습니다.
Podinfo API가 과부하되는 것을 방지하기 위한 솔루션의 두 번째 부분은 NGINX Ingress Controller를 API 게이트웨이로 사용하여 속도 제한을 구현하는 것입니다.
속도 제한이란 무엇인가요?
속도 제한은 사용자가 지정된 기간 동안 수행할 수 있는 요청 수를 제한합니다. 예를 들어 DDoS 공격을 완화하려면 속도 제한을 사용하여 들어오는 요청 속도를 실제 사용자에게 일반적인 값으로 제한할 수 있습니다. NGINX에서 속도 제한을 구현하면 너무 많은 요청을 제출하는 클라이언트는 오류 페이지로 리디렉션되어 API에 부정적인 영향을 미칠 수 없습니다. NGINX Ingress Controller 설명서 에서 이것이 어떻게 작동하는지 알아보세요.
API 게이트웨이란 무엇입니까?
API 게이트웨이는 클라이언트의 API 요청을 적절한 서비스로 라우팅합니다. 이 간단한 정의에 대한 큰 오해는 API 게이트웨이가 고유한 기술이라는 것입니다. 그렇지 않아요. 오히려 "API 게이트웨이"는 다양한 유형의 프록시(가장 일반적인 ADC 또는 로드 밸런서 및 역방향 프록시, 그리고 점점 더 많은 Ingress 컨트롤러 또는 서비스 메시)를 통해 구현할 수 있는 일련의 사용 사례를 설명합니다. 속도 제한은 API 게이트웨이를 배포하는 일반적인 사용 사례입니다. Kubernetes에서 API 게이트웨이 사용 사례에 대해 자세히 알아보세요. 어떻게 선택해야 하나요? API 게이트웨이 대 Ingress 컨트롤러와 서비스 메시 우리의 블로그에서.
클러스터 준비
새로운 아키텍처와 속도 제한을 구현하기 전에 이전 NGINX Ingress Controller 구성을 삭제해야 합니다.
- NGINX Ingress Controller 구성을 삭제합니다.
$ kubectl delete -f 2-ingress.yaml ingress.networking.k8s.io "첫 번째" 삭제됨 Podinfo 프런트엔드 에 nginx‑web 이라는 네임스페이스를 만듭니다.
$ kubectl create namespace nginx-web 네임스페이스/nginx-web 생성됨Podinfo API 에 대해 nginx‑api 라는 네임스페이스를 만듭니다.
$ kubectl create namespace nginx-api namespace/nginx-api created
Podinfo 프런트엔드용 NGINX Ingress Controller 설치
NGINX Ingress Controller 설치:
$ helm install web nginx-stable/nginx-ingress --set controller.ingressClass=nginx-web \ --set controller.service.type=NodePort \ --set controller.service.httpPort.nodePort=30020 \ --namespace nginx-webPodinfo 프런트엔드 를 위해 4-ingress-web.yaml 이라는 Ingress 매니페스트를 만듭니다(또는 GitHub에서 복사합니다 ).
api버전: k8s.nginx.org/v1 종류: 정책 메타데이터: 이름: rate-limit-policy 사양: rateLimit: rate: 10r/s 키:${binary_remote_addr} 영역 크기: 10M --- api버전: k8s.nginx.org/v1 종류: VirtualServer 메타데이터: 이름: api-vs 사양: ingressClassName: nginx-api 호스트: api.example.com 정책: - 이름: rate-limit-policy 업스트림: - 이름: api 서비스: api 포트: 80개 경로: - 경로: / 작업: 통과: API새로운 매니페스트를 배포합니다.
$ kubectl apply -f 4-ingress-web.yaml ingress.networking.k8s.io/frontend가 생성되었습니다.
로커스트 재구성
이제 Locust를 재구성하고 다음 사항을 확인하세요.
- Podinfo API는 과부하되지 않습니다.
- Podinfo API 에 아무리 많은 요청이 전송되어도 Podinfo 프런트엔드 에는 영향이 없습니다.
다음 단계를 수행하세요.
Locust 스크립트를 다음과 같이 변경합니다.
- Podinfo 프런트엔드 에 대한 모든 요청은 http://web-nginx-ingress.nginx-web 에 있는 nginx‑web NGINX Ingress Controller로 전달됩니다.
- Podinfo API 에 대한 모든 요청은 http://api-nginx-ingress.nginx-api 의 nginx‑api NGINX Ingress Controller로 전달됩니다.
Locust는 대시보드에서 단 하나의 URL만 지원하므로 다음 내용으로 YAML 파일 6-locust.yaml을 사용하여 Python 스크립트에 값을 하드코딩합니다(또는 GitHub에서 복사 ). 각
작업의 URL을 기록해 보세요.apiVersion: v1 종류: ConfigMap 메타데이터: 이름: locust-script 데이터: locustfile.py: |- from locust import HttpUser, task, between class QuickstartUser(HttpUser): wait_time = between(0.7, 1.3) @task(1) def visit_website(self): with self.client.get("http://web-nginx-ingress.nginx-web/", headers={"Host": "example.com", "User-Agent": "Mozilla"}, timeout=0.2, catch_response=True) as response: if response.request_meta["response_time"] > 200: response.failure("프런트엔드 실패") else: response.success() @task(5) def visit_api(self): with self.client.get("http://api-nginx-ingress.nginx-api/", headers={"Host": "api.example.com"}, timeout=0.2) as response: if response.request_meta["response_time"] > 200: response.failure("API 실패") else: response.success() --- apiVersion: apps/v1 kind: 배포 메타데이터: 이름: 로커스트 스펙: 선택자: matchLabels: 앱: 로커스트 템플릿: 메타데이터: 레이블: 앱: 로커스트 스펙: 컨테이너: - 이름: 로커스트 이미지: locustio/locust 포트: - 컨테이너 포트: 8089 볼륨 마운트: - 마운트 경로: /home/locust 이름: locust-script 볼륨: - 이름: locust-script configMap: 이름: locust-script --- apiVersion: v1 종류: 서비스 메타데이터: 이름: 로커스트 스펙: 포트: - 포트: 8089 대상 포트: 8089 노드포트: 30015 선택자: 앱: 메뚜기 유형: 로드밸런서새로운 Locust 구성을 배포합니다. 출력은 스크립트가 변경되었지만 다른 요소는 변경되지 않았음을 확인합니다.
$ kubectl apply -f 6-locust.yaml configmap/locust-script 구성된 deployment.apps/locust 변경되지 않음 service/locust 변경되지 않음Locust Pod를 삭제하여 새 ConfigMap을 강제로 다시 로드합니다. 제거할 Pod를 식별하기 위해
kubectldeletepod명령의 인수는 모든 Pod 목록에서 Locust Pod를 선택하는 파이프 명령의 형태로 표현됩니다.$ kubectl delete pod `kubectl get pods | grep locust | awk {'print $1'}`Locust가 다시 로드되었는지 확인하세요(
AGE열의 Locust 포드 값은 몇 초에 불과합니다).$ kubectl get pods 이름 준비 상태 ... api-7574cf7568-jrlvd 1/1 실행 중 ... frontend-6688d86fc6-vd856 1/1 실행 중 ... locust-77c699c94d-6chsg 0/1 실행 중 ... ... RESTARTS AGE ... 0 9분 57초 ... 0 9분 57초 ... 0 6초
속도 제한 확인
Locust로 돌아가서 다음 필드의 매개변수를 변경하세요.
- 사용자 수 – 400
- 스폰율 – 10
- 호스트 – http://main-nginx-ingress
Podinfo API 와 Podinfo 프런트엔드 로 트래픽을 보내려면 'Swarming 시작' 버튼을 클릭하세요.
왼쪽 상단의 Locust 제목 표시줄에서 STATUS 열의 사용자 수가 증가함에 따라 FAILURES 열의 값도 증가하는 것을 살펴보세요. 하지만 오류는 더 이상 Podinfo 프런트엔드 에서 발생하지 않고 Podinfo API 에서 발생합니다. API에 설정된 속도 제한으로 인해 과도한 요청이 거부되기 때문입니다. 오른쪽 아래의 추적에서 NGINX가 메시지를 반환하는 것을 볼 수 있습니다.503일시적으로서비스를이용할 수 없음은 요금 제한 기능의 일부이며 사용자 정의가 가능합니다. API는 속도 제한이 있으며 웹 애플리케이션은 항상 사용 가능합니다. 잘하셨어요!
다음 단계
현실 세계에서는 속도 제한만으로는 앱과 API를 악의적인 행위자로부터 보호하기에 충분하지 않습니다. Kubernetes 앱, API 및 인프라를 보호하려면 다음 방법 중 하나 또는 두 가지 이상을 구현해야 합니다.
- 인증 및 권한 부여
- 웹 애플리케이션 방화벽 및 DDoS 보호
- 종단간 암호화 및 Zero Trust
- 산업 규정 준수
이러한 주제와 더 많은 내용은 2022년 3월 마이크로서비스의 3장 - 쿠버네티스의 마이크로서비스 보안 패턴 에서 다룹니다. NGINX Plus 및 NGINX App Protect와 함께 Kubernetes용 NGINX Ingress Controller를 사용해 보려면 오늘 무료 30일 평가판을 시작하거나 당사에 문의하여 사용 사례에 대해 논의해 보세요 . NGINX 오픈 소스로 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 얻거나 DockerHub 에서 미리 빌드된 컨테이너를 다운로드하세요.
"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."