N° 01 — 목록
'Cloud & Infrastructure' (51)
-
Cloud & Infrastructure/KubernetesKubernetes - 04. pod
왜 컨테이너 하나만 띄우면 "Pod"라는 포대까지 필요한가처음 Kubernetes를 배우는 사람은 거의 다 같은 의문을 갖는다. 컨테이너를 하나 띄우고 싶을 뿐인데, 왜 kind: Pod에 containers: 배열을 넣고 그 안에 컨테이너를 적어야 하나? Docker처럼 그냥 컨테이너를 실행하면 안 되나?이 질문은 사소해 보이지만 Kubernetes의 가장 근본적인 설계 결정을 건드린다. 왜 Kubernetes는 컨테이너를 직접 다루지 않고 Pod라는 한 겹 더 두른 단위를 배포의 최소 단위로 삼았는가? 이 글의 답은 단순하다 — Pod는 컨테이너가 아니라 "함께 죽고 함께 사는 컨테이너들의 묶음"이며, 이 묶음이 공유하는 것(네트워크·스토리지·생명)이 Kubernetes의 모델을 만든다.Pod는 컨테..
-
Cloud & Infrastructure/KubernetesKubernetes - 03. api machinery
한 번 쓰고 영원히 본다 — watch/list가 조정 루프를 어떻게 지탱하는가kubectl get pods를 1초마다 돌리는 모니터링 스크립트를 본 적이 있다. 잘 동작했지만 apiserver에 1초마다 전체 Pod 목록을 요청했다 — 클러스터에 Pod가 5000개면 매초 5000개를 직렬화해 보내는 셈이다. 어느 순간 apiserver가 CPU 100%에 도달했고, 모니터링이 클러스터를 죽이는 역설이 벌어졌다. 해결책은 폴링을 멈추는 게 아니라 watch로 바꾸는 것이었다.이 글이 푸는 질문: Kubernetes에서 수십 개의 컨트롤러가 동시에 돌면서 매번 "상태가 바뀌었나?"를 확인하는데, 왜 apiserver는 붕괴하지 않는가? 답은 list-watch 패턴과 리소스 버전(resourceVersi..
-
Cloud & Infrastructure/KubernetesKubernetes - 02. architecture
클러스터의 두뇌와 손 — 컨트롤 플레인과 노드가 어떻게 갈리는가한 클러스터에서 노드 3대가 동시에 재부팅됐다. Pod들은 전부 죽었고, 운영자는 "클러스터가 죽었다"고 보고했다. 하지만 정확히 무엇이 죽은 걸까? 재부팅된 노드 위의 kubelet은 다시 살아나자마자 apiserver에 "내가 돌아왔다, 내 담당 Pod들을 다시 띄워 달라"고 물었고, 90초 안에 Pod들이 복구됐다. 죽은 건 Pod였지 클러스터가 아니었다.이 사례가 보여주는 건 Kubernetes의 가장 중요한 분리 — 결정하는 층(컨트롤 플레인)과 실행하는 층(노드) — 이다. 이 분리를 이해하면 "무엇이 죽었는지, 그래서 무엇이 복구되는지"를 정확히 읽을 수 있다. 이 글은 그 두 층이 정확히 어떤 부품으로 이뤄지고 어떻게 통신하는지..
-
Cloud & Infrastructure/KubernetesKubernetes - 01. overview
Kubernetes는 컨테이너를 실행하지 않는다2014년 즈음, 한 팀이 매일 새벽 서버 50대에 SSH로 접속해 같은 설정을 복사하고 있었다. 컨테이너는 이미 있었다. Docker가 "한 번 빌드하면 어디서든 돌아간다"고 약속했고, 실제로 그랬다. 그런데 팀은 여전히 밤을 새웠다. 컨테이너를 실행하는 일은 해결됐는데, "어디에, 몇 개를, 어떻게 계속 띄워 둘까"를 결정하는 일은 사람이 하고 있었다.이 글이 푸는 질문은 하나다. Kubernetes는 정확히 이 "결정"의 어느 부분을 가져갔는가? 그리고 왜 그 방식(선언적 API + 조정 루프)이 컨테이너를 더 빨리 띄우는 것보다 훨씬 근본적인 변화였는가?Kubernetes가 "실행"하지 않는다는 것의 의미흔한 오해부터 꺼내자. Kubernetes는 컨..
-
Cloud & Infrastructure/Operating SystemLinux - 11. services
메일은 한 번에 가지 않는다 — 인터넷 서비스의 역할 분담메일을 보냈다. 바로 도착할까? 아니다. 메일은 송신자 → 송신 서버(MTA) → 수신 서버(MTA) → 메일함(MDA) → 수신자(MUA) 의 다단계 흐름을 거친다. 어디쯤 걸려 지연되는지 알려면 이 흐름을 알아야 한다. 단일 "메일 서버"라는 말이 감추는 것이 바로 이 분업이다.서버의 주된 용도가 바로 이 서비스들이다 — 웹, 이름 해석(DNS), 메일, 파일 공유, 데이터베이스. 각각 고유한 프로토콜·포트·패키지·설정 파일을 갖는다. 이 글은 그 매핑과, 서비스가 "설치했는데 외부 접속이 안 될 때"의 3단계 진단을 다룬다.서비스는 역할별 부서다 — 포트가 내선 번호다서버는 하나의 회사, 각 서비스는 부서이자 안내 데스크다. 각 부서에 고유 ..
-
Cloud & Infrastructure/Operating SystemLinux - 10. security
설정은 다 맞는데 403이 난다 — 9할은 SELinux다httpd 설정을 다 맞췄다. 파일도 /var/www/html에 넣었다. 그런데 브라우저에서 403 Forbidden. Apache 설정만 뒤지다 한참을 헤맨다 — 그런데 진짜 원인은 SELinux인 경우가 압도적으로 많다. 파일을 cp/mv로 옮기면 보안 레이블(컨텍스트)이 잘못되어 SELinux가 접근을 막는 것이다.리눅스 보안은 다층 방어(defense in depth)다. 전통 권한(DAC) 위에 강제 접근 제어(SELinux), 네트워크 검문(firewalld), 인증(PAM)이 올려져 있고, 각 층이 독립적으로 통과돼야 접근이 허용된다. 이 장을 모르면 "설정 다 맞는데 왜 안 되지?"의 원인을 못 찾고, 방화벽·인증 정책도 못 짠다. ..