IBM Containers & Kubernetes Essentials

Jeongmin Yeo (Ethan)·2020년 12월 22일
IBMIBM Cloudersdockerkubernetes
3

IBM C:LOUDERs

목록 보기
4/5
post-thumbnail

IBM Introduction to Containers, Kubernetes, and OpenShift 수업을 듣고 핵심 내용을 정리한 글입니다.

정리한 내용은 다음과 같습니다.

  • Part 1. Understanding the Benefits of Containers
    • What is Container
    • Container vs Virtual Machine
    • What is Docker Container
    • Container vs Image
    • What is Dockerfile
    • Image Layer
    • Container Registry
  • Part 2. Understanding Kubernetes Architecture
    • Container Orchestration
    • What is Kubernetes
    • Kubernetes Architecture
      • cluster
      • Kubernetes Control Plane
      • Cloud Control Manager
      • kube-controller-manager
      • kube-api-server
      • etcd
      • kube-schedular
      • kubelet
      • node
      • pod
      • kube-proxy
      • kubectl
  • Kubernetes Object
  • Part 3. Managing Application with Kubernetes
    • ReplicaSets
    • AutoScaling
    • Rolling Updates
    • Config Maps
    • Secrets
    • Service Binding
  • Part 4. The Kubernetes Ecosystem
    • Red Hat Openshift and Kubernetes
    • Isotio

Part 1. Understanding the Benefits of Containers

What is Container

컨테이너는 code와 그 모든 dependencies을 패키징하여 애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 신속하고 안정적으로 실행되도록 하는 소프트웨어의 표준 단위입니다.

간단히 말해, 컨테이너는 응용프로그램, 모든 종속성, 라이브러리 및 기타 바이너리 파일들을 하나의 패키지 번들로 구성된 전체 런타임 환경입니다. 애플리케이션 플랫폼과 그 종속성을 컨테이너화함으로써 OS 배포와 기반 인프라의 차이는 추상화됩니다.

또 컨테이너는 모듈화를 가능하게 한다는 것입니다. 하나의 컨테이너 내에서 전체 복잡한 애플리케이션을 실행하는 대신, 애플리케이션을 모듈(예: 데이터베이스, 애플리케이션 프런트엔드 등)로 분할할 수 있습니다. 이건 마이크로 서비스 접근법으로 이러한 방식으로 구축된 애플리케이션은 각 모듈이 비교적 단순하고 전체 애플리케이션을 재구성할 필요 없이 모듈을 변경할 수 있기 때문에 더 쉽게 관리할 수 있습니다. 컨테이너는 매우 가볍기 때문에 개별 모듈(또는 마이크로 서비스)은 필요할 때만 인스턴스화할 수 있으며 바로 사용할 수 있습니다.

Container vs Virtual Machine

컨테이너는 호스트 OS(예: Linux 또는 윈도우즈)의 위에 있습니다. 각 컨테이너는 호스트 OS 커널과 이진 및 라이브러리도 공유합니다. 공유 구성 요소는 읽기 전용으로 되어있습니다. VM의 경우 크기는 기가바이트 시작하는데에 몇 분씩 걸리는 반면 컨테이너의 크기는 메가바이트에 불과하고 시작시 몇 초밖에 걸리지 않습니다.

VM에는 별도의 운영 체제 이미지가 포함되어 있어 메모리 및 스토리지 설치 공간에 오버헤드를 추가합니다. 이 문제는 개발 및 테스트에서 운영 및 재해 복구에 이르기까지 소프트웨어 개발 라이프사이클의 모든 단계에 복잡성을 가중시킵니다. 또한 이러한 접근 방식은 퍼블릭 클라우드, 프라이빗 클라우드 및 기존 데이터 센터 간의 애플리케이션 이동성을 크게 제한합니다.

컨테이너는 VM보다 오버헤드를 줄입니다. VM에는 별도의 운영 체제 이미지가 포함되어 있어 메모리 및 스토리지 설치 공간에 오버헤드가 추가로 있습니다. 이런 문제는 퍼블릭 클라우드, 프라이빗 클라우드 및 기존 데이터 센터 간의 애플리케이션 이동성을 크게 제한하고 개발 및 테스트에서 운영 및 복구에 이르는 복잡성이 있습니다. 하지만 컨테이너는 동일한 운영 체제를 공유하기 때문에 단일 운영 체제에만 버그 수정, 패치 등에 대한 관리 및 피드가 필요합니다. 이건 하이퍼바이저 호스트에서 경험하는 것과 유사합니다. 관리 지점은 적지만 장애 도메인은 약간 높습니다. 즉, VM보다 컨테이너의 무게가 가볍고 휴대성이 뛰어납니다.

What is Docker Container

컨테이너는 코드와 그 모든 의존성을 패키징하여 애플리케이션이 한 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 신속하고 안정적으로 실행되도록 하는 소프트웨어의 표준 단위입니다. Docker 컨테이너 이미지는 코드, 런타임, 시스템 도구, 시스템 라이브러리 및 설정 등 애플리케이션을 실행하는 데 필요한 모든 것을 포함하는 가독립 실행 가능한 소프트웨어 패키지입니다.

컨테이너 이미지는 런타임에 컨테이너가 되고, 도커 컨테이너의 경우, 도커 엔진에서 실행될 때 이미지가 컨테이너가 됩니다. Linux 및 Windows 기반 애플리케이션에서 모두 사용할 수 있는 컨테이너형 소프트웨어는 인프라에 관계없이 항상 동일하게 실행됩니다. 컨테이너는 소프트웨어를 환경에서 격리하고 개발 및 스테이징 간의 차이에도 불구하고 소프트웨어가 항상 동일하게 작동하도록 보장합니다.

Container vs Image

도커 이미지는 응용 프로그램을 실행하는 데 필요한 소스 코드, 라이브러리, 의존성, 및 기타 파일을 포함하는 Immutable(변경 불가) 파일입니다

ReadOnly(읽기 전용으로 인해 이러한 이미지를 특정 시점의 애플리케이션과 해당 가상 환경을 나타내느 컨테이너의 스냅샷이라고도 합니다. Immutable 특성은 Docker의 가장 큰 특징 중 하나이고 이를 통해 개발자는 안정적이고 균일한 조건에서 소프트웨어를 테스트하고 실험할 수 있습니다.

컨테이너는 이미지 없이 존재할 수 없습니다. 컨테이너는 이미지를 실행해야 하고 따라서 이를 사용하여 런타임 환경을 구성하고 응용 프로그램을 실행합니다. 실행 중인 컨테이너가 해당 프로세스의 최종 "단계"입니다.

객체 지향 언어로 비교하자면 클래스가 이미지고 컨테이너는 인스턴스입니다.

What is Dockerfile

From Dockerfile to Image to Container

Docker Container는 Dockerfile을 통해서 관리할 수 있으며 Dockerfile을 통해 이미지를 만들고 이 이미지를 통해 컨테이너를 실행합니다.

Dockerfile Instruction

  • FROM

    • From Instruction은 기반이 되는 Base Image를 알려 줍니다.

    • 이런 Base Image는 Operating System이 될 수 있고, Node가 될 수 있습니다.

  • RUN

    • 현재의 이미지에 새로운 계층의 레이어를 실행하는 역할을 합니다.

    • RUN은 FROM에서 설정한 이미지 위에서 스크립트 혹은 명령을 실행합니다. 여기서 RUN으로 실행한 결과가 새 이미지로 생성되고, 실행 내역은 이미지의 히스토리에 기록됩니다.

  • VOLUME

    • 컨테이너를 지정된 마운트 지점을 생성하고 호스트와 공유할 컨테이너 내부의 디렉터리를 설정합니다.

  • ENV

    • Dockerfile에서 사용할 환경변수를 설정합니다. 설정한 환경변수는 ${ENV_NAME} 또는 $ENV_NAME의 형태로 사용할 수 있습니다.

    • ENV 지침은 환경 변수를 Key-Value로 설정합니다.

  • COPY

    • COPY는 로컬 디렉터리에서 읽어 들인 컨텍스트로부터 이미지에 복사하는 역할을 합니다.

  • ADD

    • ADD는 COPY와 같은 역할을 합니다. 그러나 COPY는 로컬의 파일만 이미지에 추가하는 반면에 ADD는 외부 URL, tar파일 에서도 파일을 추가할 수 있습니다.

  • CMD

    • 컨테이너가 만들어질 때 실행할 기본값, 즉 실행할 명령어를 설정한다.

  • ENTRYPOINT

    • CMD와 같이 컨테이너가 시작할 때 수행할 명령어를 지정한다는 점에서 같습니다. 그러나 ENTRYPOINT는 cmd를 인자로 받아 사용할 수 잇는 스크립트의 역할을 할 수 있다는 점에서 다릅니다

  • WORKDIR

    • RUN, CMD and ENTRYPOINT에서 설정한 실행 파일이 실행될 디렉터리입니다.

  • EXPOSE

    • EXPOSE는 호스트와 연결할 포트 번호를 설정합니다. docker run 명령의 --expose 옵션과 동일합니다.

Image Layer

도커 컨테이너는 애플리케이션을 구성하는 블록입니다. 각 컨테이너는 여러 개의 읽기 전용 레이어 위에 읽기/쓰기 가능 레이어가 있는 이미지입니다.
이러한 레이어들은 Dockerfile을 통해 Docker 이미지를 빌드할 때 생성됩니다.

도커 이미지 레이어들은 Docker Host 기준으로 /var/lib/docker/aufs/diff. 여기서 볼 수 있습니다.

Container Registry

컨테이너 레지스트리는 이름이 도커 이미지를 보관하는 저장소 및 콘텐츠 전송 시스템으로 Stateless 서버측 응용 프로그램입니다.

Part 2. Understanding Kubernetes Architecture

Container Orchestration

컨테이너 오케스트레이션은 컨테이너의 배포, 관리, 확장, 네트워킹을 자동화합니다. 수백 또는 수천 개의 컨테이너와 호스트를 배포하고 관리하는 작업을 컨테이너 오케스트레이션을 통해 가능합니다.

컨테이너 오케스트레이션은 컨테이너를 사용하는 어떤 환경에서든 사용할 수 있고 또한 재설계할 필요 없이 각기 다른 환경 전반에 동일한 애플리케이션을 배포하는 데에도 도움이 됩니다. 컨테이너에 마이크로서비스를 구현하면 스토리지, 네트워킹, 보안과 같은 서비스를 간편하게 오케스트레이션할 수 있습니다.

컨테이너는 마이크로서비스 기반 애플리케이션에 배포 유닛 및 독립적인 실행 환경을 제공하기도 합니다. 마이크로서비스에서 애플리케이션의 여러 부분들을 독립적으로 실행시키고 개별 요소 및 라이프사이클을 더욱 효과적으로 제어하는게 가능합니다. 또한 로드 밸런싱 및 트래픽 라우팅이 가능하기도 합니다.

What is Kubernetes

쿠버네티스는 컨테이너 오케스트레이션 툴입니다. 컨테이너 오케스트레이션 툴은 컨테이너와 마이크로서비스 아키텍처를 규모에 따라 관리할 프레임워크를 제공해줍니다.

쿠버네티스 오케스트레이션을 사용하면 여러 컨테이너에 걸쳐 애플리케이션 서비스를 구축하고 클러스터 전체에서 컨테이너의 일정을 계획하고 이러한 컨테이너를 확장하여 컨테이너의 상태를 지속적으로 관리할 수 있습니다.

컨테이너를 실행하는 호스트 그룹(물리적 머신 또는 가상 머신 모두 가능)을 함께 클러스터링할 수 있으며 쿠버네티스를 통해 이러한 클러스터를 쉽고 효율적으로 관리할 수 있습니다.

쿠버네티스는 다음과 같은 기능을 제공합니다.

Service discovery and load balancing

쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 외부에 노출시킬 수 있습니다. 컨테이너에 대한 트래픽이 많다면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱해서 배포가 안정적으로 이루어질 수 있도록 할 수 있습니다.

Storage orchestration

쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있습니다.

Automated rollouts and rollbacks

쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태(Desired State)를 정의할 수 있으며 현재 상태를 원하는 상태로 제어된 속도에 따라 변경할 수 있습니다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있습니다.

Automatic bin packing

컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 알려주면 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공해줍니다. 각 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해줍니다.

Self-healing

쿠버네티스는 장애가 발생한 컨테이너를 재시작하고, 컨테이너를 교체하며, 사용자 정의 상태 검사(health check)에 응답하지 않는 컨테이너를 제거하며, 서비스를 제공할 준비가 될 때까지 클라이언트에게 보급하지 않습니다.

Secret and configuration management

쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리할 수 있습니다. 컨테이너 이미지를 재구성하지 않고 스택 구성의 기밀을 노출하지 않고 비밀 및 응용프로그램 구성을 배포 및 업데이트할 수 있습니다.

Kubernetes Architecture

쿠버네티스 아키텍처를 구성하는 요소들은 아래 사진과 같습니다.

cluster

쿠버네티스 클러스터는 쿠버네티스에서 배포하는 기본 단위이며 컨테이너화된 애플리케이션을 실행하기 위한 일련의 노드 머신입니다. 쿠버네티스를 실행 중이라면 클러스터를 실행하고 있는 것입니다. 모든 클러스터는 최소 한 개의 워커 노드를 가집니다.

기본적으로 클러스터에는 작업자 노드와 마스터 노드가 포함됩니다. 마스터 노드는 쿠버네티스 노드를 제어하는 머신입니다. 여기에서 모든 태스크 할당이 시작됩니다. 즉 어느 애플리케이션을 실행하고 애플리케이션이 어느 컨테이너 이미지를 사용할지와 같이 클러스터를 원하는 상태로 유지 관리합니다.

작업자 노드는 할당된 태스크를 요청대로 수행하는 머신입니다. 쿠버네티스 마스터가 이러한 노드를 제어하고 애플리케이션과 워크로드를 실제로 실행합니다.

Kubernetes Control Plane

쿠버네티스 컨트롤 플레인은 클러스터의 신경 중추라 할 수 있습니다. 여기에는 클러스터를 제어하는 쿠버네티스 구성 요소와 클러스터의 상태 및 구성에 관한 데이터가 함께 있습니다. 이 구성 요소는 컨테이너가 필요한 리소스를 갖고 충분한 횟수로 실행되도록 하는 중요한 작업을 맡습니다.

컨트롤 플레인은 컴퓨팅 노드와 상시 연결되어 있습니다. 클러스터가 일정한 방식으로 실행되도록 구성했다면 컨트롤 플레인은 해당 방식에 따라 실행됩니다.

컨트롤 플레인 컴포넌트는 클러스터에 관한 전반적인 결정(예를 들어, 스케줄링)을 수행하고 클러스터 이벤트(예를 들어, 디플로이먼트의 replicas 필드에 대한 요구 조건이 충족되지 않을 경우 새로운 파드를 구동시키는 것)를 감지하고 반응합니다. 쉽게 풀어 얘기하자면 현재의 클러스터 상태를 사용자가 원하는 클러스터 상태로 끊임없이 조정해 주는 컨트롤 센터라고 보면 됩니다.

Cloud Control Manager

클라우드별 컨트롤 로직을 포함하는 쿠버네티스 컨트롤 플레인 컴포넌트입니다. 클라우트 컨트롤러 매니저를 통해 클러스터를 클라우드 공급자의 API에 연결하고, 해당 클라우드 플랫폼과 상호 작용하는 컴포넌트와 클러스터와 상호 작용하는 컴포넌트를 분리할 수 있다.

cloud-controller-manager는 클라우드 제공자 전용 컨트롤러만 실행합니다. 자신의 사내 또는 PC 내부의 학습 환경에서 쿠버네티스를 실행 중인 경우 클러스터에는 클라우드 컨트롤러 매니저가 없다고 생각하시면 됩니다.

kube-controller-manager

Controller를 구동하는 마스터 상의 컴포넌트입니다.

Controller는 실내 온도 조절기와 같이 동작합니다. 각각의 pod들을 관리하며 API 서버를 통해 클러스터의 상태를 검사하고 현재 상태를 원하는 상태로 게속해서 이행하도록 해줍니다.

kube-api-server

쿠버네티스는 MSA(마이크로서비스아키텍처, Micoro Service Architecture) 구조로 되어 있습니다. 그래서 여러개의 분리된 프로세스로 구성되어 있습니다. 그중에서 kube-apiserver는 쿠버네티스 클러스터의 api를 사용할수 있게 해주는 프로세스입니다. 클러스터로 요청이 왔을때 그 요청이 유효한지 검증하는 역할을 합니다

API 서버는 쿠버네티스 컨트롤 플레인의 프론트 엔드라고 생각하면 되고 모든 클러스터의 통신은 kube-api-server를 통해 이뤄집니다.

etcd

etcd는 고가용성을 제공하는 키-밸류(key-value) 저장소입니다. 쿠베네티스에서 필요한 모든 데이터를 저장하는 실질적인 데이터베이스입니다.

etcd는 프로세스 1개만 띄워서 사용할수도 있지만 데이터의 안정성을 위해서는 여러개의 장비에 분산해서 etcd자체를 클러스터링을 구성해서 띄우는게 일반적인 방법입니다. etcd가 안정적이기는 하지만 보다 안정적으로 쿠버네티스를 운영하려면 주기적으로 etcd에 있는 데이터를 백업해 두는게 좋습니다.

kube-schedular

쿠버네티스에서 스케줄링은 Kubelet이 pod를 실행할 수 있도록 파드가 노드에 적합한지 확인하는 것을 말합니다.

스케줄러는 노드가 할당되지 않은 새로 생성된 파드를 감시하고 스케줄러가 발견한 모든 파드에 대해 스케줄러는 해당 파드가 실행될 최상의 노드를 찾는 책임을 집니다.

kube-scheduler는 쿠버네티스의 기본 스케줄러이며 컨트롤 플레인의 일부로 실행됩니다.

새로 생성된 모든 pod 또는 예약되지 않은 다른 pod에 대해 kube-scheduler는 실행할 최적의 노드를 선택합니다. 그러나 파드의 모든 컨테이너에는 리소스에 대한 요구사항이 다르며 모든 파드에도 요구사항이 다릅니다. 따라서 기존 노드들은 특정 스케줄링 요구사항에 따라 필터링 되어야 합니다.

스케줄러는 pod가 실행 가능한 노드를 찾은 다음 실행 가능한 노드의 점수를 측정하는 기능 셋을 수행하고 실행 가능한 노드 중에서 가장 높은 점수를 가진 노드를 선택하여 pod를 실행합니다. 그런 다음 스케줄러는 바인딩 이라는 프로세스에서 이 결정에 대해 API 서버에 알린다.

스케줄링 결정을 위해 고려해야 할 요소에는 개별 및 집단 리소스 요구사항, 하드웨어 / 소프트웨어 / 정책 제한조건, 어피니티 및 안티-어피니티 명세, 데이터 지역성(data locality), 워크로드 간 간섭 등이 포함됩니다.

kubelet

클러스터의 각 노드에서 실행되는 에이전트로 Kubelet은 pod에서 container가 확실하게 동작하도록 관리합니다.

Kubelet은 다양한 메커니즘을 통해 제공된 파드 스펙(PodSpec)의 집합을 받아서 컨테이너가 해당 파드 스펙에 따라 확실하게 동작하도록 합니다. 그리고 Kubelet은 쿠버네티스를 통해 생성되지 않는 컨테이너는 관리하지 않습니다.

node

쿠버네티스는 컨테이너를 pod내에 배치하고 노드에서 실행함으로 워크로드를 구동합니다.

유저 어플리케이션은 노드위에서 구동된다고 생각하시면 됩니다.

노드는 클러스터에 따라 가상 또는 물리적 머신일 수 있으며 각 노드에는 컨트롤 플레인이라는 컨테이너의 라이프사이클을 정의하는 API가 담긴 레이어가 포함된 pod를 실행하는데 필요한 서비스가 포함되어 있습니다.

일반적으로 클러스터에는 여러 개의 노드가 있으며, 학습 또는 리소스가 제한되는 환경에서는 하나만 있을 수도 있습니다.

노드의 컴포넌트에는 kubelet, 컨테이너 런타임 그리고 kube-proxy가 포함됩니다.

pod

Pod란 쿠버네티스에서 최소 배포 단위로 하나 이상의 컨테이너를 포함합니다.

Docker를 사용해본 사용자라면 알듯 Docker에서는 최소의 배포 단위가 컨테이너입니다.

하지만 쿠버네티스는 하나의 컨테이너가 아닌 컨테이너 및 네트워크, 스토리지가 포함된 Pod로 배포합니다

기본적으로 하나의 Pod에는 1개의 컨테이너를 올리지만 두 개의 컨테이너가 밀접한 관계를 가지고 있을 때에는 하나의 Pod에 하나 이상의 컨테이너를 배포하기도 합니다.

kube-proxy

kube-proxy는 클러스터의 각 노드에서 실행되는 네트워크 프록시로, 쿠버네티스의 서비스 개념의 구현부입니다.

kube-proxy는 노드의 네트워크 규칙을 유지 관리하며 이 네트워크 규칙이 내부 네트워크 세션이나 클러스터 바깥에서 pod로 네트워크 통신을 할 수 있도록 해줍니다.

kubectl

Kubectl은 쿠버네티스 클러스터를 제어하기 위한 커맨드 라인 도구입니다.

Kubernetes Object

쿠버네티스는 상태를 관리하기 위한 대상을 오브젝트로 정의합니다. 기본으로 수십 가지 오브젝트를 제공하고 새로운 오브젝트를 추가하기가 매우 쉽기 때문에 확장성이 좋습니다.

각각의 Object는 Spec과 Status라는 필드를 갖게되는데 쿠버네티스는 Object의 Spec을 통해 사용자가 기대하는 상태(Desired State)가 무엇인지 알 수 있고, 기대되는 값에 대비한 현재의 상태를 Object의 Status를 통해 알 수 있습니다.

이 때 Object의 Status를 갱신하고, Object를 Spec에 정의된 상태로 지속적으로 변화시키는 주체를 Controller라고 합니다.

여러 오브젝트 중 주요 오브젝트는 다음과 같습니다.

pod

쿠버네티스에서 배포할 수 있는 가장 작은 단위로 한 개 이상의 컨테이너와 스토리지, 네트워크 속성을 가집니다. Pod에 속한 컨테이너는 스토리지와 네트워크를 공유하고 서로 localhost로 접근할 수 있습니다. 컨테이너를 하나만 사용하는 경우도 반드시 Pod으로 감싸서 관리합니다.

ReplicaSet

Pod을 여러 개(한 개 이상) 복제하여 관리하는 오브젝트입니다. Pod을 생성하고 개수를 유지하려면 반드시 ReplicaSet을 사용해야 합니다. ReplicaSet은 복제할 개수, 개수를 체크할 라벨 선택자, 생성할 Pod의 설정값(템플릿)등을 가지고 있습니다. 직접적으로 ReplicaSet을 사용하기보다는 Deployment등 다른 오브젝트에 의해서 사용되는 경우가 많습니다.

Service

네트워크와 관련된 오브젝트입니다. Pod을 외부 네트워크와 연결해주고 여러 개의 Pod을 바라보는 내부 로드 밸런서를 생성할 때 사용합니다. 내부 DNS에 서비스 이름을 도메인으로 등록하기 때문에 서비스 디스커버리 역할도 합니다.

Volume

저장소와 관련된 오브젝트입니다. 호스트 디렉토리를 그대로 사용할 수도 있고 EBS 같은 스토리지를 동적으로 생성하여 사용할 수도 있습니다. 사실상 인기 있는 대부분의 저장 방식을 지원합니다.

Object Spec

오브젝트의 명세Spec는 YAML 파일로 정의하고 여기에 오브젝트의 종류와 원하는 상태를 입력합니다. 이러한 명세는 생성, 조회, 삭제로 관리할 수 있기 때문에 REST API로 쉽게 노출할 수 있습니다. 접근 권한 설정도 같은 개념을 적용하여 누가 어떤 오브젝트에 어떤 요청을 할 수 있는지 정의할 수 있습니다.

Part 3. Managing Application with Kubernetes

ReplicaSets

ReplicaSet의 목적은 ReplicaSet pod 집합의 실행을 항상 안정적으로 유지하는 것입니다. 이처럼 ReplicaSet은 보통 명시된 동일 파드 개수에 대한 가용성을 보증하는데 사용합니다.

ReplicaSet을 정의하는 필드는 획득 가능한 파드를 식별하는 방법이 명시된 Selector, 유지해야 하는 파드 개수를 명시하는 replicas, 그리고 레플리카 수 유지를 위해 생성하는 신규 파드에 대한 데이터를 명시하는 pod template을 포함합니다. 그러면 ReplicaSet은 필드에 지정된 설정을 충족하기 위해 필요한 만큼 파드를 만들고 삭제하며. ReplicaSet이 새로운 파드를 생성해야 할 경우, 명시된 파드 템플릿을 사용합니다.

AutoScaling

Auto Scaling 서비스는 사용자가 정의한 주기(스케줄링)나 이벤트(모니터링 알람)에 따라 서버를 자동으로 생성하거나 삭제됩니다. 서비스에 사용자가 늘어나는 경우에는 원활한 서비스를 위해 서버를 늘리고, 다시 여유로운 상황이 되면 불필요한 서버를 자동으로 줄여 발생하는 요금을 낮출 수 있습니다.

Kubernetes는 다음과 같은 알고리즘을 통해 적절한 pod 개수를 유지합니다.

Horizontal Pod Autoscaler 컨트롤러는 원하는(desired) 메트릭 값과 현재(current) 메트릭 값 사이의 비율로 작동합니다.

원하는 Replica(레플리카) 수
= ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]

예를 들어 현재 메트릭 값이 200m이고 원하는 값이 100m인 경우 200.0 / 100.0 == 2.0이므로 복제본 수가 두 배가 된다.

만약 현재 값이 50m 이면, 50.0 / 100.0 == 0.5 이므로 복제본 수를 반으로 줄어들 것입니다.

Rolling Updates

쿠버네티스에서는 무중단 배포를 지원합니다. 그중 가장 많이 사용되는 배포 방식 중 하나인 Rolling Update란 새 버전을 배포하면서, 새 버전 인스턴스를 하나씩 늘려가고 기존 버전의 인스턴스를 하나식 줄여나가는 방식입니다. 이러한 경우 새 버전의 인스턴스로 트래픽이 이전되기 전까지 이전 버전과 새 버전의 인스턴스가 동시에 존재할 수 있다는 단점이 있지만, 시스템을 무중단으로 업데이트 할 수 있다는 장점이 있습니다.

쿠버네티스에서 Replica Set(이하 RS)을 이용하는 방법은 아래와 같습니다.

먼저 예시의 상황은 RS가 v1 버전의 파드들을 관리하고 3개의 파드가 서비스되고 있는 상황입니다.

이때, v2버전의 pod3개를 배포해야하는 상황이 생깁니다. 그래서 2 파드를 컨트롤할 ReplicaSet를 만들고 replica를 1로 해서 v2 Pod를 하나 생성합니다. 그리고 ReplicaSet v1에서는 replica의 수를 3에서 2로 줄이고 v1 파드의 수를 2개로 조정하게 됩니다.
같은 방식으로 v1의 파드는 수를 줄여가고 v2의 파드는 수를 늘리게 됩니다. 그리고 최종적으로 v1의 파드는 0개가 되고 ReplicaSet v1은 삭제됩니다.

Config Maps

Config Map은 Key-Value 쌍으로 Secret이 아닌 데이터를 저장하는 데 사용하는 API 오브젝트입니다. pod는 Volume에서 환경 변수, 커맨드-라인 인수 또는 구성 파일로 Config Map을 사용할 수 있습니다.

Config Map을 사용하면 컨테이너 이미지에서 환경별 구성을 분리하여, 애플리케이션을 쉽게 이식할 수 있다는 특징이 있습니다.

Config Map은 보안 또는 암호화를 제공하지 않습니다. 저장하려는 데이터가 노출되면 안되는 경우인 경우, Config Map 대신 Secret 또는 추가(써드파티) 도구를 사용하여 데이터를 비공개로 유지하면 됩니다.

Secrets

시크릿(secret)은 비밀번호, OAuth 토큰, ssh 키 같은 민감한 정보들을 저장하는 용도로 사용합니다. 이런 정보들은 컨테이너 안에 저장해 두지 않고 별도로 보관해 두었다가 실제 포드가 실행할때 설정을 통해서 컨테이너에 제공해 줍니다.

시크릿은 내장 시크릿(built-in)과 사용자 시크릿 2가지 종류가 있습니다. 내장 시크릿은 쿠버네티스 클러스터 내부에서 API에 접근할때 사용됩니다. 클러스터 내부에서 사용되는 계정인 ServiceAccount를 생성하면 자동으로 관련 시크릿이 만들어 집니다. 이렇게 만들어진 시크릿을 이용해서 해당
ServiceAccount가 권한을 가지고 있는 API에 접근할 수 있습니다.

사용자 시크릿은 사용자가 만든 시크릿입니다. 시크릿은 kubectl create secret 명령으로도 만들 수 있고 다른 자원들 처럼 yaml파일을 이용해서 만들수도 있습니다.

Service Binding

IBM Cloud 서비스를 클러스터에 제공하고 싶다면 Service Binding을 사용하면 됩니다.

IBM Cloud 서비스를 클러스터에 추가하는 경우 IBM Cloud Identity and Access Management(IAM)가 사용으로 설정된 서비스와 Cloud Foundry를 기반으로 하는 서비스 중에서 선택할 수 있습니다.

서비스 바인딩은 공용 서비스 엔드포인트를 사용하고 이러한 인증 정보를 클러스터의 Kubernetes 시크릿에 저장하여 IBM Cloud 서비스에 대한 서비스 인증 정보를 작성할 수 있는 방법입니다.

클러스터에 서비스를 바인드하려면 우선 서비스의 인스턴스를 프로비저닝해야 합니다. 그런 다음, ibmcloud ks cluster service bind 명령을 사용하여 서비스 인증 정보 및 Kubernetes 시크릿을 작성합니다. Kubernetes 시크릿은 데이터 보호를 위해 etcd에서 자동으로 암호화됩니다.

Part 4. The Kubernetes Ecosystem

Red Hat Openshift and Kubernetes

Red Hat OpenShift는 쿠버네티스 배포판입니다. 즉, 오픈소스 프로젝트에 뿌리를 둔 상업용 소프트웨어 제품입니다. Red Hat OpenShift와 쿠버네티스 둘 다 컨테이너 오케스트레이션 소프트웨어입니다. 그러나 Red Hat OpenShift는 다운스트림 엔터프라이즈 오픈소스 플랫폼으로 패키징되었습니다. 즉, 별도의 테스트를 거쳤으며 쿠버네티스 오픈소스 프로젝트에서 제공하지 않는 추가 기능을 갖추고 있습니다.

Red Hat Openshift는 쿠버네티스만으로는 충분하지않은 쿠버네티스의 기능과 별도로 다른 구성 요소, 즉 네트워킹, 수신(ingress), 부하 분산, 스토리지, 모니터링, 로깅 등을 통합해서 제공합니다.

Isotio

Istio는 마이크로서비스 간 데이터 공유를 제어하는 기반을 제공하는 오픈소스 서비스 메쉬 플랫폼입니다. Istio에는 모든 로깅 플랫폼, 텔레메트리 또는 정책 시스템으로 통합하도록 지원하는 API가 포함됩니다. Istio는 온프레미스, 클라우드 호스팅, 쿠버네티스 컨테이너, 가상 머신에서 실행되는 서비스 등 다양한 환경에서 구동되도록 설계되었습니다.

Istio의 기능을 활용하여 분산된 마이크로서비스 아키텍처를 실행할 수 있습니다.

  • Traffic management

    • Istio에서의 트래픽 라우팅 및 룰 설정을 통해 서비스 간 트래픽 흐름 및 API 호출을 제어할 수 있습니다.

  • Secret

    • Istio는 기본 통신 채널을 제공하고 스케일에 따른 인증, 권한 부여 및 서비스 통신 암호화를 관리합니다. Istio를 활용하면 애플리케이션 변경을 최소화하면서 여러 프로토콜 및 런타임 전반에서 정책을 일관되게 실행할 수 있습니다. Istio와 쿠버네티스(또는 인프라) 네트워크 정책을 함께 사용하면 네트워크 및 애플리케이션 레이어에서 포드(pod) 간 또는 서비스 간 커뮤니케이션을 보안할 수 있습니다.

  • Observability

    • Istio의 추적, 모니터링 및 로깅 기능을 통해 서비스 메쉬 배포 환경에 대한 인사이트를 확보할 수 있습니다. 모니터링을 통해 서비스 활동이 성능 업스트림 및 다운스트림에 어떻게 영향을 미치는지 파악할 수 있습니다. 커스텀 대시보드를 통해 모든 서비스의 성능을 확인할 수 있습니다.
profile
Jeongmin Yeo (Ethan)
좋은 습관을 가지고 싶은 평범한 개발자입니다.
이전 포스트

IBM Building Cloud Native and Multicloud Application 뱃지 취득 및 후기

다음 포스트

IBM Introduction to Containers, Kubernetes, and OpenShift 뱃지 취득 후기

0개의 댓글