개인 공부/쿠버네티스

[쿠버네티스] PART1. 쿠버네티스 첫걸음

KimNang 2025. 4. 9. 16:11

목차

     

    1. 쿠버네티스의 등장

    01. 컨테이너 환경으로의 진화

    IT환경의 진화

    - 1990년대 IT 시스템은 다른 프로그램에 서비스를 요청하는 클라이언트와 응답하는 서버로 구성된 클라이언트/서버 형태

    - 이후 서버의 안정성을 위해 도입된 메인프레임은 중앙집중식으로 시스템을 운영

    - 2000년대에 접어들며 가상화 환경 등장

    - 가상화 환경은 인프라 확장할 때 스케일 아웃(scale out) 방식 사용하고, 메인프레임은 스케일 업(scale up)방식으로 확장

    스케일 아웃 : 기존 서버와 같은 사양 또는 비슷한 사양의 '서버 대수'를 늘려서 처리 능력 향상

    스케일 업 : '서버 자체 성능'을 향상시키는 것. CPU나 메모리를 추가하는 것

     

    - 2010년대엔 퍼블릭 클라우드(public cloud)가 급부상. 내부에 자체적으로 시스템 도입하고 구축하기보다 이미 구축된 외부의 서버를 빌려서 필요할 때만 사용하는 클라우드가 주목받기 시작함

    - 퍼블릭 클라우드는 제공 서비스에 따라 IaaS, PaaS, SaaS 모델로 나뉨

    IaaS (Infrastructure as a Service) : 인프라만 클라우드 벤더의 장비를 빌려서 사용하는 모델

    PaaS (Platform as a Service) : 개발 환경까지 클라우드 벤더가 책임지고 유지 관리

    SaaS (Software as a Service) : 서비스 영역까지 클라우드 벤더가 책임지고 관리하는 모델

    - 기업에서 서비스하려는 데이터와 애플리케이션의 성격에 따라 선택하는 모델은 각각 다름

    - 지금처럼 경쟁이 치열한 비즈니스 환경에선 IT 부서에 더 빠르고 혁신적인 기술 요구함 → 컨테이너(container) 환경 등장

    컨테이너 (container)

    - 데스크톱, 기존의 IT 환경 또는 클라우드 등 어디서나 애플리케이션 및 서비스를 실행하는데 필요한 모든 요소를 포함하는 소프트웨어 패키지
    - 운영 체제를 논리적인 구획(컨테이너)으로 나누고 애플리케이션을 격리된 환경에서 실행할 수 있음
    - 일반적인 가상화 : 하이퍼바이저 위에 가상 머신(Virtual Machine)을 올려 사용, 컨테이너 환경에서는 하이퍼바이저 대신 도커 같은 컨테이너 런타임 위에 컨테이너를 올려 사용

    • 가상화 환경과 컨테이너 환경 차이
      - 일반적은 가상화 환경은 하드웨어 수준에서 가상화, 컨테이너는 운영 체제 수준에서 가상화
      - 컨테이너는 운영 체제의 커널을 공유하기 때문에 상대적으로 가볍고 유연하게 운영할 수 있음
      - 컨테이너화된 애플리케이션은 몇 초 내로 빠르게 실행, 가상 머신과 비교했을 때 자원을 더 적게 사용해서 하나의 시스템에서 더 많은 애플리케이션 구동
      - 운영 체제를 공유해서 사용하기 때문에 패치, 업데이트 등 유지 관리와 관련한 오버헤드가 줄어든다는 장점
    • 컨테이너 런타임 (container runtime)
      - 컨테이너를 생성하고 실행할 수 있도록 도와주는 것
      - 컨테이너 런타임으로 가장 많이 사용하는 것이 도커. 하지만 쿠버네티스에서 도커를 더 이상 지원하지 않겠다고 발표하면서 크라이오 런타임의 인기가 높아짐
      • 컨테이너 런타임 도구
        - 컨테이너디(containerd) : 도커 사에서 개발한 오픈 소스 런타임. 컨테이너 이미지 내려받고 압축 푸는 과정부터 컨테이너 실행, 감독 과정까지 컨테이너의 전체 수명 주기를 관리하는 기능 제공
        - 도커(docker) : 컨테이너디 위에 설치되는 데몬. 컨테이너를 생성하고 관리하는 데 필요한 모든 기능 제공
        - 크라이오(CRI-O) : 레드햇(Redhat), 인텔(Intel), 수세(SUSE), Hyper, IBM 등의 관리자 및 커뮤니티를 중심으로 개발된 오픈 소스 런타임. 크라이오는 도커를 대체하기 위한 툴로 개발됨
    • 컨테이너 오케스트레이션 (container orchestration)
      - 컨테이너를 효과적으로 관리하도록 도와주는 것
      - 여러 시스템(노드)에 컨테이너를 분산해서 배치하거나 문제가 생긴 컨테이너를 교체하는 등 여러 역할을 맡고 있음
      - 컨테이너 오케스트레이션의 대표적인 툴이 쿠버네티스(Kubernetes)
      - 쿠버네티스가 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화하여 컨테이너 관리가 쉬워짐
      • 컨테이너 오케스트레이션 도구
        - 쿠버네티스(Kubernetes) : 구글에서 개발한 오케스트레이션 툴. 기능이 가장 많고 가상화 및 퍼블릭 클라우드 등 다양한 환경에서 작동하기 때문에 널리 사용되고 있음
        - 도커 스웜 (Docker Swarm) : 도커가 설치된 여러 대의 서버를 클러스터로 묶어 단일 환경으로 사용할 수 있는 툴. 설치 및 관리 쉬움
        - 아파치 메소스 (Apache Mesos) : 수만 대의 시스템으로 확장할 수 있도록 설계된 오케스트레이션 툴
        - 클러스터 환경에서 하둡(Hadoop), 스파크(Spark) 같은 응용 프로그램의 리소스 공유 및 분리를 유연하게 운영할 수 있음
    컨테이너, 도커, 쿠버네티스의 관계

    - 도커는 컨테이너를 실행하는 런타임, 쿠버네티스는 다수의 컨테이너를 관리하는 툴
    - 컨테이너를 실행할 때 도커는 꼭 있어야하지만, 쿠버네티스는 선택 사항
    - 애플리케이션 규모가 커지고, 데이터베이스와 백엔드, 프론트엔드 등 다양한 유형의 컨테이너들이 늘어나면 관리 어려워짐
    - 여러 컨테이너 애플리케이션을 다수의 시스템(노드)에 배포, 확장, 연결하는 작업을 자동화하는 등으로 관리 문제를 해결할 수 있는 것이 쿠버네티스
    - 컨테이너 : 호스트 운영 체제 위에 논리적인 구획(컨테이너)을 만들고 애플리케이션을 작동시키는 데 필요한 라이브러리나 애플리케이션 등을 하나로 모아 마치 별도의 서버인 것처럼 사용할 수 있게 만든 것, 애플리케이션을 구동하기 위한 환경
    - 파드는 서로 유기적인 애플리케이션이 실행 중인 컨테이너의 집합

     

    02. 쿠버네티스를 학습하기 전에 알아두면 좋은 개념

    - 데브옵스의 성숙화, 마이크로서비스 아키텍처로의 변화가 이루어지며 쿠버네티스가 일반적으로 사용될 수 있었음

    데브옵스

    - 개발(development)과 운영(operation)을 결합해 탄생한 개발 방법론

    - 시스템 개발자와 운영자의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론 또는 문화

    - 개발자와 운영자의 협업을 강조해 빠른 개발과 배포, 운영의 합의점을 찾아 비즈니스의 변화에 발맞춰 나아감

    - 데브옵스와 CI/CD 방법론을 이용해 빠르게 애플리케이션을 개발하고 배포할 수 있도록 도와주는 것이 쿠버네티스

    모놀리식 아키텍처와 마이크로서비스 아키텍처

    - 아키텍처는 어떤 방식으로 개발해야 하는지에 대한 가이드라인과 같은 역할

    - 컨테이너 기반의 애플리케이션으로 전환하고 싶다면 개발 아키텍처부터 변경해야 함

    - 애플리케이션 개발 아키텍처로는 모놀리식 아키텍처와 마이크로서비스 아키텍처가 있음

    • 모놀리식 아키텍처 (Monolithic Architecture)
      - 전통적인 애플리케이션 아키텍처를 지칭하는 의미
      - 모든 모듈이 하나의 덩어리로 구성된 서비스 또는 애플리케이션
      - 모듈끼리 서로 의존하는 성질이 강해서 모듈의 작은 변화라도 전체 애플리케이션에 영향을 미칠 수 있음
    • 마이크로서비스 아키텍처 (Microservice Architecture)
      - 모듈들이 모두 분리되어 API로 통신하는 서비스 혹은 애플리케이션
      - 각각의 모듈들이 개별적으로 분리되어 있어서 하나의 모듈을 변경한다고 해도 전체 애플리케이션에 영향을 주지 않는 장점
      - 유지 보수가 편리하며 비즈니스 변화에 능동적으로 대처할 수 있음

    - 이처럼 모듈별로 쪼개진 마이크로서비스 아키텍처에서는 더 이상 전통적 환경(서버/클라이언트)이나 가상화 환경에 애플리케이션을 구축할 필요가 없어짐

    - 상대적으로 가벼워진 애플리케이션은 이제 컨테이너 환경에서 배포가 가능해짐

    CI/CD

    - 데브옵스를 가능하게 하는 개발 방법론

    - CI (Continuos Intergration, 지속적 통합)는 데브옵스의 소프트웨어 개발 방식 중 하나, 지속적으로 통합하되 사람이 개입하는 것이 아니라 젠킨스 같은 툴을 사용해 자동으로 통합함

    - CD (Continous Deployment 지속적 배포) 역시 지속적 통합과 마찬가지로 데브옵스의 소프트웨어 개발 방식, 애플리케이션(프로그램)에 변경 사항이 발생하면 이에 대한 오류가 있는지 테스트한 후 프로그램을 리포지터리에 업로드하고, 마지막으로 운영 환경에 자동으로 배포함, 이때 운영 환경에 자동으로 배포할 수 있는 ArgoCD 같은 자동화 툴 이용

    03. 쿠버네티스 이해하기

    쿠버네티스

    - 컨테이너 기반의 애플리케이션을 개발하고 배포할 수 있도록 설계된 오픈 소스 플랫폼

    - 하나의 애플리케이션을 생성하기 위해서는 하나 이상의 파드(pod)가 필요함

    - 파드는 쿠버네티스에서 생성할 수 있는 가장 작은 배포 단위이면서 단일 혹은 다수의 컨테이너를 포함함

    - 파드 외에 서비스(service), 볼륨(volume), 네임스페이스(namespace) 등을 묶어서 오브젝트(object)라고 부름

    - 쿠버네티스에서 상태 관리가 필요한 대상이라고 이해하면 됨

    - 쿠버네티스는 다음과 같은 대상들의 상태를 관리함

    파드 : 쿠버네티스의 가장 기본적인 배포 단위

    서비스 : 배포한 파드를 외부에서 접근할 수 있게 함

    네임스페이스 : 쿠버네티스 클러스터의 논리적인 분리 단위

    볼륨 : 컨테이너의 파일을 저장하고 컨테이너 간 파일을 공유할 수 있는 저장소

    (그림)

    - 파드는 쿠버네티스에서 가장 기본적인 배포 단위이면서 하나 이상의 컨테이너를 포함함

    - 쿠버네티스의 특징 중 하나는 컨테이너를 개별적으로 하나씩 배포하는 것이 아니라 유사한 역할을 하는 컨테이너를 파드라는 단위로 묶어서 배포한다는 것

    - 도커 런타임이 설치된 환경에서 컨테이너 혹은 도커를 실행, 유지 및 관리하는 것을 워커 노드라고 함

    - 예를 들어 리눅스 위에 도커 엔진을 설치하고 그 위에 하나 이상의 컨테이너가 포함된 파드를 실행함. 이때 각 컨테이너에서는 그 목적에 맞는 서비스가 실행됨

    - 쿠버네티스는 기본적으로 마스터 노드 1대와 워커 노드 1대로 구성됨

    - 마스터 노드는 전체 쿠버네티스 환경을 관리하며, 워커 노드는 컨테이너를 실행하고 관리함

    - 워커 노드의 자원(CPU, 메모리 등) 사용률이 높을 때에는 워커 노드의 개수를 늘릴 수도 있음

    - 워커 노드의 개수와 상관없이 마스터 노드와 워커 노드로 구성된 쿠버네티스를 하나의 클러스터라고 부름

     

    쿠버네티스의 특징

    - 쿠버네티스를 사용하지 않고는 수많은 컨테이너를 관리하기 힘듦

    - 쿠버네티스를 사용하면 다음의 효과를 얻을 수 있음

    1. 무중단 서비스
      - 서비스 중단 없이 애플리케이션을 업그레이드할 수 있어서 안정적으로 서비스를 제공할 수 있음
    2. 클라우드 벤더 종속성 해결
      - 특정 클라우드 벤더에 종속되어 있지 않기 때문에 제품의 호환성 문제인 락인 현상이 없음
      - 다른 오픈 소스 제품 혹은 상용 제품과의 호환성도 뛰어남
    3. 효율적인 자원 사용
      - 파드가 사용할 수 있는 자원(CPU, 메모리 등)을 사전에 지정할 수 있어서 시스템(노드)의 전체 자원을 관리 가능
      - 따라서 자원을 효율적으로 사용할 수 있음
    4. 유연한 확장성
      - 파드의 자원 사용률에 따라 파드의 개수를 늘리거나 줄일 수 있음
    5. 애플리케이션 개발의 단순화
      - 컨테이너 환경에서는 오류 발생시 이전 환경으로 복구하거나 기존 환경은 그대로 두고 자바 버전을 업그레이드한 새로운 컨테이너를 띄우면 되므로 개발이 편리해짐
    6. 애플리케이션 배포의 가속화
      - 인프라 구성에 대한 정보 없이도 컨테이너화된 애플리케이션을 손쉽게 배포할 수 있음

     

    2. 쿠버네티스 기본 개념

    01. 쿠버네티스 아키텍처

    쿠버네티스 구조
    • 쿠버네티스 클러스터
      - 쿠버네티스의 여러 리소스를 관리하기 위한 집합체
      - 마스터 노드와 워커 노드를 이용해 하나의 쿠버네티스 클러스터를 구성할 수 있음
    • 마스터 노드
      - 쿠버네티스 클러스터 전체를 관리하는 시스템
      - 컨트롤 플레인(control plane)이라고도 함
    • 워커 노드
      - 마스터 노드에 의해 명령을 받아 파드를 생성하고 서비스한다고 해서 컴퓨팅 머신(computing machine)이라고도 함
    • 컨테이너 런타임
      - 파드를 실행하는 엔진
      - 대표적으로 도커가 있으며, 그 밖에도 컨테이너디, 크라이오 등이 런타임 엔진으로 많이 사용되고 있음
    • 영구 스토리지
      - 파드는 기본적으로 휘발성
      - 워커 노드에 떠 있는 파드가 삭제되면 파드 안의 모든 데이터도 즉시 삭제됨
      - 데이터베이스 같은 중요한 데이터는 파드 외부에 있는 영구 스토리지 (워커 노드의 D 드라이브나 데이터 저장 용도의 전용 스토리지 등)에 저장해두어야함
      - CSI (Container Storage Interface)로 외부 스토리지를 파드에 연결할 수 있음

    쿠버네티스 컴포넌트

    - 마스터 노드에는 클러스터를 유지하고 제어하기 위한 다양한 컴포넌트가 있음

    - 워커 노드에는 애플리케이션을 실행하기 위한 컴포넌트들이 있음

    - kubectl create -f deployment.yaml 명령어를 실행한 뒤 파드가 생성되는 과정에 따라 컴포넌트의 역할을 설명함

    yaml 파일
    - 쿠버네티스는 새로운 파드를 배포할 때 yaml 파일을 작성해 실행하고 관리함
    - 이러한 yaml 파일들을 매니페스트(manifest)라고 함
    - 쿠버네티스 오브젝트를 생성하는 데 필요한 메타 정보를 yaml(혹은 JSON형식도 가능) 파일로 만들어 관리함

     

    1. API 서버

    - API 서버(kube-apiserver)는 쿠버네티스 클러스터의 API를 사용할 수 있게 해주는 프로세스

    - 클러스터로 요청이 들어왔을 때 그 요청이 유효한지 검증함

    1. 가장 먼저 사용자를 인증함. 클러스터에 접속할 권한이 있는 사용자인지를 검증함
    2. 사용자가 보낸 명령어를 검증함. 문법, 철자가 맞는지 등등
    3. 사용자의 요청에 따라 파드를 생성함. API 서버가 워커 노드에 파드를 생성하도록 요청했지만 아직 생성은 안됨

     

    2. etcd

    - API 서버는 파드를 만든다는 사실을 etcd에 알리고 사용자에게 파드가 생성되었음을 알림

    - etcd는 클러스터의 상태를 저장함

    - 클러스터에 필요한 정보, 파드와 같은 리소스들의 상태 정보가 담겨 있는 곳

    - 이 정보들은 키-값(key-value) 형태로 저장됨

    - 사용자에게 파드가 생성되었음을 알렸지만, 내부적으로는 파드가 생성되지 않음

     

    3. 스케줄러

    - 파드를 위치시킬 적당한 워커 노드를 확인하고 API 서버에 이 사실을 알림

    - API 서버는 etcd에 해당 정보(어떤 워커 노드에 파드가 생성될지에 대한 정보)를 저장함

    - 파드를 어떤 노드에 할당해야 할지를 결정, 워커 노드의 리소스 사용량(CPU나 메모리 등의 사용량)을 참조해 결정

     

    4. kubelet

    - API 서버는 파드가 생성될 워커 노드에 있는 kubelet에 파드의 생성 정보를 전달함

    - kubelet은 해당 정보를 이용해 파드를 생성함

    - kubelet은 클러스터의 각 노드에서 실행되는 에이전트, 파드에서 컨테이너의 동작(생성 및 운영)을 관리함

    - 파드를 생성했다면 kubelet은 다시 API 서버에 생성된 파드의 정보를 전달하고 API 서버는 다시 etcd를 업데이트 함

    - 최종적으로 어떤 워커 노드에 어떤 파드가 생성되었는지 etcd에 저장하게 됨

     

    5. 컨트롤러 매니저

    - kube-controller-manager와 cloud-controller-manager 두가지 유형이 있음

    • kube-controller-manager
      - 다양한 컴포넌트의 상태를 지속적으로 모니터링하는 동시에 실행 상태를 유지하는 역할을 함
      - 컨트롤러 매니저가 특정 워커 노드와 통신이 불가능하다고 판단되면 해당 노드에 할당된 파드를 제거하고 다른 워커 노드에서 파드를 생성해 서비스가 계속되도록 함
    • cloud-controller-manager
      - EKS, AKS 같은 퍼블릭 클라우드에서 제공하는 쿠버네티스와 연동되는 서비스들을 관리함

     

    6. 프록시 (kube-proxy)

    - 클러스터의 모든 노드에서 실행되는 네트워크의 프록시

    - 노드에 대한 네트워크의 규칙을 관리하기 때문에 클러스터 내부와 외부에 대한 통신을 담당함

     

    7. 컨테이너 런타임

    - 컨테이너 실행을 담당함

    - 다양한 종류의 런타임을 지원

    - 많이 사용하는 도커(쿠버네티스 1.20 버전부터 도커는 지원 중단)부터 컨테이너디, 크라이오 등이 있음

     

    02. 쿠버네티스 컨트롤러

    - 쿠버네티스 컨트롤러는 파드를 관리하는 역할을 함

    - 쿠버네티스에서 제공하는 컨트롤러는 다음 그림과 같이 데몬셋, 디플로이먼트, 레플리카셋, 스테이트풀셋, 잡, 크론잡, 레플리케이션 컨트롤러가 있음

    - 용도에 따라 선택적으로 컨트롤러 사용

    디플로이먼트 (Deployment)

    - 쿠버네티스에서 상태가 없는(stateless) 애플리케이션을 배포할 때 사용하는 가장 기본적인 컨트롤러

    - 레플리카셋의 상위 개념이면서 파드를 배포할 때 사용

    - 파드를 배포할 때 다양한 방법을 지원해서 배포할 때 세밀한 조작이 가능함

    - 디플로이먼트는 다음과 같은 형식의 매니페스트 사용

    apiVersion : apps/v1      # 쿠버네티스의 apps/v1 API를 사용
kind : Deployment         # Deployment 작업으로 명시
metadata :
  name : deploy-test      # 디플로이먼트 이름 설정
  labels :
    app : deploy-test     # 디플로이먼트 레이블 설정
spec :
  replicas : 3            # 파드의 개수 설정으로 기본값은 1
  selector :              # 어떤 레이블의 파드를 선택해 관리할지 설정하는 부분, 여기서는 deploy-test라는 레이블의 파드를 관리하겠다는 의미
    matchLabels :
      app : deploy-test
  template :
    metadata :            # 어떤 파드를 실행할지 설정하는 부분, 여기서는 deploy-test라는 레이블의 파드를 실행하겠다는 의미
      labels :
        app : deploy-test
    spec :                # 컨테이너에 대한 설정 (컨테이너 이름, 이미지, 포트 정보 등을 설정)
      containers :
      - name : deploy-test
        image : nginx:latest
        ports :
        - containerPort : 80

     

    레플리카셋 (ReplicaSet)

    - 몇 개의 파드를 유지할지 결정하는 컨트롤러

    - 예를 들어 5개의 파드를 유지하도록 설정했다면 1개의 파드가 삭제되었다 해도 5개의 파드를 유지하기 위해 또 다른 파드 1개를 생성함

    apiVersion : apps/v1      # 쿠버네티스의 apps/v1 API를 사용
kind : ReplicaSet         # ReplicaSet 작업으로 명시
metadata :
  name : replica-test      # 레플리카셋셋 이름 설정
spec :
  template :
    metadata :            # 어떤 파드를 실행할지에 대한 정보
      name : replica-test # 생성될 파드의 이름
      labels :
        app : replica-test
    spec :                # 컨테이너에 대한 설정
      containers :
      - name : replica-test
        image : nginx
        ports :
        - containerPort : 80
  replicas : 3            # 몇 개의 파드를 유지할지 설정, 기본값은 1
  selector :              # 어떤 레이블의 파드를 선택할지 설정, 여기서는 replica-test 레이블을 갖는 파드를 선택
    matchLabels :
      app : replica-test

    - 레플리카셋과 유사한 기능을 가진 레플리케이션 컨트롤러 (Replication Controller)

    - 특정 파드의 개수를 유지하는 기능은 같지만 다음과 같은 차이점이 있음(최근 레플리케이션 컨트롤러는 잘 사용하지 않는 추세)

    구분 레플리카셋 레플리케이션 컨트롤러
    셀렉터
    (Selector)    		 집합 기반으로 in, not in, exists 같은 연산자를 지원함 등호 기반으로 레이블을 선택할 때 =, !=와 같이 같은지, 다른지만 비교함
    롤링 업데이트
    (rolling-update)    		 롤링 업데이트를 사용하려면 디플로이먼트를 이용해야 함 롤링 업데이트 옵션을 지원함

     

    롤링 업데이트
    - 기존에 배포된 애플리케이션(파드)을 수정해 재배포할 때, 새 버전의 애플리케이션이 포함된 파드는 하나씩 늘리고 이전 버전의 애플리케이션이 포함된 파드는 줄여가는 방식

     

    잡 (Job)

    - 하나 이상의 파드를 지정하고 지정된 수의 파드가 성공적으로 실행되도록 함

    - 노드의 하드웨어 장애나 재부팅 등으로 파드가 비정상적으로 작동하면(혹은 실행되지 않으면) 다른 노드에서 파드를 시작해 서비스가 지속되도록 함

    apiVersion : batch/v1       # 쿠버네티스의 batch/1 API를 사용
kind : Job                  # Job 작업으로 명시
metadata :
  name : job-test           # 잡 이름 설정
spec :                      # 실행할 컨테이너 설정
  template :
    metadata :
      name : job-test
    spec :
      containers :
      - name : job
        image : busybox     # 컨테이너 생성에 사용할 이미지
        command : ["echo", "job-test"] # 컨테이너에서 실행할 명령어
      restartPolicy : Never # 파드의 재시작 정책을 설정, Never는 재시작을 하지 않겠다는 의미

     

    크론잡 (CronJob)

    - 잡의 일종으로 특정 시간에 특정 파드를 실행시키는 것과 같이 지정한 일정에 따라서 잡을 실행시킬 때 사용

    - 주로 애플리케이션 프로그램, 데이터베이스와 같이 중요한 데이터를 백업하는 데 사용

    apiVersion : batch/v1       # 쿠버네티스의 batch/1 API를 사용
kind : CronJob              # CronJob 작업으로 명시
metadata :
  name : cron-test
spec :
  schedule : "*/1****"      # 잡이 실행될 주기, 여기서는 1분마다 실행되도록 설정
  jobTemplate :             # 실행될 크론잡의 설정
    spec :
      containers :
      - name : cron-test
        image : busybox
        args :
          - /bin/sh
          - -c
          - date; echo Hello this is Cron test
      restartPolicy : Never

     

    데몬셋 (DaemonSet)

    - 디플로이먼트처럼 파드를 생성하고 관리

    - 디플로이먼트가 실행해야 할 파드의 개수와 배포 전략을 세분화해 조작할 수 있다면, 데몬셋은 특정 노드 또는 모든 노드에 파드를 배포하고 관리

    - 주로 노드마다 배치되어야 하는 성능 수집 및 로그 수집 같은 작업에 사용됨

    apiVersion : apps/v1        # 쿠버네티스의 apps/1 API를 사용
kind : DaemonSet            # DaemonSet 작업으로 명시시
metadata :
  name : daemonset-test     # 데몬셋 이름 설정
  labels :
    app : daemonset-test    # 데몬셋을 식별할 수 있는 레이블을 지정
spec :
  selector :
    matchLabels :           # 어떤 레이블의 파드를 선택할지 지정
      app : daemonset-test
  template :
    metadata :
      labels :
        app : daemonset-test
    spec :
      tolerations :
      - key : node-role/master
        effect : NoSchedule
      containers :
        - name : busybox
          image : busybox
          args :
          - sleep
          - "10000"

     

    03. 쿠버네티스 서비스

    - 파드는 쿠버네티스 클러스터 안에서 옮겨 다니는 특성이 있음

    - 파드가 실행 중인 워커 노드에 문제가 생기면 다른 워커 노드에서 파드가 다시 생성될 수 있고 그때마다 IP가 변경되는 특성이 있음

    - 이 과정에서 워커 노드가 변경되기도 하고 파드 IP가 변경되기도 함

    - 동적으로 변하는 파드에 고정된 방법으로 접근하기 위해 사용하는 것이 서비스

    - 서비스를 사용하면 파드가 클러스터 내의 어디에 떠 있든지 고정된 주소를 이용해 접근할 수 있음

    - 클러스터 외부에서 파드에 접근 가능

    - 쿠버네티스 서비스는 다음과 같은 유형이 있음

    • 클러스터IP (ClusterIP)
      - 같은 클러스터 내부에서는 파드들이 통신할 방법을 제공
      - 클러스터 내의 모든 파드가 해당 클러스터 IP 주소로 접근할 수 있음
    • 노드포트 (NodePort)
      - 서비스(홈페이지 등)를 외부로 노출 할 때 사용
      - 노드포트로 서비스를 노출하기 위해 워커 노드의 IP와 포트를 이용함
    • 로드밸런서 (LoadBalancer)
      - 주로 퍼블릭 클라우드에 존재하는 로드밸런서에 연결하고자 할 때 사용
      - 사용자는 로드밸런서의 외부 IP (external IP)를 통해 접근

     

    04. 쿠버네티스 통신

    - 쿠버네티스에서 통신할 때 나타나는 몇가지 특징

    1. 파드가 사용하는 네트워크와 호스트(노드)가 사용하는 네트워크는 다름
      - 노드 내의 파드들은 가상의 네트워크(파드 및 컨테이너가 사용하는 네트워크)를 사용
      - 호스트는 물리 네트워크(마스터 및 워커 노드가 사용하는 네트워크)를 사용
    2. 같은 노드에 떠 있는 파드끼리만 통신할 수 있음
      - 같은 노드에 떠 있는 파드끼리는 통신이 가능하지만, 다른 노드의 파드 또는 외부와의 통신은 불가능
    3. 다른 노드의 파드와 통신하려면 CNI 플러그인이 필요함
      - CNI(Container Network Interface) : 컨테이너 간의 통신을 위한 네트워크 인터페이스
      - 플러그인(Plugin)은 컴퓨터에 추가 프로그램을 설치해 특정 기능을 수행할 수 있게 만드는 소프트웨어
      - CNI 플러그인은 컨테이너들의 네트워크를 연결하거나 삭제하며, 특히 삭제할 땐 할당된 자원을 제거함
      - 별도로 설치해야함
    같은 파드에 포함된 컨테이너 간 통신

    - 같은 파드 내에 있는 컨테이너 간의 통신은 직접 통신(로컬 호스트 통신)이 가능

    - 파드내에 존재하는 컨테이너들은 같은 가상 네트워크를 사용하기 때문

    - 하나의 파드 내에 존재하는 컨테이너들은 모두 동일한 IP를 사용함

    - 포트번호로 컨테이너를 구분함

    단일 노드에서 파드 간 통신

    - 단일 노드에 떠 있는 파드들은 같은 대역을 사용하므로 브리지를 통해 서로 통신함

    다수의 노드에서 파드 간 통신

    - 다수 노드에 떠 있는 파드 간의 통신은 혼란스러운 상황 발생 가능 (두 파드의 IP가 같은 경우)

    → 오버레이 네트워크로 문제 해결

    - 오버레이 네트워크 : 노드에서 사용하는 물리적인 네트워크 위에 가상의 네트워크를 구성하는 것

    - 오버레이 네트워크를 사용하면 쿠버네티스 클러스터로 묶인 모든 노드에 떠 있는 파드 간의 통신이 가능해짐

    - 쿠버네티스는 기본적으로 쿠버넷(kubenet)이라는 기본적이고 간단한 네트워크 플러그인을 제공하지만 다수의 노드에 떠 있는 파드 간의 통신이나 네트워크 정책 설정 같은 고급 기능은 CNI의 스펙을 준수하는 네트워크 플러그인을 사용해야 함

     

    플라넬(Flannel)

    - 쿠버네티스와 함께 사용할 수 있는 오버레이 네트워크 플러그인

    파드와 서비스 간의 통신
    • 서비스의 특성
      - 서비스도 파드처럼 IP를 가짐
      - 파드와 서비스에서 사용하는 IP 대역은 다름
      - 서비스에서 사용하는 가상 네트워크는 ifconfig나 라우팅 테이블에서 확인할 수 없음

    - 리눅스 커널에서 제공하는 netfilter와 iptables 덕분에 서비스IP로 Web Server 파드 찾아갈 수 있음

    - netfilter : 규칙 기반의 패킷 처리 엔진. 서비스 IP를 특정 IP로 변경할 수 있는 규칙을 저장하고 변환하는 역할

     

    외부와 서비스 간 통신

    - 서비스는 기본적으로 클러스터 내부적으로만 통신할 수 있게끔 설계됨

    - 외부와 통신할 수 있게 서비스 유형을 제공하고 있음

    • 노드포트(NodePort)
      - 노드 IP(eth)에 포트를 붙여서 외부에 노출시키는 것
    • 로드밸런서(LoadBalancer)
      - AWS, 애저, GCP와 같은 퍼블릭 클라우드에서 지원하는 쿠버네티스 로드밸런서 장비를 사용함
      - 클라우드에서 제공하는 로드밸런서와 파드를 연결한 후 로드밸런서 IP를 이용해 클러스터 외부에서 파드에 접근할 수 있도록 해줌
    • 인그레스(Ingress)
      - 클러스터 외부에서 내부로 접근하는 요청들을 어떻게 처리할지에 관한 규칙 모음
      - 인그레스 자체는 클러스터 외부에서 URL로 접근할 수 있도록 로드밸런싱, SSL 인증서 처리 등의 규칙을 정의한 것에 불과하며 실제로 동작시키는 것은 인그레스 컨트롤러(Ingress-Controller)