Ingress 컨트롤러 선택 가이드, 2부: 위험과 미래 대비

편집자 - 이 게시물은 10부작 시리즈의 일부입니다.

1. 프로덕션 등급 Kubernetes로 복잡성 감소
2. 고급 트래픽 관리를 사용하여 Kubernetes의 복원력을 개선하는 방법
3. Kubernetes에서 가시성을 개선하는 방법
4. 트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법
5. Ingress 컨트롤러 선택 가이드, 1부: 귀하의 요구 사항을 식별하세요
6. Ingress 컨트롤러 선택 가이드, 2부: 위험과 미래 보호(이 게시물)
7. Ingress 컨트롤러 선택 가이드, 3부: 오픈소스 대 기본값 대비 광고
8. Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress 컨트롤러 옵션
9. 서비스 메시를 선택하는 방법
10. 동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트

또한 전체 블로그 세트를 무료 전자책인 ' 테스트에서 프로덕션까지 Kubernetes 활용' 으로 다운로드할 수 있습니다.

Ingress 컨트롤러 선택 가이드의 1부에서는 요구 사항을 식별하는 방법을 설명했습니다. 하지만 아직 제품을 테스트할 때가 아닙니다! 이 게시물에서는 잘못된 Ingress 컨트롤러가 어떻게 릴리스 속도를 늦추고 심지어 고객 손실을 초래할 수 있는지 설명합니다. 모든 도구와 마찬가지로 Ingress 컨트롤러를 사용하면 위험이 발생하고 향후 확장성에 영향을 미칠 수 있습니다. 이로운 것보다 해로운 결과를 초래할 수 있는 선택을 제거하는 방법을 살펴보겠습니다.

Ingress 컨트롤러 위험

Kubernetes를 위한 트래픽 관리 도구를 도입할 때 고려해야 할 세 가지 위험은 복잡성, 지연 시간, 보안입니다. 이러한 문제는 종종 서로 얽혀 있습니다. 하나가 나타나면 다른 것도 보일 가능성이 큽니다. 각각은 Ingress 컨트롤러에 의해 도입될 수 있으며 위험이 허용 가능한지 여부는 조직에서 결정해야 합니다. 오늘날의 소비자는 변덕스럽고, 매력적인 기능 세트가 있더라도 디지털 경험을 저하시키는 것은 용납할 수 없습니다.

복잡성 - 마이크로서비스 아키텍처의 목적을 저해하는가?

최고의 쿠버네티스 도구는 마이크로서비스 아키텍처의 목표, 즉 가볍고 설계가 간단한 것을 충족하는 도구입니다. 이러한 원칙을 고수하면서 기능이 매우 풍부한 Ingress 컨트롤러를 개발하는 것은 가능하지만 항상 그런 것은 아닙니다. 일부 디자이너는 기본 엔진에 기본이 아닌 기능을 추가하기 위해 너무 많은 기능을 포함하거나 복잡한 스크립팅을 사용하여 불필요하게 복잡한 Ingress 컨트롤러를 생성합니다.

그게 왜 중요한가요? Kubernetes에서 지나치게 복잡한 도구는 앱 성능에 부정적인 영향을 미치고 배포를 수평적으로 확장하는 능력을 제한할 수 있습니다. 일반적으로 Ingress 컨트롤러가 지나치게 복잡한지는 크기로 알 수 있습니다. 크기가 클수록 도구가 더 복잡해집니다.

지연 시간 - Ingress 컨트롤러가 앱 속도를 저하시키나요?

Ingress 컨트롤러는 리소스 사용, 오류, 시간 초과로 인해 지연 시간을 추가할 수 있습니다. 정적 및 동적 배포에서 추가되는 지연 시간을 살펴보고 내부 요구 사항에 따라 허용할 수 없는 지연 시간을 발생시키는 옵션을 제거하세요. 재구성이 앱 속도에 어떤 영향을 미치는지에 대한 자세한 내용은 블로그의 동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트를 참조하세요.

보안 – Ingress 컨트롤러가 해커에게 문을 열어줄까?

오늘날 인터넷에는 일반적인 취약점 및 노출(CVE)이 만연해 있으며 Ingress 컨트롤러 공급자가 CVE 패치를 제공하는 데 걸리는 시간은 안전과 침해의 차이가 될 수 있습니다. 조직의 위험 허용 범위에 따라 패치를 제공하는 데 며칠 이상(또는 최대 몇 주)이 걸리는 솔루션을 제거하는 것이 좋습니다.

CVE 외에도 일부 Ingress 컨트롤러는 다른 잠재적 취약점에 노출시킬 수 있습니다. 다음과 같은 시나리오를 생각해 보세요. 여러분은 온라인 소매업체에서 일하고 있으며 오픈 소스 Ingress 컨트롤러 구성의 문제 해결에 도움이 필요합니다. 상업적 지원이 제공되지 않으므로 Stack Overflow와 같은 포럼에 문제를 게시합니다. 누군가가 도와주겠다고 제안하고 Ingress 컨트롤러와 다른 Kubernetes 구성 요소의 구성 및 로그 파일에서 문제를 찾고 싶어합니다. 문제를 빨리 해결해야 한다는 압박감을 느껴서 파일을 공유합니다.

"착한 사마리아인"이 귀하의 문제를 해결하도록 도와주지만 6개월 후에 침해 사실을 발견하게 됩니다. 고객 기록에서 신용카드 번호가 도용된 것입니다. 어머나. 당신이 공유한 파일에는 앱에 침투하는 데 사용된 정보가 포함되어 있었습니다. 이 시나리오는 조직이 지원 비용을 지불하기로 선택하는 가장 큰 이유 중 하나를 보여줍니다. 기밀성이 보장되기 때문입니다.

OpenResty 기반 Ingress 컨트롤러에 대한 참고 사항

OpenResty는 NGINX 오픈 소스 기반으로 구축된 웹 플랫폼으로, LuaJIT, Lua 스크립트, 타사 NGINX 모듈을 통합하여 NGINX 오픈 소스의 기능을 확장합니다. 차례로, OpenResty에 기반한 여러 Ingress 컨트롤러가 있으며, 이는 NGINX Open Source 및 NGINX Plus에 기반한 Ingress 컨트롤러와 비교할 때 잠재적으로 두 가지 위험을 추가할 수 있다고 생각합니다.

• 시간 초과 – 앞서 언급했듯이 OpenResty는 당사의 상용 NGINX Plus 기반 Ingress Controller와 같은 고급 기능을 구현하기 위해 Lua 스크립팅을 사용합니다. 이러한 기능 중 하나는 동적 재구성으로, 가용성을 저하시키는 NGINX 오픈 소스 요구 사항, 즉 서비스 엔드포인트가 변경될 때 NGINX 구성을 다시 로드해야 한다는 요구 사항을 제거합니다. OpenResty를 사용하여 동적 재구성을 달성하기 위해 Lua 핸들러는 요청을 라우팅할 업스트림 서비스를 선택하므로 NGINX 구성을 다시 로드할 필요가 없습니다.

  그러나 Lua는 백엔드의 변경 사항을 지속적으로 확인해야 하므로 리소스가 소모됩니다. 들어오는 요청을 처리하는 데 시간이 더 오래 걸리므로 일부 요청이 중단되고 이로 인해 시간 초과가 발생할 가능성이 커집니다. 더 많은 사용자와 서비스로 확장할수록 초당 수신 요청 수와 Lua가 처리할 수 있는 요청 수 사이의 격차는 기하급수적으로 커집니다. 결과적으로 지연, 복잡성, 높은 비용이 발생합니다.

  동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러의 성능 테스트를 읽고 Lua가 얼마나 많은 지연 시간을 추가할 수 있는지 확인하세요.

• CVE 패치 지연 – NGINX의 Ingress 컨트롤러와 비교했을 때 CVE 패치는 NGINX 오픈 소스를 기반으로 하는 OpenResty와 같은 도구를 기반으로 하는 Ingress 컨트롤러에 표시되는 데 필연적으로 더 오랜 시간이 걸립니다. NGINX Plus를 사용하여 보안 취약점을 빠르고 쉽게 완화하는 방법 에서 자세히 설명한 대로 NGINX에서 CVE가 발견되면 일반적으로 공급업체인 당사는 CVE가 공개되기 전에 통보를 받습니다. 이를 통해 CVE가 발표되자마자 NGINX 오픈 소스와 NGINX Plus에 대한 패치를 출시할 수 있습니다.

  NGINX 오픈 소스 기반 기술은 그 시점까지 CVE에 대해 알지 못할 수도 있고, 우리의 경험에 따르면 OpenResty 패치는 우리 패치보다 상당히 뒤처집니다. 최근 사례에서는 4개월이 걸렸습니다. OpenResty 기반 Ingress 컨트롤러에 대한 패치는 필연적으로 더 많은 시간이 걸리므로, 나쁜 행위자가 취약점을 악용할 수 있는 충분한 기회를 제공합니다.

Ingress 컨트롤러를 미래에 대비하세요

Kubernetes를 막 사용하기 시작했더라도 언젠가는 이를 프로덕션에 적용하고 싶어할 가능성이 큽니다. 시간이 지남에 따라 요구 사항이 증가할 가능성이 있는 네 가지 주요 영역은 인프라, 보안, 지원 및 다중 테넌시입니다.

인프라 – 하이브리드 또는 멀티 클라우드 환경에서 Kubernetes를 사용할 것인가?

한 조직이 한 가지 유형의 환경에 완전하고 영구적으로 헌신하는 경우는 드뭅니다. 더 일반적으로 조직에서는 온프레미스와 클라우드를 혼합하여 사용합니다. 여기에는 프라이빗 클라우드, 퍼블릭 클라우드, 하이브리드 클라우드, 멀티 클라우드가 포함될 수 있습니다. (이러한 환경의 차이점에 대해 자세히 알아보려면 멀티 클라우드와 하이브리드 클라우드의 차이점은 무엇인가요?를 읽어보세요.)

이 시리즈의 1부 에서 언급했듯이 각 환경에 기본적으로 제공되는 도구를 선택하고 싶은 마음이 들지만 기본 Ingress 컨트롤러에만 있는 문제가 많이 있습니다. 시리즈의 3부에서는 모든 단점을 다루겠지만, 미래 지향적인 측면에서 가장 중요한 문제는 공급업체 종속성입니다. 즉, 모든 환경에서 클라우드 전용 Ingress 컨트롤러를 사용할 수 없습니다. 기본 클라우드 전용 툴을 사용하면 두 가지 매력적이지 않은 대안만 남게 되어 확장 능력에 영향을 미칩니다.

1. 기존 클라우드를 모든 요구 사항에 맞게 작동하도록 하세요.
2. 부하 분산뿐만 아니라 보안까지 모든 구성을 다시 작성하세요! – 각 새 환경의 Ingress 컨트롤러를 위해

첫 번째 대안은 비즈니스상의 이유로 실행 불가능한 경우가 많고, 두 번째 대안도 도구 확산을 초래하고, 새로운 보안 취약점을 노출시키며, 직원들이 가파른 학습 곡선을 거쳐야 하기 때문에 까다롭습니다. 세 번째이자 가장 효율적인 대안은 처음부터 인프라에 독립적인 Ingress 컨트롤러를 선택하여 모든 환경에서 동일한 도구를 사용하는 것입니다.

인프라와 관련해서 고려해야 할 또 다른 요소는 바로 인증입니다. Red Hat OpenShift Container Platform(OCP)의 예를 들어보겠습니다. OCP 사용자라면 Red Hat Marketplace에서 NGINX Ingress Operator를 포함한 OCP용 인증 운영자를 제공한다는 사실을 이미 알고 계실 겁니다. Red Hat의 인증 표준은 해당 도구가 배포된 환경에서 작동한다는 사실과 Red Hat과 공급업체의 공동 지원도 포함될 수 있다는 사실을 알면 마음이 편안해집니다. 많은 조직에서는 보안 및 안정성 이유로 인증된 도구를 사용해야 하므로, 지금은 테스트 단계에 있더라도 회사의 프로덕션 환경 요구 사항을 염두에 두는 것이 좋습니다.

보안 – 내부에서 Kubernetes를 어떻게 보호할 것인가?

경계 보안만으로 앱과 고객을 안전하게 보호할 수 있었던 시대는 지났습니다. 보안(인증 및 권한 부여 포함)이 앱과 가까운 경우 Kubernetes 앱이 가장 잘 보호됩니다. 조직에서 종단 간 암호화를 점점 더 의무화하고 Kubernetes 내에서 제로 트러스트 네트워크 모델을 채택함에 따라 서비스 메시가 미래에 필요할 수 있습니다.

이 모든 것이 Ingress 컨트롤러와 어떤 관련이 있나요? 많이! Ingress 지점에서 보안(인증, 권한 부여, DoS 보호, 웹 애플리케이션 방화벽)을 중앙 집중화하는 것은 비용과 효율성 측면에서 매우 합리적입니다. 대부분의 서비스 메시는 대부분 Ingress 컨트롤러와 통합될 수 있지만, 통합 방식이 매우 중요합니다. 보안 전략에 맞는 Ingress 컨트롤러를 사용하면 앱 개발 과정 전체에서 큰 문제를 예방할 수 있습니다.

속도 저하 없이 클라우드 네이티브 앱 보안하기에서 클라우드 네이티브 앱 제공의 위험에 대한 자세한 내용을 읽고, Kubernetes에서 애플리케이션 서비스 배포, 2부에서 보안 도구에 가장 적합한 위치를 결정하는 요소에 대해 자세히 알아보세요.

지원 – 얼마나 "혼자서" 살 수 있을까요?

팀이 Kubernetes를 처음 실험할 때 커뮤니티나 회사의 지원은 최우선 순위가 아닌 경우가 많습니다. 팀이 자체 솔루션과 해결 방법을 생각해 낼 시간이 충분하다면 괜찮지만, 프로덕션으로 전환하면 지속 가능하지 않습니다. 지금은 지원이 필요하지 않더라도 나중에 지원을 추가할 수 있는 Ingress 컨트롤러를 선택하거나 확장하면서 업그레이드할 수 있는 저렴한 지원 계층을 제공하는 것이 현명할 수 있습니다.

다중 테넌시 - 여러 팀과 앱이 컨테이너 환경을 안전하고 보안적으로 공유할 수 있는 방법은 무엇입니까?

처음에는 하나의 팀과 하나의 앱만 있었습니다. 모든 스토리가 그렇게 시작되는 게 아닐까요? 종종 이러한 이야기는 한 팀이 하나의 Kubernetes 앱을 성공적으로 개발하여 조직이 Kubernetes에서 더 많은 서비스를 실행하게 된다는 내용으로 이어진다. 물론, 서비스가 많아질수록 팀도 많아지고 복잡성도 커집니다.

최대의 효율성을 달성하기 위해 조직은 멀티 테넌시를 채택하고 Kubernetes 모델을 도입합니다. 이는 비즈니스 프로세스에서 요구하는 액세스 및 격리를 지원하면서 동시에 운영자에게 필요한 정신 건강과 제어 기능을 제공합니다. 일부 Ingress 컨트롤러는 여러 가지 기능과 개념(역할 기반 액세스 제어(RBAC) 설정을 지원하는 여러 Ingress, 클래스, 네임스페이스 및 범위가 지정된 리소스)을 통해 클러스터를 분할하는 데 도움을 줄 수 있습니다.

다음 단계: 옵션 좁히기

이제 요구 사항, 위험 허용 범위, 미래 대비에 대해 생각해 보았으므로 매우 광범위한 Ingress 컨트롤러 범위를 좁히기에 충분한 정보를 얻었습니다. 해당 분야를 범주별로 분류하면 이 단계를 빠르게 완료하는 데 도움이 될 수 있습니다. 이 시리즈의 3부에서는 Ingress 컨트롤러의 세 가지 범주를 살펴보고 각 범주의 장단점도 알아보겠습니다.