devops

Kubernetes + Jenkins + ArgoCD로 검색엔진을 포함한 블로그 CI/CD 파이프라인 구축기 지금 이 글을 보고 있는 이 블로그는 온프레미스 Kubernetes 클러스터 위에서 돌아가고 있다. 사실 블로그 하나 띄우는 데 Kubernetes까지 필요하냐고 물으면, 솔직히 필요 없다. Vercel에 올리면 5분이면 끝난다. 근데 나는 이 블로그를 인프라 놀이터로 쓰고 싶었다. 코드를 push하면 이미지 빌드부터 배포, 검색 색인 갱신까지 자동으로 돌아가는 파이프라인을 직접 만들어보고 싶었고, 실제로 만들었다. 이 글에서는 이 파이프라인이 어떤 아키텍처로 구성되어 있고, 각 설계 결정에 어떤 이유가 있었는지를 실제 매니페스트와 함께 다뤄보려 한다. 전체 아키텍처 먼저 전체 그림을 보자. 핵심은 두 개의 Git 저장소가 역할을 분리한다는 것이다: - blog-new: 애플리케이션 소스코드. Next.js 앱, 마크다운 콘텐츠, Jenkinsfile, ES 색인 스크립트가

Kubernetes 에서 Jenkins로 Cacheable CI 파이프라인 구축하기 최근 Kubernetes 에서 Jenkins 멀티브랜치 파이프라인을 구축했습니다. DinD, DooD 의 태생적인 보안 문제 때문에, 빌드를 어떻게 진행할지 고민이 많았는데요, Kaniko 를 통해 도커데몬 없이 컨테이너 이미지를 빌드할 수 있다는것을 알게되었습니다. 본 포스트에서는 Kubernetes 환경에서 Jenkins의 agent pod을 통해 kaniko를 활용한 캐시재사용성이 있는 CI 파이프라인을 구축하는 방법에 대해 다뤄보겠습니다. Kubernetes에서의 Jenkins kubernetes 환경에 Helm 으로 Jenkins를 배포한 경우, Jenkins는 기본적으로 kubernetes api 를 호출할 수 있는 권한을 갖게 되고, 각종 플러그인도 미리 설치가 됩니다: - ServiceAccount Helm 차트는 기본적으로 jenkins라는 이름의 ServiceAc

ArgoCD 옵션을 통한 무한 리다이렉션 문제 해결기 ArgoCD를 사용하면서 Web UI 접속이 이상하게 계속 리다이렉션 되는 상황을 겪은 적이 있다. 기존 LoadBalancer 타입으로 배포된 argocd-server를 ClusterIP로 바꾸고, Gateway API에 노출하는 과정에서 발생한 일이었다. URL은 정확한데, 브라우저는 으로 계속 튕기고, 로그를 봐도 인증 자체는 성공한 듯 보이는데 진입하지 못했다. 상황 설명 - Gateway Controller: Istio - 인증서: cert-manager + Let's Encrypt - 외부 도메인: (dns01 wildcard 사용) - 서비스: 를 ClusterIP로 운영 - UI 접속을 위해 HTTPRoute로 외부에 노출 Gateway 및 HttpRoute 설정은 다음과 같이 구성했다: minseoky-gateway.yaml argocd-route.yaml 정확한 문제 상황 설명 이전에, 내 환경 이야기를

ArgoCD 사용시 K8s 리소스가 의도치 않은 네임스페이스에 생기는 경우 트러블슈팅 🧵 ReferenceGrant 네임스페이스 오버라이딩 문제 분석과 해결기 🐳ArgoCD 에서 Helm + Kustomize 를 함께 사용하여 관리하는 경우에 발생한 문제를 다룹니다. 쿠버네티스 Gateway API와 cert-manager를 함께 사용하는 경우, ReferenceGrant 리소스 설정은 TLS 인증서 발급 및 사용을 위해 꼭 필요하다. 복잡한 상황을 해소하고자 ReferenceGrant를 istio-system 어플리케이션에 몰아넣었는데, 문제가 발생했다. 여기에 문제 상황과 해결방법을 정리하고 공유하려 한다. 클러스터 상태 및 Gitops 이전 내 gitops 상황을 요약하면 아래와 같다. 크게 argocd, istio-system, jenkins, cert-manager 네 개의 어플리케이션을 관리하고 있다. Argocd + Helm + Kustomize 방식을 사용해서 관

CKA 합격 후기 2025년 6월, 올해 따기로 결심했던 자격증 중 하나인 CKA에 합격했다. 개정된 시험 포맷 이후 치른 시험이었고, DevOps, MSA 아키텍처, 인프라 자동화에 깊은 관심을 가져오던 나로서는 하나의 마일스톤이 되었다. 이 글에서는 내가 CKA에 합격하기까지 어떤 전략과 학습 경로를 거쳤는지, 어떤 부분에서 시간을 쏟았는지, 그리고 실전 시험에서 어떤 식으로 접근했는지를 공유하려한다. 왜 CKA인가? 나는 온프레미스 환경(Proxmox)에서 을 이용해 직접 Kubernetes 클러스터를 구축한 경험이 있다. 여기에 MetalLB, Calico CNI, Ingress, Istio, Helm 등을 직접 적용해보면서, Kubernetes는 나에게 단순한 관심사를 넘어 직접 다루고 싶은 도구가 되었다. 나는 백엔드 개발자이지만, 나 스스로를 단순히 "백엔드 개발자"로만 규정하고 싶지 않았다. 프론트엔드부터 인프라, 운영까지 전반적인 흐름을 이해하고 다룰 수 있는

🐳 DinD vs DooD: Docker 기반 Jenkins/Argo CI/CD 전략 분석 Docker 기반의 CI/CD 파이프라인을 구성할 때, Jenkins나 Argo 같은 자동화 도구에서 Docker를 어떻게 실행할지에 따라 DinD(Docker-in-Docker) 와 DooD(Docker-outside-of-Docker) 두 가지 방식 중 선택하게 된다. DinD (Docker-in-Docker) 컨테이너 내부에서 자체적으로 Docker 데몬을 실행하여, 완전한 격리 환경을 제공한다. 예를 들어, Jenkins Job이 실행되는 컨테이너 안에서 독립적인 Docker 데몬을 구동하여, 그 안에서 다시 컨테이너를 실행하는 구조이다. 이러한 방식은 테스트 환경을 완전히 분리하고자 할 때 유용하다. 그러나 --privileged 권한이 필요하며, 보안상 위험이 존재하고 리소스 사용량이 많을 수 있다. DooD (Docker-outside-of-Docker) 컨테이너에서 호스트의 D

Chap 17. Workflow 관리 Argo workflow 쿠버네티스 core API에는 일회성 배치 작업을 수행하는 Job 리소스가 존재한다. 간단한 retry정책이나 parallel 실행이 가능하지만 작업간 종속성 부여, 조건부 실행, 에러 핸들링 등 고급 워크플로우 관리 기능은 부재한다. 이를 해결하고자 Argo Project에서 Argo workflow를 개발했다. Argo workflow는 쿠버네티스 워크플로우 엔진으로 CNCF의 incubating 프로젝트로 등록되어 있다. 사용자가 원하는 Workflow를 직접 구성할 수 있으며 작업간 종속성을 만들어 순차적으로 실행할 수 있다. 또한 병렬실행이나 에러 핸들링 등과 같은 고급 워크플로우 관리 기능과 사용자를 위한 웹 UI도 제공한다. 사용자는 쿠버네티스 내장 리소스처럼 워크플로우를 생성, 삭제 및 관리할 수 있다. 동작 방법 Argo workflow도 다른 Operator와 마찬가지로 사용자 정의 리소스에 따라 사용자

Chap 16. 사용자 정의 리소스 사용자 정의 리소스란? Custom Resource 사용자 정의 리소스는 쿠버네티스 API를 사용자가 원하는대로 확장한 리소스를 말한다. 예를 들어, 쿠버네티스 코어 API에 Pod라는 리소스가 있지만 사용자가 원하는 특별한 기능을 더한 MyPod라는 리소스를 새롭게 정의할 수 있다. 쿠버네티스에는 사용자가 쉽게 API를 확장할 수 있도록 CustomResourceDefinition(CRD)라는 리소스를 제공한다. CRD는 바로 새로운 리소스를 정의하는 리소스이다. - kind: CustomResourceDefinition — 이 리소스가 CRD임을 나타냄. 쿠버네티스에서 새로운 리소스 타입을 정의할 때 사용함. - name: mypods.crd.example.com — CRD의 전체 이름. . 형식을 따르며, 이 이름으로 API 서버에 등록됨. - group: crd.example.com — 해당 CRD가 속한 API 그룹. 커스텀 리소스는 코어

Chap 14. 로킹과 모니터링 쿠버네티스는 기본적으로 내장하고 있는 로깅 및 모니터링 시스템이 없다. 대신 그 기능을 Cloud Native 생태계에 맡겼다. 이번 장에서는 로킹은 EFK 스택을 이용하여, 모니터링은 Prometheus, Grafana를 이용하여 시스템을 구축해보자. 로깅 시스템 구축 클러스터 레벨 로깅의 장점 kubectl logs 명령어를 사용하면 컨테이너의 로그를 바로 확인할 수 있다. 그렇다면 왜 따로 클러스터 레벨의 로깅 시스템이 필요할까? 1. 로그 히스토리 저장 pod가 실행 중인 경우에는 kubectl logs 를 통해 로그 메시지를 확인할 수 있지만 Pod가 죽게 되거나 1회성 배치 작업인 경우, Pod가 사라지게 되어 로그 기록도 같이 삭제된다. 클러스터 레벨의 로깅 시스템을 따로 구축하여 로그 기록을 저장하면 언제든지 과거의 로그 기록들을 확인할 수 있다. 2. 시스템 컴포넌트 로그 통합 쿠버네티스에는 컨테이너뿐만 아니라

Chap 13. 접근 제어 쿠버네티스에서는 사용자의 인증/인가를 통해 아래 3단계를 통과해야 시스템에 접근할 수 있다.. 1. Authentication(인증): 접속한 사람의 신분을 인증하는 단계(누가 접근하는가). 2. Authorization(인가): 어떤 권한을 가지고 어떤 자원에 어떤 행동을 할 수 있는지 확인하는 단계. 3. Admission Control: 요청한 내용이 적절한지 확인하는 단계이다 - LimitRange, ResourceQuota 기능이 Admission Control을 통해 Pod 요청이 적절한지 확인한 예시이다. 사용자 인증 쿠버네티스에는 크게 5가지 사용자 인증 방식이 존재한다. - HTTP Authentication: 토큰, 베이직 인증 사용 - X.509 Certificate: 인증서 기반 사용자 인증 - OpenID Connect: OAuth 기반 외부 인증 - Webhook 인증: 외부 서버에 인증 위임 - Proxy 인증: 프록시 서버

Chap 12. 클러스터 관리 리소스 관리 앞서, Pod의 resource property를 통해 리소스를 관리하는 방법에 대해 알아보았다. 이번에는 LimitRange, ResourceQuota와 비교하며 차이점을 알아보자. 쿠버네티스 사용자를 크게 일반 사용자(developer)와 관리자(admin)으로 나누어 생각하면, 일반 사용자는 자신이 개발한 어플리케이션을 쿠버네티스 플랫폼 위에 실행하는 사용자이다. 관리자는 쿠버네티스 클러스터 자체를 관리하고 필요한 물리 리소스(노드, 디스크, 네트워크 등)를 제공하는 총 책임자 이다. 이 두 역할을 한 사람이 다 맡을 수도 있지만, 서로 다른 사람이 맡을 수도 있다. 이때, 클러스터 관리자가 일반 사용자에게 리소스 사용량을 제한하기 위해 사용하는 것이 LimitRange와 ResourceQuota리소스 이다. LimitRange LimitRange의 기능은 2가지이다. - 일반 사용자가 리소스 사용량 정의를 생략하더라도 자동으로 Pod

Chap 11. 고급 스케줄링 고가용성 확보 - Pod 레벨 ReplicaSet, Deployment 리소스의 replica property를 이용하여 서비스의 가용성을 높이는 방법에 대해 알아보았다. 이런 방법은 일정 범위 안의 트래픽에 대해서는 서비스 가용성이 유지되지만 처리량 범위를 넘어서는 트래픽에 대해서는 한계를 가진다. replica 개수가 정적으로 고정되어 있기 때문이다. 이러한 문제를 해결하고자 쿠버네티스에서는 Pod의 리소스 사용량에 따라 자동으로 확장하는 HorizontalPodAutoScaler(HPA)라는 리소스를 제공한다. HPA는 이름에서도 짐작할 수 있듯, Pod의 개수를 수평적으로 자동 확장한다. HPA는 metrics-server라는 컴포넌트를 사용한다. metrics-server는 Pod의 리소스 사용량을 수집하는 서버이다. 이 서버를 통해 Pod의 작업량을 모니터링하다가 사용자가 지정한 일정 수준의 임계값을 넘으면 replica 개수를 동적으로 조

Chap 10. 스토리지 쿠버네티스에서는 단순히 호스트 서버의 볼륨을 연결하는 것 외에 다양한 형태로 데이터를 저장 및 참조하는 방법들을 제공한다. 이 장에서는 다음과 같은 리소스를 살펴본다: - PersistentVolume - PersistentVolumeClaim - StorageClass PersistentVolume PV는 데이터 저장소를 추상화시킨 리소스이다. 쿠버네티스 클러스터 관리자가 데이터 저장소를 사용하기 위해 미리 마련한 저장 자원을 나타낸다. PV에는 구체적인 저장소 정보가 담겨있는데, 예를 들면: - AWS 플랫폼: EBS(Elastic Block Storage) 정보 - GCP 플랫폼: PersistentDisk 정보 - 로컬 호스트: 로컬 호스트의 볼륨 path 정보 이처럼 다양한 환경에서 다양한 저장소 타입을 제공하기 위해 쿠버네티스에서는 PersistentVolume(PV)라는 추상화된 리소스를 사용하고 각 환경에 따라 그에 맞는 타입을 선택한다.

Chap 9. Ingress 리소스 Ingress란? Ingress는 HTTP, HTTPS 등 네트워크 Layer 7에 대한 설정을 담당하는 리소스이다. Ingress의 가장 기본적인 역할은 외부 HTTP 호출에 대한 트래픽을 처리한다. 이를테면, 부하 분산, TLS 종료, 도메인 기반 라우팅 기능 등을 제공한다. Ingress는 쿠버네티스 내부 서비스에 외부 접근 가능한 URL을 부여함으로써 일반 사용자들이 쉽게 접근할 수 있는 통로를 제공한다. Ingress에는 그에 맞는 Ingress Controller가 존재하며, Ingress Controller는 Ingress에 정의된 트래픽 라우팅 규칙을 보고 라우팅을 수행한다. Ingress (출처: https://medium.com/devops-mojo) Ingress Controller란? Ingress 리소스 자체로는 어떠한 프로그램이 작동하는 코드가 아니라 트래픽 처리에 대한 정보를 담고 있는 정의(또는 규칙)에 가깝다. 실제로

Chap 8. Helm 패키지 매니저 Helm이란? helm은 쿠버네티스 패키지 매니저이다. , , 툴과 비슷하다고 생각하면 된다. helm 차트의 구조는 크게 values.yaml과 templates/ 디렉터리로 구성된다. - : 사용자가 원하는 값들을 설정하는 파일 - : 설치할 리소스 파일들이 존재하는 디렉터리로, 해당 디렉터리 안에는 , 등과 같은 쿠버네티스 리소스가 Yaml 파일 형태로 들어있다. 각 파일들의 설정값은 비워져있고(placehoolder) values.yaml의 설정값들로 채워진다. 패키지가 설치될 시점에 파일의 설정값들을 이용하여 templates 디렉터리에 들어있는 Yaml 파일의 구멍난 부분(placeholder)을 채운다. 파일에는 - 자주 바뀌거나 사용자마다 달라지는 설정값들을 입력하는 용도로 사용하고 디렉터리는 패키지의 뼈대를 이룬다. helm chart helm을 잘 활용하면 다른 사람이 만든 애플리케이션도 손쉽게 나의 쿠버네티스 클러스터로 가