11개의 글이 있습니다.
Kubernetes 리소스를 관리하다 보면 한 번쯤 이런 고민을 하게 된다.Helm을 써야 할까, Kustomize를 써야 할까? 둘 다 여러 YAML을 효율적으로 관리하기 위한 도구지만, 접근 방식은 꽤 다르다.결론부터 말하면 나는 이렇게 나눠 쓰는 편이 가장 깔끔하다고 생각한다.외부에서 가져온 애플리케이션 → Helm내가 직접 만든 애플리케이션 → Kustomize왜 이렇게 나누는지 하나씩 살펴보자.Helm이란?Helm은 흔히 Kubernetes의 패키지 매니저라고 불린다.Deployment, Service, ConfigMap처럼 애플리케이션에 필요한 리소스를 Chart라는 단위로 묶고, values.yaml을 통해 설정값을 주입한다.예를 들면 이런 값들을 환경에 맞게 바꿀 수 있다.컨테이너 이미지와..
Helm 3 vs Helm 4 차이 쉽게 이해하기Kubernetes에서 여러 YAML 파일을 관리하다 보면 자연스럽게 Helm을 접하게 됩니다.Helm은 흔히 Kubernetes의 패키지 관리자라고 부릅니다.Linux Kubernetesapt → Helm.deb → Helm ChartDeployment, Service, ConfigMap 등의 Kubernetes 리소스를 하나의 Chart로 묶어 관리하고, 이를 설치하거나 업그레이드할 수 있습니다.그런데 현재 Helm에는 Helm 3와 Helm 4가 존재합니다.Helm 4에서 무엇이 달라졌는지, 특히 리소스를 업데이트하는 방식의 차이를 중심으로 쉽게 정리해보겠습니다.1. 먼저 Helm, Chart, Release 차이H..
![[Kubernetes] Helm 3 vs Helm 4 무엇이 달라졌을까? 3-Way Merge와 Server-Side Apply](https://img1.daumcdn.net/thumb/R750x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdna%2FdC1n9U%2FdJMcab6hjdD%2FAAAAAAAAAAAAAAAAAAAAALlQPrNKjLc9iHuUVyYMT6zHkd52L3rh4MprKzhUxP8O%2Fimg.png%3Fcredential%3DyqXZFxpELC7KVnFOS48ylbz2pIh7yKj8%26expires%3D1788188399%26allow_ip%3D%26allow_referer%3D%26signature%3DJcbSwleCx6TYxKxxTtqkOaIvb2s%253D)
Kubernetes를 운영하거나 CKA를 준비할 때 자주 사용하는 kubectl 명령어를 정리했습니다.모든 명령어를 나열하기보다는 실제로 반복해서 사용하는 명령어를 중심으로 구성했습니다. 명령어를 외우기보다는 조회 → 원인 확인 → 로그 확인 → 수정 → 배포 확인 흐름을 익히는 것이 중요합니다.목차kubectl 기본 구조클러스터와 Context 확인리소스 조회Namespace 관리Pod 관리로그 확인과 컨테이너 접속Deployment 관리Service와 Ingress 확인ConfigMap과 SecretYAML 적용과 수정Rollout과 롤백Node 운영Label과 Selector이벤트와 리소스 사용량Port Forward와 파일 복사권한 확인장애 대응 순서CKA에서 유용한 명령어필수 명령어 요약1. k..
쿠버네티스 아키텍처는 컴포넌트 이름을 따로 외우기보다 누가 클러스터 상태를 관리하는지, 누가 애플리케이션을 실행하는지, 그리고 요청이 어떤 경로로 이동하는지를 기준으로 이해하는 편이 정확합니다.핵심 구조Control Plane은 Kubernetes API와 클러스터 상태를 관리합니다. Worker Node는 할당된 Pod와 컨테이너를 실제로 실행합니다. 두 영역의 제어 통신은 대부분 kube-apiserver를 중심으로 이루어집니다.1. 클러스터의 두 영역: Control Plane과 Worker NodeKubernetes 클러스터는 하나 이상의 Control Plane과 하나 이상의 Worker Node로 구성됩니다.영역주요 컴포넌트역할Control Planekube-apiserver, etcd, ku..
쿠버네티스에서 애플리케이션을 운영하다 보면 결국 외부 트래픽을 어떻게 Pod까지 전달할지 고민하게 됩니다. Pod는 여러 개로 늘어날 수 있고, 장애가 나면 다시 생성되며, 배포 과정에서도 계속 바뀝니다. 이런 환경에서 특정 Pod 하나를 직접 바라보는 방식은 안정적이지 않습니다.그래서 쿠버네티스에서는 Service를 통해 Pod 앞에 고정된 진입점을 만들고, 필요에 따라 LoadBalancer나 Ingress를 붙여 외부 트래픽을 받아들입니다. 이 글에서는 쿠버네티스 환경에서 부하분산이 어떤 흐름으로 동작하는지, 특히 클라우드 환경에서 LoadBalancer 타입 Service가 어떻게 사용되는지 정리해보겠습니다.핵심은 단순합니다. 사용자는 고정된 주소로 접근하고, 쿠버네티스는 그 요청을 현재 살아있는..
ServicePod는 언제든 죽고 다시 생길 수 있다.그래서 Pod IP를 직접 보고 접근하면 안정적이지 않다.Service는 여러 Pod 앞에 붙는 고정 진입점이다.사용자는 Service IP로 접근하고, Service가 뒤쪽 Pod로 트래픽을 분산한다.정리하면, Pod는 일회성에 가깝고 Service는 고정된 주소 역할을 한다. 그래서 쿠버네티스에서 애플리케이션을 연결할 때는 보통 Pod가 아니라 Service를 바라본다.Service 타입타입역할사용 상황ClusterIP클러스터 내부에서만 접근 가능한 Service IP를 만든다.백엔드, DB, 내부 API처럼 외부에 공개하지 않는 서비스NodePort각 Node의 특정 포트를 통해 Service에 접근하게 한다.테스트 환경, 간단한 외부 노출Loa..
볼륨이 필요한 이유쿠버네티스에서 Pod 내부 컨테이너의 파일 시스템은 컨테이너가 종료되면 함께 사라지는 휘발성 저장소입니다.따라서 컨테이너 생명주기와 무관하게 데이터를 유지하기 위해서는 별도의 저장공간(Volume) 이 필요합니다.또한 각 컨테이너 별로 저장소는 공유가 되지 않기 때문에 데이터 공유가 필요할 때도 볼륨이 필요합니다.볼륨의 두 가지 주요 역할컨테이너 간 임시 저장 공간 공유컨테이너 데이터 영구 저장 공간 제공(중요)1. 컨테이너 간 임시 공간 공유 (emptyDir)컨테이너들이 서로 데이터를 주고받아야 하는 경우, Pod가 살아있는 동안만 유지되는 임시 저장소인 emptyDir을 사용할 수 있습니다.emptyDir은 Pod가 삭제될 때 함께 삭제되지만, 같은 Pod 내에서 컨테이너 재시작 ..
Kubernetes 클러스터 정리: 컨트롤 플레인 + 워커 노드Kubernetes 클러스터는 컨트롤 플레인(Control Plane)과 워커 노드(Worker Node)로 구성되며, 컨트롤 플레인은 클러스터의 두뇌 역할을, 워커 노드는 실제 애플리케이션 파드(Pod)를 실행하는 역할을 담당합니다.1. 컨트롤 플레인(Control Plane)컨트롤 플레인은 사용자가 정의한 원하는 상태(Desired State)를 유지하기 위한 모든 관리 및 조정 작업을 수행합니다.구성 요소별 역할구성 요소역할 및 기능통신의 중심API 서버 (Kube-apiserver)클러스터의 모든 통신과 요청 처리. etcd에 접근하는 유일 경로.모든 구성 요소etcd클러스터의 상태 저장소, 단 하나의 진실 근원(Source of Tr..
