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