Kubernetes Service là gì ? Tự học Kubernetes từ A-Z – phần 3

Ở phần này chúng ta sẽ tìm hiểu về Istio. Cách sử dụng, tại sao nên sử dụng, sử dụng như thế nào, ưu, nhược điểm. Cùng lướt qua bài viết nào


1071

Istio là gì ?

Istio là Service Mesh(dịch vụ lưới) cho phép giao tiếp chi tiết hơn, phức tạp hơn và có thể quan sát được giữa các pod(nhóm) và service trong cluster(cụm).

Nó quản lý điều này bằng cách mở rộng API Kubernetes với CRDs. Nó thêm các container proxy vào tất cả các pod và sau đó kiểm soát lưu lượng trong cluster.

Service Kubernetes

Bạn đã hiểu dịch vụ Kubernetes chưa ?Nếu chưa bạn có thể đọc phần 1 để hiểu rõ về nó. Bây giờ chúng ta sẽ đi sâu vào cách thức thực hiện các service Kubernetes. Tôi nghĩ rằng điều này giúp hiểu cách Istio làm mọi thứ và hiểu rõ sự khác biệt.

Kubernetes
Hình 1: Kubernetes native service request

Hình 1 cho thấy một cluster Kubernetes có hai node và 4 pod với mỗi container. Có service-nginx trỏ đến các pod nginx và service-python trỏ đến các podpython. Đường màu đỏ hiển thị một yêu cầu được thực hiện từ container nginx trong pod1-nginx đến service-python, chuyển hướng yêu cầu đến pod2-python.

Các service ClusterIP thực hiện phân phối ngẫu nhiên hoặc vòng tròn đơn giản theo mặc định. Các services trong Kubernetes không tồn tại dựa trên các node cụ thể mà chỉ tồn tại trong toàn bộ cluster. Chúng ta thấy chi tiết hơn trong hình 2:

Kubernetes
Hình 2: Kubernetes native service request with kube-proxy

Hình 2 cho thấy ví dụ tương tự như trong hình 1,chỉ là chi tiết hơn. Các service trong Kubernetes được triển khai bởi thành phần kube-proxy chạy trên mọi node. Thành phần này tạo ra các quy tắc iptables chuyển hướng yêu cầu đến pod. Do đó service không có gì khác ngoài quy tắc iptables.

Trong hình 2, chúng ta thấy rằng các chương trình API Kubernetes mỗi kube-proxy. Điều này xảy ra bất cứ khi nào có sự thay đổi trong cấu hình service hoặc các pod service. Bằng cách này, API Kubernetes có thể bị hỏng nhưng các service vẫn hoạt động.

Kubernetes Istio

Bây giờ chúng ta xem ví dụ với Istio:

Kubernetes
Hình 3: Istio Control Plane programs istio-proxy

Hình 3 cho thấy Istio được cài đặt, đi kèm với Control Plane Istio. Có thể thấy rằng mỗi pod có một container thứ hai được gọi là istio-proxy. Được tự động đưa vào các pod trong quá trình tạo.

Proxy phổ biến nhất cho Istio là Envoy với khả năng tuyệt vời của nó. Mặc dù có thể sử dụng các proxy khác.

Chúng ta có thể thấy rằng các thành phần kube-proxy không còn được hiển thị, điều này được thực hiện để giữ cho hình ảnh sạch sẽ. Chúng vẫn còn tồn tại, nhưng các pod có istio-proxy không sử dụng các component kube-proxy nữa.

Control Plane Istio thiết lập tất cả các sidecar istio-proxy mỗi khi có sự thay đổi về cấu hình hoặc service pod xảy ra. Tương tự như cách API Kubernetes thiết lập tất cả các thành phần proxy kube trong hình 2. Control Plane Istio sử dụng các service Kubernetes chỉ để hiện tất cả các pod mà mỗi dịch vụ trỏ tới. Sử dụng các địa chỉ IP pod, Istio thực hiện định tuyến riêng của mình.

Ví dụ

Sau khi Control Plane Istio thiết lập tất cả các sidecar istio-proxy:

Hình 4: Istio Control Plane programmed all istio-proxys

Trong hình 4, chúng ta thấy cách Control Plane Istio áp dụng cấu hình hiện tại cho tất cả các container proxy istio trong cluster. Để đơn giản, chúng cũng bao gồm khai báo ClusterIP. Mặc dù ClusterIP là một loại service nội bộ Kubernetes. Istio sẽ chuyển đổi các khai báo service Kubernetes thành các khai báo định tuyến riêng của nó. Nhưng nó giúp tưởng tượng điều này như được hiển thị trong hình.

Hãy xem cách một request được thực hiện bằng cách sử dụng Istio:

Hình 5: Request made with Istio

Trong hình 5, tất cả các container proxy istio đã được thiết lập bởi Control Plane Istio và chứa tất cả thông tin định tuyến cần thiết như được thấy trong hình 3/4. Container nginx từ pod1-nginx đưa ra yêu cầu service-python.

Điều gì đã xảy ra ?

Hình 1 tới 5 hiển thị cùng một ứng dụng Kubernetes với các nginx và python pod. Chúng ta đã thấy một request xảy ra như thế nào khi sử dụng các service Kubernetes mặc định và sau đó sử dụng Istio.

Điều quan trọng: bất kể phương thức nào được sử dụng, kết quả đều giống nhau và bản thân ứng dụng không cần phải thay đổi, chỉ có mã cơ sở hạ tầng.

Tại sao tất cả điều này, tại sao sử dụng Istio?

Nếu không có gì thay đổi khi sử dụng Istio (pod nginx vẫn có thể kết nối với pod python như trước đây) thì tại sao lại sử dụng Istio?

Ưu điểm đáng kinh ngạc là bây giờ tất cả lưu lượng truy cập được chuyển qua bộ container istio-proxy trong mỗi pod. Bất cứ khi nào một istio-proxy nhận được và chuyển hướng một yêu cầu, nó cũng sẽ gửi thông tin về nó tới Control Plane Istio.

Do đó, Control Plane Istio biết chính xác yêu cầu đến từ pod nào, tiêu đề HTTP nào có mặt, thời gian yêu cầu từ một proxy istio này đến proxy khác mất bao lâu và hơn thế nữa. Trong một cluster có nhiều service giao tiếp với nhau, điều này cho phép dễ quan sát hơn và kiểm soát tốt hơn tất cả lưu lượng.

Routing(định tuyến) nâng cao

Các servicenội bộ của Kubernetes chỉ có thể thực hiện vòng tròn hoặc phân phối ngẫu nhiên các yêu cầu dịch vụ tới các pod. Với Istio nhiều cách phức tạp hơn là có thể. Giống như chuyển hướng tùy thuộc vào tiêu đề yêu cầu. Nếu xảy ra lỗi hoặc service ít được sử dụng nhất.

Deployments

It allows routing certain percentages of traffic to certain service versions and hence allows for Green/Blue and Canary deployments.

Nó cho phép Routing tỷ lệ phần trăm lưu lượng truy cập nhất định đến các phiên bản service nhất định và do đó cho phép triển khai Green / Blue và Canary.

Encryption(Mã hóa)

Lưu lượng truy cập nội bộ giữa các pod, từ istio-proxy đến istio-proxy, có thể được mã hóa.

Giám sát / tạo đồ thị

Istio kết nối với các công cụ giám sát như Prometheus. Hoạt động tuyệt vời với Kiali để hiển thị tất cả các service và lưu lượng truy cập của chúng.

https://istio.io/docs/tasks/observability/kiali

Tracing(Truy tìm)

Vì Control Plane Istio có vô số dữ liệu về các yêu cầu. Chúng có thể được theo dõi và kiểm tra với ví dụ Jaeger.

https://istio.io/docs/tasks/observability/distributed-tracing/jaeger

Multi cluster mesh(Nhiều cụm lưới)

Istio có một sổ đăng ký service nội bộ có thể sử dụng các service Kubernetes hiện có. Mặc dù nó cũng có thể thêm tài nguyên từ bên ngoài cluster hoặc thậm chí kết nối các cluster khác nhau thành một mesh.

https://istio.io/docs/ops/deployment/deployment-models/#multiple-clusters

Sidecar Injection

Để Istio hoạt động, mọi pod nên là một phần của mesh cần được injection sidecar proxy istio. Điều này có thể được thực hiện tự động cho toàn bộ namespace trong quá trình tạo pod hoặc được thực hiện thủ công.

Istio có thay thế service Kubernetes không?

Không. Một câu hỏi tôi đã tự hỏi mình khi bắt đầu với Istio là liệu nó có thay thế các service Kubernetes hiện có không. Câu trả lời là không. Istio sử dụng các service Kubernetes hiện có để nhận tất cả các địa chỉ IP endpoints(điểm cuối) / pod của họ.

Istio có thay thế Ingress Kubernetes không?

Hãy đọc phần 2 tại đây để hiểu rõ

Đúng. Istio cung cấp các tài nguyên mới, như Gateway và VirtualService. Và thậm chí đi kèm với trình chuyển đổi istioctl convert-ingress. Tham khảo  https://istio.io/docs/concepts/traffic-management

Hình 6 cho thấy cách Istio Gateway có thể xử lý lưu lượng truy cập. Bản thân Gateway cũng là một thành phần istio-proxy.

Hình 6: Istio Gateway

Control Plane

Control Plane Istio bao gồm một vài thành phần nhỏ hơn như Pilot, mixer, Citadel và Galley. Nếu bạn muốn hiểu sâu hơn, tôi khuyên bạn nên truy cập https://istio.io/docs/ops/deployment/arch architecture

Điều gì xảy ra nếu Control Plane Istio bị hỏng?

Bởi vì tất cả các sidecar proxy istio đã được thiết lập, Control Plane Istio có thể hỏng và lưu lượng vẫn hoạt động như trước. Nhưng các bản cập nhật cấu hình hoặc các pod mới được tạo sẽ bị hỏng.

Mặc dù đối với routing nâng cao, như gửi lưu lượng truy cập đến pod hoặc chính sách ít được sử dụng nhất (https://istio.io/docs/tasks/policy-enforcement), cần có sự giao tiếp giữa tất cả các istio-proxys thông qua Control Plane Istio. Sau đó, mọi istio-proxy sẽ cần phải kiểm tra lại Control Plane Istio trước khi cho phép yêu cầu.

Để các cấu hình này hoạt động chính xác, tôi nghĩ rằng control plane phải có sẵn ở mọi thời điểm.

Kết luận

Đây là một giới thiệu đơn giản và tổng quan rộng mà tôi hy vọng sẽ giúp mọi người bắt đầu. Istio chắc chắn là một mức độ phức tạp khác của Kubernetes. Mặc dù đối với các kiến ​​trúc microservice hiện đại, nó thực sự cung cấp một cách đơn giản hơn nhiều so với việc phải thực hiện theo dõi hoặc quan sát vào chính code ứng dụng.


Like it? Share with your friends!

1071