Amazon EKS ve Kalıcı Depolama İhtiyacı Nedir?

Amazon EFS ve EKS Entegrasyonu: Terraform ile Kalıcı Depolama

Amazon EKS kümeleriniz için kalıcı depolama arayışında mısınız? Bu rehberde, Amazon EFS’yi EKS ile Terraform kullanarak nasıl entegre edeceğinizi adım adım ve uygulamalı örneklerle keşfedin.

Günümüzün bulut tabanlı uygulamaları, dinamik ve ölçeklenebilir altyapılar üzerinde çalışmayı gerektiriyor. Bu altyapıların başında şüphesiz Kubernetes geliyor. Amazon Elastic Kubernetes Service (EKS), AWS bulutunda yönetilen Kubernetes kümeleri sunarak, geliştiricilerin uygulamalarını daha verimli bir şekilde dağıtmasına ve yönetmesine olanak tanır. Ancak, konteyner tabanlı uygulamaların doğası gereği, pod’lar genellikle kısa ömürlüdür ve yeniden başlatıldıklarında veya farklı düğümlere taşındıklarında üzerlerindeki verileri kaybederler. İşte bu noktada kalıcı depolama (persistent storage) ihtiyacı ortaya çıkar.

Pek çok uygulama, çalışabilmek için verilerini kalıcı olarak saklamaya ihtiyaç duyar. Örneğin, bir veritabanı, bir içerik yönetim sistemi (CMS) veya bir e-ticaret platformu düşünün. Bu tür stateful uygulamalar, pod’ların ömründen bağımsız olarak verilerin korunmasını ve erişilebilir olmasını bekler. Aksi takdirde, her pod yeniden başlatıldığında, uygulama tüm verilerini kaybeder ve baştan başlamak zorunda kalır ki bu, iş sürekliliği açısından kabul edilemez bir durumdur. Kubernetes’in kalıcı depolama mekanizmaları, PersistentVolume (PV) ve PersistentVolumeClaim (PVC) sayesinde bu soruna çözüm sunar. Ancak, bu mekanizmaların altında yatan depolama çözümünün doğru seçilmesi büyük önem taşır.

Peki, Amazon EKS ortamında kalıcı depolama için en uygun seçeneklerden biri neden Amazon Elastic File System (EFS)? Çünkü EFS, birden fazla EKS pod’u tarafından aynı anda erişilebilen, ölçeklenebilir, esnek ve tam olarak yönetilen bir NFS dosya sistemi sağlar. Bu, mikro hizmet tabanlı mimarilerde, özellikle de birden fazla pod’un aynı dosya sistemine yazma/okuma yapması gereken senaryolarda kritik bir avantajdır. EKS ile entegre edildiğinde, EFS, uygulamalarınızın yüksek erişilebilirlik ve veri tutarlılığı gereksinimlerini karşılamalarına yardımcı olur. Ayrıca, Terraform gibi bir Altyapı olarak Kod (IaC) aracı kullanarak bu entegrasyonu otomatikleştirmek, hem hızı artırır hem de insan hatası riskini en aza indirir. Bu kombinasyon, DevOps pratiklerini benimsemiş ekipler için vazgeçilmez bir çözüm sunar. Dolayısıyla, bu makale boyunca, bu güçlü üçlüyü – EKS, EFS ve Terraform’u – bir araya getirerek, konteynerize uygulamalarınız için sağlam ve sürdürülebilir bir depolama altyapısı nasıl oluşturacağınızı detaylı bir şekilde inceleyeceğiz.

Temel Taşlar: Amazon EFS, EKS ve Terraform’a Yakından Bakış

Modern bulut altyapılarında başarılı entegrasyonlar gerçekleştirebilmek için, kullanılan temel bileşenleri derinlemesine anlamak elzemdir. Bu bölümde, entegrasyonumuzun temelini oluşturan Amazon EFS, Amazon EKS ve Terraform’a yakından bakacak, her birinin neden bu senaryoda kritik rol oynadığını anlayacağız.

Amazon EFS Nedir ve Neden Önemlidir?

Amazon Elastic File System (EFS), AWS bulutunda kolayca ölçeklenebilen, sunucusuz, tam olarak yönetilen bir NFS (Network File System) dosya depolama hizmetidir. EFS’nin en büyük avantajlarından biri, aynı anda binlerce EC2 örneği veya konteyner tarafından erişilebilmesidir. Bu özellik, özellikle çok sayıda pod’un aynı veri setine erişmesi gereken EKS ortamları için onu ideal bir seçenek haline getirir. EFS, verilerinizin yüksek oranda dayanıklı olmasını sağlar; AWS’nin belirttiğine göre, verileri birden fazla Availability Zone’da (AZ) depolayarak %99.999999999 (11 adet 9) dayanıklılık sunar. Ayrıca, depolama alanınızı manuel olarak sağlamanıza gerek kalmadan, uygulama ihtiyaçlarınıza göre otomatik olarak ölçeklenir, bu da maliyet etkinliği ve operasyonel kolaylık sağlar.

EFS’nin diğer önemli özellikleri arasında şunlar bulunur:

• Paylaşımlı Erişim: Birden fazla EC2 örneği veya EKS pod’u aynı anda aynı dosya sistemine okuma/yazma erişimi sağlayabilir.
• Esneklik: Dosya sistemleri terabaytlarca veriye kadar ölçeklenebilir ve sadece kullandığınız depolama alanı için ödeme yaparsınız.
• Yüksek Performans: Farklı performans modları (General Purpose, Max I/O) ve çıkış tipleri (Bursting, Provisioned) ile uygulamanızın gereksinimlerine uygun performansı sağlayabilirsiniz.
• Güvenlik: Veri aktarımı sırasında ve depoda şifreleme, AWS IAM ile entegrasyon ve ağ erişimi için güvenlik grupları gibi özelliklerle güvenlik sağlanır.

Kısacası, EFS, EKS üzerinde çalışan stateful uygulamalar için esneklik, ölçeklenebilirlik ve yüksek erişilebilirlik sunan kritik bir depolama çözümüdür.

Amazon EKS Neden Tercih Edilmeli?

Amazon Elastic Kubernetes Service (EKS), geliştiricilerin ve operasyon ekiplerinin Kubernetes’i AWS bulutunda kolayca dağıtmasına, yönetmesine ve ölçeklendirmesine olanak tanıyan tam olarak yönetilen bir hizmettir. EKS, Kubernetes kontrol düzleminin (master node’lar) yönetimini AWS’ye bırakarak, kullanıcıların yalnızca iş yüklerini (worker node’lar) yönetmeye odaklanmasını sağlar. Bu, operasyonel yükü önemli ölçüde azaltır ve altyapı yönetiminden ziyade uygulama geliştirmeye daha fazla zaman ayrılmasına imkan tanır.

EKS’nin tercih edilmesinin başlıca nedenleri şunlardır:

• Yönetilen Hizmet: Kontrol düzlemi için otomatik yamalama, yükseltmeler ve yüksek erişilebilirlik sunar.
• Güvenlik: AWS IAM ile derin entegrasyon, ağ izolasyonu ve güvenlik grupları ile güçlü güvenlik mekanizmaları sağlar.
• Ölçeklenebilirlik: Hem kontrol düzlemi hem de worker node’ları için kolay ölçeklenebilirlik sunar.
• Entegrasyon: AWS hizmetleriyle (VPC, IAM, CloudWatch, ELB gibi) sorunsuz entegrasyon sağlar.

EKS, şirketlerin modern, konteynerize uygulamalarını güvenilir, ölçeklenebilir ve yüksek performanslı bir ortamda çalıştırmaları için güçlü bir temel oluşturur. Bu da onu kalıcı depolama çözümleriyle entegrasyon için mükemmel bir platform yapar.

Terraform ile Altyapı Yönetimi Nasıl Kolaylaşır?

Terraform, HashiCorp tarafından geliştirilen açık kaynaklı bir Altyapı olarak Kod (Infrastructure as Code – IaC) aracıdır. Kullanıcıların bulut veya şirket içi kaynaklarını tanımlamalarını ve sağlamalarını sağlayan bildirimsel bir yapılandırma dili (HashiCorp Configuration Language – HCL) kullanır. Terraform’un temel avantajı, altyapıyı kod olarak yönetme yeteneğidir; bu da altyapının versiyonlanabilmesini, test edilebilir olmasını ve dağıtımların tutarlı ve tekrarlanabilir olmasını sağlar. Bu sayede, EKS kümesi oluşturmaktan EFS dosya sistemi yapılandırmaya, hatta Kubernetes kaynaklarını bile tanımlamaya kadar tüm altyapınızı tek bir araçla yönetebilirsiniz.

Terraform’un bu entegrasyon senaryosunda kritik olmasının nedenleri:

• Otomasyon: Tüm AWS ve Kubernetes kaynaklarının otomatik olarak sağlanmasını ve güncellenmesini sağlar.
• Tutarlılık: Altyapının her dağıtımında aynı şekilde oluşturulmasını garanti eder, bu da “konfigürasyon kayması” (configuration drift) riskini azaltır.
• Versiyon Kontrolü: Altyapı tanımlarını Git gibi bir versiyon kontrol sisteminde saklayarak değişiklikleri izleme ve geri alma imkanı sunar.
• Modülerlik: Tekrar kullanılabilir modüller aracılığıyla altyapı kodunu düzenlemeyi ve paylaşmayı kolaylaştırır.

Terraform, bu entegrasyon sürecini basitleştirir, hızlandırır ve hataları minimize eder. Bu üçlünün birleşimi, modern bir bulut altyapısı için sağlam, ölçeklenebilir ve yönetilebilir bir temel oluşturur.

Adım Adım Entegrasyon: Terraform ile EFS ve EKS Nasıl Yapılandırılır?

Amazon EFS’yi Amazon EKS ile entegre etmek, özellikle Terraform kullanarak, sistematik bir süreç gerektirir. Bu bölümde, gerekli önkoşulları belirledikten sonra, EFS dosya sistemi oluşturma, EKS kümesini kurma ve EFS CSI sürücüsünü yapılandırma adımlarını detaylı Terraform kod örnekleriyle açıklayacağız. Unutmayın, bu adımları takip etmeden önce AWS CLI, kubectl ve Terraform’un sisteminizde kurulu ve yapılandırılmış olduğundan emin olmalısınız.

EFS Dosya Sistemi Oluşturma ve Yapılandırma Adımları Nelerdir?

EKS kümenizin kullanacağı EFS dosya sistemini oluşturmak için öncelikle gerekli ağ altyapısını (VPC, alt ağlar, güvenlik grupları) tanımlamamız gerekiyor. EFS, EC2 örneklerinin veya EKS pod’larının ona bağlanabilmesi için bir veya daha fazla Mount Target’a ihtiyaç duyar. Her Mount Target, EFS dosya sistemine bir alt ağda ağ arayüzü sağlar.

Aşağıdaki Terraform kodu, bu adımları otomatikleştirmek için kullanılabilir:

resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  enable_dns_hostnames = true
  tags = {
    Name = "eks-efs-vpc"
  }
}

resource "aws_subnet" "public" {
  count             = 2
  vpc_id            = aws_vpc.main.id
  cidr_block        = cidrsubnet(aws_vpc.main.cidr_block, 8, count.index)
  availability_zone = data.aws_availability_zones.available.names[count.index]
  tags = {
    Name = "eks-efs-public-subnet-${count.index}"
  }
}

resource "aws_security_group" "efs_security_group" {
  name        = "efs-sg"
  description = "Allow NFS traffic to EFS"
  vpc_id      = aws_vpc.main.id

  ingress {
    description = "Allow NFS from VPC CIDR"
    from_port   = 2049 # NFS port
    to_port     = 2049
    protocol    = "tcp"
    cidr_blocks = [aws_vpc.main.cidr_block]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }
  tags = {
    Name = "efs-sg"
  }
}

resource "aws_efs_file_system" "eks_efs" {
  creation_token = "eks-efs-file-system"
  encrypted      = true
  performance_mode = "generalPurpose" # Veya "maxIO"
  throughput_mode  = "bursting"       # Veya "provisioned"

  tags = {
    Name = "eks-efs"
  }
}

resource "aws_efs_mount_target" "eks_efs_mount_target" {
  count           = length(aws_subnet.public)
  file_system_id  = aws_efs_file_system.eks_efs.id
  subnet_id       = aws_subnet.public[count.index].id
  security_groups = [aws_security_group.efs_security_group.id]
}

Yukarıdaki kod bloğu öncelikle bir VPC ve iki adet genel alt ağ oluşturur. Ardından, EFS’ye NFS (port 2049) trafiğine izin veren bir güvenlik grubu tanımlar. Daha sonra aws_efs_file_system kaynağı ile şifreli bir EFS dosya sistemi oluşturulur. performance_mode ve throughput_mode parametreleri, uygulamanızın performans gereksinimlerine göre ayarlanmalıdır. Son olarak, her bir alt ağ için birer aws_efs_mount_target oluşturularak EFS’nin bu alt ağlar üzerinden erişilebilir olması sağlanır. Bu, EFS’nin yüksek erişilebilirlik sağlamak için farklı Availability Zone’larda bulunmasına olanak tanır.

Uzman İpucu: Çoklu Mount Target’lar, EFS dosya sisteminizi birden fazla Availability Zone’a yayarak yüksek erişilebilirlik sağlar. EKS kümenizin düğümleri hangi AZ’de olursa olsun EFS’ye bağlanabilir.

EKS Kümesi Oluşturma ve EFS CSI Sürücüsü Kurulumu Nasıl Gerçekleşir?

EFS dosya sistemi hazır olduğunda, bir EKS kümesi oluşturup EFS CSI (Container Storage Interface) sürücüsünü entegre etmemiz gerekiyor. CSI sürücüsü, Kubernetes’in EFS dosya sistemini PersistentVolume (PV) ve PersistentVolumeClaim (PVC) aracılığıyla kullanmasını sağlar. EKS’nin EFS’ye erişebilmesi için gerekli IAM izinlerini ve OIDC sağlayıcısını yapılandırmak da bu adımın önemli bir parçasıdır.

# EKS Cluster IAM Role
resource "aws_iam_role" "eks_cluster_role" {
  name = "eks-cluster-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole"
        Effect = "Allow"
        Principal = {
          Service = "eks.amazonaws.com"
        }
      },
    ]
  })
}

resource "aws_iam_role_policy_attachment" "eks_cluster_policy" {
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy"
  role       = aws_iam_role.eks_cluster_role.name
}

# EKS Cluster
resource "aws_eks_cluster" "main" {
  name     = "eks-efs-cluster"
  role_arn = aws_iam_role.eks_cluster_role.arn
  vpc_config {
    subnet_ids = aws_subnet.public.*.id
  }
  depends_on = [
    aws_iam_role_policy_attachment.eks_cluster_policy
  ]
}

# EKS OIDC Provider
resource "aws_iam_openid_connect_provider" "eks_oidc" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.eks_cluster_thumbprint.certificates[0].sha1_fingerprint]
  url             = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

data "tls_certificate" "eks_cluster_thumbprint" {
  url = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

# EFS CSI Driver IAM Role
resource "aws_iam_role" "efs_csi_driver_role" {
  name = "efs-csi-driver-role"
  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Principal = {
          Federated = aws_iam_openid_connect_provider.eks_oidc.arn
        }
        Action = "sts:AssumeRoleWithWebIdentity"
        Condition = {
          StringEquals = {
            "${replace(aws_iam_openid_connect_provider.eks_oidc.url, "https://", "")}:sub" = "system:serviceaccount:kube-system:efs-csi-controller-sa"
          }
        }
      },
    ]
  })
}

resource "aws_iam_policy" "efs_csi_driver_policy" {
  name        = "efs-csi-driver-policy"
  description = "Policy for EFS CSI driver to manage EFS resources"
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = [
          "elasticfilesystem:DescribeMountTargets",
          "elasticfilesystem:DescribeFileSystems",
          "elasticfilesystem:DescribeAccessPoints"
        ]
        Resource = "*"
      },
      {
        Effect = "Allow"
        Action = [
          "ec2:DescribeAvailabilityZones"
        ]
        Resource = "*"
      }
    ]
  })
}

resource "aws_iam_role_policy_attachment" "efs_csi_driver_policy_attach" {
  policy_arn = aws_iam_policy.efs_csi_driver_policy.arn
  role       = aws_iam_role.efs_csi_driver_role.name
}

# EKS Addon for EFS CSI Driver (recommended approach)
resource "aws_eks_addon" "efs_csi_driver" {
  cluster_name          = aws_eks_cluster.main.name
  addon_name            = "aws-efs-csi-driver"
  addon_version         = "v1.5.0" # En son sürümü kontrol edin
  service_account_role_arn = aws_iam_role.efs_csi_driver_role.arn
  resolve_conflicts     = "OVERWRITE"
  depends_on = [
    aws_iam_openid_connect_provider.eks_oidc
  ]
}

Bu kod bloğu karmaşık görünse de, adım adım incelendiğinde oldukça mantıklıdır. Öncelikle EKS kümesi için bir IAM rolü ve gerekli politikayı tanımlarız. Ardından, aws_eks_cluster kaynağı ile kümemizi oluştururuz. EKS kümesi oluşturulduktan sonra, Kubernetes hizmet hesaplarının AWS kaynaklarına güvenli bir şekilde erişmesini sağlayan bir OIDC (OpenID Connect) sağlayıcısı oluşturulur. Bu, aws_iam_openid_connect_provider kaynağı ile yapılır ve data.tls_certificate kullanılarak küme sertifikasının parmak izi alınır.

Daha sonra, EFS CSI sürücüsü için özel bir IAM rolü (efs_csi_driver_role) oluşturulur. Bu rol, EKS kümesinin OIDC sağlayıcısı aracılığıyla kube-system ad alanındaki efs-csi-controller-sa hizmet hesabına atanır. Bu, sürücünün EFS kaynaklarını yönetmek için gereken AWS API çağrılarını yapmasını sağlar. aws_iam_policy ile EFS’ye erişim için gerekli izinleri içeren bir politika tanımlanır. Son ve en kritik adım ise, aws_eks_addon kaynağını kullanarak EFS CSI sürücüsünü EKS kümesine doğrudan bir eklenti olarak kurmaktır. Bu, AWS tarafından yönetilen ve önerilen bir yaklaşımdır ve kurulumu büyük ölçüde basitleştirir. service_account_role_arn parametresi ile daha önce oluşturduğumuz CSI sürücüsü IAM rolünü buraya bağlarız. addon_version için her zaman en güncel sürümü kullanmayı unutmayın.

Bu kapsamlı Terraform yapılandırması sayesinde, EFS dosya sisteminiz ve EKS kümeniz arasındaki entegrasyonun temelini sağlam bir şekilde atmış olursunuz. Artık Kubernetes uygulamalarınız, bu EFS dosya sistemini kalıcı depolama olarak kullanmaya hazırdır.

Uygulamalı Senaryolar: EFS Kalıcı Birim Talepleri (PVC) ve Kullanımı

EFS dosya sistemi ve EKS kümesi ile EFS CSI sürücüsü başarıyla yapılandırıldıktan sonra, sıra Kubernetes uygulamalarınızın bu kalıcı depolamayı kullanmasına geliyor. Bu bölümde, EFS tabanlı PersistentVolume (PV) ve PersistentVolumeClaim (PVC) oluşturmanın yanı sıra, bir uygulamanın (örneğin, bir web sunucusu veya WordPress gibi bir CMS) bu depolamayı nasıl kullanacağını gösteren gerçek dünya senaryolarına odaklanacağız. Terraform’un Kubernetes sağlayıcısı sayesinde, bu Kubernetes kaynaklarını bile IaC prensipleriyle yönetebiliriz.

Stateful Uygulamalar İçin Kalıcı Depolama Nasıl Tanımlanır?

Kubernetes’te kalıcı depolama kullanmanın ilk adımı bir StorageClass tanımlamaktır. StorageClass, Kubernetes kümesindeki depolama birimlerini soyutlamak ve dinamik olarak depolama sağlamak için kullanılır. EFS CSI sürücüsünü kurduğumuz için, EFS tabanlı depolama sağlamak için özel bir StorageClass tanımlayabiliriz.

resource "kubernetes_storage_class" "efs_sc" {
  metadata {
    name = "efs-sc"
  }
  provisioner          = "efs.csi.aws.com"
  parameters = {
    provisioningMode   = "eXistingFileSysteM" # Dinamik EFS oluşturma yerine mevcut EFS'yi kullan
    fileSystemId       = aws_efs_file_system.eks_efs.id
    directoryPerms     = "777" # Örnek için, daha kısıtlayıcı olabilir
    # accesspoint id'si belirtilirse, EFS Access Point kullanılır
    # accessPointId      = aws_efs_access_point.example.id
  }
  reclaim_policy       = "Retain"
  volume_binding_mode  = "Immediate"
  mount_options        = ["tls"] # EFS'ye güvenli bağlantı için
}

Yukarıdaki StorageClass, efs.csi.aws.com sağlayıcısını kullanarak mevcut EFS dosya sistemimizi (fileSystemId) işaret eder. provisioningMode: eXistingFileSysteM parametresi, Kubernetes’in mevcut bir EFS dosya sistemini kullanacağını belirtir. reclaim_policy: Retain, PVC silindiğinde EFS üzerindeki verilerin korunmasını sağlar, bu da veri kaybını önlemek için önemlidir. mount_options: [“tls”] ise güvenli bağlantıyı teşvik eder.

Ardından, bir PersistentVolumeClaim (PVC) oluştururuz. PVC, bir uygulamanın talep ettiği depolama kaynaklarını tanımlayan bir Kubernetes nesnesidir.

resource "kubernetes_persistent_volume_claim" "efs_pvc" {
  metadata {
    name      = "efs-claim"
    namespace = "default" # Uygulamanızın çalıştığı namespace
  }
  spec {
    access_modes       = ["ReadWriteMany"] # EFS için tipik
    storage_class_name = kubernetes_storage_class.efs_sc.metadata[0].name
    resources {
      requests = {
        storage = "5Gi" # Talep edilen depolama alanı, EFS kapasiteye göre otomatik ölçeklenir
      }
    }
  }
}

Bu PVC, efs-sc StorageClass‘ı kullanarak 5 GB depolama alanı talep eder. ReadWriteMany erişim modu, EFS’nin anahtar özelliklerinden biridir, çünkü birden fazla pod’un aynı anda depolama alanına okuma ve yazma yapmasına izin verir.

Şimdi, bu PVC‘yi kullanan basit bir Nginx dağıtımını inceleyelim:

resource "kubernetes_deployment" "nginx_deployment" {
  metadata {
    name      = "nginx-efs-app"
    namespace = "default"
  }
  spec {
    replicas = 3
    selector {
      match_labels = {
        app = "nginx-efs"
      }
    }
    template {
      metadata {
        labels = {
          app = "nginx-efs"
        }
      }
      spec {
        container {
          name  = "nginx"
          image = "nginx:latest"
          port {
            container_port = 80
          }
          volume_mount {
            name       = "efs-volume"
            mount_path = "/usr/share/nginx/html" # Nginx'in statik dosyalarını koyduğu yer
          }
        }
        volume {
          name = "efs-volume"
          persistent_volume_claim {
            claim_name = kubernetes_persistent_volume_claim.efs_pvc.metadata[0].name
          }
        }
      }
    }
  }
}

Bu Deployment, üç adet Nginx pod’u çalıştırır ve her bir pod, efs-claim adlı PVC‘yi /usr/share/nginx/html dizinine bağlar. Bu sayede, Nginx sunucusunun servis ettiği web dosyaları EFS üzerinde kalıcı olarak saklanır ve tüm pod’lar tarafından paylaşılır. Eğer bir pod ölürse veya yeniden planlanırsa, yeni pod aynı EFS depolama alanına bağlanır ve veriler sağlam kalır. Bu yapılandırma, birden fazla pod’un aynı veriye eşzamanlı olarak erişmesi gereken WordPress, Drupal gibi CMS uygulamaları veya paylaşımlı konfigürasyon dosyalarına ihtiyaç duyan mikro hizmetler için idealdir.

Vaka Analizi: E-ticaret Uygulamasının Veri Tutarlılığı

Bir e-ticaret uygulamasının fotoğraf galerisi ve ürün açıklamaları gibi statik içeriklerini depoladığını düşünelim. Bu içerikler sıkça güncellenir ve uygulamanın birden fazla mikro hizmet pod’u tarafından erişilmesi gerekir (örneğin, bir yükleyici servisi, bir gösterim servisi). Eğer bu veriler EKS pod’larının geçici depolamasında olsaydı, pod’lar yeniden başlatıldığında içerikler kaybolurdu. EFS’yi kalıcı depolama olarak kullanarak, tüm bu içerikler EFS’de merkezi olarak saklanır. Hem ürün fotoğraflarını yükleyen uploader-service pod’ları hem de web sitesinde bu fotoğrafları gösteren frontend-service pod’ları, ReadWriteMany erişim modu sayesinde aynı EFS alanına eşzamanlı olarak erişebilir. Bu, veri tutarlılığını sağlar, operasyonel karmaşıklığı azaltır ve uygulama ölçeklenebilirliğini artırır. Böylece, kullanıcılar her zaman en güncel ürün bilgilerini ve görsellerini görürken, uygulama geliştiricileri depolama yönetimi yerine iş mantığına odaklanabilirler.

Performans ve Güvenlik İpuçları: EFS ve EKS Entegrasyonunda Nelere Dikkat Edilmeli?

EFS ve EKS entegrasyonu, uygulamalarınıza güçlü bir kalıcı depolama çözümü sunarken, performansı optimize etmek ve güvenliği sağlamak için dikkat edilmesi gereken bazı önemli noktalar vardır. Doğru yapılandırmalarla hem maliyetleri düşürebilir hem de veri bütünlüğünü ve erişilebilirliğini artırabilirsiniz.

EFS Performans Modları ve Çıkış Tipleri Nelerdir?

EFS, uygulamanızın gereksinimlerine göre farklı performans modları ve çıkış (throughput) tipleri sunar. Bu seçenekleri anlamak, doğru dengeyi kurmanıza yardımcı olacaktır:

• Performans Modları:
  • General Purpose: Çoğu dosya tabanlı iş yükü için tasarlanmıştır ve düşük gecikme süresi sağlar. Web sunucuları, CMS’ler, geliştirme ortamları gibi uygulamalar için idealdir.
  • Max I/O: Çok sayıda istemciden çok yüksek oranda paralel işlemler gerektiren iş yükleri için tasarlanmıştır. Bu mod, daha yüksek gecikme süresi pahasına daha fazla giriş/çıkış operasyonunu destekler. Büyük veri analizi, medya işleme gibi senaryolarda kullanılabilir. Genellikle General Purpose modu çoğu EKS iş yükü için yeterli olacaktır.
• Çıkış Tipleri:
  • Bursting Throughput (Varsayılan): Dosya sisteminin boyutuyla orantılı olarak ölçeklenen bir temel çıkış seviyesi sunar. Dosya sistemi büyüdükçe temel çıkış seviyesi artar. Kredi sistemi kullanarak bu temel seviyenin üzerinde kısa süreli patlamalar yapabilir. Çoğu iş yükü için maliyet etkin ve uygun bir seçenektir.
  • Provisioned Throughput: Sabit ve belirli bir çıkış seviyesini garanti etmeniz gerektiğinde kullanılır. Bu, iş yükünüzün burst kredilerine güvenemeyecek kadar sürekli yüksek bir çıkış gerektirmesi durumunda tercih edilir. Performansın tahmin edilebilirliği açısından önemlidir ancak maliyeti daha yüksektir.

Uzman İpucu: Uygulamanızın I/O profiline dikkatlice bakın. Çoğu durumda, General Purpose performans modu ve Bursting Throughput çıkış tipi yeterli olacaktır. Aşırı sağlamadan kaçınmak maliyet tasarrufu sağlar. CloudWatch metriklerini kullanarak EFS performansını izleyerek doğru kararı verebilirsiniz.

Güvenlik En İyi Uygulamaları: EFS Erişimi Nasıl Sınırlandırılır?

EFS’ye erişimi güvence altına almak, EKS kümenizdeki verilerinizi korumak için hayati önem taşır:

• Şifreleme: EFS dosya sistemleri oluştururken verilerinizi şifrelemeyi (encrypted = true) her zaman etkinleştirin. Hem hareket halindeki (in-transit) hem de beklemedeki (at-rest) verilerin şifrelenmesi için TLS bağlantısı ve AWS Key Management Service (KMS) kullanılabilir.
• Ağ Güvenliği (Security Groups): EFS Mount Target’larına atanan güvenlik grupları, hangi IP adreslerinden veya güvenlik gruplarından (EKS worker node’larının güvenlik grubu gibi) NFS portu (2049) üzerinden erişime izin verileceğini kontrol etmelidir. En az ayrıcalık ilkesini uygulayın.
• IAM Yetkilendirmesi: EFS CSI sürücüsü için oluşturduğunuz IAM rolünün, yalnızca EFS kaynaklarını yönetmek ve tanımlamak için kesinlikle gerekli olan minimum izinlere sahip olduğundan emin olun.
• EFS Erişim Noktaları (Access Points): Erişim Noktaları, uygulama düzeyinde erişim denetimi sağlamak için EFS’ye özel giriş noktalarıdır. Her Erişim Noktası, belirli bir kök dizini ve POSIX kullanıcı/grup kimlikleri ile ilişkilendirilebilir. Bu sayede, EKS pod’ları belirli bir dizinden öteye geçemez ve belirli bir kullanıcı olarak işlem yapar. Bu, çok kiracılı (multi-tenant) veya sıkı izin denetimi gerektiren ortamlar için mükemmel bir güvenlik katmanı sağlar.

resource "aws_efs_access_point" "example" {
  file_system_id = aws_efs_file_system.eks_efs.id
  posix_user {
    gid = 1001
    uid = 1001
  }
  root_directory {
    path = "/app_data" # Uygulamanın erişeceği kök dizin
    creation_info {
      owner_gid   = 1001
      owner_uid   = 1001
      permissions = "0755"
    }
  }
  tags = {
    Name = "efs-access-point"
  }
}

Yukarıdaki örnekte, /app_data yolunu işaret eden ve belirli bir POSIX kullanıcısına (UID/GID 1001) ait bir EFS Erişim Noktası tanımlanmıştır. Kubernetes StorageClass‘ınızda bu accessPointId‘yi belirterek, pod’larınızın yalnızca bu dizine bu yetkilerle erişmesini sağlayabilirsiniz.

Yüksek Erişilebilirlik ve Felaket Kurtarma Stratejileri

EFS, doğası gereği yüksek erişilebilirlik sunar (verileri birden fazla AZ’de çoğaltır). Ancak, felaket kurtarma ve daha fazla esneklik için ek stratejiler düşünebilirsiniz:

• Çoklu AZ Mount Target’lar: Herhangi bir Availability Zone’da bir sorun olması durumunda EFS’ye kesintisiz erişim sağlamak için birden fazla AZ’de Mount Target oluşturduğunuzdan emin olun (Terraform kodumuz bunu zaten yapıyor).
• AWS Backup ile Yedekleme: EFS dosya sistemlerinizin düzenli olarak yedeklenmesini sağlamak için AWS Backup’ı kullanın. Bu, yanlışlıkla silme veya veri bozulması durumunda verilerinizi kurtarmanızı sağlar.
• Replikasyon (EFS Replication): EFS Replication, dosya sisteminizi aynı AWS Bölgesi içinde veya farklı bir AWS Bölgesi’ne otomatik olarak kopyalayarak veri kaybı riskini daha da azaltır ve felaket kurtarma hedeflerine ulaşmaya yardımcı olur.

Bu ipuçları ve en iyi uygulamalarla, EFS ve EKS entegrasyonunuz hem performanslı hem de güvenli bir şekilde çalışacaktır.

Sıkça Sorulan Sorular (SSS)

EFS’yi EKS ile Terraform kullanarak entegre etme süreci hakkında sıkça karşılaşılan sorular ve yanıtları aşağıdadır:

EFS ve EBS arasındaki temel fark nedir?

Cevap: Amazon EBS (Elastic Block Store), tek bir EC2 örneğine bağlı blok depolama birimidir ve ReadWriteOnce erişim modunu destekler. Yani sadece bir pod tarafından kullanılabilir. Amazon EFS ise birden fazla EC2 örneği veya EKS pod’u tarafından aynı anda erişilebilen paylaşımlı bir dosya sistemidir ve ReadWriteMany erişim modunu destekler. EFS, özellikle birden fazla pod’un aynı dosyalara eşzamanlı olarak erişmesi gereken senaryolar için idealdir.

EFS CSI sürücüsü neden gereklidir?

Cevap: EFS CSI (Container Storage Interface) sürücüsü, Kubernetes’in EFS dosya sistemini tanımasını ve kullanmasını sağlayan bir arabirimdir. Bu sürücü olmadan, Kubernetes pod’larınız EFS kaynaklarını doğrudan talep edemez ve kullanamaz. Sürücü, EKS kümenizdeki PV ve PVC taleplerini EFS dosya sistemine bağlamak için köprü görevi görür.

Terraform ile EFS Access Point nasıl oluşturulur?

Cevap: EFS Access Point, EFS dosya sistemine özel bir uygulama giriş noktasıdır. Terraform’da aws_efs_access_point kaynağını kullanarak oluşturulur. Bu kaynak, EFS dosya sistemi kimliğini, bir kök dizini (root directory) ve opsiyonel olarak POSIX kullanıcı/grup kimliklerini belirtmenizi sağlar. Daha sonra bu Access Point’i StorageClass tanımınızda kullanabilirsiniz.

EFS’de veri şifrelemesi varsayılan olarak açık mıdır?

Cevap: Hayır, EFS’de veri şifrelemesi varsayılan olarak açık değildir. EFS dosya sistemi oluştururken encrypted = true parametresini ayarlayarak şifrelemeyi etkinleştirmeniz önerilir. Bu, bekleyen verilerinizi AWS KMS anahtarlarıyla şifreler. Ayrıca, mount seçeneklerinde tls kullanarak hareket halindeki verilerinizi de şifreleyebilirsiniz.

EFS performansını nasıl izleyebilirim?

Cevap: EFS performansını Amazon CloudWatch metrikleri aracılığıyla izleyebilirsiniz. CloudWatch, dosya sistemi boyutunu, çıkış kullanımını (throughput utilization), I/O operasyonlarını ve gecikme süresi (latency) gibi kritik metrikleri sağlar. Bu metrikleri düzenli olarak kontrol ederek performans sorunlarını tespit edebilir ve EFS yapılandırmanızı (örneğin, performans modu veya çıkış tipi) optimize edebilirsiniz.

Sonuç: Geleceğe Yönelik Adımlar ve Entegrasyonun Önemi

Bu makale boyunca, Amazon EFS’yi Amazon EKS ile Terraform kullanarak entegre etmenin karmaşık olmayan ancak kritik sürecini derinlemesine inceledik. Modern konteynerize uygulamaların kalıcı depolama ihtiyaçlarını karşılamak, uygulamanın sağlamlığı ve veri tutarlılığı açısından hayati öneme sahiptir. EFS’nin sunduğu ölçeklenebilirlik, paylaşımlı erişim ve yönetilen dosya sistemi avantajları, EKS ortamındaki stateful uygulamalar için mükemmel bir temel oluşturmaktadır. Terraform ile bu entegrasyonu otomatikleştirmek ise altyapı yönetimini basitleştirir, tutarlılığı artırır ve DevOps ekipleri için paha biçilmez bir kolaylık sağlar.

EKS kümelerinizin, yüksek oranda erişilebilir ve dayanıklı bir dosya sistemine sahip olması, özellikle mikro hizmet tabanlı mimarilerde ortak veri havuzlarına ihtiyaç duyan uygulamalar için bir zorunluluktur. İster bir içerik yönetim sistemi, ister bir e-ticaret platformu veya karmaşık bir veri analiz iş yükü çalıştırın, EFS ve EKS kombinasyonu, verilerinizi güvenle ve performansla yönetmenize olanak tanır. Ayrıca, bu entegrasyonu Terraform gibi bir IaC aracıyla yönetmek, altyapı değişikliklerinin versiyonlanabilir olmasını, gözden geçirilebilir olmasını ve dağıtımların otomatikleştirilmesini sağlar. Bu da geliştirme süreçlerini hızlandırır ve operasyonel hataları minimize eder.

Gelecekte, bu entegrasyonu daha da geliştirmek için CI/CD (Sürekli Entegrasyon/Sürekli Dağıtım) boru hatlarına dahil etmek, otomatik testler eklemek ve gözlem araçlarıyla (monitoring tools) performansı sürekli izlemek gibi adımlar atabilirsiniz. AWS EFS ve EKS entegrasyonu, bulut tabanlı uygulamalarınızın kalbinde yer alan verileri yönetmek için güçlü, esnek ve güvenilir bir yol sunarak, dijital dönüşüm yolculuğunuzda önemli bir mihenk taşı olacaktır. Bu sayede, geliştiricileriniz kod yazmaya, uygulamalarınız da kesintisiz çalışmaya devam edecektir.