Kubernetes Objeleri
Kubernetes Obje Tipleri ve Servis Tipleri
Merhabalar
Bu yazımda Kubernetes obje tiplerinin bir kısmı ile Kubernetes Servis tiplerini inceliycez.
Pod
Container’ların içinde çalıştığı komponentlerdir. Kubernetes Cluster’ınızda çalışan process leri temsil etmektedir. En küçük atanabilir birimdir. Podlar Kubernetes Cluster’ınızın deploy edilebilir birimlerdir. Kendilerine has IP’leri vardır. İçlerinde bir veya daha fazla container bulundurabilir. Kisaca bir grup containera verilen addır. Pod’ların en büyük avantajı çoğaltılabilir olmalarıdır. Yük altında kolaylıkla çoğaltılıp, iş gücünü artırabiliriz.
Containerlar namespaceleri sayesinde birbirlerinden ayrılmaktadır. Farklı namespace’deki process, network ve storage birbirlerini görmeyecek, birbirlerinden izole olacaktır. Bu yaklaşımdan yola çıkarsak, Kubernetes’te network ve storage gibi kavramlar için bu soyutlama pod düzeyindedir. Bunun anlamı, aynı pod içerisindeki containerlar aynı storage, network paylaşırlar. Bir poddaki container ın açtığı bir sokete yine aynı pod’daki bir diğer container cluster üzerinden ulaşabilir.
Podların önemli sorumluluğunun da soyutlama olduğu söyleyebiliriz. Kubernetesde en fazla tercih edilen container runtime’ı docker olmakla birlikte alternatifleri de olduğunu unutmamak gerekir. Bu noktada Pod kavramı Kubernetes için aynı zamanda docker container kavramında bir soyutlama anlamınada gelmektedir. Kubernetes, containerları değil podları yönetmektedir.
Pod statüleri
Pending
- Kubernetes tarafından apply edilen komutun kabul edildi.
- Container image ın sisteme inmesi beklendiği statüdür.
Running
- Podu bir node ile ilişkilendirildiği gösterir.
- Tüm containerların yaratıldığı gösterdiği statüdür.
Succeed
- Poddaki tüm containerların sonlandırıldı yani işlemleri yaptığı gösteren statüdür.
Failed
- Tüm containerların çalışmasın bittiği ve sonlandırırken en az bir tanesinin hata verdiğini gösteren statüdür.
Unknowm
- Podun durum bilgisini alamadığını ve pod üzerinde çalışan nodedan node bilgisini okunmadığı gösteren statüdür.
Aşağıda bir Pod Manifest Örneği gösterilmiştir.
Replica Set
Bir poddan kaç tane olacağını replica set ile belirtiyoruz. Podun birisi öldüğünde bakıyor ve yeniden bir pod ayağa kaldırıyor ve IP atıyor. İstediğiniz anda bir podu kesintisiz bir şekilde scale artırabilir yada azaltabiliriz.
Replica Set Manifest
Deployment
Kubernetes nodeların da podların nasıl çoğaltılmasını ayarladığımız kubernetes objesidir. Deployment, arka tarafta Replica Set kullanır. Deployment Replica Set’in yanında rolling update yapma imkanı veren ilgili podu ve replica sayılarını belirttiğimiz bir Kubernetes objesidir. Podları güncelleştirilirken stratejisini tanımlamamızı sağlar.
Deployment Manifest
Kubernetes Rolling Update
Podları kontrol etmek için bir deployment kullanmanın faydalarından biri, sürekli güncellemeleri gerçekleştirme yeteneğidir. Periyodik güncellemeler, podların yapılandırmasını kademeli olarak güncellemenize olanak sağlar.
Deployment manifest 2 olası değere sahiptir.
- RollingUpdate: Podlar kademeli olarak eklenir ve eski podlar kademeli olarak silinir.
Örneğin eski_pod_1 ve eski_pod_2 adında iki tane poddumuz olsun önce bunları birer birer sistemden kaldırır ve kaldırdıktan sonra yeni podu ayağa kaldırır .
Rolling update kullanırken güncelleme yapmamızı sağlayan iki seçenek vardır.
- maxSurge: Güncelleme sırasında istenen podun üzerinde oluşturulacak pod sayısı belirleyebiliriz.
- maxUnavailable: Güncelleme sırasında kullanılmayan pod sayısı belirtebiliriz.
..
.
replicas: 3
strategy:
type: RollingUpdate
rolingUpdate:
maxSurge: 1
maxUnavailable
- Recreate: Yeni podları eklemeden önce sistemde olan eski podların hepsini kaldırır. Genelde önerilen strateji değildir. Ama tam versiyon geçişlerinde kullanılacak deployment strategy sidir.
Note: Recreate deployment strategy’inde roolout sıkıntı yaratabilir.
3- Kubernetes Servis Tipleri
Service, Podların oluşturduğu bir logical set olarak tanımlanabilir. Service, bizlere cluster içinde uygulamalar arasında iletişim kurmamızı veya cluster dışından gelen istekleri karşılayarak podlara yönlendirme imkanı sağlar. Örneğin; Frontend, Backend ve DB olmak üzere 3 ayrı katmandan oluşan bir uygulamamız olduğunu düşünelim. Bu uygulamayı 3 deployment objesi ile katmanlara bölelim. Bu katmanlardan, son kullanıcıların Frontend’e, Frontend katmanının Backend katmanına, Backend katmanının ise DB ile iletişimlerini Service’ler ile sağlayabiliriz.
Oluşturulan bu servicelerin hangi pod’lar için hizmet vereceği yine Label-Selector yardımı ile sağlanmaktadır. İlgili Pod’lara atanan Label değerleri ve ilgili service tanımında Selector kullanılarak tanımlama yapılır.
ClusterIP: Cluster içerisinde yer alan servislerin birbirleri arasında iletişim kurabilmesi için kullanılan servis tipidir. Varsayılan servis tipidir. Servisinizi internal bir ip ile yayınlar ve sadece cluster içerisinden (diğer servislerden) erişilebilir hale getirir. Harici yani dışarıdan erişimi yoktur. Eğer bu tipteki bir servise dışarıdan erişim ihtiyacınız olur ise bunu kubernetes proxy kullanarak yapabilirsiniz.
ClusterIP Manifest Örneği
Dışarıdan yani tarayıcıdan ClusterIP servisine erişemezsiniz. Erişmek istiyorsanız Kubernetes proxy kullanarak ulaşabilirsiniz. Trafiği proxy üzerinden service yönlendirebilirsiniz.
Kubernetes proxy başlatmak için aşağıdaki komut kullanılır;
kubectl proxy --port=8080Tarayıcıdan erişmek için de aşağıdaki linke gidin;
http://localhost:8080/api/v1/proxy/namespaces/<NAMESPACE>/services/<SERVICE-NAME>:<PORT-NAME>/Servislere erişmek için kubernetes proxy kullanacağımız bir kaç senaryo var. Bunlar;
- Hata ayıklama(debug) direk erişim için
- İç trafiğe izin verme ,iç tarifi dashboarda göstermek için
- Local cihazınızdan erişmek için
NodePort: NodePort türü ile tanımlanan bir Kubernetes Service’i cluster dışından da erişilebilir olacaktır. Bu tip Service ile node üzerinde dışarıdan erişilebilir bir port erişime açılır. Bu port numarası 30.000’den büyük bir port numarası olur. İlgili VM(Node)’in IP’si ve bu port numarası ile birlikte bu Service’e erişim sağlanır.
Kısaca, nodeport node’a bir port ataması yap ve node dışarıya aç demektir.
Servisler <NodeIP>:<NodePort> şeklinde erişilebilir olur.
Nodeport Manifest
Dikkatinizi çekecek 2 nokta var.
- type: Nodeport olması
- nodePort: 30036 eğer burda nodeport belirtmezseniz rastgele bir port açıp yayınlayacaktır. Rastgele 30000–32767 port aralığını kullanmaktadır.
NodePort’un birçok olumsuz nedeni vardır bunlar ;
- Bağlantı noktası başına yalnızca bir hizmetiniz olabilir.
- Yalnızca 30000–32767 numaralı bağlantı noktalarını kullanabilirsiniz.
- Node veya Virtual Machindeki IP adresi değişirse ise değişen IP adresi ve nodeport ile gitmemiz gerekir.
Load Balancer: Service’e bir Public IP atanması sağlanır, bu sayede Service’in dış dünyaya açılmasını sağlanır. Dış networkten gelen istekleri karşılayarak ilgili Node’lar dağıtma hizmetini sağlar.
Bir servisi doğrudan dışarıya açmak istediğimizde bu tipi kullanabiliriz. Belirtilen porttaki tüm trafik servise iletilecektir. Bu HTTP, TCP, UDP, gRPC, websockets gibi hemen hemen her tür trafiği gönderebileceğiniz anlamına gelir.LoadBalancer MetalLb yada türevi olan bir tool ile kullanarak verilir.
Loadbalancer dezavantajı;
- LB ile sunduğunuz her servisin kendi IP adresini almasıdır.
3.3.1 — Load Balancer Manifest
ExternalName: ExternalName türü ile tanımlanan bir Kubernetes Service’i önceki türlerde olduğu gibi selector kullanmak yerine DNS adını kullanacaktır. Bu türde, önceki türlerde olan proxy ya da forward işlemleri kullanılmamaktadır. Yönlendirme işlemi DNS seviyesinde gerçekleşmektedir.
Ingress: Ingress aslında bir servis türü değildir. Fakat cluster içerisindeki trafiği dışarıya açmak için loadbalancer dan daha az maliyetlidir. Ingress gelen isteklerin servislerimize ulaşabilmesini sağlayan kurallar bütünüdür. Controller yapılandırmaları ile birden çok servisin önünde durur ve cluster da bir akıllı yönlendirici veya giriş noktası (entrypoint) görevi görür. Adeta bir reserve proxy görevi yapar ve Serviceler arası yük dağıtan bir router gibi davranır. Çalışması için cluster da Ingress Controller bulunması gerekir.
Aynı IP adresi altında birden çok servisi hizmete sunmak istiyorsanız ve bu servislerin tümü aynı L7 protokolünü (tipik olarak HTTP) kullanıyorsa ingress kullanılabilir
Kısaca ingress ile tek bir ip ile cluster içerisindeki servislere erişim verebilir.
Ingress Manifest
Bu yazımızın da sonuna gelmiş bulunmaktayız. Araştırmalarım ve sektörde karşılaştığım senaryolar üzerine yazılarımı yazmaya devam edeceğim. Umarım faydalı bir yazı olmuştur. Yazımı okuduğunuz için teşekkürler.
Referanslar ;
https://kubernetes.io/docs/concepts/services-networking/service/
https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/
https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
