Kubernetes là một công cụ tuyệt vời để chạy các container Docker trong môi trường sản xuất theo cụm. Tuy nhiên, có những vấn đề mà Kubernetes không thể giải quyết được. Để triển khai sản xuất thường xuyên, chúng tôi cần triển khai Xanh/Xanh hoàn toàn tự động để tránh thời gian ngừng hoạt động trong quy trình, đồng thời cần xử lý các yêu cầu HTTP bên ngoài và thực hiện giảm tải SSL. Điều này yêu cầu tích hợp với bộ cân bằng tải như ha-proxy. Một thách thức khác là việc tự động điều chỉnh quy mô của cụm Kubernetes khi chạy trong môi trường đám mây, chẳng hạn như thu nhỏ một phần cụm vào ban đêm.
Mặc dù Kubernetes không có sẵn những tính năng này nhưng nó cung cấp một API mà bạn có thể sử dụng để giải quyết các vấn đề tương tự. Các công cụ để triển khai Blue/Green tự động và mở rộng quy mô cụm Kubernetes đã được phát triển như một phần của dự án Cloud RTI, được tạo dựa trên nguồn mở.
Bài viết này, một bản ghi video, hướng dẫn bạn cách thiết lập Kubernetes cùng với các thành phần nguồn mở khác để tạo môi trường sẵn sàng sản xuất, chấp nhận mã từ cam kết git mà không có thời gian ngừng hoạt động trong quá trình sản xuất.
Vì vậy, khi bạn có quyền truy cập vào các ứng dụng của mình từ thế giới bên ngoài, bạn có thể bắt đầu thiết lập tự động hóa hoàn toàn, nghĩa là đưa nó đến giai đoạn mà bạn có thể thực hiện cam kết git và đảm bảo rằng cam kết git này sẽ được đưa vào sản xuất. Đương nhiên khi thực hiện các bước này, khi triển khai chúng ta không muốn gặp phải tình trạng ngừng hoạt động. Vì vậy, mọi hoạt động tự động hóa trong Kubernetes đều bắt đầu bằng API.
Kubernetes không phải là một công cụ có thể được sử dụng một cách hiệu quả ngay từ đầu. Tất nhiên, bạn có thể làm điều đó, sử dụng kubectl, v.v., nhưng API vẫn là điều thú vị và hữu ích nhất về nền tảng này. Bằng cách sử dụng API làm tập hợp các hàm, bạn có thể truy cập hầu hết mọi thứ bạn muốn thực hiện trong Kubernetes. Bản thân kubectl cũng sử dụng API REST.
Đây là REST, vì vậy bạn có thể sử dụng bất kỳ ngôn ngữ hoặc công cụ nào để làm việc với API này, nhưng cuộc sống của bạn sẽ trở nên dễ dàng hơn nhiều nhờ các thư viện tùy chỉnh. Nhóm của tôi đã viết 2 thư viện như vậy: một cho Java/OSGi và một cho Go. Cái thứ hai không được sử dụng thường xuyên, nhưng trong mọi trường hợp, bạn luôn có sẵn những thứ hữu ích này. Chúng là một dự án nguồn mở được cấp phép một phần. Có rất nhiều thư viện như vậy dành cho các ngôn ngữ khác nhau, vì vậy bạn có thể chọn những thư viện phù hợp nhất với mình.
Vì vậy, trước khi bắt đầu tự động hóa quá trình triển khai của mình, bạn cần đảm bảo rằng quy trình sẽ không có bất kỳ thời gian ngừng hoạt động nào. Ví dụ: nhóm của chúng tôi tiến hành triển khai sản xuất vào giữa ngày khi mọi người đang sử dụng ứng dụng nhiều nhất, vì vậy điều quan trọng là tránh sự chậm trễ trong quá trình này. Để tránh thời gian ngừng hoạt động, 2 phương pháp được sử dụng: triển khai xanh/xanh hoặc cập nhật luân phiên. Trong trường hợp sau, nếu bạn có 5 bản sao của ứng dụng đang chạy, chúng sẽ được cập nhật tuần tự lần lượt. Phương pháp này hoạt động tốt nhưng không phù hợp nếu bạn có các phiên bản ứng dụng khác nhau chạy đồng thời trong quá trình triển khai. Trong trường hợp này, bạn có thể cập nhật giao diện người dùng trong khi phần phụ trợ đang chạy phiên bản cũ và ứng dụng sẽ ngừng hoạt động. Vì vậy, từ quan điểm lập trình, làm việc trong những điều kiện như vậy là khá khó khăn.
Đây là một trong những lý do tại sao chúng tôi thích sử dụng triển khai xanh lam/xanh lục để tự động hóa việc triển khai các ứng dụng của mình. Với phương pháp này, bạn phải đảm bảo rằng mỗi lần chỉ có một phiên bản của ứng dụng được kích hoạt.
Cơ chế triển khai xanh/xanh trông như thế này. Chúng tôi nhận được lưu lượng truy cập cho các ứng dụng của mình thông qua ha-proxy, chuyển tiếp nó tới các bản sao đang chạy của ứng dụng có cùng phiên bản.
Khi triển khai mới được thực hiện, chúng tôi sử dụng Deployer, được cung cấp các thành phần mới và triển khai phiên bản mới. Triển khai phiên bản mới của ứng dụng có nghĩa là một nhóm bản sao mới được "tăng lên", sau đó các bản sao này của phiên bản mới sẽ được khởi chạy trong một nhóm mới, riêng biệt. Tuy nhiên, ha-proxy không biết gì về chúng và chưa định tuyến bất kỳ khối lượng công việc nào cho chúng.
Do đó, trước hết, cần thực hiện kiểm tra hiệu suất của các phiên bản kiểm tra tình trạng mới để đảm bảo rằng các bản sao đã sẵn sàng phục vụ tải.
Tất cả các thành phần triển khai phải hỗ trợ một số hình thức kiểm tra tình trạng. Đây có thể là một cuộc kiểm tra cuộc gọi HTTP rất đơn giản, khi bạn nhận được mã có trạng thái 200 hoặc kiểm tra chuyên sâu hơn, trong đó bạn kiểm tra kết nối của các bản sao với cơ sở dữ liệu và các dịch vụ khác, tính ổn định của các kết nối môi trường động và liệu mọi thứ có khởi động và hoạt động chính xác hay không. Quá trình này có thể khá phức tạp.
Sau khi hệ thống xác minh rằng tất cả các bản sao được cập nhật đều đang hoạt động, Người triển khai sẽ cập nhật cấu hình và chuyển confd chính xác, cấu hình này sẽ cấu hình lại ha-proxy.
Chỉ sau đó lưu lượng truy cập mới được chuyển hướng đến nhóm có bản sao của phiên bản mới và nhóm cũ sẽ biến mất.
Cơ chế này không phải là một tính năng của Kubernetes. Khái niệm triển khai Xanh/xanh đã có từ khá lâu và nó luôn sử dụng bộ cân bằng tải. Đầu tiên, bạn hướng tất cả lưu lượng truy cập đến phiên bản cũ của ứng dụng và sau khi cập nhật, bạn chuyển hoàn toàn sang phiên bản mới. Nguyên tắc này không chỉ được sử dụng trong Kubernetes.
Bây giờ tôi sẽ giới thiệu cho bạn một thành phần triển khai mới - Deployer, thành phần này thực hiện kiểm tra tình trạng, cấu hình lại proxy, v.v. Đây là một khái niệm không áp dụng cho thế giới bên ngoài và tồn tại bên trong Kubernetes. Tôi sẽ chỉ cho bạn cách bạn có thể tạo khái niệm Người triển khai của riêng mình bằng cách sử dụng các công cụ nguồn mở.
Vì vậy, điều đầu tiên Deployer thực hiện là tạo bộ điều khiển sao chép RC bằng API Kubernetes. API này tạo các nhóm và dịch vụ để triển khai thêm, nghĩa là nó tạo ra một cụm hoàn toàn mới cho các ứng dụng của chúng tôi. Ngay sau khi RC tin chắc rằng các bản sao đã bắt đầu, nó sẽ thực hiện kiểm tra Tình trạng chức năng của chúng. Để thực hiện việc này, Người triển khai sử dụng lệnh GET /health. Nó chạy các thành phần quét thích hợp và kiểm tra tất cả các thành phần hỗ trợ hoạt động của cụm.
Sau khi tất cả các nhóm đã báo cáo tình trạng của mình, Deployer sẽ tạo một thành phần cấu hình mới - bộ lưu trữ phân tán etcd, được Kubernetes sử dụng nội bộ, bao gồm cả việc lưu trữ cấu hình cân bằng tải. Chúng tôi ghi dữ liệu vào etcd và một công cụ nhỏ gọi là confd giám sát etcd để tìm dữ liệu mới.
Nếu phát hiện bất kỳ thay đổi nào đối với cấu hình ban đầu, nó sẽ tạo một tệp cài đặt mới và chuyển nó sang ha-proxy. Trong trường hợp này, ha-proxy khởi động lại mà không làm mất bất kỳ kết nối nào và xử lý tải cho các dịch vụ mới cho phép phiên bản mới của ứng dụng của chúng tôi hoạt động.
Như bạn có thể thấy, mặc dù có rất nhiều thành phần nhưng không có gì phức tạp ở đây. Bạn chỉ cần chú ý hơn đến API và etcd. Tôi muốn kể cho bạn nghe về nhà triển khai nguồn mở mà chính chúng tôi sử dụng - Amdatu Kubernetes Deployer.
Nó là một công cụ để điều phối việc triển khai Kubernetes và có các tính năng sau:
- Triển khai Xanh/Xanh;
- thiết lập bộ cân bằng tải bên ngoài;
- quản lý mô tả triển khai;
- quản lý việc triển khai thực tế;
- kiểm tra chức năng Kiểm tra tình trạng trong quá trình triển khai;
- thực hiện các biến môi trường vào nhóm.
Deployer này được xây dựng dựa trên API Kubernetes và cung cấp API REST để quản lý các điều khiển và triển khai, cũng như API Websocket để truyền nhật ký trong quá trình triển khai.
Nó đưa dữ liệu cấu hình cân bằng tải vào etcd, do đó bạn không phải sử dụng ha-proxy với sự hỗ trợ sẵn có mà dễ dàng sử dụng tệp cấu hình cân bằng tải của riêng bạn. Amdatu Deployer được viết bằng Go, giống như Kubernetes và được Apache cấp phép.
Trước khi bắt đầu sử dụng phiên bản này của trình triển khai, tôi đã sử dụng bộ mô tả triển khai sau, trong đó chỉ định các tham số tôi cần.
Một trong những tham số quan trọng của mã này là bật cờ “useHealthCheck”. Chúng ta cần xác định rõ rằng việc kiểm tra độ chính xác phải được thực hiện trong quá trình triển khai. Cài đặt này có thể bị tắt khi quá trình triển khai sử dụng vùng chứa của bên thứ ba không cần xác minh. Bộ mô tả này cũng cho biết số lượng bản sao và URL giao diện người dùng mà ha-proxy cần. Cuối cùng là cờ đặc tả nhóm "podspec", gọi Kubernetes để biết thông tin về cấu hình cổng, hình ảnh, v.v. Đây là một bộ mô tả JSON khá đơn giản.
Một công cụ khác là một phần của dự án Amdatu nguồn mở là Deploymentctl. Nó có giao diện người dùng để định cấu hình triển khai, lưu trữ lịch sử triển khai và chứa webhooks để gọi lại từ người dùng và nhà phát triển bên thứ ba. Bạn không được sử dụng giao diện người dùng vì bản thân Amdatu Deployer là API REST, nhưng giao diện này có thể giúp bạn triển khai dễ dàng hơn nhiều mà không liên quan đến bất kỳ API nào. Deploymentctl được viết bằng OSGi/Vertx bằng Angular 2.
Bây giờ tôi sẽ trình diễn những điều trên trên màn hình bằng cách sử dụng bản ghi được ghi sẵn để bạn không phải chờ đợi. Chúng tôi sẽ triển khai một ứng dụng Go đơn giản. Đừng lo lắng nếu bạn chưa từng thử Go trước đây, đây là một ứng dụng rất đơn giản nên bạn có thể tìm ra.
Ở đây chúng tôi đang tạo một máy chủ HTTP chỉ phản hồi /health, vì vậy ứng dụng này chỉ kiểm tra việc kiểm tra tình trạng và không có gì khác. Nếu quá trình kiểm tra thành công, cấu trúc JSON hiển thị bên dưới sẽ được sử dụng. Nó chứa phiên bản ứng dụng sẽ được người triển khai triển khai, thông báo mà bạn nhìn thấy ở đầu tệp và kiểu dữ liệu boolean - cho dù ứng dụng của chúng tôi có hoạt động hay không.
Tôi đã gian lận một chút ở dòng cuối cùng, vì tôi đã đặt một giá trị boolean cố định ở đầu tệp, giá trị này trong tương lai sẽ giúp tôi triển khai ngay cả một ứng dụng “không lành mạnh”. Chúng ta sẽ giải quyết vấn đề này sau.
Vậy hãy bắt đầu. Trước tiên, chúng tôi kiểm tra sự hiện diện của bất kỳ nhóm đang chạy nào bằng lệnh ~ kubectl get pod và dựa trên việc không có phản hồi từ URL giao diện người dùng, chúng tôi đảm bảo rằng hiện không có hoạt động triển khai nào được thực hiện.
Tiếp theo trên màn hình bạn thấy giao diện Deploymentctl mà tôi đã đề cập, trong đó các tham số triển khai được đặt: không gian tên, tên ứng dụng, phiên bản triển khai, số lượng bản sao, URL giao diện người dùng, tên vùng chứa, hình ảnh, giới hạn tài nguyên, số cổng để kiểm tra tình trạng, v.v.. Giới hạn tài nguyên rất quan trọng vì chúng cho phép bạn sử dụng số lượng phần cứng tối đa có thể. Tại đây bạn cũng có thể xem nhật ký Triển khai.
Nếu bây giờ bạn lặp lại lệnh ~ kubectl get pod, bạn có thể thấy hệ thống “đóng băng” trong 20 giây, trong thời gian đó ha-proxy được cấu hình lại. Sau đó, nhóm khởi động và bản sao của chúng tôi có thể được nhìn thấy trong nhật ký triển khai.
Tôi đã bỏ 20 giây chờ đợi khỏi video và bây giờ bạn có thể thấy trên màn hình rằng phiên bản đầu tiên của ứng dụng đã được triển khai. Tất cả điều này được thực hiện chỉ bằng giao diện người dùng.
Bây giờ hãy thử phiên bản thứ hai. Để làm điều này, tôi thay đổi thông báo của ứng dụng từ "Xin chào, Kubernetes!" trên “Xin chào, Người triển khai!”, Hệ thống sẽ tạo hình ảnh này và đặt nó vào sổ đăng ký Docker, sau đó chúng ta chỉ cần nhấp lại vào nút “Triển khai” trong cửa sổ Deploymentctl. Trong trường hợp này, nhật ký triển khai sẽ tự động được khởi chạy theo cách tương tự như khi triển khai phiên bản đầu tiên của ứng dụng.
Lệnh ~ kubectl get pod cho thấy hiện tại có 2 phiên bản ứng dụng đang chạy, nhưng frontend cho thấy chúng ta vẫn đang chạy phiên bản 1.
Bộ cân bằng tải chờ quá trình kiểm tra tình trạng hoàn tất trước khi chuyển hướng lưu lượng truy cập sang phiên bản mới. Sau 20 giây, chúng tôi chuyển sang cuộn tròn và thấy rằng hiện tại chúng tôi đã triển khai phiên bản 2 của ứng dụng và phiên bản đầu tiên đã bị xóa.
Đây là việc triển khai một ứng dụng “lành mạnh”. Hãy xem điều gì sẽ xảy ra nếu đối với phiên bản mới của ứng dụng, tôi thay đổi tham số Khỏe mạnh từ đúng thành sai, tức là tôi cố gắng triển khai một ứng dụng không lành mạnh đã không vượt qua được quá trình kiểm tra tình trạng. Điều này có thể xảy ra nếu một số lỗi cấu hình xảy ra trong ứng dụng ở giai đoạn phát triển và nó được đưa vào sản xuất ở dạng này.
Như bạn có thể thấy, quá trình triển khai trải qua tất cả các bước trên và ~kubectl get pod cho thấy cả hai pod đều đang chạy. Nhưng không giống như lần triển khai trước, nhật ký hiển thị trạng thái hết thời gian chờ. Tức là do kiểm tra tình trạng không thành công nên phiên bản mới của ứng dụng không thể triển khai được. Kết quả là bạn thấy hệ thống đã quay lại sử dụng phiên bản cũ của ứng dụng và phiên bản mới đã được gỡ cài đặt.
Điểm hay của điều này là ngay cả khi bạn có một số lượng lớn yêu cầu đồng thời gửi đến ứng dụng, chúng thậm chí sẽ không nhận thấy thời gian ngừng hoạt động trong khi thực hiện quy trình triển khai. Nếu bạn kiểm tra ứng dụng này bằng cách sử dụng khung Gatling để gửi cho ứng dụng nhiều yêu cầu nhất có thể thì sẽ không có yêu cầu nào trong số này bị loại bỏ. Điều này có nghĩa là người dùng của chúng tôi thậm chí sẽ không nhận thấy các bản cập nhật phiên bản trong thời gian thực. Nếu thất bại, công việc sẽ tiếp tục trên phiên bản cũ, nếu thành công, người dùng sẽ chuyển sang phiên bản mới.
Chỉ có một điều có thể thất bại - nếu quá trình kiểm tra tình trạng thành công nhưng ứng dụng lại thất bại ngay khi khối lượng công việc được áp dụng cho nó, tức là sự cố sẽ chỉ xảy ra sau khi quá trình triển khai hoàn tất. Trong trường hợp này, bạn sẽ phải quay lại phiên bản cũ theo cách thủ công. Vì vậy, chúng tôi đã xem xét cách sử dụng Kubernetes với các công cụ nguồn mở được thiết kế cho nó. Quá trình triển khai sẽ dễ dàng hơn nhiều nếu bạn tích hợp các công cụ này vào quy trình Xây dựng/Triển khai của mình. Đồng thời, để bắt đầu triển khai, bạn có thể sử dụng giao diện người dùng hoặc tự động hóa hoàn toàn quy trình này bằng cách sử dụng, chẳng hạn như cam kết làm chủ.
Máy chủ xây dựng của chúng tôi sẽ tạo hình ảnh Docker, đẩy nó vào Docker Hub hoặc bất kỳ sổ đăng ký nào bạn sử dụng. Docker Hub hỗ trợ webhook nên chúng ta có thể kích hoạt triển khai từ xa thông qua Deployer theo cách minh họa ở trên. Bằng cách này, bạn có thể tự động hóa hoàn toàn việc triển khai ứng dụng của mình vào sản xuất tiềm năng.
Hãy chuyển sang chủ đề tiếp theo - mở rộng cụm Kubernetes. Lưu ý rằng lệnh kubectl là lệnh chia tỷ lệ. Với nhiều trợ giúp hơn, chúng tôi có thể dễ dàng tăng số lượng bản sao trong cụm hiện có của mình. Tuy nhiên, trong thực tế, chúng ta thường muốn tăng số lượng nút hơn là nhóm.
Đồng thời, bạn có thể cần tăng giờ làm việc trong giờ làm việc và vào ban đêm, để giảm chi phí dịch vụ của Amazon, bạn có thể cần giảm số lượng phiên bản ứng dụng đang chạy. Điều này không có nghĩa là chỉ cần mở rộng số lượng nhóm là đủ, bởi vì ngay cả khi một trong các nút không hoạt động, bạn vẫn sẽ phải trả tiền cho Amazon. Nghĩa là, cùng với việc mở rộng quy mô nhóm, bạn sẽ cần phải mở rộng quy mô số lượng máy được sử dụng.
Điều này có thể là một thách thức vì dù chúng ta sử dụng Amazon hay dịch vụ đám mây khác, Kubernetes không biết gì về số lượng máy đang được sử dụng. Nó thiếu một công cụ cho phép bạn mở rộng hệ thống ở cấp độ nút.
Vì vậy, chúng ta sẽ phải chăm sóc cả nút và nhóm. Chúng ta có thể dễ dàng mở rộng quy mô khởi chạy các nút mới bằng cách sử dụng API AWS và các máy nhóm Scaling để định cấu hình số lượng nút công nhân Kubernetes. Bạn cũng có thể sử dụng cloud-init hoặc tập lệnh tương tự để đăng ký các nút trong cụm Kubernetes.
Máy mới khởi động trong nhóm Scaling, tự khởi tạo dưới dạng nút, đăng ký trong sổ đăng ký chính và bắt đầu hoạt động. Sau này, bạn có thể tăng số lượng bản sao để sử dụng trên các nút kết quả. Việc thu nhỏ quy mô đòi hỏi nhiều nỗ lực hơn vì bạn cần đảm bảo rằng bước như vậy không dẫn đến việc phá hủy các ứng dụng đang chạy sau khi tắt các máy “không cần thiết”. Để ngăn chặn tình huống như vậy, bạn cần đặt các nút ở trạng thái “không thể lập lịch”. Điều này có nghĩa là bộ lập lịch mặc định sẽ bỏ qua các nút này khi lên lịch cho các nhóm DaemonSet. Bộ lập lịch sẽ không xóa bất kỳ thứ gì khỏi các máy chủ này nhưng cũng sẽ không khởi chạy vùng chứa mới nào ở đó. Bước tiếp theo là loại bỏ nút cống, nghĩa là chuyển các nhóm đang chạy từ nó sang máy khác hoặc các nút khác có đủ công suất cho việc này. Khi bạn đã đảm bảo rằng không còn bất kỳ vùng chứa nào trên các nút này nữa, bạn có thể xóa chúng khỏi Kubernetes. Sau đó, chúng sẽ không còn tồn tại đối với Kubernetes. Tiếp theo, bạn cần sử dụng API AWS để vô hiệu hóa các nút hoặc máy không cần thiết.
Bạn có thể sử dụng Amdatu Scalard, một công cụ mở rộng quy mô nguồn mở khác tương tự như API AWS. Nó cung cấp CLI để thêm hoặc xóa các nút trong một cụm. Tính năng thú vị của nó là khả năng định cấu hình bộ lập lịch bằng tệp json sau.
Mã hiển thị làm giảm một nửa công suất của cụm trong suốt thời gian ban đêm. Nó định cấu hình cả số lượng bản sao có sẵn và dung lượng mong muốn của cụm Amazon. Sử dụng bộ lập lịch này sẽ tự động giảm số lượng nút vào ban đêm và tăng chúng vào buổi sáng, tiết kiệm chi phí sử dụng các nút từ dịch vụ đám mây như Amazon. Tính năng này không được tích hợp trong Kubernetes, nhưng việc sử dụng Scalard sẽ cho phép bạn mở rộng nền tảng này theo cách bạn muốn.
Tôi muốn chỉ ra rằng nhiều người nói với tôi, “Điều đó tốt thôi, nhưng còn cơ sở dữ liệu của tôi, vốn thường ở trạng thái tĩnh thì sao?” Làm cách nào bạn có thể chạy thứ gì đó như thế này trong môi trường năng động như Kubernetes? Theo tôi, bạn không nên làm điều này, bạn không nên cố gắng chạy kho dữ liệu trong Kubernetes. Điều này là có thể về mặt kỹ thuật và có các hướng dẫn trên Internet về chủ đề này, nhưng nó sẽ làm phức tạp nghiêm trọng cuộc sống của bạn.
Đúng, có một khái niệm về các cửa hàng liên tục trong Kubernetes và bạn có thể thử chạy các kho dữ liệu như Mongo hoặc MySQL, nhưng đây là một công việc khá tốn công sức. Điều này là do kho dữ liệu không hỗ trợ đầy đủ sự tương tác với môi trường động. Hầu hết các cơ sở dữ liệu đều yêu cầu cấu hình đáng kể, bao gồm cả cấu hình thủ công của cụm, không thích tính năng tự động điều chỉnh tỷ lệ và những thứ tương tự khác.
Do đó, bạn không nên làm phức tạp cuộc sống của mình bằng cách cố gắng vận hành kho dữ liệu trong Kubernetes. Tổ chức công việc của họ theo cách truyền thống bằng cách sử dụng các dịch vụ quen thuộc và chỉ cần cung cấp cho Kubernetes khả năng sử dụng chúng.
Để kết thúc chủ đề, tôi muốn giới thiệu với bạn nền tảng Cloud RTI dựa trên Kubernetes mà nhóm của tôi đang nghiên cứu. Nó cung cấp tính năng ghi nhật ký tập trung, giám sát ứng dụng và cụm cũng như nhiều tính năng hữu ích khác sẽ có ích. Nó sử dụng nhiều công cụ nguồn mở khác nhau như Grafana để hiển thị giám sát.
Đã có câu hỏi về lý do tại sao nên sử dụng bộ cân bằng tải ha-proxy với Kubernetes. Câu hỏi hay vì hiện tại có 2 cấp độ cân bằng tải. Dịch vụ Kubernetes vẫn cư trú trên các địa chỉ IP ảo. Bạn không thể sử dụng chúng cho các cổng trên máy chủ bên ngoài vì nếu Amazon làm máy chủ đám mây của họ quá tải, địa chỉ sẽ thay đổi. Đây là lý do tại sao chúng tôi đặt ha-proxy trước các dịch vụ - để tạo cấu trúc tĩnh hơn để lưu lượng truy cập giao tiếp liền mạch với Kubernetes.
Một câu hỏi hay khác là làm cách nào bạn có thể xử lý các thay đổi trong lược đồ cơ sở dữ liệu khi thực hiện triển khai xanh lam/xanh lục? Thực tế là bất kể việc sử dụng Kubernetes như thế nào, việc thay đổi lược đồ cơ sở dữ liệu là một nhiệm vụ khó khăn. Bạn cần đảm bảo rằng lược đồ cũ và mới tương thích với nhau, sau đó bạn có thể cập nhật cơ sở dữ liệu và sau đó tự cập nhật các ứng dụng. Bạn có thể trao đổi nóng cơ sở dữ liệu và sau đó cập nhật ứng dụng. Tôi biết những người đã khởi động một cụm cơ sở dữ liệu hoàn toàn mới với một lược đồ mới, đây là một tùy chọn nếu bạn có một cơ sở dữ liệu không có sơ đồ như Mongo, nhưng dù sao thì đó cũng không phải là một nhiệm vụ dễ dàng. Nếu bạn không còn thắc mắc gì nữa, cảm ơn bạn đã quan tâm!
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è, , 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: (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 ở Hà Lan! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - từ $99! Đọc về
Nguồn: www.habr.com