1.5K 85 29

Đã đăng vào thg 8 22, 2016 9:56 CH 9 phút đọc

4.3K

Giới thiệu về Kubernetes - Docker cluster tool của Google

Bài đăng này đã không được cập nhật trong 3 năm

1. Nguồn

2. Động cơ

Một buổi chiều rảnh rỗi nơi xứ sở Anh Đào, mình quyết định tìm hiểu thêm về Docker và cách vận hành của nó, từ khoá Kubernetes đã xuất hiện rất nhiều trong lĩnh vực này. Hy vọng bài viết sẽ giúp các bạn hiểu thêm về thế giới vận hành Docker.

3. Bài viết

Kubernetes?

Các bạn biết từ trên đọc thế nào không? Tôi đã thử tra từ điển nhưng cũng đành bó tay. Sau khi nhận được comment từ mọi người thì có vẻ tôi đã hiểu được đôi chút về ý nghĩa và cách đọc của Kubernetes ・Ý nghĩa: "người lái tàu" trong tiếng Hy Lạp ・Cách đọc: Cu-ba-ni-tê-sờ

Bối cảnh

Tôi nghĩ rằng Docker chỉ có ý nghĩa cách mạng về mặt "có thể chia sẻ phần sai khác của các container image dung lượng nhẹ một cách đơn giản".

Còn thực chất nó không thể scale out bằng 1 command như Heroku hay CloudFoundry, cũng chẳng thể deploy một phát bằng git push, thậm chí không có cơ chế monitoring xem các service có đang hoạt động liên tục một cách bình thường hay không.

Mặc dù trên thế giới hiện nay đang có một phòng trào hiện thực hoá Immutable Infrastructure bằng Docker, tuy nhiên một vấn đề quá lớn hiển hiện đó chính là bạn không thể vận hành chỉ bằng Docker được. Kubernetes được sinh ra để khoả lấp vấn đề trên.

Sơ lược

Nếu các bạn có đọc Overview của Kubernetes, kubernetes cung cấp clustered container scheduling service dưới dạng bọc Docker lại.

Có thể các bạn sẽ hơi khó hiểu với khái niệm scheduling, tuy nhiên trong việc quản lý cluster có một thứ gọi là orchestration rất hay được sử dụng, schedule chính là phiên bản orchestration đã được tiến hoá.

Các bạn sẽ hiểu rõ hơn khi tôi giải thích về Pod ở bên dưới.

Architecture

Hình toàn thể

Trong tài liệu design của Kubernetes có viết quá nhiều thứ làm tôi cảm thấy rất khó hiểu, chính vì thế tôi đã quyết định tóm tắt lại bằn hình ảnh nưh dưới đây (có chuẩn xác hay không thì vẫn còn chút đáng nghi...)

Node

Node chính là đơn vị của nhân tố cấu trúc lớn nhất. Nói cụ thể hơn thì nó chính là những thứ như CoreOS, support Host OS của Docker Container. Tôi nghĩ rằng về mặt vật lý nó bằng với bare metal (computer không có OS) hay 1 virtual machine của Iaas/VMWare..

Để hình trên được dễ hiểu, tôi đã viết luôn là CoreOS, tuy nhiên trên thực tế thì tài liệu design không có ghi như vậy.

Container

Container thì vẫn thế thôi, là đơn vị container ảo hoá của Linux container. Đến đây vẫn chỉ là câu chuyện bình thường về Docker mà thôi.

Pod

Từ đây sẽ có các khái niệm riêng của Kubernetes. Pod chính là thứ tập hợp các container lại. Tuy nhiên không chỉ đơn thuần là tập hợp lại, một nhóm các container đã được schedule để tồn tại trên cùng một Node mới được gọi là Pod. Khái niệm về schedule có vẻ nó sẽ không phải là bảo đảm nằm trên một Node nào, tuy nhiên container của cùng 1 Pod nhất định phải nằm cùng một nơi.

Do nằm trên cùng 1 node, cho nên việc chia sẻ network hay storage, chia sẻ data, deploy hay scaling.. có thể dễ dàng coi như làm đối với một đơn vị riêng biệt.

Ví dụ: Container trong Pod có vẻ dự kiến sẽ cung cấp chức năng xung quanh như cache, backup, lấy log, Proxy hay quản lý... Bằng việc đặt container cung cấp các chức năng xung quanh dễ ảnh hưởng tới performance ở gần container chứa app sẽ giúp cải thiện hiệu suất.

Kubelet

Kubelet có nhiệm vụ khởi động/duy trì Pod/Container thông qua việc đọc manifest file của Pod được viết bằng YAML. Nhìn vào trong nội dung của manifest file chúng ta có thể thấy rằng tại đây có thể chỉ định Docker image cũng như biến môi trường, volume hay port sử dụng.. Mặc dù trong tài liệu có viết là manifest sẽ tồn tại trong từng đơn vị Pod, tuy nhiên khi nhìn vào manifest file thực tế sẽ thấy nó không hề đề cập gì tới cái tên Pod, cho nên tôi không dám chắc về hiểu biết chỗ này lắm. (Nếu nhìn kỹ một chút thì link phía trên không phải là của Kubernetes mà là của GCE.. ) Ngoài ra, thông tin manifest có thể update được bằng rất nhiều cách, ví dụ bằng file, HTTP endpoint, etcd hay HTTP server..

Label

Label là dạng key-value định nghĩa đơn giản nhiệm vụ của các Pod. Ví dụ: bằng việc thêm label như environment=dev, environment=production, tier=frontend hay tier=backend, ta có thể phân biệt Pod này là để develop hay production, ngoài ra là front server hay backend server, rồi từ đó tổng hợp theo từng Label để thực hiện deploy.., rất hữu ích với mặt quản lý.

Thêm nữa label cũng được sử dụng tại cơ chế scale, khi tạo mới Pod có gắn label nhất định sẽ tự động scale out, nếu xoá label sẽ tự động scale in.

Một Pod có thể chứa nhiều Label.

Proxy

Cơ chế forward access tới node đã được định nghĩa như một service. Có vẻ nó cũng tương tự như load balancer dùng để access vào service

Master

Thứ quản lý những thứ khác của các loại Node chính là Master. Về cơ bản thì nó có nhiệm vụ nhận những điểm thay đổi về cài đặt rồi triển khai.

API Server

Đúng theo tên gọi, đây chính là server cung cấp Kubernetes API. Nó có nhiệm vụ đặt Pod vào Node, đồng bộ hoá thông tin của Pod bằng REST API tiếp nhận cài đặt của pod/service/replicationController.

etcd

Có thể liên kết cài đặt với từng node thông qua etcd.

Network Model

Xung quanh mặt Network, Docker thường sử dụng port forwarding khá phiền phức. Hiện đang xem xét rất nhiều cách để cải thiện vấn đề này bao gồm sử dụng tool hay Pipework..

Kubernetes cũng muốn support về mặt này, chính vì thế mục tiêu là IP sẽ được phân chia theo đơn vị Pod.

Môi trường support

Hiện nay mới chỉ support GCE, tuy nhiên trong README.md cũng có viết sẽ support thêm nhiều môi trường trong tương lai. Nếu các bạn không có tài khoản GCE thì không thể Getting Started được. Khi nhìn source sẽ thấy đã có một thư mục tên cloudprovider được chuẩn bị sẵn, chính vì thế có vẻ sau này thư mục này sẽ được tăng lên để support các dịch vụ cloud khác. Các bạn sẵn sàng cống hiến để contribute cho chỗ này chưa?

Kết thúc

Khi nhìn vào tài liệu design sẽ thấy có rất nhiều chỗ mới trong quá trình định hướng (chưa implement), product này sẽ dần được hoàn thiện trong tương lai.

Ngoài ra tôi chưa thấy có hệ thống quan sát kiểu HealthManager của CloudFoundry. Về mặt nhiệm vụ thì Kubelet chỉ phụ trách duy trì container mà thôi, chính vì vậy tôi đã xem thử source nhưng cũng không thấy có chỗ nào làm việc như thế cả.

Có thể trong tương lai sẽ support chỗ này, tuy nhiên tôi có ấn tượng rằng về mặt chức năng nó vẫn còn đang thiếu nhiều.

Mesos cung cấp plugin dành cho Docker tên Deimos, CloudFoundry thì có Bosh, các công ty cạnh tranh đang rất cố gắng cung cấp nhiều chức năng nhằm hiện thực hoá vận hành hệ thống sử dụng Docker.

So sánh với các đối thủ cạnh tranh này, chúng ta sẽ chờ xem Kubernetes - sản phẩm được kỳ vọng để quản lý 2 tỉ container trong hệ thống của Google sẽ phát triển ra sao.