View a markdown version of this page

Buat Kelas Node untuk Amazon EKS - Amazon EKS

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.

Buat Kelas Node untuk Amazon EKS

Kelas Node Amazon EKS adalah template yang menawarkan kontrol terperinci atas konfigurasi node yang dikelola Mode Otomatis EKS Anda. Kelas Node mendefinisikan pengaturan tingkat infrastruktur yang berlaku untuk grup node di cluster EKS Anda, termasuk konfigurasi jaringan, pengaturan penyimpanan, dan penandaan sumber daya. Topik ini menjelaskan cara membuat dan mengonfigurasi Kelas Node untuk memenuhi persyaratan operasional spesifik Anda.

Saat Anda perlu menyesuaikan bagaimana Mode Otomatis EKS menyediakan dan mengonfigurasi instans EC2 di luar pengaturan default, membuat Kelas Node memberi Anda kontrol yang tepat atas parameter infrastruktur penting. Misalnya, Anda dapat menentukan penempatan subnet pribadi untuk keamanan yang ditingkatkan, mengonfigurasi penyimpanan sementara instans untuk beban kerja yang sensitif terhadap kinerja, atau menerapkan penandaan khusus untuk alokasi biaya.

Buat Kelas Node

Untuk membuatNodeClass, ikuti langkah-langkah ini:

  1. Buat file YAML (misalnya,nodeclass.yaml) dengan konfigurasi Kelas Node Anda

  2. Terapkan konfigurasi ke cluster Anda menggunakan kubectl

  3. Referensikan Kelas Node dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat Membuat Kumpulan Simpul untuk Mode Otomatis EKS.

Anda perlu kubectl menginstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat Siapkan untuk menggunakan Amazon EKS.

Contoh Kelas Node Dasar

Berikut adalah contoh Kelas Node:

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: private-compute spec: subnetSelectorTerms: - tags: Name: "private-subnet" kubernetes.io/role/internal-elb: "1" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" ephemeralStorage: size: "160Gi"

Ini NodeClass meningkatkan jumlah penyimpanan sementara pada node.

Terapkan konfigurasi ini dengan menggunakan:

kubectl apply -f nodeclass.yaml

Selanjutnya, referensi Kelas Node dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat Membuat Kumpulan Simpul untuk Mode Otomatis EKS.

Buat entri akses kelas node

Jika Anda membuat kelas node khusus, Anda perlu membuat Entri Akses EKS untuk mengizinkan node bergabung dengan cluster. EKS secara otomatis membuat entri akses saat Anda menggunakan kelas node bawaan dan kumpulan node.

Untuk informasi tentang cara kerja Entri Akses, lihatBerikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS.

Saat membuat entri akses untuk kelas node Mode Otomatis EKS, Anda perlu menggunakan jenis entri EC2 akses.

Buat entri akses dengan CLI

Untuk membuat entri akses untuk node EC2 dan mengaitkan Kebijakan Node Otomatis EKS:

Perbarui perintah CLI berikut dengan nama cluster Anda, dan peran node ARN. Peran node ARN ditentukan dalam kelas node YAML.

# Create the access entry for EC2 nodes aws eks create-access-entry \ --cluster-name <cluster-name> \ --principal-arn <node-role-arn> \ --type EC2 # Associate the auto node policy aws eks associate-access-policy \ --cluster-name <cluster-name> \ --principal-arn <node-role-arn> \ --policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \ --access-scope type=cluster

Buat entri akses dengan CloudFormation

Untuk membuat entri akses untuk node EC2 dan mengaitkan Kebijakan Node Otomatis EKS:

Perbarui yang berikut CloudFormation dengan nama cluster Anda, dan peran node ARN. Peran node ARN ditentukan dalam kelas node YAML.

EKSAutoNodeRoleAccessEntry: Type: AWS::EKS::AccessEntry Properties: ClusterName: <cluster-name> PrincipalArn: <node-role-arn> Type: "EC2" AccessPolicies: - AccessScope: Type: cluster PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy DependsOn: [ <cluster-name> ] # previously defined in CloudFormation

Untuk informasi tentang penerapan tumpu CloudFormation kan, lihat Mem ulai dengan CloudFormation

Spesifikasi Kelas Node

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: my-node-class spec: # Required fields # role and instanceProfile are mutually exclusive fields. role: MyNodeRole # IAM role for EC2 instances # instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances subnetSelectorTerms: - tags: Name: "private-subnet" kubernetes.io/role/internal-elb: "1" # Alternative using direct subnet ID # - id: "subnet-0123456789abcdef0" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" # Alternative approaches: # - id: "sg-0123456789abcdef0" # - name: "eks-cluster-security-group" # Optional: Pod subnet selector for advanced networking podSubnetSelectorTerms: - tags: Name: "pod-subnet" kubernetes.io/role/pod: "1" # Alternative using direct subnet ID # - id: "subnet-0987654321fedcba0" # must include Pod security group selector also podSecurityGroupSelectorTerms: - tags: Name: "eks-pod-sg" # Alternative using direct security group ID # - id: "sg-0123456789abcdef0" # Optional: Selects on-demand capacity reservations and capacity blocks # for EKS Auto Mode to prioritize. capacityReservationSelectorTerms: - id: cr-56fac701cc1951b03 # Alternative Approaches - tags: Name: "targeted-odcr" # Optional owning account ID filter owner: "012345678901" # Optional fields snatPolicy: Random # or Disabled networkPolicy: DefaultAllow # or DefaultDeny networkPolicyEventLogs: Disabled # or Enabled ephemeralStorage: size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T iops: 3000 # Range: 3000-16000 throughput: 125 # Range: 125-1000 # Optional KMS key for encryption kmsKeyID: "arn:aws: kms:region:account:key/key-id" # Accepted formats: # KMS Key ID # KMS Key ARN # Key Alias Name # Key Alias ARN advancedNetworking: # Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass. # If not set, defaults to the MapPublicIpOnLaunch setting on the subnet. associatePublicIPAddress: false # Optional: Forward proxy, commonly requires certificateBundles as well # for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters #httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use [] noProxy: #Max 50 entries - localhost #Max 255 characters each - 127.0.0.1 #- ::1 # IPv6 localhost #- 0:0:0:0:0:0:0:1 # IPv6 localhost - 169.254.169.254 # EC2 Instance Metadata Service #- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service # Domains to exclude, put all VPC endpoints here - .internal - .eks.amazonaws.com # ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode. ipv4PrefixSize: Auto # or "32" # enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters enableV4Egress: false # Optional: Static network interface configuration for EFA workloads networkInterfaces: # The primary ENI (networkCardIndex 0, deviceIndex 0) must use interfaceType: interface # secondaryIPv4Count and secondaryIPv4PrefixCount are only supported on networkCardIndex 0 - deviceIndex: 0 interfaceType: interface networkCardIndex: 0 secondaryIPv4Count: 10 - deviceIndex: 1 interfaceType: interface networkCardIndex: 0 secondaryIPv4PrefixCount: 2 # Only one of secondaryIPv4Count or secondaryIPv4PrefixCount per ENI - deviceIndex: 0 interfaceType: efa-only networkCardIndex: 1 advancedSecurity: # Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs. fips: false # Optional: Custom certificate bundles. certificateBundles: - name: "custom-cert" data: "base64-encoded-cert-data" # Optional: EC2 Placement Group placementGroupSelector: name: "targeted-pg" # Alternative use direct placement group ID # id: "pg-02465754522cda020" # Optional: Additional EC2 tags (with restrictions) tags: Environment: "production" Team: "platform" # Note: Cannot use restricted tags like: # - kubernetes.io/cluster/* # - karpenter.sh/provisioner-name # - karpenter.sh/nodepool # - karpenter.sh/nodeclaim # - karpenter.sh/managed-by # - eks.amazonaws.com/nodeclass

Pertimbangan-pertimbangan

  • Jika Anda ingin memverifikasi berapa banyak penyimpanan lokal yang dimiliki instance, Anda dapat menjelaskan node untuk melihat sumber daya penyimpanan sementara.

  • Enkripsi Volume - EKS menggunakan kunci KMS kustom yang dikonfigurasi untuk mengenkripsi volume root read-only dari instance dan volume data. read/write

  • Ganti peran IAM node - Jika Anda mengubah peran IAM node yang terkait dengan aNodeClass, Anda perlu membuat Entri Akses baru. EKS secara otomatis membuat Entri Akses untuk peran IAM node selama pembuatan cluster. Peran IAM node memerlukan Kebijakan Ak AmazonEKSAutoNodePolicy ses EKS. Untuk informasi selengkapnya, lihat Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS.

  • kepadatan Pod maksimum - EKS membatasi jumlah maksimum Pod pada node menjadi 110. Batas ini diterapkan setelah perhitungan Max Pod yang ada. Untuk informasi selengkapnya, lihat Pilih jenis instans node Amazon EC2 yang optimal.

  • Tag - Jika Anda ingin menyebarkan tag dari Kubernetes ke EC2, Anda perlu mengonfigurasi izin IAM tambahan. Untuk informasi selengkapnya, lihat Pelajari tentang identitas dan akses di Mode Otomatis EKS.

  • Kelas simpul default - Jangan beri nama kelas simpul kustom Andadefault. Ini karena Mode Otomatis EKS NodeClass menyertakan panggilan default yang disediakan secara otomatis ketika Anda mengaktifkan setidaknya satu bawaanNodePool. Untuk informasi tentang mengaktifkan bawaanNodePools, lihatAktifkan atau Nonaktifkan Built-in NodePools.

  • subnetSelectorTermsperilaku dengan beberapa subnet - Jika ada beberapa subnet yang cocok dengan subnetSelectorTerms kondisi atau yang Anda berikan berdasarkan ID, Mode Otomatis EKS membuat node yang didistribusikan di seluruh subnet.

    • Jika subnet berada di Availability Zones (AZ) yang berbeda, Anda dapat menggunakan fitur Kubernetes seperti batasan penyebaran topologi Pod dan Perutean Aware Topology untuk menyebarkan Pod dan lalu lintas di seluruh zona, masing-masing.

    • Jika ada beberapa subnet di AZ yang sama yang cocok dengansubnetSelectorTerms, Mode Otomatis EKS membuat Pod pada setiap node yang didistribusikan di seluruh subnet di AZ tersebut. Mode Otomatis EKS menciptakan antarmuka jaringan sekunder pada setiap node di subnet lain di AZ yang sama. Ia memilih berdasarkan jumlah alamat IP yang tersedia di setiap subnet, untuk menggunakan subnet lebih efisien. Namun, Anda tidak dapat menentukan subnet mana yang digunakan Mode Otomatis EKS untuk setiap Pod; jika Anda memerlukan Pod untuk dijalankan di subnet tertentu, gunakan Pisahkan subnet dan grup keamanan untuk Pod sebagai gantinya.

  • Batasan strategi grup penempatan — Setiap strategi grup penempatan (cluster, partisi, spread) memiliki batasan spesifik pada jenis instans, AZ, dan kapasitas. Untuk detailnya, lihat Strategi grup Penempatan di Panduan Pengguna Amazon EC2.

  • Grup penempatan spread — Batas 7 instans — Grup penempatan spread tingkat rak memungkinkan maksimal 7 instans berjalan per Availability Zone per grup. Ini menciptakan kasus tepi berikut:

    • Penggantian drift diblokir pada kapasitas — Mode Otomatis EKS meluncurkan node pengganti sebelum menghentikan yang lama. Ketika spread PG memiliki 7 instance di AZ, peluncuran pengganti gagal dan simpul yang melayang tetap berjalan sampai slot dibebaskan.

    • Semua AZ pada kapasitas — Jika setiap AZ dalam spread PG berada pada batas 7 instansnya, tidak ada penggantian yang dapat dijadwalkan. Node yang melayang atau kandidat konsolidasi tetap berjalan tanpa batas waktu.

    • Tidak ada cadangan di luar grup penempatan — Mode Otomatis EKS tidak mencoba meluncurkan instans pengganti di luar grup penempatan.

    • Solusi — Gunakan kebijakan WhenEmpty konsolidasi ()consolidationPolicy: WhenEmpty. Node dihapus hanya setelah semua pod non-daemonset habis, membebaskan slot PG tanpa perlu peluncuran pengganti terlebih dahulu. Perhatikan bahwa drift selalu menggunakan replace-then-delete terlepas dari kebijakan konsolidasi, sehingga drift tetap diblokir pada kapasitas.

  • Grup penempatan cluster AZ pinning - Setelah instance pertama diluncurkan ke grup penempatan cluster, PG disematkan ke AZ tersebut. Jika Anda NodePool mengizinkan beberapa AZ, peluncuran paralel selama peningkatan skala awal mungkin berlomba: satu berhasil dan menyematkan AZ, sisanya gagal dengan kesalahan kapasitas. Sematkan AZ dalam NodePool persyaratan Anda untuk menghindari kegagalan sementara.

  • Grup penempatan partisi — Grup penempatan partisi didukung tanpa batasan tambahan di luar batas EC2 standar.

  • Konsolidasi dapat memindahkan pod keluar dari grup penempatan — Jika pod tidak memiliki batasan penjadwalan grup penempatan (seperti aktifeks.amazonaws.com/placement-group-id), konsolidasi dapat memindahkannya ke node di luar PG. nodeSelector Aplikasi yang memerlukan keanggotaan grup penempatan harus mengekspresikan ini melalui batasan tingkat pod.

  • Grup penempatan yang tidak ada atau dihapus — Jika NodeClass referensi grup penempatan yang tidak ada atau telah dihapus, tidak ada instance yang diluncurkan. Format ID grup penempatan divalidasi saat masuk, tetapi keberadaannya hanya diperiksa pada waktu peluncuran. Jika grup penempatan dihapus saat node sedang berjalan, node yang ada ditandai sebagai hanyut dan tetap berjalan tanpa batas waktu karena peluncuran penggantian drift juga diblokir.

Pisahkan subnet dan grup keamanan untuk Pod

podSecurityGroupSelectorTermsBid podSubnetSelectorTerms ang dan memungkinkan konfigurasi jaringan lanjutan dengan mengizinkan Pod menggunakan subnet dan grup keamanan yang berbeda dari node mereka. Kedua bidang harus ditentukan bersama. Pemisahan ini memberikan kontrol yang ditingkatkan atas perutean lalu lintas jaringan dan kebijakan keamanan.

catatan

Fitur ini berbeda dengan fitur Grup Keamanan untuk Pod (SGPP) yang digunakan dengan VPC CNI untuk komputasi Mode Otomatis non-EKS. SGPP tidak didukung dalam Mode Otomatis EKS. Sebagai gantinya, gunakan podSecurityGroupSelectorTerms di NodeClass untuk menerapkan grup keamanan terpisah ke lalu lintas Pod. Grup keamanan berlaku di NodeClass level, artinya semua Pod pada node yang menggunakan yang NodeClass berbagi grup keamanan Pod yang sama.

Cara kerjanya

Saat Anda mengkonfigurasi podSubnetSelectorTerms danpodSecurityGroupSelectorTerms:

  1. ENI utama node menggunakan subnet dan grup keamanan dari subnetSelectorTerms dansecurityGroupSelectorTerms. Hanya alamat IP node sendiri yang ditetapkan ke antarmuka ini.

  2. Mode Otomatis EKS membuat ENI sekunder di subnet yang cocokpodSubnetSelectorTerms, dengan grup keamanan dari podSecurityGroupSelectorTerms terlampir. Alamat IP pod dialokasikan dari ENI sekunder ini menggunakan awalan /28 secara default, dengan fallback otomatis ke IP sekunder (/32) ketika blok awalan yang berdekatan tidak tersedia. Jika ipv4PrefixSize disetel ke "32" inadvancedNetworking, hanya IP sekunder yang digunakan.

  3. Grup keamanan yang ditentukan dalam podSecurityGroupSelectorTerms berlaku untuk lalu lintas Pod dalam VPC. Untuk lalu lintas yang ditujukan di luar VPC, Pod menggunakan ENI utama node (dan grup keamanannya) karena terjemahan alamat jaringan sumber (SNAT) menerjemahkan IP Pod ke IP node. Anda dapat memodifikasi perilaku ini dengan snatPolicy bidang diNodeClass.

Kasus penggunaan

Gunakan podSubnetSelectorTerms dan podSecurityGroupSelectorTerms kapan Anda perlu:

  • Terapkan grup keamanan yang berbeda untuk mengontrol lalu lintas untuk node dan Pod secara terpisah.

  • Pisahkan lalu lintas infrastruktur (komunikasi node-ke-node) dari lalu lintas aplikasi (Pod-to-Pod komunikasi).

  • Terapkan konfigurasi jaringan yang berbeda ke subnet node daripada subnet Pod.

  • Konfigurasikan proxy terbalik atau pemfilteran jaringan khusus untuk lalu lintas node tanpa mempengaruhi lalu lintas Pod. Gunakan advancedNetworking dan certificateBundles untuk menentukan proxy terbalik Anda dan sertifikat yang ditandatangani sendiri atau pribadi untuk proxy.

Contoh konfigurasi

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: advanced-networking spec: role: MyNodeRole # Subnets and security groups for EC2 instances (nodes) subnetSelectorTerms: - tags: Name: "node-subnet" kubernetes.io/role/internal-elb: "1" securityGroupSelectorTerms: - tags: Name: "eks-cluster-sg" # Separate subnets and security groups for Pods podSubnetSelectorTerms: - tags: Name: "pod-subnet" kubernetes.io/role/pod: "1" podSecurityGroupSelectorTerms: - tags: Name: "eks-pod-sg"

Pertimbangan untuk subnet Pod dan grup keamanan terpisah

  • Lingkup grup keamanan: Grup keamanan dari podSecurityGroupSelectorTerms dilampirkan ke ENI sekunder dan berlaku untuk lalu lintas Pod dalam VPC. Ketika SNAT diaktifkan (defaultsnatPolicy: Random), lalu lintas yang meninggalkan VPC diterjemahkan ke alamat IP ENI utama node, sehingga grup keamanan node securityGroupSelectorTerms diterapkan ke lalu lintas itu sebagai gantinya. Jika Anda menyet snatPolicy: Disabled el, Pod menggunakan alamat IP mereka sendiri untuk semua lalu lintas, dan Anda harus memastikan bahwa grup routing dan keamanan dikonfigurasi sesuai dengan itu.

  • NodeClass-level perincian: Grup keamanan Pod berlaku untuk semua Pod yang dijadwalkan pada node menggunakan. NodeClass Untuk menerapkan grup keamanan yang berbeda ke beban kerja yang berbeda, buat NodePool sumber daya terpisah NodeClass dan gunakan pencemaran, toleransi, atau pemilih node untuk menjadwalkan beban kerja ke node yang sesuai.

  • Mengurangi kepadatan Pod: Lebih sedikit Pod yang dapat berjalan di setiap node karena antarmuka jaringan utama node dicadangkan untuk IP node dan tidak dapat digunakan untuk Pod.

  • Batasan pemilih subnet: Standar subnetSelectorTerms dan securityGroupSelectorTerms konfigurasi tidak berlaku untuk subnet Pod atau pemilihan grup keamanan.

  • Perencanaan jaringan: Pastikan ruang alamat IP yang memadai di subnet node dan Pod untuk mendukung persyaratan beban kerja Anda.

  • Konfigurasi routing: Pastikan tabel rute dan Network Access Control List (ACL) subnet Pod telah dikonfigurasi dengan benar untuk komunikasi antara node dan subnet Pod.

  • Zona Ketersediaan: Pastikan Anda telah membuat subnet Pod di beberapa AZ. Jika Anda menggunakan subnet Pod tertentu, subnet itu harus berada di AZ yang sama dengan subnet node AZ.

Mode IP Sekunder untuk Pod

Bid ipv4PrefixSize ang ini memungkinkan konfigurasi jaringan lanjutan dengan mengalokasikan hanya alamat IP sekunder ke node. Fitur ini tidak mengalokasikan awalan (/28) ke node dan hanya mempertahankan satu IP sekunder sebagai MinimalIPTarget.

Kasus penggunaan

Gunakan ipv4PrefixSize saat Anda perlu:

  • Pengurangan pemanfaatan IP: Hanya satu alamat IP yang akan dipanaskan di setiap node.

  • Tingkat pengadukan pod yang lebih rendah: Kecepatan pembuatan pod bukanlah masalah utama.

  • Tidak ada fragmentasi awalan: Prefix-caused fragmentasi adalah masalah utama atau pemblokir untuk menggunakan Mode Otomatis.

Contoh konfigurasi

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: advanced-networking spec: role: MyNodeRole advancedNetworking: ipv4PrefixSize: "32"

Pertimbangan untuk mode IP sekunder

  • Mengurangi kecepatan pembuatan Pod: Karena hanya satu IP sekunder yang dipanaskan, layanan IPAM membutuhkan lebih banyak waktu untuk menyediakan IP ketika lebih banyak pod dibuat.

Nonaktifkan keluar IPv4 dari pod IPv6 di cluster IPv6.

enableV4EgressBidang ini true secara default. Untuk cluster IPv6 Mode Otomatis, fitur ini dapat dinonaktifkan sehingga Mode Otomatis tidak akan membuat antarmuka IPv4 khusus keluar untuk pod IPv6. Hal ini penting karena antarmuka keluar IPv4 tidak tunduk pada penegakan Kebijakan Jaringan. Kebijakan jaringan hanya diberlakukan pada antarmuka utama Pod (eth0).

Kasus penggunaan

Gunakan enableV4Egress saat Anda perlu:

  • Gunakan IPv6 Cluster: Lalu lintas keluar IPv4 diizinkan secara default.

  • Gunakan Kebijakan Jaringan: Saat ini Kebijakan Jaringan EKS tidak mendukung dual stack. Menonaktifkan enableV4Egress dapat mencegah lalu lintas pod keluar melalui IPv4 secara tidak terduga.

Contoh konfigurasi

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: advanced-networking spec: role: MyNodeRole advancedNetworking: enableV4Egress: false

Pertimbangan untuk menonaktifkan EnableV4egress

  • Kebijakan Jaringan di Cluster IPv6: Cluster IPv6 memungkinkan lalu lintas IPv4 secara default. Peng enableV4Egress: false aturan memblokir lalu lintas keluar IPv4, memberikan keamanan yang ditingkatkan terutama ketika digunakan dengan Kebijakan Jaringan.

Konfigurasi Antarmuka Jaringan Statis

Bid networkInterfaces ang di bawah advancedNetworking memungkinkan Anda untuk secara statis menentukan antarmuka jaringan yang dilampirkan ke instance saat peluncuran. Ini terutama digunakan untuk mengonfigurasi perangkat Elastic Fabric Adapter (EFA) untuk komunikasi antar-node berkinerja tinggi dalam pelatihan terdistribusi dan beban kerja inferensi. Fitur ini dapat dipasangkan dengan kum pulan node kapasitas statis untuk mempertahankan EFA-ready node yang sudah dipanaskan sebelumnya. Untuk informasi selengkapnya tentang manajemen perangkat EFA di EKS, lihatKelola perangkat EFA di Amazon EKS. Untuk konfigurasi EFA yang direkomendasikan untuk jenis instans tertentu, lihat Memak simalkan bandwidth jaringan untuk jenis EFA-enabled instans di Panduan Pengguna Amazon EC2.

Cara kerjanya

Setiap entri dalam networkInterfaces mendefinisikan antarmuka jaringan yang dilampirkan ke instance selama peluncuran. Setiap entri menentukan networkCardIndex (kartu jaringan, di mana 0 yang utama), a deviceIndex (posisi perangkat pada kartu itu), dan interfaceType (interfaceuntuk IP-based lalu lintas standar, atau untuk antarmuka EFA yang didedikasikan efa-only untuk lalu lintas RDMA tanpa alamat IP). ENI utama (networkCardIndex: 0,deviceIndex: 0) harus digunakan interfaceType: interface untuk mendukung komunikasi IP-based node. Antar efa-only muka hanya mendukung kemampuan perangkat EFA untuk RDMA dan tidak dapat dikonfigurasi dengan alamat IP.

Anda dapat menetapkan kapasitas IP ke antarmuka pada kartu jaringan utama (networkCardIndex: 0) menggunakan secondaryIPv4Count (setiap unit menyediakan 1 alamat IP) atau secondaryIPv4PrefixCount (setiap unit menyediakan awalan /28 dengan 16 alamat IP). Hanya satu dari ini yang dapat digunakan per antarmuka, dan mereka hanya didukungnetworkCardIndex: 0. Mereka tidak dapat digunakan pada efa-only antarmuka.

penting

Ketika networkInterfaces dikonfigurasi, Mode Otomatis EKS tidak melampirkan IP tambahan, awalan, atau ENI setelah peluncuran instance. Hanya antarmuka dan alamat IP yang dikonfigurasi saat peluncuran tersedia untuk Pod. Anda harus merencanakan kepadatan pod berdasarkan jumlah IP yang dikonfigurasi.

Pertimbangan-pertimbangan

IPv6 tidak didukung dengan antarmuka jaringan yang ditentukan secara statis. associatePublicIPAddresstidak kompatibel ketika lebih dari satu antarmuka jaringan ditentukan, sehingga node yang menggunakan beberapa antarmuka tidak dapat memiliki IP publik (baik dalam cluster publik saja atau public/private cluster campuran).

Saat menggunakan podSubnetSelectorTerms dan podSecurityGroupSelectorTerms dengan antarmuka jaringan statis, konfigurasikan ENI primer dengan 0 IP sekunder. ENI primer menggunakan subnet node dan grup keamanan, sedangkan lalu lintas Pod menggunakan konfigurasi subnet pod pada ENI sekunder.

Contoh: EFA-only antarmuka untuk pelatihan GPU

Contoh berikut menunjukkan NodeClass konfigurasi dengan EFA-only antarmuka untuk instance GPU yang digunakan dalam pelatihan terdistribusi. Antarmuka utama memiliki awalan /28 (16 pod IP) dan 4 EFA-only antarmuka tambahan menyediakan konektivitas RDMA. Konfigurasi ini dapat dipasangkan dengan kumpulan node kapasitas statis untuk mempertahankan EFA-ready node yang sudah dipanaskan sebelumnya.

apiVersion: eks.amazonaws.com/v1 kind: NodeClass metadata: name: efa-training spec: role: MyNodeRole subnetSelectorTerms: - tags: Name: "private-subnet" securityGroupSelectorTerms: - tags: Name: "efa-security-group" placementGroupSelector: name: "ml-training-pg" advancedNetworking: networkInterfaces: - deviceIndex: 0 interfaceType: interface networkCardIndex: 0 secondaryIPv4PrefixCount: 1 - deviceIndex: 1 interfaceType: efa-only networkCardIndex: 0 - deviceIndex: 0 interfaceType: efa-only networkCardIndex: 1 - deviceIndex: 0 interfaceType: efa-only networkCardIndex: 2 - deviceIndex: 0 interfaceType: efa-only networkCardIndex: 3