Pesawat Data Kubernetes

Memilih jenis EC2 instance mungkin merupakan salah satu keputusan tersulit yang dihadapi pelanggan karena dalam kelompok dengan banyak beban kerja. Tidak ada solusi one-size-fits semua. Berikut adalah beberapa tips untuk membantu Anda menghindari jebakan umum dengan penskalaan komputasi.

Penskalaan otomatis node

Kami menyarankan Anda menggunakan penskalaan otomatis node yang mengurangi kerja keras dan terintegrasi secara mendalam dengan Kubernetes. Grup node terkelola dan Karpenter direkomendasikan untuk cluster skala besar.

Grup node terkelola akan memberi Anda fleksibilitas grup EC2 Auto Scaling Amazon dengan manfaat tambahan untuk peningkatan dan konfigurasi terkelola. Ini dapat diskalakan dengan Kubernetes Cluster Autoscaler dan merupakan opsi umum untuk cluster yang memiliki berbagai kebutuhan komputasi.

Karpenter adalah open source, workload-native node autoscaler yang dibuat oleh AWS. Ini menskalakan node dalam cluster berdasarkan persyaratan beban kerja untuk sumber daya (misalnya GPU) dan taint dan toleransi (misalnya penyebaran zona) tanpa mengelola grup node. Node dibuat langsung dari EC2 mana menghindari kuota grup node default—450 node per grup—dan memberikan fleksibilitas pemilihan instance yang lebih besar dengan overhead operasional yang lebih sedikit. Kami merekomendasikan pelanggan menggunakan Karpenter jika memungkinkan.

Gunakan banyak jenis EC2 instance yang berbeda

Setiap wilayah AWS memiliki jumlah instans yang tersedia terbatas per jenis instans. Jika Anda membuat klaster yang hanya menggunakan satu jenis instance dan menskalakan jumlah node di luar kapasitas wilayah, Anda akan menerima kesalahan bahwa tidak ada instance yang tersedia. Untuk menghindari masalah ini, Anda tidak boleh secara sewenang-wenang membatasi jenis instance yang dapat digunakan di cluster Anda.

Karpenter akan menggunakan serangkaian luas jenis instance yang kompatibel secara default dan akan memilih instance pada waktu penyediaan berdasarkan persyaratan beban kerja yang tertunda, ketersediaan, dan biaya. Anda dapat memperluas daftar jenis instance yang digunakan dalam karpenter.k8s.aws/instance-category kunci. NodePools

Kubernetes Cluster Autoscaler membutuhkan kelompok node untuk memiliki ukuran yang sama sehingga mereka dapat secara konsisten diskalakan. Anda harus membuat beberapa grup berdasarkan CPU dan ukuran memori dan menskalakannya secara independen. Gunakan ec2-instance-selector untuk mengidentifikasi instance yang berukuran sama untuk grup node Anda.

ec2-instance-selector --service eks --vcpus-min 8 --memory-min 16
a1.2xlarge
a1.4xlarge
a1.metal
c4.4xlarge
c4.8xlarge
c5.12xlarge
c5.18xlarge
c5.24xlarge
c5.2xlarge
c5.4xlarge
c5.9xlarge
c5.metal

Lebih suka node yang lebih besar untuk mengurangi beban server API

Ketika memutuskan jenis instance apa yang akan digunakan, lebih sedikit, node besar akan menempatkan lebih sedikit beban pada Kubernetes Control Plane karena akan ada lebih sedikit kubelet dan berjalan. DaemonSets Namun, node besar mungkin tidak digunakan sepenuhnya seperti node yang lebih kecil. Ukuran node harus dievaluasi berdasarkan ketersediaan beban kerja dan persyaratan skala Anda.

Sebuah cluster dengan tiga instance u-24tb1.metal (memori 24 TB dan 448 core) memiliki 3 kubelet, dan akan dibatasi hingga 110 pod per node secara default. Jika pod Anda masing-masing menggunakan 4 core maka ini mungkin diharapkan (4 core x 110 = 440 core/node). Dengan cluster 3 node, kemampuan Anda untuk menangani insiden instance akan rendah karena 1 pemadaman instance dapat memengaruhi 1/3 cluster. Anda harus menentukan persyaratan node dan penyebaran pod di beban kerja Anda sehingga scheduler Kubernetes dapat menempatkan beban kerja dengan benar.

Beban kerja harus menentukan sumber daya yang mereka butuhkan dan ketersediaan yang diperlukan melalui taints, toleransi, dan. PodTopologySpread Mereka harus memilih node terbesar yang dapat dimanfaatkan sepenuhnya dan memenuhi tujuan ketersediaan untuk mengurangi beban pesawat kontrol, menurunkan operasi, dan mengurangi biaya.

Penjadwal Kubernetes akan secara otomatis mencoba menyebarkan beban kerja di seluruh zona ketersediaan dan host jika sumber daya tersedia. Jika tidak ada kapasitas yang tersedia, Kubernetes Cluster Autoscaler akan mencoba menambahkan node di setiap Availability Zone secara merata. Karpenter akan mencoba menambahkan node secepat dan semurah mungkin kecuali beban kerja menentukan persyaratan lain.

Untuk memaksa beban kerja menyebar dengan penjadwal dan node baru yang akan dibuat di seluruh zona ketersediaan, Anda harus menggunakan: topologySpreadConstraints

spec:
  topologySpreadConstraints:
    - maxSkew: 3
      topologyKey: "topology.kubernetes.io/zone"
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          dev: my-deployment
    - maxSkew: 2
      topologyKey: "kubernetes.io/hostname"
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          dev: my-deployment

Gunakan ukuran node yang serupa untuk kinerja beban kerja yang konsisten

Beban kerja harus menentukan ukuran node apa yang mereka butuhkan untuk dijalankan untuk memungkinkan kinerja yang konsisten dan penskalaan yang dapat diprediksi. Beban kerja yang meminta CPU 500m akan berkinerja berbeda pada instance dengan 4 core vs satu dengan 16 core. Hindari tipe instance yang menggunakan burstable CPUs seperti instance seri T.

Untuk memastikan beban kerja Anda mendapatkan kinerja yang konsisten, beban kerja dapat menggunakan label Karpenter yang didukung untuk menargetkan ukuran instance tertentu.

kind: deployment
...
spec:
  template:
    spec:
    containers:
    nodeSelector:
      karpenter.k8s.aws/instance-size: 8xlarge

Beban kerja yang dijadwalkan dalam klaster dengan Kubernetes Cluster Autoscaler harus cocok dengan pemilih node dengan grup node berdasarkan pencocokan label.

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/nodegroup
            operator: In
            values:
            - 8-core-node-group    # match your node group name

Gunakan sumber daya komputasi secara efisien

Sumber daya komputasi mencakup EC2 instance dan zona ketersediaan. Menggunakan sumber daya komputasi secara efektif akan meningkatkan skalabilitas, ketersediaan, kinerja, dan mengurangi total biaya Anda. Penggunaan sumber daya yang efisien sangat sulit diprediksi dalam lingkungan penskalaan otomatis dengan banyak aplikasi. Karpenter diciptakan untuk menyediakan contoh sesuai permintaan berdasarkan kebutuhan beban kerja untuk memaksimalkan pemanfaatan dan fleksibilitas.

Karpenter memungkinkan beban kerja untuk mendeklarasikan jenis sumber daya komputasi yang dibutuhkannya tanpa terlebih dahulu membuat grup node atau mengonfigurasi noda label untuk node tertentu. Lihat praktik terbaik Karpenter untuk informasi lebih lanjut. Pertimbangkan untuk mengaktifkan konsolidasi di penyedia Karpenter Anda untuk mengganti node yang sedang digunakan.

Otomatiskan pembaruan Amazon Machine Image (AMI)

Menjaga agar komponen node pekerja tetap up to date akan memastikan Anda memiliki patch keamanan terbaru dan fitur yang kompatibel dengan Kubernetes API. Memperbarui kubelet adalah komponen terpenting untuk fungsionalitas Kubernetes, tetapi mengotomatisasi OS, kernel, dan patch aplikasi yang diinstal secara lokal akan mengurangi pemeliharaan saat Anda menskalakan.

Disarankan agar Anda menggunakan Amazon EKS terbaru yang dioptimalkan Amazon Linux 2 atau Amazon EKS Bottlerocket AMI yang dioptimalkan untuk gambar simpul Anda. Karpenter akan secara otomatis menggunakan AMI terbaru yang tersedia untuk menyediakan node baru di cluster. Grup node terkelola akan memperbarui AMI selama pembaruan grup node tetapi tidak akan memperbarui ID AMI pada waktu penyediaan node.

Untuk Grup Node Terkelola, Anda perlu memperbarui templat peluncuran Auto Scaling Group (ASG) dengan AMI baru IDs saat tersedia untuk rilis patch. Versi minor AMI (misalnya 1.23.5 hingga 1.24.3) akan tersedia di konsol EKS dan API sebagai peningkatan untuk grup node. Versi rilis patch (misalnya 1.23.5 hingga 1.23.6) tidak akan disajikan sebagai peningkatan untuk grup node. Jika Anda ingin memperbarui grup node dengan rilis patch AMI, Anda perlu membuat versi template peluncuran baru dan membiarkan grup node mengganti instance dengan rilis AMI baru.

Anda dapat menemukan AMI terbaru yang tersedia dari halaman ini atau menggunakan AWS CLI.

aws ssm get-parameter \
  --name /aws/service/eks/optimized-ami/1.24/amazon-linux-2/recommended/image_id \
  --query "Parameter.Value" \
  --output text

Gunakan beberapa volume EBS untuk kontainer

Volume EBS memiliki kuota input/output (I/O) berdasarkan jenis volume (misalnya gp3) dan ukuran disk. Jika aplikasi Anda berbagi satu volume root EBS dengan host, ini dapat menghabiskan kuota disk untuk seluruh host dan menyebabkan aplikasi lain menunggu kapasitas yang tersedia. Aplikasi menulis ke disk jika mereka menulis file ke partisi overlay mereka, memasang volume lokal dari host, dan juga ketika mereka log ke standar out (STDOUT) tergantung pada agen logging yang digunakan.

Untuk menghindari I/O kehabisan disk, Anda harus memasang volume kedua ke folder status kontainer (mis. /run/containerd), gunakan volume EBS terpisah untuk penyimpanan beban kerja, dan nonaktifkan logging lokal yang tidak perlu.

Untuk memasang volume kedua ke EC2 instance Anda menggunakan eksctl, Anda dapat menggunakan grup node dengan konfigurasi ini:

managedNodeGroups:
  - name: al2-workers
    amiFamily: AmazonLinux2
    desiredCapacity: 2
    volumeSize: 80
    additionalVolumes:
      - volumeName: '/dev/sdz'
        volumeSize: 100
    preBootstrapCommands:
    - |
      "systemctl stop containerd"
      "mkfs -t ext4 /dev/nvme1n1"
      "rm -rf /var/lib/containerd/*"
      "mount /dev/nvme1n1 /var/lib/containerd/"
      "systemctl start containerd"

Jika Anda menggunakan terraform untuk menyediakan grup node Anda, silakan lihat contoh di EKS Blueprints for terraform. Jika Anda menggunakan Karpenter untuk menyediakan node, Anda dapat menggunakan blockDeviceMappingsdengan data pengguna node untuk menambahkan volume tambahan.

Untuk memasang volume EBS langsung ke pod Anda, Anda harus menggunakan driver AWS EBS CSI dan menggunakan volume dengan kelas penyimpanan.

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 4Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  containers:
  - name: app
    image: public.ecr.aws/docker/library/nginx
    volumeMounts:
    - name: persistent-storage
      mountPath: /data
  volumes:
  - name: persistent-storage
    persistentVolumeClaim:
      claimName: ebs-claim

Hindari instance dengan batas lampiran EBS rendah jika beban kerja menggunakan volume EBS

EBS adalah salah satu cara termudah agar beban kerja memiliki penyimpanan persisten, tetapi juga dilengkapi dengan keterbatasan skalabilitas. Setiap jenis instans memiliki jumlah maksimum volume EBS yang dapat dilampirkan. Beban kerja perlu mendeklarasikan tipe instance apa yang harus mereka jalankan dan membatasi jumlah replika pada satu instance dengan taints Kubernetes.

Nonaktifkan logging yang tidak perlu ke disk

Hindari logging lokal yang tidak perlu dengan tidak menjalankan aplikasi Anda dengan debug logging dalam produksi dan menonaktifkan logging yang sering membaca dan menulis ke disk. Journald adalah layanan logging lokal yang menyimpan buffer log di memori dan flushes ke disk secara berkala. Journald lebih disukai daripada syslog yang mencatat setiap baris langsung ke disk. Menonaktifkan syslog juga menurunkan jumlah total penyimpanan yang Anda butuhkan dan menghindari perlunya aturan rotasi log yang rumit. Untuk menonaktifkan syslog, Anda dapat menambahkan cuplikan berikut ke konfigurasi cloud-init Anda:

runcmd:
  - [ systemctl, disable, --now, syslog.service ]

Contoh tambalan di tempat ketika kecepatan pembaruan OS adalah suatu keharusan

penting

Contoh penambalan di tempat hanya boleh dilakukan bila diperlukan. Amazon merekomendasikan untuk memperlakukan infrastruktur sebagai pembaruan yang tidak dapat diubah dan diuji secara menyeluruh yang dipromosikan melalui lingkungan yang lebih rendah dengan cara yang sama seperti aplikasi. Bagian ini berlaku ketika itu tidak memungkinkan.

Dibutuhkan beberapa detik untuk menginstal paket pada host Linux yang ada tanpa mengganggu beban kerja kontainer. Paket dapat diinstal dan divalidasi tanpa menutup, menguras, atau mengganti instance.

Untuk mengganti instance, Anda harus terlebih dahulu membuat, memvalidasi, dan mendistribusikan yang baru AMIs. Instance perlu memiliki pengganti yang dibuat, dan instance lama perlu ditutup dan dikeringkan. Kemudian beban kerja perlu dibuat pada instance baru, diverifikasi, dan diulang untuk semua instance yang perlu ditambal. Dibutuhkan berjam-jam, berhari-hari, atau berminggu-minggu untuk mengganti instance dengan aman tanpa mengganggu beban kerja.

Amazon merekomendasikan penggunaan infrastruktur yang tidak dapat diubah yang dibangun, diuji, dan dipromosikan dari sistem deklaratif otomatis, tetapi jika Anda memiliki persyaratan untuk menambal sistem dengan cepat maka Anda perlu menambal sistem di tempat dan menggantinya saat baru AMIs tersedia. Karena perbedaan waktu yang besar antara menambal dan mengganti sistem, kami sarankan menggunakan AWS Systems Manager Patch Manager untuk mengotomatiskan patch node saat diperlukan untuk melakukannya.

Menambal node akan memungkinkan Anda untuk dengan cepat meluncurkan pembaruan keamanan dan mengganti instance pada jadwal reguler setelah AMI Anda diperbarui. Jika Anda menggunakan sistem operasi dengan sistem file root read-only seperti Flatcar Container Linux atau Bottlerocket OS, kami sarankan menggunakan operator pembaruan yang bekerja dengan sistem operasi tersebut. Operator pembaruan Flatcar Linux dan operator pembaruan Bottlerocket akan me-reboot instance untuk menjaga node tetap up to date secara otomatis.