Kubectl Nedir?

Merhaba arkadaşlar bu yazımda Kubernetes Kubectl’i nasıl daha verimli kullanacağınızı öğrenmeden önce, onun ne olduğu ve nasıl çalıştığı hakkında temel bir anlayışa sahip olmalısınız. Bir kullanıcının bakış açısından kubectl, Kubernetes’i kontrol etmek için sizin kokpitinizdir. Mümkün olan her Kubernetes işlemini gerçekleştirmenizi sağlar.

Teknik açıdan kubectl, Kubernetes API için bir istemcidir. Kubernetes API, bir HTTP REST API’sidir. Bu API, gerçek Kubernetes kullanıcı arayüzüdür. Kubernetes, bu API aracılığıyla tamamen kontrol edilir. Bu, her Kubernetes işleminin bir API uç noktası olarak kullanıma sunulduğu ve bu uç noktaya yönelik bir HTTP isteği tarafından yürütülebileceği anlamına gelir. Sonuç olarak, kubectl’in ana işi, Kubernetes API’sine HTTP isteklerini gerçekleştirmektir:

Kubernetes tamamen kaynak merkezli bir sistemdir. Bu, Kubernetes’in kaynakların dahili durumunu koruduğu ve tüm Kubernetes işlemlerinin bu kaynaklar üzerinde CRUD işlemleri olduğu anlamına gelir. Bu kaynakları manipüle ederek Kubernetes’i tamamen kontrol edersiniz (ve Kubernetes, kaynakların mevcut durumuna göre ne yapılması gerektiğini belirler). Bu nedenle, Kubernetes API referansı, ilişkili işlemleriyle birlikte kaynak türlerinin bir listesi olarak düzenlenir.

Bir örnek düşünelim.

Bir ReplicaSet kaynağı oluşturmak istediğinizi hayal edin . Bunu yapmak için, ReplicaSet’i replicaset.yaml dosyası adlı bir dosyada tanımlar ve ardından aşağıdaki komutu çalıştırırsınız:

$ kubectl create -f replicaset.yaml

Açıkçası, bu, Kubernetes’te ReplicaSet’inizi oluşturur. Ama perde arkasında ne oluyor?

Kubernetes’in bir ReplicaSet oluşturma işlemi vardır ve tüm Kubernetes işlemleri gibi, bir API uç noktası olarak sunulur. Bu işlem için belirli API uç noktası aşağıdaki gibidir:

POST /apis/apps/v1/namespaces/{namespace}/replicasets

Tüm Kubernetes işlemlerinin API uç noktalarını API referansında (yukarıdaki uç nokta dahil) bulabilirsiniz. Bir uç noktaya gerçek bir istekte bulunmak için API sunucusunun URL’sini API referansında listelenen uç nokta yollarının başına eklemeniz gerekir.

Sonuç olarak, yukarıdaki komutu çalıştırdığınızda, kubectl, yukarıdaki API uç noktasına bir HTTP POST isteği yapar. ReplicaSet tanımı (replicaset.yaml dosyasında sağladığınız), isteğin gövdesine iletilir.

Kubectl, Kubernetes kümesiyle etkileşime giren tüm komutlar için bu şekilde çalışır. Tüm bu durumlarda kubectl, uygun Kubernetes API uç noktalarına HTTP istekleri yapar.Kubernetes API’sine manuel olarak HTTP istekleri göndererek Kubernetes’i curl gibi bir araçla kontrol etmenin tamamen mümkün olduğunu unutmayın. Kubectl, Kubernetes API’sini kullanmanızı kolaylaştırır.Bunlar kubectl’in ne olduğu ve nasıl çalıştığıyla ilgili temel bilgilerdir. Ancak her kubectl kullanıcısının bilmesi gereken Kubernetes API hakkında çok daha fazlası var. Bu amaçla, Kubernetes’in içindekilere kısaca dalalım.

Kubernetes internals

Kubernetes, bir kümenin düğümlerinde ayrı işlemler olarak çalışan bir dizi bağımsız bileşenden oluşur. Bazı bileşenler ana düğümlerde, diğerleri ise çalışan düğümlerde çalışır ve her bileşenin çok özel bir işlevi vardır.

Ana düğümlerdeki en önemli bileşenler şunlardır:

Storage backend: kaynak tanımlarını saklar (genellikle etcd kullanılır)

API sunucusu: Kubernetes API’sini sağlar ve depolama arka ucunu yönetir Denetleyici yöneticisi: kaynak durumlarının spesifikasyonlarla eşleşmesini sağlar Zamanlayıcı: Bölmeleri çalışan düğümlerine programlar Ve bu, çalışan düğümlerindeki en önemli bileşendir:

Kubelet: bir çalışan düğümde kapsayıcıların yürütülmesini yönetir

Bu bileşenlerin birlikte nasıl çalıştığını görmek için bir örnek düşünelim.Az önce kubectl create -f replikaset.yaml yürüttüğünüzü ve bunun üzerine kubectl’in create ReplicaSet API uç noktasına (ReplicaSet kaynak tanımınızı ileterek) bir HTTP POST isteğinde bulunduğunu varsayın.

Kümede buna hangi etkiler neden olur? Aşağıdan izleyin:

Ardından kubectl create -f replicaset.yaml, API sunucusu, ReplicaSet kaynak tanımınızı depolama arka ucuna kaydeder.

Bu, denetleyici yöneticisinde ReplicaSet kaynaklarının oluşturulmasını, güncellemelerini ve silinmesini izleyen ReplicaSet denetleyicisini tetikler.

ReplicaSet denetleyicisi, ReplicaSet’in her bir kopyası için (ReplicaSet tanımındaki Pod şablonuna göre) bir Pod tanımı oluşturur ve bunları depolama arka ucuna kaydeder.

Scheduler, her Pod için uygun bir çalışan düğümü seçer ve bu bilgiyi depolama arka ucundaki Pod tanımlarına ekler.

Bu, çalışan node’a programlanmış Pod’ları izleyen Pod’ların programlandığı çalışan düğümündeki kubelet’i tetikler.

Kubelet, depolama arka ucundan Pod tanımlarını okur ve konteyner çalışma zamanına (örneğin Docker) konteynerleri işçi düğümünde çalıştırması talimatını verir.Ve burada metinsel açıklamayı takip eder.

Oluşturma ReplicaSet uç noktasına yönelik API isteği, API sunucusu tarafından işlenir. API sunucusu, isteğin kimliğini doğrular ve ReplicaSet kaynak tanımınızı depolama arka ucuna kaydeder.Bu olay, denetleyici yöneticisinin bir alt işlemi olan ReplicaSet denetleyicisini tetikler. ReplicaSet denetleyicisi, depolama arka ucundaki ReplicaSet kaynaklarının oluşturulmasını, güncellenmesini ve silinmesini izler ve bu gerçekleştiğinde bir olay tarafından bilgilendirilir.

ReplicaSet denetleyicisinin işi, bir ReplicaSet’in gerekli sayıda replika Pod’unun var olduğundan emin olmaktır. Örneğimizde henüz bir Pod mevcut değildir, bu nedenle ReplicaSet denetleyicisi bu Pod tanımlarını (ReplicaSet tanımındaki Pod şablonuna göre) oluşturur ve bunları depolama arka ucuna kaydeder.

Yeni Bölmelerin oluşturulması, henüz bir çalışan düğümüne programlanmamış Bölme tanımlarını izleyen zamanlayıcıyı tetikler. Zamanlayıcı, her Pod için uygun bir çalışan düğümü seçer ve bu bilgilerle depolama arka ucundaki Pod tanımlarını günceller.Bu noktaya kadar kümenin herhangi bir yerinde hiçbir iş yükü kodunun çalıştırılmadığını unutmayın. Şimdiye kadar yapılan tek şey, ana düğümdeki depolama arka ucunda kaynakları oluşturmak ve güncellemektir.

Bu olay, çalışan düğümlerine programlanmış Pod’ları izleyen kubelet’leri tetikler. ReplicaSet Pod’larınızın çalışan düğümünün kubelet’i, yapılandırılmış kapsayıcı çalışma zamanına (Docker olabilir) gerekli kapsayıcı görüntülerini indirmesi ve kapsayıcıları çalıştırması talimatını verecek şekilde programlanmıştır.

Bu noktada nihayet ReplicaSet uygulamanız çalışıyor!

Kubernetes API’sinin rolü

Yukarıdaki örnekten de görebileceğiniz gibi, Kubernetes bileşenleri (API sunucusu ve depolama arka ucu hariç), depolama arka ucundaki kaynak değişikliklerini izleyerek ve depolama arka ucunda kaynakları manipüle ederek çalışır.Ancak bu bileşenler, depolama arka ucuna doğrudan erişmez, yalnızca Kubernetes API aracılığıyla erişir.

Aşağıdaki örnekleri göz önünde bulundurun:

ReplicaSet denetleyicisi, ReplicaSet kaynaklarındaki değişiklikleri izlemek için bir izleme parametresiyle ReplicaSets API uç noktası API işlemini kullanır. ReplicaSet denetleyicisi, Pod’lar oluşturmak için Create Pod API uç noktasını kullanır. Planlayıcı, Pod’ları seçilen çalışan düğümü hakkındaki bilgilerle güncellemek için yama Pod API uç noktasını kullanır. Gördüğünüz gibi, bu kubectl tarafından da kullanılan API ile aynıdır.

Kubernetes API’sinin hem dahili bileşenler hem de harici kullanıcılar için bu ikili kullanımı, Kubernetes’in temel tasarım konseptidir.

Bu bilgi ile Kubernetes’in nasıl çalıştığını şu şekilde özetleyebilirsiniz:

Storage backend, Kubernetes’in durumunu (yani kaynakları) depolar. API sunucusu, Kubernetes API biçiminde depolama arka ucuna bir arabirim sağlar. Diğer tüm Kubernetes bileşenleri ve kullanıcıları, Kubernetes API aracılığıyla Kubernetes’in durumunu (yani kaynakları) okur, izler ve işler. Bu kavramlara aşina olmak, kubectl’i daha iyi anlamanıza ve ondan en iyi şekilde yararlanmanıza çok yardımcı olacaktır!

İlk yorum yapan olun

Bir yanıt bırakın

E-posta hesabınız yayımlanmayacak.


*