nền tảng cho phép bạn hợp lý hóa việc tạo , bao gồm cả cơ sở hạ tầng của các nhà cung cấp dịch vụ đám mây, trên nền tảng ảo hóa hoặc trong các hệ thống kim loại trần. Để tạo ra một nền tảng thực sự dựa trên đám mây, chúng tôi phải kiểm soát chặt chẽ tất cả các yếu tố được sử dụng và do đó tăng độ tin cậy của quy trình tự động hóa phức tạp.
Giải pháp hiển nhiên là sử dụng Red Hat Enterprise Linux CoreOS (một biến thể của Red Hat Enterprise Linux) và CRI-O làm tiêu chuẩn và đây là lý do...
Vì chủ đề chèo thuyền là một chủ đề rất hay để tìm ra sự tương đồng khi giải thích hoạt động của Kubernetes và container, nên hãy thử nói về các vấn đề kinh doanh mà CoreOS và CRI-O giải quyết bằng một ví dụ . Năm 1803, Marc Brunel được giao nhiệm vụ sản xuất 100 khối giàn khoan để đáp ứng nhu cầu ngày càng tăng của hải quân Anh. Khối giàn là một loại giàn được sử dụng để gắn dây vào cánh buồm. Cho đến đầu thế kỷ 19, những khối này được làm bằng tay, nhưng Brunel đã cố gắng tự động hóa sản xuất và bắt đầu sản xuất các khối tiêu chuẩn bằng máy công cụ. Tự động hóa quá trình này có nghĩa là các khối tạo ra về cơ bản giống hệt nhau, có thể dễ dàng thay thế nếu bị hỏng và có thể được sản xuất với số lượng lớn.
Bây giờ hãy tưởng tượng nếu Brunel phải thực hiện công việc này cho 20 mẫu tàu khác nhau (phiên bản Kubernetes) và cho năm hành tinh khác nhau có dòng hải lưu và gió hoàn toàn khác nhau (nhà cung cấp đám mây). Ngoài ra, yêu cầu tất cả các tàu (cụm OpenShift), bất kể hành tinh nào được thực hiện việc điều hướng, theo quan điểm của thuyền trưởng (người điều hành quản lý hoạt động của cụm) đều phải hành xử giống nhau. Để tiếp tục so sánh hàng hải, các thuyền trưởng không quan tâm đến loại khối gian lận (CRI-O) nào được sử dụng trên tàu của họ - điều quan trọng đối với họ là những khối này bền và đáng tin cậy.
OpenShift 4, với tư cách là một nền tảng đám mây, phải đối mặt với thách thức kinh doanh tương tự. Các nút mới phải được tạo tại thời điểm tạo cụm, trong trường hợp xảy ra lỗi ở một trong các nút hoặc khi mở rộng quy mô cụm. Khi một nút mới được tạo và khởi tạo, các thành phần máy chủ quan trọng, bao gồm CRI-O, phải được cấu hình tương ứng. Giống như bất kỳ hoạt động sản xuất nào khác, “nguyên liệu thô” phải được cung cấp ngay từ đầu. Đối với tàu, nguyên liệu thô là kim loại và gỗ. Tuy nhiên, trong trường hợp tạo máy chủ để triển khai các vùng chứa trong cụm OpenShift 4, bạn cần có các tệp cấu hình và máy chủ do API cung cấp làm đầu vào. OpenShift sau đó sẽ cung cấp mức độ tự động hóa cần thiết trong toàn bộ vòng đời, cung cấp hỗ trợ sản phẩm cần thiết cho người dùng cuối và do đó thu hồi khoản đầu tư vào nền tảng.
OpenShift 4 được tạo ra nhằm cung cấp khả năng cập nhật hệ thống một cách thuận tiện trong toàn bộ vòng đời của nền tảng (đối với phiên bản 4.X) cho tất cả các nhà cung cấp điện toán đám mây lớn, nền tảng ảo hóa và thậm chí cả hệ thống kim loại trần. Để làm được điều này, các nút phải được tạo trên cơ sở các phần tử có thể hoán đổi cho nhau. Khi một cụm yêu cầu phiên bản Kubernetes mới, cụm đó cũng nhận được phiên bản CRI-O tương ứng trên CoreOS. Vì phiên bản CRI-O được liên kết trực tiếp với Kubernetes nên điều này giúp đơn giản hóa đáng kể mọi hoán vị cho mục đích thử nghiệm, khắc phục sự cố hoặc hỗ trợ. Ngoài ra, cách tiếp cận này còn giúp giảm chi phí cho người dùng cuối và Red Hat.
Đây là một cách suy nghĩ mới về cơ bản về các cụm Kubernetes và đặt nền tảng cho việc lập kế hoạch cho một số tính năng mới rất hữu ích và hấp dẫn. CRI-O (Giao diện thời gian chạy vùng chứa - Sáng kiến vùng chứa mở, viết tắt CRI-OCI) hóa ra là lựa chọn thành công nhất để tạo hàng loạt các nút cần thiết để hoạt động với OpenShift. CRI-O sẽ thay thế công cụ Docker đã sử dụng trước đây, cung cấp cho người dùng OpenShift – vâng, bạn đã nghe đúng – một công cụ chứa nhàm chán được tạo riêng để làm việc với Kubernetes.
Thế giới container mở
Thế giới đã chuyển sang sử dụng container mở từ lâu. Dù ở Kubernetes hay ở cấp độ thấp hơn, dẫn đến một hệ sinh thái đổi mới ở mọi cấp độ.
Tất cả bắt đầu với việc tạo ra Sáng kiến Container mở . Ở giai đoạn đầu của công việc này, các thông số kỹ thuật của container đã được hình thành и . Điều này đảm bảo rằng các công cụ có thể sử dụng một tiêu chuẩn duy nhất và một định dạng thống nhất để làm việc với họ. Thông số kỹ thuật sau đó đã được thêm vào , cho phép người dùng dễ dàng chia sẻ .
Cộng đồng Kubernetes sau đó đã phát triển một tiêu chuẩn duy nhất cho giao diện có thể cắm được, được gọi là . Nhờ đó, người dùng Kubernetes có thể kết nối nhiều công cụ khác nhau để hoạt động với các container ngoài Docker.
Các kỹ sư tại Red Hat và Google nhận thấy nhu cầu của thị trường về công cụ vùng chứa có thể chấp nhận các yêu cầu Kubelet qua giao thức CRI và đã giới thiệu các vùng chứa tương thích với thông số kỹ thuật OCI được đề cập ở trên. Vì thế . Nhưng xin lỗi, chẳng phải chúng tôi đã nói rằng tài liệu này sẽ dành riêng cho CRI-O sao? Thực ra là như vậy, chỉ với việc phát hành dự án được đổi tên thành CRI-O.
Hình 1.
Đổi mới với CRI-O và CoreOS
Với sự ra mắt của nền tảng OpenShift 4, nó đã được thay đổi , được sử dụng theo mặc định trong nền tảng và Docker được thay thế bằng CRI-O, cung cấp một môi trường tiết kiệm chi phí, ổn định, đơn giản và nhàm chán để chạy một container phát triển song song với Kubernetes. Điều này giúp đơn giản hóa rất nhiều việc hỗ trợ và cấu hình cụm. Cấu hình của công cụ chứa và máy chủ cũng như việc quản lý chúng trở nên tự động hóa trong OpenShift 4.
Đợi đã, thế này là thế nào?
Đúng vậy, với sự ra đời của OpenShift 4, không còn cần phải kết nối với từng máy chủ riêng lẻ và cài đặt công cụ vùng chứa, định cấu hình bộ lưu trữ, định cấu hình máy chủ tìm kiếm hoặc định cấu hình mạng. Nền tảng OpenShift 4 đã được thiết kế lại hoàn toàn để sử dụng không chỉ về mặt ứng dụng của người dùng cuối mà còn về các hoạt động cơ bản ở cấp nền tảng như triển khai hình ảnh, định cấu hình hệ thống hoặc cài đặt các bản cập nhật.
Kubernetes luôn cho phép người dùng quản lý ứng dụng bằng cách xác định trạng thái mong muốn và sử dụng , để đảm bảo rằng trạng thái thực tế khớp với trạng thái mục tiêu nhất có thể. Cái này mở ra những cơ hội lớn từ cả góc độ phát triển và vận hành. Nhà phát triển có thể xác định trạng thái được yêu cầu bằng cách cho toán tử dưới dạng tệp YAML hoặc JSON, sau đó toán tử có thể tạo phiên bản ứng dụng cần thiết trong môi trường sản xuất và trạng thái hoạt động của phiên bản này sẽ hoàn toàn tương ứng với trạng thái được chỉ định.
Bằng cách sử dụng Toán tử trong nền tảng, OpenShift 4 mang mô hình mới này (sử dụng khái niệm tập hợp và trạng thái thực tế) vào việc quản lý RHEL CoreOS và CRI-O. Các tác vụ định cấu hình và quản lý các phiên bản của hệ điều hành và công cụ chứa được tự động hóa bằng cách sử dụng cái gọi là . MCO đơn giản hóa đáng kể công việc của quản trị viên cụm, về cơ bản là tự động hóa các giai đoạn cài đặt cuối cùng cũng như các hoạt động sau cài đặt tiếp theo (hoạt động của ngày thứ hai). Tất cả điều này làm cho OpenShift 4 trở thành một nền tảng đám mây thực sự. Chúng ta sẽ đi vào vấn đề này sau một chút.
Chạy container
Người dùng đã có cơ hội sử dụng công cụ CRI-O trong nền tảng OpenShift kể từ phiên bản 3.7 ở trạng thái Xem trước công nghệ và từ phiên bản 3.9 ở trạng thái Có sẵn chung (hiện được hỗ trợ). Ngoài ra, Red Hat sử dụng ồ ạt trong OpenShift Online kể từ phiên bản 3.10. Tất cả điều này cho phép nhóm làm việc trên CRI-O có được kinh nghiệm sâu rộng trong việc khởi chạy hàng loạt container trên các cụm Kubernetes lớn. Để hiểu cơ bản về cách Kubernetes sử dụng CRI-O, chúng ta hãy xem hình minh họa sau đây cho thấy cách kiến trúc hoạt động.
Cơm. 2. Cách các container hoạt động trong cụm Kubernetes
CRI-O đơn giản hóa việc tạo các máy chủ vùng chứa mới bằng cách đồng bộ hóa toàn bộ cấp cao nhất khi khởi tạo các nút mới và khi phát hành các phiên bản mới của nền tảng OpenShift. Bản sửa đổi toàn bộ nền tảng cho phép cập nhật/khôi phục giao dịch, đồng thời ngăn chặn sự bế tắc trong các phần phụ thuộc giữa lõi đuôi container, công cụ chứa, nút (Kubelets) và nút Kubernetes Master. Bằng cách quản lý tập trung tất cả các thành phần nền tảng, với khả năng kiểm soát và lập phiên bản, luôn có một đường dẫn rõ ràng từ trạng thái A đến trạng thái B. Điều này giúp đơn giản hóa quá trình cập nhật, cải thiện tính bảo mật, cải thiện báo cáo hiệu suất và giúp giảm chi phí cập nhật và cài đặt phiên bản mới .
Thể hiện sức mạnh của các yếu tố thay thế
Như đã đề cập trước đó, việc sử dụng Machine Config Operator để quản lý máy chủ container và công cụ container trong OpenShift 4 cung cấp một cấp độ tự động hóa mới mà trước đây không thể có trên nền tảng Kubernetes. Để minh họa các tính năng mới, chúng tôi sẽ chỉ ra cách bạn có thể thực hiện các thay đổi đối với tệp crio.conf. Để tránh bị nhầm lẫn bởi thuật ngữ, hãy cố gắng tập trung vào kết quả.
Trước tiên, hãy tạo cái được gọi là cấu hình thời gian chạy vùng chứa - Cấu hình thời gian chạy vùng chứa. Hãy coi nó như một tài nguyên Kubernetes đại diện cho cấu hình cho CRI-O. Trên thực tế, đây là phiên bản chuyên biệt của thứ gọi là MachineConfig, là bất kỳ cấu hình nào được triển khai cho máy RHEL CoreOS như một phần của cụm OpenShift.
Tài nguyên tùy chỉnh này, được gọi là ContainerRuntimeConfig, được tạo để giúp quản trị viên cụm định cấu hình CRI-O dễ dàng hơn. Công cụ này đủ mạnh để chỉ có thể áp dụng cho một số nút nhất định tùy thuộc vào cài đặt MachineConfigPool. Hãy nghĩ về nó như một nhóm máy phục vụ cùng một mục đích.
Lưu ý hai dòng cuối cùng mà chúng ta sẽ thay đổi trong tệp /etc/crio/crio.conf. Hai dòng này rất giống với các dòng trong file crio.conf, đó là:
vi ContainerRuntimeConfig.yaml
Kết luận:
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
name: set-log-and-pid
spec:
machineConfigPoolSelector:
matchLabels:
debug-crio: config-log-and-pid
containerRuntimeConfig:
pidsLimit: 2048
logLevel: debug
Bây giờ hãy đẩy tệp này vào cụm Kubernetes và kiểm tra xem nó đã thực sự được tạo chưa. Xin lưu ý rằng hoạt động này hoàn toàn giống với bất kỳ tài nguyên Kubernetes nào khác:
oc create -f ContainerRuntimeConfig.yaml
oc get ContainerRuntimeConfig
Kết luận:
NAME AGE
set-log-and-pid 22h
Sau khi tạo ContainerRuntimeConfig, chúng ta cần sửa đổi một trong các MachineConfigPool để báo hiệu cho Kubernetes rằng chúng ta muốn áp dụng cấu hình này cho một nhóm máy cụ thể trong cụm. Trong trường hợp này, chúng tôi sẽ thay đổi MachineConfigPool cho các nút chính:
oc edit MachineConfigPool/master
Kết luận (để rõ ràng, bản chất chính còn lại):
...
metadata:
creationTimestamp: 2019-04-10T23:42:28Z
generation: 1
labels:
debug-crio: config-log-and-pid
operator.machineconfiguration.openshift.io/required-for-upgrade: ""
...
Tại thời điểm này, MCO bắt đầu tạo tệp crio.conf mới cho cụm. Trong trường hợp này, có thể xem tệp cấu hình hoàn chỉnh hoàn chỉnh bằng API Kubernetes. Hãy nhớ rằng, ContainerRuntimeConfig chỉ là một phiên bản chuyên dụng của MachineConfig nên chúng ta có thể xem kết quả bằng cách xem các dòng liên quan trong MachineConfigs:
oc get MachineConfigs | grep rendered
Kết luận:
rendered-master-c923f24f01a0e38c77a05acfd631910b 4.0.22-201904011459-dirty 2.2.0 16h
rendered-master-f722b027a98ac5b8e0b41d71e992f626 4.0.22-201904011459-dirty 2.2.0 4m
rendered-worker-9777325797fe7e74c3f2dd11d359bc62 4.0.22-201904011459-dirty 2.2.0 16h
Xin lưu ý rằng tệp cấu hình kết quả cho các nút chính là phiên bản mới hơn cấu hình ban đầu. Để xem nó, hãy chạy lệnh sau. Nhân tiện, chúng tôi lưu ý rằng đây có lẽ là một trong những câu nói hay nhất trong lịch sử của Kubernetes:
python3 -c "import sys, urllib.parse; print(urllib.parse.unquote(sys.argv[1]))" $(oc get MachineConfig/rendered-master-f722b027a98ac5b8e0b41d71e992f626 -o YAML | grep -B4 crio.conf | grep source | tail -n 1 | cut -d, -f2) | grep pid
Kết luận:
pids_limit = 2048
Bây giờ hãy đảm bảo rằng cấu hình đã được áp dụng cho tất cả các nút chính. Đầu tiên chúng ta nhận được danh sách các nút trong cụm:
oc get node | grep master
Output:
ip-10-0-135-153.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-154-0.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
ip-10-0-166-79.us-east-2.compute.internal Ready master 23h v1.12.4+509916ce1
Bây giờ hãy xem tập tin đã cài đặt. Bạn sẽ thấy tệp đã được cập nhật với các giá trị mới cho lệnh pid và debug mà chúng tôi đã chỉ định trong tài nguyên ContainerRuntimeConfig. Bản thân sự sang trọng:
oc debug node/ip-10-0-135-153.us-east-2.compute.internal — cat /host/etc/crio/crio.conf | egrep 'debug||pid’
Kết luận:
...
pids_limit = 2048
...
log_level = "debug"
...
Tất cả những thay đổi này đối với cụm được thực hiện mà không cần chạy SSH. Tất cả công việc được thực hiện bằng cách truy cập nút chính Kuberentes. Nghĩa là, các tham số mới này chỉ được định cấu hình trên các nút chính. Các nút công nhân không thay đổi, điều này thể hiện lợi ích của phương pháp Kubernetes trong việc sử dụng các trạng thái thực tế và được chỉ định liên quan đến máy chủ vùng chứa và công cụ vùng chứa có các phần tử có thể hoán đổi cho nhau.
Ví dụ trên cho thấy khả năng thực hiện các thay đổi đối với cụm OpenShift Container Platform 4 nhỏ với ba nút sản xuất hoặc cụm sản xuất khổng lồ với 3000 nút. Trong mọi trường hợp, khối lượng công việc sẽ như nhau - và rất nhỏ - chỉ cần định cấu hình tệp ContainerRuntimeConfig và thay đổi một nhãn trong MachineConfigPool. Và bạn có thể thực hiện việc này với bất kỳ phiên bản nào của OpenShift Container Platform 4.X chạy Kubernetes trong suốt vòng đời của nó.
Thông thường, các công ty công nghệ phát triển nhanh đến mức chúng tôi không thể giải thích được tại sao chúng tôi lại chọn một số công nghệ nhất định cho các thành phần cơ bản. Công cụ container trước đây là thành phần mà người dùng tương tác trực tiếp. Vì sự phổ biến của container bắt đầu một cách tự nhiên với sự ra đời của động cơ container nên người dùng thường tỏ ra quan tâm đến chúng. Đây là một lý do khác khiến Red Hat chọn CRI-O. Các vùng chứa đang phát triển với trọng tâm là điều phối và chúng tôi nhận thấy rằng CRI-O mang lại trải nghiệm tốt nhất khi làm việc với OpenShift 4.
Nguồn: www.habr.com