Merhabalar, Kubernetes Eğitim Serimizin 13. yazısına gelmiş bulunmaktayız. Bu yazımızda size Kubernetes içerisinde servisleri anlatacağım. Bu yazıyla beraber Kubernetes servislerinin ne olduğunu bir uygulama ile beraber görebileceksiniz. Mevcut servis türlerini tartışacağız. Yerel bir proxy başlatıp ardından cluster DNS kullanmayı öğreneceğiz.

Daha önce değindiğim gibi Kubernetes Mimarisi birbirine bağlı geçici ayrık nesneler kavramı üzerine inşa edilmiştir. Servisler herhangi belirli pod’un sonlanabileceği ve yeniden inşa edilebileceği düşüncesiyle pod’ları birbirine bağlayan veya küme dışında erişim sağlayan ajanlardır. Tipik olarak label’lar kullanılarak, yenilenen pod bağlanır ve mikroservis bir endpoint nesnesi üzerinden beklenen kaynağı sağlamaya devam eder.

Her servis cluster’a hem içeriden hemde dışarıdan etki edebilir. Bir servis ayrıca iç kaynakları üçüncü party veritabanı gibi harici bir kaynağa bağlayabilir.

kube-proxy ajanı Kubernetes API’ını her node’da oluşturulan yeni servis ve endpoint’ler için izler. Rastgele portları açar ve ClusterIP:Port’a giden trafiği dinler ve trafiği rastgele oluşturulmuş servis endpoint’lerine yönlendirir.

Servisler bir label sorgusuyla eşleşen otomatik load balance sağlar. Bu seçeneğin yapılandırılması bulunmamakla birlikte IP üzerinden session yapılabilir. Ayrıca sabit bir IP veya load balance olmadan bir servis yapılandırılabilir.

Label’lar hangi pod’ların bir servisden trafik alması gerektiğini belirlemek için kullanılır. Nesnelerin bir servise bağlanmaya devam etmesini etkileyecek bir nesne için label’lar dinamik olarak güncellenebilir.

Bir Uygulamaya Servis ile Erişim

$ kubectl expose deployment/nginx --port=80 --type=NodePort
$ kubectl get svc
.....

kubectl expose komutu nginx konuşlandırılması için bir servis oluşturmaktadır. Bu servis 80 port’unu kullanmaktadır ve tüm node’larda rastgele bir port oluşturmaktadır. Burada targetPort varsayılan olarak bağlantı noktasını belirler, ancak pod bir port’a dahil olmak üzere ayarlanabilir. Her pod’un farklı bağlantı noktası olabilir, ancak trafik adı üzerinden geçirilir.

kubectl get svc komutu, varolan tüm servislerin listesini verir.

Servis Tipleri

Servisler aşağıdaki türlere sahip olabilirler.

• ClusterIP
• NodePort
• LoadBalancer
• ExternalName

ClusterIP servis türü varsayılandır ve yalnızca internal olarak erişim sağlar (manuel olarak harici bir external endpoint oluşturulma hariç). Kullanılan ClusterIP aralığı bir API sunucusu başlatma seçeneği ile tanımlanır.

NodePort türü, hata ayıklama için veya belirli bir adresteki güvenlik duvarı üzerinde statik bir IP adresi gerektiğinde kullanılır. NodePort aralığı cluster yapılandırılmasında tanımlanmıştır.

LoadBalancer servisi, istekleri GKE veya AWS gibi bir cloud sağlayıcısına iletmek için oluşturulmuştur. Private Cloud çözümleri, CloudStack ve OpenStack gibi bir cloud sağlayıcısı eklentisi varsa da bu servis türünü uygulayabilir. Bir cloud sağlayıcısı olmasa ble adres genel trafiğe açıktır ve paketler deployment’daki pod’lar arasında otomatik olarak yayılır.

Yeni bir servis bunlardan biraz daha farklı olan ExternalName. Selector burada bulunmuyor, port’ları veya endpoint’leri tanımlamıyor. Bir alias’ın (takma ad) external bir service’e döndürülmesini sağlar. Yönlendirme DNS düzeyinde yapılır bir proxy veya yönlendirme ile gerçekleşmez. Bu nesne, henüz Kubernetes cluster’ına getirilmeyen service’ler için faydalı olabilir. Gelecekte türün basit bir şekilde değiştirilmesi, trafiği internal nesnelere yönlendirecektir.

kubectl proxy komutu bir ClusterIP’ye erişmek için yerel bir servis oluşturur. Bu sorun giderme veya geliştirme çalışmalari için yararlı olabilir.

Servis Diagramı

Cluster Node’larında çalışan kube-proxy, API sunucusu servis kaynaklarını izler. ExternalName dışındaki hizmetler için bir tür sanal IP adresi kullanır.

v1.0’da servisler TCP/UDP üzerinden IP veya Layer 4 üzerinden namespace modunda çalıştırıldı. v1.1 sürümünde iptables proxy’si eklende ve v1.2 ile başlayan varsayılan mod oldu.

iptables proxy modunda kube-proxy, servis ve endpoint nesnelerindeki değişiklikleri fark edebilmek için API sunucusunu izlemeye devam eder ve nesne oluşturulduğunda veya kaldırıldığında kuralları günceller. Bu modun bir sınırlaması, orjinal isteğin başarısız olması durumunda bir pod’a bağlanmamasıdır ve bu nedenle tüm container’ların bağlantıdan önce işlevsel olmasını sağlamak için Hazırlık Probu (Readiness Probe) kullanır. Bu modda yaklaşık 5000 node’a izin verir. Node başına birden fazla servis ve pod olduğunu varsaydığında, bu durum çekirdekte bir tıkanıklığa neden olur.

v1.9’da başlayan bir başka mod ipvs‘dir. Beta versiyonundadır ve stabil hale geçmesi beklenmektedir. Çekirdek alanında yüksek hız la çalışır. Önceki 5000 node sınırlamasının çok ötesinde, bütük cluster’lar için yararlı olabilir.

kube-proxy modu, mode=iptables gibi parametre şeklinde yapılandırılabilir.

Deployment için Yerel Proxy

Bir uygulama veya servis geliştirirken servisinizi kontrol etmenin hızlı bir yolu kubectl ile yerel bir proxy çalıştırmaktır. Arkaplanda olmadıkça yakalama işlemi yapacaktır. Çalışırken localhost’taki Kubernetes API’ını çağırabilir ve ayrıca kendi API URL’lerinden ClusterIP servislerine erişebilirsiniz. Proxy’nin dinlediği IP ve port komut parametreleri ile yapılandırılabilir.

Proxy çalıştıralım.

$ kubectl proxy
Starting to serve on 127.0.0.1:8001

Ardından yerel proxy kullanarak bir “ghost” isimli servise erişmek için http://localhost:8001/api/v1 /namespaces/default/ services/ghost yolunu kullanabilirsiniz.

Servis portunun bir ismi varsa aşağıdaki yol kalıbı üzerinden erişebilirsiniz. Burda ekstra port’da girilmiştir.

http://localhost:8001/api/v1/ namespaces/default/ services/<service_adi>:<port_adi>

DNS

DNS, v1.13’ten itibaren varsayılan olarak CoreDNS üzerinden sağlanmaya başlanmıştır. CoreDNS kullanımı büyük miktarda esneklik sağlar. Pod başladıktan sonra, hizmet vermek üzere yapılandırıldığı bölgeler için bir sunucu çalıştıracaktır. Ardından her sunucu başka işlevsellik sağlamak amacıyla bir veya daha fazla eklenti zinciri yükleyebilir.

Daha fazla bilgiyi buradan ulaşabilirsiniz.

DNS Kaydı Doğrulama

DNS kurulumunuzun iyi çalıştığını ve izmetlerin kaydedildiğinden emin olmak için bunu yapmanın en kolay yolu, cluster’da bir pod çalıştırmak ve bir DNS araması yapmak için komut yürütmektir.

Bir busybox pod’unu oluşturalım ve sleep fonksiyonunu çalıştıralım.

apiVersion: v1
kind: Pod
metadata:
    name: busybox
    namespace: default
spec:
    containers:
    - image: busybox
      name: busy
      command:
        - sleep
        - "3600"

kubectl exec komutunu çalıştırıp içerisinde nslookup fonksiyonunu çağıralım.

$ kubectl exec -ti busybox -- nslookup nginx
Server: 10.0.0.10
Address 1: 10.0.0.10

Name: nginx
Address 1: 10.0.0.112

DSN adının nginx’in (nginx servisine karşılık gelen) servisin ClusterIP’isinde kayıtlı olduğunu görebiliriz.

Herhangi bir DNS sorun giderme işlemine benzer diğer adımlar, container’ın /etc/resolv.conf dosyasını kontrol etmektedir.

$ kubectl exec busybox cat /etc/resolv.conf

Ardından kube-dns pod’undaki her bir container’ın log dosyalarını kontrol edin. Uyarı için W, hata için E, failure için F satırlarına bakabilirsiniz.

Yazımızın bu satırlarında Kubernetes Servis Yönetimini tamamlıyoruz. Bir sonraki yazımda burada anlatılan teorilerin laboratuvarı yapılacaktır. Buradan laboratuvara ulaşabilirsiniz, 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 !!!!