Merhaba arkadaşlar, Kubernetes eğitim serisinin 7. içeriği olan API‘lar konusunu bugün sizlere anlatacağım. Bu temel konuyu anlamak ve akabinde gelecek olan LAB eğitimini yapmak çok önemli olacaktır. Çünkü Kubernetes’in temel haberleşmesi API’lar üzerinden gerçekleşmektedir. Bu yazının sonunda;
- API REST tabanlı mimariyi anlayabilecek,
- Annotations ile çalışabilecek,
- Basit bir Pod şablonunu anlayabilecek,
- Namespace kullanarak cluster kaynaklarını ayırabileceksiniz.
API Erişimi
Kubernetes, REST tabanlı güçlü bir API’ya sahiptir. Tüm mimari API odaklıdır. Endpoint’leri nereden bulacağınızı bilmek ve API’ın sürümler arasında nasıl değiştiğini anlamak, devam eden değişim ve büyüme ile birlikte önemli olur. Kubernetes Mimarisi yazısında öğrendiğimiz gibi cluster ajanları ve cluster dışındaki iletişim için ana etmen kube-apiserver‘dır. Ajana bir cURL sorgusu geçerli API gruplarnı gösterecektir.
RESTful
kubectl, tipik HTTP eylemlerine (GET, POST, DELETE vs.) cevap vererek sizin adınıza API çağrıları yapar. Ayrıca curl veya başka bir yazılım kullanarak harici olarak API çağrıları yapabilirsiniz. Uygun sertifika ve anahtarlarla yapılandırma değişiklikleri yapmak için isteklerde bulunabilir veya JSON dosyaları gönderebilirsiniz.
Erişim Kontrolü
Güvenlik konusunu ileriki yazılarımızda daha detaylı konuşacağız. Burada bilmemiz gereken kullanıcıların yetkilerini kontrol edebilmek. Aşağıdaki örnekte, örnek bir kullanıcının neler yapabileceği sorgulanıyor.
$ kubectl auth can-i deployments
yes
$ kubectl auth can-i create deployments --as umit
no
$ kubectl auth can-i create deployments --as umit --namespace deneme1
yesBurada kimin neyi sorgulayacağını belirlemek için uygulanacak üç API türü var.
SelfSubjectAccessReview: Herhangi bir kullanıcı için erişim incelemesi yapmak, başka kullanıcılara yetki vermede yardımcı olur.
LocalSubjectAccessReview: Belirli bir namespace ile ilgili sınırlı işlemler vardır.
SelfSubjectRulesReview: Bir kullanıcı için belirli bir namespace’teki izin verilen işlemleri yapabilir.
Annotations Kullanımı
Label’lar nesnelerle veya nesne koleksiyonlarıyla çalışmak için kullanılırken, annotations bu amaçla kullanılmaz. Objelerin metadata’larına eklenirler ve etiketlerden daha fazla okunabilir bilgi tutabilirler.
Bu tip metadata verilerine sahip olmak bir zaman damgasından daha çok, başka ekosistemdeki nesnelerin pointerlarına veya o nesnenin oluşmasından sorumlu developer’dan gelen bir e-postayı izlemek için işe yarayabilir.
Annotations, harici bir veritabanında tutulabilir ancak verilerin esnekliğini sınırlar. Ne kadar çok metadata’ya eklenirse o kadar çok yönetim ve dağıtım araçlarına entegre etmek o kadar kolay olur.
Örneğin; bir namespace’teki yalnızca pod’lara ekleme yapabilirsiniz.
$ kubectl annotate pods --all description='Ödeme sistemleri' -n odeme-sistemi
$ kubectl annotate --overwrite pods description='Eski ödeme sistemleri' -n odeme-sistemiBasit Bir Pod Şablonu
Daha önceden Kubernetes temelleri ve mimarisinde anlatıldığı üzere pod’lar en düşük birimlerdir. İçerisinde tek bir container olabilir, ancak çoğu zaman bir birincil container ve bunu destekleyen destekleyici container’lardan oluşacaktır.
Aşağıda YAML formatında basit bir pod şablonu örneği vardır. apiVersion (var olan api grubu ile eşleşmesi gerekiyor), kind (oluşturulacak nesnenin türü), metadata, spec ( kabı tanımlayan özellikler, oluşturulacak parametreler) gibi özellikler görebilirsiniz.
apiVersion: v1
kind: Pod
metadata:
name: denemepod
spec:
containers:
- image: nginx
name: webserver1YAML dosyası olarak kaydettikten sonra kubectl create komutunu kullanarak bu pod’u oluşturabilirsiniz. Oluşturduktan sonra durumunu izleyebilirsiniz ve JSON veya YAML olarak çıktı alabilirsiniz.
$ kubectl create -f deneme.yaml
pod/denemepod created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
denemepod 1/1 Running 0 28s
$ kubectl get pod denemepod -o yaml
$ kubectl get pod denemepod -o jsonAPI Kaynaklarını kubectl ile Yönetelim
Kubernetes, tüm kaynakların HTTP, JSON veya XML ile yönetilmesine izin veren RESTful API çağrıları aracılığıyla yönetilmesine olanak sağlar. Tipik protokol HTTP’dir. Kaynakların durumu standart HTTP eylemleri (örneğin, GET, POST, PATCH, DELETE …) kullanılarak değiştirilebilir.
kubectl, komutun nereden alındığı ve bilgiyi güncellediği yerin detaylarını gösteren ayrıntılı mod argümanına sahiptir. API versiyonu sıfırdan herhangi bir sayıya kadar tüm seviyeleri kabul etsede şuanda dokuzdan daha büyük bir API ayrımı sağlayan seviye yoktur. Az önce oluşturduğumuz pod’u izleyelim.
$ kubectl --v=10 get pods denemepod
....
I0412 22:53:36.468501 22283 round_trippers.go:419] curl -k -v -XGET -H "User-Agent: kubectl/v1.14.0 (linux/amd64) kubernetes/641856d" -H "Accept: application/json;as=Table;v=v1beta1;g=meta.k8s.io, application/json" 'https://10.142.0.14:6443/api/v1/namespaces/default/pods/denemepod'
....Kube Config Dosyası
$ kubectl config view
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: DATA+OMITTED
server: https://10.142.0.14:6443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
user:
client-certificate-data: REDACTED
client-key-data: REDACTEDYukarıdaki çıktı ~/.kube/config yolunda bulunan kube config dosyasıdır. 19 satırlık bir dosyadır.
apiVersion: Diğer nesnelerdede olduğu gibi kube-apiserver’da nereye atanacağını belirler.
clusters: Cluster’un adını ve API çağrılarının nereye gönderileceğini içerir. cURL isteğini doğrulamak için certificate-authority verileri iletilir.
contexts: Tek bir yapılandırma dosyasından, çeşitli kullanıcıların, birçok cluster’a kolay erişim sağlayan bir ayar. Namespace, kullanıcı ve cluster ayarlamak için kullanılabilir.
current-context: kubectl komutunun kullanacağı cluster’ı ve kullanıcıyı gösterir. Bu ayarlar ayrıca komut başına iletilir.
kind: Kubernetes içerisinde her nesne bu ayara sahip olmalıdır. Nesnenin türüdür. Config.
preferences: Halen kullanılmayan, kubectl komut çıktısını ayarlayabileceğiniz isteğe bağlı bir ayardır.
users: İstemci kimlik bilgileri ile ilişkilendirilmiş, client key, sertifika, kullanıcı adı, şifre ve token gibi bilgiler içerir.
Namespace
Namespace terimi, hem kernel özelliklerine hemde API nesnelerinin Kubernetes tarafından ayrılmasına yardımcı olmak için kullanılır.
Her API çağrısı aksi belirtilmedikçe default adında varsayılan bir namespace kullanır. Örneğin:
https://10.142.0.14:6443/api/v1/ namespaces/default/pods
Namespace’ler birden çok grubu ve quotas aracılığıyla birlikte çalışabilecekleri kaynakları ayırmayı amaçlamaktadır. Cluster ilk kez oluşturulduğunda üç namespace’i vardır.
default: Aksi belirtilmediği sürece tüm kaynakların varsayılan namespace’idir.
kube-public: Bu namespace kimliği doğrulanmayanlardan tutunda herkes tarafından okunabilir. Genel bilgiler genellikle bu ad alanlarına dahil edilir.
kube-system: Alt yapı pod’larını içerir.
Bir sistemdeki tüm kaynakları görmek istiyorsanız, –all-namespaces seçeneğini kubectl komutuna iletmelisiniz.
Örnek namespace komutları aşağıda verilmiştir.
$ kubectl get ns
Listeler
$ kubectl create ns deneme
Oluşturur
$ kubectl describe ns deneme
Açıklamasını gösterir
$ kubectl get ns/deneme -o yaml
YAML formatında çıktı verir
$ kubectl delete ns/deneme
SilerPod şablonu içerisinde aşağıdaki gibi kullanılabilir.
apiVersion: V1
kind: Pod
metadata:
name: ornek
namespace: deneme
....kubectl ile API Kaynakları
Tüm API kaynaklarına kubectl komutu ile ulaşılabilir. Daha fazla ayrıntı için kubectl help komutunu çalıştırabilirsiniz.
Syntax: kubectl [command] [type] [Name] [flag]
Syntax’da belirtilen yerleri doldurmak için aşağıdaki tabloyu kullanabilirsiniz.
Ek Kaynak Yönetim
REST ile temel kaynak yönetimine ek olarak API’lar, belirli kaynaklar için son derece yararlı endpoint’ler sağlar. Örneğin, bir container’ın loglarına erişilebilir, içine girip komut çalıştırılabilirsiniz.
Cluster içerisindeki API gruplarını takip ederek aşağıdaki çağrıları yapabilirsiniz. (Aşağıdakiler şablondur, doldurmanız gerekmektedir. Laboratuvar ortamında bu işlemleri yapacağız. )
GET /api/v1/namespaces/{namespace}/pods/{name}/exec
GET /api/v1/namespaces/{namespace}/pods/{name}/log
GET /api/v1/watch/namespaces/{namespace}/pods/{name} API Gelişimi
API gruplarının ve farklı sürümlerin kullanılması, mevcut bir API grubundaki değişikler olmadan geliştirmenin ilerlemesini sağlar. Bunun sebebi ayrı ekipler arasında işin daha kolay büyümesini ve ayrılmasını sağlar.
Adı Alpha olarak belirtilmiş API seviyeleri bug’lı olabilir ve varsayılan olarak devre dışıdır. Özellikler herhangi bir zamanda değişebilir veya kaybolabilir. Bu özellikleri test cluster’ında kullanmanızı öneririm.
Adı Beta olarak belirtilmiş API seviyeleri daha iyi test edilmiş bir koda sahiptir ve varsayılan olarak etkindir. Ayrıca değişiklikler ilerledikçe sürümler arasında geriye dönük uyumluluklar için test edilmelerini sağlar. Kararlı olarak adlandırılacak kadar benimsenmemiş ve test edilmemiştir. Bazı hatalar ve sorunlarla karşılaşabilirsiniz.
Yalnızca v harfinden sonra gelebilecek bir tam sayu ile gösterilen Stable sürümleri kullanımı kararlı API’lardır.
Yazımı bu noktada sonlandırıyorum. Bir sonraki yazımda bu teorilerin bir deneyini ve ardından API nesnelerini anlatan bir yazı yazmayı düşünüyorum. API ve Erişim hakkındaki laboratuvar ortamına buradan geçebilirsiniz, görüşmek üzere !
Umarım bu yazı sizin için bilgilendirici olmuştur. Yazıyla ilgili bir sorunuz, görüşünüz veya isteğiniz varsa alt kısımda bulunan yorumlardan veya mail adresimden iletişime geçebilirsiniz. Bu yazının başkaları içinde bilgilendirici olduğunu düşünüyorsanız sosyal olun ve sosyal medyada paylaşın! Okuduğunuz için teşekkürler !!!