Why choose Istio?

왜 Istio를 선택해야 할까요?

Istio는 2017년 출시될 때 사이드카 기반 서비스 메시의 개념을 선도했습니다. 프로젝트 초기부터 제로 트러스트 네트워킹을 위한 표준 기반 상호 TLS, 스마트 트래픽 라우팅, 메트릭/로그/추적을 통한 가시성 등 서비스 메시를 정의하는 기능들을 포함하고 있었습니다.그 이후로 Istio 프로젝트는 멀티 클러스터 및 멀티 네트워크 토폴로지, WebAssembly를 통한 확장성, Kubernetes Gateway API 개발, 앰비언트 모드를 통한 애플리케이션 개발자로부터의 메시 인프라 분리 등 메시 영역에서의 발전을 주도해 왔습니다.다음은 Istio를 서비스 메시로 사용해야 하는 몇 가지 이유입니다.

단순하면서도 강력함

쿠버네티스에는 수백 가지 기능과 수십 개의 API가 있지만, 단 하나의 명령으로 시작할 수 있습니다. 우리는 Istio도 같은 방식으로 구축했습니다. 점진적 공개(Progressive disclosure) 방식을 통해 작은 API 집합을 사용할 수 있으며, 필요한 경우에만 더 강력한 기능을 켤 수 있습니다. 다른 "단순한" 서비스 메시들은 Istio가 첫날부터 가지고 있던 기능 세트를 따라잡는 데 수년이 걸렸습니다.기능이 있어도 필요하지 않은 것이, 필요할 때 없는 것보다 낫습니다!

Envoy 프록시

Istio는 처음부터 Lyft에서 초기에 구축한 고성능 서비스 프록시인 Envoy 프록시로 구동되었습니다. Istio는 Envoy를 채택한 최초의 프로젝트였으며, Istio 팀은 최초의 외부 커미터였습니다. Envoy는 Google Cloud를 구동하는 로드 밸런서뿐만 아니라 거의 모든 다른 서비스 메시 플랫폼의 프록시가 되었습니다.Istio는 Istio 팀에 의해 Envoy에서 개발된 WebAssembly를 사용한 세계 최고 수준의 확장성을 포함하여 Envoy의 모든 힘과 유연성을 계승합니다.

커뮤니티

Istio는 진정한 커뮤니티 프로젝트입니다. 2023년에는 Istio에 1,000개 이상의 기여를 한 10개 회사가 있었으며, 어떤 회사도 25%를 넘지 않았습니다. (여기에서 숫자를 확인하세요)Istio만큼 업계의 폭넓은 지원을 받는 다른 서비스 메시 프로젝트는 없습니다.

패키지

우리는 모든 사람이 사용할 수 있는 안정적인 바이너리 릴리스를 모든 릴리스에서 제공하며, 계속 그렇게 할 것을 약속합니다. 우리는 최신 릴리스와 여러 이전 릴리스에 대해 무료로 정기적인 보안 패치를 제공합니다. 많은 벤더들이 이전 버전을 지원하겠지만, 안정적인 오픈 소스 프로젝트에서 안전하기 위해 벤더와의 계약이 필수 요건이 되어서는 안 된다고 생각합니다.

고려한 대안들

좋은 설계 문서에는 고려되었지만 궁극적으로 거부된 대안에 대한 섹션이 포함됩니다.

왜 "eBPF를 사용"하지 않나요?

우리는 적절한 곳에서 eBPF를 사용합니다! Istio는 eBPF를 사용하여 포드에서 프록시로 트래픽을 라우팅하도록 구성할 수 있습니다. 이는 iptables를 사용하는 것보다 약간의 성능 향상을 보여줍니다.그렇다면 왜 모든 것에 eBPF를 사용하지 않을까요? 아무도 그렇게 하지 않습니다. 왜냐하면 실제로는 아무도 그렇게 할 수 없기 때문입니다.eBPF는 Linux 커널 내부에서 실행되는 가상 머신입니다. 이는 커널 동작을 불안정하게 만들지 않도록 제한된 계산 범위 내에서 완료되는 것이 보장되는 함수를 위해 설계되었습니다. 예를 들어 단순한 L3 트래픽 라우팅이나 애플리케이션 관찰 기능 등이 있습니다. Envoy에서 발견되는 것과 같은 장기 실행 또는 복잡한 기능을 위해 설계되지 않았습니다. 그래서 운영 체제에는 사용자 공간이 있는 것입니다! eBPF 유지 관리자들은 Envoy만큼 복잡한 프로그램을 실행하도록 확장될 수 있다고 이론화했지만, 이는 과학 프로젝트일 뿐 실제 세계에서 실용성을 갖기는 어려울 것입니다."eBPF를 사용한다"고 주장하는 다른 메시들은 실제로는 노드당 Envoy 프록시나 다른 사용자 공간 도구를 대부분의 기능에 사용합니다.

왜 노드당 프록시를 사용하지 않나요?

Envoy는 본질적으로 멀티 테넌트가 아닙니다. 결과적으로, 우리는 제약이 없는 여러 테넌트의 L7 트래픽에 대한 복잡한 처리 규칙을 공유 인스턴스에 혼합하는 것에 대해 주요한 보안 및 안정성 문제를 갖고 있습니다. Kubernetes는 기본적으로 모든 네임스페이스의 포드를 모든 노드에 스케줄링할 수 있으므로 노드는 적절한 테넌시 경계가 아닙니다. 예산 책정 및 비용 할당도 주요 이슈인데, L7 처리 비용이 L4보다 훨씬 더 많이 들기 때문입니다.앰비언트 모드에서는 ztunnel 프록시를 Linux 커널과 마찬가지로 엄격하게 L4 처리로 제한합니다. 이는 취약점 노출 영역을 크게 줄이고 공유 구성 요소를 안전하게 운영할 수 있게 해줍니다. 그런 다음 트래픽은 네임스페이스별로 작동하는 Envoy 프록시로 전달되어 어떤 Envoy 프록시도 멀티 테넌트가 되지 않도록 합니다.

CNI가 있는데 왜 Istio가 필요한가요?

오늘날 일부 CNI 플러그인은 자체 CNI 구현 위에 서비스 메시와 유사한 기능을 추가 기능으로 제공하기 시작했습니다. 예를 들어, 노드나 포드 간 트래픽에 대한 자체 암호화 체계, 워크로드 ID를 구현하거나 트래픽을 L7 프록시로 리디렉션하여 일정 수준의 전송 계층 정책을 지원할 수 있습니다. 이러한 서비스 메시 추가 기능은 비표준이므로 해당 기능을 제공하는 CNI 위에서만 작동할 수 있습니다. 또한 다양한 기능 세트를 제공합니다. 예를 들어 Wireguard 위에 구축된 솔루션은 FIPS 준수로 만들 수 없습니다.이러한 이유로 Istio는 제로 트러스트 터널(ztunnel) 구성 요소를 구현했습니다. 이는 입증된 업계 표준 암호화 프로토콜을 사용하여 이러한 기능을 투명하고 효율적으로 제공합니다. ztunnel에 대해 자세히 알아보세요.Istio는 모든 환경, 모든 CNI에서, 또는 심지어 서로 다른 CNI를 가진 클러스터에서도 강력한 L7 정책 세트, 플랫폼에 구애받지 않는 워크로드 ID, 업계에서 검증된 mTLS 프로토콜을 사용하여 일관되고 매우 안전하며 효율적이고 표준 준수하는 서비스 메시 구현을 제공하는 서비스 메시로 설계되었습니다

PreviousWhat is Istio?NextSidecar or ambient?

Last updated 10 months ago