Kubernetes core concepts: Part 1 - 2

[bmson7112]

Nguyễn tắc hoạt động Cloud

• Đóng gói container:

  • Thực hiện công việc độc lập, không cần phụ thuộc vào hệ điều hành

• Quản lý linh hoạt:

  • Các hoạt động được lên lịch và điều phối

• ĐỊnh hướng microservice:

  • Các liên kết "lỏng lẻo" với phụ thuộc đươc mô tả rõ ràng: Các thành phần tương tác vói nhau 1 cách độc lập mà khoog ảnh hưởng tới các thành phần khác => Dễ mở rộng, bảo trì

• Tại sao lại sử dụng container, nó có những đặc điểm, lợi ích gì ???

  • Tính di dộng
  • Độ tin cậy
  • Chi phí thấp
  • Tối ưu hóa khi sử dụng tài nguyên
  • Tăng năng suất
  • Hạn chế sự phụ thuộc, xung đột

• So sánh VM với container:

  • VM:
    • OS cử dụng trên phần cứng ảo
    • Sử dụng trình ảo hóa
    • Cấu hình phần cứng mặc định
  • Container:
    • Tách rời app với OS
    • Ít ngốn tài nguyên, có thể hạn chế được
    • Không phụ thuộc vào hệ điều hành

      Kubernetes

  • Là công cụ mã nguồn mở quản lý các cluster
    • Có khả năng tự động : Deloy, managing, scaling app, ...
  • Quản ly bởi CNCF, có cộng đồng phát triển tốt
  • Có thể chạy trên nhiều nhà cung cấp khác nhau

Pods ( Tại sao sử dụng)

• Ứng dụng được tính kế thừa:
  • Có nhiều tính năng bổ sung
  • Chia thành các thành phần chắc năng riêng biệt, độc lập => Cải thiện tính module, tính bảo trì, khả năng mở rộng
  • Có khả năng tái sử dụng
    • Nếu được thiết kế phù hợp, các container có thể được sử dụng lại bởi các app khác
• Các đặc trưng chính:
  • Trong 1 pod có các thành phần như container chính và phụ, xử lý logic có thể bao gồm cả main container
  • Tách biệt nên có khả năng tái sử dụng
  • Mỗi container có thể có 1 tài nguyên riêng
• Các yêu cầu tì nguyên cuả Pod:
  • Mỗi Pod tương ứng với 1 tài nguyên cụ thể, từ đó K8S sử dụng thông tin này để tối ưu hóa tài nguyên
  • Các Pod càng quan trong thì càng được triển khai trước
• So sánh VM với K8S:
  • VM:
    • Chạy trên máy chủ vật lý, phải cấp tài nguyên cho nó
  • K8S:
    • Gọn nhẹ, ko yêu cầu phần cứng, có tính đóng gói
    • Cho phép nhiều container chạy trên 1 máy chủ duy nhất, cung cấp cơ chế lập lịch cho các node trong 1 cluster ( Cơ chế lập lịch: Tùy thuộc vào tài nguyên của node -> Xác định container nào được triển khai trên node đó)

API - Rest

• REST/ JSON based:
  • Tất cả giao tiếp qua API này
  • Có các phiên bản rõ ràng để phù hợp với các thay đổi
• API - kubectl: Giao diện commanline cho API
• VD: Creating resources: Tạo mới, update resources từ file .yaml ta dùng lệnh kubectl apply -f [file/dir/url]

K8S architecture

• Worker nodes:
  • Là những node thực sự chạy các app
  • Có CPU, RAM để xử lý
  • Kubelet:
    • Quản lý Pods: Giám sát Pods, đảm bảo các container chạy
    • Quản lý Container: Tương tác với container runtime( VD:Docker) để tạo, xóa, update,...
    • Cập nhật Pod
    • Quản lý tài nguyên Quan trọng: Kết nối URL tới API Server để báo cáo trạng thái các Pod, Container => Cấu hình URL là rất quan trong để liên kết kubelet với K8S
  • Kubeproxy:
    • Chuyển tiếp các luồng giao thức TCP, UDP,... => Điều hướng hoạt động đến các Pod phù hợp
  • Container engine:
    • Quản lý các container triều nhiều node khác nhau
    • Tạo ra các container
    • Quản lý tài nguyên container, điều phối chúng

• Control plane

  • etcd: Lưu trữ thông tin cấu hình node, pod, service, .....

    • Xử lý các yêu cầu đọc, ghi
    • Xóa phiên bản cũ ko dùng nữa => Nâng cao hiệu suất
    • Có khả năng phân quyền => Nâng có tính bảo mật

  • Schedule:

    • Lựa chọn pod nào chạy trước, container nào được triển khai trên node
    • Phân bổ pod đến node phù hợp

  • API server:

    • Là điểm truy cập duy nhất để client tương tác với server
    • Giúp:
      • Quản lý tài nguyên, Pod, delpoyment, service, ..
      • Xác thực phân quyền
      • Lập lịch, điều phối
      • Update trạng thái
      • ( Xác thực quyền -> tìm tài nguyên ( etcd ) -> CRUD -> thông báo để update dữ liệu)

  • Controller manager:

    • Quản lý các controller: Replicaset, Deployment, StatefullSet,....
    • Quản lý trạng thái tài nguyên
    • Điều phối (Tạo mới pod, mở rộng, update)

Config Pod, container:

• Probes:
  • Liveness: Kiểm tra tính sống (hoạt động) của 1 container, cho phép tự khởi động lại nếu chạy không đúng cách
  • Readiness: Kiểm tra coi có sẵn sàng phục vụ không, nếu sẵn sàng thì sẽ được kết nối với mạng
  • Exec: Chạy comman line ngay trong container để kiểm tra
  • Ứng dụng:
    • Khơi tạo bộ đệm: chỉ định Readiness khi bộ đệm nóng
    • Đảm bảo JVM khởi động thành công
    • Bảo trì container
  • Các options của Probes
    • initialDelaySeconds: Thời gian trì hoãn sau khi container được bắt đầu
    • periodSeconds: Tần suất thăm dò( thường là 10s )
    • timeoutSeconds: Mặc định là 1

Các thành phần trong file .yaml

• kind: Nhiều loại, thường sẽ là pod, service, deployment, statefulSet, ...

  • Pod: 1 pod chứa 1 hoặc nhiều container, và kind: Pod cấu hình các container chạy trong nó
  • Service: ĐỊnh nghĩa 1 tập hơn các pod, cung cấp cách truy cập các pod này qua ID,DNS,...
  • Deployment: ĐỊnh nghĩa 1 tập Replicat để quản lý 1 số lượng Pod
    • RollingUpdate: Mặc định
      • Replicaset được tạo mới mở rộng quy mô, còn Replicaset cũ bị thu hẹp lại
    • Recreate:
      • Xóa tất cả các Pod cũ trong Replicaset ban đầu
      • Tạo các Pod mới trong Replicaset mới
  • StatefulSet: Tương tự deployment, thêm tính năng, VD: khả năng cập nhật Pod tuần tự, ....
  • DeamonSet: Đảm bảo 1 node <=> Số lượng Pod cụ thể. Tức là: Mỗi 1 node trong cluster sẽ có 1 bảo sao của Pod này được triển khai

• tier: Đánh giá mức độ quan trọng, độ ưu tiền của tài nguyên đó, xác định tài nguyên đó thuộc lớp nào, nó là gì (VD: BE, FE, ...)

• track: Xác định phiên bản của 1 tài nguyên ( canary, stable, ...)

• Resources request:

  • Yêu cầu tài nguyên tối thiểu
  • Giúp K8S lên lịch cho các Pod hiệu quả hơn
  • Pod được lên lịch neus khả năng của node(tài nguyên) lớn hơn yêu cầu tài nguyên của các container

• Resources Limit:

  • Bảo vệ trước 1 app luôn chạy
  • Nếu 1 container chạy quá giới hạn tài nguyên, nó có thể bị dừng
  • Container vượt quá yêu cầu bộ nhớ, Pod của nó sẽ bị xóa bất cú khi nào Node của nó hết bộ nhớ

Một số lệnh hay dùng để kiểm tra và khắc phục

• Event log: Nhật ký sự kiện, ghi chép lại các sự kiện trên cluster, mặc định là trong 1h kubectl get events
• Lấy danh sách các đối tượng Pod, thêm thông tin của chúng kubectl get o -wide
• Lấy thêm thông tin về 1 object (bao gồm cả event) VD: 1 pod: kubectl describe pod ....
• Lấy log của 1 pod: kubectl log ....