배경
회사에 장애가 발생했었을 때 K8s로 돌아가고 있는 서비스들에 대해 가설을 나눴는데 제가 K8s에 대한 기본적인 개념들과 지식들이 얕다보니 잘못된 이야기들을 하는 순간들이 있었습니다.
쿠버네티스를 공부하기 위해서 강의까지 구매 했었지만 바쁜 일정들이 있어 미뤄두고 있었고 그렇게 계속 미뤄지다가 결국 문제가 생겼을 때까지 미뤄지게 되었습니다.
입사한 지 오래되지 않았지만 경력 개발자로서 제대로 대처하지 못한 점이 큰 충격이었고 이를 계기로 쿠버네티스의 핵심 개념과 동작 원리를 정리하여, 유사한 문제가 발생했을 때 효과적으로 대응할 수 있도록 필수 개념을 숙지하려고 합니다.
기본 아키텍처
1. Control Plane
클러스터 중앙 제어 시스템과 같은 역활을 하는 노드로 클러스터의 전반적인 상태를 유지하고 괸리하는 역활을 합니다.
1.1. Control Plane의 구성 요소
- API Server: 쿠버네티스의 핵심 진입점으로 클라이언트의 요청을 받아 다른 컴포넌트와 상호 작용을 합니다.
- Scheduler: 새롭게 생성된 Pod를 어떤 노드에 배치할지 결정합니다. API Server에서 변경사항을 조회
- Controller Manager: 클러스터의 원하는 상태를 유지하기 위해 다양한 컨트롤러(ReplicaSet, Node Controller 등)를 관리합니다.
- etcd: 클러스터 상태 정보를 저장하는 분산 Key-Value 저장소입니다.
- Cloud Controller Manager: 클라우드 서비스와 통합을 담당하며, 클라우드 리소스와 쿠버네티스를 연결합니다.
2. Worker Nodes
- 컨테이너 런타임: 컨테이너 이미지를 받아 실행하는 역할을 합니다. 일반적으로 Docker, containerd, CRI-O와 같은 런타임이 사용됩니다.
- kubelet: 각 노드에서 실행되는 에이전트로, 컨트롤 플레인(API 서버)과 통신하면서 Pod와 컨테이너의 상태를 관리하고, 정의된 스펙에 따라 컨테이너가 올바르게 실행되도록 보장합니다.
- kube-proxy: 네트워크 프록시로, 노드 내에서 네트워크 트래픽을 관리하며, 클러스터 내부의 서비스 간 통신과 로드 밸런싱을 지원합니다.
쿠버네티스의 주요 개념
쿠버네티스의 핵심 아키텍처들을 알아봤으니 이제 주요 개념들을 알아보자. 이러한 주요 개념들은 쿠버네티스를 구성할 때 기본적으로 사용되는 개념들로 쿠버네티스를 사용하기 위해서는 최소 아래와 같은 개념들을 인지하고 이해하고 있어야지만 활용할 수 있습니다.
- 파드(Pod): 컨테이너화된 애플리케이션의 가장 작은 배포 단위로, 하나 이상의 컨테이너를 포함할 수 있습니다.
- 서비스(Service): 파드의 집합에 대한 네트워크 접근 방식을 정의하여, 로드 밸런싱과 안정적인 네트워크 엔드포인트를 제공합니다.
- 볼륨(Volume): 파드 내 컨테이너 간에 데이터를 공유하거나, 데이터를 영구적으로 저장하기 위한 스토리지 리소스입니다.
- 네임스페이스(Namespace): 클러스터 내 리소스를 논리적으로 구분하여, 여러 팀이나 프로젝트가 동일한 클러스터를 효율적으로 사용할 수 있도록 합니다.
전체 동작 과정
지금까지는 쿠버네티스의 전체적인 아키텍처와 주요 개념에 대해 알아봤습니다. 이제는 쿠버네티스로 서비스를 운용하면서 발생하는 네트워크의 흐름을 이해함으로써 이전에 설명한 핵심 아키텍처와 주요 리소스에 대한 전반적인 흐름에 대해 알아보려고 합니다.
클라이언트 요청 과정
- 클라이언트에 서비스에 요청이 전달되면 Kube Proxy에 해당 요청들을 전달합니다.
- Kube Porxy는 정의된 네트워크 규칙에 따라 적절한 Pod로 로드밸런싱 합니다.
kube-proxy의 Endpoints 정보 수집
- kube-proxy는 초기화 시 또는 Endpoints 정보에 변경 사항이 발생했을 때, API 서버로부터 최신 Endpoints 정보를 요청합니다.
- API 서버는 etcd(클러스터 상태 정보 저장소)에서 Endpoints 정보를 조회하여 kube-proxy에 전달합니다.
- kube-proxy는 받은 Endpoints 정보를 기반으로 iptables 또는 IPVS 규칙을 설정하여 로드밸런싱을 수행합니다.
Pod 상태 변경 시
- Pod가 추가되거나 삭제되는 등 상태 변화가 발생하면, Controller Manager는 API 서버에 Endpoints 객체의 업데이트를 요청합니다.
- API 서버는 etcd에 새로운 Endpoints 정보를 저장하고, 각 노드의 kube-proxy에 최신 정보를 전달합니다.
- kube-proxy는 새로운 Endpoints 정보를 기반으로 iptables 또는 IPVS 규칙을 재설정하여 로드밸런싱을 지속적으로 유지합니다.
정리
정리하자면 개발자나 데브옵스 엔지니어는 컨트롤 플레인을 통해 클서스터의 상태를 관리하고 유지하며 워커 노드를 통해 가상 컨테이너 환경을 구성하여 연결 합니다. 여기서 가상환경의 개념들 중 최소 단위를 Pod라고 불립니다. 여러 Pod가 뜨는 물리 또는 가상 환경을 노드라고 불립니다.
사용자가 Pod에 접근하기 위해서는 네트워크 접근 방식들이 정의된 서비스를 통해야 하며 노드 안에 구성된 Pod 클러스터끼리 데이터를 공유하거나 저장하기 위해 사용되는 것이 볼륨입니다. 이런 분산된 클러스터 환경에서 예를들어 하나의 마이크로 서비스나 하나의 시스템으로 논리적으로 묶어서 관리해야되는 경우가 발생하는데 이럴 때 활용할 수 있는 것이 네임스페이스 입니다.
'devops' 카테고리의 다른 글
수동 배포하기 (0) | 2023.03.09 |
---|---|
Nginx와 친해지기 (0) | 2023.03.08 |
Docker와 친해지기 (2) | 2023.03.02 |
CI/CD 스터디 (리눅스, AWS) (0) | 2023.02.26 |