Argo CD (1) - GitOps와 Argo CD의 역할
1. 개요 애플리케이션을 Kubernetes에 배포할 때 kubectl apply 를 직접 실행하면 빠르게 시작할 수 있다. 하지만 환경과 클러스터가 늘어나면 누가, 언제, 어떤 설정을 바꿨는지 추적하기 어렵고, Git에 저장된 설정과 실제 클러스터의 상태가 달라질 수…
TAG
45개의 글
1. 개요 애플리케이션을 Kubernetes에 배포할 때 kubectl apply 를 직접 실행하면 빠르게 시작할 수 있다. 하지만 환경과 클러스터가 늘어나면 누가, 언제, 어떤 설정을 바꿨는지 추적하기 어렵고, Git에 저장된 설정과 실제 클러스터의 상태가 달라질 수…
1. 개요 이번 글에서는 Kubernetes 클러스터에 Argo CD를 설치하고, 초기 관리자 비밀번호로 Web UI에 접속한다. 실습에서는 외부 접속을 위해 argocd server Service를 NodePort로 변경한다. NodePort와 자체 서명 인증서는 학…
1. 개요 Argo CD의 Application 은 배포할 소스와 대상 클러스터를 연결하는 핵심 리소스다. 이번 글에서는 Bitnami NGINX Helm 차트를 예시로 Application을 만들고, 자동 동기화와 구성 드리프트 처리 옵션을 살펴본다. Helm을 직접…
1. 개요 앞 글에서는 Helm 차트를 Application으로 배포했다. 이번에는 GitHub 저장소의 manifest 디렉터리에 Namespace, Deployment, Service를 저장하고, Argo CD가 이 디렉터리를 읽어 클러스터에 배포하도록 구성한다.…
1. 개요 일반 Kubernetes Deployment를 수정하면 새 ReplicaSet을 만들고, 기본 RollingUpdate 전략에 따라 이전 Pod와 새 Pod를 점진적으로 교체한다. 이 전략은 간단하지만 새 버전을 얼마나 노출할지, 중간에 관찰을 위해 멈출지,…
1. 개요 카나리 배포는 새 버전을 일부에 먼저 적용하고, 오류율·응답 시간·로그처럼 중요한 신호를 확인한 뒤 점차 배포 범위를 넓히는 방식이다. 이번 실습에서는 파란색( blue ) 버전을 먼저 5개 배포한 뒤, 노란색( yellow ) 버전을 20%부터 점진적으로…
공개 Chart를 설치하는 데 익숙해지면 다음 질문이 생긴다. "내가 만든 애플리케이션도 이렇게 한 명령으로 설치할 수 있을까?" 답은 Chart를 직접 만드는 것이다. Chart를 만든다는 말은 대단해 보이지만, 실제로는 이미 쓰던 YAML에서 환경마다 달라지는 값만…
Nginx나 MariaDB를 Kubernetes에 직접 설치하려면 Deployment, Service, Secret, PVC처럼 여러 YAML 파일이 필요하다. Helm은 이 YAML 묶음을 재사용 가능한 패키지로 만들어, 한 명령으로 설치하고 설정을 바꾸고 이전 버전…
같은 애플리케이션을 개발 환경과 운영 환경에 배포하면 YAML 파일이 조금씩 달라진다. 개발 환경은 Pod를 1개만 실행하고, 운영 환경은 3개를 실행할 수 있다. Ingress 주소, 이미지 태그, 리소스 제한도 환경마다 다를 수 있다. 이 차이 때문에 YAML을 통…
새 버전을 배포하는 일은 단순히 Pod 이미지를 바꾸는 것보다 넓은 문제다. 기존 버전과 새 버전을 얼마나 오래 함께 실행할지, 어떤 기준으로 트래픽을 넘길지, 문제가 생겼을 때 얼마나 빨리 되돌릴지를 함께 결정해야 한다. 이 글에서는 Deployment의 기본 업데이…
일반적인 Pod는 API 서버에 매니페스트를 제출하고, 스케줄러와 컨트롤러를 거쳐 노드에서 실행된다. 반면 Static Pod는 특정 노드의 kubelet이 로컬 파일을 직접 읽어 실행·관리하는 Pod다. 이 방식은 API 서버가 아직 준비되지 않은 상황에서도 노드에서…
HPA가 부하에 맞춰 Pod 수를 늘려도, 모든 노드에 빈자리가 없다면 새 Pod는 실행되지 못하고 Pending 상태에 남는다. 이때 필요한 것은 Pod가 아니라 Pod를 실행할 노드 를 늘리는 일이다. Cluster Autoscaler는 스케줄되지 못한 Pod와 노…
앞 글에서 HPA는 부하에 따라 Pod 개수 를 조절한다고 살펴봤다. 하지만 Pod의 CPU·메모리 requests 자체가 실제 워크로드에 맞지 않으면, Pod가 불필요하게 많이 배치되지 않거나 반대로 자원을 낭비할 수 있다. Vertical Pod Autoscaler…
웹 요청이 늘어날 때 Pod를 사람이 직접 늘리고, 한가해지면 다시 줄이는 일은 반복적이고 늦기 쉽다. Horizontal Pod Autoscaler(HPA)는 관측한 지표를 바탕으로 Deployment 같은 워크로드의 복제본 수를 자동으로 조절한다. HPA는 컨테이너…
앞 글에서 컨테이너마다 requests 와 limits 를 직접 설정했다. 하지만 팀원이 많아지면 누군가 설정을 빠뜨리거나, 지나치게 큰 값을 넣는 일을 매번 리뷰만으로 막기 어렵다. LimitRange 와 ResourceQuota 는 네임스페이스 단위로 기본값과 총량…
컨테이너는 파일을 쓸 수 있다. 로그 파일, 압축 해제 파일, 임시 캐시처럼 컨테이너가 사용하는 로컬 디스크도 결국 Kubernetes 노드의 디스크 공간을 차지한다. 이런 임시 디스크 사용량을 관리하는 리소스가 ephemeral storage 다. 데이터를 오래 보존…
Deployment 같은 컨트롤러가 Pod를 생성해도 어느 Node에서 실행할지는 아직 정해지지 않았다. 기본 스케줄러인 kube scheduler 는 Node가 지정되지 않은 Pod를 발견하고, 조건을 만족하는 Node 중 적합한 곳을 선택해 연결한다. 앞에서 배운…
1. Ingress가 필요한 이유 LoadBalancer Service를 애플리케이션마다 만들면 외부 IP와 로드 밸런서가 서비스 수만큼 늘어날 수 있다. 웹 애플리케이션은 보통 하나의 도메인 아래에서 호스트 이름이나 URL 경로에 따라 여러 백엔드로 나누어 보내는 편…
1. MetalLB가 필요한 이유 type: LoadBalancer Service는 외부 로드 밸런서 구현체에 공인 또는 외부 IP 할당을 요청한다고 정리했다. AWS·GCP 같은 클라우드에서는 해당 구현체가 제공되지만, kubeadm으로 구성한 온프레미스·가상 머신…
1. selector 없이도 Service를 만들 수 있다 일반적인 Service는 selector로 Pod를 찾고, Kubernetes가 EndpointSlice를 자동 생성한다. 그러나 관리형 데이터베이스, 다른 클러스터의 서비스, Kubernetes로 이전 중인…
1. Service의 분산 경로도 제어할 수 있다 일반 Service는 준비된 모든 엔드포인트 가운데 하나로 트래픽을 보낸다. 이 기본 동작은 무상태 웹 서버에 알맞지만, 클라이언트를 같은 Pod에 유지해야 하거나 외부 요청의 원본 IP를 보존해야 할 때는 추가 정책이…
1. StatefulSet이 필요한 이유 Deployment와 ReplicaSet은 같은 사양의 Pod를 여러 개 실행하고 개수를 유지하는 데 적합하다. 하지만 데이터베이스나 메시지 브로커처럼 각 복제본이 고유한 이름, 네트워크 주소, 디스크 데이터를 가져야 하는 애플…
여러 노드에서 실행되는 Pod가 같은 파일을 함께 읽고 써야 할 때가 있다. 예를 들어 여러 웹 서버 Pod가 업로드 파일을 공유하거나, 여러 작업 Pod가 같은 결과 디렉터리를 사용해야 하는 경우다. NFS(Network File System)는 네트워크로 공유한 하…
Pod 안에서 쓰던 데이터를 Pod가 다시 만들어진 뒤에도 보존해야 할 때가 있다. 데이터베이스 파일, 사용자가 올린 파일, 메시지 큐 데이터처럼 잃으면 안 되는 데이터가 대표적이다. Kubernetes에서는 PersistentVolume(PV)과 PersistentV…
컨테이너 안에서 만든 파일은 별도 저장소를 연결하지 않았다면 컨테이너의 파일 시스템 안에 저장된다. 컨테이너가 교체되거나 Pod가 다시 만들어질 때 이 파일을 그대로 기대하면 안 된다. 하지만 모든 파일을 오래 보관할 필요는 없다. 캐시나 작업 중간 결과처럼 잠깐만 필…
데이터베이스 비밀번호, API 토큰, TLS 개인 키처럼 이미지나 일반 설정 파일에 넣으면 안 되는 값이 있다. Kubernetes의 Secret은 이런 기밀 데이터를 별도 리소스로 관리하고, 필요한 Pod에만 환경 변수 또는 파일로 전달하는 기능이다. Secret을…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
1. CronJob이 필요한 이유 Job은 한 번 실행해 완료하는 Batch 작업을 관리한다. 백업, 정기 보고서 생성, 이메일 발송, 오래된 데이터 정리처럼 같은 Job을 일정한 주기로 반복해야 한다면 매번 직접 Job을 만들기보다 CronJob을 사용한다. Cron…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…

실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…
실습 전 확인하기 : kubectl 이 실습용 클러스터를 가리키는지 먼저 확인한다. cat 파일명 으로 시작하는 블록은 터미널에 그대로 붙여넣으면 현재 디렉터리에 YAML 파일이 만들어지고, 이어지는 kubectl apply f 명령으로 적용한다. 필드 일부만 보여 주…