Kubernetes d\u00fcnyas\u0131nda kaynaklar\u0131 y\u00f6netmek, deklaratif (declarative) yakla\u015f\u0131mla m\u00fcmk\u00fcnd\u00fcr ve Modern uygulama geli\u015ftirme ve da\u011f\u0131t\u0131m s\u00fcre\u00e7lerinde, sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131 her ge\u00e7en g\u00fcn artmaktad\u0131r. Mikroservis mimarileri, bulut yerel (cloud-native) uygulamalar ve s\u00fcrekli entegrasyon\/s\u00fcrekli da\u011f\u0131t\u0131m (CI\/CD) boru hatlar\u0131, altyap\u0131 y\u00f6netiminin de ayn\u0131 h\u0131zda evrilmesini gerektirmektedir. \u0130\u015fte bu noktada Kubernetes gibi konteyner orkestrasyon platformlar\u0131 devreye girer. Kubernetes, uygulamalar\u0131n\u0131z\u0131 \u00f6l\u00e7eklenebilir, hataya dayan\u0131kl\u0131 ve y\u00f6netilebilir bir \u015fekilde \u00e7al\u0131\u015ft\u0131rman\u0131za olanak tan\u0131r. Ancak bu g\u00fc\u00e7, do\u011fru kaynak y\u00f6netimi stratejileriyle birle\u015fti\u011finde ger\u00e7ek potansiyeline ula\u015f\u0131r.<\/p>\n Geleneksel sunucu y\u00f6netimi y\u00f6ntemlerinde, bir sunucuya SSH ile ba\u011flan\u0131p komutlar \u00e7al\u0131\u015ft\u0131rmak veya yap\u0131land\u0131rma dosyalar\u0131n\u0131 manuel olarak d\u00fczenlemek yayg\u0131n bir yakla\u015f\u0131md\u0131. Ancak binlerce konteynerin ve y\u00fczlerce mikroservisin \u00e7al\u0131\u015ft\u0131\u011f\u0131 dinamik bir ortamda bu y\u00f6ntemler s\u00fcrd\u00fcr\u00fclemez hale gelir. Her bir de\u011fi\u015fikli\u011fin manuel olarak yap\u0131lmas\u0131, insan hatas\u0131na a\u00e7\u0131k kap\u0131 b\u0131rak\u0131r, tutars\u0131z yap\u0131land\u0131rmalara yol a\u00e7ar ve felaket kurtarma senaryolar\u0131n\u0131 kabusa \u00e7evirir. Bu nedenle, Kubernetes gibi platformlar, altyap\u0131y\u0131 kod olarak (Infrastructure as Code – IaC) y\u00f6netme felsefesini benimser. Kaynaklar\u0131n\u0131z\u0131 YAML veya JSON format\u0131nda tan\u0131mlars\u0131n\u0131z ve Kubernetes’e bu tan\u0131mlar\u0131 uygulamas\u0131n\u0131 s\u00f6ylersiniz.<\/p>\n Peki, bu deklaratif y\u00f6netim yakla\u015f\u0131m\u0131 neden bu kadar kritik? \u00c7\u00fcnk\u00fc bu sayede sisteminizin “istenen durumunu” (desired state) a\u00e7\u0131k\u00e7a belirtirsiniz. \u00d6rne\u011fin, bir uygulaman\u0131n her zaman \u00fc\u00e7 kopyas\u0131n\u0131n (replica) \u00e7al\u0131\u015fmas\u0131n\u0131, belirli bir miktarda CPU ve belle\u011fe sahip olmas\u0131n\u0131 veya belirli a\u011f kurallar\u0131na uymas\u0131n\u0131 isteyebilirsiniz. Kubernetes, sizin belirtti\u011finiz bu durumu s\u00fcrekli olarak g\u00f6zlemler ve mevcut durum (current state) ile istenen durum aras\u0131nda bir tutars\u0131zl\u0131k oldu\u011funda otomatik olarak d\u00fczeltici aksiyonlar al\u0131r. Bu, sisteminizin kendi kendini iyile\u015ftirmesini ve belirtilen yap\u0131land\u0131rmaya her zaman uygun kalmas\u0131n\u0131 sa\u011flar. \u0130\u015fte Deklaratif Y\u00f6netim Nedir?<\/strong><\/p>\n Deklaratif y\u00f6netim, bir sistemin “nas\u0131l” bir duruma getirilece\u011fini de\u011fil, “hangi” durumda olmas\u0131 gerekti\u011fini tan\u0131mlad\u0131\u011f\u0131m\u0131z bir yakla\u015f\u0131md\u0131r. Geleneksel olarak, sistemleri y\u00f6netirken imperatif (imperative) bir yakla\u015f\u0131m benimseriz. \u00d6rne\u011fin, bir sunucuya ba\u011flan\u0131r, bir paketi kurmak i\u00e7in Deklaratif y\u00f6netimde ise, sistemin son durumunu (\u00f6rne\u011fin, “bir web uygulamas\u0131ndan 3 adet \u00e7al\u0131\u015fs\u0131n”, “bu uygulama 80 portundan eri\u015filebilir olsun”) bir yap\u0131land\u0131rma dosyas\u0131 (genellikle YAML veya JSON) arac\u0131l\u0131\u011f\u0131yla belirtiriz. Kubernetes gibi bir sistem, bu yap\u0131land\u0131rma dosyas\u0131n\u0131 okur ve bu istenen duruma ula\u015fmak i\u00e7in gerekli t\u00fcm ad\u0131mlar\u0131 kendi ba\u015f\u0131na atar. Bu yakla\u015f\u0131m, insan hatas\u0131n\u0131 en aza indirir, tekrarlanabilirli\u011fi art\u0131r\u0131r ve sistemin \u00f6ng\u00f6r\u00fclebilirli\u011fini sa\u011flar. \u0130stenen Durum (Desired State) Nedir?<\/strong><\/p>\n \u0130stenen durum, Kubernetes’e sa\u011flad\u0131\u011f\u0131n\u0131z YAML veya JSON manifest dosyalar\u0131nda tan\u0131mlad\u0131\u011f\u0131n\u0131z, k\u00fcmedeki kaynaklar\u0131n (Pod’lar, Deployment’lar, Service’ler vb.) ideal yap\u0131land\u0131rmas\u0131d\u0131r. \u00d6rne\u011fin, a\u015fa\u011f\u0131daki basit bir Deployment manifestosu, bir Nginx uygulamas\u0131n\u0131n istenen durumunu tan\u0131mlar:<\/p>\n Bu manifestoda, Kubernetes’e \u015funlar\u0131 s\u00f6yl\u00fcyoruz:<\/p>\n Siz bu manifestoyu \u0130stemci tarafl\u0131 uygulama, bir kayna\u011f\u0131 g\u00fcncellerken \u00fc\u00e7 farkl\u0131 bilgi par\u00e7as\u0131n\u0131 dikkate al\u0131r:<\/p>\n Diyelim ki bir Deployment kayna\u011f\u0131n\u0131z var. \u0130lk olarak, bir geli\u015ftirici a\u015fa\u011f\u0131daki YAML dosyas\u0131n\u0131 uygular:<\/p>\n \u015eimdi, bir operasyon m\u00fchendisi, bu Deployment’\u0131n CPU limitini art\u0131rmak ister ve ayn\u0131 anda Pod’lar\u0131n kaynaklar\u0131n\u0131 da g\u00fcnceller. Ancak, Daha sonra, geli\u015ftirici, kendi Bu mekanizma, basit senaryolarda i\u015fe yarasa da, \u00f6zellikle birden fazla ekibin ayn\u0131 kayna\u011f\u0131n farkl\u0131 alanlar\u0131n\u0131 y\u00f6netti\u011fi veya otomasyon ara\u00e7lar\u0131n\u0131n devreye girdi\u011fi karma\u015f\u0131k ortamlarda sorunlara yol a\u00e7abilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n manuel olarak yapt\u0131\u011f\u0131 bir de\u011fi\u015fikli\u011fin, ba\u015fka bir \u0130stemci tarafl\u0131 uygulaman\u0131n (Client-Side Apply) getirdi\u011fi karma\u015f\u0131kl\u0131klar ve \u00f6zellikle e\u015f zamanl\u0131 g\u00fcncellemelerde ortaya \u00e7\u0131kan sorunlar, Kubernetes toplulu\u011funu daha sa\u011flam ve \u00f6ng\u00f6r\u00fclebilir bir mekanizma aramaya itti. Bu aray\u0131\u015f\u0131n sonucunda ortaya \u00e7\u0131kan Server-Side Apply (SSA), Client-Side Apply’\u0131n temel zorluklar\u0131 \u015funlard\u0131:<\/p>\n Server-Side Apply, bu sorunlara \u00e7\u00f6z\u00fcm getirmek i\u00e7in geli\u015ftirilmi\u015ftir. Temel fikri, birle\u015ftirme mant\u0131\u011f\u0131n\u0131 istemciden ( SSA’n\u0131n anahtar kavram\u0131 “alan sahipli\u011fi”dir. Her kaynak alan\u0131 (\u00f6rne\u011fin, SSA’n\u0131n \u00e7al\u0131\u015fma ad\u0131mlar\u0131 \u015funlard\u0131r:<\/p>\n Bir kayna\u011f\u0131n Yukar\u0131daki \u00f6rnekte, Server-Side Apply, \u00f6zellikle GitOps yakla\u015f\u0131mlar\u0131nda ve birden fazla otomasyon arac\u0131n\u0131n (Helm, Argo CD, Flux CD vb.) ayn\u0131 k\u00fcmeyi y\u00f6netti\u011fi senaryolarda \u00e7ok daha sa\u011flam ve tercih edilen bir y\u00f6ntem haline gelmi\u015ftir. \u00c7ak\u0131\u015fmalar\u0131n API sunucusu taraf\u0131nda y\u00f6netilmesi, tutarl\u0131l\u0131\u011f\u0131 art\u0131r\u0131r ve beklenmedik davran\u0131\u015flar\u0131 en aza indirir.<\/p>\n Kubernetes’in benimsenmesiyle birlikte, b\u00fcy\u00fck kurulu\u015flar genellikle birden fazla geli\u015ftirme ekibinin, operasyon ekibinin ve g\u00fcvenlik ekibinin ayn\u0131 Kubernetes k\u00fcmesi \u00fczerinde \u00e7al\u0131\u015ft\u0131\u011f\u0131 senaryolarla kar\u015f\u0131la\u015f\u0131r. Bu durum, kaynak y\u00f6netimini karma\u015f\u0131kla\u015ft\u0131r\u0131r ve \u00f6zellikle istemci tarafl\u0131 uygulama (Client-Side Apply) kullan\u0131ld\u0131\u011f\u0131nda \u00e7e\u015fitli sorunlara yol a\u00e7abilir. Bu vaka analizinde, bu sorunlar\u0131 ve Server-Side Apply (SSA) ile nas\u0131l \u00e7\u00f6z\u00fclebileceklerini inceleyece\u011fiz.<\/p>\n Bir e-ticaret \u015firketi olan “H\u0131zl\u0131Teslimat A.\u015e.”de, “Uygulama A” ad\u0131nda kritik bir mikroservis bulunmaktad\u0131r. Bu uygulaman\u0131n Kubernetes Deployment’\u0131 \u00fc\u00e7 farkl\u0131 ekip taraf\u0131ndan y\u00f6netilmektedir:<\/p>\n Her ekip, kendi YAML dosyalar\u0131n\u0131 DevTeam, DevTeam, kendi SecTeam, acil bir g\u00fcvenlik a\u00e7\u0131\u011f\u0131n\u0131 kapatmak i\u00e7in bir Deployment’a H\u0131zl\u0131Teslimat A.\u015e., bu sorunlar\u0131 a\u015fmak i\u00e7in Server-Side Apply’a ge\u00e7meye karar verir. Her ekip, kendi \u015eimdi, e\u011fer OpsTeam yanl\u0131\u015fl\u0131kla kendi E\u011fer SecTeam, acil bir durumda Sonu\u00e7 olarak, Server-Side Apply, H\u0131zl\u0131Teslimat A.\u015e.’nin \u00e7oklu ekip ortam\u0131nda Kubernetes kaynaklar\u0131n\u0131 daha g\u00fcvenli, tutarl\u0131 ve \u00f6ng\u00f6r\u00fclebilir bir \u015fekilde y\u00f6netmesini sa\u011flam\u0131\u015ft\u0131r. Ekipler aras\u0131ndaki \u00e7ak\u0131\u015fmalar azalm\u0131\u015f, hata ay\u0131klama kolayla\u015fm\u0131\u015f ve operasyonel verimlilik artm\u0131\u015ft\u0131r.<\/p>\n A\u00e7\u0131klama:<\/strong> Baz\u0131 Kubernetes kaynak alanlar\u0131, bir kere ayarland\u0131ktan sonra de\u011fi\u015ftirilemez (immutable) \u00f6zelliktedir. \u00d6rne\u011fin, bir Pod’un konteyner ad\u0131 veya bir Service’in tipi (ClusterIP, NodePort, LoadBalancer) bazen de\u011fi\u015ftirilemez olabilir. Bu hatay\u0131 genellikle, mevcut bir kayna\u011f\u0131n immutable bir alan\u0131n\u0131 de\u011fi\u015ftirmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131zda al\u0131rs\u0131n\u0131z.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong> Immutable alanlar\u0131 de\u011fi\u015ftirmek i\u00e7in genellikle kayna\u011f\u0131 silip yeniden olu\u015fturman\u0131z gerekir. Ancak bu, uygulaman\u0131zda kesintiye yol a\u00e7abilir. Kesintisiz bir g\u00fcncelleme i\u00e7in, yeni yap\u0131land\u0131rmay\u0131 farkl\u0131 bir isimle olu\u015fturup, trafi\u011fi yava\u015f yava\u015f yeni kayna\u011fa y\u00f6nlendirebilirsiniz (mavi\/ye\u015fil da\u011f\u0131t\u0131m veya canary da\u011f\u0131t\u0131m stratejileri). E\u011fer Pod’un konteyner ad\u0131n\u0131 de\u011fi\u015ftirmeye \u00e7al\u0131\u015f\u0131yorsan\u0131z, Deployment’\u0131 silip yeniden olu\u015fturman\u0131z gerekecektir. Bir Service’in tipini de\u011fi\u015ftirmek istiyorsan\u0131z, Service’i silip yeni tip ile tekrar olu\u015fturman\u0131z gerekebilir.<\/p>\n<\/li>\n A\u00e7\u0131klama:<\/strong> Server-Side Apply (SSA) kullan\u0131rken, bir alan\u0131n sahipli\u011fi ba\u015fka bir y\u00f6neticiye (field manager) aitken o alan\u0131 de\u011fi\u015ftirmeye \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131zda bu hatay\u0131 al\u0131rs\u0131n\u0131z. SSA, \u00e7ak\u0131\u015fmalar\u0131 \u00f6nlemek ve alan sahipli\u011fini korumak i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n \u00c7\u00f6z\u00fcm:<\/strong><\/p>\nkubectl apply<\/code> komutu bu yakla\u015f\u0131m\u0131n kalbinde yer al\u0131r. Ancak bu basit g\u00f6r\u00fcnen komutun perde arkas\u0131nda neler d\u00f6nd\u00fc\u011f\u00fcn\u00fc hi\u00e7 merak ettiniz mi? Bu makalede, kubectl apply<\/code>‘\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, istemci tarafl\u0131 (client-side) ve sunucu tarafl\u0131 (server-side) uygulama mekanizmalar\u0131n\u0131, karma\u015f\u0131k senaryolardaki davran\u0131\u015flar\u0131n\u0131 ve en iyi uygulama y\u00f6ntemlerini derinlemesine inceleyece\u011fiz. Amac\u0131m\u0131z, bu komutun sadece bir dosya g\u00f6ndermekten \u00e7ok daha fazlas\u0131 oldu\u011funu, Kubernetes ortam\u0131n\u0131zda istikrarl\u0131 ve \u00f6ng\u00f6r\u00fclebilir bir durum yaratmak i\u00e7in kritik bir rol oynad\u0131\u011f\u0131n\u0131 g\u00f6stermektir.<\/p>\nKubernetes Kaynak Y\u00f6netimi Neden Bu Kadar \u00d6nemli?<\/h2>\n
kubectl apply<\/code> komutu, bu deklaratif felsefenin Kubernetes API’sine ula\u015fan ana kap\u0131s\u0131d\u0131r. Bu komut, kaynak tan\u0131mlar\u0131n\u0131z\u0131 API sunucusuna g\u00f6ndererek sistemin istenen duruma ge\u00e7mesini tetikler ve bu s\u00fcre\u00e7, d\u00fc\u015f\u00fcnd\u00fc\u011f\u00fcn\u00fczden \u00e7ok daha karma\u015f\u0131kt\u0131r.<\/p>\nDeklaratif Y\u00f6netim ve \u0130stenen Durum Kavram\u0131<\/h2>\n
kubectl apply<\/code> komutunun derinliklerine inmeden \u00f6nce, Kubernetes’in temelini olu\u015fturan iki \u00f6nemli kavram\u0131 anlamak \u015fartt\u0131r: deklaratif (declarative) y\u00f6netim ve istenen durum (desired state). Bu kavramlar, Kubernetes’in “kendi kendini iyile\u015ftiren” ve “otonom” yap\u0131s\u0131n\u0131n temelini olu\u015fturur ve kubectl apply<\/code>‘\u0131n \u00e7al\u0131\u015fma prensibini do\u011frudan etkiler.<\/p>\napt install my-package<\/code> komutunu \u00e7al\u0131\u015ft\u0131r\u0131r, bir servisi ba\u015flatmak i\u00e7in systemctl start my-service<\/code> yazar\u0131z. Bu, ad\u0131m ad\u0131m talimatlar vererek bir sonuca ula\u015fmaya \u00e7al\u0131\u015fmakt\u0131r. Imperatif yakla\u015f\u0131mlar, k\u00fc\u00e7\u00fck ve basit sistemlerde iyi \u00e7al\u0131\u015fsa da, b\u00fcy\u00fck ve karma\u015f\u0131k da\u011f\u0131t\u0131k sistemlerde h\u0131zla y\u00f6netilemez hale gelir.<\/p>\nkubectl apply<\/code>, i\u015fte bu deklaratif yap\u0131land\u0131rma dosyalar\u0131n\u0131 Kubernetes k\u00fcmesine iletmek i\u00e7in kullan\u0131lan birincil ara\u00e7t\u0131r.<\/p>\n\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: nginx-deployment\n labels:\n app: nginx\nspec:\n replicas: 3\n selector:\n matchLabels:\n app: nginx\n template:\n metadata:\n labels:\n app: nginx\n spec:\n containers:\n - name: nginx\n image: nginx:1.14.2\n ports:\n - containerPort: 80\n resources:\n limits:\n cpu: \"100m\"\n memory: \"128Mi\"\n requests:\n cpu: \"50m\"\n memory: \"64Mi\"\n <\/code><\/pre>\n<\/p><\/div>\n\n
nginx-deployment<\/code> ad\u0131nda bir Deployment kayna\u011f\u0131 olu\u015ftur.<\/li>\nreplicas: 3<\/code>) her zaman \u00e7al\u0131\u015f\u0131r durumda olsun.<\/li>\nnginx:1.14.2<\/code> imaj\u0131n\u0131 kullanan bir Nginx konteyneri i\u00e7ersin.<\/li>\nkubectl apply -f nginx-deployment.yaml<\/code> ile uygulad\u0131\u011f\u0131n\u0131zda, Kubernetes API Sunucusu bu istenen durumu al\u0131r. Ard\u0131ndan, Kubernetes kontrol d\u00fczlemi (control plane) i\u00e7indeki denetleyiciler (controllers), k\u00fcmenin mevcut durumunu s\u00fcrekli olarak bu istenen durumla kar\u015f\u0131la\u015ft\u0131r\u0131r. E\u011fer mevcut durumda 3 Nginx Pod’u \u00e7al\u0131\u015fm\u0131yorsa (\u00f6rne\u011fin, biri \u00e7\u00f6km\u00fc\u015fse veya hi\u00e7 olu\u015fturulmam\u0131\u015fsa), denetleyici yeni Pod’lar olu\u015fturarak veya mevcutlar\u0131 d\u00fczelterek istenen duruma ula\u015fmay\u0131 hedefler. Bu s\u00fcrekli senkronizasyon ve kendi kendini d\u00fczeltme mekanizmas\u0131, Kubernetes’i modern altyap\u0131 y\u00f6netiminde vazge\u00e7ilmez k\u0131lar. kubectl apply<\/code>‘\u0131n g\u00f6revi, bu istenen durumu Kubernetes’e do\u011fru ve g\u00fcvenli bir \u015fekilde bildirmektir.<\/p>\nkubectl apply<\/code> Nas\u0131l \u00c7al\u0131\u015f\u0131r? \u0130stemci Tarafl\u0131 Uygulama (Client-Side Apply)<\/h2>\nkubectl apply<\/code> komutunun temel \u00e7al\u0131\u015fma prensibi, bir YAML veya JSON dosyas\u0131nda tan\u0131mlanan istenen durumu Kubernetes k\u00fcmesine iletmektir. Ancak bu s\u00fcre\u00e7, basit bir dosya kopyalamadan \u00e7ok daha karma\u015f\u0131kt\u0131r. \u00d6zellikle Kubernetes’in ilk zamanlar\u0131ndan beri kullan\u0131lan istemci tarafl\u0131 uygulama (Client-Side Apply) mekanizmas\u0131, kaynaklar\u0131n g\u00fcncellenmesi s\u0131ras\u0131nda \u00fc\u00e7 y\u00f6nl\u00fc bir birle\u015ftirme (three-way merge) stratejisi kullan\u0131r. Bu strateji, birden fazla kullan\u0131c\u0131n\u0131n veya s\u00fcrecin ayn\u0131 kayna\u011f\u0131 e\u015f zamanl\u0131 olarak g\u00fcncellemeye \u00e7al\u0131\u015fmas\u0131 durumunda ortaya \u00e7\u0131kabilecek sorunlar\u0131 y\u00f6netmek i\u00e7in geli\u015ftirilmi\u015ftir.<\/p>\n\u00dc\u00e7 Y\u00f6nl\u00fc Birle\u015ftirme (Three-Way Merge) Mekanizmas\u0131<\/h3>\n
\n
kubectl apply<\/code> i\u015flemi s\u0131ras\u0131nda kullan\u0131lan yap\u0131land\u0131rma. Bu bilgi, kayna\u011f\u0131n metadata.annotations<\/code> alan\u0131nda kubectl.kubernetes.io\/last-applied-configuration<\/code> anahtar\u0131 alt\u0131nda saklan\u0131r. Bu, kubectl apply<\/code>‘\u0131n hangi alanlar\u0131 daha \u00f6nce y\u00f6netti\u011fini hat\u0131rlamas\u0131n\u0131 sa\u011flar.<\/li>\nkubectl apply -f my-resource.yaml<\/code> komutuyla sa\u011flam\u0131\u015f oldu\u011funuz YAML veya JSON dosyas\u0131. Bu, kayna\u011f\u0131n ula\u015fmas\u0131n\u0131 istedi\u011finiz en g\u00fcncel durumdur.<\/li>\n<\/ol>\nkubectl apply<\/code> komutu \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda, a\u015fa\u011f\u0131daki ad\u0131mlar izlenir:<\/p>\n\n
kubectl<\/code> istemcisi, belirtti\u011finiz YAML\/JSON dosyas\u0131n\u0131 okur ve yeni yap\u0131land\u0131rmay\u0131 belle\u011fine al\u0131r.<\/li>\nkubectl<\/code>, Kubernetes API sunucusuna bir GET iste\u011fi g\u00f6ndererek g\u00fcncellenmek istenen kayna\u011f\u0131n mevcut durumunu (canl\u0131 durumu) al\u0131r.<\/li>\nkubectl<\/code>, canl\u0131 durumdan metadata.annotations[\"kubectl.kubernetes.io\/last-applied-configuration\"]<\/code> alan\u0131ndaki de\u011feri \u00e7\u0131kar\u0131r. Bu, daha \u00f6nce kubectl apply<\/code> taraf\u0131ndan uygulanan yap\u0131land\u0131rmad\u0131r. E\u011fer bu annotation yoksa, kaynak ilk kez uygulan\u0131yor demektir.<\/li>\nkubectl<\/code> istemcisi, yeni yap\u0131land\u0131rma, canl\u0131 durum ve son uygulanan yap\u0131land\u0131rma aras\u0131ndaki fark\u0131 (diff) hesaplar. Bu \u00fc\u00e7 bilgiyi kullanarak, bir “birle\u015ftirme yamas\u0131” (merge patch) olu\u015fturur. Bu yama, canl\u0131 durumun nas\u0131l g\u00fcncellenmesi gerekti\u011fini belirtir. \u00d6rne\u011fin, e\u011fer yeni yap\u0131land\u0131rmada bir alan eklenmi\u015fse ve bu alan son uygulanan yap\u0131land\u0131rmada yoksa, yama bu alan\u0131 ekler. E\u011fer bir alan son uygulanan yap\u0131land\u0131rmada olup yeni yap\u0131land\u0131rmada yoksa, yama bu alan\u0131 canl\u0131 durumdan kald\u0131r\u0131r. E\u011fer bir alan hem son uygulanan hem de yeni yap\u0131land\u0131rmada varsa ve de\u011feri de\u011fi\u015fmi\u015fse, yama yeni de\u011feri uygular.<\/li>\nmetadata.annotations<\/code> alan\u0131na, o anki yeni yap\u0131land\u0131rman\u0131n bir kopyas\u0131n\u0131 kubectl.kubernetes.io\/last-applied-configuration<\/code> olarak ekler. Bu, bir sonraki kubectl apply<\/code> i\u015flemi i\u00e7in referans noktas\u0131 olacakt\u0131r.<\/li>\n<\/ol>\n\u00d6rnek Senaryo ve Sorunlar<\/h3>\n
\n# deploy-v1.yaml\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-app\nspec:\n replicas: 3\n template:\n spec:\n containers:\n - name: my-container\n image: my-image:v1\n resources:\n limits:\n cpu: \"100m\"\n <\/code><\/pre>\n<\/p><\/div>\nkubectl apply -f deploy-v1.yaml<\/code> komutu \u00e7al\u0131\u015ft\u0131r\u0131l\u0131r. Kaynak olu\u015fturulur ve last-applied-configuration<\/code> annotation’\u0131 eklenir.<\/p>\ndeploy-v1.yaml<\/code> dosyas\u0131nda sadece CPU limiti vard\u0131r. Operasyon m\u00fchendisi, kubectl edit deployment my-app<\/code> komutunu kullanarak do\u011frudan k\u00fcmedeki canl\u0131 kayna\u011f\u0131 d\u00fczenler ve bellek limitini de ekler:<\/p>\n\n# Canl\u0131 durumdaki de\u011fi\u015fiklik (kubectl edit ile yap\u0131ld\u0131)\n# ...\n resources:\n limits:\n cpu: \"200m\"\n memory: \"256Mi\" # Yeni eklenen alan\n# ...\n <\/code><\/pre>\n<\/p><\/div>\ndeploy-v1.yaml<\/code> dosyas\u0131n\u0131 (i\u00e7inde sadece CPU limiti olan\u0131) tekrar kubectl apply -f deploy-v1.yaml<\/code> ile uygulamak ister. Bu durumda:<\/p>\n\n
deploy-v1.yaml<\/code> (CPU: 100m)<\/li>\nkubectl apply<\/code>, \u00fc\u00e7 y\u00f6nl\u00fc birle\u015ftirmeyi yaparak, CPU limitini tekrar 100m’ye \u00e7ekecek, \u00e7\u00fcnk\u00fc bu, geli\u015ftiricinin dosyas\u0131nda belirtilen ve daha \u00f6nce kendisi taraf\u0131ndan uygulanan de\u011ferdir. Ancak, operasyon m\u00fchendisinin ekledi\u011fi memory: 256Mi<\/code> alan\u0131, geli\u015ftiricinin manifest dosyas\u0131nda hi\u00e7 ge\u00e7medi\u011fi ve last-applied-configuration<\/code> i\u00e7inde de olmad\u0131\u011f\u0131 i\u00e7in, kubectl apply<\/code> bu alan\u0131 dokunmadan b\u0131rak\u0131r. Bu durum, istemci tarafl\u0131 uygulaman\u0131n “sahip olmad\u0131\u011f\u0131” alanlara dokunmama prensibinden kaynaklan\u0131r.<\/p>\nkubectl apply<\/code> i\u015flemi taraf\u0131ndan beklenmedik bir \u015fekilde silinmesi veya \u00e7ak\u0131\u015fmalar\u0131n fark edilmemesi gibi durumlar ortaya \u00e7\u0131kabilir. \u0130\u015fte bu t\u00fcr sorunlar\u0131 \u00e7\u00f6zmek i\u00e7in Server-Side Apply (Sunucu Tarafl\u0131 Uygulama) geli\u015ftirilmi\u015ftir.<\/p>\nServer-Side Apply (SSA): Yeni Nesil Yakla\u015f\u0131m ve Alan Sahipli\u011fi<\/h2>\n
kubectl apply<\/code> komutunun \u00e7al\u0131\u015fma \u015feklini k\u00f6kten de\u011fi\u015ftiren ve Kubernetes kaynak y\u00f6netiminde yeni bir d\u00f6nemi ba\u015flatan bir yakla\u015f\u0131md\u0131r. SSA, \u00f6zellikle \u00e7ok kullan\u0131c\u0131l\u0131 ve \u00e7ok ara\u00e7l\u0131 ortamlarda kaynak y\u00f6netimini basitle\u015ftirmeyi ve \u00e7ak\u0131\u015fmalar\u0131 daha etkin bir \u015fekilde ele almay\u0131 hedefler.<\/p>\nNeden Server-Side Apply?<\/h3>\n
\n
last-applied-configuration<\/code> Annotation’\u0131n\u0131n Y\u00fck\u00fc:<\/strong> Her kaynakta bu annotation’\u0131n tutulmas\u0131, kayna\u011f\u0131n boyutunu art\u0131r\u0131r ve API sunucusunda ek y\u00fck olu\u015fturur. Ayr\u0131ca, bu annotation’\u0131n manuel olarak silinmesi veya bozulmas\u0131 durumunda beklenmedik davran\u0131\u015flar ortaya \u00e7\u0131kabilir.<\/li>\nkubectl<\/code>) al\u0131p do\u011frudan Kubernetes API sunucusuna ta\u015f\u0131makt\u0131r. Bu sayede, API sunucusu, kaynaklar\u0131n g\u00fcncellenmesi s\u0131ras\u0131nda daha ak\u0131ll\u0131 kararlar alabilir ve alan sahipli\u011fini (field ownership) takip edebilir.<\/p>\nServer-Side Apply Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
spec.replicas<\/code>, spec.template.spec.containers[0].image<\/code>), onu en son g\u00fcncelleyen “y\u00f6netici” (field manager) taraf\u0131ndan sahip olunur. Bir y\u00f6netici, bir alan\u0131n de\u011ferini de\u011fi\u015ftirdi\u011finde, o alan\u0131n sahibi olur. E\u011fer ba\u015fka bir y\u00f6netici ayn\u0131 alan\u0131n de\u011ferini de\u011fi\u015ftirmeye \u00e7al\u0131\u015f\u0131rsa, bir \u00e7ak\u0131\u015fma (conflict) olu\u015fur ve API sunucusu bu durumu bildirir.<\/p>\n\n
kubectl apply --server-side -f my-resource.yaml<\/code> komutuyla, istemci manifest dosyas\u0131n\u0131 do\u011frudan Kubernetes API sunucusuna g\u00f6nderir. \u0130stemci, bu noktada canl\u0131 durumu veya son uygulanan yap\u0131land\u0131rmay\u0131 \u00e7ekmez.<\/li>\n\n
--field-manager<\/code> parametresiyle belirtilen veya varsay\u0131lan olarak kubectl<\/code> olan) kontrol eder.<\/li>\n\n
--force-conflicts<\/code> (k\u0131saca -f<\/code>) bayra\u011f\u0131n\u0131 kullanmad\u0131ysan\u0131z, API sunucusu bir hata d\u00f6nd\u00fcr\u00fcr ve i\u015flemi reddeder. Bu, yanl\u0131\u015fl\u0131kla ba\u015fkas\u0131n\u0131n yapt\u0131\u011f\u0131 de\u011fi\u015fikliklerin \u00fczerine yaz\u0131lmas\u0131n\u0131 engeller.<\/li>\n--force-conflicts<\/code> bayra\u011f\u0131n\u0131 kullan\u0131rsan\u0131z, API sunucusu \u00e7ak\u0131\u015fan alan\u0131n sahipli\u011fini sizden yana de\u011fi\u015ftirir ve de\u011feri g\u00fcnceller. Bu, “ben bu alan\u0131 y\u00f6netmek istiyorum, di\u011ferlerinin de\u011fi\u015fikliklerini ge\u00e7ersiz say\u0131yorum” demektir.<\/li>\nmanagedFields<\/code>) ekler. Bu, last-applied-configuration<\/code> annotation’\u0131n\u0131n yerini al\u0131r.<\/li>\n<\/ol>\nManagedFields \u00d6rne\u011fi<\/h3>\n
managedFields<\/code> b\u00f6l\u00fcm\u00fc, kimin hangi alanlar\u0131 y\u00f6netti\u011fini g\u00f6sterir. \u00d6rne\u011fin, bir Deployment’\u0131n managedFields<\/code> \u00e7\u0131kt\u0131s\u0131 \u015f\u00f6yle g\u00f6r\u00fcnebilir:<\/p>\n\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-app\n managedFields:\n - apiVersion: apps\/v1\n fieldsType: FieldsV1\n fieldsV1:\n f:metadata:\n f:labels:\n f:app: {}\n f:spec:\n f:replicas: {}\n f:selector: {}\n f:template:\n f:metadata:\n f:labels:\n f:app: {}\n f:spec:\n f:containers:\n k:{\"name\":\"my-container\"}:\n f:image: {}\n f:name: {}\n f:resources:\n f:limits:\n f:cpu: {}\n manager: kubectl\n operation: Apply\n time: \"2023-10-26T10:00:00Z\"\n - apiVersion: apps\/v1\n fieldsType: FieldsV1\n fieldsV1:\n f:spec:\n f:template:\n f:spec:\n f:containers:\n k:{\"name\":\"my-container\"}:\n f:resources:\n f:limits:\n f:memory: {}\n manager: my-ops-tool\n operation: Apply\n time: \"2023-10-26T10:05:00Z\"\n <\/code><\/pre>\n<\/p><\/div>\nkubectl<\/code> y\u00f6neticisi spec.replicas<\/code> ve spec.template.spec.containers[0].image<\/code> gibi alanlara sahipken, my-ops-tool<\/code> adl\u0131 ba\u015fka bir y\u00f6netici spec.template.spec.containers[0].resources.limits.memory<\/code> alan\u0131na sahiptir. Bu, farkl\u0131 ara\u00e7lar\u0131n veya ekiplerin ayn\u0131 kayna\u011f\u0131n farkl\u0131 y\u00f6nlerini g\u00fcvenli bir \u015fekilde y\u00f6netebilmesini sa\u011flar.<\/p>\nVaka Analizi: \u00c7oklu Ekip Ortam\u0131nda Kaynak Y\u00f6netimi Sorunlar\u0131 ve \u00c7\u00f6z\u00fcmleri<\/h2>\n
Senaryo: “Uygulama A” Deployment’\u0131n\u0131n Karma\u015f\u0131k Y\u00f6netimi<\/h3>\n
\n
Client-Side Apply ile Ortaya \u00c7\u0131kan Sorunlar<\/h3>\n
kubectl apply<\/code> ile uygulad\u0131\u011f\u0131nda a\u015fa\u011f\u0131daki sorunlar ortaya \u00e7\u0131km\u0131\u015ft\u0131r:<\/p>\n\n
nginx:1.20<\/code> imaj\u0131n\u0131 nginx:1.21<\/code> olarak g\u00fcncellemek i\u00e7in kendi deployment.yaml<\/code> dosyas\u0131n\u0131 uygular. Bir s\u00fcre sonra, OpsTeam, uygulaman\u0131n yo\u011funlu\u011funu azaltmak i\u00e7in replika say\u0131s\u0131n\u0131 3’ten 5’e \u00e7\u0131karmak amac\u0131yla kendi deployment.yaml<\/code> dosyas\u0131n\u0131 uygular. Ancak, OpsTeam’in dosyas\u0131 eski bir imaj s\u00fcr\u00fcm\u00fcn\u00fc (nginx:1.20<\/code>) i\u00e7erebilir, \u00e7\u00fcnk\u00fc DevTeam’in yapt\u0131\u011f\u0131 de\u011fi\u015fiklikten habersizdir. Sonu\u00e7 olarak, OpsTeam’in kubectl apply<\/code> i\u015flemi, replika say\u0131s\u0131n\u0131 g\u00fcncellerken, imaj s\u00fcr\u00fcm\u00fcn\u00fc tekrar eski haline (nginx:1.20<\/code>) d\u00f6nd\u00fcrebilir. Bu durum, DevTeam’in yapt\u0131\u011f\u0131 de\u011fi\u015fikli\u011fin \u00fczerine yaz\u0131lmas\u0131na ve uygulaman\u0131n beklenmedik bir \u015fekilde eski bir s\u00fcr\u00fcme d\u00f6nmesine neden olur.<\/p>\n<\/li>\nlast-applied-configuration<\/code> \u00c7ak\u0131\u015fmalar\u0131 ve Bozulmalar:<\/strong>\ndeployment.yaml<\/code> dosyas\u0131n\u0131 uygulad\u0131\u011f\u0131nda, kayna\u011f\u0131n last-applied-configuration<\/code> annotation’\u0131 DevTeam’in dosyas\u0131n\u0131n i\u00e7eri\u011fiyle g\u00fcncellenir. OpsTeam ayn\u0131 kayna\u011fa kendi deployment.yaml<\/code> dosyas\u0131n\u0131 uygulad\u0131\u011f\u0131nda, bu annotation OpsTeam’in dosyas\u0131n\u0131n i\u00e7eri\u011fiyle g\u00fcncellenir. Bu, her kubectl apply<\/code> i\u015flemiyle annotation’\u0131n s\u00fcrekli de\u011fi\u015fmesi anlam\u0131na gelir. E\u011fer bir ekip, kubectl edit<\/code> ile manuel bir de\u011fi\u015fiklik yaparsa, last-applied-configuration<\/code> annotation’\u0131 g\u00fcncellenmez ve sonraki kubectl apply<\/code> i\u015flemi s\u0131ras\u0131nda bu manuel de\u011fi\u015fiklikler beklenmedik bir \u015fekilde silinebilir.<\/p>\n<\/li>\nsecurityContext<\/code> eklemek \u00fczere kubectl edit deployment my-app<\/code> komutunu kullan\u0131r. Bu de\u011fi\u015fiklik do\u011frudan k\u00fcmede yap\u0131l\u0131r. Birka\u00e7 g\u00fcn sonra, DevTeam veya OpsTeam, kendi versiyonlar\u0131ndaki deployment.yaml<\/code> dosyas\u0131n\u0131 kubectl apply<\/code> ile uygulad\u0131\u011f\u0131nda, bu dosyalar securityContext<\/code> alan\u0131n\u0131 i\u00e7ermedi\u011fi i\u00e7in, \u00fc\u00e7 y\u00f6nl\u00fc birle\u015ftirme s\u0131ras\u0131nda bu alan last-applied-configuration<\/code>‘da da yer almad\u0131\u011f\u0131ndan, canl\u0131 durumdan silinebilir. Bu durum, g\u00fcvenlik a\u00e7\u0131\u011f\u0131n\u0131n tekrar ortaya \u00e7\u0131kmas\u0131na neden olur.<\/p>\n<\/li>\n<\/ol>\nServer-Side Apply (SSA) ile \u00c7\u00f6z\u00fcmler<\/h3>\n
kubectl apply --server-side --field-manager=\n
\n
--field-manager=DevTeam<\/code> kullan\u0131r. B\u00f6ylece spec.template.spec.containers[0].image<\/code> alan\u0131n\u0131n sahibi DevTeam olur.<\/li>\n--field-manager=OpsTeam<\/code> kullan\u0131r. B\u00f6ylece spec.replicas<\/code> alan\u0131n\u0131n sahibi OpsTeam olur.<\/li>\nsecurityContext<\/code> eklerken --field-manager=SecTeam<\/code> kullan\u0131r. B\u00f6ylece spec.template.spec.securityContext<\/code> alan\u0131n\u0131n sahibi SecTeam olur.<\/li>\n<\/ul>\ndeployment.yaml<\/code> dosyas\u0131nda eski bir imaj s\u00fcr\u00fcm\u00fc belirtirse ve --field-manager=OpsTeam<\/code> ile uygulamaya \u00e7al\u0131\u015f\u0131rsa, API sunucusu bir \u00e7ak\u0131\u015fma tespit eder. \u00c7\u00fcnk\u00fc spec.template.spec.containers[0].image<\/code> alan\u0131n\u0131n sahibi DevTeam’dir. API sunucusu, OpsTeam’e bir hata mesaj\u0131 d\u00f6nd\u00fcr\u00fcr ve i\u015flemi reddeder. OpsTeam, bu hatay\u0131 g\u00f6rerek DevTeam ile ileti\u015fime ge\u00e7ebilir veya --force-conflicts<\/code> bayra\u011f\u0131n\u0131 kullanarak DevTeam’in sahipli\u011fini zorla alabilir (bu genellikle dikkatli kullan\u0131lmas\u0131 gereken bir se\u00e7enektir).<\/p>\n<\/li>\nlast-applied-configuration<\/code> annotation’\u0131n\u0131n art\u0131k kullan\u0131lmas\u0131na gerek kalmaz. Her alan\u0131n sahibi managedFields<\/code> b\u00f6l\u00fcm\u00fcnde a\u00e7\u0131k\u00e7a belirtildi\u011fi i\u00e7in, hangi ekibin hangi alandan sorumlu oldu\u011fu kolayca anla\u015f\u0131l\u0131r. Bu, hata ay\u0131klamay\u0131 ve sorumluluk takibini basitle\u015ftirir.<\/p>\n<\/li>\nkubectl edit<\/code> ile bir de\u011fi\u015fiklik yaparsa, bu de\u011fi\u015fiklik varsay\u0131lan olarak kubectl-edit<\/code> ad\u0131nda bir y\u00f6netici taraf\u0131ndan yap\u0131lm\u0131\u015f gibi kaydedilir. Di\u011fer ekipler kubectl apply --server-side<\/code> kulland\u0131\u011f\u0131nda, SecTeam’in yapt\u0131\u011f\u0131 de\u011fi\u015fiklikler, e\u011fer di\u011fer ekiplerin manifest dosyalar\u0131nda bu alanlar belirtilmemi\u015fse, \u00fczerine yaz\u0131lmaz. E\u011fer di\u011fer ekipler bu alanlar\u0131 kendi manifestolar\u0131na ekler ve --force-conflicts<\/code> kullanmazsa, API sunucusu \u00e7ak\u0131\u015fma hatas\u0131 verir ve SecTeam’in yapt\u0131\u011f\u0131 de\u011fi\u015fikli\u011fi korur. Bu, manuel m\u00fcdahalelerin yanl\u0131\u015fl\u0131kla kaybolmas\u0131n\u0131 b\u00fcy\u00fck \u00f6l\u00e7\u00fcde engeller.<\/p>\n<\/li>\n<\/ol>\nYayg\u0131n Hatalar ve \u00c7\u00f6z\u00fcmleri<\/h2>\n
kubectl apply<\/code> komutu g\u00fc\u00e7l\u00fc olsa da, yanl\u0131\u015f kullan\u0131ld\u0131\u011f\u0131nda veya beklenmedik durumlarla kar\u015f\u0131la\u015f\u0131ld\u0131\u011f\u0131nda \u00e7e\u015fitli hatalara yol a\u00e7abilir. Bu b\u00f6l\u00fcmde, s\u0131k kar\u015f\u0131la\u015f\u0131lan baz\u0131 hatalar\u0131 ve bunlar\u0131n olas\u0131 \u00e7\u00f6z\u00fcmlerini inceleyece\u011fiz.<\/p>\n\n
Hata: “The request is invalid: patch: Invalid value: “null”: field is immutable”<\/h3>\n
Hata: “Error from server (Conflict): conflicts with other field managers” (Server-Side Apply kullan\u0131rken)<\/h3>\n
\n
--force-conflicts<\/code> Kullan\u0131m\u0131:<\/strong> E\u011fer bu alan\u0131 ger\u00e7ekten siz y\u00f6netmek istiyorsan\u0131z ve di\u011fer y\u00f6neticinin de\u011fi\u015fikliklerini ge\u00e7ersiz k\u0131lmaya haz\u0131rsan\u0131z, kubectl apply --server-side --force-conflicts -f my-resource.yaml<\/code> komutunu kullanabilirsiniz. Ancak bu, dikkatli kullan\u0131lmas\u0131 gereken bir se\u00e7enektir, \u00e7\u00fcnk\u00fc ba\u015fkas\u0131n\u0131n de\u011fi\u015fikliklerini zorla \u00fczerine yazars\u0131n\u0131z.<\/li>\n--field-manager<\/code> Belirtme:<\/strong> Her ekibin veya arac\u0131n kendi --field-manager<\/code> ad\u0131n\u0131 belirtmesi, \u00e7ak\u0131\u015fmalar\u0131 daha \u015feffaf hale getirir ve kimin hangi alandan sorumlu oldu\u011funu kolayca g\u00f6rmeyi sa\u011flar.<\/li>\n<\/ul>\n<\/li>\nHata: “Error from server (NotFound): deployments.apps “my-app” not found”<\/h3>\n