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 terkelola sepenuhnya, Google Cloud 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.

Pada tingkat tinggi, strategi migrasi melibatkan fase berikut:

Mengonfigurasi load balancer baru.
Menentukan aturan untuk menangani traffic masuk.
Men-deploy konfigurasi baru dan menguji aliran traffic ke alamat IP Gateway baru.
Mengalihkan traffic produksi ke Gateway API.
Membersihkan resource Ingress yang tersisa.

Mengonfigurasi load balancer baru

Pada fase ini, Anda men-deploy resource Gateway Kubernetes untuk menyeimbangkan traffic ke cluster GKE. Saat Anda men-deploy resource Gateway, GKE akan mengonfigurasi Load Balancer Aplikasi Lapisan 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 menerjemahkan manifes Ingress ke dalam resource HTTPRoute. Untuk mengonversi manifes Ingress, ikuti langkah-langkah di 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 secara langsung sesuai dengan aturan pemilihan rute yang ditentukan dalam manifes Ingress asli.

Men-deploy dan menguji konfigurasi baru

Pada fase ini, Anda 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 ini mengonfirmasi bahwa alamat IP Gateway baru merutekan traffic dengan benar untuk cafe.example.com 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 yang tepat 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 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 langsung terjadi untuk semua klien. Resolver DNS yang memiliki cache data sebelumnya akan menunggu hingga nilai waktu aktif (TTL) data berakhir sebelum mereka membuat kueri untuk data tersebut 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 memverifikasi hal ini 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 pemilihan rute DNS dan health check.

Membersihkan resource Ingress yang tersisa

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

Hapus resource Ingress:
```
kubectl delete ingress cafe-ingress
```
Uninstal 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 paling umum seperti pemilihan rute, header, dan pemisahan traffic.

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

Fitur	Anotasi di Ingress	Anotasi di GKE Gateway	Paritas
Perutean berbasis host	`spec.rules.host` di objek Ingress.	`hostnames` di objek HTTPRoute.	Paritas penuh.
Perutean berbasis jalur	`spec.rules.http.paths` di objek Ingress.	`rules.matches.path` di objek HTTPRoute.	Paritas penuh.
Pemisahan traffic	Anotasi `nginx.ingress.kubernetes.io/canary` .	`HTTPRoute` dengan `backendRefs` berbobot.	Paritas penuh. Selain itu, Anda dapat memisahkan traffic dengan kontrol yang mendetail.
CORS (Cross-Origin Resource Sharing)	`nginx.ingress.kubernetes.io/enable-cors`	`HTTPRoute` dengan filter `CORS`.	Paritas penuh. Catatan: GKE Gateway memberlakukan batasan pada jumlah pola karakter pengganti yang dapat Anda tentukan per listener atau nama host
Penulisan ulang URL	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` dengan filter `urlRewrite`.	Paritas sebagian. GKE Gateway hanya mendukung penggantian awalan.
Rekayasa 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): CRD `BackendPolicy`. Lainnya: Memerlukan pendekatan yang lebih kustom, mungkin dengan mesh layanan atau filter kustom.	Paritas sebagian. Identity-Aware Proxy adalah cara yang direkomendasikan untuk mengamankan Gateway Anda dan dikonfigurasi di backend.

Langkah berikutnya

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