Somaz의 IT 공부 일지

OverviewKubernetes에서 퍼시스턴트 스토리지(Persistent Storage)를 구성할 때 가장 먼저 마주하는 질문은 "어떤 스토리지 타입을 선택해야 할까?" 이다. NFS는 간단하지만 성능이 걱정되고, iSCSI는 빠르다지만 설정이 복잡해 보인다. 클라우드 환경이라면 또 다른 선택지들이 있다. 이 글에서는 Kubernetes 환경에서 사용되는 주요 스토리지 타입들의 특징과 장단점을 비교하고, 상황에 맞는 최적의 선택을 할 수 있도록 가이드를 제공한다. 실무 경험을 바탕으로 각 스토리지 타입이 어떤 워크로드에 적합한지 구체적인 사례와 함께 살펴보겠다. 1. 스토리지 타입의 기본 개념 블록 스토리지 (Block Storage) vs 파일 스토리지 (File Storage)스토리지를..

Overview사내에서 관리하던 Helm 차트를 여러 클러스터에서 공유하다 보면 결국 한계에 부딪힌다. 한 클러스터용으로 작성한 차트가 다른 클러스터에서도 유용한데, 복사해서 쓰다 보면 버전이 어긋나고 CI가 깨지고, 팀 밖으로는 공유할 방법이 없다. 이번 포스팅에서는 사내 차트 하나를 공개된 Dual Distribution Helm Chart Repository로 추출하는 전체 과정을 정리한다. GitHub Pages(커스텀 서브도메인) 기반의 전통적인 Helm Repo와 OCI Registry(GHCR)에 동시에 배포하고, ArtifactHub에 등록해 카탈로그에서 검색 가능하게 만들며, CI/CD와 거버넌스 체계까지 갖추는 방법이다. 예시로 사용한 차트는 nginx-gateway-cr이다. NGIN..

OverviewKubernetes v1.34로 업그레이드한 후, kube-apiserver 로그에 아래와 같은 Warning이 30초마다 반복적으로 출력되는 현상이 보고되고 있다.W0407 09:18:02.032615 grpc: addrConn.createTransport failed to connect to {Addr: "10.10.10.17:2379"} Err: connection error: desc = "transport: Error while dialing: dial tcp 10.10.10.17:2379: operation was canceled"이 로그만 보면 etcd 연결이 끊긴 것처럼 보이지만, 실제로는 클러스터 동작에 전혀 영향이 없는 무해한 Warning이다.이번 포스팅에서는 이 Wa..

OverviewKubernetes 클러스터를 운영하다 보면 보안 패치, 새로운 기능, 인증서 갱신 등의 이유로 주기적인 업그레이드가 필요하다. Kubespray는 upgrade-cluster.yml 플레이북을 통해 etcd → Control Plane → Worker 순서로 자동 업그레이드를 지원하며, 수동으로 각 노드에 접속하여 kubeadm upgrade를 실행할 필요 없이 Ansible 한 줄로 전체 클러스터를 업그레이드할 수 있다. 이번 포스팅에서는 다음의 내용을 중심으로 정리하였다.Kubespray ↔ Kubernetes 버전 매핑 이해etcd 백업 및 복구Kubespray 버전 전환 (v2.28.0 → v2.30.0)upgrade-cluster.yml을 이용한 Kubernetes 업그레이드 (..

OverviewKubernetes 클러스터를 구축하는 방법은 여러 가지가 있지만, 온프레미스 환경에서 반복 가능하고 자동화된 설치를 원한다면 Kubespray가 가장 강력한 선택지 중 하나이다. Kubespray는 Ansible 기반의 프로비저닝 도구로, YAML 기반 인벤토리 파일만 정의하면 다양한 환경(GCP, AWS, 온프렘 등)에서 HA 구성을 포함한 쿠버네티스 클러스터를 유연하게 설치할 수 있다.이번 포스팅에서는 다음의 내용을 중심으로 정리하였다.Ubuntu 24.04 기반 온프레미스 환경에서 Kubespray를 이용한 Kubernetes v1.34 클러스터 구축Cilium CNI, Helm, Metrics Server, Krew 등 주요 애드온 설정containerd insecure regis..

Overview Kubernetes에서 애플리케이션의 안정적인 운영을 위해 중요한 개념 중 하나가 바로 Probe이다.클러스터를 구축하거나 배포 설정을 하다 보면 liveness, readiness, startup 같은 Probe 설정을 자주 마주하게 된다. Probe는 단순히 컨테이너가 살아 있는지뿐만 아니라, 서비스 요청을 받을 준비가 되었는지, 기동이 완료되었는지 등 다양한 상태를 세밀하게 감지해준다.이러한 Probe를 적절히 구성하면 장애 회복 속도 개선, 잘못된 트래픽 분산 방지, 무한 재시작 루프 방지 등의 효과를 얻을 수 있다. 이 글에서는 Kubernetes에서 지원하는 Probe의 개념과 종류, 각각의 용도와 동작 방식을 실무적 관점에서 정리해본다. Probe란?Pro..

OverviewKubernetes 클러스터를 운영하다 보면 Git에 정의된 manifest와 실제 클러스터 상태가 달라지는 현상, 이른바 Cluster Drift가 발생한다. 누군가 `kubectl edit` 으로 replicas를 수동 변경하거나, `kubectl scale` 로 급하게 스케일링했을 때, Git 소스와 클러스터 상태 사이에 괴리가 생긴다. 기존 `kubectl diff` 로도 비교가 가능하지만, YAML 파일만 지원하고, Helm/Kustomize를 직접 다룰 수 없으며, 출력이 raw unified diff라 가독성이 떨어진다. 이 글에서는 이런 문제를 해결하기 위해 직접 만든 두 가지 도구를 소개한다.kube-diff — Go로 작성한 CLI 도구. Plain YAML, Helm..

Overview분산 시스템에서 동시성 제어는 항상 까다로운 문제다. 여러 인스턴스가 동시에 같은 리소스에 접근하려 할 때, 데이터 일관성을 보장하고 race condition을 방지하기 위해서는 적절한 락(Lock) 메커니즘이 필요하다. Redis를 사용한 분산 락 구현 시, 단순한 SET NX 명령어만으로는 네트워크 파티션이나 Redis 인스턴스 장애 상황에서 안전성을 보장하기 어렵다. 이런 문제를 해결하기 위해 Redis 창시자 Salvatore Sanfilippo가 제안한 것이 바로 Redlock 알고리즘이다. 이 글에서는 Redlock의 동작 원리부터 Kubernetes 환경에서의 실제 구현 방법, 그리고 운영 시 주의사항까지 상세히 알아본다. 특히 많은 개발자들이 놓치기 쉬운 Kubernetes..

OverviewKubernetes 환경에서 상태를 가진 애플리케이션(Stateful Applications)을 운영할 때, 적절한 스토리지 솔루션 선택은 매우 중요하다. 기존의 NFS나 클라우드 기반 스토리지의 한계를 극복하고자 많은 조직들이 local storage 기반의 분산 블록 스토리지 솔루션을 도입하고 있다. 본 가이드에서는 현재 가장 주목받고 있는 세 가지 오픈소스 스토리지 솔루션을 심층 분석하고 비교한다. OpenEBSCNCF 샌드박스 프로젝트로, Container Attached Storage(CAS) 개념을 도입한 클라우드 네이티브 스토리지 솔루션이다. 다양한 스토리지 엔진을 제공하여 다양한 워크로드 요구사항을 충족한다. LonghornRancher에서 개발한 분산 블록 스토리지로,..

Overviewcontainerd가 v2에서 v3로 업그레이드되면서 insecure registry 설정 방법이 크게 변경되었다. 기존의 `config.toml` 파일 내 설정 방식에서 별도 디렉토리 구조를 사용하는 방식으로 변경되었다. 주요 변경사항 containerd v2 (기존 방식)# /etc/containerd/config.tomlversion = 2[plugins."io.containerd.grpc.v1.cri".registry] [plugins."io.containerd.grpc.v1.cri".registry.mirrors] [plugins."io.containerd.grpc.v1.cri".registry.mirrors."harbor.somaz.link"] ..