Pelajari tentang Pergeseran Zonal Pengontrol Pemulihan Aplikasi Amazon (ARC) di Amazon EKS

Bantu tingkatkan halaman ini

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Bantu tingkatkan halaman ini

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Kubernetes memiliki fitur asli yang memungkinkan Anda membuat aplikasi Anda lebih tahan terhadap peristiwa seperti penurunan kesehatan atau gangguan Availability Zone (AZ). Saat menjalankan beban kerja di klaster Amazon EKS, Anda dapat lebih meningkatkan toleransi kesalahan lingkungan aplikasi dan pemulihan aplikasi menggunakan pergeseran zona Amazon Application Recovery Controller (ARC) atau pergeseran otomatis zona. Pergeseran zona ARC dirancang untuk menjadi tindakan sementara yang memungkinkan Anda memindahkan lalu lintas untuk sumber daya dari AZ yang rusak hingga pergeseran zona berakhir atau Anda membatalkannya. Anda dapat memperpanjang pergeseran zona jika perlu.

Anda dapat memulai pergeseran zona untuk cluster EKS, atau Anda dapat mengizinkan melakukannya AWS untuk Anda dengan mengaktifkan pergeseran otomatis zona. Pergeseran ini memperbarui alur lalu lintas east-to-west jaringan di klaster Anda untuk hanya mempertimbangkan titik akhir jaringan untuk Pod yang berjalan di node pekerja dalam keadaan sehat AZs. Selain itu, ALB atau NLB apa pun yang menangani lalu lintas masuk untuk aplikasi di kluster EKS Anda akan secara otomatis merutekan lalu lintas ke target yang sehat. AZs Bagi pelanggan yang mencari tujuan ketersediaan tertinggi, jika AZ menjadi terganggu, penting untuk dapat mengarahkan semua lalu lintas dari AZ yang rusak hingga pulih. Untuk ini, Anda juga dapat mengaktifkan ALB atau NLB dengan ARC zonal shift.

Memahami Arus Lalu Lintas Jaringan Timur-Barat Antar Pod

Diagram berikut menggambarkan dua contoh beban kerja, Pesanan, dan Produk. Tujuan dari contoh ini adalah untuk menunjukkan bagaimana beban kerja dan Pod dalam AZs komunikasi yang berbeda.

Memahami ARC Zonal Shift di Amazon EKS

Jika ada gangguan AZ di lingkungan Anda, Anda dapat memulai pergeseran zona untuk lingkungan cluster EKS Anda. Atau, Anda dapat mengizinkan AWS untuk mengelola ini untuk Anda dengan zonal autoshift. Dengan pergeseran otomatis zona, AWS akan memantau kesehatan AZ secara keseluruhan dan merespons potensi gangguan AZ dengan secara otomatis mengalihkan lalu lintas dari AZ yang terganggu di lingkungan klaster Anda.

Setelah klaster Amazon EKS Anda mengaktifkan pergeseran zona dengan ARC, Anda dapat memicu pergeseran zona atau mengaktifkan pergeseran otomatis zona menggunakan Konsol ARC, AWS CLI, atau pergeseran zona dan pergeseran otomatis zona. APIs Selama pergeseran zona EKS, berikut ini akan secara otomatis terjadi:

Diagram di bawah ini menggambarkan aliran tingkat tinggi tentang bagaimana pergeseran zona EKS memastikan bahwa hanya titik akhir Pod yang sehat yang ditargetkan di lingkungan klaster Anda.

Persyaratan Pergeseran Zonal EKS

Agar pergeseran zona berhasil bekerja di EKS, Anda perlu mengatur lingkungan cluster Anda agar tahan terhadap gangguan AZ sebelumnya. Di bawah ini adalah daftar langkah-langkah yang harus Anda ikuti.

Menyediakan Node Pekerja EKS Anda di Beberapa AZs

AWS Wilayah memiliki beberapa lokasi terpisah dengan pusat data fisik yang dikenal sebagai Availability Zones (AZs). AZs dirancang untuk secara fisik terisolasi satu sama lain untuk menghindari dampak simultan yang dapat mempengaruhi seluruh Wilayah. Saat menyediakan kluster EKS, Anda harus menerapkan node pekerja Anda AZs di beberapa wilayah. Ini akan membuat lingkungan cluster Anda lebih tahan terhadap kerusakan AZ tunggal, dan memungkinkan Anda untuk mempertahankan ketersediaan tinggi (HA) aplikasi Anda yang berjalan di yang lain. AZs Saat Anda memulai pergeseran zona menjauh dari AZ yang terkena dampak, jaringan in-cluster lingkungan EKS Anda akan diperbarui secara otomatis untuk hanya menggunakan yang sehat AZs, sambil mempertahankan postur yang sangat tersedia untuk cluster Anda.

Memastikan bahwa Anda memiliki pengaturan Multi-AZ untuk lingkungan EKS Anda akan meningkatkan keandalan keseluruhan sistem Anda. Namun, lingkungan multi-AZ dapat memainkan peran penting dalam cara data aplikasi ditransfer dan diproses, yang pada gilirannya akan berdampak pada biaya jaringan lingkungan Anda. Secara khusus, lalu lintas lintas zona keluar yang sering (lalu lintas didistribusikan antara AZs) dapat berdampak besar pada biaya terkait jaringan Anda. Anda dapat menerapkan berbagai strategi untuk mengontrol jumlah lalu lintas lintas zona antar Pod di klaster EKS Anda dan menurunkan biaya terkait. Silakan lihat panduan praktik terbaik ini untuk detail lebih lanjut tentang cara mengoptimalkan biaya jaringan saat menjalankan lingkungan EKS yang sangat tersedia.

Diagram di bawah ini menggambarkan lingkungan EKS yang sangat tersedia dengan 3 sehat AZs.

Diagram di bawah ini menggambarkan bagaimana lingkungan EKS dengan 3 AZs tahan terhadap gangguan AZ dan tetap sangat tersedia karena 2 lainnya sehat. AZs

Menyediakan Kapasitas Komputasi yang Cukup untuk Menahan Penghapusan AZ Tunggal

Untuk mengoptimalkan pemanfaatan sumber daya dan biaya untuk infrastruktur komputasi Anda di EKS Data Plane, ini adalah praktik terbaik untuk menyelaraskan kapasitas komputasi dengan persyaratan beban kerja Anda. Namun, jika semua node pekerja Anda berada pada kapasitas penuh, maka ini membuat Anda bergantung pada penambahan node pekerja baru ke Pesawat Data EKS sebelum Pod baru dapat dijadwalkan. Saat menjalankan beban kerja kritis, umumnya selalu merupakan praktik yang baik untuk dijalankan dengan kapasitas berlebihan secara online untuk menangani kemungkinan seperti peningkatan beban yang tiba-tiba, masalah kesehatan simpul, dll. Jika Anda berencana untuk menggunakan pergeseran zona, Anda berencana untuk menghapus seluruh kapasitas AZ sehingga Anda perlu menyesuaikan kapasitas komputasi redundan Anda sehingga cukup untuk menangani beban bahkan dengan AZ offline.

Saat menskalakan komputasi Anda, proses menambahkan node baru ke Pesawat Data EKS akan memakan waktu yang dapat berimplikasi pada kinerja real-time dan ketersediaan aplikasi Anda, terutama jika terjadi gangguan zona. Lingkungan EKS Anda harus tangguh untuk menyerap beban kehilangan AZ untuk menghindari pengalaman yang terdegradasi bagi pengguna akhir atau klien Anda. Ini berarti meminimalkan atau menghilangkan jeda antara waktu di mana Pod baru dibutuhkan dan kapan sebenarnya dijadwalkan pada node pekerja.

Selain itu, jika terjadi gangguan zona, Anda harus mengurangi risiko kendala kapasitas komputasi potensial yang akan mencegah node yang baru diperlukan ditambahkan ke Pesawat Data EKS Anda dalam kondisi sehat. AZs

Untuk mencapai hal ini, Anda harus menyediakan kapasitas komputasi yang berlebihan di beberapa node pekerja di masing-masing node AZs sehingga Kubernetes Scheduler memiliki kapasitas yang sudah ada sebelumnya yang tersedia untuk penempatan Pod baru, terutama ketika Anda memiliki satu AZ yang lebih sedikit di lingkungan Anda.

Jalankan & Sebarkan Beberapa Replika Pod Di Seluruh AZs

Kubernetes memungkinkan Anda untuk melakukan pra-skala beban kerja Anda dengan menjalankan beberapa instance (replika Pod) dari satu aplikasi. Menjalankan beberapa replika Pod untuk sebuah aplikasi menghilangkan satu titik kegagalan dan meningkatkan kinerjanya secara keseluruhan dengan mengurangi ketegangan sumber daya pada satu replika. Namun, untuk memiliki ketersediaan tinggi dan toleransi kesalahan yang lebih baik untuk aplikasi Anda, Anda harus menjalankan dan menyebarkan beberapa replika aplikasi di berbagai domain kegagalan (juga disebut sebagai domain topologi) dalam kasus ini. AZs Dengan kendala penyebaran topologi, Anda dapat mengatur aplikasi Anda agar memiliki stabilitas statis yang sudah ada sebelumnya sehingga, dalam kasus gangguan AZ, Anda akan memiliki cukup replika dalam kondisi sehat AZs untuk segera menangani lonjakan atau lonjakan lalu lintas tambahan yang mungkin mereka alami.

Diagram di bawah ini menggambarkan lingkungan EKS dengan arus east-to-west lalu lintas ketika AZs semuanya sehat.

Diagram di bawah ini menggambarkan lingkungan EKS dengan arus east-to-west lalu lintas ketika satu AZ gagal, dan Anda memulai pergeseran zona.

Cuplikan kode di bawah ini adalah contoh cara mengatur beban kerja Anda dengan fitur Kubernetes ini.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: orders
spec:
  replicas: 9
  selector:
    matchLabels:
      app:orders
  template:
    metadata:
      labels:
        app: orders
        tier: backend
    spec:
      topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: "topology.kubernetes.io/zone"
        whenUnsatisfiable: ScheduleAnyway
        labelSelector:
          matchLabels:
            app: orders

Yang paling penting, Anda harus menjalankan beberapa replika perangkat lunak server DNS Anda (CoreDNS/Kube-DNS) dan menerapkan batasan penyebaran topologi serupa jika belum dikonfigurasi secara default. Ini akan membantu memastikan bahwa Anda memiliki cukup Pod DNS dalam kondisi sehat AZs untuk terus menangani permintaan penemuan layanan untuk Pod komunikasi lainnya di klaster jika ada satu gangguan AZ. Add-on CoreDNS EKS memiliki pengaturan default untuk Pod CoreDNS untuk tersebar di Availability Zone klaster Anda jika ada node dalam beberapa yang tersedia. AZs Anda juga dapat mengganti pengaturan default ini dengan konfigurasi kustom Anda sendiri.

Saat menginstal CoreDNS dengan Helm, Anda dapat memperbarui replicaCount file in values.yaml untuk memastikan bahwa Anda memiliki jumlah replika yang cukup di setiap AZ. Selain itu, untuk memastikan bahwa replika ini tersebar AZs di berbagai lingkungan klaster Anda, Anda harus memperbarui topologySpreadConstraints properti dalam file values.yaml yang sama. Cuplikan kode di bawah ini menunjukkan cara mengkonfigurasi CoreDNS untuk ini.

CoreDNS Helm nilai.yaml

replicaCount: 6
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        k8s-app: kube-dns

Jika terjadi kerusakan AZ, Anda dapat menyerap peningkatan beban pada Pod CoreDNS dengan menggunakan sistem penskalaan otomatis untuk CoreDNS. Jumlah instans DNS yang Anda butuhkan akan bergantung pada jumlah beban kerja yang berjalan di klaster Anda. CoreDNS adalah CPU bound yang memungkinkannya untuk skala berdasarkan CPU menggunakan Horizontal Pod Autoscaler (HPA). Di bawah ini adalah contoh yang dapat Anda modifikasi sesuai dengan kebutuhan Anda.

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: coredns
  namespace: default
spec:
  maxReplicas: 20
  minReplicas: 2
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: coredns
  targetCPUUtilizationPercentage: 50

Atau, EKS dapat mengelola penskalaan otomatis Penerapan CoreDNS di CoreDNS versi add-on EKS. Autoscaler CoreDNS ini terus memantau status cluster, termasuk jumlah node dan core CPU. Berdasarkan informasi tersebut, pengontrol akan secara dinamis menyesuaikan jumlah replika penerapan CoreDNS di cluster EKS.

Untuk mengaktifkan konfigurasi penskalaan otomatis di add-on CoreDNS EKS, Anda harus menambahkan pengaturan konfigurasi opsional berikut:

{
  "autoScaling": {
    "enabled": true
  }
}

Anda juga dapat menggunakan NodeLocal DNS atau autoscaler proporsional cluster untuk menskalakan CoreDNS. Anda dapat membaca lebih lanjut tentang penskalaan CoreDNS secara horizontal di sini.

Colocate Pod Interdependen di AZ yang Sama

Dalam kebanyakan kasus, Anda mungkin menjalankan beban kerja yang berbeda yang harus berkomunikasi satu sama lain untuk keberhasilan pelaksanaan suatu end-to-end proses. Jika aplikasi yang berbeda tersebar di berbagai tempat AZs tetapi tidak ditempatkan di AZ yang sama, maka penurunan AZ tunggal dapat memengaruhi proses yang mendasarinya end-to-end. Misalnya, jika Aplikasi A memiliki beberapa replika di AZ 1 dan AZ 2, tetapi Aplikasi B memiliki semua replika di AZ 3, maka hilangnya AZ 3 akan memengaruhi end-to-end proses apa pun antara dua beban kerja ini (Aplikasi A dan B). Menggabungkan batasan penyebaran topologi dengan afinitas pod dapat meningkatkan ketahanan aplikasi Anda dengan menyebarkan Pod ke semua Pod AZs, serta mengonfigurasi hubungan antara Pod tertentu untuk memastikan bahwa mereka terkolokasi bersama.

Dengan aturan afinitas pod, Anda dapat menentukan hubungan antar beban kerja untuk memengaruhi perilaku Penjadwal Kubernetes sehingga Colocates Pod pada node pekerja yang sama atau di AZ yang sama. Anda juga dapat mengonfigurasi seberapa ketat batasan penjadwalan ini seharusnya.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: products
  namespace: ecommerce
  labels:
    app.kubernetes.io/version: "0.1.6"

    spec:
      serviceAccountName: graphql-service-account
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - orders
            topologyKey: "kubernetes.io/hostname"

Diagram di bawah ini menggambarkan pod yang telah ditempatkan bersama pada node yang sama menggunakan aturan afinitas pod.

Uji Bahwa Lingkungan Cluster Anda Dapat Menangani Hilangnya AZ

Setelah menyelesaikan persyaratan di atas, langkah penting berikutnya adalah menguji apakah Anda memiliki kapasitas komputasi dan beban kerja yang cukup untuk menangani hilangnya AZ. Anda dapat melakukan ini dengan secara manual memicu pergeseran zona di EKS. Atau, Anda dapat mengaktifkan zonal autoshift dan mengkonfigurasi praktik berjalan untuk menguji apakah aplikasi Anda berfungsi seperti yang diharapkan dengan satu AZ yang lebih sedikit di lingkungan cluster Anda.

Pertanyaan yang Sering Diajukan

Mengapa saya harus menggunakan fitur ini?

Dengan menggunakan ARC zonal shift atau zonal autoshift di kluster EKS Anda, Anda dapat lebih menjaga ketersediaan aplikasi Kubernetes dengan mengotomatiskan proses pemulihan cepat untuk mengalihkan lalu lintas jaringan in-cluster dari AZ yang rusak. Dengan ARC, Anda dapat menghindari langkah-langkah panjang dan rumit yang sering menyebabkan periode pemulihan yang diperpanjang selama peristiwa AZ yang terganggu.

Bagaimana cara kerja fitur ini dengan AWS layanan lain?

EKS terintegrasi dengan ARC yang menyediakan antarmuka utama bagi Anda untuk menyelesaikan operasi pemulihan di. AWS Untuk memastikan bahwa lalu lintas in-cluster diarahkan secara tepat dari AZ yang rusak, modifikasi dilakukan pada daftar titik akhir jaringan untuk Pod yang berjalan di bidang data Kubernetes. Jika Anda menggunakan AWS Load Balancer untuk merutekan lalu lintas eksternal ke cluster, Anda sudah dapat mendaftarkan penyeimbang beban Anda dengan ARC dan memicu pergeseran zona pada mereka untuk mencegah lalu lintas mengalir ke zona terdegradasi. Fitur ini juga berinteraksi dengan Amazon EC2 Auto Scaling Groups (ASG) yang dibuat oleh EKS Managed Node Groups (MNG). Untuk mencegah AZ yang rusak digunakan untuk peluncuran Pod atau node Kubernetes baru, EKS menghapus AZ yang rusak dari ASG.

Apa perbedaan fitur ini dengan perlindungan Kubernetes default?

Fitur ini bekerja bersama-sama dengan beberapa perlindungan bawaan asli Kubernetes yang membantu pelanggan tetap tangguh. Anda dapat mengonfigurasi probe kesiapan dan keaktifan Pod yang menentukan kapan Pod harus mengambil lalu lintas. Ketika probe ini gagal, Kubernetes menghapus Pod ini sebagai target untuk Service dan lalu lintas tidak lagi dikirim ke Pod. Meskipun ini berguna, tidak sepele bagi pelanggan untuk mengonfigurasi pemeriksaan kesehatan ini sehingga dijamin gagal ketika suatu zona terdegradasi. Fitur ARC zonal shift memberi Anda jaring pengaman tambahan yang membantu mereka mengisolasi AZ yang terdegradasi sepenuhnya ketika perlindungan asli Kubernetes belum cukup. Ini juga memberi Anda cara mudah untuk menguji kesiapan operasional dan ketahanan arsitektur Anda.

Dapat AWS memicu pergeseran zona atas nama saya?

Ya, jika Anda menginginkan cara yang sepenuhnya otomatis menggunakan pergeseran zona ARC, Anda dapat mengaktifkan pergeseran otomatis zona ARC. Dengan zonal autoshift, Anda dapat mengandalkan AWS untuk memantau kesehatan klaster EKS Anda, dan untuk secara otomatis memicu pergeseran ketika gangguan AZ terdeteksi. AZs

Apa yang terjadi jika saya menggunakan fitur ini dan node pekerja serta beban kerja saya tidak diskalakan sebelumnya?

Jika Anda tidak melakukan pra-skala dan mengandalkan penyediaan node atau Pod tambahan selama pergeseran zona, maka Anda berisiko mengalami pemulihan yang tertunda. Proses penambahan node baru ke bidang data Kubernetes akan memakan waktu yang dapat berimplikasi pada kinerja real-time dan ketersediaan aplikasi Anda, terutama jika terjadi kerusakan zona. Selain itu, jika terjadi gangguan zona, Anda mungkin menghadapi kendala kapasitas komputasi potensial yang akan mencegah node yang baru diperlukan ditambahkan ke yang sehat. AZs

Jika beban kerja Anda tidak diskalakan sebelumnya dan tersebar AZs di semua klaster Anda, gangguan zona dapat memengaruhi ketersediaan aplikasi yang hanya berjalan pada node pekerja di AZ yang terkena dampak. Untuk mengurangi risiko pemadaman ketersediaan lengkap untuk aplikasi Anda, EKS memiliki keamanan yang gagal untuk lalu lintas yang dikirim ke titik akhir Pod di zona yang terganggu jika beban kerja tersebut memiliki semua titik akhir di AZ yang tidak sehat. Namun, sangat disarankan agar Anda melakukan pra-skala dan menyebarkan aplikasi Anda AZs ke semua untuk menjaga ketersediaan jika terjadi masalah zona.

Apa yang terjadi jika saya menjalankan aplikasi stateful?

Jika Anda menjalankan aplikasi stateful, Anda perlu menilai toleransi kesalahannya tergantung pada kasus penggunaan dan arsitekturnya. Jika Anda memiliki arsitektur atau pola aktif/siaga, mungkin ada contoh di mana aktif berada di AZ yang rusak. Pada tingkat aplikasi, jika siaga tidak diaktifkan, Anda mungkin mengalami masalah dengan aplikasi Anda. Anda juga mungkin mengalami masalah ketika Pod Kubernetes baru diluncurkan dalam keadaan sehat AZs karena mereka tidak akan dapat melampirkan ke volume persisten yang dibatasi ke AZ yang rusak.

Apakah fitur ini berfungsi dengan Karpenter?

Dukungan Karpenter saat ini tidak tersedia dengan ARC zonal shift dan zonal autoshift di EKS. Jika AZ terganggu, Anda dapat menyesuaikan NodePool konfigurasi Karpenter yang relevan dengan menghapus AZ yang tidak sehat sehingga node pekerja baru hanya diluncurkan dalam kondisi sehat. AZs

Apakah fitur ini berfungsi dengan EKS Fargate?

Fitur ini tidak berfungsi dengan EKS Fargate. Secara default, ketika EKS Fargate mengenali peristiwa kesehatan zona, Pod akan lebih memilih untuk berjalan di acara lainnya. AZs

Apakah pesawat kontrol Kubernetes yang dikelola EKS akan terkena dampak?

Tidak, secara default Amazon EKS menjalankan dan menskalakan bidang kontrol Kubernetes di beberapa bidang AZs untuk memastikan ketersediaan yang tinggi. ARC zonal shift dan zonal autoshift hanya akan bekerja pada bidang data Kubernetes.

Apakah ada biaya yang terkait dengan fitur baru ini?

Anda dapat menggunakan ARC zonal shift dan zonal autoshift di kluster EKS Anda tanpa biaya tambahan. Namun, Anda akan terus membayar instans yang disediakan dan sangat disarankan agar Anda melakukan pra-skala pesawat data Kubernetes sebelum menggunakan fitur ini. Anda harus mempertimbangkan keseimbangan yang tepat antara biaya dan ketersediaan aplikasi.

Sumber Daya Tambahan