Ingress Controller 선택 가이드, Part 2: 위험 및 미래 대비
Ingress Controller 선택 가이드 1부에서 요구 사항을 식별하는 방법을 설명했습니다. 하지만 아직 제품을 테스트할 때가 아닙니다! 이 가이드에서는 잘못된 Ingress Controller가 릴리스 속도를 늦추고 고객에게 비용을 초래할 수 있는 방법을 설명합니다. 다른 도구와 마찬가지로 Ingress Controller는 위험을 초래하고 향후 확장성에 영향을 줄 수 있습니다. 득보다 실이 많을 수 있는 선택을 제거하는 방법을 살펴보겠습니다.
목차
1. Ingress Controller 위험(Risk)
1-1. 복잡성(Complexity) – 마이크로서비스 아키텍처(MSA)의 목적을 위배합니까?
1-2. 대기 시간(Latency) – Ingress Controller가 앱 속도를 늦추나요?
1-3. 보안(Security) – Ingress Controller가 해커의 문을 열어줍니까?
1-4. OpenResty 기반 Ingress Controller에 대한 참고 사항
2. Ingress Controller의 미래 대비
2-1. 인프라(Infrastructure) – 하이브리드 또는 다중 클라우드 환경에서 Kubernetes를 사용하시겠습니까?
2-2. 보안(Security) – 내부에서 Kubernetes를 어떻게 보호할 것인가?
2-3. 지원(Support) – 어떻게 “혼자서” 있을 수 있습니까?
3. 다음 단계: 옵션 좁히기
1. Ingress Controller 위험(Risk)
Kubernetes용 트래픽 관리 도구를 도입할 때 고려해야 하는 세 가지 특정 위험인 복잡성, 지연 시간 및 보안이 있습니다. 이러한 문제는 종종 서로 얽혀 있습니다. 하나가 있으면 다른 것도 볼 수 있습니다. 각각은 Ingress Controller에 의해 도입될 수 있으며 위험을 허용할 수 있는지 여부를 결정하는 것은 조직에 달려 있습니다. 오늘날의 소비자는 변덕스럽고, 뛰어난 기능 세트에도 불구하고 열악한 디지털 경험을 유발하는 모든 것이 용납되지 않을 수 있습니다.
1-1. 복잡성(Complexity) – 마이크로서비스 아키텍처(MSA)의 목적을 위배합니까?
최고의 Kubernetes 도구는 마이크로서비스 아키텍처의 목표인 가볍고 단순한 디자인을 충족하는 도구입니다. 이러한 원칙을 고수하는 매우 기능이 풍부한 Ingress Controller를 개발하는 것이 가능하지만 항상 표준은 아닙니다. 일부 디자이너는 너무 많은 기능을 포함하거나 복잡한 스크립팅을 사용하여 기본 엔진에 고유하지 않은 기능을 추가하여 Ingress Controller가 불필요하게 복잡해집니다.
그게 왜 중요한가요? Kubernetes에서 지나치게 복잡한 도구는 앱 성능에 부정적인 영향을 미치고 배포를 수평적으로 확장하는 능력을 제한할 수 있습니다. 일반적으로 크기에 따라 지나치게 복잡한 Ingress Controller를 찾을 수 있습니다. 설치 공간이 클수록 도구가 더 복잡해집니다.
1-2. 대기 시간(Latency) – Ingress Controller가 앱 속도를 늦추나요?
Ingress Controller는 리소스 사용량, 오류 및 시간 초과로 인해 지연 시간을 추가할 수 있습니다. 정적 및 동적 배포에 추가된 대기 시간을 살펴보고 내부 요구 사항에 따라 허용할 수 없는 대기 시간을 유발하는 옵션을 제거하십시오.
1-3. 보안(Security) – Ingress Controller가 해커의 문을 열어줍니까?
CVE(Common Vulnerabilities and Exposures)는 오늘날 인터넷에 만연하며 Ingress Controller 공급자가 CVE 패치를 제공하는 데 걸리는 시간은 안전과 침해의 차이가 될 수 있습니다. 조직의 위험 허용 범위에 따라 패치를 제공하는 데 며칠(또는 최대 몇 주) 이상 걸리는 솔루션을 제거할 수 있습니다.
CVE 외에도 일부 Ingress Controller는 또 다른 잠재적인 취약성에 노출됩니다. 다음 시나리오를 고려하십시오. 온라인 소매업체에서 일하고 오픈소스 Ingress Controller 구성 문제를 해결하는 데 도움이 필요합니다. 상업적 지원을 사용할 수 없으므로 Stack Overflow와 같은 포럼에 문제를 게시합니다. 누군가가 Ingress Controller 및 기타 Kubernetes 구성 요소에 대한 구성 및 로그 파일에서 문제를 찾고 싶어하고 도움을 주겠다고 제안합니다. 문제를 빨리 해결해야 한다는 압박감을 느끼며 파일을 공유합니다.
“착한 사마리아인”이 문제를 해결하는 데 도움이 되지만 6개월 후 고객 기록에서 신용 카드 번호가 도용된 위반 사항을 발견하게 됩니다. 죄송합니다. 공유한 파일에 앱에 침투하는 데 사용된 정보가 포함되어 있음이 밝혀졌습니다. 이 시나리오는 조직에서 지원 비용을 지불하기로 선택한 가장 큰 이유 중 하나인 기밀성을 보장한다는 것을 보여줍니다.
1-4. OpenResty 기반 Ingress Controller에 대한 참고 사항
OpenResty는 NGINX 오픈소스의 기능을 확장하기 위해 LuaJIT, Lua 스크립트 및 타사 NGINX 모듈을 통합하는 NGINX 오픈소스에 구축된 웹 플랫폼입니다. 차례로, OpenResty를 기반으로 구축된 여러 Ingress Controller가 있으며, NGINX Open Source 및 NGINX Plus 기반의 Ingress Controller에 비해 잠재적으로 두 가지 위험이 추가될 수 있다고 생각합니다.
시간 초과(Timeouts) – 언급한 바와 같이 OpenResty는 Lua 스크립팅을 사용하여 상용 NGINX Plus 기반 Ingress Controller와 같은 고급 기능을 구현합니다. 이러한 기능 중 하나는 동적 재구성으로, 가용성을 감소시키는 NGINX 오픈소스 요구 사항, 즉 서비스 Endpoint가 변경될 때 NGINX 구성을 다시 로드(reload)해야 하는 요구 사항을 제거합니다. OpenResty로 동적 재구성을 수행하기 위해 Lua 핸들러는 요청을 라우팅할 업스트림 서비스를 선택하므로 NGINX 구성을 다시 로드(reload)할 필요가 없습니다.
그러나 Lua는 리소스를 소모하는 Backend의 변경 사항을 지속적으로 확인해야 합니다. 들어오는 요청을 처리하는 데 시간이 더 오래 걸리므로 일부 요청이 중단되어 시간 초과 가능성이 높아집니다. 더 많은 사용자와 서비스로 확장함에 따라 초당 들어오는 요청 수와 Lua가 처리할 수 있는 수 사이의 격차가 기하급수적으로 넓어집니다. 그 결과 지연, 복잡성 및 더 높은 비용이 발생합니다.
동적 Kubernetes 클라우드 환경에서 성능 테스트 NGINX Ingress Controller를 읽고 Lua가 추가할 수 있는 대기 시간을 확인하십시오.
CVE 패치 지연 – NGINX의 Ingress Controller와 비교할 때 CVE용 패치는 NGINX 오픈소스를 기반으로 하는 OpenResty와 같은 도구를 기반으로 하는 Ingress Controller에 표시되는 데 필연적으로 더 오랜 시간이 걸립니다. NGINX Plus를 사용하여 빠르고 쉽게 보안 취약점 완화에 자세히 설명되어 있듯이 NGINX에서 CVE가 발견되면 일반적으로 CVE가 공개되기 전에 공급 업체인 우리에게 이를 알립니다. 이를 통해 CVE가 발표되는 즉시 NGINX 오픈소스 및 NGINX Plus용 패치를 출시할 수 있습니다.
NGINX 오픈소스를 기반으로 하는 기술은 그 시점까지 CVE에 대해 배우지 못할 수 있으며, 경험상 OpenResty 패치는 우리보다 상당히 뒤떨어져 있습니다. 최근 사례 중 하나는 4개월입니다. OpenResty를 기반으로 하는 Ingress Controlle용 패치는 필연적으로 더 많은 시간이 걸리므로 악의적인 사용자가 취약점을 악용할 수 있는 충분한 기회를 제공합니다.
2. Ingress Controller의 미래 대비
Kubernetes를 이제 막 다루기 시작했더라도 언젠가는 이를 프로덕션에 적용할 수 있는 좋은 기회가 있습니다. 시간이 지남에 따라 요구 사항이 증가할 가능성이 있는 네 가지 주요 영역인 인프라, 보안, 지원 및 다중 테넌트(multi-tenancy)가 있습니다.
2-1. 인프라(Infrastructure) – 하이브리드 또는 다중 클라우드 환경에서 Kubernetes를 사용하시겠습니까?
조직이 한 가지 유형의 환경에 완전히 영구적으로 전념하는 경우는 드뭅니다. 더 일반적으로 조직에는 프라이빗, 퍼블릭, 하이브리드 클라우드 및 멀티 클라우드가 포함될 수 있는 온프레미스와 클라우드가 혼합되어 있습니다.
이 가이드의 1부에서 언급했듯이 각 환경에 기본으로 제공되는 도구를 선택하고 싶은 마음이 들지만 기본 Ingress Controller와 관련된 많은 문제가 있습니다. 가이드의 3부에서 모든 단점을 다루지만 미래 보장과 가장 관련이 있는 문제는 공급업체 종속입니다. 모든 환경에서 클라우드 전용 Ingress Controller를 사용할 수는 없습니다. 기본 클라우드 전용 도구를 사용하면 매력적이지 않은 두 가지 대안이 남아 있기 때문에 확장 능력에 영향을 미칩니다.
- 모든 요구 사항에 대해 기존 클라우드를 작동시키십시오.
- 로드 밸런싱뿐만 아니라 보안까지 모든 구성을 다시 작성하십시오! – 각각의 새로운 환경의 Ingress Controller용
첫 번째 대안은 비즈니스상의 이유로 실행 가능하지 않은 경우가 많지만 두 번째 대안은 도구가 무분별하게 확산되고 새로운 보안 취약점이 발생하며 직원이 가파른 학습 곡선을 올라야 하기 때문에 까다롭습니다. 세 번째이자 가장 효율적인 대안은 처음부터 인프라에 구애받지 않는 Ingress Controller를 선택하여 모든 환경에서 동일한 도구를 사용할 수 있도록 하는 것입니다.
인프라와 관련하여 고려해야 할 또 다른 요소가 있습니다. 바로 인증입니다. Red Hat OpenShift Container Platform(OCP)의 예를 살펴보겠습니다. OCP 사용자라면 Red Hat Marketplace가 NGINX Ingress Operator를 포함하여 OCP에 대한 인증된 운영자를 제공한다는 사실을 이미 알고 계실 것입니다. Red Hat의 인증 표준은 도구가 배포와 함께 작동하고 Red Hat과 공급업체의 공동 지원도 포함할 수 있다는 사실을 알고 안심할 수 있음을 의미합니다. 많은 조직에서 보안 및 안정성을 위해 인증된 도구를 사용해야 하는 요구 사항이 있으므로 지금 테스트 중이더라도 프로덕션 환경에 대한 회사의 요구 사항을 염두에 두는 것이 좋습니다.
2-2. 보안(Security) – 내부에서 Kubernetes를 어떻게 보호할 것인가?
경계 보안만으로도 앱과 고객을 안전하게 보호할 수 있었던 시대는 지났습니다. Kubernetes 앱은 인증 및 권한 부여를 포함한 보안이 앱에 근접할 때 가장 잘 보호됩니다. 그리고 조직에서 end-to-end 종단 간 암호화를 요구하고 Kubernetes 내에서 제로 트러스트(zero-trust) 네트워크 모델을 채택함에 따라 Service Mesh가 미래에 나타날 수 있습니다.
이 모든 것이 Ingress Controller와 어떤 관련이 있습니까? 많이! Ingress 지점에서 보안(인증, 권한 부여, DoS 보호, 웹 애플리케이션 방화벽)을 중앙 집중화하는 것은 비용과 효율성의 관점에서 많은 의미가 있습니다. 그리고 대부분의 Service Mesh가 대부분의 Ingress Controller와 통합될 수 있지만 통합 방식이 매우 중요합니다. 보안 전략과 일치하는 Ingress Controller는 앱 개발 과정 전반에 걸쳐 큰 골칫거리를 예방할 수 있습니다.
2-3. 지원(Support) – 어떻게 “혼자서” 있을 수 있습니까?
팀이 Kubernetes를 실험할 때 커뮤니티 또는 회사의 지원이 최우선 순위가 아닌 경우가 많습니다. 팀이 자체 솔루션과 해결 방법을 제시할 시간이 많은 경우에는 괜찮지만 프로덕션으로 이동할 때는 지속 가능하지 않습니다. 현재 지원이 필요하지 않더라도 향후 지원을 추가할 수 있는 Ingress Controller를 선택하거나 확장에 따라 업그레이드할 수 있는 저렴한 지원 계층을 선택하는 것이 현명할 수 있습니다.
다중 테넌시(Multi-Tenancy) – 여러 팀과 앱이 어떻게 컨테이너 환경을 안전하고 안전하게 공유할 수 있습니까?
태초에 하나의 팀과 하나의 앱이 있었습니다. 모든 이야기가 그렇게 시작되는 것 아닙니까? 이야기는 종종 한 팀이 하나의 Kubernetes 앱을 성공적으로 개발하여 조직이 Kubernetes에서 더 많은 서비스를 실행하도록 이끄는 것으로 계속됩니다. 물론 더 많은 서비스 = 더 많은 팀 = 더 많은 복잡성.
최대 효율성을 달성하기 위해 조직은 멀티 테넌시를 채택하고 비즈니스 프로세스에서 요구하는 액세스 및 격리를 지원하는 동시에 운영자에게 필요한 온전성과 제어 기능을 제공하는 Kubernetes 모델을 채택합니다. 일부 Ingress Controller는 RBAC(역할 기반 액세스 제어) 설정을 지원하는 multiple ingress, class, 네임스페이스 및 범위가 지정된 리소스와 같은 여러 기능과 개념을 통해 이러한 클러스터를 분할하는 데 도움이 될 수 있습니다.
3. 다음 단계: 옵션 좁히기
이제 요구 사항, 위험 허용 범위 및 미래 보장에 대해 생각했으므로 Ingress Controller의 매우 광범위한 분야를 좁힐 수 있는 충분한 정보가 있습니다. 해당 필드를 범주별로 분류하면 이 단계를 빠르게 수행하는 데 도움이 될 수 있습니다.
댓글을 달려면 로그인해야 합니다.