NGINX 튜토리얼: 속도 제한으로 Kubernetes API 보호하기

NGINX | 2022년 3월 21일

이 튜토리얼은 다음 자료의 개념을 실제로 적용해 보는 네 가지 튜토리얼 중 하나입니다. Microservices March 2022: Kubernetes Networking:

더욱 다양한 Kubernetes 네트워킹 사용 사례에서 NGINX를 활용하는 방법에 대한 자세한 안내가 필요하신가요? 무료 전자책인 NGINX를 활용한 Kubernetes 트래픽 관리: 실용 가이드를 다운로드하세요.

귀사에서는 방금 Kubernetes에 첫 번째 앱과 API를 출시했습니다. 트래픽이 대량으로 유입될 것으로 예상된다는 안내를 받아 NGINX Ingress Controller가 트래픽을 신속하게 라우팅할 수 있도록 이미 자동 확장을 구현했지만, API가 악의적인 공격의 표적이 될 수 있다는 우려가 있습니다. 무차별 대입 방식의 비밀번호 추측이나 DDoS 공격 등으로 API에 대량의 HTTP 요청이 유입되면 API와 앱 모두 과부하가 걸리거나 심지어 중단될 수 있습니다.

하지만 다행히도 해결책이 있습니다! 속도 제한이라는 트래픽 제어 기법은 수신 요청 속도를 실제 사용자의 일반적인 수준으로 제한하는 API 게이트웨이 활용 사례입니다. NGINX Ingress Controller에 속도 제한 정책을 구현하도록 구성하면 과도한 요청으로 인해 앱과 API에 부하가 몰리는 것을 방지할 수 있습니다. 잘하셨습니다!

실습 및 튜토리얼 개요

이 블로그는 2022년 3월 마이크로서비스 유닛 2의 실습인 Kubernetes에서 API 노출하기와 함께 제공되며, 여러 NGINX Ingress Controller와 속도 제한을 결합하여 앱과 API에 과도한 요청이 몰리는 것을 방지하는 방법을 보여줍니다.

이 튜토리얼을 진행하려면 다음 조건을 갖춘 머신이 필요합니다:

CPU 2개 이상
2GB의 여유 메모리
20GB의 여유 디스크 공간
인터넷 연결
Docker, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox 또는 VMware Fusion/Workstation과 같은 컨테이너 또는 가상 머신 관리자
minikube 설치됨
Helm 설치됨
브라우저 창을 실행할 수 있는 환경 구성이 필요합니다. 이것이 불가능한 경우 브라우저를 통해 관련 서비스에 접속할 방법을 찾아야 합니다.

실습과 튜토리얼을 최대한 활용하려면 시작하기 전에 다음 사항을 준비하는 것이 좋습니다:

Watch the 라이브 스트리밍으로 진행된 개념 개요 녹화 영상 시청
다음을 검토하세요: 배경 정보를 다룬 블로그, 웨비나 및 동영상
18분 분량의 실습 요약 동영상을 시청하세요: &amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;amp;nbsp;

이 튜토리얼에서는 다음 기술을 사용합니다:

각 챌린지의 안내에는 앱을 구성하는 데 사용되는 YAML 파일의 전체 내용이 포함되어 있습니다. 또한 당사의 GitHub 리포지토리에서 해당 내용을 복사할 수도 있습니다. 각 YAML 파일의 내용과 함께 GitHub 링크가 제공됩니다.

이 튜토리얼에는 세 가지 과제가 포함되어 있습니다:

클러스터, 앱, API 및 Ingress Controller 배포
앱과 API에 과부하 주기
이중 인그레스 컨트롤러와 속도 제한으로 앱과 API 보호하기

과제 1: 클러스터, 앱, API 및 Ingress 컨트롤러 배포

이 과제에서는 minikube 클러스터를 배포하고 샘플 앱 및 API로 Podinfo를 설치합니다. 그런 다음 NGINX Ingress Controller를 배포하고, 트래픽 라우팅을 구성한 후, Ingress 구성을 테스트합니다.

Minikube 클러스터 생성

Create a minikube 클러스터를 생성합니다. 몇 초 후 배포가 성공했다는 메시지가 표시됩니다.

$ minikube start 🏄  Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default

Podinfo 앱 및 Podinfo API 설치

Podinfo는 “Kubernetes에서 마이크로서비스를 실행하는 모범 사례를 보여 주는 Go로 제작된 웹 애플리케이션”입니다. 설치 용량이 작기 때문에 샘플 앱 및 API로 사용합니다.

원하는 텍스트 편집기를 사용하여 다음 내용으로 1-apps.yaml이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사). 이 파일은 다음을 포함하는 Deployment를 정의합니다:

apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: api 
spec: 
  selector: 
    matchLabels: 
      app: api 
  template: 
    metadata: 
      labels: 
        app: api 
    spec: 
      containers: 
        - name: api 
          image: stefanprodan/podinfo 
          ports: 
            - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: api 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30001 
  selector: 
    app: api 
  type: LoadBalancer 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: frontend 
spec: 
  selector: 
    matchLabels: 
      app: frontend 
  template: 
    metadata: 
      labels: 
        app: frontend 
    spec: 
      containers: 
        - name: frontend 
          image: stefanprodan/podinfo 
          ports: 
            - containerPort: 9898 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: frontend 
spec: 
  ports: 
    - port: 80 
      targetPort: 9898 
      nodePort: 30002 
  selector: 
    app: frontend 
  type: LoadBalancer

HTML 페이지를 렌더링하는 웹 앱(이하 Podinfo Frontend)
JSON 페이로드를 반환하는 API(Podinfo API)

앱과 API를 배포합니다:

$ kubectl apply -f 1-apps.yamldeployment.apps/api created 
service/api created 
deployment.apps/frontend created 
service/frontend created

다음에 대한 Pod가 Podinfo API 및 Podinfo Frontend 성공적으로 배포되었는지 확인합니다. 성공적으로 배포된 경우 Running 값이 STATUS 열에 표시됩니다.

$ kubectl get pods  
NAME                        READY   STATUS    RESTARTS  AGE 
api-7574cf7568-c6tr6        1/1     Running   0         87s 
frontend-6688d86fc6-78qn7   1/1     Running   0         87s

NGINX Ingress Controller 배포

NGINX Ingress Controller를 가장 빠르게 설치하는 방법은 Helm을 사용하는 것입니다.

Helm을 사용하여 NGINX Ingress Controller를 별도의 네임스페이스(nginx)에 설치합니다.

네임스페이스를 생성합니다:

$ kubectl create namespace nginx

Helm에 NGINX 리포지토리를 추가합니다:

$ helm repo add 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 nginx

NGINX Ingress Controller Pod가 배포되었는지 확인합니다. 배포된 경우 Running 값이 STATUS 열에 표시됩니다(가독성을 위해 출력은 두 줄로 나누어 표시됨).

$ kubectl get pods -namespace nginx NAME                                  READY   STATUS   ...
main-nginx-ingress-779b74bb8b-d4qtc   1/1     Running  ...

      ... RESTARTS   AGE 
      ... 0          92s

앱으로 트래픽 라우팅

원하는 텍스트 편집기를 사용하여 다음 내용으로 2-ingress.yaml이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사). 이 파일은 앱과 API로 트래픽을 라우팅하는 데 필요한 Ingress 매니페스트를 정의합니다.

apiVersion: networking.k8s.io/v1 
kind: Ingress 
metadata: 
  name: first 
spec: 
  ingressClassName: nginx 
  rules: 
    - host: "example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: frontend 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix 
    - host: "api.example.com" 
      http: 
        paths: 
          - backend: 
              service: 
                name: api 
                port: 
                  number: 80 
            path: / 
            pathType: Prefix

Ingress 리소스를 배포합니다:

$ kubectl apply -f 2-ingress.yaml ingress.networking.k8s.io/first created

Ingress 구성 테스트

Ingress 구성이 예상대로 작동하는지 확인하려면 임시 Pod를 사용하여 테스트하세요. 클러스터에서 일회용 BusyBox Pod를 실행합니다:

$ kubectl run -ti --rm=true busybox --image=busybox If you don't see a command prompt, try pressing enter.
/ #

Test Podinfo API를 테스트하려면 호스트 이름이 api.example.com인 NGINX Ingress Controller 파드에 요청을 보냅니다. 표시된 출력은 API가 트래픽을 수신하고 있음을 나타냅니다.

/ # wget --header="Host: api.example.com" -qO- main-nginx-ingress.nginx { 
  "hostname": "api-687fd448f8-t7hqk", 
  "version": "6.0.3", 
  "revision": "", 
  "color": "#34577c", 
  "logo": "https://raw.githubusercontent.com/stefanprodan/podinfo/gh-pages/cuddle_clap.gif", 
  "message": "greetings from podinfo v6.0.3", 
  "goos": "linux", 
  "goarch": "arm64", 
  "runtime": "go1.16.9", 
  "num_goroutine": "6", 
  "num_cpu": "4" 
}

동일한 BusyBox 파드에서 다음 명령을 실행하여 웹 브라우저를 시뮬레이션하고 웹 페이지를 가져오는 방식으로 Podinfo Frontend를 테스트합니다. 표시된 출력은 웹 페이지 시작 부분의 HTML 코드입니다.

/ # wget --header="Host: example.com" --header="User-Agent: Mozilla" -qO- main-nginx-ingress.nginx <!DOCTYPE html> 
<html> 
<head> 
  <title>frontend-596d5c9ff4-xkbdc</title> 
  # ...

다른 터미널에서 브라우저로 Podinfo를 엽니다. greetings from podinfo 페이지가 표시되면 Podinfo가 실행 중인 것입니다.

$ minikube service podinfo

축하합니다! NGINX Ingress Controller가 요청을 수신하여 앱과 API로 전달하고 있습니다.
원래 터미널에서 BusyBox 세션을 종료합니다:

/ # exit 
$

과제 2: 앱과 API에 과부하 주기

이 챌린지에서는 오픈 소스 부하 생성 도구인 Locust를 설치하고, 이를 사용하여 API에 과부하를 일으키고 앱을 중단시키는 트래픽 급증을 시뮬레이션합니다.

Locust 설치

원하는 텍스트 편집기를 사용하여 다음 내용으로 3-locust.yaml이라는 YAML 파일을 만듭니다(또는 GitHub에서 복사). ConfigMap 객체는 올바른 헤더를 포함하여 Pod로 전송할 요청을 생성하는 locustfile.py라는 스크립트를 정의합니다. 트래픽은 앱과 API 간에 균등하게 분산되지 않고 Podinfo API에 편중되며, 요청 5개 중 1개만 Podinfo Frontend로 전송됩니다. Deployment 및 Service 객체는 Locust Pod를 정의합니다.

apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: locust-script 
data: 
  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("Frontend failed") 
                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 failed") 
                else: 
                    response.success() 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: locust 
spec: 
  selector: 
    matchLabels: 
      app: locust 
  template: 
    metadata: 
      labels: 
        app: locust 
    spec: 
      containers: 
        - name: locust 
          image: locustio/locust 
          ports: 
            - containerPort: 8089 
          volumeMounts: 
            - mountPath: /home/locust 
              name: locust-script 
      volumes: 
        - name: locust-script 
          configMap: 
            name: locust-script 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: locust 
spec: 
  ports: 
    - port: 8089 
      targetPort: 8089 
      nodePort: 30015 
  selector: 
    app: locust 
  type: LoadBalancer

Locust 배포:

$ kubectl apply -f 3-locust.yaml configmap/locust-script created 
deployment.apps/locust created 
service/locust created

Locust 배포를 확인합니다. 다음 샘플 출력에서는 kubectl apply 명령을 실행한 지 불과 몇 초 후에 확인 명령을 실행했으므로 설치가 아직 진행 중입니다. 이는 STATUS 필드에서 Locust Pod의 값이 ContainerCreating으로 표시되는 것으로 알 수 있습니다. 다음 섹션으로 진행하기 전에 값이 Running이 될 때까지 기다립니다. (가독성을 위해 출력은 두 줄로 나누어 표시했습니다.)

$ kubectl get pods
NAME                        READY   STATUS            ...           api-7574cf7568-c6tr6        1/1     Running           ...
frontend-6688d86fc6-78qn7   1/1     Running           ...            locust-77c699c94d-hc76t     0/1     ContainerCreating ...

      ... RESTARTS   AGE 
      ... 0          33m
      ... 0          33m
      ... 0           4s

트래픽 급증 시뮬레이션

브라우저에서 Locust를 엽니다.

$ minikube service locust

필드에 다음 값을 입력합니다:
- 사용자 수 – 1000
- 생성 속도 – 30
- 호스트 – http://main-nginx-ingress
Click the Start swarming 버튼을 클릭하여 Podinfo API와 Podinfo Frontend로 트래픽을 전송합니다. Locust의 Charts 및 Failures 탭에서 트래픽 패턴을 확인합니다:
- 차트 – API 요청 수가 증가할수록 Podinfo API의 응답 시간이 길어집니다.
- 실패 – Podinfo API와 Podinfo Frontend가 하나의 Ingress 컨트롤러를 공유하기 때문에 API 요청 수가 증가하면 곧 웹 앱에서 오류가 발생하기 시작합니다.

이는 API를 악용하는 단 한 명의 악의적인 사용자만으로도 API뿐만 아니라 NGINX Ingress Controller가 제공하는 모든 앱이 중단될 수 있기 때문에 문제가 됩니다!

과제 3: 이중 Ingress Controller와 요청 속도 제한으로 앱과 API 보호하기

마지막 과제에서는 이전 배포의 한계를 해소하기 위해 두 개의 NGINX Ingress Controller를 배포합니다. 이를 위해 각 컨트롤러마다 별도의 네임스페이스를 생성하고 Podinfo Frontend와 Podinfo API용 NGINX Ingress Controller 인스턴스를 각각 설치한 다음, 앱과 API의 트래픽이 각자의 NGINX Ingress Controller로 전달되도록 Locust를 재구성하고 속도 제한이 제대로 적용되는지 확인합니다. 먼저 아키텍처 문제를 해결하는 방법을 살펴보겠습니다. 이전 과제에서는 API 요청을 과도하게 보내 NGINX Ingress Controller에 과부하를 일으켰고, 그 결과 앱에도 영향이 미쳤습니다. 이는 하나의 Ingress Controller가 웹 앱(Podinfo Frontend)과 API(Podinfo API) 모두의 트래픽 라우팅을 담당했기 때문입니다.

각 서비스마다 별도의 NGINX Ingress Controller Pod를 실행하면 과도한 API 요청으로 인해 앱이 영향을 받는 것을 방지할 수 있습니다. 모든 사용 사례에서 반드시 필요한 것은 아니지만, 이 시뮬레이션에서는 여러 NGINX Ingress Controller를 실행할 때의 이점을 쉽게 확인할 수 있습니다.

솔루션의 두 번째 부분은 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 "first" deleted

다음 이름의 네임스페이스를 생성합니다: nginx‑web (용도: Podinfo Frontend):

$ kubectl create namespace nginx-web 
namespace/nginx-web created

다음 이름의 네임스페이스를 생성합니다. nginx‑api 대상: Podinfo 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-web

다음 이름의 Ingress 매니페스트를 생성합니다: 4-ingress-web.yaml 대상: Podinfo 프런트엔드(또는 GitHub에서 복사). apiVersion: k8s.nginx.org/v1 kind: Policy metadata: name: rate-limit-policy spec: rateLimit: rate: 10r/s key: ${binary_remote_addr} zoneSize: 10M --- apiVersion: k8s.nginx.org/v1 kind: VirtualServer metadata: name: api-vs spec: ingressClassName: nginx-api host: api.example.com policies: - name: rate-limit-policy upstreams: - name: api service: api port: 80 routes: - path: / action: pass: api
새 매니페스트를 배포합니다:

$ kubectl apply -f 4-ingress-web.yaml 
ingress.networking.k8s.io/frontend created

Locust 재구성

이제 Locust를 다시 구성하고 다음 사항을 확인합니다:

Podinfo API에 과부하가 걸리지 않습니다.
아무리 많은 요청이 전송되어도 Podinfo API는 Podinfo Frontend에 영향을 주지 않습니다.

다음 단계를 수행하세요:

Locust 스크립트를 다음과 같이 변경합니다. Locust는 대시보드에서 단일 URL만 지원하므로, 다음 내용의 YAML 파일 6-locust.yaml을 사용하여 Python 스크립트에 값을 하드코딩합니다(또는 GitHub에서 복사). 각 task의 URL을 확인하세요.


apiVersion: v1 
kind: ConfigMap 
metadata: 
  name: locust-script 
data: 
  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("Frontend failed") 
                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 failed") 
                else: 
                    response.success() 
--- 
apiVersion: apps/v1 
kind: Deployment 
metadata: 
  name: locust 
spec: 
  selector: 
    matchLabels: 
      app: locust 
  template: 
    metadata: 
      labels: 
        app: locust 
    spec: 
      containers: 
        - name: locust 
          image: locustio/locust 
          ports: 
            - containerPort: 8089 
          volumeMounts: 
            - mountPath: /home/locust 
              name: locust-script 
      volumes: 
        - name: locust-script 
          configMap: 
            name: locust-script 
--- 
apiVersion: v1 
kind: Service 
metadata: 
  name: locust 
spec: 
  ports: 
    - port: 8089 
      targetPort: 8089 
      nodePort: 30015 
  selector: 
    app: locust 
  type: LoadBalancer

모든 요청은 Podinfo 프런트엔드에서 다음 nginx‑web NGINX Ingress Controller로 전달됩니다: http://web-nginx-ingress.nginx-web
All requests to Podinfo API에 대한 모든 요청은 nginx‑api NGINX Ingress Controller의 다음 주소로 전달됩니다: http://api-nginx-ingress.nginx-api

새 Locust 구성을 배포합니다. 출력 결과를 통해 스크립트는 변경되었지만 다른 요소는 변경되지 않았음을 확인할 수 있습니다.

$ kubectl apply -f 6-locust.yaml 
configmap/locust-script configured 
deployment.apps/locust unchanged 
service/locust unchanged

새 ConfigMap을 강제로 다시 로드하려면 Locust 파드를 삭제합니다. 삭제할 파드를 식별하기 위해 kubectl delete pod 명령의 인수는 모든 파드 목록에서 Locust 파드를 선택하는 파이프 명령으로 표현됩니다.

$ kubectl delete pod `kubectl get pods | grep locust | awk {'print $1'}`

Locust가 다시 로드되었는지 확인합니다(Locust Pod의 AGE 열 값이 몇 초에 불과해야 함).

$ kubectl get pods
NAME                        READY   STATUS   ...           api-7574cf7568-jrlvd        1/1     Running  ...
frontend-6688d86fc6-vd856   1/1     Running  ...            locust-77c699c94d-6chsg     0/1     Running  ...

      ... RESTARTS   AGE 
      ... 0        9m57s
      ... 0        9m57s
      ... 0           6s

속도 제한 확인

Locust로 돌아가 다음 필드의 매개변수를 변경합니다:
- 사용자 수 – 400
- 생성 속도 – 10
- 호스트 – http://main-nginx-ingress
Click the Start swarming 버튼을 클릭하여 Podinfo API와 Podinfo Frontend로 트래픽을 전송합니다. 왼쪽 상단의 Locust 제목 표시줄에서 STATUS 열의 사용자 수가 증가함에 따라 FAILURES 열의 값도 증가하는 것을 확인합니다. 하지만 이제 오류는 Podinfo Frontend가 아니라 Podinfo API에서 발생합니다. API에 설정된 속도 제한으로 인해 과도한 요청이 거부되기 때문입니다. 오른쪽 하단의 추적 정보에서 NGINX가 503 Service Temporarily Unavailable 메시지를 반환하는 것을 확인할 수 있습니다. 이 메시지는 속도 제한 기능의 일부이며 사용자 지정할 수 있습니다. API에는 속도 제한이 적용되지만 웹 애플리케이션은 항상 사용할 수 있습니다. 잘하셨습니다!

다음 단계

실제 환경에서는 속도 제한만으로 악의적인 행위자로부터 앱과 API를 보호하기에 충분하지 않습니다. Kubernetes 앱, API 및 인프라를 보호하려면 다음 방법 중 적어도 한두 가지를 구현해야 합니다:

인증 및 권한 부여
웹 애플리케이션 방화벽 및 DDoS 보호
종단 간 암호화 및 제로 트러스트
업계 규정 준수

이러한 주제와 그 밖의 다양한 내용은 Microservices March 2022의 유닛 3인 Kubernetes의 마이크로서비스 보안 패턴에서 다룹니다. NGINX Plus 및 NGINX App Protect가 포함된 Kubernetes용 NGINX Ingress Controller를 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요. NGINX Open Source가 포함된 NGINX Ingress Controller를 사용해 보려면 릴리스 소스 코드를 받거나 DockerHub에서 사전 빌드된 컨테이너를 다운로드할 수 있습니다.

작성자 소개

Daniele Polencic

Daniele Polencic의 다른 블로그 게시물