‫Bu YAML'de muhtemelen örneklerde gördüğünüz ve etiketlerin
‫ve ek açıklamaların gerçekten ne için orada
‫olduğunu merak ederek düşündüğünüz iki meta veri parçası vardır.
‫Muhtemelen bunların önemini fark etmemişsinizdir.
‫Kubernetes'in ve işlerin birbirine bağlanmasının önemli
‫bir bileşenidir.
‫Swarm'dan çok daha fazla.
‫Bunlardan ilki etiketlerdir. Etiketler dosyanın kökündeki
‫meta veri anahtarının altına gider, bu nedenle orada isteğe
‫bağlıdırlar. Bunları koymak zorunda değilsiniz,
‫ancak etiketler başlığının altında bir anahtar değer veya anahtar değerlerin
‫bir listesidir.
‫Bunlar birçok nedenden dolayı oradalar.
‫Bunlar her zaman gerekli değildir, ancak nesneleri
‫seçmek, gruplamak ve hatta daha sonra filtrelemek
‫için bunlara ihtiyacınız olabilir.
‫Bu, nesneyi veya kaynağı tanımlayan herhangi
‫bir şey olabilir.
‫Değerin basitçe doğru veya yanlış olduğu bir anahtar değer
‫çifti olabilir.
‫Anahtarlar istediğiniz gibi olabilir.
‫Her nesnede birden fazla anahtar olamaz, bu nedenle
‫YAML'de aynı nesne için, diyelim ki app anahtar
‫adına sahip arka arkaya iki anahtarınız
‫olamaz, doğru. Bunlar gerçekten nesneyi tanımlamak
‫için kullanılır. Yarattığımız bu kaynakların
‫farklı özellikleri var.
‫Belki de prod, dev veya test gibi ortamlardır.
‫Belki de dmz, arka uç ya da ön uç gibi
‫bir konumdur. Belki uygulama adıdır, belki
‫de müşteri sitelerine ev sahipliği yapıyorsanız müşteri
‫adıdır. İstediğiniz her şey olabilir
‫ve çok fazla standart yoktur.
‫Buradaki kaynaklarda listelenen Kubernetes belgeleri size
‫bazı örnekler verir, ancak bunlar sadece örnektir.
‫Sektörde çok fazla standart yok.
‫Bu şeyi nasıl tanımlamak istediğiniz gerçekten
‫ekibinize ve şirketinize bağlıdır.
‫Ayrıca ek açıklamalarımız da var. Bir nevi yin ve yang gibiler.
‫Etiketler çok basittir.
‫Boyutları ve içlerine koyabileceğiniz karakterler
‫çok sınırlıdır. Bunlar kaynağı tanımlamak içindir.
‫Ek açıklamalarla, bu daha karmaşık veriler ve çok değerli
‫veriler, bunun gibi şeyler içindir.
‫Kubernetes'e Kubernetes ile konuşabilen ve ondan veri
‫alabilen özel şeyler eklediğinizde genellikle ek açıklamaların
‫kullanıldığını görürsünüz.
‫Ek açıklamalar belki de yapılandırma verilerini saklamak için
‫vardır, örneğin proxy'ler ve giriş öğeleri genellikle farklı yapılandırmaları
‫farklı ek açıklamaların içinde saklayabilir.
‫Yani bunlar illa ki tanımlama için
‫değil, daha çok yapılandırma için vardır.
‫Bir dakikalığına etiketlere geri dönelim, çünkü Kubernetes'te
‫tüm bu şeylerin nasıl çalıştığını anlamanın anahtarı olan çok daha
‫fazlası var.
‫İlk olarak, komut satırından etiketlere sınırlama getirerek
‫basit filtreler yapabiliriz.
‫Kapsülleri alıp bana sadece bu etikete sahip kapsülleri
‫göster diyebiliriz.
‫Birden fazla etiket eklemek için virgül bile kullanabilirsiniz.
‫Aslında, bu şey için farklı sözdizimi türleri, farklı veya'lar
‫ve ve'ler yapabileceğiniz bütün bir sözdizimi seviyesi
‫vardır.
‫Gerçekten, size tüm bunları öğretmek
‫istemediğim şeylerden biri çünkü Regex öğrenmek
‫gibi olacak. Sadece bir kez deneyerek gerçekten
‫öğrenemeyeceğiniz bir şey.
‫Bunu ancak ihtiyacınız olduğunda gerçekten
‫anlayacaksınız. Kubernetes'in dokümantasyonu
‫gerçekten harika. Kaynaklara eklediğim ve sizi
‫etiketlere ihtiyaç duyabileceğiniz tüm farklı yollara götürecek
‫çok sayıda bağlantı var.
‫Açıkçası, bir sorunu çözmek için buna ihtiyacınız olduğunu
‫bilene kadar bunu öğrenmenize gerçekten gerek yok.
‫Komutları uygulamak için bile kullanabilirsiniz.
‫Büyük bir YAML dosyasında bir sürü şey varsa ve bu
‫YAML dosyasının yalnızca belirli bölümlerini uygulamak istiyorsanız.
‫Bunu çok fazla yapmıyorum, ancak yalnızca
‫belirli etiketler için YAML'ye koyduğunuz değişiklikleri
‫veya bilgileri uygulamak için sınırlayabileceğiniz bir yer var.
‫Elbette, bununla da aynı sözdizimini kullanabilirsiniz.
‫Sadece tek bir etiketiniz olabilir.
‫Virgül koyabilir, orada birden fazla etiket ve değer bulundurabilirsiniz.
‫Sana kalmış.
‫Etiketlerin Kubernetes'in çalışması için önemli olan
‫bir başka özelliği daha vardır.
‫Diğer kaynaklarla konuşan, onlara bağlanan
‫ya da onlarla ilişkili olan belirli
‫kaynaklar vardır.
‫Nasıl söylemek istersen. Bunun iyi bir örneği, hizmetlerin
‫trafiklerini hangi podlara göndereceklerini bilmeleri
‫gerektiğidir. Nasıl bildiğini merak edebilirsiniz.
‫Yani, bunu yazdığınızda, bir kubectl hizmet Komutu yaparsanız
‫ve onu dağıtıma yönlendirirseniz, bu dağıtımı
‫tanımlamak için tam olarak ne kullanıyor?
‫CLI'da, bunun aslında dağıtım nesnesine işaret
‫ettiğini düşünürsünüz.
‫Ama aslında hizmetin dağıtımla değil podlarla konuşması
‫gerekiyor.
‫Etiket seçicileri denilen bir şey kullanıyor.
‫Bu, podların daha yüksek soyutlama seviyeleri olan
‫birçok farklı kaynakta yaygındır.
‫Bölmelerle ilişki kurmaları veya hangi bölmelerin kendilerine ait olduğunu bilmeleri
‫için etiket seçicileri kullanırlar. Bunu, son birkaç derste
‫kullandığınız depomuzun içindeki YAML'de
‫göreceksiniz.
‫Eğer uygulamaya bakarsan. yml'de, başından beri orada
‫bahsetmediğimiz birkaç şey olduğunu
‫fark edeceksiniz. Birincisi, hizmetin bulunduğu
‫üst kısımda, spesifikasyonun altında bir seçicimiz var.
‫Bu orada olmalı.
‫Trafiği yönlendirmesi gereken podlar için bir etiketin
‫anahtarını ve değerini söylüyoruz.
‫Bu sadece basit bir eşleşme.
‫Bununla kapsül bulması gerekiyor.
‫Daha sonra alttaki dağıtımda, spesifikasyonumuzun
‫kendi seçicisine, matchLabels, app, app-nginx'e
‫sahip olduğunu göreceksiniz.
‫Burada olan şey, bu nesnelerin her ikisinin de bu eşleşmeye
‫dayalı olarak kapsülleri seçmesidir.
‫Bu, pod'ları şablonlaştırdığımız spesifikasyonumuzun
‫altındaki şablonda, bu kaynakların pod'larını bulabilmesi
‫için bu etiketin olması gerektiği anlamına gelir.
‫Kubernetes'in sonraki sürümlerinde güzel olan
‫şey, en azından tek bir dağıtımla bunların senkronize
‫olması gerektiğidir. Aslında seçici eşleşme etiketlerinin
‫şablon meta veri etiketleriyle eşleşmediğini görürse dağıtımda
‫başarısız olur çünkü podları dağıtabilmesi ve kontrol
‫edebilmesi için eşleşmeleri gerekir.
‫Yanlışlıkla yanlış şekilde yapmanızı önlemek
‫için var. Bu parçaların orada olmasını
‫bekleyecektir. Eski sürümlerde, varsayılan olarak bunları
‫otomatik olarak oluşturmanın bir yolu vardı, böylece bu şeyleri dışarıda
‫bırakabilirdiniz. Artık bunu yapmayı bıraktılar ve sizi
‫bunu oraya koymaya zorluyorlar. Bunun iyi bir şey olduğunu
‫düşünüyorum, özellikle de bu etiket seçicilerin
‫ne kadar önemli olduğunu. Teknik olarak, Swarm'a geri dönerseniz,
‫Swarm, yığınlardan hizmetlere ve yığınlardan hacimlerine
‫ve bunun gibi şeylere eşleşen etiketlere sahip olduğu kutudan
‫çıkar çıkmaz bunu biraz yapar.
‫Onu gerçekten kontrol edemiyoruz ve arayüzde çok fazla
‫göremiyoruz. Swarm'da bu iş bizim için
‫arka planda hallediliyor.
‫Ama aynı zamanda çok sınırlayıcı.
‫Bir şeyleri anında değiştiremezsiniz.
‫Gerçekten benzersiz kurulumlar için gidip bunları özelleştiremezsiniz.
‫Burada, bu seçicileri değiştirmek istersek bir hizmetin
‫birden fazla dağıtımla konuşmasını
‫sağlayabiliriz.
‫Seçiciler sadece kaynakları birbirine bağlamakla ilgili değildir.
‫Bu aynı zamanda nereye gittiklerini kontrol etmekle de ilgilidir.
‫Düğümlerde, nereye gideceklerini kontrol etmek için etiketleri ve seçicileri
‫kullanabilirsiniz.
‫Kubernetes'in temelde pod'larınızın nereye gideceğini
‫kontrol edebilmesi için düğümlere belirli şeyleri
‫yapamayacaklarını söylediğiniz taints ve toleration adı
‫verilen şeylerle daha da fazla özelleştirme
‫kullanabilirsiniz.
‫Bu şeyler çok hızlı bir şekilde gerçekten özel ve gerçekten
‫gelişmiş hale geliyor. Hepsini bir arada yapmak biraz
‫kıllı ve çılgınca olabilir.
‫Onlarla kesinlikle ağırdan almanızı tavsiye ederim.
‫Her şeyi kullanıma hazır şekilde basit tutun.
‫Gerçekten incelemeniz gerekene kadar lekelerden ve toleranslardan
‫kaçının.
‫Tamam. Bu bölümün tamamını temizleyelim.
‫Kümeniz için varsayılan bir ad alanında çalışan herhangi bir şey varsa,
‫sadece bir kubectl get all yaparsanız ve orada Kubernetes API'sinin
‫kendisi dışında bir şeyler görürseniz, devam edin ve tüm bu kaynakları
‫silin çünkü devam edeceğiz.
‫Onlara ihtiyacımız olmayacak.