‫Artık pod'larınızı çalıştırdığınıza göre, muhtemelen
‫bunları bir noktada harici hizmetlere açmanız gerekecektir.
‫Bu, bir şekilde kümenizden veya kümenizin dışından bağlantıları
‫kabul etmelerine izin vermek anlamına gelir.
‫Kubernetes'te, bir hizmet oluşturmanın yollarından biri
‫olarak kubectl expose komutunu kullanırız.
‫Hizmetten daha önce birkaç kez bahsettik, ancak hizmetin ne olduğu konusunda
‫net olduğumuzdan emin olalım. Bir hizmet, kümenin içindeki
‫veya dışındaki diğer şeylerin erişebilmesi
‫için tutarlı olan bir uç noktadır.
‫Kubernetes'te kapsüller oluşturduğunuzda,
‫IP adresli harici bağlantı için otomatik olarak bir
‫DNS adı almazlar.
‫Bunu, mevcut podun üzerinde bir hizmet oluşturarak
‫yapmak istersiniz.
‫Bir hizmet oluşturmak için bu expose komutunun yanı sıra
‫çeşitli yollar vardır.
‫Ortak olana odaklanalım.
‫Burada ortak olan şey çekirdek DNS'dir.
‫Hatırlarsanız, bundan daha önce kontrol düzleminizin temel özelliklerinden
‫biri olarak bahsetmiştik.
‫Bu hizmet, tüm bu şeylerin adlarını çözümlemek için DNS
‫sunucunuz olacaktır.
‫Bunun da ötesinde, IP ve
‫bağlantı noktasını seçmek ve bunu
‫nasıl yaptığı, trafiği esasen hizmetinize nasıl
‫ulaştırdığı dört farklı hizmet türünden birinin
‫işidir. Şimdi bunların üzerinden geçelim ve sonra bazı
‫örnekler üzerinden gideceğiz. Varsayılan hizmet türü olan
‫ClusterIP ile başlayalım.
‫Bu durumda en önemli husus, yalnızca kümede kullanılabilir
‫olmasıdır.
‫Bu aslında bir Kubernetes pod kümesinin başka
‫bir pod kümesiyle konuşmasıyla ilgilidir.
‫Bu, kendi DNS stresini alır, doğru.
‫Bu, çekirdek DNS kontrol düzlemindeki DNS
‫adresi olacaktır. Küme içindeki sanal IP
‫adresi alanında bir IP adresi alacaktır.
‫Bu, kümede çalışan diğer pod'larınızın hizmetin
‫bağlantı noktasını kullanarak bu hizmetle konuşmasına
‫olanak tanır. Bir Nginx uygulaması çalıştırıyorsanız
‫ve hizmeti oluşturduğunuzda 80 numaralı bağlantı noktasında çalışıyorsa, bu
‫hizmet IP'si de 80 numaralı bağlantı noktasında olabilir.
‫Bu da bir çeşit tutarlılık sağlıyor.
‫Düşünecek olursanız, bu Swarm'da bir hizmet oluştururken
‫izlediğiniz yola çok benziyor, şimdi hizmetler Swarm'da biraz
‫farklı. Etraflarında farklı
‫bir fikir var.
‫Ancak en azından bir hizmet oluşturduğunuzda tutarlıdırlar,
‫hatırlarsanız size yük dengeleyici üzerinde dahili
‫IP'yi verir. Uygulamanın açık olduğu bağlantı noktasında çalıştırır.
‫Bu durumda, çok benzer bir şey yapıyoruz, ancak bunu bir
‫expose komutu veya daha sonra bahsedeceğimiz diğer seçeneklerle
‫oluşturmamız gerekiyor.
‫Sıradaki NodePort ise biraz daha
‫farklıdır. Kutudan çıktığı haliyle biraz kafa karıştırıcı.
‫ClusterIP varsayılandır ve her zaman küme
‫içinde çalışır.
‫Özel bir şeye ihtiyacı yok. Trafiğin kendisine
‫ulaşması için kümenin dışında herhangi bir güvenlik duvarı
‫kuralına ihtiyaç duymaz. Ancak, ClusterIP yalnızca küme içinde iyidir.
‫Bunu unutma. ClusterIP, kümede iyi.
‫NodePort, küme dışındaki bir şeyin düğümlerdeki
‫IP adresleri aracılığıyla hizmetinizle
‫konuşması için tasarlanmıştır.
‫Bir NodePort oluşturduğunuzda, bu hizmete atanan
‫her düğümde yüksek bir bağlantı noktası elde
‫edersiniz.
‫Bunu aldıktan sonra, bu bağlantı noktası hakkında bilinmesi gereken diğer şeyleri
‫güncelleyebilirsiniz.
‫Bu liman yüksek bir liman olacak.
‫Örneğin, bu türü kullandığınızda 80 numaralı bağlantı noktasını
‫kullanmayacaksınız. Bu ikisinin anahtarı, herhangi bir Kubernetes
‫kümesinde her zaman kullanılabilir olmalarıdır.
‫İster bir bulut sağlayıcı çözümü kullanın, ister kendi Kubernetes'inizi
‫oluşturun ya da Docker Enterprise veya Rancher gibi paketlenmiş
‫bir çözüm kullanın.
‫Bunlar her zaman kullanıma hazır şekilde çalışacak olanlardır.
‫Sırada yük dengeleyici türü var.
‫Bu çoğunlukla bulutta kullanılır.
‫Buradaki fikir, Kubernetes komut satırı aracılığıyla harici
‫bir yük dengeleyiciyi kontrol ediyor olmanızdır ki bu oldukça
‫havalıdır.
‫Esasen, bu bir grup otomasyondur.
‫Burada yaptığınız şey, arka planda, bu yük dengeleyiciyi
‫oluşturduğunuzda, bunların kullanılabilir olması için
‫NodePort'ta otomatik olarak ClusterIP oluşturmak
‫olacaktır. Sonra harici sistemle
‫konuşacak. Belki bir AWS yük dengeleyicisi ya da başka
‫bir bulut sağlayıcısıdır. Temel olarak, bunlar altyapı
‫sağlayıcılarınızdan gelecek ve Kubernetes'in bazı uzak API'ler aracılığıyla
‫onlarla konuşmasına ve bunları sizin için yapılandırmasına izin
‫vereceklerdir. Dolayısıyla, bir AWS yük dengeleyicisi
‫söz konusu olduğunda, bunu oluşturduğunuzda, yalnızca
‫arka uçta bu NodePorts ve ClusterIP'leri oluşturmakla kalmaz,
‫aynı zamanda AWS yük dengeleyicisine NodePorts ile konuşmasını da
‫söyler.
‫Esasen bu sadece otomasyon, değil mi?
‫Bu, yük dengeleyiciyi sizin için otomatik olarak ayarlamak üzere AWS komut satırını
‫veya web arayüzünü çalıştırmak zorunda kalmaktan bir adım tasarruf
‫etmenize yardımcı olur.
‫Bunun için iki çıkarımım var: Bunu yalnızca
‫kümenize harici bir kaynaktan gelen trafik
‫için düşünmek.
‫Kubernetes'e uzaktan konuşma yeteneği veren
‫bir altyapı sağlayıcısı gerektirir.
‫Dört hizmet türünün sonuncusu ExternalName'dir.
‫Bu daha az kullanılır ve hizmetlerinize
‫gelen trafiği kontrol etmekle gerçekten
‫bir ilgisi yoktur.
‫Bu daha çok kümenizdeki şeylerin dış hizmetlerle konuşmaya ihtiyaç
‫duymasıyla ilgilidir.
‫Çekirdek DNS sisteminde DNS adları
‫oluşturmak istersiniz, böylece kümeniz harici olarak
‫kontrol etmediğiniz ExternalNames'i
‫çözümleyebilir. ExternalName'i kullanmanızın
‫nedenlerinden biri de bir şeylerin geçişini
‫yaparken kullanmanızdır. Uzak bir uygulamanız olup olmadığını düşünün.
‫Kubernetes kümenizin dışındaki bu uzak uygulamanın
‫muhtemelen zaten bir DNS adı vardır.
‫Bu harici hizmetlerden dahili hizmetlere bir şey taşıyacaksanız,
‫Kubernetes iş akışınızdaki DNS'yi kontrol etmek
‫için ExternalName'i nasıl kullanabileceğinize
‫bakabilirsiniz.
‫Temel
‫olarak, bir şey için harici DNS'yi değiştirmem gerekiyor, bu yüzden bu DNS hizmeti
‫için başka bir yardımcı program çalıştırmam gerekiyor demek yerine
‫Kubernetes'in tek bir komut satırına sahip olabilirsiniz.
‫Ya da belki de arkasında bir API bile
‫olmayan bir şey. Belki bir kurumsal DNS ya da
‫onun gibi bir şey. Bunu kümelerinizin içinde
‫kullanabilirsiniz, böylece kümelerinizin içindeki hizmetler
‫daha önce harici olanlardan farklı bir uç noktayı çözümlemeye
‫başlar. Bunu gerçekten sadece işimin
‫kümemden bazı harici hizmetlere nasıl
‫gittiğini değiştirmem gerektiğinde kullandığımı fark ettim,
‫ancak diğer şeylerin DNS'lerini uzaktan kontrol etmenin bir
‫yolu yok. Bu yüzden, bunu Kubernetes'in
‫içinde yapmayı ve eşyalarım için bazı ExternalNames oluşturmayı tercih ediyorum.
‫Ardından, Kubernetes'te kümemdeki öğelerim için dinamik
‫olarak değiştirmek istediğimde, bunu başka bir şeyle konuşmak zorunda kalmadan oldukça
‫kolay bir şekilde yapabilirim.
‫Tamam. Bu dört hizmet türünü
‫tamamlayacağız, ancak trafiğin kümenize girebileceği
‫başka bir yol daha var.
‫Bu Ingress aracılığıyla.
‫Bu konu hakkında daha sonra konuşacağız.
‫Bu özellikle HTTP trafiği için tasarlanmıştır.
‫Bu derse geldiğimizde, bunun neden bu hizmet türlerinden biraz daha
‫farklı olduğunu anlayacaksınız.