API Gateway(게이트웨이) Kong 아키텍처 설계 및 라우팅 환경 구성

API 게이트웨이를 활용하여 인증 및 권한 부여를 관리하는 것은 매우 일반적이며 효과적인 방법입니다. 여러 오픈소스 API 게이트웨이 도구 중에서는 Kong, Apigee, Tyk, 그리고 Nginx 기반의 API Gateway가 널리 사용되고 있습니다.

여기서는 Kong을 기반으로 한 API 게이트웨이를 사용하는 방법에 대해 설명하겠습니다.

Kong을 사용한 API 게이트웨이 구축

Kong 설치 및 실행
- Kong 공식 웹사이트에서 Kong을 다운로드하고 설치합니다.
- Kong은 기본적으로 데이터베이스로 PostgreSQL을 사용하므로 PostgreSQL도 설치해야 합니다.
Kong 설정
- Kong을 실행하기 전에 kong.conf 파일을 설정하여 기본 구성을 지정합니다.
- 예를 들어, 인증 플러그인 및 데이터베이스 연결을 구성합니다.
플러그인 추가
- Kong은 플러그인을 통해 다양한 기능을 제공합니다. 인증과 관련된 플러그인 중 하나인 kong-oidc 플러그인을 추가할 수 있습니다.
- kong-oidc는 OpenID Connect(OIDC)를 지원하여 토큰 기반의 인증을 쉽게 구현할 수 있게 해줍니다.
API 등록
- Kong에 보호할 API를 등록합니다. 이는 게이트웨이를 통해 라우팅될 서비스를 나타냅니다.
라우트 및 플러그인 적용
- 등록한 API에 대한 라우트를 설정하고, 인증과 관련된 플러그인을 적용합니다.
- kong-oidc 플러그인을 사용하여 OIDC 기반의 인증을 설정합니다.
인증 토큰 발급
- 사용자가 API를 호출하기 전에 Kong 게이트웨이에 대해 인증을 수행해야 합니다.
- 인증이 성공하면 게이트웨이는 토큰을 발급하고 이를 사용하여 실제 API에 액세스할 수 있게 됩니다.
스코프 및 권한 관리
- OIDC 토큰의 스코프를 통해 권한을 부여하고 관리할 수 있습니다.
- Kong은 다양한 권한 부여 및 액세스 제어 메커니즘을 지원합니다.
로그 및 모니터링 설정
- 필요에 따라 로깅 및 모니터링을 위한 플러그인을 추가하여 API 사용량 및 성능을 추적할 수 있습니다.

참고 사항

Kong의 경우, 공식 문서가 매우 자세하게 제공되므로 구체적인 설정 및 운영 방법을 확인하기에 유용합니다.
선택한 API 게이트웨이에 따라 구체적인 설정 방법이 다를 수 있으므로 해당 도구의 공식 문서를 반드시 참조하세요.

Kubernetes (k8s) 환경에 API 게이트웨이를 구성하는 것은 매우 일반적이며, 이를 통해 마이크로서비스 아키텍처를 관리하고 보호할 수 있습니다. 아래는 Kong을 Kubernetes 클러스터에 배포하고 구성하는 단계별 설명입니다.

단계 1: Kubernetes 클러스터 구성

Kubernetes 설치
- Kubernetes 클러스터를 구축하기 위해 선택한 배포 도구 또는 서비스를 사용하여 Kubernetes를 설치합니다.

kubectl 설정

Kubernetes 클러스터에 접근하기 위해 kubectl을 구성합니다.

kubectl config set-context <context-name> --cluster=<cluster-name> --user=<user-name> --namespace=<namespace-name>
kubectl config use-context <context-name>

단계 2: Kong Ingress Controller 배포

Kong Ingress Controller 설치
- Kong Ingress Controller를 배포합니다.
```
kubectl apply -f https://bit.ly/kong-ingress-dbless
```
Kong Ingress Controller 확인
- 배포된 Pod 및 서비스가 올바르게 생성되었는지 확인합니다.
```
kubectl get pods -n kong
kubectl get services -n kong
```

단계 3: KongProxy 리소스 생성

KongProxy Custom Resource 생성
- KongProxy Custom Resource를 사용하여 Kong이 어떤 서비스를 프록시하고 어떤 인증 및 권한 부여 기능을 사용할지 구성합니다.
```
apiVersion: configuration.konghq.com/v1
kind: KongProxy
metadata:
name: example
namespace: default
```
KongProxy 확인
- KongProxy 리소스가 올바르게 생성되었는지 확인합니다.
```
kubectl get kongproxy
```

단계 4: API 서비스 등록

KongIngress 리소스 생성

KongIngress 리소스를 사용하여 백엔드 서비스를 Kong에 연결합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example
annotations:
  konghq.com/strip-path: "true"
spec:
rules:
- http:
    paths:
    - path: /example
      pathType: ImplementationSpecific
      backend:
        service:
          name: example-service
          port:
            number: 80

KongIngress 확인
- KongIngress 리소스가 올바르게 생성되었는지 확인합니다.
```
kubectl get ingress
```

단계 5: 인증 및 권한 설정

KongPlugin 리소스 생성

KongPlugin 리소스를 사용하여 인증 및 권한 플러그인을 추가합니다.

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: example
namespace: default
config:
name: key-auth
key_names:
- apikey

KongPlugin 확인
- KongPlugin 리소스가 올바르게 생성되었는지 확인합니다.
```
kubectl get kongplugin
```

단계 6: 애플리케이션 테스트

애플리케이션 테스트
- Kong이 프록시하는 서비스에 대해 인증 및 권한이 적용되었는지 확인합니다.

이제 Kong이 Kubernetes 클러스터에서 API 게이트웨이로 작동합니다. 이는 기본적인 설정으로, 필요에 따라 더 많은 기능을 추가하고 세부 사항을 조정할 수 있습니다. Kong 및 Kubernetes의 버전에 따라 몇 가지 변경이 있을 수 있으므로 각 도구의 공식 문서를 참조하는 것이 좋습니다.

Kong Ingress Controller의 새로운 버전에서는 공식적으로 Helm을 통한 설치를 권장하고 있습니다. 따라서 새로운 방법을 통해 설치할 수 있습니다.

Helm을 사용한 Kong Ingress Controller 설치

Helm Repository 추가

helm repo add kong https://charts.konghq.com
helm repo update

Kong Ingress Controller 설치
```
helm install kong/kong --generate-name --set ingressController.installCRDs=false
```
- --generate-name 옵션은 릴리즈 이름을 자동으로 생성하게 합니다.
- --set ingressController.installCRDs=false 옵션은 CRDs(카스터머 리소스 디피니션)를 설치하지 않도록 설정합니다.
Kong Ingress 확인
```
kubectl get ingress -n <namespace>
```

서비스 URL 변경

만약 /app 경로로 서비스되기를 원한다면, Ingress 리소스를 다음과 같이 수정합니다.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: example
  annotations:
    konghq.com/strip-path: "true"
spec:
  rules:
  - http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: example-service
            port:
              number: 80

위의 Ingress 리소스에서 path: /app 및 pathType: Prefix 설정을 통해 /app 경로로 들어오는 모든 요청이 example-service로 라우팅됩니다.

이제 Helm을 통해 Kong Ingress Controller를 설치하고, Ingress 리소스를 통해 /app 경로로 서비스될 수 있도록 구성했습니다.

Kubernetes에 Kong API Gateway를 설치하고 구성하는 방법을 Helm Charts를 기준으로, Kong API Gateway를 설치하는 데 필요한 Helm Chart 설정, values.yaml 파일 커스터마이징, 그리고 이슈 해결 방법에 대해 단계적으로 자세하게 정리합니다.

Helm Chart 또는 Manifest 파일을 이용하여 Kong API Gateway를 Kubernetes에 설치할 수 있습니다.
Postgres 데이터베이스를 사용하는 DB 모드로 설치할 것을 권장합니다.
커스터마이징된 values.yaml 파일을 사용하여 익명 보고를 비활성화하고 Kong을 설치할 수 있습니다.
Kong의 Admin API 또는 Kubernetes 리소스를 통해 플러그인 및 라우트를 구성할 수 있습니다.

1. Helm Charts 설치 준비

Helm Charts를 사용하여 Kong API Gateway를 설치합니다. Kong의 Helm Charts는 공식 GitHub 레포지토리에서 제공됩니다.

$ helm repo add kong https://charts.konghq.com
$ helm repo update

2. values.yaml 커스터마이징

원본 values.yaml 파일을 사용하면 일부 에러가 발생할 수 있으므로 이를 수정하여 설치를 진행합니다. 주요 변경 사항은 Postgres 데이터베이스를 사용하는 설정과 익명 보고 기능을 비활성화하는 부분입니다.

deployment:
  kong:
    enabled: true
  serviceAccount:
    create: true

env:
  nginx_worker_processes: "2"
  anonymous_reports: "off"
  database: "postgres"

admin:
  enabled: true
  type: NodePort
  annotations: {}

  http:
    enabled: true

  tls:
    enabled: true
    parameters: []

proxy:
  enabled: true
  type: LoadBalancer

  labels:
    enable-metrics: "true"

  http:
    enabled: true
    parameters: []

  tls:
    enabled: true
    parameters: []

ingressController:
  enabled: true

  args:
  - --anonymous-reports=false

  admissionWebhook:
    enabled: false

  ingressClass: kong
  ingressClassAnnotations: {}

  rbac:
    create: true

postgresql:
  enabled: true

3. Helm을 이용한 Kong API Gateway 설치

위에서 작성한 values.yaml 파일을 사용하여 Helm을 통해 Kong을 설치합니다. 여기서는 Postgres 데이터베이스를 사용하도록 설정하였으며, Kong의 관리 기능은 NodePort로 활성화합니다.

$ helm install kong kong/kong --version 2.8.2 -n kong --create-namespace -f values.yaml

4. 설치된 리소스 확인

설치가 완료된 후, 리소스 상태를 확인합니다. 다음 명령어로 Kong 배포 상태를 확인할 수 있습니다.

$ kubectl describe deployment.apps/kong-kong -n kong

출력된 내용을 보면 Kong API Gateway의 proxy와 ingress-controller 컨테이너가 배포된 것을 확인할 수 있습니다. 아래에서 더 자세하게 설명합니다.

5. 주요 설정 및 이슈 해결

익명 보고 비활성화

Kong API Gateway에서 anonymous_reports가 기본적으로 활성화되어 있어 이를 비활성화해야 하는 경우가 있습니다. 이를 위해 다음과 같은 설정을 values.yaml 파일에 추가합니다.

env:
  anonymous_reports: "off"
ingressController:
  args:
  - --anonymous-reports=false

HTTP2 관련 에러

HTTP2를 활성화하면 ingress-controller에서 에러가 발생할 수 있습니다. 이러한 문제를 해결하기 위해 HTTP2 설정을 삭제합니다.

6. Kong 구성 방법

Kong을 설정하는 방법은 크게 두 가지가 있습니다.

Ingress 및 CRD
- Kubernetes Ingress 리소스를 사용하여 트래픽을 Kong으로 전달할 수 있습니다.
- Kong Ingress Controller가 Kubernetes 오브젝트를 Kong 오브젝트로 매핑하여 구성을 관리합니다.
Admin API
- Kong의 Admin API를 통해 직접 구성할 수 있습니다. 이 방법은 Kubernetes 외부에서 Kong을 구성할 때 유용합니다.

7. 추가 고려 사항

DB 모드 vs DBless 모드

Kong은 두 가지 모드를 지원합니다.

DB 모드: Postgres와 같은 외부 데이터베이스를 사용하여 Kong을 구성합니다. 이 모드에서는 모든 Kong 플러그인을 지원합니다.
DBless 모드: 데이터베이스를 사용하지 않고 YAML 파일이나 환경 변수를 통해 구성을 관리합니다. 그러나 일부 플러그인은 DBless 모드에서 지원되지 않으므로, 가능한 DB 모드를 사용하는 것이 좋습니다.

8. Kong 플러그인 구성

Kong의 플러그인은 상황에 따라 Global, Service, Route 단위로 설정할 수 있습니다. 플러그인을 설정하는 방법은 두 가지입니다:

Admin API를 사용하여 직접 플러그인을 설정.
Kubernetes의 Service, Ingress, KongPlugin 리소스를 사용하여 플러그인을 설정.

9. Helm Charts vs. Manifest 방식 배포

Kong API Gateway는 Helm Chart를 이용한 배포와 Manifest 파일을 통한 배포 두 가지 방법을 지원합니다. 필요한 방법에 맞춰 선택할 수 있으며, Helm Chart 방식이 더 간편하게 설치할 수 있는 방법입니다.

이와 같이 Kong API Gateway를 Helm Charts를 사용하여 최신 버전으로 Kubernetes 클러스터에 설치하고 구성할 수 있습니다.

설치된 리소스 확인 명령어 및 각 항목에 대한 설명

Kong API Gateway를 Kubernetes에 설치한 후, kubectl describe 명령어를 사용하여 배포된 리소스를 확인할 수 있습니다. 아래는 예시 명령어와 샘플 출력 내용을 포함한 각 항목에 대한 설명입니다.

설치된 리소스 확인 명령어

$ kubectl describe deployment.apps/kong-kong -n kong

샘플 출력

Name:                   kong-kong
Namespace:              kong
CreationTimestamp:      Wed, 22 Sep 2023 10:22:50 +0900
Labels:                 app.kubernetes.io/component=app
                        app.kubernetes.io/instance=kong
                        app.kubernetes.io/managed-by=Helm
                        app.kubernetes.io/name=kong
                        app.kubernetes.io/version=2.8.2
                        helm.sh/chart=kong-2.8.2
Annotations:            deployment.kubernetes.io/revision: 1
                        meta.helm.sh/release-name: kong
                        meta.helm.sh/release-namespace: kong
Selector:               app.kubernetes.io/component=app, app.kubernetes.io/instance=kong, app.kubernetes.io/name=kong
Replicas:               1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:           app=kong-kong
                    app.kubernetes.io/component=app
                    app.kubernetes.io/instance=kong
                    app.kubernetes.io/managed-by=Helm
                    app.kubernetes.io/name=kong
                    app.kubernetes.io/version=2.8.2
                    helm.sh/chart=kong-2.8.2
  Annotations:      kuma.io/gateway: enabled
                    traffic.sidecar.istio.io/includeInboundPorts:
  Service Account:  kong-kong
  Init Containers:
   clear-stale-pid:
    Image:      kong:2.8.2
    Command:
      rm
      -vrf
      $KONG_PREFIX/pids
    Environment:
      KONG_ADMIN_ACCESS_LOG:        /dev/stdout
      KONG_ADMIN_ERROR_LOG:         /dev/stderr
      KONG_DATABASE:                postgres
      KONG_NGINX_WORKER_PROCESSES:  2
      KONG_PG_HOST:                 kong-postgresql
   wait-for-db:
    Image:      kong:2.8.2
    Args:
      /bin/sh
      -c
      until kong start; do echo 'waiting for db'; sleep 1; done; kong stop
  Containers:
   ingress-controller:
    Image:      kong/kubernetes-ingress-controller:2.3
    Ports:      10255/TCP
    Args:
      --anonymous-reports=false
    Environment:
      POD_NAME:        (v1:metadata.name)
      POD_NAMESPACE:   (v1:metadata.namespace)
      CONTROLLER_KONG_ADMIN_URL:  https://localhost:8444
      CONTROLLER_ELECTION_ID:  kong-ingress-controller-leader-kong
      CONTROLLER_INGRESS_CLASS: kong
      CONTROLLER_KONG_ADMIN_TLS_SKIP_VERIFY: true
      CONTROLLER_PUBLISH_SERVICE: kong/kong-kong-proxy
   proxy:
    Image:      kong:2.8.2
    Ports:      8000/TCP, 8443/TCP, 8001/TCP, 8444/TCP
    Environment:
      KONG_ADMIN_ACCESS_LOG:        /dev/stdout
      KONG_ADMIN_ERROR_LOG:         /dev/stderr
      KONG_ADMIN_GUI_ACCESS_LOG:    /dev/stdout
      KONG_ADMIN_GUI_ERROR_LOG:     /dev/stderr
      KONG_ADMIN_LISTEN:            0.0.0.0:8001, 0.0.0.0:8444 ssl
      KONG_ANONYMOUS_REPORTS:       off
      KONG_CLUSTER_LISTEN:          off
      KONG_DATABASE:                postgres
      KONG_KIC:                     on
      KONG_LUA_PACKAGE_PATH:        /opt/?.lua;/opt/?/init.lua;;
      KONG_NGINX_WORKER_PROCESSES:  2
      KONG_PG_HOST:                 kong-postgresql
      KONG_PG_PASSWORD:             <set to the key 'password' in secret 'kong-postgresql'>  Optional: false
      KONG_PG_PORT:                 5432
      KONG_PLUGINS:                 bundled
      KONG_PORTAL_API_ACCESS_LOG:   /dev/stdout
      KONG_PORTAL_API_ERROR_LOG:    /dev/stderr
      KONG_PORT_MAPS:               80:8000, 443:8443
      KONG_PREFIX:                  /kong_prefix/
      KONG_PROXY_ACCESS_LOG:        /dev/stdout
      KONG_PROXY_ERROR_LOG:         /dev/stderr
      KONG_PROXY_LISTEN:            0.0.0.0:8000, 0.0.0.0:8443 ssl
      KONG_STATUS_LISTEN:           0.0.0.0:8100
      KONG_STREAM_LISTEN:           off
      KONG_NGINX_DAEMON:            off
  Volumes:
   kong-kong-prefix-dir:
    Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
   kong-kong-tmp:
    Type:       EmptyDir
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable
OldReplicaSets:  <none>
NewReplicaSet:   kong-kong-12345abcd (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  20m   deployment-controller  Scaled up replica set kong-kong-12345abcd to 1

각 항목에 대한 설명

Name: kong-kong
Kong 배포(Deployment)의 이름입니다. Helm을 통해 설치된 Kong 리소스를 관리할 때 사용되는 이름입니다.

Namespace: kong
Kong이 설치된 Kubernetes 네임스페이스입니다. 네임스페이스는 리소스들을 논리적으로 구분하는 방법입니다.

CreationTimestamp: Wed, 22 Sep 2023 10:22:50 +0900
배포 리소스가 생성된 시간입니다.

Labels:

app.kubernetes.io/component: app
app.kubernetes.io/instance: kong
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: kong
app.kubernetes.io/version: 2.8.2
helm.sh/chart: kong-2.8.2

배포에 적용된 라벨들로, 이 배포가 Helm을 통해 설치되었으며 Kong의 특정 버전임을 나타냅니다. Kubernetes에서 리소스를 구분하고 필터링할 때 사용됩니다.

Annotations:

deployment.kubernetes.io/revision: 1
meta.helm.sh/release-name: kong
meta.helm.sh/release-namespace: kong

배포와 관련된 추가 정보입니다. Helm 릴리스와 관련된 메타데이터와 배포의 리비전(revision) 정보를 포함합니다.

Selector: app.kubernetes.io/component=app, app.kubernetes.io/instance=kong, app.kubernetes.io/name=kong
Kubernetes가 이 배포와 연관된 Pod를 선택할 때 사용하는 라벨 셀렉터입니다.

Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable
현재 배포된 Kong의 Pod 상태입니다. 원하는 Pod 수가 1개이며, 1개의 Pod가 정상적으로 배포되어 실행 중임을 나타냅니다.

StrategyType: RollingUpdate
배포 전략으로, 기존의 Pod를 중단 없이 새 버전으로 교체하는 방식입니다.

RollingUpdateStrategy: 25% max unavailable, 25% max surge
Rolling 업데이트 중 최대 25%의 Pod는 사용할 수 없으며, 동시에 25%만큼 새로운 Pod가 추가될 수 있음을 의미합니다.

Pod Template: Pod가 배포될 때 사용하는 템플릿 정보입니다.

Labels: Pod에 적용된 라벨 정보입니다. 이 라벨들은 배포와 연결된 각 Pod에 적용됩니다.
Service Account: kong-kong
이 Pod가 사용하는 서비스 어카운트입니다. 서비스 어카운트는 Pod가 Kubernetes API와 상호작용할 때 필요한 권한을 정의합니다.

Init Containers: 배포될 때 먼저 실행되는 초기화 컨테이너 목록입니다.

clear-stale-pid: 이전 실행의 PID 파일을 삭제하여 중복 실행을 방지합니다.
wait-for-db: Postgres 데이터베이스가 준비될 때까지 대기하고, 준비가 완료되면 Kong을 시작합니다.

Containers: Kong 배포에 포함된 컨테이너 목록입니다.

ingress-controller: Kubernetes의 Ingress 리소스를 제어하는 컨트롤러입니다.
- Ports: Ingress Controller는 10255 포트를 사용합니다.
- Environment
  - POD_NAME: 실행 중인 Pod의 이름입니다.
  - POD_NAMESPACE: Pod가 실행 중인 네임스페이스입니다.
  - CONTROLLER_KONG_ADMIN_URL: Kong Admin API의 URL을 지정합니다.
  - CONTROLLER_ELECTION_ID: Kong Ingress Controller의 리더 선출을 위한 설정입니다.
  - CONTROLLER_INGRESS_CLASS: 사용되는 Ingress 클래스 이름입니다.
  - CONTROLLER_KONG_ADMIN_TLS_SKIP_VERIFY: Kong Admin API의 TLS 인증서를 검증하지 않도록 설정합니다.
  - CONTROLLER_PUBLISH_SERVICE: 트래픽을 Kong에 전달하는 서비스 이름을 설정합니다.
proxy: Kong의 핵심 프록시 역할을 하는 컨테이너입니다.
- Ports: 8000/TCP는 HTTP, 8443/TCP는 HTTPS 트래픽을 처리합니다.
- Environment: Kong 설정을 정의한 환경 변수가 포함되어 있습니다.
  - KONG_ADMIN_ACCESS_LOG: Kong Admin API의 접근 로그를 /dev/stdout로 출력합니다.
  - KONG_ADMIN_ERROR_LOG: Kong Admin API의 에러 로그를 /dev/stderr로 출력합니다.
  - KONG_ADMIN_GUI_ACCESS_LOG: Kong 관리 GUI의 접근 로그를 /dev/stdout로 출력합니다.
  - KONG_ADMIN_GUI_ERROR_LOG: Kong 관리 GUI의 에러 로그를 /dev/stderr로 출력합니다.
  - KONG_ADMIN_LISTEN: Kong Admin API가 수신할 IP와 포트를 지정합니다.
  - KONG_ANONYMOUS_REPORTS: 익명 보고 기능을 비활성화합니다.
  - KONG_CLUSTER_LISTEN: 클러스터 기능을 비활성화합니다.
  - KONG_DATABASE: Kong이 사용하는 데이터베이스 종류를 설정합니다 (postgres).
  - KONG_KIC: Kong Ingress Controller 기능을 활성화합니다.
  - KONG_LUA_PACKAGE_PATH: Lua 패키지 경로를 지정합니다.
  - KONG_NGINX_WORKER_PROCESSES: NGINX 워커 프로세스 수를 설정합니다.
  - KONG_PG_HOST: Postgres 데이터베이스의 호스트 이름입니다.
  - KONG_PG_PASSWORD: Postgres 데이터베이스 비밀번호입니다.
  - KONG_PG_PORT: Postgres 데이터베이스의 포트 번호입니다.
  - KONG_PLUGINS: Kong에서 사용할 플러그인 목록입니다 (bundled).
  - KONG_PORTAL_API_ACCESS_LOG: Kong 포털 API의 접근 로그를 /dev/stdout로 출력합니다.
  - KONG_PORTAL_API_ERROR_LOG: Kong 포털 API의 에러 로그를 /dev/stderr로 출력합니다.
  - KONG_PORT_MAPS: Kong이 사용하는 포트 매핑 정보입니다.
  - KONG_PREFIX: Kong 실행 환경의 경로입니다.
  - KONG_PROXY_ACCESS_LOG: 프록시 접근 로그를 /dev/stdout로 출력합니다.
  - KONG_PROXY_ERROR_LOG: 프록시 에러 로그를 /dev/stderr로 출력합니다.
  - KONG_PROXY_LISTEN: 프록시가 수신할 IP와 포트를 지정합니다.
  - KONG_STATUS_LISTEN: 상태 확인 포트 설정입니다.
  - KONG_STREAM_LISTEN: 스트림 수신 기능을 비활성화합니다.
  - KONG_NGINX_DAEMON: NGINX 데몬을 비활성화합니다.

Volumes: Pod가 사용하는 스토리지 볼륨입니다.

kong-kong-prefix-dir: 임시 디렉토리로, Kong의 실행 환경을 구성하는 데 사용됩니다.
kong-kong-tmp: 임시 파일을 저장하는 디렉토리입니다.

Conditions: Pod의 상태를 나타냅니다.

Available: True - 최소한 하나의 Pod가 성공적으로 실행되고 있음을 나타냅니다.
Progressing: True - 새로운 ReplicaSet이 성공적으로 배포되고 있음을 의미합니다.

OldReplicaSets: <none>
이전에 실행되던 ReplicaSet이 없습니다.

NewReplicaSet: kong-kong-12345abcd (1/1 replicas created)
현재 새로운 ReplicaSet이 생성되어 1개의 Pod가 정상적으로 실행 중입니다.

Events:

Normal  ScalingReplicaSet  20m   deployment-controller  Scaled up replica set kong-kong-12345abcd to 1

이벤트는 배포 관련된 작업과 상태 변화를 기록합니다. 여기서는 새로운 ReplicaSet이 생성되고 1개의 Pod가 정상적으로 배포되었음을 나타냅니다.

이와 같은 방법으로 kubectl describe 명령어를 사용하여 Kong API Gateway의 리소스를 확인할 수 있으며, 각 항목을 통해 배포 상태와 구성 요소에 대한 정보를 얻을 수 있습니다. 모든 설정 항목은 Kong Gateway의 kong.conf 파일을 통해 구성되며, 대부분의 설정은 환경 변수로도 관리할 수 있습니다. 아래는 각 설정 항목을 설명한 내용입니다.

1. General Settings (일반 설정)

prefix: Kong의 작업 디렉토리입니다. Nginx의 prefix와 유사하게 임시 파일과 로그를 저장하는 경로입니다. 각 Kong 프로세스는 별도의 작업 디렉토리를 가져야 합니다.
- 기본값: /usr/local/kong/
log_level: Nginx 서버의 로그 레벨을 설정합니다. 가능한 값은 debug, info, notice, warn, error, crit, alert, emerg 등이 있습니다.
- 기본값: notice
proxy_access_log: 프록시 요청에 대한 액세스 로그의 경로를 설정합니다. 비활성화하려면 off로 설정할 수 있습니다.
- 기본값: logs/access.log
proxy_error_log: 프록시 요청의 에러 로그 경로를 설정합니다.
- 기본값: logs/error.log
admin_access_log: Admin API 요청에 대한 액세스 로그 경로를 설정합니다.
- 기본값: logs/admin_access.log
admin_error_log: Admin API 요청의 에러 로그 경로를 설정합니다.
- 기본값: logs/error.log
status_access_log: Status API 요청에 대한 액세스 로그 경로를 설정합니다. 비활성화하려면 off로 설정할 수 있습니다.
- 기본값: off
status_error_log: Status API 요청의 에러 로그 경로를 설정합니다.
- 기본값: logs/status_error.log

2. Hybrid Mode Settings (하이브리드 모드 설정)

role: Kong을 하이브리드 모드에서 실행할 때, 노드가 control_plane(컨트롤 플레인) 또는 data_plane(데이터 플레인) 역할을 할 것인지 설정합니다.
- 가능한 값: traditional, control_plane, data_plane
- 기본값: traditional
cluster_mtls: 클러스터 노드 간의 mTLS 인증 방법을 설정합니다.
- 가능한 값: shared, pki, pki_check_cn
- 기본값: shared
cluster_cert: 클러스터 노드 간의 통신에 사용할 인증서 경로를 설정합니다.
- 기본값: none
cluster_cert_key: 클러스터 노드 간 통신에 사용할 인증서 키 경로를 설정합니다.
- 기본값: none
cluster_ca_cert: 데이터 플레인이 컨트롤 플레인의 인증서를 확인할 때 사용할 CA 인증서 경로를 설정합니다.
- 기본값: none
cluster_control_plane: 데이터 플레인 노드에서 설정하며, 컨트롤 플레인 노드의 주소를 host:port 형식으로 지정합니다.
- 기본값: none

3. Plugins Settings (플러그인 설정)

plugins: 로드할 플러그인의 리스트를 콤마로 구분하여 설정합니다. 기본적으로 bundled 플러그인이 로드됩니다.
- 가능한 값: bundled, custom-plugin-name 등
- 기본값: bundled
dedicated_config_processing: 데이터 플레인에 대해 특별한 작업자 프로세스를 활성화할지 여부를 설정합니다.
- 기본값: on
pluginserver_names: 플러그인 서버 프로세스의 이름을 콤마로 구분하여 설정합니다.
- 기본값: none
pluginserver_XXX_socket: 플러그인 서버에 사용할 Unix 소켓의 경로를 설정합니다.
- 기본값: <prefix>/<XXX>.socket

4. Network and NGINX Settings (네트워크 및 NGINX 설정)

proxy_listen: HTTP/HTTPS 트래픽을 수신할 프록시 서버의 주소와 포트를 설정합니다.
- 기본값: 0.0.0.0:8000 reuseport backlog=16384, 0.0.0.0:8443 http2 ssl reuseport backlog=16384
admin_listen: Admin API가 수신할 주소와 포트를 설정합니다.
- 기본값: 127.0.0.1:8001 reuseport backlog=16384, 127.0.0.1:8444 http2 ssl reuseport backlog=16384
status_listen: Status API가 수신할 주소와 포트를 설정합니다.
- 기본값: 127.0.0.1:8007 reuseport backlog=16384

5. Database Settings (데이터베이스 설정)

database: Kong이 사용할 데이터베이스를 설정합니다. postgres 또는 off 값 중 하나를 선택합니다.
- 기본값: postgres
pg_host: PostgreSQL 서버의 호스트 주소를 설정합니다.
- 기본값: 127.0.0.1
pg_port: PostgreSQL 서버의 포트를 설정합니다.
- 기본값: 5432
pg_user: PostgreSQL 사용자 이름을 설정합니다.
- 기본값: kong
pg_password: PostgreSQL 사용자 비밀번호를 설정합니다.
- 기본값: none
pg_database: PostgreSQL 데이터베이스 이름을 설정합니다.
- 기본값: kong
pg_ssl: PostgreSQL과의 TLS 연결을 설정할지 여부를 지정합니다.
- 기본값: off
pg_ssl_verify: PostgreSQL 연결 시 서버 인증서 검증을 활성화할지 여부를 설정합니다.
- 기본값: off

6. Cache and Performance Settings (캐시 및 성능 설정)

mem_cache_size: 공유 메모리 캐시 크기를 설정합니다.
- 기본값: 128m
db_cache_ttl: 데이터베이스 엔터티의 캐시 TTL을 설정합니다.
- 기본값: 0 (무기한)
db_cache_neg_ttl: 데이터베이스 미스의 캐시 TTL을 설정합니다.
- 기본값: none
db_resurrect_ttl: 데이터베이스가 응답하지 않을 때 캐시된 엔터티가 복원될 시간을 설정합니다.
- 기본값: 30초

7. DNS Resolver Settings (DNS 리졸버 설정)

dns_resolver: 사용할 DNS 서버 목록을 ip[:port] 형식으로 콤마로 구분하여 설정합니다.
- 기본값: none
dns_cache_size: DNS 레코드 캐시 크기를 설정합니다.
- 기본값: 10000
dns_error_ttl: DNS 에러 응답의 TTL을 설정합니다.
- 기본값: 1초

8. SSL/TLS Settings (SSL/TLS 설정)

ssl_cert: TLS가 활성화된 프록시 리슨 포트에 사용할 SSL 인증서를 설정합니다.
- 기본값: none
ssl_cert_key: SSL 인증서에 대응하는 개인 키를 설정합니다.
- 기본값: none
ssl_protocols: TLS 클라이언트 연결을 위한 지원되는 프로토콜을 설정합니다.
- 기본값: TLSv1.2 TLSv1.3
client_ssl: 클라이언트 측 TLS 인증서 전송 및 상호 TLS 인증을 활성화할지 여부를 설정합니다.
- 기본값: off

9. Tuning & Behavior Settings (성능 및 동작 설정)

worker_consistency: 워커가 동기식 또는 비동기식으로 상태를 업데이트할지 여부를 설정합니다.
- 가능한 값: strict, eventual
- 기본값: eventual
router_flavor: 요청 라우팅에 사용할 라우터 구현을 설정합니다.
- 가능한 값: traditional, expressions, traditional_compatible
- 기본값: traditional_compatible
lua_max_req_headers: 요청 헤더의 최대 수를 설정합니다.
- 기본값: 100

10. Vault Settings (Vault 설정)

vaults: 로드할 Vault의 리스트를 설정합니다. 기본적으로 번들된 Vault가 모두 로드됩니다.
- 기본값: bundled

11. Miscellaneous Settings (기타 설정)

anonymous_reports: 익명의 사용 데이터(예: 에러 스택 트레이스)를 전송하여 Kong의 개선을 돕는 설정입니다.
- 기본값: on
proxy_server: 프록시 서버를 명시적으로 구성할 때 사용할 서버의 URL을 설정합니다.
- 기본값: none

12. WebAssembly Settings (Wasm 설정)

wasm: WebAssembly 지원을 활성화할지 여부를 설정합니다.
- 기본값: off
wasm_filters: 사용할 Wasm 필터의 목록을 설정합니다.
- 기본값: bundled,user

이 설정 항목은 Kong Gateway를 구성할 때 사용되는 주요 옵션이며, 이를 적절히 설정함으로써 다양한 환경에서 Kong을 최적화하고 운영할 수 있습니다.

728x90

저작자표시 비영리 동일조건

pages.kr 날으는물고기 <º))))><

API Gateway(게이트웨이) Kong 아키텍처 설계 및 라우팅 환경 구성

API Gateway(게이트웨이) Kong 아키텍처 설계 및 라우팅 환경 구성

Kong을 사용한 API 게이트웨이 구축

참고 사항

단계 1: Kubernetes 클러스터 구성

단계 2: Kong Ingress Controller 배포

단계 3: KongProxy 리소스 생성

단계 4: API 서비스 등록

단계 5: 인증 및 권한 설정

단계 6: 애플리케이션 테스트

Helm을 사용한 Kong Ingress Controller 설치

서비스 URL 변경

1. Helm Charts 설치 준비

2. values.yaml 커스터마이징

3. Helm을 이용한 Kong API Gateway 설치

4. 설치된 리소스 확인

5. 주요 설정 및 이슈 해결

6. Kong 구성 방법

7. 추가 고려 사항

8. Kong 플러그인 구성

9. Helm Charts vs. Manifest 방식 배포

설치된 리소스 확인 명령어 및 각 항목에 대한 설명

각 항목에 대한 설명

1. General Settings (일반 설정)

2. Hybrid Mode Settings (하이브리드 모드 설정)

3. Plugins Settings (플러그인 설정)

4. Network and NGINX Settings (네트워크 및 NGINX 설정)

5. Database Settings (데이터베이스 설정)

6. Cache and Performance Settings (캐시 및 성능 설정)

7. DNS Resolver Settings (DNS 리졸버 설정)

8. SSL/TLS Settings (SSL/TLS 설정)

9. Tuning & Behavior Settings (성능 및 동작 설정)

10. Vault Settings (Vault 설정)

11. Miscellaneous Settings (기타 설정)

12. WebAssembly Settings (Wasm 설정)

댓글

티스토리툴바

API Gateway(게이트웨이) Kong 아키텍처 설계 및 라우팅 환경 구성

API Gateway(게이트웨이) Kong 아키텍처 설계 및 라우팅 환경 구성

Kong을 사용한 API 게이트웨이 구축

참고 사항

단계 1: Kubernetes 클러스터 구성

단계 2: Kong Ingress Controller 배포

단계 3: KongProxy 리소스 생성

단계 4: API 서비스 등록

단계 5: 인증 및 권한 설정

단계 6: 애플리케이션 테스트

Helm을 사용한 Kong Ingress Controller 설치

서비스 URL 변경

1. Helm Charts 설치 준비

2. values.yaml 커스터마이징

3. Helm을 이용한 Kong API Gateway 설치

4. 설치된 리소스 확인

5. 주요 설정 및 이슈 해결

6. Kong 구성 방법

7. 추가 고려 사항

8. Kong 플러그인 구성

9. Helm Charts vs. Manifest 방식 배포

설치된 리소스 확인 명령어 및 각 항목에 대한 설명

각 항목에 대한 설명

1. General Settings (일반 설정)

2. Hybrid Mode Settings (하이브리드 모드 설정)

3. Plugins Settings (플러그인 설정)

4. Network and NGINX Settings (네트워크 및 NGINX 설정)

5. Database Settings (데이터베이스 설정)

6. Cache and Performance Settings (캐시 및 성능 설정)

7. DNS Resolver Settings (DNS 리졸버 설정)

8. SSL/TLS Settings (SSL/TLS 설정)

9. Tuning & Behavior Settings (성능 및 동작 설정)

10. Vault Settings (Vault 설정)

11. Miscellaneous Settings (기타 설정)

12. WebAssembly Settings (Wasm 설정)

관련글

댓글

티스토리툴바