Kubernetes Service là gì ? Tự học Kubernetes từ A-Z

Lời mở đầu

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.

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ộ 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.

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.

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, 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).

Máy chủ HTTP (Nginx) có thể làm gì?

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;
}

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).

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.

Ví dụ đơn giản Kubernetes:

Sử dụng service ClusterIP

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.

Sử dụng 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.

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 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.

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..

# 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à 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.

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ấ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.

Cài đặt Controller Ingress Kubernetes

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.yaml

Sử 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.

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 tested
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  namespace: default
  name: test-ingress
spec:
  rules:
  - http:
      paths:
      - path: /folder
        backend:
          serviceName: service-nginx
          servicePort: 3001
  - http:
      paths:
      - path: /other
        backend:
          serviceName: service-python
          servicePort: 3002

Chú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.

Ví dụ Ingress Kubernetes về khác Namespaces

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 tested
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  namespace: default
  name: ingress1
spec:
  rules:
  - http:
      paths:
      - path: /folder
        backend:
          serviceName: service-nginx
          servicePort: 3001

Và service-python với namespace: namespace2:

# just example, not tested
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  namespace: namespace2
  name: ingress2
spec:
  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:

kind: Ingress
metadata:
  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.

Tham khảo bên dưới để xem thêm về cấu hình Nginx

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

Kiểm tra Ingress / Nginx Logs

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

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

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/v1beta1
kind: Ingress
metadata:
  name: simple-fanout-example
spec:
  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.

Đ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/v1beta1
kind: Ingress
metadata:
  name: tls-example-ingress
spec:
  tls:
  - hosts:
    - sslexample.foo.com
    secretName: testsecret-tls
  rules:
    - host: sslexample.foo.com
      http:
        paths:
        - path: /
          backend:
            serviceName: service1
            servicePort: 80

Bạ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 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ả.

HocWeb VN

Bài viết này được sưu tầm và tổng hợp từ nhiều nguồn trên Internet.

Nếu có gì không hiểu thì inbox messenger bên dưới mình hỗ trợ thêm nhé.