Ne zaman Kubernetes kullanmalı?
HTML-код
- Опубликовано: 31 мар 2024
- 🌟 Videoyu beğendiyseniz lütfen "Beğen" tuşuna basın ve daha fazla içerik için kanala abone olun. Sorularınız, yorumlarınız veya deneyimleriniz varsa, lütfen aşağıya yorum yapmaktan çekinmeyin.
Superpeer Community: superpeer.com/daronyondem/com...
Superpeer uzerinden verdigim kocluklar için indirim kuponlari asagida:
- Ogrenci koclugu : YTBDRN
- Yasam Koclugu : YTBDRN
E-Mail Aboneligi: bulten.daron.me
Kocluk: book.daron.me
Twitter: twitter.daron.me
LinkedIn: linkedin.daron.me 
Развлечения
Bu soruyu ben sormustum hocam teşekkür ederim cevap icin :)
Bir baska sorum da monolith/m.service konusuyla alakaliydi. Aslinda simdi soracagim soruyu ne zaman k8s kullanilmali sorusunu sorarken sormam daha dogru olabilirdi ama olsun yine sorayim :)
Aslinda hem videodaki konu hemde k8s, containerlaşmış uygulamalar gibi konularin özü biraz da mikroservice konusuna baglaniyor gibi.
Yani kocaman bir monolith uygulamanin 7 8 gb tek bir image ile k8s veya bir paas ta calismasi nedense absürt geliyor. Evet bu monolith uygulama yuksek trafik altında olabilir ve scale ihtiyacı olabilir olceklenme ihtiyacı olabilir bu nedenlerle k8s e veya bir paas uzerine deploy edebiliriz sonucta k8s buna engel degil ancak eger bu monolith uygulama icin "....*bility" kavramları gerçekten önemliyse neden microservice mimariye gecmemis ve hala monolith duruyor? Uygulamanin butun bilesenlerinin mi ölceklenme ihtiyacı var(yani sepete ekle servisi ölceklenirken profil resmi degistirme servisini neden ölcekleyelim?)
Ornegin bir paas platformunda(mesela openshift) moduler monolith veya monolith bir uygulamanin çalışması k8s best practiceslerine aykiri midir yani aslinda sunu soruyorum bir container orc yazilimi olan k8s de sadece microservice uygulamalar mi olmalidir. Tabi ki monolith uygulamalar da olabilir ancak bu durum isin raconuna aykiri midir :)
Kubernetes içinde ne çalıştığına bakmaz, her şey yapılabilir. Bilmiyorum ama insanlar detayı kaçırıyor gibi geliyor bana. Sepeti eklerken profil resminide ölçekle sana bunları ayırmak aman aman performans katmayacak. Asıl konu zincirin zayıf halkasını nasıl ölçekleyeceksin? Auth servisinin databasei nasıl ölçekleyeceksin? Auth gitti mi ne mikroservis kalır ne başka bir şey. Hepsi auth üzerinden internal servislerle haberleşmek için token alacak. Bir mikroservisi ölçeklemek değilde onun dbsini ölçeklemek mesele. Sepet servisin kendi ayrı dbsi var ama 5 yerine 10 tane app server koy ne fark eder? Hepsi aynı Sepet dbsine gidecek, mesele onu ölçeklenebilir yapmak. Sepet db cluster oluşturup replikasyonu ve partitionu düzgün ayarlamak. Pacelc seçimine göre kullanacağın db her şey değişiyor. Kuberneteste db ölçekleyemedikten sonra app server 10 yerine 20 replika çalışsa boş. Zayıf halka db işin %80i dbde dönüyor
Daron hocam, Yukarıdan aşağıya dediğiniz sıralamayı yazar mısınız? Web app le başlayıp vm le biten. Arada docker, kubernates dışında birşey var mı?
Managed ortamlardan yavas yavas daha az managed ortamlara dogru bir siralama soz konusu. Azure'da bu App Service, Container Apps, Azure Kubernetes Service Azure Container Instance, Azure Virtual Machine ve BareMetal Infrastructure olarak siralanbilir. Farkli ureticilerin farkli isimlendirmeler ve urunleri olabiliyor.
baglantili soru. ACI varken developement teamlerine AKS neden verilir?
Emin olmak için soruyorum. ACI = Azure Container Instance?
"google bi şekilde herkesin kubernetes a ihtiyacı olduğuna inandırdı" diyebilir miyiz ? ben çoğu zaman (tr de yapılan işler için) dockerın yeterli olduğunu düşünüyorum ama yanlış mı düşünüyorum ?
Biri containerization, digeri ise orchestration araci. Docker Swarm daha dogru bir karsilastirma olacaktir. Genel olarak buyuk workloadlar icin Kubernetes, kucukler icin Docker Swarm diyebilecek olsam da :) ikisini daha detayli karsilastirmak gerekir.
Docker'ı tek başına orchestration aracı olmadan kullandığınızda uygulama yönetimi bir süre sonra manuel süreçlere dönüşüyor. Swarm ise görece küçük sistemlerde makul görünmekle birlikte community ve firmaların plugin desteklerinin kubernetese kayması nedeniyle belli noktalarda zorluk çıkarıyor. Kubernetes daha işlevsel, detaylı ve disiplinli bir yaklaşımı yerleştirdiği için tercih edileceğini düşünüyorum.
veri tabanlarını container ortamda tutmak sağlıklı mı? vm de tutmak daha mı iyi olur?
paas olarak almak akillicasi
@@okanakyuz neden?
Hangi ortama hakim oldugunuzla da alakali bir soru. Her ikisinde de calisir ozunde, fakat farkli bir bilgi, birikim ve deneyim gerektiriyor. Ozellikle microservice yapisi varsa DB'leri containerized Kubernetes icerisinde tutmak anlamli bir mimari secenek olacaktir. Genelde karsilasilan sorunlar DB'nin persistent storage ihtiyaci ve containerlarin yasam dongusunun VM'e kiyasla daha hareketli olmasinin sonucunda cikiyor. Her iki secenekte de "Neden VM? Neden Container?" sorularini sorup duruma gore karar vermek gerek.
daha az dertli :)
kubernetes cluster ortamında veri tabanı önermiyorum ama docker host ortamında gayet sağlıklı çalışıyor veri tabanları