Halaman ini diterjemahkan oleh Cloud Translation API.

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 untuk menangani traffic aplikasi Anda. Google Cloud

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 melibatkan 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.

Pada contoh berikut, Anda akan 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 secara langsung sesuai 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 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 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 mulai beralih dari Ingress ke Gateway, tetapi peralihan tidak terjadi segera untuk semua klien. Resolver DNS yang memiliki cache data sebelumnya menunggu nilai time to live (TTL) data berakhir sebelum mereka meminta 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 Anda mengonfirmasi bahwa Gateway baru Anda berhasil berjalan, 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 kesamaan fitur untuk sebagian besar fitur 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
Penulisan ulang URL	`nginx.ingress.kubernetes.io/rewrite-target`	`HTTPRoute` dengan filter `urlRewrite`.	Paritas sebagian. 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.
Pemilihan rute berbasis jalur	`spec.rules.http.paths` dalam objek Ingress.	`rules.matches.path` dalam objek HTTPRoute.	Paritas penuh.
Perutean berbasis host	`spec.rules.host` dalam objek Ingress.	`hostnames` dalam objek HTTPRoute.	Paritas penuh.
Pemisahan traffic	`nginx.ingress.kubernetes.io/canary` anotasi.	`HTTPRoute` dengan `backendRefs` berbobot.	Paritas penuh. Selain itu, Anda dapat memisahkan traffic dengan kontrol yang sangat baik.
Autentikasi	`nginx.ingress.kubernetes.io/auth-url` untuk autentikasi eksternal.	Identity-Aware Proxy (IAP): `BackendPolicy` CRD. Lainnya: Memerlukan pendekatan yang lebih khusus, 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 Anda.
Baca cara kerja pengelolaan traffic Gateway.