N° 01 — 목록

'분류 전체보기' (197)

  1. Cloud & Infrastructure/Kubernetes

    Kubernetes - 14. kubeadm

    클러스터는 처음 어떻게 태어나나 — kubeadm이 컨트롤 플레인을 세우는 과정클라우드에선 "클러스터 만들기" 버튼 한 번이다(EKS/GKE/AKS가 알아서 만든다). 그런데 그 뒤에서 무슨 일이 일어나는가? 한 팀이 베어메탈에 직접 클러스터를 세우려다 막혔다 — kube-apiserver, etcd, scheduler, controller-manager, CNI, 인증서를 손으로 하나씩 세팅하려니 2주가 걸렸다. kubeadm은 이 절차를 자동화한다. "버튼 한 번"이 가리키는 것이 바로 kubeadm(또는 그와 비슷한 부트스트랩 도구)이다.이 글이 푸는 것은: 빈 서버 여러 대에서 시작해 한 클러스터가 처음 어떻게 태어나는가다. 핵심은 kubeadm이 인증서·etcd·컨트롤 플레인·CNI·노드 참여를..

    · 댓글
  2. Cloud & Infrastructure/Kubernetes

    Kubernetes - 13. node administration

    노드가 "나 지금 바쁘다"고 말하는 법 — cordon, drain, 그리고 node pressure유지보수를 위해 노드 한 대를 재부팅해야 한다. 그냥 재부팅 버튼을 누르면? 그 노드의 Pod 20개가 즉시 죽고, Service가 요청을 보내다 실패한다. Kubernetes의 정답은 다르다 — 먼저 그 노드에 새 Pod가 못 들어오게 막고(cordon), 기존 Pod를 안전하게 옮긴 뒤(drain) 재부팅한다. 이 절차를 모르면 "유지보수 = 무차별 중단"이 된다.이 글이 푸는 것은: 노드의 생명주기 상태(conditions), 노드가 스스로 "지금 압박 중"을 알리는 기전(node-pressure), 그리고 운영자가 노드를 안전하게 비우는 두 명령(cordon/drain)이다.노드의 condition..

    · 댓글
  3. Cloud & Infrastructure/Kubernetes

    Kubernetes - 12. autoscaling

    부하가 늘면 누가, 무엇을, 늘리나 — 세 종류의 autoscaling이 잰 축블랙 프라이데이 트래픽이 10배로 뛰었다. 팀은 두 가지를 동시에 원했다: Pod 수를 늘리고(트래픽 대응), 노드를 늘리고(부족한 자원 확보). 그런데 Kubernetes엔 autoscaling이 한 종류가 아니다 — Pod 수(HPA), Pod 자원(VPA), 노드 수(Cluster Autoscaler/Karpenter) 세 축이 각기 다른 질문에 답한다. 이 셋을 하나로 뭉개면 "autoscaling 켰는데 안 커진다"는 혼란이 생긴다.이 글이 푸는 것은: 세 autoscaling이 각각 무슨 질문에 답하고, 언제 어떤 걸 써야 하며, 왜 HPA와 VPA를 동시에 쓰면 곤란한가다.세 축의 autoscaling — 각기 다..

    · 댓글
  4. Cloud & Infrastructure/Kubernetes

    Kubernetes - 11. resource qos

    "메모리가 부족할 때 누구를 먼저 죽이나" — QoS가 결정하는 생존 서열한 노드에 10개의 Pod가 돌고 있었다. 메모리가 꽉 찼다. kubelet은 한 Pod를 골라 죽여야 했다. 그런데 왜 그 Pod였을까? 한 팀은 "랜덤인 줄 알았다"고 했다. 랜덤이 아니었다 — kubelet은 QoS(Quality of Service) 등급이라는 보이지 않는 서열에 따라 죽일 대상을 정한다. 그 서열을 모르면, 가장 중요한 Pod를 의도치 않게 가장 먼저 죽이는 대상으로 만든다.이 글이 푸는 것은: requests와 limits가 노드 자원을 어떻게 나누고, 그 결과 세 QoS 등급(Guaranteed/Burstable/BestEffort)이 어떻게 매겨지며, 노드 압박 시 누가 먼저 죽는가다.requests와..

    · 댓글
  5. Cloud & Infrastructure/Kubernetes

    Kubernetes - 10. config secret

    왜 앱 설정을 이미지에 구우면 안 되는가 — ConfigMap과 Secret한 팀이 같은 앱을 개발/스테이징/운영 세 환경에 띄운다. 앱은 DB 호스트, API 키, 타임아웃 값을 설정 파일에서 읽는다. 처음엔 환경마다 이미지를 따로 빌드했다 — 설정 파일만 다른 이미지 세 개. 그러다 설정이 바뀔 때마다 빌드 3번, 푸시 3번, 배포 3번에 지쳤다. 그리고 깨달았다: 이미지는 코드여야지 환경 설정이어선 안 된다.이 글이 푸는 것은: Kubernetes가 ConfigMap(비기밀 설정)과 Secret(기밀 값)으로 "설정을 이미지에서 빼내는" 방법, 그리고 Secret이 사실 "비밀"이 아니라는 진실이다.설정은 세 가지로 주입된다Kubernetes에서 컨테이너에 설정을 넣는 방법은 세 가지다. 모두 Co..

    · 댓글
  6. Cloud & Infrastructure/Kubernetes

    Kubernetes - 09. storage

    Pod가 죽어도 데이터는 남아야 한다 — 볼륨에서 CSI까지의 한 단계한 팀이 Postgres를 Deployment로 띄웠다. Pod는 로컬 디스크에 데이터를 썼다. 어느 날 노드가 재부팅됐고 Pod는 다른 노드로 재생성됐다 — 그런데 데이터가 없었다. "Pod가 다시 돌아왔는데 왜 데이터가 없지?" 이 질문은 Kubernetes 스토리지 모델을 이해하지 못했을 때 반드시 부딪히는 벽이다.이 글이 푸는 것은: Kubernetes에서 "데이터를 영속시키려면" Pod의 로컬 파일시스템이 아니라 볼륨 추상화(Volume → PV/PVC → StorageClass → CSI)를 거쳐야 한다는 것, 그리고 각 단계가 왜 존재하는가다.Pod의 로컬 파일시스템은 Pod와 함께 죽는다가장 먼저 정리할 사실: 컨테이너의..

    · 댓글