Kubernetes Bölüm 3: Deployment, Stateful Sets, Daemon Sets, Service, Label, Annotation, Secret

Deployment

Rest objeleleridir. Workload’ları yaratmak ve yönetmek için yaygın bir şekilde kullanılırlar. Dockerfile’a benzer bir yapısı vardır.

Deployment, Replica Set ile derlenirken Replication Controller’ın birçok fonksiyonunu kopyalıyor gibi gözükse de rolling update noktasında birçok problemin çözülmesini sağlamaktadır. Replication Controller kullanarak update işlemi yapılmak istendiğinde öncelikle yeni Replication Controller için plan sunulmak zorundadır, ayrıca geçmişi izleme, güncelleme sırasında ağ hatalarından kurtarma ve kötü değişiklikleri geri almak gibi görevler ya zordur ya da kullanıcının sorumluluğunda kalır.

Deployment’lar, replicated Pod’ların yaşam döngüsü yönetimini kolaylaştırmak için tasarlanmış yüksek düzeyli bir nesnedir. Yapılandırmayı değiştirerek Deployment’lar kolayca değiştirilebilir ve Kubernetes replika set’lerinde ayarlayacak, farklı uygulama sürümleri arasındaki geçişleri yönetecek ve isteğe bağlı olarak olay geçmişini ve geri alma özelliklerini otomatik olarak koruyacaktır. Bu özellikler nedeniyle, Deployment’lar büyük olasılıkla en sık çalıştığınız Kubernetes nesnesi türü olacaktır.

Stateful Sets

Sıralama ve benzersizlik garantileri sunan Pod controller’ıdır. Deployment emri, persistent data veya stabil ağ bağlantısına ihtiyaç duyulduğunda daha hassas kontrole ihtiyaç duyulduğunda kullanılırlar.

Stateful sets, Pod’un başka bir node’a taşınması gerektiğinde her bir Pod için sayıya dayalı bir isim oluşturarak stabil bir ağ tanımlayıcısı sağlar. Yine rescheduling gerektiğinde persistent storage volume’lar bir Pod ile birlikte aktarılabilir.

Daemon Sets

Cluster’daki her node’da bir Pod’un kopyasını çalıştıran Pod Controller’ın özel bir formudur. Node’ların servis sağlamasına ve Pod’ların deployment’ında çok faydalıdır.

Örneğin, logların toplanması ve iletilmesi, metriklerin toplanması ve node’un kendi yeteneklerini artıran hizmetlerin çalıştırılması daemon sets için popüler adaylardır. Ben geçmişte fluentd ile logların toplanması için Kubernetes üzerinde koşturmuştum, o zaman bunu daemon set üzerinden yapmıştık. Cluster’a sonradan bir node eklenirse de daemon set otomatik yüklendiği için takip etmek oldukça kolaylaşıyordu.

Daemon sets genellikle temel hizmetler sağladığından ve fleet boyunca ihtiyaç duyulduğundan, diğer controller’ların belirli host’lara Pod’ları atamasını engelleyen Pod scheduling restriction’ları (planlama kısıtlamaları) atlayabilirler. Örnek olarak, benzersiz sorumlulukları nedeniyle, Master sık sık normal Pod planlaması için kullanılamayacak şekilde yapılandırılır, ancak daemon sets, temel hizmetlerin çalıştığından emin olmak için Pod bazında kısıtlamayı geçersiz kılma yeteneğine sahiptir.

Service

Service (servis) terimini: uzun süre çalışan, genellikle ağa bağlı, isteklere yanıt verebilen precess’leri belirtmek için geleneksel Unix  ile benzeri anlamda kullanıyorduk. Ancak Kubernetes’te Service, Pod’lar için temel bir dahili yük dengeleyici (load balancer) ve elçi olarak görev yapan bir bileşendir. Bir Service, bunları tek bir varlık olarak sunmak için aynı fonksiyonu gerçekleştiren mantıksal Pod koleksiyonlarını bir araya getirir.

Bu, belirli bir türdeki tüm backend container’larını izleyip yönlendirebilen bir Service dağıtmanıza olanak tanır. İç müşterilerin yalnızca Service tarafından sağlanan kararlı endpoint’leri bilmeleri gerekir. Bu arada, Service soyutlaması, backend birimlerini gerektiği gibi ölçeklendirmenize veya değiştirmenize olanak tanır. Bir Service’in IP adresi, yönlendirdiği Pod’lardaki değişikliklerden bağımsız olarak sabit kalır. Bir Service’i dağıtarak kolayca keşfedilebilirlik kazanır ve Pod tasarımlarınızı basitleştirebilirsiniz.

Bir veya daha fazla Pod’a başka bir uygulamaya veya harici consumer’lara erişim sağlamanız gerektiğinde, bir Service yapılandırmanız gerekir. Örneğin, internetten erişilebilmesi gereken web sunucularını çalıştıran bir dizi Pod’unuz varsa, bir Service gerekli soyutlamayı sağlayacaktır. Benzer şekilde, web sunucularınızın verileri depolaması ve alması gerekiyorsa, veritabanı Pod’unuza erişim sağlamak için internal bir Service yapılandırmak isteyebilirsiniz.

Service’ler, varsayılan olarak yalnızca internal olarak yönlendirilebilir geçerli bir IP adresi kullanarak kullanılabilir olsa da, birkaç stratejiden biri seçilerek cluster dışında da kullanılabilir hale getirilebilirler. NodePort yapılandırması, her node’un harici ağ arabiriminde bir statik bağlantı noktası açarak çalışır. Harici bağlantı noktasına gelen trafik, bir dahili cluster ip servisi kullanılarak uygun Pod’lara otomatik olarak yönlendirilecektir.

Alternatif olarak, LoadBalancer Service türü, bir bulut sağlayıcısının Kubernetes yük dengeleyici entegrasyonunu kullanarak Service’e yönlendirmek için harici bir yük dengeleyici oluşturur. Cloud controller manager, uygun kaynağı oluşturacak ve internal service hizmeti adreslerini kullanarak bunu yapılandıracaktır.

Label ve Annotation

Kubernetes’teki bir Lael, Kubernetes nesnelerini bir grubun parçası olarak işaretlemek için eklenebilen anlamsal bir etikettir. Bunlar daha sonra yönetim veya rooting için farklı instance’ları hedeflerken kullanılabilir. Örneğin, controller tabanlı nesnelerin her biri, üzerinde çalışması gereken Pod’ları tanımlamak için Label’ları kullanır. Service’ler, istekleri yönlendirmeleri gereken backend Pod’ları anlamak için Label’ları kullanır.

Label’lar basit  key / value (anahtar / değer) çiftleri olarak girilir. Her birimin birden fazla Label’ı olabilir, ancak her birimin her key için yalnızca bir kaydı olabilir. Genellikle bir “name” key’i genel amaçlı bir tanımlayıcı olarak kullanılır, ancak nesneleri ayrıca geliştirme aşaması, genel erişilebilirlik, uygulama sürümü vb. gibi diğer kriterlere göre de sınıflandırabilirsiniz.

Annotation, bir nesneye rastgele key / value bilgileri eklemenize olanak tanıyan Label benzeri bir mekanizmadır. Label’lar semantik bilgiler için bir Pod seçim kriterleriyle eşleştirmekte kullanılması gerekirken, Annotation daha serbest biçimdedir ve daha az yapılandırılmış veri içerebilir. Genel olarak Annotation’lar, bir nesnenin seçiminde bir işe yaramazlar, kullanım amacı zengin metadata eklemektir.

Secret

Docker Swarm’daki secret ile aynı mantıkta çalışır. Temel amacı hassas verilerimizi 3. Kişilerin eline geçmemesini sağlamaktır. Özellikle Database barındıracak bir Pod ayağa kaldırdığımızda secret kullanımı kaçınılmazdır.

Bir cecret şöyle oluşturulur:

Type’lar:

  • generic: Lokal bir dosyadan, dizinden veya değişmez değerden oluşturulabilir.
  • docker-registry: Docker Registry ile kullanmak üzere bir secret oluşturulabilir.
  • tls: Verilen public/private key çiftinden tls secret oluşturulur.Public/private key’ler önceden var olmalı ve public key .pem olarak encode edilmiş olmalıdır.

Data Science Earth

Data Science Earth ekibi, üst düzey Veri Bilim çözümleri üretmek amacı ile toplanmış akademisyenler ve uzmanlardan oluşmaktadır. Öncelikli olarak veri bilincini geliştirmeyi ve küreselleşen rekabet ortamında verinin gücünün doğru kullanılmasını sağlamayı amaçlamaktadır.

Sponsor

QuestionPro 35 farklı soru seçim özelliği ile anket çalışmalarımıza güç katmaktadır.