kubernetes 주요 구성 요소

  1. control plane
    • 객체의 생성, 수정, 삭제를 조정
    • k8s cluster 상태를 모니터하고 관리
    • 작업 부하 관리
    1. API 서버
      • REST API를 사용해 kubernetes 시스템과 상호작용함
    2. etcd
      • key-value database
      • API 서버는 staeless 방식이기 때문에 data 저장해 놓을 저장소가 필요함
      • 다른 구성 요소들은 etcd에 API 서버를 통해서만 접근 가능
    3. scheduler
      • app의 instance가 어디서 실행해야 하는지를 지시
      • kubernetes 관리자가 정의한 policy에 가장 적합한 work node를 선택
    4. 제어기
      • control plane에는 여러 개의 제어기가 있음 (ex. node 제어기)
  2. work nodes
    • application software를 hosting하는 node의 집합
    • control plane과 통신하기 위한 kubernetes 구성요소를 포함하여 실행
    1. kube proxy
      • node에서 실행 중인 app을 위한 네트워크 통신을 관리
    2. kubelet
      • 각각의 노드에서 실행 중인 일종의 agent
      • API server와 대화하여 node에서 실행 중인 앱을 관리하는 것
      • node의 상태를 수집하여 control plane에 API를 통해 전달
    3. container runtime
      • 앱을 hosting하며 kubelet이 관리하는 container를 실행하는 역할
      • kubernetes가 사용하는 CRI와 호환성이 있는 container runtime을 선택할 수 있음

앱의 실행을 위한 kubernetes 객체

  1. namespace
    • kubernetes 자원을 구분하는 방법
    • 다양한 팀과 동일한 cluster를 공유 가능
    • 다양한 설정, 네트워크 정책, 자원 할당량, 접근 제어 등을 유지
    • kubernetes 내 논리적 하위 cluster를 의미
  2. container image
    • 앱, 앱의 종속성, 운영체제 자원을 포함하고 있는 꾸러미
    • container image를 실행하고 있는 instance = container
  3. deployment
    • 배포 객체를 통해 container화 된 app을 추상화하여 복잡함을 감춤
    • cluster 안에서 앱에 대한 원하는 상태 정보를 포함
    • 원하는 상태가 달랐을 때 앱의 상태를 업데이트를 수행
    • 업데이트 : 복제, 삭제, 추가, 중지 등
  4. pod
    • kubernetes에서 앱을 실행하는 기본 단위
    • 가장 작은 스케줄러 작업 단위
    • 1개 pod 안의 container는 network와 disk 자원을 공유
  5. service
    • pod끼리의 network
      • 각각의 pod는 자신만의 사설 IP를 가지고, 재시작 시 주소 변경
    • kubernetes service는 하나의 추상화된 network 서비스로서 pod를 노출시킴
    • ex) reverse proxy : 실행 중인 여러 pod에 대해서 load balancing을 지원
  6. configmap, secret
    • 컨테이너 이미지를 통해 패키징한 앱을 다양한 환경에 배포했을 때, 환경(database 등) 관련 내용을 container image에 넣는 것은 안됨
    • 이러한 환경은 container image 외부에서 설정을 정의하여 container 실행 시 전달할 수 있어야함.
    • configmap, secret은 파일 or 환경변수의 형태로 pod에서 접근 가능
    • configmap : 설정 데이터를 저장하고 접근하기 위해 사용
    • secret : 암호, 사설 키 같은 민감한 설정에 사용

    1. deployment : app이 pod로 실행될 수 있도록 지원
    2. configmap : pod의 특수한 환경에 따른 설정 지원
    3. service : 배포된 pod를 마치 1개의 network service로 노출
  1. 저장소
    • pod는 일시적으로 존재하기 때문에, pod에 할당된 자원을 종료와 함께 사라짐
    • pod 내의 app은 보존이 필요한 데이터를 읽고 쓰기 위한 저장소가 필요함
    • kubernetes는 하드웨어 혹은 클라우드 서비스에서 배포되는데, 장소 상관없이 일관성 있는 저장소 자원 요청 방법이 필요함!

    • PersistentVolume (PV)
      • 물리적 저장소
      • 저장소 인프라에 대한 세부사항 포함
    • PresistentVolumeClaim (PVC)
      • PV를 가리키는 추상화된 객체
      • pod는 PVC를 인식하여 데이터를 저장하는 것
      • PVC는 PV와만 연결, pod는 PV를 모름 => 추상화

  2. ingress

    • k8s cluster 외부에서 pod에 접근이 필요한 경우에 사용
    • ingress는 cluster 외부에서 특정 서비스를 접근할 수 있도록 노출시키는 방법을 제공
    • service는 URL 사용하는 HTTP를 사용하여 표현
    • URL 접근시 SSL 사용 가능, cluster 내부에서 SSL 사용 불가 가능

kubernetes operator

  • 기존 IT 팀의 작업자들이 하는 일을 자동화하는 것

  • 지속적으로 kubernetes 환경에서 실행 중인 app을 모니터하고, 특정 구성 요소와 관련된 운영 작업을 수행

  • kubernetes app의 설치와 lifecycle을 관리하는 자동화된 소프트웨어 관리자

  • 다양한 kubernetes 객체들을 (사람이 생성하는 대신) operator가 생성, 수정함.

  • Custom Resource (CR) : operator가 수행할 특정 작업을 설정한 것

  • Custom Resource Definition (CRD) : CR의 구조나 스키마를 정의한 객체

  • operator의 app 운영 자동화 과정

  • ex) database의 instance를 관리하는 경우, 여러 pod들의 luster와 함깨 동작하도록 관리하는 경우

OLM(Operator Lifecycle Manager)

  • OLM을 통해 kubernetes operator의 설치와 관리를 간단하게 만들 수 있음
  • OLM에서 Operator 설치를 위한 단계
    1. deployment 생성
    2. operator 실행을 위한 권한 설정 (cluster 변화를 관찰해야하기 때문)
    3. CRD 생성
  • OLM과 operator는 k8s API (단일 표준 interface)만을 사용, 여러 operator의 lifecycle 관리 쉽게 만듬
  • OLM과 관련된 객체
    1. ClusterServiceVersion
      • operator의 metadata를 정의
      • metadata (설치, 필요한 권한 정보, operator 이름 및 version, CRD)
    2. Subscription
      • 사용자가 operator를 설치하고 업데이트할 수 있게 해줌
    3. OperatorGroup
      • Operator를 특정 namespace set과 연계해주는 기능을 제공
      • namespace가 없으면 OperatorGroup은 모든 namespace에서 전역적으로 동작