Tìm hiểu tự động hóa triển khai cho Applications trên Kubernetes (Phần 2)

toannm

Bài này là phần thứ hai của loạt bài viết cùng chủ đề. Đọc phần đầu tại đây .

Trong phần đầu đã tìm hiểu về kubectl và cách triển khai nhanh chóng và dễ dàng, tuy nhiên tại sao một số edge cases nhất định gây khó khăn cho việc xây dựng tự động hóa mạnh mẽ trên đó. Phần thứ hai này sẽ tìm hiểu việc sử dụng Kustomize và Terraform để tự động hóa triển khai application và lý do cần sử dụng cả hai.

PSfish.jpg

Tại sao nên dùng Kustomize và Terraform?

Cần có đa môi trường là yêu cầu gần như phổ biến cho applications. Số lượng chính xác của môi trường và tên của chúng có xu hướng khác nhau giữa các teams và applications. Nhưng mỗi team thường có nhiều hơn một môi trường. Kustomize và mô hình kế thừa của nó được xây dựng có mục đích hỗ trợ cho trường hợp sử dụng này.

Cấu hình Application có thể theo dõi trong một cơ sở mà tất cả environment overlays kế thừa từ đó và ghi đè lên các phần cụ thể của môi trường. Cung cấp cách mô tả độc đáo và đẹp mắt đơn giản để duy trì các Kubernetes manifests trong kho lưu trữ.

Đó là lý do tại sao nên sử dụng Kustomize.

Nhưng Kustomize chỉ tùy chỉnh cấu hình và để lại thành kubectl áp dụng cấu hình cho cluster. Điều này sẽ tạo ra các edge cases tương tự.

Và đó là lý do tại sao cần sử dụng Terraform, nó rất hiệu quả trong việc giải quyết những edge cases đó. Tính năng cốt lõi của Terraform là xác định plan làm thế nào để có được tài nguyên phù hợp với cấu hình mới, dựa trên cấu hình được cung cấp, thông tin mà nó theo dõi trong state và tài nguyên hiện có trong cluster. Đối với mỗi tài nguyên, plan sẽ xác định nếu cần tạo, xóa hoặc cập nhật. Và trong trường hợp cập nhật, nó có thể cập nhật tài nguyên tại chỗ hoặc xóa và tạo lại nếu cần thiết.

Để hỗ trợ các cloud providers hoặc platforms khác nhau như Kubernetes, thì Terraform yêu cầu có provider. Kubernetes provider chính thức xác định lược đồ của mỗi tài nguyên trong Terraform. Điều này mất rất nhiều công sức và khiến một số tài nguyên Kubernetes không được hỗ trợ và hoàn toàn không hoạt động với những thành phần khác, chẳng hạn như CRDs.

Một vấn đề khác gây tranh cãi là Terraform Kubernetes provider yêu cầu users chỉ định tài nguyên của họ ở Terraform’s HCL format thay vì Kubernetes’ YAML.

Không có lược đồ cho từng tài nguyên thì không thể sử dụng Terraform để chỉnh sửa Kubernetes manifests. Nhưng đã có Kustomize giải quyết vấn đề đó. Tất cả những gì cần có là provider cho phép thay thế kubectl sau khi Kustomize hoàn thành nhiệm vụ của mình.

Terraform Provider Kustomize

Để tận dụng tốt nhất cả hai lĩnh vực, cần kết hợp Kustomize để tùy chỉnh Kubernetes manifests cho các môi trường khác nhau và Terraform áp dụng tự động các thay đổi cho cluster sử dụng Terraform provider for Kustomize.

Với provider này, được cung cấp một đường dẫn đến cơ sở Kustomize hoặc overlay thực hiện 'xây dựng kustomize ' và bằng cách sử dụng dynamic client-go, xử lý bất kỳ loại tài nguyên nào từ Kustomize output.

Trong triển khai, provider xác định tài nguyên cần được tạo, xóa, cập nhật tại chỗ hoặc xóa và được tạo lại bằng server-side dry run. Điều này ngăn việc xác nhận thiếu đầy đủ và thay đổi đối với các edge cases trường bất biến. Việc lược bớt các tài nguyên trước đó cũng được xử lý, bằng cách theo dõi cấu hình đã gửi trước đó ở Terraform state.

Kết quả plan cho phép xem xét các thay đổi trên mỗi tài nguyên trước khi áp dụng. Trong khi áp dụng, provider kết nối vào khả năng của Terraform để xử lý tính nhất quán sẽ xảy ra để ngăn chặn edge case phụ thuộc tài nguyên, cả khi tạo hoặc xóa tài nguyên.

Terraforms được xây dựng để xử lý các edge case như thế này, nên việc xây dựng tự động triển khai application mạnh mẽ với nó tương đối ít phức tạp hơn.

Kết hợp mọi thành phần với nhau

Giả sử có một kho lưu trữ với application base và environment overlays tương tự như bên dưới.

Mã:
manifests/
├── bases
│   └── app
│       ├── configmap.yaml
│       ├── deployment.yaml
│       ├── kustomization.yaml
│       └── service.yaml
└── overlays
    ├── prod
    │   ├── ingress.yaml
    │   ├── kustomization.yaml
    │   └── namespace.yaml
    └── test
        ├── basic-auth-secret.yaml
        ├── ingress.yaml
        ├── kustomization.yaml
        ├── namespace.yaml
        └── patch_app_url.yaml
Để triển khai bằng Terraform, cần phải:

1. Đặt HCL sau vào file có tên main.tf trong kho lưu trữ gốc:

Mã:
terraform {
  # use any remote state storage you want
  backend "gcs" {
    bucket = "UNIQUE_BUCKET_NAME"
  }
}

data "kustomization" "current" {
  # using the workspace name to select the correct overlay
  path = "manifests/overlays/${terraform.workspace}"
}

resource "kustomization_resource" "current" {
  # use the new for_each to handle each resource individually
  for_each = data.kustomization.current.ids

  manifest = data.kustomization.current.manifests[each.value]
}
2. Nhận provider binary và thực thi:

Mã:
$ curl -LO https://github.com/kbst/terraform-provider-kustomize/releases/download/v0.1.0-beta.3/terraform-provider-kustomization-v0.1.0-beta.3-linux-amd64
$ mv terraform-provider-kustomization-v0.1.0-beta.3-linux-amd64 terraform.d/plugins/linux_amd64/terraform-provider-kustomization
$ chmod +x terraform.d/plugins/linux_amd64/terraform-provider-kustomization
3. Tạo 2 Terraform workspaces, một cho thử nghiệm và một cho môi trường prod:

Mã:
$ terraform init
$ terraform workspace new test
$ terraform workspace new prod
Tại vị trí đó, có thể chọn môi trường để triển khai bằng cách thay đổi Terraform workspace. Ví dụ, terraform workspace select test và triển khai bằng cách sử dụng terraform apply .

Nếu đang di chuyển một application đã được triển khai trước đó bằng kubectl apply , cần nhập tài nguyên Kubernetes hiện có vào Terraform’s state một lần nữa, trước khi chạy terraform apply .

Cũng có thể chạy terraform import cho từng tài nguyên như bên dưới. Xin lưu ý các trích dẫn duy nhất xung quanh tài nguyên và id:

Mã:
$ terraform import 'kustomization_resource.current["apps_v1_Deployment|test|app"]' 'apps_v1_Deployment|test|app'
Tổng kết

Kết hợp Kustomize và Terraform đưa đến sự mô tả đầy đủ, Kubernetes duy trì cấu hình mong muốn trong kho lưu trữ và dựa vào Terraform’s robust plan/apply workflow để tránh các edge cases đã được xác định trong phần một .

Tất nhiên có những công cụ khác để thay thế. Nhưng nếu đã quen thuộc với hệ sinh thái Terraform thì không cần phải thành thạo công cụ khác nữa. Để ví dụ về cách Kustomize provider có thể sử dụng trong ngữ cảnh lớn hơn, hãy xem open source Gitops framework Kubestack và cách nó sử dụng provider để duy trì cluster services.
 
Top