소개
이 실습에서는 실행 중인 Pod 와 상호 작용하는 데 필요한 핵심 기법을 배웁니다. Kubernetes 에서는 워크로드가 여러 곳에 분산되는 경우가 많고 로컬 프로세스처럼 직접 보이지 않기 때문에, 이러한 기법은 기본적인 디버깅 역량에 해당합니다.
다음 세 가지 강력한 디버깅 기법을 다룹니다.
- 로그: 애플리케이션의 상태를 확인하기 위해 애플리케이션이 출력하는 내용을 읽습니다.
- Exec: 컨테이너 내부로 들어가 환경을 살펴보고 명령을 실행합니다.
- 포트 포워딩: 로컬 컴퓨터에서 애플리케이션에 액세스할 수 있도록 임시 터널을 만듭니다.
이러한 기술은 모든 DevOps 엔지니어와 개발자에게 기본적으로 필요합니다. 이 실습을 마치면 실행 중인 Pod 를 자신 있게 조사할 수 있습니다.
로그 확인
이 단계에서는 실행 중인 Pod 의 로그를 확인하는 방법을 배웁니다. 로그를 애플리케이션의 "목소리"라고 생각해 보세요. 문제가 발생하면 로그에서 단서를 찾는 것이 일반적으로 가장 먼저 할 일입니다.
내부적으로 kubectl logs는 일반적으로 기본 컨테이너 프로세스가 표준 출력과 표준 오류에 기록한 내용을 읽습니다. 따라서 컨테이너화된 애플리케이션 대부분은 로컬 파일에 기록하는 대신 터미널에 로그를 출력하도록 설계됩니다. Kubernetes 에서는 터미널 출력을 플랫폼에서 일관되게 수집하고 노출하기가 더 쉽습니다.
환경에서 백그라운드로 my-nginx라는 Pod 를 시작합니다. 먼저 Pod 가 생성될 때까지 기다립니다.
until kubectl get pod my-nginx > /dev/null 2>&1; do sleep 2; done
그런 다음 컨테이너가 준비될 때까지 기다립니다.
kubectl wait --for=condition=ready pod/my-nginx --timeout=300s
이제 Pod 가 실행 중인지 확인합니다.
kubectl get pods
상태가 Running인 my-nginx가 표시되어야 합니다. 아직 준비되지 않았다면 잠시 기다린 후 다시 실행합니다.
Pod 가 실행되면 kubectl logs 명령으로 컨테이너가 표준 출력에 기록한 내용을 확인합니다.
kubectl logs my-nginx
Nginx 는 안정적인 웹 서버이므로 처음에는 출력이 거의 없거나, 연결을 받을 준비가 되었다는 메시지만 표시될 수 있습니다.
로그를 실시간으로 확인하려면 (실시간 TV 방송을 보는 것처럼) -f(follow) 플래그를 추가합니다.
kubectl logs -f my-nginx
커서가 멈춘 채 새 메시지를 기다리는 것을 볼 수 있습니다. 이 기능은 들어오는 트래픽을 실시간으로 확인할 때 유용합니다. 로그 추적을 중지하고 터미널 프롬프트로 돌아가려면 Ctrl+C를 누릅니다.
컨테이너에서 Exec 실행
이 단계에서는 로그를 읽는 데서 더 나아가 Pod 내부에서 명령을 실행합니다. 설정 파일이 존재하는지 확인하거나, 특정 도구가 설치되어 있는지 확인하거나, Pod 내부에서 네트워크 연결을 테스트해야 할 수 있습니다.
kubectl exec 명령을 사용하면 이 작업을 수행할 수 있습니다. 이 명령은 실행 중인 컨테이너 내부에서 명령을 실행합니다. 일반적으로 대화형 셸을 열 때 사용하며, 컨테이너 내부로 "순간 이동"하는 것과 같습니다.
여기서 중요한 차이점이 있습니다. kubectl exec는 SSH 처럼 사용자를 다른 컴퓨터로 "이동"시키지 않습니다. 노드의 kubelet 에 이미 실행 중인 컨테이너 내부에서 새 프로세스를 시작하도록 요청합니다. 따라서 로컬 터미널의 환경이 아니라 컨테이너의 파일 시스템과 환경을 보게 됩니다.
다음 명령을 실행하여 my-nginx Pod 내부에서 bash 셸을 엽니다.
kubectl exec -it my-nginx -- /bin/bash
각 플래그의 의미를 살펴봅니다.
-i(Interactive): 입력을 열린 상태로 유지하여 명령을 입력할 수 있게 합니다.-t(TTY): 일반적인 명령 프롬프트처럼 보이도록 의사 터미널을 할당합니다.--: 이 뒤에 오는 모든 항목이kubectl의 옵션이 아니라 컨테이너에서 실행할 명령임을kubectl에 알립니다.
명령 프롬프트가 root@my-nginx:/#와 같이 바뀌어야 합니다. 이제 Kubernetes 클러스터의 특정 컨테이너 내부에 있습니다.
새 환경에 들어왔는지 확인하기 위해 디렉터리의 파일을 나열합니다.
ls -F
여기에는 LabEx 작업 공간의 파일과 완전히 분리된 Nginx 컨테이너 내부의 파일이 표시됩니다.
환경 확인
이 단계에서는 컨테이너 내부의 환경을 확인합니다. 일반적인 디버깅 작업 중 하나는 컨테이너에서 실행 중인 운영 체제 (OS) 를 확인하는 것입니다. 이를 통해 apt나 apk와 같은 사용할 수 있는 명령을 파악할 수 있습니다.
이 과정에서는 컨테이너에 관한 중요한 개념도 배웁니다. 컨테이너 이미지에 따라 사용할 수 있는 사용자 공간 도구와 파일이 결정됩니다. 두 Pod 가 모두 "Linux"라고 해도 한 이미지는 Debian 기반이고 다른 이미지는 Alpine 기반일 수 있으며, 또 다른 이미지는 셸 도구를 거의 포함하지 않을 수도 있으므로 서로 크게 다를 수 있습니다.
프롬프트가 아직 root@my-nginx:/#인 상태에서 다음 명령을 실행하여 OS 릴리스 파일을 읽습니다.
cat /etc/os-release
Linux 배포판을 식별하는 출력이 표시되며, 일반적으로 "Debian GNU/Linux"가 나타납니다. 공식 Nginx 이미지가 Debian 을 기반으로 빌드되기 때문입니다.
탐색을 마쳤다면 컨테이너를 종료하고 기본 터미널로 돌아가야 합니다. 다음을 입력합니다.
exit
프롬프트가 labex:~/project로 돌아옵니다.
조사를 완료했는지 확인하기 위해 os_version.txt라는 파일을 만들고, 확인한 OS 이름 (예: "Debian") 을 파일에 기록합니다.
echo "Debian" > ~/project/os_version.txt
포트 포워딩
이 단계에서는 포트 포워딩을 통해 Nginx Pod 에 액세스합니다. 기본적으로 Pod 는 격리되어 있습니다. Pod 는 출입이 통제된 공동체의 집과 같아서 서로 통신할 수는 있지만, 외부에 있는 사용자 (예: 로컬 터미널을 사용하는 사용자) 는 쉽게 접근할 수 없습니다.
로컬 컴퓨터에서 my-nginx에서 실행 중인 웹 서버에 액세스하려면 포트 포워딩을 사용해 "비밀 터널"을 만들 수 있습니다.
포트 포워딩은 디버깅을 위한 편의 기능이며, 애플리케이션을 공개하는 일반적인 프로덕션 방식은 아닙니다. 현재 워크스테이션에서 하나의 Pod 로 연결되는 임시 터널을 만듭니다. 전체 Service 를 생성하거나 외부 네트워크 정책을 변경하지 않아도 되므로 검사와 빠른 테스트에 적합합니다.
다음 명령을 실행하여 로컬 포트 8080을 Pod 의 포트 80으로 포워딩합니다.
kubectl port-forward my-nginx 8080:80 &
끝에 있는 &에 유의하세요! 이 기호는 Linux 에서 이 프로세스를 백그라운드로 실행하도록 합니다. 이 기호가 없으면 명령이 터미널을 점유하므로 프로세스를 중지할 때까지 다른 내용을 입력할 수 없습니다.
Forwarding from 127.0.0.1:8080 -> 80이라는 메시지가 표시되어야 합니다.
이제 curl을 사용하여 이 터널을 통해 Nginx 웹 페이지에 액세스할 수 있습니다.
curl localhost:8080
Welcome to nginx! 페이지의 HTML 코드가 표시되어야 합니다. 성공했습니다. 클러스터 내부에 도달하여 터널을 통해 데이터를 가져왔습니다.
요약
이 실습에서는 Kubernetes 애플리케이션을 디버깅하는 데 필요한 세 가지 핵심 기술을 연습했습니다.
- 로그:
kubectl logs로 애플리케이션의 출력을 확인합니다. - Exec:
kubectl exec로 컨테이너 환경에 들어가 파일을 확인하고 명령을 실행합니다. - 포트 포워딩:
kubectl port-forward로 내부 서비스에 로컬에서 액세스합니다.
이 도구들은 청진기이자 X 선 기계와 같습니다. Kubernetes 에서 문제가 발생하면 가장 먼저 이 도구들을 사용해 문제를 진단합니다.
