‫Size yeni bir konu olan kuru çalışma ve diferansiyelden
‫bahsedeyim.
‫Kubernetes'in 1 ile başlayan son birkaç sürümü. 13 değiştirmeden
‫önce neyi değiştireceğimizi görmemizi
‫sağlayan bu yeni seçeneğe sahiptir.
‫Bunu daha önce de gördük.
‫Kursun başlarında size birkaç örnek göstermiştim.
‫Ancak, apply komutuyla birlikte
‫kullanılan bu yöntem yeni ve daha
‫iyi. Geçmişte bir deneme
‫sürüşümüz vardı, ancak bu sadece müşteri
‫üzerindeydi. İstemci aslında sunucuyla konuşup
‫"hey, bu kaynaklar zaten orada mı?" diye sormuyor.
‫Bunları yeniden oluşturmam gerekiyor mu, yoksa güncellenecekler mi ya
‫da ne olacak? Doğru.
‫Bu daha önce olmamıştı.
‫Şimdi, YAML'ımızı sunucuya gönderecek ve karşılaştıracak,
‫gerçekte ne olması gerektiğini anlayacak ve ardından neyin değişeceğini
‫komut satırına geri bildirecek bir sunucu kuru çalıştırma
‫seçeneği var.
‫Bunu iş başında görelim.
‫Daha önce bir derste tartıştığım gibi K8s YAML dizinindeyim,
‫Docker Mastery'nin deposundaysanız ve bu dizine sahip değilseniz,
‫en son güncellemeleri almak için bir
‫git-pull yapmanız gerekir.
‫Bu, daha önceki bir derste gördüğümüz
‫bir dosyadır, app. yml. Bu, tek bir dosyada bir
‫hizmet ve bir dağıtımdır.
‫Teknik olarak iki kaynak tek bir apply komutuyla
‫oluşturulur ve bunlar ilişkilidir.
‫Hizmet, henüz bahsetmediğimiz bir
‫seçici kullanır. Seçiciler, bir nesnenin konuşmak
‫veya bir şeyler yapmak istediği kaynakları nasıl bulduğudur.
‫Bir hizmetin pod'larla konuşması gerekir, bu nedenle bunlara ulaşmanın
‫bir yolunu bulması gerekir.
‫Buradaki anahtarları ve değerleri etiketlerle
‫eşleştirmek için esasen desen eşleştirme olarak
‫seçicileri kullanır. Burada geleneksel bir deneme çalışması
‫yapsaydım, o zaman tek yapacağı şey müşterinin uygulamaya bakması ve evet,
‫bu nesneleri oluşturacağım demesi olurdu.
‫Tamam. Her zaman geri dönecek ve yaratıldığını söyleyecektir.
‫Bunun nedeni, uygulamanın çok spesifik
‫olmamasıdır. Eğer bir güncelleme, oluşturma
‫ya da silme komutu kullanıyorsanız, ki bunun DevOps
‫tabanlı bir iş akışı olduğunu düşünmüyorum.
‫Bu komutlar sadece kuru bir çalışma yapacak ve güncellemenin
‫evet, ikisi de güncellenecek diyeceğini
‫biliyorsunuz. Ancak, kümenizde gerçekten bilmiyor,
‫değil mi? Bunu anlamak için sunucuyla konuşmadı.
‫Varsayılan olarak 1. şeyde etkin olan sunucu kuru
‫çalışmasını denemek istiyoruz. 13 ve daha yeni.
‫Bunu yaptığımda, sunucu ile konuşacak ve bana uygun bir
‫yanıt verecektir.
‫Devam edelim ve bunu oluşturalım.
‫Sunucuyu kuru çalıştırmadan çıkaracağım.
‫Bu, dağıtım ve hizmet olmak üzere iki kaynak oluşturacaktır.
‫Şimdi, yukarı oka basıp sunucu kuru çalışmasına geri dönersem,
‫her ikisi için de değişmedi yazdığını göreceksiniz.
‫Bana neyin değiştiğini ya da değişecek bir
‫şey varsa bunun ne olacağını
‫söylemiyor. Bana sadece bir kaynağın değiştirileceğini
‫veya değiştirilmeyeceğini söylüyor. Bu bir çeşit geçiş, evet ya da hayır.
‫Sunucuya vermek istediğimiz ile kaynaklarımızın
‫mevcut durumu arasındaki gerçek farkı
‫almaya ne dersiniz?
‫Bu kubectl diff komutudur.
‫Uygulamak yerine sadece bir fark verirsem,
‫elimdeki YAML'yi şu anda çalışan sunuculardaki
‫özelliklerle karşılaştıracaktır.
‫bu
‫durum geri gelir ve bunun üzerinde bir fark yaratır. Hadi yapalım şunu.
‫Hiçbir şey söylemeyecektir çünkü hiçbir fark yoktur.
‫Peki ya YAML'yi değiştirirsek?
‫Çoğaltmaları iki olarak değiştirirsem ne olur?
‫Sonra meta verilere bir etiket ekliyorum ve ona şöyle bir
‫şey veriyorum... gibi bir şey.
‫Sunucular dmz.
‫Ben uydurdum. Gerçekten önemli değil.
‫O zaman elimizde iki kopya var.
‫Aynı farkı yaparsam, artılar ve eksilerle birlikte
‫geri gelir.
‫Eğer diferansiyel okumaya alışkınsanız, bu size
‫çok mantıklı gelecektir. Eğer diff'lere alışık değilseniz, eksi,
‫o çizginin kaybolacağı anlamına gelir.
‫Daha sonra bu satırlar eklenecektir.
‫Sonra burada, size hangi satırın ve satırdaki
‫hangi karakterin kaldırıldığını gösterir.
‫Bu ekleniyor.
‫YAML biçimlendirmesini koruyor, ki bu güzel bir şey.
‫Birden fazla değişikliğin gerçekleştiğini bize bildiriyor.
‫Harika. Tabii ki, bu gerçekten bir kanarya
‫ya da test dağıtımı gibi bir şey yapmıyor.
‫Bir şeyi yapmaya çalışmak ve sonra sonucun ne olduğunu
‫görmek değildir. Gerçekten de sadece kayıtlardaki
‫spesifikasyonlara ve bizim diskimizdeki spesifikasyonlara
‫bakıyor. Bu konuda daha fazla
‫bilgi için kaynak bağlantılarına göz atın.
‫Bu, Kubernetes ekibinin bunların geleceği ve beta
‫sürümünden çıktıklarında nasıl oynayacakları hakkında
‫bir blog makalesi. Unutmayın, bu özellikler şu anda beta aşamasındadır,
‫en azından 1. sürümde. 15 taneler.
‫Umarım bununla, sıfırdan YAML'ler oluşturmak, bu YAML'lerdeki
‫özellikleri yönetmek ve ardından değişikliklerinizi
‫yapmak için tekrar tekrar apply komutunu kullanmak için kendi iş akışınızı
‫oluşturabilirsiniz.
‫Bu çok daha DevOps dostu bir kod olarak
‫altyapı türüdür.
‫Yaptığınız her şey belgelenir, umarım Git'te.
‫Yani, sunucuya dağıtmadan önce YAML'nizde yaptığınız her değişiklik
‫için bir git-commit yapacağınızı umuyorsunuz.
‫Daha sonra Git'te güzel bir dokümantasyonun yanı sıra, gerçekte
‫neyin çalıştığını görmek için bir fark gibi bir şey yaptığınızda
‫dokümantasyona sahip olursunuz.