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