Size bir şey söyleyeyim, Kubernetes’e deploy yapmak sizi hâlâ yoruyor mu? Beni de yoruyordu. Hani YAML dosyalarını elle yazıp, kubectl apply (belki yanılıyorum ama) çalıştırıp, sonra ArgoCD UI’a geçip “acaba sync oldu mu?” diye kontrol ettiğiniz o döngüyü bilirsiniz. Geçen ay bir müşteri projesinde tam olarak bu sarmalın içindeydim — üç farklı ortama deploy yapıyordum ve her seferinde ArgoCD dashboard’unu açıp, Application manifest’i kontrol edip, sync policy’yi ayarlamak… Bitmiyor işte. Sonra Kiro CLI ile ArgoCD MCP server ikilisini keşfettim ve açık konuşayım, iş akışım bayağı değişti.
Bu yazıda terminalden doğal dille ArgoCD uygulamalarınızı nasıl yönetebileceğinizi anlatacağım (ciddiyim). Sadece teoride kalmayacağız — kurulumdan pratik kullanıma, avantajlardan dezavantajlara kadar her şeyi konuşacağız. Neyse, lafı fazla uzatmadan başlayalım.
GitOps Öncesi Dünya: kubectl apply ve Umut
Dur bir saniye. Önce şunu konuşalım: ArgoCD olmadan Kubernetes’e deploy yapmak nasıl bir şeydi? Çünkü bunu yaşamayanlar GitOps’un değerini tam kavrayamıyor bence.
2019’da çalıştığım bir fintech startup’ta — ismini vermeyeyim ama İstanbul’da küçük bir ekiptik — deployment süreci şöyleydi: Deployment, Service, ConfigMap YAML’larını elle yazıyordun, sonra dizüstünden kubectl apply -f çalıştırıyordun, kaynakların doğru namespace’te çalışıp çalışmadığını kontrol ediyordun, manifest’leri Git’e commit ediyordun (hatırlarsan tabii), ve bunu her ortam için tekrar tekrar, yorulana kadar yapıyordun; üstelik cluster state ile repo arasındaki senkronizasyonun bozulmayacağını umarak.
Maalesef hep bozuldu.
Bazı ekipler Helm chart’lara geçti. Templating tarafında faydalıydı ama drift problemini çözmüyordu. Diğerleri merge’de kubectl apply çalıştıran CI/CD pipeline’ları yazdı — daha iyiydi, ama hâlâ push-based ve kırılgan bir yapıydı. Mesela bir keresinde staging ortamında birisi elle bir ConfigMap değiştirmiş, pipeline tekrar çalışınca eski halini geri getirdi; iki saat boyunca “neden ayarlarım değişiyor?” diye araştırdık. Klasik drift hikayesi. Tanıdık geldi mi?
Sonra GitOps modeli geldi ve her şeyi tersine çevirdi. Cluster’a değişiklik push etmek yerine istenen durumu Git’te tanımlıyorsun, bir controller bunu pull ediyor ve otomatik olarak düzeltiyor. ArgoCD bu pattern’in en popüler implementasyonu. Güzel. Ama günlük yönetim — Application manifest yazma, sync policy ayarlama, UI’da tıklamalar — hâlâ zahmetli. İlginç, değil mi? İşte tam burada agentic yaklaşım devreye giriyor.
Kiro CLI + ArgoCD MCP: Ne İşe Yarıyor?
Vallahi, Kiro CLI, AWS tarafından geliştirilen bir komut satırı aracı. ArgoCD MCP server ise Model Context Protocol üzerinden ArgoCD’nin API’sini dışarıya açan bir katman. İkisini birleştirdiğinizde ne oluyor? Terminalden doğal dille ArgoCD uygulamalarınızı yönetebiliyorsunuz.
Yani “guestbook uygulamasını oluştur, otomatik sync açık olsun, namespace’i default olsun” diyorsunuz — Kiro bunu anlayıp ArgoCD’ye iletiyor. Hmm, kulağa fazla güzel geliyor değil mi? Bir düşüneyim… Evet, gerçekten çalışıyor ama bazı sınırlamaları da var, ona geleceğim (yanlış duymadınız)
MCP Nedir ve Neden Önemli?
Bilmem anlatabiliyor muyum, MCP — Model Context Protocol — standardize edilmiş bir araç arayüzü. Kiro’nun harici servislerle konuşmasını sağlıyor. Kısacası, argoCD MCP server bu protokolü kullanarak ArgoCD API’sini “tool” olarak sunuyor: uygulama listeleme, oluşturma, sync etme, kaynak ağacını görme, log çekme… Hepsi terminal üzerinden, doğal dille.
İtiraf edeyim, Bunu şöyle düşünün: ArgoCD’nin UI’ı bir grafik arayüz, CLI’ı bir komut satırı arayüzü. MCP server bunlara üçüncü bir katman ekliyor — doğal dil arayüzü. Arada bir “tercüman” var, o da Kiro.
Kurulum: Adım Adım Bağlantı
Ön Gereksinimler
Başlamadan önce şunlar elinizin altında olmalı:
- ArgoCD kurulu bir Kubernetes cluster’ı (EKS, GKE, minikube — fark etmez)
- ArgoCD API token’ı (bence en önemlisi)
- Kiro CLI kurulu
- Node.js v18 veya üzeri
ArgoCD henüz kurulu değilse en hızlı yol şu:
kubectl create namespace argocd
kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
# Yerel erişim için port-forward
kubectl port-forward svc/argocd-server -n argocd 8080:443Dürüst olmak gerekirse, Ha, bu arada — port-forward’u production’da kullanmayın tabi. Ingress veya LoadBalancer ile expose edin. Ben test ortamında port-forward kullanıyorum genelde, pratik oluyor, ama production’da bu işin ayrı bir derdi var.
API Token Almak
MCP server’ın ArgoCD ile konuşabilmesi için bir API token lazım. İki yol var.
UI üzerinden: Settings → Accounts → admin → Generate New → Token’ı kopyala.
CLI üzerinden: (inanın bana)
argocd account generate-token --account adminBen genelde CLI yolunu tercih ediyorum çünkü token’ı doğrudan bir environment variable’a atabiliyorum. Bir de şunu söyleyeyim — bu token’ı güvenli bir yerde saklayın. Bir arkadaşım (2024’te, Ankara’da bir DevOps ekibinde çalışıyordu) token’ı yanlışlıkla public repo’ya commit etmişti. Sonrasını anlatmama gerek yok sanırım. “Ups” demekle kurtulamıyorsunuz o durumdan.
Kiro CLI’a MCP Server Bağlama
Şimdi gelelim asıl birleştirme kısmına. Kiro Custom Agent yapılandırması oluşturuyoruz. Projenizin kök dizininde .kiro/settings/agent.md dosyası oluşturun:
# ArgoCD GitOps Agent
You are an ArgoCD assistant. Help users manage their Kubernetes
applications using GitOps.
## Tools
Use the ArgoCD MCP server tools to:
- List and inspect applications
- Create new applications with proper sync policies
- Sync applications and monitor health
- Get resource trees and logsBunu yaşayan biri olarak söyleyeyim, Sonra MCP server tanımını .kiro/settings/mcp.json dosyasına ekleyin:
{
"mcpServers": {
"argocd-mcp": {
"command": "npx",
"args": ["-y", "argocd-mcp"],
"env": {
"ARGOCD_BASE_URL": "https://localhost:8080",
"ARGOCD_API_TOKEN": "sizin-token-buraya",
"ARGOCD_INSECURE": "true"
}
}
}
}ARGOCD_INSECURE: true sadece self-signed certificate kullanıyorsanız gerekli. Production ortamında bunu false yapıp geçerli bir sertifika kullanmanızı şiddetle tavsiye ederim.Pratikte Kullanım: Doğal Dille GitOps
Eh, Kurulum tamam. Şimdi asıl eğlenceli kısma geçelim. Bu konuyla ilgili WhatsApp’ın Kullanıcı Adı Hamlesi: Numara Dönemi Bitiyor mu? yazımıza da göz atmanızı tavsiye ederim.
Uygulama Oluşturma
Terminalde Kiro’ya şunu yazıyorsunuz:
“ArgoCD’de guestbook-app adında bir uygulama oluştur. Kaynak repo: https://github.com/argoproj/argocd-example-apps, path: guestbook, hedef cluster: in-cluster, namespace: default. Otomatik sync ve self-heal açık olsun.”
Kiro bunu alıyor, ArgoCD MCP server üzerinden gerekli API çağrılarını yapıyor ve uygulama oluşturuluyor. Elle YAML yazmak yok. Arka planda şöyle bir manifest üretiyor:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: default
syncPolicy:
automated:
prune: true
selfHeal: trueGüzel, değil mi? Ama dur — bu basit bir örnek. Gerçek dünyada işler daha karmaşık tabii. Ona da geleceğim. Amazon’un 200 Milyar Dolarlık Hamlesi: Jassy’nin Sakin Ama Sert Cevabı yazımızda bu konuya da değinmiştik.
Durum Kontrolü ve Sync
“guestbook-app’in durumunu göster” dediğinizde sync status, health status, son sync zamanı gibi bilgileri alıyorsunuz. “guestbook-app’i sync et” dediğinizde manual sync tetikleniyor. Kaynak ağacını görmek istiyorsanız “guestbook-app’in resource tree’sini göster” yeterli. Bu konuyla ilgili SteamGPT Sessizce Geliyor: Valve’ın Yeni AI Hamlesi yazımıza da göz atmanızı tavsiye ederim.
Ben geçen hafta bir demo ortamında bunu test ettim — beş farklı microservice’i olan bir yapıyı yönetmeye çalıştım. Tek tek sync etmek, durum kontrolü yapmak… Kiro ile işler gerçekten hızlanıyor, valla şaşırdım açıkçası. Ama itiraf edeyim: karmaşık Helm values override’ları için hâlâ YAML’a dönmem gerekti. Neden önemli bu? Doğal dille “values.yaml’daki replicas’ı 3 yap” gibi şeyleri anlatmak bazen oldukça zor olabiliyor, neyse uzatmayalım.
Avantajlar ve Dezavantajlar: Dürüst Bir Değerlendirme
| Avantajlar | Dezavantajlar |
|---|---|
| YAML yazmadan hızlı uygulama oluşturma | Karmaşık Helm values override’larında yetersiz |
| Tek pencereden çoklu işlem (sync, health, logs) | MCP server henüz olgunlaşmamış, bazı API’lar eksik |
| Doğal dil ile düşük öğrenme eğrisi | Internet bağlantısı gerektiriyor (LLM çağrıları için) |
| CI/CD pipeline’larına tümleşik edilebilir | Production’da doğrudan kullanmak riskli olabilir |
| Custom agent tanımlarıyla genişletilebilir | Token yönetimi ve güvenlik ekstra dikkat istiyor |
İnanın, Açık konuşayım: bu araç küçük-orta ölçekli projeler ve dev/staging ortamları için baya iş görüyor. Ama 50+ microservice’li bir enterprise production ortamında… biraz daha pişmesi lazım. Kağıt üstünde süper, pratikte bazı edge case’lerde takılıyor. Tam da öyle.
Ve işler burada ilginçleşiyor.
Küçük Startup vs Enterprise: Kimin İşine Yarar?
İtiraf edeyim, Bir startup’ta — diyelim 3-5 kişilik bir ekipsiniz, 8-10 microservice’iniz var — bu setup inanılmaz verimli. ArgoCD UI’ına geçmeden terminalden her şeyi hallediyorsunuz ve manifest oluşturma süresi dakikalardan saniyelere düşüyor, hem de hiç abartmıyorum (yanlış duymadınız). Mesela yeni bir ortam kurarken, “şu repo’dan şu path’i deploy et, auto-sync aç” demek… çok rahat, gerçekten. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Enterprise seviyede ise durum farklı. RBAC politikaları, multi-cluster yönetimi, ApplicationSet’ler, custom health check’ler… Bunların hepsini doğal dille yönetmek şu an için gerçekçi değil. Ama basit operasyonlar — sync tetikleme, durum kontrolü, log çekme — bunlar enterprise’da da faydalı. Nitekim ben Claude Code 101: Dil Modellerini Söküp Takıyoruz yazısında da benzer agentic araçların gelişim sürecinden bahsetmiştim. Bu alan hızla olgunlaşıyor — şimdiki haline bakıp “idare eder” demek yanlış, ama şimdiden production’a almak için de acele etmeyin.
Ve işler burada ilginçleşiyor.
Burada, bir de şunu söyleyeyim: Claude Code Gateway: Kurumsal Erişimde Fark Yaratan Katman yazısında tartıştığımız kurumsal erişim kontrolleri burada da geçerli. MCP server’a kimin erişeceği, hangi token’ların hangi yetkilere sahip olacağı — bunları baştan planlayın. Sonradan düzeltmek çok daha can sıkıcı oluyor.
Dikkat Edilmesi Gerekenler ve İpuçları
Vallahi, Birkaç pratik tavsiye vereyim, deneyerek öğrendiklerimden:
- Token scope’unu daraltın: Admin token yerine sadece gerekli yetkilere sahip bir service account oluşturun. “En az yetki” prensibi burada da geçerli.
- Agent prompt’unu özelleştirin:
agent.mddosyasına ekibinize özel kurallar ekleyin. Mesela “her zaman pruning açık olsun” veya “production namespace’ine deploy yapma” gibi. - Dry-run alışkanlığı edinin: Kiro’ya “önce bana YAML’ı göster, sonra uygula” demeyi öğretin. Doğrudan apply etmek yerine önce review etmek çok daha güvenli.
- Log’ları takip edin: MCP server’ın yaptığı API çağrılarını loglayın. Bir şey ters giderse debug etmeniz kolaylaşır.
Ha, unuttum neredeyse — ARGOCD_INSECURE flag’ini production’da kesinlikle false yapın. Self-signed cert kullanıyorsanız sertifikayı güvenilir CA listesine ekleyin. Neden önemli bu? Ben bir keresinde bunu unuttuğum için 2 saat MITM senaryolarıyla uğraştım — gereksiz stres, kendinize yapmayın (evet, doğru duydunuz)
Sıkça Sorulan Sorular
Kiro CLI sadece ArgoCD ile mi çalışıyor?
Hayır. Kiro CLI, MCP protokolü üzerinden farklı servislerle dahil olabiliyor. Burada, argoCD MCP server sadece bir örnek. Farklı MCP server’lar yazarak veya kullanarak başka araçlarla da entegre edebilirsiniz — mesela Terraform, Vault gibi.
ArgoCD MCP server production ortamında güvenli mi?
Token yönetimine ve erişim kontrolüne dikkat ettiğiniz sürece kullanılabilir ama henüz çok yeni bir araç. Ben şu an staging ve dev ortamlarında kullanıyorum, production için biraz daha olgunlaşmasını bekliyorum. Mesela audit logging ve RBAC entegrasyonu konusunda gelişmeye ihtiyacı var.
Helm chart’larla birlikte kullanabilir miyim?
Evet, ArgoCD zaten Helm chart’ları destekliyor ve MCP server üzerinden Helm tabanlı Application’lar oluşturabilirsiniz. Ama karmaşık values override’ları için doğal dil yerine YAML kullanmanız daha sağlıklı olur.
Kiro CLI ücretsiz mi?
Kiro CLI, AWS tarafından sunuluyor ve şu an ücretsiz olarak kullanılabiliyor. Ancak LLM çağrıları için arka planda kullanılan model maliyetleri değişebilir. Güncel fiyatlandırmayı resmi dokümantasyondan kontrol etmenizi öneririm.
Mevcut ArgoCD kurulumuma zarar verir mi?
Peki, bunu yaşayan biri olarak söyleyeyim, MCP server salt okunur veya yazma modunda çalışabilir — bu tamamen verdiğiniz token’ın yetkilerine bağlı. Read-only token ile başlayıp, güvendiğinizde write yetkisi ekleyebilirsiniz. Mevcut Application tanımlarınıza dokunmaz, sadece API üzerinden işlem yapar.
Kaynaklar ve İleri Okuma
ArgoCD MCP Server — GitHub Deposu
Şahsen, ArgoCD Resmi Dokümantasyonu (en azından benim deneyimim böyle)
Kiro CLI Resmi Dokümantasyonu (ki bu çoğu kişinin gözünden kaçıyor)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
