Cloud Native/K8s

k8s 이론: 개요

lys4321 2026. 2. 23. 16:24

k8s 란?

컨테이너화된 워크로드와 서비스를 관리를 위한 이식과 확장이 용이한 오픈소스 플랫폼이자 컨테이너 오케스트레이션 도구

k8s의 특징

1. 자가 치유 및 자동화 (Self-Healing & Automation)

  • 상태 유지: 사용자가 원하는 상태를 선언한 파일인 YAML를 사용하여 k8s가 YAML 파일에 선언한대로 지속적으로 감시
  • 자동 복구: 컨테이너가 응답하지 않거나 노드에 장애가 발생하면, 즉시 새로운 컨테이너로 교체하거나 재시작하여 중단 없는 서비스를 유지

2. 서비스 디스커버리 및 로드 밸런싱

  • 자동 노출: 컨테이너에 자체 IP나 DNS 이름을 부여하여 외부에서 접근하도록 유도
  • 부하 분산: 네트워크 부하를 여러 컨테이너에 골고루 배포하여 애플리케이션의 안정성을 보장

3. 무중단 롤아웃과 롤백

  • 버전 관리: 서비스 중단 없이 새로운 버전의 컨테이너를 순차적으로 rollout(배포)
  • 즉시 복구: 업데이트 중 문제가 발생하면 이전 버전으로 즉시 rollback(되돌리기)

4. 효율적인 자원 관리 (Bin Packing & Scaling)

  • Bin 패킹: 가용 자원(CPU, 메모리)에 맞춰 컨테이너를 적합한 노드에 자동으로 배치
  • 수평 확장: 트래픽 양이나 자원 사용량에 따라 컨테이너 개수를 동적으로 변경하여 비용을 절약

5. 유연한 스토리지 및 구성 관리

  • 스토리지 오케스트레이션: 로컬 저장소나 클라우드 스토리지 등 다양한 저장 시스템을 필요에 따라 컨테이너에 자동 연결
  • 시크릿 관리: 비밀번호나 API 토큰 같은 민감 정보를 이미지 수정 없이 별도로 안전하게 관리하고 배포

k8s 컴포넌트

기본적인 k8s 컴포넌트 구성은
k8s 클러스터안에 Control plane과 그와 연결된 1...N개의 Worker Node가 연결되어 있음
또한 추가적으로 k8s 클러스터 밖에 Cloud Provider가 존재하면
Control Plane 내 CCM이 생성되고 Cloud Provider API를 통해 통신하게 됨

 

  • Control Plane
    • Cloud Controller Manager(CCM)
      • 기본 클라우드 공급자와 통합
    • Controller Manager(kube-controller-manager)
      • 컨트롤러를 실행해 k8s API 동작을 구현
    • etcd
      • 모든 API 서버 데이터를 위한 일관성, 고가용성 기능을 갖춘 키-값 저장소
    • API Server(kube-apiserver)
      • k8s HTTP API를 노출하는 서버 컴포넌트
    • Scheduler(kube-scheduler)
      • 아직 노드에 할당하지 않은 파드를 찾아 노드에 할당
  • Woker Node
    • kubelet
      • 파드와 그 안의 컨테이너가 실행 중임을 보장
    • kube-proxy
      • 노드에서 네트워크 규칙을 유지하여 서비수 구현
    • 컨테이너 런타임
      • 컨테이너 실행을 담당하는 SW

k8s 오브젝트란?

k8s 시스템의 영속성을 가진 엔티티, k8s는 이런 엔티티를 이용해 클러스터의 상태를 나타냄

k8s 오브젝트 예시

  • 어디 노드에서 어떤 컨네이너가 무슨 애플리케이션을 실행하는지에 대한 정보
  • 애플리케이션이 사용할 수 있는 리소스
  • 애플리케이션이 어떤 환경에 처했을 때 어떻게 돌아갈 것인지에 대한 정책
  • 종합 : 상태, 방법, 의도 등의 정보들을 총칭하는 의미

k8s 오브젝트 명세(spec)과 상태(status)

  • 명세(spec)는 오브젝트 생성 시, 설정하며 리소스에 원하는 특성에 대한 설명을 제공해야 하는데, 이를 목표로 삼은 상태(Desired State)라 함
  • 상태(status)는 k8s 시스템과 컴포넌트가 제공하고 업데이트하는 오브젝트의 현재 상태
  • k8s의 컴포넌트인 Control Plane은 모든 오브젝트의 실제상태(현재 상태)가 목표로 삼은 상태(Desired State)와 일치하도록 지속적으로 확인하여 관리

k8s 매니페스트

  • k8s API를 사용해 오브젝트 생성 시, 해당 요청은 JSON형식으로 내용을 작성하며 대부분 매니페스트라는 YAML이나 JSON확장자 파일로 작성한 정보를 제공한다.
  • 필수 필드
    • apiVersion : 오브젝트를 생성 시, 사용하는 k8s API 버전
    • kind : 생성하려는 오브젝트 종류
    • metadata : name, UID 및 namespace 등을 포함하여 오브젝트를 고유하게 식별하는데 필요한 데이터
    • spec : 오브젝트에 대해 원하는 상태

k8s 오브젝트 이름과 ID

  • 클러스터의 각 오브젝트는 해당 유형의 리소스에 대해 고유한 이름을 가지고, 모든 k8s 오브젝트는 전체 클러스터에 대해 고유한 UID를 가짐
  • 이름(name)
    • 리소스 URL에서 오브젝트를 가리키는 클라이언트 제공 문자열
    • 특정 시점에 같은 종류에서 하나의 이름은 하나의 오브젝트에만 지정 가능하며 오브젝트 교체는 가능
    • API 버전과는 상관없이 동일한 리소스에서 이름은 고유해야 한다.
  • UID(UUID)
    • 오브젝트를 중복없이 식별하기 위한 k8s 시스템이 생성하는 문자열
    • 고유하다(마치 DB의 PK)

k8s 오브젝트 레이블과 레이블 셀렉터

  • 레이블(label)
    • k8s 오브젝트에 첨부된 키-값 쌍이며 k8s 오브젝트의 특성을 식별하는데 사용되어 사용자에게 의미있는 내용이지만 핵심 시스템에 대한 의미를 가지진 않는다.
    • 오브젝트 하위 집합을 구성하고 선택하는데 사용
    • 오브젝트 생성 시 첨부하며 이후 추가 및 수정이 가능
    • 오브젝트마다 label 정의가 가능하며 오브젝트의 키는 고유해야한다.
  • 레이블 셀렉터(label selector)
    • 레이블은 고유하지 않기 때문에 이를 식별하기 위해 사용하는 그룹화 요소
    • 일치성 기준 요건(Equality-based Selector)
      • 일치, 불일치로 레이블 키와 값을 필터링
      • =, != 연산자만 허용
    • 집합성 기준 요건(Set-based Selector)
      • 집합 여부 기준으로 키와 값을 필터링
      • in, notin, exists 연산자만 지원

k8s 오브젝트 네임스페이스

  • k8s에서 단일 클러스터 내에서 리소스 그룹을 격리 기술을 제공
  • 리소스의 이름은 네임스페이스 내에서 유일해야 함
  • 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트인 Deployment, Service 등에서만 적용이 가능
  • 기본 네임스페이스 구성
    • default : 기본으로 설정된 네임스페이스
    • kube-node-lease : 노드 Lease 오브젝트 저장용 네임스페이스
    • kube-public : 모든 클라이언트가 읽기 권한으로 접근 가능한 네임스페이스
    • kube-system : k8s 시스템에서 생성한 오브젝트를 위한 네임스페이스
  • 핵심기능
    • 리소스 이름 충돌 방지
    • 클러스터 자원을 리소스 쿼터(Quota)(리소스 스펙 제한)을 통해 여러 사용자 사이에서 나누는 방법

k8s 오브젝트 어노테이션

  • k8s 오브젝트에 임의의 비식별 메타데이터를 오브젝트에 첨부할 수 있는 방법
  • 도구나 라이브러리 같은 클라이언트는 이 메타데이터를 통해 검색이 가능해진다.
  • 키-값 맵 구조를 가지고 키와 값은 문자열이여야 함
  • 오브젝트를 식별하고 선택하는데 사용이 되지 않음
  • 어노테이션은 시스템이 자동 설정하는 값들과 충돌하지 않고 원하는 정보를 따로 보관하기 위한 공간
  • 레이블은 그룹화를 하기 위한 용도와 시스템 동작에 영향을 미치지만 어노테이션은 명시를 하기위한 용도이고 시스템 동작에 영향을 미치지 않는다.
  • 어노테이션이 명시하는 데이터
    • 빌드, 릴리스, 이미지 관련 정보
    • 로깅, 모니터링, 감시 시스템을 위한 정보
    • 디버깅을 위한 클라이언트 및 도구 정보
    • 출처 정보
    • 경량 롤아웃 도구의 메타데이터
    • 매뉴얼 및 문의 정보

k8s 오브젝트 필드 셀렉터

  • 한 개 이상의 리소스 필드값에 따라 k8s 오브젝트를 선택하기 위해 사용된다.
  • 레이블 셀렉터는 레이블을 가지고 검색하지만 필드 셀렉터는 필드로 검색
  • =, != 연산자만 지원하고 조합(AND) 조건(,)으로 필터링 가능

k8s 오브젝트 파이널라이저

  • k8s가 오브젝트를 완전히 삭제하기 전, 삭제 표시를 위해 특정 조건이 충족될 때까지 대기하도록 알리기 위해 Namespace에 속한 키
  • 파이널라이저를 사용할 시, 리소스를 삭제하기 전에 특정 정리 작업을 수행하도록 컨트롤러에 경고하여 리소스의 가비지 컬렉션을 제어
  • 매니페스트 파일로 리소스를 생성하는 방법일 시, metadata.finalizers 필드에 파이널라이저를 명시할 수 있다.
  • 파이널라이저의 작동 방식
    • 리소스 삭제 요청이 API 서버로 들어옴
    • API 서버가 finalizer 필드의 값을 인식함
    • 삭제를 시작한 시각과 함께 metadata.deletionTimestamp 필드를 오브젝트에 추가
    • 오브젝트의 metadata.finalizers 필드가 비워질 때까지 오브젝트가 제거되지 않도록 방지
    • 이 파이널라이저를 관리하는 컨트롤러에게 202 상태 코드를 응답
    • 컨트롤러는 그 리소스에 지정된 파이널라이저의 요구를 충족하려고 시도하고 요구가 충족될 때마다 리소스의 finalizers 필드에 해당 키를 제거
    • 필드가 지워진다면 deletionTimestamp필드가 설정된 오브젝트는 자동으로 삭제

k8s 오브젝트 소유자와 종속자(Owner and Dependents)

  • k8s에선 어떤 객체가 다른 객체의 Owner가 될 수 있다는 개념
  • 레이블의 개념과는 별개의 개념
    • 레이블과 레이블 셀렉터는 리소스를 그룹화 하고 그룹을 식별/선택하는데 사용이 됨
    • 소유자와 종속자는 그저 부모-자식 관계를 명시하는데 사용됨
  • metadata.ownerReferences 필드를 통해 누가 이 리소스의 부모인지를 명시
    • 해당 필드에는 부모의 name, UID 정보를 가져야하고 부모와 자식 둘 다 같은 Namespace에 있어야함
  • 소유자와 종속자 관계와 파이널라이저의 관계
    • 리소스 삭제 시, k8s는 해당 리소스의 파이널라이저가 있는지 그리고 종속리소스(ownerReference)가 있는지 체크
    • 포그라운드 케스케이딩 삭제 방식에선 부모 삭제 전, 자식 리소스가 모두 삭제되거나 블록 조건이 해제되어야 함
  • 삭제 옵션 및 연쇄 삭제
    • 사용자는 부모를 삭제 시, 자식들을 함께 삭제할지, 아니면 유지할 지 propagationPolicy 옵션을 사용해 설정이 가능
      • Background : 부모가 먼저 삭제가 되고 자식 삭제
      • Foreground : 부모가 먼저 삭제 표시(deletionTimestamp)되고 자식이 삭제가 될 때까지 대기

k8s 오브젝트 권장 레이블

  • 기능적인건 아니고 k8s에서 권장하는 레이블 구조
  • 레이블
    • app.kubernetes.io/name : 애플리케이션 이름(예 : mysql)
    • app.kubernetes.io/instance : 애플리케이션의 인스턴스 식별 이름(예 : mysql/abcd)
    • app.kubernetes.io/version : 애플리케이션의 현재 버전(예 : 5.3.22)
    • app.kubernetes.io/component : 아키텍처 내 구성요소(예 : database)
    • app.kubernetes.io/part-of : 이 애플리케이션의 전체 이름(예 : wordpress)
    • app.kubernetes.io/managed-by : 애플리케이션의 작동을 관리하는데 사용되는 도구명(예 : Helm)

k8s API란?
kube-apiserver에게 보내는 k8s 오브젝트 상태를 쿼리하고 조작하기 위한 요청

k8s API를 사용하는 이유

  • 모든 명령, 상태조회, 리소스 생성은 kube-apiserver를 통해 이뤄지기 때문에 원하는 요청을 보내기 위하여 사용
  • API는 RESTful 구조로 설게되어 HTTP 요청으로 리소스를 CRUD 가능

k8s API의 구조와 버전

  • k8s API 는 여러 그룹으로 나눠짐
    • core/v1(기본그룹)
    • batch/v1
    • rbac.authorization.k8s.io/v1 등
  • 그룹과 버전을 통해 API 경로가 정해진다.(예 : /api/v1, api/v2)
  • 서로 다른 버전이 동일한 리소스의 표현을 제공
    • '서로 다른 버전이 동일한 리소스의 표현' 이란
      • 같은 리소스(예 : Deployment)라도 여러 API 버전(예 : apps/v1beta1, apps/v1) 을 제공
  • API 안정성 수준
    • 안정(stable) : 안정된, 장기 호환성 보장하는 버전
    • 베타(Beta) : 실험적/새기능이 포함된 버전
    • 알파(Alpha) : 심화적으로 실험적인, 진짜 완전 실험적

k8s API와 데이터 저장과 직렬화

  • k8s는 오브젝트 상태를 etcd에 저장하는데 API 서버가 여기를 읽고 쓰는 중앙 허브 역할함
  • API 오브젝트는 OpenAPI 스펙을 통해 정의됨
  • 내부적으론 Protobuf 직렬화 형식을 사용해 클러스터 내부 통신을 효율화

k8s API 확장성

  • 커스텀 리소스(Custom Resource Definition, CRD)를 통해 사용자 정의 API 타입을 k8s 클러스터에 추가 가능
  • API Aggregated레이어를 사용해 별도의 API 서버를 연결 가능

k8s API 접근과 보안

  • API를 사용하기 위해서는 인증과 인가를 거쳐야함
  • k8s는 여러 클라이언트 라이브러리를 제공
  • 파드 내부에서도 API에 접근이 가능(파드 내에서 클러스터 정보를 읽거나 조작할 때 유용)

'Cloud Native > K8s' 카테고리의 다른 글

k8s 이론: 구성  (0) 2026.02.23
k8s 이론: 스토리지  (0) 2026.02.23
k8s 이론: 서비스, 로드밸런싱, 네트워킹  (0) 2026.02.23
k8s 이론: 워크로드  (0) 2026.02.23
k8s 이론: 아키텍처  (0) 2026.02.23

'Cloud Native/K8s'의 다른글

  • 현재글k8s 이론: 개요

관련글

티스토리툴바