클라우드 네이티브 환경에서 네트워킹 및 보안을 위한 eBPF 기술 동향

eBPF Technology Trends for Networking and Security in Cloud-native

저자
신용윤네트워크·시스템보안연구실
신지수네트워크·시스템보안연구실
박철희네트워크·시스템보안연구실
박종근네트워크·시스템보안연구실
권호
37권 5호 (통권 198)
논문구분
일반논문
페이지
62-69
발행일자
2022.10.03
DOI
10.22648/ETRI.2022.J.370507
본 저작물은 공공누리 제4유형: 출처표시 + 상업적이용금지 + 변경금지 조건에 따라 이용할 수 있습니다.
초록
In a situation where applications determine business competitiveness, they cannot respond to varying customer requirements without the cloud's flexibility and scalability. Companies have begun seeking ways to enjoy the advantages of the cloud fully, and the concept of “Cloud Native” is emerging as a solution to the problem. Cloud Native is now a target of interest in the market. Microservice and serverless functions can play a vital role in cloud-native architecture. Microservice arranges applications into various independent services, each offering certain functionality through mutual networking. eBPF is attracting attention as a cloud-native networking solution that quickly supports microservice features that repeat creation/deletion. This study identifies the characteristics of eBPF-based networking and evaluates cloud-native networking and secure networking using eBPF.
   2498 Downloaded 1070 Viewed
목록

Ⅰ. 서론

클라우드 네이티브 아키텍처(Cloud Native Architecture)는 클라우드 장점을 최대화하여 활용할 수 있도록 응용(Application)을 구축하고 실행하는 방법론을 의미하는 것으로 CNCF(Cloud Native Computing Foundation)에서 정의한 개념이다. 즉, 설계부터 클라우드 환경에 최적화된 응용 아키텍처를 구성하여 클라우드에 대한 종속을 제거하는 것이 주요 내용이다.

CNCF는 그림 1과 같이 189개국 142,000명 이상의 컨트리뷰터(Contributors)가 쿠버네티스(Kubernetes, K8s)로 대표되는 오케스트레이터(Orchestrator)부터 CI/CD까지 클라우드 네이티브 전 영역에 걸친 120여 개의 세부 프로젝트에 참여[1]하고 있으며, 필요한 프로젝트를 활용하여 목적에 맞는 클라우드 네이티브(Cloud Native) 환경을 구성할 수 있다[2]. CNCF는 클라우드 네이티브의 핵심요소로 1) DevOps, 2) CI/CD, 3) Containers, 4) Microservice를 제안하고 있다. 특히, 최근 관련 시장을 주도하고 있는 마이크로서비스 아키텍처는 클라우드 네이티브의 가장 중요한 요소로서, 응용을 상호 독립적인 최소 구성 요소로 분할하고 독립적인 요소들이 연동되어 같은 태스크(Task)를 완수할 수 있도록 하는 것으로 클라우드 네이티브의 핵심요소 중 하나인 컨테이너를 통해 제공된다. 클라우드 네이티브 아키텍처의 시스템 수평 확장 유연성, 서비스 통합/배포/생성 시간 단축, 서비스 간 종속성 최소화를 통한 장애 격리와 같은 장점을 기반하여 개발 생산성, 비즈니스 민첩성/확장성/가용성, 비용 절감 등의 효과를 높일 수 있기 때문에 주목받고 있다.

그림 1

CNCF Cloud Native Interactive Landscape

출처 Reprinted from [2], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f1.jpg

클라우드 네이티브 환경에서 특정 비즈니스 기능을 수행하는 마이크로서비스들은 상호 커뮤니케이션(Communication)을 통해 사용자 요청을 처리하게 되는데 수많은 마이크로서비스가 서로 네트워킹을 요구하기 때문에 마이크로서비스 간 통신을 제어하고 관리할 수 있는 네트워크 추상화 계층이 필요하게 되었다. 사이드카(Sidecar) 컨테이너 개념을 활용해 마이크로서비스마다 사이드카 프록시(Proxy)를 적용하여 마이크로서비스 네트워크를 구성하는 이른바 서비스-메시(Service-Mesh) 네트워크[3] 개념이 탄생하게 되었다. 즉, 그림 2와 같이 사이드카 패턴의 프록시를 통해 내부 네트워크의 안정성, 신뢰성, 탄력성, 가시성, 보안성 등을 확보할 수 있다. CNCF는 경량화 프록시 프로젝트인 Envoy[4]를 통해 클라우드 네이티브 환경에서 서비스-메시 네트워크를 지원하고 있다.

그림 2

Sidecar Proxy 기반 서비스-메시 토폴로지

출처 Reproduced from [3], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f2.jpg

하지만, 서비스마다 생성되는 사이드카 프록시 형태는 클라우드 네이티브 시스템의 인스턴스 증가 및 서비스 간 통신에 추가되는 네트워크 레이어로 인한 관리 문제를 동시에 가지고 있으며 무엇보다 이제 정식 릴리즈 된 네트워크 솔루션으로 안정화 및 기능 개선이 진행되고 있다.

본고에서는 클라우드 네이티브 환경으로 대표되는 쿠버네티스의 컨테이너 간 통신을 담당하는 네트워크 기술에 대해 살펴보고자 한다. 특히, CNCF는 컨테이너 네트워크에 대한 사실표준인 CNI(Container Network Interface)를 제시하였고, CNI를 활용하여 많은 K8s 네트워크 솔루션이 플러그인(Plugin) 형태로 제공되고 있다. 이러한 네트워크 플러그인의 목적은 유연하고, 빠르고, 안전하게 컨테이너 네트워크를 제공하는 것으로, 대표적인 예로 Calico CNI plugin을 들 수 있는데 최근 eBPF 기반의 Cilium CNI plugin이 많은 관심을 받고 있다.

따라서 본고에서는, 먼저 Ⅱ장에서 eBPF 기술의 원리 및 최근 동향을 살펴보고, Ⅲ장에서는 클라우드 네이티브 환경에서 eBPF를 적용한 네트워크 동향을 중심으로 설명한다. 마지막으로 Ⅳ장에서 결론을 제시한다.

Ⅱ. eBPF

1. eBPF 개요

지난 2021년 8월 12일 리눅스 재단(Linux Foundation)은 Facebook, Google, Isovalent, Microsoft, Netflix와 함께 eBPF 재단(eBPF Foundation)의 출범을 알렸다. 세계적 기업이 관심을 가진 eBPF는 extended Barkeley Packet Filter의 약어로 커널(Kernel)에 사용자 정의 코드를 적용하는 기술을 의미한다. 일반적으로 사용자가 작성한 코드는 사용자 영역(Users Space)에서 실행되는 것과 달리 eBPF 코드는 커널 코드 내부에 미리 정의된 훅(Hook)이나 kprobe, uprobe, tracepoint 등을 기반으로 커널 영역(Kernel Space)에서 실행된다. 운영체제 커널에서 샌드박스 프로그램을 실행하는 것으로 커널 소스 코드 자체를 변경하거나 커널 모듈을 로드할 필요 없이 커널 기능을 안전하고 효율적으로 확장할 수 있다[5].

cBPF(Classic BPF)라 부르는 초기 BPF(Barkeley Packet Filter)는 패킷을 분석하고 필터링하는 inkernel virtual machine 형태로 시작되었다. LLVM(Low Level Virtual Machine)이라 불리는 가상 환경으로 인한 한계가 존재하였지만, 컴퓨팅 성능의 비약적인 발전으로 JIT(Just In Time) 컴파일러가 추가되면서 프로세서가 직접 명령을 수행하는 현재의 단계에 이르렀다.

2. eBPF 동작 절차

Linux 커널과 eBPF 프로그램의 연관성을 나타내는 그림 3에서 볼 수 있듯이, eBPF 프로그램은 커널 코드에 정의된 hook을 통해 이벤트를 처리하게 되는데, 이러한 hook을 모아 BPF Program Type(bpf_prog_type) 및 BPF Attach Type(bpf_attach_type)에 정의하고 있다[6]. 이중 네트워크 관련 hook으로 대표되는 것이 XDP(eXpress Data Path)이다. XDP는 커널 네트워크 스택이 처리하기 전에 수신된 패킷에 대한 초기 액세스를 제공하기 때문에 빠른 패킷 처리가 가능하다[7]. 즉, 네트워크 카드로 진입하는 패킷에 대하여 XDP hook을 통해 pass/drop/manipulate/redirect를 할 수 있다.

그림 3

Linux Kernel과 eBPF 프로그램 연관성

출처 Reprinted from [5], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f3.jpg

XDP는 eBPF hook로 정의되어 네트워크 드라이버 내에서 동작하는데, 복잡한 네트워크 스택을 거친 후 사용자 영역에서 처리하는 기존 네트워크 패킷의 흐름이 네트워크 카드에서 바로 패킷을 처리하는 흐름으로 변화함으로써 성능적인 장점을 얻음과 동시에 필요한 패킷만 사용자 영역으로 전달하여 트래픽 폭증으로 인한 네트워크 및 시스템 장애 문제를 안정적으로 조절할 수 있다. 즉, 커널 네트워크 스택에 런타임 패킷 처리가 가능한 프로그램을 실행하는 것으로 한번 컴파일된 eBPF 프로그램은 재컴파일 없이 여러 커널과 아키텍처에 재사용할 수 있다.

그림 4에서 확인할 수 있는 것처럼 eBPF XDP hook을 처리하는 방식은 상당히 간단한데 1) 패킷을 모두 삭제하는 XDP_DROP, 2) 패킷의 추가 처리를 위해 네트워크 스택으로 전달하는 XDP_PASS, 3) 패킷을 수신한 인터페이스로 전달하는 XDP_TX, 4) 네트워크 스택을 무시하고 다른 네트워크 카드로 패킷을 전달하는 XDP_REDIRECT 4가지 방식을 사용한다. 이러한 장점을 토대로 패킷 처리 성능을 높일 수 있는데, 세계적인 CDN 서비스 기업인 Cloudflare를 참고하면 단일 CPU 기준 초당 1천만 개의 패킷을 버릴 수 있다고 한다[8].

그림 4

eBPF XDP 패킷 처리

출처 Reproduced from [5], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f4.jpg

3. eBPF 현재 동향

eBPF는 네트워킹, 보안, 응용 프로파일링, 시스템 관찰 관련하여 지능적이고, 확장 가능하고, 다양한 기능을 추가할 수 있다는 장래성 때문에 현재 Meta(Facebook) 데이터 센터의 로드밸런서, Google GKE의 네트워킹 및 보안, 네이버의 고성능/고가용 NAT 시스템, 카카오의 L2DSR 로드밸런서 등에 활용되고 있다.

향후, 마이크로서비스들이 eBPF를 사용한다면 서비스 설계부터 커널에 코드를 실행하는 단계가 추가된 완전히 새로운 아키텍처가 탄생할 것으로 기대된다. 이러한 기대감은 클라우드 네이티브 환경에도 반영되어 CNCF의 CNI plugins에 eBPF 기반의 컨테이너 네트워킹 솔루션인 Cilium이 추가되었으며, 최근 매우 크게 주목받고 있다.

Ⅲ. Cilium CNI plugin

1. Cilium CNI plugin 개요

앞서 살펴본 eBPF 기반 네트워크의 특성은 마이크로서비스 아키텍처의 네트워크 솔루션을 고심하던 클라우드 네이티브 진영에게 희소식이 되었고, CNCF는 2021년 10월 13일 eBPF 기반의 CNI plugin인 Cilium을 인큐베이팅(Incubating) 프로젝트로 승인했다. 클라우드 네이티브 진영에서 eBPF를 주목하는 이유는 매우 동적인 마이크로서비스 환경에서 기존의 IPtables 기반 IP/Port 중심의 포워딩이 매우 비효율적이기 때문이다.

그림 5는 Cilium의 아키텍처를 나타내는데 클라우드 네이티브 환경에서 오케스트레이터는 마이크로서비스의 생성/삭제로 인한 컨테이너를 관리함과 동시에 네트워킹을 동적으로 지원해야 한다[9]. 즉, 컨테이너 라이프사이클 관리부터 네트워킹에 이르기까지 매우 복잡한 처리를 자동화해야 한다.

그림 5

eBPF 기반 Cilium CNI architecture

출처 Reprinted from [9], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f5.jpg

2. Cilium CNI plugin 동작 절차

Cilium은 IPtables 기반 네트워킹을 제공하는 기존 CNI plugin과는 다르게 eBPF 기반의 컨테이너 네트워킹을 제공한다[10].

그림 6과 같이 기존 IPtables 기반의 네트워킹 복잡성을 줄이는 것을 볼 수 있다. 이러한 장점은 보안 측면에서도 강하게 나타난다.

그림 6

K8s POD 네트워킹 비교(vs Cilium CNI)

출처 Reproduced from [10], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f6.jpg

Cilium은 호스트의 네트워크 드라이버의 XDP hook을 활용하여 호스트 커널에서 패킷을 처리할 수 있기 때문에 비대해진 IPtables의 IP/Port 매칭을 검색하지 않아도 되며, 동적으로 생성된 마이크로서비스로 인해 만들어지는 IPtables의 sync 및 IPtables 구성 오류로 발생할 수 있는 네트워킹 문제도 해소할 수 있다. 클라우드 네이티브 특성상 시간이 지날수록 마이크로서비스는 증가하며, 마이크로서비스마다 구성한 네트워크 보안 정책으로 인한 네트워크 보안 정책 관리의 어려움이 발생하는데, Cilium은 eBPF MAP을 활용하여 호스트 커널에서 관리할 수 있기 때문에 정책 관리의 복잡성을 다소 낮출 수 있다.

그림 7은 Cilium 기반의 네트워크 보안을 간략히 보여주는 예로써 Cilium 전용 네트워크 정책 도구(Network Policy Editor)를 활용[11]하여 허용되지 않은 패킷은 호스트 커널에서 빠르게 처리(Drop)하고, 허용된 패킷은 목적지까지 전송[12]하는 eBPF 장점을 클라우드 네이티브 네트워킹에 적용하는 것을 볼 수 있다. 무엇보다 네트워크 정책이 수정되는 경우 서비스를 중단하지 않고 eBPF 프로그램만 수정하는 것으로 네트워크 보안 정책 업데이트를 전체 네트워크에 적용할 수 있기 때문에 seamless 서비스를 제공할 수 있다.

그림 7

Cilium 기반 네트워크 정책 적용 보안

출처 Reproduced from [11,12], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f7.jpg

3. Cilium 기반 서비스-메시

현재 마이크로서비스 네트워킹은 서비스-메시 구조를 활용하는 추세이다. 수많은 마이크로서비스 간 복잡한 네트워킹을 제어하기 위해 제안된 서비스메시는 경량화된 프록시를 사이드카 패턴으로 배치하여 마이크로서비스를 망처럼 엮는 구조이다. 즉, 마이크로서비스 간 네트워킹은 사이드카로 배치된 경량 프록시를 통해 routing rules, retry, timeout, Circuit Breaker 등을 설정하는 것으로 구성된다. 서비스-메시 구조는 마이크로서비스 아키텍처를 도입하면서 발생하는 런타임 복잡성 이슈 및 동적인 네트워킹 복잡성을 해소할 수 있는 반면, 마이크로 서비스마다 하나의 사이드카 프록시를 생성하기 때문에 클라우드 네이티브 환경의 인스턴스 수가 2배 이상 늘어나고, 동일 호스트에 생성된 마이크로서 비스 통신에 네트워크 계층이 추가되는 단점이 존재한다.

Cilium은 서비스-메시 환경에서 더욱 강력함을 발휘할 수 있는데, 매우 복잡한 서비스-메시 구조에 네트워크 정책을 적용하여 마이크로서비스로 허가되지 않은 패킷 진입을 호스트의 커널에서 막을 수 있고, 마이크로서비스 사이의 패킷이 복잡한 네트워크 스택을 통하지 않고 전달되도록 할 수 있으며, 클라우드 네이티브에서 생성하는 정책을 빠르게 전체 네트워크에 적용할 수 있는 관계로 최근 매우 주목받고 있다.

Cilium은 그림 8과 같이 서비스-메시를 위한 프록시를 호스트의 커널에서 지원할 수 있기 때문에 호스트 프록시를 통하여 마이크로서비스 간 네트워킹을 가능하게 한다. 즉, Cilium에서 제안하고 있는 서비스-메시 구조는 전통적인 사이드카 프록시 형태의 네트워킹 구조에서 사이드카 프록시를 제거하고 마이크로서비스 패킷을 eBPF로 처리하는 구조로 진화하는 모양을 보이고 있으며, 이를 통해 인스턴스 수의 증가 및 패킷의 전체 경로를 줄일 수 있는 효과를 가지게 된다[13].

그림 8

Cilium 기반 sidecarless 서비스-메시 구조

출처 Reproduced from [13], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f8.jpg

4. Cilium 현재 동향

eBPF의 장점을 클라우드 네이티브 환경의 네트워크로 녹여낸 Cilium은 이미 많은 클라우드 서비스에서 활용하고 있는데, 대표적으로 Amazon EKS 및 Google GKE의 기본 CNI plugin, 네이버 LINE의 Caravan, 카카오 DKOS의 network-node-manager 등의 서비스에서 제공되고 있다. 특히, 5G 서비스의 저지연/초고속/초연결 특성을 제공하기 위하여 eBPF 기반의 모바일 게이트웨이[14], 5G UPF용 BPF/XDP[15] 등의 논문들이 발표되고 있는 것을 볼 때, Cilium을 활용한 클라우드 네이티브의 5G 서비스 네트워킹의 가능성이 큰 것으로 예상된다.

Ⅳ. 결론

지금까지 클라우드 네이티브 환경에서 eBPF 기반 네트워킹 기술의 최근 연구 동향을 살펴보았다. 본고에서 소개한 eBPF 기반 네트워킹 기술은 성능, 안전성, 다양성 측면에서 많은 장점이 있으며, 무엇보다 향후 잠재된 가능성이 매우 크기 때문에 기술 확산을 위한 지속적인 관심 및 추가 연구가 필요하다. 예를 들어, 서비스-메시를 위한 리눅스 커널 레벨 프록시 기술 또는 마이크로서비스로 인하여 매우 복잡해진 네트워크 서비스의 루트(Root) 보안을 위한 리눅스 커널 레벨 보안 기술 확보 관련 추가 연구 개발 및 이에 따른 새로운 서비스 아키텍처의 구성이 병행되어야 한다.

eBPF 기반 클라우드 네이티브 네트워킹 플러그인은 현재 Cilium이 유일하며 CNCF의 인큐베이팅(Incubating) 프로젝트로 지속되고 있다. 국내에서도 eBPF 기반 클라우드 네이티브 네트워킹 기술이 활발히 연구 개발된다면, 클라우드 네이티브 네트워킹 분야의 선구적 기술을 확보할 수 있을 것으로 전망된다. 특히, 5G 서비스의 IoT, MEC, 코어에 이르는 수많은 네트워크와 서비스의 성능, 보안 측면에서 매우 유의미한 결과가 있을 것으로 기대된다.

본고에서는 클라우드 네이티브 환경 및 eBPF 기반 네트워킹에 대하여 살펴보았다. 본고를 통해 알아본 내용이 향후 관련 연구의 기초가 될 수 있기를 기대한다.

용어해설

Cloud Native 퍼블릭, 프라이빗, 하이브리드 클라우드와 같은 동적인 환경에서 확장성 있는 애플리케이션을 구축하고 실행할 수 있도록 하는 기술

Microservice 소프트웨어를 구축하기 위한 아키텍처이자 하나의 접근 방식으로 애플리케이션을 상호 독립적인 최소 구성 요소로 분할하고 연동하여 동일한 태스크를 완수하는 기술

Sidecar 패턴 기본 컨테이너의 기능을 확장하거나 강화하는 용도의 컨테이너를 추가하는 것으로 기본 컨테이너와 독립적으로 동작하는 별도의 컨테이너를 추가하여 확장된 기능을 제공하는 패턴

eBPF 커널 소스 코드를 바꾸거나 추가 모듈을 추가할 필요 없이 프로그램을 운영체제의 커널 공간에서 실행하는 기술로서 OS 커널 수준부터 전체 소프트웨어 스택에 걸쳐 관측 및 네트워킹 및 보안을 위한 프로그래밍을 가능하게 하는 기술

Cilium eBPF 및 XDP 기반의 네트워킹 및 보안 기술로 클라우드 네이티브 환경의 네트워크 솔루션으로 활용되고 있으며, 특히 쿠버네티스 등의 클라우드 네이티브 프레임워크에서 플러그인 형태로 네트워크 및 보안 필터링을 제공

약어 정리

CNCF

Cloud Native Computing Foundation

CNI

Container Network Interface

eBPF

extended Barkeley Packet Filter

EKS

Elastic Kubernetes Services

GKE

Google Kubernetes Engine

JIT

Just In Time

XDP

eXpress Data Path

참고문헌

[1] 

CNCF, 2021 CNCF Annual Report, 2021.

[2] 

CNCF, CNCF Cloud Native Interative Landscape, https://landscape.cncf.io

[3] 

CNCF, Service Mesh: A Critical Component of the Cloud Native Stack, Apr. 26, 2017, https://www.cncf.io/blog/2017/04/26/service-mesh-critical-component-cloud-native-stack/

[4] 

[7] 

Dorsal Lab, An Entertaining eBPF XDP Adventure, 2017, https://suchakra.wordpress.com/2017/05/23/an-entertaining-ebpf-xdp-adventure/

[8] 

M. Majkowski, "How to drop 10 million packets per second," Cloudflare, 2018, https://blog.cloudflare.com/how-to-drop-10-million-packets/

[9] 

Cilium, What is Cilium - Architecture, https://cilium.io/get-started

[10] 

T. Graf, "CNI benchmark: Understanding Cilium network performance," Cilium, May 11, 2021, https://cilium.io/blog/2021/05/11/cni-benchmark/

[11] 

Cilium, Network Policy Editor - Tutorial: Allow Egress To Kubernetes DNS, Tutorial: Misunderstanding How Policy Rules Combine, https://editor.cilium.io

[12] 

Cilium, Kubernetes Network Policies Using Cilium - Controlling Ingress/Egress from Namespaces, May 11, 2018, https://cilium.io/blog/2018/09/19/kubernetes-network-policies

[13] 

Cilium, Try eBPF-powered Cilium Service Mesh - Join the Beta Program!, Dec 2, 2021, https://cilium.io/blog/2021/12/01/cilium-service-mesh-beta

[14] 

F. Parola, S. Miano, and F. Risso, "A proof of concept 5G mobile gateway with eBPF," in Proc. SIGCOMM '20, (Virtual), Aug. 2020, https://dl.acm.org/doi/abs/10.1145/3405837.3411395

[15] 

T.A. Navarro do Amaral et al., "Run-time adaptive In-Kernel BPF/XDP solution for 5G UPF," Electronics, vol. 11, no. 7, 2022, https://www.mdpi.com/2079-9292/11/7/1022

그림 1

CNCF Cloud Native Interactive Landscape

출처 Reprinted from [2], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f1.jpg
그림 2

Sidecar Proxy 기반 서비스-메시 토폴로지

출처 Reproduced from [3], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f2.jpg
그림 3

Linux Kernel과 eBPF 프로그램 연관성

출처 Reprinted from [5], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f3.jpg
그림 4

eBPF XDP 패킷 처리

출처 Reproduced from [5], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f4.jpg
그림 5

eBPF 기반 Cilium CNI architecture

출처 Reprinted from [9], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f5.jpg
그림 6

K8s POD 네트워킹 비교(vs Cilium CNI)

출처 Reproduced from [10], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f6.jpg
그림 7

Cilium 기반 네트워크 정책 적용 보안

출처 Reproduced from [11,12], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f7.jpg
그림 8

Cilium 기반 sidecarless 서비스-메시 구조

출처 Reproduced from [13], CC BY 3.0.

images_1/2022/v37n5/HJTODO_2022_v37n5_62f8.jpg
Sign Up
전자통신동향분석 이메일 전자저널 구독을 원하시는 경우 정확한 이메일 주소를 입력하시기 바랍니다.