Somaz의 IT 공부 일지

Overview Kubernetes 환경에서 애플리케이션을 배포할 때, Helm은 가장 널리 쓰이는 패키지 매니저이다.하지만 여러 개의 Helm 차트를 동시에 다루거나, 환경별 변수 처리를 체계적으로 하고 싶을 때는 Helm 자체만으로는 부족함을 느끼게 된다. 이럴 때 필요한 것이 Helmfile이다.Helmfile은 Helm 기반 배포를 코드처럼 선언적으로 정의하고, 여러 차트를 일괄 관리할 수 있게 해주는 도구 Helmfile을 활용하면 다음과 같은 상황을 간결하게 처리할 수 있다.여러 Helm 차트를 한 번에 배포dev/staging/prod 환경 분리 및 values 재사용GitOps/CD 도구와 통합차트 버전, 이미지 태그, 레지스트리 관리의 일관성 확보 Helmfile 설치br..

Overview오늘은 Helm Chart 개발에서 유용한 기능인 `values.schema.json` 에 대해 알아보겠다. Helm은 기본적으로 `values.yaml` 파일을 통해 사용자 정의 값을 설정하게 되는데, 이 값의 유효성 검사를 자동화하고 싶을 때 `values.schema.json` 을 사용할 수 있다. Helm `values.schema.json` 은 Helm Chart에서 제공하는 값(`values.yaml`)의 스키마를 정의하는 표준 JSON Schema 파일이다. 이 스키마를 통해, 사용자가 제공하는 값이 올바른 형식과 타입을 가지고 있는지 사전에 검증할 수 있다.​     📅 관련 글Helm에 대한 내용들은 이전 포스팅을 참고하길 바란다.2022.09.06 - [Container..

OverviewKubernetes Deployment Strategy는 새로운 버전의 애플리케이션을 서비스 중단 없이 안정적으로 배포하기 위한 핵심 메커니즘이다. 기본적으로 Kubernetes는 RollingUpdate 전략을 사용하여 점진적으로 Pod를 교체하지만, 사용자의 요구사항에 따라 다양한 방식의 전략을 선택하거나 커스터마이징할 수 있다. 대표적인 전략은 다음과 같다.RollingUpdate: 기존 Pod를 하나씩 교체하며 가용성을 유지 (기본값)Recreate: 모든 기존 Pod를 제거한 후 새 버전을 일괄 생성 (다운타임 발생)Blue/Green: 별도 환경을 구성하여 스위칭 기반 배포 (빠른 롤백 가능)Canary: 일부 사용자 대상으로 점진적 배포 후 트래픽 확장 (실사용 기반 검증)..

Overview쿠버네티스에서 서비스는 클러스터 내의 여러 파드(Pod)로 트래픽을 라우팅하는 역할을 한다.이때 서비스가 실제 어떤 파드로 연결해야 할지를 저장하는 객체가 바로 `Endpoint` 와 `EndpointSlice` 이다.오늘은 이 두 객체의 차이점과 진화 과정, 그리고 실제 운영 환경에서 어떤 의미를 가지는지까지 깊이 있게 알아본다.   📅 관련 글2024.02.02 - [Container Orchestration/Kubernetes] - Kubernetes Network        Endpoint란?Endpoint는 서비스에 연결된 모든 파드의 IP와 포트 정보를 가진 객체이다. 쉽게 말해 "이 서비스가 어디로 트래픽을 보낼지"를 담고 있는 주소록이다.kind: EndpointsapiV..

OverviewKubernetes 클러스터에서 외부로부터 들어오는 요청의 Source IP(클라이언트 IP) 를 정확히 파악하는 것은 로깅, 보안 분석, 감시(Audit), 접근 제어 등 다양한 운영 및 보안 목적에서 매우 중요하다.그러나 Kubernetes의 기본 네트워크 구성에서는 서비스 타입에 따라 요청이 kube-proxy, NAT, ingress proxy 등을 거치며 Source IP가 변경되거나 소실되는 경우가 발생한다. 이 글에서는 Kubernetes 환경에서 Source IP가 왜 사라지는지, 그리고 이를 보존하기 위해 어떤 설정을 적용해야 하는지를 Service 타입별, Ingress 방식별로 정리한다.또한 실습을 통해 실제 요청 시 IP가 어떻게 보이는지, 어떻게 보존할 수 있는지를 ..

OverviewKubernetes는 기본적으로 Ingress 리소스를 통해 L7(HTTP/HTTPS) 트래픽을 처리하지만, 이 방식은 Layer 4(L4) 수준의 트래픽 제어나 멀티 프로토콜, 복잡한 인증 처리 등에서 한계를 가진다.  이를 해결하기 위해 등장한 Kubernetes Gateway API는 L4~L7까지 유연하게 다룰 수 있는 새로운 네트워크 모델이다. Ingress를 단순히 확장한 것이 아닌, 현대 클라우드 네트워크를 위한 진화된 표준이며, 서비스 메시, API Gateway, 로드밸런서 등을 하나의 공통 구조로 통합 관리할 수 있게 해준다.      📅 관련 글2022.08.08 - [Container Orchestration/Kubernetes] - Kubernetes Ingress..

OverviewKubernetes에 간단하게 static-file-server 생성하는 방법에 대해서 알아본다.         Static File Server 설치static-file-server Github  해당 Github 주소에 들어가서 내용을 읽어보면 Configuration에 Environment Variables, YAML Configuration File,그리고 Deployment 부분에 Without Docker, With Docker 방법이 작성되어 있다. Docker Image가 존재한다면, Kubernetes Pod로 실행하는 것은 크게 어렵지 않다.    Helm Value 작성template은 필수 입니다. template 작성이 어려우시다면 아래의 글을 확인하면 된다.2025..

OverviewKubernetes Kube-prxoy Component의 주요 개념인 IPVS vs iptables 에 대해서 알아본다.      IPVS 및 iptables의 개념 1️⃣ iptables (IP 테이블 규칙)iptables는 Linux 커널에 내장된 패킷 필터링 및 NAT(네트워크 주소 변환) 프레임워크이다.패킷이 통과해야 하는 체인의 규칙을 정의하고 네트워크 트래픽을 허용, 거부, 전달 또는 수정할지 결정하는 방식으로 작동한다. Kubernetes에서 작동하는 방식Kubernetes는 iptables 를 사용하여 서비스와 Pod 간에 트래픽을 라우팅한다.백엔드 Pod를 순차적으로 선택하여 라운드 로빈 로드 밸런싱을 구현한다.  iptables의 장점안정성: Linux 시스템에서 성숙하..

Overview이번 글에서는 Helm Chart를 활용해 Base App Chart를 설계하고, 이를 기반으로 다양한 애플리케이션을 ArgoCD를 통해 자동 배포하는 방법을 정리한다. 단일한 Helm Chart 템플릿(Base Template)을 기반으로, 환경(dev1, dev2 등)과 서비스(admin, auth 등)에 따라 개별 values.yaml 파일만 다르게 구성해 애플리케이션을 배포할 수 있는 구조를 설계한다. 이를 통해 공통된 차트 구조를 유지하면서도 확장성과 유지보수성을 높일 수 있으며, ArgoCD ApplicationSet과의 연동을 통해 GitOps 방식으로 다중 환경 및 클러스터에 손쉽게 배포가 가능하다.  글에서는 아래 항목을 실습 중심으로 설명한다.Helm Base App Ch..

Overview이번 글에서는 직접 개발한 Kubernetes Operator(예: helios-lb)를 Helm Chart로 패키징하고, GitHub Pages 기능을 활용해 Helm Chart Repository를 구축 및 배포하는 전 과정을 다룬다. helm create 명령어를 통해 Helm Chart의 기본 구조를 생성하고, CRD, 컨트롤러, RBAC, 서비스 등 필요한 리소스를 templates/에 정의한다. 이후 Helm의 `package, repo index` 명령을 통해 `.tgz` 패키지와 `index.yaml` 을 생성한 후, GitHub의 `gh-pages` 브랜치에 업로드함으로써 Helm Chart를 외부에 서비스할 수 있는 레포지토리를 구축한다. 이 과정을 통해 Helm Char..