본문 바로가기

Cloud Native99

9. [Architecture]: Logging - PLG Stack 서비스를 잘 만드는 것만큼 중요한 게 바로 "운영 중인 서비스가 지금 어떤 상태인지"를 정확히 파악하는 것이다. 쿠버네티스 아키텍처에서 로깅(Logging)은 앱의 입에서 나오는 '말(로그 데이터)'을 관리하는 것이고,모니터링(Monitoring)은 '건강 상태(CPU/메모리 자원)'를 체크하는 것이라 보면 된다. 1. 쿠버네티스 로깅/모니터링 아키텍처 개요쿠버네티스는 기본적으로 제공하는 코어 파이프라인과 기능을 확장할 수 있는 서비스 파이프라인으로 나뉜다. 1. 코어 파이프라인 (Core Pipeline)자원 관리: 각 노드의 큐블렛(Kubelet)은 C-Advisor를 통해 CPU/메모리 정보를 수집하고, 이를 매트릭 서버(Metrics Server)로 모은다. 사용자는 kubectl top 명령으.. 2026. 1. 31.
8. [Architecture]: Storage - File / Object / Block Storage 쿠버네티스 아키텍처의 세 번째 기둥인 스토리지(Storage)에 대해 파헤쳐 보자. 데이터가 사라지면 서비스도 의미가 없기에, 엔지니어로서 스토리자를 어떻게 다루느냐는 매우 중요한 역량이다. 1. PV 생성 및 연결 방식 (Concept)쿠버네티스에서 스토리지를 사용하는 방법은 크게 세 가지 흐름으로 나뉜다. 다시 정리해보자.일반적인 방법 (Static): 이미 알듯이, 관리자가 미리 PV(Persistent Volume)를 만들어 두고, 사용자가 PVC(Persistent Volume Claim)를 통해 이를 예약하여 사용하는 방식이다.StorageClass 그룹화: StorageClass를 사용하여 PV들을 특정 그룹으로 묶어둔다. PVC를 만들 때 클래스 이름을 지정하면 해당 그룹 내에서 조건에.. 2026. 1. 31.
7-2. [Architecture]: Networking - Service Network 드디어 네트워킹 아키텍처의 마지막 퍼즐 조각인 서비스 네트워크(Service Network)와 이를 실질적으로 구현하는 프록시 모드(Proxy Mode)를 파헤칠 시간이다. 앞서 배운 파드 네트워크가 '실제 데이터가 흐르는 혈관'이라면, 서비스 네트워크는 그 흐름을 목적지로 정확히 굴절시키는 '교차로와 신호등'과 같다. 1. 서비스 네트워크의 핵심: 프록시 모드 (Proxy Mode)서비스는 실제 파드로 트래픽을 전달하기 위해 가상의 IP(Cluster IP)를 사용하며, 이 연결의 실체는 당연히 엔드포인트(Endpoint) 오브젝트와 각 노드의 큐브 프록시(kube-proxy)에 의해 관리된다. 그리고 이전에 알아본 파드 네트워크 단(Pod Network Area)으로 넘어가 과정이 그대로 진행되어서 .. 2026. 1. 31.
7-1. [Architecture]: Networking - Pod, Pause Container 지난 시간에는 네트워킹의 전체적인 개요를 훑어봤다면, 이번에는 파드 네트워킹의 심장이라 할 수 있는 Pause 컨테이너와 캘리코(Calico)의 상세한 동작 원리를 파헤쳐 보겠다. 1. 파드 네트워킹의 기반: Pause 컨테이너파드를 생성하면 우리가 직접 만든 컨테이너 외에도 Pause 컨테이너라는 녀석이 자동으로 생성된다. 이 녀석이 파드 내 네트워크의 '앵커' 역할을 한다.네트워크 네임스페이스의 공유: Pause 컨테이너가 고유한 IP와 네트워크 인터페이스(eth0)를 가진 네트워크 네임스페이스를 먼저 생성한다. 쿠버네티스는 이 공간을 파드 내의 모든 컨테이너가 같이 쓰도록 구성해준다.컨테이너 간 통신: 모든 컨테이너가 동일한 IP를 공유하기 때문에, 컨테이너끼리는 포트(Port)를 통해서만 구분.. 2026. 1. 31.
7. [Architecture]: Networking 쿠버네티스 네트워킹은 사실상 클러스터라는 거대한 유기체의 '혈관 시스템'과 같다. 이번 파트는 내용이 방대하고 복잡하지만, 인프라의 핵심인 만큼 아주 상세하고 꼼꼼하게 짚어서 살펴보아야한다. 이 분야는 기술이 방대하고 복잡하지만, 전반적인 아키텍처의 흐름만 정확히 잡아도 실무에서 길을 잃지 않는다. 1. 파드 네트워크 (Pod Networking): "실제 데이터가 흐르는 통로" 파드 네트워크는 클러스터 설치 시 설정한 Pod Network CIDR (예: 20.96.0.0/12) 대역 내에서 운영된다.컨테이너 간 통신 (Intra-Pod)파드가 생성되면, 고유 IP를 가진 인터페이스(eth0)가 생긴다.파드 내부의 여러 컨테이너는 이 네트워크 네임스페이스를 공유하며, 서로 localhost를 통해 .. 2026. 1. 31.
6. [Architecture]: Component - kube-apiserver, etcd, kube-schedule, kube-proxy, kube-controlelr-manager 쿠버네티스의 껍데기를 넘어 그 속살을 들여다보는 아키텍처(Architecture) 편이다. 쿠버네티스가 단순히 '명령을 실행하는 도구'가 아니라, 여러 컴포넌트가 유기적으로 대화하며 상태를 유지하는 '하나의 거대한 생명체'임을 이해하는 과정이다. 0. 쿠버네티스 아키텍처 개요 (Networking, Storage, Logging)쿠버네티스 클러스터는 명령을 내리는 마스터 노드와 실제로 일을 하는 워커 노드로 나뉜다. 본격적인 컴포넌트 설명에 앞서 전체적인 관리 영역을 살펴보자. 1. 컴포넌트 (Components) - 클러스터의 심장과 근육마스터 노드 (Control Plane): 클러스터의 전체적인 상태를 관리하고 명령을 하달하는 두뇌 역할을 한다. 여기에는 kube-apiserver, etcd, k.. 2026. 1. 31.
5. Autoscaler - HPA (Horizontal Pod Autoscaler) 서비스가 대박 나서 사용자가 몰릴 때 좋기는 하지만 밤새 서버를 늘리느라 고생하고 싶은 엔지니어는 없을 거다. 쿠버네티스는 이를 위해 오토스케일러(Autoscaler)라는 강력한 자동화 도구를 제공한다. 오토스케일러의 종류부터 HPA(Horizontal Pod Autoscaler)의 내부 동작 원리, 그리고 계산 공식까지 알아보자. 0. 쿠버네티스 오토스케일러의 3가지 종류 (HPA, VPA, CA)쿠버네티스에는 상황에 따라 골라 쓸 수 있는 세 가지 오토스케일러가 있다. 1. HPA (Horizontal Pod Autoscaler): 수평적 확장정의: 트래픽이 증가하면 파드의 개수(Replicas)를 늘리는 방식이다. 이를 스케일 아웃(Scale-out)이라 한다.권장 조건기동 속도: 빠른 복구가 생.. 2026. 1. 30.
4. Ingress - Nginx 이전까지 서비스(Service)를 통해 클러스터 내부 통신을 정복했다면, 이번엔 클러스터의 '정문'을 만드는 인그레스(Ingress)를 파헤쳐 볼 시간이다. 인그레스는 단순히 외부 노출을 넘어 L7 스위치처럼 경로를 제어하고 보안을 책임지는 아주 똑똑한 녀석이다. 1. 인그레스의 필요성과 사용 목적기존에는 외부 접근을 위해 각 서비스마다 IP나 포트를 할당해야 했지만, 인그레스는 하나의 진입점(도메인)에서 여러 서비스를 관리하게 해준다.서비스 로드 밸런싱: 쇼핑몰처럼 쇼핑(/), 고객센터(/customer), 주문(/order) 등 경로(Path)별로 서로 다른 파드(+서비스)에 연결해준다. 이는 고가의 L4/L7 하드웨어 스위치 역할을 소프트웨어로 대체하는 것과 같다.카나리 업그레이드 (Canary .. 2026. 1. 29.
3-2. Authorization - RBAC, Role, RoleBinding 지난번 인증(Authentication)을 통해 '신분증'을 확인했다면, 이번에는 그 신분증을 가진 자가 "무엇을 할 수 있는지"를 결정하는 인가(Authorization), 그중에서도 가장 핵심인 RBAC(Role-Based Access Control)에 대해 파헤쳐 보겠다. 이 내용은 보안의 핵심이다. 1. RBAC의 기본 개념과 구조 (전반적인 개요)쿠버네티스 자원은 관리 범위에 따라 크게 두 가지로 나뉜다.클러스터 단위 자원: Node, PV, Namespace 등 클러스터 전체에 영향을 미치는 자원.네임스페이스 단위 자원: Pod, Service 등 특정 격리 공간 내에서 관리되는 자원.1-1. Role과 RoleBinding (네임스페이스 수준)ServiceAccount가 주체라고 가정하자.. 2026. 1. 28.
3-1. Authentication - X509 Certs, kubectl, ServiceAccount 쿠버네티스라는 거대한 성채를 지탱하는 가장 중요한 기둥 중 하나가 바로 인증(Authentication)이다. "들어올라는 사람이 누구인지"를 증명하지 못하면 API 서버는 단 한 줄의 정보도 내주지 않는다. API 서버에 접근하는 세 가지 핵심 인증 방법을 실무 관점에서 정리해보자. 1. X509 Client Certs: 인증서 기반의 정석 접근가장 보안이 강력하고 표준적인 방법으로, HTTPS(6443 포트)를 통해 통신한다. 1. 먼저 클러스터에 6443 포트로 API 서버가 열려 있고, 사용자가 여기로 HTTPS 접근을 하려는 것이다.2. 쿠버네티스 설치 시에 kubeconfig라고 이 클러스터에 접근할 수 있는 정보들이 들어 있는 파일이 있다. 3. 이 파일 안에 이렇게 인증서 내용이 있는데,.. 2026. 1. 27.
3. Accessing API - Overview 쿠버네티스의 심장이라 할 수 있는 API 서버 접근(Accessing API)에 대해 알아보자. 클러스터의 모든 자원 관리와 제어는 결국 이 API 서버를 통하는 통로를 어떻게 설계하고 보안을 유지하느냐에 달려 있다. 1. API 서버의 역할과 기본 접근법중앙 통제실: 마스터 노드에 위치한 API 서버는 쿠버네티스 자원을 생성하거나 조회할 수 있는 유일한 경로다.kubectl 활용: 우리가 흔히 사용하는 CLI 도구인 kubectl 또한 이 API 서버에 접근하여 정보를 가져오는 방식이다.보안 접근 (HTTPS): 기본적으로 인증서를 가진 사용자만 HTTPS를 통해 보안 접근이 가능하다.프록시 접근 (HTTP): 관리자가 kubectl proxy 명령을 실행해 준 경우, 인증서 없이 HTTP로 간편하게.. 2026. 1. 27.
2. Volume - Dynamic Provisioning, StorageClass, Status, ReclaimPolicy 이번엔 단순한 볼륨 연결을 넘어, 인프라 관리를 자동화하는 다이나믹 프로비저닝(Dynamic Provisioning)과 볼륨의 생명주기(Lifecycle)를 다루는 아주 중요한 내용이다. 0. 볼륨의 기초와 다이나믹 프로비저닝 (Dynamic Provisioning)볼륨은 데이터를 안정적으로 유지하기 위해 클러스터와 분리되어 관리된다. 관리자가 미리 공간을 확보하는 수동 방식의 번거로움을 해결하기 위해 다이나믹 프로비저닝이 등장했다. 1) 볼륨의 종류와 접근 모드외부망(Cloud): AWS, GCP, Azure와 같은 클라우드 스토리지를 클러스터와 연결한다.내부망(Internal): 노드의 물리 공간을 쓰는 hostPath, Local 볼륨과 StorageOS, Ceph, NFS 같은 온프레미스 솔.. 2026. 1. 27.
1. Service - Headless, Endpoint, ExternalName 이전까지 서비스의 겉모습을 배웠다면, 이번에는 서비스의 속살(Headless, Endpoint, ExternalName)을 파헤치는 시간이다. 인프라를 설계할 때 IP는 언제든 바뀔 수 있는 가변적인 존재다. 엔지니어가 되려면 IP가 아닌 '이름(DNS)'으로 통신하는 법을 완벽히 마스터해야 한다. 1. [복습] 서비스의 기본 3요소와 한계쿠버네티스 클러스터는 내부망(예: 192.168.x.x) 위에 파드 전용 IP(20.x.x.x)와 서비스 전용 IP(10.x.x.x) 대역을 별도로 가진다.ClusterIP: 클러스터 내부에서만 접근 가능하다. 내부망의 다른 서버들은 직접 호출할 수 없다.NodePort: 클러스터 노드들에 3만 번대 포트를 열어주어 내부망 사용자가 접근하게 해준다.내부망에 IP를 할.. 2026. 1. 27.
10-1. CI/CD 파이프라인 보안 내재화, Kubernetes, AI 도구 보안 통합 이번 파트는 AWS EKS의 보안 아키텍처, 아이덴티티 관리(IRSA vs Pod Identity), 네트워크 보안 정책, 그리고 CI/CD 파이프라인 보안의 기초를 다룬다. 핵심 주제는 EKS 클러스터 보안 구조, IAM 및 권한 관리 고도화, 네트워크 정책(NetPol), DevSecOps 파이프라인 보안 기초와 같다. 그리고 AI(Claude, Cursor) 연계 보안을 다루자. 1. Kubernetes 및 AWS EKS 보안 아키텍처 기본 구조의 이해 쿠버네티스는 마스터 노드(Control Plane)와 워커 노드(Worker Node)로 구성되며, AWS EKS는 마스터 노드의 관리를 AWS가 책임지는 구조임 추상화된 인프라 보안온프레미스에서는 서버, 스토리지, 네트워크를 직접 구성했으나,.. 2026. 1. 27.
4. Pod - Node Scheduling [중요] 쿠버네티스 운영의 꽃은 '원하는 곳에 파드를 배치하는 기술'이다. 단순히 스케줄러에게 모든 걸 맡기는 걸 바꿀 때가 왔다. 시스템의 가용성과 성능을 위해 우리가 직접 배치를 설계해야 한다. 노드 네임(nodeName)과 노드 셀렉터(nodeSelector)와 같은 기초적인 개념과 더불어 본격적으로 나머지 고급 기능들에 대해 상세하게 파헤쳐보자. 0. 노드 스케줄링 기초: "내 파드는 어디로 가는가?"쿠버네티스 클러스터는 여러 노드의 자원을 공유하며, 기본적으로 스케줄러가 자원 상황(CPU, Memory 등)을 판단해 가장 여유 있는 노드에 파드를 할당한다.1) 노드 스케줄링의 필요성사용자 의도 반영: 스케줄러의 자동 배정 외에 사용자가 특정 목적으로 노드를 직접 지정해야 할 때가 있다.관리적 제한: .. 2026. 1. 25.
3. Pod - QoS Classes (request, limit) 클러스터 운영 중 자원이 부족할 때 어떤 파드를 먼저 희생시킬지 결정하는 QoS(Quality of Service) 클래스는 서비스의 생존권과 직결되는 아주 중요한 개념이다. 단순히 설정법을 외우는 게 아니라, "자원이 부족해졌을 때, 누가 먼저 죽을 것인가"라는 냉혹한 우선순위의 관점에서 이해해야 한다. 1. 파드 QoS(Quality of Service)의 핵심 개념노드에 자원이 한정된 상황에서 특정 파드가 자원을 더 요구하거나 전체 자원이 고갈되면, 쿠버네티스는 앱의 중요도에 따라 자원을 회수한다. 이때 파드를 다운시키는 우선순위를 결정하는 것이 바로 QoS 클래스다.제거 우선순위 (Eviction Priority)자원이 부족할 때 쿠버네티스는 아래 순서대로 파드를 정리하여 자원을 반환(=회수).. 2026. 1. 25.
2. Pod - ReadinessProbe, LivenessProbe 파드가 'Running' 상태라고 해서 서비스가 '정상'이라고 믿는 것만큼 위험한 착각은 없다는 것을 알았다. 인프라가 살아있는 것과 애플리케이션이 비즈니스 로직을 처리할 준비가 된 것은 완전히 다른 이야기다. 이제, 서비스의 안정성을 극대화하는 두 가지 핵심 장치인 ReadinessProbe와 LivenessProbe에 대해 알아볼 것이다. 1. 파드 프로브(Probe)의 필요성: 안정적인 서비스 운영 전략먼저 어떤 상황에서 이 도구들이 필요한지부터 이해해야 한다.더보기1. 파드 안에 컨테이너가 생기고 파드와 컨테이너의 상태가 러닝이 되면서 그 안에 있는 앱도 정상적으로 구동이 되고 있을 것.2. 그리고 서비스에 연결이 되고 이 서비스의 IP가 외부에 알려지면서 많은 사람들이 실시간으로 접근.3. .. 2026. 1. 24.
1. Pod - Lifecycle 파드(Pod)의 라이프 사이클(Lifecycle)을 이해하는 것은 쿠버네티스 트러블슈팅의 절반을 마스터하는 것과 같다. 파드가 왜 죽었는지, 왜 서비스에 연결되지 않는지는 모두 이 생애 주기 안에 답이 있다. 1. 파드 라이프 사이클의 본질과 중요성사람이 태어나서 성장하고 생을 마감하듯, 파드도 생성부터 소멸까지 정해진 과정을 거친다.기능적 연관성: 라이프 사이클은 앞으로 배울 Readiness/Liveness Probe, QoS, Restart Policy 등 쿠버네티스의 핵심 기능들과 밀접하게 연결되어 있다.내용이 다소 복잡할 수 있으나, 모두 알아야한다. 이를 모르면 인프라의 동적인 변화를 예측할 수 없으므로 반드시 이해하고 넘어가야 한다.행동의 변화: 파드가 어느 단계에 있느냐에 따라 쿠버네티스.. 2026. 1. 24.
8. DaemonSet, Job, CronJob 서비스가 항상 떠 있어야 하는지, 아니면 할 일만 하고 퇴근해도 되는지에 따라 사용하는 도구가 달라진다. 각 오브젝트의 '생명 주기'와 '목적'을 명확히 구분하는 연습부터 한다. 1. 컨트롤러별 핵심 개념과 사용 시점 쿠버네티스에는 파드를 관리하는 여러 관리자가 있다. 상황에 맞춰 골라 쓰는 법을 익혀야 한다.DaemonSet (데몬셋): 노드의 자원 상태와 상관없이 모든 노드에 파드를 하나씩 배치한다.성능 수집(Prometheus), 로그 수집(Fluentd), 네트워크 프록시(Kube-proxy)처럼 노드 전체를 관리해야 하는 에이전트 설치에 필수적이다. 즉, 이렇게 각각의 노드마다 하나씩 설치해야하는 서비스들이 있는 것을 때 필수적이다..ReplicaSet은 자원이 많이 남은 곳에 파드를 많이 .. 2026. 1. 24.
7. Deployment - Recreate, RollingUpdate 개발보다 어려운 게 '무중단 배포'다. 서비스가 중단되는 순간 고객은 떠나고, 그 책임은 우리가 진다. 이번에는 서비스를 어떻게 안전하게 업그레이드할 것인지, 그 전략과 디플로이먼트(Deployment)의 실체에 대해 알아보자. Deployment는 현재 한 서비스가 운영 중인데, 이 서비스를 업데이트 해야해서 재배포를 해야될 때 도움을 준다. 1. 서비스 업그레이드 전략: 상황에 맞는 선택 인프라를 어떻게 갈아끼울 것인가는 자원 상황과 서비스 중요도에 따라 결정된다.Recreate (재생성): 기존 파드를 모두 죽이고 새 버전을 띄운다. 자원 사용량은 적지만 다운타임(Downtime)이 반드시 발생한다. 일시 정지가 허용되는 서비스에만 쓴다.파드 삭제 → 다운타임 → 자원 사용량 없어짐.Rolli.. 2026. 1. 23.

티스토리툴바