Kubernetes Ingress không phải là một service Kubernetes. Rất đơn giản, nó chỉ là một Nginx Pod chuyển hướng yêu cầu đến các service nội bộ (ClusterIP) khác. Bản thân có thể truy cập thông qua service Kubernetes, phổ biến 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 ư ? Bạn sử dụng nó để làm cho service nội bộ có thể truy cập từ bên ngoài cluster của bạn. Nó tiết kiệm cho bạn các 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 cho phép cấu hình nhiều hơn và thiết lập dễ dàng hơn.
Bạn đang xem: Ingress là gì
Nghe thì khó hiểu, hãy cùng đi qua từng ví dụ để hiểu hơn nào
Ở đây, chúng ta lùi lại thời gian trước khi có container, Kubernetes và thế giới của dữ liệu đám mây (Cloud).
Nó có thể nhận được yêu cầu qua giao thức HTTP cho một filepath cụ thể, kiểm tra filepath đó trên hệ thống tệp đính kèm và trả lại nếu tệp đó tồn tại:
Trong Nginx, điều này có thể được thực hiện với một cái gì đó như:
location /folder { root /var/www/; index index.html;}
Chúng ta không đi sâu vào vấn đề này nhưng với Nginx, chuyển hướng proxy có thể được định cấu hình như sau:
location /folder { proxy_pass http://second-nginx-server:8000;}Điều này có nghĩa là Nginx có thể phục vụ các tệp từ hệ thống tệp hoặc chuyển hướng phản hồi đến các máy chủ khác và trả lại phản hồi của họ, bằng cách đóng vai trò là proxy.
Một lần nữa, từ thời điểm này, bạn nên hiểu service Kubernetes. Chúng ta có hai node , chúng ta bỏ qua các node master ở đây. Và có hai service là service-nginx và service-python trỏ đến các pod(nhóm) khác nhau.
Các Services không trên bất kỳ Node cụ thể 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), chúng ta có thể tiếp cận các pod Nginx và các pod Python thông qua các service của họ. Tiếp theo, chúng ta cũng muốn cung cấp những thứ đó từ bên ngoài cụm. Vì vậy, chuyển đổi chúng thành các service LoadBalancer.
Bạn có thể thấy rằng chúng ta đã chuyển đổi service ClusterIP thành service LoadBalancer. Bởi vì chúng ta có cluster Kubernetes lưu trữ với Nhà cung cấp đám mây có thể 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 yêu cầu đến các Node IP bên ngoài của chúng, sau đó chuyển hướng đến các service ClusterIP bên trong.
Chúng ta thấy hai LoadBalancer, mỗi loại có IP riêng. Nếu chúng ta gửi yêu cầ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 chúng ta gửi yêu cầ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 nhà cung cấp đám mây. Bây giờ hãy tưởng tượng chúng ta không chỉ có hai mà nhiều service nội bộ khác muốn tạo LoadBalancer,và chi phí sẽ tăng lên.
Có một giải pháp khác cho phép 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 để khám phá điều này trước tiên bằng cách thực hiện một cách tiếp cận thủ công.
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 chúng ta chỉ đạt một LoadBalancer (11,22.33.44) nhưng với các url http khác nhau, các yêu cầu được hiển thị màu vàng là cùng một mục tiêu và chỉ chứa nội dung khác nhau (các url yêu cầu).
service-nginx-proxy quyết định (bằng cách sử dụng Nginx proxy và vị trí), tùy thuộc vào các url được chuyển, service nào chuyển hướng dựa trên yêu cầu.
# 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.
Xem thêm: Căng Tin Tiếng Anh Là Gì - Nghĩa Của Từ Căng Tin Trong Tiếng Anh
Và bởi vì đây là một giải pháp phổ biến, Kubernetes Ingress được tạo ra để giúp cấu hình dễ dàng và dễ quản lý hơn.
Từ thời điểm 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.
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ất cả những gì có để hiểu về Ingress Kubernetes. Bây giờ hãy lướt qua một số cấu hình.
Ingress Kubernetes là một Tài nguyên Kubernetes bổ sung được cài đặt 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 các tài nguyên k8s được cài đặt với namespace: ingress-nginx:
kubectl get svc,pod --namespace=ingress-nginx
Bạn thấy service LoadBalancer rất bình thường với IP bên ngoài và pod. Bạn thậm chí có thể chạy câu lệnh kubectl exec vào pod đó để xem nó chứa máy chủ Nginx được cấu hình sẵn:
Trong nginx.conf bạn sẽ thấy các cài đặt chuyển hướng proxy khác nhau và cấu hình liên quan khác.
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: /folder backend: serviceName: service-nginx servicePort: 3001 - http: paths: - path: /other backend: serviceName: service-python servicePort: 3002Chúng ta sẽ cần tạo yaml thông qua câu lệnh kubectl create -f ingress.yaml. Yaml này sau đó sẽ được chuyển đổi bởi Controller Ingress được cài đặt trước đó thành cấu hình Nginx.
Bây giờ nếu một trong các service nội bộ của bạn, mà Ingress nên chuyển hướng đến, mà ở namespace khác thì sao? Trong cấu hình Ingress, bạn chỉ có thể chuyển hướng đến các service trong cùng một namespace.
Nếu bạn xác định nhiều cấu hình yaml Ingress, thì các cấu hình đó được hợp nhất với nhau thành một cấu hình Nginx bởi một Controller Ingress duy nhất. Có nghĩa: tất cả đề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
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ó thể làm các quy tắc rất cụ thể 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 cấu hình Nginx. Bạn luôn có thể kiểm tra chúng bằng cách kết nối thủ công kubectl exec vào pod ingress Nginx và xem cấu hình.
https://github.com/kubernetes/ingress-nginx/tree/master/docs/user-guide/nginx-configuration
https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md#lua-resty-waf
Tìm ra các vấn đề hoặc lỗi bằng cách xem nhật ký Ingress:
kubectl logs -n ingress-nginx ingress-nginx-controller-6cfd5b6544-k2r4n
Trong các ví dụ trong bài viết này, chúng ta sử dụng các đường dẫn như /folder hoặc /other/folder để chuyển hướng đến các dịch vụ khác nhau. Đây được gọi là một danh sách các đường dẫn.
Nó cũng có thể phân biệt các yêu cầu theo tên máy chủ của họ để chuyển hướng api.myurl.com và website.myurl.com sang các service ClusterIP nội bộ khác nhau. Điều này 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
Đ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 chỉ SSL (thậm chí có thể là ký tự đại diện), bởi vì sau phải cấu hình một lần trên Ingress của mình chứ không phải trên tất cả các 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ó.
Qua bài viết 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 quả.