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:
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!
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)
TL: DR
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.
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:
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.)
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/concepts/services-networking/ingress/
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.