시간 설정 확인

$ timedatectl

Asia/Seoul 시간대로 변경

$ sudo timedatectl set-timezone Asia/Seoul

쉽게 변환이 가능하다.

이미 쿠버네티스 클러스터 내에서 동작 중인 파드의 시간대가 변경됐는지 확인해야한다.

역시 파드에는 바로 적용되지 않는다.

파드를 삭제해서 다시 실행되도록 하거나, Deployment 에 환경 변수를 입력해서 변경 하는 방법을 추천 받았다. (클로드 형님)

우선 파드를 삭제하고 다시 확인해봤으나 파드 삭제 후 다시 생성돼도 적용되지 않는 것을 확인했다.

Deployment나 Pod의 YAML에서 환경변수로 설정:

env:
- name: TZ
  value: Asia/Seoul

이걸 모든 Deployment 에 다 해줘야한다고 하는데.. 이건 좀..

추천 받은 방법으로는

ConfigMap 생성

apiVersion: v1
kind: ConfigMap
metadata:
  name: tz-config
  namespace: default
data:
  TZ: "Asia/Seoul"

각 Deployment에서 참조

env:
  - name: TZ
    valueFrom:
      configMapKeyRef:
        name: tz-config
        key: TZ

라고 하는데..

결국 마찬가지 아닌가?

생각해보니 Jenkins 배포는 모두 deployment-template.yaml 을 공유하고 있기 때문에 이곳에 timezone 설정을 추가하고 재배포 하면 적용이 될 것으로 추정된다.

해당 부분을 추가하고 재배포를 진행

적용이 되어버렸다.!

The post 쿠버네티스 클러스터 GMT+09:00 적용 appeared first on .

경험상 뭔가의 프로젝트를 처음 진행할 때 첫번째 고민 포인트가 항상 이 부분 이었던 것 같다. 어떻게 분류해서 네이밍하고 전략을 세울 것인가? 고민이 되는 부분이기에 결정하게 된 과정을 간단하게 작성한다.

네임스페이스

먼저 네임스페이스에 대해 알아둘 필요가 있다. 공식 문서를 읽는 것은 달가운 일이 아니지만 읽지 않으면 많은 시간을 버리게 될 때가 있다. 공식 문서를 요약하면 아래와 같다.

• 클러스터를 다수의 사용자 그룹이 나눠서 사용 할 수 있도록 한다.
• 클러스터를 생성하면 초기 네임스페이스 default, kube-system, kube-public 3개가 있다.
• kube- 접두사는 쿠버네티스 시스템 네임스페이스로 예약돼 있으므로 이를 사용해 네임스페이스를 생성하지 않도록 한다.
• 네임스페이스는 유효한 DNS 레이블 이어야 한다.
  • 최대 63개 문자를 포함
  • 소문자 영숫자 또는 ‘-‘만 포함
  • 알파벳 문자로 시작
  • 영숫자로 끝남
• 네임스페이스를 삭제하면 내부의 모든 구성요소가 제거된다.
• 네임스페이스는 여러 개의 팀이나, 프로젝트에 걸쳐서 많은 사용자가 있는 환경에서 사용하도록 만들어졌다. 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는 네임스페이스를 전혀 고려할 필요가 없다. 네임스페이스가 제공하는 기능이 필요할 때 사용하도록 하자. (공식 문서 그대로 발췌)

그럼 언제 쓰라고?

결국 여러 개의 팀에서 많은 개발 인력이 있을 때야 비로소 네임스페이스 구분이 기능적으로 유의미 하다는 것. 다만 경험상 개인 프로젝트의 경우에도 최소한의 구분은 필요하다고 생각한다. 아래와 같은 이유로 나는 네임스페이스를 분리하기로 결정했다.

• 서비스 확장 가능성
  서비스 확장이 고려되지 않은 네이밍은 나중에 일을 피곤하게 만든다. 처음에 설계 과정에서 10의 노력이 필요했다면 구축이 완료된 후 고려하고 분리하기 위해선 3~40 이상의 노력이 들어간다고 느껴진다.
  
• 장애는 나의 적
  아무리 개인 프로젝트라 하지만 수정 즉시 배포될 때 장애가 발생하는 것은 참 불쾌한 일이다. 최소한 배포 서버 환경에서 테스트 해볼 수 있도록 구성하는게 그나마 장애 발생률을 줄일 수 있다.

어떻게 구분하나?

네임스페이스 공식 문서에 예시를 든 것은 development, production 으로 환경별 구분을 하여 사용한 예시가 나온다. 비교적 규모와 상관 없이 타당한 구분 방법이라고 생각된다. 네임스페이스를 구분하는 것에 정답은 없다. 프로젝트의 크기, 팀의 구성, 환경, 보안 요구사항, 자원 관리 등의 요소에 따라 집단에 맞게 생성하면 된다.

• 환경별 구분
  가장 흔한 네임스페이스 구분 방식으로, 각 환경마다 별도의 네임스페이스를 생성하여 자원들을 격리합니다. 이를 통해 환경별로 다른 구성과 설정을 적용할 수 있다.
  예시: development, staging, production, …
  
• 기능(도메인) 또는 애플리케이션별 구분
  프론트엔드, 백엔드, 데이터베이스와 같은 애플리케이션의 기능이나 도메인별로 네임스페이스를 구분할 수 있다. MSA 프로젝트의 경우 세부 도메인으로 나누는 것도 방법이지만 너무 세분화된 구분이 될 경우 관리 복잡도가 증가 할 수 있으므로 주의
  예시 : front-end, back-end, database, user-api, payment-api, …
  
• 프로젝트 또는 팀별 구분
  프로젝트 또는 팀 단위로 네임스페이스를 구분하여 리소스를 관리하는 방식. 여러 팀이 같은 클러스터를 사용하면서 각 팀의 리소스를 독립적으로 운영할 때 유용하다.
  예시 : team-user, team-payment, team-product, …
  
• 보안 및 권한 관리
  네임스페이스는 RBAC(Role-Based Access Control)과 같은 권한 관리를 용이하게 한다. 각 네임스페이스에 대해 접근 권한을 달리 설정하여, 민감한 자원에 대한 접근을 제한하거나 각 팀에 적합한 권한을 부여할 수 있다. 관리해야 할 권한이 많아지면 관리 복잡도가 많이 높아질 수 있다.
  
• 리소스 제한 및 할당
  네임스페이스별로 리소스 쿼터(Resource Quotas)를 설정할 수 있다. 이를 통해 각 네임스페이스가 사용할 수 있는 CPU, 메모리, 스토리지 등의 자원을 제한하고 관리할 수 있다. 특정 네임스페이스가 자원을 과다하게 사용하는 것을 방지할 필요가 있을 때 유용하다.
  

네임스페이스를 생성하는 전략은 이외에도 여럿 있을 수 있다. 자신이 진행할 프로젝트에 따라 전략을 세우고 생성, 관리하면 된다.

나는 환경별로 구분하여 생성하는 전략을 사용하려한다.

The post 네임스페이스 어떻게 구분할까 appeared first on .

고가용성은 시스템, 애플리케이션, 데이터베이스, 네트워크 등이 지속적으로 운영될 수 있도록 보장하는 것을 말한다. 장애나 오류가 발생해도 서비스가 중단되지 않고 최대한 연속성을 유지하는 시스템을 구축하는 것이 고가용성의 핵심이다. 일반적으로 가용성을 99.9% (3 9s, 99.999% : 5 9s)이상 유지하는 것을 목표로 하며, 이는 1년 중 약 8.77시간 이하의 다운타임을 허용하는 수준이다.

하지만 얻는 것이 있다면 잃는 것도 있는 법. 대체적으로 세상 많은 것이 완벽과 안전을 추구하면 그에 상응하는 비용이 든다(대표적 Trade-off 관계). 이번에 쿠버네티스 클러스터를 구축하며 어디까지 구현할 것인지 고민을 하게 된 순간이 많기에 겸사겸사 포스팅으로 내용을 남긴다.

고가용성 구축 방법

고가용성 시스템을 구축하는 데에는 몇 가지 일반적인 방법이 있다.

중복성 (Redundancy)

서버, 네트워크 장비, 데이터 저장소 등을 다중화하여 하나의 요소에 장애가 발생해도 다른 요소가 대신 처리할 수 있도록 한다.

장애 조치 (Failover)

한 시스템에 장애가 발생하면 자동으로 대체 시스템으로 전환하는 기능이다. 로드밸런서를 통해 다수의 서버로 트래픽을 분산시켜 특정 서버에 장애가 생겨도 트래픽을 다른 서버로 자동으로 전환할 수 있다.

무중단 유지보수 (Rolling Updates)

시스템이 가동 중인 상태에서도 소프트웨어 업데이트, 패치 등을 적용할 수 있게 하여 서비스 중단 없이 유지보수를 가능하게 한다.

데이터 복제 및 백업

중요한 데이터는 여러 곳에 복제하거나 정기적으로 백업하여, 데이터 손실이나 장애에 대비한다. 예를 들어, 데이터베이스는 Master-Slave 구조로 복제(Replication)하거나, 분산 파일 시스템을 사용하여 고가용성을 높일 수 있다.

고려해야 할 요소

고가용성을 추구할 때는 프로젝트의 규모와 필요성을 잘 판단하는 것이 중요하다. 모든 시스템에서 고가용성을 최대로 추구할 필요는 없기 때문이다.

프로젝트의 중요성

• 만약 서비스의 장애로 인한 금전적 손실이나 사용자 이탈이 심각한 경우 고가용성은 매우 중요하다. 예를 들어, 금융 서비스나 대규모 전자상거래 사이트는 몇 분의 다운타임도 큰 손실로 이어질 수 있다. ‘다운 타임으로 발생하는 비용이 고가용성을 추구하는데 드는 비용보다 큰가?’ 를 잘 따져봐야 할 것.
• 반대로 개발 환경이나 내부 시스템에서는 잠깐의 다운타임이 큰 문제가 되지 않기 때문에 고가용성을 위한 추가 비용과 노력을 들일 필요가 없다.

규모에 따른 고려

• 작은 프로젝트나 스타트업 단계에서는 모든 시스템을 고가용성으로 구축하는 것이 오버스펙이 될 수 있다. 초기에는 싱글 서버나 단순한 클라우드 인프라만으로도 충분히 운영 가능하다. 이런 상황에서 고가용성을 과도하게 추구하면 불필요한 비용과 시간이 소모된다.
• 반면 규모가 커지면서 서비스의 트래픽이 증가하거나 사용자가 많아지는 시점에서는 고가용성을 점진적으로 도입하는 것이 바람직하다. 이때 로드밸런서, 이중화된 서버, 분산 스토리지 등의 도입을 고려해야 한다.

내가 구축하려는 시스템은 포트폴리오와 지극히 개인적으로 사용할 웹 서비스이다보니 이 부분에 대한 고민이 많아졌다. 고려 지점을 토대로 추구 정도를 결정하게 됐다.

고가용성 추구 정도

고가용성을 구축할 때는 당연히 추가적인 시간과 비용이 들어간다. 내가 진행하는 프로젝트의 규모에 따라 시간과 비용을 어느정도까지 소모 할 것인지 잘 따져봐야 한다.

복잡한 인프라

• 고가용성을 위해 시스템을 이중화하거나 다중화하면, 인프라 관리가 더 복잡해진다. Failover 설정, 데이터 복제, 네트워크 구성 등 다양한 부분을 신경 써야 하기 때문에, 시스템 운영 비용이 증가한다.
• 특히 다중 노드, 클러스터, 로드밸런서를 관리하려면 전문 지식이 필요하고 인프라 설정의 복잡성이 커진다.

비용 증가

• 고가용성 시스템을 구축하려면 추가적인 하드웨어, 클라우드 리소스, 소프트웨어 라이선스가 필요하다. 예를 들어 여러 대의 서버, 이중화된 네트워크 장비, 스토리지 공간 등을 확보해야 하기 때문에 비용이 크게 증가할 수 있다.
• 클라우드 환경에서는 자동 스케일링, 로드밸런서, 데이터 복제 서비스 등이 추가 비용을 발생시킨다. 규모가 클수록 비용 부담이 커진다.

개발 및 배포 속도 저하

• 고가용성 시스템을 유지하면서 새로운 기능을 개발하고 배포하려면 무중단 배포를 해야 하고, 이를 위해서는 별도의 배포 전략과 테스트 절차가 필요하다. 이는 개발 속도에 영향을 미치고, 배포 주기가 길어질 수 있다.
• 또한 시스템 변경 사항을 테스트하기 위해 고가용성 환경에서 테스트 인프라를 추가적으로 구성해야 할 수도 있다. (결국 또 돈)

결론

개인적으로 고민 됐던 것은 이후 노드를 늘리게 되면 다중 마스터노드 구성을 해야할 것 같은데, 처음부터 구성하고 시작할까? 그렇다면 앞단에 로드밸런서가 필요한데? 로드밸런서를 노드 중 1대에 할당한다면 결국 그 노드가 단일 장애 지점(Single Point of Failure, SPOF)이 아닌가? 나중에 추가하려면 일이 더 피곤해지는데? 클라우드에 로드밸런서를 이용할까? 돈 아까운데? 같은 고민의 연속이었다.
다녔던 회사에선 비용보단 고가용성에 큰 비중을 뒀기 때문에 너무 큰 비용과 시간 손실이 나지 않는다면 고가용성을 추구했으며 이에 대해 논의 할 사람들이 있었지만 지금은 혼자 모든 결정을 하기 때문에 더 답을 내리기 어려운 것 같다.

결국 내가 내린 결론은 고가용성은 시스템의 안정성과 신뢰성을 보장하지만, 모든 프로젝트에 적용할 필요는 없다. 작은 규모의 프로젝트에서는 고가용성을 과도하게 추구하면 시간과 비용적인 손해가 클 수 있으며, 필요 이상으로 복잡해진 인프라를 관리하는 데 어려움이 발생할 수 있다. 따라서 단일 마스터 노드로 구성하고 나중에 생각하는 것으로 결론을 내렸다.

The post 고가용성 (High Availability, HA) appeared first on .

결국 빠른 문제 해결을 위해선 어디서부터 접근해야하는지 알기 위해 동작 원리를 배워야한다. 말이 빠른 해결이지 자칫 나 혼자 공부, 포트폴리오 같은 것은 트러블 슈팅이 길어지면 포기하기 십상이다.

쿠버네티스 아키텍처

감격스럽다. 정말 간단 명료한 아키텍처 도식화라고 생각된다.
지난 포스팅에서 kubectl, kubeadm, kubelet 을 설치하고 클러스터를 만들었는데 아무런 설명을 하지 않았기 때문에 우선 위 도식을 기준으로 각 구성요소를 설명하려 한다.

쿠버네티스 어떻게 동작하는가?

ControlPlane (컨트롤 플레인)

쿠버네티스 클러스터를 관리하는 핵심 컴포넌트를 모아서 컨트롤 플레인이라고 부르며 Master Node(마스터 노드)에 설치된다.

• API Server: 클러스터 내의 모든 명령을 관리한다. kubectl, kubeadm 클라이언트는 API 서버와 통신하여 클러스터를 제어한다.
• Scheduler: 새로운 Pod를 생성할 때 적절한 워커 노드를 선택하는 역할을 수행한다.
• Controller Manager: 클러스터의 상태를 지속적으로 모니터링하며 사용자가 정의한 설정을 유지하기 위한 동작을 한다.
• etcd: 클러스터의 모든 현재 상태 정보를 Key-Value 형태로 저장, 보관한다.

Worker (워커 노드)

그림의 worker1은 워커 노드에 해당한다. 실제로 컨테이너가 실행되는 곳이다.

• kubelet: 각 노드에서 실행되며, API 서버와 통신하여 지정된 Pod가 제대로 실행되고 있는지 확인한다. Pod의 상태를 주기적으로 확인하고, 필요한 작업을 수행한다.
• kube-proxy: 클러스터 내부의 네트워킹을 관리하는 네트워크 프록시. 외부에서 들어오는 트래픽을 적절한 Pod로 라우팅한다.
• Pods: 워커 노드에서 실행되는 가장 작은 단위로, 컨테이너가 이 안에서 동작한다. 각 Pod에는 하나 이상의 컨테이너가 포함될 수 있다.
• CRI(Container Runtime Interface): 그림에서 docker1이라고 명시된 컨테이너 런타임. 이 런타임이 실제로 컨테이너를 실행시키는 역할을 한다. 과거엔 Docker 를 컨테이너 런타임으로 사용했지만 현재는 Containerd, CRI-O 를 사용한다.

동작 과정 예시

1. kubectl을 통해 API 서버에 명령을 내린다.
   
2. kubectl은 API 서버의 /api/v1/nodes 엔드포인트에 HTTP GET 요청한다.
3. API 서버는 kubectl로부터 받은 GET /api/v1/nodes 요청을 처리한다. 상태 정보를 저장한 etcd에서 모든 노드의 정보를 조회, 응답한다.
4. kubectl 클라이언트가 응답을 포맷팅하여 사용자에게 보여준다.
   

명령에 따라 사용자 설정을 etcd에 저장하고, 스케줄러가 생성할 파드를 적절한 노드로 결정하며 컨트롤러 매니저가 결정된 설정에 따라 워커 노드의 kubelet에 파드 생성 명령을 내린다.

kubectl을 통해 내린 거의 대부분 명령은 API 서버로 요청을 보낸다.

이외 알아두면 좋을 것들

당연히 알아두면 좋을 것은 엄청나게 많다. 하지만 글이 길어지면 받아들이기 쉽지 않다는 것을 안다. 마치 이 글만 보면 될 것처럼 말했었지만 추가 포스팅을 통해 좀 더 알아야 할 내용을 적어야겠다.

The post 쿠버네티스 시작하기 – 1 (최소한 알아야 할 것들) appeared first on .

쿠버네티스 설치 전 참고

쿠버네티스는 단일 노드 클러스터로도 구축이 가능하다. 정리된 명령어를 준비된 환경에 갖다 붙여넣기만 하면 클러스터를 만드는 것까지는 크게 어렵지 않을 것이다.

Ubuntu Server 24.04 LTS 를 설치하고 아무것도 설치되지 않은 환경을 가정한다.

각 코드 박스에 있는 # 주석은 참고 정도하고 무시하면 된다. (나중에 내 기억을 더듬기 위한 주석 정도로)
빠른 설치를 위한 쿡북 정도로 보면 되고 올바른 테크트리를 원하는 참 개발자는 공식 문서를 참고하여 설치하길 바란다.

쿠버네티스 설치

설치 전 준비

sudo apt update
sudo apt upgrade -y

# 설치 전 환경설정
# 1. Swap 끄기 (kubernetes는 기본적으로 swap 기능을 끄는걸 권장이 아닌 강제함)
sudo swapoff -a && sudo sed -i '/swap/s/^/#/' /etc/fstab

# 2. 방화벽 끄고 사용하지 않기 master, worker node간 통신 문제가 발생할 수 있음.
sudo systemctl stop firewalld
sudo systemctl disable firewalld

# 3. iptable bridge 설정
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables = 1
EOF
sysctl --system

containerd 설치

### containerd 설치 ###
# 계속 오류가 났던건.. containerd 가 설치되어있지 않았기 떄문이었다.
sudo apt-get install -y containerd

# 모든 worker node 에서도 containerd config.toml 파일 설정
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml

# containerd 옵션 수정 SystemdCgroup = true
# 직접 들어가서 바꿔도 되고
sudo vi /etc/containerd/config.toml
# 아래 명령어로 SystemdCgroup 옵션을 true 로 바꿔줘도 됨.
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/g' /etc/containerd/config.toml

Docker 설치 (옵션)

# Docker 설치 -- 옵션 : kubernetes runtime 에는 현재 Docker가 아닌
# Containerd 가 사용되고 있음. 
# Add Docker's official GPG key:
sudo apt-get update
sudo apt-get install ca-certificates curl
sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc

# Add the repository to Apt sources:
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update

# Docker 최신 버전 설치
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# Docker 설치 확인
sudo docker run hello-world

필요 패키지 설치

sudo apt install -y apt-transport-https gnupg-agent software-properties-common
curl -s https://packagsudo apt ines.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -

쿠버네티스 설치

# kubernetes 저장소 도메인 변경됨.
echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.30/deb/ /" | sudo tee /etc/apt/sources.list.d/kubernetes.list
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.30/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# kubernetes 설치
sudo apt update
sudo apt install -y kubelet kubeadm kubectl
# kubelet kubeadm kubectl 의 update 를 막음
sudo apt-mark hold kubelet kubeadm kubectl

# kubelet 재시작
sudo systemctl daemon-reload
sudo systemctl restart kubelet
sudo systemctl enable kubelet


# 클러스터 초기화 전 IP포워딩 활성화 필요 (안하면 init 과정에서 오류남. 마스터, 워커 모두 적용)
echo "net.ipv4.ip_forward=1" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

클러스터 초기화 (생성)

이 부분만 간략하게 설명을 해야겠다. 처음으로 나온 커스텀이 필요한 영역이라.
아래 명령어에 –pod-network-cidr=172.16.0.0/16 는 pod 가 사용할 IP 대역을 설정하는 것이기 때문에 생략해도 생성이 된다. 생략할 경우 이후 네트워크 플러그인 (플러그인이라니깐 마치 옵션 같지만 필수로 설치해야한다)을 설치 할 때 지정하거나 플러그인의 기본 CIDR 를 사용하게 된다.

CIDR 를 뭘 쓸지 고민된다면 우리집 사설 네트워크 IP CIDR 와 명확히 구분될 수 있는 것으로 지정하는게 좋다.

예를들면 우리집 공유기 아래 단말의 사설 IP 대역이 192.168.0.0/16 이라면

10.0.0.0/8 이나 172.16.0.0/12 대역으로 사용해서 명확히 구분되도록 지정하면 좋겠다. (헷갈리지 않기 위해서)

# Kubernetes 클러스터 초기화 * 마스터 노드만 실행
# sudo kubeadm init --pod-network-cidr=10.244.0.0/16
sudo kubeadm init --pod-network-cidr=172.16.0.0/16

와우. 클러스터 생성이 됐다.
여기까지 정상이라면 대략 아래와 같은 문구가 나올 것이다.

kubeadm join 192.168.100.101:6443 --token qjuyl0.8lu10et30xfj6dep \
	--discovery-token-ca-cert-hash sha256:a2193b2b0481f4dc0e1def5835bcfa110848f7f39bee844b2dcb18defb63d59b

쿠버네티스 접근 정보 저장

마스터 노드, 이후 추가할 워커 노드에도 적용이 필요하다.
root계정, 사용자 계정 모두 실행 필요.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

네트워크 애드온 설치

네트워크 애드온은 여러 종류가 있다. 이중 Calico 를 이용한 설치를 진행한다.

# calico 네트워크 애드온 설치
sudo kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

노드 상태 확인

kubectl get nodes

이렇게 나오면 작업이 완료된 것.

여기서 명령어만 더 나열할까 하다가 이젠 부족한 지식을 채워넣고 갈 때가 된 것 같아 이쯤에서 끊어주는게 좋을 것 같다.

The post 쿠버네티스 설치 (무지성 복붙) appeared first on .

물론 그땐 이름만 들어봤지 뭐하는 놈인지도 몰랐고, 내가 2024년 8월에 그걸 쓰기 위해 공부하며 구축하게 될거라곤 생각도 못했다.

쿠버네티스 왜 써야함?

뭔가를 배우거나 써먹을 때 제일 중요한 질문이라고 생각한다.
내가 이걸 왜 써야함?

회사를 다니며 느낀 것이 누군가를 설득할 때 꼭 필요한건 명분이다.

포트폴리오로 이용할라고

솔직히 이게 가장 큰 이유다.
이제 여기저기서 쿠버네티스를 쓰는 곳은 늘어나는데, 아직 업무에선 쓸 기회도 없었으니 이참에 공부도 할겸, 포트폴리오도 만들 수 있다니 뭐 쓰지 않을 이유가 있나?

자원이 부족해서

난 용돈을 받아서 쓰는 평범한 유부남인걸? 중국산 미니PC 3대, 라즈베리파이 1대를 구매하는데도 꽤나 눈치를 봤다. 기껏 가용한 자원은 16 코어 56GB 메모리. 이정도 서버로는 내가 원하는 생태계를 구축할 수 없다.
그럼 어쩌나. 적은 자원으로 최대한 뽑아먹어야지.

자주 신경쓰고 싶지 않다

한번 구축하면 오래오래 문제 없는 서비스가 좋다. 누구나 그렇겠지만.
앞으로도 개발해야 할 것은 너무 많아서 상황에 따라 이 시스템을 계속 봐줄 수 없고 나 대신 신경써주는 친구가 있었으면 좋겠다. 그 친구가 오케스트레이션을 해준다는 쿠버네티스가 아닐까?

생소한 쿠버네티스 용어

실무에서 사용되는 규모가 있는 기술엔 그것만이 가진 생태계와 특징이 있다.
쿠버네티스는 각 분야의 서비스를 컨테이너로 관리, 제공하기 위한 플랫폼이다보니 비교적 크고 복잡하다.

물론 용어를 모른다고 개발이나 구축을 못할 것은 없다.
희한하게 지내다보니 용어를 잘 아는 사람이 명분도 잘 만들고 사람들을 설득하는 기술이 뛰어나다는 것을 느꼈다.
20대 중반 개발을 시작한지 얼마 되지 않았을 무렵엔 그까짓 용어를 정확하게 아는 것이 뭐가 중요한가 뜻만 알고 다룰줄 알면 되지 생각했는데 현실은 조금 다르더라. 물론 나는 기억력이 좋지 않기 때문에 용어를 잘 못외운다. 그러니 열심히 기록을 해둬야지.

시작하기 전에 최소한의 용어와 개념을 알고 가는 것이 좋다.

Container (컨테이너)

도커를 사용해본 사람은 충분히 익숙한 그 컨테이너. 쿠버네티스 생태계에서 하나의 어플리케이션 단위로 보면 된다.

Pod (파드)

컨테이너를 관리하는 가장 작은 단위로 파드 내엔 여러개의 컨테이너가 있을 수 있다. 가령 워드프레스 같은 것은 워드프레스 웹 어플리케이션(PHP) 웹 서버(Nginx, Apache) 컨테이너 MySQL 컨테이너를 1개의 Pod로 묶어서 제공할 수 있다.
파드 내에 하나의 컨테이너만 있는 것을 single-container pod, 여러개 컨테이너가 있으면 multiple-container pod 라고 부른다.

Node (노드)

어플리케이션을 실행하는 서버. 내가 집에서 On-premise로 구축하는 경우엔 미니 PC 1대가 1개의 Node가 되는거고, 클라우드 환경에서 구축하는 경우엔 인스턴스 1대가 1개의 노드가 된다. 컨테이너, 파드는 논리적인 추상화된 개념이라 실체가 없다. 하지만 경우에 따라 노드는 실체가 있는 것이라 좀 더 이해하기 쉬울 것.

노드에겐 2가지 직업이 부여되는데 하나는 Master, 하나는 Worker 이다. 이름만 봐도 느낌이 오듯 마스터는 부리고 워커는 부려진다. (마치 회사와 나의 관계와 같이..)
마스터 노드는 클러스터를 제어, 관리(오케스트레이션)한다. Control Plane(컨트롤 플레인)이라는 개념적인 기능 집합체를 포함한 서버라고 생각하면 된다.
워커 노드는 어플리케이션을 실행한다. 이녀석도 마찬가지로 Data Plane(데이터 플레인)이라는 개념적인 어플리케이션 작업(실행, 데이터 처리, 요청 처리, ..)의 집합체를 포함한 서버라고 생각하면 된다.

실체가 있는 놈이라 개념적인 친구들을 많이 아우른다. 좀 더 자세한 내용을 다룰까 했지만 이게 또 너무 길어지면 보기가 싫어진다. 나중에 세부 개념 포스팅을 따로 하던 해야겠다.

Cluster (클러스터)

1개 이상의 노드를 묶어서 관리하기 위한 단위. 단일 노드 클러스터도 구축이 가능하지만 당연히 권장은 하지 않는다. 단일 노드 클러스터 상용 서비스를 제공하느니 쿠버네티스를 사용하지 않는 것이 낫다. 굳이..

클러스터를 구성하는 것은 마스터 노드, 워커 노드, 클러스터 네트워크 정도 된다.

쓰다보니 정말 기본 개념과 용어만 정리하는데도 너무 괴롭다.
글이 길어지면 보다가도 탈주하니 더 자세한 내용이 필요한 것에 대해선 별도의 포스팅을 작성해야겠다.

근데 다 작성하고 보니 AWS에 쿠버네티스에 대해 너무 잘 정리된 문서가 개많다.

AWS가 말하는 쿠버네티스 노드란

특히 컨트롤 플레인과 데이터 플레인 아키텍쳐를 이미지로 간략하게 표현해놔서 너무 좋다.
이해력이 딸리는 나는 이미지가 참 좋다. 앞으론 이미지를 잘 활용해보겠음.

The post 쿠버네티스 시작하기 – 0 (왜 써야함?) appeared first on .

과업

웹 개발자가 내 웹 사이트도 없는건 이상하지 않아? 라고 수 없이 떠들고 다니면서 바쁘다는 핑계로 아직도 없는 내 웹사이트.

무엇을 기록하나

백수가 된 기념으로 집에 있는 PC 를 활용해서 웹 서버로 사용하려한다.
쿠버네티스를 활용한 웹 생태계를 만드는 과정을 기록하려하고 삽질을 다시 하지 않기 위해 notion 에 혼자 작성하다보니 누군가는 이 시행착오로 도움이 될 수 있겠다 싶어서 겸사 겸사 포스팅을 할 예정이다.

준비된 것

사실 이전에 하나씩 사 모았던 대륙의 미니PC가 이미 준비되어있다.
라즈베리파이5 는 지금 보고 있는 블로그(wordpress), 아파트 단지에서 사용하도록 개발한 하자 등록 서비스 웹 어플리케이션을 제공하는 웹서버로 사용되고 있다. 대륙이들은 모두 포맷하고 ubuntu 24.04 LTS 버전으로 설치했다. PC를 고를 때 가장 크게 고려했던 것은 가격과 전력소비량이었다.

서버 자원

라즈베리파이5 – 4 core 8GB * 1
t8 pro plus – 4 core 16GB * 2
AM02 – 4 core 16GB * 1

개발 자원

인간 * 1
AI * 1 (chat GPT)
맥북 에어 M1 8GB 500GB with IntelliJ * 1
의자와 책상 그리고 에어컨 선풍기 그리고 남아도는 시간

진행 상황

쿠버네티스 클러스터를 만들고 4대의 대륙이들을 연결했다.
사실 이 과정도 순탄하진 않았는데 과거에 시행착오, 정리해둔 문서로 비교적 빨리 설정을 마칠 수 있었다.
시행착오만 없었으면 하루 내로 클러스터 생성을 마무리 할 수 있을 것 같다.

시간만 주어진다면 만리장성인들 못 쌓을까.

The post 기술 블로그 12년차 개발자의 첫번째 포스팅 appeared first on .