makgol's note – 플랫폼·인프라

01 GPU 조합이 성능을 바꾸는 조건

Wed, 21 Oct 2026 00:00:00 +0900

01 · GPU 조합이 성능을 바꾸는 조건

같은 네 장이어도 연결은 다를 수 있습니다

파드에 nvidia.com/gpu: 4를 요청하면 GPU 네 장을 받습니다. 이 요청에는 어느 GPU끼리 연결돼 있어야 하는지까지 담겨 있지 않습니다. 노드 안의 GPU 쌍이 모두 같은 경로로 통신한다면 선택에 따른 차이는 작겠지만, PCIe 스위치나 CPU 소켓을 건너야 하는 쌍이 섞여 있다면 조합에 따라 지연과 대역폭이 달라질 수 있습니다.

02 요청한 GPU는 누가 골라 주는가

Wed, 21 Oct 2026 00:00:00 +0900

02 · 요청한 GPU는 누가 골라 주는가

노드 선택과 GPU 선택은 다른 단계입니다

nvidia.com/gpu: 4는 GPU 네 장을 요청하는 문법입니다. NVLink로 이어진 네 장을 지정하는 문법은 아닙니다. 01편의 PCIe 서버처럼 GPU 쌍마다 연결 경로가 다르다면, 개수를 충족한 뒤에도 어느 조합을 줄지 결정해야 합니다.

03 GPU 할당에 DRA가 필요한 때 — 개수는 device plugin, 노드 간 NVLink는 ComputeDomain

Wed, 21 Oct 2026 00:00:00 +0900

03 · GPU 할당에 DRA가 필요한 때

GPU를 개수로 요청해 쓰고 있다면 DRA(Dynamic Resource Allocation)가 GA(정식 제공)가 됐다는 이유만으로 할당 방식을 옮길 필요는 없습니다. 2026-10-21에 확인한 설치 문서와 운영 예시에서는 device plugin과 GPU Operator가 여전히 기본 경로입니다. 장치의 메모리·모델·위치까지 선택해야 하거나, GB200처럼 NVLink가 노드를 넘어 연결되는 환경에서는 DRA가 맡는 일이 달라집니다.

04 학습 잡을 가까운 노드에 모으려면 — 토폴로지 라벨과 Kueue TAS

Wed, 21 Oct 2026 00:00:00 +0900

04 · 학습 잡을 가까운 노드에 모으려면

노드 사이에서 어떤 경계를 넘는지가 중요합니다

분산 학습 잡이 GPU를 충분히 확보했어도 파드들이 혼잡한 링크를 사이에 두고 흩어지면 성능이 떨어질 수 있습니다. 01편의 노드 안 NVLink·PCIe 경로와 02편·03편의 GPU 할당을 확인한 뒤에는, 한 잡의 파드들이 노드 사이에서 어느 네트워크 경계를 넘는지 살펴야 합니다.

05 노드 간 스케줄링 2부 — Volcano·KAI·Slurm 비교

Wed, 21 Oct 2026 00:00:00 +0900

05 · 노드 간 스케줄링 2부 — Volcano·KAI·Slurm 비교

1. 배치 요구와 토폴로지 정보의 공급자를 정한다

여러 노드의 GPU를 가까이 배치하려면 스케줄러에 물리적 위치를 알려 주어야 합니다. 클라우드의 CCM(클라우드 컨트롤러 매니저)이 라벨을 붙일지, Topograph가 정보를 수집할지, Volcano의 자동 발견을 쓸지부터 정해야 합니다. 04편에서는 노드 라벨로 토폴로지를 알리고 Kueue TAS(토폴로지 인지 스케줄링)에 연결했습니다. 여기서는 그 정보를 다른 스케줄러가 어떻게 배치 규칙으로 바꾸는지 비교합니다.

06 GPUDirect RDMA 1부 — 파드의 NIC이 GPU 메모리에 닿는 조건과 준비

Wed, 21 Oct 2026 00:00:00 +0900

06 · GPUDirect RDMA 1부 — 파드의 NIC이 GPU 메모리에 닿는 조건과 준비

1. GPU에서 NIC까지의 경로를 확인한다

GPU를 할당받은 파드가 노드 밖으로 데이터를 보내려면 NIC(네트워크 인터페이스 카드)까지 데이터를 전달해야 합니다. 일반 경로에서는 GPU 메모리의 데이터를 호스트의 고정 메모리로 복사하고 NIC이 그 버퍼를 읽습니다. GPUDirect RDMA는 NIC이 GPU 메모리를 직접 읽고 쓰게 하는 PCIe 기능입니다. 파드가 GPU를 할당받는 것만으로 이 직접 경로까지 준비되지는 않습니다. 장치 할당의 일반 원리는 03편에서 다뤘습니다.

07 GPUDirect RDMA가 실제로 쓰이는지 확인하고 클라우드별 차이를 읽기

Wed, 21 Oct 2026 00:00:00 +0900

07 · GPUDirect RDMA가 실제로 쓰이는지 확인하고 클라우드별 차이를 읽기

1. NCCL 채널 로그에서 직접 전송을 확인한다

06편의 호스트와 파드 구성을 마쳤어도 통신이 호스트 메모리를 경유할 수 있습니다. NIC(네트워크 인터페이스 카드)이 GPU 메모리에 직접 접근할 수 있도록 준비하는 일과 NCCL(GPU 간 통신 라이브러리)이 그 경로를 사용하는 일은 구분해야 합니다. 실제 선택은 NCCL_DEBUG=INFO의 채널 연결 로그에서 확인합니다.

08 스토리지 — GDS와 NVMe-oF의 CPU 우회 범위

Wed, 21 Oct 2026 00:00:00 +0900

08 · 스토리지 — GDS와 NVMe-oF의 CPU 우회 범위

1. GDS가 줄이는 복사와 CPU에 남는 일

스토리지의 데이터를 GPU로 읽는 일반 경로에서는 CPU 시스템 메모리에 바운스 버퍼를 두고, 여기에 받은 데이터를 GPU 메모리로 다시 복사합니다. NVIDIA GDS 개요 가이드는 이 중간 복사가 지연을 늘리고 유효 대역폭을 낮춘다고 설명합니다.

09 스토리지 — 학습·추론의 GDS 활용과 패브릭 분리

Wed, 21 Oct 2026 00:00:00 +0900

09 · 스토리지 — 학습·추론의 GDS 활용과 패브릭 분리

1. GDS를 켜기 전에 애플리케이션의 I/O를 본다

노드가 GDS(GPUDirect Storage)를 지원해도 학습 프레임워크가 데이터를 CPU 메모리에 받아 처리한다면 GPU로 바로 읽는 경로를 쓰지 않습니다. 08편의 드라이버·파일시스템 조건을 갖춘 뒤에는 데이터셋 리더, 체크포인트 writer, 추론 로더와 KV 캐시가 각각 어떤 API와 메모리를 사용하는지 확인해야 합니다.

10 제공자가 GPU 파드보다 먼저 맞추는 NVLink·패브릭 설정

Wed, 21 Oct 2026 00:00:00 +0900

10 · 제공자가 GPU 파드보다 먼저 맞추는 NVLink·패브릭 설정

1. GPU 세대에 맞춰 Fabric Manager를 구성한다

GPU 파드가 NVLink를 사용하려면 제공자가 먼저 노드의 패브릭을 구성해야 합니다. NVSwitch 노드에서는 Fabric Manager(FM)가, NVL72에서는 랙의 NMX와 컴퓨트 트레이의 IMEX가 각각 맡는 일이 있습니다. 그 상태를 확인한 뒤 노드 간 InfiniBand·RoCE 연결과 혼잡 제어를 맞추는 순서로 살펴봅니다.

11 GPU 클러스터를 사용자에게 내주기 위한 조건

Wed, 21 Oct 2026 00:00:00 +0900

11 · GPU 클러스터를 사용자에게 내주기 위한 조건

10편에서 FM·IMEX와 노드 간 패브릭을 구성했다면, 이제 사용자에게 제공할 범위를 정하고 그 구성으로 검증해야 합니다. 배선과 토폴로지 정보를 Kubernetes에 전달하고, 테넌트 경계와 NCCL 경로를 맞춘 뒤, 하드웨어별 합격선을 측정합니다. 운영 중에는 관측 결과가 어느 조건에서 격리로 이어질지도 정해야 합니다.

01 L4와 L7 — 프록시는 어디에 있나

Mon, 19 Oct 2026 00:00:00 +0900

01 · L4와 L7 — 프록시는 어디에 있나

1. 같은 Envoy를 어디에 두느냐의 문제

아래 도식은 사이드카, ambient, Cilium에서 요청이 거치는 프록시와 L7을 처리하는 위치를 비교합니다.

02 Gateway API 구현 — 게이트웨이 파드가 있는가

Mon, 19 Oct 2026 00:00:00 +0900

02 · Gateway API 구현 — 게이트웨이 파드가 있는가

1. 같은 Gateway를 만들면 무엇이 생기는가

Gateway를 만들었을 때 전용 Envoy 파드가 생기는지는 구현체에 달려 있습니다. Istio는 Gateway마다 파드를 만들고, Cilium은 노드의 Envoy로 트래픽을 보냅니다. 이 차이에 따라 게이트웨이의 자원 격리 방식, 노드 배치, 장애 범위가 달라집니다.

03 관측성 — 기본으로 보이는 것과 켜야 보이는 것

Mon, 19 Oct 2026 00:00:00 +0900

03 · 관측성 — 기본으로 보이는 것과 켜야 보이는 것

1. 같은 요청을 어디서 기록하는가

아래 도식은 같은 요청이 지나갈 때 Istio와 Hubble이 각각 어느 지점에서 기록을 남기는지 보여 줍니다.

04 재시도와 복원력 — 어느 API로 말할 수 있나

Mon, 19 Oct 2026 00:00:00 +0900

04 · 재시도와 복원력 — 어느 API로 말할 수 있나

1. 기능보다 설정을 담는 API를 봅니다

Cilium에서도 재시도를 설정할 수 있습니다. Istio와 Cilium 모두 L7(애플리케이션 계층) 처리는 Envoy가 맡으며, 재시도·타임아웃·서킷 브레이킹은 Envoy의 기능입니다. 이 글은 기능의 유무보다 그 기능을 어느 API로 표현하는지가 선택에 더 중요하다고 봅니다.

05 요청 커스터마이즈와 정책 — 헤더부터 ext_authz까지, 그리고 함께 쓰기

Mon, 19 Oct 2026 00:00:00 +0900

05 · 요청 커스터마이즈와 정책 — 헤더부터 ext_authz까지, 그리고 함께 쓰기

1. 요청 변경을 VirtualService와 HTTPRoute로 표현하기

동작	Istio VirtualService	Gateway API HTTPRoute	Cilium
헤더 set·add·remove	`headers`	Request/ResponseHeaderModifier	지원
rewrite	`rewrite`(uri·authority), `uriRegexRewrite`	Path/HostRewrite	지원
redirect	`redirect`	RequestRedirect	지원
가중치 분할	`route[].weight`	가중치	지원
미러링	`mirror`, `mirrors`, `mirrorPercentage`	RequestMirror	지원(다중·비율 포함)
CORS	`corsPolicy`	CORS 필터	1.20에서 추가
외부 인가	AuthorizationPolicy CUSTOM(2절)	ExternalAuth 필터(GEP-1494)	1.20에서 지원 시작
정규식 rewrite	`uriRegexRewrite`	표준에 없음	확인 못 함

헤더를 바꾸거나 요청 경로를 rewrite하고, redirect·미러링·가중치 분할을 설정하는 요구라면 양쪽의 기능 목록은 거의 같습니다. Istio는 VirtualService 필드로, Cilium은 Gateway API의 HTTPRoute 필터로 이를 표현합니다. Istio VirtualService 레퍼런스와 Cilium conformance 리포트에서 확인할 수 있는 대응 관계가 위 표입니다.

08 vmagent AZ 분할 — 존마다 수집기 하나씩

Sun, 11 Oct 2026 00:00:00 +0900

vmagent AZ 분할 — 존마다 수집기 하나씩, 라벨셋은 그대로

hub 클러스터의 vmagent는 node1에 한 대가 떠서 세 노드의 타깃을 전부 scrape했습니다. 06 글에서 node1에 ap-northeast-2a, node2에 ap-northeast-2c 존 라벨을 붙였으니, 수집도 존마다 나눠 봤습니다. 2026-10-11에 적용했고 설계는 vmagent AZ 분할로 AZ 간 scrape 전송 줄이기를 그대로 옮긴 것입니다.

07 ClickHouse 복제 전환 — 레플리카 둘과 Keeper 세 대, 데이터는 제자리에서

Wed, 07 Oct 2026 00:00:00 +0900

ClickHouse 복제 전환 — 레플리카는 워커 둘에, 과반은 세 노드에, 데이터는 제자리에서

hub 클러스터에서 HyperDX가 쓰는 ClickHouse는 node1에 레플리카 하나로 돌았고 테이블은 전부 비복제였습니다. 앞 글에서 워커가 둘이 되고 존 라벨이 붙은 뒤, 이 ClickHouse를 레플리카 2개(node1, node2)와 ClickHouse Keeper 3대(master1, node1, node2)로 바꿨습니다. 기존 데이터(변환 시점에 약 2.7GiB)는 버리지 않고 제자리에서 복제 엔진으로 변환했습니다. 2026-10-05에 조사와 설계, 리허설을 했고 10-06에 운영에 적용했습니다. 10-07 00:10에는 레플리카 1의 콜드 티어를 S3로 바꾸는 작업까지 끝났습니다.

06 AZ affinity — 워커 두 대를 존으로 나누고 로컬 볼륨을 NAS로 옮기기

Tue, 06 Oct 2026 00:00:00 +0900

AZ affinity — 라벨은 존 둘, 묶던 것은 로컬 볼륨, 과반은 세 번째 노드

hub 클러스터에 2026-10-05 두 번째 워커가 들어왔습니다. 두 워커에 AWS 서울 리전의 존 라벨을 붙이고 EKS에서 쓰는 스케줄링 규칙을 그대로 걸어 봤습니다. 두 장비는 같은 집, 같은 스위치, 같은 전원에 있습니다. 한 존이 죽어도 다른 존이 버티는 격리는 여기에 없습니다. 목적은 존 기준 규칙을 직접 다뤄 보는 연습과, AWS용 매니페스트를 고치지 않고 올리는 호환입니다. 존 라벨을 기준으로 파드 배치를 정하는 규칙을 이 글에서는 AZ affinity라고 부릅니다.

04 DNS 장애 전환 — Kuma가 깨우고 GitHub Actions가 Route53을 바꾼다

Sun, 04 Oct 2026 00:00:00 +0900

DNS 장애 전환 — 감시는 hub, 변경은 집 밖, 권한은 레코드 두 개

edge(본가)가 죽었을 때 개인 도메인의 apex와 와일드카드 A 레코드를 hub(현재 집)로 바꾸는 구성을 만들었습니다. hub의 Kuma가 장애를 감지하면 집 밖의 GitHub Actions 러너가 다시 확인하고 Route53을 변경합니다. AWS 추가 비용은 0입니다. 현재는 edge가 정상일 때 레코드를 바꾸지 않는 경로까지 실제로 확인했고, hub로 넘겼다가 돌아오는 전환 훈련은 아직 하지 않았습니다.

05 kagent — 파드로 도는 에이전트와 2026-10 점검

Mon, 05 Oct 2026 00:00:00 +0900

kagent — 에이전트는 파드, 도구는 MCP, 모델은 ModelConfig 하나

hub 클러스터에는 2026년 3월부터 kagent가 올라가 있습니다. Kubernetes 위에서 AI 에이전트를 CR로 선언해 실행하는 프레임워크입니다. 2026-10-05에 점검해 보니 에이전트 16개가 모두 Ready였지만, 파드가 뜬 뒤 7일 남짓 동안 에이전트가 실행된 기록은 1건이었습니다. 이 글에는 kagent가 무엇으로 이루어졌는지, 질문 하나가 어떤 경로로 모델까지 가는지, 운영하면서 겪은 문제와 이번 점검에서 정한 것을 적습니다.

OpenStack on Kubernetes — 컨트롤 플레인은 파드로, VM은 여전히 베어메탈의 KVM으로

Mon, 05 Oct 2026 00:00:00 +0900

07 · OpenStack on Kubernetes — 컨트롤 플레인은 파드로, VM은 여전히 베어메탈의 KVM으로

OpenStack on Kubernetes에서 Kubernetes가 배포하는 대상은 VM을 관리하는 OpenStack 서비스입니다. OpenStack-Helm에서는 API·scheduler·conductor와 MariaDB·RabbitMQ가 파드로 실행되고, VM은 컴퓨트 노드의 libvirt와 QEMU/KVM이 실행합니다. VM 하나를 호스트의 QEMU 프로세스 하나에 대응시킨 설명은 libvirt 문서를 바탕으로 한 이 글의 정리입니다.

부록 · 사이드카와 Ambient의 지연·롤아웃 실측은 무엇을 말하는가

Mon, 05 Oct 2026 00:00:00 +0900

부록 · 사이드카와 Ambient의 지연·롤아웃 실측은 무엇을 말하는가

사이드카, ztunnel만 쓰는 Ambient L4, waypoint를 추가한 Ambient L7의 차이는 정상 요청과 롤아웃에서 각각 확인해야 합니다. atomai의 Sidecar vs Ambient 모드 선택 가이드 (EKS 1.36 실험 보고)는 같은 클러스터에서 지연 분포와 Deployment 재시작 중의 오류를 비교했습니다.

01 hub/edge 2-클러스터 구조

Thu, 20 Aug 2026 00:00:00 +0900

hub와 edge: 두 집의 클러스터를 역할로 나누기

두 집에서 Kubernetes 클러스터를 운영합니다. 현재 사는 집에는 노드 2대와 Synology NAS가 있고, 본가에는 단일 노드가 있습니다. 예전에는 각각 stage와 prod라고 불렀지만, 스토리지와 관측 시스템이 현재 집에 모이면서 이름이 역할을 설명하지 못하게 됐습니다. 과거에 stage/prod 도메인까지 한 번 서로 바꾼 이력이 있어 혼동이 잦았습니다.

03 관측 스택 일원화 — Vector와 HyperDX 컬렉터로 모으기

Sun, 04 Oct 2026 00:00:00 +0900

관측 스택 일원화 — 입구는 둘, 저장소는 둘로

9월 말의 hub에서는 로그 수집기 여러 개가 같은 파일을 읽고, 로그와 트레이스를 저장소 두 곳에 각각 쓰고 있었습니다. 비교를 위해 늘린 구성이 그대로 남아 수집·저장 경로를 중복 운영하던 상태였습니다. 일주일 남짓 이 경로를 정리해, 로그는 Vector로 모으고 앱·istio·AI CLI의 OTLP는 HyperDX(ClickStack) OTel 컬렉터로 받게 했습니다. 저장소는 로그·트레이스를 담는 ClickHouse(HyperDX)와 메트릭을 담는 VictoriaMetrics입니다.

경계와 위협 모델

Mon, 14 Sep 2026 00:00:00 +0900

01 · 경계와 위협 모델 — 세 물건은 경계를 어디에 긋고, 그 경계는 무엇을 막나

Kata는 공유 커널이라는 단일 실패점을 지운다 — 그 대신 2026년 한 해에만 Kata 자신의 guest-to-host 취약점 advisory가 10건 나왔고 ✓, 16년 묵은 KVM 탈출 Januscape(CVE-2026-53359)가 Intel·AMD 양쪽에서 공개됐다 Ⓥ. 경계는 두껍지만 무한하지 않다.
Kata와 KubeVirt는 대체재가 아니다 — KubeVirt FAQ에 그 차이가 직접 적혀 있다. “Kata containers are containers inside virtual machines. KubeVirt is a virtual machine inside a container.” ✓
성능 수치는 05에, 판단표는 06에 있다 — 실측은 05 성능 실측에, 시나리오별 선택은 06 판단에 정리했다.

근거 표기 — ✓ 1차 문서 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더·프로젝트 주장 · ≈ 추정·역산 · ? 미확인 · Σ 종합 판단.

Kata Containers

Mon, 14 Sep 2026 00:00:00 +0900

02 · Kata Containers — 파드 아래 VM 한 대의 구조와 청구서

Kata 4.0.0(2026-07-20)부터 runtime-rs가 기본 런타임이고 최신은 4.1.0(2026-08-21)이다 — 원래 Go 런타임은 deprecated로 남아 버그·보안 수정만 받는다 ✓.
CPU request만 높여서는 VM이 커지지 않는다 — CPU limit이 없으면 pod VM은 vCPU 1개로 제한된다 ✓. request만 크게 잡던 워크로드는 자원 선언을 다시 확인해야 한다.
AWS의 중첩 가상화 지원은 세대 조건을 확인해야 한다 — 2026-02-16부터 C8i·M8i·R8i 상용 인스턴스에서 지원한다 ✓. .metal이 필요하던 제약이 이 세대에서 풀렸다.
VM 메모리와 RuntimeClass overhead는 따로 계산한다 — 업스트림 default_memory는 2048MiB이고 ✓, AKS는 pod VM 기본값 512Mi와 지정이 없을 때의 RuntimeClass overhead 600Mi를 따로 둔다 ✓.

근거 표기 — ✓ 1차 문서 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더·프로젝트 주장 · ≈ 추정·역산 · ? 미확인 · Σ 종합 판단.

gVisor

Mon, 14 Sep 2026 00:00:00 +0900

03 · gVisor — 커널을 다시 쓴 샌드박스가 얻는 것과 못 하는 것

호스트 커널 임의 코드 실행에 이르는 완전 탈출 CVE는 확인되지 않는다 — 공개 CVE·advisory를 조사한 범위에서의 부재 확인이다 ✓.
amd64 syscall 351개 중 277개가 완전 또는 부분 구현돼 있다 — 완전 호환이 아니라 넓은 부분 호환이며, 구현 수만으로 개별 워크로드의 호환성을 판단할 수는 없다 ✓.
모델 제공자는 gVisor, 인프라 판매자는 마이크로 VM을 고른다 — Anthropic·OpenAI·Modal은 gVisor, E2B·Fly.io는 Firecracker, Northflank·Ant Group은 Kata다 Σ.

근거 표기 — ✓ 1차 문서 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더·프로젝트 주장 · ≈ 추정·역산 · ? 미확인 · Σ 종합 판단.

KubeVirt

Mon, 14 Sep 2026 00:00:00 +0900

04 · KubeVirt — VM을 파드로 다룰 때 따라오는 계약

KubeVirt FAQ에 정의가 그대로 있다 — “Kata containers are containers inside virtual machines. KubeVirt is a virtual machine inside a container.” ✓
라이브 마이그레이션과 hotplug, 무중단 업그레이드는 RWX 공유 스토리지가 없으면 셋 다 못 쓴다 ✓.
파드가 축출되면 VM도 끝난다 — evictionStrategy: LiveMigrate가 걸린 VMI마다 PodDisruptionBudget이 자동으로 생성된다 ✓.
v1.9.0(2026-07-30)에서 Beta 게이트가 전부 기본 on이 됐다 — cgroup v1은 deprecated돼 다음 릴리스에서 제거될 예정이다 ✓.

근거 표기 — ✓ 1차 문서 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더·프로젝트 주장 · ≈ 추정·역산 · ? 미확인 · Σ 종합 판단.

성능 실측 — 직관은 절반만 맞다

Mon, 14 Sep 2026 00:00:00 +0900

05 · 성능 실측 — 직관은 절반만 맞다

연산 중심 작업에서는 격리 비용이 작다 — 2026년 K8s 실측에서 CPU·메모리 대역폭 차이는 3% 안에 머문다 Ⓑ. IO가 많은 작업까지 같은 결과를 기대할 수는 없다.
시스템콜과 IO 비용은 호출 경로에 따라 벌어진다 — Sentry 내부 처리, 호스트 호출, Gofer 왕복을 구분해야 한다. 같은 gVisor도 플랫폼과 호출 종류에 따라 결과가 달라진다 Ⓑ.
네트워크 처리량과 지연은 따로 봐야 한다 — 대역폭에서 앞선 런타임이 RTT에서도 앞서지는 않는다 Ⓑ. 링크 속도와 측정한 지연 지표도 함께 확인해야 한다.
작은 파드를 많이 띄울수록 메모리 바닥값이 부담된다 — VMM 자체의 고정 비용과 VM 크기·장치 구성에 따라 늘어나는 오버헤드를 나눠 계산해야 한다 Σ.

근거 표기 — ✓ 1차 문서 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더·프로젝트 주장 · ≈ 추정·역산 · ? 미확인 · Σ 종합 판단.

판단 — 언제 쓰고 언제 쓰지 않나

Mon, 14 Sep 2026 00:00:00 +0900

06 · 판단 — 언제 쓰고, 언제 쓰지 않고, 어디까지만 쓰나

격리 비용은 워크로드 성격과 파드 크기에 따라 달라진다 Σ — 계산 중심인가 IO·네트워크 중심인가, 파드가 크고 적은가 작고 많은가를 함께 봐야 한다.
Kata와 KubeVirt의 선택은 시나리오에서 출발한다 Σ — 이번 조사에서는 같은 하드웨어·워크로드로 정면 비교한 공개 벤치마크를 찾지 못했다.
RuntimeClass는 파드 단위로 지정한다 ✓ — 신뢰 경계를 넘는 파드에만 runtimeClassName을 붙이고 나머지는 runc로 두는 배치가 가장 흔하다.

근거 표기 — ✓ 1차 문서 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더·프로젝트 주장 · ≈ 추정·역산 · ? 미확인 · Σ 종합 판단.

Python GIL × CPU Limit

Thu, 06 Aug 2026 00:00:00 +0900

06 · Python GIL × CPU Limit — “1코어 런타임"은 왜 잘리는가

GIL은 성능 장치가 아니라 뮤텍스입니다. 바이트코드를 실행하는 스레드가 한 순간에 하나뿐이므로 순수 파이썬 프로세스의 CPU 소비는 정의상 코어 하나 분을 넘지 못합니다 — limit이 1코어 이상이면 바이트코드만으로는 스로틀이 성립하지 않습니다.
CFS quota는 “코어당 지분"이 아니라 시간 예산 풀입니다. 4코어 노드의 limit 1이 “코어마다 25%씩"을 뜻하지는 않습니다. 실행할 스레드가 있는 런큐만 전역 풀에서 5ms 슬라이스를 꺼내가는 구조입니다.
그런데도 실제 파이썬 컨테이너는 잘립니다. 경로는 네 갈래입니다 — 워커 프로세스 다중화 · GIL을 놓는 네이티브 스레드풀 · 1코어 미만 limit의 슬라이스 입도 · free-threading. 현행 커널의 파이썬 스로틀 사고는 전부 여기 속합니다.
잘리면 더 아픕니다. throttle은 per-CPU 단위라 GIL 홀더가 있는 코어만 잘려도 프로세스 전체가 유저스페이스에서 멈춥니다. 커널은 이 문제의 커널 락 버전을 고치는 중이지만 GIL은 유저스페이스 락이라 보호 밖입니다.
Python은 Go 1.25와 달리 cgroup을 안 봅니다. os.cpu_count()는 노드 코어 수를 돌려주고 3.13의 해법(PYTHON_CPU_COUNT)도 수동 주입입니다. 처방은 전부 배포 파이프라인의 몫입니다.

왜 이 문서가 따로 있나. 02 CPU Throttling이 “스로틀이 무엇이고, 어떻게 보이고, 무엇으로 대응하나"를 다룬다면 이 문서는 같은 문제를 언어 런타임 쪽에서 봅니다. 파이썬의 GIL은 두 개의 그럴듯한 오해를 만듭니다 — “GIL은 1코어를 갈구도록 설계된 구조다"와 “limit 1은 4코어에서 25%씩 배급받는다는 뜻이다”. 이 문서는 두 오해를 커널·CPython 소스 수준에서 바로잡고 그 위에서 “그런데 왜 실제 파이썬 컨테이너는 잘리는가"를 답합니다. 02 §4의 런타임 표(Go·JVM·Node.js)에서 비어 있던 Python 행이 이 문서입니다.

01 승격 이전 — step과 AnalysisRun

Fri, 28 Aug 2026 00:00:00 +0900

승격 이전 — step과 AnalysisRun

Rollout에서 “승격(promotion)“이 하는 일은 하나입니다. status.stableRS를 새 ReplicaSet의 pod-template-hash로 바꾸는 것. 그 한 줄이 일어나기 전까지의 모든 구간이 step입니다.

02 롤백이 스스로를 취소한다

Fri, 28 Aug 2026 00:00:00 +0900

롤백이 스스로를 취소한다

롤백은 컨트롤러에게 새 rollout입니다. 이 한 문장에서 사고 두 건이 나옵니다.

첫 번째는 롤백이 취소되는 것입니다. 새 rollout이니 AnalysisRun이 새로 붙습니다. 인시던트 중이라 오류율은 아직 높습니다. 되돌리려는 행위가 판정에 걸려 abort됩니다.

03 그래서 무엇을 할 것인가

Fri, 28 Aug 2026 00:00:00 +0900

그래서 무엇을 할 것인가

2부는 기전으로 끝났습니다. rollbackWindow가 인덱스를 스텝 끝으로 던지고 역탐색이 방금 건너뛴 마지막 setWeight: 100을 도로 집어오고 가용량 게이트는 canary를 보지 않는다는 것까지.

02 개발환경 — 브라우저와 아이패드

Tue, 25 Aug 2026 00:00:00 +0900

개발환경 — 터미널 하나를 어디서든 같은 자리로 연다

앞 편은 클러스터 쪽 이야기였습니다. 이번엔 그 클러스터 위에서 제가 실제로 코드를 만지는 자리를 다룹니다. 한 문장으로 줄이면 hub 클러스터에 code-server를 pod로 띄워 두고 노트북이든 데스크탑이든 브라우저로 들어가 그 터미널에 앉는 구조입니다. 같은 터미널에 아이패드로도 붙습니다. 이 글도 그 터미널 안에서 쓰고 있습니다.

레이어 1 — 클러스터 파라미터와 가변성 3분류

Sat, 15 Aug 2026 00:00:00 +0900

레이어 1 — 클러스터 파라미터와 가변성 3분류

finance blue를 만들 때 정해둘 것 셋 — upgradePolicy.supportType = STANDARD(기본값이 EXTENDED입니다), deletionProtection = true, 그리고 serviceIpv4Cidr·ipFamily·bootstrapClusterCreatorAdminPermissions. 뒤 셋은 지금 틀리면 재생성뿐입니다.
최상위 29개 파라미터는 create-only 8 · 단방향 불가역 6 · day-2 가변 15로 갈립니다(§1).
upgradePolicy.supportType 기본값은 EXTENDED입니다. 명시하지 않으면 표준지원 종료일부터 시간당 $0.60이 자동으로 붙고 확장지원에 실제로 진입한 뒤에는 STANDARD로 못 돌아옵니다(§4).
되돌릴 수 없는 문 넷 — controlPlaneEgressMode(CUSTOMER_ROUTED 진입), encryptionConfig(DisassociateEncryptionConfig API가 아예 없습니다), authenticationMode(전진만), ipFamily(생성 시 영구 고정)(§2).
Terraform은 되돌리기를 클러스터 재생성으로 모델링합니다 — plan에 뜨는 # forces replacement는 버그가 아니라 안전장치입니다(§3).
버전은 2026-07부터 되돌릴 수 있습니다(7일 창·마이너 1단계·컨트롤 플레인만). 단 --force는 PDB도 어드미션 웹훅도 우회하지 않습니다(§5).

이 페이지가 다루는 범위는 CreateCluster·UpdateClusterConfig·UpdateClusterVersion이 받는 클러스터 레벨 최상위 필드입니다. 판정하는 것은 하나뿐입니다. 그 값을 언제 정할 수 있고 정한 뒤에 되돌릴 수 있는가. 2026-08에 새로 열린 컨트롤 플레인 컴포넌트 파라미터의 내부 동작과 튜닝 판단은 레이어 2, 용량 축인 Provisioned Control Plane 티어는 용량 축, 애초에 손댈 수 없는 영역은 레이어 3이 갖습니다.

0.36 → 1.6 — v1 전환과 그 직후

Sat, 01 Aug 2026 00:00:00 +0900

01 · 0.36 → 1.6 — v1이 바꾼 것은 API가 아니라 동작이다

v1beta1→v1을 “필드 이름이 바뀐 일"로 읽으면 사고가 납니다. changelog에서 위험한 절은 Behavior Changes이고 그중 둘은 옵트아웃이 없습니다 — drift는 Stable 승격과 함께 feature gate가 삭제됐고(core#1311), expiration은 forceful로 되돌아갔습니다(core#1333).
forceful expiration이 무시하는 건 PodDisruptionBudget(PDB)이 아닙니다. 무시하는 것은 “대체 노드가 Initialized가 될 때까지 드레인을 시작하지 않는다"는 사전 안전장치와 disruption budget입니다. nodeclaim.expiration 컨트롤러는 후보 평가 없이 NodeClaim을 바로 Delete합니다(controllers/nodeclaim/expiration/controller.go:82).
consolidateAfter가 v1에서 필수 필드입니다. v1beta1의 WhenUnderutilized에서는 설정조차 불가능했던 값이라 기존 동작을 유지하려면 0s를 명시해야 합니다. Never는 그 NodePool의 consolidation을 통째로 끕니다.
terminationGracePeriod(core#916)가 최종 승자입니다. 만료되면 PDB·do-not-disrupt 무관하게 남은 파드가 강제 삭제됩니다. 반대로 TGP를 걸면 drift가 “PDB·do-not-disrupt 파드가 있는 노드"까지 후보로 채택합니다 — 안전장치를 스스로 꺼주는 대가로 CVE 패치를 밀 수 있게 됩니다. 노드 최대 수명 = expireAfter(기본 720h, 상한이지 하한이 아닙니다) + TGP.
disruption budgets가 Drifted/Underutilized/Empty reason별로 나뉘었습니다(core#991, core#1377). 삭제된 drift feature gate의 자리를 reason별 budget이 메웁니다 — 업스트림이 제시하는 유일한 drift 통제 수단입니다.
1.1.0이 v1beta1 서빙을 끝냈습니다. nodeClassRef.group/kind가 강제 필수가 되고 kubelet 호환 어노테이션이 사라집니다. 같은 릴리스의 Bottlerocket + instanceStorePolicy: RAID0은 v1.22.0 미만 이미지에서 노드가 join하지 못합니다.
1.2.0의 메트릭 reason 라벨 snake_case 전환은 CI가 못 잡는 알람 무효화입니다. reason="Drifted" 쿼리는 에러 없이 결과가 0이 됩니다. 같은 릴리스에서 nodeclass.status·nodeclass.termination이 nodeclass로 합쳐졌습니다(aws#7597).
1.6.0에서 native On-Demand Capacity Reservation(ODCR)이 beta·기본 활성화됐습니다(core#2365). open eligibility ODCR을 capacityReservationSelectorTerms에 등재하지 않고 올리면 예약을 안 쓰면서 요금은 계속 나갑니다 — 이 구간에서 가장 비싼 회귀입니다.
MinValuesPolicy(1.6, core#2299·aws#8250)는 전역 옵션이고 기본값은 Strict입니다. minValues 자체는 v0.35.0(core#963)부터 있던 API로 0.36 운영자에게 새 기능이 아닙니다.

v1 마이그레이션 가이드 763줄의 절반은 “필드가 어디로 갔다"는 표라 kubectl apply 실패로 바로 드러납니다. 진짜 위험한 건 매니페스트가 그대로 통과하는데 클러스터가 다르게 행동하는 항목입니다 — 만료된 노드가 대체 없이 드레인을 시작하고, 끄고 있던 drift가 켜지고, 쓴 적 없는 consolidateAfter가 필수가 됩니다.

In-Place Pod Resize (1.35 GA)

Sat, 01 Aug 2026 00:00:00 +0900

01 · In-Place Pod Resize — 재시작 없이 파드 리소스를 바꾼다

1.27 alpha → 1.33 beta → 1.35 GA. 파드를 재시작하지 않고 CPU/메모리를 바꿉니다. 반드시 resize 서브리소스로만 통합니다. 손댈 수 있는 건 cpu·memory 값뿐입니다(QoS 변경·항목 제거·GPU는 전부 거부).
수락 판정 기준은 실사용량이 아니라 “다른 파드들의 requests 합 vs node allocatable”. 노드가 붐비면 Deferred(재시도됨), 정책 위반이면 Infeasible(spec을 고치기 전까지 재평가 안 됨).
늘리는 쪽은 사실상 무위험, 줄이는 쪽만 조심. 메모리 축소에는 kubelet 사용량 체크의 TOCTOU 레이스가 남아 OOM-kill을 확실히 막지 못합니다(#135670, open). CPU 축소는 재시작이 없다는 뜻일 뿐 스로틀 비용을 낳는데 그건 사용률 그래프에 안 보입니다(throttled_periods로 봐야 합니다).
케이스가 전부입니다. 재시작이 비싼 stateful(DB·캐시·롱커넥션)에 최적이고 기동 부스트에도 좋습니다. JVM/Node 힙에는 반쪽(CPU만 in-place), VPA 자동화는 아직 이르고 static CPU manager 노드는 사실상 미지원입니다.

왜 6년이 걸렸을까요. “실행 중인 컨테이너의 cgroup 값만 바꾸면 되는 것 아닌가” 싶지만 이 기능에서는 스케줄러가 보는 값·kubelet이 약속한 값·커널에 실제 쓰인 값이 서로 다른 순간이 반드시 생깁니다. 그 셋의 정합성에 kubelet 재시작 후의 복구까지 맞추는 데 KEP-1287은 alpha에서 GA까지 6년을 썼습니다. 그래서 이 문서는 공식 문서에서 멈추지 않고 kubelet이 실제로 하는 일 · 열린 버그 · 케이스별 득실까지 내려갑니다.

배경 — 왜 CAPI in-place를 버리고 blue-green인가

Sat, 01 Aug 2026 00:00:00 +0900

배경 — 왜 CAPI in-place를 버리고 blue-green인가

finance EKS 클러스터는 원래 CAPI GitOps로 관리하도록 설계돼 있었습니다. 그런데 조사 시점(2026-07)에 그 설계는 이미 반쯤 무너져 있었습니다. 최초 계획은 CAPI GitOps in-place 업그레이드였지만, 조사 과정에서 진단이 두 번 뒤집힌 끝에 신규 blue 클러스터를 Terraform으로 생성하는 blue-green으로 방향이 굳었습니다. 랜딩이 요약한 이 전환의 근거를 아래 네 포인트로 풀어냅니다.

서비스 메시와 Istio 기초

Sat, 01 Aug 2026 00:00:00 +0900

01 · 서비스 메시와 Istio 기초 — 왜 EKS에 메시를 얹나

서비스 메시 = 데이터 플레인(파드마다 붙는 Envoy 사이드카) + 컨트롤 플레인(istiod). 이 분리가 챕터 전체의 뼈대입니다.
사이드카는 iptables로 트래픽을 가로채 앱 코드를 그대로 둔 채 mTLS·라우팅·재시도·관측성을 더합니다.
메시는 공짜가 아닙니다 — 프록시 오버헤드·컨트롤 플레인 부하·설정 복잡도·디버깅 난이도라는 네 비용을 집니다.
Ambient 모드(사이드카리스, ztunnel+waypoint)는 이 비용을 줄이려는 후속 설계지만, 이 챕터는 사이드카 모드 운영을 전제로 합니다.

02~05는 메시를 운영하며 겪은 사건의 기록입니다. 그 기록이 읽히려면 메시가 무엇으로 이뤄져 있고 그 대가가 무엇인지를 먼저 잡아야 합니다. 이 문서는 서비스 메시의 두 축(데이터 플레인·컨트롤 플레인), 메시가 해주는 것, 그 비용을 다룹니다.

왜 Ambient mode인가

Sat, 01 Aug 2026 00:00:00 +0900

01 · 왜 Istio Ambient mode인가 — 사이드카를 건너뛴 선택 (2026-03)

참조한 내용정리 · 이 문서는 아래 원문을 읽고 우리 지식베이스 형식으로 재구성한 요약입니다. 원문 자체가 아니며 정확한 워딩·전체 맥락·그림은 원문에서 확인합니다.

karpenter — 0.36.2 → 1.14.0, v1beta1→v1 CRD

Tue, 21 Jul 2026 00:00:00 +0900

karpenter — 0.36.2 → 1.14.0, v1beta1→v1 CRD

컨트롤러를 0.36.2에서 최신 stable 1.14.0(2026-07-11 릴리스)로 올립니다. 목표 k8s 1.35를 지원하는 최소가 1.9이고 1.14는 1.30~1.36을 커버하니 “가능한 최신 stable” 방침에 맞습니다 — 1.36으로 재검토할 때도 하한이 1.13이라 1.14.0이 그대로 유효합니다 ✓
넘을 스키마 경계는 v1beta1 → v1 하나뿐입니다. finance의 0.36.2는 이미 v1beta1(karpenter.sh/v1beta1 NodePool·karpenter.k8s.aws/v1beta1 EC2NodeClass)입니다. v1alpha5의 Provisioner·AWSNodeTemplate은 v0.33에서 졸업해 애초에 없습니다 ✓
v1에서 amiSelectorTerms가 필수가 됩니다. 빠뜨리면 EC2NodeClass와 이를 참조하는 모든 NodePool이 통째로 NotReady가 됩니다 ✓
v1은 drift를 GA로 승격시키면서 끄는 수단을 없앱니다. finance가 명시한 featureGates.drift: false는 무효가 되고 drift가 강제로 켜집니다 ✓
blue-green 신규 클러스터라 conversion 웹훅을 왕복하지 않습니다. 기존 클러스터를 in-place로 올릴 때만 밟아야 하는 0.36 → 0.36.9 → 1.0.x → 1.1+ 순차 경로를 건너뛰고 v1 CRD와 v1 매니페스트로 1.14.0을 처음부터 세웁니다 ✓

1. 왜 1.14.0인가

목표 클러스터가 k8s 1.35라서 버전은 거의 정해집니다. karpenter 호환 매트릭스에서 1.35를 받는 최소 버전이 1.9이고 1.14는 1.30~1.36을 커버합니다. “가능한 최신 stable"이라는 방침과 하한 조건이 같은 답을 가리킵니다. 나중에 1.36으로 재검토하더라도 그때의 하한이 1.13이라 1.14.0은 그대로 쓸 수 있습니다.

레이어 2 — 2026-08 열린 4종과 karpenter 가중치

Sat, 15 Aug 2026 00:00:00 +0900

레이어 2 — 2026-08 열린 4종과 karpenter 가중치

실제 후보는 MostAllocated 하나뿐이고 그것도 blue 안정화 이후 별건입니다. create 시점에는 4개 전부 기본값으로 둡니다(§8).
4개가 열렸고 그중 3개는 추가 과금이 없습니다. scoringStrategy·eventTtl·serviceNodePortRange는 k8s 1.31+ 전 리전에서 무료로 쓸 수 있고 HPA syncPeriod만 Provisioned Control Plane(월 증분 +$1,204.50)이 전제입니다.
완전 개방이 아니라 검증된 범위 안의 개방입니다. 범위 폭(HPA 5초 · eventTtl 축소 방향만 · 스케줄러 전략 2종만)이 그대로 AWS의 책임 경계 선언입니다 — 업스트림 kube-controller-manager에는 sync period validation이 아예 없습니다(§2).
karpenter는 이 설정을 읽지 않습니다. karpenter-core v1.14.0 전체에서 scoringStrategy 관련 심볼이 grep 0건입니다. 점수 공식이 각 항을 그 노드 자신의 allocatable로 나누므로 “노드의 cpu/memory 비율에 맞춰 가중치를 조정한다"는 작업은 애초에 필요하지 않습니다(§4).
AWS 문서와 실제가 어긋납니다. User Guide는 Terraform을 “coming soon"이라 쓰지만 provider v6.59.0(발표 당일)에 이미 들어왔고 eksctl·CDK는 반대로 과대 서술입니다(§6).

2026-08-12, EKS가 관리형 컨트롤 플레인 3개 컴포넌트의 파라미터 4종을 고객 설정 대상으로 열었습니다. 지금까지 kube-scheduler·kube-apiserver·kube-controller-manager 설정은 손댈 수 없는 영역이었습니다. 노드를 채워 써서 컴퓨트 비용을 줄이고 싶어도 관리형 스케줄러의 전략을 바꿀 방법이 없었습니다. 목표버전에서 확정한 blue의 목표는 1.35이고 이 4종의 하한은 1.31입니다. blue는 4개를 전부 쓸 수 있는 상태로 태어납니다. 이 페이지는 **“써야 하나”**를 판정합니다. “쓸 수 있나"는 이미 답이 나와 있습니다. 클러스터 레벨 파라미터와 가변성 3분류는 레이어 1, HPA syncPeriod가 요구하는 용량 축은 Provisioned Control Plane, 이번에도 여전히 닫혀 있는 플래그들은 레이어 3이 다룹니다.

CPU Throttling

Sat, 01 Aug 2026 00:00:00 +0900

02 · CPU Throttling — limit을 다 쓰지도 않았는데 잘린다

CFS는 CPU limit을 100ms period로 쪼개서 줍니다. period는 서로 독립이고 안 쓴 quota는 이월되지 않습니다. 그래서 “평균 사용률 34% + throttle 31%” 가 모순 없이 성립합니다 — 총량이 남는데 타이밍이 잘립니다.
사용률 그래프에는 이 상태가 안 보입니다. 대시보드는 내내 여유로운데 꼬리 지연만 길어집니다. container_cpu_cfs_throttled_periods_total / …periods_total을 같이 봐야 처음 보입니다.
잘린 시간은 CPU wait으로 스레드에 그대로 쌓이고 APM에는 “아무것도 안 하는 구간"으로 찍힙니다. 컨테이너 전체가 한꺼번에 멈추므로 꼬리(P99)가 평균보다 훨씬 크게 망가집니다.
코어가 많을수록 더 잘립니다. quota는 병렬도에 비례해 마르기 때문입니다 — 같은 1코어 limit이라도 4코어에서 도는 컨테이너는 period의 ¾을 멈춰 있습니다. 직관과 반대입니다.
대응은 셋 중 하나입니다: limit 제거(가장 효과적이지만 이웃을 노출), CPU Manager static(throttle이 아예 생기지 않지만 조건이 빡빡), CPU Burst(타이밍만 푸는 정답에 가깝지만 k8s 표면이 없습니다).

“CPU를 더 주면 빨라진다"는 직관은 limit이 걸린 컨테이너에서 자주 틀립니다. 총량은 남았는데 쓸 수 있는 타이밍만 잘린 상태가 있습니다. 이 상태는 CPU 사용률 그래프에 나타나지 않아서 몇 시간씩 엉뚱한 곳을 파게 만듭니다. 그래서 이 문서를 따로 두었습니다. 그 상태가 어떻게 만들어지는지, 어떤 지표를 겹쳐 봐야 보이는지, 대응 선택지가 각각 무엇을 대가로 치르는지를 정리합니다.

Envoy config로 해부하는 Ambient mode

Sat, 01 Aug 2026 00:00:00 +0900

02 · Envoy config로 해부하는 Ambient mode — HBONE은 어떤 설정으로 만들어지는가 (2026-04)

컨트롤 플레인 해부: istiod

Sat, 01 Aug 2026 00:00:00 +0900

02 · 컨트롤 플레인 해부 — istiod는 왜 CPU를 먹는가

istiod 부하는 프록시 수 × 변경 빈도 × 설정 범위의 곱입니다. 세 항이 함께 커지면 CPU가 벽을 칩니다.
증설은 감으로 정하지 않습니다. 1순위 지표는 pilot_proxy_convergence_time(수렴 시간), 그다음이 연결 프록시 수·push 폭주·CPU입니다.
CPU 증설은 응급 처치일 뿐입니다. Sidecar 리소스로 각 프록시가 보는 설정 범위를 좁혀야 진짜로 풀립니다.
그다음 레버가 디바운스·discoverySelectors 튜닝, 마지막이 수평 스케일입니다(istiod는 stateless).

그때 무슨 일이 있었나. 클러스터 규모가 커지고 배포가 잦아지면서 컨트롤 플레인 istiod의 CPU가 주기적으로 치솟았습니다. 급한 불은 CPU를 증설해서 껐지만 그건 응급 처치였습니다. 같은 맥락에서 “istio node/pod 리소스 최적화” 과제가 이어졌습니다 — 프록시 쪽 자원과 istiod가 다루는 설정 범위를 함께 손봐야 근본이 잡히기 때문입니다. 여기서는 istiod가 CPU를 먹는 메커니즘, 언제 증설해야 하는지 알려주는 지표, 증설 말고 진짜 해법을 정리합니다.

1.7 → 1.14 — 운영에 쓸 기능들

Thu, 30 Jul 2026 00:00:00 +0900

02 · 1.7 → 1.14 — 지금 켤 만한 것과 미룰 것

1.7 이후 8개 마이너에서 API breaking은 사실상 없습니다. 대신 켜야 비로소 쓸 수 있는 기능이 라벨·feature gate·신규 CRD·IAM 네 층으로 쌓였습니다.
flex 배제는 라벨 한 줄입니다 — karpenter.k8s.aws/instance-capability-flex를 In ["false"]로. DoesNotExist로 쓰면 모든 인스턴스 타입이 배제되어 노드가 하나도 안 뜹니다(§2.2).
기존 NodePool에 배제를 추가하면 떠 있는 flex 노드가 전부 RequirementsDrifted로 교체됩니다. “다음부터"가 아니라 “지금 있는 걸 몰아낸다"입니다.
알람이 에러 없이 깨진 곳이 둘입니다(1.7): karpenter_pods_pods_drained_total → karpenter_pods_drained_total, disrupted_total의 reason liveness → registration_timeout(§3).
업그레이드 자체가 노드를 교체하는 버전도 있습니다 — 1.12는 CA bundle이 drift 해시에 들어가면서 전 노드를 일괄 drifted로 만듭니다(§6.1). 1.8.4는 건너뜁니다(TopologySpreadConstraint(TSC) 회귀, 업스트림이 업그레이드 금지 명시).
1.14 Balanced consolidation은 게이트가 없습니다 — consolidationPolicy: Balanced 한 줄이면 됩니다(§7.2). Capacity Buffers는 alpha 게이트에 신규 CRD까지 필요하고 업스트림 문서가 코드보다 낡았습니다(§7.1).
IAM 권한은 세 번 늘었습니다 — 1.7 iam:ListInstanceProfiles, 1.11 ec2:DescribePlacementGroups, 1.12 ec2:DescribeInstanceStatus(§9).
우리 기준(blue-green으로 0.36.2 → 1.14.0 직행) 판정은 §8.

왜 이 문서인가. 릴리스노트는 “무엇이 머지됐냐"까지만 말합니다. 필요한 구분은 셋 — ① 켜면 이득인 것, ② 설정·권한·CRD를 건드릴 것, ③ 업그레이드 자체가 노드를 교체하는 것. 이 문서는 그 셋으로 1.7~1.14를 나눠 판정합니다.

istio — →1.30.3, sidecar 유지·ambient 금지

Tue, 21 Jul 2026 00:00:00 +0900

istio — →1.30.3, sidecar 유지·ambient 금지

제약(변경 불가): data plane 은 sidecar 유지가 전제입니다. ztunnel/waypoint 기반 ambient mesh 전환은 범위 밖이고 어떤 단계에서도 시도하지 않습니다 ✓
경로는 A(1.35 신규 클러스터 직행)로 확정됐다 — 2026-08-05 의 EKS 1.35 · istio 1.30 결정이 근거입니다. 아래 경로 B 서술은 “왜 안 되는가"의 근거로만 남깁니다 ✓
라이브 버전은 여전히 미확인이지만 경로 A 확정으로 성격이 바뀌었다 — 홉 산정용 blocking 은 아니고 green↔blue values·EnvoyFilter 설정 parity 확인용입니다. 그래도 컷오버 전에 istioctl version 으로 실측은 남깁니다 ?
목표 1.30.3(2026-07-16 릴리스)은 istio.io 최신 stable 이고 지원 k8s 가 1.32~1.36 이라 목표 클러스터 1.35 를 포함합니다 ✓
경로 B(기존 green in-place)로는 1.30.3 에 도달할 수 없다 — istio 1.30 의 k8s 하한이 1.32 인데 green 은 1.31 입니다. green 이 1.31 인 동안 올릴 수 있는 상한은 istio 1.29(지원 1.31~1.35)이고 그마저 EOL 이 ~2026-08 입니다. 1.30.3 은 1.35 신규 클러스터 직행(경로 A)에서만 성립합니다 ✓
native sidecar 전환 시점은 istio 버전이 아니라 노드 kubelet 버전이 정한다 — 기본값은 true 가 아닌 "auto" 이고 전 노드 kubelet ≥1.33 일 때만 켜집니다. 목표 1.35 노드에서는 처음부터 ON 이고 green(1.31)에서는 끝까지 OFF 입니다 ✓
1.29 차트 통합의 리소스 rename 은 우리에게 해당 없을 가능성이 크다 — 코드 대조 결과 istiod 차트는 1.22.0 부터 이미 신 이름(istiod-clusterrole)입니다. 대응은 rename 추적 대신 구 이름 orphan 탐색입니다 ✓
blue-green 신규 클러스터라면 canary 홉 체인 없이 1.30.3 을 처음부터 직행 설치할 수 있습니다 ✓

1. 왜 1.30.3인가

목표 버전은 남은 선택지가 좁아서 사실상 정해집니다. istio 1.24 계열이 지원하는 k8s 는 1.28~1.31 까지라 목표 1.35 에서는 아예 지원 대상 밖입니다. 1.35 를 지원하는 비-EOL 라인은 1.29(k8s 1.31~1.35)와 1.30(k8s 1.32~1.36) 둘뿐인데 그중 1.29 는 EOL 전망이 ~2026-08 입니다. 남는 건 1.30.3 하나입니다. 2026-07-16 릴리스이자 istio.io 최신 stable 이고, 지원 k8s 범위 안에 목표 클러스터 1.35 가 들어옵니다.

목표 버전 — 1.35 판정과 1.36 차단 6종

Tue, 21 Jul 2026 00:00:00 +0900

목표 버전 — 1.35 판정과 1.36 차단 6종

green은 아직 절벽이 아닙니다. 조사 도중 1.31로 in-place가 이미 끝나 있었고 확장지원 종료가 2026-11-26이라 약 4개월 런웨이가 남았습니다.
1.36을 막는 건 6종입니다. Argo CD·argo-rollouts·aws-load-balancer-controller·external-secrets·KEDA·kube-state-metrics가 아직 1.36 지원 릴리스를 내지 않았습니다.
1.35는 유효한 판정입니다. 전 컴포넌트 세트가 공식 지원 릴리스를 갖는 최고 버전이고 ESO EOL 딜레마까지 해소합니다.
kube-proxy nftables는 opt-in 한 줄로 켤 수 있고 목표 버전과 무관합니다. 상세는 03 managed addon.

이 페이지는 finance 워크로드 클러스터가 향할 버전을 확정합니다. 근거는 2026-07-21 시점의 라이브 검증(업스트림 릴리스 노트·aws eks describe-addon-configuration·각 컴포넌트 릴리스 채널)입니다. 왜 blue-green인가는 배경이, 그 버전을 어떤 토폴로지·인프라로 짓는지는 02 클러스터 설정이 다룹니다.