> For the complete documentation index, see [llms.txt](https://docs.kangal.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kangal.dev/tr/migration/kong.md). # Kong'dan geçiş Bu rehber Kong'dan Kangal'a kontrollü geçişi açıklar. Kangal benzer ağ geçidi varlıkları kullanır, ancak Kong Admin API veya decK'nin doğrudan yerine geçmez. Açık bir model dönüşümü, eklenti incelemesi, güvenlik incelemesi ve trafik geçişi planlayın. ## Geçiş ilkeleri 1. Dönüştürmeden önce envanter çıkarın. 2. Yalnızca varlık adlarını değil, davranışı eşleyin. 3. Dışa aktarılmış düz metin değerleri değil, gizli bilgi referanslarını taşıyın. 4. Her yazma işleminden önce doğrulama ve fark karşılaştırması çalıştırın. 5. Trafiği geçirmeden önce iki ağ geçidini temsilî trafikle karşılaştırın. 6. Kangal kabulü tamamlanana kadar kaynak yapılandırmayı değiştirmeyin. 7. Geri dönüşü yalnızca dağıtıma göre değil, trafik sahipliği ve veri değişikliklerine göre tanımlayın. ## Kaynak eşlemesi | Kong kavramı | Kangal hedefi | Geçiş notu | | ------------------------------ | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | Workspace/control-plane sınırı | Tenant, workspace ve gateway | Varlıkları içe aktarmadan önce kiracılık ve sahiplik kararlarını verin | | Service | Service | Protokolü, hedef URL'yi veya upstream referansını, zaman aşımlarını, yeniden denemeleri ve gateway kapsamını yeniden doğrulayın | | Route | Route | Host, path, method, header, query, SNI, strip-path, preserve-host ve öncelik davranışını yeniden sınayın | | Upstream | Upstream | Yük dengeleme ve sağlık politikasını açıkça yeniden oluşturun | | Target | Target | Host/port ve ağırlık amacını koruyun; sağlık durumunu canlı kontrollerle yeniden oluşturun | | Consumer | Consumer | Kimlik bilgisi oluşturmadan önce yinelenen kullanıcı adlarını ve tenant sahipliğini çözün | | Credential | Consumer credential | Desteklenen Kangal türleri API key, HMAC, basic ve JWT'dir; geçiş sırasında yenileyin | | Plugin | Yerleşik veya paketlenmiş eklenti | Eklenti adlarının ve şemalarının aynı olduğunu varsaymayın | | Certificate ve SNI | Certificate, CA certificate ve SNI | Onaylı gizli bilgi/sertifika yoluyla içe aktarın; sunulan zinciri doğrulayın | | Vault reference | Tenant kapsamlı vault reference | Onaylı bir Kangal `vault://` sağlayıcı yoluna dönüştürün | | Declarative state | Kangal config bundle | Kangal YAML/JSON biçimine dönüştürün; decK dosyasını değiştirmeden göndermeyin | Özel Lua kodu, haricî eklenti sunucuları, özel mülk eklentiler ve yan etkiler ayrı uygulama ve performans incelemesi gerektirir. Özellik matrisindeki eşleşen bir etiket; istek sırası, hata davranışı veya yapılandırma anlamının eşit olduğunu kanıtlamaz. ## Uyumluluk endpoint'leri Kangal, geçiş sırasında istemci değişikliklerini azaltmak için aşağıdaki sınırlı Kong tarzı iç içe Admin API alias'larını sunar: ``` GET|POST /api/v1/admin/gateways/{gateway_id}/services/{service_id_or_name}/routes GET|POST /api/v1/admin/gateways/{gateway_id}/upstreams/{upstream_id}/targets GET|POST /api/v1/admin/gateways/{gateway_id}/certificates/{certificate_id}/snis GET|POST /api/v1/admin/consumers/{consumer_id}/credentials ``` Sürümsüz `/admin/...` biçimleri de uyumluluk amacıyla kayıtlıdır. Bu alias'lar Kangal yönetici kimlik doğrulamasını ve Kangal tenant kapsamını uygular. Service route alias'ı service kimliğini veya adını kabul eder; target oluştururken `target`, target adı için alias olarak kullanılabilir. Bu alias'ları yalnızca listelenen iç içe kaynak işlemleri için kullanın. Bildirimsel yapılandırmayı ve diğer tüm yönetim akışlarını trafik geçişinden önce Kangal yapılandırma paketine, CLI'a veya sürümlü Admin API'a taşıyın. ## Aşama 1: envanter Kaynak bildirimsel yapılandırmayı onaylı Kong/decK iş akışıyla dışa aktarın ve erişimi kısıtlı geçiş kanıtı olarak saklayın. Şunları kaydedin: * Kong ve decK sürümleri, dağıtım topolojisi, workspace'ler ve data plane'ler; * tüm kapsamlardaki service, route, upstream, target, consumer, credential, certificate, SNI, vault ve eklenti örnekleri; * route eşleşme kuralları, path işleme, protokol, zaman aşımı, yeniden deneme, buffering ve header davranışı; * eklenti sırası, özel kod, haricî çağrılar, fail-open/fail-closed davranışı ve gizli alanlar; * güncel istek hacmi, gecikme, hatalar, 4xx/5xx dağılımı, upstream sağlığı, bağlantı davranışı ve hız sınırı durumu; * DNS TTL, load balancer ağırlıkları, istemci sertifikası beklentileri ve geri dönüş yolu. Dışa aktarımdaki credential değerlerini dönüştürülen Kangal dosyasına koymayın. Yeni credential veya vault reference oluşturun ve geçiş sırasında istemcileri yenileyin. ## Aşama 2: dönüştürme Tenant kapsamlı bir Kangal paketi oluşturun. İlişkiler gerektiriyorsa kararlı kimlikler verin; aksi durumda belirlenimci adlar kullanın ve bağımlı kayıtları eklemeden önce oluşan kimlikleri doğrulayın. ```yaml tenant_id: acme gateways: - id: gw-edge tenant_id: acme name: edge services: - id: svc-orders tenant_id: acme gateway_id: gw-edge name: orders url: https://orders.internal.example routes: - tenant_id: acme gateway_id: gw-edge service_id: svc-orders service_name: orders path: /orders methods: [GET, POST] strip_path: true preserve_host: false upstreams: [] targets: [] consumers: [] consumer_credentials: [] certificates: [] snis: [] vaults: [] ``` Doğrudan service hedefini `url` ile tanımlayın. Yönetilen bir backend havuzu için `url` alanını kullanmayın; service üzerinde `upstream_id` veya `upstream_name` belirtin ve referans verilen upstream ile target kayıtlarını pakete ekleyin. `upstream_url`, gateway veya service paket alanı değildir. Her seferinde tek gateway dönüştürün. Kaynak kimliği, Kangal kimliği/adı, sahibi, dönüşüm durumu, doğrulama sonucu ve istisna nedenini içeren açık bir eşleme dosyası tutun. Eşleme dosyasına kaynak dışa aktarımını veya gizli bilgileri eklemeyin. ## Aşama 3: doğrulama ve önizleme Bir yönetici context'i kaydedip genel kullanıma açık CLI'ı çalıştırın: ```bash python scripts/kangalctl.py login \ --api-url "$KANGAL_API" \ --token "$KANGAL_ADMIN_TOKEN" \ --tenant-id acme \ --context-name migration python scripts/kangalctl.py validate kangal-acme.yaml --strict python scripts/kangalctl.py diff kangal-acme.yaml --tenant-id acme --strict python scripts/kangalctl.py sync kangal-acme.yaml \ --tenant-id acme \ --snapshot-note "pre-migration preview" \ --created-by migration-operator ``` `sync`, `--apply` verilmedikçe deneme çalışması yapar. Doğrulama hatalarını ve uyarılarını, parmak izini, ekleme/güncelleme/atlama sayılarını, kaldırılmış kaynakları ve değişen her gizli bilgi referansını inceleyin. Katı doğrulama; route'un service'e ve route/service'in upstream'e yönelik paket içinde eksik kalan referanslarını hataya dönüştürür. Her kaynak alanını doğrulamaz, canlı durumdaki referansları çözmez, upstream erişilebilirliğini veya eklenti eşdeğerliğini kanıtlamaz. ## Aşama 4: hazırlık ortamında uygulama ```bash python scripts/kangalctl.py sync kangal-acme.yaml \ --tenant-id acme \ --apply \ --snapshot-note "Kong migration staging apply öncesi" \ --created-by migration-operator ``` Uygulama akışı doğrulama, fark karşılaştırması ve önizleme yapar; uygulama öncesi Kangal yapılandırma snapshot'ı oluşturur ve paketi içe aktarır. Snapshot bir MongoDB yedeği değildir ve haricî sistemleri içermez. Uygulama sonrasında: 1. Credential'ları onaylı gizli bilgi kanalıyla oluşturun veya yenileyin. 2. Service, route, upstream, target, consumer, certificate ve eklenti sayılarını doğrulayın. 3. Başarılı ve başarısız kimlik doğrulama durumlarını sınayın. 4. Route eşleşmesi, path/header dönüşümleri, yeniden deneme, zaman aşımı, yük dengeleme, sağlık kontrolleri, hız sınırları ve hata yanıtlarını karşılaştırın. 5. Kullanılıyorsa WebSocket, gRPC, TCP, TLS/mTLS, streaming ve büyük gövde testlerini çalıştırın. 6. Logları, metrikleri, trace'leri, gecikmeyi, upstream hata oranını ve consumer kimliğini karşılaştırın. 7. Tenant'lar arası olumsuz testlerle tenant yalıtımını ve yönetici RBAC'ini doğrulayın. ## Aşama 5: shadow ve canary trafik Yazma işlemlerini yinelemeyecek replay veya gölge trafik kullanın. Durum değiştiren isteklerde sentetik tenant, idempotency key veya salt okunur test path'i kullanın. Yakalanan payload'ları ve yetkilendirme materyalini maskeleyin. Önce küçük ve gözlemlenebilir bir istemciyi ya da load balancer ağırlığını taşıyın. Her adımı normal önbellek, bağlantı, yeniden deneme ve hız sınırı pencerelerini kapsayacak kadar bekletin. Şunları karşılaştırın: * route ve durum kodu bazında başarı/hata oranları; * p50, p95 ve p99 gecikme; * upstream seçimi ve sağlık davranışı; * kimlik doğrulama kararları ve consumer ilişkilendirmesi; * eklenti yan etkileri, header ve gövde dönüşümleri; * bağlantıların yeniden kullanımı, WebSocket/gRPC yaşam döngüsü ve zaman aşımı davranışı. Tenant sızıntısı, kimlik doğrulama farkı, beklenmeyen değişiklik, önemli SLO gerilemesi, eşleşmeyen route, yinelenen yan etki veya geri dönüş kanıtının kaybı durumunda durun. ## Aşama 6: trafik geçişi 1. Kaynak yapılandırma değişikliklerini dondurun veya son değişiklikleri uzlaştıracak bir yöntem kurun. 2. Son Kong durumunu dışa aktarın ve eşleme farkını yeniden çalıştırın. 3. Doğrulanmış Kangal veritabanı yedeği ve yapılandırma snapshot'ı alın. 4. Kangal katı doğrulamasını, canlı fark karşılaştırmasını ve kabul testlerini yeniden çalıştırın. 5. DNS trafik geçişine katılıyorsa TTL'i önceden düşürün. 6. İki platformu da izleyerek trafiği onaylı adımlarla taşıyın. 7. Geri dönüş penceresi boyunca Kong'u erişilebilir fakat salt okunur/değişmemiş tutun. 8. Yalnızca geçişte kullanılan credential'ları yenileyin ve geçici uyumluluk erişimini kaldırın. ## Geri dönüş ve devreden çıkarma Trafiği geri döndürmek sahipliği Kong'a verir; Kangal üzerinden daha önce kabul edilmiş yazma işlemlerini otomatik olarak kaldırmaz. Trafiği geçirmeden önce durum değiştiren her API için uzlaştırma tanımlayın. Kangal yapılandırması geri alınacaksa kaydedilmiş uygulama öncesi snapshot'ı yalnızca katı fark incelemesinden sonra kullanın; veritabanını yalnızca kurtarma runbook'una göre geri yükleyin. Geri dönüş penceresi kapanmadan, istemci DNS/yapılandırması yakınsamadan, trafik veya yönetim otomasyonu erişimi sona ermeden, audit/uyumluluk kanıtı saklanmadan, gizli bilgiler ve sertifikalar yenilenmeden ya da iptal edilmeden ve son geçiş raporu onaylanmadan Kong'u devreden çıkarmayın. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kangal.dev/tr/migration/kong.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.