앱 탐색하기

앱 탐색하기 (Explore Your App)

출처: 문서

본문

목표 (Objectives)

• 쿠버네티스 Pod에 대해 배운다.
• 쿠버네티스 Node에 대해 배운다.
• 배포된 애플리케이션을 문제 해결한다.

시작하기 전에

이 튜토리얼의 셸 명령은 대부분의 Linux·macOS 시스템의 기본 셸(예: bash, zsh, sh)이 지원하는 POSIX 셸 구문을 사용해요. Windows 사용자는 명령을 그대로 실행하려면 Windows Subsystem for Linux (WSL)이나 Git Bash 같은 POSIX 호환 셸을 사용해야 합니다. export, $() 같은 구조를 사용하는 명령은 PowerShell이나 Windows Command Prompt와 호환되지 않습니다.

쿠버네티스 Pod

파드는 하나 이상의 애플리케이션 컨테이너(예: Docker)의 그룹이며, 공유 스토리지(볼륨), IP 주소, 실행 방법에 대한 정보를 포함한다.

Module 2에서 Deployment를 만들 때 쿠버네티스는 애플리케이션 인스턴스를 호스팅하는 Pod를 만들었어요. Pod는 하나 이상의 애플리케이션 컨테이너(예: Docker)의 그룹과 그 컨테이너를 위한 일부 공유 리소스를 나타내는 쿠버네티스 추상화입니다. 그 리소스에는 다음이 포함됩니다:

• 공유 스토리지 (볼륨으로)
• 네트워킹 (고유한 클러스터 IP 주소로)
• 각 컨테이너를 실행하는 방법에 대한 정보 (컨테이너 이미지 버전이나 사용할 특정 포트 같은)

Pod는 애플리케이션 특정의 "논리적 호스트"를 모델링하며, 상대적으로 긴밀하게 결합된 서로 다른 애플리케이션 컨테이너를 포함할 수 있어요. 예를 들어 Pod에는 Node.js 앱이 있는 컨테이너와 Node.js 웹서버가 게시할 데이터를 공급하는 다른 컨테이너가 모두 포함될 수 있습니다. Pod의 컨테이너는 IP 주소와 포트 공간을 공유하고, 항상 함께 배치·공동 스케줄되며, 같은 노드의 공유 컨텍스트에서 실행됩니다.

Pod는 쿠버네티스 플랫폼의 원자 단위예요. 쿠버네티스에서 Deployment를 만들면 그 Deployment는 (컨테이너를 직접 만드는 대신) 안에 컨테이너가 있는 Pod를 만듭니다. 각 Pod는 스케줄된 노드에 묶이며, (재시작 정책에 따라) 종료되거나 삭제될 때까지 거기 머뭅니다. 노드 실패 시 동일한 Pod가 클러스터의 다른 사용 가능한 노드에 스케줄됩니다.

Pods 개요

컨테이너는 디스크 같은 리소스를 공유해야 하며 긴밀하게 결합된 경우에만 단일 Pod에서 함께 스케줄되어야 한다.

Nodes

Pod는 항상 Node에서 실행돼요. Node는 쿠버네티스의 워커 머신이며 클러스터에 따라 가상 또는 물리 머신일 수 있습니다. 각 Node는 컨트롤 플레인이 관리합니다. Node는 여러 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인이 클러스터의 노드에 걸쳐 파드 스케줄링을 자동으로 처리합니다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 고려합니다.

모든 쿠버네티스 Node는 최소한 다음을 실행합니다:

• Kubelet - 쿠버네티스 컨트롤 플레인과 노드 사이의 통신을 담당하는 프로세스. 머신에서 실행되는 Pod와 컨테이너를 관리한다.

• 컨테이너 런타임(containerd 같은) - 레지스트리에서 컨테이너 이미지를 가져오고, 컨테이너를 풀고, 애플리케이션을 실행하는 책임.

Nodes 개요

kubectl로 문제 해결하기

Module 2에서 kubectl 명령줄 인터페이스를 사용했어요. Module 3에서도 계속 사용해 배포된 애플리케이션과 그 환경에 대한 정보를 얻을 것입니다. 가장 흔한 연산은 다음 kubectl 하위 명령으로 할 수 있습니다:

• kubectl get - 리소스 나열
• kubectl describe - 리소스에 대한 상세 정보 표시
• kubectl logs - 파드의 컨테이너에서 로그 출력
• kubectl exec - 파드의 컨테이너에서 명령 실행

이 명령들을 사용해 애플리케이션이 언제 배포되었는지, 현재 상태가 무엇인지, 어디서 실행 중인지, 구성이 무엇인지 볼 수 있습니다.

이제 클러스터 구성 요소와 명령줄에 대해 더 알았으니 애플리케이션을 탐색해봅시다.

애플리케이션 구성 확인

이전 시나리오에서 배포한 애플리케이션이 실행 중인지 확인해봅시다. kubectl get 명령을 사용해 기존 파드를 찾을 거예요:

kubectl get pods

실행 중인 파드가 없으면 몇 초 기다렸다가 파드를 다시 나열해주세요. 파드 하나가 실행 중인 것을 확인하면 계속할 수 있습니다.

다음으로 그 파드 안에 어떤 컨테이너가 있고 그 컨테이너를 만드는 데 어떤 이미지가 사용되는지 보려면 kubectl describe pods 명령을 실행해요:

kubectl describe pods

여기서 파드의 컨테이너에 대한 세부 사항(IP 주소, 사용된 포트, 파드 라이프사이클과 관련된 이벤트 목록)을 볼 수 있습니다.

describe 하위 명령의 출력은 방대하며 아직 설명하지 않은 일부 개념을 다루는데, 걱정하지 마세요. 이 튜토리얼이 끝날 무렵에는 익숙해질 것입니다.

describe 하위 명령은 Nodes, Pods, Deployments를 포함한 대부분의 쿠버네티스 프리미티브에 대한 상세 정보를 얻는 데 사용될 수 있어요. describe 출력은 스크립트 대상이 아니라 인간이 읽기 쉽도록 설계되었습니다.

터미널에서 앱 보기

파드가 격리된 사설 네트워크에서 실행 중임을 기억하세요. 그래서 파드에 디버깅·상호작용을 위해 프록시 접근이 필요합니다. 이를 위해 두 번째 터미널에서 프록시를 실행할 kubectl proxy 명령을 사용할 거예요. 새 터미널 창을 열고 그 새 터미널에서 다음을 실행해요:

kubectl proxy

이제 다시 파드 이름을 얻고 프록시를 통해 그 파드를 직접 질의할 거예요. 파드 이름을 얻어 POD_NAME 환경 변수에 저장하려면:

export POD_NAME="$(kubectl get pods -o go-template --template '{{range .items}}{{.metadata.name}}{{"\n"}}{{end}}')"
echo Name of the Pod: $POD_NAME

우리 애플리케이션의 출력을 보려면 curl 요청을 실행해요:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

이 URL은 파드의 API에 대한 경로입니다.

파드 안에 컨테이너가 하나뿐이라 컨테이너 이름을 지정할 필요가 없습니다.

컨테이너에서 명령 실행

Pod가 실행 중이면 컨테이너에서 명령을 직접 실행할 수 있어요. 이를 위해 exec 하위 명령을 사용하고 파드 이름을 파라미터로 사용합니다. 환경 변수를 나열해봅시다:

kubectl exec "$POD_NAME" -- env

다시, 파드에 컨테이너가 하나뿐이므로 컨테이너 이름 자체는 생략할 수 있다는 점을 언급할 가치가 있습니다.

다음으로 파드의 컨테이너에서 bash 세션을 시작해봅시다:

kubectl exec -ti $POD_NAME -- bash

이제 NodeJS 애플리케이션을 실행하는 컨테이너에 열린 콘솔이 있습니다. 앱의 소스 코드는 server.js 파일에 있습니다:

cat server.js

curl 명령을 실행해 애플리케이션이 실행 중인지 확인할 수 있습니다:

curl http://localhost:8080

NodeJS Pod 안에서 명령을 실행했으므로 여기서 localhost를 사용했습니다. localhost:8080에 연결할 수 없다면 kubectl exec 명령을 실행했고 Pod 안에서 명령을 시작하는지 확인하세요.

컨테이너 연결을 닫으려면 exit를 입력하세요.

더 알아보기 (Learn more)

• Service로 앱 노출하기 튜토리얼.
• Pods에 대해 더 알아보기.
• Nodes에 대해 더 알아보기.