https://mungops.github.io/devops/kubernetes/deepdive/ Recent content in Kubernetes DD on mungOps Hugo en https://mungops.github.io/devops/kubernetes/deepdive/k8s00/ Mon, 01 Jan 0001 00:00:00 +0000 https://mungops.github.io/devops/kubernetes/deepdive/k8s00/ <div class="hextra-code-block hx-relative hx-mt-6 first:hx-mt-0 hx-group/code"> <div><pre><code>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 전체 구조도 &#43;-------------------&#43; | kubectl / CI | | humans / bots | &#43;---------&#43;---------&#43; | | GET/LIST/WATCH | CREATE/UPDATE/PATCH/DELETE v &#43;----------------------------------------------------------------------------------&#43; | kube-apiserver | |----------------------------------------------------------------------------------| | Authentication → Authorization → Admission → Validation → etcd | &#43;----------------------------------------------------------------------------------&#43; ^ ^ ^ ^ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | &#43;-------&#43;----&#43; &#43;-------&#43;------&#43; &#43;---------&#43;------&#43; &#43;---------&#43;--------&#43; | kubelet | | controller | | scheduler | | cloud-controller | | | | manager | | | | manager | &#43;-------&#43;----&#43; &#43;-------&#43;------&#43; &#43;---------&#43;------&#43; &#43;---------&#43;--------&#43; | | | | | | | | | | | | &#43;----------------&#43;--------------------&#43;---------------------&#43; | | v &#43;------&#43; | etcd | &#43;------&#43; 컴포넌트별 Verb 흐름 1. kubelet ↔ kube-apiserver kubelet → apiserver kubelet | &#43;--&gt; WATCH Pods &#43;--&gt; WATCH ConfigMaps &#43;--&gt; WATCH Secrets &#43;--&gt; WATCH RuntimeClasses &#43;--&gt; GET Node &#43;--&gt; PATCH Node/status &#43;--&gt; UPDATE Node/status &#43;--&gt; CREATE Event &#43;--&gt; PATCH Lease &#43;--&gt; GET CSR &#43;--&gt; 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 | &#43;--&gt; WATCH * &#43;--&gt; LIST * &#43;--&gt; UPDATE status &#43;--&gt; PATCH objects &#43;--&gt; CREATE Pods &#43;--&gt; DELETE Pods &#43;--&gt; 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 | &#43;--&gt; WATCH Pods &#43;--&gt; WATCH Nodes &#43;--&gt; WATCH PVC/PV &#43;--&gt; WATCH CSINodes &#43;--&gt; PATCH Pod/binding &#43;--&gt; 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 | &#43;--&gt; WATCH Nodes &#43;--&gt; UPDATE Nodes &#43;--&gt; WATCH Services &#43;--&gt; UPDATE Services/status &#43;--&gt; CREATE Events 대표 Verb Resource Verb services/status UPDATE nodes PATCH routes CREATE events CREATE 5. kubectl ↔ kube-apiserver kubectl | &#43;--&gt; GET &#43;--&gt; LIST &#43;--&gt; WATCH &#43;--&gt; CREATE &#43;--&gt; APPLY(PATCH) &#43;--&gt; DELETE &#43;--&gt; PATCH &#43;--&gt; 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=&#34;WATCH&#34;}[5m]) ) kubelet PATCH storm sum by (node) ( rate(apiserver_request_total{ verb=&#34;PATCH&#34;, resource=&#34;nodes&#34; }[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 &#43; Authentication Proxy &#43; Authorization Engine &#43; Admission Pipeline &#43; Object Validation Engine &#43; Distributed Watch Broker &#43; Consistency Layer &#43; Storage Abstraction 가 합쳐진 구조입니다. 전체 Request Lifecycle 가장 중요한 전체 흐름부터 보면: Client | | HTTPS Request v &#43;-------------------------------------------------------------&#43; | kube-apiserver | |-------------------------------------------------------------| | 1. Authentication | | 2. Authorization | | 3. Mutating Admission | | 4. Validation / Schema / Defaulting | | 5. Validating Admission | | 6. Storage Layer (etcd) | | 7. Watch Cache Fanout | &#43;-------------------------------------------------------------&#43; | 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) 역할 &#34;누구인가?&#34; 를 확인. 지원 방식 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) 역할 &#34;무엇을 할 수 있는가?&#34; 판단. 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의 핵심 중 하나. 역할 &#34;요청 객체를 수정/거부&#34; 순서 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: &#34;abc&#34; 거부. 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 | &#43;--&gt; core API | &#43;--&gt; 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 &#43; Policy &#43; Mutation &#43; Validation &#43; Event Distribution &#43; State Consistency &#43; API Federation 를 모두 담당합니다. &#43;-------------------------------------------------------------&#43; | kube-apiserver | |-------------------------------------------------------------| | 1. Authentication | | 2. Authorization | | 3. Mutating Admission | | 4. Validation / Schema / Defaulting | | 5. Validating Admission | | 6. Storage Layer (etcd) | | 7. Watch Cache Fanout | &#43;-------------------------------------------------------------&#43; 이 부분을 표로 정리해 줘 어떤 역할인지 단계 컴포넌트 역할 입력 출력 실패 시 대표 구현/플러그인 주요 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 &#34;admin 사용자인가?&#34; 2. Authorization &#34;deployments.apps PATCH 권한 있는가?&#34; 3. Mutating Admission &#34;sidecar inject&#34; &#34;default 값 추가&#34; 4. Validation &#34;schema 맞는가?&#34; &#34;field type 정상인가?&#34; 5. Validating Admission &#34;보안 정책 위반 없는가?&#34; 6. Storage Layer &#34;etcd 저장&#34; 7. Watch Cache Fanout &#34;controller/scheduler/kubelet 에 변경 이벤트 전파&#34; 각 단계의 목적을 한 줄로 요약 단계 본질 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=&#34;401&#34;} Authorization apiserver_request_total{code=&#34;403&#34;} Admission apiserver_admission_* Validation apiserver_request_total{code=&#34;422&#34;} 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 &#43; policy engine &#43; event streaming platform 구조입니다. 그래서 kube-apiserver는: REST API 서버 보다: Distributed Control Plane Gateway 에 더 가깝습니다. Kubernetes &#43; Distributed Storage &#43; 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 &#43; streaming &#43; object IO 주요 병목 API fanout / DNS / CNI / IO / etcd 이 정도면 이미: &#34;Medium-Large Scale Kubernetes&#34; 영역입니다. 특히 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 &amp; 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=&#34;WATCH&#34;}[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 &#43; Thanos &#43; Loki &#43; Tempo &#43; 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 &#43; Event Flow &#43; Watch Behavior &#43; Storage Latency &#43; Pod Churn &#43; Network Saturation 입니다. 즉: &#34;Kubernetes distributed systems observability&#34; 관점으로 가야 합니다.</code></pre></div><div class="hextra-code-copy-btn-container hx-opacity-0 hx-transition group-hover/code:hx-opacity-100 hx-flex hx-gap-1 hx-absolute hx-m-[11px] hx-right-0 hx-top-0"> <button class="hextra-code-copy-btn hx-group/copybtn hx-transition-all active:hx-opacity-50 hx-bg-primary-700/5 hx-border hx-border-black/5 hx-text-gray-600 hover:hx-text-gray-900 hx-rounded-md hx-p-1.5 dark:hx-bg-primary-300/10 dark:hx-border-white/10 dark:hx-text-gray-400 dark:hover:hx-text-gray-50" title="Copy code" > <div class="copy-icon group-[.copied]/copybtn:hx-hidden hx-pointer-events-none hx-h-4 hx-w-4"></div> <div class="success-icon hx-hidden group-[.copied]/copybtn:hx-block hx-pointer-events-none hx-h-4 hx-w-4"></div> </button> </div> </div>