Apinizer Sürüm Yükseltme

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.

​

Güncelleme Yöntemleri

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:

• Kubernetes worker sunucuları internete erişebiliyorsa
• Hızlı ve kolay güncelleme yapmak istiyorsanız
• İ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:

• Kubernetes worker sunucuları internete erişemiyorsa
• 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.

​

1) MongoDB Yedeğinin Alınması

Güncelleme işleminden önce veri kaybını önlemek için MongoDB yedeği alınır. Bu komut MongoDB sunucusu üzerinde çalıştırılır.

mongodump

sudo mongodump \
  --host <PRIMARY_MONGODB_IP_ADDRESS> \
  --port=25080 \
  --username=apinizer \
  --password=<PASSWORD> \
  --authenticationDatabase=admin \
  --gzip \
  --archive=<BACKUP_DIRECTORY>/apinizer-backup--<CURRENT_VERSION>--<BACKUP_DATE>--01.archive

--host · string · gerekli

Primary MongoDB sunucusunun IP adresi

--port · number · varsayılan: "25080"

MongoDB port numarası

--username · string · gerekli

MongoDB kullanıcı adı

--password · string · gerekli

MongoDB şifresi

--authenticationDatabase · string · varsayılan: "admin"

Kimlik doğrulama veritabanı

--gzip · boolean

Yedek dosyasını sıkıştırır

--archive · string · gerekli

Yedek dosyasının kaydedileceği yol ve dosya adı

Yedekleme ile ilgili detaylı bilgi için Yedekleme sayfasına bakabilirsiniz.

​

2) Apinizer Uygulamalarının Güncellenmesi

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 Stratejisi ve Kesinti Riski

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.

​

2.1) Apinizer’ın Çevrimiçi Güncellenmesi

​

2.1.1) Apinizer Api Manager Güncellenmesi

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

   kubectl get deployments -Ao wide
   
2. Api Manager deployment imajını güncelleyin

   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:

   kubectl get pods -n <MANAGER_NAMESPACE>
   kubectl get logs -f -n <MANAGER_NAMESPACE> <POD_NAME>
   

​

2.1.2) Apinizer Worker ve Cache Güncellenmesi

Apinizer Api Manager imajının güncellendiğinden emin olduktan sonra Apinizer Worker ve Cache uygulamaları güncellenir.

1. Worker ve Cache deployment imajlarını güncelleyin

   kubectl set image deployment/<WORKER_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <WORKER_CONTAINER_NAME>=apinizercloud/worker:<NEW_VERSION>
   kubectl set image deployment/<CACHE_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <CACHE_CONTAINER_NAME>=apinizercloud/cache:<NEW_VERSION>
   
2. Pod durumunu takip edin

   Pod’ların READY olması beklenir, pod durumu takip edilir:

   kubectl get pods -n <WORKER_CACHE_NAMESPACE>
   kubectl get logs -f -n <WORKER_CACHE_NAMESPACE> <POD_NAME>
   

​

2.1.3) Apinizer Portal ve Integration Güncellenmesi

Apinizer Portal ve Integration benzer şekilde güncellenebilir.

1. Portal ve Integration deployment imajlarını güncelleyin

   kubectl set image deployment/<PORTAL_DEPLOYMENT_NAME> -n <PORTAL_NAMESPACE> <PORTAL_CONTAINER_NAME>=apinizercloud/apiportal:<NEW_VERSION>
   kubectl set image deployment/<INTEGRATION_DEPLOYMENT_NAME> -n <INTEGRATION_NAMESPACE> <INTEGRATION_CONTAINER_NAME>=apinizercloud/integration:<NEW_VERSION>
   
2. Pod durumlarını takip edin

   Pod’ların READY olması beklenir, pod durumları takip edilir:

   kubectl get pods -n <PORTAL_NAMESPACE>
   kubectl get logs -f -n <PORTAL_NAMESPACE> <POD_NAME>
   kubectl get pods -n <INTEGRATION_NAMESPACE>
   kubectl get logs -f -n <INTEGRATION_NAMESPACE> <POD_NAME>
   

---

​

2.2) Apinizer’ın Çevrimdışı Güncellenmesi

Kubernetes ortamlarında güncelleme yapmayı gerektiren offline sistemler için iki ana yöntem kullanılabilir:

Manuel İmaj Transferi

İnterneti ve docker/containerd uygulaması olan bir sunucuya imaj dosyalarını çekmek ve bu imaj dosyalarını hedef Kubernetes cluster’ına aktarmak.

Yerel Registry Kullanımı

Kubernetes cluster’ın kullanacağı bir repository uygulaması kullanmak (Nexus, Harbor vb.).

​

2.2.1) Online Sunucudan İmajların Çekilmesi ve Offline Sunuculara Aktarılması

İnternete ve offline makinelere erişimi olan bir makine varsa aşağıdaki adımlar gerçekleştirilebilir.

​

2.2.1.1) Docker Kullanımı

# Online sunucudan yükseltme için gerekli olan tüm imajlar çekilir
docker 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>

# İlgili imajları offline sunuculara aktarmak için, online sunucuda imajlar `.tar` formatında kaydedilir
docker save apinizercloud/apimanager:<NEW_VERSION> -o apinizercloud-apimanager.<NEW_VERSION>.tar
docker save apinizercloud/worker:<NEW_VERSION> -o apinizercloud-worker.<NEW_VERSION>.tar
docker save apinizercloud/cache:<NEW_VERSION> -o apinizercloud-cache.<NEW_VERSION>.tar
docker save apinizercloud/apiportal:<NEW_VERSION> -o apinizercloud-apiportal.<NEW_VERSION>.tar
docker save apinizercloud/integration:<NEW_VERSION> -o apinizercloud-integration.<NEW_VERSION>.tar

# İmajların her biri offline sunucuya aktarılır
scp apinizercloud-*.tar <OFFLINE_MACHINE_USER>@<OFFLINE_MACHINE_IP>:<TARGET_DIRECTORY>

# Her bir offline sunucuda imajlar yüklenilir
docker load -i apinizercloud-apimanager.<NEW_VERSION>.tar
docker load -i apinizercloud-worker.<NEW_VERSION>.tar
docker load -i apinizercloud-cache.<NEW_VERSION>.tar
docker load -i apinizercloud-portal.<NEW_VERSION>.tar
docker load -i apinizercloud-integration.<NEW_VERSION>.tar

​

2.2.1.2) Containerd Kullanımı

# Online sunucudan yükseltme için gerekli olan tüm imajlar çekilir
ctr 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>

# İlgili imajları offline sunuculara aktarmak için, online sunucuda imajlar `.tar` formatında kaydedilir
ctr images export apinizercloud-apimanager.tar docker.io/apinizercloud/apimanager:<NEW_VERSION>
ctr images export apinizercloud-worker.tar docker.io/apinizercloud/worker:<NEW_VERSION>
ctr images export apinizercloud-cache.tar docker.io/apinizercloud/cache:<NEW_VERSION>
ctr images export apinizercloud-apiportal.tar docker.io/apinizercloud/apiportal:<NEW_VERSION>
ctr images export apinizercloud-integration.tar docker.io/apinizercloud/integration:<NEW_VERSION>

# İmajların her biri offline kubernetes worker sunuculara aktarılır
scp docker.io-apinizercloud-*.tar <OFFLINE_MACHINE_USER>@<OFFLINE_MACHINE_IP>:<TARGET_DIRECTORY>

# Her bir offline sunucuda imajlar yüklenilir
ctr images import apinizercloud-apimanager.tar
ctr images import apinizercloud-worker.tar
ctr images import apinizercloud-cache.tar
ctr images import apinizercloud-apiportal.tar
ctr images import apinizercloud-integration.tar

​

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.

​

2.2.2.1) Docker Kullanımı

# Gerekli tüm imajlar çekilir
docker 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 etiketlenir
docker 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>

​

2.2.2.2) Containerd Kullanımı

# Gerekli tüm imajlar çekilir
ctr 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 etiketlenir
ctr 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>

​

2.2.3) Apinizer Api Manager Güncellenmesi

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

   kubectl get deployments -Ao wide
   
2. Api Manager deployment imajını güncelleyin

   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:

   kubectl get pods -n <MANAGER_NAMESPACE>
   kubectl logs -f -n <MANAGER_NAMESPACE> <POD_NAME>
   

​

2.2.4) Apinizer Worker ve Cache Güncellenmesi

Apinizer Api Manager imajının güncellendiğinden emin olduktan sonra Apinizer Worker ve Cache uygulamaları güncellenir.

1. Worker ve Cache deployment imajlarını güncelleyin

   kubectl set image deployment/<WORKER_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <WORKER_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/worker:<NEW_VERSION>
   kubectl set image deployment/<CACHE_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <CACHE_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/cache:<NEW_VERSION>
   
2. Pod durumunu takip edin

   Pod’ların READY olması beklenir, pod durumu takip edilir:

   kubectl get pods -n <WORKER_CACHE_NAMESPACE>
   kubectl logs -f -n <WORKER_CACHE_NAMESPACE> <POD_NAME>
   

​

2.2.5) Apinizer Portal ve Integration Güncellenmesi

Apinizer Portal ve Integration benzer şekilde güncellenebilir.

1. Portal ve Integration deployment imajlarını güncelleyin

   kubectl set image deployment/<PORTAL_DEPLOYMENT_NAME> -n <PORTAL_NAMESPACE> <PORTAL_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/apiportal:<NEW_VERSION>
   kubectl set image deployment/<INTEGRATION_DEPLOYMENT_NAME> -n <INTEGRATION_NAMESPACE> <INTEGRATION_CONTAINER_NAME>=<YEREL_REGISTRY>/apinizercloud/integration:<NEW_VERSION>
   
2. Pod durumlarını takip edin

   Pod’ların READY olması beklenir, pod durumları takip edilir:

   kubectl get pods -n <PORTAL_NAMESPACE>
   kubectl get logs -f -n <PORTAL_NAMESPACE> <POD_NAME>
   kubectl get pods -n <INTEGRATION_NAMESPACE>
   kubectl get logs -f -n <INTEGRATION_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.

​

3.1) MongoDB Veritabanı Geri Yükleme

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:

   kubectl scale deploy <MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> --replicas=0
   
2. MongoDB yedeğini geri yükleyin

   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.

Detaylı bilgi için MongoDB Veritabanı Yedekleme ve Geri Yükleme sayfası incelenebilir.

​

3.2) Api Manager Uygulamasının Sürümünün Geri Alınması

Dönüş sırasında eğer yerel kayıt defteri kullanılacaksa komutlar buna göre güncellenmelidir.

1. Api Manager deployment imajını eski sürüme döndürün

   kubectl set image deployment/<MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> <MANAGER_CONTAINER_NAME>=apinizercloud/apimanager:<OLD_VERSION>
   
2. Replica sayısını 1'e çekin

   kubectl scale deploy <MANAGER_DEPLOYMENT_NAME> -n <MANAGER_NAMESPACE> --replicas=1
   
3. Pod durumunu takip edin

   Pod’un READY olması beklenir, pod durumu ve logları takip edilir:

   kubectl get pods -n <MANAGER_NAMESPACE>
   kubectl logs -f -n <MANAGER_NAMESPACE> <POD_NAME>
   

​

3.3) Diğer Uygulamaların Sürümünün Geri Alınması

Api Manager uygulaması çalışır hale geldiğinde diğer uygulamalar birlikte eski sürüme döndürülebilir.

Dönüş sırasında eğer yerel kayıt defteri kullanılacaksa komutlar buna göre güncellenmelidir.

1. Deployment imajlarını eski sürüme döndürün

   kubectl set image deployment/<WORKER_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <WORKER_CONTAINER_NAME>=apinizercloud/worker:<OLD_VERSION>
   kubectl set image deployment/<CACHE_DEPLOYMENT_NAME> -n <WORKER_CACHE_NAMESPACE> <CACHE_CONTAINER_NAME>=apinizercloud/cache:<OLD_VERSION>
   kubectl set image deployment/<PORTAL_DEPLOYMENT_NAME> -n <PORTAL_NAMESPACE> <PORTAL_CONTAINER_NAME>=apinizercloud/apiportal:<OLD_VERSION>
   kubectl set image deployment/<INTEGRATION_DEPLOYMENT_NAME> -n <INTEGRATION_NAMESPACE> <INTEGRATION_CONTAINER_NAME>=apinizercloud/integration:<OLD_VERSION>
   
2. Pod durumlarını kontrol edin

   Pod’ların READY olması beklenir, pod durumları ve gerekirse logları takip edilir:

   kubectl get pods -A