Kubernetes Durum Yönetimi 11/20 | VMware VIRTUALIZATION
Merhaba arkadaşlar bu yazımızıda dağıtımlarımızın durumlarını yöneteceğiz. Deployment yapılandırma detaylarını inceleyeceğiz. Bir dağıtım noktasını yukarı veya aşağı doğru ölçeklendireceğiz. Güncellemeler yapacağız ve geri alacağız (roll update – roll back). Çeşitli nesneleri seçmek için label’ları kullanacağız.
ReplicationControllers (RC), herhangi bir zamanda belirtilen sayıda pod kopyasının çalışmasını sağlar. ReplicationControllers ayrıca roll güncellemeleri gerçekleştirme imkanı sunar. Ancak, bu güncellemeler istemci tarafınca yönetilir. İstemci bağlantıyı kaybederse ve cluster’ı planlanmamış bir durumda bırakırsa bu sorun teşkil eder. İstemci tarafında RC’leri ölçeklendirirken sorunlardan kaçınmak için extensions/v1beta1 API grubuna yeni bir kaynak daha eklendi: Deployments.
Deployment’lar sunucu tarafı güncellemelerinin belirli bir oranda pod almasına izin verir. Deployment’lar ReplicationControllers’dan daha fazla seçim özelliği sunan replicaSets oluşturur.
$ kubectl create deployment webserver --image=nginx:1.13.7-alpine
deployment "webserver" created
Her denetleyici, kube-apiserver’a izledikleri nesnenin mevcut durumunu sorgular. Çalışan node’daki her nesnenin durumu local kubelet’ten geri gönderilir.
Sol üstteki şekil bir container’ı temsil eder. Kubernetes’ler container’ları doğrudan yönetmiyor. Bu yüzden Docker ve benzeri continer engine’leri ile container’lar pod’lar içerisinde konuşlandırılırlar. Sağ tarafında hemen yer alan kare şekil içerisinde container’ın pod içerisindeki halini görebiliriz.
Ardından birçok container tek bir pod içerisinde gösterilmiştir. Bir pod içerisinde ana contaier’ı besleyen yardımcı container’lar olarak düşünebiliriz. Bunlar multi-container pod‘lar olarak adlandırılmaktadır.
Sol altta bir replicaSet görüyoruz. Bu controller belirli sayıda pod’un çalıştığından emin olmamızı sağlar. Pod’ların hepsi aynı podspec ile konuşlandırıldı bu yüzden replica deniliyor. Bir pod yıkılırsa veya bulunursa replicaSet, geçerli çalışan pod sayısına ulaşana kadar pod oluşturur veya sonlandırır. Daha az pod’un çalışması talep edilmesi durumunda mevcut container’ların herhangi biri feshedilebilir.
Sağ alt taraftaki grafikte bir deployment bulunmaktadır. Bu controller pod’larda dağıtılan image’ların sürümlerini yönetmemizi sağlar. Deployment için bir düzenleme yapılması durumunda, yeni podSpec‘i kullanarak pod’ları dağıtacak yeni bir replicaSet oluşturur. Deployment daha sonra yeni replicaSet pod’ları kullanılabilir duruma geldiğinde pod’ları kapatmak için eski replicaSet‘i yönlendirir. Eski pod’ların tümü sonlandırıldığında, deployment eski replicaSet’i sonlandırır ve deployment yalnızca bir replicaSet’in çalışmasına geri döner.
Deployment Detayları ve Yapılandırma Değerleri
Yukarıda yeni oluşturulan nesnenin YAML dosyasını oluşturmak için şunları yapın:
$ kubectl get deployments,rs,pods -o YAML
Bazı zamanlar JSON çıktısı almak daha net bir okunabilirlilik sağlayabilir.
$ kubectl get deployments,rs,pods -o json
Şimdi nesne oluşturulduğunda varsayılan olarak eklenen YAML çıktılarına da bakarak incelemeler yapalım.
NOT : İki yukarıda yapılan webserver dağıtımının YAML dosyaları inceleniyor. Bu YAML dosyası üzerinden açıklamalar yapılarak devam edilecektir.
apiVersion: v1 değeri bu nesnenin kararlı bir kaynak (stable) olarak kabul edildiğini gösterir. YAML formatıan baktığımızda items türüned bir dizinin olduğunu görürüz.
items: Bir liste özelliği taşır. Koutun gösterdiği öğelerin listesini bildirir.
– apiVersion: Kısa çizgi nesnenin kendisini extensions/v1beta1 olarak tanımladığını bildiren YAML göstergesidir. Bu nesnenin kararlı kabul edilmediğini ve dinamik olacağını gösterse de konuşlandırmalar kullanılmasını önerir.
kind: Yaratulacak nesne türünü belirler, bu durumda bir deployment ilan edildiği yerdir.
Deployment Yapılandırma: Metadata
YAML çıktısına devam edersek bir sonraki genel çıktı bloğunun dağıtımdaki metadata’ların olduğunu görüyoruz. Burada label’ları, annotation’ları ve diğer yapılandırmalar için bilgiler bulacağız. Bu YAML çıktısının tüm olası yapılandırmaları göstermeyeceğini unutmayalım. PodAffinity veya nodeAffinity gibi varsayılan olarak false ayarlanan birçok ayar gösterilmez.
Aşağıda bu YAML dosyasında görmüş olduğumuz etiketleri açıklayalım.
annotations: Bu değerler nesneyi yapılandırmaz, ancak üçüncü taraf uygulamalara veya idari izlemeye yardımcı olabilecek nesnelere daha fazla bilgi sağlar. Label’lardan farklı olarak kubectl ile bir nesne seçmek için kullanılmazlar.
creationTimestamp: Nesnenin başlangıçta ne zaman oluşturulduğunu gösterir. Nesne düzenlenirse güncellenmez.
generation: Nesnenin kaç kez düzenlendiği veya replica sayısının değiştirildiği gibi değerleri saklar.
labels: kubectl veya diğer API çağrılarıyla kullanılacak nesneleri seçmek veya hariç tutmak için kullanılan rastgele metinlerdir. Yöneticilerin, tipik nesne sınırları dışında nesneleri seçmesi için kullanışlıdır.
name: Zorunlu bir parametredir. Nesnenin adını belirler ve özgün olması gereklidir.
resourceVersion: Nesnelerin eşzamanlılığına yardımcı olmak için etcd veritabanına bağlı bir değerdir. Veritabanında yapılacak herhangi bir değişiklik bu sayının değişmesine neden olacaktır.
selfLink: kube-apiserver’ın bu bilgiyi API çağrılarına nasıl alacağına dair referans içerir.
uid: Nesnenin ömrü için benzersiz bir kimlikdir.
Deployment Yapılandırma: Spec
Dağıtım için iki tane spec bildirimi vardır. Birincisi oluşturulan ReplicaSet’i değiştirecek, ikincisi ise pod yapılandırmasına geçecektir. Kodumuzun devamına geçelim.
spec: Aşağıda belirtilmiş olan öğelerin nesneyi nasıl yapılandıracağı bilgilerdir.
progressDeadlineSeconds: Bir işlem hata raporladığında değişmesini bekleyen saniye cinsinden süredir. Nedenleri; kotalar, imaj sorunları veya limit aralıkları olabilir.
replicas: Oluşturulan nesne bir ReplicaSet olduğundan, bu parametre kaç tane pod oluşturulması gerektiğini belirler. Eğer kubectl edit‘i kullanıp bu değeri ikiye çıkarırsanız ikinci bir pod oluşturacaktır.
revisionHistoryLimit: Rollback için kaç tane eski ReplicaSet spec’i tutacaktır.
selector: Replica’ların eşleşmesi ve seçimi için önemlidir.
matchLabels: Genellikle kaynağın nerede zamanlanacağını belirlemek için matchExpressions ifadesiyle bulunan değer diyebiliriz.
strategy: Pod’ları güncellemekle ilgili değerler için bir başlık görevi görür. RollingUpdate ile aşağıdaki parametreleri ile bir seferde kaç pod’un silineceğini kontrol edebilirsiniz.
maxsurge: İstenilen pod sayısı üzerinden maksimum pod sayısını oluşturmanızı sağlar. Yüzde, varsayılan olarak %25 veya mutlak bir sayı olabilir.
maxUnavailable: Güncelleme işlemi sırasında Ready durumu dışında oluşabilecek pod sayısı veya yüzdesi.
type: Girinti düzeyi nedeniyle son bölümde listelenemsine rağmen yapılandırmakta olan nesnenin türü olarak okunur (örneğin, RollingUpdate).
Deployment Yapılandırma: Pod Şablonu
- image: nginx:1.13.7-alpine
Not: Daha önce tanımladığımız değerler karşımıza çıkarsa aynı değerleri burada görmeyeceğiz.
template: Bir nesnenin nasıl dağıtlacağını belirlemek için ReplicaSet’e veri aktarılıyor. Bu durumda container’lar için kullanılmış.
containers: Bu girinti aşağıdaki öğelerin bir container parametreleri olduğunu gösteren anahtar kelimedir.
image: Genellikle Docker’a olmak üzere container engine’ine iletilen imaj dosyasının adıdır.
imagePullPolicy: Policy ayarları bir imajın ne zaman ve yerel bir önbellekten indirilip kullanılması gerektiğine ilişkin verileri container engine’ine iletir.
name: Pod isimlerini belirler. Benzersiz bir metin eklenecektir.
resources: Varsayılan olarak boştur. Burası container’lar için CPU veya Memory gibi kaynak kısıtlamaları ve ayarları yaptığımzı yerdir.
terminationMessagePath: Bir container’ın başarı veya başarısızlık bilgisinin çıktılanacağı özelleştirilebilir bir konumdur.
terminationMessagePolicy: Varsayılan değer File olarak ayarlanmıştır. Termination işlemini tutan yer olarak bilgi tutar. Ayrıca mesaj dosyası boş ise ve contaienr bir hata gösteriyorsa FallbackToLogsOnError olarak da ayarlanılabilir.
dnsPolicy: DNS sorgularının kube-dns’e mi gideceğini yoksa Default olarak ayarlandıysa, node’un DNS çözme yapılandırmasını kullanıp kullanmayacağını belirler.
restartPolicy: Yıkıldığında container’ın yeniden başlatılması durumunda kullanılır. Otomatik yeniden başaltmalar Kubernetes’in gücünün bir parçasıdır.
scheduleName: Varsayılan Kubernetes yerine özel bir scheduler kullanılmasına izin verir.
securityContext: SELinux context, AppArmor değerleri, kullanıcılar ve container’ların kullanılsması için UID’ler gibi bir veya daha fazla güvenlik ayarını geçmek için esnek bir ayardır.
terminationGracePeriodSeconds: Container’ı sonlandırmak için bir SIGKILL’in kullanılmasına kadar SIGTERM’in çalışmasını beklemek için geçen süre.
Deployment Yapılandırma: Status
- lastTransitionTime: "2019-04-15T21:58:05Z"
availableReplicas: ReplicaSet tarafından kaç tane yapılandırıldığını gösterir. Bu tüm kopyaların tamamen ve hatasız üretilip üretilmediğini belirlemek için kullanılacak readyReplicas’ın daha sonraki değerleriyle karşılaştırılır.
observerGeneration: Dağıtımın ne sıklıkla güncellendiğini gösterir. Bu bilgi, konuşlandırmanın rollout ve rollback durumunu anlamak için kullanılır.
API sunucusu, yapılandırma ayarlarının çoğunun güncellenmesine izin verir. Dağıtılmış olan Kubernetes sürümüne bağlı olarak değişebilecek ve değişmeyecek bazı değerler vardır.
Yaygın olarak kullanılan bir güncelleme, çalışan replica sayısını değiştirmektir. Bu sayı sıfıra ayarlanırsa container olmaz, ancak yinede bir ReplicaSet ve Deployment olur.
$ kubectl scale deploy/webserver --replicas=2
deployment "webserver" scaled
webserver   2/2     2            2           69m
Örneğin dağıtmış olduğumuz webserver isimli deployment’ın sürümünü değiştirmek için aşağıdaki komutu kullanarak metin düzenleyicide değiştirebilirsiniz.
$ kubectl edit deployment webserver
Burada nginx versiyonunu güncelleyebilirsiniz.
Deployment Rollback İşlemi
Yukarıda ölçeklendirdiğimiz webserver dağıtımını önceki bir revizyonuna alabilirisz. Tutulan önceki yapılandırmalar tekrardan konfigüre edilebilir. Bu işlemi bir örnek üzerinden gerçekleştirelim.
$ kubectl create deploy rollbackdeneme --image=nginx:1.13
$ kubectl set image deployment/rollbackdeneme nginx=nginx:18 --all
deployment.extensions/rollbackdeneme image updated
$ kubectl rollout undo deployment/rollbackdeneme
deployment.extensions/rollbackdeneme rolled back
NAME                              READY   STATUS             RESTARTS   AGE
rollbackdeneme-54b8c6bbcc-c2lbm   0/1     ImagePullBackOff   0          4s
–to-revision=2 gibi bir seçenekle istediğiniz revizyona dönerbilirsiniz. kubectl edit komutunu kullanarak Deployment’ı düzenleyebilirsiniz. Ayrıca bir Deployment’ı durdurabilir ve sonra devam ettirebilirsiniz.
$ kubectl rollout pause deployment/rollbackdeneme
$ kubectl rollout resume deployment/rollbackdeneme
Çalışacağımız yeni bir nesne daha var: DeamonSets. Bu controller cluster’daki her node’da tek bir pod’un bulunmasını sağlar. Yeni bir node eklendiğinde DeamonSet controller sizin adınıza yeni bir pod dağıtacaktır. Bir node’un silinmesi veya çıkarılması durumunda controller pod’u silecektir.
DeamonSet’i kullanmı, belirli bir container’ın her zaman çalışmasını sağlar.
Bir nesnenin metadata’larının bir kısmı label’dır. Label’lar API nesneleri olmasada cluster yönetimi için önemli bir araçtır. Nesne türüne bakılmaksızın, rastgele bir dizeye dayalı bir nesneyi seçmek için kullanılabilirler.
Her kaynak metadata içerisinde label içerebilirler. Varsayılan olarak kubectl create ile bir Deployment oluşturduğumuzda label’ı ekler.
Yukarıdaki kod ile pod’ların label’larını listeleyebilirsiniz.
Yazımızın bu noktasında Kubernetes Durum Yönetimini tamamlamış bulunmaktayız. Bir sonraki yazımda burada anlatılan teorinin uygulaması yapılacak ve hemen ardından Kubernetes’de Service kullanımını göreceğiz. Labaratuvara buradan ulaşabilirsiniz. Görüşmek üzere !
DeamonSets Deployment Yapılandırma Kubernetes Kubernetes Eğitim Serisi Kubernetes Eğitimi Labels Metadata Rollback Rollout
Önceki: Önceki yazı: Kubernetes LAB04 10/20
Sonraki: Sonraki yazı: Kubernetes LAB05 12/20