Kubernetes - Core Concept(1)

developowl·2026년 2월 6일
ckakubernetes

Kubernetes

목록 보기
1/2
post-thumbnail

Mumshad Mannambeth 님의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의를 들으며 정리한 내용들입니다.
Udemy Mumshad님- CKA 강의 들으러 가기

CKA 준비를 하며, 쿠버네티스를 기초부터 다지려고 합니다. 우선 이번 내용에서는 쿠버네티스의 핵심 개념들과 아키텍처를 알아보겠습니다. 아래의 사진은 이번 포스트에서 다루는 쿠버네티스 아키텍처 요소들입니다. 참고히시면 좋을 것 같습니다.

8. Cluster Architecture

Master Nodes (Control Plane)

  • Manage, Plan, Schedule, Monitor Nodes

    [ETCD Cluster]

    • 클러스터에 대한 정보를 저장하는 클러스터

      [kube-scheduler]

    • 노드에서 애플리케이션 또는 컨테이너의 스케줄링을 담당하는 스케줄러

      [Controller-Manager]

    • Node-Controller

    • Replication-Controller

      [kube-apiserver]

    • 클러스터 내의 모든 작업을 오케스트레이션 하는 API 서버

Worker Nodes

  • Host Application as Containers

    [kubelet]

    • kube API 서버의 지시를 수신하고 필요에 따라 노드에 컨테이너를 배포하거나 삭제함(컨테이너 관리).

      [kube-proxy]

    • 클러스터 내 서비스(Worker Node) 간의 통신

    • 워커 노드에서 실행 중인 컨테이너가 서로 연결될 수 있도록 필요한 규칙이 워커 노드에 적용되도록 함.

Container Runtime Engine

  • Docker, Containerd, rkt

9. Docker-vs-ContainerD

CRI(Container Runtime Interface)

  • 모든 벤더가 OCI 표준을 준수하는 한 Kubernetes의 컨테이너 런타임으로 작동할 수 있도록 허용

OCI(Open Container Initiative)

  • imagespec
  • runtimespec

11. ETCD For Beginners

Distributed reliable key-value store

  • 분산형 신뢰 키-값 저장소
  • 기본 포트는 2379번(클라이언트와 통신을 위한)
    • etcd 멤버간 통신에는 2380 포트 사용
  • TLS 암호화가 걸려 있음

12. ETCD in Kubernetes

ETCD Cluster에 저장되는 정보들

  • Nodes
  • PODs
  • Configs
  • Secrets
  • Accounts
  • Roles
  • Bindings
  • Others

ETCD 설치 방법

  1. 수동 설치(Manual)

    • 바이너리 etcd를 설치
    • 설정해야하는 것들이 많음

  2. kubeadm 사용

    • etcd-master Pod 내에서 동작

13. ETCD - Commands (Optional)

etcdctl 은 etcd를 cli 환경에서 사용할 수 있게 하는 명령어

  1. API Version 3 (필수)

    • 쿠버네티스 데이터는 V3 구조로 저장되어 있기 때문에, export ETCDCTL_API=3 을 하지 않으면 데이터를 제대로 읽을 수 없음

  2. 인증서(--cacert, --cert, --key)가 필요한 이유

  • etcd는 클러스터의 모든 기밀과 정보를 담고 있는 중요한 금고이다
  • 아무나 열어볼 수 없도록 TLS 암호화가 걸려 있기 때문에, 인증서 파일들을 명령어와 함께 전달해야 한다.

14. Kube-API Server

클러스터를 변경하기 위해 수행해야 하는 모든 작업의 중심에는 kube api-server 가 있음.

  • 보안 창구: API 서버가 중간에 권한 확인을 하며 문지기 역할을 함
  • 데이터 정제: 유효성 검사를 하여 etcd에는 오직 올바른 데이터만 저장되게 함

흐름

  1. Authenticate User - 사용자 인증
  2. Validate Request - 요청 유효성 검사
  3. Retrieve data - API 서버가 ETCD에서 데이터를 가져오는 단계
  4. Update ETCD - ETCD 업데이트. 사용자에게 업데이트 되었음을 알림
  5. Scheduler
  6. Kubelet - kube api server 지시 수신. 노드에 컨테이너를 배포/삭제
  • kube API 서버는 etcd 데이터 저장소와 직접 상호 작용하는 유일한 구성 요소
  • 스케줄러, 컨트롤러, 관리자 및 kubelet 과 같은 다른 구성 요소는 API 서버를 사용하여 각 영역에서 클러스터의 업데이트를 수행

15. Kube Controller Manager

클러스터의 현재 상태를 끊임없이 감시(Watch)하고, 사용자가 원하는 상태(Desired State)와 다를 경우 이를 일치시키기 위해 조치를 취하는 관리자들의 집합체

  • 단일 프로세스에 패키징

역할

  • Watch Status - 상태 감시
    • api server 를 통해 사용자가 원하는 상태(Desired State)와 현재 돌아가고 있는 실제 상태(Current State)를 계속 비교
  • Remediate Situation - 상황 개선/조치
    • 차이를 발견하면, 컨트롤러 매니저는 그 차이를 메우기 위해 즉시 조치를 취함

구성

  • Node-Controller - 노드의 상태를 체크하고, 노드가 죽으면(Unreachable) 대응함
  • Replication-Controller - 파드의 복제본 개수가 설정값과 일치하는지 항상 확인하고 유지함
  • Deployment-Controller - 파드의 배포와 업데이트(Rolling Update)를 관리함
  • Endpoint-Controller - Service와 Pod를 연결해주는 다리(Endpoints)를 관리함
  • Namespace-Controller - Namespace 가 삭제될 때 그 안의 자원들을 깨끗이 정리함

Node-Controller

노드 장애 대응 컨트롤러

시간 옵션

  • Node Monitor Period - 5s
    • 노드를 모니터링 하는 주기
  • Node Monitor Grace Period - 40s
    • 노드가 연결되지 않음(NotReady or Unknown)으로 처리되기까지의 대기시간
  • POD Eviction Timeout - 5m
    • Unreachable 일 때, 재연결까지 5분의 시간을 줌
    • 5분 초과 시 해당 노드에 할당된 파드 제거 & 정상 노드에 프로비저닝

Replication-Controller

Desired State(약속했던 수) Pod 수 지킴이 컨트롤러

16. Kube-Scheduler

어떤 노드에 어떤 파드를 배치할지 결정하는 역할만 담당

  • (실제 노드에 파드를 배치하지는 않음) → 해당 작업은 kubelet의 작업

스케줄러가 파드에 가장 적합한 노드를 식별하는 과정

  1. Filter Nodes - 필터링
    • 파드의 프로파일에 맞지 않는 노드를 필터링 하려고 시도
      • 프로파일 - Resource Requests, Node Selector, Taints & Tolerations 등
  2. Rank Nodes - 순위 매기기
    • 남은 노드에 순위를 매김
    • 우선순위함수(Priority Function) 사용 → 0 ~ 10점 부여
  3. Binding - 바인딩
    • 점수를 매긴 후 가장 높은 점수를 받은 노드가 결정되면, 스케줄러는 그 결과를 API 서버에 보고함
    • API 서버는 해당 정보를 etcd 에 업데이트 하는데, 이 과정을 Binding 이라고 함

→ 이 작업들이 끝나야 비로소 워커 노드의 kubelet 이 작업을 시작

Priority Function

  • Least Request
    • Pod 배치 후 남은 리소스가 가장 많은 노드에 높은 점수를 부여
    • Pod 들이 골고루 퍼짐 → workload distribution
  • Most Requested
    - 비용 절감에 유리
    - Bin Packing

17. kubelet

마스터 노드의 명령을 받아 워커 노드에서 실제 컨테이너를 가동하고 관리하는 현장 관리 소장 역할

워커 노드의 kubelet 이 하는 일

  • Register Node - 노드를 k8s 클러스터에 등록
  • Create PODs - 파드 생성
    • kubelet이 직접 컨테이너를 만드는 것은 아님!
    • kubelet은 설계도(PodSpec)를 확인하고, 실제 작업은 노드에 설치된 Docker, containerd 에게 요청함
  • Monitor Node & PODs - 노드와 파드의 상태를 지속적으로 kube api server에 보고

*주의: kube-admin 을 사용하여 클러스터 배포 시, kubelet은 자동으로 배포되지 않음.

  • 사용자가 미리 노드에 수동으로 설치(apt-get 등) 해두어야 함

18. Kube-proxy

모든 노드에 상주하며 Service IP ↔ 실제 Pod IP 를 연결하는 네트워크 규칙(iptables) 을 관리하는 역할

  1. 배경: Pod Network 의 한계

    • Pod Network: 클러스터 내 모든 파드는 서로 통신이 가능하다. (CNI 솔루션 덕분)
    • 문제점: 하지만 파드는 일시적(Ephemeral)이다. 죽었다가 살아나면 IP가 변하기 때문에 특정 파드 IP를 고정해서 믿고 사용할 수 없음

  2. 해결책: Service 라는 추상화

    • 개념: 변하지 않는 가상의 대표 번호(Cluster IP)를 부여
    • Label & Selector: 서비스는 파드의 IP 가 아니라 Label 을 보고 대상을 찾음. 파드 IP가 바뀌어도 이름표만 그대로라면 서비스는 항상 해당 파드를 찾아낼 수 있음

  3. 실무자: Kube-proxy 의 역할

    • Service 는 ‘논리적 정의’일 뿐 실제 데이터를 처리할 능력이 없음.
    • 이때 Kube-proxy 가 필요
    • 정보 수집 : API server 를 감시하다가 새로운 Service 가 생기면 정보를 즉시 수집
    • iptables : 각 워커 노드의 커널 네트워크 규칙(iptables 등)에 대표 번호로 오는 신호는 실제 파드 IP로 보내라는 이정표를 세움
    • 결과 : 사용자가 Service(대표 번호)로 접속하면, 노드의 입구에서 kube-proxy 가 만든 규칙에 의해 실제 살아있는 파드로 Forwarding 됨

profile
developowl
Don’t get mad at the computer.
다음 포스트

쿠버네티스 공식 문서에 기여하는 법(한글화 기여)

0개의 댓글