Áp dụng phía máy chủ Kubernetes là gì

[ad_1]

Sửa máy tính tại nhà TPHCM

Ứng dụng phía máy chủ (SSA) đã có sẵn rộng rãi trong Kubernetes kể từ bản phát hành v1.22 vào tháng 8 năm 2021. Đây là một chiến lược quản lý tài nguyên khai báo giúp cải thiện các tính toán khác biệt và cảnh báo về xung đột hợp nhất bằng cách di chuyển logic của kubectl apply lệnh lên máy chủ.

Bài viết này sẽ giải thích cách thức hoạt động của SSA và lý do tại sao nó được ưu tiên hơn so với phương pháp áp dụng phía máy khách (CSA) trước đây. Bạn cũng sẽ tìm hiểu cách bật SSA khi thực hiện các thay đổi đối với các đối tượng trong cụm của mình.

Hiểu cập nhật khai báo

Các kubectl apply lệnh thực hiện cập nhật đối tượng khai báo. Thay vì hướng dẫn Kubernetes sửa đổi các trường cụ thể, bạn cung cấp một biểu diễn hoàn chỉnh của đối tượng mà bạn muốn nó xuất hiện. Hệ thống sẽ tự động tính toán sự khác biệt so với trạng thái hiện tại của cụm của bạn. Sau đó, nó sẽ thực hiện các hành động chuyển đổi trạng thái thành trạng thái mong muốn được biểu thị bằng tệp kê khai của bạn.

Đây là một bảng kê khai Pod đơn giản:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest

Đang chạy kubectl apply với bảng kê khai này sẽ bắt đầu một Pod mới chạy nginx:latest hình ảnh. Sự khác biệt rõ ràng giữa trạng thái hiện có của cụm và trạng thái mong muốn: một Nhóm đã được tạo, nơi trước đây không có nhóm nào với nginx Tên.

Sau đó, bạn có thể sửa đổi tệp kê khai bằng cách thay đổi một trong các thuộc tính của Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:1.23

Lần này, sự khác biệt giữa trạng thái hiện tại và trạng thái mong muốn ít đáng kể hơn. Các kubectl apply lệnh sẽ phát hiện sửa đổi image trường và cập nhật cấu hình Pod của bạn cho phù hợp.

Các vấn đề với Client-Side Apply

Phân biệt các thay đổi và giải quyết mọi xung đột là phần quan trọng nhất của các cập nhật khai báo. Quá trình này chạy trong Kubectl theo mặc định. Máy khách chịu trách nhiệm xác định đối tượng hiện có trên máy chủ và so sánh các thay đổi của nó.

Các kubectl apply lệnh viết một last-applied-configuration chú thích vào các đối tượng để hỗ trợ quá trình này. Nó cho phép xác định các trường tồn tại trên đối tượng trực tiếp nhưng đã bị xóa khỏi tệp kê khai đến. Sau đó, khách hàng biết xóa chúng khỏi đối tượng để đạt được trạng thái mới.

Cách tiếp cận này có vấn đề khi có nhiều tác nhân cập nhật cùng một đối tượng. Chẳng hạn, một đối tượng có thể được sửa đổi bởi cả Kubectl và bộ điều khiển chuyên dụng trong cụm của bạn. Ứng dụng phía máy khách không thể theo dõi tác nhân nào đã sửa đổi một trường cũng như không thể hiểu khi xảy ra xung đột. Nó chỉ đơn giản là so sánh bảng kê khai cục bộ của bạn với đối tượng hiện có last-applied-configuration và hợp nhất trong bất kỳ thay đổi nào.

Ứng dụng phía máy khách cũng vốn được gắn với Kubectl. Các công cụ của bên thứ ba muốn thực hiện các cập nhật khai báo của riêng họ cần gọi Kubectl hoặc tạo lại apply logic từ đầu. Cả hai tùy chọn này đều không đặc biệt lý tưởng.

Cách áp dụng phía máy chủ hoạt động

Vấn đề cơ bản với CSA là các tệp kê khai cục bộ lỗi thời không bao giờ được phát hiện. Nếu ứng dụng khác thay đổi một đối tượng trước khi bạn chạy kubectl apply, các bản sửa đổi cục bộ cũ của bạn có thể ghi đè lên các bản sửa đổi mới chính xác. Khi bật SSA, xung đột sẽ được phát hiện và bản cập nhật sẽ bị chặn. Đó là một hệ thống tập trung đảm bảo rằng trạng thái địa phương của bạn luôn được cập nhật.

SSA hoạt động bằng cách thêm cơ chế mặt phẳng điều khiển lưu trữ thông tin về từng trường trong đối tượng của bạn. Nó thay thế các last-applied-configuration chú thích với một cái mới metadata.managedFields đồng ruộng. Mỗi trường trong đối tượng của bạn được theo dõi trong managedFields.

Các trường được chỉ định một “trình quản lý trường” xác định khách hàng sở hữu chúng. Nếu bạn áp dụng một bảng kê khai với Kubectl, thì Kubectl sẽ là người quản lý được chỉ định. Trình quản lý của trường cũng có thể là bộ điều khiển hoặc tích hợp bên ngoài cập nhật đối tượng của bạn.

Người quản lý bị cấm cập nhật các lĩnh vực của nhau. Bạn sẽ bị chặn thay đổi trường với kubectl apply nếu nó hiện thuộc sở hữu của một bộ điều khiển khác. Ba chiến lược có sẵn để giải quyết các xung đột hợp nhất này:

  • Buộc ghi đè giá trị – Trong một số trường hợp, bạn có thể muốn buộc cập nhật thông qua. Điều này sẽ thay đổi giá trị của nó và chuyển quyền sở hữu cho người quản lý trường mới. Nó chủ yếu dành cho các bộ điều khiển cần duy trì quyền quản lý các trường mà chúng đã điền. Bạn có thể buộc cập nhật theo cách thủ công bằng cách đặt --force-conflicts cờ trong Kubectl.
  • Không ghi đè lên giá trị – Người áp dụng có thể xóa trường khỏi cấu hình cục bộ của trường rồi lặp lại yêu cầu. Trường sẽ giữ lại giá trị hiện tại của nó. Việc xóa trường sẽ giải quyết xung đột bằng cách nhường quyền sở hữu cho người quản lý hiện tại.
  • Chia sẻ quản lý – Người áp dụng có thể cập nhật giá trị cục bộ của mình để khớp với giá trị hiện có trên máy chủ. Nếu nó lặp lại yêu cầu trong khi vẫn xác nhận quyền sở hữu, SSA sẽ cho phép nó chia sẻ quyền quản lý với người quản lý hiện có. Điều này là do người áp dụng chấp nhận trạng thái hiện tại của trường nhưng đã cho biết họ có thể muốn quản lý trường đó trong tương lai.

Cách tiếp cận này mạnh mẽ hơn nhiều so với truyền thống kubectl apply. Nó ngăn chặn việc ghi đè ngẫu nhiên, cho phép bộ điều khiển xác nhận quyền sở hữu một cách đáng tin cậy đối với các trường mà họ kiểm soát và được khai báo đầy đủ. SSA theo dõi cách những người dùng khác nhau đã thay đổi các trường riêng lẻ, thay vì chỉ ghi lại toàn bộ trạng thái cuối cùng của đối tượng. Điều đó cũng có nghĩa là giờ đây bạn có thể sử dụng ứng dụng bên trong bất kỳ công cụ nào, bất kể ngôn ngữ hay kubectl sẵn có nhị phân. Bạn sẽ nhận được kết quả nhất quán giống nhau tuy nhiên bạn bắt đầu thao tác.

Sử dụng SSA ngay hôm nay

Bạn có thể kích hoạt SSA bằng cách cài đặt --server-side gắn cờ mỗi khi bạn chạy áp dụng Kubectl:

$ kubectl apply -f nginx.yaml --server-side
pod/nginx serverside-applied

Đầu ra của lệnh thay đổi để làm nổi bật rằng SSA đã được sử dụng.

Kiểm tra tệp kê khai YAML của đối tượng sẽ hiển thị các trường được quản lý:

$ kubectl get pod nginx -o yaml
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2022-11-24T16:02:29Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:containers:
          k:{"name":"nginx"}:
            .: {}
            f:image: {}
            f:name: {}
    manager: kubectl
    operation: Apply
    time: "2022-11-24T16:02:29Z"
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:status:
        f:conditions:
          k:{"type":"ContainersReady"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
          k:{"type":"Initialized"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
          k:{"type":"Ready"}:
            .: {}
            f:lastProbeTime: {}
            f:lastTransitionTime: {}
            f:status: {}
            f:type: {}
        f:containerStatuses: {}
        f:hostIP: {}
        f:phase: {}
        f:podIP: {}
        f:podIPs:
          .: {}
          k:{"ip":"10.244.0.186"}:
            .: {}
            f:ip: {}
        f:startTime: {}
    manager: kubelet
    operation: Update
    subresource: status
    time: "2022-11-24T16:02:31Z"
...

Các trường được nhóm lại với nhau bởi người quản lý sở hữu chúng. Trong ví dụ này, spec được quản lý bởi Kubectl vì đó là cách Pod được tạo. Các status Tuy nhiên, trường được quản lý bởi Kubelet vì Nút chạy Pod sẽ thay đổi giá trị của trường đó trong vòng đời của Pod.

SSA cũng sẵn sàng để sử dụng trong bộ điều khiển. Nó cho phép ngữ nghĩa mạnh mẽ hơn và các loại bộ điều khiển mới, bao gồm cả những bộ điều khiển tái tạo lại các đối tượng. Mô hình này xử lý các thay đổi bằng cách trước tiên xây dựng lại các trường của đối tượng từ đầu cho đến khi bộ điều khiển hài lòng, sau đó áp dụng kết quả trở lại máy chủ. Đó là một phương pháp tự nhiên hơn là thiết lập thủ công chuỗi hoạt động sẽ tạo ra thay đổi mong muốn.

Kiểm tra xem một đối tượng có được quản lý bằng SSA hay không

Bạn có thể kiểm tra xem một đối tượng đang sử dụng CSA hay SSA bằng cách truy xuất tệp kê khai YAML của đối tượng đó trong Kubectl:

$ kubectl get pod nginx -o yaml

Nếu bạn thấy một last-applied-configuration chú thích, đối tượng của bạn được quản lý bởi CSA:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"nginx","namespace":"default"},"spec":{"containers":[{"image":"nginx:latest","name":"nginx"}]}}
  creationTimestamp: "2022-11-24T14:20:07Z"
  name: nginx
  namespace: default
  ...
...

SSA đã được sử dụng cho đối tượng nếu metadata.managedFields thay vào đó xuất hiện:

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2022-11-24T16:02:29Z"
  managedFields:
  - apiVersion: v1
    fieldsType: FieldsV1
    fieldsV1:
      f:spec:
        f:containers:
          k:{"name":"nginx"}:
            .: {}
            f:image: {}
            f:name: {}
    manager: kubectl
    operation: Apply
    time: "2022-11-24T16:02:29Z"
    ...
  ...
...

Bạn có thể di chuyển một đối tượng giữa CSA và SSA bằng cách thêm hoặc bỏ qua --server-side gắn cờ vào lần tới khi bạn chạy kubectl apply. Kubernetes xử lý chuyển đổi của last-applied-configuration vào trong managedFields và ngược lại.

Việc nâng cấp lên SSA có thể gây ra xung đột nếu tệp kê khai cục bộ của bạn khác với đối tượng trên máy chủ. Điều này xảy ra khi bạn chạy một lệnh bắt buộc như kubectl scale hoặc kubectl label kể từ thao tác áp dụng cuối cùng của bạn đối với đối tượng. Bạn nên kiểm tra tệp kê khai cục bộ khớp chính xác với đối tượng trực tiếp trước khi chuyển đổi sang SSA.

Bản tóm tắt

Ứng dụng phía máy chủ là một cách tiếp cận để quản lý đối tượng khai báo trong đó các trường được theo dõi bởi mặt phẳng điều khiển Kubernetes. Điều này tạo điều kiện phát hiện xung đột mạnh mẽ và các chiến lược giải quyết linh hoạt. SSA giải quyết các hạn chế của ứng dụng phía máy khách cho phép các trường bị ghi đè ngoài ý muốn mà không có bất kỳ cảnh báo nào.

Mặc dù SSA hiện khả dụng rộng rãi nhưng bạn vẫn cần chỉ định thủ công mỗi khi chạy kubectl apply. Cần lưu ý rằng SSA hữu ích nhất trong các tình huống mà các đối tượng đang được quản lý bởi một số quy trình khác nhau, chẳng hạn như người vận hành con người với Kubectl và vòng lặp bộ điều khiển. Bạn sẽ không được hưởng lợi nhiều từ SSA nếu bạn chỉ sử dụng kubectl apply để tạo và cập nhật các đối tượng.

Một bản phát hành Kubernetes trong tương lai dự kiến ​​sẽ loại bỏ CSA, khiến SSA trở thành tùy chọn mặc định và duy nhất. Các --server-side cờ sau đó sẽ trở nên dư thừa.

dịch vụ cài win online từ xa

[ad_2]