## Response Header (응답 헤더)의 변환  

Tyk를 사용하면 response가 client로 다시 프록시될 때 header 정보를 수정할 수 있습니다. 이는 제거해야 하는 민감한 를 잠재적으로 노출하는 업스트림 API가 있는 경우에 매우 유용할 수 있습니다.  

Response Transform Middleware(응답 변환 미들웨어)는 API Definition 또는 endpoint designer의 response 섹션에 설정이 적용된다는 점을 제외하고는 Request Transform Middleware(요청 변환 미들웨어)와 동일한 방식으로 작동합니다. 자세한 내용은 [Request Header Injection 문서](https://www.argopacific.io/blog/post/transform-traffic-request-headers)를 참조하세요.   

### 설정 방법 - API Definition
Tyk를 사용하면 *extended_paths.transform_response_headers* 필드에 다음을 추가하여 API 정의를 설정할 수 있습니다:  
![Response Header API Definition.png](https://storage.googleapis.com/argo-cms-strapi-upload/Response_Header_API_Definition_5098848bdc/Response_Header_API_Definition_5098848bdc.png) 

### 설정 방법 - Dashboard UI
Coming Soon 

### Response Middleware에 필요한 사항
Response Middleware(응답 미들웨어)를 등록해야 하므로 API Defintion를 편집할 때 마지막 단계가 필요합니다. 즉, 아래와 같이 프로세서에 Response Middleware를 추가하는 것입니다:  
![response middleware.png](https://storage.googleapis.com/argo-cms-strapi-upload/response_middleware_692c6de241/response_middleware_692c6de241.png)
 

Tyk Feature - Response Header 제어

## 방법1 - API 정의를 사용하여 요청 헤더 변환   

Tyk를 사용하면 헤더 정보가 프록시를 떠나기 전에, 업스트림 API로 전달되거나 응답이 클라이언트로 다시 프록시될 때 헤더 정보를 수정할 수 있습니다. 이는 단일 인증 키가 있는 업스트림 API가 있을 때, 이를 수정하거나 새로운 사용자를 지원하기 위해 투박한 인증 방법을 추가하지 않고 해당 API에 대한 다중 사용자 액세스를 추가하려는 경우에 매우 유용할 수 있습니다.  

  
**[시나리오 예시]**    

액세스를 허용하기 위해 x-widgets-secret 헤더를 사용하는 WidgetsAPI라는 API가 있습니다. 이것은 팀에서 사용하는 내부 API이지만 고객에게 공개하고 액세스 비용을 청구하려고 합니다.  

이 때, 여러분은;
1. API를 수정하고 전체 사용자, 키 및 액세스 관리 시스템을 추가하거나   
2. Tyk를 사용하여 이 헤더를 삽입하도록 만들 수 있습니다.  

**API 정의 객체 (API definition object) 업데이트:** Tyk를 사용하여 *extended_paths.transform_headers* 필드에 다음을 추가하여 API 정의를 설정할 수 있습니다.    

![extended_paths.transform_headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/extended_paths_transform_headers_7f90c83950/extended_paths_transform_headers_7f90c83950.png)  

이제, 이 API 및 버전으로 설정된 액세스 정의 규칙으로 생성한 Tyk 키에 기존 API에 새로운 코드나 기능을 추가할 필요 없이 할당량(quotas), 조절(throttling)및 액세스 검사를 적용할 수 있습니다.    

    
## 방법2 - 대시보드를 사용하여 요청 헤더 변환  

대시보드의 GUI를 사용하여 요청에 새 헤더를 삽입하려면 API 정의의 엔드포인트 디자이너 섹션에서 편집해야 합니다.   

**1단계: 엔드포인트 추가하고 헤더 수정 플러그인 선택합니다**    
또한, 매칭시킬 메소드와 요청 패턴을 설정해야만 합니다. 이러한 패턴은 중괄호, { }로 묶인 문자열 형식의 와일드카드를 포함할 수 있습니다. 이러한 와일드카드는 사람이 읽을 수 있도록 하고 변수명으로 변환하지 않습니다. 내부에서 와일드카드는 (.*)의 "모든 항목 일치" 정규식으로 변환됩니다.   
![API Designer_modifiying headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/API_Designer_modifiying_headers_f384719440/API_Designer_modifiying_headers_f384719440.png)

**2단계: “Request" 탭 선택**   -  이렇게 하면 인바운드 요청에만 적용됩니다.  
![Modify headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/Modify_headers_701a565199/Modify_headers_701a565199.png)

**3단계: 헤더 수정 설정**  
제공된 필드를 사용하여 삭제 및 삽입할 헤더 설정을 선택합니다. 추가하는 모든 헤더는 카멜방식의 대문자로 표시됩니다. 즉. UI 또는 API 정의에 x-request-id를 추가하면 응답에서 호출자는 X-Request-Id를 받게 됩니다.  
>중요: Add 버튼을 클릭하여 목록에 추가되었는지 확인하십시오.   

![setup header modify.png](https://storage.googleapis.com/argo-cms-strapi-upload/setup_header_modify_7ea34a8d81/setup_header_modify_7ea34a8d81.png)  

**4단계: API 저장** - API가 저장되면 요청 경로 및 메서드가 패턴과 일치하면 엔드포인트에 도달하는 요청이 관련 수정됩니다.  


## 방법3 - 전역적으로 요청 헤더 수정  
  
**전역적으로 헤더 주입 및 제거하기**  
어떤 경우에는 모든 아웃바운드 요청에 보안 헤더를 추가하고 싶을 수 있습니다(예: 트래픽이 게이트웨이에서 오는지 확인). 그렇게 하려면 API 정의의 버전 블록에 다음을 추가하십시오.   
![injecting and removing header globally.png](https://storage.googleapis.com/argo-cms-strapi-upload/injecting_and_removing_header_globally_bd0d3e1d4a/injecting_and_removing_header_globally_bd0d3e1d4a.png)
  <br></br>

## 방법4 - 대시보드를 통해 전역 인젝션 추가하기  
  
**Global Version Setting** 메뉴를 선택하여 API 엔드포인트 디자이너를 통해 대시보드에서 이를 달성할 수도 있습니다.
![adding global injection.png](https://storage.googleapis.com/argo-cms-strapi-upload/adding_global_injection_f6851e03d5/adding_global_injection_f6851e03d5.png)


## 방법5 - 헤더에 사용자 지정 동적 데이터 삽입  

사용자 세션 객체 내에서 전달되는 정보를 헤더 공간에도 주입할 수 있습니다. 각 토큰 또는 키에는 ‘meta_data’ 필드가 포함된 연결된 세션 개체가 있습니다. 이는 동적 미들웨어 및 기타 구성 요소가 인바운드 요청의 ID 정보를 노출하지 않고 지능적으로 작동할 수 있도록 하는 key/value 맵입니다.  


헤더 변환에서 이 데이터를 사용하려면 특수 $tyk_meta 네임스페이스에 액세스하기만 하면 됩니다. 다음은 작업 예입니다.  


세션 개체에 다음 메타데이터를 포함했다고 가정해 보겠습니다:  

![injecting custom dynamic data into header.png](https://storage.googleapis.com/argo-cms-strapi-upload/injecting_custom_dynamic_data_into_header_996765c884/injecting_custom_dynamic_data_into_header_996765c884.png)
  
헤더 변환에서 이것을 사용하려면 API 정의 경로는 다음과 같습니다.  
![transform headers.png](https://storage.googleapis.com/argo-cms-strapi-upload/transform_headers_c7093ddf02/transform_headers_c7093ddf02.png)
    
  
## 방법6 - 대시보드의 메타 데이터  

변수 이름(*$tyk_meta*)은 대시보드 필드에서도 사용할 수 있으며 동일한 방식으로 작동합니다.  
      
## 방법7 - 헤더에 컨텍스트 변수 인젝팅  

버전 2.2부터 Tyk에서는 *$tyk_context. namespace*를 사용하여 컨텍스트 변수를 헤더에 주입할 수 있습니다. 네임스페이스. 자세한 내용은 [컨텍스트 변수](https://tyk.io/docs/context-variables/)를 참조하십시오.   

**Global Header 섹션 예시**  
![example global header section.png](https://storage.googleapis.com/argo-cms-strapi-upload/example_global_header_section_e6a896bd36/example_global_header_section_e6a896bd36.png)




Tyk Feature - Request Headers 제어

medium_클러스터 내부구조.png

small_클러스터 내부구조.png

thumbnail_클러스터 내부구조.png

클러스터 내부구조.png

![클러스터 내부구조.png](https://storage.googleapis.com/argo-cms-strapi-upload/_b5514ea6af/_b5514ea6af.png)   

다이어그램에 표시된 것처럼 마스터 노드는 컨트롤 플래인으로서, 클러스터 관리를 담당합니다. 클러스터의 모든 활동을 조정하고 노드와 통신하여 Kubernetes 및 애플리케이션이 계속 실행되도록 합니다.   
노드는 Kubernetes 클러스터에서 작업자 머신 역할을 합니다. 주목해야 할 한 가지 중요한 점은 이 노드가 물리적 컴퓨터 또는 가상 머신이 될 수 있다는 것입니다.    

**노드로 역할하기 위해서는 다음과 같은 요구 사항이 있습니다:**  
- 각 노드에는 실행 중인 Kubelet이 반드시 있어야하고,   
- Docker와 같은 컨테이너 도구와   
- 실행 중인 kube-proxy 프로세스    
- 그리고, Supervisord 처럼 구성 요소를 다시 시작할 수 있는 프로세스가 있어야 합니다.   

>프로덕션의 설정에서는 Kubernetes를 사용하는 경우 최소한 노드 클러스터가 3개 이상인 것이 좋다는 것을 유의하세요.  

실습을 위해 로컬 머신에 설치하여 테스트하려면 minikube가 간편한 방법이지만, Windows 프로페셔날에서만 가능합니다.      
홈 버전의 윈도우 사용자는 [인터렉티브 튜토리얼](https://kubernetes.io/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive/)을 사용하세요.  
미니큐브는 로컬 박스에 가상 머신을 생성하고 하나의 단일 노드가 포함된 간단한 클러스터를 배포하는 경량의 Kubernetes 구현체입니다.  

![Pods의 구성요소.png](https://storage.googleapis.com/argo-cms-strapi-upload/Pods_f29bde9836/Pods_f29bde9836.png)

어떤 시나리오에서는 포드에서 여러 도커 컨테이너를 실행할 수 있지만, 포드는 단일 배포 단위로서 밀접하게 연결되고 리소스를 공유하는 Kubernetes의 단일 애플리케이션 인스턴스를 나타냅니다.   
포드는 일시적이고 일회적인 개체로 설계되었습니다. 그러므로 프로덕션 애플리케이션에서 단독으로 Pod를 생성하지 마십시오. 그런 생성은 기본 컨테이너가 실제로 작동하는지 테스트해야 할 때만 수행하는 것이 바람직합니다.   

>프로들은 Pod를 직접 사용하지 말고. 대신에 배포할 때 처럼 컨트롤러를 사용하라고 조언합니다.  

게다가, 포드는 자가 치유되지 않습니다.   
어떤 이유로 Pod가 죽으면 리스케줄 되지 않습니다. 또, 리소스가 부족하여 노드에서 포드가 종료되면 다른 건강한 노드에서 다시 시작되지 않습니다.   
컨트롤러라고 하는 Pod를 관리하고 안정성을 추가하는 더 높은 수준의 구성이 있습니다.   

**수명 주기를 통해 Pod는 다음과 같은 상태를 갖습니다:**  
- Pending  
- Running   
- Succeeded  
- Failed  
- Unknown  
- 그외, CrashLoopBackOff     

파드의 *status* 필드는 *phase* 필드를 포함하는 *PodStatus* 오브젝트로 정의됩니다.  
>파드의 phase (단계)는 파드가 라이프사이클 중 어느 단계에 해당하는지 표현하는 간단한 고수준의 요약으로서, Phase는 컨테이너나 파드의 관측 정보에 대한 포괄적인 롤업이나, 포괄적인 상태 머신을 표현하도록 의도되지는 않았습니다.  파드 phase 값에서 숫자와 의미는 엄격하게 지켜집니다. 공식문서 내용 이외에는, 파드와 파드에 주어진 phase 값에 대해서 어떤 사항도 가정되어서는 안됩니다.  

파드는 정의된 라이프사이클을 따릅니다:  Pending 단계 (Phase)에서 시작해서, 기본 컨테이너 중 적어도 하나 이상이 OK로 시작하면 Running 단계를 통과하고, 그런 다음 파드의 컨테이너가 실패로 종료되었는지 여부에 따라 Succeeded 또는 Failed 단계로 이동합니다.  

phase에 적용되는 값은 아래와 같습니다:   

**Pending**은 Kubernetes 시스템에서 Pod를 수락했지만 컨테이너가 아직 생성되지 않았음을 의미합니다. 즉, 파드가 쿠버네티스 클러스터에서 승인되었지만, 하나 이상의 컨테이너가 설정되지 않았고 실행할 준비가 되지 않았습니다. 여기에는 파드가 스케줄되기 이전까지의 시간 뿐만 아니라 네트워크를 통한 컨테이너 이미지 다운로드 시간도 포함됩니다.

**Running**은 노드에서 포드가 예약되고 모든 컨테이너가 생성되고 적어도 하나의 컨테이너가 실행 중 상태인 실행 중입니다. 즉, 파드가 노드에 바인딩되었고, 모든 컨테이너가 생성되었으며, 적어도 하나의 컨테이너가 아직 실행 중이거나, 시작 또는 재시작 중에 있음을 의미합니다.

**Succeeded**는 Pod의 모든 컨테이너가 종료 상태가 0으로 종료되었음을 의미하고, 이는 성공적인 실행을 나타내며 다시 시작되지 않습니다. 

**Failed**는 실패 상태, 즉 파드의 모든 컨테이너가 종료되었고 적어도 하나 이상의 컨테이너가 실패하여 0이 아닌 종료 상태를 반환했습니다. 다시말해, 해당 컨테이너는 non-zero 상태로 빠져나왔거나(exited) 시스템에 의해서 종료(terminated)되었음을 의미합니다.

**Unknown**은 알 수 없음, 즉 어떤 이유에 의해서 파드의 상태를 얻을 수 없는 경우입니다. 이 단계는 일반적으로 파드가 실행되어야 하는 노드와의 통신 오류로 인해 발생합니다.

그외에, **CrashLoopBackOff**이 있는데, 이는 어떤 이유로 컨테이너 시작에 실패하면 Kubernetes가 계속해서 Pod를 다시 시작하려고 시도하는 경우입니다.







K8s 기본 빌딩 블럭

large_K8s 클러스터 아키텍처.png

medium_K8s 클러스터 아키텍처.png

small_K8s 클러스터 아키텍처.png

thumbnail_K8s 클러스터 아키텍처.png

K8s 클러스터 아키텍처.png

## Kubernetes Cluster Architecture

>구름은 언제나 하늘에 떠 있었지만, 이제 클라우드 없는 세상을 상상하기 어렵게 됐습니다. 바람은 구름을 움직이고, 쿠버네티스 (Kubernetes, K8s)는 클라우드를 움직입니다.  
>   
>**Tyk APIM은 K8s 플랫폼과 유연하게 연동됩니다.**  
 
**K8s 없이는 클라우드를 조율할 수 없으니 기본 중의 기본; K8s 클러스터의 아키텍처와 각 컴포넌트들의 핵심 기능을 알아봅니다.**
     
   
   

  

![K8s 클러스터 아키텍처.png](https://storage.googleapis.com/argo-cms-strapi-upload/K8s_87ec1a5ae7/K8s_87ec1a5ae7.png)

**마스터 노드는 Kubernetes 클러스터의 전반적인 관리를 담당하며; 
통신, 스케줄링 및 컨트롤러를 처리하는 세 가지 컴포넌트: Kube API 서버, 스케줄러, 그리고 컨트롤러 관리자로 구성됩니다.**

**Kube API 서버**를 사용하면, 이름에서 알 수 있듯이, Kubernetes API와 상호 작용할 수 있습니다. 이 Kube API 서버는 Kubernetes 제어 평면의 프런트엔드입니다. 

**스케줄러**는 생성된 Pods를 감시하며 아직 Node 설계가 되지않은 Pod를 생성하고 특정 Node에서 실행되도록 Pod를 설계합니다. 

**컨트롤러 관리자**는 컨트롤러를 실행합니다. 이들은 클러스터에서 작업을 실행하는 백그라운드 스레드입니다. 컨트롤러에는 실제로 다양한 역할이 있지만 모두 단일 바이너리로 컴파일됩니다. 이들 역할에는 worker의 상태를 담당하는 **노드 컨트롤러**, 복제된 컨트롤러에 대해 올바른 수의 Pods를 유지 관리하는 책임을 지는 **리플리케이션 컨트롤러**, 서비스와 포드를 함께 연결하는 **엔드포인트 컨트롤러**가 포함됩니다. 
그리고 액세스 관리를 처리하는 **서비스 계정 및 토큰 컨트롤러**. 
마지막으로, 저장된 간단한 분산 키 값인 CD가 있습니다. 
Kubernetes는 etcd를 데이터베이스로 사용하고 모든 클러스터 데이터를 여기에 저장합니다. 저장될 수 있는 정보 중 일부는 작업 일정 정보, Pod 세부 정보, 단계 정보 (stage info) 등입니다. - Pod Lifecycle
여기까지가 마스터 노드입니다. 

여러분은 Kubernetes용 커맨드라인 인터페이스인 Kubectl 애플리케이션을 사용하여 마스터 노드와 상호 작용하게 됩니다. 
Kubectl에는 Kubeconfig라는 설정 파일이 있습니다. 이 파일에는 서버 정보와 API 서버에 접근하기 위한 인증 정보가 있습니다. 하지만, 작업자 노드 없이는 아무것도 할 수 없습니다. 이러한 작업자 노드는 여러분의 애플리케이션이 작동하는 노드입니다. 작업자 노드는 마스터 노드와 다시 통신합니다. 작업자 노드와의 통신은 Kubelet 프로세스에 의해 처리됩니다. 작업자 노드는 Pod가 노드에 맞게 설계되었는지 확인하기 위해 API 서버와 통신하는 에이전트입니다. 

작업자 노드는 컨테이너 엔진을 통해 Pod 컨테이너를 실행합니다. Pod 볼륨 및 시크릿을 탑재하고 실행합니다. 그리고 마지막으로 노드에 탑재된 포드의 상태를 인지하고 Master에게 다시 응답합니다. Kubelet이 작업자 노드에서 올바르게 작동하지 않으면 문제가 발생한다고 여기는 것이 안전합니다. 
Kubernetes는 컨테이너 오케스트레이터이므로 작업자 노드에서 실행 중인 컨테이너 기본 플랫폼이 있어야 합니다. 그래서 이 지점에서 Docker가 도입되어서 Kubelet과 함께 작동하여 노드에서 컨테이너를 실행합니다. 

다음으로 이야기할 프로세스는 Kube-proxy입니다. 이 프로세스는 단일 작업자 노드에서 서비스에 대한 네트워크 프록시이면서 로드 밸런서입니다. TCP 및 UDP 패킷에 대한 네트워크 라우팅을 처리하고 연결 전달 (connection forwarding)을 수행합니다.  
Docker Daemon이 있으면 컨테이너를 실행할 수 있습니다. 애플리케이션의 컨테이너들은 Pod에서 단단하게 결합됩니다. 공식문서에 정의된 것처럼, Pod는 Kubernetes에서 배포 (deployment)로 예약할 수 있는 가장 작은 단위입니다. 이 컨테이너 그룹은 무엇보다도 스토리지, Linux 네임 스페이스, IP 주소를 공유합니다. 그들은 같은 위치에 함께 있으며 항상 같이 스케줄된 리소스를 공유합니다. 포드가 배포되고 실행되면 Kubelet 프로세스는 포드와 통신하여 상태 및 상태를 확인하고 Kube-proxy는 통신을 원할 수 있는 다른 리소스도부터 포드로 모든 패킷을 라우팅합니다. 작업자 노드는 로드 밸런서를 통해 인터넷에 노출될 수 있습니다. 그리고 노드로 들어오는 트래픽도 Kube-proxy 의해 처리되며, 이는 최종 사용자가 Kubernetes 애플리케이션과 대화를 종료하는 방식입니다. 





K8s 클러스터 아키텍처



> Tyk 게이트웨이가가 요청을 같은 API 정의와 리스닝 경로를 사용하는 여러 개의 다른 백엔드 엔드포인트로 포워딩하는 것이 가능한가요?  


## Batch 프로세싱 예제   

**비즈니스 시나리오에서 하나의 요청이 어떤 집계된 형태의 데이터를 보여 주어야 하는 경우가 종종 있습니다. 이런 경우에는 여러 개의 다른 백엔드 엔드포인트를 호출하여 요청의 결과를 집계하여 리턴하는데, Tyk에서는 가상 엔드포인트 (virtual endpoint) 기능과 batch processing을 사용하여 원하는 결과를 얻을 수 있습니다.**    

아래의 예제는 batch 프로세싱 API를 사용하여 구현하는 방법을 보여 줍니다: 

function batchTest(request, session, config) {  
  
  // 응답 오브젝트 설정   
  var response = {  
    Body: "",  
    Headers: {  
      "test": "virtual-header-1",  
      "test-2": "virtual-header-2",  
      "content-type": "application/json"  
    },  
    Code: 200  
  }  
    
  // Batch 요청  
  var batch = {  
    "requests": [  
      {  
        "method": "GET",  
        "headers": {  
          "x-tyk-test": "1",  
          "x-tyk-version": "1.2",  
          "authorization": "1dbc83b9c431649d7698faa9797e2900f"  
        },  
        "body": "",  
        "relative_url": "http://httpbin.org/get"  
      },  
      {  
        "method": "GET",  
        "headers": {},  
        "body": "",  
        "relative_url": "http://httpbin.org/user-agent"  
      }  
    ],  
    "suppress_parallel_execution": false  
  }  
    
  log("[Virtual Test] Making Upstream Batch Request")  
  var newBody = TykBatchRequest(JSON.stringify(batch))  
    
  // 요청은 응답으로서 바디에 JSON을 가지고 올 것을 알고 있으니, 파싱합니다 
  var asJS = JSON.parse(newBody)  
  for (var i in asJS) {  
    asJS[i].body = JSON.parse(asJS[i].body)  
  }  
    
  // 이제 Tyk가 응답객체에 스트링 객체를 임베드하여 보낼 차례입니다.   
  response.Body = JSON.stringify(asJS)  
    
  return TykJsResponse(response, session.meta_data)  
    
}  
log("Batch Test initialised")  
                


Leading Tyk Partner in South Korea

Latest Posts

Tyk Feature - Response Header 제어

Tyk Feature - Request Headers 제어

K8s 기본 빌딩 블럭

K8s 클러스터 아키텍처

Tyk Feature - Request Forwarding 하기

Tyk API Gateway
Licenses

Launch

Flex

Multi-Team

Global Multi-Team

Leading Tyk Partner in South Korea

Latest Posts

Tyk Feature - Response Header 제어

Tyk Feature - Request Headers 제어

K8s 기본 빌딩 블럭

K8s 클러스터 아키텍처

Tyk Feature - Request Forwarding 하기

Tyk API Gateway Licenses

Launch

Flex

Multi-Team

Global Multi-Team

Tyk API Gateway
Licenses