둘 다 쿠버네티스(Kubernetes) 환경에서 애플리케이션을 배포하고 관리한다는 점에서 목적은 비슷하지만, 작동하는 방식과 역할의 수준(추상화 단계)에서 큰 차이가 있습니다.쉽게 비유하자면, kubectl은 컴퓨터의 파일 관리자나 기본 터미널 명령어 같고, helm은
디테일한 볼륨 종류를 알아보기 전에, 이 두 녀석의 관계부터 명확히 짚고 넘어가야 합니다. 아주 쉽게 비유하자면 "하드웨어를 사서(Volume), 컴퓨터의 특정 폴더에 연결(VolumeMounts)하는 것"과 같습니다.spec.volumes (어디서 가져올 것인가?):

🤖 ChatGPT가 그려준 K8S Component 관련 이미지먼저 Kubernetes 클러스터의 큰 구조를 살펴보자.Control Plane에는 대표적으로 다음 컴포넌트가 존재한다.Worker Node에서는 대표적으로 다음 컴포넌트가 동작한다.Kubernetes 공

Kubernetes를 처음 공부하면 Pod, ReplicaSet, Deployment, Service 같은 리소스를 각각 배우게 된다.하지만 개별 정의만 외우면 실제로 이 리소스들이 어떤 관계를 가지고 동작하는지 이해하기 어렵다.전체 구조를 먼저 단순화하면 다음과 같다
Kubernetes에서 애플리케이션을 실행하다 보면 데이터 저장 문제가 생긴다.Pod와 컨테이너는 영구적인 존재가 아니다. 장애나 배포로 인해 기존 Pod가 삭제되고 새로운 Pod로 교체될 수 있으며, 새 Pod가 반드시 이전 Pod와 같은 Node에서 실행된다는 보장
Service, Ingress, Gateway는 트래픽을 어디로 보낼지 정하는 쪽에 가깝다. NetworkPolicy는 어떤 트래픽을 허용할지 정한다. 이 차이를 잡고 들어가면 troubleshooting할 때도 어느 리소스를 봐야 하는지 빨리 좁힐 수 있다.참고 문서
Kubernetes에서 Pod의 STATUS가 Running이라고 해서 애플리케이션이 트래픽을 받을 준비까지 끝났다는 뜻은 아니다. 컨테이너 프로세스는 떠 있을 수 있지만, readiness probe가 실패하면 Pod는 Ready 상태가 되지 않는다. 이 경우 Dep
Kubernetes RBAC를 처음 배울 때 자주 헷갈리는 지점이 있다. Role과 ClusterRole, RoleBinding과 ClusterRoleBinding, 그리고 --role과 --clusterrole의 경계다. 이름이 비슷해서 “권한을 준다”는 느낌만 남기
Helm chart는 Kubernetes 리소스를 재사용 가능한 패키지와 템플릿으로 묶어 배포할 수 있게 해주는 방식이다. values 파일만 바꿔도 같은 chart에서 환경별 manifest를 만들 수 있다.Argo CD는 Git repository에 선언된 애플리케
Kubernetes를 공부하다 보면 CNI, CRI, CRD 같은 약어가 자주 나온다. 이름은 비슷하지만 서로 다른 층의 개념이다. CNI는 Pod network를 만드는 쪽에 가깝고, CRI는 kubelet이 container runtime과 대화하는 인터페이스다.