Multi-AZ EKS Mimarisi: Felaketlere Karşı Dayanıklılık

AWS'in en temel güvenilirlik prensibi, sistemlerin tek bir veri merkezine (Availability Zone - AZ) bağımlı olmamasıdır. Bir AZ'de yangın çıkabilir, sel olabilir veya elektrik kesilebilir. Amazon EKS mimarinizi Multi-AZ kurarak bu riskleri elimine edebilirsiniz.

EKS Control Plane Zaten Multi-AZ'dir

İyi haber: AWS, EKS Control Plane'ini (API Server) otomatik olarak en az 2 farklı AZ'ye dağıtır ve yönetir. Sizin yapmanız gereken, kendi Data Plane'inizi (Worker Nodes) dağıtmaktır.

Worker Node Dağıtımı

Node gruplarınızı oluştururken (Terraform veya eksctl ile), subnets parametresine en az 3 farklı AZ'deki subnetleri (örn: eu-central-1a, 1b, 1c) verin. EKS, Auto Scaling Group aracılığıyla node'ları bu AZ'lere eşit şekilde dağıtmaya çalışır.

Pod Dağıtımı (Topology Spread Constraints)

Node'larınız farklı AZ'lerde olsa bile, Kubernetes şans eseri uygulamanızın 5 podunu da aynı AZ'deki node'lara koyabilir. O AZ çökerse, uygulamanız kesintiye uğrar. Bunu engellemek için Topology Spread Constraints kullanın:

spec:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: DoNotSchedule
      labelSelector:
        matchLabels:
          app: my-app

Bu kural, Kubernetes'e "Podlarımı farklı Zone'lara eşit şekilde dağıt" emrini verir.

Depolama (EBS vs EFS)

Dikkat: Standart EBS (gp3) diskleri tek bir AZ'ye bağlıdır. AZ-a'daki bir diski, AZ-b'deki bir pod kullanamaz (Pod o AZ'de sıkışır kalır). Çözüm:

• Stateless uygulamalar tasarlayın (Diske ihtiyaç duymasın).
• Eğer disk şartsa, Multi-AZ destekleyen Amazon EFS kullanın.

AWS Danışmanlığı hizmetimizde, kritik sistemler için daima en az 3 AZ'li ve Topology Aware bir mimari kurguluyoruz.