Kubernetes Durum Yönetimi 11/20

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.

Deployments

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

Nesnelerin İlişkisi

Her denetleyici, kube-apiserver’a izledikleri nesnenin mevcut durumunu sorgular. Çalışan node’daki her nesnenin durumu local kubelet’ten geri gönderilir.

Kubernetes-Nesnelerinin-İlişkisi
Nesnelerin İlişkisi

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 imajları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
Deployments-rs-pods-YAML-ciktisi
Kod Çıktısı

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
items:
- apiVersion: extensions/v1beta1
  kind: Deployment

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ünde bir dizinin olduğunu görürüz.

items: Bir liste özelliği taşır. Komutun 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.

metadata:
    annotations:
      deployment.kubernetes.io/revision: "1"
    creationTimestamp: "2019-04-15T21:58:01Z"
    generation: 1
    labels:
      app: webserver
    name: webserver
    namespace: default
    resourceVersion: "984342"
    selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/webserver
    uid: 89dbd1a5-5fc9-11e9-bd37-42010a8e000e

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:
    progressDeadlineSeconds: 600
    replicas: 1
    revisionHistoryLimit: 10
    selector:
      matchLabels:
        app: webserver
    strategy:
      rollingUpdate:
        maxSurge: 25%
        maxUnavailable: 25%
      type: RollingUpdate

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

    template:
      metadata:
        creationTimestamp: null
        labels:
          app: webserver
      spec:
        containers:
        - image: nginx:1.13.7-alpine
          imagePullPolicy: IfNotPresent
          name: nginx
          resources: {}
          terminationMessagePath: /dev/termination-log
          terminationMessagePolicy: File
        dnsPolicy: ClusterFirst
        restartPolicy: Always
        schedulerName: default-scheduler
        securityContext: {}
        terminationGracePeriodSeconds: 30

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

  status:
    availableReplicas: 1
    conditions:
    - lastTransitionTime: "2019-04-15T21:58:05Z"
      lastUpdateTime: "2019-04-15T21:58:05Z"
      message: Deployment has minimum availability.
      reason: MinimumReplicasAvailable
      status: "True"
      type: Available
    observedGeneration: 1
    readyReplicas: 1
    replicas: 1
    updatedReplicas: 1

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.

Scaling and Rolling Updates

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

$ kubectl get deployments
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
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
....
spec:
      containers:
      - image: nginx:1.13.7-alpine
        imagePullPolicy: IfNotPresent
....

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
deployment.apps/rollbackdeneme created

$ kubectl set image deployment/rollbackdeneme nginx=nginx:18 --all
deployment.extensions/rollbackdeneme image updated

$ kubectl rollout undo deployment/rollbackdeneme
deployment.extensions/rollbackdeneme rolled back

$ kubectl get pods
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

DeamonSet Kullanımı

Ç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.

Labels Kullanımı

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.

$ kubectl get pods --show-labels

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 Servis kullanımını göreceğiz. Laboratuvara buradan ulaşabilirsiniz. Görüşmek üzere !

Umarım bu yazı sizin için bilgilendirici olmuştur. Yazıyla ilgili bir sorunuz, görüşünüz veya isteğiniz varsa alt kısımda bulunan yorumlardan veya mail adresimden iletişime geçebilirsiniz. Bu yazının başkaları içinde bilgilendirici olduğunu düşünüyorsanız sosyal olun ve sosyal medyada paylaşın! Okuduğunuz için teşekkürler !!!!

2 thoughts on “Kubernetes Durum Yönetimi 11/20

  1. kenan says:

    Merhabalar 1 master 2 worker olan kubernetes cluster üzerine test amaçlı 3 tane container kurmak istedim ama üçüncü container pending’de bekliyor hep. Hatta çalışan container lardan birisini durdurursam pending’de bekleyen çalışıyor ama bu sefer de duran kalkmıyor.
    aşağıdaki gibi hata görüyorum, sizce nedeni ne olabilir nasıl çözebilirim?
    Warning FailedScheduling default-scheduler 0/3 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn’t tolerate, 2 node(s) didn’t have free ports for the requested pod ports

    1. mustafa Kasikci says:

      Merhaba. Kaynak yetersizliğinden dolayı ready durumda bekler. Request olarak kaynak ne olarak belirlenmiş. Buna göre podu açmaya çalıştığı İcin yer yok diye açmıyordur.

Leave a Reply

Your email address will not be published. Required fields are marked *