Một trong những việc đầu tiên tôi làm sau khi triển khai cụm Kubernetes là cài đặt trình điều khiển CSI để cung cấp bộ nhớ lưu trữ liên tục cho khối lượng công việc của mình; kết hợp với quy trình làm việc GitOps; chỉ mất vài giây để có thể chạy khối lượng công việc có trạng thái.

Quy trình GitOps chỉ là một vài nguyên tắc sau :

Git là nguồn duy nhất của sự thật
Tài nguyên được khai báo rõ ràng
Kéo dựa trên

Tuy nhiên, để đảm bảo quy trình diễn ra suôn sẻ, bạn phải chắc chắn rằng ứng dụng bạn sẽ quản lý bằng GitOps tuân thủ các nguyên tắc này.

Bài viết này mô tả cách sử dụng giải pháp Microsoft Azure Arc GitOps để triển khai trình điều khiển Dell CSI cho Dell PowerMax và các Mô-đun lưu trữ container (CSM) liên kết.

Nền tảng chúng tôi sẽ sử dụng để triển khai quy trình làm việc GitOps là Azure Arc với GitHub. Tuy nhiên, các giải pháp khác có thể sử dụng các tác nhân Kubernetes như Argo CD , Flux CD và GitLab .

Azure GitOps được xây dựng dựa trên Flux CD.

Cài đặt Azure Arc

Bước đầu tiên là đưa cụm Kubernetes hiện có của bạn vào cổng thông tin Azure.

Rõ ràng là Azure agent sẽ kết nối với Internet. Trong trường hợp của tôi, việc cài đặt Arc agent không thành công từ mạng Dell với lỗi được mô tả ở đây: https://docs.microsoft.com/en-us/answers/questions/734383/connect-openshift-cluster-to-azure-arc-secret-34ku.html

Một số URL nhất định (kể cả khi bỏ qua proxy của công ty) không hoạt động tốt khi giao tiếp với Azure. Tôi đã thấy một số dịch vụ nhận được chứng chỉ tự ký, gây ra sự cố.

Giải pháp cho tôi là đặt một proxy trung gian trong suốt giữa cụm Kubernetes và cụm công ty. Theo cách đó, chúng ta có thể kiểm soát tốt hơn các phản hồi do proxy đưa ra.

Trong ví dụ này, chúng tôi cài đặt Squid trên một hộp chuyên dụng với sự trợ giúp của Docker. Để làm cho nó hoạt động, tôi đã sử dụng hình ảnh Squid của Ubuntu và đảm bảo rằng các yêu cầu Kubernetes là trực tiếp với sự trợ giúp của always_direct :

docker chạy -d --name squid-container ubuntu/squid:5.2-22.04_beta ; docker cp squid-container:/etc/squid/squid.conf ./ ; egrep -v '^#' squid.conf > my_squid.conf
docker rm -f squid-container

Sau đó thêm phần sau:

acl k8s cổng 6443 # k8s https
luôn_trực tiếp cho phép k8s

Bây giờ bạn có thể cài đặt tác nhân theo hướng dẫn sau: https://docs.microsoft.com/en-us/azure/azure-arc/kubernetes/quickstart-connect-cluster?tabs=azure-cli#connect-using-an-outbound-proxy-server .

xuất HTTP_PROXY=http://mysquid-proxy.dell.com:3128
xuất HTTPS_PROXY=http://mysquid-proxy.dell.com:3128
xuất NO_PROXY=https://kubernetes.local:6443
 
az connectedk8s kết nối --tên AzureArcCorkDevCluster \
                        --nhóm tài nguyên AzureArcTestFlorian \
                        --proxy-https http://mysquid-proxy.dell.com:3128 \
                        --proxy-http http://mysquid-proxy.dell.com:3128 \
                        --proxy-skip-range 10.0.0.0/8,kubernetes.default.svc,.svc.cluster.local,.svc \
                        --proxy-cert /etc/ssl/certs/ca-bundle.crt

Nếu mọi thứ hoạt động tốt, bạn sẽ thấy cụm có thông tin chi tiết từ cổng thông tin Azure:

Thêm tài khoản dịch vụ để có khả năng hiển thị tốt hơn trong cổng thông tin Azure

Để được hưởng lợi từ tất cả các tính năng mà Azure Arc cung cấp, hãy cấp cho tác nhân quyền truy cập vào cụm.

Bước đầu tiên là tạo một tài khoản dịch vụ:

kubectl tạo serviceaccount azure-user
kubectl tạo clusterrolebinding demo-user-binding --clusterrole cluster-admin --serviceaccount mặc định:azure-user
kubectl áp dụng -f - <<EOF
Phiên bản api: v1
loại: Bí mật
siêu dữ liệu:
  tên: azure-user-secret
  chú thích:
    kubernetes.io/service-account.name: người dùng azure
loại: kubernetes.io/service-account-token
Cuối cùng

Sau đó, từ Giao diện người dùng Azure, khi bạn được nhắc cung cấp mã thông báo, bạn có thể lấy mã thông báo đó như sau:

kubectl lấy bí mật azure-user-secret -o jsonpath='{$.data.token}' | base64 -d | sed $'s/$/\\\n/g'

Sau đó dán mã thông báo vào Giao diện người dùng Azure.

Cài đặt tác nhân GitOps

Việc cài đặt tác nhân GitOps có thể được thực hiện bằng CLI hoặc trong cổng thông tin Azure.

Tính đến thời điểm hiện tại, tài liệu của Microsoft trình bày chi tiết về việc triển khai sử dụng CLI; chúng ta hãy xem cách nó hoạt động với cổng thông tin Azure:

Tổ chức kho lưu trữ

Tổ chức kho lưu trữ Git là một phần quan trọng của kiến trúc GitOps. Nó phụ thuộc rất nhiều vào cách tổ chức các nhóm nội bộ, mức độ thông tin bạn muốn công khai và chia sẻ, vị trí của các cụm khác nhau, v.v.

Trong trường hợp của chúng tôi, yêu cầu là kết nối nhiều cụm Kubernetes do các nhóm khác nhau sở hữu với một vài hệ thống PowerMax chỉ sử dụng trình điều khiển CSI mới nhất và tốt nhất cùng CSM liên kết cho PowerMax.

Do đó, phương pháp monorepo là phù hợp.

Tổ chức này tuân theo cấu trúc sau:

├── ứng dụng

│ ├── cơ sở

│ └── lớp phủ

│ ├── phát triển nút chai

│ │ ├── nhà phát triển

│ │ └── sản phẩm

│ └── sản xuất nút chai

│ └── sản phẩm

├── cụm

│ ├── phát triển nút chai

│ └── sản xuất nút chai

└── cơ sở hạ tầng

├── trình quản lý chứng chỉ

├── sao chép csm

├── trình chụp ảnh bên ngoài

└── sức mạnh tối đa

ứng dụng: Chứa các ứng dụng sẽ được triển khai trên các cụm.
Chúng tôi có các lớp phủ khác nhau cho mỗi cụm.
cụm: Thường chứa cấu hình chính Flux CD dành riêng cho cụm; khi sử dụng Azure Arc, không cần cấu hình nào cả.
Cơ sở hạ tầng: Bao gồm các triển khai được sử dụng để chạy các dịch vụ cơ sở hạ tầng; chúng chung cho mọi cụm.
- cert-manager: Là một sự phụ thuộc của powermax reverse-proxy
- csm-replication: Là một phụ thuộc của powermax để hỗ trợ sao chép SRDF
- external-snapshotter: Là sự phụ thuộc của powermax vào snapshot
- powermax: Chứa cài đặt trình điều khiển

Bạn có thể xem tất cả các tệp trong https://github.com/coulof/fluxcd-csm-powermax .

Lưu ý : GitOps agent đi kèm với hỗ trợ đa thuê bao ; do đó, chúng ta không thể tham chiếu chéo các đối tượng giữa các không gian tên. Kustomization và HelmRelease phải được tạo trong cùng một không gian tên với agent (ở đây là flux-system ) và có targetNamespace tương ứng đến tài nguyên cần cài đặt.

Phần kết luận

Bài viết này là bài đầu tiên trong loạt bài khám phá quy trình làm việc GitOps. Tiếp theo, chúng ta sẽ xem cách quản lý ứng dụng và lưu trữ liên tục bằng quy trình làm việc GitOps, cách nâng cấp các mô-đun, v.v.