View a markdown version of this page

Pesawat Data EKS - Amazon EKS
Rekomendasi

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

Pesawat Data EKS

Untuk mengoperasikan aplikasi dengan ketersediaan tinggi dan tangguh, Anda memerlukan bidang data yang sangat tersedia dan tangguh. Bidang data elastis memastikan bahwa Kubernetes dapat menskalakan dan menyembuhkan aplikasi Anda secara otomatis. Bidang data tangguh terdiri dari dua atau lebih node pekerja, dapat tumbuh dan menyusut dengan beban kerja, dan secara otomatis pulih dari kegagalan.

Anda memiliki beberapa pilihan untuk node pekerja dengan EKS: node yang dikelola Mode Otomatis EKS, Instans EC2, dan Fargate.

Mode Otomatis EKS menawarkan jalur termudah ke bidang data yang tangguh. Mode Otomatis memperluas pengelolaan AWS cluster Kubernetes di luar cluster itu sendiri, untuk memungkinkan AWS juga menyiapkan dan mengelola infrastruktur yang memungkinkan kelancaran pengoperasian beban kerja Anda. Mode Otomatis secara otomatis menskalakan bidang data ke atas atau ke bawah saat Kubernetes menskalakan Pod dan bekerja untuk terus memastikan bahwa Node di cluster Anda berukuran tepat dan hemat biaya untuk beban kerja yang sedang berjalan saat ini.

Jika Anda memilih instans EC2, Anda dapat mengelola sendiri node pekerja atau menggunakan grup node yang dikelola EKS. Anda dapat memiliki cluster dengan campuran Mode Otomatis, node pekerja terkelola, dikelola sendiri, dan Fargate.

Fargate menjalankan setiap Pod di lingkungan komputasi terisolasi. Setiap Pod yang berjalan di Fargate mendapatkan node pekerjanya sendiri. Fargate secara otomatis menskalakan bidang data saat Kubernetes menskalakan pod. Anda dapat menskalakan bidang data dan beban kerja Anda dengan menggunakan autosc https://docs.aws.amazon.com/eks/latest/userguide/horizontal-pod-autoscaler.html aler pod horizontal.

Cara yang lebih disukai untuk menskalakan node pekerja EC2 (jika tidak menggunakan Mode Otomatis EKS di mana ini dilakukan secara otomatis oleh AWS) adalah dengan menggunakan grup Karpenter, Kubernetes Cluster Autosc aler, atau EC2 Auto Scaling. https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html

Rekomendasi

Sebarkan node pekerja dan beban kerja di beberapa AZ

Anda dapat melindungi beban kerja Anda dari kegagalan di AZ individual dengan menjalankan node pekerja dan Pod di beberapa AZ. Anda dapat mengontrol AZ tempat node pekerja dibuat menggunakan subnet tempat Anda membuat node.

Metode yang disarankan untuk menyebarkan pod di seluruh AZ adalah dengan menggunakan Topology Spread Constraints for Pod. Auto-scaling kemampuan seperti EKS Auto Mode dan Karpenter menyadari kendala penyebaran topologi dan akan secara otomatis meluncurkan Node di AZ yang benar untuk memungkinkan batasan Anda terpenuhi.

Penerapan di bawah ini menyebarkan pod di seluruh AZ jika memungkinkan, membiarkan pod tersebut tetap berjalan jika tidak:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          whenUnsatisfiable: ScheduleAnyway
          topologyKey: topology.kubernetes.io/zone
          labelSelector:
            matchLabels:
              app: web-server
      containers:
      - name: web-app
        image: nginx
        resources:
          requests:
            cpu: 1
catatan

kube-schedulerhanya mengetahui domain topologi melalui node yang ada dengan label tersebut. Jika penerapan di atas diterapkan ke cluster dengan node hanya di satu zona, semua pod akan menjadwalkan pada node kube-scheduler tersebut karena tidak mengetahui zona lain. Agar penyebaran topologi ini berfungsi seperti yang diharapkan dengan penjadwal, node harus sudah ada di semua zona. Pro minDomains perti batasan penyebaran topologi digunakan untuk menginformasikan penjadwal tentang jumlah domain yang memenuhi syarat, bahkan jika ada Node yang berjalan di sana untuk menghindari masalah ini.

Awas

Menyet whenUnsatisfiable el ke DoNotSchedule akan menyebabkan pod tidak dapat dijadwalkan jika batasan penyebaran topologi tidak dapat dipenuhi. Ini hanya boleh disetel jika lebih disukai agar pod tidak berjalan alih-alih melanggar batasan penyebaran topologi.

Pada versi Kubernetes yang lebih lama, Anda dapat menggunakan aturan anti-afinitas pod untuk menjadwalkan pod di beberapa AZ. Manifes di bawah ini menginformasikan penjadwal Kubernetes untuk memilih pod pen jadwalan di AZ yang berbeda.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server
  labels:
    app: web-server
spec:
  replicas: 4
  selector:
    matchLabels:
      app: web-server
  template:
    metadata:
      labels:
        app: web-server
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - web-server
              topologyKey: failure-domain.beta.kubernetes.io/zone
            weight: 100
      containers:
      - name: web-app
        image: nginx
Awas

Jangan mengharuskan pod dijadwalkan di AZ yang berbeda jika tidak, jumlah pod dalam penerapan tidak akan pernah melebihi jumlah AZ.

Pastikan kemampuan untuk meluncurkan Node di setiap AZ saat menggunakan volume EBS

Jika Anda menggunakan Amazon EBS untuk menyediakan Volume Persistent, maka Anda perlu memastikan bahwa pod dan volume EBS terkait berada di AZ yang sama. Pod tidak dapat mengakses volume EBS-backed persisten yang terletak di AZ yang berbeda. Pen jadwal Kubernetes mengetahui di AZ mana node pekerja berada dari label yang ada di Node dan akan selalu menjadwalkan Pod yang memerlukan volume EBS di AZ yang sama dengan volume. Namun, jika tidak ada node pekerja yang tersedia di AZ tempat volume berada, maka Pod tidak dapat dijadwalkan.

Jika menggunakan EKS Auto Mode atau Karpenter Anda perlu memastikan bahwa subnet pilihan Anda NodeClass di setiap AZ. Jika menggunakan Grup Node Terkelola, Anda perlu memastikan bahwa Anda memiliki Grup Node di setiap AZ.

Kemampuan penyimpanan EBS dibangun ke dalam Mode Otomatis EKS, tetapi jika menggunakan Karpenter atau Grup Node Terkelola, EBS CSI juga perlu diinstal.

Gunakan Mode Otomatis EKS untuk mengelola node pekerja

Mode Otomatis EKS menyederhanakan manajemen EKS dengan menyediakan cluster siap produksi dengan biaya operasional minimal. Mode Otomatis bertanggung jawab untuk meningkatkan atau menurunkan jumlah Node tergantung pada Pod yang berjalan di cluster. Node selalu diperbarui dengan patch dan perbaikan perangkat lunak secara otomatis, dengan pembaruan dilakukan sesuai dengan pengaturan NodePool gangguan yang dikonfigurasi dan Anggaran Gangguan Pod.

Jalankan Agen Pemantauan Node

Agen Pemantauan Node memantau dan bereaksi terhadap masalah kesehatan Node dengan menerbitkan peristiwa Kubernetes dan memperbarui kondisi status pada Node. Agen Pemantauan Node disertakan dengan EKS Auto Mode Nodes, dan dapat diinstal sebagai Addon EKS untuk Node yang tidak dikelola oleh Mode Otomatis.

EKS Auto Mode, Managed Node Groups, dan Karpenter semuanya memiliki kemampuan untuk mendeteksi kondisi Node fatal yang dilaporkan oleh Agen Pemantauan Node dan memperbaiki Node tersebut secara otomatis ketika kondisi tersebut terjadi.

Menerapkan QoS

Untuk aplikasi penting, pertimbangkan limits untuk mendefinisikan requests = untuk wadah di Pod. Ini akan memastikan bahwa kontainer tidak akan mati jika Pod lain meminta sumber daya.

Ini adalah praktik terbaik untuk menerapkan batas CPU dan memori untuk semua wadah karena mencegah wadah secara tidak sengaja menghabiskan sumber daya sistem yang berdampak pada ketersediaan proses yang ditempatkan bersama lainnya.

Konfigurasi dan Ukuran Sumber Daya Requests/Limits untuk semua Beban Kerja

Beberapa panduan umum dapat diterapkan untuk mengukur permintaan sumber daya dan batas untuk beban kerja:

  • Jangan tentukan batas sumber daya pada CPU. Dengan tidak adanya batasan, permintaan bertindak sebagai bobot pada berapa banyak wadah waktu CPU relatif didapat. Ini memungkinkan beban kerja Anda menggunakan CPU penuh tanpa batas buatan atau kelaparan.

  • Untuk sumber daya non-CPU, mengkonfigurasi requests = limits memberikan perilaku yang paling dapat diprediksi. Jikarequests! =limits, wadah juga memiliki QOS yang di kurangi dari Dijamin menjadi Burstable sehingga lebih mungkin untuk diusir jika terjadi tekanan simpul. https://kubernetes.io/docs/concepts/scheduling-eviction/node-pressure-eviction/

  • Untuk sumber daya non-CPU, jangan tentukan batas yang jauh lebih besar dari permintaan. Semakin limits besar konfigurasi relatif terhadaprequests, semakin besar kemungkinan node akan terlalu berkomitmen yang menyebabkan kemungkinan gangguan beban kerja yang tinggi.

  • Permintaan berukuran benar sangat penting saat menggunakan solusi penskalaan otomatis node seperti Karpenter atau Cluster. AutoScaler Alat ini melihat permintaan beban kerja Anda untuk menentukan jumlah dan ukuran node yang akan disediakan. Jika permintaan Anda terlalu kecil dengan batas yang lebih besar, Anda mungkin menemukan beban kerja Anda diusir atau OOM mati jika mereka telah dikemas rapat pada node.

Menentukan permintaan sumber daya bisa sulit, tetapi alat seperti Vertical Pod Autoscaler dapat membantu Anda “mengukur dengan tepat” permintaan dengan mengamati penggunaan sumber daya kontainer saat runtime. Alat lain yang mungkin berguna untuk menentukan ukuran permintaan meliputi:

Konfigurasikan kuota sumber daya untuk ruang nama

Ruang nama dimaksudkan untuk digunakan di lingkungan dengan banyak pengguna yang tersebar di beberapa tim, atau proyek. Mereka menyediakan ruang lingkup untuk nama dan merupakan cara untuk membagi sumber daya cluster antara beberapa tim, proyek, beban kerja. Anda dapat membatasi konsumsi sumber daya agregat dalam namespace. Ob ResourceQuota jek dapat membatasi jumlah objek yang dapat dibuat dalam namespace berdasarkan jenis, serta jumlah total sumber daya komputasi yang dapat dikonsumsi oleh sumber daya dalam proyek itu. Anda dapat membatasi jumlah total sumber daya and/or komputasi penyimpanan (CPU dan memori) yang dapat diminta dalam namespace tertentu.

Jika kuota sumber daya diaktifkan untuk namespace untuk sumber daya komputasi seperti CPU dan memori, pengguna harus menentukan permintaan atau batasan untuk setiap wadah di namespace tersebut.

Pertimbangkan untuk mengonfigurasi kuota untuk setiap namespace. Pertimbangkan LimitRanges untuk menggunakan untuk secara otomatis menerapkan batas yang telah dikonfigurasi sebelumnya ke wadah dalam ruang nama.

Batasi penggunaan sumber daya kontainer dalam namespace

Kuota Sumber Daya membantu membatasi jumlah sumber daya yang dapat digunakan namespace. Ob LimitRange jek dapat membantu Anda mengimplementasikan sumber daya minimum dan maksimum yang dapat diminta oleh wadah. Menggunakan LimitRange Anda dapat menetapkan permintaan dan batas default untuk kontainer, yang sangat membantu jika menetapkan batas sumber daya komputasi bukanlah praktik standar di organisasi Anda. Seperti namanya, LimitRange dapat menerapkan penggunaan sumber daya komputasi minimum dan maksimum per Pod atau Container dalam namespace. Serta, terapkan permintaan penyimpanan minimum dan maksimum per PersistentVolumeClaim dalam namespace.

Pertimbangkan untuk menggunakan LimitRange bersama dengan ResourceQuota untuk menegakkan batasan pada wadah serta tingkat namespace. Menetapkan batasan ini akan memastikan bahwa wadah atau namespace tidak mengganggu sumber daya yang digunakan oleh penyewa lain di cluster.

Gunakan NodeLocal DNSCache

Anda dapat meningkatkan kinerja DNS Cluster dengan menjalankan NodeLocal DNSCache. Fitur ini menjalankan agen caching DNS pada node cluster sebagaiDaemonSet. Semua pod menggunakan agen caching DNS yang berjalan di node untuk resolusi nama alih-alih menggunakan kube-dns Layanan. Fitur ini secara otomatis disertakan dalam Mode Otomatis EKS.

Konfigurasikan penskalaan otomatis CoreDNS

Metode lain untuk meningkatkan kinerja DNS Cluster adalah dengan mengaktifkan penskalaan otomatis bawaan CoreDNS Pod.

Fitur ini terus memantau status cluster, termasuk jumlah node dan inti CPU. Berdasarkan informasi itu, pengontrol akan secara dinamis menyesuaikan jumlah replika penyebaran CoreDNS di cluster EKS.