개요

도커에 이미지를 빌드하기 위해서 도커파일에 명세를 정의하고 빌드한다.

이미지 파일을 통해 패키징 시켜서 프로그램을 배포를 하게 되는데

도커는 기본적으로 하나의 서버에서만 동작한다.

추후 규모가 커지게되면 하나의 서버에서만 동작시킬 수 없고, 여러개의 서버를 묶어서 하나의 시스템인 것 처럼 사용하는데 그것을 클러스터라고 한다.

클러스터에 필요한 컨테이너를 배포를 하고 배포가 된 컨테이너들이 문제없이 실행될 수 있

도록 조절해주는데 모니터링도하고 문제가 생겼을때 다시 원래 상태로 회복시켜주는 기능도 한다.

이것들을 오케스트레이션 이라고한다.

쿠버네티스란?

  • 오픈소스
    • 필요하면 코드레벨까지 확인이 가능하다.
    • 동작하는 매커니즘, 답답한 부분을 low-level까지 확인할 수 있다!!
  • 컨테이너 관리
    • 컨테이너를 격리시켜주는 기술
      • namespace
        • 하나의 시스템에서 프로세스를 격리시킬 수 있는 가상화 기술
      • cgroup
        • CPU, 메모리, network bandwith, HD i/o 등 프로세스 그룹의 시스템 리소스 사용량을 관리한다. 어떤 애플리케이션의 리소스 사용량이 많다면 그 애플리케이션을 Cgroup에 넣어서 CPU와 메모리 사용 제한 가능.
  • 자동화
    • GitOps
      • git에 원하는 명세 파일을 가져다 놓으면 쿠버네티스에 추가적으로 설정되어 있는 엔진이 내가 선언한 부분을 원하는 상태를 맞춰주기 위해 자동으로 동작한다.
  • 선언적 구성
    • 내가 원하는 상태를 정의를 하면 쿠버네티스 클러스터는 정의한 상태를 맞추려고 내부적으로 수행한다.
    • 원하는 상태를 명령어를 치면서 구성하는 것이 아닌 명세를 파일로 정의 하고 파일을 api호출을 이용해서 실행을 하게되면 클러스터가 맞춰주는 작업을 한다.
  • 명령형 구성
    • 명령어를 통해서 작업이 가능

쿠버네티스 객체의 두 가지 요소

쿠버네티스는 크게 2가지 객체로 존재한다.

쿠버네티스 객체

  • 클러스터 상태를 나타내는 영구항목
    • 객체 사양
      • 사용자가 정의한 바람직한 상태
    • 객체 상태
      • 쿠버네티스가 나타내는 현재 상태

쿠버네티스 아키텍처

여러 개의 서버를 묶어 하나처럼 동작하는것 → 클러스터

https://kubernetes.io/ko/docs/concepts/overview/components/

  • 클러스터
    • 제어영역(컨트롤 플레인)
      • 노드(데이터 플레인)
      • 노드(데이터 플레인)
      • 노드(데이터 플레인)
  • 위와 같은 형태로 구성되어있다.
  • 노드에 문제가 생기면 떠 있는 노드 중 어딘가에 하나를 더 띄운다.
  • 노드 자체를 회복시키는 것은 쿠버네티스의 영역은 아니다!
    • 클라우드를 쓰는 이유 중 하나
      • 노드가 문제가 생겼을때 회복시키는 능력이 필요!
  • 컨트롤 플레인이 죽으면 끝이나기 때문에 2중화 3중화 같은 것들이 필요하다.
  • 사용자는 작업을 kubuctl을 통해서 컨트롤 플레인에게 api 호출만 해주면 된다. 실제 컨테이너가 동작하는 위치는 노드의 파드 단위로 배포되어 동작한다.

컨트롤 플레인

  • kube-APIserver
    • 클러스터의 모든 명령을 수락하는 진입점
  • etcd
    • 클러스터의 상태를 안정적으로 저장하는 역할(키밸류형태로 저장)
  • kube-scheduler
    • 파드를 노드에 예약하는 역할
    • 파드를 분산하고 어디에 배포하면 좋을지 정해주는 역할
  • kube-controller-manager
    • 상태를 지속적으로 모니터링하고 바람직한 상태를 달성하기 위해 변경을 시도
  • kube-cloud-manager
    • 클라우드 제공업체와 상호작용하는 컨트롤러를 관리

노드

  • kubelet
    • 컨테이너 런타임을 사용하여 파드를 시작
  • kube-proxy
    • 클러스터의 파드 간에 네트워크 연결을 유지

왜 파드 단위로 배포를 할까?

  • 애플리케이션이 동작을 하고 있고 동작하면서 어떤 작업을 했는지 로그 등이 남는다고 했을때 다른 컨테이너는 로그를 전송해서 수집하는 작업을 할 수 있다.
  • 마치 파드를 가상의 서버 같은 것이라고 생각을 하면 된다.!
  • 공유된 스토리지를 할 수 있고, 통신을 별도의 인터페이스 없이 할 수 있다.

GCP 실습해보기

create cluster

  • Autopilot
    • 클라우드측에서 데이터 플레인 마저 숨기게 된다.
    • 띄운 파드만큼만 과금이 된다.
  • Standard
    • 클라우드측에서 컨트롤 플레인에 대한 부분은 숨겨놓는다. 접근 불가!
    • 접근 가능한 곳은 데이터 플레인
    • 노드당 과금이 일어난다.
    • 노드들을 사용자가 관리한다.
    • 파드가 떠있건 말건 노드가 떠있으면 과금이된다.

실습을 위해 스탠다드 선택!

location type

  • Zonal
    • zone
      • 쿠버네티스 클러스터 내에서 물리적으로 분리된 영역을 의미. 예를 들어, 클라우드 제공 업체(GCP, AWS 등)에서 제공하는 가용 영역(Availability Zone)과 비슷한 개념입니다. 하나의 클러스터 내에서 여러 개의 Zone을 사용하여 고가용성(High Availability)을 보장할 수 있다.
  • Regional
    • 컨트롤 플레인이 삼중화가 된다.
    • Region
      • 클러스터를 호스팅하는 물리적인 지역을 의미. 예를 들어, GCP의 us-central1, asia-northeast1 등과 같은 지역 개념. 여러 개의 클러스터를 하나의 Region에서 운영할 수 있으며, 이는 지리적으로 분산된 애플리케이션을 구성하는 데 유용하다.

노드가 3개가 뜬 것을 확인할 수 있다! 컨트롤 플레인은 보이지 않고 사용자는 컨트롤 플레인의 apiServer에게 명령만 할 수 있다.

SDN

  • **SDN(Software Defined Network)**이란 소프트웨어를 통해 네트워크 리소스를 가상화하고 추상화하는 네트워크 인프라에 대한 접근 방식을 의미한다.
  • 조금 더 쉽게 설명하자면, 소프트웨어 애플리케이션과 API를 이용하여 네트워크를 프로그래밍하고, 중앙에서 전체 네트워크를 제어하고 관리하는 것이다.

Pod

배포 가능한 가장 작은 쿠버네티스 객체

  • 공유된 네트워킹, 공유된 스토리지를 사용한다.
  • 마치 하나의 pc같다. 컨테이너는 프로그램(엑셀, 등등) 필요한 프로그램이 논리적인 단위로 묶여있는 형태

객체는 yaml 파일에 정의

  • 컨테이너를 띄우기 위한 정보 → 이미지
  • 엔진엑스를 가지고 Pod를 띄우겠다!
  • 내부적으로 이름을 가지고 객체를 구분한다.
    • 똑같은 이름의 Pod를 띄울 수 없음!
    • Pod를 몇개의 중복을 갖도록 지정하는 것을 Deployment라고한다.

파드 및 컨트롤러 객체

  • 컨트롤러 객체 유형
    • Deployment
      • 파드를 복제시켜 배포하는 형태
    • StatefulSet
      • 애플리케이션의 상태정보를 저장하기 위함
    • DaemonSet
      • 각 노드마다 하나씩 띄우고자 할때
    • Job

Deployment를 통해 Pod 집합이 실행되는지 관리

  • kind가 Deployment로 바꼈고, 배포되는 Pod는 3개로 맞춰달라는 명세이다.
  • 쿠버네티스는 숫자를 바꾸지 않는 한 3개로 Pod를 유지한다.
  • 유연한 scale-out 을 위해 등장한 객체가 Deployment이다.
  • 실제로 내부적으로 복제본을 유지하는 것은 ReplicaSet이다.

+ Recent posts

티스토리툴바