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 yang tersedia tinggi dan tangguh, Anda memerlukan bidang data yang sangat tersedia dan tangguh. Bidang data elastis memastikan 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: EKS Auto Mode managed nodes, EC2 Instances dan Fargate.

Mode Otomatis EKS menawarkan jalur termudah ke bidang data yang tangguh. Mode Otomatis memperluas pengelolaan AWS klaster Kubernetes di luar klaster 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 klaster Anda berukuran tepat dan hemat biaya untuk beban kerja yang sedang berjalan.

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

Fargate menjalankan setiap Pod dalam lingkungan komputasi yang 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 autoscaler pod horizontal.

Cara yang lebih disukai untuk menskalakan node EC2 pekerja (jika tidak menggunakan Mode Otomatis EKS di mana ini dilakukan secara otomatis oleh AWS) adalah dengan menggunakan grup Karpenter, Kubernetes Cluster Autoscaler, atau Auto Scaling. EC2

Rekomendasi

Sebarkan node pekerja dan beban kerja di beberapa AZs

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

Metode yang disarankan untuk menyebarkan pod ke seluruh Pod AZs adalah dengan menggunakan Topology Spread Constraints untuk Pod. Kemampuan penskalaan otomatis seperti Mode Otomatis EKS dan Karpenter menyadari kendala penyebaran topologi dan akan secara otomatis meluncurkan Node di tempat yang benar untuk memungkinkan kendala Anda dipenuhi. AZs

Penerapan di bawah ini menyebarkan pod ke seluruh AZs 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 di-deploy ke cluster dengan node hanya dalam satu zona, semua pod akan menjadwalkan pada node tersebut karena kube-scheduler tidak mengetahui zona lainnya. Agar penyebaran topologi ini berfungsi seperti yang diharapkan dengan penjadwal, node harus sudah ada di semua zona. minDomainsProperti kendala penyebaran topologi digunakan untuk menginformasikan penjadwal jumlah domain yang memenuhi syarat, bahkan jika ada Node yang berjalan di sana untuk menghindari masalah ini.

Awas

Pengaturan whenUnsatisfiable ke DoNotSchedule akan menyebabkan pod tidak dapat dijadwalkan jika batasan penyebaran topologi tidak dapat dipenuhi. Seharusnya hanya disetel jika pod lebih disukai untuk tidak berjalan daripada melanggar batasan penyebaran topologi.

Pada versi Kubernetes yang lebih lama, Anda dapat menggunakan aturan anti-afinitas pod untuk menjadwalkan pod di beberapa pod. AZs Manifes di bawah ini memberi tahu penjadwal Kubernetes untuk memilih pod penjadwalan yang berbeda. AZs

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 secara berbeda, AZs jika tidak, jumlah Pod dalam penerapan tidak akan pernah melebihi jumlah AZs Pod.

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

Jika Anda menggunakan Amazon EBS untuk menyediakan Volume Persisten, Anda perlu memastikan bahwa pod dan volume EBS terkait berada di AZ yang sama. Sebuah Pod tidak dapat mengakses volume persisten yang didukung EBS yang terletak di AZ yang berbeda. Penjadwal Kubernetes mengetahui AZ mana node pekerja berada dari label yang ada di Node dan akan selalu menjadwalkan Pod yang membutuhkan volume EBS dalam 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 Mode Otomatis EKS atau Karpenter, Anda perlu memastikan bahwa subnet NodeClass pilihan Anda 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 merampingkan manajemen EKS dengan menyediakan klaster siap produksi dengan overhead operasional minimal. Mode Otomatis bertanggung jawab untuk menskalakan jumlah Node naik atau turun tergantung pada Pod yang berjalan di klaster. Node selalu diperbarui dengan patch dan perbaikan perangkat lunak secara otomatis, dengan pembaruan dilakukan sesuai dengan pengaturan NodePoolgangguan yang dikonfigurasi dan Anggaran Gangguan Pod.

Jalankan Agen Pemantauan Node

Agen Pemantau Node memantau dan bereaksi terhadap masalah kesehatan Node dengan mempublikasikan peristiwa Kubernetes dan memperbarui kondisi status pada Node. Agen Pemantauan Node disertakan dengan Node Mode Otomatis EKS, 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 Node Monitoring Agent dan memperbaiki Node tersebut secara otomatis ketika kondisi tersebut terjadi.

Menerapkan QoS

Untuk aplikasi kritis, pertimbangkan untuk mendefinisikan requests = limits untuk container di dalam Pod. Ini akan memastikan bahwa kontainer tidak akan dimatikan jika Pod lain meminta sumber daya.

Ini adalah praktik terbaik untuk menerapkan batas CPU dan memori untuk semua kontainer karena mencegah wadah secara tidak sengaja mengkonsumsi sumber daya sistem yang memengaruhi ketersediaan proses lain yang ditempatkan bersama.

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

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

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

  • Untuk sumber daya non-CPU, konfigurasi requests = limits memberikan perilaku yang paling dapat diprediksi. Jikarequests! =limits, kontainer juga mengurangi QOS-nya dari Dijamin menjadi Burstable sehingga lebih mungkin untuk diusir jika terjadi tekanan simpul.

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

  • Permintaan berukuran benar sangat penting saat menggunakan solusi auto-scaling node seperti Karpenter atau Cluster. AutoScaler Alat-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 dimatikan jika mereka telah dikemas rapat pada sebuah node.

Menentukan permintaan sumber daya bisa jadi sulit, tetapi alat seperti Vertical Pod Autoscaler dapat membantu Anda “mengukur” 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 di namespace. ResourceQuotaObjek 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 kontainer di namespace tersebut.

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

Batasi penggunaan sumber daya kontainer dalam namespace

Resource Quotas membantu membatasi jumlah sumber daya yang dapat digunakan namespace. LimitRangeObjek dapat membantu Anda menerapkan sumber daya minimum dan maksimum yang dapat diminta oleh wadah. Menggunakan LimitRange Anda dapat menetapkan permintaan default dan batasan untuk kontainer, yang sangat membantu jika menyetel 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. Selain itu, terapkan permintaan penyimpanan minimum dan maksimum per PersistentVolumeClaim di namespace.

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

Gunakan NodeLocal DNSCache

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

Konfigurasikan CoreDNS auto-scaling

Metode lain untuk meningkatkan kinerja DNS Cluster adalah dengan mengaktifkan auto-scaling bawaan Pod CoreDNS.

Fitur 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.