Cloud SQL Proxy Nedir ve Neden GKE’de Kullanmalıyız?
Google Cloud SQL Proxy, uygulamalarınızın Google Cloud SQL veritabanı örnekleriyle güvenli ve şifreli bir şekilde bağlantı kurmasını sağlayan açık kaynaklı bir araçtır. Özellikle Kubernetes Engine (GKE) gibi kapsayıcılı ortamlarda, veritabanı bağlantılarını basitleştirmek ve güvenliği artırmak için vazgeçilmez bir bileşendir.
Neden Cloud SQL Proxy?
* Güvenlik: Proxy, tüm iletişimi TLS 1.2 şifrelemesi ve otomatik sertifika rotasyonu ile güvence altına alır. Bu, veritabanı trafiğinizin internet üzerinden güvenli bir şekilde aktarılmasını sağlar.
* Kimlik Doğrulama: Cloud SQL Proxy, Cloud IAM (Identity and Access Management) kullanarak kimlik doğrulaması yapar. Bu, hassas veritabanı kimlik bilgilerini (kullanıcı adı/şifre) doğrudan uygulamanızda depolama ihtiyacını ortadan kaldırır veya en aza indirir. GKE’de Workload Identity ile entegrasyonu sayesinde, Kubernetes Service Account’ları aracılığıyla IAM yetkilendirmesi yapılabilir.
* Ağ Yapılandırması Kolaylığı: Cloud SQL örneğinizin genel IP adresini veya özel IP’sini doğrudan uygulamanıza açmak yerine, proxy yerel bir TCP portu üzerinden dinler. Uygulamanız bu yerel porta bağlanır ve proxy, bağlantıyı Cloud SQL’e güvenli bir şekilde tüneller. Bu, ağ güvenlik duvarı kurallarını basitleştirir ve saldırı yüzeyini azaltır.
* Dinamik IP Yönetimi: Cloud SQL örneklerinin IP adresleri değişebilir. Proxy, bu değişiklikleri otomatik olarak yönetir, böylece uygulamanızın IP adresi değişikliklerinden etkilenmesini önler.
GKE’de bir uygulama çalıştırdığınızda, Cloud SQL Proxy’yi uygulamanızla aynı pod içinde bir “sidecar” kapsayıcısı olarak çalıştırmak, en yaygın ve önerilen yöntemdir. Bu, uygulamanızın veritabanına localhost üzerinden bağlanmasını sağlar, böylece ağ karmaşıklığını en aza indirir.
Ön Gereksinimler ve Hazırlık
Cloud SQL Proxy’yi GKE’de başarıyla kullanmak için bazı ön gereksinimleri karşılamanız gerekir:
1. GCP Projesi ve GKE Kümesi: Çalışan bir Google Cloud projeniz ve bir GKE kümeniz olmalıdır.
2. Cloud SQL Veritabanı Örneği: Bağlanmak istediğiniz bir Cloud SQL veritabanı örneği (PostgreSQL, MySQL veya SQL Server) oluşturulmuş olmalıdır. Örnek bağlantı adı (project-id:region:instance-name) bu rehberde önemli olacaktır.
3. IAM İzinleri: Cloud SQL Proxy’nin Cloud SQL örneğine bağlanabilmesi için yeterli IAM izinlerine sahip bir hizmet hesabına ihtiyacı vardır. En azından Cloud SQL İstemcisi (Cloud SQL Client) rolü gereklidir.
4. Workload Identity Etkinleştirme: En güvenli ve önerilen yöntem Workload Identity kullanmaktır. Bu sayede Kubernetes Service Account’larınıza Google Cloud IAM Service Account’larının kimliklerini atayabilirsiniz. GKE kümenizde Workload Identity’nin etkinleştirildiğinden emin olun:
gcloud container clusters update YOUR_CLUSTER_NAME \
--zone YOUR_CLUSTER_ZONE \
--workload-pool=YOUR_PROJECT_ID.svc.id.googWorkload Identity Yapılandırması
Workload Identity, GKE pod’larınızın doğrudan bir Google Cloud IAM Service Account’ı gibi davranmasını sağlar. Bu, hassas anahtar dosyalarını pod’larda saklama ihtiyacını ortadan kaldırır.
1. Google Cloud IAM Hizmet Hesabı Oluşturma: Proxy’nin Cloud SQL’e bağlanması için kullanılacak bir IAM Hizmet Hesabı oluşturun:
gcloud iam service-accounts create cloudsql-proxy-sa \
--display-name "Cloud SQL Proxy Service Account"2. Gerekli İzinleri Verme: Bu hizmet hesabına Cloud SQL örneğinize bağlanma izni verin (Cloud SQL İstemcisi rolü):
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
--member "serviceAccount:cloudsql-proxy-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
--role "roles/cloudsql.client"3. Kubernetes Hizmet Hesabı Oluşturma ve İlişkilendirme: GKE kümenizde bir Kubernetes Service Account oluşturun ve bunu az önce oluşturduğunuz IAM Hizmet Hesabıyla ilişkilendirin. Bu ilişkilendirme, Kubernetes Service Account’ının IAM Hizmet Hesabı’nın kimliğini üstlenmesini sağlar.
# k8s-service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: myapp-service-account
annotations:
iam.gke.io/gcp-service-account: cloudsql-proxy-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com Uygulayın: kubectl apply -f k8s-service-account.yaml
Bu Kubernetes Service Account’ı, daha sonra Deployment YAML dosyanızda proxy kapsayıcınız için kullanılacaktır.
GKE’de Cloud SQL Proxy Uygulaması (Sidecar Deseni)
Cloud SQL Proxy’yi GKE’de kullanmanın en yaygın ve önerilen yolu, uygulamanızla aynı pod içinde bir sidecar kapsayıcısı olarak dağıtmaktır. Bu yapılandırma, uygulamanızın proxy’ye localhost üzerinden erişmesini sağlar.
Aşağıdaki Deployment YAML örneği, bir uygulamanın (örneğin bir Node.js uygulaması) Cloud SQL Proxy ile nasıl dağıtılacağını göstermektedir.
# myapp-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myapp-deployment
labels:
app: myapp
spec:
replicas: 1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
serviceAccountName: myapp-service-account # Workload Identity için Kubernetes Service Account
containers:
- name: myapp-container
image: your-app-image:latest # Kendi uygulama imajınız
ports:
- containerPort: 8080
env:
- name: DB_HOST
value: "127.0.0.1" # Proxy'nin dinlediği yerel IP
- name: DB_PORT
value: "5432" # PostgreSQL için varsayılan, MySQL için 3306
- name: DB_USER
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: cloudsql-db-credentials
key: password
# ... diğer uygulama değişkenleri
- name: cloudsql-proxy
image: gcr.io/cloudsql-docker/gce-proxy:1.33.0 # En son sürümü kullanın
command:
- "/cloud_sql_proxy"
- "-instances=YOUR_PROJECT_ID:YOUR_REGION:YOUR_INSTANCE_NAME=tcp:5432" # Cloud SQL bağlantı adı ve yerel port
# Eğer birden fazla instance'a bağlanılacaksa:
# - "-instances=instance1_conn_name=tcp:5432,instance2_conn_name=tcp:3306"
- "-enable_iam_login" # IAM tabanlı kimlik doğrulama için (önerilir)
# - "-ip_address_type=PRIVATE" # Özel IP kullanıyorsanız
securityContext:
runAsNonRoot: true
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "200m"
memory: "256Mi"Açıklamalar:
* serviceAccountName: myapp-service-account: Bu kısım, pod’un Workload Identity için yapılandırılan Kubernetes Service Account’ını kullanmasını sağlar. Bu sayede proxy, belirtilen IAM Service Account’ının kimliğiyle Cloud SQL’e bağlanır.
* myapp-container: Ana uygulama kapsayıcınızdır. DB_HOST ve DB_PORT ortam değişkenleri aracılığıyla proxy’ye bağlanır.
* cloudsql-proxy: Cloud SQL Proxy kapsayıcısıdır.
* image: Cloud SQL Proxy’nin Docker imajını belirtir. Her zaman en son kararlı sürümü kullanmanız önerilir.
* command: Proxy’yi çalıştıran komut ve parametreler.
* -instances=YOUR_PROJECT_ID:YOUR_REGION:YOUR_INSTANCE_NAME=tcp:5432: Cloud SQL örneğinizin tam bağlantı adını ve proxy’nin bu örnek için dinleyeceği yerel TCP portunu belirtir. PostgreSQL için genellikle 5432, MySQL için 3306 kullanılır.
* -enable_iam_login: Bu parametre, proxy’nin IAM tabanlı kimlik doğrulamayı etkinleştirmesini sağlar. Uygulamanızda veritabanı kullanıcı adı olarak bir IAM Service Account’ı kullanabilirsiniz.
* -ip_address_type=PRIVATE: Eğer Cloud SQL örneğiniz özel IP adresi kullanıyorsa ve GKE kümeniz aynı VPC ağına bağlıysa bu parametreyi kullanın.
* resources: Proxy kapsayıcısı için CPU ve bellek kaynak isteklerini ve limitlerini tanımlamak önemlidir. Proxy genellikle çok fazla kaynak tüketmez, ancak uygun limitler, kaynak tükenmesini önler.
* securityContext: Güvenlik için runAsNonRoot: true kullanılması önerilir.
Bu Deployment dosyasını uyguladıktan sonra (kubectl apply -f myapp-deployment.yaml), pod’unuz Cloud SQL Proxy ile birlikte çalışacak ve uygulamanız 127.0.0.1:5432 (veya belirtilen port) üzerinden veritabanına bağlanabilecektir.
Veritabanı Kimlik Bilgilerini Yönetme (Kubernetes Secrets)
Veritabanı kullanıcı adı ve şifresi gibi hassas bilgileri doğrudan YAML dosyalarına yazmak yerine Kubernetes Secrets kullanmalısınız.
1. Secret Oluşturma:
kubectl create secret generic cloudsql-db-credentials \
--from-literal=username=your_db_username \
--from-literal=password=your_db_password (Not: your_db_username ve your_db_password değerlerini kendi Cloud SQL veritabanı kullanıcı adınız ve şifrenizle değiştirin.)
2. Deployment’ta Kullanma: Yukarıdaki myapp-deployment.yaml dosyasında env bölümündeki valueFrom kısmında bu Secret’ın nasıl kullanıldığına dikkat edin.
Uygulamanızı Cloud SQL Proxy’ye Bağlama
Uygulamanızın Cloud SQL Proxy’ye bağlanması, sanki veritabanı aynı makinede çalışıyormuş gibi basittir. Bağlantı dizenizde veritabanı ana bilgisayarı olarak 127.0.0.1 (veya localhost) ve proxy’nin dinlediği yerel portu kullanmanız yeterlidir.
Örnek PostgreSQL Bağlantı Dizesi (Node.js/psql için):
const { Pool } = require('pg');
const pool = new Pool({
user: process.env.DB_USER,
host: process.env.DB_HOST, // 127.0.0.1
database: 'your_database_name',
password: process.env.DB_PASSWORD,
port: parseInt(process.env.DB_PORT, 10), // 5432
});
pool.query('SELECT NOW()', (err, res) => {
if (err) {
console.error('Error executing query', err.stack);
} else {
console.log('Connected to Cloud SQL:', res.rows[0].now);
}
});Örnek MySQL Bağlantı Dizesi (Python/SQLAlchemy için):
import os
from sqlalchemy import create_engine
DB_USER = os.environ.get("DB_USER")
DB_PASSWORD = os.environ.get("DB_PASSWORD")
DB_HOST = os.environ.get("DB_HOST") # 127.0.0.1
DB_PORT = os.environ.get("DB_PORT") # 3306
DB_NAME = "your_database_name"
MySQL için bağlantı dizesi
DATABASE_URL = f"mysql+pymysql://{DB_USER}:{DB_PASSWORD}@{DB_HOST}:{DB_PORT}/{DB_NAME}"
engine = create_engine(DATABASE_URL)
try:
with engine.connect() as connection:
result = connection.execute("SELECT NOW()")
print("Connected to Cloud SQL:", result.scalar())
except Exception as e:
print("Error connecting to Cloud SQL:", e)Uygulamanız, Cloud SQL Proxy’nin sunduğu yerel bağlantı noktasını kullanarak veritabanına bağlanır. Proxy, bu bağlantıyı alır, güvenli bir şekilde şifreler ve Cloud SQL örneğinize tüneller.
En İyi Uygulamalar ve Sorun Giderme
Cloud SQL Proxy’yi GKE’de kullanırken performansı, güvenliği ve kararlılığı sağlamak için bazı en iyi uygulamaları göz önünde bulundurmalısınız:
En İyi Uygulamalar
* Workload Identity Kullanımı: Daima Workload Identity’yi tercih edin. Bu, IAM Service Account anahtarlarını Kapsayıcınızda veya Secret’larda saklama riskini ortadan kaldırır.
* Kaynak Limitleri: Proxy kapsayıcısı için CPU ve bellek kaynak istekleri ve limitleri tanımlayın. Bu, GKE’nin kaynakları verimli bir şekilde planlamasına yardımcı olur ve proxy’nin aşırı kaynak tüketmesini veya diğer kapsayıcıları etkilemesini önler.
* Bağlantı Havuzlama (Connection Pooling): Uygulamanızda veritabanı bağlantı havuzlama kullanın. Her yeni veritabanı bağlantısı açmak yerine, mevcut bağlantıları yeniden kullanmak performansı artırır ve Cloud SQL örneği üzerindeki yükü azaltır. Proxy’nin kendisi bir bağlantı havuzu değildir; bu, uygulama katmanında yönetilmelidir.
* Liveness ve Readiness Probes: Uygulama kapsayıcınız için liveness ve readiness probes tanımladığınızdan emin olun. Proxy’nin çalışır durumda olup olmadığını kontrol etmek için ayrı bir probe genellikle gerekli değildir, çünkü proxy başarısız olursa uygulama da veritabanına bağlanamaz.
* Proxy Sürümünü Güncel Tutma: Güvenlik yamaları ve performans iyileştirmeleri için Cloud SQL Proxy imajını düzenli olarak güncelleyin.
* Özel IP Kullanımı: Mümkünse, Cloud SQL örneğiniz için özel IP kullanın ve GKE kümenizi aynı VPC ağına bağlayın. Bu, ağ gecikmesini azaltır ve genel internet üzerinden veri trafiği ihtiyacını ortadan kaldırır.
Sorun Giderme İpuçları
* Proxy Loglarını Kontrol Edin: Proxy kapsayıcısının loglarını kontrol ederek herhangi bir bağlantı hatası veya kimlik doğrulama sorunu olup olmadığını görün:
kubectl logs -f -c cloudsql-proxy * IAM İzinlerini Doğrulayın: Cloud SQL Proxy’nin kullandığı IAM Hizmet Hesabının (cloudsql-proxy-sa veya benzeri) roles/cloudsql.client rolüne sahip olduğundan emin olun. Ayrıca, Kubernetes Service Account’ının doğru IAM Service Account ile ilişkilendirildiğini kontrol edin.
* Bağlantı Adını Kontrol Edin: Proxy komutundaki Cloud SQL bağlantı adının (YOUR_PROJECT_ID:YOUR_REGION:YOUR_INSTANCE_NAME) doğru olduğundan emin olun.
* Yerel Portları Kontrol Edin: Uygulamanızın proxy’nin dinlediği doğru yerel porta (127.0.0.1:5432 veya 127.0.0.1:3306) bağlandığından emin olun.
* Ağ Bağlantısını Test Edin: GKE kümenizden Cloud SQL örneğine temel ağ bağlantısının olup olmadığını kontrol edin (özellikle özel IP kullanıyorsanız).
Sonuç ve Sıkça Sorulan Sorular (SSS)
Cloud SQL Proxy’yi GKE’de kullanmak, uygulamalarınızın Google Cloud SQL veritabanlarıyla güvenli, verimli ve yönetimi kolay bir şekilde etkileşim kurmasını sağlayan güçlü bir çözümdür. Workload Identity ile entegrasyonu, güvenlik duruşunuzu önemli ölçüde güçlendirirken, sidecar deseni dağıtım karmaşıklığını en aza indirir. Bu rehberdeki adımları izleyerek, GKE ortamınızda Cloud SQL bağlantılarını güvenle yapılandırabilirsiniz.
Sıkça Sorulan Sorular (SSS)
S: Neden Cloud SQL Proxy kullanmalıyız da doğrudan Cloud SQL’in IP adresine bağlanmıyoruz?
C: Doğrudan IP adresine bağlanmak, bağlantıyı şifresiz bırakır ve Cloud SQL örneğinizin genel internete açık olmasına neden olabilir. Proxy, tüm iletişimi TLS 1.2 ile şifreler, otomatik olarak kimlik doğrular (IAM kullanarak) ve ağ güvenlik duvarı yapılandırmasını basitleştirir.
S: Cloud SQL Proxy’yi kullanmak gecikmeyi artırır mı?
C: Proxy’nin kendisi çok hafif bir araçtır ve genellikle ihmal edilebilir bir gecikme ekler. Çoğu durumda, güvenlik ve yönetim kolaylığı faydaları, herhangi bir küçük gecikme maliyetinden çok daha ağır basar. Performans için uygulama katmanında bağlantı havuzlama kullanmak daha önemlidir.
S: Bir pod içinde birden fazla Cloud SQL örneğine bağlanabilir miyiz?
C: Evet, Cloud SQL Proxy’nin -instances parametresine birden fazla bağlantı adı sağlayarak veya her biri farklı bir yerel portta dinleyen birden fazla proxy kapsayıcısı çalıştırarak birden fazla Cloud SQL örneğine bağlanabilirsiniz.
Örnek: -instances=instance1_conn_name=tcp:5432,instance2_conn_name=tcp:3307
S: Cloud SQL Proxy’nin dinlediği portu değiştirebilir miyim?
C: Evet, -instances parametresindeki tcp: kısmını değiştirerek proxy’nin dinleyeceği yerel portu belirleyebilirsiniz. Örneğin, tcp:5000 kullanabilirsiniz. Uygulamanızın da bu porta bağlanacak şekilde yapılandırıldığından emin olun.
S: Cloud SQL Proxy’yi ayrı bir pod olarak çalıştırmak mümkün müdür?
C: Evet, mümkündür. Ancak genellikle daha karmaşıktır çünkü proxy’ye bir Kubernetes Service üzerinden erişilmesi ve ağ politikalarıyla güvenliğin sağlanması gerekir. Sidecar deseni genellikle daha basit ve daha güvenlidir çünkü uygulama ve proxy aynı ağ ad alanını paylaşır. Ayrı bir pod, özellikle birden fazla uygulamanın tek bir proxy’yi paylaştığı veya legacy uygulamalar için düşünülebilir.