• google container engine'de (gke) çalıştırdığınız uygulamaların loglarını elastic stack'e filebeat ile gönderebilir, bu logların docker engine tarafından rotate edilme parametrelerini değiştirebilirsiniz:

    https://murat.io/…s-in-google-container-engine.html
  • herkesten farkli yap kafasini sevdigimin google'i. bir container orchestration daha nasil cetrefilli hale getirilebilirdi? yildim yaml yazmaktan, biktim json yazmaktan.

    docker swarm'dan cok umitliyim. haydi cocuklar! bir auto scale bu isi cozer!
  • 2-3 basit uygulama yazip deploy edecek olanlar gidip swarm kullanmali zaten.

    kubernetes bu use case icin dogru arac degil. eger onlarca, yuzlerde uygulamanin binlerce instance'ini sahip oldugunuz binlerce makina uzerinde calistirmak, declarative olarak bunlarin configuration'larini, disklerini, loadbalancer'larini manage etmek istiyorsaniz (ki google'in altyapisi boyle calisir), kubernetes dogru aractir.

    zaten ftp uzerinden kod deploy etmek, 2-3 serverda calismak sizi anlatan bir senaryoysa docker'a bile gecmeyin gidin ftp'den kod upload etmeye devam edin, kotu bir sey degil bu.

    -- not etmekte fayda var: kubernetes ve swarm seneler once cok yakin zamanlarda duyuruldu. o gunden bu yana docker,inc "libswarm", "docker swarm", "swarm mode" adiyla ayni isi yapan seyi cope atip bastan "kendi basina" gelistirdi. yine o gunden bu yana, kubernetes, genis bir topluluk tarafindan birlikte gelistirilmis ve hicbir kesintiye ugramamistir. stability uzerine dusunulmesi gereken bir konu.
  • hadoop ve spark için mesos kullanmış biri olarak microservice meselesi için bu karşılaştırma benim için mesos vs kubernetes oluyor. tabi mesos bir distributed kernel olduğu için aynı marathon, chronos senaryosundaki gibi kubernetes de bir framework olarak mesos üzerinde çalışabiliyormuş. konteynır orkestrasyonu meselesinde son zamanlarda kubernetes topluluğunun hayvani popüler olduğunu söylemek gerek, her podcastte karşımıza çıkıyor.
  • docker'ın artık resmi olarak destekleyeceği platform.

    https://www.docker.com/kubernetes
    https://blog.docker.com/…platform-and-moby-project/
  • okuduğum kadarıyla süper ötesi bir olay. gene de bir bok anlamadım ama adı güzel.
  • google'ın "google kontainer engine" diye başlayıp "google kubernetes engine" olarak devam eden ürünüdür.

    amaç fi tarihinden beri olan freebsd içindeki libcontainer ile başlayan process jailing/isolation mantığının yönetilebilir hale getirilmesini sağlamaktır.

    docker-swarm vs kubernetes dendiğinde ise cloud vendorları ne kadar kubernetes apilerini güzel consume edip kendilerine geldiklerinde bir yaml dosyasını güncelliyorsun her şey güzel oluyor ile tercihlerin belirlenmesine uğraşmaktadır.

    aws bir vm ve serverless platformu: (bkz: lambda) (bkz: ec2)
    gcp bir network, kubernetes ve app platformu: (bkz: gke) (bkz: appengine)

    azure hakkında bilgisi olanlar yeşillendirsin zira microsoft kubernetes'e çok katkıda bulunan bir şirket.
  • https://blogs.vmware.com/…ntroduction-vmware-users/
  • kubernetes nedir?

    kubernetesi anlayabilmek icin once microservices, docker gibi kavramlari anlamamiz lazim. peki oyleyse baslayalim...

    1 - bir web uygulamasi yaptiniz, bu uygulamanizin bir e-ticaret sitesi oldugunu varsayalim. bu e-ticaret sitenizi yaparken sepet, odeme, musteri, urun, yorumlar vb. parcalara boldunuz ve bu parcalarin her biri kendi icinde, digerlerinden bagimsiz olarak calisacak sekilde tasarladiniz. tek basina calisabilen, butunun bir parcasi, her bir parcamiz, bir servistir ve kurdugumuz kucuk kucuk ve birbiri ile haberlesen, bir suru servisten olusan bu yapiya microservices denir.

    2 - web uygulamanizin, her bir servisini servera yuklemeniz ve calistirmaniz gerekiyor ki musteriler gelsin alisveris yapsin. burada bu servisleri yine birbirinden bagimsiz makinelere kuruyoruz ve birbirleri arasinda haberlestiriyoruz, fakat burada karsimiza bir zorluk cikiyor. her bir servisi calistirmak icin bizim, servisi yukledigimiz makinelerin icine, o serviste kullanilan seyleri kurmamiz gerekiyor, mesela kullanacagimiz framework, database gibi. bu noktada imdadimiza docker yetisiyor. servisini bir sanal makinenin icinde calistirdiniz ve bunu paketleyip image haline getirdiniz, bu docker imagelarini calistirdiginiz anda olusan seyin adi container. yani siz uygulamanizin her bir servisini bir container olarak sunucuda calistirabilirsiniz, bu sayede her seferinde her actiginiz makineye birseyler kurma zahmetinden kurtulursunuz ve izole calisan bir yapiya sahip olursunuz.

    3 - docker containerlarinizi birbirinden farkli makinelere kurdunuz, simdi bunlari merkezi bir yerden yonetmeniz gerekiyor, burada imdadimiza kubernetes yetisiyor. diyelim ki bizim tum servislerimiz toplam 5 adet makineye yuklu, bu 5 makinelik, microservicelerden olusan yapiya cluster deniyor, bir clusterdaki her bir makineye ise node deniyor. kubernates kurdugumuz yonetici node, master node oluyor ve diger kubernetes yuklu nodelari, master node yonetiyor.

    4 - kubectl adli bir command line interface ile nodelar yonetilebiliyor, nodelara yuklenen kubelet adli bir program ile haberlesiyorlar. yani her yeni makine actigimizda icinde kubelet ve docker yuklememiz gerekiyor, bunu da otomatize hale getiren sistemler var, bunlardan biri terraform. terraform kurup yazdiginiz .tf dosyasiyla provider, service gibi bilgilerinizi yaziyorsunuz, ssh-key ve api tokeninizi yaziyorsunuz, makine acildiginda yuklenmesini istediginiz docker gibi, kubelet gibi toollari yuklemek icin komutlarinizi yaziyorsunuz. terminalden terraform init dediginiz vakit .tf uzantili dosyanizi okuyor, terraform plan size set ettiginiz degerleri gosteriyor, terraform apply yazdiginizda ise calismaya basliyor, makinenizi aciyor, .tf dosyasina yazdiginiz islemleri satir satir yapmaya basliyor ve otomatik sekilde node olusturuyor... terraform destroy derseniz o node kendini imha edecektir...

    5 - kuberneteste replicaset denen bir replication controller bulunmaktadir, replicasetin olayi, yaml dosyalariyla dersiniz ki, bu nodedan 3 tane dursun her zaman, loadbalancer ile yuku bu 3 makineye dagitabilirsiniz. olaki makinelerden biri bozulur, kapanir, herhangi bir sorun olursa, hemen yeni bir makine acilir ve o node ile yola devam eder, bu sayede daima 3 node aciktir, bunu istediginiz zaman manuel olarak 3, 4, 5, 10 makine yapabilirsiniz.

    6 - replicaset ile esas olarak yapilabilecek daha guzel birsey vardir ki, sistem yuku arttikca yeni makineler acilir, yuk azaldikca makineler kapanir, bu sayede sisteminiz surekli ayakta kalir ve bunun optimize etmis oldugunuz icin gereksiz yere serverlara para odememis olursunuz... buna da terminolojide autoscaling deniyor...

    7 - yine replicaset ile canary testing yapabilir, sureci otomatize edebilirsiniz. bu da su demek oluyor, e-ticaret version 2 yi yazdiniz, nodelarinizdan birine bunu yukluyorsunuz, kullanicilarin kucuk bir kismi v2 kulllaniyor, eger sistem sikintisiz calisiyorsa yavas yavas v1 olan nodelari azaltip v2 leri arttiriyor ve birden degil, zamanla v2 ye geciyorsunuz, bu da size yayinda, az kullanici ile test imkani sagliyor, sisteminizde her zaman yayinda kaliyor...

    ben ogrendikce buraya yeni bilgiler eklemeye calisacagim, bir hatam varsa bilenler duzeltsin cunku aslina bakarsaniz bende pek kullandigimi soyleyemem ve yeni yeni ogreniyorum...
  • medium makalesinde arkadaş çok güzel anlatmış
hesabın var mı? giriş yap