쿠버네티스 클러스터 아키텍처 - Kubernetes 구조 이해

소개

이 랩에서는 강력한 컨테이너 오케스트레이션 플랫폼인 Kubernetes 의 아키텍처를 탐구합니다. Kubernetes 클러스터를 구성하는 주요 구성 요소를 살펴보고, 컨테이너화된 애플리케이션을 관리하기 위해 이들이 어떻게 상호 작용하는지 배웁니다. 이 랩은 초보자를 위해 설계되었으며, Kubernetes 아키텍처에 대한 실습 소개를 제공합니다.

이것은 가이드 실험입니다. 학습과 실습을 돕기 위한 단계별 지침을 제공합니다.각 단계를 완료하고 실무 경험을 쌓기 위해 지침을 주의 깊게 따르세요. 과거 데이터에 따르면, 이것은 초급 레벨의 실험이며 완료율은 92%입니다.학습자들로부터 96%의 긍정적인 리뷰율을 받았습니다.

제어 평면 구성 요소 탐색

Minikube 를 사용하여 Kubernetes 클러스터를 시작하고 제어 평면 구성 요소를 살펴보겠습니다.

먼저, 터미널을 엽니다. 기본적으로 /home/labex/project 디렉토리에 있어야 합니다. 그렇지 않은 경우, 해당 디렉토리로 이동합니다.

cd ~/project

이제 다음 명령으로 Minikube 를 시작합니다.

minikube start

이 명령은 로컬 머신에 단일 노드 Kubernetes 클러스터를 초기화합니다. 완료하는 데 몇 분 정도 걸릴 수 있습니다. 많은 출력이 표시되더라도 걱정하지 마십시오. 이는 정상입니다.

Minikube 가 시작되면 제어 평면 구성 요소를 살펴보겠습니다. 제어 평면은 Kubernetes 의 핵심이며, 클러스터의 전반적인 상태를 관리하는 역할을 합니다. 이러한 구성 요소의 상태를 확인하려면 다음을 실행합니다.

kubectl get componentstatuses

다음과 유사한 출력이 표시됩니다.

NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true"}

각 구성 요소가 수행하는 작업을 자세히 살펴보겠습니다.

스케줄러 (scheduler): 이 구성 요소는 노드가 할당되지 않은 새로 생성된 Pod 를 감시하고, Pod 가 실행될 노드를 선택합니다.
컨트롤러 매니저 (controller manager): 이 구성 요소는 시스템의 상태를 조절하는 컨트롤러 프로세스를 실행합니다. 예를 들어, 복제 컨트롤러는 적절한 수의 Pod 복제본이 실행되도록 보장합니다.
etcd: 이는 Kubernetes 의 모든 클러스터 데이터에 대한 백업 저장소 역할을 하는 분산 키 - 값 저장소입니다.

모든 구성 요소가 "Healthy"로 표시되면 제어 평면이 올바르게 작동하고 있는 것입니다. 오류가 표시되면 minikube delete를 실행한 다음 minikube start를 사용하여 Minikube 를 다시 시작하는 것이 좋습니다.

노드 구성 요소 검토

이제 제어 평면을 살펴보았으니, 노드 구성 요소를 검토해 보겠습니다. Kubernetes 에서 노드는 애플리케이션을 실행하는 작업 머신입니다. 컨테이너 실행이라는 무거운 작업을 수행하는 클러스터의 근육이라고 생각하면 됩니다.

클러스터의 노드를 보려면 다음을 실행합니다.

kubectl get nodes

다음과 유사한 출력이 표시됩니다.

NAME       STATUS   ROLES    AGE   VERSION
minikube   Ready    control plane   10m   v1.20.0

이 출력은 "minikube"라는 하나의 노드가 있음을 보여주며, 이는 마스터 (제어 평면) 이자 작업자 노드입니다. 단일 노드 클러스터를 사용하고 있기 때문입니다. 프로덕션 환경에서는 일반적으로 여러 노드가 있으며, 마스터 노드와 작업자 노드가 별도로 존재합니다.

"Ready" 상태는 노드가 정상이며 Pod 를 수락할 준비가 되었음을 의미합니다.

노드에 대한 자세한 정보를 얻으려면 다음을 사용합니다.

kubectl describe node minikube

이 명령은 노드에 대한 풍부한 정보를 제공합니다. 압도적으로 느껴지더라도 걱정하지 마십시오. 몇 가지 주요 섹션을 살펴보겠습니다.

노드 상태 (Node Conditions): 이는 다양한 노드 상태 (예: Ready, DiskPressure, MemoryPressure) 의 상태를 보여줍니다.
용량 (Capacity): 이는 노드에서 사용 가능한 총 리소스 (CPU 및 메모리) 를 보여줍니다.
할당 가능 (Allocatable): 이는 Pod 가 사용할 수 있는 리소스를 보여줍니다.
시스템 정보 (System Info): 이는 노드의 운영 체제, 커널 버전 및 컨테이너 런타임에 대한 정보를 제공합니다.

직접적으로 보이지는 않지만 노드에서 실행되는 주요 노드 구성 요소는 다음과 같습니다.

kubelet: 이는 기본 노드 에이전트입니다. 해당 노드에 할당된 Pod 를 감시하고 Pod 가 실행되도록 보장합니다.
kube-proxy: 이는 노드에서 네트워크 규칙을 유지 관리하여 클러스터 내부 또는 외부에서 Pod 로의 네트워크 통신을 허용합니다.

Pod 생성 및 검토

시작하기 전에 Kubernetes 에서 YAML 이 어떻게 작동하는지 이해해 보겠습니다.

Kubernetes 의 YAML 파일은 "코드로서의 인프라 (Infrastructure as Code)" 역할을 합니다.

Kubernetes 에 원하는 것을 알려주는 "메뉴"라고 생각하십시오.
사람이 읽을 수 있는 형식으로 원하는 시스템 상태를 설명합니다.
팀 협업을 위해 버전 관리할 수 있습니다.

첫 번째 YAML 파일을 만들어 보겠습니다. simple-pod.yaml을 생성합니다.

nano ~/project/simple-pod.yaml

다음 내용을 추가합니다.

## --- YAML 파일 시작 ---
## 1. Kubernetes 에 사용할 API 버전을 알려줍니다.
apiVersion: v1
## 2. 어떤 종류의 리소스를 생성할지 선언합니다.
kind: Pod
## 3. 이 리소스에 대한 메타데이터를 설정합니다.
metadata:
  name: nginx-pod ## Pod 의 이름
  labels: ## 레이블은 Pod 를 찾고 구성하는 데 도움이 됩니다.
    app: nginx
## 4. Pod 에 포함될 내용을 정의합니다.
spec:
  containers: ## Pod 는 하나 이상의 컨테이너를 실행할 수 있습니다.
    - name: nginx ## 컨테이너의 이름
      image: nginx:latest ## 사용할 컨테이너 이미지
      ports: ## 노출할 포트
        - containerPort: 80 ## Nginx 는 기본적으로 포트 80 을 사용합니다.

YAML 파일 구조는 트리와 같습니다.

Pod (root)
├── metadata (branch)
│   ├── name (leaf)
│   └── labels (leaf)
└── spec (branch)
    └── containers (branch)
        └── - name, image, ports (leaves)

Pod 를 생성합니다.

kubectl apply -f simple-pod.yaml ## -f는 파일에서 읽는다는 의미입니다.

이 명령은 다음을 수행합니다.

YAML 파일을 읽습니다.
Kubernetes API 로 보냅니다.
Kubernetes 는 설명된 상태를 달성하기 위해 작동합니다.

Pod 생성을 확인합니다.

kubectl get pods

다음과 같은 출력이 표시됩니다.

NAME        READY   STATUS    RESTARTS   AGE
nginx-pod   1/1     Running   0          30s

READY 아래의 "1/1"은 Pod 의 컨테이너 중 하나가 준비되었음을 의미합니다. STATUS 아래의 "Running"은 첫 번째 YAML 구성이 작동했음을 의미합니다!

💡 Pro Tips:

YAML 에서 들여쓰기는 중요합니다. 탭이 아닌 공백을 사용하십시오.

kubectl explain pod를 사용하여 필드 문서를 확인하십시오.

유지 관리를 위해 항상 주석을 추가하십시오.

Pod 에 대한 자세한 정보를 얻으려면 다음을 사용합니다.

kubectl describe pod nginx-pod

이 명령은 다음을 포함한 많은 정보를 제공합니다.

Pod 가 실행 중인 노드
Pod 의 IP 주소
Pod 의 컨테이너
Pod 와 관련된 최근 이벤트

이 정보는 애플리케이션의 상태를 디버깅하고 이해하는 데 매우 중요합니다.

Service 생성

이제 실행 중인 Pod 가 있으므로, 이를 노출하기 위해 Service 를 생성해 보겠습니다. Kubernetes 에서 Service 는 Pod 의 논리적 집합과 이에 접근하는 정책을 정의하는 추상화입니다. 클러스터 내부 또는 외부에서 애플리케이션을 네트워크에 노출하는 방법이라고 생각하면 됩니다.

프로젝트 디렉토리에 nginx-service.yaml이라는 파일을 생성합니다.

nano ~/project/nginx-service.yaml

파일에 다음 내용을 추가합니다.

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: NodePort

이 YAML 파일을 자세히 살펴보겠습니다.

selector: 이 설정은 Service 가 트래픽을 보낼 Pod 를 결정합니다. 이 경우, app: nginx 레이블이 있는 모든 Pod 를 선택합니다.
ports: 이 설정은 Service 가 사용해야 하는 포트를 지정합니다.
type: NodePort: 이는 Service 가 클러스터의 각 노드에서 포트를 통해 접근할 수 있음을 의미합니다.

파일을 저장하고 편집기를 종료합니다.

이제 다음을 실행하여 서비스를 생성합니다.

kubectl apply -f nginx-service.yaml

서비스의 상태를 확인하려면 다음을 사용합니다.

kubectl get services

다음과 유사한 출력이 표시됩니다.

NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
kubernetes      ClusterIP   10.96.0.1       <none>        443/TCP        1h
nginx-service   NodePort    10.110.126.65   <none>        80:30080/TCP   30s

nginx-service 행은 서비스가 생성되었음을 보여줍니다. PORT(S) 아래의 80:30080/TCP는 클러스터 내부의 포트 80 이 노드의 포트 30080 에 매핑되었음을 의미합니다.

서비스에 대한 자세한 정보를 얻으려면 다음을 사용합니다.

kubectl describe service nginx-service

이 명령은 서비스의 유형, IP 주소, 포트 및 엔드포인트에 대한 정보를 제공합니다. 엔드포인트는 Service 가 트래픽을 보내는 Pod 의 IP 주소입니다.

애플리케이션 접속

이제 애플리케이션을 실행하는 Pod 와 이를 노출하는 Service 가 있으므로, 애플리케이션에 접근해 보겠습니다. 이 단계에서는 우리가 설정한 모든 구성 요소가 함께 작동하여 애플리케이션에 접근할 수 있도록 하는 방법을 보여줍니다.

먼저, Minikube 가 서비스에 할당한 URL 을 찾아야 합니다.

minikube service nginx-service --url

이 명령은 http://192.168.64.2:30080과 같은 URL 을 출력합니다. IP 주소는 사용자의 컴퓨터에 따라 다를 수 있습니다.

애플리케이션에 접근하려면 URL 다음에 curl 명령을 사용할 수 있습니다.

curl $(minikube service nginx-service --url)

이 명령은 기본 Nginx 환영 페이지 HTML 을 반환해야 합니다. <!DOCTYPE html>로 시작하는 HTML 출력이 표시되면 성공적으로 애플리케이션에 접근한 것입니다!

방금 일어난 일을 자세히 살펴보겠습니다.

요청은 먼저 우리가 생성한 NodePort 서비스에 도달했습니다.
그런 다음 서비스는 요청을 Nginx 컨테이너를 실행하는 Pod 로 전달했습니다.
Nginx 컨테이너는 요청을 처리하고 기본 환영 페이지를 다시 보냈습니다.

이는 Kubernetes 가 기본 인프라를 추상화하여 애플리케이션이 실행되는 특정 머신에 대해 걱정하지 않고 애플리케이션에 집중할 수 있도록 하는 방법을 보여줍니다.

요약

이 랩에서는 Kubernetes 의 주요 구성 요소와 상호 작용을 검토하여 Kubernetes 의 아키텍처를 탐구했습니다. Minikube 를 사용하여 Kubernetes 클러스터를 시작하고, 제어 평면 (Control Plane) 및 노드 구성 요소를 검사하고, 애플리케이션을 실행하기 위한 Pod 를 생성하고, Service 를 사용하여 애플리케이션을 노출하고, 마지막으로 애플리케이션에 접근했습니다.

graph TB subgraph Control Plane API[API Server] CM[Controller Manager] SCH[Scheduler] ETCD[etcd] API --> ETCD API --> CM API --> SCH end subgraph Worker Node KL[kubelet] KP[kube-proxy] CR[Container Runtime] subgraph Workloads POD1[Pod] POD2[Pod] end SVC[Service] KL --> CR POD1 --> CR POD2 --> CR KP --> SVC SVC --> POD1 SVC --> POD2 end API --> KL Client[External Client] --> SVC

다음 사항에 대해 배웠습니다.

API 서버, 스케줄러 (Scheduler), 컨트롤러 매니저 (Controller Manager) 와 같은 제어 평면 구성 요소
kubelet 및 kube-proxy 와 같은 노드 구성 요소
Kubernetes 에서 배포 가능한 가장 작은 단위인 Pod
애플리케이션을 노출하는 방법인 Service

이 실습 경험은 Kubernetes 아키텍처를 이해하기 위한 견고한 기반을 제공합니다. Kubernetes 는 많은 움직이는 부분으로 구성된 복잡한 시스템이며, 모든 것을 즉시 이해하지 못하는 것은 괜찮습니다. Kubernetes 를 계속 사용하면서 이러한 개념은 더욱 익숙해지고 직관적으로 다가올 것입니다.

Kubernetes 여정의 다음 단계에는 애플리케이션의 여러 복제본을 관리하기 위한 Deployment, 구성을 관리하기 위한 ConfigMap 및 Secret, 데이터 저장을 위한 Persistent Volume 에 대해 배우는 것이 포함될 수 있습니다. 계속 탐구하고 즐거운 Kuberneting 되세요!