Điều gì xảy ra nếu Control Plane Istio bị hỏng ?Tại sao toàn bộ điều này, tại sao sử dụng Istio ?
Istio là gì ?
Istio là Service Mesh ( dịch vụ lưới ) được cho phép tiếp xúc chi tiết cụ thể hơn, phức tạp hơn và hoàn toàn có thể quan sát được giữa những 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 hoàn toàn có thể đọc phần 1 để hiểu rõ về nó. Bây giờ tất cả chúng ta sẽ đi sâu vào phương pháp thực thi những 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ự độc lạ .
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 những pod nginx và service-python trỏ đến những podpython. Đường màu đỏ hiển thị một nhu yếu được triển khai từ container nginx trong pod1-nginx đến service-python, chuyển hướng nhu yếu đến pod2-python .
Các service ClusterIP thực thi phân phối ngẫu nhiên hoặc vòng tròn đơn thuần theo mặc định. Các services trong Kubernetes không sống sót dựa trên những node đơn cử mà chỉ sống sót trong hàng loạt cluster. Chúng ta thấy chi tiết cụ thể hơn trong hình 2 :
Hình 2: Kubernetes native service request with kube-proxy
Hình 2 cho thấy ví dụ tựa như như trong hình 1, chỉ là cụ thể hơn. Các service trong Kubernetes được tiến hành bởi thành phần kube-proxy chạy trên mọi node. Thành phần này tạo ra những quy tắc iptables chuyển hướng nhu yếu đến pod. Do đó service không có gì khác ngoài quy tắc iptables .
Trong hình 2, tất cả chúng ta thấy rằng những chương trình API Kubernetes mỗi kube-proxy. Điều này xảy ra bất kỳ khi nào có sự biến hóa trong thông số kỹ thuật service hoặc những pod service. Bằng cách này, API Kubernetes hoàn toàn có thể bị hỏng nhưng những service vẫn hoạt động giải trí .
Kubernetes Istio
Bây giờ tất cả chúng ta xem ví dụ với Istio :
Hình 3: Istio Control Plane programs istio-proxy
Hình 3 cho thấy Istio được setup, đ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 hóa đưa vào những pod trong quy trình tạo .
Proxy phổ cập nhất cho Istio là Envoy với năng lực tuyệt vời của nó. Mặc dù hoàn toàn có thể sử dụng những proxy khác .
Chúng ta hoàn toàn có thể thấy rằng những thành phần kube-proxy không còn được hiển thị, điều này được triển khai để giữ cho hình ảnh thật sạch. Chúng vẫn còn sống sót, nhưng những pod có istio-proxy không sử dụng những component kube-proxy nữa .
Control Plane Istio thiết lập toàn bộ những sidecar istio-proxy mỗi khi có sự biến hóa về thông số kỹ thuật hoặc service pod xảy ra. Tương tự như cách API Kubernetes thiết lập toàn bộ những thành phần proxy kube trong hình 2. Control Plane Istio sử dụng những service Kubernetes chỉ để hiện tổng thể những pod mà mỗi dịch vụ trỏ tới. Sử dụng những địa chỉ IP pod, Istio triển khai định tuyến riêng của mình .
Ví dụ
Sau khi Control Plane Istio thiết lập tổng thể những sidecar istio-proxy :
Hình 4: Istio Control Plane programmed all istio-proxys
Trong hình 4, tất cả chúng ta thấy cách Control Plane Istio vận dụng thông số kỹ thuật hiện tại cho tổng thể những container proxy istio trong cluster. Để đơn thuần, chúng cũng gồm có khai báo ClusterIP. Mặc dù ClusterIP là một loại service nội bộ Kubernetes. Istio sẽ quy đổi những khai báo service Kubernetes thành những 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 triển khai bằng cách sử dụng Istio :
Hình 5: Request made with Istio
Trong hình 5, toàn bộ những container proxy istio đã được thiết lập bởi Control Plane Istio và chứa toàn bộ thông tin định tuyến thiết yếu như được thấy trong hình 3/4. Container nginx từ pod1-nginx đưa ra nhu yế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 những nginx và python pod. Chúng ta đã thấy một request xảy ra như thế nào khi sử dụng những 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ì đổi khác khi sử dụng Istio ( pod nginx vẫn hoàn toàn có thể liên kết với pod python như trước kia ) thì tại sao lại sử dụng Istio ?
Ưu điểm đáng kinh ngạc là giờ đây toàn bộ lưu lượng truy vấn đượ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 nhu yế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ỉ hoàn toàn có thể thực thi vòng tròn hoặc phân phối ngẫu nhiên những nhu yếu dịch vụ tới những pod. Với Istio nhiều cách phức tạp hơn là hoàn toàn có thể. Giống như chuyển hướng tùy thuộc vào tiêu đề nhu yế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ó được cho phép Routing tỷ suất Phần Trăm lưu lượng truy vấn nhất định đến những phiên bản service nhất định và do đó được cho phép tiến hành Green / Blue và Canary .
Encryption(Mã hóa)
Lưu lượng truy vấn nội bộ giữa những pod, từ istio-proxy đến istio-proxy, hoàn toàn có thể được mã hóa .
Giám sát / tạo đồ thị
Istio liên kết với những công cụ giám sát như Prometheus. Hoạt động tuyệt vời với Kiali để hiển thị tổng thể những service và lưu lượng truy vấn của chúng .
Tracing(Truy tìm)
Vì Control Plane Istio có vô số tài liệu về những nhu yếu. Chúng hoàn toàn 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ổ ĐK service nội bộ hoàn toàn có thể sử dụng những service Kubernetes hiện có. Mặc dù nó cũng hoàn toàn có thể thêm tài nguyên từ bên ngoài cluster hoặc thậm chí còn liên kết những cluster khác nhau thành một mesh .
Sidecar Injection
Để Istio hoạt động giải trí, mọi pod nên là một phần của mesh cần được injection sidecar proxy istio. Điều này hoàn toàn có thể được triển khai tự động hóa cho hàng loạt namespace trong quy trình tạo pod hoặc được triển khai bằng tay 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 khởi đầu với Istio là liệu nó có sửa chữa thay thế những service Kubernetes hiện có không. Câu vấn đáp là không. Istio sử dụng những service Kubernetes hiện có để nhận toàn bộ những đị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 ứng những tài nguyên mới, như Gateway và VirtualService. Và thậm chí còn đi kèm với trình quy đổi istioctl convert-ingress. Tham khảo https://istio.io/docs/concepts/traffic-management
Hình 6 cho thấy cách Istio Gateway hoàn toàn có thể giải quyết và xử lý lưu lượng truy vấn. 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 gồm có 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 vấn 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ổng thể những sidecar proxy istio đã được thiết lập, Control Plane Istio hoàn toàn có thể hỏng và lưu lượng vẫn hoạt động giải trí như trước. Nhưng những bản update thông số kỹ thuật hoặc những pod mới được tạo sẽ bị hỏng .
Mặc dù so với routing nâng cao, như gửi lưu lượng truy vấn đến pod hoặc chủ trương ít được sử dụng nhất ( https://istio.io/docs/tasks/policy-enforcement ), cần có sự tiếp xúc giữa tổng thể những istio-proxys trải 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 được cho phép nhu yếu .
Để những thông số kỹ thuật này hoạt động giải trí đúng mực, tôi nghĩ rằng control plane phải có sẵn ở mọi thời gian .
Kết luận
Đây là một trình làng đơn thuần và tổng quan rộng mà tôi kỳ vọng sẽ giúp mọi người khởi đầu. Istio chắc như đinh là một mức độ phức tạp khác của Kubernetes. Mặc dù so với những kiến trúc microservice tân tiến, nó thực sự phân phối một cách đơn thuần hơn nhiều so với việc phải triển khai theo dõi hoặc quan sát vào chính code ứng dụng .
Bài viết này mình 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 tương hỗ thêm nhé .
