@kubernetes/client-node 관련 실패 기록

@kubernetes/client-node 라이브러리를 통해 웹 콘솔로 쿠버네티스를 제어할 수 있는 프로젝트를 계획중이었는데, 약 일주일간의 데모 스크럼 이후 결과적으로 불가능에 가깝다는 결론을 내리게 되어 이번 글에서 그 이유를 정리해보려 합니다.

프로젝트 기획 배경

쿠버네티스의 학습 난이도와 더불어 개인적으로는 쿠버네티스를 GUI로 지원하는 툴이 아직 많이 부족하다고 느꼈습니다.

또한 공식 쿠버네티스 대시보드와 lens 역시 리소스의 조회만을 지원하고, 생성은 불가능한 것으로 파악해 CRUD를 모두 지원하는 어플리케이션은 충분히 수요가 있을 것이라 생각했습니다.

@kubernetes/client-node

@kubernetes/client-node 라이브러리는 쿠버네티스에서 제공하는 공식 SDK로, 쿠버네티스의 kube-apiserver 에 프로그래밍 방식으로 요청을 보낼 수 있게 하는 도구입니다.

모든 API 명세는 이곳 에서 확인할 수 있습니다.

처음에는 API들이 잘 설계되어 있고, createNode, listNamespacedDeployment 등의 직관적인 이름으로 인해 원활한 개발이 가능할 것으로 기대했습니다.

경험한 이슈 목록

제작중이던 UI 형태

로컬에서 개발 테스트를 진행할 때는 큰 어려움 없이 순조롭게 진행되는 것 같았습니다.

하지만 배포를 염두에 두고 로컬호스트를 벗어나 컨테이너 개발에 돌입하니, 몇 가지 보이지 않던 문제들이 드러나기 시작했습니다.

1. 클라이언트 배포 문제

기존에는 웹 클라이언트를 S3, Netlify 등에 배포했지만 쿠버네티스를 웹에서 조작하기 위해서는 호스트의 쿠버네티스 설정 파일 (~/.kube/config)이 필요하다는 특징이 있어, 컨테이너 환경에서 실행 가능한 이미지 형태 로 배포해야만 했습니다.

 

따라서 퍼블릭하게 접근할 수 없어 웹의 장점을 살리지 못하고, 쿠버네티스 사용자가 도커 이미지를 실행하는 형태로 서비스를 실행해야 한다는 것은 단점으로 느껴졌습니다.

2. 쿠버네티스 인증 & 도커 네트워크 문제

쿠버네티스에 접근하기 위해 호스트의 쿠버네티스 설정 파일 (~/.kube/config)을 불러오는 과정에서도 문제가 있었습니다.

먼저 호스트에 존재하는 설정 파일을 획득하기 위해 두 가지 시나리오를 구성할 수 있었습니다.

 

1. 프론트엔드에서 쿠버네티스 설정 파일을 File 포맷으로 업로드하고, 이를 백엔드에서 저장하는 형식

2. 도커 볼륨의 바인드 마운트를 활용해 컨테이너화한 백엔드가 호스트의 ~/.kube/config 파일을 볼 수 있도록 하는 방식

쿠버네티스 설정 파일의 일부

하지만 쿠버네티스 설정 파일에는 클러스터의 서버 주소 및 액세스 토큰 정보가 포함되어 있어(위 이미지) 보안성이 필요하다고 생각해 둘 중 바인드 마운트를 활용하는 방법을 택했고, 결과적으로는 잘 동작하는 것처럼 보였습니다.

API를 통해 현재 클러스터의 네임스페이스 목록을 불러오는 모습

하지만 EKS, GKE 등의 퍼블릭 쿠버네티스 api 서버에 접근할 때와는 다르게 미니쿠베는 항상 프라이빗 네트워크(localhost)를 통해 접근해야만 했는데, 이 과정에서 문제가 발생했습니다.

 

컨테이너 환경에서는 호스트의 네트워크에 접근하기 위해 network를 host 모드로 설정해야 했지만, 이렇게 하면 호스트와 네트워크를 완전히 공유함으로써 컨테이너에 요청을 보낼 방법이 사라지게 되었습니다.

(= localhost:8080으로 요청을 보내도 요청이 전달되지 않아 응답이 돌아오지 않음)

services:
  kloud-backend:
    build: .
    ports:
      - "8081:8081"
    # 호스트(localhost) 네트워크 접근을 위한 네트워크 설정
    network_mode: host  
    volumes:
      - type: bind
        source: /Users/chanmin/.kube
        target: /usr/lib/.kube
      - type: bind
        source: /Users/chanmin/.minikube
        target: /Users/chanmin/.minikube

반면 네트워크를 bridge 모드로 설정했을 때는 미니쿠베의 api 서버에 요청을 보낼 방법이 사라지게 되었습니다.

(= localhost:8080으로 요청을 보내도 미니쿠베에 접근할 수 없어 오류만이 돌아오게 됨)

 

뿐만 아니라, 문서를 통해 마지막 방법인 host.docker.internal 라는 도커에서 지정된 호스트 아이피를 사용하는 방법을 도입하기도 했지만, 미니쿠베 api 서버의 주소와 도커 호스트에서 리턴하는 주소가 다르다는 문제를 최종적으로 확인해 이 문제를 해결하기 위해서는 너무 많은 공수가 들어갈 것으로 예상되었습니다.

host.docker.interal 에서 리턴한 호스트 주소 / 미니쿠베 api 서버 주소로 요청에 실패하는 모습

결론

결론적으로 이번 프로젝트는 완성되지 못했지만, 이 과정에서 node.js로 쿠버네티스를 제어하는 방법과 도커 볼륨 & 네트워크에 대한 지식을 한층 더 다질 수 있엇습니다.

https://github.com/C17AN/kloudy

GitHub - C17AN/kloudy: 웹 기반 쿠버네티스 조작 도구

혹시라도 관련 서비스를 개발하려 하시는 분들은 위 깃허브 주소의 백엔드 부분을 확인하시면 조금이나마 도움이 되실 듯 하며, 아쉬움과 함께 여기서 글을 마치려 합니다.