‫Eğer son dersten doğrudan bu derse gelmediyseniz,
‫bir önceki derse geri dönerek uygun Dağıtımın çalıştığından
‫emin olun, böylece birazdan göreceğimiz günlüklere
‫sahip olacaksınız.
‫Arka planda çalışan bir Apache Deployment'ımız
‫var ve replikaları ikiye ölçeklendirdiğimiz için
‫iki pod'a sahip. Bir kubectl get pods işlemi yapabilmeli
‫ve sonuçları görebilmeliyiz.
‫Elbette sizin pod isimleriniz benimkinden biraz
‫farklı olacak çünkü sonlarında sayılar ve rastgele karakterler
‫olacak. Bunu yazarken, son iki
‫blokta Dağıtımınızın gösterdiğine göre
‫farklı bir şey yazacağınızın farkında olun.
‫Swarm'da ve Docker'ın kendisinde olduğu gibi
‫birkaç komut vardır. Bu durumda, bir konteynerde neler olup
‫bittiğini ve orkestratörün konteynerlerle neler yaptığını
‫anlamak için farklı komutlardır.
‫Birincisi kütükler.
‫İkincisi ise tarif.
‫Kubernetes'te teknik olarak bir inspect komutumuz yok, ancak describe
‫bundan çok daha fazlasını yapıyor.
‫İlk olarak, bir günlük komutu deneyelim.
‫Sizin çıktınız benimkinden biraz farklı olabilir.
‫Günlük dağıtımını yazdıktan sonraki ilk satırın /my-apache
‫olduğunu fark edeceksiniz.
‫İki pod bulduğunu ve bir pod adı kullandığını söylüyor,
‫orada belirli bir pod adı verdi.
‫Bunun nedeni, varsayılan log komutunun
‫Docker veya Swarm komutlarında olduğu
‫gibi tüm farklı podları çekip bir araya
‫getirmemesidir. Sadece varsayılan olarak bunlardan birini çekecektir.
‫Bu kursta alışık olduğunuz diğer
‫log komutları gibi --follow, --tail gibi birçok seçenek vardır.
‫Bunlar herhangi bir Linux sisteminde günlük komutları için
‫ortak şeylerdir.
‫Aynı komutu -- sadece takip et ile yaparsak, bu podun günlüklerinde
‫yeni bir şey görünmesini bekleyecektir.
‫O
‫zaman --tail, 1 sadece son satırı döndür anlamına gelir.
‫Bu şekilde günlüklerin büyük bir dökümünü almazsınız.
‫Bunun dışında C'yi kontrol edebilirsiniz.
‫Peki ya birden fazla pod için günlükleri bir arada görmek
‫isterseniz?
‫Bunu kesinlikle yapabilirsiniz. Bu sadece varsayılan logs
‫komutu değildir. Bu durumda, Kubernetes'te Seçici
‫adı verilen bir şey kullanmamız gerekecek; bu, hepsinin paylaştığı bir etikete
‫dayalı olarak birden fazla kapsülü almak için
‫bir tekniktir.
‫Burada güzel olan şey, kubectl run komutunu
‫kullandığınızda, tüm bu podlara otomatik olarak
‫Deployment adında bir etiket eklemesidir.
‫Böylece, bu etikete sahip tüm podları seçmek için aynı Deployment
‫adını Apache'mde kullanabiliriz.
‫Bunun sadece basit bir etiket eşleştirmesi
‫olduğunu unutmayın. Dolayısıyla, bu etikete sahip
‫olan başka Dağıtımlarınız veya bölmeleriniz varsa, onlar
‫da buna yakalanacaktır. Dolayısıyla, etiketleme ve isimlendirme konusunda
‫dikkatli olmalısınız.
‫Burada etiketi belirtmek
‫için -l kullanıyoruz ve çalıştır komutunun
‫uyguladığı etiketi belirtiyoruz, ki bu benim Apache'mdi.
‫Tıpkı Swarm ve Docker'ın kendisi gibi, bu günlük komutları
‫da hızlı sorun giderme için çok kullanışlı olabilir, ancak
‫tam bir günlük sisteminin yerini tutmaz.
‫Kubernetes'te, varsayılan olarak, günlüklerde
‫seçici çekme türünü kullandığında bir
‫seferde en fazla beş pod çekebilir.
‫Bunu her zaman artırabilirsiniz, ancak gerçek şu ki,
‫bu günlük dosyalarını tüm farklı düğümlerden çekmek
‫sistemi zorluyor.
‫Üretimde, tüm bu günlükleri toplayacak ve daha hızlı erişim için
‫zaman içinde depolayacak bir üçüncü taraf günlük kaydı
‫sistemi isteyeceksiniz.
‫Bu durum Docker, Swarm ya da Kubernetes gibi tüm konteyner
‫düzenleme sistemleri için geçerlidir.
‫Buradaki bir sonraki komut, komutu tanımlamak olacaktır.
‫Bu durumda describe komutu podun kendisini belirtmek
‫istediğimiz yerdir.
‫Çok spesifik bir kapsül elde etmek istiyoruz, ancak önce bu kapsüllerin
‫adlarını bilmemiz gerekiyor.
‫Önce kapsülleri alalım.
‫Daha sonra bu isimlerden birini kopyalayıp bir tarif komutuna yapıştırabiliriz.
‫Önce pod yazın.
‫O kapsülü geri getireceğim.
‫Tek bir kapsül belirtmek zorunda değilim.
‫Kapsül diyebilirdim ve tüm kapsülleri gösterirdi, bu da çok sayıda
‫kapsülünüz varsa biraz tehlikeli olabilir.
‫Kesinlikle diğer kaynakları tanımlayabilir ve nesneye bağlı olarak
‫çeşitli türde sonuçlar alabilirsiniz.
‫Burada vurgulamak istediğim şey, bunun Swarm'daki
‫veya Docker'ın kendisindeki inspect komutuna benzeyeceğiydi.
‫Ancak,
‫JSON yerine ekranda biraz daha güzel bir görüntü sağlar.
‫Sonuçları aşağı kaydırdığınızda, sadece farklı nesne hakkında
‫bir açıklama olmadığını, aynı zamanda alt kısımdaki olaylar
‫gibi şeyleri de çektiğini fark edeceksiniz;
‫bu, o nesnenin mevcut gerçekliği hakkında hızlı bir durum elde
‫etmenin harika bir yoludur.
‫Dolayısıyla, bir podun görüntü çekmesiyle ilgili bir
‫sorun yaşamanız durumunda, burada görüntü çekilemiyor
‫yazan bir olay görürsünüz.
‫Bu, yanlışlıkla bir resim adını veya bunun gibi bir şeyi yanlış yazdığınızda
‫yaygın olarak kullanılan bir yöntemdir.
‫Bu, bazı olayları veya hata ayıklama günlüklerini açmak zorunda kalmadan
‫hızlı bir sorun giderme tekniği için oldukça kullanışlı
‫olabilir.
‫Tamam. Bu son kısımda, Kubernetes'in
‫Swarm'a benzer şekilde nasıl esnek olduğunu göstereceğim; burada
‫alt soyutlama düzeylerinden birini silerseniz, bu durumda bir
‫pod'u silerseniz, daha üst düzey soyutlama, Dağıtım ve
‫Çoğaltma Seti, o pod'un yeniden oluşturulmasını
‫sağlayacaktır.
‫Bu, Swarm'daki bir konteyner veya görevi sildiğinizde hizmet
‫tarafından yeniden oluşturulmasına benzer.
‫Bunu iki farklı pencerede yapacağız.
‫İlk pencerede -w ile birlikte bir get kullanacağız.
‫Bu bize saat komutuna benzer bir deneyim
‫sunacak. Eğer beni bu derste herhangi bir Linux
‫komutunu izlemek için watch komutunu kullanırken gördüyseniz,
‫bu aslında o şeyi arka planda çalıştırmak anlamına gelir
‫ve bunu Linux'ta yapabilirsiniz.
‫Ancak, bu izleme komutu tüm işletim sistemlerinde
‫her zaman mevcut değildir. Burada, bir kubectl get pods
‫yapabiliriz, ancak orada oturmasına ve birkaç saniyede
‫bir yenilenmesine izin verecek
‫bir -w ekleyebiliriz.
‫Şimdi, farklı bir terminale
‫gidebiliriz. O bölmelerden birini sileceğiz.
‫Birincisi. adını kopyalamamız ve bir
‫kubectl pod / pod'un adını
‫kullanmamız gerekecek.
‫Silindiğini fark edeceksiniz.
‫Daha sonra değişen şeylerin en üstünde bu çalışan
‫günlüğü alacağız.
‫Ayrıca bunu izle komutundan biraz daha fazla
‫seviyorum çünkü izle komutu ekranı yenilerken bu, değişikliklerin
‫devam eden bir yinelemesini gösteriyor ki bu oldukça güzel.
‫En
‫altta, başka bir kubectl get pods yaparsak, ikiye geri döndüğümüzü
‫göreceksiniz.
‫Yine, bu bir tür orkestratörün kendini iyileştirme
‫yönüdür. Bu, bir taneye sahip olmanın ana amaçlarından biri.
‫Son olarak, burada geçmişte Docker a Swarm'da
‫bazı zararlı şeyler yapmaktan korunmuş olabileceğiniz bir şeye
‫dikkat çekmek istiyorum; bir şeyi değiştirmeye veya silmemeniz gereken
‫bir şeyi silmeye çalıştığınızda, sizi
‫önceden uyarabilir.
‫Kubernetes, onu nasıl kullandığınız konusunda biraz daha az fikir sahibi
‫olduğu diğer tarafa düşme eğilimindedir.
‫Bu da bazen yapmamanız gereken şeyleri yapabileceğiniz
‫anlamına gelir; örneğin daha önce verdiğim, üstündeki Dağıtımı
‫değiştirmek yerine bir ReplicaSet'i değiştirme örneğinde olduğu
‫gibi.
‫Aynı şey, gerçekten bunu yapmamanız gerekirken bir kapsülü değiştirmek için de geçerli
‫olabilir. Üstündeki nesneyi değiştirmelisiniz.
‫Bu, yanlışlıkla yanlış şeyi yanlış sırada silmemek, değiştirmemek
‫veya modifiye etmemek için ne yaptığınızın
‫ayrıntılarını anlamanız gerektiğini vurgular.
‫Bu dersten temizlenmek için bir kubectl delete deployment
‫my-apache yapmayı unutmayın.