쿠버네티스의 이해

이영진·2025년 3월 23일
SKALA쿠버네티스클라우드
0

클라우드

목록 보기
5/6
sudo ./docker-build.sh # 파일이름
sudo docker images
sudo ./docker-push.sh  # 파일이름

Docker 빌드 및 푸시 스크립트 설명

1. docker-build.sh 스크립트

이 스크립트는 Docker 이미지를 빌드하는 데 사용됩니다. 일반적으로 이 스크립트는 docker build 명령어를 사용하여 Dockerfile에 명시된 지시어를 실행하여 Docker 이미지를 생성합니다.

#!/bin/bash

# Docker 이미지 빌드
docker build -t myimage .

  • docker build: Dockerfile을 기반으로 Docker 이미지를 생성합니다.

  • -t myimage: 생성된 이미지를 myimage라는 이름으로 태깅합니다.

  • .: 현재 디렉토리를 빌드 컨텍스트로 사용합니다.

2. docker images 명령어

이 명령어는 로컬에 존재하는 Docker 이미지 목록을 출력합니다.

sudo docker images
  • docker images: 로컬에 저장된 Docker 이미지 목록을 표시합니다.

3. docker-push.sh 스크립트

이 스크립트는 Docker 이미지를 Docker Hub나 다른 레지스트리로 푸시하는 데 사용됩니다. 일반적으로 이 스크립트는 docker tag와 docker push 명령어를 사용합니다.

#!/bin/bash

# 이미지 태깅
docker tag myimage $1

# Docker Hub에 이미지 푸시
docker push $1

  • docker tag myimage $1: 이미지를 $1이라는 이름으로 태깅합니다. $1은 스크립트 실행 시 전달된 첫 번째 인자로, 일반적으로 username/repo:version 형식입니다.

  • docker push $1: 태깅된 이미지를 Docker Hub에 푸시합니다.

실행 방법

  1. 빌드 스크립트 실행:

    sudo ./docker-build.sh

  2. 이미지 목록 확인:

    sudo docker images

  3. 푸시 스크립트 실행:

    sudo ./docker-push.sh username/repo:version
    • username/repo:version은 Docker Hub에 푸시할 이미지의 이름과 버전을 지정합니다.

주의사항

  • Docker Hub에 푸시하려면 먼저 docker login 명령어로 로그인해야 합니다.

  • 스크립트는 실행 권한이 필요하므로, 필요 시 chmod +x docker-build.sh 및 chmod +x docker-push.sh 명령어로 권한을 부여합니다.

쿠버네티스 소개

1. 컨테이너의 한계

컨테이너 기술은 애플리케이션 배포의 효율성을 높였지만, 컨테이너의 수가 증가함에 따라 관리 문제가 발생합니다. 이는 모놀리식(Monolithic) 아키텍처와 달리, 마이크로 서비스 아키텍처에서 특히 두드러집니다.

많은 수의 컨테이너를 관리하고, 요청에 따라 적절히 스케줄링하고 배치하는 것이 필수적입니다.

2. 오케스트레이션의 필요성

오케스트레이션 시스템은 다수의 서버와 컨테이너를 논리적으로 하나의 시스템으로 통합하여, 요청에 맞춰 적절히 스케줄링하고 배치하는 역할을 합니다.

이는 물리적인 서버를 논리적으로 하나의 시스템으로 통일하여, 컨테이너가 효율적으로 운영되도록 지원합니다.

3. 쿠버네티스

쿠버네티스는 가상 머신(VM), 베어 메탈(Bare-Metal), 스토리지 등을 통합된 논리적 자원으로 구성하여 애플리케이션을 스케줄링하는 Cloud OS로 볼 수 있습니다.

쿠버네티스는 클라우드 네이티브 애플리케이션을 위한 오케스트레이션 시스템으로, 확장성과 유연성을 제공합니다.

4. 메니페스트(Manifest)

메니페스트는 YAML 파일 형태로, 쿠버네티스 객체의 설정과 정의를 포함하는 문서입니다.

이는 리소스 명세를 담는 그릇으로, 쿠버네티스에서 Pod, Deployment, Service 등의 리소스를 정의하는 데 사용됩니다.

5. 리소스(Resource)

쿠버네티스에서 리소스는 클러스터 내에서 관리되는 모든 요소를 의미합니다. 이는 Ingress, Service, Pod, Deployment 등 다양한 추상화된 객체를 포함합니다.

쿠버네티스는 클러스터를 하나의 거대한 컴퓨팅 플랫폼으로 보고, 이 안에서 관리되는 모든 요소를 리소스로 정의합니다.

6. 쿠버네티스의 주요 리소스

  • Pod: 쿠버네티스에서 가장 작은 실행 단위로, 하나 이상의 컨테이너를 포함할 수 있습니다.

  • Deployment: Pod의 배포와 관리를 담당하며, 롤백 및 확장 기능을 제공합니다.

  • Service: Pod에 대한 네트워크 접근을 제공하며, 서비스 디스커버리와 로드 밸런싱을 지원합니다.

  • Ingress: 외부에서 클러스터 내부의 서비스로 요청을 라우팅하는 역할을 합니다.

쿠버네티스 환경에서의 선언적 관리 방식

주요 내용

  1. 리소스(Resource) 생성:

    • 쿠버네티스 환경에서 애플리케이션을 실행하기 위해서는 다양한 리소스를 만들어야 합니다.

    • 리소스는 클러스터 내에서 관리되는 객체로, 예를 들어 Pod, Service, Deployment 등이 포함됩니다.

  2. Manifest 작성:

    • 리소스를 생성하기 위해 필요한 설정과 정의를 포함한 명세서를 작성해야 합니다.

    • Manifest 파일은 주로 YAML 형식으로 작성되며, 리소스의 구성과 동작 방식을 명시합니다.

  3. 선언적 방식:

    • 사용자는 Manifest 파일을 작성하여 쿠버네티스에 전달한 후 더 이상 신경 쓰지 않아도 됩니다.

    • 쿠버네티스는 내부 컨트롤러(Controller)를 통해 지속적으로 리소스를 관리하고 운영합니다.

  4. REST API를 통한 전달:

    • Manifest 파일은 kubectl CLI(Command Line Interface)를 통해 쿠버네티스의 REST API로 전달됩니다.

    • 이를 통해 사용자가 정의한 명세(specification)에 따라 리소스를 생성하고, 클러스터 내에서 자동으로 운영됩니다.

선언적 관리 방식의 특징

  • 사용자는 애플리케이션의 상태를 정의만 하고, 실제 운영은 쿠버네티스가 자동으로 처리합니다.

  • 내부 컨트롤러는 지속적으로 리소스를 모니터링하고, 원하는 상태(desired state)를 유지하도록 보장합니다.

  • 이 방식은 운영 자동화와 안정성을 높이는 데 유리하며, 대규모 클러스터 환경에서 특히 효과적입니다.

결론

쿠버네티스는 컨테이너의 관리 문제를 해결하기 위해 등장한 오케스트레이션 시스템으로, 다양한 리소스를 통합하여 애플리케이션을 효율적으로 스케줄링하고 배치합니다. 메니페스트와 리소스는 쿠버네티스에서 중요한 개념으로, 애플리케이션의 설정과 관리를 가능하게 합니다.

쿠버네티스 코어 구조

쿠버네티스는 Control Plane과 Data Plane으로 구성되어 있으며, API Server를 통해 통신합니다.

Control Plane은 클러스터의 상태를 관리하고, Data Plane은 실제 워크로드를 실행하는 역할을 합니다.

주요 구성 요소

  1. Control Plane:

    • API Server: 쿠버네티스의 모든 요청이 이 서버를 통해 처리됩니다. 사용자는 kubectl 명령어를 통해 API Server와 상호작용합니다.

    • Scheduler: Pod를 적절한 노드에 배치합니다.

    • Controller Manager: 클러스터의 상태를 모니터링하고 원하는 상태를 유지합니다.

  2. Data Plane:

    • Worker Node: 실제 워크로드를 실행하는 노드입니다. 각 노드에는 kubelet과 container runtime이 설치되어 있습니다.

    • kubelet: 각 노드에서 실행되는 에이전트로, Pod의 상태를 모니터링하고 API Server에 보고합니다.

    • container runtime: 컨테이너를 실행하는 소프트웨어로, Docker, runc 등이 있습니다.

주요 리소스

  1. Pod:

    • 쿠버네티스에서 배포할 수 있는 가장 작은 단위입니다.
    • 하나 이상의 컨테이너를 포함할 수 있으며, 하나의 애플리케이션으로 간주됩니다.
    • 각 Pod는 하나의 노드에만 속해야 합니다.

  2. Service:

    • Pod를 네트워크 상에 노출시키는 방법으로, 추상화 계층을 제공합니다.
    • 서비스 이름을 통해 접근할 수 있도록 하며, 로드 밸런싱 기능을 지원합니다.

  3. Deployment:

    • 여러 개의 Pod를 관리하기 위한 상위 리소스입니다.
    • 원하는 Pod의 규격(desired spec)을 선언하여 배포 및 관리합니다.

  4. Ingress:

    • 클러스터 외부에서 내부 서비스로 HTTP 및 HTTPS 트래픽을 라우팅하는 리소스입니다.
    • 외부 요청을 내부 서비스로 전달하는 역할을 수행합니다.

  5. ConfigMap:

    • 환경 변수나 설정 파일을 컨테이너 실행 시 주입하기 위한 리소스입니다.
    • 애플리케이션의 설정 정보를 중앙에서 관리할 수 있게 합니다.

  6. Secret:

    • 비밀 정보를 저장하고 관리하는 리소스입니다.
    • ConfigMap과 유사하지만, 사람이 읽을 수 없도록 인코딩하여 저장합니다.

  7. Namespace:

    • 쿠버네티스에서 애플리케이션을 배포할 때 사용되는 논리적 격리 단위입니다.
    • 네임스페이스는 리소스 이름 충돌을 방지하고, 리소스 할당 및 보안을 관리하는 데 사용됩니다.

추가 설명

  • Proxy: 네트워크 관리를 담당하며, 계속 변화하는 IP 주소를 조정합니다. 예를 들어, kube-proxy는 서비스의 IP 주소를 관리하여 트래픽을 적절한 Pod로 라우팅합니다.

  • 선언적 관리: 쿠버네티스는 선언적 관리 방식을 사용하여 사용자가 원하는 상태(desired state)를 정의하면, 시스템이 자동으로 그 상태를 유지하도록 합니다. 이는 API Server와 Controller가 협력하여 이루어집니다.

  • 노드, 파드, 컨테이너 관계: 각 노드는 여러 개의 파드를 실행할 수 있으며, 각 파드는 하나 이상의 컨테이너를 포함할 수 있습니다. 노드는 실제 워크로드를 실행하는 역할을 하며, 파드는 그 안에서 실행되는 논리적 단위입니다.

결론

쿠버네티스는 다양한 리소스를 통해 클러스터를 관리하고, 애플리케이션의 배포 및 운영을 자동화합니다. 선언적 관리 방식과 다양한 리소스를 활용하여, 대규모 시스템을 효율적으로 운영할 수 있습니다.

profile
이영진
이전 포스트

컨테이너와 쿠버네티스의 관계

다음 포스트

쿠버네티스 심화

0개의 댓글