Membuat cluster

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

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

Sebelum memulai

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

  • AWS VPC tempat cluster akan berjalan.
  • Hingga tiga subnet AWS untuk tiga replika bidang kontrol. Setiap instance harus berada di Zona Ketersediaan AWS yang berbeda.
  • Peran IAM AWS yang diasumsikan GKE di AWS saat mengelola cluster Anda. Tindakan ini memerlukan serangkaian izin IAM tertentu.
  • Kunci CMK simetris KMS untuk enkripsi saat istirahat data (etcd) dan konfigurasi cluster.
  • Profil instance IAM AWS untuk setiap replika bidang kontrol. Tindakan 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 tercakup dalam cluster dikelola oleh GKE di AWS.

Pilih rentang CIDR untuk cluster Anda

Saat membuat cluster di GKE di AWS, Anda perlu memberikan rentang alamat IPv4 yang akan digunakan untuk 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 bagi Anda untuk mengembangkan cluster tanpa masalah.

Bagian berikut memberikan detail selengkapnya.

Detail tentang memilih 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 mencakup rentang IP subnet bidang kontrol atau kumpulan node.

  • Rentang IP Pod dan Service 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 kelas operator, yang kemungkinan tidak digunakan di VPC Anda.

Misalnya, berikut adalah konfigurasi yang valid di mana jaringan Pod, Service, dan Node tidak tumpang-tindih (VPC menggunakan alamat IP pribadi RFC 1918, sedangkan jaringan Pod dan Service 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

Konfigurasi berikut juga valid meskipun jaringan Pod dan Service 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 Control Plane: 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 panel kontrol. Tumpang-tindih ini dapat mencegah beban kerja 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 Control Plane: 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 Pod. Rentang Pod cluster dibagi menjadi rentang yang lebih kecil untuk setiap node. Saat Pod dijadwalkan di node tertentu, Kubernetes menetapkan alamat IP Pod dari rentang node.

Untuk menghitung ukuran rentang alamat IP Pod, Anda perlu memperkirakan jumlah node yang Anda inginkan 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 layanan

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

Untuk menghitung ukuran rentang alamat Service, Anda perlu memperkirakan jumlah layanan yang Anda inginkan di cluster Anda.

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

Tabel rentang alamat layanan

Rentang alamat IP layanan Jumlah Layanan maksimum
/27
Rentang alamat IP Layanan sekecil mungkin		 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

Pilih project host Fleet Anda

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. Dengan demikian, akun layanan dapat 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 nomor project Google Cloud 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: projectGoogle Cloud project host Fleet Anda
    • CLUSTER_PROJECT_NUMBER: nomor project Google Cloud 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 konsol Service account. Untuk mengetahui informasi selengkapnya tentang cara menemukan nomor project Anda, lihat Mengidentifikasi project.

Buat cluster Anda

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 membuat cluster
  • GOOGLE_CLOUD_LOCATION: nama lokasi Google Cloud tempat cluster ini akan dikelola, seperti yang ditentukan dalam Google Cloud wilayah pengelolaan.
  • 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, lihat Pendaftaran lintas project.Google Cloud
  • VPC_ID: ID VPC AWS 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 API Multi-Cloud GKE
  • CONTROL_PLANE_PROFILE: profil instance IAM yang terkait dengan cluster. Untuk mengetahui detail tentang cara mengupdate profil instance IAM, lihat Mengupdate 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) dari kunci AWS KMS untuk mengenkripsi data pengguna
  • ADMIN_USERS_LIST (opsional): daftar alamat email pengguna yang dipisahkan koma untuk diberi hak istimewa administratif - misalnya, "kai@example.com,hao@example.com,kalani@example.com". Secara default, pengguna yang membuat cluster

Jika ada, parameter --tags akan menerapkan tag AWS tertentu ke semua resource AWS pokok yang 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 menjalankan SSH ke node panel kontrol ini kecuali jika Anda menentukan pasangan kunci SSH dengan tanda --ssh-ec2-key-pair.

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

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

Memberi otorisasi Cloud Logging / Cloud Monitoring

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

Untuk memberi otorisasi 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 dengan ID project Google Cloud cluster.

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

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

Langkah berikutnya