Lời mở đầu
Kubernetes Ingress không phải là một service Kubernetes. Rất đơn thuần, nó chỉ là một Nginx Pod chuyển hướng nhu yếu đến những service nội bộ ( ClusterIP ) khác. Bản thân hoàn toàn có thể truy vấn trải qua service Kubernetes, thông dụng nhất là LoadBalancer .Bạn đang xem : Ingress là gì
Hãy đọc trước phần 1 tại đây : Kubernetes Service là gì ? Tại sao phải sử dụng Kubernetes – phần 1
Tại sao sử dụng Ingress?
Tại sao ư ? Bạn sử dụng nó để làm cho service nội bộ hoàn toàn có thể truy vấn từ bên ngoài cluster của bạn. Nó tiết kiệm chi phí cho bạn những IP tĩnh quý giá, vì bạn không cần cần phải khai báo nhiều LoadBalancer. Ngoài ra, còn được cho phép thông số kỹ thuật nhiều hơn và thiết lập thuận tiện hơn .
Những điều chúng ta sẽ tìm hiểu
Đầu tiên chúng ta thực hiện một chuyến tham quan ngắn vào máy chủ http, đặc biệt là Nginx, xem chúng hoạt động và những gì chúng làm.Sau đó, chúng ta sẽ thiết lập thủ công Ingress, do đó, không cần sử dụng tài nguyên Ingress Kubernetes nào cả.Tiếp theo, sẽ thấy rằng Ingress Kubernetes không gì khác hơn là một máy chủ Nginx được cấu hình sẵn.Đầu tiên tất cả chúng ta thực thi một chuyến du lịch thăm quan ngắn vào sever http, đặc biệt quan trọng là Nginx, xem chúng hoạt động giải trí và những gì chúng làm. Sau đó, tất cả chúng ta sẽ thiết lập thủ công bằng tay Ingress, do đó, không cần sử dụng tài nguyên Ingress Kubernetes nào cả. Tiếp theo, sẽ thấy rằng Ingress Kubernetes không gì khác hơn là một sever Nginx được thông số kỹ thuật sẵn .Nghe thì khó hiểu, hãy cùng đi qua từng ví dụ để hiểu hơn nào
Tìm hiểu sâu về máy chủ HTTP
Ở đây, tất cả chúng ta lùi lại thời hạn trước khi có container, Kubernetes và quốc tế của tài liệu đám mây ( Cloud ) .
Máy chủ HTTP (Nginx) có thể làm gì?
Nó hoàn toàn có thể nhận được nhu yếu qua giao thức HTTP cho một filepath đơn cử, kiểm tra filepath đó trên mạng lưới hệ thống tệp đính kèm và trả lại nếu tệp đó sống sót :
Trong Nginx, điều này hoàn toàn có thể được triển khai với một cái gì đó như :location / thư mục { root / var / www / ; index index.html ; }
Máy chủ có thể làm thêm những gì ?
Nó có thể nhận được yêu cầu cho filepath cụ thể, chuyển hướng yêu cầu đó đến một máy chủ khác (có nghĩa là nó hoạt động như proxy) và sau đó chuyển hướng phản hồi của máy chủ đó để quay lại máy khách. Đối với máy khách không có gì thay đổi, kết quả nhận được vẫn là tệp được yêu cầu (nếu nó tồn tại).
Nó hoàn toàn có thể nhận được nhu yếu cho filepath đơn cử, chuyển hướng nhu yếu đó đến một sever khác ( có nghĩa là nó hoạt động giải trí như proxy ) và sau đó chuyển hướng phản hồi của sever đó để quay lại máy khách. Đối với máy khách không có gì đổi khác, hiệu quả nhận được vẫn là tệp được nhu yếu ( nếu nó sống sót ) .Chúng ta không đi sâu vào yếu tố này nhưng với Nginx, chuyển hướng proxy hoàn toàn có thể được định thông số kỹ thuật như sau :location / thư mục { proxy_pass http://second-nginx-server:8000 ; } Điều này có nghĩa là Nginx hoàn toàn có thể ship hàng những tệp từ mạng lưới hệ thống tệp hoặc chuyển hướng phản hồi đến những sever khác và trả lại phản hồi của họ, bằng cách đóng vai trò là proxy .
Ví dụ đơn giản Kubernetes:
Sử dụng service ClusterIP
Một lần nữa, từ thời gian này, bạn nên hiểu service Kubernetes. Chúng ta có hai node, tất cả chúng ta bỏ lỡ những node master ở đây. Và có hai service là service-nginx và service-python trỏ đến những pod ( nhóm ) khác nhau .Các Services không trên bất kể Node đơn cử nào, giả sử chúng có sẵn ở mọi nơi trong cluster .
Bạn nên hiểu những gì đang xảy ra ở đây. Bên trong cluster ( cụm ), tất cả chúng ta hoàn toàn có thể tiếp cận những pod Nginx và những pod Python trải qua những service của họ. Tiếp theo, tất cả chúng ta cũng muốn phân phối những thứ đó từ bên ngoài cụm. Vì vậy, quy đổi chúng thành những service LoadBalancer .
Sử dụng service LoadBalancer
Bạn hoàn toàn có thể thấy rằng tất cả chúng ta đã quy đổi service ClusterIP thành service LoadBalancer. Bởi vì tất cả chúng ta có cluster Kubernetes tàng trữ với Nhà phân phối đám mây hoàn toàn có thể giải quyết và xử lý việc này ( Gcloud, AWS, DigitalOcean khắc ). Nó tạo ra hai LoadBalancer bên ngoài để chuyển hướng nhu yếu đến những Node IP bên ngoài của chúng, sau đó chuyển hướng đến những service ClusterIP bên trong .
Chúng ta thấy hai LoadBalancer, mỗi loại có IP riêng. Nếu tất cả chúng ta gửi nhu yếu tới LoadBalancer 22.33.44. 55, nó sẽ được chuyển hướng đến nội bộ của service-nginx. Nếu tất cả chúng ta gửi nhu yếu tới 77.66.55. 44, nó sẽ được chuyển hướng đến nội bộ của service – python .Điều này rất tuyệt vời ! Nhưng địa chỉ IP rất hiếm và giá trị LoadBalancer phụ thuộc vào vào nhà cung ứng đám mây. Bây giờ hãy tưởng tượng tất cả chúng ta không chỉ có hai mà nhiều service nội bộ khác muốn tạo LoadBalancer, và ngân sách sẽ tăng lên .Có một giải pháp khác được cho phép tất cả chúng ta sử dụng một LoadBalancer ( với một IP ) nhưng vẫn tiếp cận trực tiếp cả hai service nội bộ ? Hãy để tò mò điều này thứ nhất bằng cách triển khai một cách tiếp cận thủ công bằng tay .
Cấu hình thủ công service Nginx như proxy
Theo mô tả trước đó, Nginx có thể hoạt động như một proxy. Trong hình ảnh dưới đây, chúng ta thấy một service mới gọi là service-nginx-proxy và đó cũng là service LoadBalancer duy nhất của chúng ta. service-nginx-proxy vẫn sẽ trỏ đến một hoặc nhiều điểm cuối Nginx-pod-endpoints. Hai service khác từ trước được chuyển đổi trở lại thành service ClusterIP đơn giản:
Có thể thấy rằng tất cả chúng ta chỉ đạt một LoadBalancer ( 11,22. 33.44 ) nhưng với những url http khác nhau, những nhu yếu được hiển thị màu vàng là cùng một tiềm năng và chỉ chứa nội dung khác nhau ( những url nhu yếu ) .service-nginx-proxy quyết định hành động ( bằng cách sử dụng Nginx proxy và vị trí ), tùy thuộc vào những url được chuyển, service nào chuyển hướng dựa trên nhu yếu .
Trong trường hợp này, chúng ta có hai lựa chọn, đỏ và xanh. Chuyển hướng màu đỏ đến service-nginx trong đó chuyển hướng màu xanh đến service-python..
Xem thêm : Comic Con Là Gì – Ho Chi Minh Comic Con
# very simplified Nginx config examplelocation /folder { proxy_pass http://service-nginx:3001;}location /other { proxy_pass http://service-python:3002;}Hiện tại cần phải định cấu hình service-nginx-proxy theo cách thủ công. Giống như tạo các tệp cấu hình Nginx thích hợp trỏ đến các dịch vụ ClusterIP. Điều này là một giải pháp, rất hiệu quả và phổ biến.
Và chính bới đây là một giải pháp phổ cập, Kubernetes Ingress được tạo ra để giúp thông số kỹ thuật thuận tiện và dễ quản trị hơn .Từ thời gian này, bạn nên hiểu lợi thế của ví dụ được hiển thị trong hình ảnh bên trên .
Sử dụng Ingress Kubernetes
So sánh hình ảnh sau với hình ảnh trước. Thực sự không có nhiều thay đổi. Chúng ta chỉ sử dụng một Nginx được cấu hình sẵn (Ingress Kubernetes ) đã thực hiện tất cả các chuyển hướng proxy, giúp tiết kiệm rất nhiều công việc cấu hình thủ công:
Đó là tổng thể những gì có để hiểu về Ingress Kubernetes. Bây giờ hãy lướt qua 1 số ít thông số kỹ thuật .
Cài đặt Controller Ingress Kubernetes
Ingress Kubernetes là một Tài nguyên Kubernetes bổ trợ được setup thêm như sau :kubectl apply – f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yamlkubectl apply – f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/provider/cloud-generic.yamlSử dụng lệnh sau, bạn sẽ thấy những tài nguyên k8s được thiết lập với namespace : ingress-nginx :kubectl get svc, pod — namespace = ingress-nginx
kubectl exec vào pod đó để xem nó chứa máy chủ Nginx được cấu hình sẵn:
Bạn thấy service LoadBalancer rất thông thường với IP bên ngoài và pod. Bạn thậm chí còn hoàn toàn có thể chạy câu lệnhvào pod đó để xem nó chứa sever Nginx được thông số kỹ thuật sẵn :Trong nginx.conf bạn sẽ thấy những thiết lập chuyển hướng proxy khác nhau và thông số kỹ thuật tương quan khác .
Ví dụ Config Ingress Kubernetes
Một ví dụ về Ingress Kubernetes và yaml sử dụng trông như thế này :# just example, not testedapiVersion : networking.k8s.io/v1beta1kind : Ingressmetadata : annotations : kubernetes.io/ingress.class : nginx namespace : default name : test-ingressspec : rules : – http : paths : – path : / thư mục backend : serviceName : service-nginx servicePort : 3001 – http : paths : – path : / other backend : serviceName : service-python servicePort : 3002C húng ta sẽ cần tạo yaml trải qua câu lệnh kubectl create – f ingress.yaml. Yaml này sau đó sẽ được quy đổi bởi Controller Ingress được thiết lập trước đó thành thông số kỹ thuật Nginx .
Ví dụ Ingress Kubernetes về khác Namespaces
Bây giờ nếu một trong những service nội bộ của bạn, mà Ingress nên chuyển hướng đến, mà ở namespace khác thì sao ? Trong thông số kỹ thuật Ingress, bạn chỉ hoàn toàn có thể chuyển hướng đến những service trong cùng một namespace .Nếu bạn xác lập nhiều thông số kỹ thuật yaml Ingress, thì những thông số kỹ thuật đó được hợp nhất với nhau thành một thông số kỹ thuật Nginx bởi một Controller Ingress duy nhất. Có nghĩa : toàn bộ đều đang sử dụng cùng một IP LoadBalancer .Vì vậy, hãy xem service-nginx với namespace : default. yaml sẽ như này
# just example, not testedapiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata: annotations: kubernetes.io/ingress.class: nginx namespace: default name: ingress1spec: rules: – http: paths: – path: /folder backend: serviceName: service-nginx servicePort: 3001Và service-python với namespace: namespace2:
# just example, not testedapiVersion : networking.k8s.io/v1beta1kind : Ingressmetadata : annotations : kubernetes.io/ingress.class : nginx namespace : namespace2 name : ingress2spec : rules : – http : paths : – path : / other backend : serviceName : service-python servicePort : 3002
Làm cách nào để tinh chỉnh cấu hình Ingress Nginx?
Bạn có thể làm điều này bằng cách chú thích trên Ingress Kubernetes. Ví dụ: bạn có thể định cấu hình các tùy chọn khác nhau mà bạn thường có thể định cấu hình trực tiếp trong Nginx:Bạn hoàn toàn có thể làm điều này bằng cách chú thích trên Ingress Kubernetes. Ví dụ : bạn hoàn toàn có thể định thông số kỹ thuật những tùy chọn khác nhau mà bạn thường hoàn toàn có thể định thông số kỹ thuật trực tiếp trong Nginx :kind : Ingressmetadata : name : ingress annotations : kubernetes.io/ingress.class : nginx nginx.ingress.kubernetes.io/proxy-connect-timeout : ” 30 ” nginx.ingress.kubernetes.io/proxy-send-timeout : ” 500 ” nginx.ingress.kubernetes.io/proxy-read-timeout : ” 500 ” nginx.ingress.kubernetes.io/send-timeout : ” 500 ” nginx.ingress.kubernetes.io/enable-cors : ” true ” nginx.ingress.kubernetes.io/cors-allow-methods : ” * ” nginx.ingress.kubernetes.io/cors-allow-origin : ” * ” … Bạn thậm chí còn hoàn toàn có thể làm những quy tắc rất đơn cử như :nginx.ingress.kubernetes.io/configuration-snippet : | if ( $ host = ” www.wuestkamp.com ” ) { rewrite ^ https://wuestkamp.com$request_uri permanent ; } Những chú thích này sau đó sẽ được dịch sang thông số kỹ thuật Nginx. Bạn luôn hoàn toàn có thể kiểm tra chúng bằng cách liên kết bằng tay thủ công kubectl exec vào pod ingress Nginx và xem thông số kỹ thuật .https://github.com/kubernetes/ingress-nginx/tree/master/docs/user-guide/nginx-configurationhttps://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#lua-resty-waf
Kiểm tra Ingress / Nginx Logs
Tìm ra những yếu tố hoặc lỗi bằng cách xem nhật ký Ingress :kubectl logs – n ingress-nginx ingress-nginx-controller-6cfd5b6544-k2r4n
Sử dụng CURD để test
Nếu bạn muốn kiểm tra các quy tắc chuyển hướng Ingress / Nginx của mình, có thể sử dụng curl -v yourhost.com thay vì trình duyệt của bạn để tránh sử dụng bộ đệm, v.v.
Cách chuyển hướng / quy tắc Ingress
Nếu bạn muốn kiểm tra những quy tắc chuyển hướng Ingress / Nginx của mình, hoàn toàn có thể sử dụng curl – v yourhost.com thay vì trình duyệt của bạn để tránh sử dụng bộ đệm, v.v.Trong những ví dụ trong bài viết này, tất cả chúng ta sử dụng những đường dẫn như / thư mục hoặc / other / thư mục để chuyển hướng đến những dịch vụ khác nhau. Đây được gọi là một list những đường dẫn .Nó cũng hoàn toàn có thể phân biệt những nhu yếu theo tên sever của họ để chuyển hướng api.myurl.com và website.myurl.com sang những service ClusterIP nội bộ khác nhau. Điều này hoàn toàn có thể trông như thế này :apiVersion : networking.k8s.io/v1beta1kind : Ingressmetadata : name : simple-fanout-examplespec : rules : – host : api.myurl.com http : paths : – path : / foo backend : serviceName : service1 servicePort : 4200 – path : / bar backend : serviceName : service2 servicePort : 8080 – host : website.myurl.com http : paths : – path : / backend : serviceName : service3 servicePort : 3333
SSL / HTTPS
SSL. Bạn đã nghe nói về nó? Bạn có thể muốn làm cho trang web của bạn truy cập thông qua https an toàn. Ingress Kubernetes cung cấp dễ dàng TLS Termination, điều đó có nghĩa là nó xử lý tất cả các giao tiếp SSL, giải mã / chấm dứt yêu cầu SSL và sau đó gửi chúng được giải mã đến các service nội bộ của bạn.
. Bạn đã nghe nói về nó? Bạn có thể muốn làm cho trang web của bạn truy cập thông qua https an toàn. Ingress Kubernetes cung cấp dễ dàng TLS Termination, điều đó có nghĩa là nó xử lý tất cả các giao tiếp SSL, giải mã / chấm dứt yêu cầu SSL và sau đó gửi chúng được giải mã đến các service nội bộ của bạn.
Điều này thật tuyệt nếu nhiều service nội bộ của bạn đang sử dụng cùng một chứng từ SSL ( thậm chí còn hoàn toàn có thể là ký tự đại diện thay mặt ), do tại sau phải thông số kỹ thuật một lần trên Ingress của mình chứ không phải trên tổng thể những service nội bộ khác .
apiVersion: networking.k8s.io/v1beta1kind: Ingressmetadata: name: tls-example-ingressspec: tls: – hosts: – sslexample.foo.com secretName: testsecret-tls rules: – host: sslexample.foo.com http: paths: – path: / backend: serviceName: service1 servicePort: 80Bạn chỉ cần đảm bảo rằng nếu có nhiều tài nguyên Ingress trong các namespaces khác nhau, bí mật TLS cũng cần phải có sẵn trong tất cả các namespaces, nơi xác định tài nguyên Ingress bằng cách sử dụng nó.
Kết luận
Qua bài viết tất cả chúng ta đã hiểu hơn về Kubernetes và cách sử dụng chúng trong từng trường hợp như thế nào cho hiệu suất cao .
