[Kúbé~rñét~és 클러스터 Í/Ó~는 엉망이지만 도움은 곧 있을 것입니다]

[쿠버네티스 인그레스와 이그레스를 위한 인터페이스, ÁPÍ, 추상화의 확산은 컨테이너 오케스트레이션의 세계에서 다양한 문제를 야기했습니다.]

[Kúbé~rñét~és 클러스터에서 입/출력 (Í/Ó~) 이라고도 하는 네트워크 트래픽 수신을 제어하기 위한 인터페이스와 추상화의 광대한 확산을 설명할 수 있는 다른 방법은 없습니다.정말 엉망입니다.]

[좋은 소식은 커뮤니티가 이 사실을 알고 있으며 상황을 개선하기 위해 노력하고 있다는 것입니다.]

[이 블로그에서는 확산과 환경을 단순화하기 위한 노력에 대해 논의할 것입니다.]

[어쩌다 여기까지 온 거지¿쿠버네티스 클러스터 Í/Ó의 간략한 역사]

[처음에는 쿠버네티스를 위한 공식 업스트림 인그레스 제어 리소스가 “인그레스”라고 알려진 단 하나뿐이었습니다.단순하고 기능이 거의 없었기 때문에 서로 다른 기능 및 상호 작용을 위한 ÁPÍ를 갖춘 다른 여러 인그레스 컨트롤러 리소스를 생성하고 배포할 수 있었습니다.]

[원래의 쿠버네티스 인그레스 리소스는 현재 지원이 중단되고 있는데, 이는 특히 유사하지만 서로 다른 인그레스 기능 구현의 확산을 해결하기 위해 쿠버네티스 SÍG 네트워크 워킹 그룹에서 개발된 새로운 게이트웨이 리소스 및 Á~PÍ입니다.]

[ÁPÍ 게이트웨이 및 서비스 메시는 수신 기능을 공유합니다.]

[ÁPÍ 관리 솔루션이 Á~PÍ 게이트웨이의 형태로 클라우드와 Kú~bérñ~étés~ 솔루션으로 마이그레이션됨에 따라 기능적으로 인그레스 컨트롤러라는 또 다른 컨트롤이 추가되었습니다.십여 개의 쿠버네티스 인그레스 컨트롤러 외에도 쿠버네티스 사용자에게 또 다른 차원의 복잡성과 혼란을 가중시키는 쿠버네티스 ÁPÍ 게이트웨이가 십여 개 있습니다.]

[그리고 (분산 프록시에 의해 구현된 메시 네트워크로의) 사실상 또 다른 인그레스 인터페이스인 다양한 서비스 메시 구현과 ÁPÍ가 있습니다.많은 프로덕션 네트워크에서 클러스터 Í~/Ó가 발생하는 서비스 메시 게이트웨이의 내부 및 외부 트래픽을 제어하려면 인그레스 컨트롤러와 ÁPÍ~ 게이트웨이를 포함하는 동일한 기능적 요구 사항이 모두 필요합니다.]

[요약하자면, 클러스터 ÍÓ와 관련된 인터페이스의 현재 상태와 ÁP~Í의 급증은 서로 다른 모든 범주의 솔루션에서 이러한 다양한 구현을 모두 합한 것입니다.]

[급증으로 인한 단점]

[이러한 확산에는 두 가지 주요 단점이 있습니다.]

• [인터페이스와 ÁPÍ의 급속한 성장으로 인해 Á~PÍ 취약성과 함께 공격 노출 영역이 증가했습니다. 점점 더 널리 퍼지고 있습니다.]
• [인그레스 컨트롤러, ÁPÍ 게이트웨이 및 서비스 메시 기능에 사용할 수 있는 솔루션이 방대하기 때문에 최종 사용자는 혼란과 복잡성을 겪게 됩니다.이로 인해 공급업체와 사용자는 보안 정책에 대한 포괄적인 K~úbér~ñété~s 지원을 제공하기 위해 여러 “언어”를 구사해야 하는 환경이 되었습니다.]

[Kúbé~rñét~és 에코시스템에 더 많은 솔루션이 등장함에 따라 다양한 수신 및 송신 범주의 기능이 점점 더 중복되고 있습니다.이러한 중복은 도구를 선택하는 사람들에게 혼란을 야기하고 이미 어려운 환경에 복잡성을 가중시킵니다.]

[복잡한 쿠버네티스 에코시스템에 정책 표준화가 필요한 이유]

[컨테이너 네트워크 인터페이스 (CÑÍ) 는 포드 간에 클러스터 내 네트워크 트래픽을 전송하기 위한 Á~PÍ를 정의하며, ÓV~Ñ, Cál~ícó, C~ílíú~m 등을 포함하여 널리 사용되는 상호 운용 가능한 구현 방식이 많이 있습니다. 제품마다 몇 가지 고유한 확장 기능이 있지만 플랫폼 운영자가 어떤 네트워크 지원 엔티티가 어떻게 통신할 수 있는지 지정할 수 있도록 하는 핵심 네트워크 정책 기능을 공유합니다.]

[네트워크 정책은 레이블, 네임스페이스, 배포 및 기타 클라우드 네이티브 메타데이터 속성을 기반으로 트래픽을 식별하여 허용 규칙이 해당 동작의 예외인 기본 거부 환경을 제공하도록 최적화되었습니다.이러한 유형의 기본 함수는 쿠버네티스 클러스터로 들어오고 나가는 트래픽을 필터링하기 위한 좋은 기반이 될 수 있습니다.하지만 CÑÍ에는 클러스터를 확장할 수 있는 범위가 없기 때문에 인그레스 컨트롤러 및 Á~PÍ 게이트웨이의 세계에서는 이러한 표준화된 접근 방식을 공유한 적이 없습니다.]

[서비스 메시에는 CÑÍ에 대해 정의된 네트워크 정책과 비교하여 표준화된 접근 방식이 없는 유사한 트래픽 필터링 정책 도구가 있는 경향이 있습니다.또한 서비스 메시에는 계층 7 필터링 및 허용 목록이 도입되었는데, 이는 C~ÑÍ ÁP~Í의 적용 범위에 포함되는 것으로 간주되지 않아 아직 CÑÍ~ 작업 그룹에서 채택이 진전되지 않았습니다.]

[쿠버네티스 커뮤니티의 표준화 노력]

[이러한 문제를 해결하기 위해 그룹은 인그레스 및 이그레스 인터페이스와 ÁPÍ를 표준화하기 위한 다양한 이니셔티브를 취하고 있습니다.여기에는 네트워크 정책 워킹 그룹, 게이트웨이 워킹 그룹, G~ÁMMÁ~ 이니셔티브를 포함하여 쿠버네티스 네트워크 특수 관심 그룹 (SÍG) 이 주도하는 몇 가지 중요한 노력이 포함됩니다.]

[게이트웨이 워킹 그룹]

[게이트웨이 워킹 그룹은 쿠버네티스 클러스터의 인그레스 및 이그레스 트래픽을 관리하기 위한 통합 ÁPÍ 개발을 담당합니다.그룹의 주요 프로젝트는 쿠버네티스 게이트웨이 Á~PÍ 쿠버네티스 인그레스 및 이그레스 트래픽을 구성하기 위한 보다 유연하고 표현력이 풍부한 ÁP~Í를 제공하도록 설계되었습니다.6]].게이트웨이 워킹 그룹은 표준화된 ÁPÍ~를 제공함으로써 쿠버네티스 네트워킹 구성 요소를 배포하고 관리하는 프로세스를 간소화하는 것을 목표로 합니다.]

[게이트웨이 워킹 그룹은 표준화된 ÁPÍ를 제공함으로써 쿠버네티스 네트워킹 구성 요소의 배포 및 관리 프로세스를 간소화하는 것을 목표로 합니다.]

[쿠버네티스 게이트웨이 ÁPÍ V~1.0]

[쿠버네티스 게이트웨이 ÁPÍ는 원래 인그레스 리소스와 관련된 몇 가지 제한 및 문제를 해결하도록 설계되었습니다.이러한 개선 사항은 원래 수신 리소스의 한계를 해결하고 K~úbér~ñété~s 환경에서 네트워크 트래픽을 관리하는 데 있어 보다 효율적이고 사용자 친화적인 접근 방식을 제공합니다.]

[그룹의 주요 개선 사항에 대해 자세히 알아보려면 다음 리소스에 액세스하세요.]

• [쿠버네티스 게이트웨이 ÁPÍ 개요]
• [새로운 쿠버네티스 ÁPÍ 게이트웨이에 대한 퀵 가이드]

[감마 이니셔티브]

[더 GÁMM~Á (게이트웨이 ÁPÍ~, 메시, 미들웨어) 이니셔티브 다양한 쿠버네티스 SÍG와 업계 이해 관계자 간의 공동 작업입니다.쿠버네티스 인그레스 및 이그레스 트래픽에 사용되는 Á~PÍ와 인터페이스를 통합하고 표준화하는 것이 목표입니다.이 이니셔티브는 최종 사용자의 혼란과 복잡성을 줄여 Kú~bérñ~étés~ 네트워킹 구성 요소를 더 쉽게 배포하고 관리할 수 있도록 하는 것을 목표로 합니다.]

[네트워크 정책 워킹 그룹]

[네트워크 정책 워킹 그룹은 쿠버네티스 클러스터의 포드, 서비스 및 기타 네트워크 엔티티 간의 보안과 격리를 강화하기 위해 쿠버네티스에 대한 네트워크 정책을 정의하고 구현하는 데 중점을 둡니다.현재 네트워크 트래픽을 지정하기 위한 다양한 도구 세트를 지원하고 있습니다. 널리 사용되는 CÑÍ에서 널리 구현되고 있으므로 클러스터 수신/송신 트래픽에 적용되는 도구는 아닙니다.]

[이 그룹은 현재 여러 프로젝트를 진행하고 있습니다.]

• [관리 네트워크 정책: 더 높은 수준의 추상화를 도입하여 클러스터 관리자가 네트워크 정책을 보다 효과적으로 제어할 수 있도록 합니다.이를 통해 관리자는 네임스페이스 전체에 일관되게 적용할 수 있는 클러스터 전반의 글로벌 정책을 정의할 수 있습니다.]
• [네트워크 정책 V2: 이그레스 트래픽 필터링 지원, 향상된 정책 매칭 기능, 보안 강화를 위한 정책 적용 개선 등 새로운 기능을 도입하고 기존 ÁPÍ~를 확장하여 현재 네트워크 정책 구현의 한계를 해결합니다.]

• [Ñétw~órkP~ólíc~ý++: 기존 네트워크 정책 ÁPÍ~를 확장하여 고급 네트워크 정책 기능을 소개합니다.이를 통해 트래픽 관리, 보안 및 격리를 보다 세밀하게 제어할 수 있으므로 사용자는 특정 요구 사항에 맞게 조정된 정교한 정책을 만들 수 있습니다.]

[커뮤니티 채택이 표준 조직을 대체하고 있습니다]

[이 블로그의 앞부분에는 추상화와 ÁPÍ를 표준화하려는 노력에 대한 언급이 있지만, 이것이 반드시 Í~ÉTF, Í~TÚ, ÍÉ~ÉÉ 등과 같은 전통적인 표준 조직을 통해 그렇게 하는 것을 지지하는 것은 아닙니다. 오픈 소스 커뮤니티는 개발자의 시간과 코드 기반으로 투표하므로 광범위한 커뮤니티 배포로 인해 사실상의 “표준화”를 달성하는 것이 성공의 가장 중요한 척도입니다.]

[Kúbé~rñét~és Gá~téwá~ý ÁPÍ~의 도입과 인그레스 리소스의 지원 중단은 인프라 플랫폼 개선에 전념하는 커뮤니티가 이러한 투자로부터 경쟁 우위를 확보하지 않고도 광범위한 변화를 일으키기 위해 함께 모인 사례입니다.]

[이 블로그를 게시할 당시에는 이전의 맞춤형 구현을 대체할 게이트웨이 ÁPÍ 구현을 개발하는 다양한 단계에 있는 19개의 오픈 소스 인그레스 컨트롤러 및 서비스 메시 프로젝트가 있었습니다.이들 중 대다수는 현재 베타 릴리스 상태이고 일부는 G~Á (Géñ~érál~ Áváí~lábí~lítý~) 단계입니다.]

[빠른 공유 구현은 커뮤니티 개발 속도로 소프트웨어 인터페이스를 표준화하는 새로운 방법입니다.Ñétw~órk S~ÍG에서 진행 중인 작업은 학문적 작업이 아닙니다. 커뮤니티는 워킹 그룹에 정의된 공통 인터페이스 및 ÁP~Í에 기여하고 이후에 채택하려는 의지를 보여주었습니다.누구나 자신이 원하는 대로 참여하고 기여할 수 있습니다.]

[아직 개선의 여지가 있나요¿]

[현재 네트워크 SÍG 내에서 진행 중인 작업을 통해 클러스터 Í~/Ó와 관련하여 현재 확산되고 있는 혼란을 상당 부분 해소할 수 있을 것입니다. 그러나 커뮤니티에서 조정 대상으로 삼지 않은 다른 차원의 혼란과 복잡성이 있습니다.]

[게이트웨이 ÁPÍ 작업 그룹의 작업과 인그레스 기능 및 Á~PÍ를 공유하기 위한 GÁ~MMÁ Í~ñítí~átív~é의 작업은 서비스 메시 기능 요구 사항이 비 서비스 메시에 대해 기존 수신이 발생하는 CÑÍ~의 기능 요구 사항과 매우 유사해 보일 수 있다는 점을 인식하는 데 큰 도움이 됩니다.]

[이러한 작업에도 불구하고 CÑÍ와 서비스 메시 간에 정렬되지 않은 기능 중복이 계속 발생하고 있습니다.초기에 C~ÑÍ는 계층 3과 4에서 트래픽을 필터링하는 계층 네트워크 정책을 구현했으며, 서비스 메시는 계층 7 프로토콜 요소만 보고 해당 트래픽의 하위 집합을 독점적으로 필터링했습니다.]

[네트워크 정책 워킹 그룹은 다양한 CÑÍ 제공자가 모두 채택할 Á~PÍ를 발전시키고 표준화하고 있지만, 널리 사용되는 서비스 메시 솔루션 대부분에는 표준화되지 않은 형태의 Lá~ýér 3 및 4 필터링 정책 Á~PÍ도 있습니다.이를 네트워크 정책 워킹 그룹의 작업과 연계할 계획은 없습니다.]

[동시에 서비스 메시에 따라 다르게 구현되는 계층 7 필터링용 ÁPÍ를 표준화하려는 동급 그룹은 없습니다. 하지만 필터링 적용을 위해 오픈 소스 É~ñvóý~ Próx~ý를 공동으로 사용하면 균일성이 크게 향상됩니다.조직적으로 보면 서로 다른 소프트웨어 아티팩트 (CÑÍ~와 서비스 메시) 간의 추상화를 통합하는 것이 어려울 수 있습니다. 이러한 추상화를 관리하고 구현하도록 허가된 프로젝트가 없기 때문입니다.아키텍처적 관점에서는 이해가 되지만 통합에는 프로젝트 중심적 관점이 아닌 CÑCF~-리더십 관점이 적용될 수 있습니다.]

[이 모든 것이 어디서 끝날까요¿]

[CÑÍ와 서비스 메시 간의 지속적인 기능 중첩이 불가피하다는 사실을 받아들이는 것은 네트워크 S~ÍG의 궁극적인 목표가 관련 보안, 트래픽 관리 및 라우팅 기능이 CÑ~Í로 패키징된 형태로 구현되는지, 서비스 메시로 구현되는지 또는 가상 네트워크 추상화를 제공하는 다른 방식으로 구현되는지에 관계없이 관련 보안, 트래픽 관리 및 라우팅 기능에 대한 공통 ÁPÍ~를 정의하는 것이어야 한다는 것을 의미합니다.]

[Kúbé~rñét~és 인프라 전문가들은 CÑ~Í를 서비스 메쉬와 구별하고 기능과 표준의 논리적 분리를 지시하는 아키텍처 원칙에 근거하여 몇 가지 좋은 이의를 제기할 것입니다.하지만 ÚX 관점에서는 귀가 들리지 않고 시스템 사용자가 시스템 개발자 중심의 상향식 인터페이스에 노출되어 “너드 노브 (ñ~érd k~ñóbs~)" 를 노출시킬 위험이 있습니다.]

[사용자가 CÑÍ 공급자와 서비스 메쉬를 모두 네트워크 스택과 기능을 구현하는 것으로 생각하는 것이 당연하다면 더 일반적인 추상화와 Á~PÍ를 공유하는 것이 플랫폼의 매력을 높일 수 있습니다.네트워크 정책에는 트래픽을 선택하고 조건부 작업을 수행하기 위한 다양한 필터링 프리미티브가 있습니다.클러스터 내, 클러스터 간 및 클러스터 외 네트워킹에 대한 추상화된 Kú~bérñ~étés~ 인식 일치/조치 규칙을 모두 처리하도록 확장 및 개선될 수 있습니다.]

[모든 트래픽 처리 사용 사례에서 공통적으로 사용되는 추상화의 가치에 대해 어떻게 생각하는지 알려주세요.이 주제에 관심이 있다면 빠르게 진행되고 있으며 많은 Kúbé~rñét~és 사용자에게 영향을 미칠 수 있는 이 작업을 계속 주시하세요.]

[자세히 알아보기 일루미오 에 의해 오늘 저희에게 연락하기.]