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

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 dua pilihan untuk node pekerja dengan EKS: EC2instance dan Fargate. Jika Anda memilih EC2 instance, Anda dapat mengelola node pekerja sendiri atau menggunakan grup node terkelola EKS. Anda dapat memiliki klaster dengan campuran node pekerja yang dikelola dan dikelola sendiri, dan Fargate.

EKS di Fargate menawarkan jalur termudah ke bidang data yang tangguh. 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 adalah dengan menggunakan Kubernetes Cluster Autoscaler, grup EC2Auto Scaling, atau proyek komunitas seperti Eskalator Atlassian.

Rekomendasi

Gunakan Grup EC2 Auto Scaling untuk membuat node pekerja

Ini adalah praktik terbaik untuk membuat node pekerja menggunakan grup EC2 Auto Scaling alih-alih membuat EC2 instance individual dan menggabungkannya ke cluster. Grup Auto Scaling akan secara otomatis mengganti node yang dihentikan atau gagal memastikan bahwa klaster selalu memiliki kapasitas untuk menjalankan beban kerja Anda.

Gunakan Kubernetes Cluster Autoscaler untuk menskalakan node

Cluster Autoscaler menyesuaikan ukuran bidang data ketika ada pod yang tidak dapat dijalankan karena cluster memiliki sumber daya yang tidak mencukupi, dan menambahkan node pekerja lain akan membantu. Meskipun Cluster Autoscaler adalah proses reaktif, ia menunggu sampai pod berada dalam status Pending karena kapasitas yang tidak mencukupi di cluster. Ketika peristiwa seperti itu terjadi, ia menambahkan EC2 instance ke cluster. Setiap kali klaster kehabisan kapasitas, replika baru - atau pod baru - tidak akan tersedia (dalam status Pending) sampai node pekerja ditambahkan. Penundaan ini dapat memengaruhi keandalan aplikasi Anda jika bidang data tidak dapat menskalakan cukup cepat untuk memenuhi tuntutan beban kerja. Jika node pekerja secara konsisten kurang dimanfaatkan dan semua pod dapat dijadwalkan pada node pekerja lain, Cluster Autoscaler menghentikannya.

Konfigurasikan penyediaan berlebih dengan Cluster Autoscaler

Cluster Autoscaler memicu peningkatan skala data-plane ketika Pod di cluster sudah Tertunda. Oleh karena itu, mungkin ada penundaan antara waktu aplikasi Anda membutuhkan lebih banyak replika, dan ketika, pada kenyataannya, mendapat lebih banyak replika. Opsi untuk memperhitungkan kemungkinan penundaan ini adalah dengan menambahkan lebih dari replika yang diperlukan, menggembungkan jumlah replika untuk aplikasi.

Pola lain yang direkomendasikan oleh Cluster Autoscaler menggunakan Pod jeda dan fitur Priority Preemption. Pod jeda menjalankan kontainer jeda, yang seperti namanya, tidak melakukan apa pun selain bertindak sebagai placeholder untuk kapasitas komputasi yang dapat digunakan oleh Pod lain di klaster Anda. Karena berjalan dengan prioritas yang ditetapkan sangat rendah, Pod jeda akan diusir dari node ketika Pod lain perlu dibuat, dan cluster tidak memiliki kapasitas yang tersedia. Penjadwal Kubernetes memperhatikan penggusuran Pod jeda dan mencoba menjadwalkannya kembali. Tetapi karena cluster berjalan pada kapasitas, Pod jeda tetap Tertunda, dimana Cluster Autoscaler bereaksi dengan menambahkan node.

Menggunakan Cluster Autoscaler dengan beberapa Grup Auto Scaling

Jalankan Cluster Autoscaler dengan flag diaktifkan. --node-group-auto-discovery Melakukan hal itu akan memungkinkan Cluster Autoscaler untuk menemukan semua grup penskalaan otomatis yang menyertakan tag tertentu yang ditentukan dan mencegah kebutuhan untuk mendefinisikan dan memelihara setiap grup penskalaan otomatis dalam manifes.

Menggunakan Cluster Autoscaler dengan penyimpanan lokal

Secara default, Cluster Autoscaler tidak menurunkan skala node yang memiliki pod yang di-deploy dengan penyimpanan lokal yang terpasang. Setel --skip-nodes-with-local-storage flag ke false untuk memungkinkan Cluster Autoscaler menurunkan skala node ini.

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.

Jika kamu menggunakan Kubernetes 1.18+, metode yang disarankan untuk menyebarkan Pod ke seluruh Pod AZs adalah dengan menggunakan Topology Spread Constraints untuk Pod.

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

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

Pastikan kapasitas 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. Pada saat penulisan, volume EBS hanya tersedia dalam satu AZ. Sebuah Pod tidak dapat mengakses volume persisten yang didukung EBS yang terletak di AZ yang berbeda. Penjadwal Kubernetes tahu di AZ mana node pekerja berada. Kubernetes 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.

Buat Auto Scaling Group untuk setiap AZ dengan kapasitas yang cukup untuk memastikan bahwa cluster selalu memiliki kapasitas untuk menjadwalkan pod di AZ yang sama dengan volume EBS yang mereka butuhkan. Selain itu, Anda harus mengaktifkan --balance-similar-node-groups fitur di Cluster Autoscaler.

Jika Anda menjalankan aplikasi yang menggunakan volume EBS tetapi tidak memiliki persyaratan untuk menjadi sangat tersedia, maka Anda dapat membatasi penyebaran aplikasi ke satu AZ. Di EKS, node pekerja secara otomatis ditambahkan failure-domain.beta.kubernetes.io/zone label, yang berisi nama AZ. Anda dapat melihat label yang dilampirkan ke node Anda dengan menjalankankubectl get nodes --show-labels. Informasi lebih lanjut tentang label node bawaan tersedia di sini. Anda dapat menggunakan pemilih node untuk menjadwalkan pod di AZ tertentu.

Pada contoh di bawah ini, pod hanya akan dijadwalkan di us-west-2c AZ:

apiVersion: v1
kind: Pod
metadata:
  name: single-az-pod
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: failure-domain.beta.kubernetes.io/zone
            operator: In
            values:
            - us-west-2c
  containers:
  - name: single-az-container
    image: kubernetes/pause

Volume persisten (didukung oleh EBS) juga secara otomatis diberi label dengan nama AZ; Anda dapat melihat AZ mana yang termasuk dalam volume persisten Anda dengan menjalankan. kubectl get pv -L topology.ebs.csi.aws.com/zone Ketika sebuah pod dibuat dan mengklaim sebuah volume, Kubernetes akan menjadwalkan Pod pada sebuah node dalam AZ yang sama dengan volume.

Pertimbangkan skenario ini; Anda memiliki cluster EKS dengan satu grup node. Grup node ini memiliki tiga node pekerja yang tersebar di tiga AZs. Anda memiliki aplikasi yang menggunakan Volume Persisten yang didukung EBS. Ketika Anda membuat aplikasi ini dan volume yang sesuai, Pod-nya akan dibuat di yang pertama dari ketiganya AZs. Kemudian, node pekerja yang menjalankan Pod ini menjadi tidak sehat dan selanjutnya tidak tersedia untuk digunakan. Cluster Autoscaler akan mengganti node yang tidak sehat dengan node pekerja baru; namun, karena grup penskalaan otomatis mencakup tiga AZs, node pekerja baru dapat diluncurkan di AZ kedua atau ketiga, tetapi tidak di AZ pertama sesuai tuntutan situasi. Karena volume EBS yang dibatasi AZ hanya ada di AZ pertama, tetapi tidak ada node pekerja yang tersedia di AZ tersebut, Pod tidak dapat dijadwalkan. Oleh karena itu, Anda harus membuat satu grup node di setiap AZ, sehingga selalu ada kapasitas yang cukup untuk menjalankan pod yang tidak dapat dijadwalkan di yang lain AZs.

Atau, EFS dapat menyederhanakan penskalaan otomatis cluster saat menjalankan aplikasi yang membutuhkan penyimpanan persisten. Klien dapat mengakses sistem file EFS secara bersamaan dari semua yang ada AZs di wilayah ini. Bahkan jika Pod yang menggunakan Persistent Volume yang didukung EFS dihentikan dan dijadwalkan di AZ yang berbeda, ia akan dapat me-mount volume.

Mendeteksi masalah node dengan agen pemantauan node

Kegagalan pada node pekerja dapat memengaruhi ketersediaan aplikasi Anda. Anda dapat menggunakan agen pemantauan node untuk mendeteksi dan menunjukkan masalah kesehatan. Anda juga dapat mengaktifkan perbaikan otomatis node untuk secara otomatis mengganti node ketika masalah terdeteksi.

Agen pemantauan node disertakan sebagai kemampuan untuk semua kluster Mode Otomatis Amazon EKS. Untuk jenis cluster lainnya, Anda dapat menambahkan agen pemantauan sebagai add-on Amazon EKS. Untuk informasi selengkapnya, lihat Aktifkan perbaikan otomatis node dan selidiki masalah kesehatan node di Panduan Pengguna Amazon EKS.

Cadangan sumber daya untuk sistem dan daemon Kubernetes

Anda dapat meningkatkan stabilitas node pekerja dengan memesan kapasitas komputasi untuk sistem operasi dan daemon Kubernetes. Pod - terutama yang tidak limits dideklarasikan - dapat menjenuhkan sumber daya sistem yang menempatkan node dalam situasi di mana proses sistem operasi dan daemon Kubernetes (kubelet, runtime container, dll.) bersaing dengan pod untuk sumber daya sistem. Anda dapat menggunakan kubelet flag --system-reserved dan --kube-reserved untuk mencadangkan sumber daya untuk proses sistem (udev,sshd, dll.) dan daemon Kubernetes masing-masing.

Jika Anda menggunakan AMI Linux yang dioptimalkan EKS, CPU, memori, dan penyimpanan dicadangkan untuk sistem dan daemon Kubernetes secara default. Ketika node pekerja berdasarkan peluncuran AMI ini, EC2 data pengguna dikonfigurasi untuk memicu skrip. bootstrap.sh Script ini menghitung reservasi CPU dan memori berdasarkan jumlah core CPU dan total memori yang tersedia pada EC2 instance. Nilai yang dihitung ditulis ke KubeletConfiguration file yang terletak di/etc/kubernetes/kubelet/kubelet-config.json.

Anda mungkin perlu meningkatkan reservasi sumber daya sistem jika Anda menjalankan daemon khusus pada node dan jumlah CPU dan memori yang dicadangkan secara default tidak mencukupi.

eksctlmenawarkan cara termudah untuk menyesuaikan reservasi sumber daya untuk sistem dan daemon Kubernetes.

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 Permintaan/Batas Sumber Daya untuk semua Beban Kerja

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

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 penyimpanan dan/atau komputasi (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.

CoreDNS

CoreDNS memenuhi resolusi nama dan fungsi penemuan layanan di Kubernetes. Ini diinstal secara default pada kluster EKS. Untuk interoperabilitas, Layanan Kubernetes untuk CoreDNS masih diberi nama kube-dns. CoreDNS Pod dijalankan sebagai bagian dari Deployment kube-system di namespace, dan di EKS, secara default, ia menjalankan dua replika dengan permintaan dan batasan yang dideklarasikan. Kueri DNS dikirim ke kube-dns Layanan yang berjalan di Namespace. kube-system

Rekomendasi

Pantau metrik CoreDNS

CoreDNS telah membangun dukungan untuk Prometheus. Anda harus secara khusus mempertimbangkan untuk memantau latensi CoreDNS coredns_dns_request_duration_seconds_sum (, sebelum versi 1.7.0 metrik core_dns_response_rcode_count_total dipanggil), error coredns_dns_responses_total (, NXDOMAIN, SERVFAIL FormErr,) dan konsumsi memori CoreDNS Pod.

Untuk tujuan pemecahan masalah, Anda dapat menggunakan kubectl untuk melihat log CoreDNS:

for p in $(kubectl get pods -n kube-system -l k8s-app=kube-dns -o jsonpath='{.items[*].metadata.name}'); do kubectl logs $p -n kube-system; done

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.

Konfigurasi cluster-proportional-scaler untuk CoreDNS

Metode lain untuk meningkatkan kinerja DNS Cluster adalah dengan secara otomatis menskalakan CoreDNS Deployment berdasarkan jumlah node dan core CPU di cluster. Horizontal cluster-proportional-autoscaler adalah wadah yang mengubah ukuran jumlah replika Deployment berdasarkan ukuran data-plane yang dapat dijadwalkan.

Node dan agregat inti CPU di node adalah dua metrik yang dapat digunakan untuk menskalakan CoreDNS. Anda dapat menggunakan kedua metrik secara bersamaan. Jika Anda menggunakan node yang lebih besar, penskalaan CoreDNS didasarkan pada jumlah inti CPU. Sedangkan, jika Anda menggunakan node yang lebih kecil, jumlah replika CoreDNS tergantung pada inti CPU di bidang data Anda. Konfigurasi autoscaler proporsional terlihat seperti ini:

linear: '{"coresPerReplica":256,"min":1,"nodesPerReplica":16}'

Memilih AMI dengan Node Group

EKS menyediakan dioptimalkan EC2 AMIs yang digunakan oleh pelanggan untuk membuat nodegroup yang dikelola sendiri dan dikelola. Ini AMIs diterbitkan di setiap wilayah untuk setiap versi Kubernetes yang didukung. EKS menandai ini AMIs sebagai usang ketika ada CVEs atau bug ditemukan. Oleh karena itu, rekomendasinya adalah untuk tidak menggunakan usang AMIs saat memilih AMI untuk grup node.

Usang AMIs dapat difilter menggunakan Ec2 describe-images api menggunakan perintah di bawah ini:

aws ec2 describe-images --image-id ami-0d551c4f633e7679c --no-include-deprecated

Anda juga dapat mengenali AMI yang tidak digunakan lagi dengan memverifikasi apakah output gambar-deskripsikan berisi bidang as a. DeprecationTime Untuk ex:

aws ec2 describe-images --image-id ami-xxx --no-include-deprecated
{
    "Images": [
        {
            "Architecture": "x86_64",
            "CreationDate": "2022-07-13T15:54:06.000Z",
            "ImageId": "ami-xxx",
            "ImageLocation": "123456789012/eks_xxx",
            "ImageType": "machine",
            "Public": false,
            "OwnerId": "123456789012",
            "PlatformDetails": "Linux/UNIX",
            "UsageOperation": "RunInstances",
            "State": "available",
            "BlockDeviceMappings": [
                {
                    "DeviceName": "/dev/xvda",
                    "Ebs": {
                        "DeleteOnTermination": true,
                        "SnapshotId": "snap-0993a2fc4bbf4f7f4",
                        "VolumeSize": 20,
                        "VolumeType": "gp2",
                        "Encrypted": false
                    }
                }
            ],
            "Description": "EKS Kubernetes Worker AMI with AmazonLinux2 image, (k8s: 1.19.15, docker: 20.10.13-2.amzn2, containerd: 1.4.13-3.amzn2)",
            "EnaSupport": true,
            "Hypervisor": "xen",
            "Name": "aws_eks_optimized_xxx",
            "RootDeviceName": "/dev/xvda",
            "RootDeviceType": "ebs",
            "SriovNetSupport": "simple",
            "VirtualizationType": "hvm",
            "DeprecationTime": "2023-02-09T19:41:00.000Z"
        }
    ]
}