Membuat cluster

Halaman ini menjelaskan cara membuat cluster GKE di AWS. Anda juga dapat Membuat VPC dan cluster dengan Terraform.

Halaman ini ditujukan untuk Admin dan arsitek serta Operator yang ingin menyiapkan, memantau, dan mengelola infrastruktur cloud. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

Sebelum memulai

Sebelum membuat cluster, Anda harus menyelesaikan prasyarat. Secara khusus, Anda harus menyediakan resource berikut:

  • AWS VPC tempat cluster akan berjalan.
  • Maksimal tiga subnet AWS untuk tiga replika bidang kontrol. Setiap subnet harus berada di AWS Availability Zone yang berbeda.
  • Peran IAM AWS yang diasumsikan GKE di AWS saat mengelola cluster Anda. Hal ini memerlukan serangkaian izin IAM tertentu. izin IAM.
  • Kunci CMK simetris KMS untuk enkripsi data cluster (etcd) dan konfigurasi dalam penyimpanan.
  • Profil instance IAM AWS untuk setiap replika bidang kontrol. Hal ini memerlukan serangkaian izin IAM tertentu.
  • Pasangan kunci SSH EC2 (opsional) jika Anda memerlukan akses SSH ke instance EC2 yang menjalankan setiap replika bidang kontrol.

Anda bertanggung jawab untuk membuat dan mengelola resource ini, yang dapat dibagikan di antara semua cluster GKE Anda. Semua resource AWS yang mendasarinya dan memiliki cakupan cluster dikelola oleh GKE di AWS.

Memilih rentang CIDR untuk cluster Anda

Saat membuat cluster di GKE di AWS, Anda harus menyediakan rentang alamat IPv4 untuk digunakan bagi Pod dan Layanan.

Rentang IP ini ditentukan menggunakan notasi Classless Inter-Domain Routing (CIDR) —misalnya, 100.64.0.0/16.

Sebaiknya gunakan rentang CIDR berikut untuk Layanan dan Pod:

  • Layanan: 100.64.0.0/16
  • Pod: 100.96.0.0/11

Rentang ini cukup besar sehingga Anda dapat mengembangkan cluster tanpa masalah.

Bagian berikut memberikan detail selengkapnya.

Detail tentang pemilihan rentang

GKE di AWS menggunakan jaringan overlay untuk Pod dan Layanan, sehingga rentang IP untuk jaringan ini tidak perlu dapat dirutekan dalam VPC. Rentang IP yang Anda gunakan harus dijamin tersedia. Untuk mengetahui informasi selengkapnya, lihat Dataplane V2.

  • Rentang IP Pod dan Layanan dapat tumpang tindih dengan jaringan VPC, asalkan tidak menyertakan rentang IP subnet bidang kontrol atau node pool.

  • Rentang IP Pod dan Layanan harus berada dalam salah satu rentang IP pribadi berikut:

    • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 — Alamat IP pribadi (RFC 1918)
    • 100.64.0.0/10 — Ruang alamat bersama (RFC 6598)
    • 192.0.0.0/24 — Penetapan protokol IETF (RFC 6890)
    • 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 — Dokumentasi (RFC 5737)
    • 192.88.99.0/24 — Relai IPv6 ke IPv4 (tidak digunakan lagi) (RFC 7526)
    • 198.18.0.0/15 — Pengujian benchmark (RFC 2544)

Sebaiknya gunakan rentang IP dalam 100.64.0.0/10 (RFC 6598). Rentang ini dicadangkan untuk NAT tingkat operator, yang kemungkinan tidak digunakan di VPC Anda.

Misalnya, berikut adalah konfigurasi yang valid saat jaringan Pod, Layanan, dan Node tidak tumpang tindih (VPC menggunakan alamat IP pribadi RFC 1918, sedangkan jaringan Pod dan Layanan di-overlay ke IP pribadi RFC 6598).

  • Jaringan VPC: 10.0.0.0/16, 172.16.1.0/24, 172.16.2.0/24
  • Jaringan Pod: 100.65.0.0/16
  • Jaringan Layanan: 100.66.0.0/16

Berikut ini juga merupakan konfigurasi yang valid meskipun jaringan Pod dan Layanan tumpang tindih dengan jaringan VPC karena tidak ada tumpang tindih dengan replika bidang kontrol.

  • Jaringan VPC: 10.0.0.0/16
  • Jaringan Pod: 10.0.1.0/24
  • Jaringan Layanan: 10.0.2.0/24
  • Subnet Replika Bidang Kontrol: 10.0.3.0/24, 10.0.4.0/24, 10.0.5.0/24

Konfigurasi berikut tidak valid, karena rentang IP Pod tumpang tindih dengan jaringan bidang kontrol. Tumpang tindih ini dapat mencegah workload berkomunikasi dengan replika bidang kontrol di jaringan VPC:

  • Jaringan VPC: 10.0.0.0/16
  • Jaringan Pod: 10.0.1.0/24
  • Jaringan Layanan: 10.1.0.0/24
  • Subnet Replika Bidang Kontrol: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Detail tentang rentang alamat IP Pod

Kubernetes mengalokasikan alamat ke objek Pod dari rentang alamat IP Pod. Rentang Pod cluster dibagi menjadi rentang yang lebih kecil untuk setiap node. Saat Pod dijadwalkan di node tertentu, Kubernetes akan menetapkan alamat IP Pod dari rentang node.

Untuk menghitung ukuran rentang alamat IP Pod, Anda perlu memperkirakan jumlah node yang diinginkan di cluster dan jumlah Pod yang ingin Anda jalankan di setiap node.

Tabel berikut memberikan rekomendasi ukuran untuk rentang CIDR Pod berdasarkan jumlah node dan Pod yang ingin Anda jalankan.

Tabel rentang alamat IP Pod

Rentang alamat IP Pod Alamat IP Pod maksimum Node maksimum Pod maksimum
/24
Rentang alamat IP Pod terkecil yang memungkinkan		 256 alamat 1 node 110 Pod
/23 512 alamat 2 node 220 Pod
/22 1.024 alamat 4 node 440 Pod
/21 2.048 alamat 8 node 880 Pod
/20 4.096 alamat 16 node 1.760 Pod
/19 8.192 alamat 32 node 3.520 Pod
/18 16.384 alamat 64 node 7.040 Pod
/17 32.768 alamat 128 node 14.080 Pod
/16 65.536 alamat 256 node 28.160 Pod
/15 131.072 alamat 512 node 56.320 Pod
/14 262.144 alamat 1.024 node 112.640 Pod

Detail tentang rentang alamat IP layanan

Kubernetes mengalokasikan alamat IP virtual untuk objek Layanan—misalnya, load balancer dari rentang alamat ini.

Untuk menghitung ukuran rentang alamat IP Layanan, Anda perlu memperkirakan jumlah layanan yang diinginkan di cluster.

Tabel berikut memberikan rekomendasi ukuran untuk rentang CIDR Layanan berdasarkan jumlah Layanan yang ingin Anda jalankan.

Tabel rentang alamat IP Layanan

Rentang alamat IP Layanan Jumlah Layanan maksimum
/27
Rentang alamat IP Layanan terkecil yang memungkinkan		 32 Layanan
/26 64 Layanan
/25 128 Layanan
/24 256 Layanan
/23 512 Layanan
/22 1.024 Layanan
/21 2.048 Layanan
/20 4.096 Layanan
/19 8.192 Layanan
/18 16.384 Layanan
/17 32.768 Layanan
/16
Rentang alamat IP Layanan seluas mungkin		 65.536 Layanan

Memilih project host Fleet

Fleet adalah Google Cloud konsep untuk mengatur cluster ke dalam grup yang lebih besar. Dengan fleet, Anda dapat mengelola beberapa cluster di beberapa cloud dan menerapkan kebijakan yang konsisten di seluruh cluster tersebut. GKE Multi-Cloud API secara otomatis mendaftarkan cluster Anda ke Fleet saat cluster dibuat.

Saat membuat cluster, Anda menentukan project host Fleet tempat cluster akan dikelola. Karena GKE di AWS menggunakan nama cluster sebagai nama keanggotaan Fleet, Anda harus memastikan bahwa nama cluster Anda unik di seluruh Fleet.

Pendaftaran lintas project

Jika ingin menggunakan project Host Fleet selain Google Cloud project tempat cluster berada, Anda harus menerapkan binding kebijakan IAM tambahan ke akun layanan Multi-Cloud Service Agent. Hal ini memungkinkan akun layanan mengelola Fleet dengan Project Host Fleet.

  1. Untuk menambahkan Agen Layanan ke project Anda, jalankan perintah ini:

    gcloud beta services identity create --service=gkemulticloud.googleapis.com \
  --project=CLUSTER_PROJECT_NUMBER

    Ganti CLUSTER_PROJECT_NUMBER dengan Google Cloud nomor project Anda.

  2. Tetapkan binding ini dengan perintah berikut:

    gcloud projects add-iam-policy-binding FLEET_PROJECT_ID \
  --member="serviceAccount:service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com" \
  --role="roles/gkemulticloud.serviceAgent"

    Ganti kode berikut:

    • FLEET_PROJECT_ID: project host Fleet Anda Google Cloud project
    • CLUSTER_PROJECT_NUMBER: nomor Google Cloud project Anda

Nama akun Multi-Cloud Service Agent memiliki format berikut: service-CLUSTER_PROJECT_NUMBER@gcp-sa-gkemulticloud.iam.gserviceaccount.com.

Anda dapat menemukan akun layanan di halaman Google Cloud console Akun layanan. Untuk mengetahui informasi selengkapnya tentang cara menemukan nomor project, lihat Mengidentifikasi project.

Membuat cluster

Gunakan perintah berikut untuk membuat cluster Anda di GKE di AWS. Untuk mengetahui informasi selengkapnya tentang perintah ini, termasuk parameter opsionalnya, lihat halaman referensi gcloud container aws.

gcloud container aws clusters create CLUSTER_NAME \
  --aws-region AWS_REGION \
  --location GOOGLE_CLOUD_LOCATION \
  --cluster-version CLUSTER_VERSION \
  --fleet-project FLEET_PROJECT \
  --vpc-id VPC_ID \
  --subnet-ids CONTROL_PLANE_SUBNET_1,CONTROL_PLANE_SUBNET_2,CONTROL_PLANE_SUBNET_3 \
  --pod-address-cidr-blocks POD_ADDRESS_CIDR_BLOCKS \
  --service-address-cidr-blocks SERVICE_ADDRESS_CIDR_BLOCKS \
  --role-arn API_ROLE_ARN \
  --database-encryption-kms-key-arn DB_KMS_KEY_ARN \
  --admin-users ADMIN_USERS_LIST \
  --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN \
  --iam-instance-profile CONTROL_PLANE_PROFILE \
  --tags "Name=CLUSTER_NAME-cp"

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster yang Anda pilih
  • AWS_REGION: region AWS tempat cluster akan dibuat
  • GOOGLE_CLOUD_LOCATION: nama lokasi tempat cluster ini akan dikelola, seperti yang ditentukan diGoogle Cloud region pengelolaan. Google Cloud
  • CLUSTER_VERSION: versi Kubernetes yang akan diinstal di cluster Anda
  • FLEET_PROJECT: project host Fleet tempat cluster akan didaftarkan. Jika Anda ingin mengelola cluster ini dari project lain,Google Cloud lihat Pendaftaran lintas project.
  • VPC_ID: ID AWS VPC untuk cluster ini
  • CONTROL_PLANE_SUBNET_1, CONTROL_PLANE_SUBNET_2, CONTROL_PLANE_SUBNET_3: ID subnet untuk tiga instance bidang kontrol cluster Anda
  • POD_ADDRESS_CIDR_BLOCKS: rentang alamat CIDR untuk pod cluster Anda
  • SERVICE_ADDRESS_CIDR_BLOCKS: rentang alamat CIDR untuk layanan cluster Anda
  • API_ROLE_ARN: ARN peran GKE Multi-Cloud API
  • CONTROL_PLANE_PROFILE: profil instance IAM yang terkait dengan cluster. Untuk mengetahui detail tentang cara memperbarui profil instance IAM, lihat Memperbarui profil instance IAM AWS.
  • DB_KMS_KEY_ARN: Amazon Resource Name (ARN) dari kunci AWS KMS untuk mengenkripsi secret cluster
  • CONFIG_KMS_KEY_ARN: Amazon Resource Name (ARN) kunci AWS KMS untuk mengenkripsi data pengguna
  • ADMIN_USERS_LIST (opsional): daftar alamat email pengguna yang dipisahkan koma untuk memberikan hak administratif kepada pengguna tersebut—misalnya, "kai@example.com,hao@example.com,kalani@example.com". Nilai defaultnya adalah pengguna yang membuat cluster

Jika ada, parameter --tags akan menerapkan tag AWS yang diberikan ke semua resource AWS yang mendasarinya dan dikelola oleh GKE di AWS. Contoh ini memberi tag pada node bidang kontrol Anda dengan nama cluster tempat node tersebut berada.

Anda tidak akan dapat melakukan SSH ke node bidang kontrol ini kecuali jika Anda menentukan pasangan kunci SSH dengan --ssh-ec2-key-pair flag.

Untuk melihat semua versi Kubernetes yang didukung di lokasi Google Cloud tertentu, jalankan perintah berikut.

gcloud container aws get-server-config --location GCP_LOCATION

Mengotorisasi Cloud Logging / Cloud Monitoring

Agar GKE di AWS dapat membuat dan mengupload log dan metrik sistem ke Google Cloud, GKE di AWS harus diotorisasi.

Untuk mengotorisasi identitas workload Kubernetes gke-system/gke-telemetry-agent untuk menulis log ke Google Cloud Logging, dan metrik ke Google Cloud Monitoring, jalankan perintah ini:

gcloud projects add-iam-policy-binding GOOGLE_PROJECT_ID \
  --member="serviceAccount:GOOGLE_PROJECT_ID.svc.id.goog[gke-system/gke-telemetry-agent]" \
  --role=roles/gkemulticloud.telemetryWriter

Ganti GOOGLE_PROJECT_ID denganproject ID cluster. Google Cloud

Binding IAM ini memberikan akses untuk semua cluster di Google Cloud project project untuk mengupload log dan metrik. Anda hanya perlu menjalankannya setelah membuat cluster pertama untuk project.

Penambahan binding IAM ini akan gagal kecuali jika setidaknya satu cluster telah di buat di project Google Cloud Anda. Hal ini karena kumpulan identitas workload yang dirujuk (GOOGLE_PROJECT_ID.svc.id.goog) tidak disediakan hingga pembuatan cluster.

Langkah berikutnya