Kubernetes (39) - Helm Chart를 직접 만들어 MariaDB 배포하기
공개 Chart를 설치하는 데 익숙해지면 다음 질문이 생긴다. "내가 만든 애플리케이션도 이렇게 한 명령으로 설치할 수 있을까?" 답은 Chart를 직접 만드는 것이다. Chart를 만든다는 말은 대단해 보이지만, 실제로는 이미 쓰던 YAML에서 환경마다 달라지는 값만…
CATEGORY
39개의 글
공개 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을…
애플리케이션은 개발·테스트·운영 환경마다 서로 다른 설정값을 사용한다. 예를 들어 실행 모드, 서버 주소, 로그 수준, 기능을 켜고 끄는 값이 여기에 해당한다. 이런 일반 설정값은 컨테이너 이미지와 분리해 관리하는 편이 좋다. Kubernetes의 ConfigMap은…
1. Headless Service가 필요한 이유 일반적인 ClusterIP Service는 하나의 가상 IP를 제공하고, 그 IP로 들어온 요청을 여러 Pod 엔드포인트에 분산한다. 하지만 StatefulSet처럼 각 Pod를 구분해 연결해야 하거나, 클라이언트가 백…
1. Service가 필요한 이유 Deployment가 관리하는 Pod는 교체·확장·축소 과정에서 IP 주소가 바뀔 수 있다. 클라이언트가 특정 Pod IP를 직접 사용하면 Pod가 재생성됐을 때 통신 대상이 사라지고, 여러 Pod에 트래픽을 나누기도 어렵다. Serv…
1. CronJob이 필요한 이유 Job은 한 번 실행해 완료하는 Batch 작업을 관리한다. 백업, 정기 보고서 생성, 이메일 발송, 오래된 데이터 정리처럼 같은 Job을 일정한 주기로 반복해야 한다면 매번 직접 Job을 만들기보다 CronJob을 사용한다. Cron…
1. Job이 필요한 이유 Deployment, ReplicaSet, DaemonSet은 Pod를 계속 실행 상태로 유지하는 워크로드다. 하지만 데이터 정리, 백업, 마이그레이션처럼 한 번 실행해 성공적으로 끝나면 되는 작업에는 Pod를 계속 살려 둘 필요가 없다. J…
1. DaemonSet이 필요한 이유 Deployment는 원하는 개수의 Pod를 실행하지만, 어느 노드에 Pod가 배치될지는 스케줄러가 결정한다. 반면 DaemonSet은 선택된 각 노드에 Pod 복제본 하나씩 이 실행되도록 보장하는 워크로드 리소스다. 클러스터에 새…
1. Deployment란? Deployment는 상태를 유지하지 않는 애플리케이션을 선언적으로 배포하고 업데이트하기 위한 워크로드 리소스다. 원하는 Pod 템플릿과 복제본 수를 선언하면 Deployment가 ReplicaSet을 만들고, ReplicaSet이 실제 P…
Pod는 노드 장애, 애플리케이션 오류, 실수로 인한 삭제처럼 여러 이유로 사라질 수 있다. ReplicaSet은 지정한 수의 Pod가 계속 실행되도록 유지 하는 컨트롤러다. Pod 수가 부족하면 새 Pod를 만들고, 많으면 일부 Pod를 제거한다. 이번 글에서는 NG…
Pod를 직접 여러 개 만들면 Pod 하나가 삭제되거나 노드 장애로 사라졌을 때 원하는 개수를 직접 다시 맞춰야 한다. ReplicationController는 선언한 수만큼 같은 Pod가 실행되도록 감시하고, 부족하면 새 Pod를 만들어 원하는 상태를 유지한다. 이번…
지금까지는 Pod를 직접 만들고 실행 설정, 상태 점검, 자원 요청량을 지정했다. 하지만 직접 만든 Pod가 삭제되면 Kubernetes가 같은 Pod를 자동으로 새로 만들지는 않는다. 애플리케이션을 지속해서 운영하려면 현재 상태를 관찰하고 원하는 상태로 되돌리는 관리…
여러 Pod가 하나의 노드에서 함께 실행되면 CPU와 메모리를 무제한으로 사용하려는 컨테이너가 다른 애플리케이션의 실행을 방해할 수 있다. Kubernetes는 컨테이너의 resources.requests 와 resources.limits 로 필요한 자원과 사용할 수…
컨테이너 프로세스가 실행 중이라는 사실만으로 애플리케이션이 요청을 정상 처리한다는 보장은 없다. 교착 상태에 빠졌거나, 데이터베이스 연결을 기다리고 있거나, 초기 캐시를 아직 불러오는 중일 수 있다. Kubernetes Probe는 kubelet이 컨테이너 상태를 주기…
Pod가 시작될 때 애플리케이션 컨테이너만 바로 실행되는 것은 아니다. 필요한 네트워크와 볼륨을 준비한 뒤, 애플리케이션 실행 전의 작업이 있다면 Init Container가 이를 먼저 처리한다. 이번 글에서는 Pod 명세에 직접 작성하는 Init Container와…
컨테이너 이미지는 여러 환경에서 같은 방식으로 재사용하고, 실행 환경마다 달라지는 값은 Pod 설정으로 분리하는 편이 좋다. Kubernetes의 환경 변수는 애플리케이션의 주소, 실행 모드, 기능 플래그처럼 컨테이너 시작 시 전달할 값을 선언하는 기본적인 방법이다.…
Pod는 하나 이상의 컨테이너를 함께 실행하는 Kubernetes의 최소 배포 단위다. 하지만 컨테이너를 한 Pod에 넣는다고 모두 같은 방식으로 협력하는 것은 아니다. 애플리케이션의 생명주기, 네트워크, 데이터 공유가 밀접할 때만 Multi Container Pod를…
앞에서 Pod를 만들고 조회할 때는 리소스 이름을 사용했다. 하지만 같은 애플리케이션의 Pod가 여러 개로 늘어나거나 새 Pod로 교체되면 각각의 이름을 직접 관리하기 어렵다. Kubernetes는 Label로 리소스에 식별 정보를 붙이고, Selector로 조건에 맞…
Pod는 Kubernetes에서 컨테이너를 실행하는 가장 작은 배포 단위다. 간단한 웹 서버는 컨테이너 하나를 담은 Pod로 실행할 수 있고, 긴밀히 협력하는 컨테이너가 있다면 하나의 Pod에 함께 배치할 수도 있다. 이번 글에서는 Nginx 단일 컨테이너 Pod를 명…
Kubernetes에서 Namespace는 하나의 클러스터 안에서 리소스를 논리적으로 분리하는 단위다. 같은 이름의 Pod라도 서로 다른 Namespace에 만들 수 있어, 개발·운영 환경이나 팀별 리소스를 구분하는 데 유용하다. 이번 글에서는 Namespace 목록을…
Kubernetes 클러스터와 상호작용할 때 사용하는 기본 CLI가 kubectl 이다. 리소스의 상태를 조회하는 것부터 Pod와 Deployment 생성, 컨테이너 로그 확인, 내부 애플리케이션 접속까지 대부분의 작업을 kubectl 명령으로 수행한다. 이번 글에서는…