Menginstal dan mengupgrade gateway

Cloud Service Mesh memberi Anda opsi untuk men-deploy dan mengelola gateway sebagai bagian dari mesh layanan. Gateway menjelaskan load balancer yang beroperasi di tepi mesh yang menerima koneksi HTTP/TCP masuk atau keluar. Gateway adalah proxy Envoy yang memberi Anda kontrol mendetail atas traffic yang masuk dan keluar dari mesh. Gateway terutama digunakan untuk mengelola traffic masuk, tetapi Anda juga dapat mengonfigurasi gateway untuk mengelola jenis traffic lainnya. Contoh:

• Gateway keluar: Gateway keluar memungkinkan Anda mengonfigurasi node keluar khusus untuk traffic yang keluar dari mesh, sehingga Anda dapat membatasi layanan mana yang dapat atau harus mengakses jaringan eksternal, atau untuk mengaktifkan kontrol traffic keluar yang aman guna menambahkan keamanan ke mesh Anda, misalnya.

• Gateway east-west: Proxy untuk traffic east-west guna memungkinkan workload layanan berkomunikasi di seluruh batas cluster dalam mesh multi-primer di jaringan yang berbeda. Secara default, gateway ini akan bersifat publik di Internet.

Halaman ini menjelaskan praktik terbaik untuk men-deploy dan mengupgrade proxy gateway serta contoh mengonfigurasi proxy gateway istio-ingressgateway dan istio-egressgateway Anda sendiri. Hal-hal seperti pemisahan traffic, pengalihan, dan logika coba lagi dapat dilakukan dengan menerapkan konfigurasi Gateway ke proxy gateway. Kemudian, alih-alih menambahkan perutean traffic lapisan aplikasi (L7) ke resource API yang sama, Anda akan mengikat Layanan Virtual ke Gateway. Hal ini memungkinkan Anda mengelola traffic gateway seperti traffic bidang data lainnya di mesh layanan.

Anda dapat men-deploy gateway dengan berbagai cara dan dapat memilih untuk menggunakan lebih dari satu topologi dalam cluster yang sama. Lihat Topologi deployment Gateway dalam dokumentasi Istio untuk mempelajari topologi ini lebih lanjut.

Praktik terbaik untuk men-deploy gateway

Praktik terbaik untuk men-deploy gateway bergantung pada apakah Anda menggunakan bidang data terkelola atau bidang data tidak terkelola.

Praktik terbaik untuk bidang data terkelola

1. Aktifkan bidang data terkelola.
2. Tambahkan label revisi terkelola ke namespace.
3. Deploy dan kelola bidang kontrol dan gateway secara terpisah.
4. Sebagai praktik terbaik keamanan, sebaiknya Anda men-deploy gateway di namespace yang berbeda dari bidang kontrol.
5. Gunakan injeksi sidecar otomatis (injeksi otomatis) untuk memasukkan konfigurasi proxy untuk gateway, mirip dengan cara Anda memasukkan proxy sidecar untuk layanan Anda.

Praktik terbaik ini:

• Memastikan gateway terkelola Anda otomatis diperbarui dengan peningkatan dan update keamanan terbaru.
• Mengalihkan pengelolaan dan pemeliharaan instance gateway ke bidang data terkelola Cloud Service Mesh.

Praktik terbaik untuk bidang data tidak terkelola

1. Deploy dan kelola bidang kontrol dan gateway secara terpisah.
2. Sebagai praktik terbaik keamanan, sebaiknya Anda men-deploy gateway di namespace yang berbeda dari bidang kontrol.
3. Gunakan injeksi sidecar otomatis (injeksi otomatis) untuk memasukkan konfigurasi proxy untuk gateway, mirip dengan cara Anda memasukkan proxy sidecar untuk layanan Anda.

Praktik terbaik ini:

• Memungkinkan administrator namespace mengelola gateway tanpa memerlukan hak istimewa yang ditingkatkan ke seluruh cluster Anda.
• Memungkinkan administrator Anda menggunakan alat atau mekanisme deployment yang sama yang mereka gunakan untuk mengelola aplikasi Kubernetes guna men-deploy dan mengelola gateway.
• Memberikan kontrol penuh kepada administrator atas Deployment gateway, dan juga menyederhanakan operasi. Saat upgrade baru tersedia atau konfigurasi telah berubah, administrator akan mengupdate Pod gateway dengan memulai ulang. Hal ini membuat pengalaman mengoperasikan Deployment gateway sama dengan mengoperasikan proxy sidecar untuk layanan Anda.

Men-deploy gateway

Untuk mendukung pengguna dengan alat deployment yang ada, Cloud Service Mesh mendukung cara yang sama untuk men-deploy gateway seperti Istio: IstioOperator, Helm, dan Kubernetes YAML. Setiap metode menghasilkan hasil yang sama. Meskipun Anda dapat memilih metode yang paling Anda kuasai, sebaiknya gunakan metode Kubernetes YAML karena lebih mudah diubah dan Anda dapat menyimpan manifes yang diisi dalam kontrol sumber.

1. Buat namespace untuk gateway jika Anda belum memilikinya. Ganti GATEWAY_NAMESPACE dengan nama namespace Anda.

   kubectl create namespace GATEWAY_NAMESPACE
   

2. Untuk mengaktifkan injeksi otomatis, Anda akan memberi label pada namespace dengan label injeksi default jika tag default disiapkan, atau dengan label revisi ke namespace Anda. Label yang Anda tambahkan juga bergantung pada apakah Anda men-deploy Cloud Service Mesh terkelola atau menginstal bidang kontrol dalam cluster. Label ini digunakan oleh webhook injector sidecar untuk mengaitkan sidecar yang dimasukkan dengan revisi bidang kontrol tertentu.

   Pilih tab di bawah sesuai dengan jenis penginstalan Anda (terkelola atau dalam cluster).

   Terkelola

   Gunakan perintah berikut untuk menemukan saluran rilis yang tersedia:

   kubectl -n istio-system get controlplanerevision
   

   Outputnya mirip dengan hal berikut ini:

   NAME                AGE
   asm-managed         6d7h
   asm-managed-rapid   6d7h
   

   Dalam output, nilai di kolom NAME adalah label revisi yang sesuai dengan saluran rilis yang tersedia untuk versi Cloud Service Mesh.

   Dalam cluster

   Untuk bidang kontrol dalam cluster, Layanan dan Deployment istiod biasanya memiliki label revisi yang mirip dengan istio.io/rev=asm-11910-9, dengan asm-11910-9 mengidentifikasi versi Cloud Service Mesh. Revisi ini menjadi bagian dari nama Layanan istiod, misalnya: istiod-asm-11910-9.istio-system

   Gunakan perintah berikut untuk menemukan label revisi di istiod untuk bidang kontrol dalam cluster:

   kubectl get deploy -n istio-system -l app=istiod \
     -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
   

3. Aktifkan namespace untuk injeksi. Ganti dan REVISION dengan nilai untuk label revisi.

   Catatan: Anda dapat mengganti istio.io/rev dengan label istio-injection=enabled jika tag default dikonfigurasi. Verifikasi bahwa tag default ada dengan menjalankan istioctl tag list dengan istioctl dari OUTPUT_DIR.

   kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
   

4. Jika Anda menginstal Cloud Service Mesh menggunakan asmcli, ubah ke direktori yang Anda tentukan di --output_dir, lalu cd ke direktori samples.

   Penting: Untuk memastikan Anda berada di direktori samples yang benar, jalankan perintah ls untuk mencantumkan konten direktori dan pastikan ada direktori gateways (yang akan Anda akses pada langkah berikutnya) dan direktori online-boutique.

   Jika Anda tidak menginstal menggunakan asmcli, salin file konfigurasi untuk gateway dari anthos-service-mesh repositori.

5. Anda dapat men-deploy konfigurasi gateway contoh yang terletak di direktori samples/gateways/ apa adanya, atau mengubahnya sesuai kebutuhan.

   Masuk

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
   

   Keluar

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
   

6. Setelah membuat deployment, pastikan layanan baru berfungsi dengan benar:

   kubectl get pod,service -n GATEWAY_NAMESPACE
   

   Pastikan outputnya mirip dengan hal berikut ini:

   NAME                                      READY   STATUS    RESTARTS   AGE
   pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s
   
   NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
   service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

Penting: Resource gateway Anda harus dikelola seperti aplikasi Kubernetes lainnya. Contoh dalam repo anthos-service-mesh-packages dimaksudkan untuk panduan dan panduan memulai cepat, dan Anda harus menyesuaikannya sesuai kebutuhan.

Pemilih gateway

Anda menerapkan konfigurasi Gateway ke proxy dan untuk mengelola traffic masuk dan keluar untuk mesh Anda, sehingga Anda dapat menentukan traffic mana yang ingin Anda masukkan atau keluarkan dari mesh.istio-ingressgatewayistio-egressgateway Label pada Pod deployment gateway digunakan oleh resource konfigurasi Gateway, jadi penting agar pemilih Gateway Anda cocok dengan label ini.

Misalnya, dalam deployment di atas, label istio=ingressgateway ditetapkan pada Pod gateway. Untuk menerapkan konfigurasi Gateway ke deployment ini, Anda harus memilih label yang sama:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

Untuk contoh konfigurasi Gateway dan Layanan Virtual, lihat frontend.yaml di aplikasi contoh Online Boutique.

Mengupgrade gateway

Upgrade langsung

Untuk sebagian besar kasus penggunaan, Anda harus mengupgrade gateway dengan mengikuti pola upgrade langsung. Karena gateway menggunakan injeksi Pod, Pod gateway baru yang dibuat akan otomatis dimasukkan dengan konfigurasi terbaru, yang mencakup versi.

Jika ingin mengubah revisi bidang kontrol yang digunakan oleh gateway, Anda dapat menetapkan label istio.io/rev pada Deployment gateway, yang juga akan memicu memulai ulang bertahap.

Bidang kontrol terkelola

Karena Google mengelola upgrade bidang kontrol untuk bidang kontrol terkelola, Anda cukup memulai ulang Deployment gateway dan pod baru akan otomatis dimasukkan dengan konfigurasi dan versi terbaru.

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

Bidang kontrol dalam cluster

Untuk menerapkan pola yang sama ke gateway saat Anda memiliki bidang kontrol dalam cluster, Anda harus mengubah revisi bidang kontrol yang digunakan oleh gateway. Tetapkan label istio.io/rev pada Deployment gateway yang akan memicu memulai ulang bertahap. Langkah-langkah yang diperlukan bergantung pada apakah Anda perlu mengupdate label revisi di namespace dan/atau pod gateway.

• Jika Anda memberi label pada namespace untuk injeksi, tetapkan label istio.io/rev pada namespace ke nilai revisi baru:

    kubectl label namespace GATEWAY_NAMESPACE \
      istio-injection- istio.io/rev=REVISION \
      --overwrite
  

• Jika Anda hanya mengaktifkan injeksi untuk pod gateway, tetapkan label istio.io/rev pada Deployment ke nilai revisi baru seperti file Kubernetes YAML berikut:

  cat <<EOF > gateway-deployment.yaml
  apiVersion: apps/v1
  kind: Deployment
  metadata:
    name: istio-ingressgateway
    namespace: GATEWAY_NAMESPACE
  spec:
    selector:
      matchLabels:
        istio: ingressgateway
    template:
      metadata:
        annotations:
          # This is required to tell Anthos Service Mesh to inject the gateway with the
          # required configuration.
          inject.istio.io/templates: gateway
        labels:
          istio: ingressgateway
          istio.io/rev: REVISION
      spec:
        containers:
        - name: istio-proxy
          image: auto # The image will automatically update each time the pod starts.
  EOF
  
  kubectl apply -f gateway-deployment.yaml
  

  Catatan: Jika image tidak otomatis diupdate dengan image proxy Cloud Service Mesh yang sebenarnya, container tidak akan ditemukan dan error akan terjadi. Lihat Memecahkan masalah gateway untuk langkah berikutnya.

Upgrade canary (lanjutan)

Jika Anda menggunakan bidang kontrol dalam cluster dan ingin mengontrol peluncuran revisi bidang kontrol baru secara lebih lambat, Anda dapat mengikuti pola upgrade canary. Anda dapat menjalankan beberapa versi Deployment gateway dan memastikan semuanya berfungsi seperti yang diharapkan dengan sebagian traffic Anda. Misalnya, jika Anda ingin meluncurkan revisi baru, canary, buat salinan Deployment gateway dengan label istio.io/rev=REVISION yang ditetapkan ke revisi baru dan nama baru, misalnya istio-ingressgateway-canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

Catatan: Jika image tidak otomatis diupdate dengan image proxy Cloud Service Mesh yang sebenarnya, container tidak akan ditemukan dan error akan terjadi. Lihat Memecahkan masalah gateway untuk langkah berikutnya.

Saat Deployment ini dibuat, Anda akan memiliki dua versi gateway, yang keduanya dipilih oleh Layanan yang sama:

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

Catatan: Tidak seperti layanan aplikasi yang di-deploy di dalam mesh, Anda tidak dapat menggunakan pengalihan traffic Istio untuk mendistribusikan traffic antara versi gateway karena traffic-nya berasal langsung dari klien eksternal yang tidak dikontrol oleh Istio. Sebagai gantinya, Anda dapat mengontrol distribusi traffic berdasarkan jumlah replika setiap Deployment. Jika Anda menggunakan load balancer lain di depan Istio, Anda juga dapat menggunakannya untuk mengontrol distribusi traffic.

Jika Anda yakin bahwa aplikasi Anda berfungsi seperti yang diharapkan, jalankan perintah ini untuk bertransisi ke versi baru dengan menghapus Deployment dengan label istio.io/rev lama yang ditetapkan:

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

Jika Anda mengalami masalah saat menguji aplikasi dengan versi gateway baru, jalankan perintah ini untuk bertransisi kembali ke versi lama dengan menghapus Deployment dengan label istio.io/rev baru yang ditetapkan:

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

Konfigurasi lanjutan

Mengonfigurasi versi TLS minimum gateway

Untuk Cloud Service Mesh versi 1.14 dan yang lebih baru, versi TLS minimum default untuk server gateway adalah 1.2. Anda dapat mengonfigurasi versi TLS minimum menggunakan kolom minProtocolVersion. Untuk mengetahui informasi selengkapnya, lihat ServerTLSSettings.

Memecahkan masalah gateway

Gagal mengupdate image gateway dari auto

Saat Anda men-deploy atau mengupgrade gateway, Cloud Service Mesh akan menyisipkan auto sebagai placeholder di kolom image. Setelah panggilan ke webhook yang berubah, Cloud Service Mesh akan otomatis mengganti placeholder ini dengan image proxy Cloud Service Mesh yang sebenarnya. Jika panggilan ke webhook yang berubah gagal, placeholder auto akan tetap ada, dan container tidak akan ditemukan. Hal ini biasanya disebabkan oleh label namespace yang salah. Pastikan Anda telah mengonfigurasi namespace yang benar, lalu deploy atau upgrade gateway lagi.