6. ConfigMap과 Secret - 설정을 이미지에서 분리
·
DevOps/kubernetes
앞 글에서 Service, Ingress, NetworkPolicy로 Pod 간 통신과 외부 노출을 다뤘습니다. Pod를 띄우고 네트워크도 연결했는데, 아직 한 가지가 빠져 있습니다. 앱에 설정값을 어떻게 넣어주느냐는 문제입니다.이미지에 DB 호스트 주소를 하드코딩해두면, 환경이 바뀔 때마다 이미지를 다시 빌드해야 합니다. 패스워드 같은 민감 정보를 이미지에 박아놓는 건 보안 측면에서도 위험하고요. 이번 글에서는 설정과 민감 정보를 이미지에서 분리하는 두 가지 도구, ConfigMap과 Secret을 정리합니다.ConfigMap — 설정을 이미지에서 분리하기왜 필요한가DB 호스트, 로그 레벨, 기능 플래그 같은 설정값을 이미지 안에 넣으면, 값 하나 바꿀 때마다 이미지를 다시 빌드해야 합니다.개발·스테이..
5. Service와 Ingress - 네트워킹 정리
·
DevOps/kubernetes
앞 글에서 StatefulSet, DaemonSet, Job 같은 워크로드 리소스를 정리했습니다. Pod를 띄우는 방법은 어느 정도 감이 잡혔는데, 한 가지 빠진 게 있었습니다. 이 Pod들이 서로 어떻게 통신하고, 외부에서는 어떻게 접근하는지를 다루지 않았거든요. Deployment로 Pod 3개를 띄웠다고 합시다. 이 Pod들에게 요청을 보내려면 IP를 알아야 하는데, Pod는 생성될 때마다 IP가 바뀝니다. 롤링 업데이트라도 하면 기존 IP는 전부 사라지게 됩니다. 이 문제를 어떻게 해결하는지, 그리고 클러스터 외부에서는 어떻게 접근하는지를 이번 글에서 정리합니다.Service — 변하지 않는 연결점Pod IP는 왜 못 쓰는 걸까?Pod에 IP가 할당되긴 합니다. kubectl get pod -o ..
4. StatefulSet 부터 CronJob 까지
·
DevOps/kubernetes
앞 글에서 Pod → ReplicaSet → Deployment로 이어지는 워크로드 기초를 다뤘습니다.Deployment가 실무 표준이라는 건 알겠는데, 문제는 모든 앱이 Deployment에 딱 맞는 건 아니라는 점입니다. 데이터베이스처럼 상태를 가진 앱은? 모든 노드에 하나씩 띄워야 하는 에이전트는? 한 번 돌고 끝나는 배치 작업은? 이런 경우에는 어떻게 해야할까요? 이번 글에서는 용도별로 나뉘는 워크로드 리소스들과, 컨테이너의 상태를 어떻게 판단하는지(Probe), 그리고 한 Pod 안에 여러 컨테이너를 두는 패턴(Init/Sidecar)까지 정리합니다.StatefulSet — 상태가 필요한 앱을 위한 리소스Deployment로 데이터베이스를 띄우면 어떤 문제가 생길까요? Pod가 재시작되면 이름과..
3. Pod에서 Deployment 까지
·
DevOps/kubernetes
앞 글에서 쿠버네티스의 클러스터 아키텍처를 정리했습니다. 컨트롤 플레인과 워커 노드가 어떻게 역할을 나누는지는 이해했는데, 정작 "그래서 내 애플리케이션은 어떻게 올리지?"하는 궁금증이 생겼습니다. 이번 글에서는 쿠버네티스에서 앱을 실행하는 기본 단위인 Pod부터 시작해서, ReplicaSet을 거쳐 Deployment까지 왜 이런 계층이 필요한지를 단계적으로 정리합니다. Labels와 Selectors가 이 리소스들을 어떻게 연결하는지도 함께 다룹니다.Pod — 쿠버네티스의 최소 실행 단위Docker에서는 컨테이너가 기본 단위였는데, 쿠버네티스에서는 Pod가 그 역할을 합니다.Pod는 하나 이상의 컨테이너를 감싸는 래퍼(wrapper)인데, 같은 Pod 안의 컨테이너들은 네트워크(IP와 포트)와 스토리..
2. Kubernetes 클러스터 아키텍처
·
DevOps/kubernetes
앞 글에서 쿠버네티스의 핵심 기능으로 스케줄링, 셀프힐링, 오토스케일링을 꼽았는데, 정작 이걸 누가 어떻게 수행하는지는 짚지 않았습니다. 트러블슈팅이나 클러스터 설계 단계에서 막히지 않으려면 내부 구조를 알아둘 필요가 있습니다. 이 글에서는 쿠버네티스 클러스터의 전체 구조와 각 컴포넌트의 역할을 정리합니다.클러스터의 두 영역 — 컨트롤 플레인과 워커 노드쿠버네티스 클러스터는 크게 컨트롤 플레인(Control Plane) 과 워커 노드(Worker Node) 로 나뉩니다.컨트롤 플레인은 클러스터의 두뇌입니다. "Pod를 어디에 띄울지", "지금 상태가 원하는 상태와 맞는지", "새 요청이 들어왔는데 권한은 있는지" 같은 판단을 내리는 곳이죠. 워커 노드는 실제 작업이 수행되는 곳입니다.. 컨트롤 플레인이 ..
3-2. ArgoCD로 GitOps 배포 파이프라인 구축하기
·
프로젝트/엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기
지난 글에서 Helm으로 ArgoCD를 설치하고, 그 과정을 Ansible로 자동화했습니다.이 글은 "엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기" 시리즈의 3편 후기입니다. 이번에는 설치한 ArgoCD를 이용하여 helm chart를 사용한 Jira를 배포하는 과정을 정리합니다.helm으로 ArgoCD를 설치한 방법을, 이번에는 Github에 설정 파일을 올리는 방식으로 ArgoCD가 대신 실행하게 됩니다.ArgoCD란 무엇인가ArgoCD를 한 줄로 표현하면 "GitHub을 바라보는 K8s 전용 배포 자동화 도구”입니다.그런데 기존에 쓰던 Jenkins 같은 CI/CD 도구와는 무엇이 다를까 궁금했는데, 차이는 배포 방향에 있었습니다.기존 방식 (Push 모델)은 외부 파이프라인(J..
3-1. Helm으로 ArgoCD 설치하고, Ansible로 자동화하기
·
프로젝트/엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기
이번 글은 Kubernetes 클러스터에 ArgoCD를 올리는 과정을 정리한 글입니다.처음에는 직접 손으로 명령어를 치면서 동작 원리를 파악하고, 그 다음에 같은 과정을 Ansible Playbook으로 옮기는 순서로 진행했습니다. 직접 터미널에서 환경을 구성하고 → 자동화하는 흐름이 개념을 이해하는 데 훨씬 도움이 됐습니다.환경은 Mac 위에서 OrbStack으로 K3s 클러스터를 구성한 로컬 환경입니다.Helm이란 무엇인가Kubernetes에 애플리케이션을 배포하려면 Deployment, Service, ConfigMap, Ingress 같은 리소스를 하나하나 YAML로 작성해야 합니다. 애플리케이션 하나를 올리는 데 수십 개의 파일이 필요하기도 합니다.Helm은 이 과정을 단순하게 만들어주는 Kub..
1. 쿠버네티스란 무엇일까?
·
DevOps/kubernetes
Docker로 컨테이너를 다루는 데 어느 정도 익숙해진 뒤, 자연스럽게 드는 의문이 있었습니다. 컨테이너 하나 두 개는 docker run으로 충분한데, 이게 수십 개가 되면 어떻게 관리하지? 어떤 서버에 띄울지, 하나가 죽으면 누가 다시 살리는지, 트래픽이 몰리면 어떻게 늘리는지. 이런 문제들을 손으로 하나하나 해결하는 건 한계가 있다는 걸 느꼈고, 그래서 쿠버네티스(Kubernetes, 줄여서 k8s)를 본격적으로 공부하기 시작했습니다. 이 글에서는 쿠버네티스가 등장하게 된 배경과, 이 도구가 실제로 어떤 문제를 해결해주는지를 정리해보려고 합니다.컨테이너는 어떻게 격리되는가쿠버네티스 이야기로 들어가기 전에, 컨테이너가 왜 "격리된" 환경이라고 부르는지부터 짚고 가겠습니다.컨테이너는 가상머신처럼 별도의..
2-2. ansible-playbook 역할 기반으로 재구성하기
·
프로젝트/엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기
Ansible 플레이북 업그레이드 — 단일 파일에서 Role 기반 구조로이 글은 "엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기" 시리즈의 2편 후기입니다.지난 편에서 site_orbstack.yml 하나로 k3s 클러스터를 구축했습니다.플레이북이 정상적으로 동작하는 걸 확인하고 나서, 한 가지 생각이 들었습니다."이 파일, 나중에 클라우드 환경에서도 재사용할 수 있을까?" 솔직히 말하면 어렵습니다. DB 설정을 조금 고치려다 실수로 쉼표 하나를 지우면 k3s 클러스터 설치 전체가 영향을 받을 수 있고, 개발 환경과 운영 환경의 JVM 메모리 크기가 다른데 그걸 코드 안에서 분리할 방법도 마땅치 않습니다.처음부터 이 프로젝트의 목표가 run-book으로 재사용할 수 있는 템플릿을 만드는..
[Github] Github Projects를 Jira처럼 세팅하기 (사이드 프로젝트 관리)
·
DevOps/Github
Atlassian 엔지니어로 근무하며 기업들의 협업 도구(Jira, Confluence 등)를 운영하다 보니, 자연스럽게 체계적인 프로젝트 관리에 많은 관심을 가지게 되었습니다.최근 사이드 프로젝트를 시작하면서 진행 상황을 효율적으로 관리할 시스템이 필요했고, 이슈 관리 툴로 GitHub Projects를 선택하게 되었습니다.이번 글에서는 엔지니어의 관점에서 왜 GitHub Projects를 선택했는지에 대한 고찰과, 이를 Jira의 체계적인 이슈 관리 형태처럼 구성한 방법을 기록으로 남기고자 합니다.왜 GitHub Projects인가?Jira는 대규모 프로젝트와 엔터프라이즈 환경에서 매우 강력한 도구입니다. 하지만 소규모 인원이 빠르게 진행해야 하는 사이드 프로젝트 환경에서는 다음과 같은 점들을 고려해..
2-1. OrbStack + Ansible로 k3s 클러스터 구축하기
·
프로젝트/엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기
이 글은 "엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기" 시리즈의 2편입니다.프로젝트를 진행함에 따라, Atlassian 제품을 k8s 로 올리는 작업을 run-book으로 사용할 수 있는 템플릿 형태로 만들고 싶었습니다.누구든 이 문서를 보고 동일한 환경을 재현할 수 있고, 테스트 환경에서 서비스를 빠르게 올리고 내리는 것을 자유롭게 반복할 수 있도록 하기 위해, Ansible을 선택하게 됐습니다.수동 설치는 재현이 어렵고, 환경마다 결과가 달라질 수 있습니다. 플레이북으로 프로비저닝을 코드화해두면 노드를 날리고 다시 세워도 항상 동일한 환경이 보장됩니다. 테스트 환경에서 빠르게 서비스를 올리고, 내리는 것을 자유롭게 진행하기 위해 Ansible로 노드를 구성하게 되었습니다.이번 편..
1. 엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기
·
프로젝트/엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기
Atlassian을 K8s에 올리기로 한 이유는 무엇일까?이 글은 "엔터프라이즈 JVM 애플리케이션의 Cloud-Native 전환기" 시리즈의 1편입니다.프로젝트를 시작하게 된 계기혹시 서버가 OOM으로 죽어, 원인 파악을 위해 며칠동안 로그를 분석한 경험이 있으신가요? 저는 Atlassian 솔루션 엔지니어로 일하면서 꽤 기억에 남는 장애를 몇 번 겪었습니다. 분산 클러스터 환경에서 정확히 1분 주기로 Full GC가 터지는 문제였는데, 처음에는 원인조차 잡기가 어려웠습니다.서버에 직접 붙어서 GC 로그를 뒤지고, 메모리가 튀는 시점에 Heap Dump를 떠서 객체 참조 상태를 하나씩 분석하고 나서야 겨우 원인을 찾을 수 있었습니다.알고 보니 매일 돌아가는 배치 스크립트에서 객체를 필요 이상으로 만들어..
okbear3
bear's blog
상단으로

티스토리툴바