Quản lý Kubernetes CustomResourceDefinitions với Google Deployment Manager

cloudFun

Xác định và sử dụng CustomResourceDefinitions (CRD) trong Kubernetes rất phổ biến. Nhưng cho đến nay, việc tạo và sử dụng toàn bộ CRD trong Google Cloud Deployment Manager (DM) chưa thể thực hiện. Lý do là vì các API endpoint mới mà CRD có thể xác định không hoàn toàn “hiện hữu” đối với DM. Nguyên nhân là do các kubernetes không tự động cập nhật thông số kỹ thuật OpenAPI để phản ánh CRD mới. Nếu máy chủ API k8s không được cập nhật, DM sẽ không bao giờ biết về chúng.

Về cơ bản, DM cốt lõi chỉ đơn giản là hệ thống hạ tầng áp dụng và quản lý các hoạt động CRUD dựa trên API. Thông thường, máy chủ API xác định Google Cloud Service như Compute Engine, Pub / Sub, Dataflow, v.v. nhưng cũng có thể xác định bất kỳ API endpoint tùy ý như được hiển thị ở Deployment Manager Type Provider Sample. Cơ bản, khi xác định DM type-provider, DM đọc thông số OpenAPI hoặc Swagger từ một máy chủ từ xa và sau đó trong quá trình hoạt động, thực thi CRUD verb dựa trên endpoint đó.

Khi tạo GKE cluster bằng DM, DM sẽ áp dụng các thao tác CRUD dựa trên GKE API để tạo cluster. Sau khi cluster được tạo, có thể xác định một type-provider đọc máy chủ API kubernetes thực tế như một đích đến khác mà nó có thể quản lý. Nếu DM 'nhận ra' kubernetes api server, nó có thể áp dụng các hoạt động dựa trên điều đó để tạo ra Deployments, Services và tạo CustomResources

CustomResource là tham số đặc biệt vì hiện nay API endpoint để quản lý CRD được tạo ra tự động và chỉ thực sự hiển thị kể từ phiên bản 1.14 của k8s với CustomResourcePublishOpenAPI được xác định trong Alpha Feature Gate,

Hướng dẫn này sẽ:
1. Triển khai một GKE clust
2. Xác định một CustomResourceDefinitions (CRD)
3. Tạo một phiên bản CRD

Lưu ý: kể từ ngày 11/8/19, tài liệu này là bản tóm tắt các thay đổi đang chờ xử lý được trích dẫn trên PR 348 of the DM-examples repo


Triển khai một GKE cluster
Trước tiên, sử dụng Deployment Manager để tạo máy chủ api k8s với flag đó được bật.

Mã:
NAME="dm-1"
CLUSTER_NAME="dm-gke-cluster-1"
ZONE="us-central1-a"
gcloud deployment-manager deployments create ${NAME} \
    --template cluster.jinja \
    --properties clusterName:${CLUSTER_NAME},zone:${ZONE}
gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE
Xem máy chủ API k8s
Cùng điểm nhanh các API endpoint mặc định đi kèm với máy chủ API k8s
Trước tiên, sử dụng API endpoint k8s vốn có thể lấy bằng một số cách khác nhau. Vì đã sử dụng trình quản lý triển khai, nó có thể sử dụng descriptorUrl :
Mã:
DESCRIPTOR_URL=`gcloud beta deployment-manager type-providers describe ${CLUSTER_NAME}-provider --format='value(descriptorUrl)'`
MASTER_IP=`gcloud container clusters describe $CLUSTER_NAME --zone $ZONE --format='value(endpoint)'`
mkdir -p files/
curl -sk -H "Authorization: Bearer `gcloud auth print-access-token`" $DESCRIPTOR_URL > files/swagger_default.json
Hiện tại vẫn khá khó để xem vì nó không được định dạng. Vì vậy nếu muốn, có thể phân tích cú pháp bằng jq hoặc sử dụng trình soạn thảo swagger.
Mã:
docker run -p 8080:8080 \
   -e SWAGGER_JSON=/files/swagger_default.json \
   -v `pwd`/files:/files swaggerapi/swagger-ui
Cũng cần ghi chú lại danh sách tất cả các CRD hiện hữu mà kubernetes biết
Mã:
$ kubectl get crd
Có vẻ những thứ này không có gì mới , hãy quay lại xác định CRD

Xác định CustomResourceDefinition
CRD về cơ bản là một API endpoint đã được đăng ký với máy chủ API kubernetes.
Mã:
$ gcloud deployment-manager deployments create my-crd \
  --template crd.jinja \
  --properties clusterType:${CLUSTER_NAME}-provider
Đến bước này, hãy liệt kê lại CRD thông qua kubectl để thấy CRD vừa được triển khai crontabs.stable.example.com
Mã:
$ kubectl get crd
NAME                                    CREATED AT
crontabs.stable.example.com             2019-05-17T20:59:52Z
Kiểm tra các đặc tả Swagger được cập nhật và một endpoint mới sẽ được thiết lập:
Mã:
curl -sk -H "Authorization: Bearer `gcloud auth print-access-token`" $DESCRIPTOR_URL > files/swagger_crd.json
$ cat files/swagger_crd.json  | jq '.' \
     | grep /apis/stable.example.com/v1/namespaces/
    
"/apis/stable.example.com/v1/namespaces/{namespace}/crontabs": {
    "/apis/stable.example.com/v1/namespaces/{namespace}/crontabs/{name}": {
(có thể xem định nghĩa swagger-ui tương tự như ở trên)
Mã:
docker run -p 8080:8080 -e SWAGGER_JSON=/files/swagger_crd.json \
     -v `pwd`/files:/files swaggerapi/swagger-ui
0_T6F-eoAEPGfitVMB.png


Tạo một phiên bản của CRD (CRD instance)

Bây giờ các k8 đã biết về endpoint mới, có thể hướng dẫn nó ‘tạo ra” một phiên bản của CRD mới đó.

Lưu ý CRD_COLLECTION sử dụng để tham chiếu cho bộ sưu tập này cho DM biết đường dẫn để invoke và các biến số để truyền cho nó (ví dụ: tên, namespace, thông số POST, v.v.)
Mã:
{% set CLUSTER_TYPE = env['project'] + '/' + properties['clusterType'] %}
{% set CRD_COLLECTION =  '/apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/{name}' %}
{% set NAME_PREFIX = env['deployment'] + '-' + env['name'] %}

resources:
- name: {{ NAME_PREFIX }}-crd
  type: {{ CLUSTER_TYPE }}:{{ CRD_COLLECTION }}
  properties:
    apiVersion: apiextensions.k8s.io/v1beta1
    kind: CustomResourceDefinition
    metadata:
      name: crontabs.stable.example.com
      namespace: default
    spec:
      group: stable.example.com
      versions:
        - name: v1
          served: true
          storage: true
      scope: Namespaced
      names:
        plural: crontabs
        singular: crontab
        kind: CronTab
        shortNames:
        - ct
Bây giờ hãy tạo nó
Mã:
$ gcloud deployment-manager deployments create \
   my-crd-instance --template crd-instance.jinja \
   --properties clusterType:${CLUSTER_NAME}-provider
Lưu ý các triển khai được thiết lập hiển thị GKE cluster, CRD và phiên bản dưới dạng deployment riêng biệt (có thể kết hợp CRD, CRD-instance thành một lệnh phân tầng khi xóa)
Mã:
$ gcloud deployment-manager deployments list
    dm-1                      insert               DONE                 manifest-1572649527023  []
    my-crd                    insert               DONE                 manifest-1572650044724  []
    my-crd-instance           insert               DONE                 manifest-1572656117578  []
Xác minh CRD được tạo
Mã:
$ kubectl get crd/crontabs.stable.example.com
    NAME                          CREATED AT
    crontabs.stable.example.com   2019-11-08T16:08:38Z
    
    
$ kubectl get crontab -o yaml
    apiVersion: v1
    items:
    - apiVersion: stable.example.com/v1
    kind: CronTab
    metadata:
        creationTimestamp: "2019-11-08T16:21:49Z"
        generation: 1
        name: my-new-cron-object
        namespace: default
        resourceVersion: "132114"
        selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
        uid: 21ee8d1d-f165-45bb-b4cb-30148963a6ce
    spec:
        cronSpec: '* * * * */5'
        image: my-awesome-cron-image
    kind: List
    metadata:
    resourceVersion: ""
    selfLink: ""
Nếu muốn kiểm tra API gốc tại CRD endpoint
Mã:
curl -sk -H "Authorization: Bearer `gcloud auth print-access-token`" https://$MASTER_IP/apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object | jq '.'
    {
    "apiVersion": "stable.example.com/v1",
    "kind": "CronTab",
    "metadata": {
        "creationTimestamp": "2019-11-08T16:21:49Z",
        "generation": 1,
        "name": "my-new-cron-object",
        "namespace": "default",
        "resourceVersion": "132114",
        "selfLink": "/apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object",
        "uid": "21ee8d1d-f165-45bb-b4cb-30148963a6ce"
    },
    "spec": {
        "cronSpec": "* * * * */5",
        "image": "my-awesome-cron-image"
    }
    }/CODE]

Xóa sơ đồ CRD phiên bản và CRD
Các bước xóa và quản lý CRD đã được thực hiện khá dễ dàng, hãy cùng nhắc lại các bước vừa được thiết lập
[CODE]$ gcloud deployment-manager deployments delete my-crd-instance -q
$ kubectl get crontab
    No resources found.
$ gcloud deployment-manager deployments delete my-crd -q
DM và k8s trạng thái Drift
Lưu ý, nếu xóa CRD hoặc CRD định nghĩa trực tiếp qua kubectl, trạng thái của deployment manager sẽ không phù hợp với GKE cluster. Lúc này chỉ còn lại phần hiển thị của DM về trạng thái k8 không đồng bộ: DM nghĩ rằng có thể CRD phiên bản tồn tại trong khi thực tế CRD định nghĩa đã bị xóa (k8s sẽ xóa bất kỳ phiên bản CRD con nào khi bản gốc không còn nữa)

Ví dụ: nếu xóa crd trước khi xóa phiên bản, thì CRD và CRD phiên bản sẽ cùng bị xóa bởi máy chủ k8s (thùng rác thu thập các đối tượng không có bản gốc). Tuy nhiên, DM không biết rằng my-crd là "bản gốc"của my-crd-instance. Điều đó có nghĩa là, nếu xóa crd và sau đó cố gắng xóa phiên bản của nó, trạng thái sẽ trở nên không nhất quán:

Nếu xóa CRD Trước phiên bản CRD
  • kubectl delete crd/crontabs.stable.example.com
  • gcloud deployment-manager deployments create my-crd
sau đó, khi chạy các hoạt động trên crd phiên bản, k8s sẽ báo cáo CRD không tồn tại
Mã:
$ gcloud deployment-manager deployments delete my-crd-instance -q
                                          
ERROR: (gcloud.deployment-manager.deployments.delete) Delete operation operation-1573194880802-596cffa085df4-f5ead2da-f5163d29 failed.
Error in Operation [operation-1573194880802-596cffa085df4-f5ead2da-f5163d29]: errors:
- code: COLLECTION_NOT_FOUND
  message: Collection '/apis/stable.example.com/v1/namespaces/{namespace}/crontabs/{name}'
    not found in discovery doc 'https://104.197.146.73/openapi/v2'
$ gcloud deployment-manager deployments  list
NAME                      LAST_OPERATION_TYPE  STATUS  DESCRIPTION  MANIFEST                ERRORS
dm-1                      insert               DONE                 manifest-1573193309755  []
my-crd-instance           delete               DONE                 manifest-1573194205576  [COLLECTION_NOT_FOUND]
Trong trường hợp đó, cần phải chấm dứt/từ bỏ resource không có bản gốc:
Mã:
$ gcloud deployment-manager deployments \
     delete my-crd-instance -q --delete-policy=ABANDON
Một cách để giảm thiểu điều này là xác định CRD và phiên bản với Explicit Dependencies nhưng nó làm cho người dùng bị bó buộc vào một template hoặc script quản lý duy nhất.



Độ trễ hoạt động của CRD/ CRD phiên bản
Phiên bản 11/8/19, CRDlate hoặc script quản lý duy nhất.a DM s9ảny động của CRDlate hoặc script quản lý duy nhất.hi nó đảny động của CRDlate hoặc script quản lý duy nhất. cú pháp. Thđộng của CRDlate hoặc script quản lý duswagger khá lr khá lộn ứng mức ~ 4 MB, khiến mỗi thao tác để xác định hoặc khởi tạo có thể mất vài phút. Độ trễ này khó có thể chấp nhận trong việc quản lý các hoạt động ở quy mô lớn và nhanh chóng nhưng điều này sẽ được giải quyết sau.

Nguồn: https://medium.com/
 
Top