Güncellendi:
Kubernetes’i öğrenirken nesne adlarını ezberlemekten çok aralarındaki ilişkiyi anlamak yararlıdır. Bir uygulamanın çalıştırılması, ağa açılması, yapılandırma alması ve veriyi saklaması farklı kaynaklarla yönetilir. Bu rehber, ilk uygulama tasarımında karşılaşılan kavramların görevlerini ve sınırlarını açıklar.
Görseli büyüt →
Kontrol düzlemi ve worker node
Kontrol düzlemi API, zamanlama ve kontrol döngülerini yönetir. Worker node’larda container çalışma zamanı ve kubelet gibi bileşenler iş yüklerini yürütür. Bir node’un hazır olması, üzerindeki bütün uygulamaların doğru yanıt verdiğini göstermez; altyapı ve uygulama sağlıklarını ayrı izleyin.
Yönetilen bir hizmette bu katmanların bazıları sağlayıcı tarafından işletilebilir. Hangi bileşenin güncellemesi, yedeği ve erişim politikasının kime ait olduğunu ürünün kapsamından doğrulayın. Erişebildiğiniz bir yönetim ekranı bütün altyapı sorumluluğunu devraldığınız veya devrettiğiniz anlamına gelmez.
Pod ile Deployment farklı görevler üstlenir
Pod, birlikte yerleştirilen ve bazı kaynakları paylaşan container’ların çalışma birimidir. Tek başına kalıcı kimlik veya disk garantisi değildir. Deployment, uygun iş yükleri için Pod örneklerinin istenen sayısını ve dağıtım durumunu yönetir; Pod yeniden oluşturulduğunda önceki örneğin yerel dosyalarının korunacağını varsaymayın.
StatefulSet, Job ve CronJob gibi kaynaklar farklı yaşam döngüleri içindir. StatefulSet kullanmak veritabanının yedeğini veya replikasyonunu otomatik kurmaz. Çalıştırma kaynağını uygulamanın durum ve tamamlanma davranışına göre seçin.
Service ve dış erişim
Service, uygun Podlara ulaşmak için kararlı bir erişim soyutlaması sağlar. Pod etiketleriyle Service seçicilerinin uyuşması gerekir. Dış dünyaya erişim için kullanılan ingress, gateway veya load balancer bileşenleri ayrıca kurulmuş ve yapılandırılmış olmalıdır.
Bir Service oluşturmak TLS sertifikası, alan adı veya bütün dış ağ kurallarını kendiliğinden tamamlamaz. DNS, sertifika, yönlendirme ve uygulama hazır olma durumunu uçtan uca doğrulayın.
ConfigMap, Secret ve namespace
ConfigMap gizli olmayan yapılandırmayı taşır. Secret hassas değerler için ayrı bir kaynak türüdür; base64 gösterimi şifreleme değildir. Secret’a kimlerin erişebildiği, API saklama koruması ve değerlerin loglara yazılıp yazılmadığı ayrıca kontrol edilmelidir.
Namespace kaynakları gruplamak ve yönetim kapsamını düzenlemek için kullanılır. Tek başına eksiksiz bir güvenlik sınırı değildir. RBAC, kaynak kotaları ve gereken ağ politikalarıyla tamamlanmalıdır. NetworkPolicy’nin beklenen etkisi için ağ eklentisinin ilgili davranışı desteklediğini doğrulayın.
Kaynak ve sağlık tanımları
Requests, zamanlama için dikkate alınan kaynak talebini; limits ise ilgili kaynak türüne göre uygulanabilen sınırları ifade eder. Çok düşük limit veya yanlış talep, CPU kısıtlaması ya da bellek kaynaklı sonlandırma gibi sorunlara yol açabilir. Değerleri gerçek yük ölçümlerinden türetin.
Readiness, uygulamanın trafiğe hazır olup olmadığını; liveness, gerektiğinde yeniden başlatma kararını; startup probe ise yavaş açılan uygulamaların başlangıç davranışını destekler. Bütün kontrolleri aynı endpoint’e kör biçimde bağlamak yerine görevlerini ayırın.
Kalıcı depolamayı ayrıca planlayın
PersistentVolumeClaim, depolama isteğini ifade eder. StorageClass ve sürücü, bu isteğin nasıl karşılanacağını belirler. Erişim modu, bölge bağımlılığı, performans ve silme politikası seçilen altyapıya bağlıdır. PVC’nin bağlı olması, uygulama verisinin yedeklendiği veya geri yüklenebilir olduğu anlamına gelmez.
Sık sorulan sorular
- Secret içindeki base64 değer güvenli şifreleme midir?
-
Hayır. Kodlama ile şifreleme farklıdır. Yetki, saklama koruması ve uygulamanın değeri kullanma biçimi ayrıca yönetilmelidir.
- Namespace farklı ekipleri tamamen izole eder mi?
-
Tek başına değil. Yetkiler, ağ politikaları, kota ve gerektiğinde daha güçlü sınırlar ayrıca tasarlanmalıdır.
Sonraki adım
Günlük işletimi Kubernetes yönetim rehberi ve sorun incelemesini Kubernetes ipuçları üzerinden ilerletin.
