KUBENT: Kullanımdan kaldırılan API’ler Kube-No-Trouble buluyor

Selamlar dostlar. Bugün sizlere workfordreamseries on birinci sayısında sizlere kubernetes cluster’larımızda sorun yakalayan ve bunları bizlere raporlayan “kubent” hakkında bilgilerimi kaleme alıyorum.

Bir süredir kullanıma sunulan ve yönetilen birçok Kubernetes platformunda yavaş yavaş kullanıma sunulan Kubernetes 1.16 ile API’nin kullanımdan kaldırılmasını duymuş olabilirsiniz. Başa çıkması oldukça basit olsa da, bu değişiklik gözetimsiz bırakılırsa hizmetlerinizi ciddi şekilde kesintiye uğratabilir.

API’nin kullanımdan kaldırılması ?

Kubernetes özellik seti geliştikçe, bu değişikliği desteklemek için API’lerin de gelişmesi gerekir. Uyumluluğu ve kararlılığı garanti etmeyi amaçlayan yürürlükteki kurallar vardır. Kubernetes Kullanımdan Kaldırma Politikası belgesi, sistemin farklı bölümlerinin nasıl eski hale getirilebileceğini ve kaldırılabileceğini yönetir ve ayrıca bu her sürümde olmaz, ancak sonunda, eskisi kullanmayacağından yeni API sürümünü ve biçimini kullanmak zorunda kalacaksınız.

* Kubernetes Kullanımdan Kaldırma ( Deprecation Policy )İlkesi belgesi, sistemin farklı bölümlerinin nasıl geçersiz hale getirilebileceğini ve kaldırılabileceğini yönetir.

1.16 sürümü ile bu neden önemlidir?
Son birkaç K8 sürümünde kullanımdan kaldırılan birkaç API tutuldu ve sonunda Kubernetes 1.16 sürümünde tamamen kaldırıldı. Yani aşağıdaki API Grupları ve sürümleri:

• Dağıtım — uzantılar/v1beta1, uygulamalar/v1beta1 ve uygulamalar/v1beta2
• NetworkPolicy — uzantılar/v1beta1
• PodSecurityPolicy — uzantılar/v1beta1
• DaemonSet — uzantılar/v1beta1 ve uygulamalar/v1beta2
• StatefulSet — uygulamalar/v1beta1 ve uygulamalar/v1beta2
• ReplicaSet — uzantılar/v1beta1, uygulamalar/v1beta1 ve uygulamalar/v1beta2
• 1.16 ile bunlardan birini kullanarak bir kaynak oluşturmaya çalışırsanız, işlem başarısız olacaktır.

Etkilenip etkilenmediğim nasıl kontrol edilir?

Tüm bildirimlerinizi manuel olarak gözden geçirebilirsiniz, ancak bu oldukça zaman alıcı olabilir, bazılarını gözden kaçırmak kolaydır ve kümeye dağıtım yapan birden fazla ekibiniz varsa veya yalnızca mevcut tüm bildirimlere bir arada sahip değilseniz son derece pratik olmayabilir. yer. İşte burada Kube-No-Trouble namı diğer kubent yardıma gelir.

Amaç ne?

Belirli bir kaynağı oluşturmak için hangi API sürümünün kullanıldığına ilişkin bilgilere normalde erişilemez, çünkü kaynak her zaman dahili olarak tercih edilen depolama sürümüne dönüştürülür ve burada depolanır. Fakat. kaynaklarınızı dağıtmak için kubectl veya helm kullanıyorsanız, orijinal bildirim de kümenin içinde depolanır ve biz bundan faydalanabiliriz.

Kurulumun en basit yolu şudur:

sh -c "$(curl -sSL 'https://git.io/install-kubent')"

Bu, kubent’in en son sürümünü /usr/local/bin konumuna yükleyecektir.

kubent -h

Kubectl’in geçerli bağlamını, kontrol etmek istediğiniz kümeye işaret edecek şekilde yapılandırın ve kubent aracını çalıştırın:

kubent

Kubent, kümenize bağlanacak, etkilenebilecek tüm kaynakları alacak, etkilenenlerin özetini tarayacak ve yazdıracaktır.

CI/CD pipeline hattınıza entegre etmek veya sonuçları daha fazla işlemek istemeniz durumunda daha uygun olan JSON formatında çıktı almak için -f json formatını’da kullanabilirsiniz. Kullanılabilir yapılandırma seçenekleriyle ilgili daha fazla ayrıntı, doitintl/kube-no-trouble repo’nun BENİOKU’sunda açıklanmıştır.

Tespit edilen kaynaklarla ne yapmalıyım?

Bazı durumlarda manifest dosyanızdaki apiVersion’u değiştirmek kadar basittir, ancak diğerlerinde yapı değişmiş olabilir ve ayarlanması gerekebilir. Ayrıca, sürümler arasında birçok varsayılanın değiştiğini unutmayın. Bununla ilgili güzel bir makale, David Schweikert’in Kubernetes 1.16 API kullanımdan kaldırmaları ve değiştirilmiş varsayılanlarıdır, bu nedenle yalnızca apiVersion’u değiştirerek ve aynı bildirimi uygulayarak farklı sonuçlar elde edersiniz. Örneğin, StatefulSet’in updateStrategy.type’ı OnDelete’den RollingUpdate’e değişti ve çok farklı davranışlara yol açtı.

kubent

Daha önce kullanılan kubectl convert komutu artık kullanımdan kaldırılmıştır ve kaynaklarınızı daha önce belirtilen varsayılan değerlere göre doğru şekilde dönüştürmeyebilir.

Muhtemelen en iyi yol, kaynakları basitçe uygulamak (onları kubent ile tespit ettiyseniz zaten sahipsiniz) ve yeni sürümü API’den almaktır. Bu, kaynağın doğru bir şekilde yeni sürüme dönüştürülmesini sağlayacaktır. Kubectl’in hangi sürümü döndürdüğü konusunda biraz belirleyici olmadığını fark etmiş olabilirsiniz. Belirli bir API sürümü istemek için tam formu kullanın:

kubectl get ingress.v1beta1.extensions -o yaml

Feedback guys.!!

Umarım bu yazım, Kubernetes kümelerinizde kullanımdan kaldırılmış API’lerin kullanımını, bunlar size herhangi bir sorun çıkarmadan önce tespit edip bunlarla başa çıkmanıza yardımcı olur.

#workfordreamseries
Uğur Duran
Senior Devops Engineer
…

:)