Kubernetes öğrenme notlarım — 1
Merhabalar,
Bu yazı serisi boyunca Özgür Öztürk’ün Kubernetes Temelleri adlı kursunda öğrendiklerimi not alacağım. Burayı bir not defteri olarak kullanıp, isteyenlerin de buradaki notlardan faydalanması için paylaşıyor olacağım. “Bilgi paylaştıkça çoğalır.” Hadi başlayalım :)
Bilişim sektörü artık büyük bir değişim yaşıyor ve hızla büyüyor. Veri merkezlerinde tutulan monolit mimariden, Cloud üstünde koşan dağıtık mimaride uygulamalara geçiliyor. Uygulamaları “microservices” şeklinde dizayn ediyor ve bunları container’lar olarak paketleyip çalıştırıyoruz. Container’ları da production ortamlarda sektör standartı haline gelmiş “Kubernetes” üzerinde koşturuyoruz. Kubernetes bir container orchestration platformu. Container’a dönüştürülmüş, dağıtık mimarideki uygulamaları kesintisiz şekilde çalıştırmanıza imkan veren bir platform. Yeni dünyada gelecek, bu platform üzerinde yükseliyor.
Bu yazı serisi boyunca ihtiyacımız olan bazı gereksinimleri hallettikten sonra teorik olarak k8s’i anlamaya çalışacağız :
Visual Studio code kurulumu yaptıktan sonra github reposundaki kodları local’imize indiriyoruz. Local’inize indirdikten sonra dosyalar aşağıdaki fotoğraftaki “1” gibi gözükecektir :
Vscode’da “2” numaralı kısımdan bazı extension’lar(eklentiler) ekleyeceğiz. Vscode eklentileri, geliştirme iş akışınızı desteklemek için kurulumunuza hata ayıklayıcılar, diller ve araçlar eklemenize olanak tanır. Biz burada Kubernetes için araçlar ekleyeceğiz. “kubernetes” araması yaptıktan sonra “3”te gördüğünüz Kubernetes eklentisini “4”teki butona basarak yüklüyoruz. Aynı şekilde bu işlemi “5” teki YAML için de yapıyoruz. Ve kurulumları böylelikle tamamlamış oluyoruz.
Burada tabii ki farklı IDE’ler vb. farklı kurulumlar üzerinden de ilerleyebilirsiniz. En yaygını Vs Code olduğu için onun üzerinden bir anlatım gerçekleştirdik. Ben de daha çok intellij IDEA kullanıyorum. Ortak bir amaca gittikten sonra hangi IDE üzerinden çalıştığımızın pek bir önemi yok :)
Şimdi teknik kısımlara geçmeden önce k8s’i teorik olarak öğrenmeye çalışalım :
Container Orchestration
Bir senaryo üzerinden Container Orchestration’u anlamaya çalışalım.
Diyelim ki ekipçe bir E-ticaret uygulaması geliştireceğiz. Ve bu uygulamayı 4 ayrı modül olarak tasarlayacağız. Müşterilerin eriştiği Front-end katmanı, uygulamayla ilgili ana işlemlerin yapıldığı bir Back-end katmanı, önbellekleme işlemleri için bir Cache katmanı ve son olarak da verilerimizi tutacağımız bir veritabanı. Production ortamında container’ların gücünden yararlanmak için, tüm bu uygulamaları birer container image’ı haline getiriyoruz. Yani 4 ayrı modülü 4 ayrı container olarak çalıştıracağız. Bu işlemlerden sonra hemen cloud service sağlayacılarından birine gittik ve Ubuntu işletim sistemi yüklü bir sanal makine oluşturduk. Bunun üzerine docker kurduk, uygulamayı ayağa kaldırmak için yapılması gerekenleri yaptık. Docker network oluşturarak uygulamaları birbiri ile konuşturduk, çeşitli docker komutları ile uygulamaları çalıştırdık, volume vb. oluşturduk. Son olarak bir sürü komut sonrası uygulama çalışmaya başladı, ortamımız ayağa kalktı. E-ticaret sitesi alt yapımız çalışıyor. → [1nci kısım]
Müşterilerimiz bağlanmaya başladı ve bir süre bu ortamda bir değişiklik yapmadan idare edebildik. Fakat biraz zaman geçtikten sonra bu ortamda sıkıntılarla karşılaşmaya başladık. Uygulamamız tek bir sunucu üzerinde koştuğu için, sistemde en ufak bir değişiklik yapsak bir kesintiye neden olacağız ve kullanıcılara hizmet veremeyeceğiz. Bu sorunu çözmek adına ikinci bir sanal makine daha kuruyoruz ve uygulamayı oluşturan tüm katmanların birer kopyasını ikinci sistem üzerinde de oluşturuyoruz. Bu sanal makinelerin önüne bir load-balancer koyuyoruz ve çeşitli ayarlamalar yaparak, bu sistemlerden bir tanesi devre dışı kalsa bile uygulamada kesinti olmadan diğer sistem üzerinden müşterilere hizmet vermeye devam edebilmesini sağıyoruz. Sistemi manuel kontrol etmek bizi epey zorlamaya başladı ve kampanya(black friday vb.) günlerinde yoğun trafik almaya başladık fakat sistemler bu trafiğe cevap verecek kapasitede değil. Bu nedenle kesintiler yaşamaya başlıyoruz. Bu sorunu çözmek için yeni sanal makineler kurmaya başlıyoruz, sistemleri bunların üzerine de dağıtmaya başlıyoruz. Zaman ve emek harcayarak bunları tek tek oluşturmaya başladık. Bir zaman geldi trafiği karşılayabilmek için yüzlerce sanal makinemiz oldu, fakat bunları yönetmekte zorlanmaya başladık. Parametrelerini manuel yönetiyor, “hangi uygulama kaç container olarak hangi makinede çalışıyor? Ip adresleri nelerdir ?” vb. sorular kafamızı meşgul etmeye başlıyordu. Bir yandan da uygulamayı ilk başta 4 modül olarak tasarlamıştık fakat geliştirmeye devam edildi, mikroservis mimariye geçildi. Tüm bu büyüyen sistemi ayakta tutmak/yönetmek için sabahtan akşama kadar uğraşıp her şeyi manuel yapıyoruz. İş kontrol çıkmış durumda ve e-ticaret sitemiz de büyümeye devam ediyor, sistemimiz büyüyor ve kontrolü zorlaşıyor. Tüm sistemi yönetecek ve bizim adımıza bu manuel işleri yapacak bir sisteme ihtiyacımız var. → [2nci kısım]
Bu docker yüklü sistemleri adeta bir orkestra şefi gibi yönetecek bir sistem tasarlıyoruz. Tüm bu işlemleri manuel olarak tek tek sistemler üzerinde yapmak yerine, bu orkestra şefine bir liste verip “benim uygulamam listedeki komponentlerden oluşuyor, bu komponentlerin özellikleri şu şekilde ve sayısı bu kadar. Bu servisler birbirleriyle konuşacak ve şunlar da dış dünyadan gelen istekleri karşılayacak şekilde bir sistem istiyorum” diyoruz. Orkestra şefi bizim adımıza tüm bunları halledip ayağa kaldırıyor, hangi container hangi sistemde koşacak? Yük dağılımları nasıl olacak? Hangi sistemde yeni container oluşturmak için kapasitemiz var? Gibi şeylere karar verip bunun yanında ip bilgileri gibi kayıtları kendi üzerinde barındırsa ve daha da ileri gidip sistemi sürekli gözleyerek yanlış giden durumlarda devreye girip otomatik olarak sistemi istediğimiz konfigürasyonda tutsa. Kısacası tüm orkestrayı ve müzik aletlerini tek tek ayarlamak yerine orkestra şefine, çalınmasını istediğimiz şarkının notalarını verip şarkının sorunsuz şekilde çalınmasını şeften istememize benziyor. İşte bunu yapan sistemlere, “Container Orchestration” sistemleri deniyor. → [3ncü kısım]
Container Orchestration’u sağlayan araçlardan en bilenenleri de: Docker tarafından oluşturulmuş ve docker’ın bir parçası olan “Docker swarm”, diğeri de open-source bir proje olarak yürütülen ve artık neredeyse sektörün tamamı tarafından standart container orchestration aracı olarak benimsenen “Kubernetes”.
Kubernetes Nedir?
Kubernetes, Google tarafında geliştirilen Borg ve Omega sistemlerini baz aldıktan sonra “Craig McLuckie, Brendan Bruns, Joe Beda” tarafından GitHub üzerinde open-source olarak yayınlandı. Logosu ve isimlendirilmesinde Docker’ın denizcilik teması takip edildi. Yunancada “gemi dümencisi” anlamına gelen kubernetes ismi verildi ve ismin uzun olmasından dolayı da “k8s” olarak kısaltıldı.
K8s’in resmi sitesinde k8s’i “Kubernetes hem beyan temelli yapılandırmayı(declarative configuration) hem de otomasyonu kolaylaştıran, container iş yüklerini ve hizmetleri yönetmek için oluşturulmuş, taşınabilir ve genişletilebilir açık kaynaklı bir platformdur” şeklinde tanımlıyor. (Beyan temelli yapılandırma ve otomasyon kavramlarını aşağıda açıklayacağız.)
Kubernetes, bilişim sektörünün büyük bir çoğunluğu tarafından container iş yüklerini yönetmek için tercih edilen, sektörün en önemli container orchestration platformu. CNCF(Cloud Native Computing Foundation) adında bir vakıf tarafından yönetilir ve açık kaynak olarak geliştirilir. Apache 2.0 ile lisanslanan kubernetes, isteyen herkes tarafından ücretsiz şekilde kullanılabilir. K8s’in bu kadar büyük bir kitleyi kendisine çekmesindeki asıl neden, dizaynı ve container orchestration sorununa yaklaşım şekli.
- Dizayn → K8s tamamen modüler yapıda tasarlanmış ve platform bu şekilde kurgulanmış. k8s bütün özelliklerinin içinde olduğu ve her işi yapan tek bir uygulamadan oluşmuyor. Bunun yerine mümkün olan her koşulda major özellikler ayrı ayrı komponentlere bölünmüş. Bu sayede her modül, sadece kendi işine odaklanıyor ve böylelikle geliştirme süreci kolaylaşıyor / hata oluşum oranı düşürülüyor / esneklik sağlanıyor.
- Container Orchestration sorununa yaklaşım şekli → K8s bize cluster üzerinde yapmak istediklerimizi tek tek “şunu yap sonra bunu yap, sonra dön şunu yap” gibi adım adım girerek yapmak yerine, “ben şöyle bir yapı oluşturmak istiyorum” deme imkanı veriyor. Yani nasıl yapılacağını tarif etmiyor, ne istediğimizi söylüyoruz. İşte bu beyan temelli yapılandırma(declarative configuration) oluyor. K8s bize declarative olarak ondan istediklerimizi belirtme imkanı sunuyor. Ve bunun yanında otomasyonu da sağlıyor → Yani biz declarative olarak istediğimizi söylüyoruz ardından k8s bize istediğimizi oluşturuyor ve bu yapıyı gözlemeye başlıyor. Yapı eğer bizim deklare ettiğimiz şeyin dışına çıkarsa k8s otomatik olarak bunu düzeltiyor ve bizim istediğimiz konfigürasyona geri dönüyor.
Kubernetes Komponentleri — 1
Uygulamanın tek bir mono-block şeklinde dizayn edilmesi yerine uygulamanın içindeki özelleşmiş işlerin ayrı ayrı servisler olarak sunulmasıdır. Tek bir uygulama yerine, tüm bu servislerin birleşiminden oluşan bir alt yapıya geçilir. Uygulamadan → platforma dönüşür. Kubernetes’in modüler yapısını da aynı buna benzetebilirsiniz. Tek bir kubernetes adında uygulama yoktur, kubernetes platformunu oluşturan bir çok servis mevcuttur ve bu servislerin bir arada düzgün kurgulanarak çalıştırılması sonucu kubernetes platformu oluşur.
Bu komponentleri ve aralarındaki ilişkileri inceleyeceğiz fakat öncesinde yine bir senaryo oluşturalım ve anlamamızı kolaylaştıralım :
Temelde iki bölümden(yönetim ve üretim) oluşan bir fabrika hayal edelim. Sol taraftaki yönetim biriminde yönetimle ilgili tüm birimler bulunuyor. Sağ tarafta ise esas işin yapıldığı, tüm üretim araçlarının/makinelerin/işçilerin bulunduğu kısım var. Ana iş üretim kısmında yapılıyor.Üretim kısmında ;
- Her makinenin başında bir ustabaşı duruyor ve başında durduğu makinenin kontrolünden sorumlu. O makinede ne üretilecekse, yönetim kısmından bu ustabaşına bildiriliyor ve ustabaşı o üretilecek şeyi üretecek işçiyi getirip, bu makinede çalıştırmaya başlıyor(İşçileri makineye yerleştirir ve durumlarını gözler).
- Ustabaşının yanında bir tane de lojistikten sorumlu görevli duruyor. Bu görevli de o makinelere dışarıdan erişilmesini, işçilerin birbirleriyle haberleşebilmelerini yani iç ve dış iletişimi sağlıyor.
Şimdi Yönetim kısmını inceleyelim.
- İlk olarak fabrika girişinde bir resepsiyon ve güvenlik kısmı (çizimdeki koltuk ve güvenlik kamerası). Fabrika içinden ve dışından gelen tüm iletişim bu resepsiyon kısmından geçmek zorunda, hiçbir birim birbiri ile direkt haberleşemez. Buranın ana görevi, gelen tüm istekleri almak, isteği yapan birimin istediği şeye yetkisi olup olmadığını kontrol etmek ve eğer yetkiliyse isteği kayıt altına almak.
- Resepsiyonun hemen arkasında kocaman bir pano duruyor(çizimde koltuğun üstündeki dosya). Resepsiyon ve güvenlik bölümü gelen tüm istekleri, bu istekler sonucu oluşan tüm kayıtları ve ne yapılması gerektiğiyle alakalı tüm bilgileri bu panoda saklıyor. Fabrika ile ilgili tüm bilgiler; ne üretildiği, mevcutta ne kadar üretim yapıldığı, kaç kişi çalışıyor, kaç makine var… gibi bilgiler bu panoda tutuluyor.
- Yönetim kısmında bir de üretim ve planlama bölümü bulunuyor(çizimde koltuğun altında olan kısım). Üretim/planlama bölümü, panoyu resepsiyondan izin alarak sürekli gözlüyor. Eğer bu kayıtlarda yeni bir ürün üretilmesine yönelik bir talimat görürse hemen bu talimatı alıyor, tüm makinelere bakıyor, bu ürünü üretebilecek özelliktekileri seçiyor. Bu seçimi yaparken ürünü üretebilecek özelliklere ve yeterli kapasiteye sahip mi diye bakıyor. Ardından o işe uygun işçinin, seçilen makineye yerleştirilmesini sağlıyor.
- Yönetim kısmındaki son bölümümüz vardiya amirliği(çizimde koltuğun sağ altında). Bu departmanda 3–4 farklı insan çalışıyor ve bunların her biri aynı işi yapıyor fakat hepsinin sorumlu olduğu ayrı bir yer var. Bir gözleri sürekli panoda, diğer gözleri ise sorumlu oldukları yapıları kontrol ediyor. Örneğin işçilerden sorumlu olan vardiya amiri, sürekli panoyu gözlüyor. Panoda 10 işçi çalışması bilgisi var, üretim kısmını gözlüyor ve 10 işçinin çalışıp çalışmadığını kontrol ediyor. Eğer işçilerden biri makine başından ayrılırsa hemen tespit edip, “panoda 10 çalışması lazımdı 9 işçi var, bunu düzeltmeliyim” diyip üretimi tekrar 10 işçiye çıkarıyor. Bir başka vardiya amiri makineyi gözlüyor vb. hepsi temelde panoda yazılanla, mevcut durumun aynı olup olmadığını kontrol ediyor ve gerekirse müdahale ediyor.
Şimdi Tüm süreci birleştirelim :
Genel merkezden fabrikaya yeni bir üründen 3 adet üretilmesi için talimat geldiğini düşünelim. Fabrikaya gelen tüm iletişim, resepsiyon ve güvenlik üzerinden olduğu için resepsiyon ve güvenlik bu talimatı alıyor. Öncelikle bu talimatı gönderen kişinin, gerçekten o kişi olup olmadığını kontrol ediyor. Sonrasında talimata bakıyor ve gönderen kişinin talimatta yapılanları isteme yetkisi var mı? Diye kontrol ediyor. Doğru kişi ve yetkili ise, talimatta yazılanları panoya kaydediyor.
Üretim planlama resepsiyondan izin alarak panoyu sürekli gözlüyordu. Üretim planlama panoya yeni talimat asıldığını görüyor ve 3 adet ürün üretilmesi gerektiğini tespit ediyorlar. Hemen arşivi kontrol edip, ürünlerin üretilebileceği makineleri listeliyorlar. Ardından bunların içinden uygun olanları seçip panoya yazıyorlar(3,9,17 numaralı makinelerde 3 işçi çalışmalı). Resepsiyon bu bilgiyi 3,9,17 numaralı makinelerin ustabaşlarına bildiriyor.
Her makinenin ustabaşı belirtilen özelliklerdeki ürünlerin üretilebilmesi için işçileri makine başına koyuyor ve çalıştırmaya başlıyor. Ardından işçilerin çalışmaya başladığını vb. bilgileri resepsiyona bildiriyor ve panoya bu bilgiler de ekleniyor. Bu arada lojistikten sorumlu görevliler bu işçilerin iletişimlerini ve koordinasyonlarını sağlamaya başlıyorlar. Ardından vardiya amirliği devreye giriyor, resepsiyondan aldıkları izinle panoyu gözlüyorlar. Her bir vardiya amirliği görevlisi sorumlu oldukları alanlarla ilgili mevcut durumu ve olması gereken durumu(current state vs. desired state) panodan takip ediyorlar. İki durum arasında fark olursa, bu farkı düzeltmek için gerekli işlemleri yapıyorlar.
Yani istediğimiz ürünü üreten bir fabrika platformu var, dışarıdan tekil bir yapı gibi gözükse de içeride bir çok alt komponentin bir arada uyum içinde çalıştığı bir platform.
Yukarıdaki tüm sistem, k8s komponent’lerini temsil ediyor. Yönetim kısmına Control plane/Master node, üretim kısmına ise Worker nodes diyoruz.
Makineler: worker nodes |ustabaşı : kubelet | lojistikten sorumlu görevli : k-proxy
Resepsiyon ve güvenlik: api server| pano ve arşiv: etcd | üretim ve planlama: sched | vardiya amirliği: c-m
Kubernetes Komponentleri — 2
Bu kısımda yukarıda anlattığımız tüm component’leri yakından tanıyacağız.
Yönetim:
* kube-api server (Resepsiyon ve güvenlik)
İlk olarak k8s’in beyni olarak adlandırabileceğimiz kube-api server’ından bahsedeceğiz, bu komponenti tasvirlememizde resepsiyon ve güvenliğe benzetmiştik. Bu komponent, k8s ile alakalı tüm komponentlerin ve dış dünyadan k8s platformuyla iletişim kuran, tüm servislerin ortak giriş noktasıdır. Api server, tüm komponent ve node bileşenlerinin direkt iletişim kurabildiği tek komponenttir ve tüm iletişim bu komponent üzerinden gerçekleşir. K8s’te kaynak oluşturma isteklerinin api doğrulamasından sorumludur. Kullanıcılar kubectl(komut satırı istemcisi) veya rest-api çağrıları aracılığıyla kube-api server ile iletişim kurabilirler. Özetle siz k8s iletişim kurmak isterseniz, kube-api server’a erişirsiniz → authentication / authorization işlemlerini tamamlar → isteklerinizi iletirsiniz. Aynı şekilde diğer tüm komponent’ler de iletişimini kube-api server aracılığıyla gerçekleştirir.
* etcd (pano ve arşiv)
K8s’in ikinci en önemli komponenti etcd(tasvirdeki pano): Tüm cluster verisi, metadata bilgileri ve k8s’de oluşturulan tüm objelerin bilgilerinin tutulduğu “key-value” veri deposudur. Cluster’ın mevcut durumu ile ilgili bilgiyi üzerinde barındırır. Özetle, k8s’in çalışması için gerekli tüm veriler etcd üzerinde tutulur. kube-api server hariç, diğer komponent’leri etcd ile direkt haberleşemezler, etcd ile iletişim kurmak isterlerse bunu kube-api server aracılığıyla yapmak zorundalar.
* kube-scheduler (üretim-planlama)
Tasvirimizde üretim-planlama olarak gösterilen kube-sceduler: Yaratılmak istenilen pod’ların gereksinimlerini kontrol ederek o pod’un en uygun çalışacağı worker node’un hangisi olduğunu tespit eder ve pod’un burada oluşturulmasını sağlar. Pod nedir daha sonra açıklayacağız ama şimdilik pod’u bir container olarak düşünelim. kube-scheduler pod’un kaynak isteğini, özel gereksinimlerini vb. çeşitli parametleri göz önünde bulundurur ve bir seçme algoritması sayesinde, pod için en uygun node’un hangisi olduğuna karar verir.
* kube-controller-manager (vardiya amirliği)
Tek bir binary olarak bulunsa da içerisinde birden fazla controller barındırır(node controller / job c. / service account & token c./endpoints c.). K8s; mevcut durumu, istenilen durumla karşılaştırma temelinde uygulama yönetimi sağlar. kube-controller-manager altındaki controller’lar, k8s cluster’ın mevcut durumu ile olması istenilen durum arasında farklılık olup/olmadığını gözlemler. Kube-api-server aracılığı ile etcd’de saklanan cluster durumunu inceler, eğer mevcut durum ile istenilen durum arasında bir fark varsa bu farkı oluşturan kaynakları gerektiği gibi oluşturur/günceller/siler vb. ile bu durumu eşitler.
- Ek bilgi: Bunların dışında Azure, Google ve AWS gibi cloud servis sağlayıcıların yönetilen k8s hizmetlerinde, cloud altyapısı ile k8s’in iletişim kurmasını sağlayan “cloud-controller-manager” adında bir komponent daha bulunur. Fakat bu konuyu çok sonra inceleyeceğiz :)
Yukarıdaki 4 komponent kubernetes yönetim kısmını(Control plane) oluşturuyor. Bu yönetim kısmı, master node olarak adlandırılan sistemler üzerinde çalışır. Tüm bu komponentler tek bir linux yüklü sisteme kurulup ordan erişilebileceği gibi, yüksek erişilebilirlik sağlaması adına birden fazla sisteme de kurulabilir. Etcd tamamen bu yapıdan ayrı olarak konumlandırılarak daha da yüksek erişilebilirlik hedeflenebilir ama genellikle etcd, api-server’ın koştuğu yerde durur.
Örneğin 3 sunucu üzerinde 3 kube api-server kurulup, diğer komponent’ler bu sistemlere dağıtılabilir. Bu üzerinde control plane’in koştuğu sistemlere cluster altında master node diyoruz. Master node’lar sadece bu sistemleri barındırmak için bulunur ve özellikle production sistemlerde herhangi bir iş yükünü bu sistemler üzerinde çalıştırmayız. Bunlarda sadece cluster’ın yönetim alt yapısını koştururuz.
Üretim:
İş yüklerimiz ise tasvirimizde makineler olarak adlandırdığımız worker node’lar üzerinde çalışır. Worker node, iş yüklerimizi(pod’larımızı) üzerinde çalıştırdığımız esas yerlerdir. Worker node’lar üzerlerinde “containerd” yada “docker” gibi container runtime(container’ları çalıştırmaktan sorumlu yazılım) barındıran ve cluster’a dahil edilmiş sistemlerdir(k8s; containerd, docker, CRI-O gibi container runtime’ları destekler).
Her worker node’da 3 temel komponent bulunur. İlk ve en önemlisi az önce bahsettiğimiz, container’ların çalışmasını sağlayacak container runtime’dır(Varsayılan olan docker’dı fakat artık containerd’ye geçti). Bunun yanında bizim tasvirimizde ustabaşı olarak tasvirlediğimiz kubelet de her worker node’da bulunur. Her worker node’da çalışan son komponent ise lojistikten sorumlu görevli olarak tasvirlediğimiz kube-proxy’dir.
* kubelet (ustabaşı)
Kubelet, kube-api server aracılığıyla etcd’yi kontrol eder ve kube-scheduler tarafından bulduğu node üzerinde çalışması gereken bir pod belirtildiyse; kubelet bu podu o sistemde yaratır. Containerd’ye haber gönderir ve belirlenen özelliklerde bir container’ın o sistemde çalışmasını sağlar.
Cluster’daki her node çalışan bir agent’tır. Pod içerisinde tanımlanan container’ların çalıştırılmasını sağlar. Kubelet, çeşitli mekanizmalar aracılığıyla sağlanan bir dizi pod tanımı alır ve bu pod tanımında belirtilen container’ların çalışır durumda ve sağlıklı olmasını sağlar.
* kube-proxy (lojistikten sorumlu görevli)
Oluşturulan pod’ların TCP,UDP ve SCTP trafik akışlarını yönetir, ağ kurallarını belirler ve yönetir. Kısacası network proxy görevi görür.
Bu komponent’lerin dışında DNS hizmeti veya GUI hizmeti sağlayan çeşitli add-on servisler, kurulumla birlikte entegre edilebilen servislerdir. Fakat core komponent’ler olarak adlandırılmaz. Tüm bu ekstraları ileride açıklayacağız.
Kubernetes Yayın Döngüsü
Bu kısımda k8s’in ne sıklıkla yeni version yayınladığını ve destek süreçlerini öğrenip, birkaç önemli kaynaktan bahsedeceğiz. Bu kısımla beraber teorik kısmı bitiriyor olacağız. Geleneksel IT sistemlerinde enterprise segmentteki ürünlerin senelerce release ve destek süreleri vardı. Bu süre k8s’de 12 aya indi. Bu bilgiyi biraz daha detaylandıralım.
İlk olarak k8s’in semantic version terminolojisini takip ederek “x.y.z” şeklinde versiyonlanır. K8s, her 4 ayda bir yeni bir minor version çıkarır. k8s her yeni version’u 12 ay boyunca güncelleyeceğini taahhüt eder, yani :
Bu da bizlerin bir version’u en çok 12 ay kullanabileceğimiz ve en geç 12 ayda bir güncelleme yapmamız anlamına geliyor. Bu ve benzeri bilgileri, CNCF(Cloud native computing foundation)üzerinden öğrenebiliriz. Buradan sonra başvurabileceğimiz bir diğer önemli kaynak da k8s’in documentation’u. K8s ile kod seviyesinde ilgilenmek isterseniz de k8s’in github adresinden yararlanabilirsiniz.
Burada biraz soluklanalım. Sonraki yazıda k8s kurulumlarını yapıp artık elimizi biraz kirletmeye başlayacağız :) Sonraki yazıda görüşmek üzere,
Mutlu günler ^^
Kaynakça :
- https://www.udemy.com/course/kubernetes-temelleri/
- https://medium.com/%40furkanbegen/mikroservis-mimarisi-nedir-ve-avantajlar%C4%B1-nelerdir-1369175cc4e6
- https://semihsaydam.medium.com/docker-yolculu%C4%9Fu-1-c2129320091
- https://github.com/aytitech/k8sfundamentals
- https://www.thefastcode.com/tr-try/article/how-to-clone-a-github-repository
- https://kodedu.com/2014/08/yaml-veri-degisim-formati-nedir/
- https://cafe.ayti.tech
- https://medium.com/%40gokhansengun/load-balancer-nedir-ve-ne-i%C5%9Fe-yarar-32d608f98ef9
- https://www.cncf.io
- https://kubernetes.io/docs/home/
- https://github.com/kubernetes/kubernetes