Dağıtık sistemler ve mikroservis mimarileri, modern yazılım geliştirmenin temel taşları haline geldi. Ancak, bu mimarilerde en sık karşılaşılan zorluklardan biri, farklı uygulamalar veya EKS (Elastic Kubernetes Service) kümeleri arasında veri paylaşımını tutarlı, güvenli ve ölçeklenebilir bir şekilde sağlamaktır. Geleneksel yaklaşımlar genellikle karmaşıklık, performans darboğazları veya yüksek maliyetlerle sonuçlanırken, AWS EFS (Elastic File System) ve Terraform’un entegrasyonu, bu problemi zarif bir şekilde çözmek için güçlü bir kombinasyon sunar. Peki, birden fazla EKS uygulamasının aynı veriye aynı anda erişmesi gerektiğinde nasıl bir strateji izlemeliyiz ve Terraform bu süreci nasıl basitleştirebilir?
EKS üzerindeki uygulamaların durumu genellikle geçicidir; pod’lar ölçeklenebilir, yeniden başlatılabilir veya farklı nodelara taşınabilir. Bu durum, uygulamaların ihtiyaç duyduğu kalıcı verinin yönetimi için özel bir yaklaşım gerektirir. Bir blog platformunuzun düşünün; kullanıcıların yüklediği görseller, makale ekleri veya paylaşılan yapılandırma dosyaları gibi verilerin, front-end, back-end ve hatta analiz servisleri gibi farklı mikroservisler tarafından erişilebilir olması şarttır. Bu senaryoda, her bir servisin kendi yerel depolama alanına sahip olması, veri tutarsızlıklarına, senkronizasyon sorunlarına ve operasyonel yükün artmasına yol açar. İşte tam bu noktada, EFS gibi merkezi, yönetilen ve ölçeklenebilir bir dosya depolama çözümü devreye girer. EFS, aynı anda binlerce Kubernetes pod’unun dosya sistemine bağlanmasına olanak tanıyarak bu karmaşıklığı ortadan kaldırır. Ancak bu altyapıyı manuel olarak kurmak hem zaman alıcı hem de hataya açıktır. Burada devreye altyapıyı kod olarak yönetmemizi sağlayan Terraform giriyor. Terraform ile EFS kaynaklarını ve EKS entegrasyonunu otomatikleştirerek, tekrarlanabilir, sürdürülebilir ve hatasız bir yapı kurmak mümkün hale gelir. Bu makalede, EFS ve EKS temellerinden başlayarak, Terraform ile adım adım altyapı oluşturma, Kubernetes entegrasyonu ve gerçek dünya senaryolarıyla bu güçlü kombinasyonun nasıl kullanılacağını detaylı bir şekilde inceleyeceğiz. Amacımız, okuyucularımızın bu teknolojileri sıfırdan öğrenerek kendi bulut altyapılarında güvenle uygulayabilmelerini sağlamaktır.
EFS ve EKS Temelleri: Bulutta Kalıcı Veri Yönetimi
Bulut tabanlı uygulamaların temel gereksinimlerinden biri, kalıcı ve ölçeklenebilir veri depolama yeteneğidir. Özellikle konteynerize edilmiş uygulamalar ve mikroservis mimarileri için bu, ayrı bir zorluk teşkil eder. AWS EFS (Elastic File System) ve EKS (Elastic Kubernetes Service), bu zorlukları aşmak için tasarlanmış iki güçlü AWS servisidir. Bu bölümde, her iki servisin ne olduğunu, neden önemli olduklarını ve bir araya geldiklerinde nasıl bir değer sunduklarını daha yakından inceleyeceğiz.
EFS (Elastic File System) Nedir ve Neden Önemlidir?
AWS Elastic File System (EFS), AWS bulutunda ve şirket içi kaynaklarla kullanılabilen, basit, sunucusuz, esnek ve tam olarak yönetilen bir NFS (Network File System) dosya depolama hizmetidir. EFS’nin en büyük avantajı, dinamik olarak ölçeklenebilme yeteneğidir. Depolama kapasitesi, dosya ekledikçe veya sildikçe otomatik olarak artar veya azalır, böylece depolama alanını önceden tahmin etmenize veya yönetmenize gerek kalmaz. Bu, özellikle veri büyüklüğü değişken olan veya anlık zirveler yaşayan uygulamalar için kritik bir özelliktir. EFS, aynı anda binlerce EC2 örneği, EKS pod’u veya diğer AWS hizmeti tarafından erişilebilir; bu da onu çoklu uygulama ve çoklu küme veri paylaşım senaryoları için ideal kılar. Yüksek kullanılabilirlik ve dayanıklılık sunar, çünkü verileriniz birden fazla Availability Zone’da (AZ) depolanır.
Peki EFS’yi bu kadar önemli kılan nedir? İlk olarak, esneklik. Geleneksel dosya sunucularının aksine, EFS manuel ölçekleme veya performans ayarlamaları gerektirmez. Uygulamanızın ihtiyaçlarına göre otomatik olarak adapte olur. İkincisi, paylaşım kolaylığı. Birden fazla sunucunun veya konteynerin aynı anda aynı dosya sistemine erişmesi, merkezi loglama, paylaşılan konfigürasyonlar, medya işleme veya web içerik yönetimi gibi senaryolarda hayat kurtarıcıdır. Üçüncüsü, tamamen yönetilen bir hizmet olması. AWS sizin için altyapıyı yönetir, yedeklemeleri ve yamaları yapar, böylece siz uygulamanızın geliştirilmesine odaklanabilirsiniz. Ayrıca, EFS, şifreleme özellikleri ile verilerinizin güvenliğini de sağlamaktadır.
EKS (Elastic Kubernetes Service) ve Mikroservis Mimarisindeki Yeri
AWS Elastic Kubernetes Service (EKS), Kubernetes kontrol düzlemini AWS’de çalıştırmak için tam olarak yönetilen bir hizmettir. Bu, Kubernetes master düğümlerini yönetme yükünü AWS’ye devrettiğiniz anlamına gelir, böylece siz sadece worker düğümlerinizi ve üzerinde çalışan uygulamalarınızı yönetmeye odaklanabilirsiniz. EKS, konteyner tabanlı uygulamaların dağıtımı, ölçeklenmesi ve yönetimi için endüstri standardı olan Kubernetes’i AWS altyapısının güvenilirliği ve ölçeklenebilirliği ile birleştirir.
Mikroservis mimarileri, uygulamaları küçük, bağımsız ve gevşek bağlı hizmetlere ayırarak geliştirme hızını, esnekliği ve dayanıklılığı artırır. Ancak bu mimarilerde karşılaşılan temel zorluklardan biri, “stateful” (durumlu) uygulamaların yönetimidir. Veritabanları, mesaj kuyrukları veya dosya depolama gerektiren uygulamalar, konteynerlerin geçici doğası nedeniyle karmaşık hale gelebilir. EKS, bu durumu Persistent Volume (PV) ve Persistent Volume Claim (PVC) gibi soyutlamalar aracılığıyla ele alır. Ancak varsayılan depolama çözümleri genellikle tek bir Pod veya Node ile sınırlıdır. İşte EFS, bu noktada EKS için vazgeçilmez bir kalıcı depolama çözümü haline gelir. Birden fazla EKS pod’unun veya farklı EKS kümelerinin bile aynı EFS dosya sistemine bağlanabilmesi, mikroservisler arası veri paylaşımı ve merkezi veri yönetimi için benzersiz bir çözüm sunar. Bu entegrasyon, uygulamaların durumlarını dışarıda bir yerde kalıcı olarak saklamasına olanak tanıyarak, konteynerlerin esnekliğini korurken veri bütünlüğünü ve erişilebilirliğini garanti eder.
Terraform ile EFS Altyapısı Oluşturma: Adım Adım Rehber
EFS’nin EKS uygulamaları için ne kadar değerli olduğunu anladığımıza göre, şimdi bu güçlü depolama çözümünü AWS üzerinde nasıl oluşturacağımızı ve yöneteceğimizi inceleyelim. Terraform, altyapıyı kod olarak (IaC – Infrastructure as Code) yönetmek için endüstri standardı bir araçtır. Bu bölüm, Terraform kullanarak bir EFS dosya sistemi, erişim noktaları ve ilgili ağ yapılandırmalarını adım adım nasıl oluşturacağınızı gösterecektir. Bu sayede, altyapınızın versiyonlanabilir, tekrarlanabilir ve otomatik olmasını sağlayacağız.
Terraform Ortamının Hazırlanması ve AWS Provider Yapılandırması
Terraform ile çalışmaya başlamadan önce, sisteminizde Terraform CLI’nın kurulu olduğundan ve AWS kimlik bilgilerinizin doğru şekilde yapılandırıldığından emin olmanız gerekir. AWS kimlik bilgileri genellikle ortam değişkenleri (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) veya ~/.aws/credentials dosyası aracılığıyla sağlanır. İlk adım, Terraform’un AWS ile iletişim kurmasını sağlayacak AWS provider’ını tanımlamaktır. Aşağıdaki örnek, temel bir main.tf dosyasını göstermektedir:
terraform {
required_providers {
aws = {
source = "hashicorp/aws"
version = "~> 5.0"
}
}
}
provider "aws" {
region = "eu-west-1" # Kullandığınız AWS bölgesini belirtin
}
Bu kod bloğu, Terraform'a hangi provider'ı (bu durumda AWS) kullanacağını ve bu provider için hangi versiyonun gerekli olduğunu söyler. Ayrıca, kaynakların hangi AWS bölgesinde oluşturulacağını da belirtir. Ortamınızı hazırladıktan sonra, terraform init komutunu çalıştırarak gerekli eklentileri indirebilirsiniz.
EFS Dosya Sisteminin ve Erişim Noktalarının Tanımlanması
EFS dosya sistemi, depolama çözümümüzün çekirdeğini oluşturur. Terraform'da aws_efs_file_system kaynağını kullanarak bir EFS dosya sistemi tanımlayabiliriz. Ayrıca, EKS uygulamalarının bu dosya sistemine belirli yollar ve kimliklerle erişmesini sağlamak için aws_efs_access_point kullanacağız. Erişim noktaları, Kubernetes'in belirli bir EFS yoluna ve kullanıcı/grup kimliğine (UID/GID) erişmesini sağlayan güçlü bir özelliktir.
# EFS Dosya Sistemi Oluşturma
resource "aws_efs_file_system" "eks_shared_efs" {
creation_token = "eks-shared-efs-filesystem"
encrypted = true # Veri şifrelemesini etkinleştir
performance_mode = "generalPurpose" # Uygulama tipinize göre "maxIo" seçebilirsiniz
throughput_mode = "bursting" # Bursting veya provisioned seçilebilir
tags = {
Name = "eks-shared-efs"
}
}
# EFS Erişim Noktası Oluşturma
# Bu erişim noktası, EKS uygulamalarının belirli bir alt dizine erişmesini sağlar
resource "aws_efs_access_point" "eks_app_access_point" {
file_system_id = aws_efs_file_system.eks_shared_efs.id
posix_user {
gid = 1000
uid = 1000
}
root_directory {
path = "/eks_data" # EFS üzerinde oluşturulacak kök dizin
creation_info {
owner_gid = 1000
owner_uid = 1000
permissions = "0755"
}
}
tags = {
Name = "eks-app-access-point"
}
}
# EFS Mount Hedefleri (Target) Oluşturma
# EFS'nin EKS kümenizin çalıştığı VPC'deki alt ağlara bağlanmasını sağlar
resource "aws_efs_mount_target" "efs_mount_targets" {
count = length(var.private_subnets) # Birden fazla alt ağ için
file_system_id = aws_efs_file_system.eks_shared_efs.id
subnet_id = var.private_subnets[count.index]
security_groups = [aws_security_group.efs_security_group.id]
}
output "efs_file_system_id" {
description = "Oluşturulan EFS Dosya Sisteminin ID'si"
value = aws_efs_file_system.eks_shared_efs.id
}
output "efs_access_point_id" {
description = "Oluşturulan EFS Erişim Noktasının ID'si"
value = aws_efs_access_point.eks_app_access_point.id
}
Yukarıdaki kod bloğu, eks_shared_efs adında şifreli bir EFS dosya sistemi ve /eks_data dizinini işaret eden bir erişim noktası oluşturur. Erişim noktası, Kubernetes pod'larının EFS'ye belirli bir kullanıcı (UID 1000, GID 1000) olarak erişmesini sağlar. aws_efs_mount_target kaynakları, EFS dosya sisteminin belirtilen VPC alt ağlarına bağlanmasına izin verir. Bu adım, EKS düğümlerinin EFS'ye ağ üzerinden erişebilmesi için hayati öneme sahiptir.
Güvenlik Grupları ve Ağ Konfigürasyonu: EFS Erişimi İçin Temel Kurallar
EFS'ye erişim, ağ düzeyinde güvenlik grupları aracılığıyla kontrol edilmelidir. EFS mount hedefi için bir güvenlik grubu oluşturup, EKS kümenizin düğümlerinin çalıştığı güvenlik grubundan gelen NFS (port 2049) trafiğine izin vermelisiniz. Bu, EFS'ye sadece yetkili EKS düğümlerinin erişebilmesini sağlar.
# EFS için Güvenlik Grubu Oluşturma
resource "aws_security_group" "efs_security_group" {
name = "efs-sg"
description = "EFS için güvenlik grubu, EKS nodelarından NFS trafiğine izin verir."
vpc_id = var.vpc_id # VPC ID'nizi belirtin
ingress {
description = "EKS Nodelarından NFS erişimi"
from_port = 2049
to_port = 2049
protocol = "tcp"
security_groups = [var.eks_node_security_group_id] # EKS node'larının SG ID'si
}
egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
tags = {
Name = "efs-sg"
}
}
# Değişkenler (variables.tf)
variable "vpc_id" {
description = "EFS'nin ve EKS'nin bulunduğu VPC ID'si."
type = string
}
variable "private_subnets" {
description = "EFS mount hedeflerinin yerleştirileceği özel alt ağ ID'leri."
type = list(string)
}
variable "eks_node_security_group_id" {
description = "EKS node'larının güvenlik grubu ID'si."
type = string
}
Bu güvenlik grubu (efs_security_group), EFS'nin bulunduğu VPC'de oluşturulur ve yalnızca eks_node_security_group_id ile belirtilen güvenlik grubundan gelen NFS (TCP/2049) trafiğine izin verir. Bu, EFS kaynaklarınıza sadece EKS kümenizin erişebilmesini sağlayarak güvenliği artırır. Bu adımları tamamladıktan sonra, terraform plan ve terraform apply komutlarını kullanarak tüm bu kaynakları AWS üzerinde oluşturabilirsiniz. Böylece, EKS uygulamalarınızın kullanabileceği güvenli ve ölçeklenebilir bir EFS altyapısı hazır olacaktır.
Uzman İpucu: EFS performansı, seçtiğiniz throughput moduna (bursting veya provisioned) ve kullandığınız depolama sınıfına (Standard veya Infrequent Access) göre değişiklik gösterebilir. Uygulamanızın I/O gereksinimlerini dikkatlice analiz ederek en uygun ayarları seçmeniz hem performans hem de maliyet açısından önemlidir.
Birden Fazla EKS Uygulamasını EFS'ye Bağlama: Kubernetes Entegrasyonu
EFS altyapımızı Terraform ile başarıyla oluşturduktan sonra, sıra EKS kümelerimizdeki uygulamaların bu paylaşılan dosya sistemine erişmesini sağlamaya geliyor. Kubernetes, depolama entegrasyonu için Container Storage Interface (CSI) adı verilen esnek bir arayüz sunar. AWS EFS CSI sürücüsü, EKS pod'larının EFS'ye kolayca bağlanmasını sağlar. Bu bölümde, EFS CSI sürücüsünü EKS'ye kurmayı, Persistent Volume (PV) ve Persistent Volume Claim (PVC) tanımlamayı ve son olarak EKS uygulamalarınızı bu paylaşılan EFS depolama alanına nasıl bağlayacağınızı adım adım inceleyeceğiz.
EFS CSI (Container Storage Interface) Sürücüsünü EKS'ye Kurmak
EFS'yi Kubernetes'e entegre etmenin en modern ve önerilen yolu, AWS EFS CSI Sürücüsünü kullanmaktır. CSI sürücüsü, Kubernetes'in EFS kaynaklarını bir depolama sağlayıcısı olarak tanımasına ve pod'larınız için depolama alanını dinamik olarak sağlamasına olanak tanır. Genellikle Helm ile kolayca kurulabilir. Öncelikle Helm'in kurulu olduğundan ve EKS kümenize erişebildiğinizden emin olun.
# EFS CSI sürücüsü deposunu ekle
helm repo add aws-efs-csi-driver https://kubernetes-sigs.github.io/aws-efs-csi-driver/
# Depoyu güncelle
helm repo update
# EFS CSI sürücüsünü kur
# EFS CSI sürücüsünün IAM rolüne, EFS kaynaklarına erişim yetkisi verildiğinden emin olun.
# Bu rol genellikle bir Service Account ile ilişkilendirilir.
helm upgrade -i aws-efs-csi-driver aws-efs-csi-driver/aws-efs-csi-driver \
--namespace kube-system \
--set image.repository=602401143452.dkr.ecr.eu-west-1.amazonaws.com/amazon/aws-efs-csi-driver \
--set controller.serviceAccount.create=true \
--set controller.serviceAccount.name=efs-csi-controller-sa \
--set controller.serviceAccount.annotations.eks\.amazonaws\.com/role-arn="arn:aws:iam::ACCOUNT_ID:role/EFSCSIDriverRole"
Yukarıdaki komutta ACCOUNT_ID yerine kendi AWS hesap ID'nizi ve EFSCSIDriverRole yerine EFS CSI sürücüsü için oluşturduğunuz IAM rolünün adını yazmalısınız. Bu IAM rolünün EFS kaynaklarına (örneğin, efs:DescribeFileSystems, efs:CreateMountTarget, ec2:DescribeSecurityGroups) erişim yetkisi olduğundan emin olun. Bu rol genellikle bir OIDC sağlayıcısı ve Kubernetes Service Account (IRSA) ile ilişkilendirilir.
Persistent Volume (PV) ve Persistent Volume Claim (PVC) Oluşturma
EFS CSI sürücüsü kurulduktan sonra, Kubernetes'te bir StorageClass tanımlayabiliriz. Bu StorageClass, EKS pod'larının EFS kaynaklarını dinamik olarak sağlamak için kullanılacaktır. Ardından, bir Persistent Volume Claim (PVC) oluşturarak uygulamalarımızın bu depolama alanını talep etmesini sağlarız. Eğer statik bir Persistent Volume kullanmak istiyorsanız, direkt EFS dosya sisteminizi ve erişim noktanızı referans gösteren bir PV tanımlayabilirsiniz.
# storageclass.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: efs-sc
provisioner: efs.csi.aws.com
parameters:
provisioningMode: efs-ap
fileSystemId: fs-xxxxxxxxxxxxxxxxx # Terraform çıktınızdaki EFS File System ID'si
directoryPerms: "700" # Dizin izinleri
# Eğer bir Access Point kullanıyorsanız aşağıdaki parametreyi de ekleyin:
# accessPointId: fsap-xxxxxxxxxxxxxxxxx # Terraform çıktınızdaki EFS Access Point ID'si
mountOptions:
- tls # Şifreli bağlantı
# pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: efs-claim
spec:
accessModes:
- ReadWriteMany # Birden fazla pod'un aynı anda yazma erişimi
storageClassName: efs-sc
resources:
requests:
storage: 5Gi # EFS esnek olduğu için bu değer sadece bir "talep"tir, gerçek kapasite değildir.
storageclass.yaml dosyasında fileSystemId ve isteğe bağlı olarak accessPointId alanlarına Terraform çıktınızdan aldığınız değerleri girmeniz gerektiğini unutmayın. ReadWriteMany erişim modu, EFS'nin ana avantajlarından biridir; birden fazla pod'un aynı anda aynı dosya sistemine okuma ve yazma erişimine sahip olmasını sağlar.
EKS Uygulamalarınızı EFS'ye Bağlama: Deployment ve StatefulSet Örnekleri
PVC oluşturulduktan sonra, EKS kümenizdeki uygulamalarınızı (Deployment'lar, StatefulSet'ler vb.) bu PVC'yi kullanarak EFS'ye bağlayabilirsiniz. Aşağıdaki örnek, bir Nginx uygulamasının nasıl bir PVC'ye bağlanacağını göstermektedir:
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-efs-app
spec:
selector:
matchLabels:
app: nginx-efs
replicas: 3
template:
metadata:
labels:
app: nginx-efs
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
volumeMounts:
- name: efs-volume
mountPath: /usr/share/nginx/html # Nginx'in statik içeriğini tutacağı yer
volumes:
- name: efs-volume
persistentVolumeClaim:
claimName: efs-claim # Yukarıda oluşturduğumuz PVC'nin adı
Bu Deployment tanımında, efs-claim adındaki PVC, Nginx pod'larının /usr/share/nginx/html dizinine bağlanmasını sağlıyor. Artık Nginx uygulaması, bu dizine yazılan statik içerikleri EFS üzerinden sunabilecek. Birden fazla Nginx pod'u aynı EFS dizinine erişebileceği için, bu, dağıtılmış bir web uygulaması için merkezi içerik yönetimi sağlar. Aynı mantıkla, birden fazla farklı uygulama (örneğin, bir Python back-end servisi, bir log toplama servisi) aynı veya farklı EFS erişim noktalarını kullanarak paylaşılan verilere erişebilir. Bu esneklik, karmaşık mikroservis mimarilerinde veri tutarlılığını ve erişilebilirliğini sağlamak için kritik öneme sahiptir.
kubectl apply -f storageclass.yaml, kubectl apply -f pvc.yaml ve kubectl apply -f deployment.yaml komutlarıyla bu kaynakları EKS kümenize uygulayarak entegrasyonu tamamlayabilirsiniz. Bu adımlar, EKS uygulamalarınızın EFS'nin sunduğu merkezi, ölçeklenebilir ve paylaşımlı dosya depolama yeteneklerinden tam olarak faydalanmasını sağlar.
Gerçek Dünya Senaryoları ve İleri Düzey Optimizasyonlar
EFS ve Terraform entegrasyonunun temelini anladığımıza göre, şimdi bu bilgiyi gerçek dünya senaryolarına nasıl uygulayabileceğimizi ve performansı, maliyeti ve güvenliği nasıl optimize edebileceğimizi inceleyelim. Mikroservis mimarileri, genellikle karmaşık veri akışlarına ve farklı hizmetler arasında paylaşılan kaynaklara ihtiyaç duyar. EFS, bu tür senaryolarda kalıcı depolama için ideal bir çözüm sunar.
Vaka Analizi: Mikroservisler Arası Paylaşımlı Konfigürasyon ve Log Yönetimi
Bir e-ticaret platformunuz olduğunu varsayalım. Bu platformda ürün katalog servisi, sipariş işleme servisi, kullanıcı yönetim servisi ve ödeme geçidi servisi gibi birçok mikroservis bulunmaktadır. Bu servislerin hepsi, merkezi bir yapılandırma deposuna erişmek ve loglarını merkezi bir konuma yazmak isteyebilir. Ayrıca, ürün görselleri veya fatura şablonları gibi statik içeriklerin de tüm servisler tarafından erişilebilir olması gerekebilir.
İşte bu senaryoda EFS'nin değeri ortaya çıkar:
- Paylaşımlı Konfigürasyon: Tüm mikroservisler için ortak konfigürasyon dosyalarını (örneğin, veritabanı bağlantı ayarları, API anahtarları) EFS'de
/configgibi bir dizinde saklayabilirsiniz. Her servis kendi EKS pod'unda bu dizini bir volume olarak bağlar. Böylece, konfigürasyon değişiklikleri tek bir yerden yönetilir ve tüm servisler tarafından anında erişilebilir hale gelir. - Merkezi Log Yönetimi: Her mikroservis, kendi loglarını EFS'deki özel bir alt dizine (örneğin,
/logs/product-catalog,/logs/order-processing) yazabilir. Ardından, bir merkezi log toplama aracı (örneğin, Fluent Bit, Filebeat) veya ayrı bir EKS pod'u, bu EFS dizinindeki tüm logları toplayarak Elasticsearch veya CloudWatch Logs gibi bir merkeze aktarabilir. Bu yaklaşım, dağıtık sistemlerde log takibini ve sorun gidermeyi önemli ölçüde basitleştirir. - Statik İçerik Paylaşımı: Ürün görselleri, PDF dosyaları veya diğer statik web varlıkları EFS'de saklanabilir. Hem front-end servisi bu görsellere doğrudan erişebilir hem de bir arka plan işleme servisi bu görseller üzerinde thumbnail oluşturma veya sıkıştırma gibi işlemler yapabilir.
Bu senaryoyu Terraform ile yapılandırmak, EFS dosya sistemi ve birden fazla erişim noktası oluşturmayı gerektirir. Her erişim noktası, farklı bir mikroservis veya log dizini için kullanılabilir, böylece izinler ve erişim yolları daha granüler bir şekilde yönetilebilir. EKS tarafında ise, her mikroservisin deployment'ında ilgili PVC'ler ve volume mount'lar tanımlanır.
# config dizini için erişim noktası
resource "aws_efs_access_point" "config_access_point" {
file_system_id = aws_efs_file_system.eks_shared_efs.id
posix_user { gid = 1000, uid = 1000 }
root_directory { path = "/config", creation_info { owner_gid = 1000, owner_uid = 1000, permissions = "0755" } }
tags = { Name = "config-ap" }
}
# logs dizini için erişim noktası
resource "aws_efs_access_point" "logs_access_point" {
file_system_id = aws_efs_file_system.eks_shared_efs.id
posix_user { gid = 1000, uid = 1000 }
root_directory { path = "/logs", creation_info { owner_gid = 1000, owner_uid = 1000, permissions = "0755" } }
tags = { Name = "logs-ap" }
}
Kubernetes tarafında ise, her servis kendi PVC'sini oluştururken ilgili accessPointId'yi StorageClass'ında belirterek EFS'nin belirli bir bölümüne bağlanır.
Performans ve Maliyet Optimizasyonu İçin İpuçları
EFS, esnek bir hizmet olsa da, performansı ve maliyeti optimize etmek için bazı stratejiler mevcuttur:
- Throughput Modu Seçimi: EFS iki ana throughput modu sunar:
- Bursting Throughput: Çoğu iş yükü için varsayılan ve uygun olan moddur. EFS kapasitenizle orantılı olarak temel bir aktarım hızı sağlar ve kısa süreli yüksek I/O operasyonları için burst (ani yükselme) yeteneği sunar.
- Provisioned Throughput: Sürekli yüksek ve tahmin edilebilir I/O gerektiren iş yükleri için uygundur. Belirli bir aktarım hızını önceden belirlersiniz, ancak bu mod bursting'e göre daha maliyetlidir. Uygulamanızın I/O profiline göre doğru seçimi yapmak kritik öneme sahiptir.
- Depolama Sınıfları (Lifecycle Management): EFS, iki depolama sınıfı sunar:
- Standard: En sık erişilen veriler için.
- Infrequent Access (IA): Daha az sıklıkla erişilen veriler için optimize edilmiştir ve daha düşük maliyetlidir. EFS yaşam döngüsü politikalarını kullanarak, belirli bir süre (örneğin, 30 gün) erişilmeyen dosyaları otomatik olarak IA sınıfına taşıyabilir ve maliyetlerden tasarruf edebilirsiniz. Örneğin, eski log dosyaları için IA idealdir.
- Monitoring: CloudWatch Metrikleri aracılığıyla EFS dosya sisteminizin performansını (throughput, latency, I/O operasyonları) sürekli izleyin. Olası darboğazları veya kapasite sorunlarını erken tespit ederek müdahale edebilirsiniz.
Uzman İpucu: Yoğun okuma operasyonları gerektiren uygulamalar için EFS mount hedeflerini okuma replikaları gibi değerlendirebilirsiniz. Aynı dosya sistemine farklı AZ'lerden bağlanmak, AZ başarısızlığı durumunda bile veri erişilebilirliğini artırır.
Güvenlik En İyi Uygulamaları: Şifreleme ve Erişim Kontrolleri
EFS verilerinizin güvenliğini sağlamak için aşağıdaki en iyi uygulamaları göz önünde bulundurun:
- Veri Şifrelemesi: EFS, hem aktarımdaki (in-transit) hem de beklemedeki (at-rest) verileri şifreleme olanağı sunar. Dosya sistemini oluştururken KMS anahtarları ile beklemedeki şifrelemeyi etkinleştirmeyi her zaman tercih edin. Aktarımdaki şifreleme için ise TLS kullanan EFS mount helper'ı veya EFS CSI sürücüsünün TLS özelliğini kullanın.
- Ağ Erişimi (Güvenlik Grupları): EFS mount hedeflerinin bağlı olduğu güvenlik gruplarını dikkatlice yapılandırın. Yalnızca EKS düğümlerinizin IP adreslerinden veya güvenlik gruplarından gelen NFS (port 2049) trafiğine izin verin. Gereksiz portları veya IP aralıklarını açmaktan kaçının.
- EFS Erişim Noktaları (Access Points): Erişim noktalarını kullanarak Kubernetes pod'larınıza granüler izinler atayın. Her uygulama için belirli bir kök dizin ve POSIX kullanıcı/grup kimliği (UID/GID) tanımlayın. Bu, uygulamaların yalnızca kendi verilerine erişmesini sağlar ve yetkisiz erişimi engeller.
- IAM Rolleri: EFS CSI sürücüsünün EFS kaynaklarına erişim için kullandığı IAM rolünün en az ayrıcalıklı prensibiyle (Least Privilege Principle) yapılandırıldığından emin olun. Yalnızca ihtiyaç duyduğu minimum yetkilere sahip olmalıdır.
- VPC Endpoint'leri: Eğer EKS kümenizden EFS'ye özel ağ üzerinden bağlanıyorsanız, VPC endpoint'lerini kullanarak trafik akışını daha güvenli ve verimli hale getirebilirsiniz.
Bu ileri düzey optimizasyonlar ve güvenlik uygulamaları, EFS tabanlı veri paylaşım çözümünüzün sadece işlevsel değil, aynı zamanda performanslı, maliyet-etkin ve güvenli olmasını sağlayacaktır. Özellikle büyük ve hassas verilerle çalışan uygulamalar için bu detaylara dikkat etmek, sistemin genel sağlamlığı açısından hayati öneme sahiptir.
Sonuç: EFS ve Terraform ile Ölçeklenebilir ve Yönetilebilir Veri Altyapısı
Günümüzün hızla değişen dijital dünyasında, mikroservis mimarileri ve konteynerize uygulamalar, işletmelerin çeviklik ve ölçeklenebilirlik hedeflerine ulaşmasında kilit rol oynamaktadır. Ancak bu karmaşık yapılar, özellikle veri yönetimi ve paylaşımı konusunda yeni zorlukları da beraberinde getirir. AWS EFS (Elastic File System) ve Terraform'un birleşimi, bu zorlukların üstesinden gelmek için güçlü, esnek ve otomatik bir çözüm sunar. Bu makale boyunca, EFS'nin birden fazla EKS uygulamasının aynı anda, güvenli ve performanslı bir şekilde kalıcı verilere erişmesini nasıl sağladığını, Terraform'un ise bu karmaşık altyapının kurulumunu ve yönetimini nasıl basitleştirdiğini adım adım inceledik.
Girişte ortaya koyduğumuz "Birden Fazla EKS Uygulaması İçin Veri Paylaşımı Neden Zorlayıcı?" sorusuna yanıt olarak, EFS'nin dağıtık sistemlerdeki veri tutarlılığı, erişilebilirlik ve ölçeklenebilirlik problemlerine sunduğu çözümleri gördük. Temel kavramlardan başlayarak, Terraform ile bir EFS dosya sistemi ve erişim noktaları oluşturmanın pratik adımlarını ele aldık. Güvenlik grupları ve ağ yapılandırmalarının önemini vurgulayarak, EFS'nin güvenli bir şekilde nasıl erişilebilir hale getirileceğini gösterdik. Ardından, EFS CSI sürücüsünü kullanarak EKS kümelerine EFS entegrasyonunun nasıl yapılacağını, Persistent Volume (PV) ve Persistent Volume Claim (PVC) tanımlarını ve son olarak da EKS uygulamalarının bu paylaşılan depolama alanına nasıl bağlanacağını detaylandırdık. Gerçek dünya senaryoları ve vaka analizleri ile, merkezi konfigürasyon ve log yönetimi gibi kritik kullanım durumlarına pratik çözümler sunduk. Son olarak, performans ve maliyet optimizasyonuna yönelik ipuçları ile güvenlik en iyi uygulamalarını paylaşarak, okuyucularımızın kendi bulut ortamlarında sağlam ve optimize edilmiş çözümler geliştirmelerine yardımcı olmayı hedefledik.
Terraform ile EFS ve EKS entegrasyonu, altyapıyı kod olarak yönetme (IaC) prensibini benimseyerek, manuel hataları azaltır, tekrarlanabilirliği artırır ve daha hızlı dağıtım döngüleri sağlar. Bu yaklaşım, sadece operasyonel yükü azaltmakla kalmaz, aynı zamanda ekiplerin daha verimli çalışmasına olanak tanır. EFS'nin ölçeklenebilirliği, yüksek kullanılabilirliği ve yönetilen yapısı sayesinde, uygulamalarınızın veri depolama ihtiyaçları konusunda endişelenmenize gerek kalmaz. Bu kombinasyon, şirketlerin modern bulut mimarilerinde veri odaklı uygulamalarını başarıyla çalıştırmaları için vazgeçilmez bir araç setidir.
Sıkça Sorulan Sorular (SSS)
-
EFS, birden fazla AWS bölgesindeki EKS kümeleri arasında veri paylaşımına izin verir mi?
Hayır, EFS bir bölgesel (regional) hizmettir ve yalnızca oluşturulduğu AWS bölgesindeki kaynaklar tarafından erişilebilir. Farklı bölgelerdeki EKS kümeleri arasında veri paylaşımı için genellikle daha karmaşık çözümler (örneğin, bölge içi EFS'ye veri kopyalayan Cross-Region Replication veya S3 gibi global depolama hizmetleri) gereklidir.
-
EFS yerine EBS (Elastic Block Store) kullanabilir miyim? Aralarındaki temel fark nedir?
EBS, tek bir EC2 örneğine bağlı blok depolamadır ve
ReadWriteOnceerişim modunu destekler, yani aynı anda birden fazla pod veya sunucu tarafından paylaşılamaz. EFS ise ağ dosya sistemi (NFS) tabanlıdır veReadWriteManyerişim modunu destekler, bu da birden fazla kaynağın aynı anda aynı dosya sistemine erişebileceği anlamına gelir. Paylaşımlı veri için EFS tercih edilmelidir, tek bir pod'un kalıcı depolaması için EBS (veya EKS'de Persistent Volume ile EBS) uygundur. -
EFS depolamasının maliyetini nasıl optimize edebilirim?
Maliyeti optimize etmek için "Infrequent Access (IA)" depolama sınıfını ve EFS Yaşam Döngüsü Yönetimi politikalarını kullanın. Az erişilen verileri otomatik olarak IA sınıfına taşıyarak önemli ölçüde tasarruf sağlayabilirsiniz. Ayrıca, uygulamanızın gerçek I/O ihtiyaçlarına uygun throughput modunu (bursting veya provisioned) seçmek de maliyet açısından önemlidir.
-
EFS CSI sürücüsü kurulumu için neden IAM rolü gerekiyor?
EFS CSI sürücüsü, EKS pod'larının EFS dosya sistemleri ve erişim noktaları ile etkileşim kurmasını sağlar. Bu etkileşimi yönetmek (örneğin, EFS dosya sistemlerini açıklamak, mount hedefleri oluşturmak) için CSI sürücüsünün AWS API çağrıları yapması gerekir. Bu API çağrıları için gerekli yetkiler, EFS CSI Service Account'ına atanan bir IAM rolü (IRSA - IAM Roles for Service Accounts) aracılığıyla sağlanır.
-
Mobil uyumluluk için HTML'de ne gibi önlemler almalıyım?
Modern HTML ve CSS yaklaşımları, mobil uyumluluğu sağlamak için önemlidir. Örneğin,
viewportmeta etiketi, duyarlı resimler (veyasrcset), esnek kutu modelleri (flexbox, grid) ve medya sorguları (@media) kullanmak gereklidir. Bu makale, teknik içeriğe odaklandığı için detaylı CSS örnekleri içermemekle birlikte, bir web sayfasının temel yapısı için aşağıdaki gibi bir medya sorgusu örneği kullanılabilir:/* style.css */ body { font-family: Arial, sans-serif; line-height: 1.6; margin: 0 auto; max-width: 1200px; padding: 20px; } h2 { color: #2c3e50; } p { margin-bottom: 1em; } /* Küçük ekranlar için stil kuralları */ @media (max-width: 768px) { body { padding: 10px; font-size: 0.9em; } h2 { font-size: 1.5em; } pre code { overflow-x: auto; /* Kod bloklarının küçük ekranda kaydırılabilir olması */ } } /* Daha küçük ekranlar için stil kuralları */ @media (max-width: 480px) { h2 { font-size: 1.2em; } ul, ol { padding-left: 20px; } }Bu CSS kuralları, ekran genişliği azaldıkça metin boyutlarını ve dolguları ayarlayarak içeriğin okunabilirliğini artırır ve kod bloklarının yatay olarak kaydırılabilir olmasını sağlar.