기본 콘텐츠로 건너뛰기

KubeEdge는 Kubernetes를 어떻게 바꾸는가 2-2

안녕하세요.

Jack 입니다.


CloudCore vs EdgeCore, 
놀라운 KubeEdge의 내부 구조에 대해 살펴 보겠습니다. 


KubeEdge가 어떻게 에지 환경에서 쿠버네티스를 구현하는지 궁금하신가요? 그 답은 내부를 구성하는 컴포넌트들의 유기적인 협업에 있습니다. 핵심만 콕 짚어 상세히 분석해 보겠습니다.

1. CloudCore: 클라우드와 에지를 잇는 가교

CloudCore는 기존 쿠버네티스 마스터 노드에 상주하며 에지 노드들을 자식처럼 관리합니다.

  • EdgeController: 에지 노드의 상태를 모니터링하고, 앱 배포 명령을 전달합니다.

  • DeviceController: 아래에서 설명할 'Device Twin' 정보를 클라우드와 동기화합니다.

2. EdgeCore: 에지의 영혼을 담은 3대장

에지 노드에서 돌아가는 EdgeCore는 사실상 작은 쿠버네티스입니다. 하지만 훨씬 끈질깁니다.

  • Edged: 쿠버네티스의 kubelet 역할을 수행합니다. 컨테이너의 생명 주기를 관리하고 리소스를 할당합니다.

  • MetaManager (최고 핵심): 이 녀석이 KubeEdge의 존재 이유입니다. 평소에 클라우드로부터 받은 설정값들을 로컬 DB(SQLite 등)에 저장해둡니다. 네트워크가 차단되면 이 DB를 보고 "아, 내가 이 앱을 돌리고 있어야 하는구나"라고 판단하며 상태를 유지합니다.

  • EventBus: MQTT 브로커와 통신하며 외부 IoT 디바이스로부터 데이터를 수집하거나 명령을 내립니다.

3. 혁신적 개념: Device Twin (디바이스 트윈)

하드웨어 장비를 다루는 방식이 예술입니다. KubeEdge는 센서, 모터, PLC 같은 물리적 장비를 소프트웨어 객체로 만듭니다.

  • 상태 정의: 장비의 '현재 상태'와 '희망 상태(Desired State)'를 정의합니다.

  • 동기화: 예를 들어, 관리자가 클라우드에서 "전등 켜기"라고 상태를 바꾸면, KubeEdge가 이를 감지해 현장의 실제 전등에 전기를 공급합니다. 하드웨어를 마치 소프트웨어 변수 다루듯 할 수 있게 되는 것입니다.

4. 한눈에 비교하는 KubeEdge vs 기존 방식

비교 항목기존 Kubernetes 노드KubeEdge 노드
자립성마스터 연결 끊기면 중단 가능성 높음연결 끊겨도 서비스 유지(LNM)
통신 프로토콜HTTP/gRPC (무거움)MQTT (가볍고 빠름)
디바이스 관리별도 솔루션 필요Device Twin으로 통합 관리
데이터 처리클라우드 집중형에지 단독/분산 처리형

KubeEdge는 단순히 유행하는 기술이 아닙니다. 클라우드의 지능을 우리 곁의 현장(Edge)으로 가져다주는 가장 현실적이고 강력한 도구입니다.


감사합니다. 


댓글

이 블로그의 인기 게시물

KubeEdge는 Kubernetes를 어떻게 바꾸는가 2-1

안녕하세요. Jack 입니다. 계속해서 KubeEdge가 에지 컴퓨팅의 표준이 된 이유에 대해 살펴 보겠습니다.  클라우드 네이티브의 상징인 쿠버네티스(Kubernetes)는 강력하지만, 모든 곳에 완벽하지는 않습니다. 특히 네트워크가 불안정하고 자원이 한정된 '에지(Edge)' 환경에서는 덩치 큰 쿠버네티스가 오히려 짐이 되곤 하죠. KubeEdge는 이 문제를 정면으로 돌파하며 "쿠버네티스를 현장에 맞게 재설계"했습니다. 1. "Kubernetes 그대로 가져오면 안 된다"는 뼈아픈 결론 쿠버네티스는 기본적으로 '모든 노드가 중앙과 24시간 연결되어 있다'는 가정을 전제로 합니다. 하지만 현실의 에지는 다릅니다. 통신 불안정: 산간 지역, 이동 중인 차량, 공장 지하 등은 연결이 수시로 끊깁니다. 리소스 부족: 에지 장비는 클라우드 서버만큼 고사양이 아닙니다. 이질적 환경: 수많은 IoT 센서와 장비들이 섞여 있습니다. 여기서 KubeEdge의 선택은 명확했습니다. "쿠버네티스의 장점인 관리 편의성은 가져오되, 에지의 열악한 현실을 수용하자"는 것이었죠. 2. KubeEdge의 핵심 전략: "중앙은 관리하고, 에지는 생존한다" KubeEdge의 구조를 보면 CloudCore 와 EdgeCore 로 명확히 나뉩니다. CloudCore (지휘본부): 기존 쿠버네티스 API와 소통하며 전체적인 전략을 짭니다. "어떤 앱을 어디에 배포할지" 결정하는 브레인입니다. EdgeCore (현장 요원): 현장에서 실제로 일을 합니다. 가장 큰 차별점은 '오프라인 자율성'입니다. 본사와 연락이 두절되어도 내가 맡은 일(Pod 실행)을 끝까지 완수합니다. 3. 왜 굳이 IoT 방식(MQTT)을 섞었을까? 많은 엔지니어가 묻습니다. "왜 쿠버네티스 표준인 HTTP 대신 MQTT를 쓰나요?" 답은 실용성에 있습니다. 에지 ...