Kubernetes Kümesi (Kubernetes Cluster / K8s)

Sistem Analizi

İşlem (Compute)PRODUCTION

Normal Davranış

Geliştiriciler istenilen sistem durumunu bildirime dayalı YAML bildirgeleri (declarative YAML manifests) kullanarak tanımlar. Kontrol düzlemi API sunucusu (control plane API server) bu durumu etcd'de saklar, zamanlayıcı (scheduler) kaynak taleplerine göre konteyner kapsüllerini (container pods) en uygun işçi düğümlerine (worker nodes) atar ve düğüm kubelet'i yerel konteyner çalışma zamanlarının (container runtimes) çalışan konteynerleri beyan edilen spesifikasyonlara uygun olarak sürdürmesini sağlar.

Çöküş Davranışı

Aşırı kaynak baskısı veya yanlış yapılandırma altında, işçi düğümlerinin belleği tükenir (out of memory - OOM), bu da kitlesel kapsül tahliyelerini (pod evictions) ve Çökme Döngüsü Geri Çekilme (CrashLoopBackOff) durumlarını tetikler. Eğer etcd G/Ç (I/O) gecikmesi veya ağ bölümlenmeleri (network partitions) yaşarsa, kontrol düzlemi fikir birliğini (consensus) kaybeder, dağıtımları dondurur ve tüm küme (cluster) genelinde yönlendirme (routing) hatalarına neden olur.

İş Sonuçları

Kubernetes kontrol düzleminin veya düğüm havuzunun (node pool) feci bir şekilde çökmesi orkestrasyon katmanını yok eder. Uygulamalar dağıtım, ölçeklendirme ve kendi kendini onarma (self-healing) mekanizmalarını kaybeder. Durum (state) korunamaz, servisler iletişim kuramaz ve tüm platform çökerek saatler süren devasa bir felaket kurtarma (disaster recovery) ve durum mutabakatı (state reconciliation) çabası gerektirir.

Görsel Tezahür

"`kubectl get nodes` komutu 'Sunucuya bağlantı reddedildi' (The connection to the server was refused) hatası döndürür ve binlerce kapsül 'Bilinmeyen' (Unknown) veya 'Sonlandırılıyor' (Terminating) durumlarına geçer."

Satirical Behavior

"An operating system for the cloud that takes 40 engineers to maintain, primarily used to run 3 microservices that would have worked fine on a single Linux VM."

Bilinen İsimler

K8sContainer Orchestrator

Teknik Terminoloji

Scheduling podsHorizontal pod autoscalingApplying manifests

Hata Göstergeleri

CrashLoopBackOffOOMKilledNode NotReady

Sistem Mimarisi

Click or hover to interact

Kullanan Karakterler

cloud bill

FAQ

Normalde nasıl davranır?

Nasıl çöker?

İş sonuçları nelerdir?

How does Kubernetes decide where to schedule a pod and what causes Pod Unschedulable errors?

The kube-scheduler uses a two-step process: Filtering (predicates) to find all worker nodes that meet the pod's CPU, memory, node selector, and affinity constraints, followed by Scoring (priorities) to rank the remaining nodes. A pod enters an Unschedulable state when no single node possesses sufficient unallocated allocatable CPU or memory matching the pod's specified requests, or when taints prevent scheduling without matching tolerations.

What is the difference between pod resource requests and resource limits in Kubernetes?

Resource requests represent the guaranteed baseline CPU and memory reserved for a container during scheduling; the scheduler only places a pod on a node with enough unreserved capacity. Resource limits define the hard ceiling a container cannot exceed; if a container surpasses its memory limit, the Linux kernel Out-Of-Memory (OOM) killer immediately terminates the process (OOMKilled, exit code 137), whereas CPU exceeding limits results in CPU throttling rather than pod termination.

Sistemi keşfet

Incidentpedia'da devam et→Olay Dizinini oku→Stack'leri incele→Konuları keşfet→Bölümleri izle→Ajanlar→

AI özeti

Kubernetes Cluster is a COMPUTE system in TinyCTO.tv. Developers declare desired system state using declarative YAML manifests. The control plane API server stores this state in etcd, the scheduler assigns container pods to optimal worker nodes based on resource requests, and the node kubelet ensures local container runtimes maintain the running containers in accordance with the declared specifications.