Membuat cluster VPC native

Autopilot Standard

---

Halaman ini menjelaskan cara mengonfigurasi cluster VPC native di Google Kubernetes Engine (GKE).

Untuk mempelajari lebih lanjut manfaat dan persyaratan cluster VPC native, lihat ringkasan untuk Cluster VPC native.

Catatan: Untuk cluster GKE Autopilot, jaringan VPC native diaktifkan secara default dan tidak dapat diganti.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

• Aktifkan Google Kubernetes Engine API.
Aktifkan Google Kubernetes Engine API
• Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu initialize gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.
  Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region dan compute/zone. Dengan menetapkan lokasi default, Anda dapat menghindari error di gcloud CLI seperti berikut: One of [--zone, --region] must be supplied: Please specify location.

Batasan

• Seperti halnya cluster GKE, alamat Layanan (ClusterIP) hanya tersedia dari dalam cluster. Jika Anda perlu mengakses Layanan Kubernetes dari instance VM di luar cluster, tetapi dalam jaringan VPC dan region cluster, buat Network Load Balancer passthrough internal.
• Jika menggunakan semua alamat IP Pod di subnet, Anda tidak dapat mengganti rentang alamat IP sekunder subnet tanpa mengubah cluster ke status tidak stabil. Namun, Anda dapat membuat rentang alamat IP Pod tambahan menggunakan CIDR multi-Pod yang berjauhan.

Membuat cluster di subnet yang ada

Petunjuk berikut menunjukkan cara membuat cluster GKE VPC native di subnet yang ada dengan metode penetapan rentang sekunder pilihan Anda.

gcloud

• Untuk menggunakan metode penetapan rentang sekunder dari yang dikelola oleh GKE:

  gcloud container clusters create CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --enable-ip-alias \
      --subnetwork=SUBNET_NAME \
      --cluster-ipv4-cidr=POD_IP_RANGE \
      --services-ipv4-cidr=SERVICES_IP_RANGE
  

• Untuk menggunakan metode penetapan rentang sekunder dari dikelola oleh pengguna:

  gcloud container clusters create CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --enable-ip-alias \
      --subnetwork=SUBNET_NAME \
      --cluster-secondary-range-name=SECONDARY_RANGE_PODS \
      --services-secondary-range-name=SECONDARY_RANGE_SERVICES
  

Ganti kode berikut:

• CLUSTER_NAME: nama cluster GKE.
• COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.
• SUBNET_NAME: nama subnet yang ada. Rentang alamat IP utama subnet digunakan untuk node. Subnet harus ada di region yang sama dengan yang digunakan oleh cluster. Jika dihilangkan, GKE akan mencoba menggunakan subnet dalam jaringan VPC default di region cluster.
• Jika metode penetapan rentang sekunder dikelola oleh GKE:
  • POD_IP_RANGE: rentang alamat IP dalam notasi CIDR, seperti 10.0.0.0/14, atau ukuran subnet mask blok CIDR, seperti /14. Metode ini digunakan untuk membuat rentang alamat IP sekunder subnet untuk Pod. Jika Anda menghilangkan opsi --cluster-ipv4-cidr, GKE akan memilih rentang /14 (2¹⁸ alamat) secara otomatis. Rentang yang dipilih otomatis akan dipilih secara acak dari 10.0.0.0/8 (rentang 2²⁴ alamat) dan tidak akan menyertakan rentang alamat IP yang dialokasikan untuk VM, rute yang ada, atau rentang yang dialokasikan ke cluster lain. Rentang yang dipilih secara otomatis mungkin bertentangan dengan alamat IP yang direservasi, rute dinamis, atau rute dalam VPC yang di-peering dengan cluster ini. Jika menggunakan salah satu dari hal tersebut, Anda harus menentukan --cluster-ipv4-cidr untuk mencegah konflik.
  • SERVICES_IP_RANGE: rentang alamat IP dalam notasi CIDR (misalnya, 10.4.0.0/19) atau ukuran subnet mask blok CIDR (misalnya, /19). Rentang alamat ini digunakan untuk membuat rentang alamat IP sekunder subnet pada Layanan.
• Jika metode penetapan rentang sekunder dikelola pengguna:
  • SECONDARY_RANGE_PODS: nama rentang alamat IP sekunder yang ada dalam SUBNET_NAME yang ditentukan. GKE menggunakan seluruh rentang alamat IP sekunder subnet untuk Pod cluster.
  • SECONDARY_RANGE_SERVICES: nama rentang alamat IP sekunder yang ada dalam kolom

Konsol

1. Buka halaman Google Kubernetes Engine di konsol Google Cloud.

   Buka Google Kubernetes Engine

2. Klik Buat lalu di bagian Standar atau Autopilot, klik Konfigurasi.

3. Dari panel navigasi, pada Cluster, klik Networking.

4. Di menu drop-down Network, pilih VPC.

5. Di menu drop-down Node subnet, pilih subnet untuk cluster.

6. Pastikan kotak centang Aktifkan perutean traffic VPC-native (menggunakan IP alias) dicentang.

7. Centang kotak Automatically create secondary ranges jika Anda ingin metode penetapan rentang sekunder dikelola oleh GKE. Hapus centang ini jika Anda sudah membuat rentang sekunder untuk subnet yang dipilih dan ingin metode penetapan rentang sekunder dikelola pengguna.

8. Di kolom Pod address range, masukkan rentang pod, seperti 10.0.0.0/14.

9. Di kolom Service address range, masukkan rentang layanan, seperti 10.4.0.0/19.

10. Konfigurasi cluster Anda.

11. Klik Create.

Terraform

Anda dapat membuat cluster native VPC dengan Terraform menggunakan modul Terraform.

Misalnya, Anda dapat menambahkan blok berikut ke konfigurasi Terraform:

module "gke" {
  source  = "terraform-google-modules/kubernetes-engine/google"
  version = "~> 12.0"

  project_id        = "PROJECT_ID"
  name              = "CLUSTER_NAME"
  region            = "COMPUTE_LOCATION"
  network           = "NETWORK_NAME"
  subnetwork        = "SUBNET_NAME"
  ip_range_pods     = "SECONDARY_RANGE_PODS"
  ip_range_services = "SECONDARY_RANGE_SERVICES"
}

Ganti kode berikut:

• PROJECT_ID: project ID Anda.
• CLUSTER_NAME: nama cluster GKE.
• COMPUTE_LOCATION: lokasi Compute Engine untuk cluster. Untuk Terraform, region Compute Engine.
• NETWORK_NAME: nama jaringan yang ada.
• SUBNET_NAME: nama subnet yang ada. Rentang alamat IP utama subnet digunakan untuk beberapa node. Subnet harus ada di region yang sama dengan yang digunakan oleh cluster.
• SECONDARY_RANGE_PODS: nama rentang alamat IP sekunder yang ada dalam kolom
• SECONDARY_RANGE_SERVICES: nama rentang alamat IP sekunder yang ada dalam kolom

API

Saat membuat cluster VPC native, tentukan objek IPAllocationPolicy. Anda dapat mereferensikan rentang alamat IP sekunder subnet yang ada atau menentukan blok CIDR. Referensikan rentang alamat IP sekunder subnet yang ada untuk membuat cluster yang metode penetapan rentang sekundernya dikelola pengguna. Sediakan blok CIDR jika Anda ingin metode penetapan rentang dikelola oleh GKE.

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "clusterIpv4CidrBlock"      : string,
    "servicesIpv4CidrBlock"     : string,
    "clusterSecondaryRangeName" : string,
    "servicesSecondaryRangeName": string,

  },
  ...
}

Perintah ini mencakup nilai-nilai berikut:

• "clusterIpv4CidrBlock": rentang CIDR untuk Pod. Parameter ini menentukan ukuran rentang sekunder untuk Pod, dan dapat berupa notasi CIDR, seperti 10.0.0.0/14. Ruang kosong dengan ukuran tertentu dipilih dari ruang yang tersedia di VPC Anda. Jika dibiarkan kosong, rentang yang valid akan ditemukan dan dibuat dengan ukuran default.
• "servicesIpv4CidrBlock": rentang CIDR untuk Layanan. Lihat deskripsi "clusterIpv4CidrBlock".
• "clusterSecondaryRangeName": nama rentang sekunder untuk Pod. Rentang sekunder harus sudah ada dan termasuk dalam subnetwork yang terkait dengan cluster.
• "serviceSecondaryRangeName": nama rentang sekunder untuk Layanan. Rentang sekunder harus sudah ada dan termasuk dalam subnetwork yang terkait dengan cluster.

Buat cluster dan pilih rentang alamat IP bidang kontrol

Secara default, cluster dengan Private Service Connect menggunakan rentang subnet utama untuk menyediakan alamat IP internal yang ditetapkan ke endpoint bidang kontrol. Anda dapat mengganti setelan default ini dengan memilih rentang subnet lain selama waktu pembuatan cluster saja. Bagian berikut menunjukkan cara membuat cluster dengan Private Service Connect dan mengganti rentang subnet.

gcloud

Buat cluster dengan Private Service Connect yang ditetapkan sebagai public

gcloud container clusters create CLUSTER_NAME \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --location=COMPUTE_LOCATION

Tambahkan flag --enable-private-nodes untuk membuat cluster Private Service Connect sebagai private.

Ganti kode berikut:

• CLUSTER_NAME: nama cluster GKE.
• SUBNET_NAME: nama subnet yang ada.
• COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.

GKE membuat cluster dengan Private Service Connect.

Buat cluster yang ditetapkan sebagai pribadi:

Di GKE versi 1.29 dan yang lebih baru, Anda dapat membuat cluster dengan Private Service Connect:

gcloud container clusters create CLUSTER_NAME --enable-ip-alias \
    --enable-private-nodes  \
    --private-endpoint-subnetwork=SUBNET_NAME \
    --region=COMPUTE_REGION

Ganti kode berikut:

• CLUSTER_NAME: nama cluster GKE.
• SUBNET_NAME: nama subnet yang ada. Jika Anda tidak memberikan nilai untuk flag private-endpoint-subnetwork, tetapi menggunakan master-ipv4-cidr, GKE akan membuat subnet baru yang menggunakan nilai yang Anda tentukan dalam master-ipv4-cidr. GKE menggunakan subnet baru untuk menyediakan alamat IP internal untuk bidang kontrol.
• COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.

Konsol

Buat cluster yang ditetapkan sebagai public:

Untuk menetapkan subnet ke bidang kontrol cluster baru, Anda harus menambahkan subnet terlebih dahulu. Selesaikan langkah-langkah berikut:

1. Buka halaman Google Kubernetes Engine di konsol Google Cloud.

   Buka Google Kubernetes Engine

2. Klik Create.

3. Di bagian Standard atau Autopilot, klik Configure.

4. Untuk Name, masukkan nama cluster Anda.

5. Untuk cluster Standard, dari panel navigasi, di bagian Cluster, klik Networking.

6. Di bagian Akses jaringan IPv4, lakukan hal berikut:

   1. Untuk membuat cluster GKE sebagai publik, pilih Cluster publik.
   2. Untuk membuat cluster GKE sebagai pribadi, pilih Cluster pribadi.

   Dalam kedua kasus tersebut, Anda dapat mengubah mode isolasi cluster saat mengedit konfigurasi cluster nanti.

7. Di bagian Opsi jaringan lanjutan, centang kotak Ganti subnet endpoint privat default bidang kontrol.

8. Di daftar Private endpoint subnet, pilih subnet yang Anda buat.

9. Klik Done. Tambahkan jaringan lain yang diizinkan sesuai kebutuhan.

Membuat cluster dan subnet secara bersamaan

Petunjuk berikut menunjukkan cara membuat subnet dan cluster GKE VPC native secara bersamaan. Metode penetapan rentang sekunder dikelola oleh GKE saat Anda melakukan dua langkah ini dengan satu perintah.

Catatan: Jika menggunakan VPC Bersama, Anda tidak dapat membuat cluster dan subnet secara bersamaan. Sebagai gantinya, Admin Jaringan di project host VPC Bersama harus membuat subnet terlebih dahulu. Kemudian, Anda dapat membuat cluster di subnet yang ada dengan metode penetapan rentang sekunder yang dikelola pengguna.

gcloud

Untuk membuat cluster dan subnet VPC native secara bersamaan:

gcloud container clusters create CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --enable-ip-alias \
    --create-subnetwork name=SUBNET_NAME,range=NODE_IP_RANGE \
    --cluster-ipv4-cidr=POD_IP_RANGE \
    --services-ipv4-cidr=SERVICES_IP_RANGE

Ganti kode berikut:

• CLUSTER_NAME: nama cluster GKE.
• COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.
• SUBNET_NAME: nama subnet yang akan dibuat. Region subnet adalah region yang sama dengan cluster (atau region yang berisi cluster zona). Gunakan string kosong (name="") jika Anda ingin GKE membuat nama untuk Anda.
• NODE_IP_RANGE: rentang alamat IP dalam notasi CIDR, seperti 10.5.0.0/20, atau ukuran subnet mask blok CIDR, seperti /20. Rentang alamat IP ini digunakan untuk membuat rentang alamat IP utama subnet untuk node. Jika dihilangkan, GKE akan memilih rentang IP yang tersedia di VPC dengan ukuran /20.
• POD_IP_RANGE: rentang alamat IP dalam notasi CIDR, seperti 10.0.0.0/14, atau ukuran subnet mask blok CIDR, seperti /14. Parameter ini digunakan untuk membuat rentang alamat IP sekunder subnet untuk Pod. Jika dihilangkan, GKE akan menggunakan rentang /14 yang dipilih secara acak yang berisi 2¹⁸ alamat. Rentang yang dipilih secara otomatis akan ditentukan secara acak dari 10.0.0.0/8 (rentang 2²⁴ alamat) dan tidak mencakup rentang alamat IP yang dialokasikan ke VM, rute yang ada, atau rentang yang dialokasikan ke cluster lain. Rentang yang dipilih secara otomatis mungkin bertentangan dengan alamat IP yang dicadangkan, rute dinamis, atau rute dalam VPC yang di-peering dengan cluster ini. Jika menggunakan salah satu rentang ini, Anda harus menentukan --cluster-ipv4-cidr untuk mencegah konflik.
• SERVICES_IP_RANGE: rentang alamat IP dalam notasi CIDR, seperti 10.4.0.0/19, atau ukuran subnet mask blok CIDR, seperti /19. Rentang alamat IP ini digunakan untuk membuat rentang alamat IP sekunder subnet untuk Layanan. Jika dihilangkan, GKE akan menggunakan /20, ukuran rentang alamat IP Layanan default.

Konsol

Anda tidak dapat membuat cluster dan subnet secara bersamaan menggunakan Konsol Google Cloud. Sebagai gantinya, buat subnet terlebih dahulu, lalu buat cluster di subnet yang ada.

API

Untuk membuat cluster VPC native, tentukan objek IPAllocationPolicy dalam resource cluster Anda:

{
  "name": CLUSTER_NAME,
  "description": DESCRIPTION,
  ...
  "ipAllocationPolicy": {
    "useIpAliases": true,
    "createSubnetwork": true,
    "subnetworkName": SUBNET_NAME
  },
  ...
}

Kolom createSubnetwork akan otomatis membuat dan menyediakan subnetwork untuk cluster. Kolom subnetworkName bersifat opsional; jika dibiarkan kosong, nama akan otomatis dipilih untuk subnetwork tersebut.

Catatan: GKE mencoba membersihkan subnetwork yang dibuat saat cluster dihapus. Namun, jika subnetwork sedang digunakan oleh resource lain, GKE tidak akan menghapus subnetwork, dan Anda harus mengelola sendiri masa berlaku subnetwork.

Gunakan rentang alamat IP non-RFC 1918

Cluster GKE dapat menggunakan rentang alamat IP di luar rentang RFC 1918 untuk node, Pod, dan Service. Baca rentang yang valid dalam dokumentasi jaringan VPC untuk mengetahui daftar rentang pribadi non-RFC 1918 yang dapat digunakan sebagai alamat IP internal untuk rentang subnet.

Rentang alamat IP non-RFC 1918 kompatibel dengan cluster pribadi dan cluster non-pribadi.

Rentang pribadi non-RFC 1918 adalah rentang subnet — Anda dapat menggunakannya secara eksklusif atau bersama dengan rentang subnet RFC 1918. Node, Pod, dan Layanan terus menggunakan rentang subnet seperti yang dijelaskan dalam rentang IP untuk cluster VPC native. Jika Anda menggunakan rentang non-RFC 1918, perhatikan hal-hal berikut:

• Rentang subnet, bahkan yang menggunakan rentang non-RFC 1918, harus ditetapkan secara manual atau oleh GKE sebelum node cluster dibuat. Anda tidak dapat beralih ke atau berhenti menggunakan rentang subnet non-RFC 1918, kecuali jika Anda mengganti cluster tersebut.

• Network Load Balancer passthrough internal hanya menggunakan alamat IP dari rentang alamat IP utama subnet. Untuk membuat Network Load Balancer passthrough internal dengan alamat non-RFC 1918, rentang alamat IP utama subnet Anda harus non-RFC 1918.

Tujuan di luar cluster Anda mungkin kesulitan menerima traffic dari rentang pribadi non-RFC 1918. Misalnya, rentang pribadi RFC 1112 (class E) biasanya digunakan sebagai alamat multicast. Jika tujuan di luar cluster Anda tidak dapat memproses paket yang sumbernya adalah alamat IP pribadi di luar rentang RFC 1918, Anda dapat melakukan hal berikut:

• Gunakan rentang RFC 1918 untuk rentang alamat IP utama subnet. Dengan cara ini, node dalam cluster menggunakan alamat RFC 1918.

• Pastikan cluster Anda menjalankan agen penyamaran IP dan tujuan tidak ada dalam daftar nonMasqueradeCIDRs. Dengan cara ini, paket yang dikirim dari Pod akan mengubah sumber (SNAT) menjadi alamat node, yaitu RFC 1918.

Mengaktifkan rentang alamat IP publik yang digunakan secara pribadi

Cluster GKE dapat secara pribadi menggunakan rentang alamat IP publik tertentu sebagai rentang alamat IP subnet internal. Anda dapat menggunakan alamat IP publik apa pun secara pribadi kecuali untuk rentang terbatas tertentu, seperti yang dijelaskan dalam dokumentasi jaringan VPC.

Rentang publik yang digunakan secara pribadi adalah rentang subnet. Anda dapat menggunakannya secara eksklusif atau bersama dengan rentang subnet lain yang menggunakan alamat pribadi. Node, Pod, dan Layanan terus menggunakan rentang subnet seperti yang dijelaskan dalam rentang IP untuk cluster VPC native. Perhatikan hal-hal berikut saat menggunakan kembali alamat IP publik secara pribadi:

• Jika Anda menggunakan rentang alamat IP eksternal sebagai rentang subnet, cluster Anda tidak dapat lagi berkomunikasi dengan sistem di Internet yang menggunakan rentang publik tersebut. Rentang tersebut menjadi rentang alamat IP internal di jaringan VPC cluster.

• Rentang subnet, bahkan yang secara pribadi menggunakan rentang alamat IP publik, harus ditetapkan secara manual atau oleh GKE sebelum node cluster dibuat. Anda tidak dapat beralih atau berhenti menggunakan alamat IP publik yang digunakan secara pribadi, kecuali jika Anda mengganti cluster.

GKE secara default menerapkan SNAT pada node ke tujuan IP publik. Jika Anda telah mengonfigurasi CIDR Pod untuk menggunakan alamat IP eksternal, aturan SNAT akan berlaku untuk traffic Pod-to-Pod. Untuk menghindari hal ini, Anda memiliki 2 opsi:

• Buat cluster dengan flag --disable-default-snat. Untuk mengetahui detail selengkapnya tentang flag ini, baca penyamaran IP di GKE.
• Konfigurasikan configMap ip-masq-agent termasuk dalam daftar nonMasqueradeCIDRs setidaknya CIDR Pod, CIDR Service, dan subnet node.

Menggunakan jaringan stack ganda IPv4/IPv6 untuk membuat cluster stack ganda

Anda dapat membuat cluster dengan jaringan stack ganda IPv4/IPv6 pada subnet stack ganda yang baru atau yang sudah ada.

Bagian ini menunjukkan cara menyelesaikan tugas berikut:

• Buat subnet dual stack (tersedia di cluster Autopilot versi 1.25 atau yang lebih baru, dan Cluster standar versi 1.24 atau yang lebih baru).
• Mengupdate subnet yang ada ke subnet dual stack (tersedia di cluster Autopilot versi 1.25 atau yang lebih baru, dan cluster standar versi 1.24 atau yang lebih baru).
• Buat cluster dengan jaringan dual-stack (tersedia di cluster Autopilot versi 1.25 atau yang lebih baru, dan Cluster standar versi 1.24 atau yang lebih baru). Cluster GKE Autopilot ditetapkan secara default ke cluster dual stack saat Anda menggunakan subnet dual-stack. Setelah pembuatan cluster, Anda dapat memperbarui cluster Autopilot agar hanya menggunakan IPv4.
• Buat cluster dual-stack dan subnet dual-stack secara bersamaan (tersedia di cluster Autopilot versi 1.25 atau yang lebih baru, dan Cluster standar versi 1.24 atau yang lebih baru).

Untuk mempelajari lebih lanjut manfaat dan persyaratan cluster GKE dengan ringkasan jaringan dual-stack, lihat dokumentasi cluster native VPC.

Catatan: Sebelum menyiapkan cluster dual stack, sebaiknya tinjau batasan dan batasan jaringan dual stack.

Membuat subnet stack ganda

Untuk membuat subnet stack ganda, jalankan perintah berikut:

gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --network=NETWORK_NAME \
    --range=PRIMARY_RANGE \
    --region=COMPUTE_REGION

Ganti kode berikut:

• SUBNET_NAME: nama subnet yang Anda pilih.
• ACCESS_TYPE: kemampuan untuk dirutekan ke internet publik. Gunakan INTERNAL untuk cluster pribadi dan EXTERNAL untuk cluster publik. Jika --ipv6-access-type tidak ditentukan, jenis akses default-nya adalah EXTERNAL.
• NETWORK_NAME: nama jaringan yang akan berisi subnet baru. Jaringan ini harus memenuhi kondisi berikut:
  • Jaringan VPC tersebut harus berupa mode kustom. Untuk mengetahui informasi selengkapnya, lihat cara mengalihkan jaringan VPC dari mode otomatis ke mode kustom.
  • Jika Anda mengganti ACCESS_TYPE dengan INTERNAL, jaringan harus menggunakan Unique Local IPv6 Unicast addresses (ULA).
• PRIMARY_RANGE: rentang alamat IP IPv4 utama untuk subnet baru, dalam notasi CIDR. Untuk mengetahui informasi selengkapnya, lihat Rentang subnet.
• COMPUTE_REGION: region komputasi untuk cluster.

Mengupdate subnet yang ada ke subnet stack ganda

Untuk mengupdate subnet yang ada ke subnet stack ganda, jalankan perintah berikut. Mengupdate subnet tidak akan memengaruhi cluster IPv4 yang ada di subnet.

gcloud compute networks subnets update SUBNET_NAME \
    --stack-type=ipv4-ipv6 \
    --ipv6-access-type=ACCESS_TYPE \
    --region=COMPUTE_REGION

Ganti kode berikut:

• SUBNET_NAME: nama subnet.
• ACCESS_TYPE: kemampuan untuk dirutekan ke internet publik. Gunakan INTERNAL untuk cluster pribadi dan EXTERNAL untuk cluster publik. Jika --ipv6-access-type tidak ditentukan, jenis akses default-nya adalah EXTERNAL.
• COMPUTE_REGION: region komputasi untuk cluster.

Membuat cluster dengan jaringan stack ganda

Untuk membuat cluster dengan subnet stack ganda yang ada, Anda dapat menggunakan gcloud CLI atau Konsol Google Cloud:

gcloud

• Untuk cluster Autopilot, jalankan perintah berikut:

    gcloud container clusters create-auto CLUSTER_NAME \
        --location=COMPUTE_LOCATION \
        --network=NETWORK_NAME \
        --subnetwork=SUBNET_NAME
  

  Ganti kode berikut:

  • CLUSTER_NAME: nama cluster Autopilot baru Anda.
  • COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.
  • NETWORK_NAME: nama jaringan VPC yang berisi subnet. Jaringan VPC ini harus berupa jaringan VPC mode kustom. Untuk mengetahui informasi selengkapnya, lihat cara mengalihkan jaringan VPC dari mode otomatis ke mode kustom.

  • SUBNET_NAME: nama subnet stack ganda. Untuk mempelajari lebih lanjut, lihat cara membuat subnet dual-stack.

    Cluster GKE Autopilot ditetapkan secara default ke cluster dual stack saat Anda menggunakan subnet dual-stack. Setelah pembuatan cluster, Anda dapat mengupdate cluster Autopilot menjadi cluster khusus IPv4.

• Untuk cluster Standard, jalankan perintah berikut:

  gcloud container clusters create CLUSTER_NAME \
      --enable-ip-alias \
      --enable-dataplane-v2 \
      --stack-type=ipv4-ipv6 \
      --network=NETWORK_NAME \
      --subnetwork=SUBNET_NAME \
      --location=COMPUTE_LOCATION
  

  Ganti kode berikut:

  • CLUSTER_NAME: nama cluster baru.
  • NETWORK_NAME: nama jaringan VPC yang berisi subnet. Jaringan VPC ini harus berupa jaringan VPC mode kustom yang menggunakan Unique Local IPv6 Unicast Address (ULA). Untuk informasi selengkapnya, lihat cara mengalihkan jaringan VPC dari mode otomatis ke mode kustom.
  • SUBNET_NAME: nama subnet.
  • COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.

Konsol

1. Buka halaman Google Kubernetes Engine di konsol Google Cloud.

   Buka Google Kubernetes Engine

2. Klik Create.

3. Di bagian Standard atau Autopilot, klik Configure.

4. Konfigurasi cluster Anda sesuai kebutuhan.

5. Dari panel navigasi, pada Cluster, klik Networking.

6. Dalam daftar Network, pilih nama jaringan Anda.

7. Dalam daftar Node subnet, pilih nama subnet stack ganda Anda.

8. Untuk cluster Standar, pilih tombol pilihan IPv4 dan IPv6 (dual stack). Opsi ini hanya tersedia jika Anda memilih subnet stack ganda.

   Cluster autopilot ditetapkan secara default ke cluster dual stack saat Anda menggunakan subnet stack ganda.

9. Klik Create.

Membuat cluster stack ganda dan subnet secara bersamaan

Anda dapat membuat subnet dan cluster stack ganda secara bersamaan. GKE membuat subnet IPv6 dan menetapkan rentang utama IPv6 eksternal ke subnet.

• Untuk cluster Autopilot, jalankan perintah berikut:

  gcloud container clusters create-auto CLUSTER_NAME \
      --location=COMPUTE_LOCATION \
      --network=NETWORK_NAME \
      --create-subnetwork name=SUBNET_NAME
  

  Ganti kode berikut:

  • CLUSTER_NAME: nama cluster Autopilot baru Anda.
  • COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.
  • NETWORK_NAME: nama jaringan VPC yang berisi subnet. Jaringan VPC ini harus berupa jaringan VPC mode kustom yang menggunakan Unique Local IPv6 Unicast Address (ULA). Untuk informasi selengkapnya, lihat cara mengalihkan jaringan VPC dari mode otomatis ke mode kustom.
  • SUBNET_NAME: nama subnet baru. GKE dapat membuat subnet berdasarkan kebijakan organisasi Anda:
    • Jika kebijakan organisasi Anda mengizinkan stack ganda, dan jaringan berada dalam mode kustom, GKE akan membuat subnet stack ganda dan menetapkan rentang utama IPv6 eksternal ke subnet.
    • Jika kebijakan organisasi Anda tidak mengizinkan stack ganda, atau jika jaringan berada dalam mode otomatis, GKE akan membuat subnet stack tunggal (IPv4).

• Untuk cluster Standard, jalankan perintah berikut:

  gcloud container clusters create CLUSTER_NAME \
      --enable-ip-alias \
      --stack-type=ipv4-ipv6 \
      --ipv6-access-type=ACCESS_TYPE \
      --network=NETWORK_NAME \
      --create-subnetwork name=SUBNET_NAME,range=PRIMARY_RANGE \
      --location=COMPUTE_LOCATION
  

  Ganti kode berikut:

  • CLUSTER_NAME: nama cluster baru yang Anda pilih.
  • ACCESS_TYPE: routability ke internet publik. Gunakan INTERNAL untuk cluster pribadi dan EXTERNAL untuk cluster publik. Jika --ipv6-access-type tidak ditentukan, jenis akses defaultnya adalah EXTERNAL.
  • NETWORK_NAME: nama jaringan yang akan berisi subnet baru. Jaringan ini harus memenuhi kondisi berikut:
    • Jaringan VPC tersebut harus berupa mode kustom. Untuk informasi selengkapnya, lihat cara mengalihkan jaringan VPC dari mode otomatis ke mode kustom.
    • Jika Anda mengganti ACCESS_TYPE dengan INTERNAL, jaringan harus menggunakan Unique Local IPv6 Unicast Address (ULA).
  • SUBNET_NAME: nama subnet baru yang Anda pilih.
  • PRIMARY_RANGE: rentang alamat IPv4 utama untuk subnet baru, dalam notasi CIDR. Untuk mengetahui informasi selengkapnya, lihat Rentang subnet.
  • COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.

Memperbarui jenis stack di cluster yang ada

Anda dapat mengubah jenis stack cluster yang ada. Sebelum mengubah jenis stack di cluster yang ada, pertimbangkan batasan berikut:

• Perubahan jenis stack didukung di cluster GKE baru yang menjalankan versi 1.25 atau yang lebih baru. Cluster GKE yang telah diupgrade dari versi 1.24 ke versi 1.25 atau 1.26 mungkin mengalami error validasi saat mengaktifkan jaringan dual-stack. Jika terjadi error, hubungi tim dukungan Google Cloud.

• Mengubah jenis stack merupakan operasi yang disruptif karena GKE memulai ulang komponen di bidang kontrol dan node.

• GKE mematuhi masa pemeliharaan yang Anda konfigurasi saat membuat ulang node. Ini berarti bahwa jenis stack cluster tidak akan dapat dioperasikan pada cluster hingga masa pemeliharaan berikutnya terjadi. Jika memilih untuk tidak menunggu, Anda dapat mengupgrade kumpulan node secara manual dengan menyetel flag --cluster-version ke versi GKE yang sama dengan bidang kontrol yang sudah berjalan. Anda harus menggunakan gcloud CLI jika menggunakan solusi ini. Untuk informasi selengkapnya, lihat peringatan untuk masa pemeliharaan.

• Mengubah jenis stack tidak otomatis mengubah kelompok IP Layanan yang ada. Kondisi berikut berlaku:

  • Jika Anda mengubah stack tunggal menjadi stack ganda, Layanan yang ada akan mempertahankan stack tunggal.
  • Jika Anda mengubah stack ganda menjadi stack tunggal, status error akan terjadi pada Layanan yang ada dengan alamat IPv6. Hapus Service dan buat yang baru dengan ipFamilies yang benar. Untuk mempelajari lebih lanjut, lihat contoh cara menyiapkan Deployment.

Untuk mengupdate cluster VPC native yang ada, Anda dapat menggunakan gcloud CLI atau Konsol Google Cloud:

gcloud

Jalankan perintah berikut:

  gcloud container clusters update CLUSTER_NAME \
      --stack-type=STACK_TYPE \
      --location=COMPUTE_LOCATION

Ganti kode berikut:

• CLUSTER_NAME: nama cluster yang ingin Anda perbarui.
• STACK_TYPE: jenis stack. Ganti dengan salah satu nilai berikut:
  • ipv4: untuk mengupdate cluster stack ganda ke cluster khusus IPv4. GKE menggunakan rentang alamat IPv4 utama dari subnet cluster.
  • ipv4-ipv6: untuk mengupdate cluster IPv4 yang ada ke stack ganda. Anda hanya dapat mengubah cluster menjadi dual-stack jika subnet yang mendasarinya mendukung dual-stack. Untuk mempelajari lebih lanjut, lihat Memperbarui subnet yang ada ke subnet dual-stack.
• COMPUTE_LOCATION: lokasi Compute Engine untuk cluster.

Konsol

1. Buka halaman Google Kubernetes Engine di konsol Google Cloud.

   Buka Google Kubernetes Engine

2. Di samping cluster yang ingin diedit, klik Actions, lalu klik Edit.

3. Di bagian Networking, di samping Stack type, klik Edit.

4. Pada dialog Edit stack type, centang kotak untuk jenis stack cluster yang Anda perlukan.

5. Klik Save Changes.

Membuat Layanan stack ganda IPv4/IPv6

Anda dapat membuat Layanan dual-stack IPv4/IPv6 dengan jenis ClusterIP atau NodePort. Cluster GKE baru yang menjalankan versi 1.29 atau yang lebih baru mendukung Layanan dual-stack jenis LoadBalancer. Untuk mempelajari lebih lanjut, lihat Layanan LoadBalancer dual-stack IPv4/IPv6.

Untuk setiap jenis Layanan ini, Anda dapat menentukan kolom ipFamilies dan ipFamilyPolicy sebagai IPv4, IPv6, atau stack ganda. Untuk mempelajari lebih lanjut, lihat Layanan dual-stack IPv4/IPv6.

Memverifikasi jenis stack, Pod, dan rentang alamat IP Layanan

Setelah membuat cluster VPC native, Anda dapat memverifikasi Pod dan rentang Layanannya.

gcloud

Untuk memverifikasi cluster, jalankan perintah berikut:

gcloud container clusters describe CLUSTER_NAME

Outputnya memiliki blok ipAllocationPolicy. Kolom stackType menjelaskan jenis penetapan jaringan. Untuk setiap jenis, Anda dapat melihat informasi jaringan berikut:

• Informasi jaringan IPv4:

  • clusterIpv4Cidr adalah rentang sekunder untuk Pod.
  • servicesIpv4Cidr adalah rentang sekunder untuk Layanan.

• Informasi jaringan IPv6 (jika cluster memiliki jaringan stack ganda):

  • ipv6AccessType: Kemampuan untuk dirutekan ke internet publik. INTERNAL untuk alamat IPv6 pribadi dan EXTERNAL untuk alamat IPv6 publik.
  • subnetIpv6CidrBlock: Rentang alamat IPv6 sekunder untuk subnet baru.
  • servicesIpv6CidrBlock: Rentang alamat yang ditetapkan untuk Layanan IPv6 di cluster dual-stack.

Konsol

Untuk memverifikasi cluster, lakukan langkah-langkah berikut:

1. Buka halaman Google Kubernetes Engine di Konsol Google Cloud.

   Buka Google Kubernetes Engine

2. Dalam daftar cluster, klik nama cluster yang ingin diperiksa.

Rentang sekunder ditampilkan di bagian Networking:

• Rentang alamat pod adalah rentang sekunder untuk Pod
• Rentang alamat layanan adalah rentang sekunder untuk Layanan

Pemecahan masalah

Bagian ini memberikan panduan untuk menyelesaikan masalah terkait cluster native VPC. Anda juga dapat melihat insight penggunaan alamat IP GKE.

Resource jaringan default belum siap

Gejala

Anda akan mendapatkan pesan error yang mirip dengan berikut ini:

projects/[PROJECT_NAME]/regions/XXX/subnetworks/default

Kemungkinan penyebab

Ada operasi paralel di subnet yang sama. Misalnya, cluster VPC native lain sedang dibuat, atau rentang sekunder sedang ditambahkan atau dihapus di subnet.

Resolusi

Coba lagi perintah tersebut.

Nilai tidak valid untuk IPCidrRange.

Gejala

Anda akan mendapatkan pesan error yang mirip dengan berikut ini:

resource.secondaryIpRanges[1].ipCidrRange': 'XXX'. Invalid IPCidrRange: XXX conflicts with existing subnetwork 'default' in region 'XXX'

Kemungkinan penyebab

Cluster VPC native lain sedang dibuat secara bersamaan dan mencoba mengalokasikan rentang yang sama di jaringan VPC yang sama.

Rentang sekunder yang sama ditambahkan ke subnetwork di jaringan VPC yang sama.

Resolusi

Jika error ini ditampilkan saat pembuatan cluster saat tidak ada rentang sekunder yang ditentukan, coba lagi perintah pembuatan cluster.

Ruang alamat IP kosong tidak cukup untuk Pod

Gejala

Cluster macet dalam status penyediaan untuk jangka waktu yang lebih lama.

Pembuatan cluster menampilkan error Grup Instance Terkelola (MIG).

Saat Anda menambahkan satu atau beberapa node ke cluster, error berikut akan muncul:

[IP_SPACE_EXHAUSTED] Instance 'INSTANCE_NAME' creation failed: IP space of 'projects/PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME-SECONDARY_RANGE_NAME' is exhausted.

Kemungkinan penyebab

Ruang yang belum dialokasikan dalam rentang alamat IP Pod tidak cukup besar untuk node yang diminta dalam cluster. Misalnya, jika rentang alamat IP Pod cluster memiliki netmask yang ukurannya /23 (512 alamat), dan Pod maksimum per node adalah 110, Anda tidak dapat membuat lebih dari dua node. Setiap node diberi rentang alamat IP alias dengan netmask yang ukurannya /24.

Solusi

Anda dapat menambahkan rentang IP Pod ke cluster menggunakan CIDR multi-Pod yang berjauhan.

Buat cluster pengganti setelah meninjau serta merencanakan rentang alamat IP utama dan sekunder yang berukuran sesuai. Lihat Rentang IP untuk cluster VPC native dan perencanaan rentang IP.

Buat kumpulan node baru dengan jumlah maksimum Pod per node yang lebih kecil. Jika memungkinkan, migrasikan workload ke node pool tersebut, lalu hapus node pool sebelumnya. Dengan mengurangi jumlah maksimum Pod per node, Anda dapat mendukung lebih banyak node pada rentang alamat IP sekunder tetap untuk Pod. Lihat Rentang alamat IP sekunder subnet untuk Pod dan Rentang yang membatasi node untuk mengetahui detail tentang penghitungan yang terlibat.

Mengonfirmasi apakah SNAT default dinonaktifkan

Gunakan perintah berikut untuk memeriksa status SNAT default:

gcloud container clusters describe CLUSTER_NAME

Ganti CLUSTER_NAME dengan nama cluster Anda.

Outputnya mirip dengan hal berikut ini:

networkConfig:
  disableDefaultSnat: true
  network: ...

Tidak dapat menggunakan --disable-default-snat tanpa --enable-ip-alias

Dengan pesan error ini, dan must disable default sNAT (--disable-default-snat) before using public IP address privately in the cluster, berarti Anda harus secara eksplisit menetapkan flag --disable-default-snat saat membuat cluster karena Anda menggunakan alamat IP publik di cluster pribadi.

Jika Anda melihat pesan error seperti cannot disable default sNAT ..., ini berarti SNAT default tidak dapat dinonaktifkan di cluster Anda. Untuk mengatasi masalah ini, tinjau konfigurasi cluster Anda.

Men-debug Cloud NAT dengan SNAT default dinonaktifkan

Jika Anda memiliki cluster pribadi yang dibuat dengan flag --disable-default-snat dan telah menyiapkan Cloud NAT untuk akses internet, tetapi tidak melihat traffic yang terhubung ke internet dari Pod Anda, pastikan rentang Pod tersebut disertakan dalam konfigurasi Cloud NAT.

Jika ada masalah dengan komunikasi Pod ke Pod, periksa aturan iptables pada node untuk memverifikasi bahwa rentang Pod tidak disamarkan oleh aturan iptables.

Untuk informasi selengkapnya, lihat dokumentasi penyamaran IP GKE.

Jika Anda belum mengonfigurasi agen penyamaran IP untuk cluster, GKE secara otomatis memastikan bahwa komunikasi Pod ke Pod tidak disamarkan. Namun, jika agen penyamaran IP dikonfigurasi, agen tersebut akan menggantikan aturan penyamaran IP default. Pastikan aturan tambahan dikonfigurasi dalam agen penyamaran IP untuk mengabaikan penyamaran rentang Pod.

Komunikasi jaringan cluster stack ganda tidak berfungsi sesuai ekspektasi

Kemungkinan penyebab

Aturan firewall yang dibuat oleh cluster GKE tidak menyertakan alamat IPv6 yang dialokasikan.

Resolusi

Anda dapat memvalidasi aturan firewall dengan mengikuti langkah-langkah berikut:

1. Verifikasi konten aturan firewall:

   gcloud compute firewall-rules describe FIREWALL_RULE_NAME
   

   Ganti FIREWALL_RULE_NAME dengan nama aturan firewall.

   Setiap cluster dual stack membuat aturan firewall yang memungkinkan node dan Pod berkomunikasi satu sama lain. Isi aturan firewall-nya mirip dengan berikut ini:

   allowed:
   - IPProtocol: esp
   - IPProtocol: ah
   - IPProtocol: sctp
   - IPProtocol: tcp
   - IPProtocol: udp
   - IPProtocol: '58'
   creationTimestamp: '2021-08-16T22:20:14.747-07:00'
   description: ''
   direction: INGRESS
   disabled: false
   enableLogging: false
   id: '7326842601032055265'
   kind: compute#firewall
   logConfig:
     enable: false
   name: gke-ipv6-4-3d8e9c78-ipv6-all
   network: https://www.googleapis.com/compute/alpha/projects/my-project/global/networks/alphanet
   priority: 1000
   selfLink: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/gke-ipv6-4-3d8e9c78-ipv6-all
   selfLinkWithId: https://www.googleapis.com/compute/alpha/projects/my-project/global/firewalls/7326842601032055265
   sourceRanges:
   - 2600:1900:4120:fabf::/64
   targetTags:
   - gke-ipv6-4-3d8e9c78-node
   

   Nilai sourceRanges harus sama dengan subnetIpv6CidrBlock. Nilai targetTags harus sama dengan tag di node GKE. Untuk memperbaiki masalah ini, update aturan firewall dengan informasi blok ipAllocationPolicy cluster.

Langkah selanjutnya

• Baca ringkasan jaringan GKE.
• Pelajari load balancing internal.
• Pelajari cara mengonfigurasi jaringan yang diizinkan.
• Pelajari cara membuat kebijakan jaringan cluster.