Bantu meningkatkan 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 GitHub tautan Edit halaman ini di 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.

Pelajari tentang pergeseran zona Amazon Application Recovery Controller (ARC) di Amazon EKS

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

Anda dapat memulai pergeseran zona untuk cluster EKS, atau Anda dapat mengizinkan AWS untuk menggeser lalu lintas untuk Anda dengan mengaktifkan zonal autoshift. Pergeseran ini memperbarui aliran lalu lintas jaringan dari timur ke barat di cluster Anda untuk hanya mempertimbangkan titik akhir jaringan untuk Pod yang berjalan pada node pekerja di AZ yang sehat. Selain itu, setiap ALB atau NLB yang menangani lalu lintas masuk untuk aplikasi di cluster EKS Anda akan secara otomatis mengarahkan lalu lintas ke target di AZ yang sehat. Bagi pelanggan yang mencari tujuan ketersediaan tertinggi, jika AZ menjadi terganggu, penting untuk dapat mengarahkan semua lalu lintas dari AZ yang rusak sampai pulih. Untuk ini, Anda juga dapat mengaktifkan ALB atau NLB dengan pergeseran zonal ARC.

Memahami aliran lalu lintas jaringan timur-barat antara Pod

Diagram berikut menggambarkan dua contoh beban kerja, Pesanan, dan Produk. Tujuan dari contoh ini adalah untuk menunjukkan bagaimana beban kerja dan Pod di AZ yang berbeda berkomunikasi.

Memahami pergeseran zona ARC di Amazon EKS

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

Setelah cluster Amazon EKS mengaktifkan pergeseran zonal dengan ARC, Anda dapat memulai pergeseran zonal atau mengaktifkan zonal autoshift dengan menggunakan Konsol ARC, AWS CLI, atau pergeseran zonal dan API autoshift zonal. Selama pergeseran zona EKS, berikut ini dilakukan secara otomatis:

Diagram berikut memberikan gambaran umum tingkat tinggi tentang bagaimana pergeseran zona EKS memastikan bahwa hanya titik akhir Pod yang sehat yang ditargetkan di lingkungan cluster Anda.

Persyaratan pergeseran zona EKS

Agar shift zona berhasil bekerja dengan EKS, Anda harus mengatur lingkungan cluster Anda sebelumnya agar tahan terhadap penurunan nilai AZ. Berikut ini adalah daftar opsi konfigurasi yang membantu memastikan ketahanan.

Menyediakan node pekerja EKS Anda di beberapa Zona Ketersediaan

AWS Wilayah memiliki beberapa lokasi terpisah dengan pusat data fisik, yang dikenal sebagai Availability Zones (AZ). AZ dirancang untuk diisolasi secara fisik satu sama lain untuk menghindari dampak simultan yang dapat mempengaruhi seluruh Wilayah. Saat Anda menyediakan cluster EKS, sebaiknya gunakan node pekerja di beberapa AZ di Wilayah. Ini membantu membuat lingkungan cluster Anda lebih tahan terhadap kerusakan AZ tunggal, dan memungkinkan Anda mempertahankan ketersediaan tinggi untuk aplikasi Anda yang berjalan di AZ lainnya. Saat Anda memulai pergeseran zona menjauh dari AZ yang terkena dampak, jaringan in-cluster lingkungan EKS Anda secara otomatis diperbarui untuk hanya menggunakan AZ yang sehat, untuk membantu menjaga ketersediaan tinggi untuk cluster Anda.

Memastikan bahwa Anda memiliki pengaturan Multi-AZ untuk lingkungan EKS Anda meningkatkan keandalan keseluruhan sistem Anda. Namun, lingkungan multi-AZ memengaruhi cara data aplikasi ditransfer dan diproses, yang pada gilirannya berdampak pada biaya jaringan lingkungan Anda. Secara khusus, lalu lintas lintas zona keluar yang sering (lalu lintas yang didistribusikan antar AZ) dapat berdampak besar pada biaya terkait jaringan Anda. Anda dapat menerapkan strategi yang berbeda untuk mengontrol jumlah lalu lintas lintas zona antara Pod di cluster EKS Anda dan menurunkan biaya terkait. Untuk informasi selengkapnya tentang cara mengoptimalkan biaya jaringan saat menjalankan lingkungan EKS yang sangat tersedia, lihat praktik terbaik ini .

Diagram berikut menggambarkan lingkungan EKS yang sangat tersedia dengan tiga AZ yang sehat.

Diagram berikut menggambarkan bagaimana lingkungan EKS dengan tiga AZ tahan terhadap penurunan AZ dan tetap sangat tersedia karena ada dua AZ sehat yang tersisa.

Menyediakan kapasitas komputasi yang cukup untuk menahan penghapusan Zona Ketersediaan tunggal

Untuk mengoptimalkan pemanfaatan sumber daya dan biaya untuk infrastruktur komputasi Anda di bidang data EKS, ini adalah praktik terbaik untuk menyelaraskan kapasitas komputasi dengan persyaratan beban kerja Anda. Namun, jika semua node pekerja Anda memiliki kapasitas penuh, Anda bergantung pada penambahan node pekerja baru ke bidang data EKS sebelum Pod baru dapat dijadwalkan. Ketika Anda menjalankan beban kerja kritis, umumnya merupakan praktik yang baik untuk menjalankan dengan kapasitas redundan secara online untuk menangani skenario seperti peningkatan tiba-tiba dalam beban dan masalah kesehatan node. Jika Anda berencana untuk menggunakan pergeseran zonal, Anda berencana untuk menghapus seluruh kapasitas AZ ketika ada penurunan. Ini berarti bahwa Anda harus menyesuaikan kapasitas komputasi redundan Anda sehingga cukup untuk menangani beban bahkan dengan salah satu AZ offline.

Saat Anda menskalakan sumber daya komputasi Anda, proses menambahkan node baru ke bidang data EKS membutuhkan waktu. Hal ini dapat berimplikasi pada kinerja real-time dan ketersediaan aplikasi Anda, terutama jika terjadi gangguan zona. Lingkungan EKS Anda harus dapat menyerap beban kehilangan satu AZ tanpa menghasilkan pengalaman yang menurun bagi pengguna akhir atau klien Anda. Ini berarti meminimalkan atau menghilangkan jeda antara waktu ketika Pod baru diperlukan dan saat itu benar-benar dijadwalkan pada node pekerja.

Selain itu, ketika ada penurunan zona, Anda harus bertujuan untuk mengurangi risiko mengalami kendala kapasitas komputasi yang akan mencegah node yang baru diperlukan ditambahkan ke bidang data EKS Anda di AZ yang sehat.

Untuk mengurangi risiko dampak negatif potensial ini, sebaiknya Anda menyediakan kapasitas komputasi secara berlebihan di beberapa node pekerja di masing-masing AZ. Dengan melakukan ini, Penjadwal Kubernetes memiliki kapasitas yang sudah ada sebelumnya yang tersedia untuk penempatan Pod baru, yang sangat penting ketika Anda kehilangan salah satu AZ di lingkungan Anda.

Menjalankan dan menyebarkan beberapa replika Pod di seluruh Availability Zone

Kubernetes memungkinkan Anda melakukan pra-skala beban kerja dengan menjalankan beberapa instance (replika Pod) dari satu aplikasi. Menjalankan beberapa replika Pod untuk aplikasi menghilangkan satu titik kegagalan dan meningkatkan kinerja secara keseluruhan dengan mengurangi ketegangan sumber daya pada satu replika. Namun, untuk memiliki ketersediaan tinggi dan toleransi kesalahan yang lebih baik untuk aplikasi Anda, sebaiknya jalankan beberapa replika aplikasi Anda dan menyebarkan replika di domain kegagalan yang berbeda, juga disebut sebagai domain topologi. Domain kegagalan dalam skenario ini adalah Zona Ketersediaan. Dengan menggunakan batasan penyebaran topologi, Anda dapat mengatur aplikasi Anda agar memiliki stabilitas statis yang sudah ada sebelumnya. Kemudian, ketika ada gangguan AZ, lingkungan Anda akan memiliki cukup replika di AZ yang sehat untuk segera menangani lonjakan atau lonjakan lalu lintas.

Diagram berikut menggambarkan lingkungan EKS yang memiliki arus lalu lintas timur-barat ketika semua AZ sehat.

Diagram berikut menggambarkan lingkungan EKS yang memiliki aliran lalu lintas timur-barat di mana AZ tunggal telah gagal dan Anda telah memulai pergeseran zona.

Cuplikan kode berikut adalah contoh cara mengatur beban kerja Anda dengan beberapa replika di Kubernetes.

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 terpenting, Anda harus menjalankan beberapa replika perangkat lunak server DNS Anda (CoreDNS/kube-dns) dan menerapkan batasan penyebaran topologi yang serupa, jika tidak dikonfigurasi secara default. Ini membantu memastikan bahwa, jika ada penurunan AZ tunggal, Anda memiliki cukup Pod DNS di AZ yang sehat untuk terus menangani permintaan penemuan layanan untuk Pod berkomunikasi lainnya di cluster. Add- Mengelola CoreDNS untuk DNS di klaster Amazon EKS on CoreDNS EKS memiliki pengaturan default untuk Pod CoreDNS yang memastikan bahwa, jika ada node di beberapa AZ yang tersedia, mereka tersebar di Zona Ketersediaan cluster Anda. Jika Anda suka, Anda dapat mengganti pengaturan default ini dengan konfigurasi khusus Anda sendiri.

Saat Anda menginstal CoreDNS dengan Helm, Anda dapat memperbarui file values.yaml untuk memastikan bahwa Anda memiliki replika yang cukup replicaCount di setiap AZ. Selain itu, untuk memastikan bahwa replika ini tersebar di AZ yang berbeda di lingkungan cluster Anda, pastikan Anda memperbarui topologySpreadConstraints properti dalam file yang samavalues.yaml. Cuplikan kode berikut menggambarkan bagaimana Anda dapat mengkonfigurasi CoreDNS untuk melakukan ini.

Nilai CoreDNS Helm.yaml

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

Jika ada penurunan AZ, Anda dapat menyerap peningkatan beban pada Pod CoreDNS dengan menggunakan sistem penskalaan otomatis untuk CoreDNS. Jumlah instance DNS yang Anda perlukan tergantung pada jumlah beban kerja yang berjalan di cluster Anda. CoreDNS terikat CPU, yang memungkinkannya untuk skala berdasarkan CPU dengan menggunakan Horizon tal Pod Autoscaler (HPA). Berikut 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 inti CPU. Berdasarkan informasi itu, pengontrol secara dinamis menyesuaikan jumlah replika penyebaran CoreDNS di cluster EKS.

Untuk mengaktifkan konfigurasi penskalaan otomatis di add-on CoreDNS EKS, gunakan pengaturan konfigurasi berikut:

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

Anda juga dapat menggunakan NodeLocal DNS atau autoscaler proporsional cluster untuk menskalakan CoreDNS. Untuk informasi selengkapnya, lihat Men skalakan CoreDNS secara horizontal.

Kumpulkan Pod yang saling bergantung di Zona Ketersediaan yang sama

Biasanya, aplikasi memiliki beban kerja berbeda yang perlu berkomunikasi satu sama lain untuk berhasil menyelesaikan proses end-to-end. Jika aplikasi yang berbeda ini tersebar di AZ yang berbeda dan tidak ditempatkan di AZ yang sama, maka penurunan AZ tunggal dapat memengaruhi proses ujung ke ujung. 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 mempengaruhi proses end-to-end antara dua beban kerja, Aplikasi A dan Aplikasi B. Jika menggabungkan batasan penyebaran topologi dengan afinitas pod, Anda dapat meningkatkan ketahanan aplikasi dengan menyebarkan Pod di semua AZ. Selain itu, ini mengonfigurasi hubungan antara Pod tertentu untuk memastikan bahwa mereka ditempatkan.

Dengan aturan afinitas pod, Anda dapat menentukan hubungan antara beban kerja untuk mempengaruhi perilaku Penjadwal Kubernetes sehingga menampung Pod pada node pekerja yang sama atau di AZ yang sama. Anda juga dapat mengonfigurasi seberapa ketat batasan penjadwalan 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 berikut menunjukkan beberapa pod yang telah ditempatkan pada node yang sama dengan menggunakan aturan afinitas pod.

Uji bahwa lingkungan cluster Anda dapat menangani hilangnya AZ

Setelah Anda menyelesaikan persyaratan yang dijelaskan di bagian sebelumnya, langkah selanjutnya adalah menguji apakah Anda memiliki kapasitas komputasi dan beban kerja yang cukup untuk menangani hilangnya AZ. Anda dapat melakukan ini dengan memulai pergeseran zonal secara manual di EKS. Atau, Anda dapat mengaktifkan zonal autoshift dan mengonfigurasi proses latihan, yang juga menguji apakah aplikasi Anda berfungsi seperti yang diharapkan dengan satu AZ lebih sedikit di lingkungan cluster Anda.

Pertanyaan umum

Mengapa saya harus menggunakan fitur ini?

Dengan menggunakan ARC zonal shift atau zonal autoshift di cluster EKS Anda, Anda dapat mempertahankan ketersediaan aplikasi Kubernetes dengan lebih baik 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 dapat 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 AWS. Untuk memastikan bahwa lalu lintas dalam cluster dialihkan dengan tepat dari AZ yang rusak, EKS membuat modifikasi pada daftar titik akhir jaringan untuk Pod yang berjalan di bidang data Kubernetes. Jika Anda menggunakan Elastic Load Balancing untuk merutekan lalu lintas eksternal ke cluster, Anda dapat mendaftarkan penyeimbang beban Anda dengan ARC dan memulai pergeseran zonal pada mereka untuk mencegah lalu lintas mengalir ke AZ yang terdegradasi. Jika Anda menggunakan Mode Otomatis EKS, Mode Otomatis EKS secara otomatis membatasi penyediaan node ke AZ yang sehat. Pergeseran zona juga berfungsi dengan grup Amazon EC2 Auto Scaling yang dibuat oleh grup node yang dikelola EKS. Untuk mencegah AZ yang rusak digunakan untuk Pod Kubernetes baru atau peluncuran node, EKS menghapus AZ yang rusak dari grup Penskalaan Otomatis.

Bagaimana fitur ini berbeda dari perlindungan Kubernetes default?

Fitur ini bekerja bersamaan dengan beberapa perlindungan bawaan Kubernetes yang membantu ketahanan aplikasi pelanggan. Anda dapat mengonfigurasi probe kesiapan dan keaktifan Pod yang menentukan kapan Pod harus menerima lalu lintas. Ketika probe ini gagal, Kubernetes menghapus Pod ini sebagai target untuk layanan, dan lalu lintas tidak lagi dikirim ke Pod. Meskipun ini berguna, tidak mudah bagi pelanggan untuk mengkonfigurasi pemeriksaan kesehatan ini sehingga mereka dijamin gagal ketika AZ terdegradasi. Fitur pergeseran zona ARC menyediakan jaring pengaman tambahan yang membantu Anda mengisolasi AZ yang terdegradasi sepenuhnya ketika perlindungan asli Kubernetes tidak cukup. Pergeseran zona juga memberi Anda cara mudah untuk menguji kesiapan operasional dan ketahanan arsitektur Anda.

Bisakah AWS memulai pergeseran zonal atas nama saya?

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

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 bergantung pada penyediaan node atau Pod tambahan selama pergeseran zona, Anda berisiko mengalami pemulihan yang tertunda. Proses penambahan node baru ke bidang data Kubernetes membutuhkan waktu, yang dapat memengaruhi kinerja real-time dan ketersediaan aplikasi Anda, terutama ketika ada gangguan zona. Selain itu, jika terjadi penurunan zona, Anda mungkin menemukan batasan kapasitas komputasi potensial yang dapat mencegah node yang baru diperlukan ditambahkan ke AZ yang sehat.

Jika Anda menggunakan Mode Otomatis EKS, Mode Otomatis EKS secara otomatis menyediakan node baru di AZ yang sehat untuk memenuhi permintaan Pod yang tidak dapat dijadwalkan. Namun, node baru masih membutuhkan waktu untuk diluncurkan dan menjadi siap. Untuk pemulihan tercepat, sebaiknya lakukan pra-skala beban kerja di beberapa AZ.

Jika beban kerja Anda tidak diskalakan sebelumnya dan tersebar di semua AZ di cluster 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 safe kegagalan untuk lalu lintas yang akan dikirim ke titik akhir Pod di zona terganggu jika beban kerja tersebut memiliki semua titik akhir di AZ yang tidak sehat. Namun, kami sangat menyarankan Anda melakukan pra-skala dan menyebarkan aplikasi Anda di semua AZ untuk menjaga ketersediaan jika terjadi masalah zona.

Bagaimana cara kerjanya jika saya menjalankan aplikasi stateful?

Jika Anda menjalankan aplikasi stateful, Anda harus menilai toleransi kesalahannya, berdasarkan kasus penggunaan dan arsitektur Anda. Jika Anda memiliki active/standby arsitektur atau pola, mungkin ada contoh di mana yang aktif berada di AZ yang rusak. Pada tingkat aplikasi, jika standby tidak diaktifkan, Anda mungkin mengalami masalah dengan aplikasi Anda. Anda mungkin juga mengalami masalah saat Pod Kubernetes baru diluncurkan di AZ yang sehat, karena Pods tersebut tidak akan dapat dilampirkan ke volume persisten yang dibatasi pada AZ yang rusak.

Apakah fitur ini bekerja dengan Mode Otomatis EKS?

Ya. Saat Anda mengaktifkan pergeseran zonal pada cluster Mode Otomatis EKS, Mode Otomatis EKS secara otomatis merespons peristiwa pergeseran zonal. Selama pergeseran zona, Mode Otomatis EKS berhenti menyediakan node baru di AZ yang rusak, menangguhkan tindakan gangguan sukarela (seperti konsolidasi dan penyimpangan) yang akan mempengaruhi AZ yang terganggu, dan menghindari kapasitas peluncuran untuk Pod dengan persyaratan penjadwalan ketat yang menargetkan AZ yang rusak. Anda tidak memerlukan konfigurasi tambahan selain mengaktifkan pergeseran zonal pada cluster.

Apakah fitur ini berfungsi dengan Karpenter yang dikelola sendiri?

Self-managed Dukungan Karpenter tersedia dengan ARC zonal shift dan zonal autoshift di EKS dengan Karpenter versi 1.12 atau lebih tinggi.

Apakah fitur ini bekerja dengan EKS Fargate?

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

Akankah pesawat kontrol Kubernetes yang dikelola EKS terkena dampak?

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

Apakah ada biaya yang terkait dengan fitur baru ini?

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

Sumber daya tambahan