‫Peki, Kubernetes için sırada ne var?
‫Bu, ne kadar hızlı büyüdüğüne ve etrafındaki
‫tüm ekosisteme baktığımızda çoğumuzun aklına gelen bir soru ve bunun
‫tek bir kişinin üstesinden gelemeyeceği kadar fazla
‫olduğunu düşünüyorum.
‫Gelecekte ne olacak?
‫İyi haber şu ki, eğer tahmin etmem gerekirse,
‫geleceğin sıkıcı olmaya başlaması gerektiğini
‫düşünüyorum. Kurucuların çoğunu toplum içinde gördüğünüzde
‫bu konu hakkında konuştuklarını duyacaksınız.
‫Bilirsiniz, altyapıyı mümkün olduğunca sıkıcı hale getirmemiz
‫gerektiğinden ve böylece bunun üzerine yaptığımız şeylere
‫daha fazla güvenebileceğimizden bahsederler.
‫Çünkü
‫gerçekten de tüm bunlar, uygulamalarımızı piyasaya sürebilmemiz için burada, değil mi?
‫Kubernetes'in amacı Kubernetes'in kendisi olmak değildir.
‫Yapmak istediğiniz şeyleri daha hızlı yapmanızı sağlamak için.
‫Bence Kubernetes için, son birkaç
‫sürüme bakarsanız, gerçekten güvenilirlik,
‫kararlılık, güvenlik üzerine odaklanmaya
‫başladı, temelde o kadar kararlı hale geliyor
‫ki sadece orada.
‫Bu konuda çok fazla endişelenmenize gerek yok.
‫Çok fazla tamir etmene gerek yok.
‫Düzenli sürümleri var, bu yüzden kesinlikle
‫sürüm programını ve bu videoda bağlantısını verdiğim
‫sürüm notlarını kontrol etmelisiniz.
‫Bu yıl, 2019'da gerçekleşen bir şey, birçok şeyi ortaya
‫çıkaran birçok çekirdek kodun büyük bir
‫güvenlik denetimiydi.
‫Aslında, bloglarında, neler olduğuna dair tam ve ayrıntılı
‫bir analizleri var.
‫Bu kadar önemli ve büyük bir açık kaynak projesinin,
‫üçüncü bir tarafın güvenlik analizini yapmakla kalmayıp,
‫tüm potansiyel sorunları ve sonuçları ortaya çıkarması gerçekten
‫harika.
‫Bence bu durum, hızlıca düzeltilmesi gereken pek çok PR'ın
‫yanı sıra zaman içinde düzeltilecek bazı şeylerin de ortaya
‫çıkmasına neden oldu.
‫İlla ki güvenlik açığına dayalı olması gerekmiyordu, ancak
‫bu alanın daha fazlası geliştirilebilirdi, bu yüzden zaman
‫içinde değiştireceğiz.
‫Göreceğiniz bir başka şey de, daha basit bir araç olduğu zamanlara
‫ait bu eski kavramlardan bazılarının, kaldırıldıkça kaybolmaya
‫başlayacağıdır. CSI olmayan depolama eklentilerinin
‫eninde sonunda kaldırılacağını düşünüyorum, böylece depolama
‫eklentileriniz için yerleşik şeyler yerine CSI'a güvenmek zorunda kalacaksınız.
‫Kubectl run gibi farklı komutların değiştiğini ve bize uyarı
‫vermeyi bıraktığını göreceksiniz çünkü kutudan çıkar çıkmaz
‫tüm oluşturuculara sahip olmak yerine varsayılan olarak basit bir
‫pod çalıştırıcı olacak.
‫Daha sonra burada bahsettiğim servis tarafı kuru çalışması
‫gibi diğer şeylerin kararlı hale geldiğini ve etrafında daha fazla özellik
‫olduğunu göreceksiniz. Çünkü daha iyi denetim ve zaman içindeki
‫değişimin daha iyi anlaşılması için güçlü bir baskı
‫olduğunu düşünüyorum. Bunu yapmadan önce ne değişecek,
‫yaptıktan sonra ne değişti ve bu tür raporlama
‫ölçütleri.
‫Üçüncü taraf söz konusu olduğunda, bu balonlaşmaya ve büyümeye
‫devam edecek ve gerçekten de herhangi birimizin bilebileceğinden
‫çok daha fazla.
‫Dümen 3. 0 bitmek üzere.
‫Bunları Kubernetes'te konuşlandırmayı ve yönetmeyi kolaylaştıracak
‫üçüncü taraf araçlar için kesinlikle daha fazla operatörümüz
‫olacak.
‫Bu daha çok bir umut, ancak bildirimsel iş
‫akışlarına çok daha fazla odaklanacağımızı
‫düşünüyorum.
‫Çünkü DevOps ile ilgili bu yeni tema ve daha spesifik olarak
‫git-ops, yani podcast'imde
‫bahsettiğim git ops.
‫Git-ops iş akışı nispeten yeni bir kavram, ancak biz operatörlerin,
‫yani bu Kubernetes kümelerini yöneten
‫insanların, gerçekten operatör olarak
‫hareket ettiğimiz fikri.
‫Operatörler, GitHub gibi araçların ortaya çıkmasına
‫neden olan, kodu ve zaman içinde kod değişimini
‫ve sürümleri yönetmek zorunda kaldıkları yazılım ekiplerindeki
‫gelişmeleri, altyapımızı bildirimsel bir şekilde yönetmek
‫için aynı araçları kullanmak üzere alıyor.
‫Beni bu konuda konuşurken duymuşsunuzdur.
‫Kubernetes'in zaman içindeki özellik setine baktığınızda,
‫stil olarak nasıl daha bildirimsel hale geldiğini
‫ve özellik setinin ve odak noktasının bu bildirimsel iş akışı olduğunu görebilirsiniz.
‫Daha iyi araçlara sahip olacağımızı ve elimizdekilerin zaman
‫içinde daha fazla özellik kazanacağını umuyorum.
‫Buradaki bir diğer önemli şey de Windows Server desteği.
‫2019 yılında Windows Server desteği
‫ile ilgili büyük bir duyuru yapıldı ve
‫bu henüz emekleme aşamasında.
‫Bu, Swarm'ın teknik olarak Kubernetes'ten daha ileride
‫olduğu bir şeydir.
‫Docker ve Swarm'ın Windows Server desteği yıllardır
‫var ve zaman içinde kesinlikle gelişti.
‫Ancak, bunu Server 2016 ile başlattılar ve ilerletip daha
‫iyi hale getiriyorlar.
‫Oysa Kubernetes şu anda Windows Server 2019'da
‫gerçekten desteğe sahip olduklarını söylüyor.
‫Üretimde Server hakkında konuşurken duyduğum
‫kadarıyla, Windows Server'ın Kubernetes dünyasında Linux'a
‫eşit olabilmesi için hala çok daha fazla çalışmaya ihtiyacı
‫var. Bu nedenle, daha fazla Windows
‫işletmesi bu konteyner orkestratörlerini benimsedikçe bunun büyük
‫bir odak alanı olacağını düşünüyorum.
‫Buradaki son birkaç şey kesinlikle Edge vakaları üzerinde
‫çalışılacak.
‫Makine öğrenimi gibi şeyler.
‫Edge ve küçük altyapı gibi şeylerin hepsine odaklanılacak
‫çünkü Kubernetes'in başlangıcında çok büyük ve çok hantaldı,
‫ancak bunların çoğunu
‫çekip çıkarıyorlar ve dağıtımı
‫kolaylaştırıyorlar.
‫Bu yüzden kubeadm gibi araçların ortaya çıktığını ve HA kümelerini dağıtabildiğini
‫görüyorsunuz.
‫Tamamen güvenlidir ve hataya karşı toleranslı ise
‫kullanıma hazırdır. Bunların hepsi şu anda meyvelerini
‫vermeye başlayan şeyler.
‫Bu geleceğin bir parçası da diğer ilgili projeler hakkında bilgi sahibi olmaktır.
‫Bu
‫sadece bu kursta bahsetmediğim ve göz atmak isteyebileceğiniz
‫şeylerin hızlı bir listesi. Çünkü Kubernetes'in kendisi,
‫diğer tüm şeylerin üzerine inşa edilmeye başlandığı
‫bir platform haline geldi. Aslında projenin yazarlarının
‫asıl hedefleri de buydu.
‫Kubernetes'i doğrudan ham, açık kaynak
‫Kubernetes anlamında kullanmamızı asla istemediler.
‫Aslında diğer insanların iş yüklerimizi çalıştırabilmemiz için bunun üzerine
‫soyutlamalar inşa etmelerini amaçlıyorlardı.
‫Bu yüzden birçok durumda dağıtımların ortaya çıktığını görüyorsunuz,
‫çünkü bunu yapmak için üstüne başka bir katman inşa ediyorlar.
‫Bu
‫durumda, başka şeyler yapmak için her türlü başka altyapının ortaya çıktığını
‫görüyoruz. İlk sırada Knative var.
‫Bu, sunucu listelerinin etrafında ve kesinlikle
‫resmi bir CNCF projesi, bu yüzden Kubernetes dünyasıyla sıkı sıkıya
‫ilişkili.
‫Sunucu listeleriyle ilgileniyorsanız, kesinlikle göz atmak
‫isteyeceğiniz projelerden biri.
‫Sırada Rancher'dan birkaç proje var:
‫K3s ve K3os.
‫K3s aslında Kubernetes'in
‫karmaşık dağıtımını ve yönetimini ele alan ve onunla birlikte
‫gelen tüm gereksiz şeyleri çıkararak basitleştiren
‫bir ekip.
‫Belki bazı eski komutlar ve kodlar.
‫CSI'ınız varsa belki artık ihtiyacınız olmayan bazı depolama
‫sürücüleri.
‫Bu tür şeyler. Her şeyi ortaya çıkarıyorlar ve size gerçekten
‫kolay bir veri tabanı veriyorlar.
‫Kutudan çıktığı haliyle etcd bile kullanmıyor.
‫Daha basit bir veritabanı kullanır.
‫Aslen IoT gibi şeyler içindir.
‫Ancak şimdi, Kubernetes'i Swarm kadar basit hale getirme
‫hedefleriyle, CTO'ları ve kurucu ortakları
‫Darren Shepherd tarafından bu yıl DockerCon'da
‫söylendi. Oldukça ilginç bir açıklamaydı.
‫Swarm'ın dağıtım, kullanım kolaylığı ve minimum etki konularında
‫çok başarılı olduğunu söylüyordu.
‫Bu çok küçük bir ikili.
‫Altyapı açısından çok
‫az ek yükü vardır. Kubernetes bunun
‫tam tersidir. Orta yolu bulmaya çalışıyorlar.
‫Yeterince şeyi çıkarırsak ve yine de onu gerçek Kubernetes
‫yaparsak, ARM, Raspberry Pis gibi küçük sistemlere dağıtmayı
‫çok kolay hale getirebilir miyiz?
‫Yani, bu izlenmesi gereken bir proje.
‫K3os, üzerinde K3s bulunan bir
‫işletim sistemidir.
‫Küçük cihazlarda K3'leri çalıştırmak
‫için tasarlanmış çok minimal bir Linux
‫kurulumu. Bu oldukça yeni bir proje ama
‫yine de ilginç bir proje. Podcast'imde daha çok bahsedeceğimi
‫duyacağınız bir diğer büyük odak alanı ise son
‫birkaç yıldır yeni bir kavram ve gerçekten yeni bir terim
‫olan hizmet ağı.
‫Bu kelimeyi sektörde daha önce pek kullanmamıştık.
‫Hizmet ağı, yalnızca
‫İnternet'ten gelen bağlantılar için değil,
‫uygulamanızın tüm parçaları için tüm küme boyunca
‫bu proxy katmanı fikridir.
‫Güvenlik açısından, izleme açısından ve uygun konumlara
‫yönlendirme açısından, dağıtılmış uygulamanızın
‫tüm parçaları için tüm trafiği kontrol
‫etmek için bir aracı haline gelir.
‫Bu, mikro hizmetler sorunundan ortaya çıkan
‫bir dizi projedir. Daha önce herhangi
‫bir mikro hizmet yaptıysanız, gerçek zorluklardan biri, tek bir sunucuda
‫tek bir ikili dosyada bulunan ve sorun gidermesi nispeten kolay
‫olan şeyin, düzinelerce sunucu üzerinde düzinelerce
‫konteynere dönüşmesidir.
‫Harika ağ araçlarına sahip olmadığınız sürece bu sorunu
‫gidermek çok zor hale gelir.
‫Dolayısıyla, hizmet ağı bu soruna işaret
‫ediyor ve dağıtılmış uygulamalarımız ve mikro
‫hizmetlerimiz etrafında daha fazla
‫görünürlük, izleme, sorun giderme ve güvenlik için bir katman
‫oluşturarak arkasında standartlar olan bir standart haline gelmeye
‫çalışıyor.