Why choose Istio?
Last updated
Was this helpful?
Last updated
Was this helpful?
Istio는 2017년 출시 당시 사이드카 기반 서비스 메시 개념을 선보였습니다. 프로젝트는 출시와 동시에 제로 트러스트 네트워킹을 위한 표준 기반 상호 TLS, 스마트 트래픽 라우팅, 메트릭/로그/추적을 통한 관찰 가능성 등 서비스 메시를 정의하는 기능들을 포함했습니다.이후 Istio는 멀티 클러스터 및 멀티 네트워크 토폴로지, WebAssembly를 통한 확장성, Kubernetes Gateway API 개발, 앰비언트 모드를 통한 메시 인프라의 애플리케이션 개발자로부터의 분리 등 메시 영역의 발전을 주도해왔습니다.Istio를 서비스 메시로 선택해야 하는 몇 가지 이유는 다음과 같습니다.
Kubernetes가 수백 개의 기능과 수십 개의 API를 가지고 있지만 단 하나의 명령으로 시작할 수 있는 것처럼, Istio도 같은 방식으로 구축되었습니다. 점진적 공개 원칙에 따라 작은 API 세트를 사용할 수 있으며, 필요한 경우에만 더 강력한 기능을 활성화할 수 있습니다. 다른 "단순한" 서비스 메시들은 Istio가 첫날부터 가지고 있던 기능 세트를 따라잡는 데 수년이 걸렸습니다.필요하지 않은 기능을 가지고 있는 것이, 필요한 기능이 없는 것보다 낫습니다!
처음부터 Istio는 Lyft에서 처음 개발한 고성능 서비스 프록시인 Envoy를 기반으로 했습니다. Istio는 Envoy를 채택한 첫 번째 프로젝트였으며, Istio 팀은 첫 외부 기여자였습니다. Envoy는 이후 Google Cloud의 로드 밸런서를 구동하는 프록시가 되었으며, 거의 모든 다른 서비스 메시 플랫폼의 프록시로도 사용되고 있습니다.Istio는 Envoy의 모든 강력함과 유연성을 상속받았으며, 여기에는 Istio 팀이 Envoy에서 개발한 WebAssembly를 사용한 세계 최고 수준의 확장성도 포함됩니다.
Istio는 진정한 커뮤니티 프로젝트입니다. 2023년에는 10개 회사가 각각 1,000개 이상의 기여를 했으며, 어떤 단일 회사도 25%를 초과하지 않았습니다. (여기에서 수치를 확인할 수 있습니다)다른 어떤 서비스 메시 프로젝트도 Istio만큼 업계의 폭넓은 지원을 받지 못하고 있습니다.
우리는 모든 릴리스에 대해 안정적인 바이너리를 모든 사람에게 제공하며, 앞으로도 계속 제공할 것을 약속합니다. 최신 릴리스와 이전 여러 릴리스에 대해 무료로 정기적인 보안 패치를 제공합니다. 많은 벤더들이 더 오래된 버전을 지원하지만, 우리는 안정적인 오픈 소스 프로젝트에서 안전하게 사용하기 위해 벤더와 계약하는 것이 필수가 되어서는 안 된다고 믿습니다.
좋은 설계 문서에는 고려되었지만 결국 거부된 대안들에 대한 섹션이 포함됩니다.
우리는 적절한 경우에 eBPF를 사용합니다! Istio는 eBPF를 사용하여 파드에서 프록시로 트래픽을 라우팅하도록 구성할 수 있습니다. 이는 iptables를 사용하는 것보다 약간의 성능 향상을 보여줍니다.왜 모든 것에 eBPF를 사용하지 않나요? 아무도 그렇게 하지 않습니다. 왜냐하면 실제로 아무도 그렇게 할 수 없기 때문입니다.eBPF는 Linux 커널 내부에서 실행되는 가상 머신입니다. 이는 커널 동작을 불안정하게 만들지 않기 위해 제한된 계산 범위 내에서 완료가 보장되는 함수들, 예를 들어 간단한 L3 트래픽 라우팅이나 애플리케이션 관찰 가능성을 수행하는 함수들을 위해 설계되었습니다. Envoy에서 볼 수 있는 것과 같은 장시간 실행되거나 복잡한 함수를 위해 설계되지 않았습니다. 그래서 운영 체제에 사용자 공간이 있는 것입니다! eBPF 유지 관리자들은 이론적으로 Envoy와 같이 복잡한 프로그램을 실행할 수 있도록 확장될 수 있다고 생각하지만, 이는 과학 프로젝트 수준이며 실제 세계에서 실용성을 가질 가능성은 낮습니다."eBPF를 사용한다"고 주장하는 다른 메시들은 실제로 노드당 Envoy 프록시나 다른 사용자 공간 도구를 많은 기능에 사용합니다.
Envoy는 본질적으로 멀티테넌트가 아닙니다. 결과적으로, 우리는 여러 제한되지 않은 테넌트의 L7 트래픽에 대한 복잡한 처리 규칙을 공유 인스턴스에서 혼합하는 것에 대해 중대한 보안 및 안정성 우려를 가지고 있습니다. Kubernetes는 기본적으로 모든 네임스페이스의 파드를 모든 노드에 스케줄링할 수 있기 때문에, 노드는 적절한 테넌시 경계가 되지 않습니다. 예산 책정과 비용 귀속도 주요 문제입니다. L7 처리는 L4보다 훨씬 더 많은 비용이 들기 때문입니다.앰비언트 모드에서, 우리는 ztunnel 프록시를 Linux 커널처럼 엄격하게 L4 처리로 제한합니다. 이는 취약점 표면적을 크게 줄이고 공유 컴포넌트를 안전하게 운영할 수 있게 합니다. 그런 다음 트래픽은 네임스페이스별로 작동하는 Envoy 프록시로 전달되어, 어떤 Envoy 프록시도 멀티테넌트가 되지 않도록 합니다.
오늘날 일부 CNI 플러그인들은 자체 CNI 구현 위에 서비스 메시와 유사한 기능을 애드온으로 제공하기 시작하고 있습니다. 예를 들어, 노드나 파드 간 트래픽에 대한 자체 암호화 방식을 구현하거나, 워크로드 식별을 지원하거나, L7 프록시로 트래픽을 리디렉션하여 일정 수준의 전송 계층 정책을 지원할 수 있습니다. 이러한 서비스 메시 애드온들은 비표준이며, 따라서 그것들을 제공하는 CNI에서만 작동할 수 있습니다. 또한 다양한 기능 세트를 제공합니다. 예를 들어, Wireguard 위에 구축된 솔루션은 FIPS 준수가 불가능합니다.이러한 이유로 Istio는 제로 트러스트 터널(ztunnel) 컴포넌트를 구현했습니다. 이는 검증된 업계 표준 암호화 프로토콜을 사용하여 투명하고 효율적으로 이러한 기능을 제공합니다. ztunnel에 대해 자세히 알아보세요.Istio는 일관되고 고도로 안전하며 효율적이고 표준을 준수하는 서비스 메시 구현을 제공하도록 설계되었습니다. 강력한 L7 정책 세트, 플랫폼에 구애받지 않는 워크로드 식별, 업계에서 검증된 mTLS 프로토콜을 사용하여 모든 환경, 모든 CNI, 심지어 다른 CNI를 가진 클러스터 간에도 사용할 수 있습니다.
