서버구축 (WEB,DB)

컨테이너 오케스트레이션 플랫폼 K8s, K3s, Minikube 분석

날으는물고기 2024. 8. 22. 00:11

Bare Metal, Virtualization, Container의 비교

Bare Metal

  • 물리적인 서버 하드웨어에서 직접 운영체제와 애플리케이션이 구동되는 환경입니다.
  • 하드웨어 자원을 최대한 활용할 수 있습니다.

장점

  • 고성능: 중간 레이어가 없어 직접 하드웨어 자원을 활용하여 최대 성능을 낼 수 있습니다.
  • 예측 가능성: 하드웨어 자원이 고정되어 있어 성능 예측이 쉽습니다.
  • 보안성: 단일 환경에서 운영되므로 보안 관점에서 단순합니다.

단점

  • 확장성 부족: 서버를 추가할 때마다 새로운 하드웨어를 추가해야 하므로 확장성이 떨어집니다.
  • 비용: 물리적 서버를 다수 운영할 경우 초기 비용과 유지보수 비용이 높습니다.
  • 유연성 부족: 다양한 애플리케이션을 효율적으로 운영하기 위해서는 여러 대의 서버가 필요합니다.

Virtualization

  • 하나의 물리 서버에서 여러 개의 가상 머신(VM)을 생성하여 운영체제와 애플리케이션을 분리해 구동하는 방식입니다.
  • 하이퍼바이저(예: VMware, KVM, Hyper-V)가 물리 자원을 가상화합니다.

장점

  • 자원 효율성: 하나의 물리 서버를 여러 가상 머신으로 나눠 자원을 효율적으로 사용할 수 있습니다.
  • 유연성: 필요에 따라 가상 머신을 생성하거나 제거할 수 있어 유연한 자원 관리가 가능합니다.
  • 격리성: 각 VM은 독립된 환경에서 구동되므로 한 VM의 문제가 다른 VM에 영향을 미치지 않습니다.

단점

  • 오버헤드: 하이퍼바이저가 자원을 관리하므로 성능 오버헤드가 발생할 수 있습니다.
  • 복잡성: 가상 환경을 관리하기 위해 추가적인 관리 도구와 노하우가 필요합니다.
  • 비용: 하이퍼바이저와 가상화 관리 도구의 라이센스 비용이 발생할 수 있습니다.

Container

  • 애플리케이션과 그 의존성을 하나의 패키지로 묶어 격리된 환경에서 구동하는 기술입니다.
  • Docker, Kubernetes 등이 대표적인 도구입니다.

장점

  • 경량화: 컨테이너는 호스트 운영체제를 공유하므로 VM에 비해 매우 가볍고 빠릅니다.
  • 빠른 배포: 컨테이너 이미지를 통해 일관된 배포가 가능하며, 배포 속도가 빠릅니다.
  • 확장성: Kubernetes와 같은 오케스트레이션 도구를 사용하면 컨테이너를 자동으로 확장할 수 있습니다.
  • 이식성: 컨테이너 이미지는 어디서든 동일하게 실행될 수 있어 개발환경과 운영환경 간의 차이가 없습니다.

단점

  • 보안: 컨테이너는 호스트 운영체제를 공유하므로 보안 격리가 완벽하지 않을 수 있습니다.
  • 관리 복잡성: 많은 수의 컨테이너를 관리하려면 Kubernetes와 같은 복잡한 오케스트레이션 도구가 필요합니다.
  • 네트워크 오버헤드: 많은 컨테이너가 통신할 때 네트워크 오버헤드가 발생할 수 있습니다.

컨테이너의 특장점 및 최선의 방안

특장점

  • 경량성: 컨테이너는 VM보다 가볍고 빠르게 시작 및 종료할 수 있습니다.
  • 이식성: 컨테이너 이미지는 개발 환경과 운영 환경 간의 차이를 최소화하여 어디서나 동일하게 동작할 수 있습니다.
  • 확장성: 컨테이너 오케스트레이션 도구(Kubernetes)를 통해 자동 확장 및 축소가 가능합니다.
  • 효율성: 호스트 운영체제를 공유하여 자원을 효율적으로 사용할 수 있습니다.
  • 빠른 배포: CI/CD 파이프라인과 결합하여 코드 변경 사항을 빠르게 배포할 수 있습니다.

최선의 방안

현대 IT 환경에서는 컨테이너를 활용한 마이크로서비스 아키텍처가 최선의 방안으로 많이 채택되고 있습니다. 특히, Kubernetes와 같은 오케스트레이션 도구를 사용하여 컨테이너를 관리하면 다음과 같은 이점을 얻을 수 있습니다.

  • 자동화된 확장 및 복구: 애플리케이션의 부하에 따라 자동으로 컨테이너를 확장하거나 축소할 수 있으며, 장애가 발생한 컨테이너를 자동으로 복구합니다.
  • 일관된 배포: 컨테이너 이미지를 사용하여 일관된 환경에서 애플리케이션을 배포할 수 있습니다.
  • 멀티 클라우드 및 하이브리드 클라우드: Kubernetes를 사용하면 여러 클라우드 서비스 제공자 또는 온프레미스와 클라우드를 혼합한 환경에서도 일관되게 애플리케이션을 관리할 수 있습니다.
  • 보안 강화: 네임스페이스와 네트워크 정책을 사용하여 컨테이너 간의 통신을 제한하고, 보안성을 강화할 수 있습니다.

활용 사례

  • Netflix: 마이크로서비스 아키텍처를 도입하여 수천 개의 컨테이너를 운영하고 있으며, 이는 서비스의 유연성과 확장성을 크게 향상시켰습니다.
  • Google: 내부적으로 Borg라는 컨테이너 오케스트레이션 시스템을 사용하여 수백만 개의 컨테이너를 관리하며, 이를 바탕으로 Kubernetes를 오픈 소스로 공개하였습니다.
  • Airbnb: Docker와 Kubernetes를 활용하여 개발 환경과 운영 환경의 일관성을 유지하고, 빠른 배포와 확장을 가능하게 하였습니다.

컨테이너 기술은 현대 애플리케이션 개발 및 운영의 핵심 요소로 자리 잡고 있으며, 이를 효과적으로 활용하기 위해서는 적절한 도구와 전략을 선택하는 것이 중요합니다.

Bare Metal, Virtualization, Container의 비교 표

항목 Bare Metal Virtualization Container
성능 최고 성능, 중간 레이어 없음 성능 오버헤드 발생 가능 경량화, 빠른 성능
자원 효율성 자원 효율성 낮음 자원 효율성 중간 자원 효율성 높음
확장성 물리 서버 추가 필요 VM 추가로 확장 가능 컨테이너 자동 확장 가능
배포 속도 느림 빠름 매우 빠름
유연성 유연성 낮음 유연성 높음 매우 유연
보안성 보안성 높음 보안성 중간 보안성 향상 필요
관리 복잡성 관리 복잡성 낮음 관리 복잡성 중간 관리 복잡성 높음
비용 초기 비용 및 유지 비용 높음 라이센스 비용 발생 가능 비용 효율적
이식성 물리적 환경에 종속 특정 하이퍼바이저에 종속될 수 있음 환경 간 이식성 높음
운영체제 단일 운영체제 사용 VM마다 별도 운영체제 사용 가능 호스트 운영체제 공유
격리성 격리성 낮음 VM 간 완전 격리 프로세스 수준 격리
  • Bare Metal은 고성능이 필요하고 예측 가능한 환경에서 유리하지만, 확장성과 유연성이 떨어집니다.
  • Virtualization은 자원 효율성과 유연성이 좋지만, 성능 오버헤드와 관리 복잡성이 있을 수 있습니다.
  • Container는 경량화된 환경에서 빠른 배포와 높은 자원 효율성을 제공하며, 현대적인 클라우드 네이티브 애플리케이션 개발에 적합합니다. 그러나 보안성과 관리 복잡성을 해결하기 위한 추가 도구와 전략이 필요합니다.

Docker Daemon

Docker Daemon은 Docker의 핵심 구성 요소로, Docker API 요청을 수신하고, 이미지를 관리하며, 컨테이너를 시작, 중지, 삭제하는 등의 작업을 수행합니다. dockerd라는 이름으로 실행되며, 클라이언트 도구인 docker 명령어와 상호작용합니다.

기본 포트와 서비스

  1. Docker API
    • 포트: 2375 (HTTP), 2376 (HTTPS)
    • 설명: Docker Daemon은 RESTful API를 통해 외부와 통신할 수 있습니다. 2375 포트는 보안이 적용되지 않은 HTTP를 통해, 2376 포트는 TLS를 통한 HTTPS로 접근할 수 있습니다.
    • 구성 예시: { "hosts": ["tcp://0.0.0.0:2375", "unix:///var/run/docker.sock"] }
  2. Docker Socket
    • 포트: Unix Socket (/var/run/docker.sock)
    • 설명: Docker CLI와 Docker Daemon 간의 기본 통신 방법으로 사용됩니다. 이 소켓을 통해 명령어가 전달됩니다. 보안상의 이유로 Unix Socket 접근 권한을 제한하는 것이 좋습니다.
  3. Registry
    • 포트: 5000
    • 설명: Docker는 기본적으로 도커 허브(Docker Hub)와 통신하지만, 로컬 또는 사설 레지스트리를 사용할 수도 있습니다. 이 경우 5000 포트에서 레지스트리가 구동될 수 있습니다.
    • 구성 예시: docker run -d -p 5000:5000 --restart=always --name registry registry:2
  4. Swarm 모드 (옵션)
    • 포트: 2377 (클러스터 관리), 7946 (노드 간 통신), 4789 (Overlay 네트워크)
    • 설명: Docker Swarm은 Docker의 네이티브 클러스터링 및 오케스트레이션 솔루션으로, 여러 호스트에서 컨테이너를 관리할 수 있습니다.
    • 구성 예시: docker swarm init --advertise-addr <MANAGER-IP>

구성 파일

Docker Daemon의 설정은 일반적으로 /etc/docker/daemon.json 파일을 통해 관리할 수 있습니다.

{
  "debug": true,
  "tls": true,
  "tlsverify": true,
  "tlscacert": "/path/to/ca.pem",
  "tlscert": "/path/to/server-cert.pem",
  "tlskey": "/path/to/server-key.pem",
  "hosts": ["tcp://0.0.0.0:2376", "unix:///var/run/docker.sock"]
}

보안 고려 사항

  • TLS 사용: API 접근 시 TLS를 설정하여 보안 통신을 보장합니다.
  • 인증 및 권한 관리: Docker Socket에 대한 접근 권한을 제한하고, 필요한 경우 사용자 인증을 설정합니다.
  • 방화벽 설정: 필요하지 않은 포트는 방화벽을 통해 차단하고, 필요한 포트만 개방합니다.

이와 같은 구성을 통해 Docker Daemon이 구동될 때 필요한 서비스와 포트를 관리하고 보안성을 높일 수 있습니다. Docker의 설정 파일을 통해 필요한 포트를 명확하게 정의하고, TLS를 통한 보안 통신을 설정하는 것이 중요합니다.

Kubernetes Cluster Architecture and Components

Kubernetes(K8s)는 컨테이너 오케스트레이션 플랫폼으로, 컨테이너화된 애플리케이션의 배포, 확장 및 관리를 자동화합니다. Kubernetes는 다양한 컨테이너 런타임과 함께 작동할 수 있으며, Docker 외에도 여러 대안이 있습니다.

1. Docker

  • 설명: 가장 널리 알려진 컨테이너 런타임. Docker는 컨테이너를 만들고 배포하며, 이를 Kubernetes와 함께 사용하는 것이 일반적입니다.
  • 특징: Docker는 이미지 빌드, 배포 및 실행에 대한 강력한 생태계를 제공합니다.

2. containerd

  • 설명: Docker에서 분리된 오픈소스 컨테이너 런타임으로, CNCF(Cloud Native Computing Foundation) 프로젝트입니다.
  • 특징: Kubernetes의 CRI(Container Runtime Interface)를 통해 Kubernetes와 직접 통합되며, 경량화되어 있어 성능이 뛰어납니다.

3. CRI-O

  • 설명: 오픈소스 프로젝트로, Kubernetes CRI와 호환되도록 설계된 컨테이너 런타임입니다.
  • 특징: Kubernetes의 표준 컨테이너 런타임으로 사용되며, Open Container Initiative(OCI) 이미지 형식을 지원합니다.

4. rkt (Rocket)

  • 설명: CoreOS에서 개발한 컨테이너 런타임으로, 보안에 중점을 두고 설계되었습니다.
  • 특징: 다양한 실행 모드를 제공하며, Kubernetes에서 사용할 수 있는 CRI 구현체를 제공합니다.

5. Kata Containers

  • 설명: 경량 가상 머신 기반의 컨테이너 런타임으로, 하드웨어 가상화를 활용하여 보안을 강화합니다.
  • 특징: 가상 머신의 격리 기능을 제공하여 높은 보안을 요구하는 환경에서 사용됩니다.

6. Podman

  • 설명: Red Hat에서 개발한 컨테이너 런타임으로, Docker와 호환되지만 데몬리스(Daemonless) 방식으로 동작합니다.
  • 특징: 루트리스(Rootless) 컨테이너를 지원하여 보안성을 높이며, Kubernetes와의 통합도 지원합니다.

이 외에도 Kubernetes는 OCI(Open Container Initiative) 표준을 준수하는 다양한 컨테이너 런타임과 호환될 수 있습니다. 각 런타임은 고유의 특성과 장점을 가지고 있어, 사용자는 자신의 요구에 맞는 런타임을 선택할 수 있습니다.

K3s는 경량화된 Kubernetes(K8s) 배포판으로, 리소스가 제한된 환경에서의 컨테이너 오케스트레이션을 위해 설계되었습니다. Rancher Labs에서 개발한 K3s는 특히 에지 컴퓨팅, IoT, 그리고 개발 및 테스트 환경에서 사용하기에 적합합니다.

K3s의 주요 특징

  1. 경량화: K3s는 기존 Kubernetes에서 사용되지 않는 기능들을 제거하고, 불필요한 컨테이너 런타임과 스토리지 플러그인을 제거하여 크기를 줄였습니다. 일반적으로 K3s 바이너리는 100MB 이하입니다.
  2. 단일 바이너리: K3s는 단일 바이너리 파일로 제공되어 설치 및 관리가 간편합니다. 이는 복잡한 설치 과정을 단순화하고, 작은 장치에서도 쉽게 사용할 수 있도록 합니다.
  3. 간편한 설치: K3s는 curl -sfL https://get.k3s.io | sh - 명령어 한 줄로 설치할 수 있습니다. 이는 빠르고 간단하게 클러스터를 구성할 수 있게 합니다.
  4. 내장된 데이터베이스: 기본적으로 SQLite를 사용하며, 필요에 따라 외부 데이터베이스(예: MySQL, PostgreSQL)와 통합할 수 있습니다.
  5. 여러 아키텍처 지원: ARM, x86_64 등 다양한 CPU 아키텍처를 지원하여 Raspberry Pi와 같은 소형 장치에서도 사용할 수 있습니다.
  6. 내장된 컨테이너 런타임: 기본적으로 컨테이너 런타임으로 containerd를 사용합니다. 이는 Kubernetes에서 가장 많이 사용하는 런타임 중 하나로, 안정성과 성능이 검증되어 있습니다.

K3s의 활용 사례

  1. 에지 컴퓨팅: IoT 장치나 소형 서버에서 Kubernetes 클러스터를 실행해야 하는 경우, K3s는 가벼운 리소스 사용량으로 이상적입니다.
  2. 개발 및 테스트 환경: 로컬 개발 환경이나 CI/CD 파이프라인에서 경량화된 Kubernetes 클러스터를 빠르게 배포하고 테스트하는 데 유용합니다.
  3. 리소스 제한 환경: 메모리나 CPU가 제한된 환경에서 컨테이너 오케스트레이션을 필요로 할 때, K3s는 기존의 Kubernetes보다 효율적으로 운영할 수 있습니다.

보안 관점에서의 K3s 설치 및 운영 가이드

설치 전 점검 사항

  1. 네트워크 보안: K3s 클러스터를 구성하기 전에 네트워크 방화벽 규칙을 설정하여 불필요한 포트가 열려 있지 않도록 합니다.
  2. 최신 패치 적용: K3s 및 의존 패키지의 최신 보안 패치를 적용합니다.
  3. 데이터베이스 보안: 외부 데이터베이스를 사용할 경우, 데이터베이스 보안 설정(예: 암호화, 접근 제어)을 철저히 합니다.

설치 후 점검 사항

  1. 권한 관리: Kubernetes RBAC(Role-Based Access Control)을 설정하여 사용자와 서비스 계정에 필요한 최소한의 권한만 부여합니다.
  2. 네트워크 정책: 네트워크 정책을 사용하여 클러스터 내의 네트워크 트래픽을 제어하고, 불필요한 통신을 차단합니다.
  3. 모니터링 및 로깅: K3s 클러스터의 상태와 보안 이벤트를 모니터링하고, 로그를 중앙화된 시스템에 수집하여 이상 징후를 조기에 탐지합니다.

K3s 설치 예제

단일 노드 클러스터 설치

curl -sfL https://get.k3s.io | sh -

멀티 노드 클러스터 설치

  1. 서버 노드 설치 
    curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--write-kubeconfig-mode 644" sh -
  2. 에이전트 노드 설치 
    curl -sfL https://get.k3s.io | K3S_URL=https://<server-node-ip>:6443 K3S_TOKEN=<server-node-token> sh -

외부 데이터베이스와 통합

curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--datastore-endpoint='mysql://user:password@tcp(hostname:3306)/database'" sh -

위의 가이드라인과 예제를 통해 K3s를 보다 안전하게 설치하고 운영할 수 있습니다. 추가적으로 K3s 관련 보안 업데이트와 모범 사례를 지속적으로 모니터링하여 최신 상태를 유지하는 것이 중요합니다.

Minikube와 K3s는 둘 다 Kubernetes 클러스터를 로컬 환경에서 쉽게 실행할 수 있도록 돕는 도구이지만, 그 목적과 특성에서 몇 가지 차이점이 있습니다.

목적 및 용도

  • Minikube
    • 주로 로컬 개발 환경에서 Kubernetes 클러스터를 쉽게 실행하고 테스트할 수 있도록 설계되었습니다.
    • 다양한 하이퍼바이저(예: VirtualBox, VMware, Hyper-V)를 사용하여 VM 내에 클러스터를 생성합니다.
    • Kubernetes의 완전한 기능을 제공하여, 클러스터 환경을 테스트하고 실험하는 데 적합합니다.
  • K3s
    • 경량화된 Kubernetes 배포판으로, 리소스가 제한된 환경에서의 사용을 목적으로 합니다.
    • 에지 컴퓨팅, IoT 장치, 소형 서버 등에 적합합니다.
    • 단일 바이너리 파일로 제공되며, 설치 및 관리가 매우 간편합니다.
    • 기본적으로 containerd를 사용하여 실행됩니다.

설치 및 실행

  • Minikube
    • 다양한 운영 체제에서 사용할 수 있으며, 각 운영 체제에 맞는 하이퍼바이저를 필요로 합니다.
    • 설치 명령어 예시: minikube start
    • 클러스터 내에 모든 Kubernetes 구성 요소(API 서버, 스케줄러, 컨트롤러 매니저 등)를 포함하여 Kubernetes의 완전한 기능을 제공합니다.
  • K3s
    • 단일 바이너리 파일로 제공되어 설치가 매우 간편하며, 리소스 사용량이 적습니다.
    • 설치 명령어 예시: curl -sfL https://get.k3s.io | sh -
    • 경량화된 Kubernetes 구성 요소를 포함하며, 불필요한 기능을 제거하여 크기를 줄였습니다.

성능 및 리소스 사용량

  • Minikube
    • VM을 사용하기 때문에 리소스 사용량이 상대적으로 높습니다.
    • Kubernetes의 모든 기능을 제공하므로, 더 많은 리소스를 필요로 할 수 있습니다.
  • K3s
    • 경량화된 설계로, CPU 및 메모리 사용량이 적습니다.
    • 작은 디바이스(예: Raspberry Pi)에서도 원활하게 동작할 수 있습니다.

데이터베이스 지원

  • Minikube
    • 기본적으로 내장된 etcd를 사용하여 클러스터 상태를 저장합니다.
  • K3s
    • 기본적으로 SQLite를 사용하며, 필요에 따라 외부 데이터베이스(예: MySQL, PostgreSQL)로 확장할 수 있습니다.

확장성 및 고가용성

  • Minikube
    • 주로 단일 노드 클러스터로 실행되며, 멀티 노드 클러스터를 구성하는 데는 제한적입니다.
    • 고가용성 구성에는 적합하지 않습니다.
  • K3s
    • 멀티 노드 클러스터를 쉽게 구성할 수 있으며, 경량화된 환경에서 고가용성 구성을 지원합니다.
    • 클러스터 확장이 용이하고, 다양한 환경에서 활용될 수 있습니다.

사용 사례

  • Minikube
    • 로컬 개발 및 테스트 환경에서 Kubernetes 애플리케이션을 개발하고 테스트하는 데 적합합니다.
    • Kubernetes 학습 및 실험용으로 사용됩니다.
  • K3s
    • 에지 컴퓨팅, IoT, 소형 서버 등 리소스가 제한된 환경에서 Kubernetes 클러스터를 실행하는 데 적합합니다.
    • 경량화된 환경에서의 프로덕션 클러스터 운영에도 사용할 수 있습니다.

 

Minikube는 로컬 개발 환경에서 완전한 Kubernetes 클러스터를 쉽게 실행하고 테스트하는 데 적합하며, 다양한 하이퍼바이저를 사용하여 VM 내에서 실행됩니다.

K3s는 경량화된 Kubernetes 배포판으로, 리소스가 제한된 환경에서의 컨테이너 오케스트레이션을 목적으로 하며, 단일 바이너리 파일로 제공되어 설치와 관리가 매우 간편합니다.

두 도구 모두 특정 환경에서 Kubernetes 클러스터를 실행하는 데 유용하지만, 사용 목적과 환경에 따라 적합한 도구를 선택하는 것이 중요합니다.

Kubernetes(K8s)와 K3s의 최소 구성과 고가용성을 위한 최적화 환경을 비교하고 설명하겠습니다.

Kubernetes (K8s) 최소 구성

최소 서버 구성

  1. 마스터 노드 (1대)
    • Kubernetes 컨트롤 플레인을 실행하는 노드.
    • API 서버, 컨트롤러 매니저, 스케줄러 등을 포함.
  2. 워커 노드 (1대 이상)
    • 실제 애플리케이션 컨테이너를 실행하는 노드.
    • kubelet, kube-proxy, 컨테이너 런타임 등을 포함.

고가용성 구성

  • 마스터 노드 (3대 이상)
    • 고가용성을 위해 마스터 노드는 최소 3대로 구성.
    • etcd도 분산 구성을 통해 3개 이상의 인스턴스로 운영.
  • 워커 노드 (2대 이상)
    • 애플리케이션 가용성을 위해 최소 2대 이상의 워커 노드를 권장.

최적화 환경

  • 컨트롤 플레인 구성
    • 3대 이상의 마스터 노드로 구성하여 컨트롤 플레인에서 고가용성을 유지.
    • etcd는 3개 이상의 인스턴스로 분산 배치하여 데이터 일관성과 고가용성 보장.
  • 노드 구성
    • 워커 노드를 최소 2대 이상 구성하여 애플리케이션 가용성을 높임.
    • 노드 장애 시에도 다른 노드로 워크로드가 이동하여 서비스 중단을 최소화.
  • 로드 밸런서
    • 외부 로드 밸런서를 사용하여 API 서버의 가용성을 높이고, 트래픽을 고르게 분산.

K3s 최소 구성

최소 서버 구성

  1. 단일 노드 구성 (1대)
    • 단일 노드에서 모든 Kubernetes 구성 요소를 실행.
    • 개발 및 테스트 환경에 적합.
  2. 멀티 노드 구성 (2대 이상)
    • 하나의 서버 노드와 하나 이상의 에이전트 노드로 구성.

고가용성 구성

  • 서버 노드 (3대 이상)
    • 고가용성을 위해 서버 노드는 최소 3대로 구성.
    • K3s는 기본적으로 SQLite를 사용하지만, 고가용성을 위해 외부 데이터베이스(MySQL, PostgreSQL)를 사용하는 것이 좋음.
  • 에이전트 노드 (2대 이상)
    • 애플리케이션 가용성을 위해 최소 2대 이상의 에이전트 노드를 권장.

최적화 환경

  • 컨트롤 플레인 구성
    • 3대 이상의 서버 노드로 구성하여 컨트롤 플레인의 고가용성을 유지.
    • 외부 데이터베이스를 사용하여 고가용성 데이터 스토어를 구현.
  • 노드 구성
    • 에이전트 노드를 최소 2대 이상 구성하여 애플리케이션 가용성을 높임.
    • 노드 장애 시에도 다른 노드로 워크로드가 이동하여 서비스 중단을 최소화.
  • 로드 밸런서
    • 외부 로드 밸런서를 사용하여 API 서버의 가용성을 높이고, 트래픽을 고르게 분산.

고가용성 구성 예제

Kubernetes (K8s) 고가용성 구성

  1. 마스터 노드 설정 (3대)
    • 각각의 마스터 노드에 Kubernetes 컨트롤 플레인을 설치하고, etcd 클러스터를 구성.
    • HAProxy 또는 Keepalived를 사용하여 로드 밸런서 구성.
    # etcd 클러스터 구성
kubeadm init --control-plane-endpoint "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT" --upload-certs
  2. 워커 노드 설정 (2대 이상)
    • 각 워커 노드에 kubeadm join 명령을 통해 클러스터에 조인.
    kubeadm join LOAD_BALANCER_DNS:LOAD_BALANCER_PORT --token <token> --discovery-token-ca-cert-hash sha256:<hash>

K3s 고가용성 구성

  1. 서버 노드 설정 (3대)
    • 외부 데이터베이스 사용하여 고가용성 구성.
    curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --datastore-endpoint='mysql://user:password@tcp(hostname:3306)/database'" sh -
  2. 에이전트 노드 설정 (2대 이상)
    • 각 에이전트 노드에 K3s 설치 및 서버 노드에 조인.
    curl -sfL https://get.k3s.io | K3S_URL=https://<server-node-ip>:6443 K3S_TOKEN=<server-node-token> sh -
  3. 로드 밸런서 구성
    • Keepalived 및 HAProxy를 사용하여 API 서버의 로드 밸런서를 설정.
    # Keepalived 설정 예제
vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 101
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1234
    }
    virtual_ipaddress {
        192.168.1.100
    }
}

# HAProxy 설정 예제
frontend k3s_api
    bind *:6443
    mode tcp
    default_backend k3s_api_backend

backend k3s_api_backend
    mode tcp
    balance roundrobin
    server master1 192.168.1.101:6443 check
    server master2 192.168.1.102:6443 check
    server master3 192.168.1.103:6443 check

위의 구성 예제를 통해 K8s와 K3s의 고가용성 클러스터를 구현할 수 있습니다. 이러한 구성을 통해 한 대의 노드에 장애가 발생하더라도 클러스터가 지속적으로 원활하게 운영될 수 있습니다.

 

다음은 Kubernetes(K8s), K3s, Minikube의 대표적인 기능을 분류하여 비교한 표입니다. 각 도구의 목적과 사용 사례에 따라 주요 기능들을 나열하였습니다.

기능 Kubernetes (K8s) K3s Minikube
목적 대규모 프로덕션 환경 경량화된 환경 (에지 컴퓨팅, IoT, 소형 서버 등) 로컬 개발 및 테스트 환경
설치 및 구성 비교적 복잡, 다양한 구성 요소 필요 단일 바이너리, 간편한 설치 간편한 설치 (단일 명령어)
운영체제 지원 리눅스, 윈도우, 맥 리눅스, ARM 아키텍처 (Raspberry Pi 등) 지원 리눅스, 윈도우, 맥
노드 구성 마스터 노드, 워커 노드 서버 노드, 에이전트 노드 단일 노드 구성 (VM)
고가용성 지원 지원 (다수의 마스터 및 etcd 클러스터) 지원 (다수의 서버 노드 및 외부 데이터베이스) 제한적 (주로 단일 노드)
데이터베이스 etcd 기본 SQLite, 외부 데이터베이스 (MySQL, PostgreSQL) 지원 내장 etcd
컨테이너 런타임 containerd, CRI-O, Docker 등 기본 containerd 기본 Docker
네트워크 플러그인 Calico, Flannel, Weave, Cilium 등 다양한 플러그인 지원 기본적으로 Flannel 내장, 다른 플러그인도 지원 가능 기본적으로 Kubernetes 기본 네트워크 사용
스토리지 플러그인 CSI를 통한 다양한 스토리지 플러그인 지원 기본적으로 로컬 스토리지, 외부 스토리지 플러그인 지원 호스트 머신의 스토리지 사용
업데이트 다양한 업그레이드 전략 필요 단일 바이너리 업그레이드 간편한 업그레이드 (명령어 기반)
확장성 매우 높은 확장성 경량화된 환경에서의 확장성 로컬 개발 및 테스트 목적의 확장성 제한
CLI 툴 kubectl kubectl (동일) kubectl (동일)
대시보드 Kubernetes Dashboard k3s도 동일한 Kubernetes Dashboard 사용 가능 Kubernetes Dashboard
사용 사례 대규모 클러스터, 고가용성 프로덕션 환경 에지 컴퓨팅, IoT, 소형 서버, 경량화 환경 로컬 개발, 테스트, 교육

이 표는 Kubernetes(K8s), K3s, Minikube의 주요 기능과 특징을 비교한 것입니다. 각각의 도구는 특정 환경과 목적에 맞게 설계되었으며, 사용자의 요구사항에 따라 적합한 도구를 선택하는 것이 중요합니다.

Kubernetes(K8s) 클러스터를 구성하면 기본적으로 제공되는 주요 서비스와 기능들은 다음과 같습니다. 각 구성 요소는 클러스터의 관리 및 운영에 필수적인 역할을 합니다.

Kubernetes의 주요 구성 요소 및 기능

  1. API Server (kube-apiserver)
    • 용도: Kubernetes API를 제공하는 중심 구성 요소로, 클러스터 내 모든 요청을 처리합니다. kubectl 명령어와 같은 클라이언트가 클러스터와 상호작용할 때 이 서버를 통해 통신합니다.
    • 기능
      • 클러스터의 상태 조회 및 업데이트
      • 인증 및 인가 처리
      • API 요청 라우팅 및 검증
  2. etcd
    • 용도: Kubernetes의 분산 키-값 저장소로, 클러스터의 모든 상태 정보를 저장합니다. 구성 요소의 상태, 시크릿, 설정 정보 등을 저장하며, 고가용성 및 데이터 일관성을 보장합니다.
    • 기능
      • 클러스터의 구성 및 상태 데이터 저장
      • 시크릿, 구성 맵, 서비스 디스커버리 데이터 관리
  3. Controller Manager (kube-controller-manager)
    • 용도: 클러스터 상태를 관리하고 유지하는 컨트롤러들의 집합체입니다. 다양한 종류의 컨트롤러가 포함되어 있으며, 클러스터의 원하는 상태를 실제 상태로 유지하기 위해 지속적으로 작업합니다.
    • 기능
      • 레플리케이션 컨트롤러: 파드의 복제본을 관리
      • 노드 컨트롤러: 노드 상태 모니터링 및 복구
      • 엔드포인트 컨트롤러: 서비스와 파드 연결 관리
  4. Scheduler (kube-scheduler)
    • 용도: 새로 생성된 파드를 적절한 노드에 할당하는 역할을 합니다. 리소스 요구사항, 정책, 제약 조건 등을 고려하여 최적의 노드를 선택합니다.
    • 기능
      • 파드의 리소스 요구사항 분석
      • 노드의 가용 리소스 평가
      • 스케줄링 정책 및 제약 조건 적용
  5. Kubelet
    • 용도: 각 노드에서 실행되는 에이전트로, 파드를 관리하고 컨테이너를 시작 및 중지합니다. API Server와 통신하여 파드 사양을 받아들이고, 컨테이너 런타임을 통해 컨테이너를 실행합니다.
    • 기능
      • 파드의 라이프사이클 관리
      • 컨테이너 런타임 인터페이스 (CRI)와 상호작용
      • 노드 상태 보고 및 업데이트
  6. Kube-proxy
    • 용도: 각 노드에서 네트워킹을 관리하는 컴포넌트로, Kubernetes 서비스의 네트워크 규칙을 유지하고 트래픽을 올바른 파드로 라우팅합니다.
    • 기능
      • 서비스 IP와 포트 설정
      • 네트워크 프록시 및 로드 밸런싱
      • 네트워크 정책 적용
  7. Container Runtime
    • 용도: 컨테이너를 실제로 실행하는 소프트웨어입니다. Kubernetes는 다양한 컨테이너 런타임을 지원합니다.
    • 기능
      • 컨테이너 이미지를 다운로드 및 캐싱
      • 컨테이너 생성 및 실행
      • 컨테이너 라이프사이클 관리
    • 예시: Docker, containerd, CRI-O

추가적으로 사용할 수 있는 구성 요소

  1. Kubernetes Dashboard
    • 용도: 웹 기반의 UI로, 클러스터의 상태를 모니터링하고 관리할 수 있습니다.
    • 기능
      • 클러스터 리소스 관리 (파드, 서비스, 디플로이먼트 등)
      • 클러스터 상태 및 로그 조회
      • 작업 실행 및 배포 관리
  2. CoreDNS
    • 용도: 클러스터 내에서 DNS 서비스를 제공하여 서비스 디스커버리를 가능하게 합니다.
    • 기능
      • 클러스터 내부 DNS 레코드 관리
      • 서비스 이름 해석 및 IP 주소 제공
  3. Ingress Controller
    • 용도: 외부 HTTP 및 HTTPS 트래픽을 클러스터 내부의 서비스로 라우팅하는 역할을 합니다.
    • 기능
      • 인그레스 리소스 관리
      • 로드 밸런싱 및 SSL 종료
      • 트래픽 라우팅 및 리다이렉션

이와 같은 구성 요소들은 Kubernetes 클러스터의 기본적인 운영 및 관리를 가능하게 합니다. 각각의 구성 요소는 특정한 역할을 담당하며, 이들 간의 협력을 통해 전체 클러스터가 안정적으로 동작합니다.

 

아래 표는 Kubernetes(K8s)의 주요 구성 요소와 각 구성 요소의 용도, 그리고 K3s와 Minikube와의 차이점을 정리한 것입니다.

구성 요소 용도 K3s 차이점 Minikube 차이점
API Server (kube-apiserver) 클러스터의 중심 API, 모든 요청 처리 및 인증/인가 동일 동일
etcd 분산 키-값 저장소, 클러스터 상태 정보 저장 기본 SQLite, 외부 DB 사용 가능 내장 etcd 사용
Controller Manager (kube-controller-manager) 다양한 컨트롤러 관리, 클러스터 상태 유지 동일 동일
Scheduler (kube-scheduler) 파드를 적절한 노드에 할당 동일 동일
Kubelet 노드 에이전트, 파드와 컨테이너 관리 동일 동일
Kube-proxy 네트워크 관리, 서비스 트래픽 라우팅 동일 동일
Container Runtime 컨테이너 실행 소프트웨어 (예: Docker, containerd) 기본 containerd 사용 기본 Docker 사용
Kubernetes Dashboard 웹 기반 UI, 클러스터 상태 모니터링 및 관리 동일 동일
CoreDNS DNS 서비스 제공, 서비스 디스커버리 동일 동일
Ingress Controller 외부 트래픽을 내부 서비스로 라우팅 동일 동일

주요 차이점 요약

  • etcd
    • K8s는 기본적으로 etcd를 사용하지만, K3s는 기본 SQLite를 사용하며 외부 데이터베이스(MySQL, PostgreSQL)로 확장 가능.
    • Minikube는 내장된 etcd를 사용.
  • Container Runtime
    • K8s와 K3s는 다양한 컨테이너 런타임(containerd, CRI-O, Docker 등)을 지원하지만, K3s는 기본적으로 containerd를 사용.
    • Minikube는 기본적으로 Docker를 사용하지만 다른 런타임도 설정 가능.

참고사항

  • K3s
    • 경량화된 설계로, 리소스 사용량이 적으며, 단일 바이너리 파일로 제공되어 설치가 간편.
    • 에지 컴퓨팅, IoT, 소형 서버 등 리소스가 제한된 환경에 적합.
    • 기본적으로 containerd를 사용하며, 외부 데이터베이스로 확장 가능.
  • Minikube
    • 로컬 개발 환경에서 Kubernetes 클러스터를 쉽게 실행하고 테스트할 수 있도록 설계.
    • 다양한 하이퍼바이저(예: VirtualBox, VMware, Hyper-V)를 사용하여 VM 내에 클러스터를 생성.
    • Kubernetes의 모든 기능을 제공하며, 주로 로컬 개발 및 테스트에 사용.

 

아래는 Kubernetes(K8s)의 주요 구성 요소와 각 구성 요소의 용도, 서비스 포트 정보, 그리고 K3s 및 Minikube와의 차이점을 정리한 표입니다.

구성 요소 용도 기본 포트 K3s 차이점 Minikube 차이점
API Server (kube-apiserver) 클러스터의 중심 API, 모든 요청 처리 및 인증/인가 6443 동일 동일
etcd 분산 키-값 저장소, 클러스터 상태 정보 저장 2379, 2380 기본 SQLite, 외부 DB 사용 가능 내장 etcd 사용
Controller Manager (kube-controller-manager) 다양한 컨트롤러 관리, 클러스터 상태 유지 10252 동일 동일
Scheduler (kube-scheduler) 파드를 적절한 노드에 할당 10251 동일 동일
Kubelet 노드 에이전트, 파드와 컨테이너 관리 10250 동일 동일
Kube-proxy 네트워크 관리, 서비스 트래픽 라우팅 없음 (IPTables/IPVS 사용) 동일 동일
Container Runtime 컨테이너 실행 소프트웨어 (예: Docker, containerd) - 기본 containerd 사용 기본 Docker 사용
Kubernetes Dashboard 웹 기반 UI, 클러스터 상태 모니터링 및 관리 30000 (NodePort) 동일 동일
CoreDNS DNS 서비스 제공, 서비스 디스커버리 53 (UDP/TCP) 동일 동일
Ingress Controller 외부 트래픽을 내부 서비스로 라우팅 80, 443 (HTTP/HTTPS) 동일 동일

주요 포트 설명

  • API Server (kube-apiserver)
    • 포트 6443: 클러스터 API 서버가 HTTPS를 통해 제공하는 포트. 클라이언트가 클러스터와 상호작용하는 주요 엔드포인트.
  • etcd
    • 포트 2379: 클라이언트 통신을 위한 포트.
    • 포트 2380: 서버 간 통신을 위한 포트.
  • Controller Manager (kube-controller-manager)
    • 포트 10252: 컨트롤러 매니저가 메트릭을 노출하는 포트.
  • Scheduler (kube-scheduler)
    • 포트 10251: 스케줄러가 메트릭을 노출하는 포트.
  • Kubelet
    • 포트 10250: Kubelet이 HTTPS로 API 서버와 통신하는 포트.
  • Kube-proxy
    • 포트 번호가 없음. 대신 IPTables 또는 IPVS를 사용하여 서비스 트래픽을 라우팅.
  • Kubernetes Dashboard
    • 포트 30000 (NodePort): 기본적으로 노드 포트로 노출되며, 클러스터 외부에서 접근 가능.
  • CoreDNS
    • 포트 53 (UDP/TCP): DNS 서비스 제공을 위한 표준 포트.
  • Ingress Controller
    • 포트 80: HTTP 트래픽을 라우팅.
    • 포트 443: HTTPS 트래픽을 라우팅.
  •  

Weave CNI(Weave Net)는 Kubernetes 클러스터에서 네트워킹을 관리하기 위한 플러그인입니다. 이는 Kubernetes의 핵심 구성 요소와는 다른 개념으로, 네트워크 연결을 설정하고 관리하는 데 사용됩니다. Kubernetes 클러스터는 기본 네트워킹 기능을 제공하지만, 다양한 네트워크 요구 사항을 충족하기 위해 여러 네트워크 플러그인(CNI, Container Network Interface)을 사용할 수 있습니다.

Weave CNI (Weave Net) 개요

Weave Net는 간단하고 강력한 네트워킹 솔루션으로, Kubernetes 클러스터 내에서 컨테이너 간의 네트워크 통신을 설정하고 관리합니다. 아래는 Weave Net의 주요 특징과 기능입니다.

주요 특징

  1. 간편한 설치: Weave Net는 Kubernetes 클러스터에 쉽게 설치할 수 있으며, 복잡한 네트워크 구성을 필요로 하지 않습니다.
  2. 자동 네트워크 구성: 클러스터 내 모든 노드에서 컨테이너 간의 통신을 자동으로 설정하고 관리합니다.
  3. 네트워크 보안: 네트워크 정책을 통해 네트워크 트래픽을 제어하고, 보안을 강화할 수 있습니다.
  4. 확장성: 클러스터 크기에 관계없이 확장 가능하며, 대규모 클러스터에서도 안정적으로 동작합니다.
  5. 다양한 기능: IPAM(아이피 주소 관리), 네트워크 암호화, 네트워크 격리 등의 기능을 제공합니다.

주요 구성 요소

  1. weave-kube: Kubernetes와의 통합을 담당하는 구성 요소로, 클러스터 내에서 Weave Net을 실행하고 관리합니다.
  2. weave-npc (Network Policy Controller): Kubernetes 네트워크 정책을 구현하고, 네트워크 보안을 관리합니다.

Weave Net 설치 예제

kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')

네트워크 플러그인(CNI)의 개념

네트워크 플러그인은 Kubernetes 클러스터에서 파드 간의 네트워크 통신을 설정하고 관리하는 데 사용됩니다. Kubernetes는 다양한 네트워크 플러그인을 지원하며, 각 플러그인은 고유한 네트워크 모델과 기능을 제공합니다. 대표적인 네트워크 플러그인에는 다음과 같은 것들이 있습니다.

  1. Flannel: 간단하고 경량화된 네트워크 플러그인으로, 오버레이 네트워크를 사용하여 클러스터 내 파드 간의 통신을 설정합니다.
  2. Calico: 네트워크 정책을 지원하며, 고성능 네트워크를 제공합니다. 네트워크 보안을 강화하는데 유리합니다.
  3. Weave Net: 자동 네트워크 구성과 네트워크 보안을 제공하며, 간편하게 설치할 수 있습니다.
  4. Cilium: BPF(eBPF)를 사용하여 고성능 네트워크와 네트워크 보안을 제공합니다.

Kubernetes 구성 요소와의 차이

Kubernetes의 기본 구성 요소는 클러스터의 관리, 오케스트레이션 및 운영을 담당합니다. 예를 들어, API Server, etcd, Scheduler, Kubelet 등이 이에 해당합니다. 반면에 네트워크 플러그인(CNI)은 이러한 기본 구성 요소와 별개로 클러스터 내 네트워크 통신을 설정하고 관리하는 역할을 합니다.

  • Kubernetes 기본 구성 요소: 클러스터의 전반적인 관리와 운영에 필수적인 역할을 하는 요소들.
  • 네트워크 플러그인 (CNI): 클러스터 내 파드와 서비스 간의 네트워크 연결을 설정하고 관리하는 추가적인 기능을 제공.

 

Weave Net와 같은 네트워크 플러그인은 클러스터의 네트워크 요구 사항을 충족하기 위해 설치되고 구성되며, 클러스터의 확장성, 보안 및 성능을 향상시키는 데 도움을 줍니다. 아래는 Kubernetes에서 사용할 수 있는 다양한 네트워크 플러그인(CNI, Container Network Interface)의 목록과 각 플러그인의 용도를 정리한 표입니다.

네트워크 플러그인 용도
Flannel 간단하고 경량화된 오버레이 네트워크 플러그인으로, 클러스터 내 파드 간의 기본 네트워크 연결을 제공.
Calico 네트워크 정책 지원과 고성능 네트워크 제공. 보안이 중요한 환경에서 네트워크 세분화를 위해 사용.
Weave Net 자동 네트워크 구성과 네트워크 보안 제공. 간편한 설치와 사용으로 에지 컴퓨팅 및 소형 클러스터에 적합.
Cilium BPF(eBPF)를 사용하여 고성능 네트워크와 네트워크 보안을 제공. 동적 네트워크 정책 및 로드밸런싱을 지원.
Canal Flannel과 Calico의 기능을 결합한 플러그인으로, 네트워크 정책과 오버레이 네트워크를 함께 제공.
Kube-Router 고성능 네트워크 라우팅과 네트워크 정책을 제공. 네이티브 IP 라우팅을 통해 효율적인 네트워크 성능을 구현.
Multus 다중 네트워크 인터페이스를 지원하여, 여러 네트워크 플러그인을 동시에 사용 가능. 멀티 네트워크 환경에 적합.
Romana 네이티브 L3 네트워크를 제공하며, 네트워크 정책 관리에 최적화. 대규모 클러스터에서 효율적.
Contiv 정책 기반 네트워크와 멀티 테넌트 네트워크 지원. 네트워크 격리가 중요한 환경에서 사용.
Macvlan 물리적 네트워크 인터페이스를 가상화하여 파드에 직접 할당. 고성능 네트워크가 필요한 환경에 적합.
Azure CNI Azure Kubernetes Service(AKS)와 통합된 네트워크 플러그인으로, Azure 네트워크와의 원활한 통합 제공.
Amazon VPC CNI Amazon EKS에서 사용되는 네트워크 플러그인으로, VPC 네트워크와 통합하여 AWS 리소스와의 원활한 통합 제공.
Google VPC CNI Google Kubernetes Engine(GKE)에서 사용되는 네트워크 플러그인으로, GCP 네트워크와의 원활한 통합 제공.

주요 네트워크 플러그인의 설명

  1. Flannel
    • 용도: 간단하고 경량화된 오버레이 네트워크 플러그인으로, 클러스터 내 파드 간의 기본 네트워크 연결을 제공합니다. 주로 소규모 클러스터나 간단한 네트워크 구성이 필요한 경우 사용됩니다.
  2. Calico
    • 용도: 네트워크 정책을 지원하고 고성능 네트워크를 제공합니다. 보안이 중요한 환경에서 네트워크 세분화를 위해 사용되며, BGP를 통한 네이티브 라우팅도 지원합니다.
  3. Weave Net
    • 용도: 자동 네트워크 구성과 네트워크 보안을 제공합니다. 간편한 설치와 사용으로 에지 컴퓨팅 및 소형 클러스터에 적합합니다.
  4. Cilium
    • 용도: BPF(eBPF)를 사용하여 고성능 네트워크와 네트워크 보안을 제공합니다. 동적 네트워크 정책, 로드밸런싱, 마이크로서비스 보안을 지원합니다.
  5. Canal
    • 용도: Flannel과 Calico의 기능을 결합하여 네트워크 정책과 오버레이 네트워크를 함께 제공합니다. 두 플러그인의 장점을 모두 활용할 수 있습니다.
  6. Kube-Router
    • 용도: 고성능 네트워크 라우팅과 네트워크 정책을 제공합니다. 네이티브 IP 라우팅을 통해 효율적인 네트워크 성능을 구현합니다.
  7. Multus
    • 용도: 다중 네트워크 인터페이스를 지원하여 여러 네트워크 플러그인을 동시에 사용할 수 있습니다. 멀티 네트워크 환경에 적합합니다.
  8. Romana
    • 용도: 네이티브 L3 네트워크를 제공하며, 네트워크 정책 관리에 최적화되어 있습니다. 대규모 클러스터에서 효율적입니다.
  9. Contiv
    • 용도: 정책 기반 네트워크와 멀티 테넌트 네트워크를 지원합니다. 네트워크 격리가 중요한 환경에서 사용됩니다.
  10. Macvlan
    • 용도: 물리적 네트워크 인터페이스를 가상화하여 파드에 직접 할당합니다. 고성능 네트워크가 필요한 환경에 적합합니다.
  11. Azure CNI
    • 용도: Azure Kubernetes Service(AKS)와 통합된 네트워크 플러그인으로, Azure 네트워크와의 원활한 통합을 제공합니다.
  12. Amazon VPC CNI
    • 용도: Amazon EKS에서 사용되는 네트워크 플러그인으로, VPC 네트워크와 통합하여 AWS 리소스와의 원활한 통합을 제공합니다.
  13. Google VPC CNI
    • 용도: Google Kubernetes Engine(GKE)에서 사용되는 네트워크 플러그인으로, GCP 네트워크와의 원활한 통합을 제공합니다.

이 표는 Kubernetes에서 사용할 수 있는 다양한 네트워크 플러그인의 용도와 주요 기능을 요약한 것입니다. 각 플러그인은 특정 네트워크 요구 사항을 충족하도록 설계되었으며, 클러스터의 특성과 요구에 맞게 적절한 플러그인을 선택하여 사용할 수 있습니다.

 

네트워크 플러그인(CNI)은 일반적으로 Kubernetes 클러스터에 파드 형태로 설치됩니다. 이러한 플러그인들은 클러스터의 네트워크 구성을 설정하고 관리하기 위한 리소스를 제공하며, 설치 과정은 Kubernetes 리소스를 배포하는 것과 유사합니다. 아래는 몇 가지 주요 네트워크 플러그인의 설치 방법을 간략하게 설명한 예제입니다.

Flannel 설치

Flannel은 간단하고 경량화된 오버레이 네트워크 플러그인으로, Kubernetes 클러스터에 쉽게 설치할 수 있습니다.

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Calico 설치

Calico는 네트워크 정책을 지원하고 고성능 네트워크를 제공하는 플러그인입니다.

kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

Weave Net 설치

Weave Net는 자동 네트워크 구성과 네트워크 보안을 제공하며, 간편하게 설치할 수 있습니다.

kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')

Cilium 설치

Cilium은 BPF(eBPF)를 사용하여 고성능 네트워크와 네트워크 보안을 제공하는 플러그인입니다.

kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/v1.11/install/kubernetes/quick-install.yaml

Canal 설치

Canal은 Flannel과 Calico의 기능을 결합하여 네트워크 정책과 오버레이 네트워크를 함께 제공합니다.

kubectl apply -f https://docs.projectcalico.org/manifests/canal.yaml

Kube-Router 설치

Kube-Router는 고성능 네트워크 라우팅과 네트워크 정책을 제공하는 플러그인입니다.

kubectl apply -f https://raw.githubusercontent.com/cloudnativelabs/kube-router/master/daemonset/kube-router-all.yaml

Multus 설치

Multus는 다중 네트워크 인터페이스를 지원하여 여러 네트워크 플러그인을 동시에 사용할 수 있게 해줍니다.

kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/images/multus-daemonset.yml

Romana 설치

Romana는 네이티브 L3 네트워크를 제공하며, 네트워크 정책 관리에 최적화된 플러그인입니다.

kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml

Contiv 설치

Contiv는 정책 기반 네트워크와 멀티 테넌트 네트워크를 지원하는 플러그인입니다.

kubectl apply -f https://raw.githubusercontent.com/contiv/netplugin/master/k8s/contiv.yaml

Macvlan 설치

Macvlan은 물리적 네트워크 인터페이스를 가상화하여 파드에 직접 할당하는 플러그인입니다.

kubectl apply -f https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/master/examples/macvlan-daemonset.yaml

Azure CNI 설치

Azure Kubernetes Service(AKS)와 통합된 네트워크 플러그인입니다.

# Azure CNI 설치는 Azure CLI를 통해 AKS 클러스터 생성 시 자동으로 포함됩니다.
az aks create --resource-group myResourceGroup --name myAKSCluster --network-plugin azure

Amazon VPC CNI 설치

Amazon EKS에서 사용되는 네트워크 플러그인으로, VPC 네트워크와 통합하여 AWS 리소스와의 원활한 통합을 제공합니다.

# Amazon VPC CNI는 EKS 클러스터 생성 시 자동으로 포함됩니다.
# 추가적으로 VPC CNI 업데이트나 설치는 aws-node DaemonSet을 통해 관리됩니다.
kubectl apply -f https://raw.githubusercontent.com/aws/amazon-vpc-cni-k8s/master/config/v1.7/aws-k8s-cni.yaml

Google VPC CNI 설치

Google Kubernetes Engine(GKE)에서 사용되는 네트워크 플러그인으로, GCP 네트워크와의 원활한 통합을 제공합니다.

# Google VPC CNI는 GKE 클러스터 생성 시 자동으로 포함됩니다.
# 추가적인 설정은 gcloud CLI를 통해 관리됩니다.
gcloud container clusters create my-gke-cluster --enable-ip-alias

이처럼 네트워크 플러그인은 Kubernetes 클러스터에 파드 형태로 설치되며, kubectl apply 명령어를 통해 쉽게 배포할 수 있습니다. 각 플러그인은 특정한 YAML 매니페스트 파일을 통해 설치되며, 해당 파일에는 플러그인에 필요한 모든 리소스 정의가 포함되어 있습니다.

Kubernetes(K8s) 클러스터에서는 마스터 노드와 워커 노드가 각각 다른 역할을 수행합니다. 마스터 노드는 클러스터의 제어 및 관리 기능을 담당하며, 워커 노드는 실제 애플리케이션 컨테이너가 실행되는 곳입니다.

마스터 노드의 구성 요소

마스터 노드에는 클러스터를 관리하고 제어하는 데 필요한 주요 구성 요소들이 배포됩니다. 이러한 구성 요소들은 보통 Kubernetes 시스템 파드로 실행됩니다.

  1. API Server (kube-apiserver): 클러스터의 모든 API 요청을 처리하는 중심 서버.
  2. etcd: 클러스터의 상태 정보를 저장하는 분산 키-값 저장소.
  3. Controller Manager (kube-controller-manager): 클러스터의 상태를 관리하고 유지하는 다양한 컨트롤러들을 실행.
  4. Scheduler (kube-scheduler): 새로 생성된 파드를 적절한 워커 노드에 할당.

마스터 노드와 파드

마스터 노드에는 기본적으로 클러스터 제어를 위한 시스템 파드들이 실행됩니다. 그러나 애플리케이션 파드는 기본적으로 마스터 노드에 배포되지 않습니다. 이는 마스터 노드의 리소스를 클러스터 제어 기능에 전적으로 할당하고, 안정성을 높이기 위함입니다.

워커 노드의 역할

워커 노드는 실제 애플리케이션 파드가 실행되는 곳입니다. 각 워커 노드는 다음과 같은 주요 구성 요소를 포함합니다.

  1. Kubelet: 노드에서 파드와 컨테이너를 관리하는 에이전트.
  2. Kube-proxy: 네트워크 프록시로, 네트워크 규칙을 유지하고 서비스 트래픽을 적절하게 라우팅.
  3. Container Runtime: 컨테이너를 실제로 실행하는 소프트웨어 (예: Docker, containerd).

마스터 노드에 애플리케이션 파드를 배포할 수 있는 방법

기본적으로 마스터 노드는 애플리케이션 파드를 실행하지 않지만, 필요하다면 마스터 노드에서도 애플리케이션 파드를 실행할 수 있습니다. 이를 위해서는 마스터 노드에 특정 라벨을 제거해야 합니다. 마스터 노드는 기본적으로 node-role.kubernetes.io/master라는 테인트(Taint)를 가지고 있으며, 이 테인트는 파드가 마스터 노드에 스케줄링되는 것을 방지합니다.

마스터 노드에서 테인트 제거 예시

kubectl taint nodes --all node-role.kubernetes.io/master-

이 명령어는 모든 마스터 노드에서 node-role.kubernetes.io/master 테인트를 제거하여, 애플리케이션 파드가 마스터 노드에 스케줄링될 수 있게 합니다. 그러나 이는 보안과 안정성 측면에서 주의해서 사용해야 합니다.

 

이와 같이, Kubernetes 클러스터는 마스터 노드와 워커 노드의 역할을 분리하여, 클러스터의 관리 및 애플리케이션 실행을 효과적으로 수행합니다. Kubernetes 클러스터에서 마스터 노드의 장애는 클러스터의 전체 관리 및 제어 기능에 영향을 미칠 수 있습니다. 이를 방지하고자 마스터 노드의 고가용성을 확보하기 위해 다중 마스터 노드를 사용하는 방식이 일반적입니다. 여기서 마스터 노드들 사이에 "슬레이브"라는 개념보다는, 다중 마스터 노드가 상호 간에 동기화되어 고가용성을 유지하는 방식으로 작동합니다.

다중 마스터 노드를 사용한 고가용성 구성

  1. 다중 API 서버: 각 마스터 노드에 API 서버가 실행됩니다.
  2. 분산 etcd 클러스터: etcd는 고가용성을 위해 3개 이상의 인스턴스로 구성됩니다.
  3. 다중 Controller Manager 및 Scheduler: 다중 마스터 노드에 각 구성 요소가 복제되어 실행됩니다.

다중 마스터 노드의 구성 방법

etcd 클러스터 구성

etcd는 고가용성을 위해 홀수 개의 노드로 구성해야 합니다. 최소 3개의 노드로 시작하여, 각 노드는 서로 통신하여 데이터를 복제하고 일관성을 유지합니다.

# etcd 설치 및 클러스터 구성 예제 (각 노드에서 실행)
etcd --name infra0 --initial-advertise-peer-urls http://<IP0>:2380 \
  --listen-peer-urls http://<IP0>:2380 \
  --listen-client-urls http://<IP0>:2379,http://127.0.0.1:2379 \
  --advertise-client-urls http://<IP0>:2379 \
  --initial-cluster-token etcd-cluster-1 \
  --initial-cluster infra0=http://<IP0>:2380,infra1=http://<IP1>:2380,infra2=http://<IP2>:2380 \
  --initial-cluster-state new

API 서버 구성

각 마스터 노드에 API 서버를 설치하고, 로드 밸런서를 통해 클러스터 외부에서 접근 가능하게 설정합니다.

# kube-apiserver 설정 예제
kube-apiserver --advertise-address=<IP> --etcd-servers=http://<etcd-IP>:2379 \
  --apiserver-count=3 --service-cluster-ip-range=<CIDR> --client-ca-file=<path-to-ca-cert> \
  --tls-cert-file=<path-to-cert> --tls-private-key-file=<path-to-key>

Controller Manager 및 Scheduler 구성

다중 마스터 노드에 동일하게 설치하며, 각 인스턴스는 클러스터 상태를 지속적으로 점검하고 유지합니다.

# kube-controller-manager 설정 예제
kube-controller-manager --master=http://<master-IP>:8080 --leader-elect=true

# kube-scheduler 설정 예제
kube-scheduler --master=http://<master-IP>:8080 --leader-elect=true

로드 밸런서 구성

API 서버의 고가용성을 위해 외부 로드 밸런서를 구성하여, 모든 API 서버 인스턴스에 트래픽을 분산시킵니다.

# HAProxy 설정 예제
frontend kubernetes-api
    bind *:6443
    default_backend kubernetes-api

backend kubernetes-api
    balance roundrobin
    server master1 <master1-IP>:6443 check
    server master2 <master2-IP>:6443 check
    server master3 <master3-IP>:6443 check

마스터 노드 장애 발생 시 작동 원리

  • API 서버: 로드 밸런서를 통해 트래픽이 분산되므로, 하나의 API 서버가 장애가 발생해도 나머지 API 서버가 요청을 처리합니다.
  • etcd: 분산된 etcd 클러스터는 3개 이상의 인스턴스로 구성되므로, 하나의 etcd 노드가 장애가 발생해도 클러스터는 계속 작동합니다.
  • Controller Manager 및 Scheduler: 각 인스턴스는 리더 선출 과정을 통해 하나의 리더가 활성 상태를 유지하며, 장애가 발생해도 새로운 리더가 자동으로 선출됩니다.

장애 조치 방법

  1. 장애 탐지: 마스터 노드의 상태를 모니터링하여 장애 발생 시 신속하게 탐지합니다. Prometheus와 같은 모니터링 도구를 사용할 수 있습니다.
  2. 장애 노드 복구
    • 장애가 발생한 마스터 노드를 복구하거나, 새로운 마스터 노드를 클러스터에 추가합니다.
    • etcd 데이터베이스를 백업하고, 필요 시 복구합니다.
# etcd 백업
ETCDCTL_API=3 etcdctl snapshot save snapshot.db

# etcd 복구
ETCDCTL_API=3 etcdctl snapshot restore snapshot.db --initial-cluster-token etcd-cluster-1 \
  --initial-advertise-peer-urls http://<IP>:2380 --name infra0 \
  --initial-cluster infra0=http://<IP0>:2380,infra1=http://<IP1>:2380,infra2=http://<IP2>:2380 \
  --initial-cluster-state existing
  1. 로드 밸런서 업데이트: 복구된 마스터 노드를 로드 밸런서 설정에 추가합니다.
  2. 테스트 및 확인: 복구 작업 후 클러스터 상태를 점검하고, 모든 마스터 노드와 워커 노드가 정상적으로 작동하는지 확인합니다.

이와 같은 고가용성 구성은 Kubernetes 클러스터의 안정성과 가용성을 크게 향상시켜, 마스터 노드 장애 발생 시에도 클러스터가 지속적으로 동작할 수 있도록 보장합니다. Kubernetes 클러스터에서 워커 노드의 장애는 애플리케이션 가용성에 영향을 미칠 수 있습니다. 따라서 워커 노드의 고가용성을 확보하기 위해 클러스터를 구성하고 관리하는 방법을 이해하는 것이 중요합니다. 아래에서는 워커 노드의 고가용성 구성을 위한 전략과 그 작동 원리를 설명합니다.

워커 노드 고가용성 구성

1. 노드 풀 사용

노드 풀(Node Pool)은 클러스터의 워커 노드 그룹으로, 각 노드 풀은 특정 구성을 공유하는 여러 노드로 구성됩니다. 다중 노드 풀을 사용하면 워커 노드의 장애에 대한 복원력을 높일 수 있습니다.

2. 자동 스케일링

Kubernetes는 클러스터 오토스케일러(Cluster Autoscaler)와 Horizontal Pod Autoscaler(HPA)를 통해 노드와 파드의 수를 자동으로 조정할 수 있습니다. 이를 통해 워커 노드 장애 시에도 적절한 리소스를 확보할 수 있습니다.

  • Cluster Autoscaler: 필요에 따라 노드를 자동으로 추가하거나 제거하여 클러스터의 리소스를 최적화합니다.
  • Horizontal Pod Autoscaler (HPA): 파드의 수를 자동으로 조정하여 애플리케이션의 부하를 분산합니다.

3. 파드 분산

파드를 여러 노드에 분산 배치하여 특정 노드 장애 시에도 애플리케이션 가용성을 유지할 수 있습니다. 이를 위해 Kubernetes는 다음과 같은 기능을 제공합니다:

  • 노드 셀렉터(Node Selector) 및 노드 어피니티(Node Affinity): 특정 조건을 만족하는 노드에 파드를 배치합니다.
  • 파드 안티-어피니티(Pod Anti-Affinity): 동일한 노드에 여러 파드가 배치되지 않도록 합니다.
  • Pod Disruption Budget (PDB): 파드의 최소 가용 수를 정의하여 계획된 중단 동안에도 서비스 가용성을 유지합니다.

고가용성 대응 원리

1. 파드 복제 및 배포 전략

애플리케이션 파드를 복제하여 여러 노드에 배포함으로써, 한 노드에 장애가 발생해도 다른 노드에서 파드가 계속 실행될 수 있습니다. Kubernetes의 디플로이먼트(Deployment) 객체는 파드의 복제본을 관리하며, 롤링 업데이트(Rolling Update)와 같은 배포 전략을 지원합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest

2. 노드 장애 감지 및 대체

Kubernetes는 노드 상태를 지속적으로 모니터링하며, 노드가 비정상 상태가 되면 해당 노드에서 실행 중인 파드를 다른 노드로 자동으로 재배치합니다. 이를 통해 노드 장애 시에도 애플리케이션의 가용성을 유지합니다.

  • Kubelet: 각 노드에서 실행되며, 노드 상태를 주기적으로 API 서버에 보고합니다.
  • Controller Manager: 노드 컨트롤러(Node Controller)는 노드의 상태를 모니터링하고, 비정상 노드에서 파드를 다른 노드로 스케줄링합니다.

3. 서비스 로드밸런싱

Kubernetes 서비스(Service)는 여러 파드 간의 로드밸런싱을 제공합니다. 서비스 객체는 클러스터 내부 또는 외부에서 접근할 수 있는 고정 IP와 DNS 이름을 제공하며, 파드가 실패하거나 이동할 때에도 트래픽을 자동으로 재분배합니다.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: my-app
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
  type: LoadBalancer

장애 조치 방법

  1. 장애 탐지
    • Prometheus와 같은 모니터링 도구를 사용하여 노드 상태를 실시간으로 모니터링합니다.
    • 노드 장애 알림을 설정하여 즉각적인 대응이 가능하도록 합니다.
  2. 장애 노드 복구
    • 장애가 발생한 노드를 점검하고, 필요 시 재부팅하거나 교체합니다.
    • 클러스터 오토스케일러가 자동으로 새로운 노드를 추가하도록 설정합니다.
  3. 파드 재배치 확인
    • 노드 장애 시 Controller Manager가 파드를 다른 노드로 재배치했는지 확인합니다.
    • 필요 시 수동으로 파드를 다시 스케줄링합니다.
  4. 테스트 및 확인
    • 복구 작업 후 클러스터 상태를 점검하고, 모든 노드와 파드가 정상적으로 작동하는지 확인합니다.

이러한 전략을 통해 Kubernetes 클러스터는 워커 노드 장애에도 높은 가용성을 유지하며, 애플리케이션의 연속성을 보장할 수 있습니다.

Kubernetes에서는 다양한 유형의 파드(Pod)를 정의하고 실행할 수 있는 여러 종류의 리소스가 있습니다. 각 리소스는 특정한 사용 사례에 맞게 설계되어 있습니다. 여기서는 일반적인 앱 파드, Job 파드, 그리고 기타 파드 유형에 대해 설명하겠습니다.

1. 일반적인 앱 파드 (Deployment)

일반적인 애플리케이션 파드는 지속적으로 실행되며, 사용자의 요청을 처리하거나 지속적인 서비스를 제공합니다. 이를 위해 주로 Deployment 리소스를 사용합니다.

Deployment

  • 용도: 지속적으로 실행되는 애플리케이션을 배포하고 관리합니다.
  • 특징
    • 원하는 상태를 유지하며, 파드의 복제본을 관리합니다.
    • 롤링 업데이트와 롤백 기능을 제공합니다.
    • 파드의 수를 자동으로 조정할 수 있습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest

2. Job 파드

Job 파드는 일회성 작업이나 일정 기간 동안 실행되는 작업을 처리합니다. 작업이 완료되면 파드는 종료됩니다.

Job

  • 용도: 일회성 작업 또는 일정 기간 동안 실행되는 작업을 관리합니다.
  • 특징
    • 작업이 완료되면 파드가 종료됩니다.
    • 성공적으로 완료된 작업의 수를 추적할 수 있습니다.
    • 실패한 작업을 재시도할 수 있습니다.
apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - name: my-job
        image: my-job-image:latest
      restartPolicy: OnFailure
  backoffLimit: 4

CronJob

  • 용도: 일정한 시간 간격으로 반복 실행되는 작업을 관리합니다.
  • 특징
    • 스케줄링된 시간에 따라 Job을 생성하고 실행합니다.
    • Cron 표현식을 사용하여 일정 설정이 가능합니다.
apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/5 * * * *"  # 매 5분마다 실행
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-cronjob
            image: my-cronjob-image:latest
          restartPolicy: OnFailure

3. 기타 파드 유형

StatefulSet

  • 용도: 상태를 가지는 애플리케이션(예: 데이터베이스, Kafka 등)을 배포하고 관리합니다.
  • 특징
    • 각 파드는 고유한 정체성을 가지며, 네트워크 ID와 스토리지 볼륨이 고유합니다.
    • 파드 순서 보장(생성과 종료 시 순서 보장).
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-statefulapp
spec:
  serviceName: "my-service"
  replicas: 3
  selector:
    matchLabels:
      app: my-statefulapp
  template:
    metadata:
      labels:
        app: my-statefulapp
    spec:
      containers:
      - name: my-statefulapp
        image: my-statefulapp-image:latest
        volumeMounts:
        - name: my-storage
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: my-storage
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 1Gi

DaemonSet

  • 용도: 클러스터의 모든 노드에서 실행되어야 하는 애플리케이션(예: 로그 수집기, 모니터링 에이전트 등)을 배포합니다.
  • 특징
    • 클러스터의 각 노드마다 하나의 파드를 실행합니다.
    • 새로운 노드가 클러스터에 추가되면 자동으로 파드를 배포합니다.
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: my-daemonset
spec:
  selector:
    matchLabels:
      app: my-daemonset
  template:
    metadata:
      labels:
        app: my-daemonset
    spec:
      containers:
      - name: my-daemonset
        image: my-daemonset-image:latest

ReplicaSet

  • 용도: 특정 수의 파드를 항상 유지합니다. 주로 Deployment에서 사용되며, 직접 사용하는 경우는 드뭅니다.
  • 특징
    • 지정된 수의 파드를 항상 유지하도록 합니다.
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:latest
  1. 일반적인 앱 파드 (Deployment): 지속적인 서비스 제공.
  2. Job 파드: 일회성 작업.
  3. CronJob: 주기적으로 실행되는 작업.
  4. StatefulSet: 상태를 가지는 애플리케이션.
  5. DaemonSet: 모든 노드에서 실행되어야 하는 애플리케이션.
  6. ReplicaSet: 특정 수의 파드를 유지(보통 Deployment에서 사용).

이와 같이 Kubernetes는 다양한 파드 유형을 제공하여 다양한 애플리케이션 배포 및 관리 요구 사항을 충족합니다. 각 리소스 유형은 특정 사용 사례에 맞게 설계되어 있어, 요구 사항에 따라 적절한 리소스를 선택하여 사용할 수 있습니다.

Examining Kubernetes internals using a REST API example - Red Hat Developer

Kubernetes에서 CR(Custom Resource)와 CRD(Custom Resource Definition)는 사용자 정의 리소스를 정의하고 사용하는 메커니즘을 제공합니다. 이를 통해 Kubernetes API를 확장하고, 표준 Kubernetes 리소스(예: Pods, Services) 외에 사용자 정의 리소스를 생성할 수 있습니다.

Custom Resource (CR)

Custom Resource(CR)는 Kubernetes API에서 기본적으로 제공하는 리소스 외에, 사용자가 정의하고 사용할 수 있는 새로운 리소스 유형입니다. CR은 특정 도메인 또는 애플리케이션에 필요한 데이터와 상태를 관리하는 데 사용됩니다.

Custom Resource Definition (CRD)

Custom Resource Definition(CRD)는 Kubernetes API에 새로운 사용자 정의 리소스를 추가하는 메커니즘입니다. CRD를 생성하면, Kubernetes는 지정된 스키마에 따라 새로운 리소스 유형을 인식하고 이를 관리할 수 있습니다.

 

CRD는 YAML 파일로 정의되며, kubectl apply 명령을 통해 클러스터에 적용할 수 있습니다. 예를 들어, "MySQLDatabase"라는 사용자 정의 리소스를 정의하는 CRD는 다음과 같습니다.

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: mysqldatabases.example.com
spec:
  group: example.com
  versions:
  - name: v1
    served: true
    storage: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              version:
                type: string
              storage:
                type: string
                format: int64
  scope: Namespaced
  names:
    plural: mysqldatabases
    singular: mysqldatabase
    kind: MySQLDatabase
    shortNames:
    - mdb

이 CRD를 클러스터에 적용하면 mysqldatabases라는 새로운 리소스 유형을 사용할 수 있게 됩니다.

kubectl apply -f crd-mysqldatabase.yaml

Custom Resource (CR) 생성 예제

위에서 정의한 CRD를 기반으로 실제 사용자 정의 리소스를 생성할 수 있습니다. 예를 들어, 특정 버전과 스토리지 크기를 가지는 MySQL 데이터베이스 인스턴스를 정의하는 CR은 다음과 같습니다.

apiVersion: example.com/v1
kind: MySQLDatabase
metadata:
  name: my-database
spec:
  version: "5.7"
  storage: 10

이 CR을 클러스터에 적용하면 MySQLDatabase 리소스가 생성됩니다.

kubectl apply -f cr-mysqldatabase.yaml

CR과 CRD의 주요 개념 및 설정

  1. Custom Resource Definition (CRD)
    • 용도: 새로운 사용자 정의 리소스 유형을 정의하고, Kubernetes API에 추가합니다.
    • 구성 요소
      • group: 리소스 그룹 (예: example.com).
      • versions: 리소스 버전 및 스키마 정의.
      • scope: 리소스의 범위 (Namespaced 또는 Cluster).
      • names: 리소스 이름 (plural, singular, kind, shortNames).
  2. Custom Resource (CR)
    • 용도: CRD로 정의된 사용자 정의 리소스 인스턴스를 생성하고 관리합니다.
    • 구성 요소
      • apiVersion: CRD에서 정의한 API 버전 (예: example.com/v1).
      • kind: 리소스 유형 (예: MySQLDatabase).
      • metadata: 리소스 메타데이터 (이름 등).
      • spec: 리소스 사양.

CRD와 CR의 활용

CRD와 CR을 활용하면 특정 애플리케이션 도메인에 필요한 맞춤형 리소스를 Kubernetes에서 직접 관리할 수 있습니다. 이는 애플리케이션 개발자와 운영자가 Kubernetes의 기능을 확장하고, 복잡한 애플리케이션의 상태와 구성을 보다 효율적으로 관리할 수 있게 합니다.

 

예를 들어, 데이터베이스 운영, 맞춤형 배포 전략, 특정 워크플로우 관리 등의 요구 사항을 CRD와 CR을 통해 구현할 수 있습니다. 이를 통해 Kubernetes의 유연성과 확장성을 극대화할 수 있습니다.

728x90
저작자표시 비영리 동일조건