Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

Memigrasikan Ingress ke Gateway API

Autopilot Standard

Halaman ini menunjukkan cara memigrasikan pengelolaan traffic di Google Kubernetes Engine (GKE) dari Ingress API ke Gateway API. Gateway API menyediakan solusi Google Cloud terkelola sepenuhnya untuk menangani traffic aplikasi Anda.

Untuk meminimalkan waktu nonaktif dan mengurangi risiko, pendekatan paling efektif untuk bermigrasi ke Gateway API adalah menjalankan konfigurasi Ingress API yang ada dan Gateway API baru secara bersamaan. Metode ini memungkinkan pengujian menyeluruh terhadap konfigurasi Gateway baru di lingkungan aktif tanpa memengaruhi layanan Anda saat ini. Setelah memvalidasi konfigurasi Gateway baru, Anda dapat melakukan pengalihan DNS cepat untuk mengalihkan traffic ke Gateway API, dan membantu memastikan transisi yang lancar dan berisiko rendah.

Secara umum, strategi migrasi mencakup fase berikut:

Konfigurasi load balancer baru.
Tentukan aturan untuk menangani traffic masuk.
Deploy konfigurasi baru dan uji alur traffic ke alamat IP Gateway baru.
Alihkan traffic produksi ke Gateway API.
Bersihkan resource Ingress yang tersisa.

Mengonfigurasi load balancer baru

Pada fase ini, Anda akan men-deploy resource Gateway Kubernetes untuk melakukan load balancing pada traffic ke cluster GKE Anda. Saat Anda men-deploy resource Gateway, GKE mengonfigurasi Load Balancer Aplikasi Layer 7 untuk mengekspos traffic HTTP(S) ke aplikasi yang berjalan di cluster. Anda men-deploy satu resource Gateway untuk setiap cluster atau untuk setiap load balancer yang Anda perlukan.

Dalam contoh berikut, Anda mengonfigurasi Load Balancer Aplikasi eksternal Global. Untuk membuat Gateway, simpan manifes berikut sebagai gateway.yaml:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http-gateway
spec:
  gatewayClassName: gke-l7-global-external-managed # GKE's managed external Application Load Balancer
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same # Only allow HTTPRoutes from the same namespace

Manifes sebelumnya menjelaskan Gateway yang mencakup kolom berikut:

gatewayClassName: gke-l7-global-external-managed: menentukan GatewayClass untuk Gateway ini. Class Gateway ini menggunakan Load Balancer Aplikasi eksternal global.
protocol: HTTP dan port: 80: menentukan bahwa Gateway mengekspos port 80 untuk traffic HTTP.

Menentukan aturan traffic untuk traffic masuk

Resource rute menentukan aturan khusus protokol untuk memetakan traffic dari Gateway ke Layanan backend.

Pada fase ini, Anda akan menerjemahkan manifes Ingress menjadi resource HTTPRoute. Untuk mengonversi manifes Ingress, ikuti langkah-langkah di alat ingress2gateway.

Contoh ini mengasumsikan bahwa Anda memiliki resource Ingress berikut:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: cafe-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: cafe.example.com
    http:
      paths:
      - path: /tea
        pathType: Prefix
        backend:
          service:
            name: tea-svc
            port:
              number: 80
      - path: /coffee
        pathType: Prefix
        backend:
          service:
            name: coffee-svc
            port:
              number: 80

Setelah Anda mengonversi manifes menggunakan alat ingress2gateway, outputnya adalah manifes HTTPRoute yang diterjemahkan.

Simpan manifes contoh berikut sebagai httproute.yaml:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: cafe-route
spec:
  # This route attaches to our new Gateway
  parentRefs:
  - name: external-http-gateway
  # The hostname is the same as before
  hostnames:
  - "cafe.example.com"
  # The routing rules are now more explicit
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /tea
    backendRefs:
    - name: tea-svc
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /coffee
    backendRefs:
    - name: coffee-svc
      port: 80

Perhatikan bahwa kolom rules dalam manifes HTTPRoute berhubungan langsung dengan aturan pemilihan rute yang ditentukan dalam manifes Ingress asli.

Men-deploy dan menguji konfigurasi baru

Pada fase ini, Anda akan menerapkan manifes Gateway dan HTTPRoute yang dibuat pada dua fase sebelumnya dan menguji bahwa traffic mengalir ke alamat IP baru Gateway.

Terapkan manifes Gateway dan HTTPRoute:

kubectl apply -f gateway.yaml
kubectl apply -f httproute.yaml

Dapatkan alamat IP Gateway. Mungkin perlu waktu beberapa menit untuk mengalokasikan alamat IP:
```
kubectl get gateway external-http-gateway -o=jsonpath="{.status.addresses[0].value}" --watch
```
Outputnya adalah alamat IP eksternal Gateway, misalnya, 203.0.113.90.
Uji alamat IP Gateway baru. Gunakan perintah curl berikut untuk mengirim permintaan ke alamat IP dan menentukan nama host cafe.example.com. Contoh:
```
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/tea
curl --resolve cafe.example.com:80:203.0.113.90 http://cafe.example.com/coffee
```
Ganti 203.0.113.90 dengan alamat IP eksternal yang Anda dapatkan dari langkah sebelumnya. Output mengonfirmasi bahwa alamat IP Gateway baru merutekan traffic untuk cafe.example.com dengan benar tanpa melakukan pencarian DNS.

Mengarahkan traffic ke alamat IP Gateway baru

Pada fase ini, Anda mengalihkan traffic aktif dari Ingress sebelumnya ke Gateway baru dengan memperbarui data DNS agar mengarah ke alamat IP Gateway baru. Langkah-langkah persis untuk memperbarui data DNS bervariasi, bergantung pada penyedia DNS Anda.

Misalnya, jika Anda mengonfigurasi cafe.example.com di Ingress, Anda akan menemukan data A untuk cafe.example.com dengan penyedia DNS Anda dan mengubah nilai alamat IP Ingress lama menjadi 203.0.113.90, yang merupakan alamat IP Gateway baru.

Setelah Anda memperbarui data DNS, traffic akan mulai beralih dari Ingress ke Gateway, tetapi pengalihan tidak akan langsung terjadi untuk semua klien. DNS resolver yang telah memiliki data sebelumnya yang di-cache akan menunggu hingga masa berlaku nilai time to live (TTL) data tersebut berakhir sebelum mengkueri data lagi dan menerima alamat IP yang diperbarui. Oleh karena itu, Anda harus terus menjalankan Ingress yang ada dan Gateway baru secara bersamaan hingga Anda memverifikasi bahwa traffic ke Ingress telah berhenti, yang menunjukkan bahwa propagasi DNS telah selesai dan klien tidak lagi diarahkan ke alamat IP lama. Anda dapat memverifikasinya dengan memantau traffic di load balancer atau pengontrol Ingress. Untuk mengetahui informasi selengkapnya, lihat Memeriksa propagasi DNS.

Jika menggunakan Cloud DNS, Anda dapat menggunakan bobot target untuk mengalihkan traffic secara bertahap dari alamat IP lama ke alamat IP baru. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi kebijakan perutean DNS dan health check.

Membersihkan resource Ingress yang tersisa

Setelah mengonfirmasi bahwa Gateway baru Anda berhasil berjalan, bersihkan resource Ingress lama.

Hapus resource Ingress:
```
kubectl delete ingress cafe-ingress
```
Lepaskan pengontrol ingress-nginx. Misalnya, jika Anda menggunakan Helm untuk menginstal pengontrol, jalankan perintah berikut:
```
helm uninstall ingress-nginx -n ingress-nginx
```

Perbandingan fitur antara Ingress NGINX dan GKE Gateway

Gateway API menyediakan cara yang lebih standar untuk mengonfigurasi ingress, dan memiliki paritas fitur untuk fitur yang paling umum seperti pemilihan rute, header, dan pemisahan traffic.

Tabel berikut membandingkan konfigurasi yang digunakan untuk fitur umum di pengontrol Ingress dan Gateway API.

Fitur	Anotasi di Ingress	Konfigurasi di GKE Gateway	Paritas
Pemilihan rute berbasis host	Kolom `spec.rules.host` di objek Ingress.	Kolom `hostnames` di objek HTTPRoute.	Paritas penuh.
Pemilihan rute berbasis jalur	Kolom `spec.rules.http.paths` dalam objek Ingress.	Kolom `rules.matches.path` dalam objek HTTPRoute.	Paritas penuh.
Pemisahan traffic	`nginx.ingress.kubernetes.io/canary` anotasi.	HTTPRoute dengan kolom `backendRefs` berbobot.	Paritas penuh. Selain itu, Anda dapat membagi traffic dengan kontrol yang mendetail.
Afinitas sesi	`nginx.ingress.kubernetes.io/affinity` dan anotasi `nginx.ingress.kubernetes.io/affinity-mode`.	GCPTrafficDistributionPolicy dengan kolom `sessionAffinity`.	Paritas penuh. GKE Gateway mendukung beberapa jenis afinitas sesi, termasuk jenis afinitas berbasis cookie (`HTTP_COOKIE`, `GENERATED_COOKIE`, dan `STRONG_COOKIE_AFFINITY` stateful), afinitas berbasis header (`HEADER_FIELD`), dan afinitas berbasis IP klien (`CLIENT_IP`).
CORS (Cross-Origin Resource Sharing)	`nginx.ingress.kubernetes.io/enable-cors`	HTTPRoute dengan filter `CORS`.	Paritas penuh. Catatan: Gateway GKE memberlakukan batas pada jumlah pola karakter pengganti yang dapat Anda tentukan per pendengar atau nama host
Penulisan ulang URL	`nginx.ingress.kubernetes.io/rewrite-target`	HTTPRoute dengan filter `urlRewrite`.	Paritas parsial. Gateway GKE hanya mendukung penggantian awalan.
Manipulasi header	`nginx.ingress.kubernetes.io/proxy-set-headers` atau `add-headers`	HTTPRoute dengan pengubah `requestHeaderModifier` atau filter `responseHeaderModifier`.	Paritas penuh.
Autentikasi	`nginx.ingress.kubernetes.io/auth-url` untuk autentikasi eksternal.	Identity-Aware Proxy (IAP): Resource kustom GCPBackendPolicy. Lainnya: Memerlukan pendekatan yang lebih kustom, mungkin dengan mesh layanan atau filter kustom.	Paritas parsial. Identity-Aware Proxy adalah cara yang direkomendasikan untuk mengamankan Gateway Anda dan dikonfigurasi di backend.

Langkah berikutnya

Pelajari cara mengamankan Gateway Anda.
Baca cara kerja pengelolaan traffic Gateway.