.png)
Kubernetes 클러스터 I/O는 큰 난장판이지만 도움이 오고 있습니다.
Kubernetes 인그레스 및 이그레스를 위한 인터페이스, API, 추상화가 확산되면서 컨테이너 오케스트레이션의 세계에서 다양한 문제가 발생하고 있습니다.
구버네티스 클러스터에서 입출력(I/O)이라고도 하는 네트워크 트래픽이 들어오고 나가는 것을 제어하기 위한 인터페이스와 추상화의 방대한 확산을 설명할 수 있는 다른 방법은 없습니다. 엉망진창입니다.
좋은 소식은 커뮤니티가 이 사실을 인지하고 상황을 개선하기 위해 노력하고 있다는 것입니다.
이 블로그에서는 확산과 환경을 단순화하기 위한 노력에 대해 설명합니다.
어떻게 여기까지 왔나요? 쿠버네티스 클러스터 I/O의 간략한 역사
처음에는 단순히 "인그레스"라고 알려진 Kubernetes의 공식 업스트림 인그레스 제어 리소스가 하나뿐이었습니다. 이 리소스는 간단하고 최소한의 기능만 갖추고 있어 다양한 기능과 상호 작용을 위한 API를 갖춘 다른 여러 인그레스 컨트롤러 리소스를 생성 및 배포할 수 있었습니다.
원래의 쿠버네티스 인그레스 리소스는 현재 유사하지만 다른 인그레스 기능 구현의 확산을 해결하기 위해 특별히 쿠버네티스 SIG 네트워크 워킹 그룹에서 개발된 최신 게이트웨이 리소스 및 API를 위해 더 이상 사용되지 않는 과정에 있다.
API 게이트웨이와 서비스 메시가 인그레스 기능 공유
API 관리 솔루션이 클라우드와 API 게이트웨이 형태의 Kubernetes 솔루션으로 마이그레이션됨에 따라, 기능적으로 인그레스 컨트롤러인 또 다른 컨트롤이 추가되었습니다. 12개 정도의 Kubernetes 인그레스 컨트롤러 외에도, Kubernetes 사용자에게 또 다른 차원의 복잡성과 혼란을 더하는 12개 정도의 Kubernetes API 게이트웨이가 있습니다.
그리고 분산 프록시에 의해 구현된 메시 네트워크로의 또 다른 인그레스 인터페이스인 다양한 서비스 메시 구현과 API가 있습니다. 많은 프로덕션 네트워크에서 클러스터 I/O가 발생하는 서비스 메시 게이트웨이의 트래픽을 제어하려면 인그레스 컨트롤러와 API 게이트웨이를 구성하는 모든 동일한 기능 요구 사항이 필요합니다.
요약하자면, 클러스터 IO에 대한 인터페이스 및 API 확산의 현재 상태는 모든 다양한 솔루션 범주에서 이러한 모든 다양한 구현을 합친 것입니다.
확산의 단점
이러한 확산에는 두 가지 주요 단점이 있습니다:
- 인터페이스와 API의 급속한 성장으로 인해 공격 표면이 증가하면서 API 취약점이 더욱 널리 퍼지고 있습니다.
- 인그레스 컨트롤러, API 게이트웨이, 서비스 메시 기능에 사용할 수 있는 솔루션이 너무 많아서 최종 사용자에게 혼란과 복잡성을 야기합니다. 이로 인해 공급업체와 사용자는 보안 정책에 대한 포괄적인 Kubernetes 지원을 제공하기 위해 여러 "언어(" )를 사용해야 하는 환경이 조성되었습니다.
쿠버네티스 에코시스템에 더 많은 솔루션이 등장함에 따라 다양한 인그레스 및 이그레스 카테고리의 기능이 점점 더 중복되고 있습니다. 이러한 중복은 도구를 선택하는 사람들에게 혼란을 야기하고 이미 어려운 환경에 복잡성을 더합니다.
복잡한 쿠버네티스 에코시스템에 정책 표준화가 필요한 이유
컨테이너 네트워크 인터페이스(CNI)는 파드 간에 클러스터 내 네트워크 트래픽을 전송하기 위한 API를 정의하며, OVN, Calico, Cilium 등을 포함하여 널리 사용되는 상호 운용 가능한 구현이 많이 있습니다. 제품마다 몇 가지 고유한 확장 기능이 있지만, 플랫폼 운영자가 통신할 수 있는 네트워크 지원 개체를 지정하고 통신 방법을 지정할 수 있는 네트워크 정책 기능의 공통된 핵심을 공유합니다.
네트워크 정책은 레이블, 네임스페이스, 배포 및 기타 클라우드 네이티브 메타데이터 속성을 기반으로 트래픽을 식별하여 허용 규칙이 해당 동작의 예외가 되는 기본 거부 환경을 제공하도록 최적화되어 있습니다. 이들은 바로 Kubernetes 클러스터로 들어오고 나가는 트래픽을 필터링하는 데 좋은 기반이 될 수 있는 기본 함수 유형입니다. 그러나 CNI에는 클러스터 외 범위가 없기 때문에 인그레스 컨트롤러 및 API 게이트웨이의 세계에서 이 표준화된 접근 방식이 공유되지 않았습니다.
서비스 메시에는 CNI에 대해 정의된 네트워크 정책에 비해 표준화된 접근 방식이 없는 유사한 트래픽 필터링 정책 도구가 있는 경향이 있습니다. 또한 서비스 메시에는 CNI API의 범위로 간주되지 않았고 아직 CNI 워킹 그룹에서 채택이 진행되지 않은 레이어 7 필터링 및 허용 목록이 도입되었습니다.
쿠버네티스 커뮤니티의 표준화 노력
이러한 문제를 해결하기 위해 각 그룹은 인그레스 및 아웃그레스 인터페이스와 API를 표준화하기 위한 다양한 이니셔티브를 진행하고 있습니다. 여기에는 네트워크 정책 워킹 그룹, 게이트웨이 워킹 그룹, 감마 이니셔티브 등 쿠버네티스 네트워크 특별 관심 그룹(SIG)의 주도하에 이루어지는 몇 가지 중요한 노력이 포함됩니다.
게이트웨이 워킹 그룹
게이트웨이 워킹 그룹은 쿠버네티스 클러스터에서 수신 및 송신 트래픽을 관리하기 위한 통합 API를 개발하는 일을 담당합니다. 이 그룹의 주요 프로젝트는 Kubernetes 인그레스 및 이그레스 트래픽을 구성하기 위한 보다 유연하고 표현력이 풍부한 API를 제공하도록 설계된 Kubernetes 게이트웨이 API입니다6]]. 게이트웨이 워킹 그룹은 표준화된 API를 제공함으로써 Kubernetes 네트워킹 구성 요소를 배포하고 관리하는 프로세스를 간소화하는 것을 목표로 합니다.
게이트웨이 워킹 그룹은 표준화된 API를 제공함으로써 Kubernetes 네트워킹 구성 요소를 배포하고 관리하는 프로세스를 간소화하는 것을 목표로 합니다.
쿠버네티스 게이트웨이 API V1.0
쿠버네티스 게이트웨이 API는 원래의 인그레스 리소스와 관련된 몇 가지 제한 사항과 문제를 해결하도록 설계되었습니다. 이러한 개선 사항은 원래 인그레스 리소스의 한계를 해결하고 Kubernetes 환경에서 네트워크 트래픽을 관리하기 위한 보다 효율적이고 사용자 친화적인 접근 방식을 제공합니다.
그룹의 주요 개선 사항에 대해 자세히 알아보려면 다음 리소스에 액세스하세요:
감마 이니셔티브
GAMMA(게이트웨이 API, 메시 및 미들웨어) 이니셔티브는 다양한 쿠버네티스 SIG와 업계 이해관계자 간의 협력 노력입니다. 이 프로젝트의 목표는 쿠버네티스 인그레스 및 이그레스 트래픽에 사용되는 API와 인터페이스를 통합하고 표준화하는 것입니다. 이 이니셔티브는 최종 사용자의 혼란과 복잡성을 줄여 Kubernetes 네트워킹 구성 요소를 더 쉽게 배포하고 관리할 수 있도록 하는 것을 목표로 합니다.
네트워크 정책 워킹 그룹
네트워크 정책 워킹 그룹은 쿠버네티스 클러스터의 파드, 서비스 및 기타 네트워크 엔티티 간의 보안과 격리를 강화하기 위해 쿠버네티스를 위한 네트워크 정책을 정의하고 구현하는 데 중점을 두고 있다. 현재 네트워크 트래픽을 지정하기 위한 다양한 도구를 지원하며, 널리 사용되는 CNI에서 널리 구현되므로 클러스터 인그레스/이그레스 트래픽에 적용되는 도구는 아닙니다.
이 그룹은 현재 여러 프로젝트를 진행 중입니다:
- 관리 네트워크 정책: 더 높은 수준의 추상화를 도입하여 클러스터 관리자에게 네트워크 정책을 더 잘 제어할 수 있는 기능을 제공합니다. 이를 통해 관리자는 네임스페이스 전체에 일관되게 적용할 수 있는 글로벌 클러스터 전체 정책을 정의할 수 있습니다.
- 네트워크 정책 V2: 송신 트래픽 필터링 지원, 향상된 정책 매칭 기능, 보안 강화를 위한 정책 시행 개선 등 새로운 기능을 도입하고 기존 API를 확장하여 현재 네트워크 정책 구현의 한계를 해결합니다.
- NetworkPolicy++: 기존 네트워크 정책 API를 확장하여 고급 네트워크 정책 기능을 도입합니다. 이를 통해 트래픽 관리, 보안 및 격리를 보다 세밀하게 제어할 수 있으므로 사용자는 특정 요구사항에 맞는 정교한 정책을 만들 수 있습니다.
커뮤니티 채택이 표준 조직을 대체하고 있습니다.
이 블로그의 앞부분에서 추상화 및 API를 표준화하려는 노력에 대해 언급했지만, 이것이 반드시 IETF, ITU, IEEE 등과 같은 전통적인 표준 단체를 통한 표준화를 지지하는 것은 아닙니다. 오픈소스 커뮤니티는 개발자의 시간과 코드 기반으로 투표를 하기 때문에 광범위한 커뮤니티 배포를 통해 사실상의 '표준화'를 달성하는 것이 가장 중요한 성공의 척도입니다.
쿠버네티스 게이트웨이 API의 도입과 인그레스 리소스의 사용 중단은 인프라 플랫폼 개선에 전념하는 커뮤니티가 함께 모여 투자에 따른 경쟁 우위를 얻지 않고도 광범위한 변화를 이룬 사례입니다.
이 블로그 게시 시점에는 19개의 오픈 소스 인그레스 컨트롤러 및 서비스 메시 프로젝트가 이전의 맞춤형 구현을 대체하기 위해 게이트웨이 API 구현을 개발하는 다양한 단계에 있었습니다. 이 중 대부분은 현재 베타 버전으로 출시되어 있으며 일부는 정식 버전(GA)으로 출시되었습니다.
빠른 공유 구현은 커뮤니티 개발 속도에 맞춰 소프트웨어 인터페이스를 표준화할 수 있는 새로운 방법입니다. 네트워크 SIG에서 수행되는 작업은 학술적인 작업이 아니며, 커뮤니티는 워킹 그룹에서 정의된 공통 인터페이스와 API에 기여하고 이후 이를 채택하려는 의지를 보여 왔습니다. 누구나 원하는 대로 참여하여 기여할 수 있습니다.
아직 개선의 여지가 있나요?
현재 네트워크 SIG 내에서 진행 중인 작업은 클러스터 I/O와 관련하여 현재 존재하는 확산 문제를 상당 부분 정리할 것입니다. 그러나 커뮤니티에서 조율의 대상이 되지 않은 다른 차원의 혼란과 복잡성도 존재합니다.
인그레스 기능과 API를 게이트웨이 API 작업 그룹의 작업과 공유하기 위한 GAMMA 이니셔티브의 작업은 서비스 메시 기능 요구 사항이 비서비스 메시에서 기존 인그레스가 발생하는 CNI와 매우 유사할 수 있다는 점을 인식하는 데 큰 도움이 됩니다.
이러한 작업에도 불구하고 CNI와 서비스 메시 간에 조정되지 않은 기능적 중복이 계속 발생하고 있습니다. 초기에 CNI는 레이어 3과 4에서 트래픽을 필터링하는 레이어 네트워크 정책을 구현했고, 서비스 메시에서는 레이어 7 프로토콜 요소만 보고 해당 트래픽의 하위 집합을 필터링했습니다.
네트워크 정책 워킹 그룹은 모든 다양한 CNI 제공업체가 채택할 API를 발전시키고 표준화하고 있지만, 대부분의 인기 있는 서비스 메시 솔루션에는 표준화되지 않은 형태의 레이어 3 및 4 필터링 정책 API도 있습니다. 네트워크 정책 워킹 그룹의 작업과 이를 연계할 계획은 없습니다.
동시에, 서비스 메시마다 다르게 구현되는 레이어 7 필터링용 API를 표준화하려는 동등한 그룹은 없습니다(필터링 적용을 위해 오픈 소스 Envoy 프록시를 공동으로 사용함으로써 훨씬 더 균일한 결과를 가져올 수 있지만). 조직적으로는 이를 신경 쓰고 구현하기 위해 공인된 프로젝트가 없기 때문에 서로 다른 소프트웨어 아티팩트(CNI와 서비스 메시) 간의 추상화를 통합하는 것이 어려울 수 있습니다. 아키텍처 관점에서는 이해가 되지만, 통합은 프로젝트 중심이 아닌 CNCF 리더십 관점이 필요할 수 있습니다.
이 모든 것이 어떻게 끝날까요?
CNI와 서비스 메시 간의 지속적인 기능 중복이 불가피하다는 점을 인정한다면, 네트워크 SIG의 목표는 궁극적으로 관련 보안, 트래픽 관리 및 라우팅 기능이 CNI, 서비스 메시 또는 가상 네트워크 추상화를 제공하는 다른 방식으로 구현되는지 여부에 관계없이 관련 보안, 트래픽 관리 및 라우팅 기능을 위한 공통 API를 정의하는 것이어야 한다는 의미입니다.
쿠버네티스 인프라 전문가들은 CNI와 서비스 메시를 구분하고 기능과 표준의 논리적 분리를 지시하는 아키텍처 원칙에 따라 몇 가지 좋은 이의를 제기할 것입니다. 그러나 UX 관점에서 볼 때, 시스템 개발자가 중심이 된 상향식 인터페이스로 인해 시스템 사용자가 "괴짜 노브"에 노출될 수 있는 위험이 있습니다.
사용자가 CNI 제공자와 서비스 메시를 모두 네트워크 스택과 기능을 구현하는 것으로 생각하는 것이 자연스럽다면, 보다 일반적인 추상화와 API를 공유하는 것이 플랫폼의 매력을 높일 수 있습니다. 네트워크 정책에는 트래픽을 선택하고 조건부 작업을 수행하기 위한 다양한 필터링 기본 요소 집합이 있습니다. 클러스터 내, 클러스터 간 및 클러스터 외 네트워킹을 위해 추상화된 모든 Kubernetes 인식 일치/작업 규칙을 처리하도록 확장 및 개선할 수 있습니다.
모든 트래픽 처리 사용 사례에서 공통 추상화의 가치에 대해 어떻게 생각하는지 알려주세요. 이 주제에 관심이 있으시다면 빠르게 진행 중이며 많은 Kubernetes 사용자에게 영향을 미칠 이 작업을 주시해 주세요.
.webp)
