Ingress vs Load Balancer


212

Saya cukup bingung tentang peran Ingress dan Load Balancer di Kubernetes.

Sejauh yang saya mengerti Ingress digunakan untuk memetakan lalu lintas masuk dari internet ke layanan yang berjalan di cluster.

Peran load balancer adalah untuk meneruskan lalu lintas ke host. Dalam hal itu, bagaimana perbedaan masuknya dengan penyeimbang beban? Juga apa konsep penyeimbang beban di dalam kubernet dibandingkan dengan Amazon ELB dan ALB?

Jawaban:


183

Load Balancer: Layanan kubernet LoadBalancer adalah layanan yang menunjuk ke penyeimbang beban eksternal yang TIDAK ada di kluster kubernet Anda, tetapi ada di tempat lain. Mereka dapat bekerja dengan pod Anda, dengan asumsi bahwa pod Anda dapat dirutekan secara eksternal. Google dan AWS menyediakan kemampuan ini secara asli. Dalam hal Amazon, peta ini secara langsung dengan ELB dan kubernet ketika berjalan di AWS dapat secara otomatis menyediakan dan mengkonfigurasi turunan ELB untuk setiap layanan LoadBalancer yang digunakan.

Ingress: ingress sebenarnya hanya seperangkat aturan untuk dilewatkan ke controller yang mendengarkannya. Anda dapat menggunakan banyak aturan masuknya, tetapi tidak akan terjadi apa-apa kecuali Anda memiliki pengontrol yang dapat memprosesnya. Layanan LoadBalancer dapat mendengarkan aturan masuknya, jika dikonfigurasi untuk melakukannya.

Anda juga dapat membuat layanan NodePort , yang memiliki IP perutean eksternal di luar cluster, tetapi menunjuk ke pod yang ada di dalam cluster Anda. Ini bisa menjadi Pengontrol Ingress.

Ingress Controller hanyalah sebuah pod yang dikonfigurasi untuk menafsirkan aturan masuknya. Salah satu pengendali masuknya paling populer yang didukung oleh kubernetes adalah nginx. Dalam hal Amazon, ALB dapat digunakan sebagai pengendali masuknya.

Sebagai contoh, ini kontroler nginx mampu menelan aturan masuknya sudah Anda tetapkan dan menerjemahkannya ke file nginx.conf bahwa beban dan dimulai di pod nya.

Misalnya katakanlah Anda mendefinisikan masuknya sebagai berikut:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
   ingress.kubernetes.io/rewrite-target: /
 name: web-ingress
spec:
  rules:
  - host: kubernetes.foo.bar
    http:
      paths:
      - backend:
          serviceName: appsvc
          servicePort: 80
        path: /app

Jika Anda memeriksa pod controller nginx Anda, Anda akan melihat aturan berikut ini didefinisikan dalam /etc/nginx.conf:

server {
    server_name kubernetes.foo.bar;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    location ~* ^/web2\/?(?<baseuri>.*) {
        set $proxy_upstream_name "apps-web2svc-8080";
        port_in_redirect off;

        client_max_body_size                    "1m";

        proxy_set_header Host                   $best_http_host;

        # Pass the extracted client certificate to the backend

        # Allow websocket connections
        proxy_set_header                        Upgrade           $http_upgrade;
        proxy_set_header                        Connection        $connection_upgrade;

        proxy_set_header X-Real-IP              $the_real_ip;
        proxy_set_header X-Forwarded-For        $the_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $best_http_host;
        proxy_set_header X-Forwarded-Port       $pass_port;
        proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
        proxy_set_header X-Original-URI         $request_uri;
        proxy_set_header X-Scheme               $pass_access_scheme;

        # mitigate HTTPoxy Vulnerability
        # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
        proxy_set_header Proxy                  "";

        # Custom headers

        proxy_connect_timeout                   5s;
        proxy_send_timeout                      60s;
        proxy_read_timeout                      60s;

        proxy_redirect                          off;
        proxy_buffering                         off;
        proxy_buffer_size                       "4k";
        proxy_buffers                           4 "4k";

        proxy_http_version                      1.1;

        proxy_cookie_domain                     off;
        proxy_cookie_path                       off;

    rewrite /app/(.*) /$1 break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;

    }

Nginx baru saja membuat aturan untuk merutekan http://kubernetes.foo.bar/appke titik ke layanan appsvcdi cluster Anda.

Berikut ini adalah contoh bagaimana menerapkan cluster kubernetes dengan pengontrol masuk nginx. Semoga ini membantu!


1
Saya mendapatkan perbedaan antara ingress dan ingress controller dan peran masing-masing. Akibatnya, penyeimbang beban juga bertanggung jawab untuk mengarahkan lalu lintas ke pod kubernet saya melalui seperangkat aturan yang ditentukan. Bisakah Anda menjelaskan lebih lanjut tentang bagaimana pengontrol masuknya berbeda dengan penyeimbang beban dalam hal itu? Mungkin contoh di mana penyerap beban maupun penyeimbang beban digunakan akan membantu.
arunkjn

Pengontrol masuknya bukan jenis kubernet resmi, itu hanya penyebaran gambar LB (nginx hanyalah sebuah contoh) yang dapat menginterpretasikan aturan masuknya. Saya percaya kebanyakan orang berasumsi bahwa pengendali masuknya juga merupakan LB internal yang hidup di dalam cluster. Saya belum benar-benar mencoba membuat penyeimbang beban eksternal yang menginterpretasikan aturan masuk. Saya membayangkan itu mungkin, tetapi saya bisa sepenuhnya salah :)
Lindsay Landry

6
Dalam aplikasi saya saat ini, saya telah mengekspos penyebaran nginx sebagai layanan LoadBalancer di GKE dan melakukan reverse-proxy dari nginx ke semua layanan lain yang berjalan dalam cluster. Haruskah saya menggunakan ingress daripada pendekatan di atas?
rigal

hai @rigal di proxy nginx Anda bagaimana aturan proxy terlihat? Apakah mereka diselesaikan oleh kube-dns?
arunkjn

@arunkjn ya. Aturannya terlihat seperti ini: location / api / url / {proxy_pass service-name: 80 / api / url ; }
rigal

59

Saya menemukan artikel yang sangat menarik ini yang menjelaskan perbedaan antara NodePort, LoadBalancer dan Ingress.

Dari konten yang ada dalam artikel:

LoadBalancer:

Layanan LoadBalancer adalah cara standar untuk mengekspos layanan ke internet. Pada GKE, ini akan memunculkan Network Load Balancer yang akan memberi Anda satu alamat IP yang akan meneruskan semua lalu lintas ke layanan Anda.

Jika Anda ingin langsung mengekspos layanan, ini adalah metode default. Semua lalu lintas pada port yang Anda tentukan akan diteruskan ke layanan. Tidak ada pemfilteran, tidak ada perutean, dll. Ini berarti Anda dapat mengirim hampir semua jenis lalu lintas ke sana, seperti HTTP, TCP, UDP, Websockets, gRPC, atau apa pun.

Kelemahan besar adalah bahwa setiap layanan yang Anda paparkan dengan LoadBalancer akan mendapatkan alamat IP sendiri, dan Anda harus membayar untuk LoadBalancer per layanan yang terbuka, yang bisa menjadi mahal!

Masuk:

Ingress sebenarnya BUKAN jenis layanan. Sebaliknya, itu duduk di depan beberapa layanan dan bertindak sebagai "router pintar" atau titik masuk ke kluster Anda.

Anda dapat melakukan banyak hal berbeda dengan Ingress, dan ada banyak jenis pengontrol Ingress yang memiliki kemampuan berbeda.

Pengontrol masuk GKE default akan memunculkan Load Balancer HTTP (S) untuk Anda. Ini akan memungkinkan Anda melakukan perutean berbasis path dan subdomain ke layanan backend. Misalnya, Anda dapat mengirim semuanya di foo.domainanda.com ke layanan foo, dan semua yang ada di bawah yourdomain.com/bar/ jalur ke layanan bar.

Ingress mungkin merupakan cara paling ampuh untuk mengekspos layanan Anda, tetapi juga bisa menjadi yang paling rumit. Ada banyak jenis pengontrol Ingress, dari Google Cloud Load Balancer, Nginx, Contour, Istio, dan lainnya. Ada juga plugin untuk pengontrol Ingress, seperti cert-manager, yang dapat secara otomatis menyediakan sertifikat SSL untuk layanan Anda.

Ingress adalah yang paling berguna jika Anda ingin mengekspos beberapa layanan di bawah alamat IP yang sama, dan semua layanan ini menggunakan protokol L7 yang sama (biasanya HTTP). Anda hanya membayar untuk satu penyeimbang beban jika Anda menggunakan integrasi asli GCP, dan karena Ingress adalah "pintar" Anda bisa mendapatkan banyak fitur di luar kotak (seperti SSL, Auth, Routing, dll)


2
Harap pastikan untuk tidak melanggar hak cipta siapa pun saat mengutip beberapa paragraf kata demi kata. Saya bukan ahli dalam hal ini, kasus ini mungkin baik-baik saja, tapi itu pasti sesuatu yang harus diperhatikan.
anothernode

14

TL: DR

  1. Ingress berada di antara jaringan publik (Internet) dan layanan Kubernetes yang secara publik memaparkan implementasi Api kami.
  2. Ingress mampu menyediakan Load Balancing, terminasi SSL, dan hosting virtual berbasis nama.
  3. Kemampuan Ingress memungkinkan untuk mengekspos beberapa API atau Aplikasi dengan aman dari satu nama domain.

Mari kita mulai dengan kasus penggunaan praktis: Anda memiliki beberapa Apis yang didukung oleh paket implementasi layanan (ASIP untuk jelas dan singkat) untuk digunakan di bawah satu nama domain tunggal. Karena Anda adalah pengembang yang mutakhir, Anda menerapkan arsitektur layanan mikro yang membutuhkan penyebaran terpisah untuk setiap ASIP sehingga dapat ditingkatkan atau ditingkatkan secara individual. Tentu saja, ASIP ini dikemas dalam wadah buruh pelabuhan individual dan tersedia untuk Kubernetes (K8s) dari repositori wadah.

Katakanlah sekarang bahwa Anda ingin menggunakan ini di Google K8 GKE. Untuk mengimplementasikan ketersediaan berkelanjutan, setiap instance ASIP (replika) digunakan pada node yang berbeda (VM) di mana setiap VM memiliki alamat IP internal cloud sendiri. Setiap penyebaran ASIP dikonfigurasikan dalam file "deployment.yaml" dengan nama yang tepat di mana Anda menentukan secara deklaratif, di antara hal-hal lain, jumlah replika AS8 K8 yang harus digunakan.

Langkah selanjutnya adalah mengekspos API ke dunia ouside dan permintaan saluran ke salah satu instance ASIP yang digunakan. Karena kami memiliki banyak replika dari ASIP yang sama berjalan pada node yang berbeda, kami membutuhkan sesuatu yang akan mendistribusikan permintaan di antara replika itu. Untuk mengatasi ini, kita dapat membuat dan menerapkan file "service.yaml" yang akan mengonfigurasi layanan K8 (KServ) yang akan diekspos secara eksternal dan dapat diakses melalui alamat IP. KServ ini akan bertanggung jawab atas distribusi permintaan API di antara ASIP yang dikonfigurasi. Perhatikan bahwa KServ akan secara otomatis dikonfigurasi ulang oleh master K8 ketika node ASIP gagal dan di-restart. Alamat IP internal tidak pernah digunakan kembali dalam kasus seperti itu dan KServ harus diberitahukan tentang lokasi penempatan ASIP yang baru.

Tetapi kami memiliki paket layanan Api lain yang akan diekspos dengan nama domain yang sama. Memutar KServ baru akan membuat alamat IP eksternal baru dan kami tidak akan dapat mengeksposnya dengan nama domain yang sama. Nah, di sinilah Ingress masuk.

Ingress duduk di antara Internet dan semua layanan KS yang kami paparkan ke dunia luar. Ingress mampu menyediakan penyeimbangan muatan, penghentian SSL, dan hosting virtual berbasis nama. Kapasitas yang terakhir mampu merutekan permintaan masuk ke layanan yang tepat dengan menganalisis URL-nya. Tentu saja, Ingress harus dikonfigurasi dan diterapkan dengan ... "ingress.yaml" file yang akan menentukan penulisan ulang dan rute yang diperlukan untuk mengirim permintaan ke KServ yang tepat.

Internet -> Masuk -> Layanan K8 -> Replika

Jadi, dengan masuknya yang tepat, konfigurasi KServices dan ASIPs, kami dapat dengan aman mengekspos banyak API menggunakan nama domain yang sama.


9
internet -> loadbalancer -> ingress controller -> aturan ingress -> k8s-services -> Replika
c4f4t0r


@ofjake, apa yang ingin saya katakan?
c4f4t0r

9

Ada 4 cara untuk memungkinkan pod di cluster Anda menerima lalu lintas eksternal:
1.) Pod menggunakan HostNetworking: true dan (Memungkinkan 1 pod per node untuk mendengarkan langsung ke port pada node host. Minikube, bare metal, dan rasberry pi kadang-kadang pergi rute ini yang dapat memungkinkan simpul host untuk mendengarkan pada port 80/443 memungkinkan tidak menggunakan penyeimbang beban atau konfigurasi penyeimbang beban awan lanjutan, juga memotong Layanan Kubernet yang dapat berguna untuk menghindari SNAT / mencapai efek yang serupa dari externalTrafficPolicy: Lokal dalam skenario di mana itu tidak didukung seperti pada AWS.)
2.) Layanan NodePort
3.) Layanan LoadBalancer (Yang dibangun di atas Layanan NodePort)
4.) Pengontrol Ingress + Objek Ingress (Yang dibangun di atas)

Katakanlah Anda memiliki 10 situs web yang di-host di cluster Anda dan Anda ingin mengekspos mereka semua ke lalu lintas eksternal.
* Jika Anda menggunakan layanan LoadBalancer jenis Anda akan menelurkan 10 penyeimbang beban Cloud Cloud (setiap biaya uang)
* Jika Anda menggunakan jenis Ingress Controller Anda akan menelurkan 1 penyeimbang beban Cloud HA (menghemat uang), dan itu akan mengarah ke Ingress Pengontrol berjalan di cluster Anda.

Pengendali Ingress adalah:

  • Layanan tipe Load Balancer yang didukung oleh penyebaran pod yang berjalan di cluster Anda.
  • Setiap pod melakukan 2 hal:
    1. Bertindak sebagai Layer 7 Load Balancer yang berjalan di dalam cluster Anda. (Hadir dalam banyak rasa, Nginx populer)
    2. Mengkonfigurasi sendiri secara dinamis berdasarkan Objek Ingress di kluster Anda
      (Objek Ingress dapat dianggap sebagai potongan konfigurasi deklaratif dari Layer 7 Load Balancer.)

L7 LB / Ingress Controller di dalam cluster Anda Load Balance / membalikkan lalu lintas proksi ke Layanan IP Cluster di dalam Cluster Anda, itu juga dapat menghentikan HTTPS jika Anda memiliki Kubernetes Secret of type TLS cert, dan objek Ingress yang mereferensikannya.)

masukkan deskripsi gambar di sini


1
Jika ada yang mencari jawaban mendalam, saya menulis seri mendalam tentang Ingress oteemo.com/2019/10/28/…
neokyle

apa yang akan menjadi perbedaan antara metallb dan pengendali masuknya?
ImranRazaKhan

1
Gagasan dari ingress controller adalah itu adalah pod L7 LB yang berjalan di jaringan inner cluster Anda. Dan biasanya terpapar ke LAN melalui LB yang ada di Jaringan LAN. MetalLB adalah perangkat lunak yang dapat Anda instal pada Kube Nodes yang dapat memberikan ilusi menjadi LAN yang menghadap alamat IP virtual / VIP yang dapat dijangkau pada LAN, untuk memenuhi peran LB yang ada pada LAN.
neokyle

6

Ingress: Ingress Object + Ingress Controller

Objek Ingress:

Sama seperti Obyek Layanan, kecuali ia tidak melakukan apa pun dengan sendirinya. Objek Ingress hanya menjelaskan cara untuk merutekan lalu lintas Layer 7 ke cluster Anda, dengan menentukan hal-hal seperti jalur permintaan, domain permintaan, dan layanan target kubernetes, sementara objek layanan sebenarnya menciptakan layanan

Pengontrol Ingress:

Layanan yang:

  1. listens on specific ports (usually 80 and 443) for web traffic
  2. Listens for the creation, modification, or deletion of Ingress Objects
  3. Creates internal L7 routing rules based on these Ingress Objects

Sebagai contoh, Nginx Ingress Controller, dapat menggunakan layanan untuk mendengarkan pada port 80 dan 443 dan kemudian membaca Objek Ingress baru dan mem-parsingnya ke bagian server {} baru yang secara dinamis ditempatkan di nginx.conf

LoadBalancer: Penyedia Penyeimbang Beban Eksternal + Jenis Layanan

Penyedia Penyeimbang Beban Eksternal:

Penyedia Penyeimbang Beban Eksternal biasanya dikonfigurasikan dalam cloud seperti AWS dan GKE dan menyediakan cara untuk menetapkan IP eksternal melalui penciptaan penyeimbang beban eksternal. Fungsionalitas ini dapat digunakan dengan menunjuk suatu layanan sebagai tipe "LoadBalancer".

Jenis Layanan:

Ketika jenis layanan diatur ke LoadBalancer, Kubernetes mencoba membuat dan kemudian memprogram penyeimbang beban eksternal dengan entri untuk pod Kubernetes, dengan demikian menetapkan mereka IP eksternal.

Pengontrol layanan Kubernetes mengotomatiskan penciptaan penyeimbang beban eksternal, pemeriksaan kesehatan (jika perlu), aturan firewall (jika perlu) dan mengambil IP eksternal LoadBalancer yang baru dibuat atau dikonfigurasi yang dialokasikan oleh penyedia cloud dan mengisinya dalam objek layanan.

Hubungan:

Layanan Pengontrol Ingress sering ditetapkan sebagai tipe LoadBalancer, sehingga permintaan http dan https dapat diproksikan / dialihkan ke layanan internal tertentu melalui ip eksternal.

Namun, LoadBalancer tidak sepenuhnya diperlukan untuk ini. Karena, melalui penggunaan hostNetwork atau hostPort, Anda secara teknis dapat mengikat port pada host ke layanan (memungkinkan Anda untuk mengunjunginya melalui host eksternal ip: port). Meskipun secara resmi ini tidak dianjurkan karena menggunakan port pada node yang sebenarnya.

Referensi:

https://kubernetes.io/docs/concepts/configuration/overview/#services

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#external-load-balancer-providers

https://kubernetes.io/docs/concepts/services-networking/ingress/


3

Dengan kata sederhana, penyeimbang beban mendistribusikan permintaan di antara beberapa layanan backend (dari jenis yang sama) sedangkan masuknya lebih seperti gateway API (proxy terbalik) yang merutekan permintaan ke layanan backend tertentu berdasarkan, misalnya, URL.


Untuk mengikuti jawaban Anda, dalam kasus di mana keseimbangan beban dan pengontrol masuknya terpisah, pengontrol masuk dalam setiap kasus berada di belakang penyeimbang beban.
AQuirky
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.