Quay lại

Bài 11: Chạy Container trên Cluster - phần 3 Chuyên mục Docker    2023-12-17    14 Lượt xem    11 Lượt thích    comment-3 Created with Sketch Beta. 0 Bình luận

Bài 11: Chạy Container trên Cluster - phần 3

Kiến trúc Docker Swarm Orchestrator

Như các bạn đã biết Docker Swarm là một công cụ của Docker cho phép quản lý và triển khai các ứng dụng chạy trong các container trên một cluster của các máy chủ Docker, ở bài trước thì chúng ta đã được biết đến những khái niệm và các câu lệnh cơ bản, ở bài này chúng ta sẽ đi tìm hiểu sâu hơn về kiến trúc để xem nó hoạt động như thế nào? Mình sẽ đi bóc tách từng phần trong kiến trúc của nó nhé !

1. Internal distributed state store

Trong Docker Swarm, internal distributed state store là một phần của hệ thống được sử dụng để lưu trữđồng bộ trạng thái của swarm giữa các manager nodes. Nó chịu trách nhiệm cho việc duy trì thông tin về các dịch vụ, nhiệm vụ (tasks), và trạng thái của các node trong swarm.

Docker Swarm sử dụng một số cơ chế để thực hiện internal distributed state store. Các phiên bản trước của Docker Swarm sử dụng Consul làm backend để lưu trữ trạng thái phân tán. Từ Docker 1.12 và sau đó, Docker Swarm chuyển sang sử dụng Raft Consensus Algorithm để quản lý trạng thái nội bộ của swarm.

Dưới đây là một số điểm quan trọng về internal distributed state store trong Docker Swarm:

  1. Raft Consensus Algorithm:

    • Raft là một thuật toán bảo đảm tính nhất quán của trạng thái phân tán giữa các manager nodes.
    • Mỗi manager node trong swarm giữ một bản sao của trạng thái và sử dụng Raft để đồng bộ trạng thái này.
  2. Truyền tải Thông Tin:

    • Thông tin về dịch vụ, task, node và các yếu tố khác của swarm được truyền tải qua hệ thống internal distributed state store.
  3. Chịu Lỗi và Mở Rộng:

    • Cơ chế này giúp swarm tự động chịu lỗi bằng cách chia sẻ và đồng bộ trạng thái giữa các manager nodes.
    • Cũng hỗ trợ việc mở rộng swarm bằng cách thêm mới manager nodes mà không làm ảnh hưởng đến tính ổn định của hệ thống.
  4. Etcd:

    • Ngoài Raft, một số phiên bản Docker Swarm cũ hơn cũng có thể sử dụng etcd (một cơ sở dữ liệu phân tán) để lưu trữ trạng thái phân tán.

Quyết định sử dụng Raft và các cơ chế khác là để đảm bảo tính nhất quán và đồng bộ của trạng thái trong môi trường phân tán. Điều này quan trọng để Swarm có thể hoạt động hiệu quả và đáng tin cậy trong việc triển khai và quản lý các ứng dụng chạy trong các container trên một cluster.

2. Manager Nodes

Trong Docker Swarm, các Manager Nodes là các máy chủ Docker đảm nhiệm vai trò quản lý của cluster Swarm. Manager Nodes chịu trách nhiệm điều phối và quản lý các nhiệm vụ (tasks) của ứng dụng được triển khai trong swarm. Dưới đây là một số điểm quan trọng về Manager Nodes:

  1. Quản Lý Swarm:

    • Manager Nodes đảm nhiệm việc quản lý toàn bộ Docker Swarm, bao gồm việc duy trì trạng thái của các dịch vụ, tasks, và nodes.
  2. Raft Consensus Algorithm:

    • Manager Nodes sử dụng thuật toán Raft để đồng thuận trạng thái giữa chúng.
    • Raft giúp đảm bảo rằng các Manager Nodes đều có cái nhìn chính xác về trạng thái của swarm và giữ cho nó tính nhất quán.
  3. Triển Khai Dịch Vụ:

    • Manager Nodes chịu trách nhiệm cho quá trình triển khai dịch vụ trong swarm.
    • Khi một service được triển khai, Manager Nodes quyết định nơi mà các tasks của service đó sẽ chạy trên các worker nodes.
  4. Cân Bằng Tải:

    • Manager Nodes thực hiện cân bằng tải cho các tasks của dịch vụ trên các worker nodes.
    • Điều này đảm bảo rằng các tasks được phân phối đồng đều trong swarm để tối ưu hóa hiệu suất và tận dụng tài nguyên.
  5. Chịu Lỗi:

    • Manager Nodes cung cấp tính năng chịu lỗi cho swarm. Nếu một hoặc một số Manager Nodes gặp sự cố, các Manager Nodes khác vẫn có thể tiếp tục quản lý swarm mà không gây gián đoạn.
  6. Tính Mở Rộng:

    • Swarm có thể được mở rộng bằng cách thêm mới Manager Nodes.
    • Việc thêm mới Manager Nodes giúp tăng khả năng mở rộng của swarm và đảm bảo tính sẵn sàng và ổn định.
  7. Distributed State Store:

    • Manager Nodes sử dụng một hệ thống internal distributed state store để lưu trữ và đồng bộ trạng thái swarm giữa các nodes.
  8. Docker Swarm Mode:

    • Khi một node được chọn làm manager và swarm được kích hoạt, nó chuyển sang chế độ "Swarm Mode", và các tính năng quản lý của Manager Nodes trở nên hoạt động.
  9. Docker Swarm Agent:

    • Mỗi manager node chạy một Docker Swarm Agent, là một tiến trình phần mềm chịu trách nhiệm quản lý các task và container trên node đó.
    • Swarm Agent đảm bảo rằng các dịch vụ được triển khai và quản lý đúng cách.

Lưu ý thêm :

  • Ít nhất phải có 2 đến 3 manager để đảm bảo rằng khi 1 host manager bị lỗi hoặc gặp vấn đề thì vẫn không ảnh hưởng đến hệ thống.
  • Manager và worker có thể chạy chung 1 node (host) là bình thường rất phổ biến trong cluser nhỏ, nếu 1 hệ thống lớn thì có thể tách riêng manager ra 1 host để quản lý, còn workers là những node server là có RAM và CPU mạnh hơn để host các containers ở trên đó.

Manager Nodes là yếu tố quan trọng trong việc quản lý Docker Swarm, và chúng đóng vai trò quan trọng trong việc đảm bảo tính nhất quán và hiệu suất của môi trường phân tán.

3. Worker

Trong Docker Swarm, worker là một loại node trong một cluster Swarm. Cluster này bao gồm một hoặc nhiều worker nodes và một hoặc nhiều manager nodes. Worker nodes chịu trách nhiệm chạy các container thực tế của dịch vụ được triển khai trong swarm. Dưới đây là một số chi tiết về worker nodes trong Docker Swarm:

  1. Chạy Container:

    • Worker nodes thực hiện công việc thực tế của việc chạy các container. Các container này chứa phiên bản cụ thể của ứng dụng hoặc dịch vụ bạn đang triển khai.
  2. Chịu Trách Nhiệm Cho Nhiệm Vụ (Tasks):

    • Mỗi container chạy trên worker node được quản lý dưới dạng một task. Task là một phiên bản cụ thể của một dịch vụ.
  3. Nhận Lệnh Từ Manager Nodes:

    • Manager nodes chịu trách nhiệm cho việc điều phối nhiệm vụ (tasks) và quản lý cân bằng tải. Các worker nodes nhận lệnh từ manager nodes và thực hiện các nhiệm vụ được giao.
  4. Không Thể Quản Lý Swarm:

    • Worker nodes không có khả năng quản lý toàn bộ Swarm. Chúng chỉ thực hiện công việc chạy container và thực hiện tasks được giao.
  5. Tính Khả Dụng và Mở Rộng:

    • Một cluster Swarm có thể có nhiều worker nodes để tăng khả dụng, mở rộng và phân chia tải công việc một cách hiệu quả.
  6. Distributed State Store:

    • Các worker nodes đồng bộ thông tin của mình với các manager nodes thông qua hệ thống internal distributed state store (thường sử dụng Raft Consensus Algorithm).
  7. Service Discovery:

    • Các worker nodes có khả năng tham gia vào một service để chạy các container của dịch vụ đó. Các service này có thể được quản lý bởi manager nodes.
  8. Không Có Quyền Quản Lý Swarm:

    • Worker nodes không có khả năng thực hiện các tác vụ quản lý như tạo dịch vụ mới, cập nhật service definitions, hoặc quản lý trạng thái swarm.
  9. Điều Khiển Container Cụ Thể:

    • Worker nodes chỉ chịu trách nhiệm cho việc điều khiển các container cụ thể mà chúng chạy. Các nhiệm vụ khác, như cân bằng tải và quyết định nơi triển khai các container, được thực hiện bởi manager nodes.

Trong một Swarm, worker nodes đóng vai trò quan trọng trong việc chạy và duy trì các container, làm tăng khả năng mở rộng và đảm bảo tính chịu lỗi của ứng dụng phân tán.

Kiến trúc bên trong Docker Service

Trong Docker Swarm, một service là một định nghĩa của ứng dụng hoặc một phần của ứng dụng mà bạn muốn triển khai và quản lý trên một cluster của các máy chủ Docker. Dịch vụ này có thể bao gồm một hoặc nhiều container chạy cùng một phiên bản cụ thể của ứng dụng đó. Docker Swarm sẽ quản lý việc triển khai và vận hành các dịch vụ này trên các worker nodes trong cluster.

Dưới đây là một số đặc điểm quan trọng của service trong Docker Swarm:

  • Container:

    • Container là thành phần cơ bản của Docker Service. Mỗi dịch vụ được triển khai thành một hoặc nhiều container.
    • Mỗi container chứa một phiên bản cụ thể của ứng dụng hoặc dịch vụ bạn đang triển khai.
  • Task:

    • Mỗi container chạy trong một Task. Task là một phiên bản cụ thể của một dịch vụ và đại diện cho một instance của nó.
    • Các task được quản lý và phân phối trên các worker nodes trong Docker Swarm.
  • Định Nghĩa Dịch Vụ (Service Definition):

    • Một service được định nghĩa thông qua một tập hợp các thông tin, bao gồm:
      • Image Docker: Hình ảnh Docker mà dịch vụ sẽ sử dụng để triển khai các container.
      • Cổng (Port): Cổng mà dịch vụ sẽ lắng nghe và chia sẻ.
      • Biến Môi Trường (Environment Variables): Các biến môi trường cần thiết cho việc cấu hình của ứng dụng.
      • Các tùy chọn khác: Như số lượng replica (bản sao) của dịch vụ, các thiết lập mạng, v.v.
  • Scalability (Khả Năng Mở Rộng):

    • Bạn có thể chỉ định số lượng bản sao (replicas) của dịch vụ mà bạn muốn triển khai. Docker Swarm sẽ tự động phân phối các bản sao này trên các worker nodes.
    • Việc này giúp tăng khả năng mở rộng và cải thiện khả năng chịu lỗi.
  • Load Balancing (Cân Bằng Tải):

    • Docker Swarm cung cấp cân bằng tải tự động cho các dịch vụ. Các yêu cầu đến dịch vụ sẽ được phân phối đều đặn đến các container chạy dịch vụ trên các worker nodes.
  • Service Discovery (Khám Phá Dịch Vụ):

    • Dịch vụ được kết hợp với một tên miền DNS duy nhất, giúp các container khám phá và giao tiếp với dịch vụ thông qua tên miền đó.
  • Updating Services (Cập Nhật Dịch Vụ):

    • Bạn có thể cập nhật dịch vụ bằng cách thay đổi service definition và sử dụng lệnh docker service update.
    • Docker Swarm sẽ thực hiện cập nhật mà không làm gián đoạn dịch vụ.
  • Service Rolling Updates (Cập Nhật Tự Động):

    • Docker Swarm hỗ trợ cập nhật tự động của dịch vụ theo cách tự động và kiểm soát được quá trình triển khai mới, đảm bảo rằng dịch vụ luôn khả dụng.
  • Distributed State Store:

    • Dữ liệu về service, tasks, và node được lưu trữ và đồng bộ qua hệ thống internal distributed state store giữa các Manager Nodes.

Sử dụng service trong Docker Swarm giúp quản lý và triển khai ứng dụng phân tán một cách dễ dàng và hiệu quả, cung cấp tính năng mở rộng và chịu lỗi tự động.

Thành phần bên trong manager và worker node

Khi chúng ta sử dụng CLI để tạo 1 service -> ngay lập tức cmd này sẽ được gửi đi thông qua 1 API đến manager node.

1. Manager node api

Manager Node API (Application Programming Interface) trong Docker Swarm là một tập hợp các giao diện lập trình ứng dụng (API) cung cấp các dịch vụ và chức năng để tương tác với và quản lý Docker Swarm từ các ứng dụng bên ngoài. API này cho phép các ứng dụng và công cụ tự động hóa thực hiện các thao tác liên quan đến việc quản lý cluster Docker Swarm, như triển khai dịch vụ, cập nhật Image, thêm hoặc xóa nodes, và nhiều thao tác khác.

Manager Node API cung cấp một cổng giao tiếp cho các ứng dụng và dịch vụ để tương tác với Docker Swarm thông qua các yêu cầu HTTP. Các yêu cầu này có thể được thực hiện bằng cách sử dụng HTTP methods như GET, POST, PUT, và DELETE

Dưới đây là một số API endpoints phổ biến mà bạn có thể gặp khi làm việc với Docker Swarm:

  1. Dịch Vụ (Services):

    • GET /services: Lấy danh sách các dịch vụ trong Swarm.
    • POST /services/create: Tạo một dịch vụ mới.
    • GET /services/{id}: Lấy thông tin chi tiết về một dịch vụ cụ thể.
    • PUT /services/{id}/update: Cập nhật một dịch vụ.
  2. Nodes:

    • GET /nodes: Lấy danh sách các nodes trong Swarm.
    • GET /nodes/{id}: Lấy thông tin chi tiết về một node cụ thể.
    • POST /nodes/{id}/update: Cập nhật một node trong Swarm.
  3. Raft Consensus:

    • GET /swarm: Lấy thông tin về trạng thái của Swarm, bao gồm cả thông tin về Raft Consensus.
  4. Overlay Network:

    • GET /networks: Lấy danh sách các mạng trong Swarm.
    • POST /networks/create: Tạo một mạng overlay mới.
  5. Tasks:

    • GET /tasks: Lấy danh sách các tasks trong Swarm.
    • GET /tasks/{id}: Lấy thông tin chi tiết về một task cụ thể.
  6. Service Secrets:

    • GET /secrets: Lấy danh sách các secrets trong Swarm.
    • POST /secrets/create: Tạo một secret mới.

Sau khi API xử lý dịch ra những tác vụ bên trong để tương tác với phần Ocrchestractor

2. Manager Node Orchestrator

  • Reconciliation loop for service objects and create tasks để mình tách ra cho bạn rễ hiểu hơn:
  1. Reconciliation Loop (Vòng Lặp Hòa Hợp):

    • "Reconciliation loop" là một khái niệm trong quản lý tài nguyên và trạng thái hệ thống. Nó đề cập đến quá trình kiểm tra và đảm bảo tính nhất quán giữa trạng thái hiện tại của hệ thống và trạng thái mong muốn.
  2. Service Objects (Đối Tượng Dịch Vụ):

    • Trong ngữ cảnh của Docker Swarm hoặc các hệ thống container orchestration khác, "service objects" có thể đề cập đến định nghĩa của một dịch vụ cụ thể mà bạn muốn triển khai và quản lý. Đối tượng dịch vụ bao gồm các thông tin như hình ảnh Docker, cổng lắng nghe, biến môi trường, số lượng bản sao (replicas), và các tùy chọn khác.
  3. Create Tasks (Tạo Nhiệm Vụ):

    • "Tasks" là các phiên bản cụ thể của một dịch vụ đang chạy trên các nodes trong một cluster. Việc tạo tasks thường được thực hiện để triển khai dịch vụ và đảm bảo rằng số lượng bản sao (replicas) được quy định đang chạy và duy trì tính nhất quán.

Vậy, "Reconciliation loop for service objects and create tasks" có thể ám chỉ một quá trình tự động kiểm tra và điều chỉnh trạng thái của các đối tượng dịch vụ, đồng thời tạo hoặc cập nhật các nhiệm vụ (tasks) để đảm bảo rằng trạng thái thực hiện của hệ thống đồng bộ với trạng thái mong muốn được đặt ra. Điều này thường được thực hiện để đảm bảo tính nhất quán và hiệu suất của các dịch vụ chạy trong môi trường container orchestration như Docker Swarm.

3. Allocator

Sau khi API xử lý Manager Node Ocrchestractor nó sẽ có bộ Allocator để quản lý các địa chỉ IP và gán Ip cho các tasks hay còn gọi là gán các IP cho các containers

4. Scheduler

Trong Docker Swarm, Scheduler không phải là một phần của Raft Consensus Algorithm. Raft được sử dụng để đảm bảo tính nhất quán giữa các Manager Nodes trong Docker Swarm, trong khi Scheduler chịu trách nhiệm quyết định cách triển khai các containers trên Worker Nodes.

Dưới đây là mô tả về Scheduler và vai trò của nó trong Docker Swarm:

Scheduler:

  • Scheduler là một thành phần quan trọng trong Docker Swarm, chịu trách nhiệm quyết định cách triển khai các containers trên các Worker Nodes.
  • Khi một service được tạo trong Docker Swarm, Scheduler quyết định nơi triển khai các containers của dịch vụ đó trên các Worker Nodes.
  • Scheduler sẽ xác định xem container nên chạy trên Worker Node nào dựa trên các tiêu chí như tài nguyên có sẵn, trạng thái health check của node, và chiến lược phân phối cân bằng tải.
  • health check và kiểm tra các tải của các node vật lý sau đó nó phân phối các tasks về các node vật lý.

Raft Consensus Algorithm:

  • Raft không trực tiếp liên quan đến việc quyết định nơi triển khai các containers trên Worker Nodes. Nhiệm vụ chính của Raft là duy trì tính nhất quán giữa các Manager Nodes trong Docker Swarm bằng cách quản lý trạng thái và quyết định về leader trong mỗi term.

Trong tóm tắt, Scheduler và Raft Consensus Algorithm đóng vai trò khác nhau trong Docker Swarm. Scheduler quyết định cách triển khai và quản lý containers, trong khi Raft đảm bảo tính nhất quán giữa các Manager Nodes. Cả hai đều đóng vai trò quan trọng để cung cấp một hệ thống Docker Swarm phân tán, linh hoạt và ổn định.

5. Dispatcher 

- Dùng để health check các node worker để kiểm tra xem là các containers trên đó có chạy ổn hay không? hay có lỗi gì không? nếu có lỗi nó sẽ giúp chúng ta khởi tạo lại container trên các  node đó.

 
 
 
 
 
 
 
 

Bình luận (0)

Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough
Michael Gough

Bài viết liên quan

Learning English Everyday