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