Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Thực tiễn tốt nhất của Kubernetes. Tạo các thùng chứa nhỏ
Thực tiễn tốt nhất của Kubernetes. Tổ chức Kubernetes với không gian tên
Thực tiễn tốt nhất của Kubernetes. Xác thực tính sống động của Kubernetes bằng các bài kiểm tra tính sẵn sàng và tính sống động
Thực tiễn tốt nhất của Kubernetes. Thiết lập các yêu cầu và giới hạn tài nguyên
Thực tiễn tốt nhất của Kubernetes. Tắt máy đúng Chấm dứt

Nếu giống như hầu hết mọi người, có thể bạn đang sử dụng các tài nguyên chạy bên ngoài cụm của mình. Có lẽ bạn sử dụng API Taleo để gửi tin nhắn văn bản hoặc phân tích hình ảnh bằng API Google Cloud Vision.

Nếu bạn sử dụng cùng một điểm cuối yêu cầu phía máy chủ trong tất cả các môi trường của mình và không có kế hoạch di chuyển máy chủ sang Kubernetes thì việc có điểm cuối dịch vụ ngay trong mã của bạn là hoàn toàn ổn. Tuy nhiên, có nhiều kịch bản khác cho sự phát triển của các sự kiện. Trong loạt bài Thực tiễn tốt nhất về Kubernetes này, bạn sẽ tìm hiểu cách sử dụng các cơ chế tích hợp sẵn của Kubernetes để khám phá các dịch vụ cả bên trong và bên ngoài cụm.

Một ví dụ về dịch vụ bên ngoài phổ biến là cơ sở dữ liệu chạy bên ngoài cụm Kubernetes. Không giống như cơ sở dữ liệu đám mây như Google Cloud Data Store hoặc Google Cloud Spanner, sử dụng một điểm cuối duy nhất cho tất cả quyền truy cập, hầu hết các cơ sở dữ liệu đều có điểm cuối riêng biệt cho các trường hợp khác nhau.
Các phương pháp hay nhất để sử dụng cơ sở dữ liệu truyền thống như MySQL và MongoDB thường có nghĩa là bạn kết nối với các thành phần khác nhau cho các môi trường khác nhau. Bạn có thể có một máy lớn cho dữ liệu sản xuất và một máy nhỏ hơn cho môi trường thử nghiệm. Mỗi người trong số họ sẽ có địa chỉ IP hoặc tên miền riêng, nhưng có thể bạn sẽ không muốn thay đổi mã của mình khi chuyển từ môi trường này sang môi trường khác. Vì vậy, thay vì mã hóa cứng các địa chỉ này, bạn có thể sử dụng tính năng khám phá dịch vụ bên ngoài dựa trên DNS tích hợp của Kubernetes giống như các dịch vụ Kubernetes gốc.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Giả sử bạn đang chạy cơ sở dữ liệu MongoDB trên Google Computer Engine. Bạn sẽ bị mắc kẹt trong thế giới lai này cho đến khi bạn chuyển được nó vào cụm.

May mắn thay, bạn có thể sử dụng các dịch vụ Kubernetes tĩnh để giúp cuộc sống của bạn dễ dàng hơn một chút. Trong ví dụ này, tôi đã tạo máy chủ MongoDB bằng Google Cloud Launcher. Vì nó được tạo trên cùng một mạng (hoặc VPC cụm Kubernetes), nên nó được truy cập bằng địa chỉ IP nội bộ hiệu suất cao.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Đây là cài đặt mặc định trên Google Cloud nên bạn không phải định cấu hình gì cả. Bây giờ bạn đã có địa chỉ IP, bước đầu tiên là tạo một dịch vụ. Bạn có thể nhận thấy rằng không có bộ chọn nhóm nào cho dịch vụ này. Tức là chúng tôi đã tạo ra một dịch vụ không biết gửi lưu lượng truy cập vào đâu. Điều này sẽ cho phép bạn tạo thủ công một đối tượng điểm cuối sẽ nhận lưu lượng truy cập từ dịch vụ này.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Ví dụ mã sau đây cho thấy điểm cuối xác định địa chỉ IP cho cơ sở dữ liệu bằng cách sử dụng cùng tên mongo với dịch vụ.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Kubernetes sẽ sử dụng tất cả các địa chỉ IP để tìm endpoint như thể chúng là Kubernetes Pods thông thường, vì vậy bây giờ bạn có thể truy cập cơ sở dữ liệu bằng một chuỗi kết nối đơn giản với tên trên mongodb://mongo. Không cần sử dụng địa chỉ IP trong mã của bạn.

Nếu địa chỉ IP thay đổi trong tương lai, bạn chỉ cần cập nhật điểm cuối của mình bằng địa chỉ IP mới và ứng dụng của bạn sẽ không cần phải sửa đổi theo bất kỳ cách nào bổ sung.

Nếu bạn đang sử dụng cơ sở dữ liệu được lưu trữ trên máy chủ của bên thứ ba, có thể chủ sở hữu máy chủ đã cung cấp cho bạn URI Mã định danh tài nguyên thống nhất để kết nối. Vì vậy, nếu bạn đã được cấp một địa chỉ IP, bạn chỉ cần sử dụng phương pháp trước đó. Ví dụ này cho thấy tôi có hai cơ sở dữ liệu MongoDB được lưu trữ trên máy chủ mLab.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Một là cơ sở dữ liệu dành cho nhà phát triển và cái còn lại là cơ sở dữ liệu sản xuất. Chuỗi kết nối cho các cơ sở dữ liệu này trông như thế này - mLab cung cấp cho bạn URI động và cổng động. Như bạn có thể thấy, chúng khác nhau.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Để trừu tượng hóa điều này, hãy sử dụng Kubernetes và kết nối với cơ sở dữ liệu dành cho nhà phát triển. Bạn có thể tạo tên dịch vụ Kubernetes bên ngoài để cung cấp cho bạn một dịch vụ tĩnh chuyển tiếp lưu lượng truy cập đến dịch vụ bên ngoài.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Dịch vụ này sẽ thực hiện chuyển tiếp CNAME đơn giản ở cấp kernel với tác động hiệu suất tối thiểu. Nhờ đó bạn có thể sử dụng chuỗi kết nối đơn giản hơn.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Nhưng vì tên bên ngoài sử dụng chuyển tiếp CNAME nên nó không thể thực hiện chuyển tiếp cổng. Vì vậy, giải pháp này chỉ áp dụng được cho cổng tĩnh và không thể sử dụng với cổng động. Tuy nhiên, mLab Free Tier cung cấp cho người dùng số cổng động theo mặc định và bạn không thể thay đổi số đó. Điều này có nghĩa là bạn cần các dòng lệnh kết nối khác nhau cho dev và prod. Điều tệ là việc này sẽ yêu cầu bạn mã hóa cứng số cổng. Vậy làm cách nào để chuyển tiếp cổng hoạt động?

Bước đầu tiên là lấy địa chỉ IP từ URI. Nếu bạn chạy nslookup, tên máy chủ hoặc ping URI, bạn có thể lấy địa chỉ IP của cơ sở dữ liệu. Nếu dịch vụ trả về một số địa chỉ IP cho bạn thì tất cả các địa chỉ này có thể được sử dụng ở điểm cuối của đối tượng.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Một điều cần lưu ý là IP URI có thể thay đổi mà không cần thông báo, khiến chúng khá rủi ro khi sử dụng trong sản xuất. Sử dụng địa chỉ IP này, bạn có thể kết nối với cơ sở dữ liệu từ xa mà không cần chỉ định cổng. Do đó, dịch vụ Kubernetes thực hiện chuyển tiếp cổng khá minh bạch.

Thực tiễn tốt nhất của Kubernetes. Lập bản đồ các dịch vụ bên ngoài

Ánh xạ hoặc ánh xạ các tài nguyên bên ngoài tới các tài nguyên nội bộ, mang lại cho bạn sự linh hoạt khi sử dụng các dịch vụ này trong cụm trong tương lai đồng thời giảm thiểu nỗ lực tái cấu trúc. Nó cũng giúp quản lý và cung cấp thông tin chi tiết về những dịch vụ bên ngoài mà công ty bạn sử dụng dễ dàng hơn.

Sẽ sớm được tiếp tục...

Một số quảng cáo 🙂

Cảm ơn bạn đã ở với chúng tôi. Bạn có thích bài viết của chúng tôi? Bạn muốn xem nội dung thú vị hơn? Hỗ trợ chúng tôi bằng cách đặt hàng hoặc giới thiệu cho bạn bè, VPS đám mây cho nhà phát triển từ $4.99, một dạng tương tự duy nhất của các máy chủ cấp đầu vào do chúng tôi phát minh ra dành cho bạn: Toàn bộ sự thật về VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps từ 19$ hay cách share server? (có sẵn với RAID1 và RAID10, tối đa 24 lõi và tối đa 40GB DDR4).

Dell R730xd rẻ hơn gấp 2 lần tại trung tâm dữ liệu Equinix Tier IV ở Amsterdam? Chỉ ở đây 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV từ $199 ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về Làm thế nào để xây dựng cơ sở hạ tầng corp. đẳng cấp với việc sử dụng máy chủ Dell R730xd E5-2650 v4 trị giá 9000 euro cho một xu?

Nguồn: www.habr.com

Thêm một lời nhận xét