Kubernetes üzerinde çalışan Apinizer imajlarının sürüm yükseltme işlemlerini gerçekleştirebilir. Çevrim içi ve çevrim dışı güncelleme yöntemlerini destekler, MongoDB yedekleme işlemlerini yönetebilir ve güncelleme işlemlerini geri alabilir.
Apinizer sürüm yükseltme işlemi, Kubernetes worker sunucularının internete erişim durumuna göre iki farklı yöntemle gerçekleştirilebilir:
Çevrim İçi Güncelleme
Kubernetes cluster’ının internet erişimine sahip olduğu durumlarda kullanılır. Docker imajları doğrudan Docker Hub’dan çekilir ve otomatik olarak güncellenir. Daha hızlı ve kolay bir güncelleme süreci sağlar.Ne Zaman Kullanılır:
İmaj transferi için ekstra adımlar atmak istemiyorsanız
Çevrim Dışı Güncelleme
Kubernetes cluster’ının internet erişimine sahip olmadığı veya güvenlik politikaları nedeniyle doğrudan internet erişiminin kısıtlandığı durumlarda kullanılır. İmajlar önce internete erişimi olan bir sunucuda çekilir, .tar dosyası olarak kaydedilir veya yerel bir registry’ye yüklenir.Ne Zaman Kullanılır:
Güvenlik politikaları nedeniyle doğrudan internet erişimi kısıtlanmışsa
Yerel bir Docker registry (Nexus, Harbor vb.) kullanılıyorsa
Yöntemler:
Manuel İmaj Transferi
Yerel Registry Kullanımı
Güncelleme ile direkt bir ilgisi olmasa da her zaman MongoDB veritabanındaki Apinizer’ın kullandığı veritabanının yedeklenmesi, olası bir rollback durumu için önerilmektedir.
Güncelleme işleminden önce, mevcut sistem yapılandırmasıyla uyumsuzluk oluşturabilecek değişiklikleri tespit etmek ve gerekli önlemleri almak adına Sürüm Notlarının incelenmesi tavsiye edilir.
Sistem, temel olarak apimanager (2025.11.0 ve öncesi sürümlerde manager), worker ve cache uygulamalarından oluşur. Lisans kapsamına bağlı olarak integration ve apiportal (2025.04.5 ve öncesi sürümlerde portal) uygulamaları da bulunabilir.Güncel sürüm bilgilerine Docker Hub adresinden veya sürüm notları sayfasından erişilebilir.
Güncelleme sırasında trafik kesintisi riski; pod sayısı, güncelleme stratejisi ve sunucu kaynaklarının uygunluğu gibi faktörlere bağlı olarak değişkenlik gösterebilir.
Replica/Pod Sayısı
Güncellenecek uygulama yalnızca 1 pod üzerinde çalışıyorsa kısa süreli kesinti yaşanabilir. Api Manager bileşeninin 1 pod ile çalışması önerilir.
Güncelleme Stratejisi
Kurulum sırasında özel bir strateji belirtilmediği sürece, güncellemeler RollingUpdate yöntemiyle ve en az bir pod aktif kalacak şekilde gerçekleştirilir. Api Manager ve Cache bileşenlerinde Recreate stratejisi de tercih edilebilir.
Sunucu Kaynakları
Kubernetes worker sunucu sayısının az olduğu ve mevcut kaynakların sınırda kullanıldığı ortamlarda, güncelleme sırasında manuel müdahale gerekebilir ve trafik akışında kesinti yaşanması muhtemeldir.
İlgili sunucularda internet erişimi varsa 2.1 Çevrim İçi Güncelleme, yoksa 2.2 Çevrim Dışı Güncelleme bölümünden devam ediniz.
Apinizer’ın diğer bileşenlerini güncellemeden önce Apinizer Api Manager’ın güncellenmesi gerekmektedir.Api Manager’ın veritabanına yapacağı güncellemelerden sonra diğer Apinizer uygulamalarının güncel ayarlarla veritabanından beslenmesi gerekmektedir.Bu nedenle, Api Manager güncellendikten sonra Kubernetes üzerindeki Api Manager podlarının “ready” durumuna geldiğinden emin olunmalı ve ardından diğer bileşenler güncellenmelidir.
Bu ve sonraki adımlardaki komutlar, Kubernetes Control Plane görevine sahip sunucular üzerinde çalıştırılır.
1
Deployment bilgilerini kontrol edin
Kopyala
kubectl get deployments -Ao wide
2
Api Manager deployment imajını güncelleyin
Kopyala
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=apinizercloud/apimanager:<NEW_VERSION>
3
Pod durumunu takip edin
Pod’un READY olması beklenir, pod durumu ve logları takip edilir:
Kopyala
kubectl get pods -n <MANAGER_NAMESPACE>kubectl get logs -f -n <MANAGER_NAMESPACE> <POD_NAME>
2.2.2) Yerel İmaj Registry ya da Repository Kullanımı
Farklı imaj registry ve repository’leri farklı yöntemlerle çalışsa da çoğunda çekilen imajlar tag’lenerek uygulamaya gönderilmelidir.
Eğer uygulama reverse proxy şeklinde kullanılıyorsa hub.docker.com adresindeki apinizercloud reposuna yönelik gerekli tanımın verilmesi yeterli olmaktadır.
# Gerekli tüm imajlar çekilirdocker pull apinizercloud/apimanager:<NEW_VERSION>docker pull apinizercloud/worker:<NEW_VERSION>docker pull apinizercloud/cache:<NEW_VERSION>docker pull apinizercloud/apiportal:<NEW_VERSION>docker pull apinizercloud/integration:<NEW_VERSION># Çekilen imajlar, gerekli tag bilgileri ile yeniden etiketlenirdocker tag apinizercloud/apimanager:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>docker tag apinizercloud/worker:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>docker tag apinizercloud/cache:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>docker tag apinizercloud/apiportal:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>docker tag apinizercloud/integration:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION># Kurumun yerel imaj registry'sine imajlar aktarılır:docker push <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>docker push <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>docker push <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>docker push <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>docker push <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>
# Gerekli tüm imajlar çekilirctr image pull docker.io/apinizercloud/apimanager:<NEW_VERSION>ctr image pull docker.io/apinizercloud/worker:<NEW_VERSION>ctr image pull docker.io/apinizercloud/cache:<NEW_VERSION>ctr image pull docker.io/apinizercloud/apiportal:<NEW_VERSION>ctr image pull docker.io/apinizercloud/integration:<NEW_VERSION># Çekilen imajlar, gerekli tag bilgileri ile yeniden etiketlenirctr image tag docker.io/apinizercloud/apimanager:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>ctr image tag docker.io/apinizercloud/worker:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>ctr image tag docker.io/apinizercloud/cache:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>ctr image tag docker.io/apinizercloud/apiportal:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>ctr image tag docker.io/apinizercloud/integration:<NEW_VERSION> <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION># Kurumun yerel imaj registry'sine imajlar aktarılır:ctr images push <YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>ctr images push <YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>ctr images push <YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>ctr images push <YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>ctr images push <YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>
Apinizer’ın diğer bileşenlerini güncellemeden önce Apinizer Api Manager’ın güncellenmesi gerekmektedir.Api Manager’ın veritabanına yapacağı güncellemelerden sonra diğer Apinizer uygulamalarının güncel ayarlarla veritabanından beslenmesi gerekmektedir.Bu nedenle, Api Manager güncellendikten sonra Kubernetes üzerindeki Api Manager podlarının “ready” durumuna geldiğinden emin olunmalı ve ardından diğer bileşenler güncellenmelidir.
Bu ve sonraki adımlardaki komutlar, Kubernetes Control Plane görevine sahip sunucular üzerinde çalıştırılır.
1
Deployment bilgilerini kontrol edin
Kopyala
kubectl get deployments -Ao wide
2
Api Manager deployment imajını güncelleyin
Kopyala
kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/apimanager:<NEW_VERSION>
3
Pod durumunu takip edin
Pod’un READY olması beklenir, pod durumu takip edilir:
Kopyala
kubectl get pods -n <MANAGER_NAMESPACE>kubectl logs -f -n <MANAGER_NAMESPACE> <POD_NAME>
3) Apinizer Uygulama Güncellemelerinin Geri Alınması
Apinizer uygulamalarında sürüm düşürülmesi desteklenmemektedir. Ancak güncellenen bir sürüm veritabanı yedekleri varsa geri alınabilir.
Herhangi bir sebep ile güncellemelerin geri alınması gerektiğinde yapılması gereken ilk iş güncelleme öncesi MongoDB yedeğinin alınmış olduğunu kontrol etmektir. Güncelleme öncesi alınmış bir veritabanı yedeği yoksa Api Manager uygulamasının veritabanında yapacağı değişiklikleri geri almanın bir yolu olmadığı için veritabanı sunucularının sistemsel bir yedeği varsa mevcut son yedeğe dönülerek o tarihteki sürüme geri dönülebilir.Bu işlem o tarihten itibaren yapılan değişikliklerin kaybına yol açacağı için dikkatle yapılmalıdır. Güncelleme ile yapısal farklılıklar oluşabileceğinden bu işlem sadece referans olarak kullanılmak için düşünülebilir.
Bu işlemin öncesinde Api Manager uygulamasının kubernetes üzerinde CrashLoopBackOff hatası ile yeniden başlatılma döngüsünde olmadığı teyit edilmelidir. En güvenli yöntem için Api Manager uygulaması replica sayısı 0’a indirilerek durdurulmalıdır.
1
Api Manager'ı durdurun
Api Manager replica sayısı 0’a çekilir ve tüm pod’lar kapatılır:
MongoDB mevcut son yedeğe dönülmelidir. Dönüş sırasında olası çakışmaları engellemek için --drop parametresi kullanılabilir. Bu sadece yedek dosyasında karşılığı olan koleksiyonları drop edecek ve yüklemeyi sonrasında gerçekleştirmeyi sağlayacaktır.