들어가며 이전 글에서는 Kubernetes 볼륨의 개념과 PV, PVC, StorageClass, CSI 드라이버의 동작 원리를 살펴봤습니다. 이번 글에서는 실전 활용과 운영에 초점을 맞춥니다: AccessModes: 누가 어떻게 접근할 수 있나? “다른 Pod에서도 이 볼륨을 쓸 수 있나요?”라는 질문의 답은 AccessMode에 달려 있습니다. 세 가지 AccessMode AccessMode 약어 의미 ReadWriteOnce RWO 단일 노드에서 읽기/쓰기 ReadOnlyMany ROX 여러 노드에서 읽기 … 더 읽기
들어가며 이전 글에서는 Kubernetes에서 Pod가 어떻게 생성되고 실행되는지 살펴봤습니다. Scheduler가 노드를 선택하고, kubelet이 컨테이너를 실행하는 과정을 알게 됐죠. 그런데 한 가지 문제가 있습니다. Pod가 죽으면 그 안의 데이터도 함께 사라집니다. 데이터베이스를 Pod로 운영한다고 생각해보세요. Pod가 재시작될 때마다 데이터가 날아간다면 서비스가 될 수 없겠죠. 그래서 Kubernetes는 Pod의 라이프사이클과 독립적인 영구 저장소(Persistent Storage)를 제공합니다. 이 글에서는 다음 … 더 읽기
들어가며 이전 글에서는 Kubernetes 클러스터 내부에서 Pod끼리 어떻게 통신하는지 살펴봤습니다. CNI 플러그인이 네트워크를 구성하고, CoreDNS가 서비스 디스커버리를 담당한다는 것을 알게 됐죠. 그런데 그 Pod는 애초에 어떻게 생성되고 실행되는 걸까요? kubectl apply -f deployment.yaml을 실행하면 마법처럼 Pod가 생성됩니다. 하지만 그 사이에는 여러 구성요소가 협력하는 복잡한 과정이 있습니다. 이 글에서는 다음 질문들에 답합니다: 전체 그림: 컨트롤 플레인과 … 더 읽기
들어가며 이전 글에서는 외부 사용자의 요청이 어떻게 Kubernetes 클러스터 내부의 Pod까지 도달하는지 살펴봤습니다. 외부 LB → NodePort → Ingress Controller → Service → Pod 으로 이어지는 흐름이었죠. 그런데 한 가지 의문이 남습니다. 클러스터 내부에서 Pod끼리는 어떻게 통신할까요? 예를 들어, 주문 서비스 Pod이 사용자 서비스 Pod의 API를 호출할 때 실제로 어떤 일이 벌어질까요? 이 글에서는 다음 … 더 읽기
서론 Kubernetes를 사용하다 보면 “내 요청이 정확히 어떤 경로로 Pod까지 도달하는 걸까?”라는 의문이 생깁니다. kubectl apply로 Ingress와 Service를 배포하면 마법처럼 트래픽이 흘러가지만, 문제가 생겼을 때 어디를 봐야 할지 막막해지는 경험을 해보셨을 겁니다. 이 글에서는 외부 사용자의 HTTP 요청이 Kubernetes 클러스터 내부의 Pod까지 도달하는 전체 과정을 단계별로 분석합니다. 각 구간에서 어떤 컴포넌트가 어떤 역할을 하는지, 그리고 … 더 읽기