머신 클러스터 전반에 걸쳐 컨테이너에서 마이크로서비스 애플리케이션을 대규모로 실행하고 관리하는 것은 어려운 작업입니다.
Kubernetes는 컨테이너 오케스트레이션을 위한 강력한 솔루션을 제공하여 이러한 과제를 해결하는 데 도움이 됩니다.
여기에는 장애 허용, 자동 확장, 롤링 업데이트, 스토리지, 서비스 검색 및 로드 밸런싱과 같은 여러 가지 중요한 기능이 포함되어 있습니다.
이 블로그 게시물에서는 HTTP 트래픽을 위한 내장 Kubernetes 로드 밸런싱 프레임워크인 Ingress 와 함께
NGINX Open Source 또는 NGINX Plus를 사용하는 방법을 설명합니다.
Ingress를 사용하면 Kubernetes 클러스터의 서비스로의 외부 트래픽 라우팅을 제어하는 규칙을 구성할 수 있습니다.
Kubernetes와 로드 밸런서를 통합하기 위해 클러스터에 배포하는
소프트웨어인 Ingress 컨트롤러를 제공하는 모든 로드 밸런서를 선택할 수 있습니다 .
여기서는 Ingress와 NGINX Plus 및 NGINX에 대해 제공하는 Ingress 컨트롤러를 사용하여
마이크로서비스 애플리케이션에 대한 로드 밸런싱을 구성하는 방법을 보여드립니다.
[편집자 - 이전에 NGINX 및 NGINX Plus에 대해 분리되어 있던 컨트롤러가 두 가지 모두에 대한 단일 Ingress 컨트롤러 로 병합되었습니다 .]
이 블로그 게시물에서는 Ingress를 사용한 Kubernetes의 HTTP 로드 밸런싱만 살펴봅니다.
다른 로드 밸런싱 옵션에 대해 자세히 알아보려면 블로그에서 NGINX Plus를 사용한 Kubernetes 서비스 로드 밸런싱을 참조하세요.
참고: 이 블로그 게시물에서 논의된 절차에 대한 전체 지침은 GitHub 저장소 에서 제공됩니다 .
이 게시물은 모든 필수 단계를 다루지는 않지만 대신 해당 지침에 대한 링크를 제공합니다.
샘플 애플리케이션을 배포하고 이에 대한 부하 분산을 구성하기 전에
부하 분산 장치를 선택하고 해당 Ingress 컨트롤러를 배포해야 합니다.
Ingress 컨트롤러는 특정 로드 밸런서를 Kubernetes와 통합하는 소프트웨어입니다.
저희는 NGINX Open Source와 NGINX Plus를 위한 Ingress 컨트롤러를 개발했으며, 이제 GitHub 저장소 에서 사용할 수 있습니다 .
타사에서 만든 다른 구현도 있습니다. 자세한 내용은 Kubernetes용 GitHub 저장소의 Ingress 컨트롤러 페이지를 방문하세요.
클러스터에 NGINX 또는 NGINX Plus Ingress 컨트롤러를 배포하는 방법에 대한 전체 지침은 GitHub 저장소를 참조하세요 .
샘플 애플리케이션은 각각 별도로 배포되는 여러 서비스로 구성된 전형적인 마이크로서비스 웹 애플리케이션입니다.
cafe 라는 애플리케이션을 사용하면 티 서비스를 통해 차를 주문하거나 커피 서비스 를 통해 커피를 주문할 수 있습니다 .
HTTP 요청의 URI로 음료 선호도를 표시합니다. /tea 로 끝나는 URI는 차를 제공하고 /coffee 로 끝나는 URI는 커피를 제공합니다.
애플리케이션에 대한 연결은 SSL/TLS로 보안해야 합니다.
아래 다이어그램은 NGINX Plus 로드 밸런서가 클라이언트 요청을 적절한 서비스로 라우팅하고 SSL/TLS를 사용하여
클라이언트 연결을 보호하는 중요한 역할을 수행하는 애플리케이션을 개념적으로 보여줍니다.
클러스터에 애플리케이션을 배포하려면 GitHub 저장소 의 지침을 따르세요 .
카페 앱 에서는 로드 밸런서가 두 가지 기능을 제공해야 합니다.
Ingress로 로드 밸런싱을 구성하려면 Ingress 리소스 에서 규칙을 정의합니다 .
규칙은 클러스터의 서비스로 외부 트래픽을 라우팅하는 방법을 지정합니다.
리소스에서 여러 가상 서버를 정의할 수 있으며, 각각 다른 도메인 이름에 대해 정의할 수 있습니다.
가상 서버는 일반적으로 클러스터에 배포된 단일 마이크로서비스 애플리케이션에 해당합니다.
각 서버에 대해 다음을 수행할 수 있습니다.
Ingress에 대한 더 자세한 설명과 예제는 Ingress 문서 페이지 에서 확인할 수 있습니다 .
cafe 앱 의 Ingress 리소스( cafe‑ingress.yaml )는 다음과 같습니다 .
줄별로 살펴보면 다음과 같습니다.
6-9행에서 SSL/TLS 종료를 설정합니다.
13-21행에서 두 개의 경로 기반 규칙을 정의합니다.
클러스터에 Ingress 및 Secret 리소스를 배포하는 방법에 대한 전체 지침은 GitHub 저장소를 참조하세요 .
NGINX Plus Ingress Controller와 함께 제공되는 샘플 애플리케이션과 리소스를 배포하면
Kubernetes 환경에서 로드 밸런싱과 애플리케이션 동작을 테스트할 수 있습니다.
예를 들어, 브라우저에서 /tea URI로 요청을 보내면 티 서비스에서 생성된 페이지가 표시됩니다.
이 샘플 애플리케이션은 실제로 음료를 제공하지 않지만, 요청 세부 정보와 컨테이너에 대한 정보를 포함한 페이지를 반환합니다.
여기에는 컨테이너의 호스트 이름과 IP 주소, 요청 URI, 클라이언트 IP 주소 등이 포함되며,
페이지를 새로고침할 때마다 다른 컨테이너가 응답을 제공해 로드 밸런싱의 동작을 확인할 수 있습니다.
또한, NGINX Plus의 라이브 활동 모니터링 대시보드를 통해 각 애플리케이션 컨테이너와
NGINX Plus의 실시간 로드 밸런싱 지표를 확인할 수 있습니다.
이러한 기능은 Kubernetes와 NGINX Plus Ingress Controller 설정을 테스트하거나 디버깅하는 데 유용하며,
마이크로서비스 아키텍처와 NGINX Plus의 고급 기능을 이해하는 데 도움을 줍니다.
Ingress는 기본 HTTP 로드 밸런싱 기능을 제공합니다.
그러나 애플리케이션의 로드 밸런싱 요구 사항이 더 복잡하여 Ingress에서 지원하지 않는 경우가 많습니다.
이러한 요구 사항 중 일부를 해결하기 위해 Ingress 컨트롤러에 여러 확장 기능을 추가했습니다.
이렇게 하면 Kubernetes 리소스를 사용하여 로드 밸런싱을 구성하는 이점을
계속 활용할 수 있지만(로드 밸런서를 직접 구성하는 것과는 대조적으로) 고급 로드 밸런싱 기능을 활용할 수 있습니다.
사용 가능한 확장 기능의 전체 목록은 GitHub 저장소에서 확인하세요 .
또한, Config Maps 리소스 또는 Annotations를 통해 Kubernetes 리소스를 통해
NGINX 구성을 사용자 정의하는proxy_connect_timeout 메커니즘을 제공합니다.
예를 들어, 또는 proxy_read_timeout지시문의 값을 사용자 정의할 수 있습니다.
로드 밸런싱 요구 사항이 Ingress와 확장 프로그램에서 지원하는 범위를 넘어서는 경우
Ingress 컨트롤러를 사용하지 않는 NGINX Plus 배포 및 구성에 대한 다른 접근 방식을 제안합니다.
자세한 내용은 블로그에서 NGINX Plus를 사용한 Kubernetes 서비스 로드 밸런싱을 읽어보세요.
NGINX Plus를 사용하면 Ingress 컨트롤러는 NGINX를 통해 얻을 수 있는 이점 외에도 다음과 같은 이점을 제공합니다.
매우 동적인 환경에서의 안정성 – Ingress를 통해 노출되는 서비스 포드 수가 변경될 때마다Kubernetes는 Ingress를 사용하여 클러스터의 서비스로 외부 트래픽을 라우팅하기 위한 내장 HTTP 로드 밸런싱을 제공합니다.
NGINX 및 NGINX Plus는 Kubernetes 로드 밸런싱과 통합되어 Ingress 기능을 완벽하게 지원하고
확장된 로드 밸런싱 요구 사항을 지원하는 확장 기능도 제공합니다.
NGINX Plus와 Ingress 컨트롤러 데모버전을 사용해 보려면
전문가에게 상담받기를 클릭해주세요.
2016년 9월, 오스틴에서 열린 NGINX.conf 2016에서 저는 Docker Swarm 클러스터에서
NGINX와 NGINX Plus를 활용하는 방법에 대해 발표했습니다.
이 글에서는 Docker 1.12에서 새롭게 추가된 기능을 포함해
Docker Swarm의 로드 밸런싱 기능을 NGINX와 NGINX Plus로 구현하는 방법을 설명하고자 합니다.
발표에서 사용했던 모든 파일은 GitHub에서 제공되며, 직접 실험해볼 수 있습니다.
개요
2016년 7월 말 출시된 Docker 1.12는 Docker Engine과 Swarm을 통합하여 몇 가지 새로운 오케스트레이션 기능을 도입함으로써
Kubernetes와 유사한 플랫폼을 제공합니다.
Docker 1.12의 Swarm 모드는 여러 Docker 호스트를 하나의 Swarm으로 통합하여 내결함성, 자동 복구 기능, 분산 아키텍처를 지원합니다.
이 플랫폼은 Swarm 클러스터 설정을 단순화하고, 모든 노드에 키 기반 보호와 노드 간 통신의 TLS 암호화를 기본으로 제공합니다.
Docker API는 이제 컨테이너 세트를 ‘서비스’로 인식하게 되어, 서비스를 생성 및 확장하고,
롤링 업데이트와 상태 검사를 수행하는 등 다양한 기능을 제공합니다.
DNS 기반 서비스 검색과 로드 밸런싱이 기본으로 제공되며, 클러스터 전체에 걸친 오버레이 네트워크도 설정할 수 있습니다.
Docker Swarm 로드 밸런싱 토폴로지
이 데모에서는 관리자 노드와 두 개의 작업자 노드로 구성된 Swarm 클러스터를 사용했습니다.
관리자 노드는 Swarm 명령어가 실행되는 중앙 노드로서,
Swarm은 모든 노드에서 스케줄링, DNS 서비스 검색, 확장 및 컨테이너 로드 밸런싱을 담당합니다.
그림 1: Docker Swarm 클러스터 토폴로지
Docker Swarm 클러스터는 관리자 노드와 두 개의 작업자 노드로 구성되며,
모든 노드는 내부 오버레이 네트워크를 통해 연결되어 있습니다.
클러스터 내 컨테이너 간에는 이 네트워크를 통해 프라이빗 통신이 이루어지며,
Swarm 로드 밸런서를 사용하여 외부와의 연결도 지원합니다.
그림 2. Docker Swarm 클러스터의 내부 및 외부 네트워크 연결
Docker Swarm 클러스터의 내부 오버레이 네트워크는 외부 및 내부 요청 모두를 처리합니다.
Swarm 로드 밸런서는 모든 노드에서 실행되어 클러스터 내 모든 컨테이너에 대해 로드 밸런싱을 수행합니다.
Swarm 기본 로드 밸런서가 배포된 경우, 인바운드 클라이언트 요청과 서비스 간 내부 요청을
각각 그림 3의 녹색 및 빨간색 화살표로 표현했습니다.
그림 3. NGINX 또는 NGINX Plus가 없는 Swarm 클러스터에서 클라이언트 및 서비스 간 요청의 로드 밸런싱
하지만 Swarm에 자체 로드 밸런서가 포함되어 있음에도, 다른 로드 밸런서를 추가해야 하는 이유가 있습니다.
Swarm의 기본 로드 밸런서는 Layer 4(TCP) 수준에서만 로드 밸런싱을 제공하기 때문에,
다음과 같은 고급 기능을 원하는 애플리케이션에는 제한이 있습니다:
또한 이미 로드 밸런서를 사용해 본 경험이 있을 수 있으며,
Swarm과 함께 사용하면 이미 사용 중인 툴과 지식을 활용할 수 있습니다.
NGINX 오픈 소스 및 NGINX Plus의 역할
NGINX 오픈 소스와 NGINX Plus는 Swarm 기본 로드 밸런서로는 지원되지 않는 애플리케이션에 필수적인 다양한 기능을 제공합니다.
NGINX 오픈 소스 사용
NGINX 오픈 소스는 SSL/TLS 종료 외에도 다음과 같은 기능을 지원합니다:
NGINX 오픈 소스를 Swarm 클러스터에서 사용하는 가장 간단한 방법은
NGINX를 하나 이상의 컨테이너로 서비스 형태로 배포하는 것입니다.
필요한 포트는 클러스터 외부에 노출되며,
Swarm 로드 밸런서는 이 포트로 들어오는 요청을 NGINX 컨테이너에 분배합니다.
그림 4. Swarm 로드 밸런서는 NGINX 서비스에 대한 요청을 인스턴스 간에 분산합니다.
이 예제에서는 NGINX가 SSL/TLS 종료 서비스를 제공하도록 구성되어 있습니다.
SSL/TLS 종료란 클라이언트와의 통신에서 SSL/TLS 암호화를 해제하여,
클러스터 내부 통신에서는 암호화된 연결을 요구하지 않는 방식입니다.
이를 설명하기 위해 클러스터에 백엔드 서비스 A를 배포하고
세 개의 컨테이너(그림 5에 표시된 대로 한 노드에 두 개의 인스턴스, 다른 노드에 하나의 인스턴스)로 확장합니다.
Swarm은 클러스터 내부에서 사용할 가상 IP 주소(VIP)를 서비스 A에 할당합니다.
컨테이너의 개별 IP 주소를 나열하는 대신 서비스 A의 업스트림 그룹의 NGINX 구성에서 이 VIP를 사용합니다.
이렇게 하면 NGINX 구성을 변경하지 않고도 서비스 A를 확장할 수 있습니다.
그림 5. NGINX는 외부 클라이언트 요청에 대해 SSL/TLS 종료를 제공합니다.
그림 5에서 보듯이, 클라이언트가 첫 번째 Swarm 노드에 서비스 A에 대한 요청을 하면,
해당 노드의 Swarm 로드 밸런서는 요청을 NGINX로 라우팅합니다. NGINX는 요청을 처리하는데,
이 예에서는 SSL/TLS 복호화를 수행하고 서비스 A의 VIP로 라우팅합니다.
Swarm 로드 밸런서는 (이제 암호화되지 않은) 요청을
모든 Swarm 노드의 서비스 A 컨테이너 중 하나로 라우팅합니다.
이런 구조는 클러스터 외부에서의 SSL/TLS 통신은 유지하면서,
내부에서는 비암호화된 상태로 빠르게 요청을 전달할 수 있어,
보안성과 성능을 모두 고려한 효율적인 아키텍처를 제공합니다.
NGINX는 로드 밸런싱된 요청을 백엔드 컨테이너로 직접 보낼 수 있으며,
또한 내부 서비스 간 요청을 처리할 수 있습니다.
하지만 이 경우, 서비스 A의 컨테이너 인스턴스가 확장될 때마다 NGINX 구성을 수동으로 업데이트하고
다시 로드해야 하는 번거로움이 발생합니다.
이는 서비스 인스턴스가 자주 변경되는 환경에서는 다소 복잡한 해결책이 될 수 있습니다.
이 문제를 더 효율적으로 해결할 수 있는 방법이 NGINX Plus를 활용하는 것입니다.
NGINX Plus는 서비스 인스턴스의 동적 변화를 자동으로 인식하여,
NGINX 구성을 수동으로 조정할 필요 없이 자동으로 로드 밸런싱 설정을 업데이트할 수 있습니다.
이를 통해 운영의 복잡성을 줄이고, 서비스의 확장과 유지보수를 보다 쉽게 관리할 수 있습니다.
NGINX Plus 사용
NGINX Plus가 제공하는 추가 기능 중 일부는 다음과 같습니다.
> 활성 애플리케이션 상태 점검 – NGINX Plus는 백엔드 노드를 지속적으로 점검하여 정상 상태이며
적절하게 응답하는지 확인하고, 로드 밸런싱 로테이션에서 비정상 상태인 노드를 제거합니다
> 세션 지속성 - 스티키 세션이라고도 하며 , 클라이언트가 동일한 백엔드로 요청을 계속 보내야 하는 애플리케이션에 필요합니다.
NGINX Plus는 열려 있는 세션이 있는 클라이언트에 영향을 주지 않고,
백엔드 서버를 오프라인으로 전환해야 할 때 세션 드레이닝을 지원합니다.
> 동적 재구성 - NGINX 구성을 변경하고 다시 로드할 필요 없이 백엔드를 확장 및 축소할 수 있는 기능을 제공합니다.
이는 Swarm과 같은 마이크로서비스 플랫폼으로 서비스 검색을 수행할 때 특히 유용하며,
NGINX Plus가 이러한 플랫폼과 완벽하게 통합될 수 있도록 하는 가장 중요한 기능 중 하나입니다.
동적 재구성 방법에는 두 가지가 있습니다. NGINX Plus에 변경 사항을 푸시할 수 있는
API와 NGINX Plus가 도메인 이름에 연결된 노드 수의 변경 사항을 지속적으로 확인하는 DNS입니다.
이 방법은 이 NGINX Plus 데모에서 Swarm의 기본 제공 서비스 검색과 통합하는 데 사용됩니다.
> 라이브 활동 모니터링 – NGINX Plus에서 광범위한 지표를 얻기 위한 API와 API를 기반으로
구축된 웹 대시보드를 제공하여 지표를 보고 백엔드 서버를 추가, 제거, 변경할 수 있습니다.
위 설명에 따르면, NGINX 오픈 소스 구성에서는
Swarm 로드 밸런서가 주로 외부 요청을 백엔드 컨테이너에 분산시키고 서비스 간 내부 요청을 처리합니다.
여기서 NGINX의 주요 역할은 SSL/TLS 오프로드로,
외부로부터 받은 암호화된 요청을 복호화해 백엔드 컨테이너로 전달하는 것입니다.
반면 NGINX Plus를 사용할 경우, Swarm 로드 밸런서가 여전히 외부 요청을 먼저 수신하지만,
이후 요청의 실제 로드 밸런싱은 NGINX Plus가 수행하게 됩니다(그림 6 참조).
이 설정은 NGINX Plus가 요청을 처리하는 단계에서 고급 로드 밸런싱 기능을 활용하게 하며,
고가용성(HA) 구성도 쉽게 구축할 수 있는 장점이 있습니다.
Swarm 로드 밸런서가 초기에 요청을 받아 NGINX Plus로 전달하는 구조를 통해,
NGINX Plus가 장애 발생 시에도 안정적인 운영을 유지할 수 있도록 설정할 수 있습니다.
그림 6. Docker Swarm 로드 밸런서는 서비스 인스턴스 간 로드 밸런싱을 위해 클라이언트 요청을 NGINX Plus로 전달합니다.
마찬가지로 Swarm 로드 밸런서는 서비스 간 요청을 받지만 NGINX Plus는 실제로 이를 여러 서비스에 분산합니다(그림 7).
그림 7. Docker Swarm 로드 밸런서는 서비스 인스턴스 간 로드 밸런싱을 위해 서비스 간 요청을 NGINX Plus로 전달합니다.
NGINX를 사용하거나 사용하지 않고 Docker 로드 밸런싱에 Swarm을 사용하는
몇 가지 예를 제공하기 위해 세 가지 데모를 만들었습니다.
이러한 데모의 모든 파일은 자세한 지침과 함께 GitHub 에서 사용할 수 있습니다.
세 가지 데모는 다음과 같습니다.
Docker Swarm 로드 밸런싱
이는 NGINX나 NGINX Plus를 사용하지 않고도 간단한 웹 앱 백엔드에 대한 요청의 Docker Swarm 로드 밸런싱을 보여줍니다.
NGINX 오픈 소스를 사용한 Docker Swarm 로드 밸런싱
이 데모는 외부 요청에 대한 SSL/TLS 오프로드를 제공하기 위해 NGINX 오픈 소스를 추가합니다.
Swarm 로드 밸런서는 이전 데모와 동일한 간단한 웹 앱 백엔드에 요청을 분산하고 내부 서비스 간 요청을 처리합니다.
NGINX Plus를 사용한 Docker Swarm 로드 밸런싱
이 데모의 첫 번째 부분에서는 NGINX Plus를 사용해 SSL/TLS 오프로드뿐 아니라,
백엔드 컨테이너에 직접 요청을 로드 밸런싱하고, 내부 서비스 간 요청도 처리하는 방식을 보여줍니다.
이때 NGINX Plus는 동적 DNS를 활용하여 백엔드 서비스와 관련된 도메인 이름을 지속적으로 확인하고,
Swarm의 서비스 검색 기능과 통합되어 있습니다.
이를 통해 백엔드 인프라가 변경될 때도 실시간으로 업데이트된 상태를 유지할 수 있습니다.
이 구성에서 NGINX Plus는 두 개의 백엔드 서비스, 즉 Service1과 Service2를 로드 밸런싱합니다.
또한 Service1이 Service2에 요청을 보내는 방식으로 내부 서비스 간 요청을 처리합니다.
이를 통해 서비스 간 통신에 있어서도 안정성과 효율성을 제공합니다.
그림 8. NGINX Plus는 백엔드 서비스 부하 분산 시 Swarm의 동적 DNS 서비스 검색 메커니즘을 사용합니다.
두 번째 부분에서는 NGINX Status API와 Docker Service API를 결합해 백엔드 컨테이너를 자동으로 확장하는 방법을 보여줍니다.
이 구성에서는 Python 프로그램이 NGINX Plus Status API를 활용해 Service1과 Service2의 부하 상태를 모니터링하고,
이를 기반으로 Docker Swarm의 Service API를 통해 백엔드 컨테이너를 확장하거나 축소합니다.
그림 9. Docker Swarm은 자동 확장 목적으로 서비스 부하를 추적하기 위해 NGINX Plus 라이브 활동 모니터링을 사용합니다.
요약
Docker 1.12에 도입된 새로운 기능은 Swarm을 더욱 강력한 플랫폼으로 만들었지만
NGINX Open Source를 활용하고 NGINX Plus를 사용하면 더욱 강화할 수 있습니다.
NGINX Plus가 DNS를 사용하여 부하 분산을 위해 백엔드 컨테이너를 동적으로 재구성하는 기능과
Status API가 제공하는 가시성은 매우 강력한 컨테이너 솔루션을 제공합니다.
NGINX Plus를 사용해보려면 오늘 무료 30일 체험판을 시작하거나 저희에게 연락해 사용 사례에 대해 논의해 보세요 .
GitHub 저장소 에서 제공되는 데모를 사용해 보세요 .
Red Hat과의 파트너십 에서 우리는 OpenShift에서 DevOps 호환 서비스 제공을 위한 고성능,
확장 가능한 장기적 솔루션이 필요한 엔터프라이즈 사용자를 지원하는 데 계속 집중하고 있습니다.
OpenShift용 NGINX Ingress Operator는 OpenShift 환경에서 기본 라우터와 함께
Kubernetes용 NGINX Plus Ingress Controller를 배포하기 위한 지원 및 인증된 메커니즘으로 ,
포인트 앤 클릭 설치 및 자동 업그레이드가 가능합니다.
Operator Lifecycle Manager (OLM)를 활용하여 NGINX Ingress Operator의 설치, 업그레이드 및 구성을 수행할 수 있습니다.
기본 라우터 외에도 NGINX Plus Ingress Controller를 사용하고 싶은 이유가 궁금하신가요?
Red Hat + NGINX의 가치 블로그에서 파트너십이 안전하고 확장 가능하며 지원되는 애플리케이션 제공을 어떻게 가능하게 하는지 알아보세요.
이 단계별 가이드는 NGINX Ingress Operator를 시작하는 데 필요한 모든 것을 제공합니다.
시작하기 전에 OpenShift 4.3 이상을 실행하는 OpenShift 클러스터 환경에 대한 관리자 액세스 권한이 있는지 확인하세요.
운영자 설치
NGINX Ingress Operator를 설치하는 방법을 보여주는 비디오와 스크린샷이 포함되어 있습니다.
OpenShift 콘솔에서 NGINX Ingress Operator를 설치합니다.
OpenShift 콘솔에 관리자로 로그인합니다. 왼쪽 탐색 열에서 Operators를 클릭한 다음 OperatorHub를 클릭합니다 .
검색 상자에 nginx를 입력하고 나타나는 Nginx Ingress Operator 상자를 클릭합니다.
3. 제품 정보를 검토한 후 설치 버튼을 클릭하세요.
4. 열리는 Create Operator Subscription 페이지 에서 Operator를 설치할 클러스터 네임 스페이스를 지정합니다
(이 예에서는 nginx-ingress ).
또한 Approval Strategy 아래의 Automatic 라디오 버튼을 클릭하여 관리자의 수동 승인 없이 실행 중인 Operator 인스턴스의 자동 업데이트를 활성화합니다.
Subscribe 버튼을 클릭합니다 .
5. 설치가 완료되면 터미널에서 다음 명령을 실행하여 Operator가 실행 중인지 확인하세요.
# oc get pods –n nginx-ingress NAME READY STATUS RESTARTS AGE
nginx-ingress-operator-dd546d869-xxxxx 1/1 Running 0 7m29s
6. 왼쪽 탐색 열에서 설치된 운영자를 클릭합니다.
열리는 페이지에서 제공된 API 열에서 NginxIngressController 링크를 클릭합니다 .
NginxIngressController는 운영자가 OpenShift 클러스터에 NGINX Plus Ingress Controller를 배포하는 데 사용하는 사용자 지정 리소스입니다.
7. 열리는 페이지에서 다음 예제와 같은 매니페스트를 텍스트 필드에 붙여넣고 ' 만들기' 버튼을 클릭하여
Kubernetes 배포를 위한 NGINX Plus Ingress Controller를 배포합니다.
TLS 인증서와 키가 있는 SecretdefaultSecret 을 필드에 임베드한다는 점에 유의하세요
wildcardTLS. 이를 통해 Secret을 Ingress 정책에 포함시키지 않고도 TLS 종료 및 패스스루가 가능해집니다.
Kubernetes용 NGINX Plus Ingress Controller를 구성할 때 설정할 수 있는 다양한 옵션이 있으며, 이는 GitHub 저장소 에 나열되어 있습니다
apiVersion: k8s.nginx.org/v1alpha1kind: NginxIngressController
metadata:
name: my-nginx-ingress-controller
namespace: nginx-ingress
spec:
enableCRDs: true
image:
pullPolicy: Always
repository: registry.hub.docker.com/nginx/nginx-ingress
tag: edge
nginxPlus: false
serviceType: LoadBalancer
type: deployment
replicas: 2
defaultSecret: nginx-ingress/default-server-secret
wildcardTLS: default/app-secret
configMapData:
error-log-level: debug
enableTLSPassthrough: true
globalConfiguration: nginx-ingress/nginx-configuration
8. 배포를 확인하려면 터미널에서 다음 명령을 실행합니다. 출력에서 볼 수 있듯이 이전 단계에서 사용한 매니페스트는 NGINX Plus Ingress Controller의 복제본 두 개를 배포하고 이를 서비스에 노출했습니다 LoadBalancer. (명령의 출력은 get읽기 쉽도록 여러 줄에 걸쳐 있습니다.)
다음 명령을 실행하여 NGINX Plus Ingress Controller가 요청에 응답하는지 확인합니다. NGINX Plus Ingress Controller를 노출하는 서비스 public_IP_address의 외부 IP 주소를 대체합니다 .LoadBalancer
이 시점에서 명령이 를 반환한다는 점에 유의하세요 404 Not Found. 이는 아직 백엔드 Pod로 트래픽을 라우팅하기 위한 Ingress 리소스를 구성하고 배포하지 않았기 때문입니다. 자세한 내용은 설명서 를 참조하세요 .
# oc get pods -n nginx-ingressNAME READY STATUS RESTARTS AGE my-nginx-ingress-controller-579f455d7d-xxxxx 1/1 Running 0 5m53s my-nginx-ingress-controller-579f455d7d-xxxxx 1/1 Running 0 5m53s nginx-ingress-operator-dd546d869-xxxxx 1/1 Running 0 56m # oc get svc –n nginx-ingress my-nginx-ingress-controller LoadBalancer 172.xx.48.254 <pending> ... nginx-ingress-operator-metrics ClusterIP 172.xx.209.190 <none> ... ... 80:32028/TCP,443:31973/TCP 10m ... 80:32028/TCP,443:31973/TCP 10m
다음 명령을 실행하여 NGINX Plus Ingress Controller가 요청에 응답하는지 확인합니다. NGINX Plus Ingress Controller를 노출하는 서비스 public_IP_address의 외부 IP 주소를 대체합니다 .LoadBalancer
이 시점에서 명령이 를 반환한다는 점에 유의하세요 404 Not Found. 이는 아직 백엔드 Pod로 트래픽을 라우팅하기 위한 Ingress 리소스를 구성하고 배포하지 않았기 때문입니다. 자세한 내용은 설명서 를 참조하세요 .
# curl public_IP_address <html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.13.4</center>
</body>
</html>
최종 사용자는 NginxIngressController 리소스의 여러 매니페스트를 제출할 수 있으며 각각에 대해 별도의 배포가 생성됩니다.
Operator는 또한 다른 네임스페이스에 걸친 배포를 지원합니다.
네임스페이스는 metadata매니페스트의 섹션에서 지정할 수 있습니다.
NGINX Ingress Operator는 특히 다음을 통해 NGINX Plus Ingress Controller 배포를 관리하는 데 도움이 됩니다.
이제 NGINX Plus Ingress Controller를 준비하고 배포했으니,
설명서 와 GitHub 리포지토리를 참조하여 OpenShift에서 NGINX Plus의 고급 기능을 사용해보세요.
위 내용과 같이 NGINX Ingress Controller 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
이 블로그 시리즈는 Kubernetes의 테스트부터 운영 환경까지의 전환을 다루고 있으며, 전체 블로그를 묶어 제공하는 무료 eBook 형태로도 다운로드할 수 있습니다.점점 더 많은 기업들이 운영 환경에서 컨테이너화된 애플리케이션을 실행함에 따라 Kubernetes는 컨테이너 오케스트레이션의 표준 도구로서 입지를 굳히고 있습니다. 또한, COVID-19 팬데믹으로 인한 재택근무 확대가 인터넷 트래픽 증가를 가속화하면서 클라우드 컴퓨팅 수요 역시 몇 년 빨리 앞당겨졌습니다. 많은 회사들이 고객의 네트워크 장애와 과부하 문제를 해결하기 위해 인프라 업그레이드에 속도를 내고 있습니다.
클라우드 기반 마이크로서비스 환경에서 요구되는 성능 수준을 달성하기 위해서는 차세대 하이퍼스케일 데이터 센터의 확장성과 성능을 활용할 수 있는 빠르고 완전한 동적 소프트웨어가 필요합니다. Kubernetes를 사용하여 컨테이너를 관리하는 조직들 중 상당수가 NGINX 기반의 Ingress 컨트롤러를 사용하여 애플리케이션을 사용자에게 전달하고 있습니다.
이 블로그에서는 멀티 클라우드 환경에서 NGINX Ingress 컨트롤러 세 가지의 성능 테스트 결과를 보고합니다.
테스트에서는 인터넷을 통한 클라이언트 연결의 지연 시간을 측정했습니다.
테스트 프로토콜 및 수집된 메트릭
우리는 wrk2라는 부하 생성 프로그램을 사용하여 클라이언트를 에뮬레이션하고, 정의된 기간 동안 지속적으로 HTTPS 요청을 생성했습니다. 테스트 중인 Ingress 컨트롤러(커뮤니티 Ingress 컨트롤러, NGINX 오픈 소스 기반 NGINX Ingress 컨트롤러, NGINX Plus 기반 NGINX Ingress 컨트롤러)는 Kubernetes Pods에 배포된 백엔드 애플리케이션으로 요청을 전달하고, 클라이언트에게 응답을 반환했습니다. Ingress 컨트롤러들을 스트레스 테스트하여 다음과 같은 성능 지표를 수집했습니다.
토폴로지
모든 테스트에서 AWS 클라이언트 머신에서 wrk2 유틸리티를 사용해 요청을 생성했습니다. AWS 클라이언트는 Ingress 컨트롤러의 외부 IP 주소에 연결했으며, 해당 컨트롤러는 Google Kubernetes Engine(GKE) 환경의 GKE-node-1에 Kubernetes DaemonSet으로 배포되었습니다. Ingress 컨트롤러는 SSL 종료를 위해 Kubernetes Secret을 참조하고 레이어 7 라우팅이 구성되었으며, Kubernetes의 LoadBalancer 타입 서비스로 노출되었습니다. 백엔드 애플리케이션은 GKE-node-2에 Kubernetes Deployment로 실행되었습니다.
클라우드 머신 유형과 소프트웨어 구성에 대한 전체 세부 사항은 부록을 참조하세요.
테스트 방법론
AWS 클라이언트 머신에서 wrk2 (버전 4.0.0) 스크립트를 실행했습니다. 이 스크립트는 두 개의 wrk 스레드를 생성하여 GKE에 배포된 Ingress 컨트롤러에 1,000개의 연결을 동시에 설정합니다. 각 테스트는 3분 동안 실행되며, 스크립트는 초당 30,000개의 요청(RPS)을 생성합니다. 이는 운영 환경에서 Ingress 컨트롤러에 가해질 수 있는 부하를 효과적으로 시뮬레이션하기 위한 적절한 조건으로 간주됩니다.
wrk -t2 -c1000 -d180s -L -R30000 https://app.example.com:443/설명:
TLS 암호화는 2048비트 키 크기의 RSA와 Perfect Forward Secrecy를 사용하여 구현했습니다.
백엔드 애플리케이션의 각 응답 (https://app.example.com:443에서 액세스)에는 약 1KB의 기본 서버 메타데이터와 200 OK HTTP 상태 코드가 포함됩니다.
백엔드 애플리케이션 배포
테스트는 정적 배포와 동적 배포 환경에서 수행했습니다.
정적 배포에서는 5개의 Pod 복제본을 사용하였으며, Kubernetes API를 통해 적용된 변경 사항이 없습니다.
동적 배포에서는 다음 스크립트를 사용하여 백엔드 nginx 배포를 주기적으로 확장하여 Pod 복제본을 5개에서 7개로 늘렸다가 다시 5개로 축소했습니다. 이를 통해 동적 Kubernetes 환경을 에뮬레이션하며 Ingress 컨트롤러가 엔드포인트 변경 사항에 얼마나 효과적으로 적응하는지 테스트했습니다.
while [ 1 -eq 1 ] do kubectl scale deployment nginx --replicas=5 sleep 12 kubectl scale deployment nginx --replicas=7 sleep 10 done
성능 결과
정적 배포에 대한 지연 시간 결과
그래프에 나타난 바와 같이, 세 가지 Ingress 컨트롤러 모두 백엔드 애플리케이션의 정적 배포에서 유사한 성능을 보였습니다. 이는 모두 NGINX Open Source를 기반으로 하고 있으며, 정적 배포에서는 Ingress 컨트롤러의 재구성이 필요하지 않기 때문에 합리적인 결과입니다.
동적 배포에 대한 지연 시간 결과
동적 배포에서는 백엔드 애플리케이션의 Pod 복제본을 주기적으로 5개에서 7개로 확장했다가 다시 5개로 축소했습니다(자세한 내용은 백엔드 애플리케이션 배포 섹션 참조). 그래프에 따르면, 동적 환경에서는 NGINX Plus 기반 Ingress 컨트롤러만이 뛰어난 성능을 유지하며, 99.99번째 백분위수까지도 거의 지연 시간이 발생하지 않았습니다. 반면, 커뮤니티와 NGINX Open Source 기반 Ingress 컨트롤러는 각각 다른 양상으로 낮은 백분위수부터 눈에 띄는 지연 시간이 발생했습니다.
이러한 지연 시간은 Ingress 컨트롤러가 백엔드 애플리케이션의 엔드포인트 변경에 대응해 NGINX 구성을 업데이트하고 재로드할 때 발생하는 오류와 타임아웃으로 인해 발생한 것입니다.
상세한 결과 분석
동일한 테스트 조건에서 커뮤니티 Ingress 컨트롤러와 NGINX Plus 기반 Ingress 컨트롤러의 성능을 보다 세밀하게 분석한 결과는 다음과 같습니다. NGINX Plus 기반 Ingress 컨트롤러는 99.99번째 백분위수까지 거의 지연 시간이 없으며, 99.9999번째 백분위수에서는 254ms에 도달하며 상승하기 시작합니다. 반면, 커뮤니티 Ingress 컨트롤러는 지연 시간이 점진적으로 증가하여 99번째 백분위수에서 5000ms에 도달한 후 일정한 수준을 유지합니다.
타임아웃 및 오류 결과 (동적 배포)
다음 표는 각 Ingress 컨트롤러에서 발생한 지연 시간의 원인을 상세히 설명합니다.
| Connection errors | 33365 | 0 | 0 |
| Connection timeouts | 309 | 8809 | 0 |
| Read errors | 4650 | 0 | 0 |
NGINX Open Source 기반 Ingress 컨트롤러는 백엔드 애플리케이션의 엔드포인트 변경 시 매번 NGINX 설정을 업데이트하고 다시 로드해야 하므로 많은 연결 오류, 타임아웃, 읽기 오류가 발생했습니다. 설정이 리로드되는 동안 클라이언트가 할당되지 않은 소켓에 연결을 시도하거나, 백엔드 엔드포인트가 더 이상 사용 가능하지 않아 연결 타임아웃이 발생할 수 있습니다. 이러한 오류와 타임아웃으로 인해 높은 백분위수에서 32초에서 60초에 달하는 지연 시간이 발생했습니다.
커뮤니티 Ingress 컨트롤러는 엔드포인트 변경 시 설정을 다시 로드하지 않고 Lua 코드로 엔드포인트 변경을 처리합니다. 그 결과 일부 성능 문제가 개선되었지만, 여전히 연결 타임아웃이 발생하여 높은 백분위수에서 상당한 지연 시간이 관찰되었습니다.
NGINX Plus 기반 Ingress 컨트롤러는 NGINX Plus API를 사용하여 엔드포인트가 변경될 때마다 설정을 동적으로 업데이트하여 오류와 타임아웃이 발생하지 않았습니다. 성능에 거의 영향을 받지 않았으며, 최대 지연 시간은 99.9999번째 백분위수에서 254ms에 불과했습니다.
결론
이 테스트 결과에 따르면, 동적 Kubernetes 클라우드 환경에서 타임아웃과 오류를 완전히 없애기 위해서는 엔드포인트 변경 시 동적으로 설정을 조정할 수 있는 Ingress 컨트롤러가 필요합니다. NGINX Plus API는 동적 환경에서 NGINX 설정을 재구성하기 위한 최적의 솔루션임이 확인되었습니다.
| Client | AWS | m5a.4xlarge |
| GKE-node-1 | GCP | e2-standard-32 |
| GKE-node-2 | GCP | e2-standard-32 |
NGINX Open Source 및 NGINX Plus Ingress 컨트롤러 설정
Kubernetes 설정
apiVersion: apps/v1
kind: DaemonSet
metadata:
name: nginx-ingress
namespace: nginx-ingress
spec:
selector:
matchLabels:
app: nginx-ingress
template:
metadata:
labels:
app: nginx-ingress
#annotations:
#prometheus.io/scrape: "true"
#prometheus.io/port: "9113"
spec:
serviceAccountName: nginx-ingress
nodeSelector:
kubernetes.io/hostname: gke-rawdata-cluster-default-pool-3ac53622-6nzr
hostNetwork: true
containers:
- image: gcr.io/nginx-demos/nap-ingress:edge
imagePullPolicy: Always
name: nginx-plus-ingress
ports:
- name: http
containerPort: 80
hostPort: 80
- name: https
containerPort: 443
hostPort: 443
- name: readiness-port
containerPort: 8081
#- name: prometheus
#containerPort: 9113
readinessProbe:
httpGet:
path: /nginx-ready
port: readiness-port
periodSeconds: 1
securityContext:
allowPrivilegeEscalation: true
runAsUser: 101 #nginx
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
env:
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
args:
- -nginx-plus
- -nginx-configmaps=$(POD_NAMESPACE)/nginx-config
- -default-server-tls-secret=$(POD_NAMESPACE)/default-server-secretConfigMap 설정 (NGINX Plus)
이 설정은 NGINX Plus를 위한 ConfigMap으로, NGINX Open Source에 대한 참조는 필요에 따라 조정되었습니다.
NGINX App Protect는 이미지(gcr.io/nginx-demos/nap-ingress)에 포함되어 있지만,
-enable-app-protect 플래그는 생략되어 비활성화되었습니다.
ConfigMap 예시
아래는 NGINX Plus의 ConfigMap 설정 예시입니다. 이 설정은 애플리케이션의 구성을 관리하기 위해 사용됩니다
kind: ConfigMap
apiVersion: v1
metadata:
name: nginx-config
namespace: nginx-ingress
data:
worker-connections: "10000"
worker-rlimit-nofile: "10240"
keepalive: "100"
keepalive-requests: "100000000" 커뮤니티 NGINX Ingress 컨트롤러 구성
Kubernetes 구성 예시
apiVersion: apps/v1
kind: DaemonSet
metadata:
labels:
helm.sh/chart: ingress-nginx-2.11.1
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/version: 0.34.1
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/component: controller
name: ingress-nginx-controller
namespace: ingress-nginx
spec:
selector:
matchLabels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
template:
metadata:
labels:
app.kubernetes.io/name: ingress-nginx
app.kubernetes.io/instance: ingress-nginx
app.kubernetes.io/component: controller
spec:
nodeSelector:
kubernetes.io/hostname: gke-rawdata-cluster-default-pool-3ac53622-6nzr
hostNetwork: true
containers:
- name: controller
image: us.gcr.io/k8s-artifacts-prod/ingress-nginx/controller:v0.34.1@sha256:0e072dddd1f7f8fc8909a2ca6f65e76c5f0d2fcfb8be47935ae3457e8bbceb20
imagePullPolicy: IfNotPresent
lifecycle:
preStop:
exec:
command:
- /wait-shutdown
args:
- /nginx-ingress-controller
- --election-id=ingress-controller-leader
- --ingress-class=nginx
- --configmap=$(POD_NAMESPACE)/ingress-nginx-controller
- --validating-webhook=:8443
- --validating-webhook-certificate=/usr/local/certificates/cert
- --validating-webhook-key=/usr/local/certificates/key
securityContext:
capabilities:
drop:
- ALL
add:
- NET_BIND_SERVICE
runAsUser: 101
allowPrivilegeEscalation: true
env:
- name: POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: POD_NAMESPACE
valueFrom:
fieldRef:
fieldPath: metadata.namespace
readinessProbe:
httpGet:
path: /healthz
port: 10254
scheme: HTTP
periodSeconds: 1
ports:
- name: http
containerPort: 80
protocol: TCP
- name: https
containerPort: 443
protocol: TCP
- name: webhook
containerPort: 8443
protocol: TCP
volumeMounts:
- name: webhook-cert
mountPath: /usr/local/certificates/
readOnly: true
serviceAccountName: ingress-nginx
terminationGracePeriodSeconds: 300
volumes:
- name: webhook-cert
secret:
secretName: ingress-nginx-admissionConfigMap 구성
apiVersion: v1
kind: ConfigMap
metadata:
name: ingress-nginx-controller
namespace: ingress-nginx
data:
max-worker-connections: "10000"
max-worker-open-files: "10204"
upstream-keepalive-connections: "100"
keep-alive-requests: "100000000"백엔드 애플리케이션 구성
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
nodeSelector:
kubernetes.io/hostname: gke-rawdata-cluster-default-pool-3ac53622-t2dz
containers:
- name: nginx
image: nginx
ports:
- containerPort: 8080
volumeMounts:
- name: main-config-volume
mountPath: /etc/nginx
- name: app-config-volume
mountPath: /etc/nginx/conf.d
readinessProbe:
httpGet:
path: /healthz
port: 8080
periodSeconds: 3
volumes:
- name: main-config-volume
configMap:
name: main-conf
- name: app-config-volume
configMap:
name: app-conf
---apiVersion: v1
kind: ConfigMap
metadata:
name: main-conf
namespace: default
data:
nginx.conf: |+
user nginx;
worker_processes 16;
worker_rlimit_nofile 102400;
worker_cpu_affinity auto 1111111111111111;
error_log /var/log/nginx/error.log notice;
pid /var/run/nginx.pid;
events {
worker_connections 100000;
}
http {
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
sendfile on;
tcp_nodelay on;
access_log off;
include /etc/nginx/conf.d/*.conf;
}
---
apiVersion: v1
kind: ConfigMap
metadata:
name: app-conf
namespace: default
data:
app.conf: "server {listen 8080;location / {default_type text/plain;expires -1;return 200 'Server address: $server_addr:
$server_port\nServer name:$hostname\nDate: $time_local\nURI: $request_uri\nRequest ID:
$request_id\n';}location /healthz {return 200 'I am happy and healthy :)';}}"
---apiVersion: v1
kind: Service
metadata:
name: app-svc
spec:
ports:
- port: 80
targetPort: 8080
protocol: TCP
name: http
selector:
app: nginx
---
편집자 - 이 게시물은 10부작 시리즈의 일부입니다.
2020년은 우리 중 거의 누구도 잊지 못할 한 해였습니다.
학교, 기업, 공공 서비스가 갑자기 문을 닫으면서 우리는 갑자기 지역 사회에서 고립되었고
안전과 재정적 안정에 대한 불확실성에 빠졌습니다.
이제 이런 일이 2000년이나 2010년에 일어났다고 상상해보세요.
무엇이 달랐을까요? 기술입니다.
우리가 당연하게 여기는 고품질 디지털 서비스(의료, 스트리밍 비디오, 원격 협업 도구)가 없었다면
팬데믹은 매우 다른 경험이었을 것입니다.
2020년의 기술을 지난 수십 년과 크게 다르게 만든 것은 무엇일까요?
컨테이너와 마이크로서비스입니다.
마이크로서비스 아키텍처(일반적으로 컨테이너와 쿠버네티스를 활용)는 디지털 경험의 출시 시간을 단축하여
비즈니스 성장과 혁신을 촉진합니다.
기존 아키텍처와 함께든 단독으로든 이러한 최신 앱 기술은 뛰어난 확장성과 유연성,
더 빠른 배포, 심지어 비용 절감까지 가능하게 합니다.
2020년 이전에는 대부분 고객이 디지털 전환 전략의 일환으로 마이크로서비스를 도입하기 시작했지만,
팬데믹으로 인해 앱 현대화가 진정으로 가속화되었습니다.
NGINX 사용자를 대상으로 한 2020년 설문 조사에서 응답자의 60%가 프로덕션에서 마이크로서비스를 사용하고 있으며,
이는 2019년의 40%에서 증가한 수치이며, 컨테이너는 다른 최신 앱 기술보다 두 배 이상 인기가 높습니다.
Kubernetes는 컨테이너화된 앱을 관리하는 데 있어 사실상의 표준입니다.
이는 Cloud Native Computing Foundation(CNCF)의 2020년 설문 조사에서 입증되었는데,
응답자의 91%가 Kubernetes를 사용하고 있으며, 그 중 83%가 프로덕션에 사용하고 있습니다.
Kubernetes를 도입할 때 많은 조직은 상당한 아키텍처 변경에 대비하지만
대규모로 최신 앱 기술을 실행하는 데 따른 조직적 영향에 놀랐습니다.
Kubernetes를 실행하고 있다면 다음과 같은 세 가지 비즈니스에서 중요한 장벽을 모두 겪었을 가능성이 큽니다.
대부분의 조직적 문제와 마찬가지로 쿠버네티스의 과제를 극복하기 위한 답은 기술과 프로세스의 조합입니다.
이 글의 나머지 부분에서는 기술 구성 요소에 집중하겠지만, 프로세스 및 기타 주제에 대한 향후 블로그에도 주목하세요.
쿠버네티스는 오픈소스 기술이기 때문에 구현 방법이 다양합니다.
일부 조직은 자체 바닐라 쿠버네티스를 롤링하는 것을 선호하지만,
많은 조직은 Amazon Elastic Kubernetes Service(EKS),
Google Kubernetes Engine(GKE), Microsoft Azure Kubernetes Service(AKS),
Red Hat OpenShift Container Platform, Rancher와 같은 서비스가 제공하는
유연성, 처방성, 지원의 조합에서 가치를 찾습니다.
쿠버네티스 플랫폼은 쉽게 시작하고 실행할 수 있게 해줍니다. 하지만 깊이보다는 광범위한 서비스에 초점을 맞춥니다.
따라서 필요한 모든 서비스를 한곳에서 얻을 수 있지만, 규모에 맞는 진정한 프로덕션 준비에 필요한 기능 세트를 제공하지는 않을 것입니다.
즉, 고급 네트워킹과 보안에 초점을 맞추지 않는데, 쿠버네티스가 많은 고객을 실망시키는 부분입니다.
Kubernetes를 프로덕션 수준으로 만들려면 다음 순서로 세 가지 구성 요소를 추가해야 합니다.
클러스터에서 트래픽을 입출력하기 위한 확장 가능한 인그레스-이그레스 계층
이는 Kubernetes 네트워킹의 복잡성을 추상화하고 Kubernetes 클러스터의 서비스와 외부 서비스 간을 연결하는
특수 로드 밸런서인 Ingress 컨트롤러를 사용하여 달성됩니다.
이 구성 요소는 복원성을 높이고(예: 고급 상태 검사 및 Prometheus 메트릭), 빠른 확장성(동적 재구성)을 지원하고,
셀프 서비스(역할 기반 액세스 제어[RBAC])를 지원하는 기능이 포함되면 프로덕션 등급이 됩니다.
2. 클러스터 전체에서 위협으로부터 보호하기 위한 내장 보안
"거친" 보안이 클러스터 외부에서 충분할 수 있지만, 클러스터 내부에서는 "세밀한" 보안이 필요합니다.
클러스터의 복잡성에 따라 유연한 웹 애플리케이션 방화벽(WAF)을 배포해야 할 수 있는 세 가지 위치가 있습니다.
Ingress 컨트롤러, 서비스별 프록시, Pod별 프록시입니다.
이러한 유연성 덕분에 민감한 앱(예: 청구)에는 더 엄격한 제어를 적용하고 위험이 낮은 곳에는 더 느슨한 제어를 적용할 수 있습니다.
이 세 번째 구성 요소는 Kubernetes 애플리케이션이 기본 도구가 처리할 수 있는 복잡성과 규모 수준을 넘어선 후에 필요합니다.
이 단계에서는 클러스터 내 애플리케이션 서비스에 더욱 세분화된 트래픽 관리 및 보안을 제공하는 오케스트레이션 도구인
서비스 메시가 필요합니다. 서비스 메시는 일반적으로 컨테이너화된 애플리케이션 간의 애플리케이션 라우팅을 관리하고,
자율적인 서비스 간 상호 TLS(mTLS) 정책을 제공하고 시행하며, 애플리케이션 가용성 및 보안에 대한 가시성을 제공하는 역할을 합니다
이러한 구성 요소를 선택할 때 이식성과 가시성을 우선시하세요.
플랫폼 독립적인 구성 요소는 복잡성을 줄이고 보안을 개선하며, 팀이 학습하고 보안을 강화해야 할 도구가 줄어들고
비즈니스 요구 사항에 따라 워크로드를 보다 쉽게 전환할 수 있습니다.
가시성과 모니터링의 중요성은 과장하기 어렵습니다.
Grafana 및 Prometheus와 같은 인기 있는 도구와 통합하면 인프라에 대한 통합된 "단일 창" 뷰가 생성되어
고객이 문제를 발견하기 전에 팀이 문제를 감지할 수 있습니다.
또한 프로덕션 등급 Kubernetes에 반드시 필요하지는 않지만 최신 앱 개발의 필수적인 부분인 다른 보완 기술이 있습니다.
예를 들어 조직이 기존 앱을 현대화할 준비가 되면 첫 번째 단계 중 하나는 API 게이트웨이로 마이크로서비스를 구축하는 것입니다.
당사의 Kubernetes 솔루션은 플랫폼에 구애받지 않으며 프로덕션 등급 Kubernetes를 활성화하는 데 필요한 세 가지 구성 요소를 포함합니다.
즉, 수신-송신 계층인 NGINX Ingress Controller, WAF인 NGINX App Protect, 동서 계층인 NGINX Service Mesh입니다.
이러한 솔루션은 Kubernetes를 네 가지 핵심 영역에서 활성화하여ㅡ 가장 가깝게 활용할 수 있습니다.
NGINX Ingress Controller는 30일 무료 평가판으로 제공되며, 여기에는 컨테이너화된 앱을 보호하는 NGINX App Protect가 포함됩니다.
평가판을 최대한 활용하려면 항상 무료인 NGINX Service Mesh(f5.com에서 다운로드 가능)를 추가하는 것이 좋습니다.
오늘부터 원하는 클라우드에 Bring Your Own License(BYOL)를 사용할 수 있습니다.
통찰력을 얻기 위한 가시성 확보
가시성과 통찰력에 대한 기본 정의를 살펴보겠습니다:
StackRox의 2020년 설문 조사에 따르면, Kubernetes 사용자 중 75%가 가시성을 "필수" 기능으로 인식했습니다.
Kubernetes에서의 가시성은 특히 배포된 콘텐츠를 파악하기 어려운 경우가 많기 때문에 매우 중요합니다.
그러나 F5의 2021년 State of Application Strategy(SOAS) 보고서에 따르면,
응답자의 95%가 방대한 데이터는 가지고 있지만,
애플리케이션의 성능, 보안, 가용성에 대한 중요한 통찰력이 부족하다고 보고했습니다.
그렇다면 통찰력의 중요성과 이를 확보하는 방법에 대해 알아보겠습니다.
통찰력의 중요성:
통찰력은 다음과 같은 여러 측면에서 중요합니다:
통찰력 확보 방법:
통찰력을 얻기 위해서는 두 가지 유형의 가시성 데이터가 필요합니다:
이 두 가지 유형의 데이터를 결합하면, 애플리케이션과 Kubernetes 성능에 대한 유의미한 통찰력을 얻을 수 있습니다.
전략적 접근 필요성:
SOAS 보고서는 또한 통찰력을 얻는 데 있어서 전략적 접근의 중요성을 강조합니다.
전략적 접근을 가로막는 주요 조직적 요인은 다음과 같습니다:
- 관련 기술 세트 부족: 응답자의 47%가 숙련된 기술 전문가 부족을 문제로 보고했습니다.이 게시물은 통찰력의 기술적 측면에 중점을 두었습니다.
향후 블로그에서는 전략, 프로세스 및 기타 관련 주제에 대해 다룰 예정입니다.
대부분의 Kubernetes 배포는 이미 여러 모니터링 도구를 사용하고 있지만,
NGINX는 이러한 도구와의 통합을 통해 성능과 가용성에 대한 중요한 통찰력을 추가적으로 제공합니다.
다음은 NGINX가 어떻게 도움이 되는지와 관련된 몇 가지 주요 측면입니다.
1. NGINX Plus API를 통한 메트릭 내보내기
NGINX Plus API는 메트릭을 쉽게 내보낼 수 있는 기능을 제공하며,
OpenTracing, Grafana, Prometheus와 같은 인기 있는 모니터링 도구와 통합할 수 있습니다.
이를 통해 Kubernetes 클러스터 내에서 애플리케이션의 성능을 종합적으로 파악할 수 있습니다.
2. 유입-유출 트래픽에 대한 인사이트
NGINX Ingress Controller는 Kubernetes 클러스터 내로 들어오고 나가는 트래픽에 대한 중요한 통찰력을 제공합니다.
다양한 NGINX 기반 Ingress 컨트롤러 중에서 적합한 것을 선택하는 것이 중요합니다.
잘못된 선택은 마이크로서비스 전략을 복잡하게 만들 수 있습니다.
블로그 게시물 [Wait, Which NGINX Ingress Controller for Kubernetes Am I Using?]에서
각 옵션을 비교하여 최적의 선택을 할 수 있도록 돕습니다.
3. 동서 트래픽에 대한 인사이트
NGINX Service Mesh는 컨테이너화된 애플리케이션 간의 트래픽 흐름에 대한 깊이 있는 통찰력을 제공합니다.
이를 통해 다음과 같은 두 가지 일반적인 문제를 해결할 수 있습니다:
4. NGINX Ingress Controller를 통한 라이브 모니터링
NGINX Plus를 사용하면 라이브 활동 모니터링 대시보드를 통해 수백 개의 주요 부하 및 성능 메트릭을 실시간으로 표시할 수 있습니다.
이를 통해 단일 포드 수준까지 세부적인 정보를 얻을 수 있으며, 앱의 응답 시간을 빠르게 측정하고 문제의 근원을 진단할 수 있습니다.
Kubernetes 환경이 커짐에 따라, 각 NGINX Ingress Controller 인스턴스에 대한 대시보드도 자동으로 업데이트됩니다.
요청: 초당 요청 수(Req/s)가 예상보다 낮으면 (예: 초당 40개의 요청이 정상이라면, 이 수치가 감소하면)
NGINX Ingress Controller는 NGINX 오픈 소스를 기반으로 하며,
기본적으로 8가지 주요 측정 항목을 보고하는 상태 페이지를 제공합니다.이러한 메트릭을 통해 클러스터의 트래픽을 실시간으로 분석하고, 성능 문제를 조기에 감지할 수 있습니다.
NGINX Service Mesh는 NGINX OpenTracing 모듈을 통해 OpenTracing을 지원합니다.
현재 이 모듈은 다음과 같은 분산 추적 시스템과 통합됩니다:
- Datadog
- LightStep
- Jaeger
- ZipkinNGINX OpenTracing 모듈을 통해 마이크로서비스 간의 요청 흐름을 추적하고, 애플리케이션의 성능을 깊이 분석할 수 있습니다.
이를 통해 서비스 간의 지연 시간, 오류 발생 지점 등을 시각적으로 파악할 수 있습니다.
리소스 부족 문제 해결
클러스터나 플랫폼의 리소스 부족 문제를 진단할 때, 다음과 같은 HTTP 오류 코드를 확인하는 것이 중요합니다:
NGINX Ingress Controller의 로깅 기능
네트워크 문제를 진단하는 첫 번째 단계는 NGINX Ingress Controller 로그를 확인하는 것입니다.
이 로그에는 모든 로그 항목에 관련 Kubernetes 서비스가 주석으로 달려 있습니다.
오류에 관한 항목은 연관된 서비스를 식별합니다.
로그에는 Ingress Controller를 통과한 모든 트래픽에 대한 자세한 정보가 포함되며,
타임스탬프, 소스 IP 주소 및 응답 상태 코드가 포함됩니다.
또한, 로그를 Datadog, Grafana, Splunk와 같은 인기 있는 애그리게이터로 내보낼 수 있습니다.
Prometheus 메트릭
NGINX Ingress Controller의 가장 인기 있는 기능 중 하나는
네트워크 성능 및 Ingress 컨트롤러 트래픽에 대한 메트릭을 포함하는 끊임없이 확장되는 Prometheus 메트릭 목록입니다.
NGINX Plus를 사용하면 NGINX Ingress Controller는 NGINX 작업자 그룹이 처리하는 연결, 캐싱,
HTTP 및 TCP/UDP 트래픽에 대한 메트릭을 내보냅니다.
이 작업자 그룹은 메모리 영역에서 데이터를 공유하며, HTTP 및 TCP/UDP 트래픽은 백엔드 서버 그룹이 처리합니다.
NGINX Service Mesh는 NGINX Plus API를 사용하여 NGINX Service Mesh 사이드카와
NGINX Ingress Controller 포드에서 메트릭을 스크래핑하는 Prometheus 서버를 배포합니다.
기존 Prometheus 배포를 사용하려는 경우, Prometheus 구성 파일에 추가할 스크래핑 구성을 제공합니다.
Grafana 대시보드
우리는 NGINX Ingress Controller 및 NGINX Service Mesh에 대한 공식 Grafana 대시보드를 제공하여
Prometheus Exporter에서 노출된 메트릭을 시각화합니다.
사용자는 밀리초 단위의 세부 사항, 일별 오버레이 및 트래픽 급증 등을 포함하는 데이터의 세분성을 중요하게 생각합니다.
예를 들어, NGINX Service Mesh 대시보드는 특정 서비스나 포드의 트래픽 양과 모니터링되는
활성 포드 수를 표시하여 포드가 용량에 도달했는지를 나타낼 수 있습니다.
프로덕션 준비 완료
NGINX Ingress Controller(NGINX Plus 기반)는 30일 무료 평가판으로 제공되며,
NGINX App Protect가 포함되어 컨테이너화된 애플리케이션을 보호합니다.
NGINX Service Mesh는 무료로 다운로드할 수 있으며, f5.com에서 이용 가능합니다.
이와 같은 도구들을 활용하면 Kubernetes 환경에서 애플리케이션의 성능과 리소스 상태를 효과적으로 모니터링하고 문제를 진단할 수 있습니다.
회사가 최신 앱 개발 기술을 제대로 활용하지 않는다는 신호는 고객의 소셜 미디어에서 불만이 쏟아지는 것과 같은 경우입니다.
예를 들어, 사용자가 '비디오 재생 오류'에 대해 불평하거나, 온라인 뱅킹에 접속할 수 없거나, 장바구니가 시간 초과되는 등의 상황입니다.
고객이 공개적으로 불만을 토로하지 않더라도, 그들의 나쁜 경험이 기업에 큰 영향을 미칠 수 있습니다.
예를 들어, 한 대형 보험사는 자사의 홈페이지가 3초 이내에 로드되지 않으면 고객을 잃을 수 있다고 경고했습니다.
이러한 문제의 근본 원인은 애플리케이션의 복원력 부족에 있습니다.
컨테이너와 Kubernetes를 활용한 마이크로서비스 아키텍처는 앱의 복원력을 개선하여 사용자 경험을 크게 향상시킬 수 있습니다.
핵심은 아키텍처 설계에 있습니다.
모놀리식 vs. 마이크로서비스 아키텍처
모놀리식 아키텍처는 조명이 꺼지면 전체 조명이 어두워지는 전구 스트랜드와 비슷합니다.
전구 하나가 고장나면 전체 시스템이 멈추는 것입니다.
반면, 현대의 조명 시스템은 개별 전구가 꺼져도 나머지 전구가 계속 켜집니다.
이는 잘 설계된 마이크로서비스 아키텍처와 같습니다.
즉, 하나의 서비스가 실패하더라도 나머지 서비스는 계속 작동할 수 있습니다.
컨테이너는 애플리케이션을 더 작고 개별적인 구성 요소로 나누어 빌드할 수 있게 해 주기 때문에
마이크로서비스 아키텍처에서 매우 인기가 있습니다. 컨테이너는 가볍고, 이동이 용이하며, 확장성이 뛰어납니다.
Kubernetes는 컨테이너 오케스트레이션의 사실상 표준으로 자리 잡았지만,
이를 프로덕션 환경에서 효과적으로 사용하는 데는 여러 도전 과제가 있습니다.
Kubernetes 앱의 제어와 복원력을 향상시키기 위한 중요한 요소 중 하나는 트래픽을 단순히 패킷이 아닌 서비스 단위로 관리하고,
트래픽 관리 규칙을 동적으로 조정할 수 있는 성숙한 전략을 갖추는 것입니다.
트래픽 관리의 중요성은 모든 아키텍처에서 공통적이지만,
특히 고성능 앱에서는 두 가지 핵심 도구인 트래픽 제어와 트래픽 분할이 필수적입니다.
트래픽 제어(일명 트래픽 라우팅 또는 트래픽 셰이핑)는 트래픽이 어디로 향하고 어떻게 도달할지를 조절하는 작업을 의미합니다.
Kubernetes 환경에서 이러한 제어는 특히 중요합니다.
이는 인프라와 애플리케이션을 공격이나 트래픽 급증으로부터 보호하는 데 필수적이기 때문입니다.
트래픽 제어를 앱 개발 주기에 통합하는 방법에는 속도 제한과 회로 차단이 있습니다.
사례: 서비스에 과도한 요청이 들어오는 것을 방지하고 싶습니다.
솔루션: 속도 제한
속도 제한은 사용자가 특정 시간 동안 수행할 수 있는 요청 수를 제한하는 기술입니다.
이는 악의적인 공격(예: 무차별 대입 공격, DDoS 공격)이나 비정상적으로 많은 요청(예: 세일 기간 동안 몰려드는 고객들)으로부터
서비스를 보호하는 데 유용합니다.
속도 제한을 설정하면, 대량의 요청이 들어와도 이를 필터링하여 실제 사용자에게 영향을 미치지 않도록 할 수 있습니다.
사례: 연쇄적인 실패를 방지하고 싶습니다.
솔루션: 회로 차단
서비스가 응답하지 않거나 지연될 경우, 클라이언트는 시간 초과 오류를 경험할 수 있으며,
이는 연쇄적인 실패로 이어질 수 있습니다.
연쇄적인 실패는 한 서비스의 중단이 다른 서비스의 시간 초과를 초래하고,
결국 애플리케이션 전체의 실패로 이어질 수 있습니다.
회로 차단기는 서비스의 실패를 모니터링하여 이러한 연쇄적 실패를 방지합니다.
실패한 요청 수가 특정 임계값을 초과하면 회로 차단기가 활성화되어 요청을 즉시 거부하고,
클라이언트에게 오류 응답을 반환함으로써 서비스에 대한 트래픽을 효과적으로 제한합니다.
회로 차단기는 요청을 제한된 수만큼 허용하고, 이를 성공적으로 처리하면 트래픽 제한을 해제합니다.
그렇지 않으면, 회로 차단기는 요청을 계속 거부하며 상태를 모니터링합니다.
트래픽 분할
트래픽 분할(또는 트래픽 테스트라고도 함)은 트래픽 제어의 하위 범주로,
여러 버전의 백엔드 애플리케이션(일반적으로 현재 프로덕션 버전과 새로운 버전)으로 수신 트래픽의 비율을 조절하는 작업을 의미합니다.
이는 새로운 기능이나 버전의 안정성을 고객에게 부정적인 영향을 주지 않으면서 테스트할 수 있는 방법을 제공합니다.
일반적인 배포 시나리오로는 디버그 라우팅, 카나리아 배포, A/B 테스트, 블루-그린 배포 등이 있습니다.
사례: 프로덕션에서 새 버전을 테스트할 준비가 되었습니다.
솔루션: 디버그 라우팅
예를 들어, 은행 앱에 신용 점수 기능을 추가하려는 경우,
고객과 공유하기 전에 이 기능의 성능을 프로덕션 환경에서 미리 보고 싶을 수 있습니다.
디버그 라우팅을 사용하면, 특정 사용자만 새로운 기능에 접근할 수 있도록 설정할 수 있습니다.
예를 들어, 관리자 세션 쿠키를 가진 사용자에게만 신용 점수 기능이 포함된 새로운 버전을 제공하고,
다른 모든 사용자에게는 기존의 안정적인 버전을 계속 제공할 수 있습니다.
이를 통해 실사용자에게 영향을 주지 않으면서 새로운 기능을 테스트할 수 있습니다.
사례: 새 버전의 안정성을 검증해야 할 때
솔루션: 카나리아 배포
카나리아 배포는 역사적 광산 안전 관행에서 유래된 개념입니다.
과거 석탄 광산에서는 독가스가 발생할 경우 카나리아가 먼저 피해를 입어 광부들이 위험을 감지할 수 있었습니다.
현대 애플리케이션에서는 새 버전이 실제로 해를 입지는 않습니다!
카나리아 배포는 새로운 기능이나 버전의 안정성을 테스트하기 위한 안전하고 유연한 방법을 제공합니다.
일반적으로, 카나리아 배포는 안정적인 기존 버전이 전체 트래픽의 대부분(예: 99%)을 처리하도록 유지하면서,
소수(예: 1%)의 트래픽만 새로운 버전으로 전환합니다.
새 버전에서 문제가 발생하면(예: 충돌, 오류 응답) 즉시 해당 트래픽을 안정적인 버전으로 되돌릴 수 있습니다.
새 버전이 성공적일 경우, 모든 사용자에게 새 버전을 배포할 수 있으며, 이는 즉시 전환하거나 점진적으로 진행할 수 있습니다.
사례: 고객이 현재 버전보다 새 버전을 더 선호하는지 알아내고 싶을 때
솔루션: A/B 테스트
새로운 기능이 프로덕션 환경에서 정상적으로 작동하는 것을 확인한 후, A/B 테스트를 통해 고객의 피드백을 받아볼 수 있습니다.
A/B 테스트는 사용자 행동을 측정하여 다양한 제품 또는 앱 버전의 상대적인 성공을 판단하는 방법입니다.
일반적으로, A/B 테스트에서는 사용자 그룹의 50%가 현재 버전(A)을 사용하고, 나머지 50%는 새로운 기능이 포함된 버전(B)을 사용합니다.
KPI(핵심 성과 지표)가 더 우수한 버전이 승자로 간주됩니다.
사례: 다운타임 없이 사용자를 새 버전으로 전환하고 싶을 때
솔루션: 블루-그린 배포
예를 들어, 뱅킹 앱의 주요 버전 업데이트를 고려해 보겠습니다.
과거에는 버전 업그레이드가 사용자에게 다운타임을 발생시켰습니다.
새로운 버전을 프로덕션에 배포하기 전에 기존 버전을 삭제해야 했기 때문입니다.
그러나 오늘날 경쟁적인 환경에서는 다운타임이 거의 용납되지 않습니다.
블루-그린 배포는 다운타임을 크게 줄이거나 완전히 제거할 수 있는 방법입니다.
기존 버전(블루)을 프로덕션에 유지하면서 동시에 새 버전(그린)을 배포합니다.
대부분의 조직은 100%의 사용자를 한 번에 새 버전으로 전환하지 않으려 합니다.
만약 새 버전에서 문제가 발생하면 어떻게 될까요?
카나리아 배포를 사용하여 점진적으로 사용자를 새 버전으로 이동시켜 위험을 최소화할 수 있습니다.
문제가 발생하면 빠르게 기존 버전으로 복구할 수 있습니다.
NGINX가 어떻게 도움이 되는지
고급 트래픽 제어와 분할을 위해 Ingress 컨트롤러와 서비스 메시를 사용할 수 있습니다.
어떤 기술을 선택할지는 애플리케이션 아키텍처와 사용 사례에 따라 다릅니다.
Ingress 컨트롤러는 다음과 같은 경우 유용할 수 있습니다:
서비스 메시가 필요한 복잡한 배포에서는, 개별 마이크로서비스의 테스트 또는 업그레이드를 위해
서비스 간에 트래픽을 분할하는 것이 일반적입니다.
예를 들어, 모바일 프런트엔드 뒤에 두 가지 버전의 지리적 위치 마이크로서비스 API 간에 카나리아 배포를 수행할 수 있습니다.
그러나 일부 Ingress 컨트롤러와 서비스 메시를 설정하는 데는 시간이 많이 걸리고 오류가 발생할 수 있습니다.
이유는 다음과 같습니다:
NGINX Ingress Controller와 NGINX Service Mesh를 사용하면 강력한 트래픽 라우팅 및 분할 정책을 쉽게 구성할 수 있습니다.
NGINX Ingress Controller와 NGINX Service Mesh를 활용하면, 몇 초 만에 설정을 완료하고,
고급 사용자 정의와 향상된 가시성으로 시간을 절약할 수 있습니다.
NGINX Ingress 리소스를 사용하면 구성이 보다 간편해집니다.
NGINX Ingress Controller는 표준 Kubernetes Ingress 리소스 외에도 NGINX Ingress 리소스를 제공하여,
SSL/TLS 종료, HTTP 로드 밸런싱, 레이어 7 라우팅을 간소화합니다.
이는 NGINX 사용자가 기존 로드 밸런서 구성을 재사용할 수 있게 합니다.
**SMI(Specification for Service Mesh Interface)**를 사용한 NGINX 서비스 메시도 유용합니다.
SMI는 Kubernetes에서 서비스 메시에 대한 표준 인터페이스를 정의하며,
이를 통해 카나리아 배포와 같은 트래픽 분할 정책을 쉽게 구현할 수 있습니다.
예를 들어, NGINX 서비스 메시로 카나리아 배포를 설정하는 방법을 통해 최소한의 중단으로 프로덕션 트래픽을 배포할 수 있습니다.
이러한 NGINX 기능은 구성을 보다 쉽게 만듭니다.
NGINX Ingress Controller용 NGINX Ingress 리소스 -
NGINX Ingress Controller를 사용할 때 표준 Kubernetes Ingress 리소스는 SSL/TLS 종료, HTTP 로드 밸런싱, 레이어 7 라우팅 등의 기본 기능을 제공하지만, 회로 차단, A/B 테스트, 블루-그린 배포와 같은 고급 사용자 정의 기능은 포함되어 있지 않습니다. NGINX 사용자는 주석, ConfigMaps, 사용자 정의 템플릿 등을 사용하여 이러한 기능을 구현해야 하는데, 이 방법들은 세부적인 제어가 부족하고, 보안 문제를 일으킬 수 있으며, 오류가 발생하기 쉬운 점이 있습니다.
반면, NGINX Ingress 리소스는 표준 Ingress 리소스의 대안으로 제공됩니다. 이 리소스는 네이티브하고 타입 안전성이 높은 구성 스타일을 제공하여 Ingress 로드 밸런싱을 단순화합니다. NGINX Ingress 리소스를 사용하면 기존 NGINX 환경에서 로드 밸런싱 구성을 재사용할 수 있어, 모든 NGINX 로드 밸런서가 일관된 구성을 사용할 수 있습니다.
SMI를 사용한 NGINX 서비스 메시 – NGINX 서비스 메시는 Kubernetes에서 서비스 메시에 대한 표준 인터페이스를 정의하는 SMI(Specification for Service Mesh Interface) 사양을 구현합니다. SMI는 TrafficSplit, TrafficTarget, HTTPRouteGroup 등과 같은 형식화된 리소스를 제공합니다. 이를 통해 NGINX 서비스 메시와 SMI는 카나리아 배포와 같은 트래픽 분할 정책을 프로덕션 트래픽을 최소한으로 중단하여 쉽게 배포할 수 있도록 도와줍니다. 예를 들어, 카나리아 배포를 NGINX 서비스 메시로 정의하는 방법은 다음과 같습니다:
apiVersion: split.smi-spec.io/v1alpha2kind: TrafficSplit
metadata:
name: target-ts
spec:
service: target-svc
backends:
- service: target-v1-0 weight: 90
- service: target-v2-0 weight: 10이러한 접근법을 통해 트래픽 제어 및 분할을 효과적으로 수행하면서도 간편하게 구성할 수 있습니다.
고급 사용자 정의를 통한 정교한 트래픽 제어 및 분할
NGINX의 다양한 기능을 활용하면 트래픽을 정교하게 제어하고 분할할 수 있습니다.
카나리아 배포를 위한 키-값 저장소
A/B 테스트나 블루-그린 배포를 진행할 때,
트래픽을 단계적으로 새 버전으로 전환하는 작업(예: 0%, 5%, 10%, 25%, 50%, 100%)은
일반적으로 수동적인 과정이 필요합니다.
각 단계에서 백분율을 수정하고 구성 파일을 다시 로드해야 하기 때문입니다.
이로 인해 5%에서 100%로의 급격한 전환을 감수할 수도 있습니다.
그러나 NGINX Plus 기반의 NGINX Ingress Controller를 사용하면,
키-값 저장소를 통해 백분율을 동적으로 조정할 수 있으며,
이 과정에서 구성 파일을 다시 로드할 필요가 없습니다.
NGINX Ingress Controller를 통한 회로 차단
정교한 회로 차단기는 장애를 신속하게 감지하고 대응하며,
상태가 좋지 않은 업스트림에 대해 사용자 정의 오류 페이지를 설정하여 시간을 절약하고 시스템 복원력을 향상시킬 수 있습니다.
예를 들어, 검색 서비스의 회로 차단기는 비어 있는 검색 결과 집합을 반환하도록 설정할 수 있습니다.
NGINX Plus 기반의 NGINX Ingress Controller는 TCP 및 UDP 업스트림 서버의 상태를 사전에 모니터링하는
활성 상태 검사를 제공하여 클라이언트가 오류를 경험할 가능성을 줄입니다.
NGINX 서비스 메시를 통한 회로 차단
NGINX 서비스 메시의 회로 차단기 사양에는 다음과 같은 세 가지 사용자 정의 필드가 포함됩니다:
errors와 timeoutSeconds는 표준 회로 차단기 기능을 제공하며, fallback을 통해 백업 서버를 정의함으로써 복원력을 더욱 강화할 수 있습니다.
백업 서버에서의 응답이 클러스터의 문제를 조기에 나타내는 지표가 될 수 있어, 문제 해결을 신속하게 시작할 수 있습니다.
대시보드를 통한 트래픽 분할 결과 분석
트래픽 분할을 구현한 후, 결과 분석이 필요합니다.
많은 조직이 Kubernetes 트래픽과 애플리케이션 성과에 대한 중요한 통찰력을 놓치는 경우가 많습니다.
NGINX는 Prometheus Exporter에서 노출된 메트릭을 시각화할 수 있는
NGINX Plus 대시보드와 사전 구축된 Grafana 대시보드를 제공하여 이러한 통찰력을 보다 쉽게 얻을 수 있도록 돕습니다.
Kubernetes에서 가시성을 개선하는 방법에 대한 자세한 내용은 블로그를 참조하세요.
NGINX로 마이크로서비스 마스터하기
NGINX Plus 기반의 NGINX Ingress Controller는 NGINX App Protect가 포함된 30일 무료 평가판을 제공하며,
이를 통해 컨테이너화된 애플리케이션을 보호할 수 있습니다.
NGINX 오픈 소스의 NGINX Ingress Controller를 사용해 보려면
릴리스 소스 코드를 다운로드하거나 DockerHub에서 미리 빌드된 컨테이너를 받으세요.
또한, NGINX 서비스 메시는 항상 무료로 제공되며, f5.com에서 다운로드할 수 있습니다.
NGINX가 현대 애플리케이션의 요구 계층을 지원하는 방법
표준 Kubernetes Ingress 리소스는 기본적인 Ingress 로드 밸런싱을 프로비저닝하고 구성하는 데 유용하지만,
Kubernetes를 프로덕션 등급으로 만들기 위해 필요한 맞춤화 기능은 포함되어 있지 않습니다.
대신, 비-NGINX 사용자는 주석, ConfigMaps 및 맞춤 템플릿을 사용해야 하는데,
이는 오류가 발생하기 쉽고, 사용하기 어려우며, 보안이 부족하고 세밀한 범위 설정이 부족합니다.
NGINX Ingress 리소스는 이러한 문제에 대한 우리의 해결책입니다.
NGINX Ingress 리소스는 NGINX Open Source 및 NGINX Plus 기반의 NGINX Ingress Controller 버전 모두에서 사용할 수 있습니다.
이 리소스는 기본적인, 타입-안전하며 의도된 구성 스타일을 제공하여 Ingress 로드 밸런싱 구현을 간소화합니다.
이 블로그에서는 NGINX Ingress Controller 1.11.0에서 도입된
두 가지 기능에 중점을 두어 WAF 및 로드 밸런싱 정책 구성을 쉽게 할 수 있도록 합니다:
TransportServer 리소스 – TransportServer 리소스는 TCP, UDP, TLS Passthrough 로드 밸런싱 구성을 정의합니다.
우리는 TCP/UDP 로드 밸런싱을 향상시키기 위해 헬스 체크, 상태 보고 및 구성 스니펫을 추가했습니다.
NGINX Ingress WAF 정책 – NGINX App Protect 3.0을 NGINX Ingress Controller와 함께 배포하면,
NGINX Ingress 리소스를 활용하여 특정 Kubernetes 서비스에 WAF 정책을 적용할 수 있습니다.
TransportServer 스니펫
NGINX Ingress Controller에서는 VirtualServer 및 VirtualServerRoute (VS 및 VSR) 리소스에 대해 구성 스니펫을 도입했습니다.
이는 HTTP 기반 클라이언트를 위한 NGINX Ingress 구성을 네이티브로 확장할 수 있게 해 줍니다.
1.11.0 릴리스에서는 TS 리소스에 대한 스니펫을 도입하여 TCP/UDP 기반 서비스를 제공할 수 있는
NGINX 및 NGINX Plus의 전체 기능을 쉽게 활용할 수 있습니다.
예를 들어, IP 주소 및 범위를 사용하여 서비스에 접근할 수 있는 클라이언트를 정의하는 deny 및 allow 지시어를 추가할 수 있습니다.
TransportServer 리소스의 향상 사항
NGINX Ingress Controller 1.11.0은 다음 영역에서 TransportServer (TS) 리소스를 확장합니다:
참고: TransportServer 리소스에 대한 추가 사항은 1.11.0 릴리스에서 기술 미리보기 상태이며,
향후 릴리스에서 안정적이고 프로덕션 준비가 완료된 품질 기준으로 승격될 것입니다.
NGINX Ingress Controller에서는 VirtualServer 및 VirtualServerRoute (VS 및 VSR) 리소스에 대해 구성 스니펫을 도입했습니다.
이는 HTTP 기반 클라이언트를 위한 NGINX Ingress 구성을 네이티브로 확장할 수 있게 해 줍니다.
1.11.0 릴리스에서는 TS 리소스에 대한 스니펫을 도입하여 TCP/UDP 기반 서비스를 제공할 수 있는
NGINX 및 NGINX Plus의 전체 기능을 쉽게 활용할 수 있습니다.
예를 들어, IP 주소 및 범위를 사용하여 서비스에 접근할 수 있는 클라이언트를 정의하는 deny 및 allow 지시어를 추가할 수 있습니다.
apiVersion: k8s.nginx.org/v1alpha1
kind: TransportServer
metadata:
name: cafe
spec:
host: cafe.example.com
serverSnippets: |
deny 192.168.1.1;
allow 192.168.1.0/24;
upstreams:
- name: tea
service: tea-svc
port: 80Kubernetes 클러스터의 상태를 모니터링하기 위해 NGINX Ingress Controller는
애플리케이션 포드에 로컬로 적용된 Kubernetes 프로브만 고려하지 않고,
TCP/UDP 기반의 업스트림 서비스 간 네트워크 상태도 지속적으로 점검합니다.
패시브 헬스 체크를 통해 전송 중인 트랜잭션의 건강 상태를 평가하고,
액티브 헬스 체크(NGINX Plus 전용)를 통해 엔드포인트를 주기적으로 탐색합니다.
헬스 체크는 회로 차단 및 애플리케이션 오류 처리에 매우 유용할 수 있습니다.
TS 리소스의 healthCheck 필드를 사용하여 프로브 간 간격, 프로브 타임아웃, 프로브 간 지연 시간 등을 설정하여
헬스 체크를 사용자 정의할 수 있습니다.
또한, NGINX Ingress Controller에서 헬스 프로브의 업스트림 서비스 및 포트 대상을 설정할 수 있습니다.
이는 업스트림 애플리케이션의 건강 상태가 다른 프로세스나 서브시스템에 의해 다른 리스너에서 노출되는 상황에서 유용합니다.
IngressClassName을 통한 여러 TransportServer 리소스 지원
TS 리소스를 업데이트하고 적용할 때, 구성이 유효한지 및 해당 Ingress Controller 배포에 성공적으로 적용되었는지
확인하는 것이 유용합니다. 1.11.0 릴리스에서는 TS 리소스에 대해 ingressClassName 필드와 상태 보고를 도입했습니다.
ingressClassName 필드는 여러 배포가 있는 환경에서 TS 리소스가 특정 Ingress Controller 배포에 의해 처리되도록 보장합니다.
TS 리소스의 상태를 표시하려면 kubectl get transportserver 명령을 실행하십시오.
출력에는 상태(유효 또는 무효), 가장 최근 업데이트의 이유, 그리고 (단일 TS의 경우) 사용자 정의 메시지가 포함됩니다
$ kubectl get transportserver
NAME STATE REASON AGE
dns-tcp Valid AddedOrUpdated 47m
$ kubectl describe transportserver dns-tcp
. . .
Status:
Message: Configuration for default/dns-tcp was added or updated
Reason: AddedOrUpdated
State: Valid 여러 TS 리소스가 동일한 호스트/리스너를 경쟁할 경우,
NGINX Ingress Controller는 가장 오래된 타임스탬프를 가진 TS 리소스를 선택하여 결과를 결정합니다.
NGINX App Protect 지원을 통한 WAF 정책 정의
NGINX Ingress 리소스는 구성 작업을 더 쉽고 유연하게 만들 뿐만 아니라, 트래픽 제어를 다양한 팀에 위임하고
VirtualServerRoute (VSR) 리소스에서 정의된 애플리케이션 하위 경로에 대한 엄격한 권한 제한을 적용할 수 있게 해줍니다.
올바른 팀에 적절한 Kubernetes 리소스에 대한 액세스를 부여함으로써,
NGINX Ingress 리소스는 네트워킹 리소스에 대한 세밀한 제어를 가능하게 하고,
사용자가 침해되거나 해킹될 경우 애플리케이션의 잠재적 피해를 줄일 수 있습니다.
1.11.0 릴리스에서는 Kubernetes 배포에서 NGINX App Protect의 구성을 확장하기 위해
네이티브 웹 애플리케이션 방화벽(WAF) 정책 객체를 도입했습니다.
이 정책은 1.8.0 릴리스에서 도입된 APLogConf 및 APPolicy 객체를 활용하며,
VirtualServer (VS) 및 VSR 리소스 모두에 첨부할 수 있습니다.
이는 보안 관리자가 VS 리소스를 통해 Ingress 구성의 전체 범위를 소유할 수 있도록 하면서,
VSR 리소스를 참조하여 다른 팀에 보안 책임을 위임할 수 있게 해줍니다.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: webapp
spec:
host: webapp.example.com
policies:
- name: waf-prod
tls:
secret: app-secret
upstreams:
- name: webapp-prod
service: webapp-svc
port: 80
routes:
- path: /v2
route: test/test
- path: /v1
action:
pass: webapp-prod다음 예제에서는 waf-prod 정책이 webapp-prod 업스트림으로 라우팅되는 사용자에게 적용됩니다.
다른 네임스페이스에 걸쳐 /v2 경로에 대한 보안 책임을 위임하기 위해, 강조된 경로 지시어가 VSR 리소스를 참조합니다..
apiVersion: k8s.nginx.org/v1
kind: VirtualServerRoute
metadata:
name: test
namespace: test
spec:
host: webapp.example.com
upstreams:
- name: webapp
service: webapp-test-svc
port: 80
subroutes:
- path: /v2
policies:
- name: waf-test
action:
pass: webapp이 예제는 네임스페이스별로 테넌트를 분리하고,
test 네임스페이스의 webapp-test-svc 서비스에 대해 다른 WAF 정책을 적용합니다.
이는 리소스를 다른 팀에 위임하고 객체로 캡슐화하여 프로덕션 애플리케이션을 방해하지 않고
새로운 기능을 테스트할 수 있는 방법을 보여줍니다.
릴리스 1.11.0의 추가 사항은 무엇인가요?
NGINX Ingress Controller 1.11.0 릴리스는 유연하고 강력하며
사용하기 쉬운 프로덕션 등급의 Ingress 컨트롤러를 제공하겠다는
우리의 약속을 지속적으로 이행합니다.
WAF 및 TS 개선 사항 외에도, 1.11.0 릴리스는 다음과 같은 향상을 포함하고 있습니다:
- 주석의 추가 검증 – 더 많은 구성 오류 방지주석의 추가 검증
릴리스 1.10.0에서 주석 검증 개선에 이어, 이제 다음과 같은 추가 주석을 검증하고 있습니다:
| nginx.org/client-max-body-size | Must be a valid offset |
| nginx.org/fail-timeout | Must be a valid time |
| nginx.org/max-conns | Must be a valid non‑negative integer |
| nginx.org/max-fails | Must be a valid non‑negative integer |
| nginx.org/proxy-buffer-size | Must be a valid size |
| nginx.org/proxy-buffers | Must be a valid proxy buffer spec |
| nginx.org/proxy-connect-timeout | Must be a valid time |
| nginx.org/proxy-max-temp-file-size | Must be a valid size |
| nginx.org/proxy-read-timeout | Must be a valid time |
| nginx.org/proxy-send-timeout | Must be a valid time |
| nginx.org/upstream-zone-size | Must be a valid size |
주석의 값이 유효하지 않으면, Ingress 리소스가 적용될 때
Ingress Controller는 리소스를 거부하고 해당 구성 항목을 NGINX에서 제거합니다.
Status Information about Policies
kubectl get policy 명령을 사용하여 정책의 상태(유효 또는 무효) 및 (단일 TS의 경우)
사용자 정의 메시지 및 가장 최근 업데이트의 이유를 보고할 수 있습니다.
$ kubectl get policy
NAME STATE AGE
webapp-policy Valid 30s
$ kubectl describe policy webapp-policy
. . .
Status:
Message: Configuration for default/webapp-policy was added or updated
Reason: AddedOrUpdated
State: Valid
NGINX Ingress Controller는 이제 Istio 서비스 메시 내부에서 실행되는 앱의 Ingress 컨트롤러로 사용할 수 있습니다.
이를 통해 사용자는 NGINX Ingress Controller가 제공하는
고급 기능을 Istio 기반 환경에서도 계속 사용할 수 있습니다.
이 통합에는 두 가지 요구 사항이 있습니다:
첫 번째 요구 사항을 충족하려면 NGINX Ingress Deployment 파일의 주석 필드에 다음 항목을 포함하십시오
annotations:
traffic.sidecar.istio.io/includeInboundPorts: ""
traffic.sidecar.istio.io/excludeInboundPorts: "80,443"
traffic.sidecar.istio.io/excludeOutboundIPRanges: "10.90.0.0/16,10.45.0.0/16"
sidecar.istio.io/inject: 'true'두 번째 요구 사항은 requestHeaders 필드의 동작을 변경하여 달성됩니다.
이전 릴리스에서는 다음 구성으로 두 개의 Host 헤더가 백엔드로 전송되었습니다: $host와 지정된 값인 bar.example.com.
apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
name: foo
spec:
host: foo.example.com
upstreams:
- name: foo
port: 8080
service: backend-svc
use-cluster-ip: true
routes:
- path: "/"
action:
proxy:
upstream: foo
requestHeaders:
set:
- name: Host
value: bar.example.com릴리스 1.11.0 이후로는 지정된 값만 전송됩니다. $host를 보내려면 requestHeaders 필드를 생략하십시오.
Cluster-IP Addresses for Upstream Endpoints
NGINX Ingress Controller 구성에서 업스트림 엔드포인트를 개별 포드 엔드포인트의 IP 주소 대신
서비스/클러스터-IP 주소로 채울 수 있습니다.
NGINX Ingress Controller가 Cluster-IP 서비스로 트래픽을 라우팅할 수 있도록 하려면,
VS 또는 VSR 구성의 upstreams 섹션에 use-cluster-ip: true 필드를 포함하십시오:
upstreams:
- name: tea
service: tea-svc
port: 80
use-cluster-ip: true
- name: coffee
service: coffee-svc
port: 80
use-cluster-ip: true릴리스 1.11.0의 전체 변경 로그는 릴리스 노트에서 확인할 수 있습니다.
NGINX Plus 및 NGINX App Protect와 함께 NGINX Ingress Controller를 사용해 보려면
무료 30일 평가판을 시작하거나 사용 사례에 대해 논의하려면 저희에게 연락하십시오.
NGINX Open Source와 함께 NGINX Ingress Controller를 사용해 보려면,
릴리스 소스 코드를 얻거나 DockerHub에서 미리 빌드된 컨테이너를 다운로드할 수 있습니다.
서비스 메시가 실제로 Kubernetes 환경을 관리하는 것을 더 복잡하게 만들 수 있는 방법 중 하나는
Ingress 컨트롤러 와 별도로 구성해야 하는 경우입니다 .
별도의 구성은 시간 소모적일 뿐만 아니라, 적절한 트래픽 라우팅을 방해하고
심지어 보안 취약성(예: 악의적인 행위자가 제한된 앱에 액세스)과 열악한 경험(예: 고객이 권한이 있는 앱에 액세스할 수 없음)으로
이어질 수 있는 구성 오류의 가능성을 높입니다.
별도의 구성을 수행하는 데 걸리는 시간 외에도 오류 문제 해결에 더 많은 시간을 소비하게 됩니다.
NGINX Plus 기반 NGINX Ingress Controller를 NGINX Service Mesh 와 통합하여
인그레스와 이그레스 mTLS 트래픽을 모두 제어하면 이러한 문제를 피하고 시간을 절약할 수 있습니다 .
이 비디오 데모에서는 전체 단계를 다룹니다.
필수 조건 (0:18)
실제 데모를 시작하기 전에, 다음과 같은 전제조건을 갖고 착수했습니다.
1. Kubernetes 클러스터에 NGINX Server Mesh 제어 평면을 설치 하고 mTLS와 서비스 메시에 대한 정책을 설정했습니다 strict .strict1 단계에서 만든 정책 의 결과로 bookinfo메시 외부의 클라이언트에서 앱으로의 요청은 사이드카에서 거부됩니다. 데모에서 다음 명령을 먼저 실행하여 포트 포워딩을 설정하여 이를 설명합니다.
> kubectl port-forward svc/product-page 9080Forwarding from 127.0.0.1:9080 -> 9080
Forwarding from [::1]:9080 -> 9080
Handling connection for 9080앱에 액세스하려고 하면 503로컬 머신이 서비스 메시의 일부가 아니기 때문에 상태 코드가 표시됩니다.
> curl localhost:9080503NGINX 서비스 메시를 사용하여 NGINX Ingress Controller 배포(1:50)
앱을 노출하는 프로세스의 첫 번째 단계는 NGINX Ingress Controller 인스턴스를 배포하는 것입니다. 해당 지침은 튜토리얼 Deploy with NGINX Plus Ingress Controller for Kubernetes 에서 제공됩니다 .
NGINX는 이 목적을 위해 Deployment와 DaemonSet 매니페스트를 모두 제공합니다. 데모에서는 Deployment 매니페스트인 nginx-plus-ingress.yaml을 사용합니다 . 여기에는 동일한 NGINX Ingress Controller 인스턴스를 통해 인그레스와 이그레스 트래픽을 모두 라우팅하는 주석이 포함되어 있습니다.
매니페스트는 NGINX Ingress Controller를 NGINX Service Mesh의 인증 기관(CA)인 Spire와 직접 통합할 수 있게 하므로 NGINX Ingress Controller에 NGINX Service Mesh 사이드카를 주입할 필요가 없습니다. 대신 NGINX Ingress Controller는 Spire CA에서 직접 인증서와 키를 가져와 메시의 포드와 함께 mTLS에 사용합니다. 매니페스트는 Spire 에이전트 주소를 지정합니다.
그리고 Spire 에이전트 UNIX 소켓을 NGINX Ingress Controller Pod에 마운트합니다.
매니페스트에 대해 주목해야 할 마지막 사항은 -enable-internal-routesCLI 인수로, 이를 통해 송신 서비스로 라우팅할 수 있습니다.
데모를 시작하기 전에 NGINX Ingress Controller를 설치
kubectl apply -f nginx-plus-ingress.yaml 하는 명령을 실행했고 ,
이 시점에서 네임스페이스에서 배포를 검사합니다 .
다음 출력의 열에 표시된 대로 NGINX Ingress Controller 포드에 대한 컨테이너는 하나뿐입니다.
NGINX Service Mesh 사이드카를 주입하지 않았기 때문입니다.nginx-ingressREADY
또한 클러스터 외부의 NGINX Ingress Controller(여기서는 35.233.133.188)의
외부 IP 주소를 노출하는 유형의 서비스를 배포했습니다.
해당 IP 주소에서 LoadBalancer샘플 애플리케이션에 액세스합니다 .bookinfo
kubectl get pods '--namespace=nginx-ingressNAME READY STATUS RESTARTS AGE pod/nginx-ingress-867f954b8f0fzdrm 1/1 Running 0 3d3h NAME TYPE CLUSTER-IP EXTERNAL-IP ... service-nginx-ingress LoadBalancer 10.31.245.207 35.233.133.188 ... ... PORT(S) AGE ... 80:31469/TCP,443:32481/TCP 4d2h ...
표준 Kubernetes Ingress 리소스를 사용하여 앱 노출(3:55)
이제 bookinfo-ingress.yamlbookinfo 에 정의된 표준 Kubernetes Ingress 리소스를 사용하여 메시에서 앱을 노출합니다 . 해당 지침은 튜토리얼 NGINX Plus Ingress Controller로 애플리케이션 노출에 제공됩니다 .
리소스는 10번째 줄에서 앱에 대한 Kubernetes Secret을 참조 하고 bookinfo.example.com 에 대한 요청이 서비스 로 전송되도록 bookinfo지정하는 라우팅 규칙을 포함합니다 ( 11~18번째 줄 ). Secret은 bookinfo-secret.yaml 에 정의되어 있습니다 .productpage
데모에서는 자체 서명된 키와 인증서를 로드하려면 다음 명령을 실행합니다.
> kubectl apply -f bookinfo-secret.yamlsecret/bookinfo-secret unchangedIngress 리소스를 활성화합니다.
> kubectl apply -f bookinfo-ingress.yamlingress.networking.k8s.io/bookinfo-ingress deleted그리고 출력 끝의 이벤트에서 확인된 대로 Ingress Controller가
리소스에 정의된 경로를 추가했는지 확인합니다.
> kubectl describe ingress bookinfo-ingress...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal AddedOrUpdated 5s nginx-ingress-controller Configuration for ...
...default/bookinfo-ingress was added or updated데모에서는 이제 브라우저를 사용하여 https://bookinfo.example.com/bookinfo 에서 앱에 액세스합니다 . (이전에 로컬 /etc/hosts 파일에 Ingress Controller 서비스의 IP 주소(데모에서는 위에 언급된 대로 35.233.133.188)와 bookinfo.example.com 간의 매핑을 추가했습니다 . 지침은 설명서 를 참조하세요.) 페이지의 Book Reviews 섹션 에 있는 정보는 bookinfo.yaml 에 정의된 서비스 의 세 가지 버전을 통해 요청이 순환함에 따라 주기적으로 변경됩니다 ( 다운로드 ).reviews
다음으로 클러스터로의 인그레스 트래픽을 검사합니다 . generate-traffic.shproductpage 스크립트를 실행하여 NGINX Ingress Controller의 공개 IP 주소를 통해 서비스 에 요청을 한 다음 nginx-meshctl top명령을 실행하여 트래픽을 모니터링합니다.
> > nginxmesh-ctl top deploy/productpage-v1Deployment Direction Resource Success Rate P99 P90 P50 ...
productpage-v1
To details-v1 100.00% 3ms 3ms 2ms
To reviews-v2 100.00% 99ms 90ms 20ms
To reviews-v3 100.00% 99ms 85ms 18ms
To reviews-v1 100.00% 20ms 17ms 9ms
From nginx-ingress 100.00% 192ms 120ms 38ms
... NumRequests
... 14
... 5
... 5
... 12NGINX VirtualServer 리소스를 사용하여 앱 노출(6:45)
다음으로 NGINX VirtualServer 리소스를 사용하여 앱을 노출하는 대체 방법을 보여드리겠습니다.
이는 트래픽 분할 및 콘텐츠 기반 라우팅과 같은 보다 복잡한 트래픽 처리를 지원하는
사용자 지정 NGINX Ingress Controller 리소스입니다.
먼저 표준 Ingress 리소스를 삭제합니다.
> kubectl delete -f bookinfo-ingress.yamlingress.networking.k8s.io "bookinfo-ingress" deletedbookinfo -vs.yaml 파일은 bookinfo-ingress.yaml ( 7-8행 ) 과 동일한 Secret으로 mTLS를 구성합니다 . 9-12행은productpage 서비스를 업스트림으로 정의하고 , 13-24행은 bookinfo.example.comGET 에서 수행된 모든 요청을 해당 업스트림으로 보내는 경로를 정의합니다 . 이외의 HTTP 메서드의 경우 상태 코드를 반환합니다 .GET405
우리는 리소스를 적용합니다:
> kubectl apply -f bookinfo-vs.yamlvirtualserver.kubernetes.nginx.org/bookinfo-vs created그런 다음 Ingress 리소스와 동일한 단계를 수행합니다. 즉, kubectl describe올바른 배포를 확인하기 위해 명령을 실행하고 브라우저에서 앱에 액세스합니다. 앱이 올바르게 작동한다는 또 다른 확인은 메서드를 거부한다는 것입니다 POST.
> curl -k -X POST https://bookinfo.example.com/Method not allowedNGINX Ingress Controller를 사용하여 보안 Egress 경로 구성(8:44)
이제 NGINX Ingress Controller를 통해 egress 트래픽을 라우팅하는 방법을 보여드리겠습니다. NGINX Plus Ingress Controller로 보안 egress 경로 구성 튜토리얼은 다양한 샘플 앱을 사용하여 프로세스를 다룹니다.
우리는 이미 bash.yamlbash 에서 간단한 포드를 정의 하고 요청을 보내는 기본 네임스페이스에 배포했습니다. 이 출력의 열에 표시된 대로 NGINX Service Mesh 사이드카로 주입되었습니다.READY
>> kubectl get allNAME READY STATUS RESTARTS AGE
pod/bash-6ccb678958-zsgm7 2/2 Running 0 77s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/kubernetes ClusterIP 10.31.240.1 443/TCP 4d2h
....포드 내부에서 NGINX 서비스 메시에 속하지 않는 모든 엔터티인 Igress 서비스 로의 요청을 활성화하려는 사용 사례가 여러 가지 있습니다 . 배포된 서비스의 예는 다음과 같습니다.
- 클러스터 외부데모에서는 최종 사용 사례를 고려하고 있습니다. legacyNGINX Service Mesh에서 제어하지 않고 NGINX Service Mesh 사이드카의 자동 주입이 비활성화된 네임스페이스에 배포된 애플리케이션이 있습니다. 앱에서 실행되는 포드는 하나뿐입니다.
>> kubectl get all --namespaces=legacyNAME READY STATUS RESTARTS AGE
pod/target-5f7bcb96c6-km9lz 1/1 Running 0 27m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/target-svc ClusterIP 10.31.245.213 80/TCP,443/TCP 27mNGINX 서비스 메시에 mTLS 정책을 구성했다는 점을 기억하세요 strict. 그 결과 포드에서 bash대상 서비스로 직접 요청을 보낼 수 없습니다. 둘이 서로 인증할 수 없기 때문입니다. 시도하면 503여기에 설명된 대로 상태 코드가 표시됩니다.
> kubectl exec -it bash-6ccb678958-zsgm7 -c bash -- curl target-svc.legacycurl: (56) Recv failure: connection reset by peer
503command terminated with exit code 56해결책은 포드가 NGINX Ingress Controller를 통해 egress 트래픽을 보낼 수 있도록 하는 것입니다 . bash.yaml 의 14~15번째 줄bash 에 있는 주석의 주석을 해제합니다 .
그런 다음 새로운 구성을 적용합니다.
> kubectl apply -f bash.yamldeployment.apps/bash configured새로운 bash포드가 회전했는지 확인하세요.
> kubectl get podsNAME READY STATUS RESTARTS AGE bash-678c8b4579-7sfml 2/2 Running 0 6s bash-6ccb678958-zsgm7 2/2 Terminating 0 3m28s
kubectl exec이제 이전과 같은 명령을 실행하여 bash포드에서 대상 서비스로 요청을 보내면 404 대신 상태 코드가 표시됩니다 503. 이는 bash포드가 NGINX Ingress Controller로 요청을 성공적으로 보냈지만 후자는 경로가 정의되지 않았기 때문에 어디로 전달해야 할지 모른다는 것을 나타냅니다.
다음 Ingress 리소스 정의를 legacy-route.yaml 에 사용하여 필요한 경로를 만듭니다 . internal-route7번째 줄의 주석은 대상 서비스가 인터넷에 노출되지 않고 NGINX Service Mesh 내의 워크로드에만 노출된다는 것을 의미합니다.
새 리소스를 활성화하고 NGINX Ingress Controller가 리소스에 정의된 경로를 추가했는지 확인합니다.
> kubectl apply -f legacy-route.yamlingress.networking.k8s.io/target-internal-route created
> kubectl describe ingress target-internal-route -n legacy
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal AddedOrUpdated 6s nginx-ingress-controller Configuration for ...
...legacy/target-internal-route was added or updated이제 명령을 실행하면 kubectl exec대상 서비스에 도달합니다.
{"req": {"method": "GET" "url": "/",
"host": "target-svc.legacy",
"remoteAddr": "10.28.2.76:56086"}}NGINX Ingress Controller를 통해 송신 트래픽을 라우팅하는 이점은 클러스터 내부에서 어떤 외부 서비스에 접근할 수 있는지 정확하게 제어할 수 있다는 것입니다. 즉, 경로를 정의한 서비스에만 해당됩니다.
데모에서 보여드릴 마지막 사항은 이탈 트래픽을 모니터링하는 방법입니다. kubectl exec여러 요청을 보내는 명령을 실행한 다음 이 명령을 실행합니다.
> > nginxmesh-ctl top deploy/nginx-ingress -n nginx-ingressDeployment Direction Resource Success Rate P99 P90 P50 NumRequests nginx-ingress To target 100.00% 1ms 1ms 1ms 9 From bash 100.00% 0ms 0ms 0ms 9
지연에 대해 "NO"라고 하세요
NGINX Ingress Controller로 NGINX 서비스 메시를 시도하세요
많은 서비스 메시가 인그레스 및 이그레스 게이트웨이 옵션을 제공하지만, NGINX 통합의 추가 이점인 낮은 지연 시간을 높이 평가하실 것으로 생각합니다. 대부분의 메시는 인그레스 컨트롤러에 사이드카를 주입해야 하며, 이를 위해 트래픽이 앱으로 가는 길에 추가 홉을 만들어야 합니다.
몇 초가 중요하며, 디지털 경험을 느리게 하는 추가 홉으로 인해 고객이 다른 곳으로 전환할 수 있습니다. NGINX Service Mesh는 NGINX Ingress Controller에 사이드카를 주입하지 않으므로 불필요한 지연 시간을 추가하지 않습니다. 대신 메시의 CA인 Spire와 직접 통합하여 NGINX Ingress Controller가 NGINX Service Mesh의 일부가 됩니다.
NGINX Ingress Controller는 Spire 에이전트에서 인증서와 키를 간단히 가져와서 메시된 포드와 mTLS 인증서 교환에 참여하는 데 사용합니다. Kubernetes용 NGINX Ingress Controller에는 NGINX Open Source와 NGINX Plus의 두 가지 버전이 있습니다. 이 블로그에 설명된 대로 NGINX Service Mesh와 함께 NGINX Ingress Controller를 배포하려면 30일 무료 평가판 으로 제공되는 NGINX Plus 버전을 사용해야 합니다 .
NGINX Service Mesh는 완전 무료이며 즉시 다운로드 할 수 있으며 10분 이내에 배포할 수 있습니다! 시작하려면 문서를 확인 하고 GitHub을 통해 진행 상황을 알려주세요 .
이제 AWS Marketplace for Containers 에서 NGINX App Protect가 있거나 없는
NGINX Ingress Controller 의 NGINX Plus 기반 버전을 직접 구매할 수 있다는 소식을 알려드리게 되어 기쁩니다.
이 마켓플레이스를 통해 AWS와의 파트너십을 계속 강화하여 고성능 있클라우드 네이티브 앱을 손쉽게 제공할 수 있습니다.
NGINX는 Kubernetes 배포를 프로덕션 수준으로 만들기 위한 두 가지 옵션을 제공합니다 .
빠른 확장성을 가능하게 하고, 셀프 서비스를 지원하는 Ingress 컨트롤러를 추가하는 것입니다 . 30일 동안 무료로 사용해 보세요 .
Kubernetes 앱이 성숙해짐에 따라 침해 및 단일 장애 지점의 위험을 줄이기 위해 보안을 강화해야 합니다.
Ingress 지점에 유연한 웹 애플리케이션 방화벽(WAF) 을 배포하면 WAF가 Kubernetes 앱에 더 가까워지고 별도의 WAF 장치가 필요 없게 됩니다.
30일 동안 무료로 사용해 보세요 .
AWS의 This is My Architecture 비디오 시리즈 의 이번 에피소드를 시청하면 NGINX Ingress Controller가
Elastic Kubernetes Service (EKS)를 사용하여 트래픽을 라우팅하고 보호하는 방법과
Elastic Container Registry (ECR)와 함께 Infrastructure-as-Code를 사용하여
애플리케이션 배포 및 버전 관리를 위한 자동화된 파이프라인을 구축하는 방법을 알아볼 수 있습니다.
지원 옵션
당사의 오퍼링은 F5의 Kubernetes 전문가가 지원합니다. 다음 지원 계층 중에서 선택할 수 있습니다 .
AWS에서 NGINX에 대해 자세히 알아보기
사이징 가이드 검토 – 특정 AWS 인스턴스 유형에서 달성할 수 있는 성능 수준 과 예상 월별 비용에 대한 개요를 확인하세요 .
웨비나 참석 – NGINX를 사용하여 Amazon EKS에서 보안 및 트래픽 가시성 강화 에서
Zipwhip의 수석 아키텍트와 대화하여 회사가 NGINX Ingress Controller와 AWS를 사용하여
Kubernetes로 전환하여 99.99% 가동 시간을 달성한 방법에 대해 알아보세요.
데모 보기 – 이 YouTube 재생 목록 에서는 AWS에서 NGINX를 사용하여 성능, 복원력 및 보안을 개선하는 여러 가지 방법을 보여줍니다.
비공개 제안 요청 – NGINX App Protect와 함께 NGINX Ingress Controller에 대한 맞춤 가격을 협상하여 연간 최대 20%까지 절약하세요.
자세한 내용은 당사에 문의하세요.
AWS 에서 NGINX Plus 사용해 보기 –
새로운 컨테이너 제안 외에도 AWS Marketplace에서
NGINX Plus (NGINX App Protect 포함 및 미포함)를 구매할 수도 있습니다.
지금 무료로 사용해 보세요 .