Bulut tabanl\u0131 Kubernetes \u00e7\u00f6z\u00fcmleri, modern uygulama geli\u015ftirmenin vazge\u00e7ilmez bir par\u00e7as\u0131 haline geldi. \u00d6zellikle Google Kubernetes Engine (GKE), sa\u011flad\u0131\u011f\u0131 y\u00f6netilen hizmetlerle geli\u015ftiricilerin ve operasyon ekiplerinin y\u00fck\u00fcn\u00fc b\u00fcy\u00fck \u00f6l\u00e7\u00fcde hafifletiyor. Ancak bu kolayl\u0131\u011f\u0131n arkas\u0131nda, k\u00fcme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fcn en kritik par\u00e7alar\u0131ndan biri olan y\u00fckseltme (upgrade) s\u00fcre\u00e7leri yatmaktad\u0131r. GKE’deki kontrol d\u00fczlemi y\u00fckseltmeleri, k\u00fcmelerinizin kararl\u0131l\u0131\u011f\u0131n\u0131 ve g\u00fcvenli\u011fini do\u011frudan etkileyen hassas operasyonlard\u0131r. Peki, bu y\u00fckseltmeler nas\u0131l y\u00f6netiliyor ve beklenmedik bir sorunla kar\u015f\u0131la\u015f\u0131ld\u0131\u011f\u0131nda min\u00f6r s\u00fcr\u00fcm geri almalar\u0131 (rollback) tam olarak nas\u0131l \u00e7al\u0131\u015f\u0131yor? Bu makalede, GKE’nin iki a\u015famal\u0131 y\u00fckseltme modelini derinlemesine inceleyecek, olas\u0131 geri alma senaryolar\u0131n\u0131 ve bu s\u00fcre\u00e7lerin arka plan\u0131ndaki mekanizmalar\u0131 ad\u0131m ad\u0131m ke\u015ffedece\u011fiz. Amac\u0131m\u0131z, GKE y\u00fckseltme stratejilerinizi daha bilin\u00e7li bir \u015fekilde planlaman\u0131za yard\u0131mc\u0131 olmak ve kar\u015f\u0131la\u015fabilece\u011finiz zorluklara kar\u015f\u0131 sizi donan\u0131ml\u0131 hale getirmektir.<\/p>\n
Kubernetes, da\u011f\u0131t\u0131k sistemlerin y\u00f6netimi i\u00e7in devrim niteli\u011finde bir platform sunsa da, bu platformun kendisi de s\u00fcrekli evrim ge\u00e7iren bir yaz\u0131l\u0131md\u0131r. Yeni \u00f6zellikler, performans iyile\u015ftirmeleri ve en \u00f6nemlisi g\u00fcvenlik yamalar\u0131, Kubernetes’in her yeni s\u00fcr\u00fcm\u00fcnde kar\u015f\u0131m\u0131za \u00e7\u0131kar. GKE gibi y\u00f6netilen bir Kubernetes hizmetinde, bu g\u00fcncellemelerin k\u00fcmelerinize sorunsuz bir \u015fekilde uygulanmas\u0131 b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r. Kontrol d\u00fczlemi (control plane), Kubernetes k\u00fcmesinin beynidir; API sunucusu, zamanlay\u0131c\u0131 (scheduler), kontrol\u00f6r y\u00f6neticisi (controller manager) ve etcd gibi temel bile\u015fenleri bar\u0131nd\u0131r\u0131r. Bu bile\u015fenler, k\u00fcmedeki t\u00fcm operasyonlar\u0131 y\u00f6netir, i\u015f y\u00fcklerini da\u011f\u0131t\u0131r ve k\u00fcmenin genel durumunu s\u00fcrd\u00fcr\u00fcr. Dolay\u0131s\u0131yla, kontrol d\u00fczleminin g\u00fcncel ve sa\u011fl\u0131kl\u0131 olmas\u0131, uygulaman\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131 i\u00e7in hayati \u00f6neme sahiptir.<\/p>\n
Y\u00fckseltmelerin ihmal edilmesi, bir dizi potansiyel sorunu beraberinde getirebilir. \u00d6ncelikle, g\u00fcvenlik a\u00e7\u0131klar\u0131n\u0131n yamalanmamas\u0131, k\u00fcmenizi siber sald\u0131r\u0131lara kar\u015f\u0131 savunmas\u0131z hale getirebilir. Eski s\u00fcr\u00fcmler, bilinen zafiyetleri i\u00e7erebilir ve bu da hassas verilerin veya uygulama i\u015flevlerinin tehlikeye at\u0131lmas\u0131na yol a\u00e7abilir. \u0130kincisi, performans iyile\u015ftirmelerinden ve yeni \u00f6zelliklerden mahrum kal\u0131rs\u0131n\u0131z. Kubernetes ekosistemi h\u0131zla geli\u015fiyor; yeni API’ler, geli\u015fmi\u015f kaynak y\u00f6netimi yetenekleri ve daha verimli i\u015f y\u00fck\u00fc da\u011f\u0131t\u0131m stratejileri, uygulaman\u0131z\u0131n \u00f6l\u00e7eklenebilirli\u011fini ve maliyet etkinli\u011fini art\u0131rabilir. Eski bir s\u00fcr\u00fcmde kalmak, bu avantajlardan faydalanamaman\u0131z anlam\u0131na gelir. \u00dc\u00e7\u00fcnc\u00fcs\u00fc, s\u00fcr\u00fcm uyumsuzluklar\u0131 zamanla birikerek gelecekteki y\u00fckseltmeleri daha karma\u015f\u0131k ve riskli hale getirebilir. \u00c7ok eski bir s\u00fcr\u00fcmden do\u011frudan en yeni s\u00fcr\u00fcme ge\u00e7i\u015f yapmak, aradaki de\u011fi\u015fikliklerin b\u00fcy\u00fckl\u00fc\u011f\u00fc nedeniyle ciddi uyumluluk sorunlar\u0131na yol a\u00e7abilir ve potansiyel olarak uygulama kesintilerine neden olabilir. Bu nedenle, d\u00fczenli ve kontroll\u00fc y\u00fckseltmeler, GKE k\u00fcmelerinizin uzun \u00f6m\u00fcrl\u00fc, g\u00fcvenli ve performansl\u0131 kalmas\u0131n\u0131 sa\u011flamak i\u00e7in vazge\u00e7ilmez bir operasyonel pratik olarak kabul edilmelidir. GKE, bu s\u00fcre\u00e7leri y\u00f6neterek karma\u015f\u0131kl\u0131\u011f\u0131 azalt\u0131r, ancak yine de kullan\u0131c\u0131lar\u0131n y\u00fckseltme politikalar\u0131n\u0131 anlamalar\u0131 ve do\u011fru stratejileri uygulamalar\u0131 gerekmektedir.<\/p>\n
GKE’deki y\u00fckseltme s\u00fcreci, genellikle “iki a\u015famal\u0131” bir model olarak tan\u0131mlan\u0131r ve bu model, hem g\u00fcvenlik hem de kararl\u0131l\u0131k a\u00e7\u0131s\u0131ndan \u00f6nemli avantajlar sunar. Bu yakla\u015f\u0131m, k\u00fcmenin kontrol d\u00fczlemi (master) ve d\u00fc\u011f\u00fcm havuzlar\u0131 (node pools) olmak \u00fczere iki ana bile\u015feninin ayr\u0131 ayr\u0131 y\u00fckseltilmesini i\u00e7erir. Bu ayr\u0131m, y\u00fckseltme riskini minimize etmek ve olas\u0131 sorunlar\u0131n etkisini s\u0131n\u0131rlamak amac\u0131yla tasarlanm\u0131\u015ft\u0131r. Tek a\u015famal\u0131 bir y\u00fckseltme modelinde, t\u00fcm k\u00fcme bile\u015fenleri ayn\u0131 anda g\u00fcncellenirken, iki a\u015famal\u0131 yakla\u015f\u0131m bu s\u00fcreci daha y\u00f6netilebilir k\u0131lar.<\/p>\n
\u0130lk a\u015famada, GKE k\u00fcmenizin kontrol d\u00fczlemi y\u00fckseltilir. Bu, API sunucusu, etcd, zamanlay\u0131c\u0131 ve kontrol\u00f6r y\u00f6neticisi gibi kritik bile\u015fenlerin yeni bir s\u00fcr\u00fcme ge\u00e7irilmesi anlam\u0131na gelir. Kontrol d\u00fczlemi y\u00fckseltilirken, k\u00fcmedeki i\u015f y\u00fckleri (uygulamalar\u0131n\u0131z) genellikle \u00e7al\u0131\u015fmaya devam eder \u00e7\u00fcnk\u00fc d\u00fc\u011f\u00fcm havuzlar\u0131 hen\u00fcz g\u00fcncellenmemi\u015ftir. Ancak bu s\u00fcre zarf\u0131nda, k\u00fcme y\u00f6netimi operasyonlar\u0131nda (\u00f6rne\u011fin, yeni pod olu\u015fturma, \u00f6l\u00e7eklendirme veya yap\u0131land\u0131rma de\u011fi\u015fiklikleri) k\u0131sa s\u00fcreli kesintiler veya gecikmeler ya\u015fanabilir. GKE, kontrol d\u00fczlemi y\u00fckseltmesini \u00e7o\u011falt\u0131lm\u0131\u015f (replicated) bir yap\u0131 \u00fczerinde ger\u00e7ekle\u015ftirerek bu kesintileri en aza indirmeyi hedefler. Bu a\u015faman\u0131n amac\u0131, k\u00fcmenin beynini en son g\u00fcvenli ve \u00f6zellikli s\u00fcr\u00fcme ta\u015f\u0131makt\u0131r.<\/p>\n
\u0130kinci a\u015famada ise, kontrol d\u00fczlemi y\u00fckseltildikten ve kararl\u0131l\u0131\u011f\u0131 do\u011fruland\u0131ktan sonra, k\u00fcmedeki d\u00fc\u011f\u00fcm havuzlar\u0131 y\u00fckseltilir. D\u00fc\u011f\u00fcm havuzlar\u0131, uygulamalar\u0131n\u0131z\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 sanal makinelerden (VM’ler) olu\u015fur. Bu a\u015famada GKE, her d\u00fc\u011f\u00fcm havuzundaki d\u00fc\u011f\u00fcmleri tek tek veya gruplar halinde g\u00fcnceller. Bu s\u00fcre\u00e7 genellikle yeni d\u00fc\u011f\u00fcmlerin ba\u015flat\u0131lmas\u0131, i\u015f y\u00fcklerinin eski d\u00fc\u011f\u00fcmlerden yeni d\u00fc\u011f\u00fcmlere ta\u015f\u0131nmas\u0131 (cordon ve drain) ve eski d\u00fc\u011f\u00fcmlerin sonland\u0131r\u0131lmas\u0131 \u015feklinde ilerler. Bu “kayan y\u00fckseltme” (rolling upgrade) stratejisi, uygulama kesintilerini en aza indirmeyi ama\u00e7lar. \u0130ki a\u015famal\u0131 modelin temel mant\u0131\u011f\u0131, kontrol d\u00fczlemi ile d\u00fc\u011f\u00fcm havuzlar\u0131 aras\u0131nda ge\u00e7ici bir s\u00fcr\u00fcm uyumsuzlu\u011funa izin vermesidir. Genellikle, d\u00fc\u011f\u00fcm havuzlar\u0131, kontrol d\u00fczleminden en fazla iki min\u00f6r s\u00fcr\u00fcm geride olabilir. Bu esneklik, geli\u015ftiricilere ve operasyon ekiplerine, kontrol d\u00fczlemi y\u00fckseltmesinin ard\u0131ndan uygulamalar\u0131n\u0131 yeni kontrol d\u00fczlemi s\u00fcr\u00fcm\u00fcyle test etmeleri ve d\u00fc\u011f\u00fcm havuzlar\u0131n\u0131 y\u00fckseltmeden \u00f6nce olas\u0131 uyumluluk sorunlar\u0131n\u0131 gidermeleri i\u00e7in zaman tan\u0131r.<\/p>\n
Bu model, \u00f6zellikle min\u00f6r s\u00fcr\u00fcm y\u00fckseltmelerinde risk y\u00f6netimini optimize eder. \u00d6rne\u011fin, bir kontrol d\u00fczlemi y\u00fckseltmesi sonras\u0131nda beklenmedik bir sorun ortaya \u00e7\u0131karsa, hen\u00fcz d\u00fc\u011f\u00fcm havuzlar\u0131 g\u00fcncellenmedi\u011fi i\u00e7in geri alma s\u00fcreci daha az karma\u015f\u0131k olabilir. Ayr\u0131ca, uygulaman\u0131z\u0131n yeni kontrol d\u00fczlemi s\u00fcr\u00fcm\u00fcyle uyumlulu\u011funu test etme f\u0131rsat\u0131 sunarak, tam k\u00fcme y\u00fckseltmesinin potansiyel etkisini azalt\u0131r. Bu sayede GKE, hem g\u00fcncel kalmay\u0131 hem de operasyonel kararl\u0131l\u0131\u011f\u0131 korumay\u0131 ama\u00e7layan dengeli bir y\u00fckseltme stratejisi sunar.<\/p>\n
GKE kontrol d\u00fczlemi y\u00fckseltme s\u00fcreci, otomatik veya manuel olarak tetiklenebilir ve belirli ad\u0131mlar\u0131 takip eder. Bu s\u00fcreci anlamak, y\u00fckseltmeleri daha etkin y\u00f6netmenizi ve olas\u0131 sorunlara kar\u015f\u0131 haz\u0131rl\u0131kl\u0131 olman\u0131z\u0131 sa\u011flar. Her ne kadar GKE bu s\u00fcreci sizin i\u00e7in y\u00f6netse de, arka planda neler olup bitti\u011fini bilmek \u00f6nemlidir.<\/p>\n
Her y\u00fckseltme \u00f6ncesinde at\u0131lmas\u0131 gereken baz\u0131 kritik ad\u0131mlar vard\u0131r. \u00d6ncelikle, mevcut k\u00fcmenizin ve uygulamalar\u0131n\u0131z\u0131n bir yede\u011fini almak her zaman iyi bir pratiktir. \u00d6zellikle etcd veritaban\u0131n\u0131n anl\u0131k g\u00f6r\u00fcnt\u00fcs\u00fc (snapshot) veya uygulama verilerinizin yedeklenmesi, beklenmedik bir durumda geri d\u00f6n\u00fc\u015f i\u00e7in g\u00fcvence sa\u011flar. \u0130kinci olarak, uygulamalar\u0131n\u0131z\u0131n ve ba\u011f\u0131ml\u0131l\u0131klar\u0131n\u0131z\u0131n yeni Kubernetes s\u00fcr\u00fcm\u00fcyle uyumlulu\u011funu kontrol etmek \u00f6nemlidir. Kubernetes API’sinde yap\u0131lan de\u011fi\u015fiklikler veya kald\u0131r\u0131lan \u00f6zellikler, eski uygulamalar\u0131n d\u00fczg\u00fcn \u00e7al\u0131\u015fmamas\u0131na neden olabilir. Bu nedenle, geli\u015ftirme veya haz\u0131rl\u0131k ortamlar\u0131nda (staging environment) y\u00fckseltmeyi test etmek, potansiyel sorunlar\u0131 \u00fcretim ortam\u0131na yans\u0131madan \u00f6nce tespit etmenize yard\u0131mc\u0131 olur. \u00dc\u00e7\u00fcnc\u00fc olarak, k\u00fcme kaynak kullan\u0131m\u0131n\u0131z\u0131 ve performans metriklerini y\u00fckseltme \u00f6ncesinde izlemek, y\u00fckseltme sonras\u0131 kar\u015f\u0131la\u015ft\u0131rmalar i\u00e7in bir temel olu\u015fturur. B\u00f6ylece, y\u00fckseltmenin performans \u00fczerinde olumsuz bir etkisi olup olmad\u0131\u011f\u0131n\u0131 kolayca anlayabilirsiniz. Ayr\u0131ca, GKE’nin bak\u0131m pencerelerini (maintenance windows) ve hari\u00e7 tutmalar\u0131 (exclusions) do\u011fru yap\u0131land\u0131rd\u0131\u011f\u0131n\u0131zdan emin olun. Bu, y\u00fckseltmelerin i\u015f y\u00fck\u00fcn\u00fcz i\u00e7in en az kesintiye neden olacak zamanlarda ger\u00e7ekle\u015fmesini sa\u011flar.<\/p>\n
Kontrol d\u00fczlemi y\u00fckseltmesi, genellikle otomatik bak\u0131m pencerelerinde GKE taraf\u0131ndan tetiklenir veya manuel olarak Bu komut, belirtilen k\u00fcmenin kontrol d\u00fczlemini hedef s\u00fcr\u00fcme y\u00fckseltir. Kontrol d\u00fczlemi y\u00fckseltmesi ba\u015far\u0131yla tamamland\u0131ktan ve kararl\u0131l\u0131\u011f\u0131 do\u011fruland\u0131ktan sonra, d\u00fc\u011f\u00fcm havuzlar\u0131n\u0131 y\u00fckseltme zaman\u0131 gelir. Bu a\u015fama da otomatik olarak veya manuel olarak ba\u015flat\u0131labilir. GKE, her d\u00fc\u011f\u00fcm havuzundaki d\u00fc\u011f\u00fcmleri y\u00fckseltmek i\u00e7in bir “kayan y\u00fckseltme” stratejisi kullan\u0131r. Bu, yeni s\u00fcr\u00fcme sahip yeni d\u00fc\u011f\u00fcmlerin ba\u015flat\u0131lmas\u0131, mevcut i\u015f y\u00fcklerinin eski d\u00fc\u011f\u00fcmlerden yeni d\u00fc\u011f\u00fcmlere g\u00fcvenli bir \u015fekilde ta\u015f\u0131nmas\u0131 (drain i\u015flemi) ve eski d\u00fc\u011f\u00fcmlerin sonland\u0131r\u0131lmas\u0131 anlam\u0131na gelir. Bu s\u00fcre\u00e7, uygulaman\u0131z\u0131n kesintisiz \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamak i\u00e7in dikkatle y\u00f6netilir. Y\u00fckseltme s\u0131ras\u0131nda, uygulaman\u0131z\u0131n pod’lar\u0131 yeni d\u00fc\u011f\u00fcmlere yeniden zamanlan\u0131rken k\u0131sa s\u00fcreli eri\u015filebilirlik sorunlar\u0131 ya\u015fanabilir. Bu a\u015faman\u0131n tamamlanmas\u0131, t\u00fcm k\u00fcmenizin yeni s\u00fcr\u00fcme ge\u00e7ti\u011fi anlam\u0131na gelir. D\u00fc\u011f\u00fcm havuzlar\u0131n\u0131 y\u00fckseltmek i\u00e7in kullan\u0131lan komut \u00f6rne\u011fi:<\/p>\n Bu komut, belirli bir d\u00fc\u011f\u00fcm havuzunu, k\u00fcmenin kontrol d\u00fczlemi s\u00fcr\u00fcm\u00fcne veya uyumlu bir s\u00fcr\u00fcme y\u00fckseltir. Bu iki a\u015famal\u0131 yakla\u015f\u0131m, y\u00fckseltme s\u00fcrecini daha kontroll\u00fc ve daha az riskli hale getirir.<\/p>\n GKE, otomatik y\u00fckseltme \u00f6zelli\u011fi ile k\u00fcmelerinizi g\u00fcncel tutma y\u00fck\u00fcn\u00fc azalt\u0131r. Bak\u0131m pencereleri ve hari\u00e7 tutmalar, bu otomatik y\u00fckseltmelerin ne zaman ger\u00e7ekle\u015fece\u011fini kontrol etmenizi sa\u011flar. Bak\u0131m pencereleri, GKE’nin y\u00fckseltme gibi bak\u0131m operasyonlar\u0131n\u0131 ger\u00e7ekle\u015ftirmesine izin verilen belirli zaman dilimleridir. Hari\u00e7 tutmalar ise, bu operasyonlar\u0131n kesinlikle yap\u0131lmamas\u0131 gereken zaman dilimlerini belirtir. Bu yap\u0131land\u0131rmalar, y\u00fckseltmelerin i\u015f y\u00fck\u00fcn\u00fcz\u00fcn en az etkilendi\u011fi, \u00f6rne\u011fin d\u00fc\u015f\u00fck trafikli saatlerde veya hafta sonlar\u0131nda ger\u00e7ekle\u015fmesini sa\u011flayarak operasyonel riski d\u00fc\u015f\u00fcr\u00fcr.<\/p>\n GKE’de y\u00fckseltme s\u00fcre\u00e7leri genellikle sorunsuz ilerlese de, her zaman beklenmedik durumlar ortaya \u00e7\u0131kabilir. Yeni bir min\u00f6r s\u00fcr\u00fcm y\u00fckseltmesi sonras\u0131, uygulaman\u0131zda kritik hatalar, performans d\u00fc\u015f\u00fc\u015fleri veya uyumluluk sorunlar\u0131 g\u00f6zlemleyebilirsiniz. Bu t\u00fcr senaryolarda, h\u0131zl\u0131 ve g\u00fcvenli bir \u015fekilde \u00f6nceki kararl\u0131 s\u00fcr\u00fcme geri d\u00f6nebilme yetene\u011fi, operasyonel s\u00fcreklilik i\u00e7in hayati \u00f6nem ta\u015f\u0131r. \u0130\u015fte burada GKE’nin min\u00f6r s\u00fcr\u00fcm geri alma (rollback) \u00f6zelli\u011fi devreye girer. Bu \u00f6zellik, \u00f6zellikle kontrol d\u00fczlemi y\u00fckseltmelerinde, k\u00fcmenizin beynini g\u00fcvenli bir \u015fekilde \u00f6nceki \u00e7al\u0131\u015fma durumuna d\u00f6nd\u00fcrmenizi sa\u011flar.<\/p>\n Geri alma ihtiyac\u0131 genellikle a\u015fa\u011f\u0131daki gibi senaryolarda ortaya \u00e7\u0131kar:<\/p>\n Bu riskler, bir y\u00fckseltme sonras\u0131 geri alma se\u00e7ene\u011finin neden bu kadar de\u011ferli oldu\u011funu a\u00e7\u0131k\u00e7a ortaya koymaktad\u0131r. Geri alma yetene\u011fi, potansiyel olarak uzun s\u00fcreli kesintileri \u00f6nleyebilir ve i\u015f s\u00fcreklili\u011fini sa\u011flayabilir.<\/p>\n GKE’de min\u00f6r s\u00fcr\u00fcm geri almas\u0131, genellikle kontrol d\u00fczlemi i\u00e7in ge\u00e7erlidir ve GKE’nin y\u00f6netilen do\u011fas\u0131 sayesinde m\u00fcmk\u00fcn olur. GKE, kontrol d\u00fczlemi y\u00fckseltmelerini ger\u00e7ekle\u015ftirirken, \u00f6nceki kararl\u0131 min\u00f6r s\u00fcr\u00fcm\u00fcn durumunu ve yap\u0131land\u0131rmas\u0131n\u0131 bir s\u00fcre boyunca korur. Bu, bir “anl\u0131k g\u00f6r\u00fcnt\u00fc” (snapshot) veya “ge\u00e7ici durum” (temporary state) gibi d\u00fc\u015f\u00fcn\u00fclebilir. Bir geri alma talebi geldi\u011finde, GKE bu korunan \u00f6nceki durumu kullanarak kontrol d\u00fczlemini yeniden yap\u0131land\u0131r\u0131r ve devreye al\u0131r. Bu s\u00fcre\u00e7, API sunucusunun, etcd’nin ve di\u011fer kontrol d\u00fczlemi bile\u015fenlerinin \u00f6nceki s\u00fcr\u00fcmlerine geri d\u00f6nmesini i\u00e7erir.<\/p>\n \u00d6nemli bir nokta, GKE’nin yaln\u0131zca min\u00f6r s\u00fcr\u00fcmler aras\u0131nda geri almaya izin vermesidir. Yani, 1.25’ten 1.26’ya y\u00fckselttiyseniz ve sorun ya\u015fad\u0131ysan\u0131z, 1.25’e geri d\u00f6nebilirsiniz. Ancak 1.24’ten 1.26’ya atlay\u0131p sonra 1.24’e geri d\u00f6nmek m\u00fcmk\u00fcn olmayabilir, \u00e7\u00fcnk\u00fc GKE genellikle yaln\u0131zca bir \u00f6nceki min\u00f6r s\u00fcr\u00fcm\u00fc geri alma hedefi olarak tutar. B\u00fcy\u00fck (major) s\u00fcr\u00fcm geri almalar\u0131, API uyumluluk de\u011fi\u015fiklikleri nedeniyle \u00e7ok daha karma\u015f\u0131kt\u0131r ve GKE taraf\u0131ndan desteklenmez. Geri alma i\u015flemi s\u0131ras\u0131nda, kontrol d\u00fczlemi ge\u00e7ici olarak yeniden ba\u015flat\u0131labilir veya yeniden yap\u0131land\u0131r\u0131labilir, bu da API sunucusuna yap\u0131lan isteklerde k\u0131sa s\u00fcreli kesintilere neden olabilir.<\/p>\n Bir geri alma i\u015flemi ba\u015flatmak i\u00e7in Bu komut, kontrol d\u00fczlemini belirtilen \u00f6nceki min\u00f6r s\u00fcr\u00fcme geri d\u00f6nd\u00fcrme talebini GKE’ye iletir. Geri alma s\u00fcreci, y\u00fckseltme s\u00fcreciyle benzer \u015fekilde, kontrol d\u00fczlemi bile\u015fenlerinin yeni (eski) s\u00fcr\u00fcmle de\u011fi\u015ftirilmesini i\u00e7erir. Bu i\u015flem tamamland\u0131\u011f\u0131nda, kontrol d\u00fczlemi \u00f6nceki kararl\u0131 min\u00f6r s\u00fcr\u00fcmde \u00e7al\u0131\u015fmaya devam eder. Geri alman\u0131n etkileri \u015funlar\u0131 i\u00e7erebilir:<\/p>\n GKE’nin geri alma politikalar\u0131 belirli s\u0131n\u0131rlamalara tabidir. Genellikle, yaln\u0131zca bir \u00f6nceki min\u00f6r s\u00fcr\u00fcme geri d\u00f6n\u00fclebilir. \u00d6rne\u011fin, 1.27’ye y\u00fckselttikten sonra 1.26’ya geri d\u00f6nebilirsiniz, ancak 1.25’e geri d\u00f6nmek m\u00fcmk\u00fcn olmayabilir. Bu s\u0131n\u0131rlama, GKE’nin sistem kaynaklar\u0131n\u0131 ve karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netme \u015feklinden kaynaklan\u0131r. Bu nedenle, y\u00fckseltme planlamas\u0131 yaparken, geri alma se\u00e7ene\u011finin yaln\u0131zca en yak\u0131n \u00f6nceki min\u00f6r s\u00fcr\u00fcm i\u00e7in ge\u00e7erli oldu\u011funu unutmamak \u00f6nemlidir. Ayr\u0131ca, kontrol d\u00fczlemi geri almas\u0131, d\u00fc\u011f\u00fcm havuzlar\u0131n\u0131n da eski s\u00fcr\u00fcme d\u00f6nmesini garanti etmez. E\u011fer d\u00fc\u011f\u00fcm havuzlar\u0131 yeni s\u00fcr\u00fcme y\u00fckseltildiyse ve uygulaman\u0131z\u0131n \u00f6nceki kontrol d\u00fczlemi s\u00fcr\u00fcm\u00fcyle uyumlu bir d\u00fc\u011f\u00fcm havuzu s\u00fcr\u00fcm\u00fcne ihtiyac\u0131 varsa, manuel m\u00fcdahale gerekebilir. Bu durum, y\u00fckseltme s\u00fcrecinde her iki a\u015famay\u0131 da dikkatle y\u00f6netmenin ve test etmenin \u00f6nemini bir kez daha vurgular.<\/p>\n Her ne kadar GKE y\u00fckseltmeleri genellikle sorunsuz ilerlese de, bazen beklenmedik durumlar ortaya \u00e7\u0131kabilir. \u0130\u015fte, bir geli\u015ftirme ekibinin ya\u015fad\u0131\u011f\u0131 ve min\u00f6r s\u00fcr\u00fcm geri alma \u00f6zelli\u011finin ne kadar kritik oldu\u011funu g\u00f6steren hayali bir senaryo:<\/p>\n Bir e-ticaret \u015firketi, GKE k\u00fcmesini Kubernetes 1.26’dan 1.27’ye y\u00fckseltmeye karar verdi. Bak\u0131m penceresi olarak gece yar\u0131s\u0131 saatleri se\u00e7ildi ve y\u00fckseltme otomatik olarak ba\u015flat\u0131ld\u0131. \u0130lk a\u015fama olan kontrol d\u00fczlemi y\u00fckseltmesi ba\u015far\u0131yla tamamland\u0131. Ekip, sabah erken saatlerde kontrol d\u00fczleminin 1.27’ye ge\u00e7ti\u011fini do\u011frulad\u0131 ve her \u015fey yolunda g\u00f6r\u00fcn\u00fcyordu. Ancak, \u00f6\u011fleden sonra, m\u00fc\u015fteri hizmetleri ekibinden gelen yo\u011fun \u015fikayetler \u00fczerine, sipari\u015f takip sisteminin (Order Tracking System – OTS) \u00e7al\u0131\u015fmad\u0131\u011f\u0131 fark edildi. OTS, kritik bir i\u015f y\u00fck\u00fcyd\u00fc ve m\u00fc\u015fterilerin sipari\u015flerini takip etmelerini sa\u011fl\u0131yordu.<\/p>\n Ekip, hemen sorunu ara\u015ft\u0131rmaya ba\u015flad\u0131. Loglar\u0131 incelediklerinde, OTS’nin kulland\u0131\u011f\u0131 \u00f6zel bir Kubernetes Custom Resource Definition (CRD) kontrol\u00f6r\u00fcn\u00fcn s\u00fcrekli olarak hata verdi\u011fini ve API sunucusuna istek g\u00f6nderirken “ Durumun ciddiyeti anla\u015f\u0131ld\u0131. Sipari\u015fler i\u015flenmeye devam ediyordu ancak m\u00fc\u015fteriler sipari\u015flerini takip edemiyordu, bu da m\u00fc\u015fteri memnuniyetini ve \u015firket itibar\u0131n\u0131 olumsuz etkiliyordu. K\u0131sa vadede OTS’yi d\u00fczeltmek i\u00e7in kod de\u011fi\u015fikli\u011fi yapmak ve da\u011f\u0131tmak, test s\u00fcre\u00e7leri de dahil olmak \u00fczere saatler, hatta g\u00fcnler alabilirdi. Bu durum, min\u00f6r s\u00fcr\u00fcm y\u00fckseltmelerinde bile detayl\u0131 testlerin ve geri alma stratejilerinin ne kadar \u00f6nemli oldu\u011funu ac\u0131 bir \u015fekilde g\u00f6sterdi.<\/p>\n Operasyon ekibi, durumu de\u011ferlendirdikten sonra, OTS’yi h\u0131zla \u00e7al\u0131\u015f\u0131r duruma getirmek i\u00e7in tek se\u00e7ene\u011fin kontrol d\u00fczlemini \u00f6nceki kararl\u0131 s\u00fcr\u00fcm olan 1.26’ya geri almak oldu\u011funa karar verdi. Neyse ki, d\u00fc\u011f\u00fcm havuzlar\u0131 hen\u00fcz 1.27’ye y\u00fckseltilmemi\u015fti ve hala 1.26 s\u00fcr\u00fcm\u00fcnde \u00e7al\u0131\u015f\u0131yorlard\u0131. Bu, geri alma i\u015flemini nispeten daha az karma\u015f\u0131k hale getiriyordu. Ekip, a\u015fa\u011f\u0131daki Bu olaydan sonra \u015firket, y\u00fckseltme s\u00fcre\u00e7lerini yeniden g\u00f6zden ge\u00e7irdi ve \u00f6nemli dersler \u00e7\u0131kard\u0131:<\/p>\n Bu vaka analizi, GKE’nin min\u00f6r s\u00fcr\u00fcm geri alma \u00f6zelli\u011finin, iyi planlanm\u0131\u015f bir y\u00fckseltme stratejisinin ayr\u0131lmaz bir par\u00e7as\u0131 oldu\u011funu ve beklenmedik durumlarda operasyonel s\u00fcreklili\u011fi sa\u011flamak i\u00e7in kritik bir ara\u00e7 oldu\u011funu a\u00e7\u0131k\u00e7a g\u00f6stermektedir.<\/p>\n GKE’de y\u00fckseltme s\u00fcre\u00e7lerini daha da sa\u011flam ve risksiz hale getirmek i\u00e7in baz\u0131 ileri d\u00fczey ipu\u00e7lar\u0131 ve en iyi uygulamalar mevcuttur. Bu stratejiler, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k \u00fcretim ortamlar\u0131nda \u00e7al\u0131\u015fan ekipler i\u00e7in de\u011ferlidir.<\/p>\n Do\u011frudan t\u00fcm k\u00fcmeyi y\u00fckseltmek yerine, daha kontroll\u00fc ve a\u015famal\u0131 da\u011f\u0131t\u0131m stratejileri uygulayabilirsiniz:<\/p>\n Y\u00fckseltme s\u00fcre\u00e7lerini manuel olarak y\u00f6netmek, \u00f6zellikle birden fazla k\u00fcme veya s\u0131k y\u00fckseltmeler s\u00f6z konusu oldu\u011funda hata yapmaya a\u00e7\u0131k ve zaman al\u0131c\u0131d\u0131r. CI\/CD (S\u00fcrekli Entegrasyon\/S\u00fcrekli Da\u011f\u0131t\u0131m) boru hatlar\u0131na GKE y\u00fckseltme ad\u0131mlar\u0131n\u0131 entegre etmek, bu s\u00fcreci otomatikle\u015ftirmek i\u00e7in g\u00fc\u00e7l\u00fc bir yoldur. \u00d6rne\u011fin:<\/p>\n Terraform veya Crossplane gibi ara\u00e7lar, GKE k\u00fcme ya\u015fam d\u00f6ng\u00fcs\u00fcn\u00fc kod olarak (Infrastructure as Code – IaC) y\u00f6netmenize olanak tan\u0131r. Bu sayede, y\u00fckseltmeleri de kod tabanl\u0131 ve tekrarlanabilir bir \u015fekilde ger\u00e7ekle\u015ftirebilirsiniz. \u00d6rne\u011fin, Terraform ile k\u00fcme s\u00fcr\u00fcm\u00fcn\u00fc g\u00fcncelleyip, ard\u0131ndan Y\u00fckseltme s\u00fcrecinin her a\u015famas\u0131nda k\u00fcmenizin ve uygulamalar\u0131n\u0131z\u0131n sa\u011fl\u0131\u011f\u0131n\u0131 yak\u0131ndan izlemek kritik \u00f6neme sahiptir. Geli\u015fmi\u015f g\u00f6zlemleme ara\u00e7lar\u0131 (Prometheus, Grafana, Google Cloud Monitoring ve Logging) kullanarak:<\/p>\n Bu ileri d\u00fczey teknikler, GKE y\u00fckseltme s\u00fcre\u00e7lerinizi daha g\u00fcvenli, verimli ve \u00f6ng\u00f6r\u00fclebilir hale getirerek operasyonel m\u00fckemmelli\u011fe ula\u015fman\u0131za yard\u0131mc\u0131 olur. Her zaman “k\u00fc\u00e7\u00fck ba\u015fla, yava\u015f ilerle ve s\u00fcrekli izle” prensibini benimsemek, ba\u015far\u0131l\u0131 y\u00fckseltmelerin anahtar\u0131d\u0131r.<\/p>\n GKE’de iki a\u015famal\u0131 kontrol d\u00fczlemi y\u00fckseltmeleri, y\u00f6netilen Kubernetes k\u00fcmelerinin kararl\u0131l\u0131\u011f\u0131n\u0131 ve g\u00fcvenli\u011fini sa\u011flamak i\u00e7in kritik bir s\u00fcre\u00e7tir. Bu makalede, kontrol d\u00fczlemi ve d\u00fc\u011f\u00fcm havuzlar\u0131n\u0131n ayr\u0131 ayr\u0131 y\u00fckseltilmesinin neden \u00f6nemli oldu\u011funu, bu s\u00fcre\u00e7lerin ad\u0131m ad\u0131m nas\u0131l i\u015fledi\u011fini ve en \u00f6nemlisi, beklenmedik sorunlar kar\u015f\u0131s\u0131nda min\u00f6r s\u00fcr\u00fcm geri alma mekanizmas\u0131n\u0131n nas\u0131l bir cankurtaran g\u00f6revi \u00fcstlendi\u011fini detayl\u0131ca inceledik. Ger\u00e7ek d\u00fcnya senaryolar\u0131 \u00fczerinden, iyi planlanm\u0131\u015f bir y\u00fckseltme stratejisinin, kapsaml\u0131 testlerin ve g\u00fc\u00e7l\u00fc bir geri alma plan\u0131n\u0131n operasyonel s\u00fcreklilik i\u00e7in vazge\u00e7ilmez oldu\u011funu g\u00f6rd\u00fck. GKE, arka plandaki karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6neterek bu s\u00fcre\u00e7leri basitle\u015ftirse de, geli\u015ftiricilerin ve operasyon ekiplerinin bu mekanizmalar\u0131 derinlemesine anlamas\u0131, potansiyel riskleri minimize etmeleri ve k\u00fcmelerini g\u00fcvenle g\u00fcncel tutmalar\u0131 i\u00e7in elzemdir. Otomasyon, geli\u015fmi\u015f g\u00f6zlemleme ve a\u015famal\u0131 da\u011f\u0131t\u0131m stratejileri gibi ileri d\u00fczey uygulamalarla, y\u00fckseltme deneyiminizi daha da g\u00fc\u00e7lendirebilirsiniz. Unutmay\u0131n, g\u00fcncel kalmak yaln\u0131zca yeni \u00f6zelliklere eri\u015fmekle kalmaz, ayn\u0131 zamanda k\u00fcmenizin g\u00fcvenli\u011fini ve performans\u0131n\u0131 da art\u0131r\u0131r.<\/p>\n 1. GKE’de b\u00fcy\u00fck (major) s\u00fcr\u00fcm geri almas\u0131 m\u00fcmk\u00fcn m\u00fcd\u00fcr?<\/strong><\/p>\n Hay\u0131r, GKE genellikle b\u00fcy\u00fck s\u00fcr\u00fcm geri almalar\u0131n\u0131 desteklemez. \u00d6rne\u011fin, Kubernetes 1.25’ten 1.27’ye y\u00fckselttiyseniz, 1.25’e geri d\u00f6nmeniz m\u00fcmk\u00fcn de\u011fildir. Bunun nedeni, b\u00fcy\u00fck s\u00fcr\u00fcmler aras\u0131nda API’lerde ve temel bile\u015fenlerde \u00f6nemli de\u011fi\u015fiklikler olmas\u0131d\u0131r. Geri alma yetene\u011fi genellikle yaln\u0131zca bir \u00f6nceki min\u00f6r s\u00fcr\u00fcm i\u00e7in ge\u00e7erlidir.<\/p>\n 2. Kontrol d\u00fczlemi geri almas\u0131 ne kadar s\u00fcrer?<\/strong><\/p>\n Kontrol d\u00fczlemi geri almas\u0131 s\u00fcresi, k\u00fcmenizin b\u00fcy\u00fckl\u00fc\u011f\u00fcne, yap\u0131land\u0131rmas\u0131na ve GKE’nin mevcut y\u00fck\u00fcne ba\u011fl\u0131 olarak de\u011fi\u015febilir. Ancak genellikle 15 ila 30 dakika aras\u0131nda tamamlan\u0131r. Bu s\u00fcre zarf\u0131nda API sunucusuna yap\u0131lan isteklerde k\u0131sa s\u00fcreli kesintiler ya\u015fanabilir.<\/p>\n 3. D\u00fc\u011f\u00fcm havuzlar\u0131n\u0131 da geri alabilir miyim?<\/strong><\/p>\n GKE, d\u00fc\u011f\u00fcm havuzlar\u0131 i\u00e7in do\u011frudan bir “geri alma” komutu sunmaz. E\u011fer d\u00fc\u011f\u00fcm havuzlar\u0131n\u0131 y\u00fckselttikten sonra sorun ya\u015farsan\u0131z, genellikle eski s\u00fcr\u00fcme sahip yeni bir d\u00fc\u011f\u00fcm havuzu olu\u015fturman\u0131z, i\u015f y\u00fcklerinizi bu havuza ta\u015f\u0131man\u0131z ve ard\u0131ndan sorunlu d\u00fc\u011f\u00fcm havuzunu silmeniz \u00f6nerilir. Bu, daha kontroll\u00fc bir geri d\u00f6n\u00fc\u015f y\u00f6ntemidir.<\/p>\n 4. Otomatik y\u00fckseltmeleri tamamen kapatabilir miyim?<\/strong><\/p>\n GKE’de otomatik y\u00fckseltmeleri tamamen kapatmak yerine, bak\u0131m pencereleri ve hari\u00e7 tutmalar (maintenance windows and exclusions) belirleyerek y\u00fckseltmelerin ne zaman ger\u00e7ekle\u015fece\u011fini kontrol edebilirsiniz. Bu, k\u00fcmenizin g\u00fcvenlik ve performans a\u00e7\u0131s\u0131ndan g\u00fcncel kalmas\u0131n\u0131 sa\u011flarken, operasyonel ihtiya\u00e7lar\u0131n\u0131za uygun zamanlamay\u0131 da sunar. GKE, kritik g\u00fcvenlik yamalar\u0131n\u0131 zorunlu olarak uygulayabilir, bu nedenle tamamen kapatmak genellikle \u00f6nerilmez.<\/p>\n 5. Y\u00fckseltme \u00f6ncesi hangi testleri yapmal\u0131y\u0131m?<\/strong><\/p>\n Y\u00fckseltme \u00f6ncesi yap\u0131lmas\u0131 gereken testler \u015funlar\u0131 i\u00e7erir: uygulama fonksiyonel testleri, performans testleri (y\u00fck testi), API uyumluluk testleri (\u00f6zellikle kullan\u0131lan Kubernetes API’lerinin yeni s\u00fcr\u00fcmde hala mevcut ve beklendi\u011fi gibi \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak), entegrasyon testleri (\u00fc\u00e7\u00fcnc\u00fc taraf ara\u00e7larla uyumluluk) ve g\u00fcvenlik testleri. Bu testleri bir haz\u0131rl\u0131k veya test ortam\u0131nda yapmak, \u00fcretim ortam\u0131ndaki riskleri minimize eder.<\/p>\n #GKE #Kubernetes #KontrolD\u00fczlemi #Y\u00fckseltme #GeriAlma #CloudComputing #DevOps<\/p>\ngcloud<\/code> komut sat\u0131r\u0131 arac\u0131yla ba\u015flat\u0131labilir. Y\u00fckseltme ba\u015flad\u0131\u011f\u0131nda, GKE kontrol d\u00fczleminin yeni s\u00fcr\u00fcm\u00fcn\u00fc da\u011f\u0131tmaya ba\u015flar. Bu s\u00fcre\u00e7, genellikle bir “rolling update” (kayan y\u00fckseltme) stratejisiyle ger\u00e7ekle\u015ftirilir, yani mevcut kontrol d\u00fczlemi bile\u015fenleri tamamen kapat\u0131lmadan \u00f6nce yeni bile\u015fenler devreye al\u0131n\u0131r. Bu, API sunucusu gibi kritik bile\u015fenlerin s\u00fcrekli olarak eri\u015filebilir kalmas\u0131n\u0131 sa\u011flamak i\u00e7in \u00e7o\u011falt\u0131lm\u0131\u015f (replicated) bir mimari \u00fczerinde ger\u00e7ekle\u015fir. Y\u00fckseltme s\u0131ras\u0131nda, API sunucusuna yap\u0131lan isteklerde k\u0131sa s\u00fcreli gecikmeler veya ba\u011flant\u0131 s\u0131f\u0131rlamalar\u0131 ya\u015fanabilir, ancak GKE bu kesintileri en aza indirecek \u015fekilde tasarlanm\u0131\u015ft\u0131r. Y\u00fckseltme tamamland\u0131\u011f\u0131nda, kontrol d\u00fczlemi yeni s\u00fcr\u00fcme ge\u00e7mi\u015f olur, ancak d\u00fc\u011f\u00fcm havuzlar\u0131 hala eski s\u00fcr\u00fcmde kal\u0131r. Kontrol d\u00fczleminin y\u00fckseltilmesi i\u00e7in kullan\u0131lan komut \u00f6rne\u011fi \u015f\u00f6yledir:<\/p>\ngcloud container clusters upgrade [CLUSTER_ADI] --master --cluster-version [YENI_KONTROL_DUZLEMI_SURUMU] --region [BOLGE]<\/code><\/pre>\n<\/div>\n--master<\/code> bayra\u011f\u0131, yaln\u0131zca kontrol d\u00fczleminin y\u00fckseltilece\u011fini belirtir.<\/p>\nA\u015fama 2: D\u00fc\u011f\u00fcm Havuzu Y\u00fckseltmesi<\/h3>\n
gcloud container node-pools upgrade [NODE_HAVUZU_ADI] --cluster [CLUSTER_ADI] --cluster-version [YENI_DUGUM_SURUMU] --region [BOLGE]<\/code><\/pre>\n<\/div>\nOtomatik Y\u00fckseltmeler ve Bak\u0131m Pencereleri<\/h3>\n
Min\u00f6r S\u00fcr\u00fcm Geri Almalar\u0131: Felaket Kurtarma Senaryolar\u0131nda Hayat Kurtar\u0131c\u0131 Bir \u00d6zellik<\/h2>\n
Geri Alma \u0130htiyac\u0131n\u0131n Ortaya \u00c7\u0131k\u0131\u015f\u0131: Senaryolar ve Riskler<\/h3>\n
\n
Kontrol D\u00fczlemi Geri Alma Mekanizmas\u0131: Arka Planda Neler Oluyor?<\/h3>\n
Geri Alma S\u00fcrecinin \u0130\u015fleyi\u015fi ve Etkileri<\/h3>\n
gcloud<\/code> komut sat\u0131r\u0131 arac\u0131n\u0131 kullanabilirsiniz. \u00d6rne\u011fin:<\/p>\ngcloud container clusters upgrade [CLUSTER_ADI] --master --cluster-version [ONCEKI_KONTROL_DUZLEMI_SURUMU] --region [BOLGE]<\/code><\/pre>\n<\/div>\n\n
S\u00fcr\u00fcm Geri Alma Politikalar\u0131 ve S\u0131n\u0131rlamalar\u0131<\/h3>\n
Ger\u00e7ek D\u00fcnya Senaryosu: Bir Geri Alma \u00d6rne\u011fi ve Dersler<\/h2>\n
Yanl\u0131\u015f Giden Bir Y\u00fckseltme Hikayesi<\/h3>\n
unknown field<\/code>” (bilinmeyen alan) hatas\u0131 ald\u0131\u011f\u0131n\u0131 g\u00f6rd\u00fcler. Bu CRD, \u015firket i\u00e7i bir geli\u015ftirme ekibi taraf\u0131ndan yaz\u0131lm\u0131\u015ft\u0131 ve Kubernetes 1.26 API’sindeki belirli bir alan\u0131 kullan\u0131yordu. Kubernetes 1.27 ile birlikte, bu alan kald\u0131r\u0131lm\u0131\u015f veya de\u011fi\u015ftirilmi\u015fti ve OTS kontrol\u00f6r\u00fc bu de\u011fi\u015fikli\u011fe uyarlanmam\u0131\u015ft\u0131. Uygulama geli\u015ftirme ekibi, bu API de\u011fi\u015fikli\u011finden haberdar de\u011fildi veya testlerini yeterince yapmam\u0131\u015ft\u0131. Geri d\u00f6n\u00fc\u015f\u00fcm (rollback) plan\u0131 yap\u0131lmam\u0131\u015ft\u0131 ve panik ba\u015flad\u0131.<\/p>\nGeri Alma Karar\u0131 ve Uygulama<\/h3>\n
gcloud<\/code> komutunu kullanarak kontrol d\u00fczlemi geri alma i\u015flemini ba\u015flatt\u0131:<\/p>\ngcloud container clusters upgrade my-ecommerce-cluster --master --cluster-version 1.26.X-gke.Y --region europe-west1<\/code><\/pre>\n<\/div>\n1.26.X-gke.Y<\/code> burada 1.26 serisindeki \u00f6nceki kararl\u0131 s\u00fcr\u00fcm\u00fc temsil etmektedir. Geri alma i\u015flemi yakla\u015f\u0131k 15-20 dakika s\u00fcrd\u00fc. Kontrol d\u00fczlemi 1.26’ya geri d\u00f6nd\u00fc\u011f\u00fcnde, OTS kontrol\u00f6r\u00fc otomatik olarak yeniden ba\u015flat\u0131ld\u0131 ve API sunucusuna yapt\u0131\u011f\u0131 istekler tekrar ba\u015far\u0131l\u0131 olmaya ba\u015flad\u0131. M\u00fc\u015fteriler, sipari\u015flerini tekrar takip edebildiler ve kriz durumu kontrol alt\u0131na al\u0131nd\u0131.<\/p>\nAl\u0131nan Dersler ve Gelecek \u0130\u00e7in \u00d6neriler<\/h3>\n
\n
\u0130leri D\u00fczey \u0130pu\u00e7lar\u0131 ve En \u0130yi Uygulamalar<\/h2>\n
Y\u00fckseltme Stratejileri: Kanarya, Mavi\/Ye\u015fil Yakla\u015f\u0131mlar<\/h3>\n
\n
GKE Y\u00fckseltmelerinde Otomasyon ve CI\/CD Entegrasyonu<\/h3>\n
\n
terraform apply<\/code> komutuyla y\u00fckseltmeyi ba\u015flatabilirsiniz. Bu, insan hatas\u0131n\u0131 azalt\u0131r ve y\u00fckseltme s\u00fcre\u00e7lerinin daha tutarl\u0131 olmas\u0131n\u0131 sa\u011flar.<\/p>\nG\u00f6zlemleme (Observability) ve Uyar\u0131 Mekanizmalar\u0131<\/h3>\n
\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular<\/h3>\n