API Server DD
Kubernetes API Server 통신 구조 (Verb 중심)
아래는 kube-apiserver 기준으로 각 주요 컴포넌트가 어떤 Kubernetes API Verb를 사용하는지 정리한 구조입니다.
그라파나에서 트레이싱할 때 핵심 메트릭은 보통 다음입니다.
verb
resource
subresource
useragent
component
code
scope
namespace
특히 아래 metric/log source를 많이 사용합니다.
apiserver_request_total
apiserver_request_duration_seconds
Audit Logs
APIServer tracing (otel)
etcd request metrics
전체 구조도
+-------------------+
| kubectl / CI |
| humans / bots |
+---------+---------+
|
| GET/LIST/WATCH
| CREATE/UPDATE/PATCH/DELETE
v
+----------------------------------------------------------------------------------+
| kube-apiserver |
|----------------------------------------------------------------------------------|
| Authentication → Authorization → Admission → Validation → etcd |
+----------------------------------------------------------------------------------+
^ ^ ^ ^
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
+-------+----+ +-------+------+ +---------+------+ +---------+--------+
| kubelet | | controller | | scheduler | | cloud-controller |
| | | manager | | | | manager |
+-------+----+ +-------+------+ +---------+------+ +---------+--------+
| | | |
| | | |
| | | |
+----------------+--------------------+---------------------+
|
|
v
+------+
| etcd |
+------+
컴포넌트별 Verb 흐름
1. kubelet ↔ kube-apiserver
kubelet → apiserver
kubelet
|
+--> WATCH Pods
+--> WATCH ConfigMaps
+--> WATCH Secrets
+--> WATCH RuntimeClasses
+--> GET Node
+--> PATCH Node/status
+--> UPDATE Node/status
+--> CREATE Event
+--> PATCH Lease
+--> GET CSR
+--> CREATE CSR
핵심 Verb
Resource Verb 목적
pods WATCH 스케줄된 Pod 감지
configmaps WATCH 설정 동기화
secrets WATCH Secret 동기화
nodes/status PATCH/UPDATE 노드 상태 보고
leases PATCH heartbeat
events CREATE 이벤트 기록
certificatesigningrequests CREATE kubelet 인증서
2. kube-controller-manager ↔ kube-apiserver
컨트롤러별로 매우 많음.
대표 흐름:
controller-manager
|
+--> WATCH *
+--> LIST *
+--> UPDATE status
+--> PATCH objects
+--> CREATE Pods
+--> DELETE Pods
+--> UPDATE finalizers
주요 Controller별 Verb
Controller 주요 Verb
Deployment Controller WATCH ReplicaSets, PATCH Deployments
ReplicaSet Controller LIST Pods, CREATE Pods, DELETE Pods
Node Controller WATCH Nodes, PATCH Nodes
Job Controller CREATE Pods, DELETE Pods
ServiceAccount Controller CREATE Secrets
EndpointSlice Controller WATCH Services/Pods, UPDATE EndpointSlices
3. kube-scheduler ↔ kube-apiserver
scheduler
|
+--> WATCH Pods
+--> WATCH Nodes
+--> WATCH PVC/PV
+--> WATCH CSINodes
+--> PATCH Pod/binding
+--> UPDATE Pod
핵심 Verb
Resource Verb
pods WATCH
nodes WATCH
pods/binding CREATE
pods/status UPDATE
events CREATE
스케줄러는 실제로 binding subresource를 사용합니다.
4. cloud-controller-manager ↔ kube-apiserver
cloud-controller-manager
|
+--> WATCH Nodes
+--> UPDATE Nodes
+--> WATCH Services
+--> UPDATE Services/status
+--> CREATE Events
대표 Verb
Resource Verb
services/status UPDATE
nodes PATCH
routes CREATE
events CREATE
5. kubectl ↔ kube-apiserver
kubectl
|
+--> GET
+--> LIST
+--> WATCH
+--> CREATE
+--> APPLY(PATCH)
+--> DELETE
+--> PATCH
+--> REPLACE(PUT)
6. Operators / Controllers (client-go)
대부분 동일 패턴:
Reflector:
LIST
WATCH
Reconciler:
GET
PATCH
UPDATE
CREATE
DELETE
controller-runtime 기반이면 거의 동일합니다.
Verb 기준 전체 맵
WATCH
├─ kubelet
├─ scheduler
├─ controller-manager
├─ operators
└─ kubectl
LIST
├─ scheduler
├─ controllers
├─ operators
└─ kubectl
GET
├─ kubelet
├─ kubectl
├─ operators
└─ controllers
CREATE
├─ controllers (pods/events)
├─ scheduler (binding)
├─ kubelet (events/csr)
├─ kubectl
└─ operators
PATCH
├─ kubelet (node status/lease)
├─ scheduler
├─ controllers
├─ operators
└─ kubectl apply
UPDATE
├─ controllers
├─ kubelet
├─ scheduler
└─ cloud-controller-manager
DELETE
├─ controllers
├─ kubectl
└─ operators
Grafana / Prometheus 에서 가장 중요한 메트릭
APIServer Request Count
sum by (verb,resource) (
rate(apiserver_request_total[5m])
)
컴포넌트별 Verb
sum by (verb,useragent) (
rate(apiserver_request_total[5m])
)
WATCH 폭증 확인
sum by (resource) (
rate(apiserver_request_total{verb="WATCH"}[5m])
)
kubelet PATCH storm
sum by (node) (
rate(apiserver_request_total{
verb="PATCH",
resource="nodes"
}[5m])
)
실무적으로 중요한 포인트
WATCH 는 Long-lived connection
실제로는:
LIST → WATCH
패턴입니다.
client-go reflector는 거의 항상:
LIST initial state
WATCH incremental updates
로 동작합니다.
PATCH vs UPDATE
Kubernetes 내부 컴포넌트는 대부분:
PATCH
Status PATCH
Server Side Apply
를 선호합니다.
UPDATE(PUT) 는 상대적으로 적습니다.
실제 가장 많은 Verb
대규모 클러스터 기준:
1. WATCH
2. LIST
3. PATCH
4. GET
5. CREATE
순으로 많습니다.
Audit Log 기준 실제 흐름 예시
kube-scheduler
WATCH pods
GET nodes
CREATE pods/binding
PATCH pods/status
CREATE events
kubelet
WATCH pods
WATCH secrets
PATCH nodes/status
PATCH leases
CREATE events
Grafana 추천 차원(dimensions)
아래 label 조합이 가장 유용합니다.
label 이유
verb API 유형
resource 병목 리소스
subresource status/binding 구분
code 실패율
component 어느 컴포넌트인지
useragent client-go 구분
scope cluster/ns
group CRD 구분
특히 중요한 userAgent
대표 예시:
kubelet/v1.xx
kube-scheduler/v1.xx
kube-controller-manager/v1.xx
kubectl/v1.xx
external-secrets/vx
argocd-application-controller
helm
추천 Grafana 패널
1. Verb Heatmap
sum by (verb,resource)(
rate(apiserver_request_total[5m])
)
2. Slow Requests
histogram_quantile(
0.99,
sum by (verb,resource,le)(
rate(apiserver_request_duration_seconds_bucket[5m])
)
)
3. WATCH saturation
sum(
apiserver_longrunning_requests
)
최종적으로 기억할 핵심
쿠버네티스는 거의 모든 컴포넌트가:
LIST → WATCH → RECONCILE → PATCH/UPDATE
패턴으로 움직입니다.
즉:
Observe (LIST/WATCH)
→ Decide
→ Act (PATCH/UPDATE/CREATE/DELETE)
가 Kubernetes control loop의 본질입니다.
kube-apiserver 내부 파이프라인 상세 구조
kube-apiserver 는 단순 REST API 서버가 아닙니다.
실제로는:
API Gateway
+ Authentication Proxy
+ Authorization Engine
+ Admission Pipeline
+ Object Validation Engine
+ Distributed Watch Broker
+ Consistency Layer
+ Storage Abstraction
가 합쳐진 구조입니다.
전체 Request Lifecycle
가장 중요한 전체 흐름부터 보면:
Client
|
| HTTPS Request
v
+-------------------------------------------------------------+
| kube-apiserver |
|-------------------------------------------------------------|
| 1. Authentication |
| 2. Authorization |
| 3. Mutating Admission |
| 4. Validation / Schema / Defaulting |
| 5. Validating Admission |
| 6. Storage Layer (etcd) |
| 7. Watch Cache Fanout |
+-------------------------------------------------------------+
|
v
etcd
내부 구조 상세
┌──────────────────────────────┐
│ HTTP Server │
│ (go-restful / net/http) │
└─────────────┬────────────────┘
│
v
┌──────────────────────────────┐
│ Authentication │
│------------------------------│
│ x509 │
│ Bearer Token │
│ ServiceAccount JWT │
│ OIDC │
│ Webhook │
└─────────────┬────────────────┘
│ user.Info
v
┌──────────────────────────────┐
│ Authorization │
│------------------------------│
│ RBAC │
│ Node Authorizer │
│ Webhook │
│ ABAC (legacy) │
└─────────────┬────────────────┘
│ allow/deny
v
┌──────────────────────────────┐
│ Admission Chain │
│------------------------------│
│ MutatingAdmissionWebhook │
│ ResourceQuota │
│ PodSecurity │
│ LimitRanger │
│ ValidatingWebhook │
└─────────────┬────────────────┘
│ mutated object
v
┌──────────────────────────────┐
│ Validation / Defaulting │
│------------------------------│
│ OpenAPI Schema │
│ CRD Schema │
│ Strategic Merge │
│ Server Side Apply │
└─────────────┬────────────────┘
│ validated object
v
┌──────────────────────────────┐
│ API REST Storage │
│------------------------------│
│ RESTStrategy │
│ Generic Registry │
│ Storage.Interface │
└─────────────┬────────────────┘
│
v
┌──────────────────────────────┐
│ Watch Cache │
│------------------------------│
│ Cacher │
│ Reflector │
│ DeltaFIFO │
│ Watch Broadcaster │
└─────────────┬────────────────┘
│
v
┌──────────────────────────────┐
│ etcd │
└──────────────────────────────┘
1. Authentication (AuthN)
역할
"누구인가?"
를 확인.
지원 방식
x509 Client Cert
CN=kubelet-node1
O=system:nodes
kubelet
controller-manager
scheduler
가 주로 사용.
Bearer Token
Authorization: Bearer eyJhbGc...
kubectl
operators
CI/CD
ServiceAccount JWT
Pod 내부:
/var/run/secrets/kubernetes.io/serviceaccount/token
OIDC
예:
Dex
Okta
Keycloak
Entra ID
Webhook Authenticator
외부 auth server 위임.
AuthN 결과
최종적으로:
user.Info
생성.
예:
username: system:serviceaccount:argo:argocd
groups:
- system:serviceaccounts
- system:authenticated
2. Authorization (AuthZ)
역할
"무엇을 할 수 있는가?"
판단.
RBAC
가장 핵심.
예:
verbs:
- get
- list
- watch
resources:
- pods
Node Authorizer
kubelet 전용 특수 Authorizer.
예:
node-1 kubelet
→ 자기 node pod만 조회 가능
Webhook Authorizer
OPA/Gatekeeper 같은 외부 시스템 위임.
여기서 평가되는 것
user
verb
resource
namespace
subresource
apiGroup
resourceName
예시
system:serviceaccount:default:app
PATCH deployments.apps
namespace=prod
RBAC 룰과 매칭.
3. Admission Chain
여기가 Kubernetes의 핵심 중 하나.
역할
"요청 객체를 수정/거부"
순서
Mutating Admission
↓
Validation
↓
Validating Admission
Mutating Admission
객체 수정 가능.
예:
Istio Sidecar Injection
Pod 생성
→ Envoy sidecar 자동 추가
Defaulting
imagePullPolicy: IfNotPresent
자동 추가.
대표 Mutating Plugins
Plugin 역할
MutatingAdmissionWebhook custom webhook
ServiceAccount token mount
DefaultStorageClass storageclass default
RuntimeClass runtime inject
Validation
객체 구조 검사.
OpenAPI Validation
replicas: "abc"
거부.
CRD Schema Validation
openAPIV3Schema
기반 검증.
Validating Admission
수정 불가.
허용/거부만 가능.
예시
Pod Security Admission
privileged: true
차단.
Gatekeeper/Kyverno
정책 강제.
예:
latest tag 금지
4. Mutation
실제로는 Admission과 SSA 내부에서 수행.
Strategic Merge Patch
containers:
- name: app
기준 merge.
Server Side Apply
field ownership 추적.
managedFields
생성.
핵심
SSA는 apiserver 내부에서:
3-way merge
수행.
5. API Aggregation
엄청 중요.
Kubernetes API를 확장 가능하게 함.
구조
kubectl
|
v
kube-apiserver
|
+--> core API
|
+--> aggregated API server
예시
API 실제 서버
metrics.k8s.io metrics-server
custom.metrics.k8s.io prometheus-adapter
apiextensions.k8s.io CRD API
APIService
kind: APIService
로 연결.
흐름
kubectl top pod
↓
apiserver aggregation layer
↓
metrics-server
6. Watch Cache
대규모 클러스터 핵심.
문제
etcd 직접 LIST/WATCH 하면:
etcd overload
발생.
해결
apiserver 내부 cacher 사용.
구조
etcd
↑
storage watcher
↑
watch cache
↑
client watchers
역할
LIST 최적화
LIST pod
→ cache memory 응답
WATCH fanout
1 etcd watch
→ 10,000 client watches
핵심 컴포넌트
Component 역할
Cacher object cache
WatchBroadcaster watch fanout
Reflector backend sync
DeltaFIFO event queue
Watch Event 흐름
Pod changed
↓
etcd revision update
↓
storage watcher
↓
watch cache update
↓
broadcast
↓
kubelet/controller/operator
왜 WATCH가 중요한가
Kubernetes control loop는 거의 모두:
WATCH → reconcile
기반.
Polling 아님.
실제 성능 병목
대규모 환경에서는 보통:
병목 원인
LIST storm controller restart
WATCH fanout watcher 너무 많음
Large CRD huge object
PATCH storm status update flood
Admission latency webhook 느림
etcd quorum latency disk/network
실무적으로 가장 위험한 것
Admission Webhook
엄청 자주 장애 원인.
왜냐면:
모든 API write path blocking
이기 때문.
예시
kubectl apply
↓
mutating webhook timeout
↓
entire cluster API latency 증가
그래서 반드시 봐야 하는 메트릭
Admission latency
histogram_quantile(
0.99,
sum by (name,le)(
rate(apiserver_admission_controller_admission_duration_seconds_bucket[5m])
)
)
Watch Cache Metrics
apiserver_watch_cache_events_dispatched_total
Request Volume
sum by (verb,resource,useragent)(
rate(apiserver_request_total[5m])
)
최종 핵심
kube-apiserver는 사실상:
Kubernetes Distributed Kernel
에 가깝습니다.
단순 REST 서버가 아니라:
Identity
+ Policy
+ Mutation
+ Validation
+ Event Distribution
+ State Consistency
+ API Federation
를 모두 담당합니다.
+-------------------------------------------------------------+
| kube-apiserver |
|-------------------------------------------------------------|
| 1. Authentication |
| 2. Authorization |
| 3. Mutating Admission |
| 4. Validation / Schema / Defaulting |
| 5. Validating Admission |
| 6. Storage Layer (etcd) |
| 7. Watch Cache Fanout |
+-------------------------------------------------------------+
이 부분을 표로 정리해 줘 어떤 역할인지
단계 컴포넌트 역할 입력 출력 실패 시 대표 구현/플러그인 주요 Verb 영향
1 Authentication 요청 주체 식별 (누구인가) TLS cert, Bearer Token, JWT, OIDC user.Info 401 Unauthorized x509, ServiceAccount JWT, OIDC, Webhook Authenticator 모든 verb
2 Authorization 요청 권한 확인 (무엇을 할 수 있는가) user, verb, resource, namespace allow / deny 403 Forbidden RBAC, Node Authorizer, Webhook Authorizer GET/LIST/WATCH/CREATE/PATCH 등
3 Mutating Admission 요청 객체 수정/주입 API object mutated object reject / timeout MutatingWebhook, Istio Injection, DefaultStorageClass CREATE, UPDATE, PATCH
4 Validation / Schema / Defaulting 객체 구조 및 schema 검증 mutated object validated object 422 Unprocessable Entity OpenAPI Validation, CRD Schema, SSA merge CREATE, UPDATE, PATCH
5 Validating Admission 정책 기반 허용/거부 validated object final accepted object reject / timeout ValidatingWebhook, PodSecurity, Kyverno, Gatekeeper CREATE, UPDATE, DELETE
6 Storage Layer (etcd) 상태 영속화 및 revision 관리 final object persisted state etcd timeout/quorum failure storage backend, storage.Interface 모든 write path
7 Watch Cache Fanout 변경 이벤트 브로드캐스트 etcd change stream watch events stale cache / lag Cacher, WatchBroadcaster, Reflector WATCH
단계별 실제 흐름 예시
kubectl apply -f deploy.yaml
1. Authentication
"admin 사용자인가?"
2. Authorization
"deployments.apps PATCH 권한 있는가?"
3. Mutating Admission
"sidecar inject"
"default 값 추가"
4. Validation
"schema 맞는가?"
"field type 정상인가?"
5. Validating Admission
"보안 정책 위반 없는가?"
6. Storage Layer
"etcd 저장"
7. Watch Cache Fanout
"controller/scheduler/kubelet 에 변경 이벤트 전파"
각 단계의 목적을 한 줄로 요약
단계 본질
Authentication 신원 확인
Authorization 권한 확인
Mutating Admission 객체 변경
Validation 객체 검증
Validating Admission 정책 검사
Storage 상태 저장
Watch Cache 이벤트 전파
컴포넌트 관점으로 보면
Client Request
↓
[Identity Layer]
Authentication
Authorization
[Policy Layer]
Mutating Admission
Validation
Validating Admission
[Persistence Layer]
Storage(etcd)
[Event Distribution Layer]
Watch Cache
Grafana/Tracing 관점에서 중요한 메트릭
단계 핵심 메트릭
Authentication apiserver_request_total{code="401"}
Authorization apiserver_request_total{code="403"}
Admission apiserver_admission_*
Validation apiserver_request_total{code="422"}
Storage etcd_request_duration_seconds_*
Watch Cache apiserver_watch_cache_*
실제 latency가 가장 많이 발생하는 구간
대규모 클러스터 기준:
순위 병목
1 Admission Webhook
2 etcd quorum write
3 LIST serialization
4 Watch fanout
5 CRD conversion webhook
Write 요청 기준 실제 call stack
HTTP Request
↓
AuthN
↓
AuthZ
↓
Mutating Admission
↓
Defaulting
↓
Validation
↓
Validating Admission
↓
FieldManager(SSA)
↓
etcd write
↓
watch notification
Read 요청은 다름
GET/LIST
HTTP Request
↓
AuthN
↓
AuthZ
↓
Watch Cache / Storage
↓
Response
Admission 안 탐.
WATCH는 더 특수함
WATCH request
↓
AuthN/AuthZ
↓
Watch registration
↓
Long-running stream
↓
Cache fanout
즉:
WATCH = persistent streaming connection
입니다.
Kubernetes 핵심 철학
이 전체 구조는 사실상:
desired state database
+ policy engine
+ event streaming platform
구조입니다.
그래서 kube-apiserver는:
REST API 서버
보다:
Distributed Control Plane Gateway
에 더 가깝습니다.
Kubernetes + Distributed Storage + Distributed Compute
복합 시스템입니다.
특히:
Spark
Polaris
MinIO
대규모 WATCH/LIST
huge CRDs
massive object IO
long-running batch
shuffle traffic
조합은 일반 SaaS Kubernetes와 병목 포인트가 완전히 다릅니다.
우선 현재 규모 해석
대략:
영역 규모
Compute Nodes ~150
Storage Nodes ~90
Total Nodes ~240
Workload 특성 batch + streaming + object IO
주요 병목 API fanout / DNS / CNI / IO / etcd
이 정도면 이미:
"Medium-Large Scale Kubernetes"
영역입니다.
특히 Spark가 들어가면:
Pod churn rate
가 매우 중요해집니다.
당신 환경에서 반드시 추가해야 하는 Deep Monitoring
1. APIServer Deep Tracing
일반 메트릭 말고:
request lifecycle tracing
까지 봐야 함.
반드시 수집
Metric 이유
apiserver_request_duration_seconds 전체 latency
apiserver_response_sizes huge object
apiserver_watch_cache_* cache saturation
apiserver_current_inflight_requests throttling
apiserver_flowcontrol_* APF starvation
apiserver_storage_* etcd storage latency
매우 중요
API Priority & Fairness (APF)
Spark cluster는 burst가 심함.
예:
1000 pod create/sec
가능.
그러면:
controller-manager starvation
발생 가능.
반드시 봐야 함:
apiserver_flowcontrol_current_executing_requests
2. WATCH Fanout Analysis
이 환경에서 매우 중요.
Spark executor 폭증 시:
WATCH explosion
발생.
봐야 하는 것
userAgent 기반
sum by (useragent,verb)(
rate(apiserver_request_total{verb="WATCH"}[5m])
)
핵심 원인 분석
원인 증상
operator bug LIST storm
spark executor churn pod watch flood
informer resync API spike
bad CRD design huge watch payload
3. etcd Deep Visibility
이건 매우 중요.
대규모 datalake cluster는:
etcd tail latency
가 control-plane 전체에 영향 줌.
반드시 봐야 하는 것
Metric 의미
etcd_disk_wal_fsync_duration_seconds WAL latency
etcd_network_peer_round_trip_time_seconds raft RTT
etcd_mvcc_db_total_size_in_bytes DB bloat
etcd_mvcc_compaction_pause_duration_milliseconds compaction stall
grpc_server_handled_total gRPC overload
매우 중요
WAL fsync latency
histogram_quantile(
0.99,
rate(etcd_disk_wal_fsync_duration_seconds_bucket[5m])
)
10ms 넘기 시작하면 위험 신호.
4. Admission Webhook Latency
Spark workload는 Pod 생성 폭증이 있음.
그러면:
admission webhook latency amplification
발생.
실제 위험
1 webhook = 50ms
1000 pod create
= cluster-wide API stall
반드시 수집
apiserver_admission_controller_admission_duration_seconds
5. Scheduler Internal Metrics
Spark는 scheduler 압박 심함.
봐야 하는 것
Metric 의미
scheduler_pending_pods scheduling backlog
scheduler_e2e_scheduling_duration_seconds end-to-end latency
scheduler_framework_extension_point_duration_seconds plugin bottleneck
특히 중요
scheduling latency
Spark executor startup latency
와 직접 연결됨.
6. Kubelet Pressure Deep Dive
Spark executor churn 때문에 kubelet pressure가 핵심.
반드시 봐야 하는 것
Metric 의미
pod worker latency pod lifecycle delay
pleg relist duration runtime sync
runtime operations CRI latency
image pull duration executor startup
cgroup manager latency cpu pressure
매우 중요
PLEG
Pod Lifecycle Event Generator
느려지면 kubelet 장애 전조.
7. CNI / Network Plane
Datalake는:
east-west traffic monster
임.
특히:
shuffle
MinIO replication
Spark executor traffic
봐야 하는 것
Metric 의미
conntrack usage NAT exhaustion
drops/retransmits packet loss
CNI allocation latency pod startup
TCP RTT shuffle latency
MTU fragmentation throughput collapse
매우 중요
conntrack saturation
node_nf_conntrack_entries / node_nf_conntrack_entries_limit
8. MinIO-Specific Deep Monitoring
이건 매우 중요.
MinIO는 사실상 storage backend.
봐야 하는 것
Metric 의미
drive latency disk bottleneck
healing operations degraded set
erasure coding rebuild IO storm
object PUT/GET latency app impact
network throughput replication pressure
매우 중요
MinIO healing
healing은 cluster 전체 IO를 죽일 수 있음.
9. Spark-Specific Control Plane Metrics
이 환경 핵심.
봐야 하는 것
Metric 의미
executor startup latency pod scheduling
executor churn API pressure
shuffle spill disk pressure
dynamic allocation oscillation cluster instability
failed executors node/network issues
매우 중요
executor churn rate
높으면:
API server death spiral
유발 가능.
10. Object Size Monitoring (중요)
대규모 cluster는:
huge object syndrome
발생.
특히 위험
리소스 위험
ConfigMap huge spark config
CRD Status gigantic status
EndpointSlice massive endpoints
봐야 하는 것
apiserver_response_sizes
당신 환경에서 실제 가장 위험한 것들
위험도 TOP 10
위험 영향
WATCH explosion API saturation
Spark pod churn scheduler overload
etcd WAL latency cluster-wide slowdown
admission webhook latency API stall
conntrack exhaustion random network failure
kubelet PLEG stalls node NotReady
huge CRD objects apiserver memory blowup
MinIO healing storms IO collapse
DNS saturation executor failures
EndpointSlice explosion kube-proxy overload
추천 아키텍처
당신 규모면:
Prometheus
+ Thanos
+ Loki
+ Tempo
+ Pyroscope
거의 필수급.
반드시 추천
eBPF Observability
이 환경은 eBPF 가치 큼.
추천:
Tool 용도
Cilium Hubble network flow
Pixie K8s tracing
Parca/Pyroscope profiling
Inspektor Gadget kernel insight
최종적으로 가장 중요한 것
당신 환경은:
CPU/Memory monitoring
단계는 이미 지났습니다.
실제 중요한 건:
Control Plane Dynamics
+
Event Flow
+
Watch Behavior
+
Storage Latency
+
Pod Churn
+
Network Saturation
입니다.
즉:
"Kubernetes distributed systems observability"
관점으로 가야 합니다.