Sự khác biệt giữa nhóm và triển khai là gì?

Tôi đã tạo các nhóm với type:deploymentnhưng tôi thấy rằng một số tài liệu sử dụng type:pod, cụ thể hơn là tài liệu cho các nhóm đa container :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

Nhưng để tạo nhóm, tôi chỉ có thể sử dụng loại triển khai :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

Tôi nhận thấy tài liệu pod nói:

Lệnh tạo có thể được sử dụng để tạo một nhóm trực tiếp hoặc nó có thể tạo một nhóm hoặc nhóm thông qua Triển khai. Chúng tôi khuyên bạn nên sử dụng Triển khai để tạo các nhóm của mình. Nó theo dõi các nhóm không thành công và sẽ khởi động các nhóm mới theo yêu cầu để duy trì số lượng được chỉ định. Nếu bạn không muốn Triển khai theo dõi nhóm của mình (ví dụ: nhóm của bạn đang ghi dữ liệu không liên tục sẽ không tồn tại khi khởi động lại hoặc nhóm của bạn dự định sẽ rất ngắn), bạn có thể tạo nhóm trực tiếp với lệnh tạo.

Lưu ý: Chúng tôi khuyên bạn nên sử dụng Triển khai để tạo nhóm. Bạn chỉ nên sử dụng các hướng dẫn bên dưới nếu bạn không muốn tạo Triển khai.

Nhưng điều này đặt ra câu hỏi cái gì kind:podtốt cho? Bạn có thể bằng cách nào đó tham khảo pod trong một triển khai? Tôi đã không nhìn thấy một cách. Có vẻ như những gì bạn nhận được với các nhóm là một số siêu dữ liệu bổ sung nhưng không có tùy chọn triển khai nào như replicahoặc chính sách khởi động lại. Điều gì tốt là một pod không lưu dữ liệu, tồn tại khi khởi động lại? Tôi nghĩ rằng tôi cũng có thể tạo một nhóm nhiều container với việc triển khai.

Cả Pod và Deployment đều là các đối tượng chính thức trong API Kubernetes. Triển khai quản lý việc tạo Pod bằng các bản sao. Điều nó sôi nổi là Deployment sẽ tạo ra các Pod với thông số được lấy từ mẫu. Bạn không cần phải tạo Pods trực tiếp cho trường hợp sử dụng sản xuất.

Câu trả lời Radek là rất tốt, nhưng tôi muốn sân trong từ kinh nghiệm của tôi, bạn sẽ hầu như không bao giờ sử dụng một đối tượng với các loại pod , bởi vì điều đó không có ý nghĩa gì trong thực tế.

Bởi vì bạn cần một đối tượng triển khai - hoặc các đối tượng API Kubernetes khác như bộ điều khiển sao chép hoặc bản sao - cần giữ cho các bản sao (nhóm) tồn tại (đó là điểm sử dụng kubernetes).

Những gì bạn sẽ sử dụng trong thực tế cho một ứng dụng điển hình là:

1. Đối tượng triển khai (nơi bạn sẽ chỉ định vùng chứa / vùng chứa ứng dụng) sẽ lưu trữ vùng chứa ứng dụng của bạn với một số thông số kỹ thuật khác.

2. Đối tượng dịch vụ (giống như một đối tượng nhóm và cung cấp cho nó cái gọi là IP ảo (cụm IP) cho podsmột nhãn nhất định - và podsvề cơ bản đó là các thùng chứa ứng dụng mà bạn đã triển khai với đối tượng triển khai trước đó).

Bạn cần phải có đối tượng dịch vụ vì đối tượng podstriển khai có thể bị giết, tăng hoặc giảm và bạn không thể dựa vào địa chỉ IP của chúng vì chúng sẽ không tồn tại.

Vì vậy, bạn cần một đối tượng như một dịch vụ , cung cấp cho những podsIP ổn định.

Chỉ muốn cung cấp cho bạn một số bối cảnh xung quanh pods, vì vậy bạn biết làm thế nào mọi thứ làm việc cùng nhau.

Hy vọng rằng sẽ xóa một vài điều cho bạn, cách đây không lâu tôi đã ở trong đôi giày của bạn :)

Kubernetes có ba loại đối tượng bạn nên biết về:

• Pods - chạy một hoặc nhiều container liên quan chặt chẽ
• Dịch vụ - thiết lập kết nối mạng trong cụm Kubernetes
• Triển khai - Duy trì một nhóm các nhóm giống hệt nhau, đảm bảo rằng chúng có cấu hình chính xác và số lượng đúng của chúng tồn tại.

Pods:

• Chạy một bộ container
• Tốt cho mục đích phát triển một lần
• Hiếm khi sử dụng trực tiếp trong sản xuất

Triển khai:

• Chạy một tập hợp các nhóm giống hệt nhau
• Theo dõi trạng thái của từng nhóm, cập nhật khi cần thiết
• Tốt cho nhà phát triển
• Tốt cho sản xuất

Và tôi sẽ đồng ý với các câu trả lời khác, quên đi Pods và chỉ sử dụng Triển khai. Tại sao? Nhìn vào điểm đạn thứ hai, nó theo dõi trạng thái của từng nhóm, cập nhật khi cần thiết.

Vì vậy, thay vì đấu tranh với các thông báo lỗi như thế này:

Cấm: cập nhật pod có thể không thay đổi các trường khác ngoài spec.containers[*].image

Vì vậy, chỉ cần cấu trúc lại hoặc tái tạo hoàn toàn Pod của bạn thành Deployment để tạo một nhóm để thực hiện những gì bạn cần làm. Với Deployment bạn có thể thay đổi bất kỳ phần cấu hình nào bạn muốn và bạn không cần phải lo lắng khi thấy thông báo lỗi đó.

Pod là ví dụ container.

Đó là đầu ra của replicas: 3

Hãy nghĩ về một người deploymentcó thể có nhiều phiên bản đang chạy (bản sao).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Pod là một bộ sưu tập các container và đối tượng cơ bản của Kuberntes. Tất cả các thùng chứa nằm trong cùng một nút.

• Không phù hợp với sản xuất
• Không cập nhật cán

Triển khai là một loại bộ điều khiển trong Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

Triển khai tạo ra một bản sao mà lần lượt đảm bảo rằng, CurrentReplicas luôn giống như mong muốn.

Ưu điểm:

• Bạn có thể triển khai và khôi phục các thay đổi của mình bằng cách triển khai
• Theo dõi trạng thái của từng nhóm
• Thích hợp nhất cho sản xuất
• Hỗ trợ cập nhật cán

Tôi muốn thêm một số thông tin từ cuốn sách Kubernetes In Action , để bạn có thể xem tất cả hình ảnh và kết nối mối quan hệ giữa các tài nguyên Kubernetes như Pod, Deployment và ReplicationContoder (Bản sao)

Pods

là đơn vị triển khai cơ bản trong Kubernetes. Nhưng trong các trường hợp sử dụng trong thế giới thực, bạn muốn các triển khai của mình được duy trì và chạy tự động và vẫn khỏe mạnh mà không cần bất kỳ sự can thiệp thủ công nào. Đối với điều này, cách tiếp cận được đề xuất là sử dụng Deployment , trong phần dưới mui xe, tạo một bản sao .

Một bản sao , như tên của nó ngụ ý, là một bộ các bản sao (Pods) được duy trì với lịch sử Sửa đổi của chúng .

(Bản sao mở rộng một đối tượng cũ hơn gọi là ReplicationContoder - hoàn toàn giống nhau nhưng không có lịch sử sửa đổi.)

Một bản sao liên tục theo dõi danh sách các nhóm đang chạy và đảm bảo số lượng nhóm đang chạy phù hợp với một đặc điểm kỹ thuật nhất định luôn khớp với số lượng mong muốn.

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

Một triển khai

là một tài nguyên cấp cao hơn có nghĩa là để triển khai các ứng dụng và cập nhật chúng theo cách khai báo.

Khi bạn tạo ra một triển khai , một ReplicaSet bên dưới tài nguyên được tạo ra (thậm chí nhiều hơn trong số họ). Bản sao cũng sao chép và quản lý các nhóm. Khi sử dụng một triển khai, vỏ thực tế được tạo ra và quản lý bởi Deployment ‘s ReplicaSets , không phải do triển khai trực tiếp

Hãy suy nghĩ về những gì đã xảy ra. Bằng cách thay đổi mẫu nhóm trong tài nguyên Triển khai của bạn, bạn đã cập nhật ứng dụng của mình lên phiên bản mới hơn bằng cách thay đổi một trường duy nhất!

Cuối cùng, khôi phục lại một Triển khai cho lần sửa đổi trước hoặc cho bất kỳ sửa đổi nào trước đó thật dễ dàng với tài nguyên Triển khai.

Những hình ảnh này là từ cuốn sách Kubernetes In Action , quá.

Thay vào đó, hãy cố gắng tránh Pods và triển khai Triển khai để quản lý các thùng chứa vì các đối tượng thuộc loại Pod sẽ không được lên lịch lại (hoặc tự phục hồi) trong trường hợp lỗi nút hoặc chấm dứt pod.

Việc triển khai thường được ưu tiên hơn vì nó xác định Bản sao để đảm bảo rằng số lượng Pod mong muốn luôn có sẵn và chỉ định chiến lược để thay thế Pods, chẳng hạn như RollingUpdate.

Trong kubernetes Pods là đơn vị triển khai nhỏ nhất. Mỗi khi chúng ta tạo một đối tượng kubernetes như Triển khai, bộ bản sao, trạng thái, trình nền, nó sẽ tạo nhóm.

Như đã đề cập ở trên, việc tạo các nhóm dựa trên trạng thái mong muốn được đề cập trong đối tượng triển khai của bạn. Vì vậy, ví dụ bạn muốn có 5 bản sao của một ứng dụng, bạn đã đề cập replicas: 5trong bảng kê khai triển khai của mình. Bây giờ bộ điều khiển triển khai có trách nhiệm tạo 5 bản sao giống hệt nhau (không ít hơn, không hơn) ứng dụng đã cho với tất cả siêu dữ liệu như chính sách RBAC, chính sách mạng, nhãn, chú thích, kiểm tra sức khỏe, hạn ngạch tài nguyên, dung sai / dung sai và liên kết với từng nhóm nó tạo ra

Có một số trường hợp khi bạn muốn tạo pod, ví dụ nếu bạn đang chạy thử nghiệm sidecar nơi bạn không cần chạy ứng dụng mãi mãi, bạn không cần nhiều bản sao và bạn chạy ứng dụng khi bạn muốn thực thi trong đó trường hợp pod là phù hợp. Ví dụ helm test, đó là một định nghĩa nhóm chỉ định một thùng chứa với một lệnh đã cho để chạy.