‫İlk kümeniz için, hatta belki de ilk birkaç kümeniz için,
‫bu ad alanları ve bağlamlar kavramı hakkında çok fazla
‫endişelenmeniz gerekmeyecektir.
‫Ancak, kullanmanız gerektiğinde varlığından
‫haberdar olmanız gereken bir şeydir.
‫Ad alanları aslında tek bir küme içindeki sanal kümeler
‫veya sanal görünümlerdir.
‫Komutları yazarken yalnızca belirli şeyleri görmeniz için yalnızca
‫komut görünümünü filtrelemekle kalmaz,
‫aynı zamanda doğru ağ ilkesi eklentileriyle ağ bağlantısını
‫da kontrol edebilir.
‫Bu, Swarm'dan biraz farklıdır; Swarm'da, kullanıma
‫hazır olarak, farklı kaplama ağları oluşturabilirdiniz
‫ve her şey esasen özeldi.
‫Kubernetes'te ağ oluşturma ve uygulamaların kontrolü, gizlilikleri,
‫neleri görebilecekleri ve nelere erişebilecekleri ve orada
‫fiziksel olarak nelerin kontrol edildiği gerçekten ağ eklentinize
‫bağlıdır.
‫Ad alanlarının kendisi, duymuş olabileceğiniz Docker
‫ad alanlarıyla ilgili değildir, bu gerçekten Linux
‫alt sisteminin bir parçasıdır ve konteynerler bu
‫şekilde çalışır. Bunun onunla bir ilgisi yok.
‫Bu basitçe Kubernetes'in şunu söylemesidir: hey, kümenizde
‫bir sürü şey olabilir ve ben size ad alanını bir bağlamla
‫ayarlayacağınız küçük mini kümeler yapma fırsatı
‫veriyorum ve bu da bağlamınızı değiştirerek
‫görünümünüzdür.
‫Gördüklerinizi değiştirebilirsiniz.
‫Daha sonra ad alanı, komutları filtrelemek
‫ve potansiyel olarak ağ oluşturmak için farklı
‫segmentlerdir. Buradaki sistemimde, masaüstümde,
‫kubectl get namespaces komutunu görüyorum ve bu komut bana
‫4 tane gösteriyor. Göreceğiniz standart
‫bu şekilde olacaktır.
‫Varsayılan, şu ana kadar çalıştığınız şeydir.
‫Bu, uygulamalarınızın varsayılan ad alanı için
‫yapılmıştır. Bir kubectl get all yaptığınızda
‫size gerçekten gösterdiği tek şey
‫Kubernetes API uç noktasının kendisidir, değil mi?
‫Uygulama eklemeye başlayana kadar, orada gerçekten
‫bir şey görmedik. Teknik olarak arka planda
‫çalışan bir sürü şey var, değil mi? Kubectl get all --all isim alanlarının
‫yaptığı şey budur.
‫Bu komutla Kubernetes'in içinde çalışan
‫tüm API kapsayıcılarını ve diğer şeyleri
‫görebilirsiniz. Tüm ad alanlarına aynı anda bakarsam, sistem
‫öğeleri de dahil olmak üzere her şeyi alırım.
‫Bu, kümenin kendisini çalıştırmak için her şeyi
‫kendi pod'larına koyan minikube'de nasıl görüneceğine dair
‫bir görünümdür.
‫Orada çok şey oluyor.
‫Normalde Kubernetes kullanırken komut satırının
‫varsayılan olarak varsayılan ad alanına odaklandığını
‫fark edersiniz.
‫API uç noktası dışında orada yalnızca uygulamalarınızı
‫göreceksiniz.
‫Bu iyi bir şey, değil mi? Arka planda olup bitenlerin
‫karmaşıklığını günlük komutlarınızdan gizler,
‫çünkü yükseltmeniz veya değiştirmeniz gerekmedikçe
‫ya da bir sorun yaşamadıkça bu şeyleri görmeniz gerekmez.
‫Bağlam,
‫komutları çalıştırırken görünümünüzü ayarlamak için devreye girer.
‫Kubectl pek çok şey yapar, doğru.
‫Farklı kümelere bağlanabilir.
‫Kümeyle konuşmak için kullandığınız kimlik doğrulamasını
‫veya kullanıcıyı değiştirebilir, ki bundan bahsetmedik
‫ya da ad alanını.
‫Yani, bir bağlamın gerçekten de bu üç parçası vardır.
‫Yani küme, kimlik doğrulama veya kullanıcı ve ardından
‫görmek istediğiniz ad alanı.
‫Tüm bunlar varsayılan
‫olarak . ev dizininizin kube
‫dizini.
‫Orada config adında bir dosya var ve temelde
‫bu parçaların üçünden oluşan bir YAML dosyası olacak.
‫Burada birden fazla giriş yapabilir ve istediğiniz gibi
‫düzenleyebilirsiniz.
‫Bir sürü farklı kümeniz olabilir ve onlarla konuşmak için sertifikalarınız
‫olduğu sürece, doğru kimlik doğrulama, tüm bu şeyleri o dosyaya koyabilirsiniz
‫ve bu gizli tutmak istediğiniz bir şeydir.
‫Bu
‫gerçekten paylaşmak isteyeceğiniz bir şey değildir çünkü genellikle
‫bir kümeyle konuşmak için kimlik doğrulama anahtarlarınızı
‫içerir. Eğer kubectl config
‫komutunu get contexts alt komutu ile kullanırsanız, bu çoğuldur,
‫temel olarak bu dosyanın çıktısını
‫görebilirsiniz. Ham olarak boşaltmak yerine,
‫içinde ne olduğuna dair küçük ve güzel
‫bir liste görebilirsiniz.
‫Benim durumumda, yerel makinemde standart Docker
‫Masaüstüm var. Docker Desktop'ın son birkaç sürümünde
‫bu giriş iki kez yer alıyor çünkü adını değiştirdiler, bu yüzden uyumluluk
‫için her ikisini de orada tutuyorlar.
‫Sonra yerel bir minikube ve bir Ubuntu
‫sunucusunda çalışan uzak bir micro K8s
‫örneğim var.
‫Dolayısıyla, çok sayıda başka sunucuyu yönetiyor
‫olsaydım, bu makinelere her zaman ssh ile girmek istemeyeceğimi
‫tahmin edebilirsiniz. Gerçekten sadece yerel makinemde oturmak ve uzaktaki
‫API ile konuşmak istiyorum.
‫Kubectl config komutunu ayarlanan seçeneklerden herhangi biriyle
‫kullanabilirsiniz. Oradaki yardımı kesinlikle
‫kontrol etmek istersiniz. Ancak, bunların her biri için varsayılanları ayarlamak
‫için ayar seçenekleri vardır, bu nedenle kullanıcıyı farklı bir kimlik
‫doğrulamasına sahip olacak şekilde değiştirebilirsiniz.
‫Yani,
‫belki de Kubernetes'in çalıştırabileceği komutların sadece bir alt kümesi yerine Tanrı
‫haklarına sahipsiniz. Ya da belki de konuştuğunuz kümeyi
‫değiştireceksiniz.
‫Google'a bakarsanız, kabuğunuzda hangi bağlamı
‫kullandığınızı görmenizi sağlayan
‫komut satırı eklentileri bile vardır.
‫Bu, bir sürü farklı kümeyi yönetmek zorunda kaldığınızda oldukça
‫kullanışlıdır. Bilmek istiyorsun, hey şu
‫anda hangisiyle konuşuyorum? Aslında bunu ayarlayabilirsiniz,
‫tıpkı get komutlarının size hangi şubede olduğunuzu söylemesi
‫gibi. Bunlar, isteminizde hangi bağlama sahip
‫olduğunuzu size söyleyecektir.