Tess's Infra Engineering Journey

Kubernetes가 Docker/Podman 위에서 무엇을 추가로 해주는지 이해하기Control Plane과 Worker Node 역할 구분하기Slurm과 비교해서 scheduler / node / workload 관계 잡기1. Kubernetes는 “컨테이너 실행기”가 아니다Docker/Podman만 있어도 container는 띄울 수 있음.문제는 container가 수십~수백 개가 되면 생김.예를 들어 서버 20대에 container 300개가 있다고 해보자.어느 서버에 띄울까?죽으면 누가 다시 띄울까?서버가 죽으면 다른 서버로 옮길까?CPU/Memory 부족한 서버는 피할까?서비스 IP는 어떻게 유지할까?container 수를 3개로 유지하려면?이걸 자동으로 관리하는 게 Kubernetes핵심은:..

Docker/Podman의 실행 구조와 차이를 이해하기image / container / volume / network를 운영 관점에서 구분하기컨테이너가 안 뜨거나 통신 안 될 때 기본 점검 순서를 익히기1. Image와 Container이 둘을 확실히 구분하면 절반은 끝이야.Image= 실행 전 템플릿= read-only layer 묶음Container= image를 실제로 실행한 instance= process + writable layer예를 들어:docker pull nginx하면 image를 받는 거고,docker run nginx하면 그 image로 container를 하나 실행하는 거야.같은 image로 container 여러 개 띄울 수 있어.nginx image ├─ container A..

Container가 VM과 어떻게 다른지 구조적으로 이해하기namespace, cgroup, filesystem이 container를 만드는 핵심이라는 걸 이해하기Docker/Podman 장애가 나면 host Linux 기준으로 어디부터 볼지 감 잡기1. Container는 “작은 VM”이 아니다가장 먼저 이거부터.VM:Physical Server └─ Hypervisor ├─ VM1 │ └─ Guest OS └─ VM2 └─ Guest OSContainer:Physical Server └─ Host Linux Kernel ├─ Container A ├─ Container B └─ Container CContainer는 자기 k..

load average, CPU utilization, run queue의 차이를 이해하기top, vmstat, pidstat를 각각 언제 쓰는지 구분하기CPU saturation인지, I/O wait인지, 특정 프로세스 문제인지 판별하기1. CPU 사용률이 높다 ≠ CPU가 부족하다예를 들어 128 CPU 서버에서:CPU usage = 90%라고 해도 반드시 문제는 아니야.128개 중 대부분이 유용하게 일하고 있을 수도 있지.반대로:CPU usage = 30%인데도 사용자는 느리다고 할 수 있어.왜냐하면 특정 프로세스가:single-thread라 한 코어만 100% 쓰고 있거나I/O를 기다리거나lock을 기다리거나NUMA 문제로 느릴 수도 있기 때문이야.즉 먼저 봐야 할 건:CPU를 많이 쓰는가?vsC..

장애를 증상 → 범위 → 최근 변경 → 계층별 확인 순서로 쪼개는 습관 만들기CPU/Memory/Network 같은 개별 지표보다 먼저 어디까지 정상인가?를 판단하기재시작 전에 반드시 남겨야 할 증거와 명령을 익히기1. 장애 대응에서 SRE 관점으로 질문하기1. 정확히 뭐가 안 되는가?2. 누구에게 안 되는가?3. 언제부터 안 되었는가?4. 어디까지는 정상인가?5. 직전에 무엇이 바뀌었는가?6. 어느 계층이 의심되는가? 2. Symptom -> Scope 증상을 구체화 1) 서버 전체가 느린 경우uptimetopvmstat 1*vmstat(Virtual Memory Statistics)CPU / process / memory / swap / I/O 상태를 한 번에 빠르게 보는 명령procs -------..