Kubernetes 클러스터에 배포할 애플리케이션 로컬 디버깅 및 개발하기

Kubernetes 환경에서 로컬 디버깅 및 개발 방식

보통 Kubernetes 환경에서 로컬 개발은 아래와 같은 다양한 선택지 중 하나를 취사선택하여 개발할 수 있습니다.

⑴ docker-compose 혹은 minikube 등으로 직접 로컬에서 클러스터 환경을 구성하여 개발

• 새로운 개발 환경을 구성할 경우 복잡한 환경 설정 및 설치 작업 등으로 인하여 부담이 될 수 있습니다.
• 리소스 부족으로 인하여 로컬 환경이 느려지는 경우가 발생할 수 있습니다.

⑵ 모든 애플리케이션을 로컬에서 실행하여 개발

• ⑴번과 같이 리소스 부족으로 인하여 로컬 환경이 느려지는 경우가 발생할 수 있습니다.
• 다른 애플리케이션과의 의존성으로 인해 내가 담당하고 있지 않은 다른 애플리케이션까지 로컬에서 구동할 수 있어야 합니다.
• 다양한 언어 및 프레임워크로 개발되는 MSA 특성상 복잡한 설치 작업 혹은 환경설정 작업이 수반될 수 있습니다.

⑶ 일부 애플리케이션만 실행하여 개발한 후 Kubernetes 클러스터 환경에 배포하여 확인

• 개발할 애플리케이션으로 들어오는 요청 및 응답을 직접 구성하여 테스트가 필요하며,
• 기능 확인을 위해서 Kubernetes 환경에 배포하여 디버깅하는 작업이 필요합니다.
• 수정된 애플리케이션을 클러스터 환경에 배포하여 확인하는 작업에 시간이 많이 소요될 경우 생산성이 저하될 수 있습니다.

Telepresence는 빠른 로컬 개발 및 디버깅을 위한 도구이며 이러한 단점들을 해결할 수 있습니다.

Telepresence 란?

먼저 Telepresence의 사전적 의미는 공간적으로 떨어져 있는 장소 또는 가상의 장소를 경험하는 것입니다. 이러한 단어의 뜻과 유사하게 Telepresence는 원격 Kubernetes 클러스터로 서비스를 프록시하여 로컬에서 개발 및 디버깅하는 과정을 용이하게 하는 도구입니다.

• Kubernetes 클러스터 환경에서 디버깅을 하려면 코드 컴파일하고, 컨테이너 빌드하고 버전 바꿔서 태깅하고, 푸시 한 다음, YAML 형식으로 변경해서 반영하고, 실행 후 외부에서 접속이 가능하도록 네트워크 주소를 변환해 주는 포트 포워딩을 통해서 실행 결과를 확인해야 하는데 이러한 과정 없이도 디버깅을 편하게 할 수 있습니다.

Telepresence는 2018년 5월 15일에 CNCF의 샌드박스 단계로 채택이 되었습니다.

레거시 Telepresence와 Telepresence 2(가칭)와의 차이점

레거시 Telepresence의 경우 pod에서 동작하고 있는 서비스가 Telepresence proxy로 스와핑되는 방식으로 동작합니다. 그리고 이 proxy는 서비스로 향하는 트래픽을 받아 해당 트래픽을 로컬 컴퓨터로 전달하는데 이러한 방식을 "swap-deployment"방식이라고 합니다.

이 방식은 단순하지만 아래와 같은 결점이 있습니다.

• 클러스터로의 연결이 유실될 경우 Deployment가 불안정한 상태로 남겨질 수 있습니다. 즉, pod를 교체하는 데 시간이 걸리게 됩니다.

Telepresence 2의 경우 이러한 문제를 해결하는 "intercept"를 중심으로 구축된 새로운 아키텍처를 도입하였습니다. Intercept란 sidecar proxy("traffic agent")가 pod에 주입되어, 서비스로 향하는 트래픽을 받아서 로컬 컴퓨터로 라우팅하는 동작을 의미합니다.

이러한 방식의 장점은 서비스가 항상 실행 중이기 때문에 모든 요청을 라우팅하지 않고 특정 유저에 속한 것으로 지정된 트래픽만 라우팅하여 개발자들끼리 서로 방해받지 않고 자유롭게 개발 및 디버깅을 진행할 수 있다는 것입니다.

Telepresence의 아키텍처 살펴보기

Telepresence의 주요 구성요소는 아래와 같습니다.

Telepresence CLI

Telepresence CLI는 오케스트레이션을 수행합니다. 즉, Telepresence Daemons를 실행하고, Ambassador Cloud에 대한 인증 및 Telepresence Daemons 중 하나인 User Daemon을 위한 사용자 친화적인 인터페이스를 제공합니다.

Ambassador Cloud는 Telepresence를 개발한 Ambassador Labs가 제공하는 서비스로 Kubernetes 워크플로우에 맞춰 서비스를 개발하고 관리해 주는 인터페이스입니다.

Telepresence Daemons

Telepresence는 클러스터와 통신하고 intercept된 요청을 다루기 위해 로컬 컴퓨터에서 실행되고 클러스터 네트워크에 대한 통신의 주요 포인트가 되는 2가지 타입의 Daemon이 있습니다.

• User-Daemon

  • Traffic Manager와 통신하여 intercept의 생성 및 삭제를 다룹니다.

• Root-Daemon

  • 가상 네트워크 장치(VIF)를 설정하여 로컬 컴퓨터와 클러스터 간의 트래픽을 처리하는데 필요한 네트워킹을 관리합니다.

Traffic Manager

Traffic Manager는 클러스터의 Traffic Agent와 로컬 컴퓨터의 Daemon 간 통신의 중심점입니다. intercepted pod에 Traffic Agent sidecar를 주입시켜 모든 관련된 유입 및 유출 트래픽을 프록시하고 active intercepts를 추적하는 역할을 합니다.

Traffic Agent

intercepts를 용이하게 하는 sidecar 컨테이너를 의미합니다

Telepresence의 기본 개념

Telepresence는 2개의 코어 아키텍처로 구성되어 있습니다.

1. client-side Telepresence binary (로컬 컴퓨터에 설치된 CLI Tool)
2. cluster-side traffic-manager and traffic-agent (원격 쿠버네티스 클러스터에 위치)

먼저 'telepresence connect' 명령어는 traffic-manager로 하여금 로컬 컴퓨터와 원격 클러스터 환경과의 양방향 proxied tunnel을 만듭니다.

• 이것은 원격의 Kubernetes 서비스를 마치 로컬에서 동작하는 것처럼 인식하게 해줍니다.

이후 'telepresence intercept {service-name}' 명령어는 traffic-manager를 트리거 하여, 타깃 서비스와 연관된 Pod 내에서 실행되는 traffic-agent proxy container를 설치하도록 합니다.

• 이것은 개발 및 디버깅을 위해 원격 트래픽을 로컬 컴퓨터로 라우팅할 수 있게 해줍니다.

그럼 간단한 튜토리얼을 통해서 Telepresence를 어떻게 활용할 수 있는지 살펴보도록 하겠습니다.

Telepresence를 사용한 Remote Debugging 튜토리얼

① 로컬의 ~/.kube/config 파일을 원격 Kubernetis cluster 환경의 config 파일로 대체하여 로컬에서 원격 cluster 개발 환경 구성(필수) MacOS 기준이며, 사전에 docker desktop for Mac 및 Kubernetes 사용 설정과 kubectl 설치가 되어있다고 가정합니다.

② 이후 Telepresence 및 관련 라이브러리 설치

• 설치하기 문서 참고

# Install via brew (Apple silicon Macs에 해당, 다른 OS의 경우 설치 문서 참고)
$ brew install datawire/blackbird/telepresence-arm64
 
# Make the binary executable (실행 권한 부여)
$ sudo chmod a+x /opt/homebrew/bin/telepresence
 
# traffic manager 설치 필요(Traffic Manager installed successfully 글씨가 나오면 성공)
# 어떤 helm chart가 install되는지 보려면 (https://github.com/telepresenceio/telepresence/tree/release/v2/charts/telepresence) 참조
$ telepresence helm install

③ 클러스터 환경의 traffic manager 실행

$ telepresence connect 명령어 실행
 
# 만약 오류 발생 시 vi /Users/nhn/Library/Logs/telepresence/connector.log에서 오류 내용 확인 가능
# 특정 위치에 파일이나 폴더가 없다는 오류가 발생하면 mkdir -p /Users/$USER/Library/Caches/telepresence ($USER는 해당 컴퓨터의 사용자 이름으로 repleace 필요)
# Connected to context kubernetes-admin@kubernetes (https://10.162.5.215:6443) 메시지가 뜨면 성공

④ telepresence status 명령어로 상세 정보 확인 (User Daemon과 Root Daemon이 실행 중 인지 확인)

⑤ 클러스터 환경에 배포되어 있는 pod 및 deployment 확인

사전에 8080 포트로 호출하면 Hello World 라고 출력되는 웹 애플리케이션(아래의 leejeongwha-pipeline-test가 해당)이 배포되어 있어야 합니다.

$ kubectl describe pods leejeonwha-pipeline-test-559f9b644f-fgp2h
$ kubectl describe deployment leejeonwha-pipeline-test

⑥ 노출할 서비스 생성

$ kubectl expose deployment leejeonwha-pipeline-test --type=LoadBalancer
$ kubectl describe services leejeonwha-pipeline-test 명령어로 IP 확인 후 호출

⑦ curl 10.105.34.3:8080으로 서비스 호출해 보기

• IP 및 Port는 클러스터 환경 및 애플리케이션 설정에 따라 다를 수 있습니다.
• 위에서 수행한 telepresence connect 명령어로 인해 로컬에서 원격 클러스터 환경에 직접 접근이 가능하게 됩니다

⑧ telepresence list 명령어로 intercept 가능한 리스트 확인

⑨ intercept를 통해 Kubernetes로 들어온 요청을 가로채기

$ telepresence intercept leejeonwha-pipeline-test --port 9000:8080 

# Kubernetes 클러스터의 8080으로 들어온 요청을 로컬의 127.0.0.1:9000 으로 전달

⑩ Kubernetes의 해당 app을 호출한 뒤 로컬에서 내용 변경 후 다시 호출해 보기

$ curl 10.105.34.3:8080 

# 로컬 프로젝트 내용 변경 후 다시 호출하여 변경된 내용이 출력 되면 success!

⑪ 종료

$ telepresence quit

Telepresence의 기타 기능

위의 예제로 살펴본 기능은 global intercept(모든 요청을 intercept)에 대한 부분이고, private intercept를 이용할 경우, 특정 헤더 혹은 특정 경로에 대해서만 intercept할 수 있어 여러 개발자가 서로 간섭 없이 로컬 환경에서 개발 및 디버깅이 가능합니다.

또한 Telepresence는 공유 가능한 preview URL을 생성할 수 있고, 해당 환경을 팀원과 공유하여 두 명이 하나의 프로그램을 개발하는 Pair 프로그래밍을 할 수도 있습니다.

• Telepresence는 해당 미리 보기 URL에서 오는 요청만 로컬 환경으로 라우팅하게 됩니다(인그레스에 대한 요청은 평소와 같이 클러스터로 라우팅 됩니다).

Telepresence 사용 후기

처음 팀 내 프로젝트에 Telepresence를 사용하면서 global하게 요청을 intercept해서 다른 개발자들이 개발 클러스터 환경에서 테스트 중인 요청들도 모두 가로채어 문제가 되었는데, Team mode방식이 private interceptor를 지원해 준다는 사실을 알게 되었습니다.

이후 Team mode 방식으로 새로 Telepresence를 설치한 뒤 요청 헤더에 개발자 별로 고유한 ID를 담아 다른 요청이 intercept 하지 않도록 하여 협업에 용이한 상태로 개발을 진행할 수 있었습니다.

개인적으로 느낀 부분은 로컬 환경에서 원하는 component만 띄워서 개발 및 디버깅을 할 수 있는 장점이 있었으나, 각 component에 사용자가 개별 정의한 header를 전달해 주는 세팅이 필요하며, 모든 개발자들이 Telepresence 사용하는 방법에 협의를 하고 사용 방법에 대해서 어느 정도는 인지하고 있어야 한다는 단점이 있었습니다.

이미지 출처 및 참고자료

• https://www.getambassador.io/docs/telepresence/latest/reference/architecture • https://www.getambassador.io/docs/telepresence/latest/reference/client • https://www.getambassador.io/docs/telepresence/latest/concepts/intercepts • https://www.getambassador.io/docs/telepresence/latest/install • https://www.digitalocean.com/community/tutorials/how-to-use-telepresence-on-kubernetes-for-rapid-development-on-ubuntu-20-04